わたしが知らないスゴ本は、きっとあなたが読んでいる: いきなりコンサルタントに抜擢されたSEが読むべき4冊目
このエントリは、「いきなりコンサルタントに抜擢されたSEが読むべき3冊」[参照]の続きになる。 「コンサルタント」と一緒に仕事をしたことがあるだろうか? 肩書だけのなんちゃって自称コンサルではなく、McKinsey & Company や accenture といった、それでメシ喰っている連中のことだ。 彼らの阿呆ほどの猛仕事ぶりは、「マッキンゼーITの本質」[参照] に書いたが、仕事の順序というか、ダンドリの要領よさについては常々不思議に思っていた。「俺たちに明日はない」という言葉がピッタリの猪突猛進なのだが、仕事のやり方は整然粛々としている。見た目のロジカルさだけでなく、コンサルティングの仕事そのものが、あたかも何かのマニュアルに従っているかのような感じがしてならなかった。 その予感はあたってた。マニュアルを見つけたんだ。それは、「情報システム計画の立て方・活かし方」。いや、その辺に転
「やることリスト」に基づく見積もり手法
業務としてソフトウェアを開発するならば、工数の見積もりは避けては通れない。見積もりは、ソフトウェア開発プロセスのはじめの一歩に過ぎないが、その成否はプロジェクト全体の命運を握ることになる。プロジェクトに焦燥と混乱をもたらすことなく、堅実に開発を進めていくためには、正確で具体的な見積もり手法が求められる。 良く知られた見積もり手法の１つに、ファンクションポイント法がある。外部との入出力に着目して、ソフトウェアの機能から工数を見積もるファンクションポイント法は、有効な見積もり手法である。 だが、実際のソフトウェア開発の現場では、ファンクションポイント法で見積もりを行っているケースは多くはない。その原因の１つには、ファンクションポイント法を使うためには、入出力を定めたモデルの作成や、ポイントの計算方法など、専門的な知識と技能が必要なことが挙げられる。 小規模なソフトウェア開発では、見積もりのしや
素早く正規形を見抜く実践テクニック（1/4） － ＠IT
今回のテーマはデータベースエンジニアの必須知識の1つである「正規化」です。正規化は、リレーショナル・データベースのテーブル設計を行ううえで非常に重要なテクニックであり、データベースを設計、実装したことのある方なら一度は正規化に触れているのではないでしょうか。 それほど基本的な知識であるにもかかわらず、正規化を説明できる人はなかなかいません。多く聞かれるのが「何となくテーブルを作ると自然に第3正規形になる」とか「実務上は第3正規化まで行えば問題ない」というものです。 ではなぜ「第3正規化まで行えば問題ない」のでしょうか。本稿ではひととおり正規化について確認しながら、あまり触れられることのない第3正規化より先の正規化を紹介して、この疑問に答えていきたいと思います。 正規化の位置付け 正規化は、データベース設計全般にかかわる基礎知識ですが、特に論理データモデリングの作業の中で必要になります。本稿
ハドソン、Wiiのバーチャルコンソール対応ソフト「Bonk’s Adventure」を出展
ハドソンは、北米・ロサンゼルスで5月10日～5月12日（現地時間）まで開催される世界最大のゲームイベント「E3 2006」Nintendo of Americaブースにおいて、「Wii」を使用した仮想ゲームプラットフォーム「バーチャルコンソール」対応のゲームソフト「Bonk’s Adventure」を初披露すると発表した。今回は、実機操作できるプレイアブルの状態での出展となる。 Bonk’s Adventureは、横スクロール型のアクションゲームで、同社が1989年12月に日本国内で発売した家庭用テレビゲーム機「PCエンジン」用ゲーム「PC原人」の海外版。同社はゲームの主人公キャラクターである“Bonk”（＝PC原人）の北米での認知度も高いことから、出展が決定したとしている。その他展示予定タイトルは以下の通り。 Nintendo of Americaブース Bonk’s Adventure
ITmedia エンタープライズ：「地方自治体に金はない、残されているのは時間だけ」――長崎県 (1/4)
自治体にとって地場産業の活性化は重要なポイントであるはずだが、実際にそれを実践できている自治体は少ない。IT調達の現状を見ても、地場企業が受注しているケースは非常にまれである。 それは行政側の努力が足りない部分があると話すのは、長崎県総務部参事監の島村秀世氏。長崎県は業務システムにオープンソースを導入し、地場企業が参加する機会を積極的に創出していることでも知られている。同氏に自治体は電子自治体化をどう考えるべきか、また、オープンソースはそこにどう寄与するのかを聞いた。 自治体のシステムはなぜ高いのか？ ITmedia 業務システムにオープンソースを導入したことによるここ数年の成果を振り返っていただけますか。 島村 わたしが民間から入庁した際、知事から「電子自治体の構築には数百億必要だとも言われているが、この金額は長崎県の現状とあまりにかけ離れている。これを安価に構築できるようにしてほしい。
速く動くより早く書くが重要な時代 : 404 Blog Not Found
2006年04月18日12:24 カテゴリLightweight Languages 速く動くより早く書くが重要な時代 以下の意見に首肯する人には、普通のやつらの上を行くことは出来ないだろう。 Hardcoded: 素朴な疑問 - なぜスクリプト系 Web アプリ言語がいまだ主流なのか？ 現在、処理速度、データ量、並列処理といった諸要件が Web アプリに厳しい条件を課している。しかしながら、相変わらず Web アプリの主流がスクリプト言語にあることには素朴な疑問を覚えざるを得ない。ムーアの法則よろしくいくらコンピュータの性能が向上しているとはいえ、大量のスクリプト言語処理が及ぼす負荷は計り知れない。 ましてや、AmazonやGoogleには何億年たっても追いつけない。 理由はタイトルの通り。今や速く動くプログラムを書く事より、プログラムを早く書く方がよっぽど重要だからだ。以下はあまりに有
CNET Japan Blog - 江島健太郎 - Kenn's Clairvoyance：あらためて感じる、開発の進め方の難しさ
あらためて感じる、開発の進め方の難しさ 公開日時： 2006/04/16 14:43 著者： kenn 最近めっきり開発者モードへと還って失われた日々を取り戻しつつ目下急成長中（注：当人比）の江島でございます皆様いかがお過ごしでしょうか。 色々模索しながらやってきた新サービス開発プロジェクトですが、同僚のダニーがバックエンドのコードを書き、ぼくがUIの部分を担当するという大まかな分業に落ち着いてきています。 すでにpretrieve.comというパブリックレコード検索エンジンを開発してリリースした経験のあるダニーはともかく、ぼくは本格的なウェブのサービス開発というのは初めてなので、あちこちで頭をぶつけながら修行中です。 この手のウェブのプロジェクトは、一見簡単そうに見えて実際やってみるとスピーディにやるのは結構難しくて、とくに進め方についてはずっと暗中模索でちょっとずつ前進という
バッドノウハウからグッドラッパーへ
「有用なものを生み出すけれど複雑怪奇になっているシステム」を見つけたときには、 「バッドノウハウだ」と批判するだけではなく、 バッドノウハウを隠す「グッドラッパー」を作ることを考えよう、というお話。 目次 はじめに 有益なものを生み出さなければ「奥が深い」とも呼ばれない バッドノウハウをグッドラッパーで隠そう 本当によくないシステムとは よびかけ 補足：Perlとバッドノウハウ いろんな方からのコメント 反応リンク 関連リンク 更新履歴 ぜひ、感想をお送りください はじめに 高林哲さんは『バッドノウハウと「奥が深い症候群」』というページで、 「奥が深い症候群」や「バッドノウハウをありがたがることの危険性」について書いています。 これはもっともな指摘なので、それを受けてもう一歩進んだ話を書いてみましょう。 有益なものを生み出さなければ「奥が深い」とも呼ばれない もしも「奥が深い」システムが何
いやなブログ: 配列操作の比較表: Ruby, Python, JavaScript, Perl, C++
配列操作の比較表: Ruby, Python, JavaScript, Perl, C++ プログラムを書いていると、他のプログラミング言語の記憶とごっちゃになって、「配列の後ろに要素を追加するのは push だっけ、 append だっけ」などと混乱することがあります。特に Ruby, Python, JavaScript はコードの書き方が似ているので、この問題が起きがちです。 そこで、備忘録として、 Ruby, Python, JavaScript, Perl, C++ の配列操作の比較表を作りました。一番慣れている Ruby を基準にしています。間違いなどがあったらご指摘いただけると助かります。他の言語のもあるといいなあ。 Ruby (Array) Python (list) JavaScript (Array) Perl (@) C++ (std::vector)
「戻る」で入力データが消えてしまうフォームはいらない ― ＠IT
Webアプリケーションのユーザーインターフェイス[6] 「戻る」で入力データが消えてしまうフォームはいらない 「寛容性とユーザーコントロール」 ソシオメディア 上野 学 2005/12/22 前回「入力情報を預かる責任を果たせる画面デザインとは？」は、あらゆる経験則の土台となる価値観として、「ユーザーを尊重する」というユーザー中心の姿勢について述べました。今回からは、Webアプリケーションのユーザーインターフェイス（UI）・デザインを行ううえで有効な経験則を、少し具体的に考えていきたいと思います。 その前にまず、連載の第1回「ユーザーにとっては“ユーザーインターフェイス”こそが製品そのもの」で触れた HCI（Human-Computer Interaction）の分野でよく挙げられる、コンピュータを用いた対話型システムの設計原則を紹介しておきます。ここでいう「対話型システム」とは、ユーザー
Rubyでアジャイルプロトタイピング（1） ― ＠IT
想定する読者はこういう人々 本連載では、新たなアプローチでプロトタイピングを行い、アジャイルかつ正確にクライアントからの機能要件を取りまとめることを提案します。読者には、次のような方を想定しています。 上流工程に携わっているが、うまく進まず悩んでいる これから上流工程に挑戦しようとしている 下流工程でコスト、労力が増大してしまったが、その原因は上流工程にあったと感じている 上流工程の進め方について、新しいアプローチを模索している 本連載では、プロトタイピングに使用するツールとして、オブジェクト指向スクリプト言語であるRubyと、Ruby上に構築されたWebシステムフレームワークであるRuby On Rails（以下：RoR）についても説明し、実際に要件定義からプロトタイピングを作成してみるところまで行う予定です。 なお、Webシステムの開発を前提として解説を行いますが、クライアントサーバシ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Universal Binary Briefing
Joel on Software
