退職しました

2nd Apr, 2011 | job

やめちゃった。

8年半前に創業直後だったこの会社に入って、ほぼ0から色々なものを作り、動かし、それなりに会社は大きくなり、立場的にもそれなりに偉くなり、給料もそれなりに貰って、居心地は悪くなくて、そうなんだけど、その一方で、自分にとって刺激は少なくなり、なんとなく楽しさが減っていた、という感じ。自分自身なんとなく安定してしまっている、という状況自体がなんとなく怖かったりもした。

それでも、暇なら色々と遊べるのだけど、日々やらないといけないことは全然減らなくて、忙しいんだけど何か刺激がない、みたいな悪い状態に陥っていた。

会社のことを考えてみても、多少老害になりそうな自分が辞めることで、新陳代謝したほうがいいのかなー、というのもある。よく知っているだけに思い切ったことができなくなっていることも多いし、なんとなく偉そうにしている自分も嫌だったりした。

前にも少し書いた ように基本的にいい会社になっているとは思うんだけど、悪い文化もできてしまっている。その悪い文化を作ることになってしまった一端は、長いこといる自分にもあるわけで、その自分が存在しつつ、その悪い文化を変えていくのはなかなか難しい、と感じているのもある。

まあ、上記すべて本音のつもりだけど微妙に嘘っぽく、後付けの理由っぽくもある。単に、色々なことに飽きてしまったのかも!

家族もいるし、常に崖っぷちを楽しむわけにもいかないけど、それなりの逃げ道を残しつつも新しいことドキドキしながらしたいとか思ってしまう。こんな時代だし、飽きちゃったとか、新しいことしたい、とかいう理由でやめちゃうのは甘っちょろいな、とも思うんだけど、まあやめちゃいました。

なんだかんだで8年半在籍したわけだけど、8年半ってのは結構長いよなあ。自分の中でも、人生で所属した組織で一番長いものになってしまった。2位が小学校で、3位が最初に入った会社かな。そういう組織を離れるのはなかなか寂しいものはあるのだけど、別れはいつか来るということで。

それにしても、この会社では本当に、大きなことから小さなことまで色々な新しい経験をさせてもらったなー。外国文化に触れることもできたし、とても人生にとってプラスになるものだったと思う。感謝でいっぱい。

で、何するの? ってことだけど、まだ内緒! ということで。もう少しロンドンにいる予定です。



Google App EngineとPythonでの素直な開発環境の構築(TDDができるように)

31st Jan, 2011 | Google App Engine python TDD

追記: 続編的なものを書いた。

今年は色々なことに手を出してみよう、ってことで少し前からGoogle App Engine(以下GAE)で、あるモノを作っている。モノ自体は近いうちに公表できると思う。

基本的に、Pythonと標準っぽいフレームワークだけでやってみている。作っているものがそれなりにシンプルなのと(だからこそGAE!)、GAEでそれなりの規模の開発をするのが自分自身初めてということもあり、あまり色々なレイヤーを重ねて手こずりたくなかった、ってのがその理由。

ただ、GAE初心者なので、「いやいやそれは今時ないよ」「XXの方が100倍いい」とかあったら教えてくれると嬉しいので今のところの環境を書いておくことにした。今ならスイッチ可能。

今作っているものがJSONファイルを入出力するだけのものなので、HTML生成パートみたいのはない。

1. フレームワーク

上にも書いたように、今回は、わりと単純なアプリケーションの作成なので、Google App Engine (Python)で提供されている最小限のフレームワークだけを使っている。

2. Pythonのバージョンは2.5

Google App Engineは2.5が前提 らしい。

Mac (Snow Leopard) だと、2.6と2.5の両方が入っていて、デフォルト(/usr/bin/python)のバージョンは2.6。そのため普通にGoogle App Engineの開発環境をインストールすると2.6が使われてしまっていて、最初の数時間無駄にした。

defaultコマンドで /usr/bin/python の指すバージョンを変えられるようだけど、他に影響を与えたくなかったので、今回は、

  • コマンドラインから実行するpython関連のコマンドは2.5を付けて実行(例: easy_install-2.5)
  • GoogleAppEngineLauncherで、 /usr/bin/python2.5 を指定

で、なんとかなっている。

3. ディレクトリ構成

「GAE/Pythonスタンダードなディレクトリ構成」みたいのはないようなので、いろいろな公開されているプロジェクトを参考にして以下のような配置にしてみた。最初はもうちょっと深い構成にしていたのだけど、これぐらいで十分かも。今のところModelは1ファイルにまとめてるがだいぶ増えてきたので、近い将来分離する予定。

application dir/
  models.py
  handlers/foo_handler.py
  handlers/bar_handler.py
  tests/test_foo_handler.py
  tests/bar_foo_handler.py
  main.py
  app.yaml

controller的なものをhandlerと呼ぶみたいなのでそうしてる。

4. テスティング環境

もう当然TDDだよね、ということで最初に手をつけたのがテスト環境の構築。

まず、ここしばらくWeb開発でRuby on Rails + rspecメインな生活をしていることもあり、GAE/Python上でもそれっぽいのを探してみたところ、いくつかそれっぽいのはあったのだけど、「開発が活発ではない」「使いづらそう」という感じがしたのでその方向は諦めて、普通にUnitTestでいくことにした。マイナーなものを使うよりも、自分以外の人が触ることになったときのことを考えて、ふつーなものにしておいたほうがいいかな、という判断もある。

素のUnitTestだけだといろいろいまいちなので、以下の物を入れた。

sudo easy_install-2.5 nose
sudo easy_install-2.5 nosegae
sudo easy_install-2.5 gaetestbed
sudo easy_install-2.5 webtest

使い方等は、その中のgaetestbedの README 読めばなんとなく使い方はわかるので省略。

5. doctest併用

UnitTestの他に、コードの中にテストを書ける doctest も使っている。基本的にhandlerのテストはUnitTestで、modelのテストはdoctestで書いている。

併用している理由としては、長い間うっすらと「なんかdoctestいいなー、いつか使ってみたい」と思っていたのと、今回はそれほど複雑なmodelがないというのがある。

nosegaeは、UnitTestとdoctestの両方を同時に扱えるので、この二つを混ぜても素直に全体のテストの実行が1コマンドできる。オプションに—with-doctest を付けて、

> nosetests --with-gae --with-doctest 

こんな感じ。CIでもほぼこれと同じコマンドを実行している。

6. セッション管理

GAEでは、Googleアカウントと連動したセッション+アカウント管理は標準で提供されているようだけど、今回は自前でセッション/アカウント管理をしたかったので、それは使わずに、セッション管理には gae-sessions を使ってみた。他にも色々あるのだけど、単純で軽そうだったのでこれにした。

そのライブラリの作者が作った他のライブラリとの 比較表 が参考になる。完全勝利になってるのは若干あやしいが。

このライブラリで作成したセッションに、自分で作ったユーザ用のモデルを入れるという簡単実装にした(gae-sessionsのセッションの実装自体は普通にCookieを使ったものなのでデバッグ等も簡単)。

一つ躓いた点として、gae-sessionsの導入手順をREADMEに従うと、 appengine_config.py を作ってそこでmiddlewareをセットする、となっている。ただ、ローカルの開発環境でnosegaeを使いunit testを流すと、 appengine_config.py は読んでくれないので、main.py の中で直接読み込んでごまかしてる。こんな感じ。

application = SessionMiddleware(
    webapp.WSGIApplication([....],
                           debug=True),
    cookie_key="hogehogehogehogehogehogehogehogehogehogehogehogehogehoge")

7. 本: Code in the Cloud

とりあえずGoogle App Engineを始めるにあたって何冊か読んだ本の中でそれなりに良かった奴。JavaとPython両方が書いてあるのが微妙に読みづらいが、最初に読む本、としてはそこそこいい本だと思う。テスト関係のことはほとんど載ってないけど。

8. まとめ

以上の環境で、ぼちぼちコードを書いているけど、気持ち良くTDDができている。GAE自体は思ってたよりも(話に聞いていたよりは)複雑でも難しくもなく素直だなーって印象。ドキュメントもわかりやすい。まあ、後発組は楽だなあ、と。

とは言え、もうちょっとやると壁にあたりそうなので、そのときまた何か書きたいと思う。

9. 参考にしたもの

http://www.cuberick.com/2008/11/unit-test-your-google-app-engine-models.html
https://github.com/jgeewax/gaetestbed/
http://www.slideshare.net/adeoshineye/test-driven-development-on-google-app-engine



2010年を振り返っちゃう

31st Dec, 2010 |

全体的になかなかいい年だったかな。Web開発に関係するところを挙げてみると、

このブログを始めた

どうもヒキコモリ過ぎてるなと感じていたので、ブログを始めてみた。3日坊主にならずにそれなりに続いたのは良かった。やっぱり、自分を外に出すことは自分を客観的に見るためにも大切だ。

おかげさまで、そこそこの反応を頂けたりと、なかなか楽しいです。

技術面

Rubyを始めて2年目にしてRubyとRailsが身についた、って感じかなー。自分の学習曲線の中のいいタイミングで、 Metaprogramming Ruby という良本に出会えたのが良かった。

また、去年の後半くらいからMongoDBを追いかけていたのだけど、今年の後半、実際のシステムで少し使うことができて手応えを得ている。今後は、もうちょっと大きいところでも使ってみるつもり。MongoDBいいですよ。

スクラム初体験してみたのも今年だったかな。これは正直、完全に自分の武器になったか、と言うと微妙なところ。もうちょっと実戦で勉強。

来年

来年は、仕事面でちょっと変化の年にしたい。ここ数年、いい面でも悪い意味でも安定してしまっているので、少しかき混ぜたい感じ。

流行に乗り、スマートフォンやGoogle App Engineなどにも急激に興味が出てきたので(やらなきゃまずいかな、というのもある)、そっち方面を攻めるのが濃厚。流されやすいんです!

そんなわけで、来年もよろしくー!



Heroku + MongoHQ が素晴らしい

16th Nov, 2010 | heroku mongodb rails ruby

前から気になっていた Heroku + MongoHQ を試してみた。HerokuはRubyアプリケーションを走らせるホスティングサービスで、MongoHQはMongoDBのホスティングサービスだ。この二つを組み合わせることで、MongoDBを使ったRubyアプリケーションを一瞬で運用開始することができる。

あまりにも簡単に使えてあまり書くこともないんだけどメモ。

まず、両方とも最低限の環境は無料で使用できる(ただしHerokuからMongoHQを使うためにはクレジットカードの登録は必要っぽい)。

今回は Ruby on Rails 3 + Mongoid で作ったアプリを置いてみた。

手順

1. まず、普通に RoR + Mongoid のアプリケーションを作る

2. Herokuにアカウントを作りアプリケーションを登録する (http://docs.heroku.com/quickstart )

3. HerokuでMongoHQを有効にする (http://docs.heroku.com/mongohq )

$ heroku addons:add mongohq:free

4. Mongoidの接続情報であるconfig/mongoid.ymlのproduction環境のところを以下のように書き換える。

production:
  uri: <%= ENV['MONGOHQ_URL'] %>

追記: もしくは、 config/initializers/mongohq.rb のようなファイルを作り、 そこで指定する。

if ENV['MONGOHQ_URL']
  # For Heroku (See: http://docs.heroku.com/mongohq)
  Mongoid::Config.instance.from_hash({"uri"=> ENV['MONGOHQ_URL']})
end

5. 普通にHerokuへdeployする (具体的には、gitでHerokuにpushする)

これだけで、MongoHQのMongoDBを使うようになる。超簡単。

(ちなみに、ここ最近、RubyとMongoDB間のORMはMongoidしか使っていない。一時期、 MongoMapper を使っていたのだけど、Mongoid の使いやすさに負けた。機能的には大きく変わらないのだけど、ちょっとした細かいところとか、センスの良さが全然違う。)

気付いたところ

1. Heroku経由でMongoHQを使うとMongoHQにログインできない?

MongoHQにも管理画面的なのがあるっぽいのでこれはちょっと嫌だ。(何か方法ありそうだが)

2. ここ にあるように、MongoDBの接続情報を取得し、自分の環境からHerokuを通さずに直接接続も可能。

バックアップもmongodumpコマンドで普通に取れるし、 Mongoシェル でアクセスするのも問題ない。これは便利。

ただ、便利なのだけど、つまりMongoHQのMongoDBは全世界から接続可能なので、接続情報や、ID/パスワードの管理は慎重にする必要があるのがちょっと厳しい。例えば、Rubyアプリ側では、 ENV[“MONGOHQ_URL”] にID/パスワード含む接続情報がすべて入っているので、デバッグ目的などでENVを間違えて表示しちゃったりすると大惨事になりそう(これはHerokuのMySQLとかPostgreSQLとかも同じっぽいが)。

3. HerokuからMongoHQまでのlatencyは一桁ミリ秒だった。

なんとなく不安だったのだけど問題なさそう。

まとめ

RoRとMongoDB(Mongoid)のスキーマレスでの素早い開発と、簡単にデプロイできるHeroku+MongoHQの相性がとてもよい。ちょっとしたアプリケーションを作ったり、プロトタイプを作って色々な人に見せたい場合にとても向いていると感じた。もちろん、アクセス数やデータベース容量にあわせて、Heroku/MongoHQともに有料コースに切り替えて本番環境として使い続けるのも問題ないだろう。

また、「Heroku+MongoHQで動かす」と言っても、アプリケーション自体はもちろん普通のRuby(Rails)とMongoDBなので、Heroku/MongoHQが嫌になったら、他へ移ることも、自分で運用するのにも何の問題もない。「とりあえず作ってHeroku+MongoHQで動かしてある程度軌道に乗ったところ次を考える」というのが可能だ。これはかなり魅力的(今、世の中はロックインが流行ってるようだし!)。



1356 はてブ、761 ツイートのパワー

25th Oct, 2010 | development

このブログは「何か書きたい」というのと「色々試したい」という欲求を満たすために今年の一月に始めたわけだけど、その「試したい」ことの一つが「はてなブックマーク(以下はてブ)」だった。

自分自身はブックマークとしては delicious を使っているのだけど、はてブもRSSで人気エントリのものはなんとなく読んでいるし、twitterでも、はてブが元の話題がそれなりに流れているし、影響力がそれなりに強いように思う。

それで、 前回の記事 に、たくさんのはてブを頂いたので、ちょっとアクセス数を出してみる。

また、同じように、今、旬なtwitterからのアクセス数も出してみる。タイトルの"761 ツイート"ってのは、twitter公式の Tweet Button で表示されてる数。

visitor数 (Google Analytics調べ)

トータル はてなブックマーク経由 はてなトップ経由 twitter経由
19日 12,261 3,059 1,336 710
20日 7,465 2,497 51 395
21日 1,670 234 18 96
22日 704 90 0 32

記事を投稿したのが19日で、普段のvisitor数が数百なので、どかーんと増えてだいたい丸3日で正常運転に戻ったようだ。ほとんどが、はてなブックマークのトップページ(人気エントリ)と、はてなのトップという掲載期間のあるものだから当然か。

twitterは自分が想像していたよりも息が短く、同じように丸3日ぐらいでブログへのアクセスもほとんどなくなり、自分宛のmentionもほとんどなくなった。もちろん、記事の内容や質によってはもっと後を引くこともあるんだろう。

もちろん、リファラーからの分析なので、専用クライントとか、RSSリーダからのものは入ってない。特にtwitterはそういうのが多そうだなあ、と想像はできる。

数字的には、正直なところ、まあこんなものか、という感じ。もう数倍くらい多いのかなと勝手に妄想していた。

ええ、普段はB2BのWebのお仕事なのであまりこの辺の分析をしたことがない。そろそろ勉強しないとね。

おまけ – そのアクセスによって:

followers/subscribersの増加

  • twitterのfollowerが+100
  • Google Readerのsubscribersが+116
  • livedoor Readerのsubscribersが+53

ネットワーク使用量: 1.85GB

このブログで使ってるVPS の契約は月間100GBなんでしばらく平気そう。

はてブのコメントへの感想

コメント は基本的に「共感できる」と「勉強になる」とが大部分だった。感想文/反省文なんで、あんまり叩かれることもなく静かだった。

IE6だと化けるよ、について

直した。content-typeのヘッダーにtypoがあったorz

IE/Firefox/Chrome/Safari/Opera/w3m 辺りの最新版ではたまに確認しているのだけど、IE6とかもう仕事だけで勘弁してよ! ってのはある。

また、このブログでのIE6は、通常時で0.7%くらい。今回の一時的にアクセスが多かったときで1%ぐらい。こういうブログでまだ1%弱いるってのはほんと驚き。

それでは、静かに戻ったこのブログを今後もよろしくー。