技術の進歩に取り残されたSIの開発手法に関する雑談
@naka_aki_spl そうですね。POJOなどの思想もそうですが、ルールで縛るのではなく、プログラマーが自分の良識で設計できるというのが理想的だと私も思います。
2011-05-29 11:28:54@ryoasai74 脱線ですが、道具の複雑さで意識を促す方法だと、上流下流が分離しちまった開発体制では、上流がその意識を持つ機会が無く、勝手な妄想を下流に押し付けて、実装も大変だし性能も出ないしで「責められる」というオチになりそう。
2011-05-29 11:28:56@naka_aki_spl 最終的には価格競争になるので、「外人、新人(コネ会社系)、ロートル(下手すると別技術)」が集まりますね<汗 RT @irof 技術者かどうか微妙な連中だけが集まるんだろうな。俺ももう駄目だーー
2011-05-29 11:29:12RT @kimukou_26: @naka_aki_spl 最終的には価格競争になるので、「外人、新人(コネ会社系)、ロートル(下手すると別技術)」が集まりますね<汗 RT @irof 技術者かどうか微妙な連中だけが集まるんだろうな。俺ももう駄目だーー
2011-05-29 11:29:56@kimukou_26 最終はその火消しに行くことになるんですけどね。何故か単価は前任者のをそのまま引きずって。 @naka_aki_spl
2011-05-29 11:37:12@irof そうか、そういうときに困った時の@mahmさん(火消し救助のプロ)のご登場になる訳ですねw<苦笑 RT 最終はその火消しに行くことになるんですけどね。何故か単価は前任者のをそのまま引きずって。 @naka_aki_spl
2011-05-29 11:40:00@ryoasai74 商用サービスのハードには金をかけて最新の機能を搭載させるけど、プログラマーの使う端末には古いままのマシンを使わせるので、せっかくの最新のハードの機能を活用できないし、新しい技術を使えるどころか技術が進歩していくのを指を加えて見てるだけというのもありますね。
2011-05-29 11:54:55@mike_neck そうそう。一番ひどかったのは98SE端末渡された時。eclipseもメモリ足りなくて動かせない><。こういう環境ほどエディタ無双になりますね RT @ryoasai74 商用サービスのハード最新、PG端末は古いまま 略 http://goo.gl/vQ3dU
2011-05-29 11:58:55RT @mike_neck: @ryoasai74 商用サービスのハードには金をかけて最新の機能を搭載させるけど、プログラマーの使う端末には古いままのマシンを使わせるので、せっかくの最新のハードの機能を活用できないし、新しい技術を使えるどころか技術が進歩していくのを指を加えて見てるだけというのもありますね。
2011-05-29 12:05:10しかしPOJOって簡単なのか?1つのクラスのなかで仕様の「でこぼこを付ける」ことが素では出来なくなる。そのぶんアノーテーションとかで「ここは何、あそこは何」とでこぼこを付けることになる。overrideだから特別な何かだというようなのが無い。これって楽なのか?
2011-05-29 12:09:58ハードウェアは保守切れしますからね。スクラッチしたアプリは保守切れという概念が無いことが多い。実際、単純マイグレーションの需要は多いですね。RT @ryoasai74: ハードやミドルはお金をかけてバージョンアップするけど、プログラムの書き方は昔のまま
2011-05-29 12:10:50上位クラスが無いことが重要なのじゃなく、有ったとしてもそれがエレガントであるかどうかが重要だと思う。出来が悪いとみんなが迷惑するだけ。出来が良いとみんな盛り上がる。いやほんとうに盛り上がるといっていい状態になる。「有益な」親クラスが有益なんだよ。
2011-05-29 12:12:08RT @mike_neck: @ryoasai74 商用サービスのハードには金をかけて最新の機能を搭載させるけど、プログラマーの使う端末には古いままのマシンを使わせるので、せっかくの最新のハードの機能を活用できないし、新しい技術を使えるどころか技術が進歩していくのを指を加えて見てるだけというのもありますね。
2011-05-29 12:16:28RT @tomy_DJ: ハードウェアは保守切れしますからね。スクラッチしたアプリは保守切れという概念が無いことが多い。実際、単純マイグレーションの需要は多いですね。RT @ryoasai74: ハードやミドルはお金をかけてバージョンアップするけど、プログラムの書き方は昔のまま
2011-05-29 12:17:00@naka_aki_spl POJOは簡単というより、要件に応じていかにも設計できるというところが本質だと思うのですよね。複雑なドメインなどでは継承や委譲やデザパタが使えますし、簡単な場合はデータBeanでよい。 http://bit.ly/g808j6
2011-05-29 12:21:49@ryoasai74 のだけど、実際には継承構造を持たせたPOJOを食わすと期待通り動いてくれないFWとか有るわけで、結局、縛りの明示化から暗黙陰湿ww化になっただけじゃねか?と思うことが(常にじゃないですが)時々あります。
2011-05-29 12:24:26@ryoasai74 こっちから能動的に動くようなクラスについてはまあいいんですが、FWにPOJOなオブジェクト(やクラス)を放り込んだら魔法のように!系のやつは、POJOとはいっても実は縛りが多いってのが有るような印象。受動的なぶん想定条件がアッチ持ちになってる。
2011-05-29 12:25:34@naka_aki_spl なるほど、こういうあたりで、クラスをどのように設計すべきかはまだ職人の勘が必要なところだし、どうしてもアジャイル的にくせを検証する期間が必要になる部分ですね。
2011-05-29 12:28:58@ryoasai74 順番が逆転しましたが(第一印象を重んじたいもので)リンク先を読みました。「侵略的」か。なるほどです。これとさっきの俺のと組み合わせると「対POJO侵略的なFW」も有るねというコトに成っちゃうかな。
2011-05-29 12:29:28@naka_aki_spl [ロートル=該当知識がないのに会社的コネでいる人]「モヒカン族=技術と知識が豊富なベテラン(亀仙人」なイメージで@naka_aki_splさんは後者なイメージですね。単につかれているだけですよ RT @irof はーいロートルでーす。もうだめだーー
2011-05-29 12:31:39@ryoasai74 POJOは(すなおに考えれば)結局はlibやFWと無縁な存在ですから、libやFWと「親和させる」層がどこかには必要になりますよね。うーん。そこが味噌か。
2011-05-29 12:31:48@naka_aki_spl クラスの構造は比較的自由だけれど、見えない部分で制約を与えているという意味ではintrusiveなところがあるとは言えますね。でも、いずれにしてもハイレベルの議論で、一昔前のSIer FWの侵略性はひどいものがありましたのでそれに比べたら天国に見える。
2011-05-29 12:31:56@ryoasai74 「くせを検証する」かあ。そうですねえ。卑近にいえば独りよがりの癖の塊だったらPOJOというよりPoor(哀れな) Ore-sama Java Objectになっちゃうもんなww
2011-05-29 12:33:12