The most important time in history is, NOW, the present

2009年の年末、渋谷から六本木に向かうバスでこのエントリを読んだ。

Retrospect 2009 – 慢性的アテンション断片化/アンビエント・インティマシー/『罪と罰』をめぐって « IA Spectrum

自分の目の前にあるもの、自分が手にしているものと、ちゃんと関わっているかどうか。

今という時間を、自分がどのように体験しているのか。

読んでいる途中、視界に入ってくる六本木通りの街路樹の緑色の感触と師走の雰囲気に、これが体験の存在だな、と理解した瞬間を今でも克明に覚えている。

2009年の年末といえば、最初の転職から1年、プログラマーとしてやっていける手応えを掴みつつある時期だった。 当時に比べると、僕自身の生活をとりまく要素は圧倒的に増えた。忙しさにかまけて、「今」という時間を体験する事はほったらかしだったように思う。

昨日、歩いている時に空を見上げた。1月というのに春のような陽気だけど空は冬らしい濃い青色、高速道路の高架の白いフェンスと青のコントラストが鮮やかで、「今」という瞬間がくれるご褒美のような光景だった。

「今」のことをまだすっかり忘れてしまったわけでは無いようなので、ちょっと安心した。

タイトルはTalib Kweliの名ヴァースより。

This was posted 8 months ago. It has 1 note.

週末にプロジェクト管理はしない。けどプログラミングはやっている

最近、プロジェクト管理やミーティングへの出席など、いわゆるビジネス寄りの仕事がだんだん多くなってきた。別にプログラミングをするために今の会社に入ったわけじゃないので(仕事をするために入りました)いいんだけど、ふと気がついた事がある。僕は週末にプロジェクト管理はしない。けどプログラミングはやっている。

これは大発見だった。 この熱が醒めないうちはコードを書くんだろうな。

This was posted 10 months ago. It has 3 notes.

QuipperでHTML5アプリを作ってる話

9月からQuipperという会社で働いています。 今日はリリース前というのに同僚がすごい勢いでブログエントリを書いている。

同調圧力に負け、僕も書くことにした。

最近、いわゆるHTML5アプリ(HTML+CSS+JavaScriptのクライアント)を作った。もうすぐリリース。 そこで色々新しいテクノロジーを使ったので、私見を交えつつ簡単にご報告します。

Chaplin.js

素のBackboneだと、ブートやインスタンス管理の仕組みを作るのが面倒。ここ一年でそれっぽいものを2度作ったので、もうやりたくなかった。 Chaplin.jsはレールがひいてあり、インスタンス管理も行き届いてる。 Brunchで雛形つくれるのもよかった。

ChaplinはmediatorというApplicatin wideなメッセージングシステムがある。ViewとModelの通信などで大変便利。しかし、これは可読性を一気に下げるえげつないgoto文になるのでほどほどにすべき。

Brunch

今回のクライアントのコードは、最初はAPI用のRailsアプリにassetとして載せていた。あるときこれをやめた。理由は重いのと、CommonJSがそのままだと使えないこと(ChaplinはCommonJSかRequireJS必須)、あと、本質的じゃないこと。RailsはHTML5アプリ(この呼称間違ってるからやめたい)のアセンブラーではない。GruntにするかBrunchにするか悩み、Chaplinと相性のよいBrunchにした。

テスト

テストで使ってるライブラリはphantomjs, mocha, chai, sinon, fakerなど。 こんな感じのci用のスクリプトを用意してる。

#! /bin/sh
set -e

export BRUNCH_ENV=ci
gem install sass --install-dir=./gems
gem install compass --install-dir=./gems
npm install brunch
npm install mocha-phantomjs
npm install bower
npm install

./node_modules/bower/bin/bower install
./node_modules/brunch/bin/brunch build

./node_modules/mocha-phantomjs/bin/mocha-phantomjs public/test/index.html

その他

CoffeeScriptは当然採択。生JavaScriptはきつい。underscore.jsとリスト内包表記でバリバリとリスト操作してる。

テンプレートエンジンはHandlebars、これはHaml系に慣れてないメンバーが多かったから。今考えるとHaml、Jadeなど閉じタグの無いものにすべきだった。Handlebarsはやはり冗長で生産性低い。タグの閉じ忘れにも何度か苦しめられた。

データバインディングはbackbone.stickit。信頼のNew York Timesプロダクト。使いやすく便利なんだけど、APIや仕様との相性の都合もあって、ちょっとしか使ってない。

CSSはScssで書いた。BEMなどのメソドロジーは使ってない。色は _colors.scss 内に書いた変数で管理、ボタン用のmixinを使うなど、よくある感じです。今考えるとTwitter Bootstrapを使えばよかったと思う。

jQuery.Deferredを多用した。パフォーマンス向上、可読性アップ、描画タイミングを揃えて見栄えを良くする、画像先読みなど大活躍だった。

フロントエンドのライブラリはbowerで管理。ただfont-awesomeなど例外はある。

まとめ

Chaplin.jsはなかなか良いです。もう素のBackbone.jsは書きたくない。

API*2 + clientを一度に動かすrake taskとかも書いたので、いつか紹介したい。まじ辛かった。

個人的にはそろそろWeb API書きたいなーとも思います。

あと、プロジェクトの合間にHaskellでbundle gemgrunt init的なことをするhiってライブラリを書いたので、試してみてね!

エンジニアも募集してるので、面白いなーと思ったら、こちらまでご連絡ください。

This was posted 12 months ago. It has 7 notes.

Quipperに入社しました

Quipperに入社しました。がんばります。

This was posted 1 year ago. It has 3 notes.

開発ツールの模様替え

夏なので涼しい色に変えました。Solarized lightだったんだけど、何か涼しさが足りないなと思い。

ターミナルはHemisu。背景はグレーに変更。

VimはPyte

This was posted 1 year ago. It has 6 notes.

すごい!rspec-somethingがあれば、メール送信のテストが2行も短くなる

Ruby on Railsでメール飛ばす時、みなさんテストはどうしてますか? 僕はこんな感じでした。

アプリケーションのコード

UserMailer.hello(current_user).deliver

テストコード

mail = double
mail.should_receive :deliver
UserMailer.should_receive(:hello).and_return mail

やってること大したことないのに何か長ったらしいですよね!

ということで短く書くためにrspec-somethingって小さいライブラリを作りました。 「一個だけメッセージを受け取ること」を検証するtest doubleを返します。

require 'rspec-something'しておくと、さっきのspecがこう書きます。

UserMailer.should_receive(:hello).and_return something.deliver

便利ですね!

RailsだとMailerが一番のユースケースだと思います。

SomeAction.should_receive(:build).and_return something.perform! って感じでService Object的なものにも使えそうですね。

メッセージを受け取らない事を検証することもできます。

UserMailer.should_receive(:hello).and_return something.won_t.deliver

本当はsomething.deliveredと書けるようにしたかったです。あとrspec-mocksの機能でカバーできそうな気もしてます(調べてません)。実装は楽しかったです。

それではHappy test-doubling with rspec-something!

This was posted 1 year ago. It has 1 note.

タオルについて

僕はタオルが大好きです。乾燥機から出したての熱いパッサパサの感じも好きだし、ちょっと水を吸ってしっとりした時の感触も好きです。

最近、気分転換したいなーと思って家のフェイスタオルを全部交換しました。

アメリカのホテルの定番とのこと。日本のタオルに比べて圧倒的に肉厚で密な感触です。フワフワ感を求める人には好まれないかもしれません。しっかりした感触を求める方にはたまらないと思います。サイズは日本のフェイスタオルより一回り大きめ。僕はすっかり気に入りました。

This was posted 1 year ago. It has 0 notes.

技術系カンファレンスでポルノの話題はやめよう

今のところ、プログラミングに関わる人の多くは男性です。この偏ったバランスを改善するため、世界中で様々な試みがなされています。

ところでポルノは多くの女性にとって心地良い話題ではありません。ある集団にとって不快な話題をコミュニティが許容することは、その人達を一人前の成員として認めてない事と同じです。

ということで、技術系カンファレンスでポルノの話はやめましょう。

This was posted 1 year ago. It has 6 notes.

頭の中は映画のスクリーン

「…おれはな、人間の頭の中は映画のスクリーンだと思ってる。もしおまけがどうしようもないマヌケだったら、おまえはただ席に座って、頭の中をしっちゃかめっちゃかにする、くだらねえ馬鹿げた映画をそのスクリーンに移して観てるだけなんだ」

そして彼はこうもいった。「なあぼうや、よっぽどのばかじゃない限り、自分を苦しめたり自分の長所を鈍らせたりする映画を、そのスクリーンで上映する手はないぜ。なんだかんだいったところで、おれたちみんな一人ひとりがその映画の支配人で、自分の頭の中で映画を映してるんだ。脚本も自分で書いてるんだぜ。どうせ書くんなら、常に前向きのダイナミックな脚本を書いて、自分にとって最高の映画をそのスクリーンで上映するこった、お前がピンプだろうと司祭だろうとな」

p.72, アイスバーグ・スリム『ピンプ』

This was posted 1 year ago. It has 3 notes.

これからプログラマーになる人にオススメの、あまりオススメされていない本

新年度ということで、色々な人が若いプログラマーの皆さんに大量の本をオススメしています。そこで僕もオススメをちょっと紹介してみます。

「役立つ技術書」という観点だけでなく、どれも一人の本読みとして「いいな」と思える本です。どの本も前提知識は一切要りません。

『思考する機械コンピュータ』

一般向けの本です。この本の前半で論理回路、有限状態機械などコンピュータの基礎が学べます。平易でわかりやすく、かつ骨太です。これが何の訳に立つのか?って思うかもしれませんが、原理を知ると応用のスピードは上がります。

『The Little Schemer』

一問一答の対話を通じて、ラムダ計算のこと、再帰、リスト操作の定石などが学べます。そう言うと難しそうですが、ほとんど何の前提知識も要りません。 『Scheme手習い』という邦題で翻訳も出ていますが、僕は原書で読むことをお勧めします。平易で、読んでて楽しい英語です。

『はじめて学ぶソフトウェアのテスト技法』

テストの手法と、テストとは?が書いてあります。恐らくソフトウェアを書くことに比べて、テストのやり方については学ぶ機会が少ないと思います。早い段階で定石を学んでおくと生産性は高くなります。読みやすく実践的、妙なユーモアもある素敵な本です。

最後に

僕はお昼休みは一人で本を読んでいる事が多いです。世の中は思うようにいかず、辛いこともあります。そういう時は小説を読むと良いです。昼休みの1時間の間でも、うまくいかない世界から小説の世界にワープすることができます。アドバイスをくれることもあるし、自分のいる状況を俯瞰する眼をくれることもあります。進むべき道に悩んだら読んでみてください。

This was posted 1 year ago. It has 7 notes.