2017-06-07

YAPC::Fukuoka 2017ではてなブログの開発の話をします

来てくれ!!! 20分でこういう話をします．アジェンダ詰めすぎた感もあるので急いでしゃべる感じになりそう．

はてなブログは2011年にリリースされ，2016年に5周年に突入，今年6年目になりますが，まだまだアクティブに開発しています．
日々の開発を通じてうまくいった設計テクニックや，失敗したテクニックや，そのために開発したツール，などの開発テクニックと，それを使った，リモート開発を支える技術，未来に向けて考えていることなどを紹介します．
2015年までの話は2015年のYAPC::Asiaで話したので，それ以降の話や，そこでは話せなかった最近の最新の話をします．

話せるといいこと

以前からのはてなブログの雰囲気を軽く紹介

アプリケーションの設計でうまくいった話や，試したけどイマイチだった設計の話

開発を支援する便利グッズやリリースを楽にするツールやbotの活用の話

リモート開発をうまくやるための取り組みの話

品質を維持するための普段の活動の話

未来に向けてこういうことをやりたいという話

YAPC::Fukuoka 2017 HAKATA - Timetable

九州行ったことないので楽しみです．福岡というと，小学生の高学年くらいまで青森の隣にあるものだと思い込んでいた．福井と混同していた(そして福井も青森の隣にはない…)．

2017-06-07

フードプロセッサーほしい

料理の大半の時間は材料を切る時間で，加熱する時間はわりとすぐだったり，放置したらできたりする．

セロリとにんじんとにんにくと玉ねぎ，とかチマチマ刻んでるとまな板から離れて飛んで行ったり床にポロポロこぼれたりして悲しい気持ちになる．

また，たいていの物体はとりあえず粉砕できればあとは加熱するだけで食べられそう．

なのでフードプロセッサーほしい!

masawada.hatenadiary.com

papixさんがキーマカレー簡単に作らててよさそうだった．

tsukurioki.hatenablog.com

2017-06-06

指定されたURLを開いていってHTMLとしてパースしてCSSセレクタがマッチしたらURLを出力するやつ

URLがたくさんあって，この中で，ソーシャルボタンを含むのはどのURLなのか? というときに目視で見ては疲れるので，ちょっとしたスクリプトを書いてみた．
たとえば，ブログのいろんなページのうち，twitterのwidgets.jsをロードしているのはどこなのか? というとき

% cat urls.txt
http://blog.sushi.money/
http://blog.sushi.money/about
http://blog.sushi.money/entry/futa
% cat urls.txt | bundle exec -- ./grep-by-css-selector 'script[src="//platform.twitter.com/widgets.js"]'
http://blog.sushi.money/
http://blog.sushi.money/entry/futa

こんなかんじで，トップページと，記事ページ，ということが分かる．
単なるテキストのgrepと比べると，指定されたURLを開いてくれるところと，CSSセレクタを使えるところが違う．

github.com

2017-06-06

めっちゃいいアカウント

良すぎる
twitter.com

毎日勉強！
— ルフィ【勉強垢】フォロバ100% (@queen_student) 2017年6月5日

レベルの高い大学に行くんだ！
— ルフィ【勉強垢】フォロバ100% (@queen_student) 2017年6月5日

2017-06-05

人月の暗黙知の本

本

見積りについて興味が出てきたので読んだ．コードコンプリートを書いたスティーブマコネルの本．
具体的な見積りの技法が紹介されているけど，それよりも，いい話がたくさん書いてあって良かった．

見積りとターゲット見積り=作業量とか規模とかターゲット=いつまでにほしいとか
- 数ヶ月後の発表会のための開発なら，その規模のものは作れませんではなく，間に合うような物を一緒に考える
- 技術的な知識を使っていろんな代案を出すのは技術者の責任
即興で見積りしてはいけない→正確ではない
専門家の判断は品質が低い→正確ではない
計算できるなら計算しなければならない
見積りに幅を持たせるこの期間で終わる確率は何%とか，最良で何週間，最低で何週間，とか
- そのときも計算する
高く見積るとプロジェクトが却下されるからといって安く見積ってはいけない
- 正しい情報を提供できないので，意思決定できなくなってしまう
- リソースが本来コストに見合うプロジェクトから，コストに見合わないプロジェクトに流れてしまう
見積りについての議論では交渉ではなく問題解決するパイの奪い合いではなく，テーブルにいる全員が勝つか負けるか
- 最後の章が良かった

僕は「普通にやるとこの日までにはできます，すごく急げばこのくらい」みたいな話をよくしていて，見積りとコミットメントを一緒に話していた．2日で終わる作業だけど，他のタスクのすき間にやるので1週間かかります，これだけやればうまくいけば2日です，みたいな．
どちらが良いか分からないけど，最速ではここ，最悪でここ，みたいな話をできるとよいかもしれない．しかし，最良の場合と最悪の場合を伝えると，まさか最悪の状態に至るとは思いにくい，俺たちはいつでも最高でしょ，みたいなイメージもありそう．
よく言われてることだけど，過去のデータを取っておいて見比べよう，という話があって，簡単でもいいのでデータ貯めていきたい．ところで，規模をどう見積るかという話もあって，GitHub時代ならpull requestのdiffの行数とかだと見やすいけど，コンパイルすると増えるファイルなどが混ざっていると難しくなりそう．そしてたいていコンパイルすると増えるファイルはけっこうな勢いで増えたりする．そういうものはリポジトリから除いていきたい(すでにだいたい除いている)．
Kindleで読める．おすすめです．