コンピュータやソフトウェアのあれこれ@道民(&元道民)
Archive for 9月, 2011
[Java][Cucumber][ATDD][TDDBC] cuke4duke を使い Cucumber を Java で使う
9月 29th
第5回アジャイルサムライ読書会 @札幌道場 開催
9月 29th
第5回アジャイルサムライ読書会 札幌道場を開催しました。
今回は参加者が少なかったので、急遽「先日行われた他流試合の動画を見る」ことにしました。
だから本当の意味では「読書会」ではないです。
時間内に見切れなかった動画を先ほど見終わりまして、ちょっとまだ興奮しております。
動画を見ながらのディスカッションは、github – agile-samurai-ja / supportのwiki
にまとめてあります。(「読書会」ではないけれど)
今回の動画で「グっときた」ところ
歯車の一つになった人間は仕事を楽しくできない
いいソフトウェアを作りたい人は、いいソフトウェアを作れなければいけない
日本の読者の皆さんへ 西村さん(@nawato)
アジャイルは方法論ではなく、自分がどう実践していくか、何ができるか、それが大事。
実際の体験を通した生の声(悩む者として、そして実践していった者として)を聞く事ができた気がします。
- あなたが顧客に価値を届ける
- 自分で考える自分のやり方
- 自分のやり方を自分でデザインする
「無理かも」と思える事、やれない理由はたくさんある。
自分の環境が不遇なのではなくて、やれない理由はどこにでもたくさんある。
そのような環境で、何をするか?「やろうとおもうか」「あきらめない」事の大切さ。
読書会を行う事によって「何ができるだろうか」をブレイクダウンして話し合う事ができているのかもしれないなと思いました。
マスターセンセイへの質問
ここで一番印象に残ったのは、マスターセンセイは答えを言わなかったこと。
道を示すヒントや「自分の場合はこうだった」という話はあったけれど「あなたのやり方はあなたが見つける事だよ」が答えなのかなと感じました。
札幌道場でしか話をしたことがなかったけれど、みんな同じような事で悩み、解決策を探っているのだなぁと心強く感じました。
実際、当日のディスカッションでも、この話題から派生して「実際みんなのところではどういう工夫をしているか?」という話題でたいへん盛り上がりました。
誰かの話を聞く事、思いやノウハウを共有する事って大切ですね。
読書会としての時間はここまで。
監訳者あとがき 角谷さん(@kakutani)
実は普段家でセッションの動画を見る事があまりないのですが、これはガツンときました。
「感極まる」ってこういうことなのか、これか、これなのか。
たくさんのメッセージを受け取りました。
- 本で得た答えを現実世界でどう生かす事ができるか
- 仕事が楽しくなるのは仕事の全体像が把握でき、仕事全体の質に責任を持つ場合である
- できない事をスコープして解像度を上げたらやれることがあるんじゃない?
- 毎日小さな奇跡をおこしながら作業をすすめる、それがプログラマ
- 本当にできないのか、それは言い訳じゃないか?
自分のこれからについて、そして、これからの読書会についていろいろ考えた。
わたくしごと
「歯車の一つになった仕事」で楽しくないと思った事が思い当たりすぎて。
自分の中で「あ、これは歯車だ、仕事だから、仕事しよう」とある意味で見切った・切り替えた・壁を作った瞬間というのがたくさんあります。
「チャレンジだととらえられる仕事をやっているかどうか」。
チャレンジと思えるかどうかは自分次第であったりもする。何か一つチャレンジできる事を見つける事を大切にしていこう。
そのような、気持ちの持ちようを再確認させてもらえました。
と、同時に「いいソフトウェアを作れる技術のあるプログラマ」「作るところを見せる事のできるプログラマ」になりたい、という気持ちを絶対に忘れないでいこうと思いました。足りない、足りなすぎる。
読書会に向けてのこころの持ち方
「マスターセンセイは概念でありマスターセンセイの世界で行われている事は理念の集合」そこで現実を見た時に諦めるか、それとも、そこからどう読み解くか、リトマス試験紙。
これは今後の読書会を進める上で心に留めておきたいと思いました。
「これができたら”アジャイル”だ、というものはない」、だからこそ読書会を通じてどれだけ各自が自分の世界に持ち帰ってできる事を見つける事ができるか、1人で読んだだけでは発見できない視点を提供できるか…。
ディスカッションの時間を大切にしている読書会としてこれからも現実世界の話を交えながら進めていきたいと思います。
「この本は”作る人に向けた本”」なので作る人として何を伝えていけるか、自分達に足りないところを直視しつつ、これからできる事を各自が探していけるきっかけになれるような読書会にしていきたいです。
最後に。会場を提供していただいた弊社に感謝。
毎回ありがとうございます。
そして、他流試合で札幌模造紙を用意してくださったスタッフの@ShiroKappaさん、それにレスポンスをくださった皆様、本当にありがとうございます。
地道に、あきらめないで、そしてこれからも「お客様を巻き込んでうまくやっていくために我々ができる事はなにか」というテーマを忘れずに、読書会を続けていきたいと思います。
次回からはまた、じっくりみんなで本を読み進めていきたいです。
しかし、あれです、あー、会場にいたかった。
TDD Boot Camp 札幌 2.1に参加しました
9月 29th
9月24日に行われたTDD Boot Camp 札幌 2.1に参加してきました。
当日の様子については@sue445さんによるまとめ – TDD BootCamp 札幌 2.1 #TDDBC があります。
今回もJavaチームのTAとして参加。
演習では「会議室の予約を管理するよくある社内システム」を構築するというのをslim3&GAEを使って行いました。
セッション等については他の方が書いていると思いますので、TAとして思った事を書いていきたいと思います。
反省点
いきなり、反省点から。
slim3というほぼ初体験のFWを使ったTDDBCだったにも関わらず、事前準備があまりできませんでした。
前日のJenkins勉強会の懇親会時点で、環境構築で戸惑っていた始末。
(なのに懇親会に行ったのか?・・・@sue445さんに懇親会でお会いできたからこその当日だったのです)
ミスリードはしないまでも、slim3を使った開発という面での技術的支援はあまりできなかったです。ごめんなさい。むしろ、slim3とGAEでバリバリ開発経験のある@t_hachinoheさんから学ぶ事が多かった!大変感謝しております。
翌週なんてどうなるかわからないから、時間のあるうちにできることをしておけ、と身をもって学びました。
TAとして伝えたかった事
今回は「実際の仕事で(時間的制約がある中で)どこを抜いて、どこは締めるのか」をチームプログラミングを通じて少しでも伝えられていたら良いなと思って演習を進めていました。
仕事には、期限があります。決められた時間の中でより良いもの、質の高いものを作っていく、そのために大事な事の一つとしてTDDという開発手法があります。そう思っています。
実際に1時間で1ユースケースをこなすのは時間が足りなすぎた。
完璧なロジックで、理想の形でTDDをやる(つまりはすべてのパターンのテストを作って開発していく)のはなかなか難しい。
で、目的を達成するために外してはいけないところはどこなのか。
今回のシステムの場合、短納期のプロジェクトだったらどうするか、そこで出した答えは
「GUIのテストは省く」
でした。まずはデータだな、と。
データの取得更新がシステムとして正しい事、これだけは確実にしておこう。
ロジックとして引数が美しくないところもありましたが「そこは次のイテレーションがあったらそこで改善する」と割り切りました。その分データ更新の部分はテストからきちんと書くことにしました。
全体の流れ、ユースケースを実現する事を意識して。
実際、本当に必要なテストも若干足りていなかった(バリデーションのパターンが足りなかったなど)のですが、そこについては
「ここは絶対にやっておいたほうがよいところ、間違いなくTODOコメントを残しておく事」
と適宜話していく感じで、外してはいけない部分は伝えられたかなと思います。
テストからインターフェースを考える、というあたりをチームメンバーが既に把握していたというのもあり、実践として、自分が仕事で得た経験を・・・共有できて・・・いたかな。
「時間的制約」を意識してもらえていたら良かったなと思います。
制約のある中できちんとしたものを作りたい
↓
短い時間の中でもTDDで開発したコードは動くという自信が持てる
↓
TDDで作っておけば少々コードがアレでもあとで安心してリファクタリングできる
↓
そもそも技術力が上がればもっとたくさんのコードがかけるよね
このどれかでも持ち帰っていただければ!
だんだん書いていて不安になってきました。これでよかったんだろうか。
たのしかったこと
みんなで考えながら、プログラミングをする事が純粋に楽しかったです。
いままでは「テスト駆動開発をしよう」という緊張感のようなものがメンバーにありましたが、今回はTDDを行う事は当たり前、自然な事であるという流れができていたような気がします。どうテストをするかという悩みもありましたが、それよりもその先をどうしようか「どう作っていこうか」という話し合いが多くできた事がとてもよかったです。
(準備をもっとしていればはまらなかった事もあったのですが)、みんなで頭をひねって考える時間、ソースを見ながらあーだこーだ言う時間がもてたのは「参加型」としてよかったことだったかもしれないな、なんて。
あと、自分のチーム懇親会参加率が100%だった。えへ。
終わったあとの鶏とビールは最高でした。

謝辞
毎回、素晴らしいスピード感でTDDBCを開催してくださる@shuji_w6eさん、今回も本当にありがとうございました。
JavaのTAとして事前準備をまかせっぱなしにしてしまい、さらに前日から(お酒の席にも関わらず)サポートいただいた@sue445さん、今回お会いできて本当によかったです。ありがとうございました。
そして、同じチームだった@hope_784さん、@onjiroさん、@t_hachinoheさん、当日撮った写真では大変疲れた様子でしたが、楽しんでいただけましたでしょうか。至らないところもたくさんありましたが、皆さんとプログラミングができて、私はとても楽しかったです!ありがとうございました。
次回はみっちり自分も鍛え上げられるtddbcにも参加してみたいです。
LOCAL DEVELOPER DAY ’11/Fall in KUSHIRO
9月 28th
今年もLOCAL DEVELOPER DAY’11/Fall in KUSHIROを開催することができました。
イベントからもう2週間が経とうとしていますが、ようやく僕の中で整理が付いてきたので、自分なりにまとめておこうと思います。時系列を追ってのまとめは、他の方が書いてくださっている通りなので、思うところを中心に。
自分のやったこと
今回僕は、こんな感じでこのイベントに関わりました。
- 主催団体の一つである一般社団法人LOCALの一員として、大まかな企画立案
- 当日の写真撮影
- いち個人の勝手企画として、澤田北海道ツーリストの催行
- そして、もちろん、一人の参加者として
なので、それぞれの観点、切り口から、振り返ってみようかなと思います。
イベントについて
今回のイベントの企画運営は、実質的には釧路OSSさんが主体となって動いて下さりました。釧路OSSの皆さまに感謝いたします。運営については、細かく見ていくと、改善するべき点などはあるかな、と思います。とはいえ、現状で出来る限りのことをしていただいた、とも思います。今後、もっともっと良くなっていくだろうなあ、と思っています。
そういった細かいことより、まず、今回、このタイミングで、この内容のイベントが出来たのがとても良かったと思います。特に、稲葉さん、june29さん、そして釧路市副市長の小松さんを迎えてのパネルは、釧路OSSだから実現できたのではないでしょうか。
単にパネリストに素晴らしい面々が並んでいて良かった、ではなく、内容が良かったと感じています。進行の斎藤さん、お疲れさまでした。
今回のイベントは1~3コマ目までテクニカルなセッションは無く、4コマ目の一コマにテクニカルセッションが平行3本走るという、なかなか他のコミュニティイベントでは考えにくい(と思う)タイムテーブルとしました。釧路OSSさん自体が開発者コミュニティではなくユーザコミュニティである点、また想定するイベント参加者像を考慮して、こうなっています。
いわば前半「非テクニカルの部」のまとめとなるこのパネルセッション、まず印象に残ったのが小松副市長との距離感の近さでした。
市でのOSSの活用について、一筋縄ではいかない事情などを紹介頂いたうえで「それでもうまくいけばみんな幸せになれるんだから勉強していきたいよね」という趣旨のお話を頂いたと記憶しています。(記憶ベースなので一言一句までは自信無いですごめんなさい) それ自体は、いや、もちろんとてもいいお話なのですが、それよりいいなあと僕が嬉しく思ったのは、こう、一緒に考えていこう!っていう空気といいますか、一緒に考えてくれているなあ、と感じられたことなのでした。「まずは足がかりに小さなサブシステムからですかねえ」というような話もあったかと思うのですが、今後もこういった意見交換が続けられて、実際の動きに繋がっていくと素晴らしいなあ、と感じました。
ところで、小松副市長は、毎日ブログを書いていらっしゃる素晴らしい方なのですが(これは簡単なことではないです)、当日の日記にもあるように、june29さんの「プレゼン」に大変感銘を受けていらっしゃいました。要するにZENスタイル、ということになると思うのですが、june29さんご自身が仰っているように、これは功罪微妙なところあるのかも、などと生意気にも思いました。僕はZENスタイルでのプレゼンなんてできないので、偉そうなことを言える身分ではないのですが。
june29さんのプレゼンテーションは、素晴らしいものでした。示唆に富んだ内容で、僕なんかは釧路が地元の人間でもなんでもないですが、とても勉強になりました。あと、「ITで釧路をでデベロップする」のdevelopを自動詞として捉える、というのは気付かなかった。テーマが大きかっただけに、話すポイントを絞り込むのが大変だったかと思います。本当にありがとうございました。
この日の前半「非テクニカルセッション」の土台となる、OSSサービスの現況について、1コマ目に稲葉さんにお話を頂きました。
内容としては、この日記を読むような方はどちらかというとOSSサービス提供側の方が多いぐらいではないかと思いますので、改めて僕から書くことはありません。今回のイベントは、普段OSSに接していない方も多いだろうという想定がありましたので、そういった方には興味深く聞いていただけたのではないかと思います。また、パネルセッションにおいては、「OSSはサポートをどうするのか」といった話題や、「OSSが基幹で使われるなんて考えられない」などといった質疑(会場から)などがありました。そういった問題こそ、どのような(どのように)OSSサービスを提供し、ユーザ企業はそれを活用していくか、という話題そのものになるのであろうと思います。今回は時間の制約上、内容を深めることができませんでしたが、時間が許すのであればその話題だけでもう一コマやれると面白かっただろうなあ、と思いました。稲葉さん、本当にありがとうございました。
懇親タイムについては、去年の日記を見てもらえれば大体いいかなと思います。また、その後のテクニカルの時間については、各所写真撮影で回っていて、それぞれのお話を聞いていないので、ここはちょっとどんな感じだったのかわからないです。
総じて、テクニカルに寄りすぎず、有志個人の集まりによるコミュニティで、地元の活性化をIT/OSSという視点から考えるコミュニティ、という色合いが出たイベントになったのではないかと思います。特定技術をテーマとしたコミュニティでは企画出来ないのではないでしょうか。と、こう書くと小難しい感じに見えますが(スーツの人が難しい顔をして難解なお話をしているような)、そうではなく、眠くなる余裕なんてない、とても充実したイベントでした。その点において、今回のイベントはとてもよかったと感じました。
写真撮影について
半分趣味なのでさらっと。
- 80-200/2.8は偉大
- 直進式の初期型だけど、AF遅いけど、ていうかなんかイマイチAF外すけど、VRもEDもないけど、それでも200/2.8じゃないと撮れない
- ISO1000でスピードライト使って-0.3EVでようやく1/100。これでも被写体ブレは避けられない。
- どうせ200mmになったら三脚使わないとどうしょもないんだからVRは無くていい(この用途なら)
- そりゃEDレンズ欲しいけど
- 自前のスピードライトの購入を検討すべきか否か悩むところ
- 普段使わないけどイベントの人撮りにはやっぱり必要だなあ
- SB-700かなあ
- 16-85/3.5-5.6 VRは失敗
- 広角全景用手持ちサブ機のレンズは17-50/2.8 VCにするべきだった。暗い。
- D7000ならISO1600とかISO2000とかで撮れるのかなあ・・・ほわわ
- 今回新たに導入した三脚は、モノに文句は無いんだけど如何せん重い。クルマじゃないと辛い。
まあ、記録としてはそれなりに撮れたと思うので、こんなもんじゃないかと思います。
澤田北海道ツーリストについて
無事故無検挙で良かったです。それが全て。
と、これだけじゃアレなのでもうちょっと補足すると、何より、往路が開始時間に間に合って本当によかったです。途中、国道区間で車が詰まったりとやきもきした場面もありましたが、無茶はせずに15分前には開場入りすることができました(ただし、今年も味噌汁は走行中の車内で飲むことになりました。ごめんなさい)。要するに去年の道中遊びすぎたことを反省して無駄を切り詰めた点と、イベントの開始を30分遅らせてもらったのが奏功した結果になると思います。そして、もし来年があるなら・・・来月、念願の道東道全面開通です。もっとラクになると思います。
そういえば、特に二日目の食事など気にかけて頂きみなさんすみません。
ツアーやるということは、つまりそういう事だと、最初からそのつもりでやっておりますので、何も問題ないのです。食べすぎたら眠くなっちゃうし。
あとは、観光スポットが好評で良かったです。2年連続で天候に恵まれなかったのは残念ですが、博物館も模擬坑道も素晴らしかったと思います。実際の採掘現場は暑いらしいですね。一回行ってみたいものです。
いち参加者として
今回のイベントを振り返っていたら、いつの間にか、経済圏の人口と、その地域に根差すコミュニティの傾向について考えていました。
大規模都市(たとえば東京)には、専門性が高いエッジのコミュニティが成立するように思います。それは当然と言えば当然のことでしょう。それぞれの専門分野(たとえば特定のソフトウェアや技術単位)でコミュニティを細分化(=狭く深くなる)していけるのかと思います。一方で、それらコミュニティ間の横のつながりというのは、どれぐらいあるのでしょう。あまり横で繋がらなくても、それぞれでうまく回っているのであれば、積極的に連携する必然性は薄いのかもなあ、などと思うのですが、結構繋がってる気もするし、その辺はちょっと何とも言えないところです。よく発表側に回る人ではなく、勉強会やイベントへの参加者レベルでの繋がりは当り前にあるものなのでしょうか。今ならtwitterでやりとりしますよね。いずれにせよ、こういった大都市圏では、2000年頃にはコミュニティが成立していたのかなあ、と思います。
中規模都市(たとえば札幌)には、エッジのコミュニティは成立しずらいのかなあ、と思います。もちろん、地方都市で最先端・エッジの事をやっている方はいらっしゃいます。が、大規模都市ほどその数は多くないため、エッジのコミュニティの成立が難しいのではないでしょうか。とはいえ、専門性の高いことに造詣が深い方や、それを仕事にしている方、興味がある方は居り、そういった方々が勉強会を開催しているのが現状ではないかと思います。コミュニティの単位としては、大都市ほどは専門性の高い切り方では成立しずらいけれども、ある程度で細分化して成立している感じなのかなあ、と思います(大規模都市にも、同程度のゆるい切り方のコミュニティは存在すると思います)。コミュニティ間の横の繋がりもある程度あって、たとえばインフラとセキュリティ、のように関連領域では、結局参加する人や主催する人が同じになりやすく、横の連携が行いやすいのかな、と思います。僕は札幌の事しかわかりませんが、ここ4-5年で、そういった勉強会が活発になったかな、という印象です。
では、小規模都市(たとえば釧路)は、どうなるのでしょうか。ここが2011年の今、問われているのではないでしょうか。
特定技術に細分化したコミュニティは、成立しないでしょう。元々の分母となる経済圏の人口が少ない上に、そういった地方都市ではITを専業とする会社がそう多くない、という事情もあるかと思います。そうなると、釧路OSSのように、様々な趣味・関心・指向がmixされたコミュニティが成立するのは必然かと思います。地方都市のコミュニティは、これを「特長」として自認する必要があるのだろう、と今回感じました。
専門性を求めても、大/中規模都市と同じことをやるのは難しいかと思います。話し手が居ない(居ても一人になってしまう)、参加者が集まらない、という状況では、やる方が疲弊してしまうだけになりそうです。そうではなく、むしろ大/中規模都市のコミュニティではあり得ないもの-関心領域の広さ、様々なポジション(見識、指向、社会的役割、職業)の人間の「組み合わせ」から生じる「活動の幅」-が持ち味になるのではないかと思います。今回の釧路OSSのイベントが、まさにそうだったのではないでしょうか。僕はじゅーんさんの「組み合わせる」を、自分たちにも向けられているなあ、と感じながら拝聴していました。
他の都市、特に大/中規模都市を真似ようとしない勇気が必要なのだと思います。自分たちが、自分たちをどうしたいか(たとえば、地域経済に貢献する、ITで楽しく暮らす、学生を育てる)を今一度見つめ直す必要があるかもしれません。そこでコンセンサスを得て、その目的のために活動していくことができれば、それが小規模都市におけるコミュニティのあり方として、新しいスタイルになるのかもしれない、と思いました。いや、新しいスタイルかどうかなんて、どうでもいいんですけど。その地域に貢献でき、かつ、やっている方も楽しいコミュニティが形成されるのではないでしょうか。
ところで、小規模都市におけるITコミュニティの成立下限規模は、どの程度なのでしょうか。釧路を見ていると、20万都市はいける気がします。10万都市はいけるのでしょうか。5万都市では無理なのでしょうか。きっと、それぞれの規模や地域に適したやり方があるのだと思います。それぞれの地域で、それぞれのやり方が見つかるといいのですが。
そんなことを考えていました。
ここまで書いて思いましたが、大規模・中規模・小規模都市って、たぶん独自の言い回しになっちゃってますね。学問上や社会通念上は違う区切りになるのかもしれません(政令指定都市はみんな大都市?)。そこは意図を酌んで頂けるとありがたく。
あともう一つ、じゅーんさんの出したキーワード「嫉妬」について。tweetもしましたが、とても共感します。これについて僕は「常に下の世代に嫉妬していられる状況を維持できれば、それがいい」と感じました。それ自体は常々思っていたことですが、「嫉妬」の一言で見事に表現しきったじゅーんさんのセンスには脱帽です。
結局、自分がいいなと思うものを一つでも残すことができれば、文化の拡大再生産と言うと大げさですが、バトンを繋ぐことができた、ということになるのではないでしょうか。そう考えると、何か一つでも自分が思う「良い方」に変えて、次に繋げることが大事なのでしょう。センパイはコーハイにオゴル、の繰り返し、みたいなものですかね。(ちがいます)
まとめ
要するに、いいイベントだった、みんなおつかれさま、釧路の今後に期待!ということでした。ここまで読んだ方、お疲れさまでした。
いやしかし、もうちょっと手短に書けないもんかね、おれ。
Jenkins勉強会 札幌に参加しました
9月 27th

https://wiki.jenkins-ci.org/display/JENKINS/Logo
9月23日(金)に行われたJenkins 勉強会 札幌に参加しました。
Jenkinsに触れるようになって1年あまり。
基本的なMavenプロジェクトの設定であればできるようになってきたかなという立場での参加でした。
JenkinsCIのコミッタの @cactusmanさんによるJenkinsの全体像のお話と@shuji_w6eさんの導入事例を、「どうやって広めていくか」という観点で興味深く聞かせていただきました。
あなたのプロジェクトはCIで何をやりたいの?
@cactusmanさんのこの問いは、今まで考えた事がなかったなぁ。
なんとなく、CIで実現したい事は皆同じであると思っていました。
でも、実際はプロジェクトによって、CIを導入する立場によってみんなやっている事が違う。
- 言語の違い
- 最終成果物の違い
- コンテキストの違い
- 目的による違い
だからこそ、闇雲に導入するのではなく目的を考える必要があるんだな。
導入する事そのものが目的になってはいけない。これはCIに限らず気を付けねば、と思いました。
- 何をやるかをはっきりしよう
- 簡単な事からはじめましょう
- 難しい事は後回しにしましょう
ローカル環境でも簡単に導入できるようなので、自分のプロジェクトを作った時には、テストをきちんと作ってCI環境もたててみようかな。
私のプロジェクトのJenkinsさん
余談ですが。
@shuji_w6eさんのセッション中にあった「仲間を巻き込んだプロジェクト」の渦中にて、Jenkinsを知った私です。
Tracよりなにより、一番親しみやすいツールでした。人名だから。
ロゴのおじさんにはとても愛着がわいています。
「おじさんが怒ってる!」
「はやくおじさんの怒りを沈めなくては!」
(CIビルドが通っていない時の会話)
「親しみを持つ」ことによって、メンバー間に”CIはあって当たり前”という空気が生まれてきたように思います。
今後はもう少しCI環境をたてるところから、1人でできるように勉強していきたいです。
達人プログラマー読書会@札幌-2011.09.20 に参加しました
9月 27th
9月20日(火)に行われた、達人プログラマー読書会@札幌に参加しました。
第3章の終わりまで。
プログラマに必要なデバッグ力の話が心に残りました。
18. デバッグ
自分がプログラマとして少し成長したな、と最初に感じたのは、デバッグをしてソースコードを追えるようになった時だったと記憶しています。
プログラムはサンプルソースがあれば書けるけれど、デバッグは動きを理解していなければ途中で置いていかれるから。
この章に書かれていた事、特に心理的な面はやはり忘れがちになるのでしっかりと心に留めておきたいです。
- 非難するのではなく問題を修復する
- パニックに陥らない
- 一つだけ修正しておかしくなったならば、何を道こじつけようとその修正に問題がある
- 公平で冷静な目でデバッグする
そして、何よりデバッグする前に、きちんとバグを再現させる事。条件を絞り込む事。
やみくもにデバッグをすると泥沼にはまる。
19. テキスト操作
シェルと同様、あまり得意ではない分野。
食わず嫌いもあるのかもしれないけれど、克服しなければ行けないところなんだよな。
これらの力を身につける事ができたら何倍も生産性があがってすっきりするんだろうな。
ディスカッションの時に「制限時間を決めて、ペアプロ対抗でテキスト操作対決とかするイベントがあったら面白いよね」という話をしました。
いつかやりたいなー。
20. コード・ジェネレータ
同じ物の繰り返しが発生した時は、コピーペーストをしない。
ルーチンワークを減らす。
コードジェネレーターがあることにより、本当に必要な部分にだけ頭を使う事ができます。
最近、JavaのAPTを使ってコード生成をするプログラムを作ったので、ちょっと頑張れば便利になる事を感じたばかりでした。
コードジェネレーターを作る方がコストがかかるように思える事があるけれど、結果的に作っておいて損はない、事の方が多い事を忘れないようにしたい。
この章は本当に今すぐできる、忘れては行けない事がたくさん書いてあった。
何度も読み直すべし。
[TDD][TDDBC][JenkinsCI] TDDBC 札幌 2.1 開催しました
9月 26th
フランス旅行5、6日目
9月 26th
フランス旅行5、6日目
フランス旅行最終日。
ホテルをチェックアウトし、空港へ。搭乗まではスムーズだったんたけれど、メンテナンスが終わらないとかで離陸まで2時間以上待たされることに。おかげで成田で予定していた千歳行きの便には乗り継げずに、3時間ほど成田で足止め。時差でだいぶ身体が駄目な感じだったのでラウンジなどで休みつつ夕方の便で這々の体で千歳へ戻ってきたのであった。
と、行きと帰りにいろいろあったものの、大したトラブルもなく大変に良い休暇を過ごさせていただきました。旅行は良いものだなあ。休暇の間、会社を守ってくれたみんなに感謝。来週からまたがんばります。









