再び、化学反応を起こしてくれる日まで
土曜日の沖縄公演(FINAL)で発表があって(行ってないけど、発表されたらしい)、翌日、オフィシャルサイトでも発表されましたが、
「CHEMISTRY活動休止、ソロ活動専念を発表」
http://headlines.yahoo.co.jp/hl?a=20120408-00000124-spnannex-ent
だそうです。
まぁ、ソロでも応援するつもりですが、このタイミングとは意外でした。(勝手に、今年の末あたりかなーとか思ってたってだけですが…)
先ずは、TrinityのBlu-rayリリースをお待ちしています!!
要っち曰く、「必ず戻ってくるから!」だそうなので(これもTwitter情報)、再び、化学反応を起こしてくれるその日まで、川畑要と堂珍嘉邦のそれぞれのファンとして応援することとして、CHEMISTRYファンをお休みします。
あのハーモニーを再び、生で聴ける日を待ってるよー!!
記事になってる♪───O(≧∇≦)O────♪
昨日のサプライズが記事になってます。
http://www.excite.co.jp/music/news/detail/E1331173334779.html
ロウソクでかいですよね(笑)
iPhoneから送信
CHEMISTRY TOUR 2012 -Trinity- at Tokyo
行って来ましたー♪───O(≧∇≦)O────♪
NHKホールに!Trinity2戦目です!!
ヤバかった!!!マジで!
2回目は、セットリスト知ってるのにも関わらず、リポビタンD2000を飲んでも、それで補った体力すら使い果たすくらいに!!!_| ̄|○←今の俺の状態
それに、2012/3/7は記念すべきCHEMISTRY11回目の誕生日!!
サプライズで、1回目のMCのときに、でっかい11のローソクの刺さったケーキが登場して、みんなでハッピーバースデーを歌って、その後、火を吹き消し忘れていた2人がそれぞれに消す。
そして、どーちゃんソロではアドリブ曲ありの、最後のほうでは記念写真ありのと、ファンにとってもサプライズ盛り沢山な公演でした。
ちなみに、相変わらず、どーちゃんはカミカミ(それも魅力)でした(笑)
本当に夢のひとときでした。
あと、「アンコール!ヘィッ!」も健在(?)で、ヘィッ!って叫んでました(笑)
前回、漢はペンライト不要だ!!とか書きましたが…必須です!!(ペンライト買えばよかったと、物凄く後悔してます)
あぁ…疲れた。(家に着いて普通のリポD飲んで、やっと眠れるくらいの体力を回復したかも…)
iPhoneから送信
ソースコード記述の自動化のメリットとデメリット
[development][ソフトウェア開発]
今、某SIerの案件でソースコードと詳細設計書(と言うか、コードの日本語化)を自動生成するツールを使って開発を行っているプロジェクトに参画している。
そこでツール利用者として実感したことを、メリットとデメリットという観点で記述したいと思う。
【メリットだが】
・詳細設計書らしきもの(よくある内容が細か過ぎて、ソースコードを日本語化したようなもの)を自動生成してくれる
・少しだけ、実装に掛けた時間が短く感じる(実際に、コードを書くより短縮はされているだろう)
【デメリット】
・普通に実装すれば標準搭載されているライブラリを使って1行もあれば記述出来るようなことを実装し辛い(ツールの拡張で対応してはいるが…)
・結局、特殊な言語で実装を記述している
・出力される言語の言語仕様で使える機能すら対応していない(Javaなんだけど、ツール仕様でtry-catch使えないんだよね)
・テストの自動化が出来ない
・生成されたソースの中でやっていることが分かりづらかったり、参照先ライブラリの動きがわからなかったり、デバッグに時間がかかる
・VCS管理する対象が増える
・導入まで時間が掛かる
・ソースコードの生成時間が長い(ツールの問題だけど)
・保守出来る人間が限られる上に保守し辛い(ツールの独自言語の問題)
・ウォーターフォールでしか開発出来ない(ツールの仕様の問題かも?)
・詳細設計書らしきものは、内容がソースコードの日本語化したようなものなので、その記述で(ある程度のブロック単位で)何をやりたいかを掴めない(コメントが書かれていて、実装に則していようとも、結局、コメント自体が仕様を実現するのに合っているのか確認出来ない)
といった感じ。個人的な感想だけれども、正直、プロジェクトの上のほうの人たちが言うように工期圧縮出来ているとは思えない(むしろ、ろくに単体テスト出来ない上に、デバッグと修正に時間が掛かる上に、実装するのにも制限だらけで、逆に工数が嵩んでる気がする)
あと、Struts1.x+Spring+iBatisとかって…設定ファイル多過ぎでしょ?
と言うか、バリデーター…チェック対象のJavaBeansの中にアノテーションでチェックルール書いてしまったほうがいいと思うんだけどね。
どうせ、チェック内容変えたりすれば、テストし直すのだから、設定ファイルだろうとコードだろうと大差無いよね。
って言うか、Struts1.x+Spring2って、Struts2とそのインターセプターで同じ事出来そうだよね。あれだとほとんどの設定がアノテーションで書けるんだったかな?
とりあえず、単体テストの自動化(出来たらTDD)で、デプロイなどを自動化出来るようにならないと、ソースコードを自動生成しても意味が無い。
詳細過ぎる詳細設計書に関しては…割愛!!(少なくとも、あれなら、普通に実装したコードを読んでも変わらないとだけ言っておく。他所でも結構、議論になってるのでね)
って言うかさ、マジ…人居なくなったら、誰がメンテナンスすんの?って感じなんだけど…引き継ぎ云々でどうにかならないレベルです。
まぁ、コードの自動生成よりも深刻な問題があるプロジェクトだから、マニュアル読めばマスター出来るツールが可愛く見えてしまう(笑)
iPhoneから送信