鯨飲馬食

いろいろつまみ食いで勉強したことのメモ書き

TDD Boot Camp Osaka 4.0 で boot されてきた

www.kokuchpro.com

参加動機

  • 職場で若い人とペアプロでテスト駆動で開発してみたことがある
  • 短期間で機能を完成させてリリースし、有効性が見れた
  • でもその後、自分も他のメンバもペアプロテスト駆動開発を実践することがなかった

有効性が見れたのに何故継続できなかったのかは気になっていて

  • 最初の単体テストコードを書くのが難しいから他の案件でできなかった? (やれたときは、最初に作るときに単体テストを書いていた部分の機能追加だった)
  • テスト駆動開発のやりかたがよくなくてまたやろうと思わせられなかった?

という疑問は持ちつつも次の一手を打つこと無く時間が過ぎていた。 今回、テスト駆動開発がどう美味しいのか考え直したいと思いTDDBCに参加しました。

学んだこと

午前中は講演とデモがあり、午後はペアでひたすらRed、Green、Refactorのサイクルを回しました。ほとんど使ったことがなかった言語 (Ruby) で書いたので最初は手間取ったものの、徐々にペースを掴んでいって最後はもっとやりたいと思いつつも時間終了でした。

講演とデモの解説の中で irof さんから

  • 不安をテストにする
  • 不安がないところはテストを書かなくてよい
  • まずassertionを書くことでゴールが明確になる
  • 一歩一歩踏みしめたいとき以外は、こう書けばいいとわかっているなら一息で書いてしまえばよい
  • TDDのテストは開発のためのテストであり、品質を保証するためのテストはまた別
  • 開発が主役。テストが主役ではない

という話があり、動く(価値のある)きれいなコードを素早く開発するための手段としてのTDDであり、テストをたくさん書くことが目的ではないということは肝に銘じておかねばと思いました。

懇親会では原田騎郎さんから、サボるためにTDDをやるんだ、とプログラマの三大美徳の一つである怠惰に絡めた教えをいただきました。楽できるところは楽をするために頑張って、プロダクトの本質に集中して価値を届けていきたいです。

boot された?

オープニングの話で、TDD boot campに受講者として何度も参加すると boot されてないということになって主催者が叱られるという話がありました。素振りはしっかりできたので、ここで満足して終わりにするのではなく現場での実践を試みていきたいです。次回はTAなりで協力できればと思います。

講師・サポートスタッフの方々、会場提供いただいたファーストサーバさん、お菓子差し入れをいただいた皆様ありがとうございました。

(追記)後日、一緒に参加していた同僚と、職場のエンジニアに向けて学んできたことの共有をしました:

Cookpad Tech Kitchen #8 に行ってきた

cookpad.connpass.com

非同期ジョブと仲良くする / 小林 秀和さん

非同期ジョブと仲良くする // Speaker Deck

  • barbeque (https://github.com/cookpad/barbeque) の話
  • Docker ベースのジョブキューシステム
  • アプリ(マスター)とワーカーは同じDockerイメージから起動(起動時引数が違うだけ)
  • Hako (Dockerコンテナ管理ツール) を利用してる
  • キューは SQS なので、AWS におまかせ
    • cf. sidekiq + redis を増やしたら、スケールするように redis cluster の面倒見が必要
  • アプリからの実行は ActiveJob 準拠なので barbeque 特有のコード書かなくてよい
  • 開発用にローカルでの実行もできる
  • AWS SNS 契機でのジョブ実行もできる
  • アプリのデプロイはなく、ビルドした Docker イメージを上げればよい。

AWSのサービスやHakoと連携してそれらの機能をうまく活用することで、非常にシンプルな構成で、スケールする仕組みを実現できているのがよいなと感じました。

kuroko2の近況とクックパッドのバッチ周りの概況 / 大石 英介さん

kuroko2の近況とクックパッドのバッチ周りの概況 // Speaker Deck

  • kuroko2 (https://github.com/cookpad/kuroko2)の話
  • 高井さんのスカンクワークで開発され、社内導入
  • 大石さんがメンテを引き継ぐ
  • 元々OSS化の予定はなかったが、2016/10 OSS化、諸般の事情によりサイレントリリース
  • 現実的な運用を見すえた設計方針。
  • カスタムタスクによる拡張性
    • kuroko2 本体に手を入れなくてもドメインに合わせたタスクを作れる
  • バッチまわりの近況
    • 社内では OSS のkuroko2 のmaster のヘッドを使ってる
    • 700個のバッチジョブ
    • 一日あたり6000実行
    • 230 worker
    • 監視用のAPIをたたいて監視 (zabbix)
    • capistrano でデプロイ. worker は HUPシグナルでgraceful shutdown
    • ほぼすべてのジョブを1つのkuroko2アプリで管理

バッチ実行基盤なのでその上で個々のバッチが確実に実行され、それぞれの価値を生むのを継続して支えつづけることに価値があり、安定的に運用できることに価値を置いて技術選択、設計をされたという点が一番印象に残りました。自分も開発対象のそれぞれの特性によって何に重点を置くべきかはしっかり考えて行きたいと思いました。

美しいバッチの壊し方 / 青木 峰郎さん

Cookpad TechKitchen #8: Breaking BatchJobs Beautifully // Speaker Deck

  • ジョブ数が多くフローが複雑。とはいえ1000ジョブ強なので小規模もいいとこ
  • Kuroko2 でスケジュール。中身をBricolage で実行してる。
  • Bricolage
    • SQLバッチ専用フレームワーク
    • 1ジョブ = 1SQL分の強固な思想に基く → よいバッチのために必要だから
  • 運用しやすいバッチはよいバッチ
    • 落ちたときに簡単に対処できる = 障害を直しやすい = 美しく壊れる
  • 美しく壊れるバッチの3つのポイント
    • どこで壊れたかすぐわかる
    • 続きから実行できる (9割までいってたらせめて8割5分くらいから実行できる)
    • リトライで直せる (ちょこっと直してリトライ)
  • どうやったら美しく壊れる?
    • 処理をひたすら細かく分割し、小さい job を繋いで全体を構成する
      • Bricolage は 1SQLなので、もう分割できないところまで分割できてる。
    • I/O対象ごとにジョブ分割
      • 中間テーブルに書いたらそこで無条件に切る
    • ジョブ管理システムで結合
      • →今のところ Kuroko2 で繋いでる。
      • グラフで正常終了、実行中、落ちてるが見えて区別できるとよいなぁ… (Kuroko2への要望)
  • 羃等バッチの記述
    • いっこいっこがリトライ可能じゃないと意味がない
    • トランザクションなど。
    • 更新 (UPDATE) しない→あたらしいテーブルつくるか、DELETE&INSERTするか

どこで壊れたかすぐわかること、続きから実行できること、ちょこっと直してリトライで直せることというのはSQLにかぎらず一般的に大きなバッチをどう美しく(壊れた時に早く対処できるように)していくべきかの指針になると思うが、単位を1SQL文にするという明確なルールでそれを実現したというのは興味深かった。

懇親会

成田さんとヨシオリさんに、自前で作ってOSS化することに関して聞かせていただきました。最初から自分たちで作ることを考えるわけではなく、まずはその領域のありものをしっかり調査して、その結果はまるものがない場合に覚悟を決めて自分たちで作るという判断をしてること、一方で開発するときはOSS化することを前提に設計することで、業務依存な部分(OSS化しない)とそうでない基盤部分(OSS化する)をうまく分離していることなど、自分が最近悩んでいたことに対する他での取り組み方を聞けてとても参考になりました。

Agile Japan 2017 大阪サテライトに行ってきた

agilejapan-osaka.connpass.com

いろいろな方からたくさんの勇気をもらいました。参加してよかった。

Agile Japan 2017基調講演 “モダンアジャイル” / Joshua Kerievsky 氏

  • Agile Japan 2017本編のビデオが放映された。
  • 「パターン指向リファクタリング」の著者という紹介があり、読んだこと思い出しました。
  • Modern Agile
  • 古いやり方で本当にうまくいくのか?もっといい方法はないのか
    • 自転車の補助輪の例
    • 乗って漕げるようになっても、補助輪外したら怖がる。
    • バランスが重要
    • 補助輪なし、ペダル無しのバイクでバランス感覚を得ると、24hで自転車乗れるようになった。
      • 子供たちが乗って遊んでるあれの目的がそういうことだったのを知りませんでした。
  • make people awesome
    • 新幹線開発で、250km/hという very challenging な目標を設定
      • カーブがあるから→まっすぐにすればいいという発想
      • 9年でやりとげた (1955)
      • とてつもないことをやることで people を awesome に
    • いいプロダクトを作るのではなく、いいユーザーを作れ
  • Anzeneering
    • safety という単語はかっこよくないので日本語の「安全」を使った
    • 心理的安全性を前提とする
    • 安全は high performance にも繋がる
    • Fire Phone が売れなかったことに対する Jeff Bezos の言葉: “We’re working on much bigger failures right now”
    • たくさん失敗しても、成功して得るものが大きければ問題ない。
    • 素早く実験と学びを

会社の文化をアジャイルに変えたい?キミにもできるよ! / 新井 剛 氏

speakerdeck.com

  • ヴァル研究所での取り組みの紹介
  • 本気モードとのことではだしで登壇されていた
  • 問題解決ではなく共感を目的に
  • 社員向け社内見学ツアー
  • 隣に座っている取締役の話をみんなにも聞かせたい→宮本塾
  • ホーソン効果
    • 工場のあかりを明るくすると生産性あがった。一方で暗くしても生産性あがった
    • 自分たちでやってるとわかると生産性上がる
    • 内発的動機づけ
  • 会社見学ツアーをやってよかったこと
    • 良いことの後押しになる(あのすごい人がよいと言ってくれてる)
    • 広めてくれる
  • することから始める by 岡潔
  • 楽しい、好き

「楽しさ」に導かれたアジャイル開発 ~老舗メーカーでの実践~ / 久保 明氏

www.slideshare.net

  • 現場主導、コーチなし、経験なし
  • きっかけ
    • 仕事の行き詰まり
    • Project Facilitation の講演に来た平鍋さんの言葉
      • やってみてください。楽しいですから。
  • 朝会
    • 進捗確認ではなく、健康診断だと思ってる。
    • メンバーが悩んでないかな?怒ってないかな?
  • TDD
    • やることが増えた感じにしない
    • こだわらない
    • →動作確認のコードを残そう
  • 楽しみが伝搬
  • 繋がり
    • すごい人と繋がる
    • 48時間以内に連絡する。
  • 仲間の力を借りよう、そして、自分のまわりを楽しくしよう
  • 成長することは良いこと?
    • 裏にすると、成長しないことは悪いこと。辛い
    • 成長することは楽しいことだ
      • 裏にしても「成長しないことは楽しくないことだ」。乗り切れる。
  • 迷惑をかけよう
    • 無理して頑張ってると感謝できない
    • 迷惑かけて感謝しよう
      • ついうっかり迷惑かけてしまった感じで
  • 勇気
    • 高い塀の上の子供に大人のかける言葉:「大丈夫だよ」
      • 飛び降りたことあるから
      • 失敗しても大丈夫?
      • 最初、大丈夫と思って降りたわけじゃない
        • → 怖いままやってみよう

免疫マップをつくってみた

2017/03/23 (木) にDevLove関西の勉強会に参加して免疫マップをつくってみました。

devlove-kansai.doorkeeper.jp

最初にファシリテーターの広瀬さんから、書籍

なぜ人と組織は変われないのか――ハーバード流 自己変革の理論と実践

なぜ人と組織は変われないのか――ハーバード流 自己変革の理論と実践

に書かれている免疫マップをつくってみるという今回のワークの目標と、その作成がメンタルに痛いものでアジア人には向かないと言われているが、安全な作り方があるのかに興味を持っているというお話があって、早速ワークに突入しました。

まず個人ワークで自分の「改善目標」とそれに対する「阻害行動」を書き出して、テーブルの隣の人とお互いのものを説明しあいました。ここまでは全然痛くなかった。

次に被験者になりたい人が立候補することになったのでせっかくの「素振りの場」なので手を上げました。手を上げた人を含めて4人一組くらいのグループに分かれて、被験者が改善目標と阻害目標について周りの人に一方的に説明する時間があり、その後幾つかの質問を受け答えをする時間がありました。

改善目標(私が最も改善するべき点を一つ上げるとすれば何?)
  • まわりから見て楽しんで仕事してる風に見えるようになる
    • not いそがしそう、not しんどそう
      • 後から聞くと、いそがしそうだったから聞けなかったということがよくある→話しかけやすくしたい
    • まわりの人も会社に来るのが楽しいと思える雰囲気をつくりたい
阻害行動
  • 誰かが困っていて、誰かがやらないといけないけど面倒で誰もやろうとしないことをすすんで拾ってやってしまう
  • 解決しない課題を解くのに残業してしまったり、課題のことを家でプライベートの時間にも考えてしまっていたりする
  • そういうことしてるから余裕がなくなっている

あとは後ろ向いといてと言われてメンバに背を向けて座り直させられました。そしてその後ろで、メンバは被験者が居ない体で(でも聞こえるように)好き勝手に言い合って阻害行動を深掘りしたり、その行間を推測したりして、その元になっている裏の目標を掘り起こすという時間になり、私が出した改善目標と阻害行動を元にメンバが好き勝手に話し合うのです。後ろ向いて聞いていると、「そんなこと考えてたら自分は悪い人だな。でも確かにそう考えてたかもしれない」と思ったり、「そういうわけじゃない〜」と言い訳したくなるような辛い事をズバズバ言ってくれていて、自分一人だとそこまで一気に掘り下げていけない所まで短時間で連れて行ってもらえました。

裏の目標
  • みんな楽しいわけでもないのに楽しんでいるようにふるまいつつ仕事する会社にしたい
  • 自分からメンバに話しかける努力をせずとも、まわりから話かけてもらいたい
  • 面倒な課題を自分でやっちゃうことで若手の成長の芽をつみ、自分個人の評価を上げたい
  • 面倒な課題があたかもないかのように取り繕って隠蔽したい

メンバに言われたことを元に裏の目標としてその場で書き出した内容は、かなり言われて凹んだ後だったのでマイナスの面が強くでています。
ワークではここまでだったので、残りの「協力な固定概念」は帰ってから考えました。

強力な固定概念
  • 同じ仕事をするにしても、つまらなそうにただこなすより、興味持って楽しんでやった方が発見あるんじゃないかという思い
    • でもそれって過去の自分の体験に重ねてしまっておりその人自身を見てないかも
  • みんなが成果を出せる領域へ早く連れて行かないといけない
    • まわりの成長を待って、まわりのスピード感に合わせてやってたら遅過ぎる。基準になるスピード感を再定義してしまいたい
      • と言いつつも実際はいそがしさに足を掬われてそこまでのスピードを出せていない現実があるかも
    • 綺麗なものを一切見ずに面倒なことばかり見てたらそれにのまれてしまわないか心配。先に美味しいところを味わってもらいつつ、目指していく目標地点を共有したい
      • 周りの力を信じる気持ちが足りてなくて隠しすぎているかも

ここまで厳しい視点での深掘りを短時間でやるのは一人では無理だったと思うので、同じグループの3人の方々には感謝の気持ちがいっぱいです。勇気出して被験者立候補してよかったと思います。
こうして作った免疫マップを元にどうやって改善していけばいいかは宿題で、正直どう進んでいけばいいかのイメージは持ててない状態。ただ、主催の中村さんから、「会うたびに顔が暗くなっていってますよ」と言われているので改善すすめるのは必須かと思ってます。まずは読むの厳しいと言われていた冒頭の本を読みつつもう少し考えてみようかな。

マージ済みのコミットハッシュからプルリクエストを開く

コード見てもわからない情報(その変更が必要となった背景や、数ある実現方法の中からどうしてその方針で変更したのかなど)がコミットメッセージにもJIRAのチケットにも書いてなくて、当時居た人をなんとか探して聞きまわる、そして大概は昔のことなので忘れている…といった状況が当たり前だったのが一年半くらい前。最近はチームメンバが積極的にJIRA のチケットに要件確認のやりとりや、調査のメモなど、どんどん情報を残してくれるようになり、新しめのコードについては人の記憶に頼らなくても情報収集できるようになってきた。

次に課題として出てきたのが、チケット見てもコメントがたくさんありすぎて、要点を抽出するのが大変という問題。チケットクローズするときに最後のコメントとしてサマリを残してますーという声は一部からあったけど、まわりを見渡すと、最後にやったことの記録があればまだ良くて、スプリントの終わりに閉じ忘れてたチケットを急いで閉じる時とか、何も書かずに閉じちゃってることもしばしば。

通常の導線上でサマリを残す一手間をゆるく強制できないかなと思っていて、こないだの上司との 1 on 1 で相談してみたら、少し前にレビューの効率悪いのをどうにかしようという文脈でプルリクエストにサマリを書くという話をしていたのを思い出した。プルリクエスト出すときにやったことの要点と関連情報をちゃんと整理して書き、レビューアに十分な情報を出した上でレビュー依頼することで、より深いレビューをしようという話だった。リリースのために必要な一つのステップとして自然に開発フローに組み込めるのでこれはよい。

コミットメッセージにはチケット番号を入れるというルールにしてるので、次の開発や不具合調査のときに git blame すれば、過去にそのコードを変更したチケットを開くのは簡単にできて、さらにJIRAとBitbucketを連携させているから自動的にチケットからプルリクエストへのリンクも張られていて、プルリクエストに書かれたサマリに到達できる…。待てよ、毎度毎度リンクを辿るというのは面倒だな。GitHub の pull request 開くやり方は見たことあるし、自分たちが使っている Bitbucket でも同じようにできるよねと思って、元ネタ

qiita.com

を見直してみると、マージコミットを取ってくる所までは流用できるけどその先を hub に任せてるのでそちらは何とかする必要があることがわかった。

ここで先日 OSS Gate というイベントに参加して刺激をもらっていたのが効いた。

oss-gate.doorkeeper.jp

やってみたらよいということで実装してみて期待した動作になったので、初めて PyPI へ登録するところまで勢いでやった。

github.com

以下は開発の流れのメモ。こういう水面下でばたばたした情報も残しておくと後で何かの役に立つかもというのを OSS Gate に参加して思い出すことができた。

  • BitbucketでもGitHubと同様に、マージボタンのコミットメッセージにプルリクエストの番号が定形で入るのは知ってた。
  • それとリモートURLをパースしたものと合わせれば、プルリクエストの URL は生成できる!いけそうだ。
  • 外部コマンド実行して出力取るの、commands で簡単にできる。(deprecated と書いてあるのこの時点では見落としてた)
  • ブラウザを開くのどうしよう。macOS でも Windows でも Linux でも使えるといいんだけど。
  • open, start, xdg-open を叩くようなの書けばいけそうだけど面倒だなー。
  • webbrowser 使えばいけるやん。
  • 引数もかっこよく処理したいなー。 argparse 使っちゃお。
  • 説明読んでも add_argument の使い方分からないので試行錯誤して何とか解決 (わかりやすい チュートリアル へのリンクがあったのは後で気付いた)
  • commands は python3 だとなくなってる。subprocess で書き直そう
  • せっかくだし、PyPI にも登録しておこうか。
  • https://pypi.python.org/pypi の Register からユーザ登録と、Package Submission から PKG-INFO の登録を試みる。
  • エラーページに飛ばされる。pypi の調子が悪い?何度かやったらうまくいった。
  • Package Submission のページからリンクされていた、twine を使ってアップロード
  • pip install openpr でインストールできるようになった!

2017 = 9^2 + 44^2

昨年末の納会のビブリオバトルで自分が影響を受けた本として紹介するのに「ハッカーと画家」を久しぶりに読み返しました。表題にもなっている「ハッカーと画家」では、良いプログラマと良い画家の共通点として、ともに書く(描く)ことによって学ぶこと、よい作品を見ることで学ぶことが挙げられている。そして、書いたものをどんどん書き直して洗練していくこと、見たり使ったりする人の気持ちになって「共感」を得られるものを創っていくことの大切さを述べている。2000年代初頭に書かれたエッセイを集めたもので、十数年が経過してプログラミングをとりまく状況も変わってきているので若手が読んで共感できる内容がどれだけあるかはわからないが、少なくとも自分にとっては再度読み返して、変わらず大切なことに気づけたのでよい本だと思いました。納会のセッションでその気持ちがうまく伝えられたかは不明だけど。

昨年2016年の自分の振る舞いをふりかえると、書く前に考えすぎちゃって、口だけ動かして何も出来てないってことが結構ありました。そんなこともあり年末の悪あがきでちょっと書いて(古いフレームワークの上でやってて遅々として進まない状況だった事柄について、いっその事と思い車輪の再発明をして)みたら、わりと簡単に書けちゃうのがわかったり、書いているうちに改善すべき点が見えてきたりして、やっぱり口じゃなくて手を動かすことに注力しないと物事は進まないなというのを実感しました。2017年はどんどんコードを書いて、自分で使ったり周りの人に使ってもらいながらどんどん直して洗練しつつ、物事を前に進めていくことを自分への課題として課します。

今年もプログラミングを楽しみます!

ドメイン駆動で開発する:初期のラフスケッチから実装まで

devlove-kansai.doorkeeper.jp

参加から半月ほど空いてしまいましたが、2016/10/31 のDevLove関西勉強会で増田さんの話が聞けるということで定時ダッシュで京都まで行ってきました。増田さんのトークを聞くのは初めてでしたが、以前勉強会(の懇親会)で会った人が増田さんと一緒に仕事をしてすごい人だと話をされていたので楽しみにして参加したところ、終始生き生きした語り口にぐいぐい引き込まれました。

最初は、よくない設計、「でも動いている」という動いた駆動の開発から抜け出そうと試行錯誤をしていてドメイン駆動設計に出会い、それを実践していくうちに自然と良い設計ができてきて、業務を学びながら開発する楽しさ、対象領域の知識とコードが一致していることによるわかりやすさ、安心感が得られてきたというひとつの物語を聞くことができました。話の中で何度も「今も試行錯誤を続けている」という言葉が繰り返し出てきて、常に一歩先へ進もうとする姿勢に刺激を受け、自分も常にちょっとずつでも前に進んでいきたいという思いを持ちました。

勉強会の前の日に名前にまつわる過去の出来事をいろいろ思い出していて、どうしたら名前の重要性をまわりに伝えられるかなというのを考えながら参加して、帰ってから話の中で出てきたオブジェクト指向エクササイズにトライしてみて、やっぱりプログラミングは難くて楽しいというのを実感した。こういうのを自分で楽しみながらやってみると、説明してふーんで終わられるよりも体で覚えていけてよいのかな。