SIerが変わらなきゃってことには同意。けど日本でSIerは当分なくならない。少なくとも解雇規制がなくならないとね。米国で何故ユーザー企業が専門家を雇えるかというと、要らなくなったらクビにできるからだ。例えば汎用機とCobolのシステムをLinuxとJavaに移行する場合は、汎用機オペレータとCobolプログラマを切って、LinuxオペレータtJavaプログラマを雇い入れる。そういう世界だ。 日本じゃ簡単にクビを切れないから、潰しのきかない技術者はできるだけ雇いたくない。そこのところはSIerに押しつける訳だ。重層的な下請け構造が何故あるかというと、SIerも簡単にはクビを切れないんでバッファを必要とするからで、6次とか7次になれば会社そのものが吹けば飛ぶ世界で、労働基準法なんか形骸化しているしね。 今後はユーザー企業がどんどん内製で出来るようなシステム作りを支援する方向に向かわねばならな
諸君!!俺は Java が好きだ!! って書いてみたかった。 言語論争あんまり好きじゃないから あんまりそれらしいこと書いてなかったけど ちょっとだけ書いてみます。 「j」が付かない方の Yoshiori から見た Djangoへの片思い日記 - Struts脳の恐怖とRails ということで♪ いわゆる高級言語というのは 人間が書きやすい&読みやすいという側面も大きいと思っています。 で、完全に僕の主観ですが Java のソースコードは凄く読みやすいです。 他の言語がメインの人に聞いても 「やっぱり Java は読みやすいよね」 と、言われることもあります。 さて、実際にプログラムを書くときですが、 そのプログラムの稼働期間はどのくらいでしょうか? 開発期間より稼働期間のほうが長い場合、 保守などでコードを書く時間より 書いたコードを読む時間のほうが多いときがあります。 複数人で書いてい
今回の日本出張ではいくつかのプロジェクトの状況をみてきた。で、思ったこと。 「COBOL時代のデータ構造を引きずることで、生産性や保守性が落ちている」 フラグだらけのマスター 本物のコードをだすわけにはいかないので、すごく簡略化した例で説明したい。あるシステムを利用できるユーザのマスターテーブルがあるのだけど、そいつには「なんちゃらサービス利用可否フラグ」みたいなのがたくさんついているのね。 この方式の問題は以下の通り。 テスト負荷 フラグがあるということはそれをチェックするif文があるということ。 if文があればテスト件数は最低2件は増える。 入れ子になれば、4件、8件...と増えていく。andやorでも同じ。 コードの冗長性 「あるユーザがサービスAを使えるか」を調べる処理と「あるユーザがサービスBを使えるか」を調べる処理はほぼ同様になることは明らか。 「サービスAを使えるユーザ」を調
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く