* 日々のメモ2013

Facebookで「いつかはゆかし」というウザい広告を消す方法

広告に起用しているタレントさんの目つきが、生理的に不快でした。
一度くらいならまぁいいかと思いましたが、繰り返し出てくるので「狙い撃ち」で対策しました。


私はこれで消すことができました、という話なので、あらゆる環境で消せるかは不明です。悪く思わないでください。

私は、Linux(Fedora17)を使っています。ブラウザはFirefox17.0.1です。
Firefoxのプラグイン、Adblock Plus 2.2.1 を使っています。


アドオンの 設定 -> フィルタ設定 で、以下のフィルタを追加します。

##li[class="uiUnifiedStory uiStreamStory genericStreamStory aid_367590283324440 uiListItem"]

以上です。

---

なお、広告全部を消すのではなく、写真だけを消すのであれば

##a[class="uiPhotoThumb largePhoto"]

でOKでした。

---

てへぺろ。

スパムメール、もしくはフィッシングメールの新手が来ましたよ。

配送業者の誤配通知を装っているようです。



私はこの年末年始にFedExなんて使っていないので、見た瞬間に「怪しい」と思いましたが、確かにこの時期こんなメールがきたらクリックしてしまいますよね。敵ながらあっぱれってやつです...。

皆さん、注意しましょう。

250バイクか、スクーターか、自転車か、何らかの移動ツールを買おう、と思っていたのですが、

やはり

タバコを吸わない人間関係が欲しい！
タバコを吸わない明確な動機が欲しい！

という想いで、自転車を注文しました。

20年ぶりのロードレーサーです。

学生の時、初めての練習前、メットかぶって、ビンディングはめて、5分で立ちゴケしたことを覚えています。
なれるまでは安全なところで乗ろう…。

そして、20年ぶりに"スネ毛を剃ってるひと"になります。

買いました。



【+.自転車】

---

Fedora17、ddclientの件。

/var/lock/subsys/network とか
/var/lock/sybsys/NetworkManager が
存在しないと終了するようになっていて、そんなものはもはやないので終了してた。
もとは「ネットワークに接続していないときには終了する」いとだったのだろうけど。

http://forums.fedoraforum.org/showthread.php?t=277567

あと、/var/run/ddclient/ddclient.pid が作れないってことだったのでディレクトリを作成、グループddclientで読み書きできるようにしてやった。

これでうまく動いてるようだ。

ツイッター、その他インターネットブログでAdobe祭りになっとる…

リンク	備考
Adobeが『Photoshop』や『Illustrator』などを無償提供！	痛いニュース

ツイッターの祭り状態のスクリーンショットがこちら。



と思ったら、アクティベーションサーバを停止するための正規ユーザの救済措置だそうで。

リンク	備考
UPDATE: Adobe is not giving away free copies of its CS2 software package	Adobe公式

ふむぅ。
旧バージョン無償公開という、新たなソフトウェアビジネスのモデルか？
と期待したのですが、そういうわけではなさそうです。

個人的にはこれがツボにハマりました。



(*´∀｀;) ハハハ...

結局…


幾つになっても孤独を脱する事は無い。
ただ、それに慣れていくだけだ。



男女の違い、世代の違い、感性の違い

僕は君じゃないし君は僕じゃない

日清食品の「どん兵衛」の袋麺があったので買ってみました。

これ、いいです。何がいいって、まるいのがいい。



1人分の鍋にちょうどフィットします。



日清食品、やるな！

個人的な経緯で、「どん兵衛」のカップ麺には思い入れがあるのですが、袋麺もよいです。

【* 日々のメモ】

ちょっと思う所があり、このドメインの新しいコンテンツを作成中です。

Wikiシステムのストレージとして、Gitを使いたい。のだが、意外と対応している物が少ないようで、決めかねています。

git-wikiてのとikiwikiてのを見ていますが、うーむ。


【* 日々のメモ】

サイクリングに行って来ました。

環状2号を南下して、NAPSの辺りまで行って、海を見て、帰ってきました。往復で40km強。
本当は八景島シーパラダイスまで行きたかったのですが、お尻が痛くて断念。

これ、慣れるまで痛いんですよね。レーサーパンツ2枚重ねて履いてたのに、痛い。

あと、降りた時に歩きやすい事を期待して、シマノのMTB用のビンディングペダルを選んだのですが、これ、思いのほか悪いです。

降りた時の歩きやすさは期待通りだったのですが。

普通のレーサー用のペダルと違って重心が真ん中にあって、はめる時に同じ向きになってない！ので、いちいち見て向きを確認しないといけない。これが、めっちゃくちゃストレスになります。

あと、ストレスと感じたのが、初装備のブレーキ一体型の変速レバー。左右で、操作と、その結果どうなるのかの統一性が無いので、UIとして非常にわかりにくい。これ、オレが品証担当だったら不合格にしたい。

まぁ、引っ張る操作と緩める操作なんだって事で、メカの動作をイメージして覚えるしか、現状では方法が無いんだろうなぁ。

【* 日々のメモ】

久しぶりに雪が積もりました。横浜は13cmだったそうです。

雪だるま…と思って
結局こうなりました。



ゆうべ作ったときはもう遅かったので、明るくなったとことで撮ってみました。







次にこんなに降るのは何年後でしょうね。

【* 日々のメモ】

以下、別ページを内包:+ 日本語コーディング・各言語で
PARA(){\+ 日本語コーディング・各言語で}

---

今、なにか作るなら Python3 だな！

mod_python で .pyp .psp とかできるし(いわゆるaspとかjspとかphpみたいな、CGIと図と地が入れ替わってるやつの、Python版)。

PHPは卒業しよう…。

---

あと、関係ないけど RDBMS に代わるDBMSって、昨今の分散バージョン管理システムでいいんじゃね。レプリケーションも簡単にできるし。

分散バージョン管理システム	親和性の高い言語
Git	perl
Mercurial(hg)	python

てことで、おいらは python(2), python3, hg で行きます、これからしばらく。

---

また別の話。
昔、フリーのWebページサイトを、「Webページ作成中です」っていう体で、自分専用のFTPバックアップ場所にする方法があったけど…

今ならさ。
なんか「フリーソフト開発してます」っていう体で、GitかMercurialのリポジトリをGoogleかどこかに作って、それをWebアクセスできるようにすれば、普通にWebサイトを無料で作れると思う。
しかもバックアップ簡単、壊れたときの復旧も楽。
Wiki的な記法も使える。GitならMarkdown、MercurialならreStructuredTextが親和性高い。
WindowsのGUIから操作できるToutoiseGit、ToutoiseHgもある。

ねぇ。


【* 日々のメモ】

コールバック プログラミングの、次の話。

python の yield 文おもしろい。

リンク	備考
yield 文	Pythonリファレンス(3.3)(2系にもここから飛べる)
PEP 255	yield文を機能拡張として導入するときの提案文書。18-May-2001

シンプルな例、を引用。フィボナッチ数列を順に返すプログラムだね。

       def fib():
           a, b = 0, 1
           while 1:
               yield b
               a, b = b, a+b

yeild は return みたいなものなんだけど、returnじゃない。関数全体はイテレータを生成して返す。 yield は、イテレーションの1個の値を追加する。


こういうことだと理解した。

呼ばれた側が、呼び側に何らかの影響を及ぼすような値を、次々に返す、ていうプログラムを作りたい場合の話。

古来は、グローバルな状態マシンに記憶しつつコールバックで実現するのが普通で、それは今(?)でも典型的な実装なのだけど、分からない人には分かりにくい。わかりやすいのはスレッドを使ってしまうことだけど、スレッドは使えない環境があるし、遅い。

返却値をリストにして返す方式で、何も考えないと全部作ってからドカンと返す実装になって、現実的じゃない。

そこで、イテレータ（リストから値を順に取り出せる）を返すことにする、と。で、呼び側が .next() とやったら1個取れればいいので、そのつど「呼ばれた側」がレジュームして次の1個を格納する方式なら、スレッドを使わなくて済む。スレッドみたいに、どこで割り込まれるか分からない、なんていう厄介な事を考慮する必要がないし、割り込まれる場所が明確なので、ロック・アンロックを作り込む必要がない。

と。そんなところかな。
この概念いいね。

この話で私が大事だと思う事は、プログラマが「ここで割り込んでね」と思うところでだけ割り込まれる仕組みである、ということ。

昔々の格言で、

割り込みが1回発生するとプログラマの白髪が1本増える

てのがあって、スレッドにもその考えが当てはまる。
んでも、コールバックってのは、割り込みがどこで起こるかがプログラマにとって明確だから、上記に該当しない。ただし、コールバックの概念はちょっと中上級者向け。

私は、この話って充分「計算機科学の問題の一つ」だと思っている。

yield 文てのは、この問題に一石を投じるものだね。


2001年から公開されてた話だなんて、全然知らなかったよ…アンテナ低いぞ、俺。

---

リンク先の文書で コンシューマ-ジェネレータ(のプログラムパターン) て言葉がある。
そう、確かに、この概念は「パイプライン方式のプログラミング」=「有向グラフ接続方式のシステム開発」に有効だね。
何度も書いたりつぶやいたりしてるけど、「Unixパイプ」はソフトウェア再利用のもっとも成功した例の一つ。しかもマルチコアにとても親和性がある。だから、yield文を有効活用するプログラミング方式を推し進めると、ソフトウェアの再利用性が劇的に向上し、かつ処理速度も向上する、可能性がある。


【* 日々のメモ】

新コンテンツ向け、画像作成プログラムの実験中です。

ポジションマーク


コードの主音を1とした度数


キーの主音を1とした度数


【* 日々のメモ】

ツイッター社が新アプリを開発したそうで、動画作成アプリだそうです。

リンク	備考
Twitter、最長6秒のループ動画を作成できるiOSアプリ「Vine」	internet watch

「最長140文字」でヒットしたツイッター社だけあって、「最長6秒」というのがポイントなのでしょう。
このニュースを見て最初に思ったのは、おいおい、猫画像、猫動画をこれ以上増やしたいのか…という事でした。去年のニュースで、インターネット上のデータをコンピュータに学習させたら、コンピュータが「猫」の概念を獲得した、という話がありました。それ程に、ネット上に猫動画や猫画像が溢れています。数百年後に今の時代を分析したら、実態よりも「猫が沢山いた」ていう分析結果になるんじゃないでしょうか？


その理由を考えてみると、いくつか思い当たることがあります。
ネットで公共に配信するときには、オリジナルのコンテンツでないと権利侵害になってしまいます。また、個人の情報を公開しすぎると、ストーカー被害の元になったり、興味本位の「うわさ」「陰口」をされるきっかけになる、という考え方もあります。
猫の画像や動画がネットに溢れるのは、猫が被写体テーマとして、誰にも身近であり、公に送信しても他人の権利を犯さず、送信者の個人情報の漏洩にもならず、多くの受信者からも感謝されるから、かもしれません。


昔、友人Aと一緒に、一人暮らし中だった友人Bの部屋に遊びに行った時の事を思い出しました。
友人Aは、友人B宅の冷蔵庫を漁り、プリンだかヨーグルトだかを見つけると「なぁ。これ食べていいか。後で買ってきたるわ」と言いました。
「それ、アカン」
「ええやん。後で何かこうて来たる」
「アカン。それ俺のちゃうんや」
「アホかw。ほな誰のやねん」
「それは…(沈黙の後)…猫のや」
とまぁこのように、猫は、人々の暮らしの中に、入り込んでいます。


(参考画像:wikipediaより)


という事で、最長6秒の動画を作成できるアプリ「Vine」、自宅で猫を飼われている方、自宅に猫のような何かがいる方は、このアプリで猫動画を配信してみてはいかがでしょうか。でも猫でなくても別にいいです。

手軽に短い動画を発信するツールとして、ツイッター社の次のヒットになることを期待したいと思います。
現時点ではiOSアプリのみで、Android版は開発中とのこと。私はAndroidユーザなので、まだ試すことができません。


なお友人Aは結局、「食ったる」と言って例のプリンだかヨーグルトを食べてしまいました。
「アカンて言うたやろ」
「別の猫が食ったことにしとけや」
「そんなん余計アカンわ」
そんな会話があったような、なかったような。

【* 日々のメモ】

うわーアクセスログにime.nuがあるよ…
めちゃくちゃ気になるけど気にしないようにしよう…

いろいろ痛い(イナタイ?)ことの自覚はあります。

---

どうやら、Unix板で話題になっていた模様。
日本のGoogleで シェル バイナリ で検索するとオイラのページがトップにきますよーイエーイ(自慢

【* 日々のメモ】

Mozilla Thunderbirdで、追加アカウントの設定ができなくて悩んだ。

どうやら、別のOSと /home を共通でマウントしていたのが原因で、~/.thunderbird/ フォルダが壊れていたらしい。

私はすべてのアカウントでIMAPを使っているので、ローカルPC上のフォルダなんか消えても大丈夫。てことで、.thunderbird.dis にリネームしてから全アカウントの設定をやり直したら、上手く行きました。


【* 日々のメモ】

来週はクマー先生だ！

来週月曜のNHKスーパープレゼンテーションは、クアドロコプターロボットのクマー先生（クマール先生？）らしい。楽しみです。

まぁ、

リンク	備考
ヴィージェイ・クーマー 「協力し合う飛行ロボット」	YouTube

と同じだと思うんですが...私、英語聞き取れないし...

---

懺悔します

昨夜、というか今朝なんですが、やらかしてしまいました。

ツイートボットの設定を間違えて、社外サーバに想定外の負荷をかけてしまいました。


crontab の設定を間違えました。

月曜から金曜の午前7時に1回だけ実行
0 7 * * 1-5 /パス/コマンド

と設定すべきところ、

月曜から金曜の午前7時に毎分1回実行
* 7 * * 1-5 /パス/コマンド

と設定してしまいました。

1回の実行で2ツイート実行するようにしていたため、50分程度経過したところで「1時間100回」のリミットを超過する結果になり、今日の17時過ぎまで status/update_with_media 禁止処分に。ひえぇ。ツイッターの中の人、ごめんなさい。これからは、あせらずちゃんと 内 -> 外 とテスト手順踏みます。

これって、規模は小さいですが、業界用語では「事故」と言われる事象です。しかも社内じゃなくて社外に迷惑をかけるものなので、重大。反省します。

---

禁止解けました。
cronによる起動、書き込み成功。よかった。
さぁ、どうすればもっと良くなるか、考えていこう。

【* 日々のメモ】

検索ワード上位のキーワード

いま「良いソフトウェア」でググったらこのサイトが一番上に来てたよ！単純にうれしいよ！

このサイトが上位に入る検索キーワードがいくつかあって、それは

Word UML

シェルスクリプト バイナリ

良いソフトウェア

などなどです。

私の仕事モチベーションの一つに「コンピュータエンジニアにとって有用な文書を書きたい」という願いがあります。
歩みは遅々としていますが、少しずつは前に進めているのかな、と思います。
これからも地道にやっていきたいと思います。


昔は

C# テトリス

とかもあったんですが今はダメポですね…。

---

ツイートボット稼働しました

music/20130206

PARA(){music/20130206}

【* 日々のメモ】

Stateパターン

Stateパターン(とStrategyパターン)を改めて検証中です。数日中に、ここに自分の短文を出そうとしています。
「例を使った説明」は、具体例がどれだけ適切かが大事なのよね。
「具体例の適切さ」という点において、GoF本はBestではない部分が多いと思う。

---

別の話。

「プロセスを起動する」か、「プロセスを起動させる」か

複数メンバで文書を書いているとき、「する」「させる」の統一性が問題になることがあります。
つまり、「プロセスを起動する」か、「プロセスを起動させる」のどちらか。

私は、迷うような例では全て「する」に統一したほうが、心地が良いです。
「する」の方が、誰がその行為をしたいと考えているかが明確で、技術文書としていさぎよい気がするのです。

この件で、こんなページを発見。

リンク	備考
最近気になる放送用語:「クロスする」？「クロスさせる」？	NHKのページ

Q:「（両手を）クロスする／クロスさせる」は、どちらを使ったらよいでしょうか。

A:「どちらも正しい」という人が最も多いのですが、その一方でこの場合には
「クロスする」はおかしいと考える人も少なからずいます。放送では、
特別な意図がない限り「両手をクロスさせる」のように言っておいたほうが無難でしょう。

うーむ。そうですか。またこんな記述も。

日本語として使われるようになってから歴史の浅い動詞の中には、「～を～する」
という形がよいのか、あるいは「～を～させる」という形がよいのか、しっかり
定まっていないものがときどきあるのです。ほかに、「（新連載を）スタートする／
スタートさせる」「（議論を）ストップする／ストップさせる」などがあります。 
(中略)
もしかすると、自然にクロスできるような状況では「両手をクロスする」、
なかなかクロスしにくい状況下で力を振り絞ってするのが「両手をクロスさせる」
といったような使い分けが、特に若い人たちの間にはあるのかもしれません。

勉強になりました。

コンピュータシステムの説明書では、プロセスの起動を、苦労して行うとか、努力を払って行う
といったニュアンスを含めるのは適切ではないと考えます。

やはり、私が決定できる範囲では、プロセスを「起動する」に統一していきたいと思います。

【* 日々のメモ】

ぬあー！Ubuntu12の /etc/resolv.conf 書き換えで宅内の名前解決が失敗する！そして対策したつもりなのに再発する！そっちをみるなと言うとろうが！

俺の環境設計がいけてないのかな？

むーん

【* 日々のメモ】

GoF本のStateパターンの件

自分だったら、Stateパターンをどう活用するか。


結論から書きます。

Stateパターンが活きるのは

Stateパターンが活きるのは、少なくとも、

• 目的を実現する機構を、状態遷移機械もしくは有限オートマトンとして設計した
• メッセージ数がとても多い
• 状態によって、受信者にとって関心のあるメッセージがガラッと変わる
• 状態によらず、送信者はメッセージを出しつづけたい

の全てを満たす場合、だと考えます。


GoF本のStateパターンの図

たくさんのイベントメッセージは、たくさんのメソッドの羅列で実現

状態基底クラス
 △
 |__具体状態クラス1
 |  ...
 |__具体状態クラスM

// 無視メソッド
int 状態基底クラス::メッセージ1処理メソッド(メッセージ1の具体パラメータ並び v1, v2)
int 状態基底クラス::メッセージ2処理メソッド(メッセージ2の具体パラメータ並び v1, v2, v3)
int 状態基底クラス::メッセージN処理メソッド(メッセージNの具体パラメータ並び v1)

// 具体状態クラス1 が メッセージ1 に関心があるとして 
int 具体状態クラス1::メッセージ1処理メソッド(メッセージ1の具体パラメータ並び v1, v2)

// 具体状態クラス2 が メッセージ1 と メッセージ2 に関心があるとして 
int 具体状態クラス2::メッセージ1処理メソッド(メッセージ1の具体パラメータ並び v1, v2)
int 具体状態クラス2::メッセージ2処理メソッド(メッセージ1の具体パラメータ並び v1, v2, v3)

「メッセージの振り分け」は、言語自体が持っている多態機能にマッピングします。


拡張Stateパターン

私が考える、現場で使えるStateパターン、つまり「拡張Stateパターン」はこうです。

• メッセージを、union構造体や継承関係を持つクラス群で実装する
• ので、「メッセージのうちどれか1つ」を受信できることを、union構造体もしくは基底クラス1つのパラメータ形式で表現しきれる

拡張Stateパターンの図

イベントメッセージ基底クラス
 △
 |__具体メッセージクラス1
 |__具体メッセージクラス2
 |  ...
 |__具体メッセージクラスN

状態基底クラス
 △
 |__具体状態クラス1
 |  ...
 |__具体状態クラスM

// 無視メソッド
int 状態基底クラス::メッセージ処理メソッド(イベントメッセージ基底クラス msg)

// 具体状態クラス1 が メッセージ1 に関心があるとして
int 具体状態クラス1::メッセージ処理メソッド(具体メッセージクラス1 msg)

// 具体状態クラス2 が メッセージ1 と メッセージ2 に関心があるとして 
int 具体状態クラス2::メッセージ処理メソッド(具体メッセージクラス1 msg)
int 具体状態クラス2::メッセージ処理メソッド(具体メッセージクラス2 msg)

実際の現場では何がうれしいのか

メッセージ数がN、状態数Mで、状態遷移機械は N x M の大きな一覧表で描けますが、実際の仕事で状態遷移機械を使うときは、NもMも大きな値になり、一覧表は米粒サイズの文字でA3用紙に数枚に渡って印刷するような状況に、よくなります。

そして、ある状態がほしいメッセージは、ごくわずかだ、つまり棲み分けがかなりできている、という状況になることが、よくあります。

このような状況では、「無視する」メソッドを基底クラスに書き、各状態を、別々のソースファイルで書くことで、改修時に「見なくてよいソースを早い段階で枝刈りでき、見なくてすむ」という、うれしい状況になります。

---

背景

そもそも、なんでStateパターンを再考しようとしたかというと...

リンク	備考
状態管理用の変数をインスタンスに持たせるな

この文書を見て、非常に違和感を持ったのです。

リンク先、著者さんの文書は...間違った事は言っていないと...思いたいです。
他のエントリを見ても、よく分かっている人が、極力わかりやすくしようと書かれていると感じます。

けれども、「bestでない例題によって、意図がわかりにくい説明になっている」ように思いました。

私自身、動物クラスを継承する犬や猫がワンニャーと鳴く、のような、「犬猫問題」を持ち出してしまった恥ずかしい過去があります。しかし、小規模プログラムでオブジェクト指向のメリットを説明するのは、本当に難しいのです。

ソフトウェア工学が問題にするのは大規模ソフトウェアを完納すること。中小規模はどうやろうと管理できる。ジャンボジェットをどう設計して完納しようか、という話においては、昆虫の飛行理論は、規模が違いすぎて、専門家にはほぼ別の話なのです。

苦言

揚げ足とりであることを承知で苦言を。

• classがならんでるところをswitch文で書いたとしても、ソースリストの視覚的複雑さ(可読性)は同じですよね。つまり、「if文の条件の並べ方を変えると見やすくなる」という例文になってしまっている。
• むしろnew処理がある分、switch文で書いた場合より処理が重い。

あとStateとは関係ないですが:
当初から決まっている要件をStateパターンで実装する話ではなく、次々に襲う仕様変更要求に対応する話になっていますが、このような論説は、十分な説得力を得ないことが多いです。

Stateパターンって何？

今回、Stateパターンとは何か、ということを深く考えました。

この文脈(だれかがGoF本のパターンを、ネット上のBlog等で物知りさんの立場で説明しているのを読んで、違和感を感じる)において、大事なことが3つあると整理しました。

• (1)「状態遷移機械」（などGoF本が取り上げるパターンの基礎となる概念）は、クラスの概念や、GoF本より遥か昔から存在しているものである
• (2) GoF本は「継承機能って、ウィンドウマネージャのプログラミング位にしか使えないよね」と言われていた時代背景において、「古くからある(ウィンドウマネージャ以外の)様々なソフトウェア概念を、クラスと継承関係を用いるとこのように実装できる」という例をたくさん例示した点で優れていたものであって、取り上げた例を実際にクラスと継承関係を用いて実装することが最適だと、比較検討するような事は、一言も言っていない
• (3) 本当の意味での「ソフトウェアの実装パターン集」としては、POSA本やPOSA2本のほうが、遥かに優れている

ということです。

難しい言い方でごめんなさい。要するに基本的な私の考えは、

GoF本は、OOP言語の継承機能の活用例としてはイケてるけど、ソフトウェアパターンとしてはそんなにイケてない

です。


で。

GoF本が示したStateパターンとは何か。私は、以下のものだと考えています。

• ソフトウェアを状態遷移機械として(=状態遷移モデルで)設計した場合には、必ず「ディスパッチャ」が必要となる。
• オブジェクト指向言語は多態機能を実現する機構として"仮想関数テーブル"を持ちます
• 状態遷移機械のディスパッチャをどう実装するかという「機能-実装 マッピング」選択において、それをオブジェクト指向言語の多態機能(仮想関数テーブル)に割り当てた 場合のことを、GoF本ではStateパターンと呼ぶ

と。

それ以上でもそれ以下でもない。つまり、

• 状態遷移機械をクラス構造として実装することで、状態遷移機械自体が洗練されるものではないし、
• 何らかのソフトウェア要件を状態遷移機械として実装するか、しないかの選択に、何らかの示唆を与えるものではない

と考えます。

じゃあ具体例は？

何よりも、「より適した実例を」出したかったのですが、自分自身が、お金を得る実際の仕事でStateパターンを活用して腹の底から成功した、といえる実体験をしていないので、

これが具体例だ、という例を、出せませんでした。ごめんなさい。

ただし、某、特殊船舶の仕事で、あるものを発射する、というプログラムの実装でStateパターン風の実装を行った経験はあります。

それは

• 要件として
• 「インターロックが解除されないと発射できない」もので、
• 「インターロック解除の条件はいろいろあって」
• 「インターロック解除状態以外では"発射"メッセージは必ず無視する、ということをソフトウェアソースコード上でわかりやすく実装してほしい」

があって

• 対応として
• インターロック状態とインターロック解除状態を別の状態として実装し、
• ソフトウェアのソースファイルを根本的に分離する

としたものでした。

しかし、このプログラムでは

• ディスパッチャ機構は、クラスメソッド内で独自に実装していた
• そのため、ディスパッチャを「仮想関数テーブルにはマッピングしなかった」

のです。
つまり、真の意味でGoF本のようなStateパターンにはしなかったのです。

まとめ

ということで、なんとも歯切れの悪い結論ですが、私の考えを整理した結果は先頭に書いたとおりです。

(再掲)
Stateパターンが活きるのは、少なくとも、

• 目的を実現する機構を、状態遷移機械もしくは有限オートマトンとして設計した
• メッセージ数がとても多い
• 状態によって、受信者にとって関心のあるメッセージがガラッと変わる
• 状態によらず、送信者はメッセージを出しつづけたい

の全てを満たす場合、だと考えます。

なお

実際のコーディングでは、状態が遷移するときに、「状態クラス間で内部データを引き継ぎたい」事態が、よく発生します。

卑しい例を出すと、商社において取引先A社の担当はS君で固定だったのが、内部状態の変更でT君に変更になる、という状況で、S君からT君にA社固有のノウハウを引き継ぎしたいのです。

「商社」は状態遷移マシン、「取引先A社」はメッセージの送信者、「S君」「T君」はある状態を実装するクラス、に対応します。

状態変更時、このような引継ぎ問題をどう解決するかは、GoF本のStateパターンでは何も触れていません。

追記: つまり何が言いたいかと言うと、こうです。
GoF本は、ステートパターンなどと命名して大層な事を言っている様に見えますが、実際には、継承というプログラミング言語機能を活用する中級テクニックを解説した物に過ぎません。
クラスを用いて状態を実装する事で、ソフトウェアの可読性や可管理性がどう向上するかを語っていない上に、状態遷移モデルを活用する上で度々問題となる話題に触れていません。
つまりは、真の意味で「状態遷移モデルを用いるソフトウェアの設計理論の発展に寄与した」とは言えないのです。

だから、有能なソフトウェアエンジニアの皆さん。GoF本をありがたがる事なんか辞めて、本質的なソフトウェア設計理論を高める研究をしましょう。

---

【* 日々のメモ】

インスタントコーヒーの「香味焙煎」がおいしくて、最近こればかり飲んでいます。

ですが先日買った「中煎り」は、全然おいしくない。おいしいのは「深煎り」です。パッケージが青いのが深煎り。紫なのが中煎り。

たまたま体調不良でそう感じるのかな？と思ってリトライしているがやっぱりダメだ。

香味焙煎は深煎りに限る。

---

2月ももう終わりますね…

次の案件探さないといけないし、その前に確定申告しないといけないしで、気分が重いです。ちょっと精神が逃避ぎみ。

いかんですな。がんばろう。なりたい自分になれるようにがんばろう。

【* 日々のメモ】

久しぶりにガッツリとアレルギー症状なう。
ハウスダストだろうか…

【* 日々のメモ】

なんかいろいろごちゃごちゃ。

どの店へ行っても変な客で嫌な気分になる。
この間、横浜で飲んだときは隣に座った知らないオヤジから「店をやらないか」とかしつこく話しかけられて嫌だった。

純粋においしいお酒を楽しめる、大人の飲み方ができるお店に行きたい。
馬車道かな…

【* 日々のメモ】

自己否定と自己肯定の波状攻撃について。

これ、生きてる限りずっとあるのだと思う。
経験上、一番効くのは「やらなきゃいけない事に正面から取り組む」だったと思う。

今回もそうだろう。きっとそうだ。

---

ぬあー！複式簿記めんどくせぇ！
源泉徴収されてるし、年をまたいだ売掛と回収はちゃんとやらざるを得ないし！


【* 日々のメモ】

MessagePackにString専用型を追加すべきか否かの議論に、ぜんぜんついていけてない。

シリアライズ/デシリアライズを含むデータ通信フォーマットオタクになりたかったのに、ちょっとかじったことがあるだけの奴だな、私は。

そして、JSのStringは腐っているという共通認識が神々の間でありそうな気配なのだが、どこがどう腐っているのか分かっていない。

こりゃまずい。大急ぎで勉強しないと超ヤバい。

【* 日々のメモ】

ロストした。

進むのが正しいか戻るのが正しいか、答はお釈迦様しか分からん。
少し冷静に考える必要があるが、動きながら考えないとダメだ。

下手の考え休むに似たり、かな。

---

微々たる事だが、一つやってみた。さて、次だ。

【* 日々のメモ】

確定申告書デキターーーー(◎∀◎)ーーーー!!

今日は打ち上げだ！(w

---

まぁあの、申告書を作るには期首から期末までをいろいろと振り返る必要がありまして

...


もう大丈夫かと思って
うっかり家族写真のフォルダを開けてしまった。

まだ全然大丈夫じゃなかった。orz


今日は回線切って休みます。


【* 日々のメモ】

数年ぶりで、馬車道の有名バーへ。

おいしかったです。
ラッフルズホテルのロゴ入りグラスも久しぶり。

素敵な時間を堪能しました。


ただ、花粉症の症状が辛かった。
今度は花粉のない時期にお邪魔したいです。

【* 日々のメモ】

忘れたいこと、忘れたくないこと

リンク	備考
アルツハイマー病の血管からの投与による遺伝子治療実験に成功	理化学研究所 プレスリリース

アルツハイマー病を治療する方法の一つについて、これまでは脳に対する直接の外科的手術を伴い、技術的に困難であったが、新しいやりかたでは血管からの投与でできそうだ、という話。まだマウスを使った動物実験の段階だけどね、と。

---

アルツハイマー病に苦しむ患者さん、介護する家族の方には、希望の光となるのではないでしょうか。研究が着実に進み、その成果がたくさんの人の幸せにつながるといいです。

---

不謹慎かもしれないけど、ここからヨタ話。

忘れたい記憶を忘れられなくはなってしまう、ということはないのだろうか。


高度に職能を磨いた飲食業の方って、オーダーの内容(メニュー品、数、テーブル)を瞬時に覚えるじゃないですか。
あるバーテンダーさんが、猛烈に混んだ状態でオーダーを的確に覚えて処理していた。私はそれを見て非常に関心して、後日すごいですね、と話したら、あることをそっと教えてくれました。いわく、「仕事ですから覚えます。覚えるのはバーの仕事の中では容易な方。それより難しいのが、すでに完了したオーダーを、忘れていく事。間違えてまた作ってしまいそうになる」との事。

ふへー、すごいレベルで仕事をしてるんだなぁと思いました。また、私にはとても無理だ...とも思いました。

で：
その話に関連して。


辛い記憶を忘れることも、人間が生きていく上で重要な機能であると思うのですよ。

本日、BSの無料放送でやっていた「エターナル・サンシャイン」という映画を見ました。主演はジムキャリー。日常系SF映画。

主人公は恋人と別れたつらい記憶を忘れようと、「記憶を消してくれる医者」に消去作業を依頼する。その晩に行われた消去作業中、恋人との楽しかった想い出まで消されることに気づいて思い直した彼は、無意識状態の中で必死に抵抗する。彼の願い虚しく、次々に記憶は消されていく。翌朝になり、彼が見たものは…

という話。

リンク	備考
wikipedia:エターナル・サンシャイン

私にも、いつまでも鮮明に覚えていたら、とても辛くなるような記憶があります。人間は忘れるからこそ生きられるという面もあるように思います。苦労して学んだ事などをいつまでも覚えていたい気持ちと、つらい想い出などを忘れてしまいたい気持ち、両方あります。覚えていたいことは覚えていたいし、忘れたいことは忘れたい。でも、なかなかそうは行かない。

記憶を自在にコントロールできたらいいのに、と思う半面、自在にコントロールできないのもまた人生か、とも思います。すべての生命は、記憶を持たない状態で生まれ、たくさんの他の生命を食べることで生き、やがて自分も大量の記憶を捨てて死ぬ。

つらい記憶で胃の縮むような苦しみを味わったり、美化した記憶や妄想をもて遊んでみたり、それもまた生きる本質なのか、どうでしょうか。


【* 日々のメモ】

数字に対する「カン」ができること

ひとりごと。

16進数のビットパターンをさんざんいじくり倒していると、数字を見た瞬間にパターンが頭に浮かぶようになる。
また、図形的に左右を反転するのが数字でいくつか、が、思い浮かぶようになる。

たとえば、1 の 反対は 8、3 の反対は c, 6 の裏は 9。

1: ___1
8: 1___

3: __11
c: 11__

6: _11_
9: 1__1

あと、メモリモジュールのテストで、ゼロイチを繰り返すパターンを書き込んでから、読み込んで「本当にその値になるよね」って確認する、なんていうプログラムに、たまに出会ったりする。そういうときは、5 か a が出てくる。

5: _1_1
a: 1_1_

てな具合で、小学生のときに8ビットパターンでドット打ってた私は、ビットパターンが頭に染み付いています。


で

音楽の音程の数字も、扱っていると少しずつ頭に浮かぶようになってきます。2音の音程の、オクターブを反対にすると何度か、ていう数字の早覚え法があるということを最近覚えました。例えば 長3度 のオクターブ逆転は 短6度 とか。

法則性があって、ある度数のオクターブ逆転は

• 1と8、2と7、3と6、4と5 を交換
• 増と減、長と短、を交換。完全は完全

で出せる。

長3度 の反対は-> 長に対して短、3に対して6、で短6度。


人間の脳には、訓練するとショートカットできるようになる、というおもしろい機能があるなぁ、という、独り言のような話なのでした。

【* 日々のメモ】

学生のころ、何気なく聞いていたFMラジオでDJさんがこんなことを言っていた。
曰く、好きな言葉があって、その一つが "Burn the bridge behind you" だとか。退路を断って前進せよ、てことだと思う。

その言葉がずっとアタマに引っかかっていた。だけど、今自信をもって否定したい。

背後の橋を焼く必要なんて、ない。そんなもの、自分の弱さを他人に迷惑をかけてカバーしてるだけだ。
過去を切り捨てた今になど意味はない。今そこにある今は、それ(or私orあなた)が背負っている過去との連続に意味があって、それ以外にはない。のだと思う。

背後の橋を燃やす必要なんて、どこにもない。そう思う。

【* 日々のメモ】

今期も、すでに第一クォーター終わりましたね。引き続き頑張っていきましょう。

【* 日々のメモ】

空手部の先輩が突然亡くなり、昨日お通夜に伺いました。

仲間をとても大事にされる先輩でした。
2年ほど前の忘年会でお会いしたのが最後でした。その時も仕事の愚痴を聞いてくれて、親身になってアドバイスをしてくださった。

先輩とやりとりしたメールがフォルダに残っています。蒸し返して返信したら、また何か返してくださるような気がします。

何もお返しできませんでしたが、いただいたご親切に感謝しております。
どうもありがとうございました。


【* 日々のメモ】

リンク	備考
http://synodos.jp/politics/3894	橋下徹大阪市長「米軍の風俗業活用を」はいかなる文脈で発言されたのか（2013年5月13日）大阪市長・橋下徹氏ぶらさがり取材全文文字起こし - SYNODOS

荻上チキ氏の意見には賛成しかねることも多いのだけど、この記事は素晴らしいと思う。

これを読む限り、私は結婚して子供作って離婚も経験したオッサンとして（=セックス経験のない子供ではなく、という意味で）、橋下氏はなんら間違ったことを言っていないと思う。何が問題になっているんだろう。

あと、的外れかもしれないけど、主題よりも気になったこと。「取材してる記者さんの 語尾までちゃんと言わない 訊き方は、よろしくない」という感想を持ったよ。

電話でもときどきやっちゃうよね。「○○の件でお電話したのですが」で言葉を止めてしまうこと。あれ良くない。「○○の件でお電話したのですが、お分かりになる方をお願いできますか？」までちゃんと言おう。と思う。

人の振り見て我振り直せだな。

【* 日々のメモ】

うう…お腹痛い…
なんだこれ

【* 日々のメモ】

お腹は無事治りました。

今朝方、ものすごく嫌な痛い夢を見ました。
忘れたいので内容書きません…

体内から悪いものが出ていくときにこういう事があるのかもしれない、などと思った。

【* 日々のメモ】

ファーストガンダム、「ガルマ散る」

40のオッサンになった今見ると、また違う視点で見てしまう。
シャアの、親を殺された恨み。
デギンザビの、子を失った悲しみ。
イセリナの、想いを寄せる者を失った悲しみ。
結局ガンダムって戦争を拙い物語で描いて、子供にオモチャ売るだけの話じゃん。とか。まぁ好きなんだけど。

あと、今になって分かること。イセリナのお父さんの「子供の結婚相手の家族と幸せな関係を持つ権利」について。
人間は誰でも、「親」をやるのもまた人生での最初の経験で、「娘・息子の夫婦といい関係を築いて、じいちゃんとして孫と接する」のは、人生で１回なのよね。だから、すべての親は、「自分の幸せを求める権利」の行使の一環として、娘・息子が誰と結婚するかについて、口をはさむ権利がある。と気づいたよ、オッサンになって。

そのあたりは、物語では全然描かれていないけどね。

てかさ、当時は富野監督もまだ若くて、むしろガキだっただろうから、分からなかい事もあっただろうなぁ、と思う。分かってたかも知れないけど。

うーむ。

---

しかし幾つになっても孤独はこたえるもんだねぇ。未だに何が幸せなのか、何のために生きてるのか、よくわからんよ。

少し前にCMで、30前後のキャラクターが誰かに「その年で自分探しかよ」ってのがあった。まぁそう言いたい気分なのも（その年頃を経験した者として）分かるが、「雇われてる人間だろうに、お前の年で一人前になった気分なのは、まだ幻だ」と言いたいわ。本当の一人前ってのは、起業してそれを軌道に乗せられたひとの事だと、今は思う。30代で会社員として一通りの仕事ができると、分かったような気分になるんだよね。誰でも。あと、軌道に乗らないんだよなぁ。

そんであのCM、流れなくなったよね。不評だったんだろう。

歌の詞で「幸せとは getting what you want ではなくて、wanting what you getだ、と誰かが言う」てのがあった。最近この言葉がなんども去来する。何かを欲しいと思うその事自体が幸せなのだと。そうおっしゃる。

人生半分過ぎて未だに、どこへ向かえばいいのかすら見つからない。

【* 日々のメモ】

自分から動いて、教えてくださいとお願いすると、よほどの事がなければ何かを教えていただける。何かを学べる。

自分の内側にこもって作り上げる作業も大事だけど、外へ行くことも大事だね。

とっても勉強になりました。

【* 日々のメモ】

プラスにせよマイナスにせよ、自分を評価する言葉を頂くと、褒め殺しとか、皮肉が混じっているように感じてしまうのは、自分の性格がひねくれているからだろうか。もしくは、自分の実体が「それほど大したものじゃない」事を自分は知っているから、だから身の置き場がなくなるのだろうか。


私は、自分のWebサイトに対して、誰かからお金をもらって書いてる訳じゃない。ただ、今は、ソフトウェアの商売をやってるから、その宣伝をしたい、という意図は、確実にある。自分自身の広告媒体だと思って書いている。だから、音楽関係の知人に配慮して「ソフトウェアの事を書かない」だの、「別にする」、なんてのは本末転倒だ。残念ながら、音楽関係の知人には、ソフトウェア関係のお客様ほど、私にお金を払っては頂けていない。お金でない幸せを含めると微妙だが、事実は事実。

コンピュータの知識も、音楽の知識も、それらに対する、アスペルガー症候群的な奇妙で微細なこだわり/好き嫌いも、みんな自分の一部です。これが私です。専門知識をひけらかして自慢する意図があるわけでも、実物以上に自分を大きく見せたいわけでも、ありません。大体、ソフトウェアの世界で自分がどれだけちっぽけな存在か、痛いほど知っている。

この、自分の中にある訳の分からない怪物をどうにか制御して、何とか社会でお金を頂いて生きて行きたいのであって。自分のWebサイトで自分の考えをどう書こうが、それが他人を傷つけるものでない限りは、他人から否定されても、へこむべきじゃないと思う。自分は自分だと胸を張って生きたい。他の誰かが、その人自身の有りようを思って勝手にへこむのは、自分にはどうしようもない。自分だってそりゃ同じで、自分が勝手にへこむのは他人のせいじゃない。

だけど、何だか分からないプレッシャーに負けてつぶされそうだ。生きることは、この潰されそうなプレッシャーに耐えて前に進もうとすること、かもしれない。

【* 日々のメモ】

かけるだけの高菜パスタのソースと、きしめんうどんがありました。
↓
きしめんを茹でて高菜ソースをかけて食事開始
↓
普通のうどんのように食べていたら、鷹の爪が喉に張り付いてむせた
↓
鼻の奥に、高菜らしき何かが入って鼻痛い
↓
鼻をかんだけど出てこないので、そのまま食事して終了
↓
食事を終えくつろいでいたが、やっぱりなんか鼻が痛いので、水道水を鼻から流し込んで洗浄
↓
改めて鼻をかんだら、「鷹の爪の輪切り」（幅1mm）が出てきてびっくり <- 今ここ

画像を取ってWebに上げようかと思ったけど、あんまりなので止めます。
パスタのソースでうどんを食べるときは、気をつけましょう。



【* 日々のメモ】

ARM Androidのネイティブモジュール開発を経験して、感動しています。

モバイル機器(ARM CPU)上で動くネイティブモジュールを、こんなに簡単にクロスコンパイルできて、こんなに簡単にデバッグできるって、すごい事ですよね。

すごいなぁ。

本当にすごい。感動です。

道を拓いてくれた、たくさんの優秀なエンジニアの方々と、赤字を顧みずAndroidビジネスを継続してくれたGoogle社に感謝の気持ちでいっぱいです。
願わくば自分も誰かの役に立てますように。

【* 日々のメモ】

うわーんまたやっちまった…

画像ネタ探してて過去の写真フォルダ開いてしまったよ…


前向いて行こう。もう本当に。

【* 日々のメモ】

今日はめでたく工程終了だ！パーッと行くぞ！

と思ったのですが、なんでも連絡があり家族が開胸手術するとかしないとか…

という事で、本日はお家で静かにしてます。
人生いろいろあります。

【* 日々のメモ】

コンピュータ関係のページを追加しました。
→【+ PhoneGapって何だ】

【* 日々のメモ】

痛い。
カミソリに負けてるような感じ。なんかヒリヒリする。

刃がなまってるから痛いのか、刃の当て方が悪いのか。
そもそも何を剃ってるんだろうか、自分は。

探し方が悪いのか、探す物の設定の仕方が悪いのか。

うーむ。

【* 日々のメモ】

「鼻をかんだときに出てきたことがあるもの」に、そば（11cm）を追加しました。

• しめじ
• 唐揚げ
• 鷹の爪輪切り
• そば11cm <- 今ここ

【* 日々のメモ】

唐突ですが。

私1972年生まれです。

わがまま言ってスミマセンが、私は「若く見えますね」と言われるのが、本当に真面目にイヤなので、もし覚えていてくださったら、やめてください。よろしくお願いします。m(_ _)m

【* 日々のメモ】

なんだか良くわからないですが、性格が攻撃的になって周りにご迷惑をお掛けしている気がします。

躁鬱気質について教えてくれた友人が、躁鬱で本当に困るのは鬱(うつ)ではなく躁(そう)の方だ、と言っていました。

もしかしたら自分、今なにかのスイッチが入ってしまって躁(そう)になっているかもです。ごめんなさい。気をつけます。

あと、ゆっくりを心がけます。

リンク	備考
プログラマの心の健康	結城さんのページ

【* 日々のメモ】

ふとしたきっかけで、自分のサイトを"Java"で検索したら、なんかたくさんでてきました。

そんな話をまとめてみました。

+ Javaの弱い参照について

【* 日々のメモ】

録画していた映画「パーマネント野ばら」を視聴。

幼い娘を連れて離婚した女性が、母親の美容院を手伝いながら、漁師町で暮らしています。
その美容院は近所のおばちゃんの溜まり場になっていて、いつも悲喜こもごもの
ガールズトークが繰り広げられます。
いくつになっても恋をする心は変わらず。
主人公も、その二人の幼馴染の女性も男にまつわる苦労があって…

という感じの話。


原作は西原理恵子さんだそうで。良かったです。
サイバラさん本人が経験した人生の悲哀を通してこの作品が生み出されたような気がしてなりません。

徹底した女性視点で、男がみんなダメ男に描かれています。男性諸氏は視聴注意です。
「そう見られているのだろうな」という気持ちと、
「でも見栄はって格好つけるときもあるんだよ」と弁解したい気持ちで、
心がとても痛くなります。

菅野美穂さん、池脇千鶴さん、小池栄子さんがみんないい味を出しています。
3人それぞれ、映画の中で最後に登場するシーンがみんな素晴らしかった。

そしてラストがとても切なかった。

「大丈夫、いいことあるよ」と西原さんに語りかけられたような気がする、
そんな不思議な映画でした。


機会があったら見てみてください！

【* 日々のメモ】

進撃の巨人でですねぇ、すごく納得いかんのですよ。


仲間が殉職したとして、それを家族に伝えるとき、遺体を持ち帰れないとしてもだよ、
戦友が「あいつは勇敢に戦いましたが死にました」て言うのと、
「行方不明です」て言うのは、

全然違いますから！

行方不明ってのは、遺族からしたら生きてるかもしれないってこと。
亡くなったことが確実なら、遺族はどんなふうに亡くなったかを戦友に語ってもらったほうがいいよ。諦めがつく。

生死不明で諦めがつかない状況のほうが地獄だよ


死んだことが明らかなのに、隊長が「行方不明で処理しろ」って、この作者どんだけバカなの？

まぁ、架空の物語だからね。
そんなに熱くなることでもないんだけど。
多分この作者は友人が死んだ経験がないんだよ。

【* 日々のメモ】

ウィスキーをオレンジジュースでわってちょっとレモン入れると美味しい！

ていうかこれ飲めすぎて危険！

うわーい

【* 日々のメモ】

ある現場で、いまだにムーアの法則を盾にする人がいました。気になって、考えを整理しました。

ムーアの法則を盾にする人たち登場時代

昔(1990年代ごろ)、ムーアの法則を盾に、必要な設計をサボる人たちがいた。

曰く、「コンピュータはどんどん速くなる。なので、メモリの解放など気にせず、スレッドをたくさんつくり、人間がプログラミングする工数を削減するほうがビジネスで勝てる」と。

これ、この説が出た当初から、コンピュータの性能を出し切るような世界で働いているひとたち(ゲームとか組み込みとかの人たち)は「バカなこと言ってんじゃねーよ」という態度で冷静に眺めていました。

ムーアの法則を盾にしたらダメ時代

2000年代ごろ、やっぱあれダメじゃね？という認識が広がりました。

• CPUのベース周波数競争、コア数競争が進んだが、発熱が多く電気を食いファンがうるさいと気づく
• C10K問題が顕在化
• CAP定理が認識された
• スケールアップ型の限界が見え、スケールアウト型が増えた

ソフトウェアの作りの違いで鮮やかに解決する人たちが登場し、逆に「ムーアの法則を盾にするひとたち」が駆逐されて行く。

Android と Java

Javaは、いわゆる「ムーアの法則を盾にする」思想で設計されたプログラミング言語です。

Androidは Java の開発環境を用いていますが、厳しいリソース環境に対応するため、

• 独自のVMを作ったり
• シングルスレッドのイベント処理APIを豊富に作ったり

して、古い Java の思想と決別しています。

マルチコアの活かし方

マルチスレッドやマルチコアを活かすにも良いやり方とヘタなやりかたがあります。

• 「同じ作業をするワーカーがたくさん」型は失敗する
• 「パイプライン」型の処理はうまくいく

仕事をどう分割して、ワーカーをどう配置するか、それはある意味で経営者としての采配に近いです。
ワーカー同士が競合すると、仕事がうまく進まない。
個々のワーカーが、十分な裁量を持って、独自に作業をすすめるとうまくいく。
ワーカー同士が競合するのは、経営者のタスク分割設計が拙いから。

ソフトウェア設計者は、「仮想のワーカー」をいくらでも作ることができ、いつでも雇い入れ、いつでも解雇することができます。上手に経営しましょう。

---

私の意見

ムーアの法則を盾にする思想を否定する論

• コンピュータ システムのビジネスは、常に「今までできなかったことが できるようになった」ことを飯のタネにしている。
• 例：弾道計算、画像解析→動画解析、SNS等の多ノード計算、…
• 同じコスト・同じコンピュータで、高性能のソフトウェアを開発する人が、常に登場する。
• 自分のアタマを使い、いま使える物といまのニーズをうまく結びつけた人が、ビジネスでは常に勝つ。

その意味で、ソフト屋は、程度の違いこそあれ、エッジに立たなければならない宿命にあります。そのための苦労は、必要な苦労です。

優秀なプログラマが集まらないから仕方がない？
いいえ。それはあなたの「いま使える物」(リソース)の条件の一つです。
それをどう上手く使ってニーズと結びつけるかを設計するのが、あなたの、私たちの、仕事です。

私はこう考えています。

ムーアの法則を盾にする思想は、

• 必要な仕事をサボるための言い訳
• 負け犬根性

である

ソフトウェア設計者の皆さん、ムーアの法則を盾にするのは、やめましょう。


【* 日々のメモ】

ソフトウェアプログラミングにしろ、ギターにしろ、同じくらいのレベルでオタク会話できる友達が欲しいです。
みんなどうやって見つけるんだろう。
カンファレンスとか勉強会とか行けばいいのかなぁ。

僕は28で破れかぶれ独立してしまったので、以来「同僚」がいません。
客の愚痴を誰かにこぼしたくて、夜中に独り言が止まらなくなった事があります。
そしたら当時の嫁さんが気味悪がって子供連れて離婚してしまった。

よく考えてミドルウェアやフレームワークを作ってお客さんに納めても、誰も理解してくれず打ち捨てられていく。
一度だけ、ルータ改造系の案件の現場を去った後、たまたま会ったある人から「車さんがやりたかった事が分かった」と言われた。

でもまぁそんな物だろうね。

結局、メンテする人が何年生くらいかを想定して、そのレベルに合わせてコーディングしないと、サービスにならず自己満足になっちゃう。

自分の作りたい物を作るには、企画書を書いてスポンサーを探して説得しないとね。頑張ろう。頑張ろう…


【* 日々のメモ】

自分用メモ。
http://rocketnews24.com/2013/08/30/362069/
脳内のイメージをコンピュータ上で再現するという話。

私が考える「ムーアの法則を期待していい人」は、例えばこういう多量のボクセル計算をする人。

私を含む、チンケな業務システム屋なんかは、ムーアの法則を言い訳にしたらアカン。

【* 日々のメモ】

幸せの定義 2013.9

周囲の人から「価値のある人物」と評価される事。

価値のある人物とは、価値のあるモノ、コトを提供できる人物。

価値のあるモノ、コトとは、
仕事ならモノ=設計書やプログラム、コト=打合せでの態度や発言、不愉快にさせない振る舞い。
音楽趣味では、モノ=曲、詞等作品内容、実演。コト=態度や発言、以下同じ。

評価するのは、所属するコミュニティのメンバ。


私が、私を、価値のある人物にするのだ、という意思を持つ事、大事。



逆に考えると
私が、他人を、幸せにするには、その人物がコミュニティの中で「価値ある人物だ」と評価される状態にすればいい。

更には、価値ある人物でないと評価される状態にする事は、その人物を不幸にする事。自分がされて嫌な事は、他人にしないのがいい。




お金が往き来する関係の場合、注意が必要。

大人の人間関係は、お金が往き来する(商売上の)関係が割合多い。

客の立場から:
客は客(神様)でなく、でも客は客(部外者)。
店にとって、また来て欲しい客になれているか。
他の客に迷惑をかけるのは嫌われる。
常連には常連の役割がある。
店が提示している金額は、大体、本来ほしい額より安い。
コミュニティで価値ある人物と評価される=幸せでありたいのは自分なのだから、その目的に忠実に考えれば良い。

店の立場から:
下請けから脱却、の前に、ちゃんと下請けできているか？
客は、自分より計算機科学を知らなくて当たり前。
だけど、俺は客だ、という顔をしたがるのはしょうがない。
金をもらっているのは事実。
事実だけど、本来ほしい額より安いのも事実。
その金額上で「価値ある人物」を演出できているかを確認して、堂々とするしかない。



幸せとは、周囲の人から「価値のある人物」と評価される事。


【* 日々のメモ】

この10年、趣味にしろ、仕事につながることにしろ、すぐに仕事にはつながらなそうなことにしろ、勉強することをサボりすぎたように思います。反省。

振り返ると、僕の「身になった」一番の勉強は「写経」方式だったかもしれません。

プログラミングも、作詞や作曲も。

プログラミングについては僕らの世代は「ベーマガ」が、そりゃもう寺子屋式の先生だった。トップビューも、サイドビューも、一定速度移動やら、加速度移動、ジャンプ動作、アタリ判定、マップのデータ持ち、そしてドット絵のドット打ちもずいぶんやったなぁ。

仕事に就いてからは、オブジェクト指向の 理想に対する「現実」を、ずいぶん考えながら書いた。読んで、書いて、書いて、考えて、…。

作詞については、学生のときずいぶん手で写経しまくりました。あるときそのコピーで部屋中の壁を満たしたので、部屋がまるで耳なし芳一のようになってた。

手でコピーして、コピーすることによって作る作業を模擬体験して、手で感覚を覚えたこと、そしてその意味を座学で考えたこと、それが今の自分の体を構成しているように思う。言ってみれば、それ以外の「お勉強」は、ほとんど身になって残ってない。

もっと写経しよう。そんで、それを考えよう。と、ふと思ったことでした。


あー、そういや情報処理の一種（ソフ開）取ってからもう10年経ってる。
次のところへ行かないと、なぁ。

---

そうだ、ただし、家族を持つこととは何か、についてはこの10年で随分学んだな。
うむ。何も学んでなかったわけじゃない。

最初から何でも上手くできるわけじゃない。
失敗しても、そこから反省して「またチャンスがあるならもっと上手くやろう」と思えばいいよね。

【* 日々のメモ】

アレルギー症状がひどいです…

秋の花粉時期の予兆を感じたので、3週間前から第二世代のアレルギー薬の服用を始めています。なのにひどい。


お酒飲み過ぎか、
夜遊び過ぎ（寝不足）か、
食べたものが良くなかったか、
掃除してないからダニ吸い過ぎか、
アコギ弦弾いたのが悪かったか、
花粉か、

多分全部なんだろうけど、
痒いし、イライラするし、だるいし、
そして全身各所の皮膚がひどいことになっています。
多分、いまラッキー(w)なことがあっても、服を脱げませぬ。


「これが悪い」っていう悪役が一匹いるわけじゃなくて、複合なのよね。

一個ずつ注意して少しずつ生活を改善していくしかないのです。わかっちゃいるけどめんどくさい。


【* 日々のメモ】

誰にも言えないことは
どうすりゃいいの？

【* 日々のメモ】

昨日、行きつけの皮膚科に行ったら悪化してるとの診断で点滴打たれました。眠くなる薬だったようで、かなり酔っ払いました。

写真は、待合室で久しぶりに見かけた本。

大きな卵を見つけたので、それでカステラを作って食べる、という話。
そういやこんな内容だったなー、結構厳しい内容だ（生存競争的な意味で）、と思い出しましたよ。



これを元にしたネタ画像でネットに出回ってるこんなのあります。
見たとき声出して笑いました。



【* 日々のメモ】

Fedoraを17から18、19とアップグレード。18はgdmが起動しなくて焦ったが、どうやら既知の問題だったようなので、思い切って19に上げてみたら治ってた。

よかった、よかった。

【* 日々のメモ】

日本語コーディング、日本語の識別子をプログラミングで用いるという話で、
「日本語コーディング」でググるとトップにこのページが出るのだけど、
「日本語プログラミング」では箸にも棒にもかからない。

うーむ。


この話題でよいスライドがありましたのでメモします。

リンク	備考
日本語識別子の必要性	slideshare

【* 日々のメモ】

うーん…収まったと思って薬を止めるとまた全身に赤い湿疹が…

なんでもこれ、全身性エリテマトーデスとか言うらしいです。

痒い。そしてイライラする。

【* 日々のメモ】

設計書・ドキュメントは、書きすぎても問題になるし、書かなすぎても問題になる。

ソースと同じ内容のフローチャートを書くのはさすがにやり過ぎ。二重管理になって食い違いが出て、結局ソースを見ることになるので意味がない。一方で、どうせソースしか残らないからとドキュメントを一切書かないというのはそれもやり過ぎ。
例えば、犬小屋を作るのに壮大・長大な、時代背景の分析から始まる設計書を書く必要はない。一方で、地図に残るような、巨大な橋、例えば横浜ベイブリッジを作るのに設計書が一切ないなんて、ありえない。どこの未開国だって話になる。
ソフトウェアを作る案件にもいろんな案件があるけど、複数のメンバーで対処する案件は、犬小屋よりは大きくて、横浜ベイブリッジよりは小さい。その時、どんなドキュメントを書くのが良いかは、違う。

要は、人間同士のコミュニケーションのために必要なドキュメントは何か、ということを、その案件ごとに自分の頭を使って考える必要があって、適切なレベルの設計書を書いて打ち合わせをするのが、正解なのだろう。
そんなことは当たり前、と思うのだが…人間は悲しいもので、どういうわけか、思考停止してしまう事があるのだ。
原因はなんだろう。酷い経験をすると、それがトラウマになって反対側の振り子に振れてしまうのかな。悲しいけど。

「自分の頭を使って考える」という作業は、実は結構面倒臭い。

プロジェクトが走り始めたら、お定まりの手順で進めたい、と思ってしまうのは、ごく当たり前の事だと思う。
でも、仕事って頭使うものだよね。
悩んで考えて、アイデアひねって。

先日「ガイアの夜明け」で、女性技術者/女性活用の回があった。その回の本題は、建築現場等、男性ばかりと考えられる仕事場で女性が活躍している、という話だったのだけど、男か女か、という事とは別のレベルで、現場の監督（＝女性の方）が頭を使って問題を解決している、という話が取り上げられていて、すごく関心した。

ある作業で、2140mmだったかな、特定の深さの穴をいくつも掘る必要があって、毎回メジャーで測って面倒そうだった。そこで、専用の道具を作り、作業を効率化した。道具というのは、木材を2本組み合わせてT字型にしただけ。ただしその「特定の長さ」なので、毎回メジャーで測る必要がなくなる。

また別の作業で、掘った穴に脱落しないように柵を立てておく必要があり、足場に使うパイプを使って、穴のまわりに四角形に柵を立てていた。

+ー+  +ー+  +ー+ 
|○|  |○|  |○|
+ー+  +ー+  +ー+ 

ところが、柵と柵の間隔が狭いので、間を通るときに作業着が引っかかる。そこで

 /\   ____   /\
/○\  \○/  /○\
----   \/  -----

柵を組み替えて三角にした。こうすることで柵と柵の間隔が広くなって、通りやすくなり、作業効率が上がった。

と。

監督はこういうことに、手間とか頭とか使わないとね、という話。作業員と一緒に切ったり貼ったりするだけが、仕事じゃない、と。

自分の仕事をかえりみて、すごく反省したことでした。
頭使って働こう。

【* 日々のメモ】

問題：
Fedora19で、Gnome3でCapsLockキーをCtrlにする設定で使用しており、サスペンドからレジュームすると、CapsLockキーがCapsLockに戻ってしまう。

暫定対処：
ログアウトしてログインし直すと設定が直る。


成果物をダータで利用させてもらっておいてアレだが、しょーもないバグ作りこんだね…。

---

追記：2014-04-28
GNOMEの設定ではなくxorg.confの設定で実現すると、この問題を回避できます。

/etc/X11/xorg.conf.d/00-keyboard.conf

# Read and parsed by systemd-localed. It's probably wise not to edit this file
# manually too freely.
Section "InputClass"
        Identifier "system-keyboard"
        MatchIsKeyboard "on"
        Option "XkbLayout" "jp"
        Option "XkbOptions" "ctrl:nocaps"
EndSection

【* 日々のメモ】

樋口有介さんの「彼女はたぶん魔法を使う」を三読中。



刑事あがりのキザなオッサン私立探偵が主人公の青春風味ミステリーなんですけど、この作品好きなんですよ…出てくる女性が、若い方からそれなりの年齢の方まで、美女ばーっかり。謎解きの部分はまぁアレなんですけど、会話の軽妙さがいいんです！よ。特に、ラストシーンなんか俺、大好き過ぎて、かなりのページなんですけど写経して勉強しましたもの。

初めて読んだのは多分、20代前半の時。今や、主人公の柚木草平38歳の年齢を超えてオイラ41ですよ…`,､('∀`) '`,､

柚木草平みたいに格好いい生き方できてないなぁ。


作品の中で、彼女である冴子さんがドライマティーニを、主人公がバーボンのロックを飲む、という描写があります。

作品の中では「バーボンのオン・ザ・ロック」という表記になっていて、うーむ、樋口さん、酒に関してはあんまり詳しくなかったのだなぁとニヤけてしまいましたが(笑)(バーボンロックなら、どのバーボンかを明示して○○ロックと表現するのが普通です。ETとかハーパーとかフォーローゼズとかメイカーズとか)

まぁあれです。ドライマティーニを注文するような女性と一緒にお酒を飲んでみたいもんです。わはは。

マティーニっていうのは、ベルモットという、白ワインに香りづけをしたお酒と、ジンを合わせて、オリーブを添えて作る、割合にアルコール度数の強い部類のカクテルです。そして、ベルモットとジンのちょっとした割合の違いでカクテルの名前が変わってしまうような、繊細なお酒です。このお酒を注文するような女性は相当な酒好き、相当な夜遊び好きなはず。

そんな女性とデートしてお酒を飲んでみたいなぁ。と。


月末でお金がなくて、コンビニで買った焼酎のソーダ割りでいい気分になっている、ソフトウェアエンジニア41歳の、ほんの戯言でした。



【* 日々のメモ】

私は「特定秘密保護法案に反対している人に、疑問を投げかけたい考え」を持っています。

私は過去に防衛関係のソフトウェア開発に少しだけ関わらせて頂いたことがあり、自衛官の皆さん、関連企業の皆さんは、秘密情報の扱い(秘密指定、閲覧、etc)を真面目にされていたという感覚を持っています。「真面目に」というのは、余分なことは秘密指定しない、という意味も含みます。大変なんですよ。


「特定秘密保護法案 問題」でググると最初に出てくる、特定秘密保護法案に反対する日弁連さんのページについて。

http://www.nichibenren.or.jp/activity/human/secret/problem.html

リンク先読んでみましたけど...なんだか、すごく筋違いな感じがします。

リンク先の1番目、プライバシー侵害と書いてますが、ズバリ言ってこれは「ハニートラップ防止」だと思っています。防衛秘密、しかも特定防衛秘密（秘密レベルが高い）に触れる人物に、特定外国の異性スパイが近づくことの危険性は計り知れないです（男性の方はすごく知的美人の、女性の方はすごくイケメン紳士の、スパイもしくはテロリストを想像してください）。ハニートラップ防止のためには、プライバシーに踏み込むことが当然に必要です。

リンク先の2番目、例に出しているものは全て、テロリストや特定外国のスパイに知られたら国民の生命や財産が脅かされる情報ですね。国民に広く公開したら、国民のふりをしているテロリストやスパイにも知られてしまいます。業務上知ることが必要な人物に適切に公開すれば、よいはずです。

リンク先の最後、「いま、日本で必要なことは、国民を重要な情報から遠ざけ、疎外する秘密保護法をつくることではなく、情報の公表・公開を進めること、情報管理を適正化するシステムを作ることあると、日弁連は考えます。」（「作ることあると」は原文ママ） 一見もっともな意見だと思いますけど、どういう論理（＝妥当な仮定に基づく妥当な推論）でこの結論に結びつくのか、私にはわかりませんでした。話の前提が共有できていないと思うのです。


うーむ。
防衛案件でなくても、昨今、ソフトウェア開発に関わる情報などは、そのほとんどが「プロジェクト外秘」指定されていて、なんでもかんでも企業秘密になっています。その現状と比較しても、2013年現在の社会常識と著しく異なるとは思わないのです。

「恣意的な運用をしたら」と言うなら、破壊活動防止法など、恣意的な運用ができてしまう法律はたくさんあると思います。それらの法をきちんと運用するだけの知恵がない人物は、運用する立場に立つべきではないでしょう。しかし闇雲に「運用者にその知恵がない」と断言するのは、少々見くびり過ぎ、失礼な気がします。

現状、日本にはスパイ行為を取り締まる法がない、と私は考えています。（一時的な拘束、事情聴取、裁判、...）


どうでしょうか。



【* 日々のメモ】

録画していた「八日目の蝉」を見た。良い作品でした。

内容については割愛。

---

以下、映画の内容ではなく、現実の自分の話。
いつか、ありがとうと、ごめんねを言える。言えるはず。そう思った。

結婚する前、世界を斜めに見ていた。一人で見ていた。

結婚して、子供を授かって、生活した。
愛をもらった。たくさん、たくさん、もらった。
幸せをもらった。たくさんもらった。

今、身の回りにたくさんモノがある。すごくたくさんある。けど、生きていくのに本当に必要なものは、こんなにたくさんのものじゃない様な気がした。

ちゃんと反省しよう。ちゃんと反省して、そうしたら、次の場所へ進もう。
シカオちゃんの曲を思い出すよ。

谷川俊太郎氏の詩も思い出した。
悲しみの理由は、いつもいつも愛だった、ってやつ。

愛だったねえ。たくさんもらったねえ。


無くしてから気づくのが、愚かだねえ。


【* 日々のメモ】

うーむ。とても悩んだのですが、.ru からのリファラスパムがあまりに酷いので、リモートホスト .ru 全部ブロックさせて頂きます。本当にありがとうございました。

【* 日々のメモ】