2011年12月 togetter.com blog.sushi.money ■ - hitode909の日記 見做さ あっっまっっっみ忌みな皆様社会みんん皆様，帰宅したので日記を みなさ，みなさ，皆様，帰宅しましたので，日記をaaaaaaaaaaaaaaa更新いさっっしいしまししっっっ死さいました，しました2011/12/27 00:56 b.hatena.ne.jp 2015年3月 blog.sushi.money 2016年9月 ← NEW! benevolent0505.hatenadiary.com 我々はこの悲劇を決して繰り返してはならない． wei wei wei wei— みきお.pm (@benevolent0505) 2016年9月7日

ざっと見てよさそうなの探したのでしばらく過ごせそう． SCRUM BOOT CAMP THE BOOK 作者: 西村直人,永瀬美穂,吉羽龍太郎出版社/メーカー: 翔泳社発売日: 2013/04/13メディア: Kindle版この商品を含むブログ (2件) を見るアジャイルな見積りと計画づくり ?価値あるソフトウェアを育てる概念と技法? 作者: Mike Cohn出版社/メーカー: マイナビ出版発売日: 2009/01/29メディア: Kindle版この商品を含むブログ (1件) を見るWrite Great Code〈Vol.1〉　ハードウェアを知り、ソフトウェアを書く 作者: Randall Hyde出版社/メーカー: マイナビ出版発売日: 2014/06/03メディア: Kindle版この商品を含むブログを見るWrite Great Code〈Vol.2〉　低いレベルで考え、高いレベル

ヤパチーで聞いた話で，古いissueはとりあえずcloseして，やっぱりやるとなったらまたopenする，というのがあった． ノリでKotlin化するというissueを入れたのだけど，テンションが下がってきたので，やめませんかってなってcloseする，とか． これは良いと思って，古いissueは単に古いというだけで価値が減っていきそう． すぐにやらないと困るようなら，古いissueがopenのまま置いてあるということはまずい状況で，そうでなければ，やらなくてもいいということで，openで置いてあるのは邪魔で，次に何をやるべきなのか分からなくなってしまう． また，当時とは状況が変わってきて，実はやらなくてよくなった，みたいなものもある． 誰かが意識的にissueの治安を維持しないと，どんどん増えていって制御できなくなってしまうと思う． ふだん仕事でやってるプロジェクトでは，たまに棚卸しするのだ

取り組むべき課題を見極めたのちに，解の質を上げていきましょう，という話． 解決してもうれしくないとか，解決したかどうかの定義が明確ではない，とか，そういうのはイシューではない． がむしゃらにどうでもいいタスクを大量にこなしても，あまり良い状態にはならなくて，大事なタスクを1個こなすほうが価値がある． クックパッドの井原さんが書かれてた記事を思い出した．何かに取り組むときには三つの輪があって，自分がやりたくて，かつ得意で，会社としてもやるべきことをやろうという話． よくこの図を思い出して普段から便利に使っていて，このタスクとあのタスクだと，こっちのほうが重なり度が強いから，こっちからやったほうがうまくいきそう，とか． やるべきことの見つけ方とそのときに一番大事なもの - ihara2525's blog ソフトウェアだと，コアドメイン以外のところをリファクタリングしまくっても良い結果は得られ

ひどいコードは何やってるか分からない ひどいコードが何やってるか分かっても、なぜそうなってるのか、そこを変えるとどうなるか分からない ひどいコードは新たな変更に耐えられず書き直されることになる ひどいコードを書き直すには、ひどいコードがどうなっているか理解し、どこを変えるとどうなるのか理解する必要がある ひどいコードはたいていひどいテストコードが支えていて、テストコードがあったとしてもひどいコードと同様の問題があり、頼れるものが何もない どんなにひどいコードでも、書いた人を憎んではいけない。たとえ自分の書いたコードだとしても、先輩の書いたコードだとしても、ソフトウェアとしてひどい物にはひどいと言っていくことが大切で、だからと言って人に向かってひどいと言ってるわけではない。 最高の仲間たちが日々変化する難しい問題に対処していいコードを書いたり、ときにはひどいコードを書いている、という😇的な

仕事のコードで，子クラスがたくさんいる難しいクラスがいて，継承関係を整理したいけど，どこがどうなってるのか一見すると分からなかったので，静的解析してクラス図をレンダリングするやつを作った． github.com package2plantumlclassdiagramっていうコマンド(長い)に，このファイルたちをレンダリングしてくれ，って渡して，PlantUML形式のファイルを作る PlantUMLでPNGとかに変換 という手順で使う． % package2plantumlclassdiagram ~/Plack/lib/**/**.pm > plack.plantuml % GRAPHVIZ_DOT=$(which dot) plantuml -charset UTF-8 -tpng plack.plantuml Plackのソースコード全体をレンダリングするとこんなかんじで，継承してる

ソフトウェア作ってるとどうしようもないひどい状況になったり、知らないプロダクトを読んだらひどい状況になってたりすることがあって、どんなときにそういうことになるのか、必ずそうなるのか、そうなることを予見できないか、完成したソフトウェアを見てひどいかどうか判定できるか、とか気になってる。 作ってる途中に気付けないものか 作る前に気づけることはあるかひどいのは分かってるけどやるしかないときにだけひどいものができるのか時間はあるけどやる気がないとそうなるのかプライベートでなんかあるとそうなるのか書いてから時間が経つと大体のものはそうなるのかコードは正しくて読者が使われてるパターンに理解がないだけなのかパターンの使い方が変だと読めなくなるのか当時と環境、社会情勢や実行環境、データ量、などが変わってひどくなるのかいい技術が発明される前なのでしかたないのかいい技術が発明されたときにキャッチアップすべきか

Domain-Driven Design Reference，Amazon見てたら発見して，安かったから買ってみた． ぺらっとしてて，ポケット索引集みたいな雰囲気．エリックエヴァンスのドメイン駆動設計から，要約が抜粋されていて，70ページくらいで，重要な概念を押さえられる．原著は著者の経験を語ってくれるコーナーが大半を占めるけど，この本ではバサッと切られて，定義だけが載ってる． 前の本から10年くらい経ったので，新しい内容も増えてる．ドメインイベントとパートナーシップ，巨大な泥団子．いずれも実践ドメイン駆動設計に出てきた． これだけ読んでドメイン駆動設計さあ始めよう，とはならないだろうけど，でかい本読みたくないけど議論には参加したい，とか，どんなものか軽く眺めたい，みたいな人が読むにはてっとり早いかもしれない． 唯一役立ったのが前書きで，エリックエヴァンスのドメイン駆動設計の本のことをTh

画像に集中線を入れてアニメーションGIFにしてくれるウェブサービスを作りました!!!集中線GIFメーカー!!! speedline.herokuapp.com 見慣れたおにぎりを持った男性の写真から，こんなGIFが作れます!!! 高級寿司が流れるだけでも，とにかく!!勢いがある!!!!! 歴史上の人物も!!!本人は動いてないのに勢いがある!!!! 今すぐ無料でお使いいただけます!!!!! speedline.herokuapp.com 追記 意外とみなさまに使っていただいていて，サーバーが重くなっているようです．失敗しても，しばらくしてやり直すとうまくいくかもしれません．どんどん使ってください．

YAPC発表で，良い本を紹介しました オブジェクト指向入門 これは最高の本です 下巻はいま在庫なかったので困る オブジェクト指向入門 第2版 原則・コンセプト (IT Architect’Archive クラシックモダン・コンピューティング) 作者: バートランド・メイヤー,酒匂寛 出版社/メーカー: 翔泳社 発売日: 2007/01/10 メディア: 単行本（ソフトカバー） 購入: 11人 クリック: 307回 この商品を含むブログ (132件) を見る オブジェクト指向入門 第2版 方法論・実践 (IT Architects’Archive CLASSIC MODER) 作者: バートランド・メイヤー,酒匂寛 出版社/メーカー: 翔泳社 発売日: 2008/08/29 メディア: 単行本（ソフトカバー） 購入: 5人 クリック: 97回 この商品を含むブログ (52件) を見る ドメイ

YAPCでおもしろ発表してきた． はてなブログの開発を振り返って設計の進化と最高の設計を紹介するという話． speakerdeck.com なぜか大人気発表みたいになってて，会場満員で，すみませんこんなところに来ていただいてすみませんというかんじだった． 紹介した本はこちら．予約投稿で仕込んであって，発表終わったら，こちらから買ってくださいとかやろうと思ってたけど，すっかり忘れてた． YAPCの発表で紹介した本 - hitode909の日記 質問たくさんいただいて，よいかんじにおさまったと思う． 「難しくて挫折するという問題がありますよね」「歯を食い縛って実装しろって書いてあった」 #yapcasiaE— そらは (@sora_h) 2015, 8月 21 Q: 「コメントの良い書き方は？」 A: 「オブジェクト指向入門下巻に書いてあります」 ↓ 「買って読みます。」 #yapcasiaE

大きめのこととか，自信のないところを触るときは，コード書く前に，こういう作戦考えてみたけどどうですかって聞いてみたり，こういうことやりたいんだけど一緒に考えませんかって，いっしょに話して設計考えたりするとよいと思う． 一緒に考えたすぐあとに気が狂った設計とか言い出したらおかしいので，未然に変な設計のままコード書いてしまうのを防げる． 特に辛い気持ちになるのが、「気が狂った設計」「クソコード」「（こんな実装は）有り得ない」といった言葉だ。 Pull Requestのレビューが辛くて会社をやめたい 単に言葉が強いのはよくないと思う．我が社にはそんな強い言葉でレビュー書く人はいない． 我が社には，普段から強い言葉を発する人もいなくて，みんな物腰柔らかな変な言葉を話している． 言葉使いや文体は，ずっと過ごしてると同僚から移ったりするので，普段からそういう言葉を話していると，全体の雰囲気も悪くなりそ

だいぶ前のはてなインターンの講義で，JavaScriptの講義をしたのだけど，そのときの課題で，マウスストーカーを作る，というのを出題した． 教科書は公開されていて，課題はこのへん． https://github.com/hatena/Hatena-Textbook/blob/public2014/javascript-event-driven.md#課題2 インターン生たちがいろんなおもしろマウスストーカーを作ってくれて，おもしろかったのだけど，せっかく出題したので，僕も作ってみた． このページでも有効になってるので，マウスのボタンを押してみてください．ご迷惑おかけします． http://mouse-stalkers.github.io/the-best-stalker-ever/ こういうファンシーな見た目． GIFだと見ずらいけど，☆が飛んでくるっていうマウスストーカー．マウスダウン

これまで、きれいなコード書くにはどうしたらいいか考えてたけど、そんなことではいけないと思った。 ソフトウェアとして意味があるためには、誰もこれまでに書いたことがない、すばらしい働きをするコードでないといけない。 めちゃくちゃいい働きをするコードができたら、あとできれいにすればよい。誰にでもきれいにできるような些細なところはほっといて、本質的に難しいところを解決したほうがいい。 どんなにコードがきれいでも、正しく動かなかったり、使用に耐えないくらい性能が低くてはしかたがない。また、普通に動くソフトウェアは世界中に普通にあるから、それを超えるすごい便利さとか、使いやすさとか、他にこんなのはないとか、なんかそういうのがないと、作る価値はないと思う。 ということを思った。最近難しいことをいろいろやってて、夕方にはくたびれてくる。そこそこいいけど、まだめちゃくちゃよくはないから、もう一声という感じ。

Rubyでインターネットを巡回する本． いちばん簡単なのだと，Wgetで再帰的にダウンロードしてみましょうとか，Anemoneっていうクローラ作るためのライブラリとか，ThreadやEventMachineで並列に動かすとか． あとは，Rubyだからgemの便利グッズが紹介されていて，一番よかったのは，koalaっていうfacebookにアクセスするためのライブラリで，キラキラネームでまぶしい． 気になったのは，けっこうHTMLをXPathとかで取り出してスクレイピングしていることで，こういう方法だとしばらくすれば壊れそう．壊れたときに気付けるように結果もバリデーションしましょう，とか書いてあったけど，メンテナンスできるのか．それか，意外とマークアップ変わらなくて壊れないもの? スクレイピングというと2007年くらいにPerlの人たちがCPANでYoutubeをダウンロードとかいって喜んで

会社でボードゲームしてる人たちがいる。 僕はボードゲーム苦手で、たまにやっても全然勝てない。 将棋とかイメージすると、こっちがこういう手を出すと相手はどうするか、そしてその次は、というのを予測すればよいのだけど、なんかそれがめんどうで、なんでこんなこと考えないといけないのか、とか考えだしてくたびれてしまう。 ずっと論理的に考えるのが苦手で、すぐめんどうになってやめてしまう。 普段、仕事や遊びでソフトウェア作ってるのだけど、よく考えると、ソフトウェアの動作が論理的なだけで、ソフトウェア作るのは勘でできる。 ソフトウェアが正しく動くかどうかは論理的に決められて、電卓アプリなら計算結果が狂ってたら間違っているけど、その電卓アプリがどのように作られたか、には正しさはない。逆立ちして作っても、猿にタイプライターを渡して作っても、計算結果合ってれば良い。 過去のデータとか経験によると猿に書かせるのは効

弊社では毎年インターンを受け入れているのだけど，いまもインターンが来てて，テスト先に書きたいけど油断すると先に実装を書いてしまう，とか話してた． 個人的には，テスト先に書くのが大事というよりかは，意識して仕様を先に考えるのが大事だと思っている．テストを先に書くと，先に仕様を考えざるを得ないので，良いスタイルが身につく． 僕がよくやるのは，関連しそうなクラスの絵をひと通りノートに書いてみて，その図だけで，うまく動くことを説明できるくらい考えてみる．その時点でおかしかったら，コード書いてもおかしくなる．ノートに方眼ついてるとクラス図書きやすい．UMLとかじゃなくても，自分で見て分かるくらいでもいいと思う． 紙でうまくいったら，外部仕様だけソースコードに書いてみる．クラス名と，メソッドの定義と，メソッドの上くらいに，ひと通りコメントでも書いてみて，この関数はこういうことをするんです，こういう引数

プレゼン自分ではすべったことないから得意だと思ってるのでいつも気をつけてることをシェアします。これさえ守ればすべらないのだから楽。 目次 目次 最初にめちゃくちゃおもしろい話をする 箇条書きせず一行ずつページを分ける 絵をでかくする 新しいページ作ったらデフォルトのパーツを全部消す 先に言う 意見や疑問を述べる スターウォーズエピソード4を見る 最初にめちゃくちゃおもしろい話をする 聴衆は懇親会のことしか考えてないので、とりあえず最初におもしろい話をして、注意を引きつけるとよい。つかみはこれでオッケーだって言えればよいくらいの面白い話をしましょう。よくある技術ブログとか、技術雑誌だと、こんにちは、最近温泉に行って心身共にリフレッシュしました、ヒトデです、とか書いてあるけど、そんなの読んで喜ぶ人が本人と家族と親類以外にこの世にいたらおかしいから、そういうのじゃないとよい。 箇条書きせず一行ず

うちのチームでは，デプロイするたびに自動的にgitのtagを切るようにしてる．たとえば，いまデプロイしたら，deploy/2014-02-01-14-48とか． たまに，リリースした直後になんかミスってたことに気付いて，慌ててロールバックすることがある． tagを切ってるので，ひとつ前に戻せばいいのだけど，えっと，どれだっけとかいって探すので慌てるし，普段はタグ指定してデプロイしてないので，どうやって戻すか忘れる． デプロイ終わったときに，今回のデプロイを戻すには，これをしましょう，とか表示するようにした． デプロイ終わったらこんなのが出る．前回のデプロイが昨日だったら昨日くらいのタグが出る． ヒント：戻すときは以下のコマンドを実行しましょう cap -S revision=deploy/2014-01-31-15-17 deploy 実装方法としては，こんな感じに，デプロイ前に最新のタグ

コードレビュー，慣れるとできるけど，いきなりdiffを渡されて，どうぞ見てくださいと言われてもよくわからないと思う． やりましょうというのはいいけど，ただむやみに読んでもうまくいかない．変更がある程度大きくなるとdiffだけ見てもよくわからないので，いろいろ見ることになる． 僕はいつも以下のようなことを無意識にやってて，うまくいってる気がしてる．GitHubのPull Requestの仕組みを使ってる前提で． Discussionをさらっと眺めてどういう問題を解決したいのか見る Commit Statusを見て，テスト通ってることを確認する Commitsタブで1コミットずつブラウザの新しいタブに開く 全部クリックし終わったら古い順に1コミットずつ読む 気になる点があったらエディタとかにメモしておく．あとで書き直されるかもしれないので，まだコメントしない 全コミット見終わったらFiles