まじか...
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シグナルズが考える「働き方革命」
- 作者: ジェイソン・フリード,デイヴィッド・ハイネマイヤー・ハンソン,高橋璃子
- 出版社/メーカー: 早川書房
- 発売日: 2014/01/24
- メディア: 単行本
- この商品を含むブログ (5件) を見る
原著はREMOTEという名前の本。リモートワーク最高という話をBasecamp(元 37 Signals。社名変わってたの知らなかった)の人が教えてくれる。気楽なお話なので、すぐ読める。rebuild.fm#35でも触れられていた本。
本書によると、オフィスに集まって仕事するのは、集中が乱されることが多いし、通勤も大変、住みづらい都会に住む必要もある。リモートで働くことにすれば集中出来る環境で、住む場所や時間にしばられず、効率よく仕事ができるらしい。職種にもよるものの、いろんな工夫をすれば、十分仕事はできるし、Basecamp社やいくつかの企業でも実際うまくやっているそうな。
リモートワークに対してよくあげられる疑問に対して、勢い良く答えている章がおもしろい。みんなが集まってこそ生まれる最高のアイディアがあるんじゃないか、と言う疑問に対しては、リモートでもアイディアは生まれることは、何度もあったし、仮に対面のほうがいいアイディアが山ほど生まれたとしても、企業がそれらをすべて処理できるわけではないと答えてる。リモートだと仕事をサボるのでは、と言う話についてはそもそもそういう人間を雇うのがおかしいというはなしで、勢いがある。
リモートワークすればすべて解決というわけではなくて、オフィスワークとはコミュニケーションのやり方は変えないといけない。コアタイムをきめて、全員がコミュニケーションできる時間を作ったり、チャットツールやビデオ会議ツールをうまく活用したり、いい感じのコラボレーションツール(ここでBasecampをご利用くださいとなる。WikiとかGithubみたいなイメージ)を使ったほうが良いらしい。
Basecampのひとがリモートワークを推進するのはそりゃそうだよな、と思いつつも、確かにずっとオフィスに引きこもって仕事をする必要がないとも思った。今のチームでも、朝に軽く相談したあとは、普段の仕事はだいたいIRCとHipchatとGithubの上で会話するのでなんとかなってる。少なくともコードを書く活動をする分には、家とかカフェとかでも仕事ができる気がする。とはいえ、新しいチームができたときにはじめに信頼関係を築くとか、ブースの真ん中に集まって雑談して、なんとなく問題を整理するとか、帯域の広いコミュニケーションに頼らないといけなかったことは結構あるので、そのへんはなんか工夫しないとダメそう。本書でも、たまには会わないと行けないっと書いてある。
いろんなツールが揃ってきたことで、スムーズにリモートワークできるようになって、自由に働けるなら、そんなにうれしいことはないという感じであった。
関西2014年春アニメ 放送時間まとめ
毎度おなじみの関西における今期のアニメの放送状況を表にまとめました。今回もしょぼいカレンダーのデータを利用させていただいています。予約設定時の確認などにお役立てください。今回からは、スマートフォンでも見やすいページ も用意しましたので、ご利用ください。
今季の関西最速は以下の5作品でした。
- 悪魔のリドル
- selector infected WIXOSS
- キャプテン・アース
- 召しませロードス島戦記~それっておいしいの? (TOKYO MXと同時)
- シドニアの騎士
冬アニメの2作品に比べて今期は最速作品が多く、すばらしい期になりそうです。
やはりまずはキャプテンアースに期待です。STAR DRIVER 輝きのタクトのスタッフが再結集して作るロボットアニメということで、同じようにおしゃれな動きのロボットが活躍してくれるのでしょうか。どんなストーリなのかも期待です。
悪魔のリドルはNewTypeで連載中のコミックが原作で、高河ゆんさんの作品です。クラスメイトが全員暗殺者というストーリーの展開や、アクションシーンが楽しみですね。
selector infected WIXOSSはカードゲームを舞台にしたオリジナル作品で、WIXOSSというカードゲームがアニメと同時に実際に展開されるそうです。予告のCMは結構ダークな雰囲気なので、思ったよりシリアスなストーリーが楽しめそうです。
召しませロードス島戦記~それっておいしいの?はロードス島戦記好きの主人公がロードス島戦記を広めるために、ロードス島戦記の劇をする..という内容の三分アニメらしいです。あまり情報がないので、どういったアニメになるか、見てみて知れという感じですね。
それでは、関西の皆さん、今期もがんばりましょう。
この上に番組表が表示されていない場合は、@hakobe にお問い合わせください。
ドメイン駆動設計読んだ
エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践)
- 作者: エリック・エヴァンス,今関剛,和智右桂,牧野祐子
- 出版社/メーカー: 翔泳社
- 発売日: 2011/04/09
- メディア: 大型本
- 購入: 19人 クリック: 1,360回
- この商品を含むブログ (130件) を見る
ドメイン駆動設計読み終った。ドメインを中心に据えてソフトウェアを設計するための方法を教えてくれる本だった。設計の話なので、抽象度が高く、なかなか読み辛いけど、良い話がたくさんでてくる。この本で例にでてくるソフトウェアが経理システムだとか貨物の配送システムなどのエンタープライズよりだったので、はじめは自分のような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円と比べると支払い枚数が多くなってしまうわりに、お釣り枚数は変わらなく、最適とはいえない。なるほど〜
実際には、レジの前で支払いパターンの計算とかしてたら迷惑だし、財布のなかに入ってる小銭との兼ね合いを考えないといけない。そもそも、直感的な判断でだいたいなんとかなってるし、レジでの支払いでやりとりされる硬貨/紙幣の枚数が多少ちがったところで、だれも困らないので、まじでどうでもいい話だった。
金額をいれると、レジのまえでよくやってるお支払い行為に対応した数字が出てくるのはちょっとおもしろい。評価関数を変えれば最適の基準もいじれるので、とにかく財布の中の小銭を減らすストラテジーとか、モデルの改善の余地はある。がとにかくどうでもいい感じではある。
unite-scriptがUnite.vim本体に取り込まれました
ずいぶん前につくった unite-script が、先日リリースされた Unite.vim の ver 6からscript sourceとして本体に取り込まれました。今後は、別にunite-scriptをインストールすることなく、script sourceが利用できます。
unites-scriptはずいぶん長い間メンテナンスが滞っていて、ご迷惑をおかけしていたのですが、今後は本体機能として安心してご利用いただけます。取り込みなどほとんどの作業は、Unite.vimの作者の@Shougo さんにやっていただきました。ありがとうございました!!
そもそも、unite-scriptは、unite.vim の source をお好きなスクリプト言語で書ける unite-script - はこべブログ ♨ という記事ではじめて登場した、Unite.vimのsourceの1つです。自由なスクリプトを実行し、その実行結果をUnite.vimに表示してアクションを実行できます。
例えば、以下の様なスクリプトを準備することで、Githubの通知をvimから表示することができます。
このscriptを実行すると以下のように、項目名と、選択されたときのアクションがTAB区切りで一行ごとに標準出力に表示されます。この場合はgithubからの通知の内容と、スクリプト自身にURLを渡して起動するアクションがTAB区切りで一行ごとに表示されています。
$ ruby /path/to/github-notify.rb list [htmlcatgo Issue] 色付けに対応 call unite#util#system('ruby /path/to/github-notify.rb open https://api.github.com/repos/hakobe/htmlcatgo/issues') [unite-script-examples Issue] CPANモジュール依存を取り除く call unite#util#system('ruby /path/to/github-notify.rb open https://api.github.com/repos/hakobe/unite-script-examples/issues/7') [unite-script-examples Issue] 売りになりそうなおもしろいscriptを思いつく call unite#util#system('ruby /path/to/github-notify.rb open https://api.github.com/repos/hakobe/unite-script-examples/issues/6')
このスクリプトをUnite.vimのscript sourceで利用するには以下のようなコマンドを実行します。
:Unite script:ruby:/path/to/github-notify.rb list
これで 以下のようにvimからGithubの通知を確認できるようになりました。自分のPullRequestのレビューが進んだかどうかなどがvimからすぐに確認できるので大変便利です。
このスクリプトを動作させるには、~/.unitescriptrcにyamlで設定を記述する必要があります。くわしくはscript内のコメントを御覧ください。Github Enterpriseにも対応しています。
こういう調子で、仕様にしたがって出力を組み立てるだけで、いろいろなものをUnite.vimに表示できて便利です。ぜひお試しください。これまで公開されていた以下のようなスクリプトも利用できます。(ありがとうございます > 公開いただいていた方々)
- Unite.vimでChromeのブックマークを表示するスクリプトを作った · THINKING MEGANE (monochromeganeさん作)
- unite-script使って unite-script-favstar(python) してみた - mizchi log (mizchiさん作)
- bookmarks.pl はてなブックマークの人気エントリをUnite.vimで表示/アクセス
- gmail.pl Gmailの受信箱のメール一覧を表示/アクセス
- itunes.pl iTunesで現在再生しているプレイリストの曲を一覧/再生(Mac用)
script sourceがUnite.vimで利用できることになったのに伴い、unite-scriptのリポジトリはunite-script-example として、script source用の便利なスクリプトをあつめるリポジトリにしましたので、おもしろscriptができましたらぜひPull Requestしてみてください。
個人的には itunes.pl が便利で気に入ってます。(Macでしか使えません)
どうぞご利用ください。
2014/02/14 追記
Shougoさんから教えていただいたところによりますと、Unite.vimのscript sourceに指定できるコマンドは、vimのruntimepathからの想定パスで指定できるそうです。
ですので、.vimrcに
NeoBundle 'hakobe/unite-script-examples'
のように書くと、.vim/bundle/unite-script-examplesがruntimepathにはいるので、.vim/bundle/unite-script-examples/examplesにはるスクリプトを以下のように利用できます。
:Unite script:ruby:examples/github-notify.rb
パスの解決をする必要がなくて、大変便利ですね。