札幌市西区

そういえば、社会人になってましたとかさえここに書いてなかった気がする。懸命に働いてました！(過去形)

ご連絡

19:14 |

2011/09/15 付で現在のお勤め先を退職することになりました。おつかれさまでした。ありがとうございました。

2011/09/09 が最終出社日なので、ここを利用してご連絡ということにさせてもらいます。

振り返ると、本当に無茶苦茶いろんなことを学ぶことができました。働くということ。成果を出すということ。プログラミングをするということ。「ものづくり」をするということ。チームを育てる、チームで立ち向かうということ。サービスを立ち上げ、続けるということ。

RubyKaigi へのスタッフ参加など社外の活動にも理解をしてくれて、本当に本当に、いろんな機会を得て、いろんな経験をさせてもらいました。

就職する前から関わらせてもらっていた会社なので離れるのはそれなりに感慨深いです。いまの会社が進むべき方向と、自分が自分の成長のために進みたい方向を吟味して、決定をしました。

"Love it or Leave it" は二者択一じゃないだろうし、これが今生の別れなはずもなし。応援しています。がんばります。

さて、

次、というはなし。少なくともひと月ふた月くらいは「どこにも属さない」というのをやってみようかなと思ってます。いわゆるフリーランスという形なんでしょうか。どこにも属さないのをいいことに、いろんなものを見たい知りたいという感じです*1。

「ちょっと話きいて」「話きかせて」「説教させろ」等々ありましたら、ぜひお声がけください！

まとめ

がんばります。ひきつづき、よろしくお願いします。

夏が過ぎ去る。

WEB+DB PRESS で Ruby の連載をしています。

ruby | 19:26 |

いま出ている最新のは Vol.64 ですが、前号の Vol.63 から「Rubyわくわくナビ」という連載を @june29 と担当させてもらっています。

Vol.64 ではじめて自分の記事が出たのでご紹介宣伝エントリ。

june29 の連載一回目のエントリはここ。

WEB+DB PRESSにてRubyの連載がはじまりました - 準二級.jp

Vol.64 のご紹介

「Railsでサクサク作るTwitter／Facebookアプリケーション」と題して、Twitter/Facebook 連携アプリを Ruby on Rails で作る、というのを書きました。"rails new app" から始まり、OmniAuth 経由で OAuth 認証をし、取得した OAuth で投稿するまでを解説しました。

「OAuth は知ってるけど、実際なににどうやって使うの？」という疑問や「Rails で Twitter 連携するなら OmniAuth がいいらしいけど、調べる手間がなぁ」という方に、まるっとさくっと理解できるサンプルアプリとして読んでもらえると嬉しいです。

良い道具を知ることで発想が広がり、新しいモノがどんどん出てくる一助になれば嬉しいです。

今回の記事で作ったアプリはソースコードを公開しています。参考にしてみてください。

wdpress11rb/intr - GitHub

記事のレビューを @hsbt さんにお願いしました。ありがとうございました！実際にアプリを動かすときにハマリそうなところ、セキュリティで気をつけたほうがよいところなどを指摘してもらい、見落としていたところを的確に拾っていただきました。

タイトル裏話

自分たちで出したタイトル案はまるっとお蔵入りしたのでひとつご紹介。

いちばん最初に出てきた案は "Ruby.enjoy!" でした。短かすぎたのが敗因かなー。

次号！

たぶん @june29 先生による、Ruby 界隈の最新技術動向が読めるはずです。

次号 Vol.65 もお楽しみに！

ぐでーっとだけどかいた。

RubyKaigi2011でした

ruby | 01:33 |

ここで得たなにか文章を残すことはとても大事に思うんだけど、文章にするのがとっても大変です。

あと、これはわたしのブログなのでですます調とかぐちゃぐちゃだよ。

わたしと RubyKaigi (事実ベースのこと)

RubyKaigi2008

(これ以前はRubyKaigiに関わりがなかった。Ruby札幌のひとたちからお話を聞いたくらい)

• RubyKaigi2008(つくば) に、上京して行きやすくなったので参加した。札幌でお世話になった方と再会できた。(谷口先生の結婚お祝い寄せ書きを書いた覚えがある)

RubyKaigi2009

• RubyKaigi2009(東京) の2ヶ月前くらいにしまださんから、gihyo.jp での当日レポート係を june29 と担当しないか、というお誘いが来た。
• レポート班として RubyKaigi2009 の直前レポート、当日レポート3日間、開催後の運営委員長のかくたにさん (と偶然居合わせた実行委員のしまださん) インタビューを記事にした。
  • ふりかえると、インタビューに同席できたのは、RubyKaigi とそれを通して Ruby に関わるうえで大きなキッカケだった気がする。

RubyKaigi2010

• TokyoRubyKaigi03 のときに、しだらさんとかくたにさんから、RubyKaigi2010 でコミュニケーションデザインを実行委員としてやらないか、というお誘いが来た。
• 2009 のレポート班の体制では 2010 は乗り切れないとおもって、takkanm さん、sugamasao さん、ukstudio さんを仲間に誘った。
• コミュニケーションデザイン班というのを june29 と組織した。
  • サブスクリーン用に Web アプリを作って、Chrome で全画面表示したらいけるんじゃない？というのを作った。norio さんのデザイナーズコミットでぐんとよくなったのがうれしかった。
  • 会場が広かったのでやりたいことをいろいろやった。書道とか。
• 撤収のことを考えてなくてドタバタになっちゃった。

RubyKaigi2011

• 「2011 は最後の RubyKaigi」というのを初めて聴いたのはいつだったかなぁ。2010 のための KaigiKaigi を開いていたときだったような。
• たしか RubyKaigi2010 最終日のスタッフ打ち上げのあと、帰りのつくばエクスプレスの中でかくたにさんから「(スタッフは)来年どうする？」って言われた気がする。やりたいです、と即答した気がする。
• レポート班は t, s, u の三人にお任せすることにした。さらに oshow さん、hokkai7go くんが参加してくれた。自分たちが名前をつけて作ったものをさらに良いものにつなぐことができたのは、とても良い体験だった。
• さらにコミュニケーションデザイン班としてコミットをした。
  • 2010 のサブスクリーンがすでに「ふつう」になってて (tenderlove キーノートのサプライズのときも、事前に「翻訳やめてっていうからやめてね！」と言われてて、「翻訳サブスクリーンある前提で話が進んでる...!」とおもった) うれしかった。
  • 2011 では、Twitter ログをどっさり記録したり、システム全体を Rails で書いたりした。当日 JS 周りでバグっぽい挙動に遭遇したりしたけど、2日目にはどうにかパッチをあてた (翻訳サブスクリーンが白い画面になってたのを見たとしたら、それは裏でバグ取りをしていた証)
  • 会場は昨年より自由に使える場所が少なかった。けれど、昨年の経験から、「事前に決めすぎない。現場で作ったほうがよいものになる」というのの見極めが出来た気がする。
  • 現場でかくたにさんと会場設計をしたときの「こっちから人が流れるから、(身振りで)こういう流れをつくる。そうすると机はここに来る」というのを見ていて、設計力を感じた。
• 今年はコミュニケーションデザインからもう少し手を伸ばして、物品まわりの手配もはがすことができた。
  • トランシーバ、喫茶飲み物、会場物品、文房具小物など、まるっと情報を集約できたのはある程度良かった気がする。
• 2010 での懸念だった、撤収もうまいことこなせた。撤収前にウォークスルーができたのがよかった。計画重要でした。

わたしと RubyKaigi (スタッフのこと。あるいは感謝について)

実行委員、当日スタッフのかたがた

RubyKaigi 最終日の撤収のあと、高橋会長の最後の挨拶のあと、かくたにさんの「解散！」という声で、3日間と数ヶ月のチームは解散したのでした。

某 Anonymous Diary の方と同様に「あまりにも個人的なメッセージ」になってしまうので、それぞれお会いしたときにお話ししたいです。

ちょっとだけ名指しさせてください。

現場棟梁のかたがた

「現場棟梁」という名前が実にしっくりくる、現場を支える屋台骨のみなさまでした。現場棟梁分科会を繰り返し開けたのが、今回勝つるに至ったポイントだったかなと振り返っています。ありがとうございました。

たなべさん、あづみさん

今回、物品まわりや会場の撤収作業で、ほんとうにたくさん助けられました。おふたりがいなかったら自分はめちゃくちゃテンパってたとおもいます。ありがとうございました。

KaigiFreaks レポート班のみんな t, s, u, o, h

おつかれさまでした。ここのみんなは年齢も近いので、単純に友達なんですよね。それがうれしいです。

ZoAmichi くん

いきなり名指しするけど、フロアマップに手を挙げてくれたのは本当に嬉しかったのですよ。ありがとう。

しだらさん

ほんとうにいろいろな場面でお世話になりました。今年はある程度うまくやれたんじゃないかとおもっています。ありがとうございました。

高橋会長、かくたにさん、しまださん、ささださん

ほんとうに、おつかれさまでした。ありがとうございました。

参加者のかたがた

今回、何人かのかたに「ぜひ RubyKaigi 来てみてください！」と無茶な誘い方をしていたのだけど、無茶を承知で誘いたいくらい RubyKaigi に参加することに良さがあると思えていました。そんなお誘いに乗っていただいて参加してくれて、なにかを得られたのならとてもうれしいです。

会場でお会いできたみなさん、忙しそうにしちゃっててごめんなさい。もう少し余裕をもてればよかったです。

参加したみなさん(あなたですよ)、ありがとうございました。

わたしと RubyKaigi (スピリチュアルな感じのこと)

Kaigi

RubyKaigi に contribute したことで、「Kaigi 的ななにか」が潜んでいることに気づいたんです。文化祭的なノリが合う人合わない人いるだろうけど、なんでああなるかというと、事前に作っている人たちも楽しくなっちゃうからだと思う。「今回、夜の部も借りれることになったけどどうしようね？」「"夜のRubyKaigi"やる？」「"闇"にしようぜ！厨二っぽい！」みたいな、大人げない大人が全力で楽しむとああなる、っていう。楽しんでもらうのが楽しいから、世界地図とか寄せ書きとか全力でつくっちゃうし、当日レポートだけじゃなくて事前レポートやしおりとかまで準備しちゃう。

文化祭的なノリが内輪ノリなんて言われちゃうのかもしれないけど、「みなさんにキチンと楽しんでほしい。それが楽しい。そう思いませんか？」という思いのコミュニケーションの齟齬なのかなとおもう (コミュニケーションは伝送路と伝送路の両端の問題です)。

「楽しいのも楽じゃない」のがちょっとむずかしいところなのですが。現実は目の前にある。

Ruby

2011 では例年に比べて「楽しいRuby」への参照が多かった気がする。まつもとさんのキーノートの大人げなさも、実に楽しそうだった。

とはいえ、自分自身は Ruby への contribute はしていない(し、言語よりもサービス寄りのレイヤーに興味がある)。でも、Ruby という道具はよく手に馴染んだし、Ruby のおかげで様々なものや文化を知る手がかりをもらった。Ruby を手にしたとき、モノリスに触れていたのかもしれないなあ。

RubyKaigi

Ruby と Kaigi を分けたのは、たださんの日記にもあったように、今年の RubyKaigi に参加していた人の間口がどーんと大きくなって「プログラミング言語 Ruby」とちょっとずつ離れ始めているのかもと感じたから。「プログラミング言語 Ruby」の根幹の話は正直いって難しいです(そんななかで ennnnd はすごいとおもう)。

そう感じたんだけど、会期が終わって整理していくと、RubyKaigi はやっぱり(あたりまえだけど) Ruby のことを Kaigi する場所なんだなぁとおもった。「Ruby って楽しい。そう思いませんか？」という問いかけを発していたんだろうなあと、勝手なことを言っておわりにします。

歌詞に時代を感じてしまいますね。

"1/2" というサービスを作ってた24時間くらいのはなしをします

04:40 |

4/22から4/23にかけての24時間、クックパッド主催の「第2回 開発コンテスト24」というのに参加しました。

• エンジニア向け「第2回 開発コンテスト24」開催 | クックパッド株式会社

がいよう

「半径3メートル以内の世界でもっと もっとひっついてたいのさ」というコンセプトで、ブラウザのタブをみんなでリアルタイムに共有するというサービス、"1/2 Real-time Tab Sync" を作りました。

• 1/2 - Real-time Tab Sync

作ったサービスの解説もあるけどそれより何より、つくっていた24時間がとても楽しい時間だったので、わたしが「第2回 開発コンテスト24」をどのように過ごしたかをメインに紹介します。

一緒に作ってた @darashi さんと @june29 さんもまた別の視点から同じ24時間を記録してくれていて、神の視点的に眺めると面白いかもしれません。最後に書く特権で、ところどころふたつのエントリの内容に委譲するよ。

• 半径3メートル以内の世界でもっともっとひっついてたくて「1/2」をつくりました - 準二級.jp
• 「できればいいのに」が現実になる場所: 1/2 Real-time Tab Sync の開発に混ぜてもらいました - dara日記

4/22(金) 21:00くらい 「着席しています」

金曜の21時くらいはふつうにお仕事でコード書いてました。

ふと Twitter を見るとフォローしてる何人かの発言から、クックパッド主催のコンテストが開催されてるとのこと。24時間でなにかプロダクトを開発するというこのコンテストについては、去年のレポートを見たことがあって覚えてました。開始と同時にテーマが発表されるのもあって、わたしのタイムラインでは何人かが発表されたテーマについて盛り上がってました。

発表されたテーマを見て、「普遍的でかつ個人的で、流石の設定やなー」とか思った覚えがあります。

課題:

（普段の生活で）半径3m以内にいる人が困っていることを解決する

エンジニア向け「第2回 開発コンテスト24」開催 | クックパッド株式会社

のんきに(お仕事しながら)小ネタつぶやいたりしてました。

http://twitter.com/kei_s/status/61400866330128384

そしたら @masa_edw さんがお題に対してほぼ満点ともいえる tweet を...!!!

http://twitter.com/masa_edw/status/61405935364616192

川本真琴好きとして思いつくのに遅れをとってキークヤシー！とか思いながらお仕事を終えて23:00前くらいに帰路についたのでした。

4/22(金) 23:00くらい 「帰路にて」

会社からの帰り道も @masa_edw さんの才能に嫉妬しながら、ぼんやりとコンテストについて考えていました。半径3m以内のひとかー誰がいるかなーと考えていたら、先の @darashi さんのエントリにもある、ペアプロの光景を思い出しました。そのとき感じた「screen だけじゃなくてブラウザも同期できればいいのにね」は、半径3m以内の人(ほんとは札幌と東京で800kmくらいあるんだけど)が困ってることだな、と思い当たりました。そこでもう少し具体的に考え始め、全体の設計をしてみました。

• WebSocket で通信して、複数のブラウザをほぼリアルタイムに更新することができないかな
• カーソルの軌道を WebSocket で通信して描画するのもよさそう。(@ursm さんの通称「ホータルサイト」に憧れて)
• WebSocket なら Node.js (+ Socket.io ) つかってみたい。Node.js ちょうたのしそう
• Google Chrome 拡張機能を使えば、片方が更新したらそれを検知してサーバに送信できそう。Chrome 拡張から WebSocket を使うのは buzztter の Chrome 拡張 で既に出来ているらしい

という感じで、Chrome 拡張と Node.js を触れるプロダクトにしようと考えました。

さらには

もっともっとひっついてたいのさ (タブが)

とワードが浮かんできて、これはやってみる価値がありそうだ*1、とおもいました。

4/22(土) 0:00くらい 「手遊び」

とはいえ Chrome 拡張を作るのは初めてのことでした。まずはチュートリアルを見つつサンプルを作るところからスタート。Chrome 拡張自体の開発のしやすさもあってサンプルはすぐにできました。

つづいて実際に "1/2" としてのコードを書き始めました。起動ボタンとしてアイコンを出す方法、JS を拡張のバックグラウンドで走らせる方法、バックグラウンドのコードからブラウザの描画部分との通信(Chrome の独特の実装でとっつきにくかった)など、ひとつひとつ調べながら潰していきました。

実際のところ、コンテスト自体にはあまり思い入れがなく*2、「コンテストを名目に、勉強も兼ねて遊んでみよう。どっかで少しでもつまづいたらそこでおしまいにしよう。最悪でも(順調に行っても)土曜日が拘束されるまで。日曜はなにしようかな*3」という具合で始めてました。なので、このあたりの初期の段階で詰まっていたら、"1/2" は、いくつもある書きかけプロダクトのひとつになっていたと思います。できてよかった。

拡張側に WebSocket 通信がのっけられた段階で、バックエンドの Node.js を書き始めました。バックエンドのお仕事は通信を横流しするだけだし、Socket.io は既に触ったことがあったのですんなり。

4/22(土) 4:00くらい 「大ハマリだ！」

この時間くらいになって Chrome でタブが更新されたら WebSocket に投げる、という部分を実装し始めました。詳細は省きますが Chrome 拡張のタブアップデート周りに大ハマリしてました*4。イベントリスナとメッセージングの仕組みがこんがらがってだんだんヤラれてきたので、6:00ごろ睡眠デバッグに任せて寝ることにします。JS 力が足りなかった...!

4/22(土) 12:00くらい 「ご確認のほど、よろしくお願い致します」

睡眠デバッグの成果はというと、綺麗とは言えないものの、どうにか実装できるコードが出来上がりました。タブの更新を WebSocket で Node.js に流して、Node.js がほかのクライアントに投げる、という部分を作ったあたりで、ふと感じました。

このサービス、Chrome が複数ないとテストできない...!

13:00くらいまで Twitter も見ずにひとりで作業してたのですが、某IRCにいるだろう @darashi さんと @june29 さんを釣るべく覗いてみるとふたりでネタ出しをしてたので

13:05:47 >kei-s< やってるよー

13:05:53 <june29> なんと

13:06:03 >kei-s< けっこういいとこまできた

13:06:10 <june29> いいねいいね

13:06:55 >kei-s< 3m 以内のペアプロ相手に、skype 経由で URL 送って開いてもらうとか面倒なので、タブを sync させましょう

13:07:07 >kei-s< chrome extension + node.js

13:07:14 <june29> おおお

ということで @june29 さんにテストにつきあってもらいました。

Skype 通話をしながらテストをしてると、これはかなり面白い体験だというのが分かってきて、テンションがあがってきました。テスト用に使ったURLは cookpad.co.jp で、関係者の皆様本当にすみません。

そうこうしてると @darashi さんも IRC にいらっしゃったので即座に Skype をつなぎました。

さあここからはチーム戦。

4/22(土) 14:30くらい 「いつものかんじだなぁ」

まずはここまで自分だけで育ててた git リポジトリを github に置き二人を招待、コードを見てもらいます。その後はすぐに戦略会議。

「リリースまでに必要なことはなんだ？」

• ルーム機能の実装 (この時点では接続した人がすべて同じタブを共有してた)
• バックエンドのデプロイ先とデプロイ手順の確立
• Chrome Extension の配布方法
• サービスの顔のフロントエンド、利用方法の説明

二人の担当した部分は先のエントリにあるとおり、わたしはデプロイと Chrome 拡張側のルーム機能を作っていきました。全員自宅にいて(東京は雨がひどかった)Skype で話しながら、「Github に Push しましたー」「Pull しております」「Pushed!」「Pulled!」などと話しながら、各々のやれることをやっていく、というふつうのやり方で、ひとつずつ作り上げていきました。途中、Skype の INPUT に川本真琴の曲を流そうと試行錯誤したものの設定に手間取って叶わず、というのもあり。

4/22(土) 19:30くらい 「keep ( product.shippable? == true )」

残り1時間半。このあたりになると大体の実装ができてきました。この時間からのキーワードは「shippable? (出荷できる？)」。大きな機能追加は出来なさそうなので小さな機能追加を作ってみるものの、上手くいかなさそうと判断したらすぐに戻して、常に「出荷できる状態」を保つ、というのをやっていました。このあたりは @darashi さんの「プロダクトにする力」だなーと感心してしまいます。

4/22(土) 20:30くらい 「醍醐味」

バックエンドのデプロイや拡張の登録などを行い、最後の最後、コンテストへの登録作業に入りました。紹介文面を考える悪乗りタイムはサービスを作りきった醍醐味ですね。コンテストの中の人が吹いてくれれば万々歳でございます。

ブラウザとブラウザ 瞳と瞳と 手と手

同じもの同じ感じかたしてるの 愛してる 愛してる 愛してる

あたしまだ懲りてない 大人じゃわかんない

届かないって 言われたって このままジャンプしたい

4/22(土) 20:55くらい 「おつかれさまでした」

登録完了。いやはや結局作りきることができました。はい、おつかれさまでした。おふたりともいきなり参加してくれて、ほんとうにありがとうございました！

かんそう

今回は、わたしのサービス(と小ネタ)の思いつきから二人に参加してもらってサービスをつくりました。@june29 さんのブログや @darashi さんのエントリにもあるように、こんなふうに作ったサービスは実は初めてではありません。しかしそのどれも、誰かが「こんなんつくったんだけどさー」から始まっています。それは決して空想のアイデアではなく、拙いながらも「動くもの」を種にして、水を与え光を与え、育てているサービスです。

種を見せるには、手を動かす必要があります。頭の中を覗かせることはできません。いいアイデアが浮かんだとき、それを種として手渡すことができないと、誰も分かってくれません。いいアイデアだけが降ってきても、見せられなければ無いも同然です。種を作るためには、基礎体力をつけることが大事だと感じています。今回のコンテストに参加したのも、アイデアを見せつけたいという気持ちより、自分の基礎体力をつけるために触ったことのない技術に挑戦するよい機会だと思ったからです。どんなに良いアイデアでも24時間で作りきらなければいけない、逆に言えば、ドツボにハマりまくっても24時間で終わるということです。とってもよい企画だとおもいます。

いつ浮かんでくるかわからない、世界を変えてしまうかもしれないアイデアを大切にするためにも、少しづつでも出来ることをふやしていきたいです。

ここからは後日談

4/23(日)

けっこう気を張ってたようで、ぐっすり寝てた*5。

4/24(月)

• 第2回「開発コンテスト24」受賞作品発表 | クックパッド株式会社

「特別賞」て、本当にびっくりしました。上のとおり、スタート時点では作りきる気持ちもそこまでなく、ダシにして遊んでたようなものなのですが、二人の参加のおかげで「プロダクト」まで作り上げることができました。ありがとうありがとう。

こっそり、渾身の紹介文が晒されたのが嬉しかったりもする。

まとめ

こんな感じで、充実した 4/22~4/23 の24時間を過ごすことができました。以下、謝辞。

• @darashi さん
• @june29 さん
• @masa_edw さん (あの tweet がなかったらスタートしてなかったでしょう)
• @ursm さん (ホータルサイトのコードを参考にさせてもらいました)

そしてなにより、

• 素晴らしいコンテストを開催してくれた、クックパッドのみなさま

本当にありがとうございました！

おまけ

川本真琴さんにもありがとう。last.fm の履歴が物語っています。

おまけのおまけ 6/8

第2回「開発コンテスト24」表彰式に参加して LT してきたときの資料を貼り付けます。

おまけのおまけのおまけ 6/8

と言われたのでコードを公開しました。private を public にする簡単なお仕事。

kei-s/onehalf - GitHub

macbook 新調記念に。

zsh のプロンプトに、各種 VCS のブランチ名表示と、git の変更を表示

zsh, git | 01:57 |

zsh の prompt に、svn やら git やらのブランチ名を表示し、git のときだけ変更点を(詳し目に)表示する zshrc の設定を、いろんなものを参考に書きました。

コードは最後の方にあります。

こんなかんじになる

• ブランチ名を右側に表示

• git add した直後

• 変更があるとき

• untracked なファイルがあるとき

• 組み合わさっているとき

ファイルの削除・リネーム、unmerged なファイルの場合の表示もある。割愛。

参考にさせてもらったところ

基本的には id:mollifier さんの、zsh で Git の作業コピーに変更があるかどうかをプロンプトに表示する方法 - ess supを参考に、zsh の vcs_info を使っています。上の例がゴテゴテしていると感じる方は、リンク先のほうがスッキリしていてよいでしょう。

調べているうちに oh-my-zsh で git の細かい変更点を表示している例があったものの、それだけのために oh-my-zsh を導入するのは大きすぎると感じたので、うらやましくなって git の変更点表示部分を参考にして、そこだけ書きました。

コード

こんなかんじ。git コマンドを実際に投げてるので重いと感じることもあるかも。自分の macbook ではそんなに感じませんでした。色などお好みで変更するとよいでしょう(といいつつそこまで変更しやすくできてない)。

.zshrc at master from kei-s/dotfiles - GitHub にわたしの使ってる .zshrc があるのでそちらも参考にどうぞ。rvm のバージョンを表示をしたりもしてます。