ダダ漏れ日記

最低限の機能を持ったものを「MVP(Minimal Viable Product)」というらしい。 http://jibun.atmarkit.co.jp/lskill01/rensai/scrum/06/01.html （本筋とは関係なくて2ページ目の最後にちょろっと書いてある） 例えば「これがないとリリースできない（リリースさせてもらえない）必須機能」というのがいろんな理由で存在するが、それのみを最低限のレベルでクリアすればMVPってことか。 今まで、＋αとなる目標は、「必須じゃないけどやりたい目標」と、長ったらしい言葉で言ってきたが、これからは「非MVPタスク」と呼ぶか。 それとも、最低限しかやってない仕事を「これってMVPじゃね？」と蔑むか。 ROMやCDに焼くゲームを作ってた頃はMVPが全てだったが、今はMVPという言葉が出来るほど後からリカバリをする・できるようになったってことか。 ところで、何をしたらMVPなのかを定義することって、地味にプロジェクトの生命線だよね。。 （これがお客さんと共有できてないと最後の最後でトラブルになるからね。なったしね泣）

（Java+Eclipseが前提） 保守不能ソースに絶望 しても、それに立ち向かわなくてはいけない時、 解読可能な状態に修正したいのだが、 リスクを取らずに定型的に行えることがある。 １）変数とメソッドのスコープを必要最低限にしてみる。 protectedや無印になっている変数をprivateにしてみたり、 内部からしか呼ばれていないくせにpublicなメソッドをprivateにしてみたり。 無駄なSetterだったり。 すると、実は使ってない変数やメソッドが浮かび上がってくるので、それらを思い切って削除する。 削除まで行かなくとも、外部から操作される可能性を絞る事ができる。 ２）privateで一回しか呼ばれないようなメソッドは展開してしまう。 ３）privateで数回呼ばれているけど、数行しかないメソッドは思い切って展開してしまう。 ４）２，３をしたことによって判明した無駄なエラーチェックや重複している処理を省く。 メソッドにわかれているが故に無駄なnullチェックをしている場合がある。 ５）Beanを使っている場合、そのSetterが消せないかどうか検討する。 この場合、BeanとはSetterとGetterをpublicで装備しているクラスを指す。 例えばInputStreamからBeanを作成するような場合、Setterを消して、Beanにファクトリメソッドを作成するのが有効。それだけで、外部から操作される可能性を消すことができる。 ６）直感的に判りにくいクラス名や変数名は、Eclipseのリファクタリング機能でおもいっきり判りやすい名前に変える。 ローマ字だっていいじゃないか。"銘柄"を示すクラスを"Meigara"としてみるとか。 ７）無駄に使い回されているローカル変数は、中カッコを駆使する等して、いちいち宣言しなおすようにする。 アセンブラのレジスタじゃないんだから変数を無駄に使いまわすのはやめようぜ。 これにより、ロジックの切れ目が判りやすくなる。 ８）メンバにする必要のない変数は、メンバから外しローカル変数とする。 ９）パッケージがかなり細かく分かれている場合、特にinterfaceとかlistenerとかで分...

人が作ったプログラムソースをここ5年ほどよく見るようになったが、 最近見ているソースがずば抜け過ぎているために、 それを表現する言葉をずっと探していたのだが、ようやく見つけた。 それが、「保守不能ソース」という言葉だ。 世の中のプログラムソースには二種類ある。 「保守可能ソース」と「保守不能ソース」だ。 で、得てして世の中は「保守不能ソース」を生み出してしまうわけだが、 なんと言ったらよいか、今の気持ちはそんな世の中に絶望した気持ちだ。 などということを考えていたら、テレビで修理に携わる職人たちを紹介していた。 そういえばソフトウェアの修理屋って職業を聞いたことはないが、 人のソースを解析してバグを修正するのは間違いなく修理屋のやる仕事だし、 今、自分がやっていることは、間違いなくその類なのだが。 修理専門のソフトウェア技術者ってのもありなのか、を想像してみた時に、 年がら年中、次から次へと、毎日向かい合うであろうそのソースの、 たぶん多くを占めているのは「保守不能ソース」だろう、ということを ・・・想像してみただけなのに吐き気がしてくる。。

Windowsのexeファイルを作成するのって、真っ当な選択肢が無い。 （.Netをやりたくないだけだが・・・） というわけで、PythonでWindowsのexeファイルを作る方法を調べてみた ツール PyInstaller( Download ) インストール方法 zipをダウンロードして、展開して、好きなフォルダに置く コマンドラインからそのフォルダにて以下のコマンドを実行 > python Configure.py 使い方 コマンドラインから以下のコマンドを順番に実行 ※適当なパスを通す必要があります > python Makespec.py 俺プログラム.py > python Build.py -F 俺プログラム.spec Makespec.py及びBuild.pyはPyInstallerのプログラム。 .specファイルは、Makespec.pyが作り出す中間ファイル ※本当は設定ファイル。ツールである程度作ってくれるというイメージらしい。 成果物 ツールが作成するdistディレクトリに、俺プログラム.exeが出力されます。 それ単体で動きます。 ファイルサイズは「print "helloworld"」で1.8MByte程度。 ※ちなみにBuild.pyの時の-Fオプションを外すと、VisualCやpython本体のdllを別構成にすることができる。 Makespec.pyのオプション -F または --onefile　→　exeファイルをひとつに収める --windowed　→　Windowsアプリとする。コマンドラインが出ない。 --icon　→　アイコン画像(.ico)を設定する ライセンス エキサイト翻訳によると、商用であってもこれを使ったものを配布するのに制限はない、らしいが真偽のほどについてはご自分でご確認ください。

Flash Builderでは、ひとつのソースから iPhoneとAndroidのネイティブアプリが作れるらしい。 Flash Builder以外にもこういったものはあって、 これってすごく魅力的なのだが、諸々な事が そのツールに依存することになることを考えると なかなか導入に踏み切れない。 例えば、そのツールがOSの新Ver対応に遅れた場合、 こちらとしてはそれを待つしか無いわけですよ。 それってほとんど無いものの、万が一あった時に 「そのツールのせいだから仕方ないです。お待ちください」 って言うことを考えると…言えないよね。。 特にiOS5とか見てると、スマフォって ドラスティックな変化があることが前提な気もしてくるので。

開発において問題解決に臨む時、 忘れてはならない言葉ってのがあることに気づいたので 忘れないうちにメモ。 ・仮説 ・切り分け ・境界線 まあ、自分としては普段無意識にやってるので、 当たり前的なんだけども、改めて定義するのも 大切かな、と。

久しぶりにeclipseでAndroidのレイアウトエディターを開いたら、 "LayoutLib is too recent. Update your tool!" とか言われて動かなかった。 ADT12にアップデートしたかららしい。 ググったらIssueとして上がっているようだ。 http://code.google.com/p/android/issues/detail?id=17369 しかもReleasedになっている。 というわけでまずeclipseのプラグインをアップデートしてみた。 そしたら、main.xmlに触れただけでエラーが出るようになった。 うむむ… そうだ、eclipseを-cleanオプションを付けて起動してみよう！ よし！できた。 ビックリさせやがって… Amazon.co.jp ウィジェット

最近、Androidのアプリを作っているのだが、 バージョン管理として github を使い始めた。 無料のリポジトリを探した末にgithubにたどり着いたのだが、 なんといってもあのネコが大好きだ。 SVN含めていくつか無料のリポジトリを試した結果、 怪しくなくて、マニュアルがちゃんとあり、まともに動いた最初のサービスがgithubで、 UIのデザインも操作レスポンスも高いレベルであり遊びゴコロもあるということはどうでもよくて、 なんといってもあのネコが大好きだ。 仕事ではSVNを使っているものの、gitの方に未来がある気がして 色々調べながら一人プロジェクトで試験運用中だが、 そんなことより、近いうち、あのネコのグッズを購入したいと思う。 あのネコって言ってるけどOctocatっていうらしい。 部類で言えばキモカワか。ゆるキャラ選手権に出ればいいセン行けそうだ。 どうか危険な発言だけはしないで欲しい。

関わる人が多くなると、 社内調整にものすごい時間が取られる。 意識合わせの打ち合わせが多くなり、 それに使う資料を作成するために多くの時間を使う。 何か物事を進める時、オフィス中を駆けまわり、 何人もの人に同じ事を説明する。 メーリングリストに飛ぶメールの数が半端なく、 それを読むだけで一日が終わる。 （実際のところ、半分以上、フィルタによって無視している） アメリカの映画で、デスクが個人ブースになっている会社の光景をよく見る。 そんなことしたら効率悪いだろうと思うくらい、人と話をしている。 「密にコミュニケーションを取る」 その一言で上記の事は肯定されてしまいそうだが ・・・ちょっとまて、生産性という観点で見るとどうなのだろうか？ もし、アウトプットを犠牲にすること無く、コミュニケーションにかける時間を 生産的な時間に回せるなら、そうする事が正しいと誰もが思うだろう。 だけど、現実はそういう方向にはいかないよね。 なんでだろうね。

Adobe Edge... ついに本格的なHTML5の時代が始まるに違いない。 次のウハウハ企業はHTML5関連のオーサリングツールや フレームワークを押さえたところかな。 （それは少なくともウチの会社ではなさそうだ。。） だってJavascriptでコードを書いて開発するって大変だよね。 あんなイベントのハンドラ...

自分はもしかしたらソースコードにコメントをすごく入れるほうかもしれない。 それは、アセンブラをやってたせいもあると思う。 アセンブラは解読が困難なので、コメントを書かなかっただけでなく、 コメントの出来が悪いだけで、昨日作った自分のソースですら 何をやっているのかよくわからない状況に陥ってしまう。 「明日の自分は他人」という格言まで編み出したくらいだ。 （自分としては名言だと思う。やや字足らずだが） しかし、最近コメントをロクに書かない人も増えているような気がして、 もしかしたら自分が特殊なのか？特殊ならまだしも時代遅れの OLDプログラマーだったらどうしよう、等と心配してしまう。 コメントを書かない人のなかで、 「メソッド名や変数名でカバーしてるから」という人もいたが、 その人のメソッド名と変数名は死ぬほど長く、もはや、 コメントの問題とは別に可読性が非常に悪かった。 （開いた瞬間見る気が失せるソース…） 自分の場合、コードを書いた後、俺レビューしながら、 コメントを整理するので、単純にコメントを書くというより、 もはやコーディングの一部なんだけど、 世の中の流れ的にはどうなんでしょう。 ワタクシが時代遅れじゃなければそれで良いんだけどね。。

わが社の話です。 ～社内品質向上推進会議の結論～ 「単体テスト、各自でしっかりやってください」 ～バグが出たときのやりとり～ リーダー：「単体テストやったの？」 メンバー：「はい、やりました」 ～ケアレスミスのバグが出たとき～ 「それって単体テストレベルじゃね？」 …単体テストって、なんなの？（笑）