『組織にテストを書く文化を根付かせる戦略と戦術』を聞いて #jopf

はじめに

先日開催された『開発を活性化するためのポイントとテストに関する勉強会』にて、『組織にテストを書く文化を根付かせる戦略と戦術』のお話を聞いてきたので、そこでの内容と自分が所属している組織への適用について記してみます。

各種資料

発表資料

組織にテストを書く文化を根付かせる戦略と戦術 from Takuto Wada

Togetter

togetter.com

感想

衝撃的だったのは、「テストを書く文化の醸成には2年ぐらいかかる」という言葉。

t_wada「文化の醸成は年単位の事業になる。だいたい2年ぐらいかかる。」 #jopf

— みよひで。オシャレ男子になりたい (@miyohide) 2016, 2月 16

一日二日でできるとは思っていないんですが、まさか年単位とは。

そのため、勢いで乗りきれるほど甘くはなく、戦略と戦術でもってテストを書く文化を醸成しましょうという話に続きます。

スライド10ページ目で引用されている『テストを書く時間がないのではなく、テストを書かないから時間がなくなるのだ』

t_wada「『テストを書く時間がないのではなく、テストを書かないから時間がなくなる。』James Grenning
」 #jopf

— みよひで。オシャレ男子になりたい (@miyohide) 2016, 2月 16

でさらっと、テストを書かない理由No.1に対する厳しい答えを提示し、戦術として「どこから手を付けるか」（スライド21ページ目）や、「テストでこだわりがちなところに対する警鐘」（スライド24ページ目）、「テストでのこだわりポイント」（スライド25ページ目）を例示されて、一つ一つが勉強になりました。

で、どうする

一番手っ取り早いのは、自分のテストスキルを上げることかなと思います。発表の中でも言われていましたが、「レガシードコード改善ガイド」を読んで用語や考え方を身につけ、

レガシーコード改善ガイド (Object Oriented SELECTION)

実際にテストを書いてみるというのを自分はやっています。

Ruby/Railsでは、『Read Everyday Rails - RSpecによるRailsテスト入門 | Leanpub』や『Rails 4 Test Prescriptions』などがよいように思います。

pragprog.com

後は、公開されているOSSには結構テストが書かれていないことが多いので、テストを追加するPull Requestを出すというのもいい勉強になるかなと思っています。

実際に組織に展開するというフェーズについては、それぞれ組織ごと・チームごとに異なるように思えます。私が言われたものでも、

• テストを書く時間がない
• テストを書くためのスキルがない
• テストコードの品質が担保できない
• それは（QA｜開発者）の仕事
• テストコードによって生産性が上がるといった定量的指標がない

などなど。あー言えばこー言う状態なので、真正面でぶつかってはダメで、地道に答えを用意するのが一番早いように思っています。

それか、トップを仲間につけてトップダウン式で強制させるというのもある組織形態では有効な気がします。

冒頭で書いた「文化の醸成は年単位の事業になる」という言葉を旨に、いろいろと試行錯誤するしか無いのかなと思っています。

某Webマガジンのベースシステム移行計画（案だけ）

きっかけ

先日、Yokohama.rbにて某Webマガジンに最近コミットしている人たちが複数人集まったので、その話が盛り上がりました。実現するかどうかは分かりませんが、ちょっとメモっておきます。

もともとの要望

もともとは、「markdownで記事を書きたい」という要望です。Webで表示するコンテンツを書く上で、特にエンジニア界隈ではmarkdownは標準的な知識として定着したように思えます。そのため、独自文法よりもmarkdownで書きたいというのは自然な要望かと思います。

潜在的な要望

ただ「新しい文法で記事を書きたい」というのは理由としては表面的なもので、潜在的な要望としては次のものがあることが分かりました。

• 現在の文法では表現できていないものがあるので、それを解消したい
• 著者自身がローカルでレイアウトなどを確認しながら記事を作成したい
• その他もろもろ

新しいシステムは何がよいか

こういう要望が高いことが分かったので、「markdownで記事が書けるシステムは何が良いか」というのをちょっと探してみました。探してみたのは、いわゆる静的サイトジェネレーター。Ruby製で言えば、

• Jekyll
• Octopress
• Middleman

ぐらいでしょうか。また、コンテンツマネジメントシステム（CMS）もおそらく調査対象になるかなと思います。まだ調べ始めた感じなので、それぞれ使い勝手をいろいろと見ながら方向性を決めていきたいなと思っています。

ざっと必要な機能を洗い出してみると、

• markdownで記事が書けること
• ソースコードのシンタックスハイライト機能があること
• 画像を貼り付けることができること
• ユーザ認証機能があること
• アクセス制御機能があること
  • 特定の日まではユーザ認証を受けた人だけしか参照できない
• 目次作成機能
• 類似記事リスト化機能

ぐらいなので、後は触ってみた感じで適当に選んでみることでしょうか。

なお、「自作する」というのは除外しています。そもそもスタッフが少ない中、できるだけ手間を掛けたくないという思いがあります。そのため、どうしてもメンテナンスが高くなる自作についてはちょっと除外したいなと考えています。

運用フロー

システムと同様に、運用フローについても考えないといけません。できれば、pull requestを出すことで回していきたいという思いがあるのですが、随時に記事をリリースする形ではなく、定期刊行という形を取っている以上、ちょっと難しいかなと思っています。

また、費用面の問題もあり、できるだけ低コストで済ませたいという思いがあります。

移行

実は、一番頭を悩ませているのがこの移行です。すでに少なくない記事をリリースしていることもあり、移行するとなるとちょっと頭を悩ませる問題です。

移行と言っても様々な方式があり、ざっくり

• ばっさり切り捨てる（全部なかったことにする）
• 静的HTMLとしてどっかにホストしておき、新システムとは別のものとする
• 新システム用に全部移行する

という案が挙げられます。バッサリ切り捨てるというのは多分ありえないので、静的HTML化か新システムに移行かの二択ですが、また、いろいろと考えてみようかなと思います。

最後に言い訳

ということを考えたり考えなかったりしていたら、いつの間にか年末になったので、この冬休みの間にでもちょっと調査してみようかなと思い、エントリ化してみました。が、実現できるかどうかはまた別の話です。

RubyKaigi 2015のStaffとしてRubyKaigiの運営お手伝いをした

はじめに

2015年12月11日（金）〜13日（日）で開催されたRubyKaigi 2015。そこでRubyKaigi 2015のStaffとして参加しました。ここでは、Staff目線で今回のRubyKaigi 2015を振り返りたいと思います。

きっかけ

そもそもRubyKaigi 2015のStaffになるきっかけは6月某日にオーガナイザーから来た1通のMessengerでした。Messengerには

「ぼくといっしょにRubyKaigiをつくりませんか」

と記されておりそこから今回の話がスタートしました。大変なことになるだろうなとは思いましたが、オーガナイザーの熱い思いに感化され、10分ぐらいで「はい。よろしくお願いします。」とお応えしました。

準備

地域Ruby会議をStaffとして参加したことはありますが、RubyKaigiのような大規模カンファレンスでのStaff経験は初めてです。地域Ruby会議とは

• 入場者数
• スポンサー
• 用意するノベルティや設備

などの面において桁が変わってきます。普段のn倍だから...とのんきに構えられる量ではなく、いろいろと考えることが増えました。

具体的には、入場者がスムーズに動くことができるためにはどのように会場をレイアウトすれば良いか、ノベルティは何日前に発注*1し、いつまでに入金しなければいけないか*2、送付される荷物の量は会場のキャパに収まるかなどなどを考えてデザイナーさんや振込担当者さん、業者との調整をするのは今回初めての経験で、色々と勉強になりました。

チーム間のコミュニケーションにはidobataとesa.ioを使いました。idobataは簡単なチャットとして、esa.ioは議論の叩き台やまとめを書く場所としてそれぞれ活用しました。ちなみに、esa.ioといえば、このるびまの記事を読むといいと思います。

文字ベースのやりとりだけでなく、ミーティングを重ね、徐々にオーガナイザーや他のStaffと言葉をかわしていきました。Staffはそれぞれ別の会社に勤めているので、いわゆるオフラインミーティングを取るのは二週間に一度ぐらいが限度だったのですが、オンラインミーティングを随時に入れ込むことでカバーしました。文字ベースだけのやり取りは誤解を招いたり、真意が伝わりづらいことがあるので、こういうやり取りは良かったかと思います。
オンラインミーティングとして使用したツールとしてはhangoutsやSkypeが多かったです。これらのサービスは回線速度があまり出ない時でも安定してコミュニケーションを取ることができました。

自分の中では、当日発注したノベルティや準備品などの荷物がちゃんと届いているかは不安だったのですが、当日、会場に入った時にパーカー・Tシャツ・ストラップ・名札・各種機材等々が全部届いているのを見た時、心のなかでガッツポーズしました。

当日

私に割り当てられたタスクは会期運営。会期中起こることをいい感じにハンドリングして、いい感じに解決するというお仕事を担当しました。

具体的にはHall Aにてタイムキーピング、各種アナウンスを受け持っていたのですが、その他にアナウンス・スライド内容の作成と調整、撤収作業に向けた各種手続き、ゴミの回収と片付けを実施していました。

また配布品の一つとして、スケジュール表がありました。これはオーガナイザーの方による提案で作成に至ったのですが、これが我々Staffの中でも大活躍。自分はここにいろいろと書き込みをして、アナウンス内容等を忘れないようにしました。

そんなこんなでドタバタしぱなっし。うまく行ったとかドジッたとかそういう実感を感じる間もなく3日間が終わってしまい、とりあえず乗り切った感が強いです。

終わりに

なんだかんだあっという間に過ぎ去った3日間でした。会場の片付けが終わり、自宅に帰ったらただただ泥のように眠ってました。会期中はあまりセッションの内容が聞けなかったので、スライドや後日公開される動画でゆっくり復習しようかと考えています。

あ、来年は京都のようですね。会期期間中、「来年は5K FUN RUNをやってみたら？」と言われたので、ちょっと音頭とってやってみようかなと思ったり思わなかったり。真夏の京都ということでかなりつらそうですが(^^ゞ

*1:だいたい10営業日前がデッドライン

*2:基本は前金。受け取り日付と業者の稼働日に合わせて振込する必要あり

「Crafting Rails 4 Applications」をオンライン読書会で読み終わりました

はじめに

「Crafting Rails 4 Applications」という本を、先日読み終わりました。

今回、この本を読み終わるために、オンライン読書会という手法を使わせていただきました。このエントリーでは、読み終わるためにやったことを記します。

本の紹介

「Crafting Rails 4 Applications」は便利なツールを作ることを通してRuby on Railsの内部構造を解説していくという1冊です。The Pragmatic Bookshelfにて発売されており、DRMフリーなPDFが購入できます。

pragprog.com

Ruby on Railsを勉強しはじめ、RailsTutorialを一通りこなした人が読むと良い本と紹介され、読んでみることに。洋書ということもあり、英語の面が気になりましたが、

• サンプルとして公開されている部分を読むと、辞書片手に読めなくはないと思った
• ソースコードとテストコードがそれぞれ丁寧に書かれているので、最低でも何かモノが作れる

という思いがあり、読み進めることにしました。

挫折しないために

それでも洋書は読み続けることは難しいです。和書でさえ積読にすることが多いのに、洋書を読み進めることができるんだろうかと不安になっていました。

ちょうどその頃、 @tatsuoSakuraiさんが「オンライン読書会で読み進めませんか？」というお誘いをいただき、それに乗っかってみることにしました。

オンライン読書会とは

我々がやったオンライン読書会は、月に2回それぞれ1時間の枠でWebチャットのLingrに集まり、本を読み進めるというものでした。

当初は本文を1文1文訳していましたが、さすがにそれだと進みが悪かったです。そこで、参加メンバーが固定化された時からは、ある程度予習していることを前提に、「ここはこういうことを書いていますよね？」という形で段落単位でざっくり読み進める形にしました。

また、ソースコードが出てきた時には写経をしました。写経には5分や10分程度の時間を取り、実際にソースコードを入力し、実行します。

写経は、本に書いているソースコードを自分で入力するということだけですが、実際にテストを動かしてみると失敗したり、異常終了したり。本に書いていないことが次々と起こります。理由はいろいろありますが、

• 単なるタイポ
• 本が書かれた時とはフレームワークやライブラリがバージョンアップし、仕様が変わった

が主な原因だったように思います。後者は特に原因追求が難しいので、最初は本に書かれているバージョンで写経すると良いかなと思います。 ただ、それだけでも写経は意味があるものと思っています。特に本に書いていない挙動を起こすと必然的に本を必死で読み返し、ソースコードの意味を理解しようとするので、写経の際にわざと間違えてみるというのも良い勉強方法では？と思ったりします。

予習

オンライン読書会の進め方が変わったことも有って、予習をちゃんとするようにしました。 自分がやったのは、読書会の前になると定期的に該当ページを印刷し、わからない単語は辞書で調べ、意味が通る日本語訳にするようにしておきました。こういうときにDRMフリーのPDFが買えるのはいいですね。

もちろん、全部きれいな日本語訳にできたわけではないですが、わからないところと印をつけておいて、読書会で聞くようにしました。

それにしても長かった

第1回の読書会が2013年8月19日、終了したのが2015年11月2日でしたので、かれこれ2年以上やりました。流石にひと月に2回、1回1時間という枠だと短い感じがします。オンラインという特性を活かして、もう少し頻繁にやっても良かったのかもしれません。

謝辞

それでも、2年以上続けられたのはオンライン読書会に参加してくれた人が居たからです。企画者である@tatsuoSakuraiさんやRuby on Railsの最新動向に詳しい@y_yagiさん、英語訳について適切な指摘をくれた@netwillnetさんには助けられました。ありがとうございました。

積読消化合宿というのをやりました

はじめに

9月4日（金）の夜から6日（日）にかけて、積読消化合宿というのをやりました。積読合宿とは、技術書なり小説なり、買ったことに満足して読み終わっていない本、いわゆる積読を消化することを目的に温泉旅館に篭って本を読むことです。

場所

温泉で有名な熱海にしました。理由は色々とあるのですが、

• 温泉があること
• 金曜日の夜に移動しても十分早い時間に到着すること
• 料理が美味しそうなところ

といった感じで適当にネットで引っかかった場所を選択して、泊まることにしました。今回は湯宿一番地さんにお世話になることにしました。

www.yuyado-ichibanchi.jp

いわゆる開発合宿ですと、

• 無線LANが整備されていること
• 机と椅子があること

って言ったこともポイントになるのですが、各人思い思いの本を読むだけでしたらそういう点は考えなくてOK。普通に旅行気分で行きました。

本

今回、読もうと思っていた積読本は以下のものです。

• メルマガ「メディアの現場」3回分
• Effective Ruby

Effective Ruby

• 入門React

入門 React ―コンポーネントベースのWebフロントエンド開発

一昔前でしたら、本を持っていくというのはかさばるし、重いしで億劫だったのですが、昨今の電子書籍とガジェットの普及により、紙の本を持って行かなくても良かったのは楽でした。

代わりに電源については気を配らないといけないので、電源タップにAnkerのUSB充電器を持っていって電源難民にならないように対応しました。

Anker 40W 5ポート USB急速充電器 ACアダプタ PowerIQ搭載 iPhone6/iPhone5C/5S/5/4S/4/iPod/iPad/Xperia/GALAXY/ウォークマン等対応 【PowerIQ搭載】 71AN7105SS-WJA

結果

目標としていたもののうち、メルマガと『Effective Ruby』は読了。『入門React』は半分まで読むことが出来ました。

5名で行ったのですが、みんなが本を読んでいると「自分も読まなきゃ！」という思いが出てきてゆるい強制力のもと本を読むことが出来ました。Twitterやテレビなどに逃げることができないという環境が作り出せたので、たぶん、一人だと難しかったかなと思います。

また、ちょっと歩くと海に出ることができるので、読書に疲れたら散歩と称して気分転換。汗を温泉で洗い流してまた読書に戻るということで、ドンドン本を読むことが出来ました。

感想

当初の目的である積読消化はだいたいクリアでき、気分もリフレッシュ出来たので大成功だったのかなと思います。毎週末やるってわけにはなかなか行きませんが、1年に1回はこういう風に本を読むという場を設けても良いのかなと感じました。

Atom Editorへの乗り換えを考えている その2

やっぱり機能拡張があると嬉しい

AtomにはPackageと呼ばれる機能拡張がたくさんあるみたいで、8月30日（日）時点で2,600件ほどあるみたい。いろいろと入れて便利にしようと、Packageを探す旅に。

とりあえず、色々と入れてみて試したものを記します。

atom-runner

編集中のプログラムをショートカットキーで実行できる。実行結果は画面が分割されて右に出てくる。

file-icons

ファイルのアイコンを変更できます。視認性だいじ。

file-types

拡張子とファイルの種類の関連付け。積極的に入れた覚えがないんだけど、なにかの依存関係で入ったのかな？

git-control

AtomにGitのGUI環境を提供してくれる。とりあえず入れてみた感じ。あんまり活用していない。エディタの部分で右クリックして「Toggle git-control」を選択すると出てくる。

git-plus

Gitの操作をコマンドパレットから行うことができるPackage。Atomでは「cmd-shift-p」でコマンドパレットというものが呼び出され、現在開いている画面に関連した内容が列挙されます。

そこで、「git」と打てば、Gitに関するコマンドが入力できるというのがこのPackage。

language-javascript-jsx

Reactのコードを書くときにSyntax Highlightが欲しかったので。

linter

シンタックスチェックなんかを行ってくれるPackageの基盤となるもの。実際には、言語に合わせたPackageが必要。

linter-jshint

JavaScriptのLinter。JavaScriptのLinterって色々種類があるようだけど、特に思いはなかったのでJS Hintで。こんな風にエラーが出ます。

linter-ruby

RubyのLinter。こんな風にエラーが出ます。

open-recent

最近使ったファイルを開くってもの。

tabs-to-spaces

タブとスペースとの相互変換。

まとめ

とりあえず、現状で入れているPackageを書いてみました。まだまだAtom一本で生活するってほどではないのでこれぐらいの数で済んでますが、依存度が高くなるとPackageが増えてくるかもしれません。

Atom Editorへの乗り換えを考えている

はじめに

ある日何を思ったのか、Vim Pluginの更新をしようとneobundle updateをかけたらよくわからないエラーメッセージが出ちゃいまして。

そこでエラーメッセージを解決するのが正しい姿かと思うのですが、「おれはエディタのメンテをしたいんじゃない、単にコードを書きたいだけなんだ」という思いのもと、Vimからの脱却を考えるようになりました。

そこで目につけたのがAtom。周りでも乗り換えている人が多いので、自分も乗り換えてみることにしました。

なお、ここでは、Atom 1.0.7を使いました。

エディタに求めること

普段の生活を見直すと、エディタを使うシーンは色々ありました。

• WindowsとMacで動いて欲しい
  • 会社ではWindows、家ではMacを使っているので。
• 設定が楽であること
  • なんちゃらrcとかのファイルをあまりメンテナンスしたくない。
  • とはいえ、複数のマシンで使ったりするので、設定は何らかの形で共有化したい
• RubyやGo、JavaScriptのコードを書くこと
  • ある程度補完が効いて欲しい。do - endとか{を入れたら}が入力されるとか。
  • ショートカットキーを入れたら、スクリプトが実行されると嬉しい。
• Markdownを書く
  • プレビューしたいなぁ
• VMやサーバにあるファイルを編集する
  • これはVimかなぁ。

Atomでやったこと

• [Atom] - [Preference]で[Settings]画面を出し、フォントとThemeを設定
  • [Font Family]の欄に直接「Ricty」と入力する。ここ、フォント設定パネルとか出してほしいなぁ。
  • Themeはhttps://atom.io/themesからよさ気なものを選択してインストール。
  • インストールは、[Install]で[themes]を選択してキーワードを打つと出てくる。インストールすごく楽。
  • Themeの適用は[Themes]から。
    • Macだとデフォルトでよさ気なんだけど、自分のWindows環境だと黒がだいぶ強め。入力欄が見にくい。
    • スタイルシートをいじるっていう手もあるけど、あまり手を掛けたくないので、Themeで頑張ることに。
    • いろいろと試して、[UI Theme]は「Atom Light」に、[Syntax Theme]は「Monokai」にしてみました。
    • たぶん、ちまちまと適当に変える予定。
• 会社でのインターネット接続にはProxyという山があってですね...
  • .atom/.apmrcに「https-proxy = http://ユーザID:パスワード@ホスト:ポート番号」と書けばOK

今日はここまで

ここまでで私のブログを書く気力が尽きたので、続きはまた後日。