Skip to content

Frontier Blog

for more efficient software development!!

Archive

Archive for 12月, 2012

C++のコードを書いていて嵌ったので、備忘録を兼ねて書いて置きます。

HTMLのパースするようなコードを書いていて、

のようなコードを書いてみたのですが、複数行にマッチするオプションがないので、少し探してみて、この記事を見つけて、

 

 

のように書いてみました。

うまくマッチしていると一瞬思ったのですが、少し長い文字列を入れると、Stack Overflowを投げるようになってしまいました。「regex_search stack overflow」というキーワードで検索しても、Stack Overflowの記事が引っかかるばかり。

結局、こちらの記事を参考に次のように修正して解決しました。考えてみれば当たり前なんですけどね。

 

 

コピペそのままはダメだよという教訓でした。

 

ついに最終日。

とても興味深い5日間だった。そして、色々とやりたいことが見つかった5日間だった。

1つ言いたいことは、Scrumを使った開発をやりたいと思いつつ、うまくできないと思っている人には、是非、受けてみて欲しい。

英語力とか、そんなことを気にせず、受ける価値のあるものだと思う。

 

 

大分、開発がメインの内容になってきていて、ようやくインフラからも解放されて、何かを作っているという感じがする1日だった。

プロダクトコードの変更はそんなに大きくないけれども、TDDのリズムに乗って、うまくリズムに乗れないことも経験できたし、コミットのタイミングについても色々と考えるところがあった。

 

ここまでScrumで取り組んで感じたいくつかの疑問点をBasに確認してみた。

 

・ペア作業をしている際に、複数のペアがごちゃごちゃになって作業することはよいか?

よく見られる状態なのだそうだ。

スタックするよりも流動的に動いていた方が良い部分もあるのだろう。

 

・ペア作業をしたときに、Daily Scrumは重複した内容を告げる必要があるのでは?

It depends on the team.

重複しているので、ペアごとに告げてもいいけれども、ペアをスイッチしたりと状況は色々ある。

これを書きながら、Daily Scrumの目的は何かを考えれば、それまでなのかなとは思った。

 

・ファイル名を変える、メソッド名を変えるなどのリファクタリングを行うと、リファクタリング中にテストが失敗するようになるが?

リファクタリングはテストコードとプロダクトコードの両方に行うべきことで、間違っていない。

 

ただ、これは今日の経験からだが、1つずつやらないと面倒を引き起こすことも。

プロダクトコードを1つ修正したら、テストコードが期待する形で失敗する。

テストコードでデザインを1つ変更したら、期待する形でプロダクトコードが失敗する。

これの繰り返しなのだろうなぁと。

 

後1日で、Mr. POにコミットしたところまで終わるかは・・・。

 

3日目からは、研修の内容が大分開発に集中するようになってきている。

とはいうものの、Jenkins、Jetty、Tomcat、Mavenと戦っていたと言えるかもしれない。

何より、今日はテストがパスしない状態でいることの苦痛をすごく感じた。

 

赤い画面を常に見せつけられて、パニック!パニック!と言われると、焦りますね。

 

同時に、グリーンに戻ったときの安堵感というか、居心地の良さは大きいですね。

グリーンが当たり前なのかもしれませんが。

 

そんなこともあって、今日はペア作業といいつつも、ペアを超えてガヤガヤやっていた気がする。

 

あとは、スプリントプランニングパート2というか、タスクの管理のやり方は工夫の余地があるかもしれない。

言葉で各タスクの内容で合意はとっていたつもりでも、実際にやってみると、それに関する小さなタスクが出てくることが多い。

そのタスクで行うか、新しいタスクで行うか。

 

今日、はまったのは、複数のTestSuitesで、Start Selenium Serverを実行すると、うまく行かない。

ブラウザを使ったテストは、1つのTest Suiteにまとめるのが一番なようだ。

CSDコースの2日目。

 

今日はRobot FrameworkとSeleniumとの連携だけに開発は時間を使ったような感じがする。

インフラの整備は大変。

BasがTDDのデモをしてくれたのだけれども、IDEとショートカットを使いこなした上での操作は魔法のように見える。

このくらいIDEを使いこなせると効率は全然違うだろうなと思う。

特にリファクタリングは迅速にかつ安全にできると思う。

 

今回の参加者は、中国人1人、タイ人1、日本人1人(自分)を含む7人でした。

 

スキルや知識がまちまちの状態で、コンセンサスをとることはとても難しいと感じた1日でもありました。

また、自分の英語のスキルがもどかしく感じた1日でもありました。

 

思い返してみると、今日は何をしたのだろうという感じでもあるのですが、きっとスクラムチームを立ち上げた際に陥りがちな問題をいくつも経験できた気がします。

一言で言うならば、今日はとてもよい素振りが出来たという気がします。