UK STUDIO

プログラマという職業は「ふつう」の人には厳しくないかでは結構な反応もらって少しびっくり。

そこらへんのことをもう少し述べると、僕自身はプログラマが勉強をしないでいい職業とは思っていない。ただ、現状プログラマをやっている人で、普段自分でコードを書かない(能力的に平均以下であろう)人達がかなり多く存在している。個人的にはハッキリ言ってそういう人達は足手纏いだと思っている。なので正直、そういう人達がいなくなればいいとも思っている。

だが、現状そういう人達が存在している以上、「あなたたちはプログラマとして無理なのでやめてください」と言ってしまっていいのか、それはさすがに傲慢じゃないのか、普段からコードを書き能力がある人達と、そうじゃない人達が共存する方法はないのかと思って色々書いたのが先のエントリ。

@ukstudio 別にその仕事を好きでもなくて向いてるでもなくて、ていう人たちに別の仕事やったら? ていうのは排除してるわけじゃないと思うんだけどなー。

しかし、ogijunさんにこのように言われて、それもそうかと納得してしまったので、僕にとって結局のところプログラマは自己学習をし、ある一定以上の能力がある人達が就く職業ということで落ち着いた。

で、落ち着いたはいいけど、現状そうはなっていない。個人的に一番疑問なのが給与面である。

先のエントリでの反応で、「業務時間外の行動が業務に影響し、それ相応の査定・給与となっているのだからいいではないか」と言ったような意見をいくつかもらったが、本当に査定・給与に反映されているのだろうか。正直、プログラマは技術力にかなりの格差があるにもかかわらず、給与にそこまでの格差がないように思える。

はてブで「プログラマや専門職はそういうもんだ」「社会人なら勉強してて当然だ」という意見が多数だったが、そういう人達は相応の対価をもらっているのだろうか。そこが一番不思議だ。個々の能力を給与に反映されてないにも関わらず、業務時間外に勉強するのが当然と思っているとしたら、少々社畜っぽいなと感じる。医者や弁護士を例に出した人もいたが、それらは資格が必要なのもあって供給の少なさからそれなりの高給をもらっていると思うのだが、プログラマはそうじゃない。

これは多分、プログラマに限った問題ではない。この間聞いた話だと、不動産の営業で片や2億売り上げた、もう片方は200万売り上げた。しかし給与はほぼ同じという例もある。もちろん、会社という存在があってこその2億だとは思うが、それを考慮しても本人からしたら1億9800万の差が給与に反映されていないならモチベーションがあがるはずもない。

プログラマの場合、問題になるのが成果がわかりづらいという点である。なにをもってプログラマの価値を決めればいいのかわかりにくい。例えば、優秀な人であればコード量は少なく労働時間も短く作れるものが、他の人であればコードは肥大化し労働時間も長くなるだろう。その場合、後者の方が残業代なども含めて給与が高くなるだろう。

結局のところ、プログラマが作りだす価値を定量的に評価できないのが問題だとは思うけど、そこを解決する術が正直わからない。

業界云々ではなく、自分で自分の問題を解決するだけなら、会社に所属した以上自分の価値を決めるのは会社になってしまうので、それを解決するには起業や個人事業主などを検討するのがいいとは思っているけどどうなんだろうか。

例えば、会社員だとあるサービスを作ったとしてそれが大成功をしたとしても、売り上げた金額に比べて自分の給与に反映される金額はそこまで大きくないだろう。しかし、法人や個人事業主としてなら契約金+レベニューシェア的なことも検討できる。

いまのはあくまで1つの例だが、そういう選択を自分で出来ることを考えると起業・個人事業主というのも1つの選択肢としては全然有りなはずだ。法人なら税金も安くすませるはずだし。

とりあえずGoogle Mapで。他のサービスもservice変数を書き換えれば認証までは通るはず。クエリのPasswdをPasswordにしてて結構はまった。Unix文化め。

参考: Google Data API – Google Code

opensocial-ruby-clientのドキュメントがあまり無くて結構苦労した。

まず、opensocial-ruby-clientはRailsありきなんだけど、そこで修正が必要。

これは自分のプロフィールとマイミクとかをとってくるコード。mixi用のConnectionがないので自分で作る必要があり。

最近、実はプログラマという職業が「ふつう」の人には厳しいなーと思っていたりする。

業務外にコードを書いたり、技術書などを読むというのは素晴らしいことだと思う。けど、会社側がもし「業務時間外にコードを書いたり、技術書を読んだり、勉強会に参加しなさい」と言ったら、それは業務時間外労働と変わらないと思う。個人のたのしみとは別に会社側がそれらを求めたらそれは業務だ。

しかし、僕が思うにはそういう業務時間外に自主的に勉強をしないと、正直いってまともな品質なソフトウェアを作るのは難しい。

例えば良書と言われているものは結構な数あり、ある程度経験がありそれらの本を読んだことがある人は「プログラマならこの本は読んでおくべき」という本をいくつかあげたりもするだろう。けど、それらをいつ読むのか。業務時間内にそれらをじっくり読んだり、実際にコードを書いたりする時間があるところはないだろう。そうなると自分のプライベートの時間を使うしかない。

別に僕はそういうことが好きだからいい。会社への貢献とかそういうことは関係なく自分で読みたい技術書は読むし、書きたいコードは書く。では、そうじゃない人達は? (とりあえず、ここではそういう人達を「ふつう」の人と言うことにする)

「ふつう」の人達はプログラマになるべきじゃないのだろうか? 例えば、プロスポーツ選手であれば普段の生活からそれ相応の生活を求められるだろうが、プログラマもそういう職種なのだろうか。

少なくとも今現在まわりと見渡すと「ふつう」のプログラマも結構いるように思う。結婚して妻子がいて、そういう勉強の時間があまり取れないって人もいると思う。そういう人達にプログラマはもう無理だねと言ってしまってもいいのだろうか。

多分、個人的にそれは違うと思っている。なぜ?と言われると正直「なんとなく」程度でしかないのだが、プログラマは「ふつう」の人達でも普通に働ける職種であるべきじゃないのか。

業務時間外に勉強をすることを業務時間外労働と捉えた場合、業務時間外労働をしないとやっていけない職種はおかしいというか病んでいるんじゃないかなぁ。

東京Ruby会議03 – Regional RubyKaigi -

先程、公開しました。受付けも開始してるのでそちらから申し込みください。多分、右側の開発概要はこれから詳細が公開されていくと思います。

今回はいつもと違って東京Ruby会議03専用デザインです。デザインは@mayucoさん。専用デザインを使うため、僕の方でRegionalRubyKaigiのシステムに手を入れました。バグがないといいけど。

本当は明日、公開予定だったんだけど、@ayuminさんが今日開催されてる並カンで宣伝枠をもらったらしく、そこでデプロイしたらおもしろいんじゃない?とか言われたので、@ayuminさんが発表しながらSkypeで僕に合図をし、僕が家でデプロイ作業をするというよくわからない感じに公開しました。

なにはともあれ、スタッフ一同良いイベントにしようと頑張っているのでぜひ参加してくださいねー。

先日、ちょっとした思いつきで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)エンジニアを探しているところがあれば声をかけてもらえれば幸いです。ちなみにうつ病あがりなので、その点はご了承ください。