「Webアプリエンジニア養成読本」を読みました

Perlの話がほぼ出てこないこの本はクソ！！！！！ (嘘です．著者の1人にそう書けって言われたものだから……)

Webアプリエンジニア養成読本[しくみ、開発、環境構築・運用…全体像を最新知識で最初から! ] (Software Design plus)

Webアプリの着想・設計・制作・運用までバランスよくまとまっていて良い本だと思いました．この手の書籍で運用にまつわる話が載っているのは中々珍しい気がします．

1章

基本的なWebの技術 (HTTPとかServer-ClientアーキテクチャとかHTMLとか) の説明が優しく，わかりやすくて良いです．僕もWebアプリ触り始めの頃にこれを読めれば！！！！　という気持ちになりました．
また，「どんな言語を使うべきか」というところで「その言語を使っている身近な人がいるか，もしくは，コミュニティが活発か」という指標を示していて，大事だと思うとともにフェアだなーと思いました．重要な話だ．
あとGitHubの話題とかあってだいぶナウいですね．

2章 (PHP編)

PHP凄い！！
「とりあえずechoでエラー出してみよーぜー」とか，「$_GETぶっこもーぜー」とか，そういう悪いPHP的世界ではなく，もっと正常で，かつ清浄な，格好いい世界のPHPの話が展開されています．

「簡単な掲示板を作る」というイカニモな話題を通して内容が展開される訳ですが，ビルトインサーバやらパッケージマネージャやらテンプレートエンジンやらORMやら，とにかくPHPの近代的なイケてるツールをふんだんに取り入れていて格好良いです．PHPの入門書籍で名前空間を最初からちゃんと説明しているの良いですね．

また「イケてないPHP情報の見極め方」というコラムは非常に参考になります．他の言語にも通用すると思います．

あとGentoo向けにemergeでPHPをインストールする方法が書いてあってマニアック過ぎる！　Gentoo LinuxでのPHPインストール方法が載っている書籍はこれが世界で初ではないでしょうか．*1

2章 (Ruby編)

RailsではなくSinatraを使っていて，Railsがうまい具合に隠してしまって目にできない (しかしそこが重要だったりする) ところをあえて触る，という感じで好印象です．

Rubyの基本的な書式や，最近のRubyを取り巻くエコシステム等が網羅的に説明されており，Rubyを触った事が無い人や「さいきんご無沙汰だワ」という人でも安心して読めて良いなあと思いました．

ブックマークアプリケーションの制作という流れで説明が進みますが，これ読めば大体分かってめっちゃ便利．過不足がなくて凄い．

それにしてもActiveRecord便利過ぎる．そしてRSpecは強力だ……

3章

サーバ (IaaS) の契約 ，サーバの構築，そしてデプロイまでがスピード感ある感じで説明されています．冒頭で書かれている，「自分のサービスを知る」「どこがボトルネックになるかを認識する」「どれくらいの時間サービスがダウンしても許容できるかを把握する」といったことは非常に大切だと感じました．

手作業でのサーバ構築指南だけではなく，ChefやAnsible，またserverspecなどの自動化を支援するツールについても言及されておりバリューがある感じがします．

そして「SCP (FTP) でのデプロイは絶対やってはいけません」と書かれていて非常に力強く感じると共におや涙が……

4章

すごい，監視と測定まで話が広がっている！

サーバの監視手法と共に，監視項目の閾値例も乗っていて大変参考になる感じでした．うっかり蔑ろにしてしまいがちなロギングの話やバックアップの話も丁寧に説明されていてグッドです．
また，ベンチマークとチューニングといった実践的な話についても紙面が割かれており非常に勉強になりました．アプリケーションのどこから測定してどうチューニングするか，という事例が乗っていて大変参考になります．

総評

ムック本という特性上そこまで厚い本ではありませんが，それを感じさせないボリューム感があります．ひと通り体系的な知識が付くと思うので，Webアプリ触りたての人とかが読まれると良いのでは無いでしょうか．

ただ，この本にはSQLの話が載っていなくて，しかしながらSQLはカジュアルに「よう！」といった感じで，まるで友人の如く登場してくるので面食らうかもわかりません．なので，SQLについて勉強したい人はウェブサイトや別の書籍など，他の媒体を当たる必要があると思います．
また，この書籍ではソフトウェアのテストについて触れられていますが，どちらかと言うとテストライブラリをどう使うか，といった方法論的な話が主なので，理屈的な事を詳しく知りたい人も他の書籍等を参照する必要があると思いました．

この本読んでわからないことあったらすぐにググったほうが絶対に良いと思います．そのコンピュータは艦これのためだけにあるのではない．

そうそう

今週木曜日 (3/20) にこの書籍の発売を記念して、池袋のジュンク堂書店にてイベントを行われるそうです．

http://www.junkudo.co.jp/mj/store/event_detail.php?fair_id=4314

どうやらまだ会場に空きがあるとの事でしたので，興味の有る方は参加されると良いのではないかと思います．

以上現場でした．

*1:これ誰に刺さるんだろう？

Ukigumoの新機能一覧

https://metacpan.org/pod/Ukigumo::Server
https://metacpan.org/pod/Ukigumo::Client
https://metacpan.org/pod/Ukigumo::Agent

ゆるふわCIエコシステムのUkigumoですが，最近ひと通りアップグレードしたのでそれに伴って搭載された新機能について紹介します．

注意

Ukigumo::Server 2.0.0以降はDBのスキーマが変更されているので，テーブルのALTERが必要です．

ALTER TABLE report ADD compare_url VARCHAR(255) DEFAULT NULL;

などとしてやる必要があります．

Ukigumo::AgentがGitHubのWebhooksに対応した

/api/github_hookにGitHubのWebhookを飛ばしてやるとjobが登録されるようになりました．
つまり，GitHubのWebhooksの設定でhttp://your-ukigumo-agent-server.com/みたいな感じで宛先を追加してやるとWebhooksが飛んだタイミングでjobが登録されるようになります．便利！

GitHubのStatuses APIに対応した

こういうことが出来るようになりました．

ありていに言えばTravisのような事ができます．

.ukigumo.ymlに

notifications:
  guthub_statuses:
    - api_endpoint: https://api.github.com
      access_token: YOUR_ACCESS_TOKEN

などと書いてやると実現できるでしょう．
なおこのAccessTokenにはrepo:statusを操作する権限を与えられている必要があります．

Compare URLに対応した

commitの差分URLが出るようになりました．*1
こういったURLがテスト結果のページに出ます: https://github.com/ukigumo/Ukigumo-Agent/compare/caa6fb3bed2ce584ec05c98a15a8f0ec85f2af18...5a378c84459f2b8a94e05635e4a125f5f34d9658

保存するテスト結果の最大数を設定出来るようになった

今までは無制限にテスト結果を保存していましたが，この変更で最大保存件数を設定出来るようになりました．

設定ファイルに以下のように書くと，最大件数を設定することが出来ます．

{
    max_num_of_reports_by_branch => 10,
    max_num_of_reports => 200,
};

max_num_of_reports_by_branchはブランチごとに保存する最大の件数で，max_num_of_reportsは全体の最大保存件数です．

最大保存件数を超えた場合，古いものから削除されていきます．

テスト結果の内容を圧縮できるようになった

テスト結果を圧縮して保存できるようになりました．

設定ファイルに

{
    enable_compression => 1
}

などと記述して，enable_compressionを有効にしてやると，テスト結果を圧縮するようになります．

……という感じでGitHubとの連携に寄せた変更が多く入りました．
ご利用ください．

*1:GitHubしか対応していない気がする

“Perl::Lint - Yet Another Static Analyzer for Perl5”というタイトルでTPF助成金に応募しました

I proposed a tpf grant. I’m waiting for your feedback! #perl #tpf http://t.co/PUJLf4VIOR

— セカイ系 (@moznion) 2014, 3月 16

The Perl FoundationのGrants Committeeのルールが変わったそうで，折角の良い機会なのでGrantにProposalを出してみました．
TPF Grants Committeeのルールの変更については次の記事を参照してください．
TPFによるPerl助成金の交付の変更等について : D-7 <altijd in beweging>

提出したProposalの詳細は以下です．
http://news.perlfoundation.org/2014/03/grant-proposal-perllint---yet.html

ざっくりとこのProposalの内容を説明すると……

目的

Perl::Criticは大変素晴らしいモジュールであり，Perlで書かれたコードの品質向上に一役買っている．しかしながら現状のPerl::Criticは処理が重く低速である為，気軽にCritic処理を回す *1 ことに対する心理的障壁は高い．
そこで本プロジェクトではPerl::Critic互換の新しく，なおかつ高速なモジュールであるPerl::Lintを作成する事を目的とする．

手法

Perl::Criticはソースコードの解析にPPIを利用している．PPIとはPure Perlで記述されたPerlの解析器 (Tokenizer & Parser) のことである．Perl::LintではC++で記述されておりPPIよりも高速なCompiler::Lexer並びにCompiler::Parserを解析器として使用することによって高速化の実現を図る *2 *3 *4．
本プロジェクトに類似した応用例としてPerl::MinimumVersion::Fastが存在する．当該モジュールはCompiler::Lexerを使用しており，PPIを使用しているPerl::MinimumVersionと比較して30倍程度の高速化を実現している *5 *6．したがって本プロジェクトでも同様の効果を期待できる．

……という感じになっています．

TPFのブログ記事の方で目下フィードバックを受け付けている最中ですので，ご意見ご感想などをお待ちしています．
よろしくお願いします．

なお，Proposalの作成にあたっては@lestrratさんに大変なご助力を頂きました．ありがとうございます． (具体的に言うと，僕の書いた破滅的な英語もとい英語とも呼べない代物を牧さんに適切な形に翻訳し直し……というかもはや書き直して頂いた上に，内容に関しても多くの助言を頂きました)

*1:例えばエディッタの保存時にHookして処理するなど

*2:Perlと出会い、Perlを作る

*3:YAPC::Asia Tokyo 2012で発表してきました | mixi Engineers' Blog

*4:YAPC::Asia 2013で発表してきました - goccyでごっしー

*5:Compiler::Lexer をつかって Perl::MinimumVersion::Fast をかいてみた - blog.64p.org

*6:https://github.com/tokuhirom/Perl-MinimumVersion-Fast/blob/master/author/benchmark.pl

コードレビューポエム

これはポエムです (It's just like a unko)．

■

「なぜコードレビューをするのか」という問いに対する答えは様々だ．コードの品質を上げるため，コードレビュー自体が楽しいから，あるいはコードレビューやってる俺たちって恰好良いじゃん，などなど色々ある．
これらは全部正しいと思う．コードレビューをすればコードの品質が高くなる可能性は強まるだろうし，「コードレビューが楽しい」という感情がコードを書くための原動力になるのであればそれは良いだろうし (なぜならコードレビューをするにはレビュー対象たりえるコードが必要だ)，「コードレビューやってる俺たちって恰好良いじゃん！」というのも結構だ．貴方がたは本当に恰好良いヨ！

さて，コードレビューという話題に必ずついて回る尤もらしい理由の1つである「コードの品質向上」について考えたい．

なぜコードレビューがコードの品質を上げるための手段としてここまで人気なのか．
例えばコードレビューではなく，書籍を読んでそこから得られた知見で品質を上げることは出来ないのか．或いは他のプロジェクトのソースコードを読んで，そこから学び，活かすことは出来ないのか．さてこれらは反語だ．多分可能だと思う．長い時間，極端な例だが1年かければ確実にその対象のコード (例えば1 issue分のコード) の品質を最高にほど近い水準まで持っていけると思う．

しかし期日の無いプロジェクトなど無い．仮に全ての開発メンバーが各々1つのissueに1年もかけてしまってはビジネスは破滅する．我々に要求されているのはスピード感だ．

つまりあけすけに言うと，「コードの品質を向上させるため」っていう大義名分は重要な接頭辞を省略していて，これを省略せずに言い換えると「短期間でコードの品質を向上させるため」になると思う．

我々はコードを書く時に思考する．いつだってこれが最善かどうか悩むし，不安になる．そのまま自問自答を繰り返しても良いが，そうしている間にも納期は陽気にやってくる．
そのように1人悶々とする時期も必要かもしれないが，やはり我々に求められているのはスピード感と最高のグルーヴだ．所属しているプロジェクトのドメインに詳しい仲間に質問して，意見を求めて，相談して，そして実装を始めたり洗練させたりしたほうが早く解決する可能性が高い．

つまり「最短距離で」なおかつ「高品質で」突っ走る為にコードレビューは必要なのだと思う．そしてそれがウケているから人気なのだとも思う．

従って，その最短距離を目指しているはずの「コードレビュー」で奇妙なところを指摘して，迂回させるのはまったく意味が無い．しっかり本質を見極め，そこに力を割かなければならない．コストを下げる為の活動なのに，逆にコストが上がってしまってはならない．

文字だけでコードレビューしてると (例えばGitHubのWeb UI上とかで) こういうことは起きがちで、そもそも文字ベースのコミュニケーションは話題が本筋から逸れた時に元に戻しにくい傾向にあると思う．変な議論が始まるとずっと変な議論を続けがちになるから良くない．そういうのを避けるためにも，毎回とは言わずとも，そこそこの頻度で実際に対面してコードレビューは行なったほうが良いと思う．

さて，最小のコストで高品質を求める皆さんならもうお察しでしょうが，最小のコストで高品質を獲得出来るならコードレビューをしなくても良い．例えば「1+1 = 2」みたいなコードに対してレビュー出来る事は少ないと思うので，こういうところにコードレビューのコストを割くべきではない *1．コードレビューをすることによって生じるコストと，そのコードレビューによって得られる利益とを比較検討しなければならないと思うけど，そこら辺難しいですよねという感じ．相談すべきか，相談せざるべきか，という問題になってしまう．まあ悩むくらいなら誰かに相談すれば良いと思うんですが．

その辺のバランス感覚を養いたいものです．

*1:数学の怖い話はよそでやってくれ！

App::GitHubWebhooks2Ikachanが出た

長い名前だ！！！　そしてマニアック．
https://metacpan.org/release/App-GitHubWebhooks2Ikachan
https://github.com/moznion/App-GitHubWebhooks2Ikachan

これは何

GitHubのWebhooksを受け取って，いい感じにしてIkachanに投げる君です．
現状，issues，pull_request，issue_comment，pushの各イベントに対応しています．

雰囲気としてはこんな感じの通知がIRCに飛ぶ．

[issue opened] This is new issue (@moznion) https://github.com/moznion/sandbox/issues/13
[comment (#13)] foobar (@moznion) https://github.com/moznion/sandbox/issues/13#issuecomment-37093289
[push to master] Commit1 (@moznion) https://github.com/moznion/sandbox/commit/b4da12df1bc19d2b20d7ab8a11fe9a4413ddf509
[push to master] Commit2 (@moznion) https://github.com/moznion/sandbox/commit/e2e64cea713dbfb574f1ace80a4be6c55f98433d
[pull request opened] New Pull Request (@moznion) https://github.com/moznion/sandbox/pull/15

GitHubのWebhooksの詳細については以下などを参照いただくと良いでしょう．
http://developer.github.com/webhooks/
http://developer.github.com/v3/activity/events/types/

使い方

まず何はなくともサーバを立ち上げます．
CPAN経由でこのアプリケーションをインストールするとgithubwebhooks2ikachanというコマンドがインストールされるのでそれを使って以下のように立ち上げるのが良いでしょう．

$ githubwebhooks2ikachan --ikachan_url=http://your-ikachan-server.com/notice --port=12345

この時，ikachan_urlは必須です．portはオプショナルです．デフォルトだと5555番ポートが使われます．

次にGitHubのWebhooksを登録します．
リポジトリの設定のところから“Webhooks & Services”を開いてWebhooksの設定を行います．
「どのイベントの時にWebhook送ってほしい？」って部分は“Send me everything”にしておけば良いと思います．

肝心のPayload URLは以下のようになるでしょう．

http://your-githubwebhooks2ikachan-server.com/${path}?subscribe=issues,pull_request&issues=opened,closed&pull_request=opened

${path}の部分は通知を送りたいIRCのチャンネル名になります．
つまり，http://your-githubwebhooks2ikachan-server.com/%23foobarとか書いておくと，#foobarにメッセージが飛びます．

クエリパラメータのsubscribeの部分は通知を飛ばして欲しいイベント名をコンマセパレ―テッドで指定できます．
例えば，subscribe=issues,pull_requestと書くと，issuesイベントとpull_requestイベントだけ通知するようになります．
このパラメータを省略した場合は，対応しているイベントすべて *1 のWebhookが飛んできた時に通知します．

issuesとpull_requestパラメータは通知を飛ばして欲しいアクション名をコンマセパレ―テッドで指定できます．
例えば，issues=open,closeのように書くと，issueがopenされた時とcloseされた時にだけ通知を飛ばすようになります．
パラメータを省略した場合はすべてのアクションに対して通知します．

いろいろ

本当はissuesやpull_requestとかだけではなく任意のイベントを差し込めたり，NotifierをIkachanだけではなくて他のものに差し替えられたり，出力フォーマットを好みの形に変更できたりする予定だったんですが，複雑性が増す上に利用側に結構な量のconfigを書いてもらわなければならなくなったので，今の形に落ち着きました．

「このイベントが取れないとは何事だ！」みたいなお叱り等ございましたら，Issueなどに登録していただけると対応しますのでよろしくお願いします．

*1:つまりissues，pull_request，issue_comment，push

CUDAプログラムがsegvする時の対処法

1. デバイス (つまりGPU) のドライバのバージョンを最新にする
2. CUDA処理系のバージョンを最新にする (とはいえバージョンを上げるとカジュアルに後方互換が壊れるので注意が必要)
3. それで駄目なら書いたプログラムが悪いので頑張って直す

デバイスのドライバがおかしい場合であってもsegvという形でしかエラー内容が目に見えないのは不親切極まりない感じですが，諦めましょう．

「システム環境設定」でアイコンがグレーアウトしてる項目について設定したい

Mac OS Xの話です．

権限の都合上，「システム環境設定」のアイコンがグレーアウトしていて，その項目に関して設定出来ないことがあります．こんな感じ．

この場合だと，「セキュリティとプライバシー」と「共有」がグレーアウトしていて設定が出来ません．

どうするか

以下のコマンドを実行して，NSPrefPaneGroups.xmlファイルを移動します (実際は削除でも良いんですが)．

$ sudo mv /Applications/System\ Preferences.app/Contents/Resources/NSPrefPaneGroups.xml /Applications/System\ Preferences.app/Contents/Resources/NSPrefPaneGroups.xml.orig

すると，「システム環境設定」が以下のように変化します．

オゥ，なんてこった！！！　アイコンが全部なく無くなっちまった！！！
しかしご心配なく．上のツールバーの「表示」を選ぶと……

設定項目がズラっと表示されます．そしてなんと，グレーアウトしていたはずの項目が設定できるようになっている！
便利！！！！！！！

あるいは

$ sudo cp -R /Applications/System\ Preferences.app ./Ura\ System\ Preferences.app
$ sudo rm Ura\ System\ Preferences.app/Contents/Resources/NSPrefPaneGroups.xml
$ open ./Ura\ System\ Preferences.app/

などとしてやって，System Preferences.appをコピーして，そのコピーしたappからNSPrefPaneGroups.xmlを取り除いてやると同様の効果が得られます．

とは言え

セキュリティ等の観点から設定できないようにグレーアウトさせているケースが多いと思うので，悪用は厳禁です．