UK STUDIO

先日、ちょっとした思いつきでTwitter上で好きなデザインパターンと嫌いなデザインパターンを募集してみたのでその結果をまとめる。 一応、今回答えてくれた人達のTwitterアカウントが全員Publicだったので各発言にリンクを貼っておいた。問題がある人はTwitterかなにかで一言連絡を。

好きなパターン

Stateパターン 2票

stateパターンでしょうか。switch文がなくなりますです。 引用元:@naokirin244

呼び出し側の条件分岐がなくなってすっきりするから。 引用元: @mollifier

TemplateMethodパターン 2票

テンプレートパターンですね。ざっと動作を抽象化して、場合によってはストラテジーパターンあたりと組み合わせて抽象性あげると最高です。 引用元:@takayuki_h

好きなのはTemplateMethod 引用元: @匿名

Builderパターン 1票

私が1番好きなパターンはBuilderパターンです。流れるようなインタフェースが書けるし意図をコードに残しやすくもなるので、ライブラリ実装時に使いたくなります。 引用元:@eller86

Commandパターン 2票

でも1番感動したのはCommandでアンドゥ・リドゥが簡単に実装できたときかも。 引用元:@eller86

キメると気持ちいい。 引用元: @t_wada

Strartegyパターン 2票

好きなパターン “Strategy” 。継承より委譲を学べた (だったと思う)。
引用元:@koic

OOPの持つインタフェースと実装の分離が分かりやすいため。 引用元: @a_hisame

Compositeパターン 1票

好きというか、OO言語でこのパターンを使わずして、構造化されたデータを表現するのは困難でしょう。 引用元: @kmizu

嫌いなパターン

Singletonパターン 3票

嫌いなパターンは “Singleton” 。マルチスレッドプログラミングのロック問題や、同一 JVM 内でのみ sole instance など、厄介な問題を抱えているので。 引用元:@koic

コードの結合度を無駄に高めるし、本当に唯一の情報にしたいときにはプロセス内での唯一性程度では足りない (本当に唯一にしたいときは、プロセス間とかネットワーク上で唯一じゃないとダメなケースが多い) ため。 引用元： @t_wada

ただのグローバル変数化されてしまって死にそうになった。 引用元: @匿名

Interpreterパターン 1票

実際にこのパターンで言語処理系を作るのはメンテナンス性が悪過ぎる 引用元: @kmizu

正直、もう少し回答の数が欲しかったところだけど集まらなかったのだから仕方がない。とりあえず引き続き回答を募集するので、Twitter上やこのブログのコメントやトラックバックなどでどうぞ。しばらくはこのエントリに追記していく予定。

ちなみに今回の票に反映はさせてないけど、僕が好きなパターンはStrategyパターンです。 嫌いなパターンは今のところ特にないかな。

オブジェクト指向における再利用のためのデザインパターン
	Erich Gamma ソフトバンククリエイティブ 1999-10 売り上げランキング : 23044 おすすめ平均 内容は良いが翻訳が。。。 デザインパターン教へようこそ 設計の再利用 Amazonで詳しく見る by G-Tools

Java言語で学ぶデザインパターン入門
	ソフトバンククリエイティブ 2001-06 売り上げランキング : 216240 おすすめ平均 設計型紙 すばらしい本です Java以外でも使えます。 Amazonで詳しく見る by G-Tools

考えるきっかけになったのは、最近話題になっている以下のエントリ。

人生を書き換える者すらいた。: 人材獲得作戦・４　試験問題ほか

個人的に、あるアルゴリズムを用いて解くような問題を採用試験にだすのはどうかと思っていた。理由としてはいくつかあるのだけれど、「業務でそういったアルゴリズムを使うことが少ない(為、そういう知識がない」「知っている人と知らない人とで差がでてしまう」などなど。

で、先程Twitterに発言しながら似たようなことを考えていたのだけど、よくよく考えると上記の理由は「採用される側」での意見ということに気づいた。

まず、「採用する側」で一番避けたいのは、「ダメな人を雇ってしまわない」ということ。優秀な人を間違って落してしまうのも勿体無い話ではあるが、ダメな人を雇ってしまうよりはマシだ。そうなると採用試験では、その「ダメな人」を確実に篩い落したいわけだ。

大体において、業務で使わないようなアルゴリズムを知っている人は優秀である可能性が高い。「知識の差で合否が決まるのか」という話もあるが、知っている人は独自で勉強をしているだろうし、それをきちんとこういう問題にあてはめられる人はやはり優秀な人が多いのではなかろうか。

逆に言うと、それ以外の人は「ダメな人」である可能性が高いのであって、採用側がこのような問題を用いるのは割と理にかなっている。

それに仮にアルゴリズムを知らなくても、プログラマの基礎能力として「アルゴリズムを自分で考えられる」というのは大事なので、「私はこのアルゴリズムを知らないので理不尽だ」というのも結局自分のダメさアピールにしかならない。

採用試験をある種のフィルタと考えた場合、取り零しよりそのフィルタを抜けてきた人が重要という点を考えれば、この様な採用試験はかなり有効だと思われる。

これまた、割と今更なエントリ。当日は@t_wadaさんのお誘いでRubyグループのコーチ役として参加したけどあまりコーチらしいことしてないな・・・申し訳ない。

TDD Boot Camp(以下tddbc)では、午前中に @t_wada さんと Lasse氏 の講演、午後は各言語ごとにグループを作りペアプログラミング。朝から夜にかけてがっつりなイベントだった。TDDをやりたくてもやり方がわからない、やってみたはいいけど上手くいかないって人にはとてもいいイベントだったんじゃなかろうか。実際、僕も色々と得るものがあった。

とりあえず、当日のお題をあとで自分で書いたものを晒しておく。スレッドセーフ以外の仕様変更まで取りこんである。

http://github.com/ukstudio/LRUCache

これは1つのクラスにまとめてあるけど、結構複雑な感じになってきているので、CacheItemみたいな感じでもう1つ別のクラスを作ってそっちにキャッシュの保存期限とか持たせた方がいいかもしれない。仮にここからクラスを抽出するとしてこれだけテストが書いてあればそんなに苦労せずに抽出できるはず。テストがあるからこそクラスを抽出させるという変更も恐れることなく対応できる。

Fixnum#seconds_laterはLasse氏のを参考にした。個人的にStubの影響をブロックの中だけに限定させたかったので少し修正してある。あとは、Rspecの機能で言うと、subjectやカスタムマッチャを使ってる。それぞれそんなに難しくないので使ってみることをおすすめする。

最後にちょろっと感想を伸べておくと、tddbcはとても素晴しいイベントだったと思う。 @ebackyさんや、来日してくれたLasse氏をはじめ、スタッフのみなさん、今回このようなイベントを開催してくれて本当にありがとうございました。また参加された皆様からも色々な気づきを得られました。ありがとうございます。

僕はTDDでプログラマの階段を更に1歩登れたように思う。ハッキリ言って、TDDを知る前と知った後のコードにはかなりの差がある。なにより、TDDでのプログラミングは楽しい。tddbcに参加された皆様もこの楽しさを知ってもらえればと思う。

大分今更のエントリだけど、去年末にオブラブ忘年会2009に参加、LTで発表してきた。とりあえず資料はりつけ。永田さん、なんでiPhone買ってしもうたんや。

資料を当日用意したので、色々とグダグダな発表だったけど楽しかったのでよしとする。酒を飲みながらのLTは初めてだけど、変なテンションであれはあれで良かったかも。

オブラブ忘年会、楽しかったです。スタッフの皆様、本当にありがとうございました。

みなさま、あけましておめでとうございます。 本年もよろしくお願い致します。

思えば、昨年もいろんな人のお世話になりました。休職から結局退職することになってしまったRAWHIDE.の人達をはじめ、仕事がきっかけで仲良くさせて頂くようになった永和システムマネージメントの人達や、Twitterや様々なコミュニティで知り合った人達、普段から仲良くさせて頂いてる人達などなど、本当にありがとうございます。

ところで、今さらっと書きましたが先日社長とお話をさせて頂きまして結果、12月付けでRAWHIDE.を退職することとなりました。書類とか手続きとかをまだ済ませていないけれど、一応そういうことです。

今後の予定としては、実は某雑誌での記事の執筆が決まっているので1月はそっちに集中して2月あたりに次の仕事が見つかればいいかなと思っています。

次の仕事については僕がベストを尽せるのはRuby(on Rails)なので、今のところその方向で考えています。もし、Ruby(on Rails)エンジニアを探しているところがあれば声をかけてもらえれば幸いです。ちなみにうつ病あがりなので、その点はご了承ください。

プログラマーのジレンマ 夢と現実の狭間 伊豆原 弓 日経BP社 2009-05-21 売り上げランキング : 29765 おすすめ平均 Amazonで詳しく見る by G-Tools

読み終わってから結構日が立ってしまったが、なかなかよい本だと思ったので紹介しておく。

本書は、「Chandler」というOSSプロジェクトを1人のジャーナリストが3年間に渡って追い続けたドキュメンタリーだ。Chandlerプロジェクトは、優秀なメンバー(名前や、名前がわからなくとも参加したプロジェクト、製品なら大抵の人が知ってるであろう人々)、潤沢な資金、OSSの為リリース日を自分達で調整できるなど開発者からしたら理想とも言える環境で開発が進められた。しかし、結果としてプロジェクトは迷走に迷走を重ね、本書の中でバージョン1.0がリリースされることはなかった。

正直、あまりにプロジェクトが進まないので中盤あたりから少しうんざりしていた。本書中盤でまともな製品が出来ておらず、リリースも遅れに遅れて、「おい、おまえらいい加減にしろよ」と少なからず思った。その停滞感が文章でもきっちり表現されていてなかなかツラかった。

それでも、私はこの本をおすすめする。プロジェクトの失敗した話というのはあまりプロジェクト外に出ることは少ない。出たとしても局所的な失敗談や、技術的な話題が多いように思う。そうした点でこの本はプロジェクトのほとんどを曝けだしている。さらにその時、彼ら(彼女ら)がなにを考えなにをしようとしたのかが読める本書は、 色々と考えさせられる部分が多い。明確な答えを得られるような本ではないが、ソフトウェア開発について考えるきっかけとしてはかなり良い本だ。

ソフトウェアは難しい
　　　　　　　　- ドナルド・クヌース 「The Art of Computer Programming」

本書の冒頭でも引用されているが、Chandlerプロジェクトの失敗の数々はこの一言に集約される気がする。少々身も蓋もないかもしれないが。個人的には開発者だけでなく、開発者達の上に立つ上司や経営者にも本書を読んでほしい。「ソフトウェアは難しい」ということが少しはわかるだろう。

ところで、このChandler プロジェクトが現在も開発が続いてるようで無事バージョン1.0が公開されたようだ。残念ながら私のSnow Leopardでは動作させることが出来なかったので試せなかったのだが、もし興味がある人は以下のURLが参考になるだろう。

Chandler Project
MOONGIFT: » ようやく出てきたカレンダーアプリケーション「Chandler」:オープンソースを毎日紹介
GTD を意識したカレンダー・タスク管理アプリ：Chandler | Lifehacking.jp

HT-03Aを買ってからそれなりに時間がたったわけだけど、現時点で僕の使い方をまとめておく。

主な用途もなにも、僕は携帯をこれ1つしか持っていないので基本的にはガラパゴスケータイと然程かわらない。知り合いとのメールや電話での連絡、あとはネットを見るのが主な用途。もちろん、ガラパゴスケータイ(この言い方あまり好きじゃないんだけど他に何て言えばいいのかしら)からHT-03Aに移行してかわったことも多いので、そこらへんを重点的にまとめる。

Twitter

AndroidマーケットにはたくさんのTwitterアプリが存在するが、僕はm.twitter.comでTwitterを見ている。色々試したが、FavやReplyが出来無いことを除けばこれがベストだ。基本的に外出時は発言や適当にTLを閲覧するのが主だからかもしれない。一応Twidroidをインストールしているが、ブラウザからURLを共有してそのURLを発言する用途のためだ。

メール

HT-03AにはGmailアプリともう1つメーラが付属している。Gmailアプリで知り合いの携帯にメールを送るとデコメ扱いされて困っていたので、以前はGmailアプリで通知を受け取り、もう1つの標準メーラでメールを送るという使い方をしていた。

現時点は、K-9 Emailのみ使用している。とりあえずこれならデコメ扱いにもならず、メールも1分ごとに確認できる為だ。これを使いだしてからバッテリーの減りが早くなった気もするが、メーラを2つ使うよりはマシだ。

はてなブックマーク+ LDR

外出時の携帯の用途は実は暇潰しが多い。大体Twitterの閲覧をして暇を潰すが、LDRのFeedを消化することもある。LDReaderというアプリもあったが、実際の記事を見にいくとLDReader読んでいた記事の位置が保持されないので使用をやめた。(例えばはてブのFeedを読んでいて、10番目の記事から実際の記事をブラウザで表示させるとLDReaderに戻ると1番目の記事に戻っている)

なので今はブラウザから直接LDRを見に行っている。既読管理は出来無いが、Lite版のLDRの出来が結構良いので特に不満はない。既読管理もあとでPC版のLDRをみたときに読んだなってやつはそのまま流せばいいだけの話。

LDRでFeedを消化していると、はてなブックマークに登録したい記事もいくつかでてくる。以前は、HT-03Aからはてブするうまい方法がなかったので困っていたが、今でははてなB LiteというアプリでブラウザからURLを共有することでブクマできるようになった。

文字入力

文字入力はOpenWnn PlusとKaoMashを使用。SimejiよりはOpenWnn Plusの方が使いやすい気がする。なんとなく。KaoMashはSimejiやOpenWnn Plusと連携して顔文字を入力するアプリ。

OSが1.6にアップしたあと一度初期化したんだが、それからモサモサ具合が大分軽減された気がする。裏でダウンロードやアプリのインストールさせてるとさすがにツラいが、うまいことそういうのを避ければ大分ラクになったように思う。

その他

あとは細かいところで、路線探索に路線ドロイドや天気予報に東京アメッシュや世界の天気を使用している。カメラ系だと、ジオラマカメラやFxCameraを使用。特にFxCameraのトイカメラモードがお気に入り。

以前、ToggleSettingsを使用していたがOSを1.6にしてから動かなくなった。けど、1.6からウィジェットに電源管理というものが追加されて、それで代用できなくもないので特に困っていない。

まとめ

Androidは正直まだまだ使い勝手がいいとは言えないし、アプリも貧弱なものが多い。がアプリ間の共有機能はとても便利だ。単機能のアプリでもうまいこと連携させれば便利なことも多い。このエントリでもはてブ+LDRなども共有機能を使って実現している。

なのでアプリ開発者は共有機能を意識して開発をしてもらいたいし、ユーザー側もうまいこと共有機能を使いこなせると色々と便利になると思う。

Twitterやブログでもなんでもいいけど、「このアプリとアプリを組合せると便利!」というのがあればどんどん公開して欲しいなと思う。

ぼくには数字が風景に見える

ぼくには数字が風景に見える
	古屋 美登里 講談社 2007-06-13 売り上げランキング : 20117 おすすめ平均 新鮮な感動を感じました 天才の頭の中を覗ける本 異常な天才の半生記 Amazonで詳しく見る by G-Tools

割と最近(と言ってもここ数ヶ月の話だが)に「レインマン」のDVDを見たのでその繋りで積読状態になっていたのを読み切ってみた。レインマン繋りというのは、レインマンの主人公と同じくこの本の著者ダニエルもサヴァン症候群(アスペルガー症候群)であるという点。

注意: サヴァン症候群とアスペルガー症候群は厳密には違う。(サヴァン症候群 アスペルガー症候群 Wikipediaより)

文章は淡々としており、人によっては退屈するかもしれないが、個人的には丁寧で好感が持てる文章だった。ユーモアらしいユーモアもなく、生真面目な文章でどことなく本人の人柄が伺える。作中では、ダニエルの全体より細かい部分への拘りや言語に対する興味などが伺えるが、そのような性格がこのような文章を作りあげるのだろう。

タイトル通り、ダニエルは数字を風景、つまりイメージとして感じることができる。それを共感覚と言うらしい。本の中では数字がイメージとしてみえるということを丁寧に説明されており、正直イメージとして見えることが羨ましく思えた。僕自身、数字に対して漠然としたイメージはあるが、ダニエルのそれとは比較にもならない。

この本は、数字に関する話だけではなくダニエルの半生記としての側面もある。と言うよりかは、半生記の中に数字の話もでてくると言った方が正しいかもしれない。

その中には、当時アスペルガー症候群がまだあまり認知されていないにもかかわらず、素晴しい愛を持って育ててくれた両親や、アスペルガー症候群でありながらも一歩一歩前に進んでいくダニエルの姿も書かれている。特に「レインマン」のモデルにもなったキム・ピークと会う場面は感動的であった。

全体的に数学的な話や共感覚についてはあまり深く掘り下げておらず、ドキュメンタリーに近い内容になっているので、もし興味がある人はその点には注意した方がいいかもしれない。

数学に感動する頭をつくる

数学に感動する頭をつくる
	ディスカヴァー・トゥエンティワン 2004-06-30 売り上げランキング : 97118 おすすめ平均 数学ができる人とできない人は何が違うのかがわかる 幼少期の数的能力育成の方向性を知るために 子供の数学的能力をどうやって伸ばすか。 Amazonで詳しく見る by G-Tools

今年の春先ぐらいからだったと思うが、id:snow-bell(以下、yukky)が中心となって勉強会を不定期に行なっており、nishioさん、Misho、kuboon、cafistar等が参加している。

以前、kuboonがyukkyに微積を説明してるところを見てニヤニヤしてたが、僕自身そこまで微積をちゃんと理解しているわけではない。公式を覚えれば問題を解くことはできるだろうが、「数学の楽しさ」を感じることは出来ていない。「問題を解いた」という達成感はあるが、数学の楽しさはそこではない気がする。簡単に言うと博士の愛した数式に登場する博士の様に数学と接してみたいのだ。そんなときにたまたまこの本を見つけた。

本の中で、「数感」という単語が登場する。「音感」に合わせて著者が作った造語だが、一般に言う絶対音感や相対音感といった音感とは少々異なる。まぁそれは些細なことなので気にしなくてもよい。著者は本の中でこう述べている。

若い頃から、音楽を聞いている。なんとなく耳慣れている。もちろん深い意味でわかってなどいない。だが、なんとなく耳に心地良いぐらいの気はするようになってくる。そのうちにある日突然目覚める。

これはクラシックの良さがわかるまでの過程だが、数学もこれと同じということらしい。

はじめはわからないが、わからないなりに修練を積んでいく。なんとなく少しは問題が解けるようになる。そのうちにある日突然目覚めがやってくる。ある問題に触れる。あるいは、ある定理を深く理解する。その途端に、突然意味がかわる。数学は美しいものだ、と多くの人を嘆息させたあの魅力が、突然目の前に現われるのだ。

つまり、クラシックの良さを理解するには音楽に触れ音感を鍛える必要があるが、数学もそれと同じで数学に触れ数感を鍛える必要があると著者は言いたいらしい。では、具体的にどう鍛えればよいのかと言うのも本の中で解説されている。その中でも、特に僕が覚えているのは「イメージ力」と「構造化して記憶する」ということだった(詳細は本を読んでください)

著者は塾に勤めているというのもあってか、子を持つ親へのメッセージといった側面もこの本にはあるように思える。なので、子をもつ親にもオススメできる本となっている。出来れば子供が小学校入る前に読むといいだろう。

もちろん、僕自身得るものがあったので数学に苦手意識を持つ人や、現在学校で数学を勉強しなければならない、中学・高校・大学受験を控えているという人にもオススメだ。

Object#send(__send__)ならメソッドの呼び出し制限に関わらずメソッドを呼び出すことが可能なので、privateメソッドもテスト可能。

確か、1.9以降はメソッド呼び出し制限がObject#sendにも影響するとどこかで見た記憶があるのだけど結局そうはなっていないみたい。

1.9.1、1.8.7で確認済み。

ちなみにオマケ。

Pythonはメソッド名の前にアンダースコアを2つけるとprivateなメソッドになるのだけれど、実際のところ別名でメソッドを定義してそちらを呼び出してるっぽい。別名で定義された方はprivateではないので、そちらを呼び出してテストすることが可能。

他にもJavaだったらsetAccessible(True)を実行すればpublicなメソッドに変更されるのでテスト可能。と聞いただけで確認はしていない。

やけに煽ってるタイトルだけど、別にそんな大した話でもない。最近個人的に思ってることをつらつらと書く。

まず、Web系受託会社の定義だけどまぁWebサービスやWebアプリケーションなど比較的規模の小さいものを受託で作っているところとする。「規模の小さい」も割と感覚的なものだけど、まぁその辺の詳細は省く。

で、なんでまた亡びるとか言いだしたのかと言うとこの程度の規模のものは外部に開発を依頼するより、自分達で作る内製に向かっていくんじゃないと思っている為。特に最近の不景気でエンジニアを雇って内部で作るという流れがあるように見える。少なくとも僕のまわりでは。現にそういう話で「うちこない?」的なことも何度か言われている。受託会社に勤めている身としてはうちに発注してよと思わなくもないが、なかなかそうも行かないらしい。

まぁ個人的にはWebサービス、アプリケーションに限らず、いわゆる業務システムも内製した方がいいと思ってるからまぁこの流れは歓迎してると言えばしてるんだけど、受託会社としてはちょっとやばいかなと。

要は今まで発注してくれてた会社が自分達で作るようになって、受託会社に仕事がこなくなるからやばいんじゃないのって話。業務システムとか割と規模の大きい仕事を受けてるところはまだ大丈夫だと思う。 それよりWebサービス、アプリケーションをメインで受託してる会社がやばい。

なんでやばいかと言うと、ちょっと優秀なエンジニアなら1人で作れるものが多い。例えばSNS(ブームは去ったけどね)を作ろうとなったときに、外部に依頼するよりエンジニア1人とデザイナ1人雇えば十分だと思うし、僕自身作れる自信がある。まぁSNSと言っても規模は色々あるんだろうけど。

まぁさっきも言ったように、内製するのは歓迎だしそれはそれでいいんだけど、受託会社として今後どうするのかって話。

いくつか思いつくのは、業務システム系に手を出す、売るものを作る(パッケージ開発)、自社サービス(広告、課金)とかとか。まぁどれが正解とかわからんし、もしかしたら他にも道があるかも。

そんなことを考える日々です。他のWeb系受託の人たちはどう考えてるんだろうねー。