223 Software

12/4(日)に僕の主催するP4D(デザイナー向けプログラム部)主催でデザイナーxエンジニアハッカソンを開催しました。

当日まで

11月の初旬から準備を始めました。11/6(日)にいつものフィヨルドオフィスに集まって当日の企画を練り、そこから参加者やスタッフの募集などをコツコツ行いました。

こういうイベントを行うときに一番気がかりなのが会場なのですが、今回もそのへんは @machida さんにおまかせして余裕で30人ほどが入れて無線LANもあるベンチャーカフェ様を借りられることになりました。

参加者集めも工夫しました。

このイベントの一番の特長はエンジニアとデザイナーをペアにして1日で動くものを作ってもらう、という点です。

エンジニアには1日でシステムを組み上げるという開発スキルだけではなく、(大体)初対面のデザイナーさんとコミュニケーションしながら、時にはレクチャーをしながら開発するというハイスキルが要求されてしまいます。このことから、今回エンジニアは広く告知をして希望者を集めることをせず身の回りの知り合いに協力を仰ぐという集め方をしました。

幸い僕の身の回りにはとても優秀なエンジニアの方ばかりでしたので、エンジニアの方は問題なく集まりました。

募集開始

やはりコラボレーションをスムーズに進めるにはGitの使えるデザイナーさんを優先して集めたい、という狙いがあり、まずは先日開催したWebデザイナーのためのGit勉強会に参加された方にgithub上でメッセージを送って参加を募りました。

しかし、残念ながらこれは全然反応がありませんでした。そもそも普段からgithubを使っている人以外はgithub上でメッセージを送られても気づかないおそれがあります。ということで急遽ATNDを立てて募集しました。

出足こそ悪かったもののなんとか9人のデザイナーさんが集まり、「デザイナーさんは来てくれるかな・・・」という一番の心配事は解消されました。

デザイナー、エンジニアともに9人の参加者が集まった時点で締め切ったのですが、欠席者が出ることを考えて念のためにサポートエンジニアとしてtwitterや社内で追加のエンジニアを募集しました。ありがたいことにすぐに4人の方に手を挙げていただいてあっという間にサポートスタッフまで集まりました。

当日

なんと欠席者0人。しかもほぼ全員が10時の時間通りに来ていただけました。嬉しかったです。

おかげで急遽ペアにサポートをつけなければならない事態にもならず、逆にサポートエンジニアで来ていただいた方にはあまりやることがなくなってしまって申し訳ない気持ちにもなりましたが、それでも準備から片付けまで色々手伝っていただきました。本当にありがとうございました。

会場が休日のため入退場に若干手間がかかり少し開始時刻を押してしまったりとバタバタしたものの、自己紹介と開発するネタの発表まで無事に終わらせてあとはひたすら開発でした。

このイベント、デザイナー側から見てもノートPCのみでデザインを仕上げなければならないというかなり厳しい制約が課せられ、また時間の制約から考えてHTML納品というのも考えにくく、狙い通りほとんどのペアがgithubを用いたコラボレーションを行っていました。

そして活発にペアでコミュニケーションをとっていたのも印象的でした。サービスの名称から細かい仕様まで、お互いに話し合いながら、それでも手を動かせる者同士ということもあり簡潔なディスカッションを繰り返しながらテンポよくどのペアも開発を進めていた印象です。ちゃんとspecまで書いていたペアがいることは驚きでした。

開発言語は全ペアがRuby+JavaScriptを使っていました。この事実だけで、いかに偏った空間かということがわかるかと思います。そしてなぜかこの日に限ってherokuの調子が悪く、全ペアに大打撃を与えていました。

自分のペア

主催者でありながら、ちゃっかり開発もしました。僕は@saucerjpさんと組んでwebsocketを使ったアプリを開発しました。当日のうちにコアな機能はほぼほぼできたのですが、正式リリースに向けてもうちょっと機能追加+調整を行いたいので詳細は後日。

発表LT

懇親会を兼ねて、ビールを片手に各ペアの発表を聞きました。

これがまたどのペアも完成度が高い！デザインがきちんと入るとこんなにもレベルが高くなるんだなぁと感心しました。

成果物はwikiのOutputのページでも見られますし、きっとさらに完成度をあげて正式リリースされることと思います。各々のサービスについての詳細はそのときに発表されると思います。

まとめ

自分で言ってしまうのもアレですが、想像以上にいいイベントにできたと思います。これも準備段階から協力していただいたスタッフのみなさん、サポートエンジニアの方々、会場を提供していただいたベンチャーカフェ様、そして当日惜しみなくそのスキルを発揮していただいた参加者のみなさんのおかげです。

本当に開催して良かったと思います。またこういったイベントを開催していきたいと思いますので、今回惜しくも参加できなかった方もぜひ次回を楽しみにお待ちいただければ幸いです。

これをきっかけに毎月のP4Dの活動もますます盛り上げていきたいと思います。どうぞよろしくお願いします。

11/5（土）に開催されたTDDBC横浜にスタッフ、そしてJavaScriptのTAとして参加してきました。
遅ればせながらエントリーにしたいと思います。

参加のきっかけ

Yokohama.rbで@setoazusaさんがスタッフの募集を告知されて、それに乗っかった形で参加させていただきました。

TDDBCといえば毎回告知から数時間ですぐに参加枠がいっぱいになってしまうような人気イベントです。僕も過去参加申し込みをしたことがありましたが、絶望的なキャンセル待ちとなり参加できずじまいでした。
そんなTDDBCに参加できるとあればやらない手はありません。

予習

そして開催日の数日前にRubyではなくJavaScriptのTAを依頼され、正直JSのTDDを教えられるほどの自信はあまりなかったのですが、いい勉強の機会だと思って引き受けさせていただきました。（そのため、突然QUnitのエントリを書いたのでした→QUnit + QUnit-TAPでJSのTDDをしてみた）

JSのTAをするにあたって事前に予習したのはQUnit+QUnit-TAPでのnode.jsを使ったTDDだったのですが、ブラウザでのTDDの動作も確認しておかねば、と思い当日の電車の中でQUnit on ブラウザの環境を整えながら会場へ向かいました。
とはいえ結局テストの書き方はほとんど変わらないので、ブラウザでもguard-livereloadなどを併用すれば十分テンポよくTDDできますね。

また、QUnitと並んでJasmineの方もとても人気のあるJSのテスト用ライブラリです。今回は使いませんでしたがrspecのような書き方ができ、業務でも使っているので個人的にももっと使い込んでいきたいと思います。

当日

イベント自体の当日の様子などは既にwikiにまとめられているので、そちらをご参照ください。
TDDBC横浜/記録

今の職場では幸い業務でTDDできているのですが、やはりt-wadaさんの（RedBull片手の）基調講演を聴き、他の方のテストや今まで触れたことの無かった言語のテストなどを見ることにより、だいぶ自分のテストの書き方もブラッシュアップすることができました。

たった1日のイベントではありましたがずいぶんテストに対する考え方が整理されました。

• red -> greenにするだけではなく、きちんとリファクタリングをしよう
• テストすべきは自分が不安に感じるところである
• 自分が最初のユーザーになる気持ちで、APIをどう使いたいかという視点からテストを書く
• テストは目的ではなく手段であるということ

ペアプロやりたい

久しぶりにペアプロをやってみて感じたのですが、他の方がどんなことを考えながらどういう書き方で実装するのか、をライブで見るのは非常に面白いですし、勉強になります。

いいコードはgithubでいつでもたくさん読むことができますが、やはりライブは完成品に至るまでの過程が見えるあたり情報量が違いますよね。

他にも使っているエディタやプラグインの話をしたり、同じ実装をするにしても書き方の流儀が違ったり（JSのオブジェクトの作り方とか）そんなやりとりもペアプロの魅力だと思います。

ハッカソンの企画が終わったらペアプロも企画してみようかなぁ・・・などと画策中です。

やはりTDDBootCampですからね。Bootしただけじゃなくて、今後はそのスキルを上げていないといけません。TDDはスキルであり、そして量は質に転化する。積極的に機会を見つけて今後もスキルアップしていきたいと思います。

素晴らしいイベントでした。参加させていただいて、そしてスタッフ・TAやらせていただいて光栄です。ありがとうございました。

Twitter社の公開したScala教育用のコンテンツである Scala School! を使って社内Scala勉強会を始めました。

第一回は先週の11/2で、Basicsのページを進めました。

形式はみんなで顔を合わせつつ、同時にSkypeもつないでハマったところを共有しながら各自進める、という形式でやってみました。残念ながら僕は序盤に打ち合わせが入ってしまい抜けたのですが、一応全員Basicsのページは一通り進めたようです。

というわけでちょっと間が空いてしまいましたが、第一回で学んだことを簡単にメモします。

valとvar

変数の宣言の仕方が2通りです。valにすると再代入ができません。

scala> val two = 1 + 1
two: Int = 2

scala> two = 3
<console>:8: error: reassignment to val
       two = 3
           ^

メソッド

色んな定義の仕方があってややこしい。

基本？

def addOne(m: Int): Int = m + 1
def メソッド名(仮引数: 仮引数の型): 返り値の型 = 処理内容

処理内容が複数の表現を含むときは、{}で囲むことができる

def timesTwo(i: Int): Int = {
  println("hello world")
  i * 2
}

最後に評価した値が返り値となるのはrubyっぽい。
追記：上記、誤解でした。 @bleisさんに『最後に評価した値が戻り値になるわけではないです。それだと型を付けることができないので』と教えていただきました。以下のように書くとエラーになりました。

scala> def two: Int = {
     | 2
     | "string"
     | }
<console>:9: error: type mismatch;
 found   : java.lang.String("string")
 required: Int
       "string"
       ^

ちなみにLLの感覚で文字列をシングルクォーテーションで囲むとエラー。Char型を表すのですね。

無名関数

scala> (x: Int) => x + 1

CoffeeScriptっぽい。もちろん変数に入れることも可能。

scala> val addOne = (x: Int) => x + 1

無名関数も{}で囲むことができる。

scala> { i: Int =>
  println("hello world")
  i * 2
}

引数を取らない場合はかっこを省略できる。

scala> def three() = 1 + 2
scala> three
res3: Int = 3

部分適用

メソッドの引数のうち、一部だけを与えて新しいメソッドを作ることができる。

scala> def adder(m: Int, n: Int) = m + n
scala> val add2 = adder(2, _:Int)
scala> add2(3)
res19: Int = 7

まだ使いどころがよくわからない。

カリー化

メソッドを返すメソッドを作ることができる？

scala> def multiply(m: Int)(n: Int): Int = m * n
scala> multiply(2)(3)
res0: Int = 6
scala> val timesTwo = multiply(2)(_)
scala> timesTwo(3)
res1: Int = 6

これも使いどころがよくわからない。
以下も同じような使い方ができると思うけど、使い分けは？

scala> def multiply(m:Int, n:Int) = m * n
multiply: (m: Int, n: Int)Int
scala> val timesThree = multiply(3, _:Int)
timesThree: Int => Int = <function1>
scala> timesThree(5)
res20: Int = 15

上記のメソッドは以下のようにしてカリー化できる。

scala> (multiply(_, _)).curried
res21: Int => Int => Int = <function1>

可変引数

def capitalizeAll(args: String*) = {
  args.map { arg =>
    arg.capitalize
  }
}

次のrubyコードと動作は同じ。よく似てる。

def capitalizeAll(*args)
  args.map {|arg|
    arg.capitalize
  }
end

クラス

class Calculator {
  val brand: String = "HP"
  def add(m: Int, n: Int): Int = m + n
}

scala> val calc = new Calculator
scala> calc.brand
res23: String = HP
scala> calc.add(4, 3)
res24: Int = 7

プロパティとメソッドの定義。

コンストラクタは特定の名前のメソッドを定義するのではなく、クラス内のメソッド定義の外側のコードがコンストラクタ。

class Calculator {
  /**
   * コンストラクタ
   */
  val color: String = if (brand == "TI") {
    "blue"
  } else if (brand == "HP") {
    "black"
  } else {
    "white"
  }

  // インスタンスメソッド
  def add(m: Int, n: Int): Int = m + n
}

継承

class ScientificCalculator(brand: String) extends Calculator(brand) {
  def log(m: Double, base: Double) = math.log(m) / math.log(base)
}

オーバーロード

class EvenMoreScientificCalculator(brand: String) extends ScientificCalculator(brand) {
  def log(m: Int) = log(m, math.exp(1))
}

書いていないけど、オーバーライドのときはoverrideとつけないといけない。
いい例が思いつかなかったので、処理内容が同一です。

class MyScientificCalculator(brand: String) extends ScientificCalculator(brand) {
  override def log(m: Double, base: Double) = math.log(m) / math.log(base)
}

トレイト

PHPでも5.4から使えるあれですね。

trait Car {
  var brand: String
}

class BMW extends Car {
  var brand: "BMW"
}

インターフェイスとは違って抽象メソッドじゃなくても入れておけます。とか、複数のトレイトを使用する場合のこととか、そういうのはあとから出てくるのでしょうか。

型

型引数、とかジェネリクスとか言われると、Javaをやっていない身からするとちょっと厳しいです。
次のように、型引数を使用できます。

trait Cache[K, V] {
  def get(key: K): V
  def put(key: K, value: V)
  def delete(key: K)
}

メソッドも型引数をつけられるそう。

def remove[K](key: K)

まとめ

後半の内容は、正直使いどころとかが理解できていません。
頑張って引き続き学んでいこうと思います。

実は去年にコップ本は一通り読んだのですが、残念ながらほとんど覚えていませんでした・・・。
一通りこのScala Schoolが終わったら読み直さないとダメかな。

ちなみに僕が持っているのは第1版です。

開催してきました！

まとめは前回同様、GitHubのwikiにまとめましたのでご覧ください。

https://github.com/prog4designer/meetups/wiki/第3回

はじめての欧文書体 - 欧文書体の種類と歴史について

• @9d さん
• 欧文書体の種類 * 第一回：欧文書体の種類と歴史について * はじめての欧文書体さん

セリフ / サンセリフとありますが、その歴史の長さには大きな違いがあることを初めて知り、驚きました。
またTimes RomanやHelveticaとか、なんとなく使っていましたがそれぞれの書体にもやはり開発された背景や歴史、そして性格（見出し向きとか本文向きとか）があり、それぞれを知ることでWebのコンテンツにも活かせるのかな、と感じました。

同じ書体でも間隔や太さを変えるだけでも全然違う書体に見えるところも意外でした。

次回以降には実際にWebデザインに活かす方法なども話していただけるようで、そちらも楽しみです。

WebデザイナーのためのWeb(HTTP)入門

• @komagata さん

急遽資料を作っていただき、お話していただきました。

内容はHTTPの基礎を理解する、ということでしたがsinatraでその場で簡単なアプリを書いて、そのアプリに対してブラウザではなくtelnetコマンドを使って黒い画面でブラウザの行っている動作を再現する、というなかなか硬派な内容でした。

そこから派生してRESTfulやrailsの思想などの話にも話題が広がったり、とプログラマーから見ても大変興味深い内容でした。

今日お話しいただいたHTTPについてをもっと詳しく知りたい場合は以下の書籍が最適かと思います。

ライブコードレビュー

• @saucerjp さん

既にJSをバリバリと使っている@saucerjpさんですが、2本ほどJSで書いたプログラムを持ってきていただき、それをスクリーンに移しながらみんなで意見を出し合う、というコードレビューを行いました。

モジュール化に関しては一応プログラマとして色々アイディアを出させていただきましたが、そもそも今後の再利用性を始めからきちんと考えて組もう、という考えにご自分で至るあたりがすごいと思いました。

コードレビューの中ではJSの var self = this; のイディオムについてや、call(), apply()メソッドについての話、CoffeeScriptについての話までに発展して盛り上がりました。

次回以降の話

来月中旬 or 下旬に30人規模のハッカソンを企画しています。興味のある方はぜひGoogleグループの方に参加していただけると幸いです。

また1〜3回まで開催してみて、ここまでは開発環境構築やWebアプリの仕組みなどのWeb開発に必須の内容を発表メインの形式で活動を行ってきましたが、そろそろ実際に手を動かすような活動をもっと取り入れていきたいと考えています。
次回の第4回からは、例えばチャットを作る、掲示板を作る、twitter連携サービスを作る、といった簡単なテーマを設けて、少しずつ実践的なプログラミングをステップアップで学んでいける内容にしてみようかと思います。

なかなか全員のニーズを満たす活動というのは難しいですが、少しずつ内容を充実させてエンジニア・デザイナをつなぐ架け橋として機能する活動というかコミュニティを作れるように頑張りたいと思います。

Pythonを全然やっていないくせに、Python Developers Festa 2011.10に参加してきました。

rubyとpythonだとどちらもオブジェクト指向のスクリプト言語ということで特長がよく似ていますし、どちらか片方だけできればいいのかもしれませんが、他の言語の文化を学ぶことでさらにプログラミングへの理解が深まると思い・・・。

環境構築

席について、すぐにpythonの開発環境の構築を始めました。

最初はbrewでpythonをインストールしたのですがMacには最初からPythonも入っていて、よく見るとバージョンも2.7.1でbrewで入る2.7.2とあまり変わらないです。
なので、実際に環境構築に必要なコマンドは以下の2つくらいだったので楽々でした。

$ sudo each_install pip
$ sudo pip install virtualenv

ハンズオン

初心者ハンズオンもありそちらに行くべきか悩んだのですが、一応pythonもチュートリアル程度はやったことがあるので大丈夫かと思い、@voluntasさんが講師のdjango + heroku組へと参加しました。
djangoもインストールすらしてないのに参加して講師側のハードルを上げてしまいましたが、一応virtualenvのインストールやらgemのインストールで他の参加者の方のお手伝いもできたので良かったと思います。

virtualenvやheroku gemのインストールが終わった後は、Heroku 上で Django を動かすの手順に従ってコマンドを打っていくだけであっさりとできてしまいました。ネットワークの関係上、heroku run コマンドが実行できなかったのがちょっと残念でしたが、とりあえずトップページの表示までは問題なくできました。

やってみてしまえば簡単でしたが、なかなか実際にやってみるきっかけがなくてpythonはほとんど触らずじまいだったので、きっかけを得ることができてとても良かったです。

午後の部

発表を聴きながら、Objective-Cを書いてiPhoneアプリの開発を勉強していました。
あとは初心者ハンズオンの資料が公開されていましたので、一通りやってみました。

発表の方はpythonの話もありましたが、ネットワーク、hadoop、DBなど話題が幅広く、今まで参加した勉強会の中で一番置いてけぼり感を感じるものでした。まだまだ勉強することたくさんあるなぁと感じました。

全体を通じて

ハンズオン、発表を通じてgitの話題も多かったのが印象に残りました。
個人的にもgitを教える活動をしていたりするので興味深く聴いていました。

gitも多人数で使いだすとやはりgit-flowとかgit-dailyみたいなブランチの扱い方というのも考える必要があるのですね。

自分のチームはまだ開発者も4人と少なく、幸いgithubを使った開発ができており、さらに幸いなことに全員がコマンドラインからgitを使うことに不自由しないスキルを持っているため、あまり意識したことがありませんでした。

「基本的にトピックブランチを切って、masterにマージをするときにはpull request使いましょうか？」程度の打ち合わせでブランチの運用の仕方が決まっています。

今後人数が増えたり運用フェーズに入ったりしたときには、多分もう一度考える必要があると思うので、参考にしたいと思います。

参加している方が多様なのも印象に残りました。pythonの方ばかりかと思いきや、組み込み、java、PHPなど色んな方と出会い、情報交換をすることができました。

あと女性も多かったです。IT系の勉強会としては珍しいのではないでしょうか。女性枠のおかげなのでしょうか？

ということでまとまりなく書いてきましたが、楽しい勉強会を企画してくださった@voluntasさんはじめ、スタッフの方々、そして素晴らしい会場を提供してくださったオラクルさんに感謝したいと思います。ありがとうございました。

もう何回目になったのかあまり覚えていませんが参加してきました。

発表（転職とコミュニティ）

今回は発表の時間を頂いたので転職活動を通じて感じたことなどを発表してきました。
技術的なネタも一応考えてはみたのですが、転職ラッシュの今しか話せないかな、と思いこのネタです。

• 資料
• 動画 (miyohideさん、ありがとうございます)

質疑応答でもお話ししたのですが、決して転職という選択肢が全員にとって良いものとは限りません。現在転職を検討されている方も、ぜひ慎重にじっくりと考えて欲しいと思います。

Yokohama.rbメンバーはちょうど転職ラッシュの最中です。みなさんがよりよい仕事に就けるよう応援したいと思っています。

レシピブック読書会

この本をみんなで読み進めています。

これが予想以上に濃いんですよね。一人で読んでいると読み飛ばしてしまうようなところまで、深く掘り下げることができます。

少し読んではコードを書き、議論し、そしてまた進むという。

まさに初心者にとっても上級者にとっても面白い企画になっていると思います。

スティーブ・ジョブズの演説

追悼として、伝説のスピーチとされるスティーブ・ジョブズのスタンフォード大学での卒業式式辞をみんなで鑑賞しました。

http://www.youtube.com/watch?v=OaMT8fZpEXA

僕は今回初めてこの動画を見たのですが、「点をつなげること」、「愛と喪失」、「死について」いずれのテーマも経験に基づいた話で、非常に勇気づけられ、背中を押してもらえるような内容でした。

• 「今日で死ぬとしたら、今日は本当にすべきことをするのか。その答えがNoである日が続くようなら、何かを変える時だ。」
• 「他人の人生を生きないこと」

何かを決断するとき、勇気をもらえそうな言葉ですね。

ところで、転職の話題の後でこの動画を見るとうっかり転職してしまいそうな人が多発しそうです・・・。

TDDBC横浜

TDDBC横浜 にスタッフとして参加することにしました。
うちから会場まで1時間半以上かかってしまい結構遠いのですが、いつも定員オーバーでなかなか参加することのできないTDDBCに確実に参加するチャンスでもあると思いますし。

幸い業務でrspecを使用していますが、この機会にrspecの復習をしておきたいと思います。

WebデザイナーのためのGit勉強会を9/11に開催しました。
既に１週間が経ってしまいましたが、エントリーにまとめておこうとおもいます。

この勉強会の目的

この勉強会は僕の主催するデザイナー向けプログラム部のメンバーが中心となって、Gitを使えるデザイナーを増やそう！との目的で企画したものです。

7月に参加したハッカソン（詳しくはプログラマとデザイナでハッカソンした話）の際に感じたのですが、お互いにGit, GitHubが使えるだけで格段にコラボレーションがやりやすくなります。近々行いたいと思っているデザイナーとエンジニアを一堂に集めたハッカソンにあたってはやはりGitが使えるデザイナーを集めたいという狙いもあり、今回の勉強会のきっかけとなっています。

準備

9/4に都合のついたメンバーで集まって、当日の内容や手順についての打ち合わせを行いました。
14時頃〜19時過ぎの長丁場となりましたが、いいミーティングができたと思います。10名を超える規模の勉強会を企画したのは初めてでしたが、こういう準備が重要だなぁと感じると同時に、休日にもかかわらずに協力してくださるみなさんには本当に感謝したいと思います。

当日の様子

ざっくり分けると4部構成で行いました。

まずは@machidaさんによる、デザイナー視点から見たGit, GitHubを使うことのメリットのお話。資料はこちら -> Github勉強会。

ここから先はひたすらハンズオンでした。準備編ではGitHubのアカウントを持っていない人を対象に、アカウントの取得からSSHキーの登録などを行いました。既に設定済みの方もいらっしゃったので、そこはGit関連の書籍や情報の調べ方などを提示しつつ・・・。資料 -> WebデザイナーのためのGit勉強会 〜準備編〜

その際に紹介した書籍は以下の3冊です。

入門Gitは２冊ありますが、@monoookiさんから白い方が入門者向けには易しいとの情報をいただきました。黒い方はGitのメンテナの方が書かれているので、より深く理解したい方向けでしょうか。

あとはオンラインで読めるProGitも紹介させて頂きました。

次は基本操作編と題して、主に一人でGitを使うために必須のコマンドの練習やリポジトリをGitHubにpushするところまでを行いました。資料 -> WebデザイナーのためのGit勉強会 〜基本操作編〜

最後は応用編として、各グループごとにエンジニアを配置してのグループ作業としました。全員共通の作業は以下のとおり。（グループリーダーを引き受けてくださった、@jishihaさん、@tyabeさん、@shu_0115さん、@u1tnkさん、@saucerjpさん、ありがとうございました。）資料 -> WebデザイナーのためのGit勉強会 〜応用編〜

1. prog4designer/p4d-gitを中央のリポジトリとし、それを各自のアカウントにfork
2. forkしたリポジトリを各自のローカルにclone
3. 変更を加えて（今回は自己紹介をindex.htmlに書きこんでもらいました）push
4. Pull Request

この内容ができれば、もうオープンソースのソフトウェアへデザイナーとして参加することが十分可能だと考えています。

そして当日は全参加者がここまでできましたので、一気に20名以上もオープンソースへ貢献できるデザイナーが増えたと言っても過言ではありません！（キリッ

グループによっては、ブランチの話までできたようです。

今後について

今回、Gitの特長といえるブランチの使い方にまではあまり踏み込むことができませんでした。Pull Requestをするにしても、ブランチを切って作業する方が通常のやり方だと思いますのでこれはフォローしたいと思っています。

あとは今回定員オーバーとなってしまい参加できなかった方がいらっしゃいます。これに関してはフィヨルドさんにて後日もう一回今回の内容を行うことが決定していますので、近々ご連絡できると思います。

そして@machidaさんのスライドにもあったデザイナー、エンジニアを一堂に集めたハッカソンですがまだ日程は未定ですがぜひ行いたいと思います。

これらに興味のあるデザイナーの方、または協力してくださるエンジニアの方はぜひデザイナー向けプログラム部をチェックして下さい。GoogleグループやLingrでイベントの打ち合わせをしたりしていますので、お気軽にご参加下さい。

最後に

会場を提供してくださったZynga Japan様、もろもろの調整や連絡などを引き受けてくださった@machidaさん、そして協力してくださったたくさんの方々、当日参加してくださった方々に感謝したいと思います。
ありがとうございました。

今後も色々とイベントごともやってみたいと思っていますので、またお世話になりますがよろしくお願いいたします！

懇親会を含めて全日程参加してきました。
セッションの様子や感想などはhttp://b.hatena.ne.jp/t/rubykaigi2011やRubyKaigi2011 スペシャルレポートを見ていただくのがいいです。

ここでは自分が主体的に参加した部分と、感想などを書いてみようと思います。

!RubyKaigiで発表しました。

資料: 趣味プログラミングのすすめ

「趣味プログラミングのすすめ」というタイトルで15分、しゃべりました。

内容的には、今は個人でどんどんサービスが作れてしまう時代だしチャレンジしてみると色々返ってくるものもあって楽しいですよ、というお話です。

自分の経験を事例として、どんなきっかけで趣味でもプログラミングをするようになったのか、どうやってモチベーションを保つようにしているのか、といったことを話しました。

最後のRubyKaigiで自分の話をすることができてとてもよかったです。

Rails勉強会@東京第64回を開催しました。

@1syoさんが中心となって企画を進めてきた、これに乗っかってお手伝いをしました。

僕の担当はRails3時代の情報の調べ方について、ということで素晴らしい「Rails情報源の歩き方（前編）」に沿って、それぞれのサイトの特徴や使い方を紹介したり、ということを、僭越ながらみなさんの前に出て進行役をさせていただきました。

参加者もたくさんいましたが、ある程度みなさんの意見も聞きながらコミュニケーションできたのでは、と思っています。

また後半は飛び入りで参加して下さった@AkitaOnRailsさんから、非常に力強いメッセージをいただくことができました。

そのあたりはwiki（Rails勉強会@東京第64回）にまとめさせていただいたので、ぜひご覧ください。

初めてだけど楽しめた

実は、今回が僕にとっては初めてのRubyKaigiでした。まさに最初で最後のRubyKaigiです。

初めてだけどこんなに楽しく3日間を過ごすことができたのはyokohama.rbのメンバーをはじめとする、たくさんの仲間がいたからだと思います。
まだ数回しか行っていないし、そもそも横浜に住んでもいないし通ってもいないし、という遠慮がちょっとあって「yokohama.rbによく顔を出しています」なんていう自己紹介をしていましたが、そろそろ「yokohama.rbから来ました」と言わせていただいてもいいですよね？

もちろんこの場での出会いも素晴らしいものでした。
たまたま初日に隣り合っただけの岡山から来た学生さんと意気投合して一緒に行動したりできたのも、やっぱりrubyという共通のものを通してつながった仲間だからだと思います。

今後の課題

もっと前に出る

有名な方もたくさんいらっしゃってしかも目の前にいてお話しするチャンスもたくさんあったのに、なんか物怖じしてしまい話しかけられなかった。これは自分でも悪いところだと思っていて、でも勇気が出なくて・・・と思っていました。

最終日の夜、RejectRejectReject(?)HerokuPartyでだんさん（@dan5ya）さんからも、「なんで話しかけないのかわからない、もったいない」と言われました。だんさんの経験なども聞かせていただいて、次こそはもっと前に出て、色んな人に話しかける勇気をもらいました。
あと、「頭の良さは伝染る」というお話も良かった。すごい人の近くにいると、その人の価値観とか考え方に影響されることがあって、それが「伝染る」ということです。
「話しかけれられて嫌がる人はいないから・・・」、確かにそうですよね。やってみます。

「これ」と言える実績を作る

プロダクトでも、活動でも、「あぁ、あの@satococoaさんね！」と言われるような実績を作りたい。当面は発表でもやったような趣味プログラミングを、もう少し技術ドリブンではなくて、使う人を少し幸せにできるようなサービスを作りたいなぁと思います。

あとは、最近立ち上げたデザイナー向けプログラム部を盛り上げていけるよう頑張りたいです。

Rails勉強会@東京第63回に参加してきました。

今日のセッションは以下のとおり。

• 前 CoffeeScriptについて（全体）

• 中

  1. テストについて
  2. Rails 3.1について

• 後

  1. PaaSについて
  2. Rails開発のTipsなど

CoffeeScript

まずはセッション開始前にjs2coffeeというNodeのライブラリを教えてもらいました。
始めは普通に.coffeeを.jsにするものだと勘違いし、会話が成り立っていませんでした。すみません。逆なんですね。

セッションではCoffeeScriptをインストールし、公式サイトを見ながら実際に打ち込んでテストをしました。

MacでもWindowsでも、Nodeを入れなくてもruby-coffee-scriptを使えばexecjsが適切なJavaScriptの実行系を探して、CoffeeScriptにコンパイルできるみたいです。

$ gem install coffee-script

この場合、コマンドラインからcoffee -> jsにするにはそれ用のスクリプトを作る必要があります。

セッションではそれぞれnodeのcoffeeコマンドで実行したり、公式サイトのTRY COFFEESCRIPTで実行したりして試しました。

-bオプションを付けるのと付けないのとで、まずはコンパイルのされ方が違うことを確認。-bオプションを付けないと、全体が無名関数に囲まれます。

$ coffee -c hello.coffee
$ coffee -bc hello.coffee

途中までは上から順番に進めていっていたのですが、「CoffeeScriptで便利なのはClassを使えるところ」という意見があり、Classを作ってみることに。

class Animal
  constructor: (@name) ->
  move: (meters) ->
    console.log @name + ' moved ' + meters + 'm.'


class Snake extends Animal
  move: ->
    console.log "Slithering..."
    super 5

sam = new Snake "Sammy the Python"
sam.move()

これでクラスの継承。簡潔ですね。@nameはjsにするとthis.nameと解釈されます。
(ずっと勘違いして今まで@.nameとわざわざ書いていたことにこのとき気付きました。)

そして、次にクラスメソッドを試してみたところで問題が発生しました。
クラスメソッドのあるクラスを継承した場合、TRY COFFEESCRIPTの実行結果とローカルでcoffeeコマンドで実行した結果が違った・・・と思って今やり直したら、同じ結果になりました。
バージョンの違いか、何か間違っていたのか、ちょっと原因はわかりませんが、以下のコードはどちらでも意図通り動きます。

class Animal
  constructor: (@name) ->
  @classmethod: () ->
    console.log "Animal's classmethod"

class Snake extends Animal
  @classmethod: () ->
    console.log "Snake's classmethod"

Animal.classmethod() #=> Animal's classmethod
Snake.classmethod()  #=> Snake's classmethod

あとは便利だなーと思ったのは=>でしょうか。

Account = (customer, cart) ->
  @customer = customer
  @cart = cart

  $('.shopping_cart').bind 'click', (event) =>
    @customer.purchase @cart

JSだと、'click'にbindするときに、実行時のthisがAccountのオブジェクト自体にならないために通常 var self = this; するところを、=>を使うと自動的に定義時のthisが実行時にもthisとして参照できるようなコードを生成してくれます。

あと-wオプションではファイル単位ではなくディレクトリを指定することもできることを今日知りました。便利。

しかし、これを変換したjsをブラウザで実行させ、デバッグさせるとなると大変です。何かいい方法はないのでしょうか？
しかもrails3.1で使うと本番環境ではさらにuglifierによる圧縮もかかります。

Rails 3.1

中盤のセッションはRails 3.1の話題の方へ参加しました。

とりあえずrails newしてみていきなり自動的にbundleが始まり、意図せずgemsetも分けていないシステムに全gemが入っていってしまう事件を目撃しました。

ちなみに、bundleを自動的に実行させたくないときは--skip-bundleオプションを付けます。

$ rails new blog --skip-bundle

その後はapp/assets/javascripts/application.jsを見て、実際にcoffeeを書いてみて、Sprocketsをちょっと調べました。

次にHTTP Streamingを調べるためにASCIIcastsの266: HTTPストリーミングを見ながら実際にcurlでコマンドを打って実験してみました。
使いどころとしては、CSVをダウンロードさせる、とかXMLをダウンロードさせる、とかかなぁ・・・という話。

次にIdentity Mapの動きをrails consoleで試し、最後にtest/unitの結果に色がついて綺麗になったところまで確認して終わり。

PaaSについて

3コマ目のセッションはPaaSについて語りました。

セッション参加者が使ったことのあるPaaSは以下のとおりで、それぞれ使ってみた感想や特徴などを話しました。

• heroku
• DuoStack
• DotCloud
• CloudFoundry
• fluxflex(微妙だったという話)

DuoStackはDotCloudに買収され、もう新規アプリは作れなくなっていました。
herokuは課金体系が変わり、1dyno hourという単位で課金されますが、1dyno or 1workerを1ヶ月フルに動かす分＋ちょっとが無料で使用できる範囲となっています。あと、CedarというstackでNodeも動くようになっています。

最後にherokuを使う上で便利なadd-onについて話しました。

• Hoptoad: 業務で使うなら入れるべき。JSのエラーまで通知してくれる。
• StillAlive: 公式サイトのビデオは必見。Cucumberみたいな感じに実行する操作を定義できます。

まとめ

前回より人数は少なかったみたいですが、その分実践的な話や具体的な話ができたり、わいわいと3.1を触ったりできて楽しかったです。
また、いつもながら場所を提供していただいている永和システムマネジメント様に感謝です。

また参加したいと思います。ありがとうございました。

WebSocket勉強会に参加してきました。
いつものようにつらつらとメモや感想のまとめを。

時間のない方へはじめに結論(というか、盛り上がったポイント？)

さくらVPSとNode(Node.js) + Socket.IOを使えば「もう何も怖くない」by @kanreisa さん

業務向けにはIIJさんのIIJ GIOもよろしくね。

WebSocketを見てみよう

• @Kuruma さん
• 資料：WebSocketを見てみよう

今までの双方向通信

• AjaxによるPolling
• Comet (代表: Long Polling)

WebSocket

標準化は現在進行形であり、仕様は以下のあたり

• IETF HyBi WG
• W3C WebApps WG

特徴は「全二重の双方向通信で、UTF-8の文字列 OR バイナリ（最近のレビジョン）のデータをやり取りできること。」

HTML5の一員として語られることが多いが、正確にはHTML5とは独立したものではある。
とは言え広義のHTML5の一員であると言えるため、この辺厳密な線引きはされていない様子。

既存のWebとの親和性を考慮して策定されており、最初のハンドシェイクをHTTPで行い、80番ポート（もしくは443ポート）を使用することで、既存のWeb-proxyを通過できるように工夫されている。
（しかし、現状ではFWは通過できるだろうけど、パケットを覗くproxyでは弾かれてしまうかも？）

各ブラウザの実行状況は資料のP.12からを見る方がいいと思いますが、サーバー側の実装が潤沢であるにも関わらず、クライアント側（Webブラウザ）などはまだまだこれからといった状態です。

ブラウザへの実装状況ですが、ほとんど現在は各ブラウザの開発版には搭載されている状況です。Firefox4ではデフォルトで無効化されていますが、それはちょっと前に問題になったプロトコル上のセキュリティに関する懸念があるからです。
ただ、それを利用した具体的な攻撃方法も見つかっていないため、それが見つかるまでは特に問題がないとみなされ、ChromeやSafariではそのセキュリティに対する懸念のあると言われているレビジョンの実装が有効化されています。

現実に今からWebSocketを使おうと考えた場合は、Socket.IOや、PusherなどWebSocketが使えないクライアントではFlashを代替手段として使ってくれる、などのfallbackが考慮されているライブラリを使用するといいと思います。

個人的な感想ですが、Socket.IOはいいですね。Socket.IO使えば「もう何も怖くない。」

WebSocketのしくみ

スライドP.17からの内容です。2011/0525時点でIETF/W3Cの公開しているドラフト文書に基づいて、細かく説明してくださいました。

大まかな流れは以下のとおり。

1. Scriptを実行

• コンストラクタ: ws = new WebSocket(url [, protocol]) # 第2引数は後述のサブプロトコル
• 4つのイベントハンドラ: onopen, onmessage, onerror, onclose
• 2つのメソッド: boolean send(data), void close()

URLについては、

• schemeはws or wss(http, httpsのような対応関係)
• portを含んでもよい(ws://example.com:3000/)
  省略されればws:なら80, wss:443
• path, queryも含められる
  例) ws://example.com/chat/?room=1
• fragmentを含んではならない
  ws://example.com/chat#room=1 はできない

2. HTTPでハンドシェイク

資料P.25を見ていただくのがいいかも。 リクエストの3行目、Upgrade: websocketが中身を覗くプロキシに弾かれてしまう、という声も会場からはありました。

プロトコルのレベルになると僕は全然知識が足らずにいまいち理解が出来ていないのですが、
"Wec-WebSocket-Key: 任意の文字列"を使用して認証を実現したりするようです。

また、仕様では明示的にCookie使用可とは書かれていませんが、リクエストヘッダの例として「例えばCookieとか、Sec-WebSocket-Protocolとか・・・」のような書き方がされているそうです。要はあとはアプリケーション側でなんとかしてってことですかね。

ここで"Sec-WebSocket-Protocol:"というのが出てきますが、これが前述のサブプロトコルです。
アプリケーションレベルで任意にプロトコルを定義して、サーバーから返されることが期待されるものを列挙してリクエストとして送り、サーバーがその中から使用するプロトコルを選択する、という仕組みだそうです。
意外とフリーダムな印象です。

あとはSec-WebSocket-Extensionsヘッダを使って圧縮などの拡張を使用できるそうです。

3. WebSocketでデータ転送

WebSocketはデータを転送する際、1つまたはそれ以上のフレームの連続としてデータを転送するそうです。 フレームが確実に届くことと、その順序はTCPなので保証されており、ブラウザから送られるペイロード（転送されるデータ本体）は必ずマスクされます。（暗号化とは違い気休め程度、という声もありました。）

また、資料P.35のペイロード長の定義を知っておくと、サブプロトコルの設計やデータ量の節約などに役に立つと思います。

4. 切断

サーバー・クライアントからcloseを送信しただけでは切断されず、必ずそれに対する返答を受信してから切断される仕組みだそうです。

補足

質疑応答の際にWebSocketも基本的にはSame-Originのポリシーとの説明がありましたが、実際はそうではないとの旨懇親会でご本人から補足がありました。
（別ドメインのWebSocketサーバーにもつなげるということ。）

まとめ

プロトコルのレイヤーの話は今まで殆ど分かっていませんでした。
アプリ開発者としてはSocket.IOなどに任せてしまう部分だとは思いますが、知っておかないとデバッグなどで困ることになるのかもしれません。
まともなWeb開発者ならHTTPのヘッダを確認することは普通ですし、その延長ですよね。

WebSocket事例紹介

• @MiCHiLU さん
• 資料：WebSocket

「WebSocketを使うと無駄なヘッダーのやりとりが節約できます。」というのは知っていましたが、資料のP.14は必見です。
この条件で300万円/月の節約になると聞き、取り組むべき価値がかなり明確になりました。
接続数が多くなれば多くなるほど切実ですね。

僕が作ったアプリでも使っているPusherの紹介もありました。heroku使ってる人にはおすすめです。

発表された@MiCHiLUさんはWebSocket.JPというグループの立ち上げやShirasu.wsというWebSocketのフレームワークの開発なども行っているそうで、精力的に取り組まれている様子でした。

NonBlock Socket and Asynchronous I/O

• @nori0428 さん
• 資料：NonBlock Socket and Asynchronous I/O

Node(Node.js)などを語る際によく言われるノンブロッキングとか、非同期とかのあたりを分かりやすく整理してくださいました。

覚えておくこと3つ

1. 並行処理
2. 同期呼び出し・非同期呼び出し
3. ブロッキングI/O・ノンブロッキングI/O

気をつけること

イベントハンドラ内はシングルスレッドなのでなるべく処理を軽くする。

スケールさせるには？

• 複数サーバ立てる
• Reverse Proxy / Load Balancer

lighttpd用モジュール

lighttpd用のWebSocketモジュールを作られているそうです。

簡単な設定ファイルを作るだけでWebSocketから、ローカルのTCPSocketを繋ぎ込むことができるモジュールで、実際にサーバー上のPostfixとブラウザをつないでSMTPがしゃべれるデモを見せて下さいました。

これを応用するとブラウザからSSHできたりしそうですね。（もう既にある？）

「さくらのVPSでnode.jsを使ってみよう」(仮)

• @kanreisa さん
• 資料：さくらのVPSでnode.jsを使ってみよう（仮）

軽妙な語り口で、随所でウケを取っていました。
デモも、さくらのVPS上にインストールしたDebianへiPadから接続してコマンドを打つ、というスタイル。

Togetterを見るとその盛り上がりの一端が見えると思います。

Node(Node.js)をイチオシされていました。さらにSocket.ioを使えば「もう何も怖くない」

• デモの中身
• ソース

• radio.sock

• PHPで実装してみた gist

ブラウザのハードウェア対応の未来を探る

• @ndruger さん
• 資料：ブラウザのハードウェア対応の未来を探る

ustにこの部分、入っていますでしょうか。確認していませんが、デモをぜひ見てください。

仮想現実の中に入り込めるようなゲーム、面白そうですね〜。スト4みたいなものもできる時代が来るのでしょうか。

Websocket Communication

• @kamiyam さん
• 資料：Websocket Communication

発表資料自体がWebSocketを使って作られていて、@kamiyamさんの手元のiPhoneでスライドを切り替えると、各参加者の画面上でもスライドが切り替わる、という仕組みでした。

また途中に盛りこんであったアンケートにも当然WebSocketを使われていて、回答が送信されるたびに数字が増えていくさまが面白かったです。

WebSocketでデバイス間連携

• @kanasan
• Web

HTML5とか勉強会のスタッフをされたりしているそうです。

Jettyを使ってiPhoneからWindowsを操作したり、Keynoteを操作したりするデモを見せて下さいました。

Jettyを使った理由としては機能面（ライブラリの充実、exe可/app可の容易さ）を挙げていらっしゃいました。 Java.awt.Robotというライブラリを使うとマウスやキーボードの操作をエミュレートすることができ、Java Scripting APIを使用するとApple Script（等他の言語）を呼び出すことができたりするそうです。

また、ご自身の作られたWebSocketRemote（http://www.kanasansoft.com/weblab/2010/04/websocketremote00_1.html）で苦労した点についてもお話がありました。

懇親会

なぜかアジャイルについて語ったり、ゲーム業界とWeb業界のプロジェクトの進め方の違いについて語ったり、楽しい時間を過ごさせていただきました。

おいしい料理もたくさん出てきて、大満足でした。

最後に

今回の勉強会は非常にテーマが幅広く、WebSocket自体のプロトコルについての話から採用事例、デモまで上から下のレイヤーまでカバーされていました。
そのため参加されている方もWeb開発者が半数程度、という普段僕が参加する勉強会とはまた違った雰囲気で、とても刺激になりました。

朝〜夜までという長丁場でしたが、熱気に満ちた大変ためになる勉強会でした。主催者の方々、講師の方々、どうもありがとうございました。

蛇足ですが、ボランティアとして朝イチの受付で懇親会のお金集めをさせていただいていたのが僕です。
慣れないもので手際があまり良くなかったかと思いますが、ご勘弁ください。