女子高生ハッカー

http://ameblo.jp/aoi-hacker/

Rubyに関して、一瞬で抜かれてしまった。ってかありえねーよ、この成長曲線。

これはひどいコード

今日、ちょっとしたきっかけで保守委託している会社の書いたコードが激ヒット！

if(hoge == FALSE){
hoge = TRUE;
}

キタコレ！意味不明！

他にもたかだか20行程度のコードに6ヶ所位指摘ポイントありました。

社内でコードレビューしててこれって…

ここに保守を頼んでいることが少し怖くなりましたよ。

本日もPython日和

週末から続けて今日もPython。

作りたいツールは一通り完成しました。zipfileモジュールで展開・圧縮したり、簡易なGUIもイレ込んだり、かなり複雑なものになったかな。

あくまでバッチの延長なのでPythonらしい感じではない気もしますが、バッチでは出来ない部分もカバー出来るので、これはこれで価値ありです。

個人的にはPHPの方が敷居が低い感じなのですが、PHPはもともとHTML埋め込み言語なのでコマンドラインで動作させるのは何か違和感あるし、最近世間で叩かれ、後ろの席の人にも毎日叩かれる始末なので（笑）、今後はしばらくPythonで！

S/N比の悪いコード

「特定コンパイル環境でメモリの内容が消える」ということで、机上デバッグでお手伝い。

...うーん、追えない...orz

やばげなパッケージは意味不明な設計(内部属性をconstも付けずに外部にモロ見せ)、それを利用する側は面白コード(全てのpublicメソッドに「インスタンスがなかったら初期化」というコードが入っている つд;)になっており、コードを斜め読み出来ない。

オブジェクト指向(というかC++)で重要な、インスタンスの生成と消滅の管理が危ういこと危ういこと、生成、消滅が上手に隠蔽できてないので、そのインスタンスを使う誰でもが生成、消滅させられちゃう。それじゃあ、Cで作っているのと一緒ジャン。C++を使っている利点をスポイルしちゃってるよなー

結局のところ、机上で見る限りは問題なさそうな感じだったのですが、そう感じるまでに雑草を掻き分けながらのコードトレースになってしまって、いまいち自信が持てません。

先々、変なバグを仕組まないためにも、若い人にはコーディングテクニックを磨いていただきたいものです。

人の分析シーンを診て思ってこと

リーダーになったからといって、オブジェクト指向開発を疎かにしたりはしません。

いずれ思考がまとまったら書こうかと思っていたのですが、すぐにはまとまりそうにないし、メモ書きも悪くないと思って書くことにしました。

最近、うちのチーム内で一番重大かつ切羽詰っているサブチームは、現在UP(Unified Process)における方向付けフェーズの分析をメンバー全員(5人)でまとまって行っています。前々から興味もあったのと、先週進捗をきっかけとした開発状況に対する漠然とした不安を解消するためにオーディエンス的なノリで参加してみました。

その時に、そちらのチームの棟梁と話をしながら気づいた点を中心に箇条書きに。一部重複してます。

• 方向付けフェーズの分析であるなら、チームとして重要な部分がどこと認識していて、それについての基本的な考え(どう動かすといけそうか)だけ決まったら、深追い不要。だって、動かさないと本当のことはわかんないじゃん(たぶん一般論)
• そういう意味では動かすために必要な重要なデータ(属性)にどのようなものがあるかだけが見えてくれば、それで十分では？(これはまったくの私見)
• 自分の中で60点取れるモデルだったらOK(私見)
• 分析モデルを基に動的分析する場面において、皆で動きを考える際に議論や説明が空中戦になってしまうことがありがち。皆でひとつの図に10円玉を置いて、コックリさん状態で動きを追うという手で、空中戦を防止するべき(某社ではその時使う図がわざわざ定義してある)(多分一般論)
• 複数案でもめているなら、きちんとホワイトボードなどを使って「A案、B案」等と書いてそれぞれのメリットデメリットをきちんと論じるべき。でないと議論が堂々巡りしてしまう(一般論)
  
• 「わかんない」禁止。それは思考停止でしかない。わからないなら、何が分からないかを良く考えて質問すること。でないと、お互いのアイディアの議論にならない(一般論)
• 悩んだら方針に立ち返れ。方針にないことを考えていないか？(一般論)
• 分析モデルを作り始める前に持っていたアイディアを大事にしよう。細部を考えると見失いがち。細部の分析は初期のアイディアを固める方向で行う(一般論)
• 今回作る対象は、どう考えたってMVCなんだから、少し意識した方が良いのでは？(私見)
• ロバストネス分析を入れてみるのも良いかも(ちょー私見)
  

話は若干それますが、今回のチームは新人が多いので、どうしても分析の袋小路に入りがちな印象を受けました。経験を積んだ技術者なら、オブジェクト指向開発しているしていないに関わらず「落としどころ」を意識して作業を行えるのですが、なまじ頭は良いけど経験はない状況では致し方ないのかもしれません。

仕事は学校の勉強や研究と違って、「やったなりの成果が出ません」し、「情熱だけでは達成できません」し、「時間はない」し、「何があっても出さなければいけない」んです。その厳しい現実と理想にどう折り合いをつけていくかもひとつの課題になりますかね。

ま、偉そうにこんなこと書いているσ(^^)も出来ているわけではないですが(^^;;;;;;

でぶさみ2006二日目感想＆総括

二日目の感想です。

1. エンジニアの生きがいとは？??マインドマップを使ったQoEL探検ワークショップ??
   
   数名のグループでエンジニアとしてやってきて良かった事等を話し合いました。何がどうということではないですが、参加者同士で話し合う場は貴重ですね。


2. デブサミ2006!オフィシャルコミュニティによるLightningTalks
   
   一番最初のBDDネタ(with長州小力)がパフォーマンス的には最高でした。これを観てからだったらもうちょっといいプレゼン出来たかも。


3. プロジェクト・オートメーション〜コンピュータもチームメンバだ!!
   
   角谷さん、さいこーでした。自分が目指している発表の仕方に一番近かったし、一番頭にすーっと入って来ました。まさーるさんの下りで涙する角谷さんを見て、自分も思わず涙してしまいました。自分自身はまさーるさんと直接交流があったわけではないですが...
   
   「態度重要」。自分が社会人になってからずっと思っていたことを一言で言われてしまった気がします。そういう意味では、あの場の私はHobbit族だったかもしれません(^^;


4. XP 2.0
   
   前半のXP2.0の説明は平凡(でも必要)でしたが、後半の日本の受託開発でのXPの実践法はユーモアあり、貴重なKnowHowありのすばらしいセッションでした。


5. 要求定義入門
   
   えーと、寝ました。


6. みんなで踊ろうMVC,みんなで創ろうパターンダンス
   
   「なにをやらかすのだ？」という興味本位な気持ちで参加。MVCやデザインパターンの動きをグループごとに演技で表現しようというワークショップ。ソフトウェアのイメージをどう動きで表現するかというのも頭を使うところですが、それよりも如何に短時間でその場の人たちと溶け合うかというところが、結局のところ重要なようです。うちのグループはちょっといまいちだったかな。
   

二日目のほうが感覚的に行って面白かったですが、全体的に面白いと思ったのがファシリテーショントラックばかり。でぶさみの参加者がWeb技術者が多く、テクニカルなトラックはJavaとか.Netに行きがちで、自然と避けてしまった面もありますが。ソーシャルハックやヒューマンハックばかりが盛り上がるのも、少しばかり寂しい感じです。まぁ、技術はWebと書籍で勉強できるからいいのかな？

とにかく今年も楽しいSummitでした。また来年も参加します。翔泳社さん、発表者の皆さん、お疲れ様＆ありがとうございました。

でぶさみ2006一日目感想

一日目の感想を書いておきます。

1. オープン・ソース・ソフトウェアをビジネスで活用するには
   
   自分も開発プロダクトの一部としてOSSを利用しているので、普通に勉強になりました。



2. Apache Geronimoハッキング
   
   JBossを補完する、OSSのサーブレットコンテナ(って表現で良いのか？)。こういうところでもDIって活きているんですねぇ。単純なサーブレットのコンテナというだけでなく、OSSで提供されている様々なコンポーネントを繋ぐフレームワークとして使えるという点が興味深かったです。自分が作りたいのもそういうものなんですけど、C++じゃ厳しいですかねぇ(--;



3. モデリングライブ
   
   ひそかに尊敬している荒井さんのセッション。生玲子さん初めて見ました(^^;モデリングもさておき、日本語ちゃんと書けよというお言葉は深く胸に突き刺さりました。


4. 史上最多!?道路交通情報Webサービスを使った複合Webサービスシステム
   
   あまり面白くなかったので、寝てしまいました。すみません



5. ユースケースによるアスペクト指向ソフトウェア開発
   
   アスペクト指向って言うと非機能要件の実現手段というイメージだったのですが、機能要件の実現にも使えるよという話が新鮮でした。でも、それやっちゃうと、1つのクラスが一体どんなクラスだか分からなくなっちゃう(誰かれ勝手にクラスを修正出来ちゃう)気がして、ちょっと不安です。


6. TeamFoundationServerによるチーム開発コトハジメ
   
   要するにVS2005TFSの紹介。便利そうだが40万円は高くないか？

正直一日目は平凡な感じかなー

チームのかんばん

先週から、オブジェクトクラブのクリスマスイベントで紹介されていた「形から入る『見栄っ張り』アジャイル開発講座」と「困った上司とのつきあいかた教えます」に触発されて、独自の看板を作成しました。



一般的なかんばんは「ToDo」、「Doing」、「Done」なんですが、うちは反復を1週間ではなく2??3週間と長めなので、1週間毎の進捗を可視化するために「今日」、「明日」、「今週(写真は「来週」になっていますが書き間違えです)」、「その後」というくくりで作ってみました。金曜日に「今週」に残っているPost-itがなくなるかで判断するというのりです。「ネタ」はペア開発で行うタスク以外で、ペア開発出来ない時間を利用してやることをまとめたリスト。「問題点」は具体的な利用法は考えていないのですが、環境的な問題などをリストしておいて、他人にアピールする為のエリアとして確保しています。

で、今週一週間やってみたのですが、何故か1枚しか進まず...えーと、典型的な見積もり失敗です(--;

まぁ、最初のタスクカードが実は難関だったので想定の範囲内ではあったのですが、最初の週からずっこけるとそれなりにへこみますね...orz

来週がんばりまつ...

オブジェクト倶楽部クリスマスイベント

参加の募集期日を見落としてしまい参加できなかったのですが、オブジェクト倶楽部クリスマスイベントの発表資料が公開されています。

ライトニングトークスのネタはかなり興味深いですよ。一部ネタは早速使わせていただいてます。

2006夏はちゃんと参加したいですよ。楽しそうだし。