December 2007
38 posts
InfoQ: ビジネスロジックとテクノロジを離して考える: Kathleen... →
「特定の書式で記述された仕様書」から「ソースコード」をジェネレートする。「ベストな開発を行っても、ほどほどのコード生成開発よりも劣っているのです。」とまで言っているよぅだが、どぅか？最近、「仕様書」->「BDDでいうshouldの生成」＝UnitTestより少し上流のテストコードの自動生成、とか考えていたけど、この記事とはBDDでつながったカンジがして納得できる。
Adobe - Flex: See a Flex app built webcast →
実はFlexBuilderでの開発を見るのはこれが初めて。
OpenIDを使ってみた － ＠IT →
この記事自体はOpenIDの記事だが、その中の項目のひとつに「サービス中心からリソース中心の世界へ」ってのがあった。こんな観点からもROAが登場ですね。
デザイナーはデザイン、開発者はプログラムだけという時代は終わった―アドビ イルグ社長 -... →
最近はJSもゴリゴリ弄れるデザイナさんも多いし、デザイナ側に歩み寄れない開発者は邪魔ですよね。個人でやってるデザイナさんは管理方法や方式的な事も詳しいだろうし、個人レベルで見るとデザイナさんの方が各種能力のベースが優秀な人が多そうだ。「実装」という意味の技術的な観点よりもそういった管理方法とか方式、プロセスに対する能力の方がはるかに大事だし。
本当は楽しいIT業界——“重鎮”を超えて − ＠IT →
「ネットは自立的に動いている人にはパワーをくれるが、寝ている人には何もない。そこを気がついて、サバイブするか、しないか」 「外に出て行ける環境やコミュニケーションツールがあるにも関わらず、中にとどまって3K、7Kと不平不満だけをいうのは「甘えがある」」 そう、やれば何とかなる、やれる人は生けていける。だが、やらない人には生きにくいという状況はまだまだ進むんだろぅ。是非そう進んで欲しい。んでも俺はなにがなんでも生きていきますよ。
【ハウツー】姿を見せ始めたWeb Beans - サンプルコードで見るその具体像 (1)... →
JSR299:WebBeansについての詳細。今までで一番細かくてわかりやすいかも。 まず最初の感想は 「アノテーションだらけになっちゃう」「Guiceのいいところを取り入れてる」「Conversationスコープは便利そう」といったカンジ。アノテーションの氾濫については「ステレオタイプ」なる仕組みで解決しようとするみたいだが、「そこまでしてアノテーションでやりたいか？」という気がした。アノテーション自体の継承ってできるんだろうか？やったこと無いけど、これが無きゃステレオタイプがあってもアノテーション地獄になると思った。XML地獄、アノテーション地獄を渡り歩くのはイヤだな。 つーわけでGoogle様、JSR299を実装したGuice2.0をお願いします。
【レポート】"Enterprise RIA"を推進するアドビのオープンソース戦略 (1)... →
リモーティングとメッセージングを処理するBlazeDSと、ClientのAIR。その間の通信はActionMessageFormatというバイナリ形式にする事で「ClientServer両側で行われるJSON/JS間の変換コスト」を小さくする、と。おいおい！時代が逆行してきてんじゃないの！？こんな事されたらAMFの実装まで標準サポートしなきゃぁーとなるんじゃないの！？
InfoQ: HudsonとFindBugsを用いた継続的インテグレーションとコードインスペクション →
Hudson、最近Java-jaのMavenの会でも話題に上がっていた模様。普通に使っている人もたくさんいそぅだ。
コード品質を追求する: ビヘイビア駆動開発を舞台にした冒険 →
BDDを行うためのjBehaveについて。より人間的なアプローチになっていて、読んでいると「仕様から対応するTestCaseを…！」につながった人もたくさんいるんじゃないかと。
Java SE 6の強化をあらためて振り返る - builder by ZDNet Japan →
あれ？JSR223 Scripting…ってJava6だったんだ！？Java7だと勘違いしてたよ、嗚呼ぁぁ。
InfoQ: 依存性注入(DI)は成功したか？ →
DIは試験の時に…とはよく言われる事で、これに関しては同じ違憲だった。だけど、確かにDIがなくても試験の時は外から注入することも可能だもんなぁ。。と思ったが、やっぱ「DIしないとしても、DIする事を前提とした設計にする」という効果はあるのかも。単なる疎結合の為の強制力？ まぁ結局Intercept()するし、DIできる設計になっていれば、DIするかどぅかはどぅでもいいと思うんですけどね。Intercept()万歳ですよ。
メソッドの機能を一言で説明しようの会(会員数一人) - じゃばてな →
一言で…というのは特に目新しくない。JavaDocのメソッド概要は最初の読点まで…も目新しくない。が、しかし！これらを組み合わせるという意識は無かった。ありがとうございます、ひとつ賢くなれました。
2007年 Webの注目話題：「脱ブラウザ」と「beyondブラウザ」に現実味：ITpro →
Androidが抜けてませんか？
InfoQ: 品質に交渉の余地はあるか？ →
「品質は必要ない」とか言われても。でも、そんな相手に過剰な品質保証のための工数は確かに無駄とも考えられる。だがしかし、記事中にもかかれているように「極端な低品質」も無理。どこまで？というのは決めることは難しいから、「期間、工数」を基準にするってのはどぅかな。
アーキテクトの役割とは—ビルダーとユーザーの境界 - builder by ZDNet Japan →
「アーキテクチャとは「技術の組み合わせ方」」「エンジニアにも必要なアーキテクト的発想」「技術は単体では意味がない」などなど激しく同意。
［動画で解説］和田卓人の“テスト駆動開発”講座：第14回 テスト厨，TDDの壁，DBやGUIのテスト｜... →
まとめると「GUIコードの自動テストは難しく，コストがかかる割には資産価値が低い」ということです。 この意見は、和田先生の知識不足なんじゃないか？と思う。和田先生がいう「GUI」がHtmlClientの事なのかRichなClientの事なのかわからないが、「資産価値が低い」なんて事は無いと思う。「敷居が高い」と思っているからそういった意見につながっていくのではないか？と解釈したんだけど、どぅなのかな。HtmlClientに関してはまだ敷居が高く感じるけど、RichClientに関しては今はそぅ敷居が高いものだとは思わない。そして、どっちにしても資産価値は高いと思う。敷居が高いから見送るという選択肢は多いにありだけど、それにしても「試験手順の自動再生」をするためのモノくらいはあるべきだ。手順だけだと「テスト」とは呼びづらいですけどね。
TechCrunch Japanese アーカイブ » Google Knolについての考察 →
「広告在庫」なる単語は初めて目にしたけど、なるほどわかりやすい表現だ。
EnterpriseZine：トラブルだけが原因じゃない～発病のワナと対処法について知る →
「ワナその３」を見て思ったが、この記事の書き手は「エンジニア＝客先常駐」と考えているのだろうか？と思って経歴を見てみると医学博士らすぃ。内科医らしいが、メンヘルに関しても経験が深いのかな？そして、病みやすいのが「客先常駐タイプのエンジニア」という事なんだろぅか。ウチの若い連中は大丈夫かなぁ。
ユーザーの「思い」は、1つだけではない − ＠IT情報マネジメント →
記事とは関係ないけれど、リッチピクチャと言う意味ではGoogleDocsよりZohoに分があるな。 TODO: MOYA
Ruby on Rails 2.0はとっても“RESTful” − ＠IT →
強く印象に残ったのが「絶対にSOAPを使わなければならない、というのでなければ、われわれはそうしないことを強く勧める」てトコ。
Tomcat 6で実現！ Ajaxを超える通信技術Comet (1/3) - ＠IT →
Tomcat6でCometができるとは知らんかった！記事もサンプルでの説明なので非常に動作がわかりやすい！ただ、Client側のAjaxはなんらかのライブラリでやってほしかったかな。
Geekなぺーじ : ソフトウェアマネージャへの公開書簡 →
ウケタｗｗ 納期を勝手に決めるなら予算を勝手に決めさせろとかワロタｗ
コンサルとアプリ開発者、給与格差250万円の実態とは？:インフラコンサルティングの最前線 -... →
ホントにそんな向上心がある人たちが多いの？というのは記事に同感。ただ「日本企業はゼネラリスト志向が強く、専門職の人間を正しく評価して活躍の舞台を用意できていない」という点には疑問、というか「専門職！＝ゼネラリスト」という意味なら違うと思う。逆に「ゼネラリストの仮面をかぶっただけの、実は浅い人」という人が増えそう。「複数の分野において高い知識、技術を持ったうえで、さらに特定の分野では専門的」である必要があると思う。
Japan.internet.com Webビジネス - 「愚か者よ、大事なのはデータだ」 →
「データは神様」「ITは関係ない」。そうかもなぁ。でもIT業界は汚いから、エンドユーザからぼれるだけぼるやり方は変わらんですよ、きっと。大手SIerが…といいたいトコだけど、末端もまたその輪に加担してるわけだし。俺もその輪の構成要素なんだよな、あーヤダヤダ。
価値を生むために知っておくべき，フルフラッシュサイト制作のあらすじ：第4回 情報設計，チャート，構成要... →
さすがにFullFlashなんて事に携わることはないだろうけど、Ajaxで派手に画面構成を触ったりすることはあるのかも。そんなとき、役に立つフローの書式とかってあるのかなぁ？[TODO]
売春婦らが運営する銀行、インドで成功納める | 世界のこぼれ話 | Reuters →
これもマイクロクレジットのひとつ？
Google Android用携帯アプリ作成のための基礎知識 （3/5） - ＠IT →
Softbankで使えるならいいんだが…といぅか、Google優先かな。自作のアプリを簡単に携帯で使えるならそんな良い事はないなぁ。SQLiteも使えるならTask管理を作っておきたい。ちなみに、DesktopPCとのHotsyncがPalm並に使えるならEdgeもCLIE達もまとめて処分する。いや、iPodTouchと同期できるPIMがあればGooglePhoneもいらんか…？
InfoQ: Javascript Frameworks用の抽出基準 →
個人的にはjQuery,Dojo,Ext2.0を使いたいということはこの記事を読んだところで変わらんけど、参考にしたい。といぅか、他の皆はどんな基準で選ぶんだろう？
Javaのオープンソースプロジェクト”無名だが役立つ”トップ10 - ZDNet Japan →
10位のZKしか使った事がないとは…。9位のQueplix、5位のNuxは興味あるかな。
CodeZine：AJAXアプリケーションで標準的なブラウザナビゲーションを再現する（Dojo,... →
Ajaxなどでブックマーカブル、という手法は既に色々あるっぽい。GWTのその機能も特にメリットとしては言えなくなってると言うことか。
InfoQ: JavaScriptへのマルチスレッド・プログラミングの導入 →
この情報が無く、JavaScriptの仕組みもわかっていなければ間違いなくハマる。ただ、紹介されているライブラリってMPLなんだよな。使いづらい印象があるなぁ。
［動画で解説］和田卓人の“テスト駆動開発”講座：第12回 モックオブジェクト技法｜gihyo.jp... →
jMockとRMockは抑えておきたい。ただ、和田先生のいう「小さいテストの資産価値」「役割を終えたので捨てる」というのがどうにも実感がわかないんだよなぁ。そんな簡単なモンなんだろぅか。
第14回 SNS上のWeb... →
こういったAPIが普及したときに、すぐに実践できるよう準備しておきたい。というか、企業としてSNSをどんどん使用していないトコは、このあたりをちゃんと抑えられないのかも。狙い目かも。
要求発明学入門(2)：要求開発アライアンスのビジネス・モデリング道場：ITpro →
要件ではなく、要求を引き出す事によって、顧客が出す要件を越える要件を提案できると。でも、そんな上流はウチには回ってこないんだよなぁ。知識として持っておくけど、実践する機会はないかもなぁ。
ウェブ・リテラシーを身につける方法ver0.1 - My Image Ltd. →
社内の教育用としてひっそり使わせてもらうためにも要注目。
satolog: リーナス・トーバルズ「Subversion ほど無意味なプロジェクトはない」 →
CVSとSubversionしか知識が無い俺はどーしたらいいんだｗひとつ言えるのは「Eclipseから便利に使えないSCMはカス」というくらいかなぁ。
まつもと×丸山 in MIJSカンファレンス：「開発者の自由な裁量こそが生産性向上のカギ」... →
最近の日本のGeekな人たちは海外にも負けていないし、その方々を刺激としてもっともっと日本のGeekが増えると良いなぁ。俺もがんばろぅ。
BBCが"Perl" on Railsを開発—なぜRubyじゃだめなの？？:ニュース - ZDNet... →
Perlの方が軽いってこと？Perlなら新しく勉強する必要が無いからありがたいなぁ。