社内横断で開発効率を上げる取り組み #pepabohatena - hitode909の日記
プレゼンモード 再生 ← / →で移動 fでフルスクリーン escでおわる こんにちは，id:hitode909です．はてな・ペパボ技術大会 #4 〜DevOps〜 @京都において，「社内横断で開発効率を上げる取り組み」というお題で発表しています．この記事は，その発表資料です． 社内横断で開発効率を上げる取り組み はてな・ペパボ技術大会 #4 〜DevOps〜 @京都 hitode909 自己紹介 hitode909 株式会社はてな アプリケーションエンジニア 好きな本はオブジェクト指向入門とドメイン駆動設計 2009年〜 うごメモチーム 2012年〜 ブログチーム 2017年〜 マンガチーム 2018年〜 CTO室(兼務) アジェンダ CTO室での活動 特定のチームに閉じず，社内横断で開発効率を上げるための試み みなさん 学生の方? 🙌 社会人の方? 🙌 Devの方? 🙌 Opsの
ImageMagickでliquid rescaleする - hitode909の日記
ImageMagickのリサイズまわりの挙動を調べてたら異常なアニメーションGIFが掲載されいているのを発見して，その瞬間に調べ物はどうでもよくなった． 領域が狭くなると，文字が帽子の上に周りこんでいる． http://www.imagemagick.org/Usage/resize/#liquid-rescale Seam carving(liquird rescale)は画像のなかで自然に切り取れるところを探してリサイズする技術．物がないところを探して切り詰めるので物だけが残る． Seam carving - Wikipedia ImageMagickをliblqrつきでインストールすると使えるようになる． brew install imagemagick --with-liblqrオライリーの書影とか見るからに縮めやすくてめちゃくちゃ楽しいのでは?と思ったので練習． Docker 作
コードレビューのクオリティとスピード，とくにスピードについて，それとコミュニケーションについて - hitode909の日記
ソフトウェアを作るときにクオリティとスピードのバランスをとりたくて，どちらかに偏ってはいけなく，どちらもキープしないといけない．すごく雑に*1とらえると， クオリティ→正しく動き，不具合がないほうがよい スピード→(計算時間ではなく)早く作れるほうがよい ということになる． コードレビューでは，不具合を見つけて直してもらったり，動きはしてもコードの可読性に問題があって直してもらったりと，クオリティに目を向けられがちだと思う． ところで，コードレビューとスピードの関わりについて考えてみる．スピードのためにできることはいくつかあり， 早く読み始める→他のことやってても手を止めて読み始めたり，1日のうち決まった時間にレビュータイムを設けたり 速く読む→これはコツとかある*2けど精読しないといけないので難しい 不具合を見逃さない→リリース後とか，リリース直前に正しく動かないことが分かったら大きな手
App::PRTに指定したコード内に登場する変数を紹介してくれる機能をつけた - hitode909の日記
以前から作っていた，PerlリファクタリングツールであるApp::PRTに，指定したコード内に登場する変数を紹介してくれる機能をつけた． App-PRT-0.20 by HITODE https://t.co/7aT6PJypki— CPAN New Modules (@cpan_new) 2016年10月28日 背景 Perlのコードをリファクタリングするとき，一部をメソッドとして切り出したいときがある． IDEがあればIDEが自動でやってくれるけど，そういったものはないので，手動でやることになる． エディタで選択して，この中にはどういった変数があるのか，ということが気になる． そういったときに，選択したコード内にはこれらの変数があります，ということが一目で分かると便利． そこを切り出せそうか判断するのに使えたり，おかしな変数が登場していたら，その変数が登場しない形に書き直したのちに，メ
イシューからはじめよ - hitode909の日記
取り組むべき課題を見極めたのちに，解の質を上げていきましょう，という話． 解決してもうれしくないとか，解決したかどうかの定義が明確ではない，とか，そういうのはイシューではない． がむしゃらにどうでもいいタスクを大量にこなしても，あまり良い状態にはならなくて，大事なタスクを1個こなすほうが価値がある． クックパッドの井原さんが書かれてた記事を思い出した．何かに取り組むときには三つの輪があって，自分がやりたくて，かつ得意で，会社としてもやるべきことをやろうという話． よくこの図を思い出して普段から便利に使っていて，このタスクとあのタスクだと，こっちのほうが重なり度が強いから，こっちからやったほうがうまくいきそう，とか． やるべきことの見つけ方とそのときに一番大事なもの - ihara2525's blog ソフトウェアだと，コアドメイン以外のところをリファクタリングしまくっても良い結果は得られ
なぜひどいコードを書いてはいけないか - hitode909の日記
ひどいコードは何やってるか分からない ひどいコードが何やってるか分かっても、なぜそうなってるのか、そこを変えるとどうなるか分からない ひどいコードは新たな変更に耐えられず書き直されることになる ひどいコードを書き直すには、ひどいコードがどうなっているか理解し、どこを変えるとどうなるのか理解する必要がある ひどいコードはたいていひどいテストコードが支えていて、テストコードがあったとしてもひどいコードと同様の問題があり、頼れるものが何もない どんなにひどいコードでも、書いた人を憎んではいけない。たとえ自分の書いたコードだとしても、先輩の書いたコードだとしても、ソフトウェアとしてひどい物にはひどいと言っていくことが大切で、だからと言って人に向かってひどいと言ってるわけではない。 最高の仲間たちが日々変化する難しい問題に対処していいコードを書いたり、ときにはひどいコードを書いている、という😇的な
作り直し - hitode909の日記
ソフトウェアを作ってて、作り直したり、書き直したりするべきかどうかという話をすることがある。 大きな規模だと、ソフトウェアを作り直す、というところから、小さな規模だと、込み入った機能を書き直す、くらいまであるけど、作り直すとうまくいくのは、次の二つのうちどちらかではないか。 最初に作ったときより世の中の技術が発展したとき 昔のコンピュータでは収まらなかったとか、昔は良いライブラリがなかったけど、今はある、というとき。 単に今ありふれた技術で作り直すと、よいものができそう。 最初に作ったときよりはコンピュータのスペックが上がったので、そのつもりで、並列度倍に上げても止まらないし、より速く動かせる、とか。 昔はバッチで計算しないといけなかったけど、今ならリアルタイムに返せる、とか。 昔は依存管理のよいライブラリがなかったけど、今ならこれ入れたら簡単、とか。 最初に作ったときより人間の技術が発展
70ページでドメイン駆動設計の要点を押さえられるDomain-Driven Design Reference - hitode909の日記
Domain-Driven Design Reference，Amazon見てたら発見して，安かったから買ってみた． ぺらっとしてて，ポケット索引集みたいな雰囲気．エリックエヴァンスのドメイン駆動設計から，要約が抜粋されていて，70ページくらいで，重要な概念を押さえられる．原著は著者の経験を語ってくれるコーナーが大半を占めるけど，この本ではバサッと切られて，定義だけが載ってる． 前の本から10年くらい経ったので，新しい内容も増えてる．ドメインイベントとパートナーシップ，巨大な泥団子．いずれも実践ドメイン駆動設計に出てきた． これだけ読んでドメイン駆動設計さあ始めよう，とはならないだろうけど，でかい本読みたくないけど議論には参加したい，とか，どんなものか軽く眺めたい，みたいな人が読むにはてっとり早いかもしれない． 唯一役立ったのが前書きで，エリックエヴァンスのドメイン駆動設計の本のことをTh
#納豆に何入れたら一番おいしいか選手権 - hitode909の日記
関西の人は納豆食べないみたいな話があって、その証拠にうちの父は食べない。卵かけご飯を食べる。弟もそうだったような。僕と母は食べる。僕は頻繁に食べてて、朝ごはんはなぜか納豆ご飯とミルクティーという感じだった。納豆食べない人、給食にも出るので、食べない人は大変そう。最近の人は食べるのかな。 納豆に入れるとおいしいものを紹介します。 卵 卵は基本という感じで入れる。納豆混ぜて、醤油とか辛子とか一通り入れてから、卵を割って混ぜる。 わさび薬味 こっちは、完成した納豆ご飯にふりかける。わさび薬味は、ふりかけっぽいけど、本来薬味として作られているので、ハードコアな味でうまい。単にご飯にかけるだけでもうまいのでおすすめです。 君だけの最強納豆を投稿しよう 選手権やってるらしいので、皆様も納豆レシピを投稿されてはいかがでしょうか。納豆パンっていうのを試したことがあるけど、それはイマイチだった。そういう話を
コードレビュー - hitode909の日記
コードレビュー，慣れるとできるけど，いきなりdiffを渡されて，どうぞ見てくださいと言われてもよくわからないと思う． やりましょうというのはいいけど，ただむやみに読んでもうまくいかない．変更がある程度大きくなるとdiffだけ見てもよくわからないので，いろいろ見ることになる． 僕はいつも以下のようなことを無意識にやってて，うまくいってる気がしてる．GitHubのPull Requestの仕組みを使ってる前提で． Discussionをさらっと眺めてどういう問題を解決したいのか見る Commit Statusを見て，テスト通ってることを確認する Commitsタブで1コミットずつブラウザの新しいタブに開く 全部クリックし終わったら古い順に1コミットずつ読む 気になる点があったらエディタとかにメモしておく．あとで書き直されるかもしれないので，まだコメントしない 全コミット見終わったらFiles
スキーマレスなオブジェクトたちからスキーマを推測するやつ - hitode909の日記
MongoDBなどはスキーマレスなデータベースであり，先にスキーマ決めなくても，何でもつっこめることになってる． データベースから見ればスキーマレスということでいいけど，アプリケーション的には，何が入ってるかちゃんと管理したい． 下の例では，AliceとBobでは持ってるフィールドがちがって，Bobはhobbyを持ってるけど，Aliceは持ってない． { name => 'Alice', age => 20, } { name => 'Bob', age => 21, hobbies => ['tennis', 'soccer'], } これくらいなら見れば分かるけど，長期間運用してて，結局何が入ってるのか分からない，みたいなことがあって，難しかった． オブジェクトをどんどん渡していくと構造を教えてくれるのを作った． hitode909/perl-object-classifier · G
UI変更批判バトルと複数のバージョンのウェブサービスを同時に配信することについて - hitode909の日記
ウェブサービス，UI変えると，改悪とか，元に戻してとか，そういう意見が出る． サービス提供する側の立場では，新しいUIのほうが使いやすかったり，機能が増えたり，収益が増えたりするので，新しい方を多くの人に提供することに価値がある．使いやすいかとか，儲かるかとかは，リリースまでに調べておく必要があり，リリースの結果使いにくくなったり収益減ったりしたら，失敗ということになる． 一方で，ユーザーの立場からすると，前の方がずっと使ってて愛着があったとか，新しい方を覚えるのは手間とか，確かにという感じはする．また，ウェブサービスは最終的にユーザーの手元のブラウザで表示されて動くので，映画の結末が気に入らないから変えたいといった要望よりは，受け入れやすい．データ構造についての，サーバー側の処理についてのユーザーからの要望というのはあまりなくて，このボタンがどうみたいな，UIの要望が多いと思う． 全部置
テスト書きすぎ問題 - hitode909の日記
テスト書きすぎるとよくないって言ってる人がいた．DHHっていう人．作業時間の1/3以上テストしてたらおかしいとか，ActiveRecordのバリデーションなど，Railsの機能はテストしない，とか． Signals vs. Noiseの去年のエントリに、テストをどれくらい書くべきかということについてDHHが指針を示していたものがあったので... - Sooey 偉い人が言ってるからという理由で，テスト手抜き派の人に良い材料を与えてしまった．僕は意見ちがって，作業時間半分以上はテスト書いたりしてる． テストたくさん書くと，最初に書くときのコストは増える．けど，あとから読む時や，変更したい時には，読むだけだし，書くのも差分だけで良い．コード本体を理解できれば，要らないテスト捨てるのは，落ちたのを消すだけだから簡単．あとで見て，テスト足りないと分かったときに，明文化されてない仕様からテストを補う
Perlの使ってないメソッド探すやつ - hitode909の日記
Perlの使ってないメソッド探すやつ作った． hitode909/perl-find-unused-methods · GitHub r7kamuraさんのやつそこそこ使えるって聞いたのでPerl用のを作ってみた． https://github.com/r7kamura/guideline/blob/master/lib/guideline/checkers/unused_method_checker.rb プロジェクト内で，fooっていうメソッド定義だけして，プロジェクト内で呼んでないときに，消しましょうって教えてくれる．メソッド名だけ見ているので，他のクラスに同名のメソッドがあって，そっちは呼んでない，みたいなのは発見できない． 中村さんのはメソッドの定義とかにフックしてコールバックが呼ばれるといったかっこいい設計だけど，Perlでどうやるか分からなかったから，PPIでsub xxx
CasperJSで気軽にJSのテストできる - hitode909の日記
ウェブアプリケーションのJSのテストするのにCasperJS使ったら便利だった． CasperJSはPhantomJSにテスト用ユーティリティがついて便利になったやつ． JS，MVCできれいに書いてると，Modelの単体テストとかできるけど，昔ながらの感じだと，ここをクリックしたらこれが表示されること，みたいなテストを書くことになる．けどライブラリとかいろいろあってどれを使えばよいか分からなくて敷居が高い．CasperJSを使ったらこれだけで完結してテスト書ける． PhantomJSは単なるブラウザだけど，CasperJSはテストのフレームワークとか，DOMのテスト関数とかがついてる． 非同期なタスクの実行の仕組みも入ってて，casper.thenっていうのを順番に書いていくと，順番に呼んでくれて，click()して，casper.thenしたら，ページ遷移したら次のページに移動してる．ス
この夏インターン給料で買いたいおすすめ本 - hitode909の日記
会社でLT大会があって，いまインターンが来てるので，3分で若者におすすめ本を紹介する活動を行った． 本を読みましょう 大学にいると教科書とかあって，教授もいて，勉強できるけど，社会に出たら教科書ないから，自主的に勉強する必要がある．仕事をしながら学ぶというのあるけど，それだけでは不十分だと思う．仕事してるだけだと，今持ってる技しか出せなくて，生まれ持った技術だけでどうにかすることになる．外科医は手術するのが仕事だけど，手術しかしてない医者いたら心配だと思う． 脳外科医が週60時間も執刀していたとして、そんな医者にかかりたいと思うでしょうか？ かかりたい人はいないはずです。プロには、備えるための時間、知識と技術を高める時間がどうしても必要なのです。 プログラマが知るべき97のこと 長時間働かないだけでなくて，あいた時間で勉強しないといけない． 本，会社で買ってもらえる制度あるけど，読んだ本あ
動画をアニメーションGIFに変換するウェブアプリケーション作った - hitode909の日記
rokugaっていうウェブアプリケーションを作った．ブラウザ上で動画をアニメーションGIFに変換できる．Google Chromeでもちょっと動くけどSafariで見るのが良い． http://rokuga.herokuapp.com/ 使い方 こんな感じで，動画をドロップしてくださいとか言ってる． 1コマずつ出てきて，このコマとこのコマ，この速さ，みたいな指定ができる． 完成したアニメーションGIFは名前を付けて保存しましょう． 特徴 ブラウザで再生できる動画なら何でも変換できる Macなら動画はQuickTime Playerで撮れるので気軽に使える リアルタイムにプレビューしながら仕上がりを確認できる コマ送りは逆再生，行ったり来たり，シャッフルに対応 Herokuで動かしたらCPUが遅くて動画の変換にす時間かかる git cloneしてローカルで動かすとちょっと速い ソースコード→
アクセスログ聞くやつ - hitode909の日記
ウェブアプリケーションデプロイしたあとしばらくエラー出てないかログ見たりすると思う．たとえばデプロイした瞬間にエラー出まくったら戻すとか，アクセスログが流れなくなったら誰もアクセスできてないということだからおかしいとか，いろいろあると思う． アクセスログずっと見てるの疲れるからwebtailを使って聞けるようにしてずっと聞いてる．直近5秒間のGETとPOSTの数にあわせて音程が変わる，500が出たらピンクノイズが流れる，みたいな感じ． デプロイするときアクセスログ聞いててエラー出たらピンクノイズ流れるようにしてるけど急にザーっていう音出るから心臓に悪いし本当に障害起きると直るまでずっとピンクノイズ聞き続けることになる— 趣味はマリンスポーツですさん (@hitode909) 10月 31, 2012 アクセスログの形式ちがったら73行目の正規表現書き換えれば動くと思う．73〜77行目くらい
HTMLとJSだけで何か作るときの - hitode909の日記
HTMLとJSだけで何か作ることが多くて，開発環境をどう作るかとか，ノウハウみたいなのがたまってきたと思う． ローカルのHTMLファイルをブラウザで開くと，いろんな制約がある．たとえば，ファイルAPIを使えないとか，YouTubeのプレイヤー貼り付けできないとか，/js/みたいに絶対パスで指定することもできない．ページ1枚なら他のページにリンクとかいらないけど，ウェブサイトを作ってるときとかは，/help/でヘルプページを表示するとか書いたときに，ローカルのファイルを見てリンクが切れてるということになる．開発中はリンク切れだけど本番サーバーに置くと見れるはずとか言って開発するのは怖い． サーバーでRubyとかPerlが動いてるみたいなときはローカルでサーバーを立てて開発してると思う．HTMLとJSだけ使うときでもローカルでサーバーを立てて開発したほうがいいと思う． 開発中は，nginxでフ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
YAPC::Asia Tokyo 2014でPerlの静的解析やリファクタリングについて喋りました - hitode909の日記
