内作フレームワークが持つリスクを考慮すべきですよ＞某大手 SIer さん - イトウ アスカ blog
大手（ばかりではないでしょうが）SIer さんがたまにやる、どこにも公開していない内作フレームワーク（今回は、Java の Web アプリケーション用のものを念頭におきます）でプロジェクトをすすめるのはこういうリスクがあるんですけど、考慮してますか？ っていう話です。 わざわざ書くってことは、考慮してない現場をまのあたりにしてるからなわけですが。 名の知れているフレームワークと言うとまずは Struts ですね。名が知れていないものでも、容易に情報が得られるフレームワークはたくさんあります。また、プロの編集者がちゃんと編集・校正して、しっかりと製本されたそれらの参考書も手にはいります。 いっぽう、内作のフレームワークについて、それを使わされる下請けさんなどの立場で見るとどうでしょうか。 プロジェクトが始まるまで、下手すれば名前すら聞いたことがない。 プロジェクトが始まっても、なぜか実行環境
見積もり2億円のIP電話を820万円で構築した秋田県大館市から学べること：ITpro
秋田県大館市は2008年12月，市庁舎にIP電話を導入したことを公開した。同市は2005年6月に1市2町が合併して現在の大館市となった。以前の市と町の庁舎を有効活用するため分庁舎制をとっていたが，8庁舎9事務所間の連絡を公衆回線で行っていたため「多大な電話料金が生じていた」（大館市）。2006年，本庁舎の構内交換機を交換する時期に合わせ更新を検討した。電話料金の削減を狙いIP電話を検討したが，ベンダーからの見積もりは約2億円。電話料金の削減をあきらめて従来と同じアナログ交換機を更新する場合でも約2000万円との見積もりだった。 このとき，自前でのIP電話導入を提案した職員がいた。前述の中村芳樹氏である。中村氏は同市商工課の職員。電話網を担当する総務課ではなかったが，趣味で中学生のころからパソコンを使っており，独学でプログラミングも学んでいた。市でIP電話の導入を検討していることを耳にした中
そろそろ例のプロジェクトについて言及するか - 西尾泰和のはてなダイアリー
以前、とあるシステムのソースコードを読む機会があったのだけどあまりにひどかった。あのひどいコードでまあまあまともに動いているというのが逆に信じられない。今日昼ご飯を食べながら少し話していたのだけど意外と知られていないようなので、話せる範囲でいかにひどいのか説明してみようと思う。 まず、ソースコードが大雑把に見積もって3750万行あるのだけど、その中でまともに機能しているコードは3%しかない。10分の1程度のソースコードで同程度の機能を実現しているシステムもあるのでほんとあのシステムのコードはゴミだと言っても過言じゃない(*1) プログラマとしてはなんでそのプロジェクトはそんな状態になってしまったのか気になるところだけども、まあ多くのプロジェクト同様、真相を知る人は誰もいない。でもまあ、実際に機能しているコードのコピーみたいなものがあちこちに散らばっていることからしてコピー＆ペーストが盛んに
バグで大事なのは内容じゃない！ - Fight the Future
火消しプロジェクトなので、毎日数十件というバグが出ていた。 BTSのようなシロモノはなく、Excelでの障害管理表という(悪い意味での)一般的なバグ管理だった。 しかし、そこに書かれているのはバグの内容ばかり。 ああ、わかっていない。 エンジニアにとって、重要なのはバグの内容でもなければ、コードを書けもしない人の原因の推測でもない。 バグの再現手順だ。 再現さえできればバグの内容なんてすぐに把握できる。 だからバグの内容なんて1行程度の概要だけでいい。 でも再現手順がなければそのバグを再現するだけで相当の工数がかかる。 たとえば、どんなユーザーでログインしたのか？ どんな画面遷移をしてその画面に行くのか？ どんなIDのデータなのか？ 画面上でどんな操作をすればバグが出現するのか？ こういったことが記述され、すぐにでも再現できればバグの修正コストは相当低くなる。 そもそもの話で、管理表にバグ
第3回■ぜい弱性対策の考え方 -- 「保証なし」が原則のオープンソースは運用体制が超重要
表を見ると分かるように，PHP4は7年半にわたってサポートが継続していた。これだけを見ると商用製品に大きく引けを取るわけではない。ただ，後継バージョンであるPHP5が公開された時期がPHP4の4年遅れだったため，PHP5の公開直前にPHP4で開発されたアプリケーションは3年半でセキュリティ・アップデート終了ということになった（図1）。 加えてPHP5の初期バージョンが不安定であったこと，PHP4に対する互換性が不十分だったことなどから，PHP5への移行はなかなか進まなかった。結果として，PHP4で開発したあと1～2年でPHP4のサポート終了を迎えたサイトも多いようだ。 現行のPHP5系統についても，PHP5の最初のリリースから既に4年以上が経過していることから，今後何年程度サポートが継続されるかは不明確である。今後PHPを使用してWebアプリケーションを開発する場合は，アプリケーションの保
古いプログラムを有効活用 “高知県方式”に注目:アルファルファモザイク
汎用機と呼ばれる業務用の大型コンピューターを、より安価なシステムに更新する際に、以前の機種で動いていたプログラムを有効活用する手法を、高知県と地元ＩＴ企業が開発した。 “高知県方式”と呼ばれ、特許も取得。ほかの自治体などから「費用が安く期間も短い」と注目されている。 汎用機は高性能だが、高価で保守費用がかさむのが難点。最近は保守が簡単な複数の小型コンピューターをつないだシステムへの切り替えが盛んだ。 従来はプログラムを新たに作り直す必要があったが、高知電子計算センター（高知市）がプログラムを自動変換する技術を開発。１９９９年に始まった県の業務システム更新に用いた。 当初は３年かかるとみられていた汎用機１台の更新が１年半で完了。費用も４分の１の２億６０００万円で済んだ。 県情報政策課の吉本幸弘主任は「高知県方式が広まれば、地域の産業振興や雇用の拡大につながる」と期待している。 ■
エンジニア的発想は危険な気がしている - 矢野勉のはてな日記
雑談「エンジニア主導で作ると、動いたところで満足してしまう。『ちゃんと動いているから、あとは使う人が分かってくれるだろう』と、考えをストップするところがあった。本当は、動いたものを説明して分かってもらい、使ってもらうところまで来てやっと完成なのに」近藤社長「未熟だったと思う」 はてなが目指す“脱IT系” (1/2) - ITmedia News なんかね、私がコンピュータにはまったときに理想とされていたことから比べると、それでもまだ足りないと思っちゃったんです。 自分ができているかどうかは棚に上げて、理想とするところを考えてみる。目標がどこにあるかっていうのはすごく大事なことだと思うし、上記の発言は目標を吐露したものだと思うので。 私はMac OS Xが生まれる前の、漢字Talk 7とか作ってた頃のAppleの、Macintoshを買ってコンピュータの世界に没入しました。そのころのコンピ
製造を行っていないSIerで製造出来る社員に育つには - Yamkazu's Blog
id:yuripopのエントリーを読んで感じたことをただ書いてみる。 そこそこ大きなSIerになると、製造は外注というのは良くある話で、SIerに技術の空洞化みたな現象が起きているというのも良く聞く話です。 でも本当会社にもよるし、大きい会社だと部署ごとに文化が本当に違ったりするので一概には言えませんが。 そういったSIerでも製造は全くやっていないのかといえば、そういうわけでもなくて新人にはやらせてたりする。ただこれは、あくまでも新人の育成の観点で製造をやらしているだけであって、本当に製造が出来る人材を育てようとしているわけではない。少なくとも私の周りでは。 内製者が技術力を外に求めてどうする、というようなことを。 外注と同じ仕事しかしないなら辞めろ - 歩きつづける ゆり 咲きつづける でも、これってしかない場合もあるかなと思います。だって、中に製造技術がないんだもん。 別にその製造を
SEとPG、どっちが頭がいい？（2）：下流から見たIT業界：エンジニアライフ
刺戟的な題名で続けます。 前回は日本独特のSE／PGの分業体制がどのようにして発生したのか、ということを説明しました。それは日本にソフトウェア開発が産業として根付いたときに、PGが単純作業労働者と位置付けられてしまったため、上級技術者を区別する言葉が必要とされた、それがSE（システムエンジニア）だというものでした。 ●C言語＠UNIXでは COBOLの開発ではSE作業とPG作業がきちんと分けられていると思われがちですが、これも前回述べたとおり実際には形式だけのものになっていました。これはタイムシェアリング端末の普及によってプログラミング作業が格段に効率化されたからでした。プログラミングに残っていた煩雑な手作業の部分が省力化されたのです。 この事情はBasicやC言語でも同じことです。1980年代後半、わたしは最初の会社を辞め、パソコンの開発をするようになりました。現場では、技術者はそれぞれ
開発者と利用者では「継続」の意味が違う - ただのにっき (2008-05-16)
■ 開発者と利用者では「継続」の意味が違う tDiaryのリポジトリを、CVSからSubversionに移行中だ(hsbtが)。SourceForge.netがsvnをサポートしたのはずいぶん前だから、とっと移行しちゃえば良かったんだけど、「2.2を出すまで待とう」と思っていたらいつまでたっても出せなかったので(笑)、こんな時期になってしまった。もたもたしている間に巷ではgitやらMercurialのような分散VCSが流行し始めてしまい、いまさらsvnかよ的な状況。でもまぁ、これくらいがちょうどいいんじゃないかね。 いまのところ、tDiaryプロジェクトのミッションは「プロジェクトを25年間存続させる」である(参考:「継続」という目標)。人生の記録をつける日記システムが、たかだか数年で消えうせるようでは困る。せめて四半世紀は安心して日記をつけ続けられるようにしたい。バグ修正だけでなく、時流
スルガ銀と日本IBMの「動かないコンピュータ」裁判の訴状内容が判明、要件定義を3回繰り返す
スルガ銀行がシステム開発の中止で損害を受けたとして、発注先の日本IBMに約111億円の支払いを求めた裁判の訴状内容が明らかになった。3月6日の提訴直後に日本IBMが訴状の「閲覧制限」を申請していたため訴状を閲覧することができなかったが、4月24日に一部内容を除いて制限が解除された。 この閲覧制限解除とは別に日経コンピュータは独自に訴状を入手。その訴状によればスルガ銀は、「日本IBMから2004年3月に、米フィデリティ・インフォメーション・サービスの勘定系パッケージ・ソフト『Corebank』を日本市場向けにカスタマイズする提案を受けた」。 Corebankの売りは2つある。1つは、口座単位で預金の残高を管理するのではなく、顧客単位で複数の口座をまとめて管理できる点。もう1つは、預金や融資など複数の金融商品を組み合わせた連動型商品を素早く開発できる点である。日本の銀行における勘定系システムの
極力ユニットテストを書かずに品質を確保する方法 - ひがやすを技術ブログ
今日のテストサミットで、できるだけユニットテストを書かずに品質を確保する方法について、ディスカッションします。 やり方を簡単に紹介すると、最初は、Programming First Developmentで、機能を実装して、ユーザに動かしてもらうってことをユーザの要件が固まるまで繰り返します。このときは、基本的にユニットテストは書きません。動かすことに集中します。 ユーザの要件が固まった(実装がほとんど終わった)ら、保守のためのドキュメントの一つとして、テストシナリオ(ユースケーステスト)を作って、テストを行います。そのテスト中に、バグが発見されたらその周辺のユニットテストを書いていきます。 これは、「バグは偏在(偏って存在)する」という特徴を利用して、一通り動かした後に見つかったバグの近くをテストしておけば、主なバグはつぶれるだろうという考えです。 これまでは、「ユニットテストは、できる
メンテナブルなコードよりもテストが重要っておかしくない? - ひがやすを技術ブログ
その意味で、実はコーディング規約より、メンテナブルなコードよりも役に立つのが、テスト。要はテストをパスしてしまえばどうコードしても構わない、というのがTDD = Test Driven Development =テスト駆動開発の考え方のベースとなっています。 テストは、どう考えても、「目的」ではなくて「手段」ですよ。 メンテ不能なスパゲティコードだけど、テストは完璧ってソースに修正を入れられますか。 「テストをパスしてしまえばどうコードしても構わない、というのがTDD」というのは、TDDをかなり狭く捉えているっていうか、誤解している。 TDDの元になっている(と思う)XPは、メンテナブルなコードを書くことを目指している(と思う)。じゃどうやってメンテナブルなコードを書くかという「設計手法」がTDDなわけです。 TDDはテスト手法じゃない。設計手法です。テストって単語が入っていると、テストの
『ドキュメント内のリテラルにも注意』
というように、決まった値を持つようなもの（名義尺度や順序尺度 ）である。 プログラミングでこうした値を扱う場合は、数値やコード値をそのまま（リテラル ）では記述せず、定数を定義して、それを使う。あるいは、「列挙型 」を扱える言語であれば、そちらを使う。 ソースコードが読みやすくなるのはもちろん、数字と「意味」の対応が変わった時に、定義だけを変えれば対応できるからだ。例えば、途中に新しいステータスが挿入されて後ろの数字がずれたとしても、既存のソースコードには影響しない（もちろん、挿入したステータスを使う必要がある箇所は別だし、新しいステータスの追加により「意味」が微妙に変わったりすると、修正が必要にはなるが）。 これはプログラマにとっては基本的なテクニックであり、初心者の書いたコードでもそうなっていることがほとんどだろう。
SIerのフレームワーク - Kazzz's diary
最近うんざりしているのは、自ら作った(or用意した)フレームワークを案件にバーターしてくるSIerがいることだ。 SIerから仕事を請けているソフトウェアハウスの多くは、コンペで低く抑えられた発注金額や単価を生産性や熟練度でカバーするために自社又はOSSのフレームワークを採用することが多いのだが、プラットホームやミドルウェアならまだしもフレームワークまで押し付けられると、こういった目論見がパーになるのである。 SIerのフレームワークといっても、ソースを見ると大抵はOSSのフレームワークを拡張しただけの設計であり、それにオーサリングツールとEclipseプラグインを組合せた構成なので、結局は使う開発環境やツールまでロックインされており、お世辞にも快適とは言えない場合が多い。その癖エンドユーザからはちゃっかりとフレームワークのライセンスフィーを頂いていることが多く(ユーザ向けにはパッケージ扱
Game Developers Conference 2008現地レポート
【10月2日】 「任天堂カンファレンス 2008.秋」レポートその1 ハード編 「自分専用DS」を目指した「ニンテンドーDSi」 「任天堂カンファレンス 2008.秋」レポートその2 ソフト編 年末年始も磐石? 「Wii Music」ではとたけけ登場!? 「任天堂カンファレンス2008秋」 主要タイトル・ファーストインプレッション 「ニンテンドーDSi」を一足先に体験!! 他 任天堂、スクリーンショット集〜DS編 「マリオ&ルイージRPG3!!! (仮)」、「メイドイン俺」、「立体ピクロス (仮称)」など 任天堂、スクリーンショット集〜Wii編 「罪と罰2 (仮称)」、「Punch-Out!!」、「街へいこうよ どうぶつの森」など 任天堂、「ニンテンドーDSi」を発表 30万画素カメラ付、SDカードスロット付で11月1日発売 【速報版】 佐藤カフジの「PCゲーミ
2008-02-19
「オープンソースとRIAの融合：Seasar2とBlazeDSでFlex3が加速する」 というテーマで講演します。 フレームワークが、最初登場したときは、必要な機能が足りなかったり、バグがあったりするものです。それが、ユーザに辛抱強く使ってもらうことで、機能が強化され、バグは修正され、安定していきます。 そうすると、ユーザも増えていき、さらに機能も強化されていきます。 機能を強化するというと聞こえはいいのですが、悪い言い方をすると、どんどん肥大化していきます。 肥大化していく中で、あるポイントを過ぎるとユーザは、重い、あるいは、機能過剰と感じ、離れていく。 このことに、フレームワークを作っているほうは気が付かない。自分たちは中身を良く知っているから、覚えることがたくさんあるとは感じないし、自分たちで必要だと思って追加したんだから、不要な機能があるとは感じない。 既存のユーザは、新機能だけを
Matzに聞いてみた：効率の良い開発についてどうお考えでしょう？ - builder by ZDNet Japan
曖昧になる技術の境界線 ウェブエンジニアを取り巻く状況は混沌としている。まずは知っておかなければ行けない分野が飛躍的に増えている。HTMLやCSS、JavaScriptはもちろん、ときにはRubyまでもやらなければいけない、さらにはデータベース（DB）のことも知っておかなければならない、といった具合だ。 さらには、どこからどこまでをどの技術でやるべきかという見極めも難しい。たとえば、Ajaxアプリケーションを作る際、JavaScriptを使ってフロント側で処理するのか、バックエンドでRubyで処理するのか、あるいはどこまでをバックエンドで処理すべきなのか。どこからどこまでをJavaScriptですればいいのか。そうした技術の境界は、どこにあると見るべきなのか。ウェブ開発の分野では、技術の境界が曖昧になっているのである。 この“曖昧になる技術の境界”に対して、Ruby開発者であるまつもとゆき
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
HisasAnn.com is for sale | HugeDomains
はてなブログ | 無料ブログを作成しよう