Hatena::ブログ(Diary)

naoyaのはてなダイアリー

March 18, 2014

HBFav の不具合が直りました

HBFav で新着ブックマークが正しく取得できない不具合が発生しています - naoyaのはてなダイアリー で報告しました HBFav の不具合ですが、はてなブックマーク本体が修正されたことにより HBFav 側もこれまでどおり動作するようになりました。

ご利用の皆様にはご迷惑をおかけしました。また、修正にあたったはてなスタッフの皆様に感謝申し上げます。

引き続き HBFav をよろしくお願いいたします。

March 15, 2014

JAWS DAYS 2014、Immutable Infrastructure について

何もかも投げ棄てて Dark Souls II をやりたい気持ち抑えながら JAWS DAYS 2014 で Immutable Infrastructure について話してきました。以下、資料です。(Embed できないのでリンクです)

https://speakerdeck.com/naoya/immutable-infrastructure-number-jawsdays

Immutable Infrastructure トラックのトップバッターだったので、そもそも Immutable Infrastructure とは何か、どのような背景でこのような概念が提唱されるに至ったのか、そして現在は。またこれから何が変わるのかみたいな、大枠の話にフォーカスして話しました。会場は Immutable Infrastructure トラックは立ち見が出てるくらい盛況で、やはりこの分野に注目が集まってるのだなと実感しました。

続けて 3/25 にも Immutable Infrasturcute Conference #1 があります。こちらの方は聴衆の顔ぶれがまた JAWS DAYS と少し異なりそうなので、開発プロセスと関連づける形で話してみようかなと思います。とはいえ、こちらもオーバービュー的な役割だし結構かぶるかもしれない。

ちなみに、講演中 Immutable Infrastructure / Infrastructure as Code と発音するのに10回以上噛みました。

March 13, 2014

HBFav で新着ブックマークが正しく取得できない不具合が発生しています

HBFav で一昨日ほどから、新着ブックマーク取得時に正しく取得できない、具体的にはすでに表示済みのエントリが二重に表示されたり、新着で取得したものが更新すると消えてしまう、という現象が発生しています。

こちら、昨晩にはてなブックマーク本体側から報告のあった以下の不具合が原因である可能性が高いです。

HBFav ははてなブックマーク本体の、お気に入り機能の API (RSSフィード) からデータを取得している都合上、本体側での不具合の影響を受けることがあります。

経過は以下の Github Issue でも議論されています。

ご不便をおかけしますが、回復までしばらくお待ち下さい。

# 中の人ガンバレ

些末なコードレビュー

朝起きて布団から出るのがつらいので、HBFav をつらつらと眺めていた。

あるサービスの JavaScript が重いとか、そのコードが難読化されてないとか、担当者とおぼしき人間が書いたコメントがそのまま残ってるから消しましょうよとか、そんなことが書かれていた。JavaScript が重い、という話は結局そのサービスの JavaScript が重かったのではなく、ユーザーが自分で導入した広告が重いというだけの話だった。

コードが難読化されていない、趣味の製品ではなく会社の製品なのでコメントそのまま残ってるから消しましょう・・・実にくだらない。

ところで話は変わってコードレビューについて。

コードレビューに慣れないチームが、何の考えもナシにコードレビューを始めるととにかく気になったこと大小様々な指摘が行われることになる。一見、いろいろな指摘が出て議論が活発になっているように見えるが、だいたい議論が紛糾しているのは「コードのインデント幅が違う」とか「return が省略されてる。俺は return があったほうが好み」とか「その場合は字下げをした方が綺麗にみえるんでは」とか、そんな些末なことばかりである、ということが多い。必ず一度は通る道である。

そんなことを延々議論していたって、はっきり言って何の意味もない。何の意味もない、は言い過ぎにしても、そんなところを改善したところで実質的な品質は何ひとつ上がらないわけだし、どうしても揃えたいなら lint ツールか何かで機械的にチェックすればよいことであって人間がやることではない。

やらなければいけないのは、「その設計は拡張に対して開いていないから開くべき」とか「これではエッジケースが想定されていないからこういう不具合につながるのでは」とか「そのテストでは後日見返したときに第三者が要求仕様を解釈しづらい」とかそういう指摘である。これらはちゃんとコードを読んで、コードの構造を把握して、そこに書かれているコード以外のシステムの全体感が頭に入っていて、初めてできる指摘である。当然、それをするにはレビュワーにも知識とスキル、そして真摯な態度が要求される。

JavaScript にコメントが残っているからダメだ、なんてのはインデント幅が2じゃない、4にしろ、と言っているようなものである。自転車置き場の議論を読むべき。難読化は、しなければいけないというものではない。仮に難読化ではなくソース圧縮だって速度的にそこが律速ならするべきだが、多少の JavaScript の文字数を減らしたところで、他のファイルとのサイズあるいは gzip 圧縮との相対感からいくとその効果はハナクソみたいなものであることがほとんどだ。

インデントがとか、コメントがみたいな指摘をしているのを目にすると、くだらない、と妙に腹が立つ。

なんで腹が立つのだろうか。

それは過去の自分がまさにそれそのものだったからだ。人間、他人に腹を立てるときは、そいつがあまりにも自分に似ているか、そいつが過去の自分・・・自己嫌悪の対象だった自分と重なってみえるからだ。自分の実力のなさをごまかすため、自分を大きくみせたいがために、些細な指摘をする。そのコメントは必要ないとか、if 文の条件の書き方がなってないとか、そこの括弧は省略できる、とか。そしてそんなことで優位に立ったと、自分を大きく見せられたと、思いこんでいる。やがて時が経ちいろいろ経験を積んだ頃になって、当時周りの先輩たちは、お里の知れてる自分を生暖かく見守ってくれていただけであることに気づくのである。

追記

自分は元のエントリを明確に批判しているが、それが原因で話があらぬ方向に行くのを避けようと思い敢えてどのエントリかは書かなかったが、この記事が拡散される中、それこそ要らない誤解を招きそうなので追記する。

そしてはてなブックマークのコメントへの反応その他を見ていると「コメントが残っていたことではなく、コメントの内容に問題があったのが問題なのでは」と指摘があった。自分は、上記エントリを読んだがコメントの「内容」のどこに問題があるのか全く理解できなかった。

パスワードなど、何かユーザーやこのサービスに不利益になることがコメントに書かれているのか? 古いコメントが残っていてコードの動作と反するような記述になっているのか? コメントが原因で、そのほか悪影響を及ぼすようなことはあるのか。見た限り、そんなことはなさそうだ。もしそのようなコメントであれば、それは当然コードレビューでも指摘するべき。パスワードが云々のような本当の意味で致命的なものなら、第三者がインターネット上などで指摘することは重要だと思う。

一方、このエントリに書かれているのは「恥ずかしいコメントを書いちゃだめ」「趣味ではなく会社の製品なんだからコメント消しましょう」「コピペと言わずに共通化」と言いましょうというような指摘で、いずれもどうしてそうしなければいけないのか自分にはわからない。むしろ「些細なエラーなので無視する」というコメントなどは現在 console に出ているエラーは無視しても構わないと開発者が判断しているというヒントになるのであり、そのコメントがあることが有益であるとすら感じた。

はてなブックマークの方では「コメントの内容が致命的にひどい」とあるが、本当に致命的にひどいのであれば、何か致命的な問題が起こるだろう。そのようなことが起こっているのか。また、一企業がコメントで意図をあけすけにするのは微妙だから、というのは全く賛同できない。なぜ隠す必要がないようなことまで、無難な方に倒して、隠す必要があるのか。

コードレビュー中にコーディング規約に類することには意味がない、と書いた。一方「意味がないとも言わないが」とも書いた。意図としては、本来設計そのほかもっとレビューしなければいけない項目があるのに、規約についてばかり議論していてもしょうがない、それは木を見て森を見ずだということを述べている。当然、初学者の新人がインデントもコメントもぐちゃぐちゃなコードを書いてきたらそれはレビューで指摘するべきだし、レビュイー本人の成長にもつながる。それは程度の問題である。

本記事を読む各人が置かれている環境・・・まわりに規約を全く守れない開発者がいる、規約すらない、などいろいろな状況があるとは思う。その自分の環境に重ねていろいろ想像されることは各人の自由だと思うので、そのことについては特に思うことはない。すくなくとも、自分の場合も、自分の周囲の開発者のスキルや傾向などを想定・前提として書いている。

自分が暗黙的に想像としているサービスは自社開発のWebサービスであり、顧客に納品するミッションクリティカルな業務アプリケーション、ではない。元になったエントリもまた、自社開発のWebサービスについて論じている。(この一文は対象ドメインが違うと作法も異なるであろうという意図で書いたが「ミッションクリティカル」は余計な要素だと感じたので del とする。決して自社開発Webサービスは品質を犠牲にしてよいと言っているわけではない)

追記2

上記2エントリのうち、後者 id:hevohevo さんに関しては、コメントの内容については問題がなく肯定的であると論じています。それに関して、上記2エントリどちらもが批判的なエントリを書かれていると、本エントリの読者の方に受け取られかねない記述をしてしまったことをお詫びいたします。

id:hevohevo さんのエントリで私が賛同できない部分は、「会社のプロダクトなのでコメントは隠そう」「miniftyすべき」という点です。その賛同できない理由については前述の通りです。また、私は賛同できないが id:hevohevo さんにはコメントを隠す、minify するということには理由があろうということは追記されていました。(いずれにせよ、私はそれにはあまり賛同できません。minify すべきか、コメントを隠すべきかはその開発チームのポリシーや優先度で決まることであり、どちらが良いかという一般論ではないと思っています。)

ご迷惑おかけしました。

February 12, 2014

Rebuild #29 でアプリのレビューをして欲しいと話したらたくさんレビューが来た

@miyagawa の Podcast (まあ、このブログを読んでくれてる人にはわざわざ説明するまでもない) である Rebuild #29 で、iOS アプリのレビューの話になって、自分が作ってる HBFav も☆5個のレビューくださいね、と冗談半分で言ってたら、きづいたらレビューが50件近くついてました・・・!

f:id:naoya:20140212200243p:image:w320

Podcast、出てみるもんですね! w

引き続き、☆5レビューをお待ちしてます。

January 27, 2014

Github を使って雑誌原稿を書く

今日はこのあと Github の Tokyo Drinkup January 2014 に行くのだが、先方から、もしかしたら 10分ほど Github について話してもらうかも、と打診された。話すか話さないかわからないが、もし話すとしたらと仮定し内容の整理も兼ねて以下「Github を使って雑誌原稿を書く」ということについて書いてみようと思う。

「Github を使って雑誌原稿を書く」もしくは「Github を使った雑誌編集者とのコラボレーション」について、である。

Web+DB PRESS の連載

ご存知の方もいるかもしれないが、このところ技術評論社の Web+DB PRESS で連載をしている。連載を始めて、もう一年近く経った。以前にも Perl に関する連載をしていて、そのときも数年ぐらい続けたので、間があきつつも、なんだかんだでそれぐらいの付き合いになる。

最近は特にテーマは決めずに、隔月ごとに、そのとき旬な物あるいは自分が強く興味がもっていることについて書いている。RubyMotion の話を書いたかと思えば、serverspec の話を書いたりとかそんな感じ。もし良かったら読んでみて下さい。宣伝終わり。

Github 以前

数年前の当時、まだ Github が世の中にリリースされるかされないか、その頃の雑誌原稿のやりとりは基本メールだった。連載〆切りが近づいてくると、編集者さんから「そろそろいかがですか」的なメールがきて、あとはそのメールをピンポンしながらやりとりをする。原稿も適当なフォーマット (当時ははてな記法)で書いて、メールに添付して送る。

しばらく待っていると、原稿が PDF になるなり何なりして、そこから校正作業が始まりなんどかやり取りしたところで完了となる。

まあ、特にこれで何か特段困ったことがあったかというと実はそういうことはなかった。

当然、原稿そのものは手元で Subversion、その後 Git でバージョン管理はしていたし、Github を使うようになった今でもコミュニケーションのピンポンを繰り返してやりとりしていって校了となる・・・というフローそのものは変わっていない。

Github 以降

このメール時代の頃から原稿を Git で管理することはしていたけれど、それはローカルだけの話でリモートに push したりはしていなかった。

それを、今回の連載を開始するにあたり、そろそろ Github もコモディティになってきたことだしということで、担当の @inao さんに github に push するからそこでコミュニケーションしてみませんか、と提案した。ただ、このときは特に深い狙いはなく、どうせ手元でバージョン管理してるんだからリモートに上げるのもすぐだし、メールに添付するよりはそっちのほうが共有が楽とかそのぐらいしか考えてなかった。

それが、Github を使い始めてから作業のやり方に色々とアイデアが出てきて、今では原稿は Markdown で書き、お互い基本的に Pull Request で飛ばす方法が定着した。Pull Request はいわゆる「Working In Progress」な WIP Pull Request として出す。つまり、原稿を書き上げたところで Pull Reuqest するのではなくて、いきなり Pull Request を出してしまってあとはその Pull Request に、原稿の進捗に合わせてコミットを重ねていく。

このブログで再三にわたって紹介しているが、WIP Pull Request については

このスライドが分かりやすいと思う。

Pull Request で原稿をやりとりする

以下がその WIP Pull Request の様子。簡単な TODO を共有し、少しずつ原稿を追加していっている様子が伝わると思う。編集者は「naoyaさん原稿書いてますか?」とかメールを送ってこなくても、進捗が把握できる。途中でレビューを加えようと思えばいつでもそれは可能だ。

f:id:naoya:20140127180235p:image:w640

原稿をやりとりするフローでは、最初は著者側にボールがあって、PDF化の作業なんかが始まるとボールは編集側に移る。PDFを確認するタイミングになると著者側にボールが移る。その繰り返しである。そして、自分と @inao とのやりとりでは、Pull Request を出した側がそのボールを持っているという関係になっている。

例えば、ぼちぼち著者の手元での原稿が固まってきたな・・・という頃に @inao がその Pull Request をメインブランチにマージする。マージした段階で「あ、向こうにボールが渡ったな」というのが分かるのでこちらはレビュワー側に回る。

以下はその、編集側から飛ばしている Pull Request。

f:id:naoya:20140127180420p:image:w640

コミットログを綺麗に整理してくれているので、こちらも、自分の原稿にどんな修正が入ったかがよくわかる。ああ、結構 typo 編集してくれてるんだなとか、用語統一とか、読みづらいところを校正してくれてるんだなとか。今だから言えるが、以前メールで作業していたときは、こういう細かい所まで作業してもらっているということにあまり気づいていなかった。

Git をお互いに使っている、という利点が活きる場面も結構多い。

例えば現在の原稿はちょっと書きすぎてしまってページ数がその分確保できるか怪しいという話があって内容を少し削ったのだが、仮にページ数を確保できた場合には元に戻そうという話をしていて、実際確保できそうだったので削除コミット自体を revert して元に戻す、なんてことをした。メールでやりとりしていたときは、こういうコラボレーションはなかなか難しかった。

f:id:naoya:20140127181332p:image:w640

このように、Github + Pull Request の利点を上手く活かして編集とやりとりすることができている。

自分たちはそこまでやっていないが、知人のエンジニアは、Jenkins を回して git push の度に PDF のビルドとか用語統一とかそういうのを自動化しているなんて話もしていて面白かった。

わかったこと

メールでやりとりしていたときにも、そこまで困ったことはなかったけれども、Github にしてからはずいぶんとやりやすくなった。

Pull Request による進捗とコミュニケーションの一本化

色々と良かったところはあるのだけれど、ざっくりいうとそれはお互いの作業状況が見えること、そしてその作業状況にコミュニケーションがうまく集約されることとだと思う。

Pull Request ベースの開発をしたことがある人ならよくわかると思うが、Pull Request は単にパッチを取り込んでもらう依頼が簡単になるということだけでなく、その Pull Request のスレッド上でコミュニケーションを重ねることで、作業進捗とコミュニケーションが一つにまとまった形で可視化されるところがすごく良い。大袈裟にいえばワークフローとコミュニケーションの一体化、とも言える。

雑誌原稿の執筆作業のワークフロー自体は、関連する人間は2人から3人程度だしシンプルなのだけれども、その昔メールでピンポンしていたやり取りが原稿の commit や typo の修正といった一つ一つの作業と関連づけられる形でスレッドになるのは、後日見返したときにすごく安心感がある。どちらが作業のボールを持っているかも明確になるし、数日おいて原稿の状況を確認するにあたって「どんな議論になってたっけかな・・・」というのを思い出すのも Pull Request の状況を見るだけでほとんどストレスなく思い出すことができる。

元々 Github を使い始めた当初は Pull Request ではなく、Issue で原稿の進捗を管理していた。@inao から、〆切り日にあわせてこの日までにアウトラインが欲しいとか、これこれを終わらせてくださいとか、その単位で Issue を切っていた。でも、実際には個別の Issue にするほどそれぞれの作業は独立していなくて、基本原稿書きは逐次で物事が進んでいくので、WIP な Pull Request に一本化してその上でやりとりしていくほうが面倒もすくなく、且つ分かりやすかった。

こうして作業が可視化され、ストレスなく状況を把握しやすくなったことによって、著者と編集者の間でのちょっとした行き違いみたいなことがだいぶ少なくなった。結果的に「ああ、こんなに自分の誤字脱字を編集してくれてるんだな」とか今まであまり気づいていなかった作業についても自覚することができるようになり、より良い信頼関係を築くに至っている・・・と @inao は知らないけど、自分は思っている。

Github がソフトウェア開発以外で活きてくる可能性

そんなわけで、Github はソフトウェア開発の分野以外にも、コラボレーションが必要な領域で色々と応用の可能性を持っている、と自分は思っている。

実際、昨年 Github が資金調達をした際に今後はいろいろな分野に Github を広げていくみたいな話をしていたように記憶しているので、そういう利用シーンもこれから増えていくのではないかと思っている。雑誌の原稿編集だけでなく、自分でも気づいてない分野の応用例なんかがでてくることをとても期待している。

問題は、@inao のように Git と Github を使いこなせる編集者が世の中にほとんどいない、という点ではないかという話があるのだがそれについては今は考えないでおくとしよう。