レガシーコード改善勉強会でした。 #wewlc_jp
運営について
アークヒルズサウスタワーにある、Yahoo さんの会議室でした。
オープニング
発起人?の方から、オープニングとして次のような話をうかがいました。
- この集まりの目的は何?
- 改善について議論できる下地を作ること
- 今後どうしたいか
- ITの力の最大化
- レガシーコードを改善しなくてよくなる
- レガシーコードの改善が当たり前に
- 今回はウルシステムズさんと一緒にやらせていただいた、もっといろいろ広げたい
- それ以上は分からない
アンケート用紙が配られていて、その集計結果次第で第二回、第三回があるかもしれない、とのこと。
セッション1
演者の稲葉さんが都合が悪くなってしまったとのことで、代役で訳者である平澤さんが書籍の内容をざっくりと説明するセッションになりました。
平澤さんはドメイン特化言語、リファクタリングも訳されてる…大物感。
一番記憶に残ったのは、レガシーコード改善ガイドがすでに七刷にもなっていて、一定したペースで売れ続けているということでした。
息が長いっていいことですねぇ…
書籍の内容ですが、書かれているのはビルドできるコードのことが多い。
なので、よくわからない設定ファイルや、ビルドできないコードについても、同じような(場合によってはもっとヒドい)戦いの記録がありそうだなぁと思いました。
セッション2
kyon_mm による方法論の話。
何のために、どういうことをやればいいのか、積み上げていく感じで分かりやすいものでした。
- 変更するなら、そのものを知らなければならない
- 知るためには、役割、目的に応じて適切なツール(ものであったり技法であったり)を使うべき
- ツールの使い方なんてもはや教養なので学べ
1 bleis 月とか 1 kyon_mm 月とかの人に特化した規模感がなんとなく危ういなぁとか思ったので、懇親会で会話してみたのですけど、
いまいち伝えられなかったのが残念でした。
kyon_mm 曰く「PO と QA を兼任してるけど、やっぱりコードが書けてテストもできる人がやるべきだよ!」(意訳)って言ってて、
それ巷で話題のフルスタックエンジニアですよねー、とツッコんでおきました…
セッション3
goyoki による心構えや振る舞いについての話。
以前見かけたときより健康そうな雰囲気でした。
大枠として次のような分類で課題と目標、実際のアプローチを説明していました。
- 人
- 環境
- アプローチ
保守性の話で、リスク分析して優先度を付けて要件にして、そのトレーサビリティを保つようにしていく、という話を聞いていて、
「で、誰が何をどうするから、誰がどう嬉しいんだろう」というのが分からず隙間時間(という名の休憩時間)に聞いてみましたけど、やっぱりよく分かりませんでした。
今度機会があったら聞いてみよう。
セッション4
ソニックガーデンの西見さんでした。
今回も Point of Sales と Point of Use のグラフが紹介されていたんですが、個人的に何か腑に落ちていなかったんですけどその理由が分かりました。
それぞれで、縦軸の縮尺が違うはずなんですよ。
納品時点での利益?が最大、という場合、利用者が要求したものが10入っているとする。
一方、使い始めたときから利益?が最大、という場合は、最初の時点では要求したものが1か2しか無いはず。
なのに、それらを同じ縮尺であるかのように見せている…これがグラフの魔術!!
今回も、組織的に技術基盤を揃えて、その効率を高める戦略は素敵だなぁと思いました。
セッション6
Yahoo トップページ部隊としての佐藤さんでした。
組織内でコード改善をする機運を高めて、実際にやってきたという話。
namespace で関数名を隠蔽してスタブ関数を実行する、というトリッキーなテクニックとかを紹介されてました。
懇親会で、テストコードのサンプルを作りこんで「さあお前ら手を動かせ」的なアプローチを取らざるを得なかった、などの裏話をお聞きして、
見かけによらずパワーのある人だなぁと思いました。
セッション7
誤タイプを招く ID 体系を導入されている t_wada さん。
こちらも一番最近の記憶に比べて健康さが増しているように感じたのですが、実際はそうでもなかったっぽい。お大事に…
お話をまとめるとこんな感じでした。
- 状況を具体的にして
- 一番やばいところから
- できることを一つずつ
- 確実にやっていけ
- 高望みするな
早速やろうと思って、話を聞きながらどうにかこうにか自動ビルドを復活させたりしてました。
エッセンシャルスクラムが出版されました。よかった。
初めてのなんとかです。
会社帰りに最寄りの書店で陳列されていることを確認しました。
発売日は7月7日だと思ってたんですが、書店によってぶれる模様。流通とか関係あるのかもしれない。
これがなんなのか、ということをここから書いていきます。
エッセンシャルスクラム
エッセンシャル スクラム: アジャイル開発に関わるすべての人のための完全攻略ガイド (Object Oriented Selection)
- 作者: Kenneth Rubin,岡澤裕二,角征典,高木正弘,和智右桂
- 出版社/メーカー: 翔泳社
- 発売日: 2014/07/08
- メディア: 大型本
- この商品を含むブログ (7件) を見る
私の関わり方
- きっかけ
- 隣から「タスケテ」って聞こえてきたのでのこのこ首をつっこんでみました
- ところがそうそうたるメンバーですごい冷や汗
- やったこと
- 序盤のあの章とあの章を翻訳したり
- 全体をレビューしたり
- レビューアの方の指摘を取り込んだり
ありがとうございました
TDD の人としてテストに導かれた設計をする前に、id:digitalsoul に導かれて別のジョブ(翻訳者)の熟練度が上がってしまいました。
id:akon に見本出来をお見せしたら「この人(著者)と一緒に仕事したことあるよ」とかまるで親戚のことみたいに出てきたのは面白かった。
5年10年前には想像もつかない生活をしていて、自分が怖い。
なんで自分と同じたくさんの読み手の人たちと仲良くなるのを通り越して、書き手の人とのつながりが強くなってるんだろう。
今まで何度か翻訳のレビューをさせていただいた際、私は楽しかったのですが、書いた側としてはどうなんだろうな、と少し心残りがありました。
ですが、今回レビュー指摘をいただく側になってみて、「こっちも楽しい」と思えたのは発見でした。
なんというか、隙がなくなるというか、研ぎ澄まされていく感がよい。
もっとやりましょう。
あと、ソフトウェア開発をする人の役に立ちそうな本、自分でも買いそうな本を、まだ見ぬ誰かにお届けする手伝いができたのではないかと思います。
先代に受けた恩を次代に返すことができる機会はそうないので、自画自賛ではありますが、自分にとっては高評価な出来事です。
今回のお話(翻訳やろうZE!)の中で私が果たせた役割といったら、id:digitalsoul の懐刀どころか、せいぜいかばんに入ってる折りたたみナイフくらいのものだろうと思います(注:入ってません)。
悔しいので、今後もめげずに積み重ねていこうと思います。
■
[misc] 越えられない壁
スポートニュース眺めてて気がついた。
私はスポーツのプロ選手を見て「この動きは無理だろう…」と感じる。
これってプログラムの出来ない人がプログラマーのやってることを見て感じてることなんじゃないかしらん。
どんなところにも階層構造はできるんだなぁ、という納得感を得た。
(とはいえ実際はそんなに敷居は高くない、と思ってる。)
[cucumber] cucumber 1.3.14 が動かないなぁ…
https://github.com/yujiorama/atdd_airport_parking_lot
ナンデ?
rubypython ナンデ?
$ cat Gemfile source "https://rubygems.org" gem "cucumber" gem "rspec" gem "selenium-client" # missing... gem "ramaze" gem "rack-test" gem "webrat" gem "rubypython" $ ruby -v ruby 2.1.1p76 (2014-02-24 revision 45161) [x86_64-darwin13.0] $ bundle exec cucumber -r . -r etc -r step_definitions valet.feature undefined method `find_hidden_method' for BasicObject:Class (NoMethodError) /tmp/atdd_airport_parking_lot/vendor/bundle/ruby/2.1.0/gems/builder-3.2.2/lib/blankslate.rb:61:in `find_hidden_method' /tmp/atdd_airport_parking_lot/vendor/bundle/ruby/2.1.0/gems/builder-3.2.2/lib/blankslate.rb:61:in `find_hidden_method' /tmp/atdd_airport_parking_lot/vendor/bundle/ruby/2.1.0/gems/builder-3.2.2/lib/blankslate.rb:61:in `find_hidden_method' /tmp/atdd_airport_parking_lot/vendor/bundle/ruby/2.1.0/gems/builder-3.2.2/lib/blankslate.rb:67:in `reveal' /tmp/atdd_airport_parking_lot/vendor/bundle/ruby/2.1.0/gems/rubypython-0.6.3/lib/rubypython/rubypyproxy.rb:103:in `<class:RubyPyProxy>' /tmp/atdd_airport_parking_lot/vendor/bundle/ruby/2.1.0/gems/rubypython-0.6.3/lib/rubypython/rubypyproxy.rb:62:in `<module:RubyPython>' /tmp/atdd_airport_parking_lot/vendor/bundle/ruby/2.1.0/gems/rubypython-0.6.3/lib/rubypython/rubypyproxy.rb:7:in `<top (required)>' /tmp/atdd_airport_parking_lot/vendor/bundle/ruby/2.1.0/gems/rubypython-0.6.3/lib/rubypython.rb:26:in `require' /tmp/atdd_airport_parking_lot/vendor/bundle/ruby/2.1.0/gems/rubypython-0.6.3/lib/rubypython.rb:26:in `<top (required)>' /tmp/atdd_airport_parking_lot/vendor/bundle/ruby/2.1.0/gems/cucumber-1.3.14/examples/ruby2python/features/support/env.rb:1:in `require' /tmp/atdd_airport_parking_lot/vendor/bundle/ruby/2.1.0/gems/cucumber-1.3.14/examples/ruby2python/features/support/env.rb:1:in `<top (required)>' /tmp/atdd_airport_parking_lot/vendor/bundle/ruby/2.1.0/gems/cucumber-1.3.14/lib/cucumber/rb_support/rb_language.rb:95:in `load' /tmp/atdd_airport_parking_lot/vendor/bundle/ruby/2.1.0/gems/cucumber-1.3.14/lib/cucumber/rb_support/rb_language.rb:95:in `load_code_file' /tmp/atdd_airport_parking_lot/vendor/bundle/ruby/2.1.0/gems/cucumber-1.3.14/lib/cucumber/runtime/support_code.rb:180:in `load_file' /tmp/atdd_airport_parking_lot/vendor/bundle/ruby/2.1.0/gems/cucumber-1.3.14/lib/cucumber/runtime/support_code.rb:83:in `block in load_files!' /tmp/atdd_airport_parking_lot/vendor/bundle/ruby/2.1.0/gems/cucumber-1.3.14/lib/cucumber/runtime/support_code.rb:82:in `each' /tmp/atdd_airport_parking_lot/vendor/bundle/ruby/2.1.0/gems/cucumber-1.3.14/lib/cucumber/runtime/support_code.rb:82:in `load_files!' /tmp/atdd_airport_parking_lot/vendor/bundle/ruby/2.1.0/gems/cucumber-1.3.14/lib/cucumber/runtime.rb:184:in `load_step_definitions' /tmp/atdd_airport_parking_lot/vendor/bundle/ruby/2.1.0/gems/cucumber-1.3.14/lib/cucumber/runtime.rb:42:in `run!' /tmp/atdd_airport_parking_lot/vendor/bundle/ruby/2.1.0/gems/cucumber-1.3.14/lib/cucumber/cli/main.rb:47:in `execute!' /tmp/atdd_airport_parking_lot/vendor/bundle/ruby/2.1.0/gems/cucumber-1.3.14/bin/cucumber:13:in `<top (required)>' /tmp/atdd_airport_parking_lot/vendor/bundle/ruby/2.1.0/bin/cucumber:23:in `load' /tmp/atdd_airport_parking_lot/vendor/bundle/ruby/2.1.0/bin/cucumber:23:in `<main>' FAIL: 1
DDD再読
今年で定年になってしまうので初心に立ち返って勉強し直すことにした。
まずはDDDを読み直します。
この辺にメモを書いてこうとしてます。
yujiorama / DomainDrivenDevelopment / wiki / Home — Bitbucket
毎週土曜日午後から、会社で自習していくつもり(3月22日現在)。
JJUGイベント 「祝☆Java 8 Launch」の感想
【東京】JJUGイベント 「祝☆Java 8 Launch」3/21(金/春分の日) - 日本Javaユーザーグループ/Japan Java User Group | Doorkeeper
@khasunuma さんによる「Brand new Date and Time API」のセッションが印象的でした。
APIの説明をするにはISO8601について説明する必要があり、そのためには日時の定義を説明する必要があり、そのためには日付の、そのためには時間の、そのためには秒の定義が必要で、、、
という感じでした。
それぞれの定義の説明が楽しい!
知っているもの(秒は原子時計で定義されてるとか)もあれば、まったく知らなかったもの(GMTからUTCに至るまでの経緯とか)もあったり。
肝心のAPIについてはサンプルコードをGithubで公開していただけてるので今度見る。
https://github.com/btnrouge/threetensamples
懇親会で @yusuke さんが「Chronon 超便利」とおっしゃっていたので、真に受けてIDEA13 を買ってしまいそうな気持ちです。
IntelliJ IDEA Ultimate 2018.2 – 株式会社サムライズム
転職エントリ
他意は無い。無いったら無いんですが、日頃の感謝を込めて。
from SI
昨年の4月末日、6年ほど在籍していた会社を退職しました。
良かったこと、良くなかったこと、色んなことがありました。
{ここにいろいろな出来事を書く}
今の私を形成している要素の半分くらいはそこで得られたものです。
いや言い過ぎか、でもいいや、それくらいはもらってるんじゃないかと思っています。
人間的に危機的な場面もありましたが見守ってもらいましたし。おかげで今は元気です。
本当にありがとうございました。
to SI
とある会社GxPと呼ばれるグロースエクスパートナーズ株式会社に応募(apply っていうとなんかかっこいいですね)して採用されました。現職です。
日々驚きの連続(もう10ヶ月も経つのに)ですが、楽しく仕事をしております。
具体的には、門番を自称する id:digitalsoul と共にアーキテクトチームのような立ち位置で生きています。もっと彼の荷物を引き受けられればいいなぁ。
- ベンチャーみたいな雰囲気と統制された雰囲気が混ざり合っているかのような感じです。
- 理由も無く無駄なことをやることは許さん!みたいなところが過ごしやすくて素敵です。
- 思考停止は容赦なく叱られます。
- (今は)人はそんなに若くないけど組織は若くてどんどん変わろうとしています。
自分を変える
自分の経験も棚卸しして、いらないものはどんどん捨てて新しいものを取り入れていかないといけないなと思っております。
まずはたまに出てしまう下請け根性を葬り去らないといけない。
これは必須(10ヶ月何してたんだっていうのは置いといて。結構根深い)。
それと面倒くさいと評判になりつつある点は訂正してきたいと思います。
具体的にはもっと提案するということを考えていきますよ。
補足
軽微なネタがあったので追記。
java-ja が始まった場所だった
- すっかり覚えてなかったんですが第一回チキチキ Java-ja 勉強会ミーティングに参加しており
- 10ヶ月経ってから一度来社(オフィスが西新宿にある頃に)していたことが判明
- java-ja が始まった?場所なのかと思うと感慨深い
- 今となっては誰も SI やってないのが面白い
向こう側の世界
- 名だたる面々が顔をそろえて
暗躍活躍しております。 - 自分には届かない世界(セレブっぽいイメージ)だと思ってた人達を身近に感じられて楽しいです。
- DDD 翻訳で知られている id:digitalsoul
- アーキテクト97本で有名な
@yusuke_arklanp@yusuke_arclamp - プラクティス本を読んだことのある人なら間違いなくお世話になっている @a_konno
- POStudy主催の @fullvirture
- マインドマッパーな @dproject21
- 総じて皆笑顔である
飲み会がカオス
- Why たこ焼き、おでん
- 油性ペンで顔面ペイント…
第n回GOOS(日本語版)読書会を開催しました
はじめに
実践テスト駆動開発の読書会でした。
5人くらいだったので話題とか時間とかいろいろと調整しやすかったです。
何をしたのか?
皆ひと通り読んでいる、ということだったので次のように進めてました。
1時間くらいで休憩を挟みつつ。
- 1部、2部
- 若干の思い出し時間を設ける
- ざっくばらんに気になるテーマを出して話す
- 3部
- オブジェクトの図を中心に育つ様子をトレース
- 4部、5部
- 超高速チラ見ガイド
感想
- TDDの一歩目って何
- 会話しやすい
- 少人数だから誰かを妨げることはあんまりない
- 素通りしてたところを拾えた
- 値型の分解、発芽、Bundling Up (忘れた)とかのあたりで「そもそもドメインって何を指してるの?」みたいなやつを回収できた
- 図の間違いを見つけた
- 3部でオブジェクトの図を流して見ていて「これ説明と合って無くね?」となり、調べたら翻訳原稿での誤りだったという。原著は合ってた
- 俺、設計やってない
- 3部でシステムが育っていくところを改めて見なおした結果、普段の仕事では全然やれてないことを思い知らされてしまったので猛省する
- 3部を納得しながら読んでいくために
- コードだけでも図だけでも片手落ちになるので、それぞれをくっつけながら読むとよさそう
- 4部5部は動かしてこそ理解も深まるし面白いのでは
- 「あるあるー」で済ましておくのではなく、書いた方が分かりそう
- 6部の話おもしろい
- 読んで無かったという orz
おわりに
「企画が下手」とかいろいろありますが前回の二倍を越える方々に来ていただいて嬉しいです。
これからも下手の横好きで続けていきたいと思います。
が、3部をうまく読む方法は今のところ思いつかないので、次回は4部5部をじっくり読むことにしようかなと思います。
参加いただいた皆様、本当にありがとうございました。