12月であるし、アドベントカレンダーが回っていたりして、よくできた興味深いブログの記事を目にすることが多い。 よくできた記事ばかり見ていると、自分もちゃんとしたものを出さなければ、となってしまうことがありそう。しかしちょっと待ってほしい。 ブログ記事、といっても、プロの編集の手が入ったお金のかかった記事、一人で頑張って書いた大作、チョロっと書いて出てきた日記まで様々なものがある。 100文字くらいで終わっているものもあれば10万文字くらい書かれているものもあるので、文量に1000倍の差がある。 映像の世界で1000倍の差を出そうとすると、2時間すなわち7000秒の映画と、スマホで撮った7秒の動画、くらいの差がある。 2時間で観れるすばらしい映画がなにかあるとして、 Amazon.co.jp: フォレスト・ガンプ／一期一会 (字幕版)を観る | Prime Video これの1000分の1の

三点見積もりでもやってみるか、という話になって、id:onkさんにおすすめされたので読んだ。PERT、Program Evaluation and Review Techniqueについて教えてくれる本。1965年の初版が電子書籍化されていておもしろい。 読んでたら、こんなの大学の授業でやったなってだんだん思い出してきた。 PERTは各タスクの依存関係をグラフにしたもので、見積もり時間を持っているもの。ガントチャートと違って、各タスクの依存関係や、遅れたときに全体に影響がある箇所や、余裕がある工程がどこなのかを可視化できる。 ja.wikipedia.org 以下は読書メモ ネットワークは関係者が集まって描く。お互いの意見を出し合って最高のプランがネットワークとしてまとまるのが良い点 見積もりトータルフロートが0であるパスがクリティカルパス。そのパス以外はフロートがあり、早くやっても仕方な

ふだんの開発では，稼働中のシステムに影響を与えないように開発中の新機能や新システムを共存させながらちょっとずつデプロイして進めている．どんな事を考えてやっているか記しておきます． フィーチャートグルを使う すべてのコードが本番環境に入っているけど無効化されている状態で開発を進める ブランチをたくさん作るのに対する考え方で，フラグを有効にすると開発中の機能を使える スタッフなら有効にしたり，フィーチャーのオンオフを選べる画面を作ってたこともある フィーチャーブランチを利用した開発はチームを継続的インテグレーションから遠ざける – ゆびてく FeatureToggle 完成したらフィーチャートグルに関係なく全員に有効状態にして完成 フロントエンドの施策で，実際のデータやインフラ構成でどれくらいスピードが出るかわからないときに，ひとまずフラグをオンにすると動く形でデプロイしたりとか レイヤの下の

プレゼンモード 再生 ← / →で移動 fでフルスクリーン escでおわる こんにちは，id:hitode909です．はてな・ペパボ技術大会 #4 〜DevOps〜 @京都において，「社内横断で開発効率を上げる取り組み」というお題で発表しています．この記事は，その発表資料です． 社内横断で開発効率を上げる取り組み はてな・ペパボ技術大会 #4 〜DevOps〜 @京都 hitode909 自己紹介 hitode909 株式会社はてな アプリケーションエンジニア 好きな本はオブジェクト指向入門とドメイン駆動設計 2009年〜 うごメモチーム 2012年〜 ブログチーム 2017年〜 マンガチーム 2018年〜 CTO室(兼務) アジェンダ CTO室での活動 特定のチームに閉じず，社内横断で開発効率を上げるための試み みなさん 学生の方? 🙌 社会人の方? 🙌 Devの方? 🙌 Opsの

ふだん開発してるアプリケーションのエラーの様子を見る仕組みを作って，ふだん便利に暮らせているので紹介します． BitBarについて BitBarはメニューバーにいろいろ出せるやつで，コマンドラインの標準出力をそのままメニューバーに表示できる． getbitbar.com プラグインを置くディレクトリが用意されていて，シェルスクリプトを置いていく．calコマンドを呼ぶだけのスクリプトを配置するとこんな感じで，そのままカレンダーが出る． sparkコマンドについて sparkコマンドはコマンドラインでスパークラインを表示するもので，標準入力で数字の列を渡すと，数字の列をグラフにして表示してくれる． 数字を正規化してから渡す必要はなくて，なんでもいいから数字を渡すとその形を教えてくれる． % echo '1 2 3 4 5 6 7 8 9 10' | spark ▁▁▂▃▄▄▅▆▇█ % ech

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

Plack::Middleware::PostErrorToSlackというのを書いた．これは何かというと，アプリケーションの例外を自動的にSlackに投げるやつ． 使い方は簡単で，Incoming WebhookのURLを設定するだけ．あとは例外を起こすだけ． enable "PostErrorToSlack", webhook_url => 'https://hooks.slack.com/services/...'; それで，Slackにこんなのが出る． 誰が，どのブランチで，何をしたら，こういうエラーが出ましたよ，というのがSlackに投稿される．uriメソッド呼びたいけどなんかおかしそう，とか分かる． これだと寂しいので，😇な絵文字などを設定すると，😇感が出て良くなる． enable "PostErrorToSlack", webhook_url => 'https://ho

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

将来的には ← 将来はない時間のあるときに ← 時間はない余裕のあるときに ← 余裕はない手の空いた時に ← 手は空かないこのフィーチャーはPhase 2で ← イテレーションはPhase 1で完結する誰かやっといて ← やらない# TODO ← やらない# FIX ME ← 自分で直すことになる気付いた人が直す ← 自分で直すことになる

長年の技術的負債で，あるネームスペース以下には，このオブジェクトを渡さず，このオブジェクトのフィールドの一部だけを渡したい，みたいな話があった．コンテキストオブジェクト全部渡すと，そのメソッドが何に依存しているか分からないので，必要な分だけ渡すべきで，最近は必要な分だけもらってるけど，昔書いた分は全部もらってて，混在しててきびしい状況だった． 静的解析して安全に置き換えられることを確認して，ソースコードの定義と呼び出し元を書き換えて，変更箇所のテストが通ったらcommitしてpushする，テスト失敗したら人間を呼ぶ，みたいなスクリプトを書いた．午前中にスクリプト書いて，午後に動かして，263コミット，280ファイル書き換えて無事リファクタリング成功した．すごい． すごいけど，最初から型さえあればIDEからちまちまリファクタリングできたはずなので，2014年にこういう技術を開発してるのはつら

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

marqueeタグ，最近人気ないけど，かわいいので，使っていきたい．今日の日記もmarqueeにすることにした．あなたの意図に反してこの文字が流れていたら私の意図通りこの文字が流れていると言える．フィードリーダーとかではmarquee出せない気がするので，わざわざ元のページ開いて見てほしい．現実世界には，あまり流れる文字ない気がするけど，巻物とかがんばって巻くとmarqueeになる．本はmarqueeじゃなくて，Page Downという感じだから，あまりもう紙では見ることない気がする．身近なmarqueeとしては，新幹線とか乗るとmarquee見れる．自分が新幹線作ることを考えると，乗客にmarqueeを見せ続けて便利というのは不気味だから，新幹線考えた人は偉い．普通は乗客にmarquee見せようと思わないと思う．あと京都駅の駅前に防災情報みたいな電光掲示板が設置されてて，そこでmarqu

ウェブサービス，UI変えると，改悪とか，元に戻してとか，そういう意見が出る． サービス提供する側の立場では，新しいUIのほうが使いやすかったり，機能が増えたり，収益が増えたりするので，新しい方を多くの人に提供することに価値がある．使いやすいかとか，儲かるかとかは，リリースまでに調べておく必要があり，リリースの結果使いにくくなったり収益減ったりしたら，失敗ということになる． 一方で，ユーザーの立場からすると，前の方がずっと使ってて愛着があったとか，新しい方を覚えるのは手間とか，確かにという感じはする．また，ウェブサービスは最終的にユーザーの手元のブラウザで表示されて動くので，映画の結末が気に入らないから変えたいといった要望よりは，受け入れやすい．データ構造についての，サーバー側の処理についてのユーザーからの要望というのはあまりなくて，このボタンがどうみたいな，UIの要望が多いと思う． 全部置

会社でLT大会があって，いまインターンが来てるので，3分で若者におすすめ本を紹介する活動を行った． 本を読みましょう 大学にいると教科書とかあって，教授もいて，勉強できるけど，社会に出たら教科書ないから，自主的に勉強する必要がある．仕事をしながら学ぶというのあるけど，それだけでは不十分だと思う．仕事してるだけだと，今持ってる技しか出せなくて，生まれ持った技術だけでどうにかすることになる．外科医は手術するのが仕事だけど，手術しかしてない医者いたら心配だと思う． 脳外科医が週60時間も執刀していたとして、そんな医者にかかりたいと思うでしょうか？　かかりたい人はいないはずです。プロには、備えるための時間、知識と技術を高める時間がどうしても必要なのです。 プログラマが知るべき97のこと 長時間働かないだけでなくて，あいた時間で勉強しないといけない． 本，会社で買ってもらえる制度あるけど，読んだ本あ

rokugaっていうウェブアプリケーションを作った．ブラウザ上で動画をアニメーションGIFに変換できる．Google Chromeでもちょっと動くけどSafariで見るのが良い． http://rokuga.herokuapp.com/ 使い方 こんな感じで，動画をドロップしてくださいとか言ってる． 1コマずつ出てきて，このコマとこのコマ，この速さ，みたいな指定ができる． 完成したアニメーションGIFは名前を付けて保存しましょう． 特徴 ブラウザで再生できる動画なら何でも変換できる Macなら動画はQuickTime Playerで撮れるので気軽に使える リアルタイムにプレビューしながら仕上がりを確認できる コマ送りは逆再生，行ったり来たり，シャッフルに対応 Herokuで動かしたらCPUが遅くて動画の変換にす時間かかる git cloneしてローカルで動かすとちょっと速い ソースコード→