ボウリングゲーム

ひますぎてボウリングゲーム実装してた。

これはCoding Kataの一種で、ボウリングゲームのスコア計算をするのが目的ではない。Coding Kataというのは、達人プログラマー―システム開発の職人から名匠への道などで有名な
Dave Thomasさんが提唱した、プログラミングの練習法。このボウリングゲームのKataはアジャイルソフトウェア開発の奥義 第2版 オブジェクト指向開発の神髄と匠の技などの著者であるRobert C. MartinさんのWebサイトに詳しいやり方が載ってる。2008年くらいの角谷さんの発表にも少しのっていてわかりやすい(当時実演を見せてもらった)。

ボウリングゲーム以外に逆ポーランド記法電卓でやるパターンとかさがせばいろいろある。

Kataといってるのはまさに柔道の形のことで、Wikipediaによると、

形（型）（かた）による形稽古は日本の武道（日本の武術）では普遍的な稽古法であるが、柔道（柔術）では、技を掛ける「取（とり）」と技を受ける「受（うけ）」にわかれ、理合いに従って、決められた手順で技を掛け、受け止め、反撃し、それを反復することによってその理合と技を習得するものである。我が国の修行方法といえる

とある。これと同じで、決められたプログラムを決められた手順で実装することで、リズム感のあるTDDの開発や、テストライブラリの使い方や、効率のよいエディタの操作方法などの練習ができ、実戦でもすばらしいプログラミングができるようになるというものだ。

今回やったボウリングゲームは、なんか資料を見ながらちまちまやってたら一時間くらいかかったのだけど、練習するうちに10分くらいでできるようになってすばらしい生産性が得られる予定。ひまなときにどんどんボウリングゲームしていきたい。

Play Framework で開発用Webサーバと同時に grunt/gulp を起動する

手元の環境でWebアプリケーションを開発するために、複数のプログラムを手動で起動しないといけないのは面倒だ。たとえば、rackupとgruntを同時に起動しておかないと、lessやjsをコンパイルしながらページを表示できないという風だと、いつも両方が起動しているように気をつけないといけないし、そのこと忘れてしまってなぜかデザインが当たらないなどといって悩むはめになる。

RubyのforemanやPerlのProcletなどを使うと、複数のプログラムを同時に起動したり終了したりすることができる。先ほどの例だと、Procfileにrackupとgruntの起動コマンドを書いて、開発環境でWebアプリケーションを起動するときにはforeman startするということにしておけば、必要なプログラムがすべて起動しているという状態に簡単にできて便利だ。

一方最近自分は、Play Frameworkで開発をしてる。Play Framework では sbt から開発用のWebサーバを起動する。sbtの起動は時間がかかるので、sbt自体は起動したままにして、sbtのコンソールから、Webサーバを起動したり停止したりできる仕組みになっている。このような仕組みなので、foremanから直接Webサーバを起動するのは難しい。(できなくはないけど、都度sbtを起動しなおすことになるので遅い)

調べてみたところ、sbtとPlay Frameworkの機能をうまく使うと、Play Frameworkの Webサーバが実行されている間だけ、別のプログラムを起動することができるようだった(参考:Playframework 2.2 Grunt Runner · GitHub)。

Play Frameworkには playRunHooks というsbtのSettingがある。これにPlayRunHookというtraitを実装したobjectを設定しておくと、Webアプリケーションが起動するタイミングや終了するタイミングにhookをかけれる。sbtには別のプロセスを起動する仕組みがあるので組み合わせると以下のようになる。(参考にさせていただいた、Playframework 2.2 Grunt Runner · GitHubをちょっと汎用的にしてる)

// project/RunSubProcess.scala
import sbt._
import Process._
import Keys._
import play.PlayRunHook
 
object RunSubProcess {
  def apply(command: String): PlayRunHook = {
 
    object RunSubProcessHook extends PlayRunHook {
 
      var process: Option[Process] = None
 
      override def beforeStarted(): Unit = {
        process = Some(Process(command).run)
      }
 
      override def afterStopped(): Unit = {
        process.map(p => p.destroy())
        process = None
      }
    }
 
    RunSubProcessHook
  }
}

// build.sbt
name := "hoge"
 
// ... 中略 ...

play.Project.playScalaSettings
 
playRunHooks += RunSubProcess("grunt watch")

これで無事、Play FrameworkのWebサーバを起動するだけで、同時に別のプログラムも起動することができるようになった。余計なことをきにする必要が減って便利になった。

強いチームはオフィスを捨てるを読んだ

技術書レビュー

強いチームはオフィスを捨てる: 37シグナルズが考える「働き方革命」

強いチームはオフィスを捨てる: 37シグナルズが考える「働き方革命」

  • 作者: ジェイソン・フリード,デイヴィッド・ハイネマイヤー・ハンソン,高橋璃子
  • 出版社/メーカー: 早川書房
  • 発売日: 2014/01/24
  • メディア: 単行本
  • この商品を含むブログ (5件) を見る

原著はREMOTEという名前の本。リモートワーク最高という話をBasecamp(元 37 Signals。社名変わってたの知らなかった)の人が教えてくれる。気楽なお話なので、すぐ読める。rebuild.fm#35でも触れられていた本。

本書によると、オフィスに集まって仕事するのは、集中が乱されることが多いし、通勤も大変、住みづらい都会に住む必要もある。リモートで働くことにすれば集中出来る環境で、住む場所や時間にしばられず、効率よく仕事ができるらしい。職種にもよるものの、いろんな工夫をすれば、十分仕事はできるし、Basecamp社やいくつかの企業でも実際うまくやっているそうな。

リモートワークに対してよくあげられる疑問に対して、勢い良く答えている章がおもしろい。みんなが集まってこそ生まれる最高のアイディアがあるんじゃないか、と言う疑問に対しては、リモートでもアイディアは生まれることは、何度もあったし、仮に対面のほうがいいアイディアが山ほど生まれたとしても、企業がそれらをすべて処理できるわけではないと答えてる。リモートだと仕事をサボるのでは、と言う話についてはそもそもそういう人間を雇うのがおかしいというはなしで、勢いがある。

リモートワークすればすべて解決というわけではなくて、オフィスワークとはコミュニケーションのやり方は変えないといけない。コアタイムをきめて、全員がコミュニケーションできる時間を作ったり、チャットツールやビデオ会議ツールをうまく活用したり、いい感じのコラボレーションツール(ここでBasecampをご利用くださいとなる。WikiとかGithubみたいなイメージ)を使ったほうが良いらしい。

Basecampのひとがリモートワークを推進するのはそりゃそうだよな、と思いつつも、確かにずっとオフィスに引きこもって仕事をする必要がないとも思った。今のチームでも、朝に軽く相談したあとは、普段の仕事はだいたいIRCとHipchatとGithubの上で会話するのでなんとかなってる。少なくともコードを書く活動をする分には、家とかカフェとかでも仕事ができる気がする。とはいえ、新しいチームができたときにはじめに信頼関係を築くとか、ブースの真ん中に集まって雑談して、なんとなく問題を整理するとか、帯域の広いコミュニケーションに頼らないといけなかったことは結構あるので、そのへんはなんか工夫しないとダメそう。本書でも、たまには会わないと行けないっと書いてある。

いろんなツールが揃ってきたことで、スムーズにリモートワークできるようになって、自由に働けるなら、そんなにうれしいことはないという感じであった。

関西2014年春アニメ 放送時間まとめ

毎度おなじみの関西における今期のアニメの放送状況を表にまとめました。今回もしょぼいカレンダーのデータを利用させていただいています。予約設定時の確認などにお役立てください。今回からは、スマートフォンでも見やすいページ も用意しましたので、ご利用ください。

今季の関西最速は以下の5作品でした。

冬アニメの2作品に比べて今期は最速作品が多く、すばらしい期になりそうです。

やはりまずはキャプテンアースに期待です。STAR DRIVER 輝きのタクトのスタッフが再結集して作るロボットアニメということで、同じようにおしゃれな動きのロボットが活躍してくれるのでしょうか。どんなストーリなのかも期待です。

悪魔のリドルはNewTypeで連載中のコミックが原作で、高河ゆんさんの作品です。クラスメイトが全員暗殺者というストーリーの展開や、アクションシーンが楽しみですね。

selector infected WIXOSSはカードゲームを舞台にしたオリジナル作品で、WIXOSSというカードゲームがアニメと同時に実際に展開されるそうです。予告のCMは結構ダークな雰囲気なので、思ったよりシリアスなストーリーが楽しめそうです。

召しませロードス島戦記～それっておいしいの？はロードス島戦記好きの主人公がロードス島戦記を広めるために、ロードス島戦記の劇をする..という内容の三分アニメらしいです。あまり情報がないので、どういったアニメになるか、見てみて知れという感じですね。

それでは、関西の皆さん、今期もがんばりましょう。


この上に番組表が表示されていない場合は、@hakobe にお問い合わせください。

ドメイン駆動設計読んだ

技術書レビュー

エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践)

エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践)


ドメイン駆動設計読み終った。ドメインを中心に据えてソフトウェアを設計するための方法を教えてくれる本だった。設計の話なので、抽象度が高く、なかなか読み辛いけど、良い話がたくさんでてくる。この本で例にでてくるソフトウェアが経理システムだとか貨物の配送システムなどのエンタープライズよりだったので、はじめは自分のようなWebエンジニアとっては参考にしにくいかと思っていたのだけど、まったくそういうことはなく、たいへん参考になった。

ドメイン駆動設計でいうドメインとはソフトウェアが価値を生み出す問題領域のことだ。ドメイン駆動設計手法では、開発チームがドメインエキスパートと継続的に議論してドメインモデルをつくりあげ、ソフトウェア中でも同じドメインモデルを利用することで、チーム全体がドメインに対する知識を深めることを可能にし、理想的にはドメインを良くモデリングした有用かつ変化に強いソフトウェアが効率良く開発できる。(すごい)

この本が良かったのは、詳細レベルの設計テクニックではなく、アプリケーション全体をどのように設計するべきか、ということについてかなり詳細に説明してくれているところだ。これまでソフトウェアを設計するときにぼんやりとして捉えられていなかったところが、とてもよく整理されていて勉強になった。

例えば、第2部の”モデル駆動設計の構成要素”ではモデルをエンティティ、値オブジェクト、サービスなどの種類のオブジェクトに分類し、それらのライフサイクルはファクトリやリポジトリによって管理するという構成について教えてくれる。自分が設計しているコードのモデルが、それぞれどういった役割を意図していたものか、より整理された見方ができるようになった。

他にもドメインモデルをうまく取り扱えるように、継続的にリファクタリングする方法や、より複雑なシステムにおける設計戦略について紹介されている。ドメイン駆動開発の利点を分析するために、実例に基づいたアンチパターンが、都度、紹介されるのだけど、多くに心当たりあってなかなかつらい。しかし、なぜ悪いのか説明してくれるので、とても役立つ。

理想的な話に終始していないのもよい。時代はドメイン駆動設計や!とかいって、急激に設計を変えても良い設計にはならず、少しづつおかしなところを継続的にリファクタリングしていかなければならないという話や、もはや設計を変えることができないレガシーシステムになんとか対処する方法などについてもくわしく言及されていて、現実の問題に対応している。

自分がソフトウェアをつくる中で感じたり、これまでチームで議論してきた、設計上の難しい部分が、ドメインモデルを軸に次々と整理されて、目からうろこという感じだった。自分のように、これまでWebアプリケーションの設計をしてきた人にとっても、これまでうまくいった(あるいはうまくいかなかった)設計についての評価がたぶん見つかるので、ためしに読むと参考になると思う。急にすべての設計パターンを実際のプロジェクトに反映するのは難しいし、それこそ急激な設計変更になってうまくいかないだろうから、少しづつ実際の開発に生かしていきたい。

レジでの支払いのはなし

レジとかでお金を払うときに、支払う紙幣/硬貨の枚数が少なくて、かつ、お釣りの紙幣/硬貨の枚数が少ない、かっこいい支払いというのがある(適当)。あわよくば、かっこいい支払いをしようと思っていつもねらってる。なんか適当に言ってるけど、451円払う時に、適当に500円玉を渡すと10円x4枚+5円x1枚+1円x4円がお釣りになるのはイヤなので、501円を渡してお釣りを50円x1枚にしたりする、よくあるやつです。

451円請求されているときには、だいたい501円はらったら良さそうなのはわかる。では、例えば771円請求されている場合は、どうすれば最適な支払いになるかと考えると、801円か1001円か1021円かそのあたりかなーという感じですこし丁寧にしらべる必要がある。

小銭が関係する1000円以下の最適な支払いパターンくらいだと、機械的に全パターン調べられそうだったのでプログラムを書いてみた。以下のフォームに金額をいれると、どう支払ったら最適な支払いができるかわかる。ここで言ってる最適な支払いとは、レジの人に支払う紙幣/硬貨の枚数とおつりの紙幣/硬貨の枚数の合計が最小になるような支払いのことだ。お財布の中には、すべての種類の小銭が十分に入っているという前提で計算してる。(100円支払うのに1円玉100枚つかったりしない)

レジで771円請求された場合、おつりがないように771円払うのと、1001円払っておつりをもらうのと、1021円払ってお釣りをもらうのとでは、どれも同じ枚数だけの硬貨/紙幣がやりとりされる。支払う硬貨/紙幣の枚数とおつりの枚数はちがうので、あとは好みの問題ということになる。801円払う場合は、1021円と比べると支払い枚数が多くなってしまうわりに、お釣り枚数は変わらなく、最適とはいえない。なるほど〜

実際には、レジの前で支払いパターンの計算とかしてたら迷惑だし、財布のなかに入ってる小銭との兼ね合いを考えないといけない。そもそも、直感的な判断でだいたいなんとかなってるし、レジでの支払いでやりとりされる硬貨/紙幣の枚数が多少ちがったところで、だれも困らないので、まじでどうでもいい話だった。

金額をいれると、レジのまえでよくやってるお支払い行為に対応した数字が出てくるのはちょっとおもしろい。評価関数を変えれば最適の基準もいじれるので、とにかく財布の中の小銭を減らすストラテジーとか、モデルの改善の余地はある。がとにかくどうでもいい感じではある。