少し間があいたけど、今年のRubyKaigiについてつらつらと書こうかな。

スタッフ参加してみて

今年はスタッフとしての参加だったのだけれど、RubyKaigiのスタッフは東京RubyKaigi03の時にやっただけなので、本家の方は初めて。3日間と結構な長丁場なのでうまく立ち回れるか不安だったのだけど、自分なりにはそれなりに頑張れたのではないかなと思う。

ひとつ前のエントリでも書いたけど、担当はレポート班でした。当日スタッフに応募する前はrubykaigi.orgの制作・実装の方も手伝っていたけど、実質ほとんど何もしていない・できなかったのでスタッフとしては90%ぐらいはレポート班な感じ。

レポート班はある意味発表を見るのが仕事みたいな部分もあったし、文章を書くのも割と好きなので、RubyKaigiを楽しみつつ仕事も楽しむという割とおいしい感じに過ごせた。自分の語彙の少なさや英語力のなさなど色々と痛感した部分もあるけど、楽しくやることが出来ました。

今年は開催が筑波ということで、スタッフの大半はホテル山久(#hotel39)に泊まったわけだけど、本当に楽しかった。#hotel39_107 の楽しさは異常である。あの感じはなんだったんだろうなぁ。

実はChad Folwerの基調講演と高橋さんのclosingから、色々な想いがまざって泣きそうになってた。未だにその時の気持ちが整理できていないのだけど「Chadに励まされてる感じ」「今年のRubyKaigiが終わる感じ」「来年でRubyKaigiが終わる感じ」「3日間の疲れ」あたりの気持ちが色々と混ってよくわからない感じになったのだと思う。

元々、この手の技術系カンファレンスは情報を仕入れに来てるタイプだったので、まさか泣きそうになるとは自分でも意外だった。多分、一般参加してそうなるとは思えないので、やっぱりスタッフとして参加したのが大きかったのかなと思う。

来年のRubyKaigi

最後のRubyKaigiと言うことで、自分なりに何を成し遂げたいか簡単に書いておく。

ひとつは発表者として参加すること。やっぱりあの場で話すのは一種の憧れみたいなものがあるにはあるので、それを憧れで終わらせない為にも何か話したい。一応話してみたいことはちらほらあるので、1年あれば十分まとめられるはず。

あとは、書き始めてるアレを間に合せたい。あわよくばサイン会・・・実質、ほとんどまだ手が動いていないのでいい加減動かないとまずい。

最後はやっぱりスタッフ参加かなぁ。本当に終わってしまうのであれば、最後はスタッフとして見届けたい。

ところで僕の所属はKaigiFreaksレポート班なのですが、既にスタッフ業としてRubyist Magazine 日本Ruby会議2010直前特集号と、gihyo.jpにRubyKaigi2010直前レポートを一部書きました。まだ読んでいない方はぜひ読んでみてください。直前特集号の中にRubyKaigi2010参加者のしおりがありますので、参加者の方は明日以降のRubyKaigi2010に向けて目を通しておくといいと思います。

当日はgihyo.jpにて当日レポートを行います。このレポートはRubyKaigi2010スペシャルレポートに掲載される予定です。

そんなわけで、ちょっとしたレポート班の宣伝でした。会期中はレポートを書きながら会場をフラフラしてると思いますので、気軽に声をかけてくださいまし。ではでは、RubyKaigi2010楽しんでいきましょー。

mailtoをGmailにする

PCでGmailを使うにあたってメーラーを使わずWebで済ませていますが、その場合mailtoをクリックしたときに使ってもいないMail.appが起動してしまったりと困る場合があります。

その場合、Google Notifierを使うと便利です。Google NotifierはGmailの受信通知やGoogle カレンダーのリマインダ通知などをしてくれるアプリですが、簡易的なメール送信機能もありmailtoにそれを指定することができます。メーラーを使うほどでもないけど、通知とmailtoの設定ぐらいはしたいという時に便利なアプリです。設定は設定画面のAdvancedタブにあります。

複数のメールアカウントを1つのアカウントに統合する

実は普段使うメールアカウントを2つ程持っています。理由は元々Gmailドメインをそのまま使っていたのですが、仕事の都合上独自ドメインでも運用したくなりGoogle Appsで改めてアカウントを取得した為です。2つアカウントを持っているとそれぞれログインしなおしたりするのが面倒なので1つのアカウントに統合すると便利です。

とりあえず、普段使用したいアカウントをA、統合してしまいたいアカウントをBとします。

まず、受信ですがこれは単純に転送設定を用います。アカウントBでログインし、「設定」から「メール転送とPOP/IMAP」から転送アドレスを追加します。後は好みでアカウントBのメールはアーカイブするなり削除するなりすればいいでしょう。アカウントAでは一応わかりやすい用にアカウントBから転送されたメールにはラベルを付けるようフィルターの設定をしています。

次に送信です。実はGmailにはFromのアドレスを独自に設定することが出来ます。アカウントAの「設定」から「アカウントとインポート」を選び、そこにある「別のアドレスからメッセージを送信」を選びます。後は指示に従ってアカウントBのアドレスを設定します。これでアカウントAにログインした状態からアカウントBとしてもメールを送ることが出来ます。

同じく、「アカウントとインポート」から「メッセージの受信時」の設定を「メールを受信したアドレスから返信する」にしておくと返信の際にアドレスが変わってしまうということがなくなります。これでHT-03Aなどでも受信したアドレスで返信することが出来るようになります。

参考: 独自に設定した [From] アドレスの追加

ただ、GmailやGoogle カレンダーは複数アカウントに対応しはじめたみたいなので人によってはわざわざこういう設定をする必要はないかもしれません。ただ、僕の場合HT-03Aがアカウントの切り替えに対応しておらずしばらくはこの設定で運用することになりそうです。

グループに登録してある人にまとめてメールを送信する

Googleの連絡先には「グループ」という概念があります。グループに連絡先をまとめておくことで、まとめてメールを送信することができます。MLを用意する程でもないけど複数人数で話題を共有したいというときにちょっと便利です。

やり方は連絡先にグループを作り、そこに連絡先を登録しておきます。後はWebでメールを新規に書くときにFromの欄でメールアドレスと同じようにグループ名がサジェストされるのでそれを選択するだけです。後は自動的にメールアドレスが補完され記入されます。

参考: 連絡先グループのメンバー全員にメッセージを送信するにはどうすればよいですか。 – Gmail ヘルプ

ラベルをネストにする

Gmailにラベルという機能があります。ラベルはそれぞれ独立しており、そこに特に関係性はありません。しかし、Gmail Labsにある「Nested Labels」を使えば名前の通りラベルをネスト構造にすることができます。「設定」から「Labs」を選び「ラベルのネスト」(日本語版の場合です)を有効にし、あとは適切にラベルを設定するだけです。例えば僕の場合「ruby/ruby-list」「ruby/rubykaigi」と言った感じでラベリングしています。

ただ、紹介しといて何ですがそんなに便利でもないかなーというのが正直なところです。ですが、サイドバーのラベルが折り畳めるようになるのでラベルの数が増えてきて整理したいという場合にはそれなりに便利なのではないかと思います。

僕がここ最近ずっと「コードはきれいに書くべき」「読みやすいコードを」と言い続けています。16日のオブラブの発表もそうですし、WEB+DB Vol.56の記事もそうです。

ただ、僕が話すメリットも基本的には開発者側の視点です。もちろん、開発者がメリットを享受した結果、顧客にも何らかのメリットはあります。(バグが減る、仕様変更のコストが減るなど)

とは言え、「コードをきれいに書ける」と言うのは「自分自身が書こうと思ったものを書ける」と言うことでしかないとも思うわけで、それはつまり「自分の脳内で思い描いたソフトウェアを具現化する」能力とも言えるのかなと思います。

じゃあ、仮に「顧客が思い描いたソフトウェア」と「開発者が思い描いたソフトウェア」でズレがあった場合はどうでしょう。当然そこに価値はありません。(価値が0とは言いませんが、理想よりは少ないことは確か)

更に言うと、「顧客が思い描いたソフトウェア」が顧客にとって本当に必要なものだとは限りません。

結局のところ、顧客に対して価値を提供するには「きれいにコードを書ける」こと以外にも更に何かプラスアルファがいるはずです。そのプラスアルファが何かは僕自身まだ答えはでていません。

ですが、プラスアルファが何であれ「きれにコードを書ける」技術はほぼ間違いなく必要です。理想を思い描けたところで、それを具現化する能力がおぼつかなければ意味がありません。

つまり、「きれいにコードを書ける」ということは、「前提」であり、その先も考える必要があるのだと最近は思っています。

招待講演ということで、若人トラックトップバッター務めさせて頂きました。発表を聞いて頂いた方、ありがとうございました。

個人的に今回印象に残っているのは、m_sekiさんのロールプレイの話とjune29さんの最大限能力を発揮する話でした。色々とグサグサくるというか要反省な感じです。

今回のオブラブはいつもよりスタッフが少なかったらしいですが、全然気にならない進行ぶりでした。どうもありがとうございました!

以下、個人的KPT。

Keep

• 遅刻しなかった
• 発表した
• 資料間に合った

Problem

• 資料の出来
• 発表の出来
• 人見知り力
• m_sekiさんからの質問にしどろもどろになってしまった

Try

• 前日には資料用意
• 一回は発表を通しで練習する
• Twitter上で絡みのある人ぐらいには話かける

必要なgemはwardenとrails_wardenの2つ。

Userモデルは以下のような感じで。

次にgithubのページを参考にconfig/initializers/warden.rbを追加します。今回はパスワードで認証をしたいのでpasswordのstrategyを自分で追加します。(と言ってもほとんどサンプルと同じ)

この後はUser.authenticateの中身をfind_by_login_and_passwordとかで実装してもいいのですが、それだとパスワードが平文になってしまうのでrestful_authenticationのコードを少し拝借することにします。

includeいているものがrestful_authenticationのコードです。適当にコピーしてlibにでも置いておくといいと思います。

これでpasswordとpassword_confirmationによるパスワードの確認、User#save時にパスワードをハッシュ化して保存してくれます。

後、一応ログイン処理するコントローラも載せておきます。

unauthenticatedが認証に失敗したときに遷移するアクションです。

正直、パスワード認証のことだけ考えるとちょっと面倒な気もします。パスワードの暗号化も自分で書かなければいけないし。ただ、上記のようにmoduleを別途用意しておけば作業の手間自体は結構軽減されので、そこまでは問題にならないかもしれません。

Strategyまわりについてはほとんど検証していませんが、色々と融通は効きそうな気もします。この辺は追々。

後はdeviseというwardenベースのライブラリもあるのでこれを試すのもありかなという気はします。ただ、deviseは色々とやり過ぎというか、多機能すぎてよくわからない感じもしますが・・・

頂いた本

今日、Amazonから3冊ほど屆きました。ソフトウェアテストの技法 第二版、初めて人のためのLISP、Joel on Softwareの3冊です。

自分で買ったものではなく、どうやら僕のwishlistから送って頂いたようなんですが、差出人が書かれておらず誰からなのかわかりません。引越し祝いかなにかかなーと思って@takkanmと@yoshioriに聞いてみたけれどどうやら違う模様。

本の内容・冊数からして確実に身近な誰かのはずなのですが、心当たりがありすぎて誰だかよくわかりません。もしよかったら、送って頂いた方は教えて頂けるとありがたいです。

なにはともあれ、結構な金額の本を送って頂きありがとうございました! 大事に読ませて頂きます。

持っている携帯がHT-03Aしか無いので、実機での確認はそれのみ。後はFxの方でUserAgentをSoftbankに変えて確認しました。

なので細かいところは全然確認してないので、何か問題があったら教えて頂けるとありがたいです。

y.akamatsu[at]ukstudio.jp

自分でメールサーバーを持ちたくなかったのでGoogle AppsのStandard Editionを使うことにしました。便利ですね、Google Apps。

それとちょっとオマケですが、5月中に引越しを予定していて、そっちが落ち着いたら個人事業主として開業届けを出そうと思っています。その辺りはまた正式に届け出を出してからまたお知らせしようと思っています。もし、Railsエンジニアが足りないということでしたらお声をかけて頂ければなと思います。

実は元々参加する予定はなかったのだけれど、ちょっと前に榊さん達と飲む機会にあってその時に「@fshin2000さん呼ぶんだけど話何聞きたい?」と聞かれ、好き勝手要望を出してたらいつのまにか参加する流れになっていたのでATNDの参加ボタンを押すことにした。にもかかわらず、今日は肝心のfshinさんの発表が終わる頃に到着したわけだけど。

なにはともあれ、今日はおいしい食事と楽しく色々な方と話が出来てよかった。主催の榊さん、スタッフ、発表された方々、それと会場提供のCafe Hi Famigliaさん、どうもありがとうございました。

ちょっと話が変わって少し暗い話。大して内容のある話でもないので適当に読み流してください。

今日のMitaka.rbで落札価格が3x万で落とされる云々の話を聞いた。具体的な規模は聞いていないけど、一般的に2〜3ヶ月かかる程度のものだったらしい。

3x万ってプログラマ１人雇うことすら出来ないじゃないか、採算どうやって取るんだと思って話を聞いていると、どうやらその落札者はあくまで「営業」として行なっているということらしい。つまり目的は落札してそこで売上をあげることではなく、その更に先にある「何か」なんだろう。つまり、赤字でも全く問題ない。ある意味でいうと投資みたいな感じなんだろうか。

この辺は推測なのだけど、赤字でも問題ないとは言え、わざわざ必要以上に赤字を出す必要もないので3x万という単価じゃ納品されるものもそんな大した出来じゃないだろう。でもきっと発注側の担当者はコストダウンしたということをきっと評価されるに違いない。そして今後もそこが発注する時は「以前同じような規模を3x万で作ってくれたよ」とか言いだすのかもしれない。あぁ、なんということだ。

基本的に僕は自分が体験したことのないことは、言い方が悪いけど話半分程度に聞いている。だからこの話も実際にそうだとしたらなんだかなーと言った程度のものである。とは言え、RubyのまつもとさんのTwitter上の発言にもあったから実際にあるんだろうな。

みんなこういう現状をどう受け入れていっているんだろう。