UK STUDIO

2月27日に開催された東京Ruby会議03にスタッフとして参加した。

今年初めになんとなく立てた目標に「なんかしらのイベントにスタッフとして参加する」というものがあって、当初はRuby会議の方に参加するつもりだったんだけど、takknamの人が「東京Ruby会議がスタッフ募集しているみたいだよ」と教えてくれたのがきっかけでスタッフとして応募することになった。

今回、東京Ruby会議03専用に公式サイトを用意したいと言うことで既存のRegionalRuby会議のシステムに僕の方で手を入れることになった。デザイン・マークアップはmayucoさんが担当が担当してそれを僕が組込むという感じ。話を聞くと好評だったようで、僕がスタッフらしい仕事をしたのはこれぐらいなんだけど、これだけでもスタッフとして参加してよかったなと思う。

当日は、会場の準備と受付以外は基本プラプラしてた。朝、東京マラソンのことをすっかり忘れてタクシー使ったら思いっ切り遅刻してしまった。ほんとすみません・・・

セッションは残念ながら成瀬さんの時は受付にいたので聞けなかった。yuguiさんと田中さんのセッションはすごい勉強になった。２人とも説明がとてもわかりやすく素晴らしかった。残念ながらどちらのセッションも理解不足のところがあるので要復習。

ワークショップはどこかに参加はせず、プラプラと。ワークショップも好評だったらしく、開催中みんな楽しそうだった。個人的にメイド服と川口さんの娘さんが折り紙おってたのが印象的です。実は、折り紙ワークショップの内容がすごい気になってたりするんだけどどこかに資料あがったりするのだろうか。

懇親会では、吉岡さんと初めてお会いしたのだけれど、あの質問力はすごいなと思った。見習いたい。

最後に。今回東京Ruby会議03にスタッフとして参加できて本当に良かったです。本当にありがとうございました。

新しい言語学ぶ時はとりあえずFizzBuzzを書く。Clojureのcondは括弧が少なくて個人的に好きです。

RedLine Magazine : PHP

デザイナの@red_hippyさんがPHPを勉強しているとのことなので適当に。ちなみに僕はあまりPHPを書けないのでバリバリPHPを書いてる人からみたらおかしいところがあるかもしれないけど、なるべくそういうのないよう頑張ります。

そもそもオブジェクト指向でやる必要はあるのか

これは個人的な意見だけど、本職のプログラマでもない限り無理にオブジェクト指向でやる必要はないと思ってる。特に学びはじめのデザイナさんならそこまで複雑なものを作らないだろうし。@red_hippyさんがどの程度のものを作ってるかわからないから一概には言えないけど、掲示板やお問い合わせフォームレベルのものだったらオブジェクト指向である必要はない。

プログラマの人が「PHP5ならオブジェクト指向っすよ!」とか言っても信じちゃいけません! 本当にオブジェクト指向が必要だと思って言ってるのか少し疑問。初心者の人妻にHaskellやらSICPやらすすめる人もいるし、困ったもんだ。

とりあえず、最初は愚直に処理の順番通りに書いていって、「なんかこのコード何回も書いてるなー」ってのが出てきたらそこを関数にするとかで十分。

とは言うものの、@red_hippyさん自身が楽しんでればそれでいいと思うし、Twitterを見る限り楽しんでそうなのでオブジェクト指向の話もちゃんとします。

追記:
これを書いてる途中に@red_hippyさんから、「プログラマさんが勉強するようなことをちゃんとやりたい。」と言われたので上の話はなかったことに。

オブジェクトってなんぞ

では、オブジェクトって何でしょう。

データとそのデータを操作する手続きをまとめたものを「オブジェクト」と呼び、オブジェクトの定義（雛形）を「クラス」と呼びます。PHPでは、オブジェクトは変数（データ）と関数（手続き）をまとめたものです。

@red_hippyさんのブログでも書かれてるけれど、説明的にはこれでOK。これだけでわかる人もそういないと思うけど。 この説明だけだとわかりづらいので「ブログの記事」を例に説明してみる。

まず、「ブログの記事」が持つデータについて考えてみよう。とりあえず思いつくのを適当にあげると「タイトル」「本文」「投稿日」「投稿者」などが考えられる。そしてそのデータを操作する手続きについてはそのデータの保存と取得が考えられる。いわゆるsetter/getter。アクセサとも言う。これを実際のコードに置き換えてみよう。

データがprivateな変数としてあって、それの操作としてsetTitleやgetTitleがあるのがわかる。簡単な例ではあるけど、オブジェクトがデータとそれの手続きをまとめたものというのはこういうこと。ちなみにこの変数のことをメンバ変数の他にインスタンス変数、フィールドとか言ったりする。これは言語によって違うかも。Rubyだと大抵インスタンス変数と言う。

ちなみにマジックメソッドを使ってもいいと思うけど、これはprivateな変数に対してアクセサを作ってしまうので注意が必要。下手すると隠蔽の意味がなくなる。個人的には必要なものだけをアクセスできるようにしたいので、マジックメソッドは使わない。

getter/setterの意味

で、なぜ一々getter/setterを作るのか。一言で言うと、直接データにアクセスされると困る場合が多いから。

まず、困る例を。以下のコードはSquare(正方形)というクラスにもかかわらず、直接データをいじれてしまう為、縦と横で一致しないデータを入れることが出来てしまう。

これを防ぐにはsetterでうまく処理をする必要がある。

heightもしくはwidthに値を保存したら、もう片方にも値をいれることで同じ値になるようにした。メンバ変数をprivateにすることで、この関数を通してでしか値を保存することが出来ない為、縦と横でデータが一致しないということはなくなる。しかし、これはこれで縦を指定しているにもかかわらず、横もかわってるという気持ち悪さが残る。これをもう少し改良して、値の保存はgetLengthという名前にする。これなら関数の名前から縦・横が変わっていても違和感ないだろう。

これと似たような話で、例えばあるデータには数値だけ、文字列だけ入れたいというチェックもsetterでやることができる。

基本的にクラスの中の変数や関数は本当に必要なもの以外privateでいい。別に1つのメンバ変数に対して必ずsetter/getterがいるというわけじゃない。むしろそういうのはよろしくないので、いくつかのメンバ変数をまとめて処理して1つの関数で出力するというのも全然あり。

例えば、prefecture(都道府県)、city(市区町村)、street(通り)というメンバ変数があったら、それぞれpublicにするより、getAddressという関数を作ってその中でそれらを連結して返すという方がいい場合もある。この方が例えば仕様変更でcityがなくなった時に修正する部分が少なくて済むという利点もある。このあたりは抽象化とかデータ構造の分離とかそういう話になるんだけど、ちょっと難しくなりそうなのでこの辺でやめとく。

ちなみにPHPでsetter/getterをちゃんとやってるコードをあまりみない(全部public)なのは、元々オブジェクト指向の言語ではなかったし、そこらへんあまり考えない・知らない人が多いからだと思う。

MVCについて

MVCについてだけど、個人的にはとりあえずフレームワークを使ってしまった方がイメージがつくので理解しやすくなるかと。最初のうちはフレームワーク使わない方がいいって人もいるけど、個人的にはフレームワークを使って疑問に思ったところ、気になったところを調べる方が理解が早い気と思う。

どのフレームワークがオススメとかは正直わからないんだけれど、日本語のドキュメントが多くて有名なのを使っておくのが無難かと。

まとめ

オブジェクト指向は難しいと思います。未だに僕も勉強中だし、ちゃんと理解してないプログラマも多いし。 多分、理解するには人のコードを読んで、自分でコードを書いて、それを誰かにレビューしてもらうというのが早いと思うんだけど、とりあえず1つ1つ理解していくしかないと思うのでじっくり頑張ってください。

結構時間かかった。今日(正確には昨日)の夕方からずっといじってた。まとめるとそんな時間かかるようなものでもないんだけどね。clojureよりvimclojureで色々手間取った。ちなみにプログラミング Clojureのサンプルを動かすだけなら、サンプルコードの中にClojureの実行環境(REPL)が含まれてるので以下の設定をやる必要はなし。

clojureのインストール

ソースはgithubから落としてくる。masterでもいいんだけど、clojure-contribの方がmasterだとうまくbuildできなかったので1.1.0を使うことにした。

$ git clone git://github.com/richhickey/clojure.git
$ cd clojure
$ git co -b 1.1.0 1.1.0
$ ant

clojure-contribのインストール

プログラミング Clojureではcontribのライブラリを結構使うみたいなのでこちらもインストール。

$ git clone git://github.com/rechhickey/clojure-contrib.git
$ cd clojure-contrib
$ git co -b 1.1.0 1.1.0
$ ant -Dclojure.jar=/github/clojure/clojure.jar

REPLの起動

$ java -cp /github/clojure/clojure.jar:/github/clojure/clojure-contrib.jar clojure.main

これで無事REPLが起動すればOK。contribが使えるか気になる人は試しにuseなどしてみるといい。エラーがでずにnilが返ってくればOK。

user=> (use 'clojure.contrib.str-utils)
nil

起動コマンド

いつもjava -cpとかやるのは面倒なので起動コマンドを使う。

$ mkdir ~/.clojure
$ ln -s /github/clojure/clojure.jar ~/.clojure
$ ln -s /github/clojure-contrib/clojure-contrib.jar ~/.clojure
$ export CLOJURE_EXT=~/.clojure
$ alias clj=/github/clojure-contrib/launchers/bash/clj-env-dir

clojure-contribに起動用のスクリプトがあるのでそれを使う。CLOJURE_EXTにjarのあるディレクトリを指定する必要があるため、適当なディレクトリを作り、そこにjarを入れておく。あとは適当にaliasはるか、実行パスのあるところにファイルを置けばよい。

vimclojureのインストール

vimclojureもリポジトリから落としてくる。tip(masterとかtrunkと同義)だとBuildツールがantじゃなくてgradleになってるけど、うまくbuild出来なかったので2.1.2を使う。

$ hg clone http://bitbucket.org/kotarak/vimclojure/
$ cd vimclojure
$ hg co -r v2.1.2

/path/to/vimclojureにlocal.propertiesというファイルを作る。

clojure.jar = /home/user/.clojure/clojure.jar
clojure-contrib = /home/user/.clojure/clojure-contrib.jar
nailgun-client = ng
vimdir = /home/user/.vim

そしてbuild。

$ cd /path/to/vimclojure
$ ant
$ ant install

antでbuild、ant installでvimdirにpluginとかがインストールされる。vimrcを設定すれば、この時点でsyntax-highlightとかOmni補完とかは使えるようになっているはず。

VimでREPL

vimでREPLなどの機能を使うためにはng-serverを立ち上げる必要がある。CLASSPATHにjarが設定されていないといけないみたいなので設定する。

$ export CLASSPATH=$CLOJURE_EXT/clojure.jar:$CLOJURE_EXT/clojure-contrib.jar:/path/to/vimclojure.jar
$ sh bin/ng-server
NGServer started on 127.0.0.1, port 2113.

そして、vimrcの修正。syntax highlightの設定なども含む。

" vimclojure
let clj_highlight_builtins = 1
let clj_highlight_contrib = 1
let clj_paren_rainbow = 1
let clj_want_gorilla = 1
let vimclojure#NailgunClient = "/path/to/vimclojure/ng"

適当なclojureのファイルを開く。使い方は:help clojure.vimを見ればよい。とりあえず、REPLの起動は<LocalLeader>sr。

これで一通り設定完了。結構時間がかかったけど、大体詰まるところはCLASSPATHまわりだったのでもしうまく動かなかったらまずそこを確認した方がいいかも。

良いclojure + vimライフを。

参考:
Kotka : Projects : Clojure : VimClojure
Clojure Programming/Getting Started – Wikibooks, collection of open-content textbooks

rvmのインストール

rvmのインストールはgithubからやった。(rvm: Ruby Version Manager – Ways to install rvm.)

使うバージョンは、1.8.7。

rvm install 1.8.7
rvm 1.8.7 --default

Passengerのインストール

Gentooだと、Passengerはmaskされてるっぽいので/etc/portage/package.keywordsにwww-apache/passenger追加して、emerge passengerする。

Apacheの設定

/etc/conf.d/apacheに”-D PASSENGER”追加。

/etc/apache/vhosts.d/にvirtualhost追加。

<VirtualHost *:80>
  ServerName hoge.example.jp
  DocumentRoot /path/rails/public
  RailsBaseURI /
  <Directory /path/rails/public>
    Options FollowSymLinks
    AllowOverride None
    Order allow,deny
    Allow from all
  </Directory>
</VirtualHost>

/etc/apache2/modules.d/30_mod_passenger.confを修正。

PassengerRuby /home/ukstudio/.rvm/bin/ruby-1.8.7-p249
PassengerRoot /home/ukstudio/.rvm/gems/ruby-1.8.7-p249/gems/passenger-2.2.9/

あとはapacheを再起動すればOK。

なんか、rvmに–passengerオプションがあるのでそれを使うよう設定すれば、気軽にPassengerで使うrubyを返られる気がしなくもない。そこらへんはそのうちやる。

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

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

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

@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で僕に合図をし、僕が家でデプロイ作業をするというよくわからない感じに公開しました。

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