愛車:マツダアテンザ
Webを中心とした、ビジネス&テクノロジーに関する思いつき
by F-shin
[ このサイトについて ] [ F-shinについて ] [ トップ ]
author:えふしん
photo_20.jpg
藤川真一について


モバツイの中の人
マインドスコープ(株)社長
人の良いジョンカビラと言われます。
AMN sponsor rolls
モバツイの2つのスマートフォン
アンドロイドアプリ!
アンドロイドアプリ モバツイtouch
全てのスマートフォンブラウザと、Nintendo3DSで! HTML5版Webアプリ「モバツイsmart」
本を書きました!
100万人から教わったウェブサービスの極意 ~「モバツイ」開発1268日の知恵と視点
Google Friend Connect
このカテゴリ[会社活動]の最新30件
バルスのツイート機能に関する謝罪を書いたら沢山反応があった件 モバツイの広告の取り組みについて、発表資料の共有 モバツイ、2つのスマホへのチャレンジ「モバツイtouchとsmart」 あなたのシステム開発観は、「動けば良い派」?それとも「ロマン派」? サードパーティツイッタークライアントの生きる道 モノを作る人は、鵜飼いの鵜ではなく鵜飼いの人 ネットは儲かるか?〜1人1円を1億人からもらって1億円売り上げる仕事 映画「ソーシャルネットワーク」の興味深いポイント6点 自分のやりたいことを会社で実現する方法 日本の葛藤 日本をコントロールしているもの 「ぼくはこうしてプログラミングを覚えた」をどう読みましたか? 方向性はあっている、という言葉の危険性 バタラさんとの採用コンテンツ作成秘話 ネットサービス系企業における、積み上げ型タスク管理の危険性 その時、誰がモバツイを必要としたか? - 震災発生から1週間の状況 「ツイッターのおすすめユーザー欄に表示される垢が、同一のグローバルIPアドレスからチョイスされた件」を回避する方法 ツイッターapi利用規約を翻訳しました。 つぶやきから、ソーシャルコマースにならないかを考えています 仕様の決断と、想定外 モバツイのエイプリルフール機能「イマココ(uso)」で、1万ツイート/day突破 モバツイに今いる場所を適当に送信する「イマココ!(uso)」をリリース 仕事のペース 業務ののりしろ ネットビジネスで成功した人は無茶をやってきた人 映画「ソーシャル・ネットワーク」の感想 エンジニアのこだわりと、継続的開発、チャレンジについて。 2010年振り返り2011年これから。 あなたの選択は正社員?非正規雇用? 「このサイトいくらぐらいでできるよ!」のピュア
[このカテゴリをもっと見る]
Powered by
Movable Type

June 16, 2005

Strutsを見たときに直感的に、XMLでうじゃうじゃ書いてつながりがわからなくなることに対する拒否反応を持った。そして今、Strutsを使おうとしているわけだが(別に初めてじゃないけど、自分自身がそこにまともに向き合おうとしてるのは始めて)、

さらに時代は、Seaser2などのDIコンテナに行こうとしている。
うちのメンバーに話を聞くとDIのすばらしさや、テスト効率の良さは評価はすれど、現状の採用に関しては否定的だ。理由は、

・XML記述が増えて、情報の流れがわからなくなる。独立性を高めることで、視認性が悪くなる(で、うちは大規模開発じゃないから、仕様書よりソースコード見たほうが早いこともあるわけで。頑張っても恩恵を得ないかなという判断。)
・Eclipseの入力補完に対応していなかったりして、わかりにくい・・・とか。

Strutsあたりがバランス的に良いんではないだろうかという考え方で、「既存のServletの知識、経験でカバーできる範囲を逸脱しないこと」を重視している。

ところが、こんな話がある。

「動的言語と静的言語の交差点──RubyとJava/Seasar2の出会い」

S2DAOは,多くのJavaのO/Rマッパーと異なりXMLによる設定ファイルが不要である。~中略~いずれもJavaプログラマが必要とするスキルはJavaプログラミングと命名規約への遵守だけである。

すなわち開発者に求められるのはプログラミング・スキルだけで十分な,そういうフレームワークの方向だ。

そこだけ読むと、解決したい問題は同じというか、激しく同意なわけで。

そもそも、いろんなことを覚えなくてはいけないフレームワークは嫌いだ。
フレームワークのための教育フレームワークが必要になるなら、Windowsアプリみたいに長く食えるものとか、それ相応のメリットが相当必要だ。

とにかく、わかりやすくて、手間がかからなくて簡単なのが良い。

そういう意味で、XMLによる設定記述はウザイ。こういうのはGUIなどによるプログラム自動構築ツールが出てきて始めて生きてくるのかなと思っているわけだが、DIコンテナの基本は、XMLを利用してプログラムモジュールの構築することにあると思っていた。

その場合、もし手書きで書いた場合、XML自体の妥当性を保証してくれるツールが、あるのかないのかわからないが、少なくとも、普通にJavaコードを書けば、型にまつわるエラーはEclipseが教えてくれる。JSPは教えてくれないけど。そんぐらいならPHPとかASPの経験から解決は精神的に難しくない。

でも、この記事では、僕同様、XMLなどを敬遠する方向の記事が書いてあるわけで。
まぁO/Rマッピングに関しては、スクリプト自動生成ツールを作って対処すれば良いと思ってますけどね。無駄な記述が嫌いなのをどう解決するか?という手段としては、それもアリかなと。

でも、何が良いのかわからくなってきた。誰か教えてエロい人。
今のうちに、その本質をつかんでおきたいんだよね、やっぱ自分でコード書いてみないとわからないかもなぁ。

ただのブームには乗りたくないが、本当に良いものを見逃したくもない。


##単純に記事を読んで混乱しただけという気もしてきますた。

■同じカテゴリ[会社活動]のエントリー
<<前の記事 ゼネラリストとスペシャリスト
>>次の記事 調べていくとキリがないから、やりません
■このblogの書き込み最新3件
インターネットの可能性を信じて〜本を書きました。 バルスのツイート機能に関する謝罪を書いたら沢山反応があった件 モバツイの広告の取り組みについて、発表資料の共有