今回はそのTDDBCがYokohama Devtesting と合同でイベントを開催されるということだったので、
こちらのイベントに参加してきました。

TDDBCとは？

TDDを手を動かしながら体験することを目的として、全国各地にてハンズオンイベントを開催しているコミュニティ。
アジャイルとかCIのイベントに参加してるけど、結局何を契機に始めたらいいのかわかんないや みたいな方のためのイベントも。
言語はイベントによって異なる模様(今回はJava)。

Yokohama Devtesting とは？

横浜でソフトウェア開発のテストについて考えるコミュニティ。
月一回のペースにてテスト駆動開発本の読書会も開催されている模様。

イベントの流れ

・TDDに関するプレゼン
・ペアプロデモ
・実際にペアプロ
・コードレビュー

TDDに関するプレゼン

以下、TDDに関するメモ。

● TDDのゴール

「動作するきれいなコード」

● TDDのこころ

・小さくまわす
・TODOリストに入れて いっこいっこつぶして行く
・複数を相手にしない

● TDD三原則

・失敗する単体テストのコードを書く前に製品のコードを書いてはならない
・コンパイルが通り適切に失敗する単体テストができるまでは次の単体テストを書いてはならない
・現在失敗している単体テストが通るまで次の製品コードを書いてはならない。

● 用語集

・TODOリスト
最終的にめざすゴールと一つ一つのゴール
・アサートファースト
テストをどこから書く？
→ コードによって何を実現したいかをアサーションとして書く。
・仮実装
→ まず最初にやるテスト。
とりあえずテストを成功させる。
テストをテストする意味合いを持っている。
・三角測量
二つの側面からテストにより一つの実装を導く
・明白な実装

ーーー

ペアプロに関するメモ。

● ペア・チームにて「これは実装しないと駄目だよね」みたいな感じで 設計を含めて合意

● 紙・メモ帳(TODOリスト)に出しておく
ペアプロでよくあること「交代」。適切なタイミング(イテレーションが終わった時とか、詰まった時とか)で交代しよう。
実際に書いていく人 – ドライバ
アドバイスする人 – ナビゲータ

ペアプロデモ

「百聞は一見にしかず」ということで、
今回はFizzBuzzをお題に主催の方のうち2人がプロジェクタにペアプロの様子を映しながら開発。

「TODOリストを見てみましょうか」
「何からはじめる？」
「仮実装」
「テストを実行」
「コンパイルを通ることを確認」
「別のケース。エラーになりました」
「テストが通るようにプロダクトコードを修正」
「OK」
「んー、単純なんでリファクタリングする必要もなさそうですね」
「次のTODOにうつりますか」
「ここでナビゲータ交代」
「なんかここプライベート変数に置き換えた方よさそうですね」
「TODOに追加しておきましょう」

という感じのやり取りが続く。
うーん、こういう感じでやるのか…勉強になる。

実際にペアプロ

参加者で2人組になってペアプロを実際にやってみる。
結構な量の課題が小分けに出題されていて、
それをTDDで出来る所まで実際にペアプロで開発していくというスタイル。

ハンズオンの時間は1時間30分。
これがかなり楽しくて、もっとやりたかったなーという感じ。
何はともあれ、おかげでTDDのプロセスがようやく腑に落ちた感じ。

コードレビュー

書くだけで終わりじゃなくて、実際に全員の前でコードレビュー。
どのようなプロセスで課題に取り組んだか、どこで詰まったか等の説明とともに ペアプロで書いたコードの発表。
Javaだったらprivate関数の頭にアンスコ付ける必要あんまないよーとか
そこプリミティブ型の方がいいよーとか
そこチェック例外書かなくても大丈夫だよーとか
色々ご指摘を頂いて沢山勉強させていただきました。

その後

すっかり触発されて、高くて買うのに悩んでいたTDD本を買ってしまった。

ついでに「act_as_professional」と書かれた TDDのグリーンバンドもゲットしてきた。
(* グリーンバンドは TDD関連の偉い人がテスト辛くなった時に「でも俺プロだろ！」って自分を戒めるためのバンドらしいです)

やったぜ＼(^o^)／

The post テスト駆動開発のハンズオンイベント「ミニTDDBC」に参加してきた appeared first on きのこる庭.

Tokyo Hacker Space?

東京にあるものづくりのためのコミュニティ。

ホームページ見てると結構ハード寄りのことしてるみたい。

参加には月会費が必要だけど、月に何回か一般向けにもイベント開催してるっぽい。

コミュニティスペース自体も工具とかいっぱい並んでるガレージみたいな感じでものづくり精神がかき立てられる。

というわけで人生初のハードを体験。

これがRaspberry Pi本体。Ethernet端子やらUSB端子やらイヤホンジャックやらHDMI端子やら色々ついてる。

ワークショップでは8GBのSDカードを挿して「Raspbian」というDebianベースのOSを使用。

IPアドレス経由で、MacからSSHでログイン。GUIもサポートされており、「オーバークロック」やら「ロケール」やら「カメラとの連携」やら色々設定可。

Lチカしてみた。

Lチカ… LEDをチカっと光らせるハード界のド定番らしい。プログラミング言語で言う「Hello World」みたいな感じ。

「ブレッドボード」と呼ばれるものにLEDと電気抵抗を挿して、Raspberry Pi本体と接続。

(この時配線を間違えるとヘタすればショートするらしい。例えば 3.3V用のLEDを5Vのジャックに繋げちゃうと死ぬとか )

光らせる時は以下のようにササッとシェルで命令を渡す( 何回か引数指定間違えてエラー出してるのは内緒 )。

gpio/value を “1″にすると、

チカッ。

うおーーー！！！！！！

感動。

因みに連続した命令を書く事も可能で、ちょっと繰り返し構文とかを書いてあげるだけで、5回連続で1秒おきにつけたり消したりとかもしてくれる。書いたコードが即座にハードに伝わるのは何とも言えない喜びがある。

因みに、シェルだけじゃなくてPythonでも操作できる。

次は温度計つくるよ。

今度は「バックライト付ディスプレイ」と「温度計測機」を用意。

これらはジャックと接続するために接続部分を「はんだづけ」。

はんだごてなんていじったの、中学校でジャージ溶かして以来だな！ちょっと自信無いながらもうまくはんだづけできました。

実際にはんだづけが終わって ディスプレイと温度計測機をブレッドボードに装着し、本体と接続したものがこちら。

配線が結構ややこしかった！接続ポートごとに役割が決まってるから、間違ってるとうまく動かない。

そんなわけで接続完了して シェルを叩くと…

よっしゃあ！うまくできたみたいです。

今回でハードのいじり方の基礎の基礎を何となく理解できたので、今後も色んなデバイスと接続したりして遊んでみます。

The post Raspberry Pi ではじめてのLチカ体験 & 温度計制作 appeared first on きのこる庭.

というわけで 今回はRESTful Web APIs読書会(第三回)の参加報告を。

今回は主に「リソースの定義」と「HTTPリクエストの種類」と「安全性・べき等性」のお話。

・リソースの定義

リソースというと結構個人的に定義が曖昧で、データベースのデータとかがメインになるのかなと思っていたけど、どうやらRESTにおいて URIで表現されるものは全てリソースになるらしい。

そしてリソースの状態は以下の二つによって表現されうるらしい。

( 2013年12月1日改正、コメントより「リソースが（同じ状態で）複数の表現を持つ場合に、クライアントは望む表現をどのように指定するか、の選択肢である」といただきました。必ずしも二つではないということですね )

1. Content negotiation( 「内容ネゴシエーション」とも。HTTPリクエストとレスポンスから成るクライアントサーバ間のやり取り？ )
2. URI( Railsで言うと new とか edit とかでURIが分かれてるイメージ？ )

・HTTPリクエストの種類

・GET

最も一般的なリクエスト。クライアントがリソースの何らかの表現を得るためのもの。

・POST

クライアントが新たにリソースを作成するためのもの。

実際、HTMLでは「GET」「POST」しかサポートしていなかったのもあって、これまでの世の中の一般的なWebサービスはPUTやらDELETEやら何でもかんでもPOSTでやってた風潮があった( 因みに そういう場合は「overloaded POST」というらしい )けど、著者は非推奨している。

・PUT

主に既存のリソースの更新に使用される。

リクエスト対象は PUT /some_resource/hogehoge みたいな感じに成る。

PUTでPOSTの役割(新しいリソースを作成する)を果たすこともできる。その場合、クライアントが リクエストを投げるURIをあらかじめ知っている必要がある。

実例を挙げるとするならばWikiみたいな感じ。「hogehoge」についての記事を書こうと ユーザがリクエストを投げた際、既にリソースがあれば更新、リソースが無ければ新たにリソースをつくる みたいなイメージ。

・DELETE

リソースの削除。

・PATCH

PUTに似ているが、diff(差分)を取って 変更のあった部分のみ更新。

その他 LINK / UNLINK、HEAD、OPTIONS 等々。重要なのは上記に挙げた5つ。

結局どのメソッドを使えば良いかは それぞれのAPI提供者を取り巻くコミュニティに依存すると言ってよい。HTMLに準拠するなら「GET/POST」しか使えないだろうし、Railsなら「GET/POST/PUT/DELETE」だろうし、ファイルシステムのGUIとか関わってくるなら上記に挙げた例意外にWebDAVとか入ってくるだろうし。

・安全性、べき等性

・安全性

リソースが増えたり書き変わったり消えたり、リソースそのものに影響があるかどうか。

RESTの設計原則に基づく場合、GET は 安全である( あるURIにGETでアクセスしたらいきなりデータ消えちゃった！みたいなことが無い…とかそんなイメージ )。

・べき等性

あるリクエストを送った時に、常に同じレスポンスを保証するかどうか。

( 2013年12月1日改正、上記についてコメントより「 1回送っても複数回送ってもリソースの状態が同じであること」といただきました。レスポンスが常に同じではなくても良いみたいです )

GET, PUT, DELETE はべき等。

因みに、べき等性について は以下に示すように数学の計算から来ている概念だとか。

・DELETEの場合… ある数字に 0 をかけた場合、その後何回 0 をかけても 0 から変わらないというのと同じイメージで、あるリソースに対して一度DELETEリクエスト送ったらその後 レスポンスは 変わらない。

・GETの場合… ある数字に 何回 1をかけても最初の数値から変わらないというのと同じイメージで、あるリソースに対して何回GETリクエスト送っても返ってくるレスポンスは変わらない。

・気になった点など

Q.「複数条件で検索結果を絞る」みたいな実装をする場合に POSTを使ったりするけど、これってどうなんだろう

A. 上記で説明したoverloaded POSTにあたる。検索条件が長過ぎてGETじゃさばけない時にPOSTを使ったりとか。Googleの検索結果のURIみたいに一般的にはGETを使うらしい。

Q. 上記でGETを使う場合、RESTの特徴の一つである「シンプルなURI」の点でどうなんだろう

A. 「RESTful Web APIs」の著者が URIに関して 書籍ではあまり触れていない印象。URIに関してはそこまで重要視していない感じ？ なお、「RESTful Web Services」にもURI設計についての記載があるらしいのでそちらを参照すると良いかも。

・頂いたもの

オライリーのステッカー。JSでよく見かけるサイが左下に。飛び上がるほど嬉しかったです。

DevOpsの小冊子。今読んでいるデザパタの本と並行して読ませていただきます。

そしてRESTful Web APIs。ドキドキが止まらない。

今回もとても勉強になりました。

RESTやHTTPというと結構つかみ所の無い印象だったけれど、最近ようやくフレームを理解し始めた感じです。

そう考えると勉強会って 分からない部分や気になっている部分を参加者主体で共有したり議論したりできるからすごく良い機会だなって思いました。

次回のRESTful Web APIs 読書会は 11/28(木) 19:30- 。今から楽しみです。

The post RESTful Web APIs 読書会( 第三回 )に参加してきた appeared first on きのこる庭.

RESTful Web APIs 読書会 #2 に参加してきた。

RESTful Web API？

要約すると以下のような感じ。

・Webサービスだとハイパーリンクとかをたどって ユーザは目的達成できるけど、APIの場合って  多くの場合ドキュメントがWeb上に別個に公開されていて、URLだけ見てもわからない上に、ドキュメントを見ても個々の機能がどのように関連しているかがわかりにくいよね

・そもそも そういうWeb APIのあり方って 自己記述性の点でどうなの？(=RESTfulじゃないよね)

・自己記述的なものが含まれていて、最初のURLさえあれば使い方がわかるようなAPIが理想的だよね

そこで RESTful Web APIの著者は Collection+JSON というフォーマットを推奨している。

Collection+JSONとは？

JSONが汎用的でプレーンテキストを扱うものだとしたら、Collection+JSON とは JSONよりも限定的で 「Web上のリソースの検索可能なリストを公開するための規格」である。

HTTPヘッダでは Content-Type: application/vnd.collection+json という形で渡される。

RESTful Web APIs 著者がアクセスしたサイトのうち http://youtypeitwepostit.herokuapp.com/app/ にアクセスすると以下のようなJSONデータがGETできる(なお、このURLに関してはレスポンスのContent-Typeに上記の形式が返され、これは主要ブラウザが現在認識しないため ダウンロードが行われる)。

{
  "collection" :
  {
    "version" : "1.0",
    "href" : "http://youtypeitwepostit.herokuapp.com/api/",

    "items" : [
      {
        "href": "http://youtypeitwepostit.herokuapp.com/api/613856331910938",
        "data": [
          {
            "name": "text",
            "value": "Squid!"
          },
          {
            "name": "date_posted",
            "value": "2013-03-28T21:51:08.406Z"
          }
        ]
      }
    ],

    "template" : {
      "data" : [
        {"prompt" : "Text of message", "name" : "text", "value" : ""}
      ]
    }
  }
}

まず collection という属性があり、items には リソース一覧が返される。リソースにはhref、name、valueがついているが、これがリソースの自己明示性を保つのに一役買っている。

さらに、API経由で データのPOSTを行いたい場合どうすれば良いのかもこのオブジェクトの中に書かれていて、これがWebサイトで言うハイパーメディアの役割を果たしている(「template」の中に書かれたdata属性が持つオブジェクトの形式に沿ってPOSTを行う)。

この構造によって 従来のJSONが表現しづらかった「リンク」を表現できる。なるほど確かにRESTful。

“constraints can be liberating. ( 「制約」により自由になる )”

という言葉は特に印象に残っている。

次回の読書会は 11/14(木) 19:30 から。楽しみ。

(ところで、結局「Squid」って何だったんだろう)

The post RESTful Web APIs 読書会( 第二回 )に参加してきた appeared first on きのこる庭.