最終回です。今回は，ある意味IT業界の禁忌に触れてみます。Web＋DBシステムを発注したときの見積もり額の秘密です。システムが目指す最終的な目的は”利益を上げられる仕組みの構築”です。見積もり額は利益算定の一番わかりやすいコスト判断ですが，果たして構築費用はどういう計算で生まれているのでしょうか。 利益を上げるコツは「身の丈に合った投資」をすること 利益を上げるためにはどうするべきか。私は経済評論家ではありませんから，あれやこれや難しい話はできません。ただ物事の本質は，実はいつだって単純なものです。バサっと単純明快に言い切ってしまいましょう。「自分の身の丈に合った額を投入すること」です。 決して都会とは言い切れない我が家周辺では，冬になると焼き芋の巡回販売車が回ってきます。焼き芋屋さんのほとんどは軽トラックを使っています。なぜ軽トラックなのでしょうか？　つまらないことに見えますが，これがビ

前回はクロスサイト・スクリプティングのぜい弱性を突く攻撃の対策としてのHTMLエンコードの有効性を述べた。ただ，HTMLエンコードだけではクロスサイト・スクリプティング攻撃を完全に防御することはできない。そこで今回は，HTMLエンコードで対処できないタイプのクロスサイト・スクリプティング攻撃の手口と，その対策について解説する。 HTMLエンコードで対処できない攻撃には，次のようなものがある。 タグ文字の入力を許容している場合（Webメール，ブログなど） CSS（カスケーディング・スタイルシート）の入力を許容している場合（ブログなど） 文字コードを明示していないケースでUTF-7文字コードによるクロスサイト・スクリプティング <SCRIPT>の内容を動的に生成している場合 AタグなどのURLを動的に生成している場合注） 以下では，HTMLタグやCSSの入力を許容している場合と，文字コードを明

新人配属や異動の季節になった。この4月，あなたがもし新しい職場に配属されて，上司から「君，Ajaxって知ってる？」と聞かれたとする。そのとき，堂々と「知ってますよ」と答えられるだろうか？ このITproのサイトでは，Ajax，マッシュアップ，リッチ・クライアント，SaaSなどいわゆるWeb2.0関連の記事が一昨年ぐらいから毎日のように掲載されている。そもそもITproはこうした言葉を知っている読者を対象にしているので，ほとんどの読者は冒頭のような質問を受けても，「知ってますよ」と堂々と答えられるだろう。しかし，この春初めてITの世界に入る人の中には，「名前や概念的なことなら分かるのですが…」という人も多いのではないだろうか。 そこで今回の記者の眼では，そういう新人君にお勧めな「Ajax学習法」を考えてみた。といっても，要するに，実際に自分でちょっとしたプログラムを作って試してみるだけである

Flash 8 入門講座 目次 お絵描きからActionScriptを使ったアニメーション制作まで いまやすっかり，Web上のインタラクティブ・コンテンツの代名詞となった感がある“Flash”。実は，アニメーションやゲームなど私たちが目にする，いわゆるFlashコンテンツは正確には「Flashムービー（ファイルの拡張子は.swf）」と呼びます。 Flashムービーを作成する方法はいくつかありますが，一般には，アドビシステムズの開発ツール「Macromedia Flash（以下，単にFlash）」を使います。本連載では，Flashの最新版である「Flash 8」を使って，Flashムービーの作成方法を中心に紹介していきます。Flash 8を持っていないという人も，1カ月間タダですべての機能を使用できる体験版がアドビシステムズのWebサイトに用意されているので，ダウンロードして一度試してみては

ソフトウエア・エンジニアリングのリーダーの一人、エド・ヨードンは1992年に、『Decline and Fall of the American Programmer 』を著し、米国のソフトウエア産業の衰退と挫折を警告した。この本を出す少し前まで、彼は「この国が危ない（A Nation at Risk）」というタイトルで講演行脚をしており、同書はそれをまとめたものである。 この本の中で、ヨードンは日本をソフトウエア開発における優等生の一人として挙げ、インドの飛躍を予見している。本が書かれた時点では、インドのＩＴ産業はまだ黎明（れいめい）期にあったが、彼の予想通り、現在は英語圏で質の高いソフトウエア開発力が得られる国として、欧米から頼られる存在になり、ＩＴ立国を目指す他のアジア諸国からお手本と見なされるまでになった。 「この国が危ない」というヨードンの警告に触発されたのか、米国上院の「米国の

この連載では，エンジニアの視点から使いやすさを考えています。今回はユーザー登録画面などに代表される，フォームを使った入力画面について考えてみたいと思います。 なぜこのテーマを選んだかというと，フォームを介して利用者からデータを受け取って処理をして返すという一連の処理が，ウェブサイトのバックエンドの処理やデータ形式などによって変化しやすく，プログラマやエンジニアの作業がもっとも使いやすさと関係しやすい分野ではないかなあ，と思っているからです。こうした部分はエンジニアが使いやすさに寄与しやすい部分であり，もっと言えば，使いやすさを向上させるに当たって，エンジニアにしかできない事柄がたくさんある部分だってことになると思います。 今回は「ユーザー登録ページ」を例に，フォームにおける使い勝手を考えていきたいと思っています。その理由としてまずは，筆者が勤務する株式会社はてなにもユーザー登録画面があり，

このパートでは，プログラミングを勉強するうえで欠かせないアルゴリズムの中でも定番中の定番を紹介します。ソート（並べ替え）やサーチ（検索）などの機能は今では標準のライブラリとして提供されています。実用的なプログラムを作るときにそのものずばりをいちいち書く機会は少ないかもしれません。しかし定番のアルゴリズムは，様々に形を変えて普段のプログラミングに登場します。 解説を読んで仕組みがわかったら，ぜひそれをプログラムにしてみてください。読んだだけではプログラムを書けるようにはなりませんし，プログラムを書いてみて初めて，実は十分に理解できていなかったと気付くことがよくあります。しかもアルゴリズムは特定のプログラミング言語に依存しないので，一度身に付ければ，後でどんな言語を学ぶ場合でも役に立ちます。 1番目から6番目まではソートのアルゴリズム，7番目から9番目まではサーチのアルゴリズムです。一つひとつ

最近，Webプログラミングの世界で静かなブームになっている言語があります。何を隠そうJavaScriptです。JavaScriptはご存知のとおり，クライアントサイドすなわちWebブラウザ上で動作するタイプのプログラミング言語です。最初にJavaScriptが実装されたのは，今から10年以上前の1995年，Netscape Navigator2.0でのことです（登場当時はLiveScriptと呼ばれていました）。決して新しい言語ではありません。それが，どうして再び注目されることになったのでしょう。その理由は，Webインタフェースのプログラミングで，JavaScriptの有効性や利便性が再発見され，言語そのものが持つユニークさや機能が技術者の関心を集めているからです（図1）。 JavaScriptを使うのはダサかった？ Webインタフェースの技術といってもHTMLしかなかったころ，様々なプロ

Webの全体像を効率よく取り込み，分類する 「YSTのシステムは大まかに三つの機能に分かれます（図2）。最初は世界中のWebページをYSTのシステムに取り込む『クローリング（crawling）』という機能です」（Yahoo! JAPAN，リスティング事業部 検索企画室の宮崎光世氏，以下同）。 取り込むと簡単に言っても，Webページの数は膨大なうえ，更新の頻度や情報の質などがまちまちです。すべてのページに同じようにアクセスしていると非効率なことこの上ありません。そこで，限られた時間で質の良い検索ができるようにするための工夫をしています。例えば，クローリングを繰り返すうちに頻繁に更新されることがわかったページは短いサイクルでチェックし，ほとんど更新のないページはチェックの頻度を落とす，といったことをしているそうです。 ただ，更新の頻度が単に高いだけではダメです。重要性が高いと考えられるWebサ

Webサイトのデザインの中で，ここ2年で大きく変わりつつある「常識」があります。それは，「メニュー（索引）」の位置と「一等地」の場所です。ユーザーの閲覧環境が加速度的に変化しているという認識の下で，それでも最良のユーザビリティを提供しようとするなら，どのようなことを考えておく必要があるでしょうか。 左メニューと右メニュー（視線との交差）のどちらがベスト？ まだモニター画面の大きさが小さかった時代（1995年前後），情報へアクセスしやすくする「メニュー」の位置は，ほとんど誰が考えても左側にあり，議論もされなかったように記憶しています。確実に画面の中に入り，ユーザーも基本的に左端にさえ注意を向けていれば，大切な情報にたどり着けるという「暗黙の常識」が存在していたかのような時代でした。 しかしここ数年，メニューが左側にあると本当に操作性が良いのかという議論を聞くようになり，大手のWebサイトでも

今，Webアプリケーション開発者の間で，あるフレームワークが大変な注目を集めています。オブジェクト指向スクリプト言語であるRubyを使って作成されたWebアプリケーション・フレームワーク「Ruby on Rails」です。略して「Rails」や「RoR」とも呼ばれています。開発者はデンマーク在住のプログラマであるDavid Heinemeier Hansson氏です。現在は彼が属する37Signalsという企業が中心になって開発しています。 Railsは，2005年に海外で大きな話題を呼び，一大旋風を巻き起こしました。そのおかげで米国ではRuby関連の書籍の売り上げが1年間で15倍以上に増えたそうです。また，2005年8月に開催されたオープンソース・ソフトウエアに関する世界最大のコンベンション「O'Reilly Open Source Convention（OSCON）2005」では，Ra

Webプログラミングは，プロはもちろんアマチュアのプログラマの間でも，もはや欠かせない開発ジャンルの一つです。しかし，書籍や雑誌の解説記事のほとんどが，データベースがどうとか，サーバーサイドがどうとか，どうしてもディープな方向に進んでしまう傾向にあります。もちろん，それはそれで大切なことなんですが，いったい何割の人が，その技術を“自分の”ホームページに使っているでしょう。 最近話題の「リッチ・コンテンツ」にしても同様です。例えばFlash。たしかにActionScriptというスクリプト言語を使えば，動く，鳴る，つながると，いいこと尽くめです。でも，いかんせん「Macromedia Flash MX 2004を買ってきてね」とあっては，皆がみな使えるわけではありません。 Part1でも解説があったようにblog（ブログ）の認知度が上がり，利用率も増えて，プロバイダからの提供体制も整ってきて

Webサイトを設計する際，「色」は様々な問題を起こします。開発者それぞれの想いが込められやすいのかもしれません。開発末期になってから，色の変更指示で不眠開発になるという話は，いまだ昔話にはなっていません。 色の問題を解決するためには，色についての知識があったほうが助かります。ただし，色自体の講釈をここではしません。色を決めていく過程の参考になりそうなことを記します。 刷り込まれている色/固定イメージのある色 私たちは様々な色に囲まれて生活しています。その中で，色と行動が一番密接にかかわりを持つのは「信号」です。我々の取るべき行動を色が指示します。それはあまりに一般的になりすぎて，我々は無意識のうちにそれらの色に対して同様の行動パターンを取りやすくなっています。 例えば，赤色を見ると何か危険なことがそばにあるのかもしれないと警戒したり，黄色の標識を目にすると周囲に対して少し注意力をはらったり

対象とするユーザーの“慣れや知識”によって，画面の構成を変えたほうが伝わりやすいとするならば，画面上の「ユーザー・インタフェース（UI）部品」の色や形状も，ユーザーに応じて変えるべきでしょう。今回は，代表的なUI部品でありながら，なかなか作り手の思うように押してくれない「ボタン」について考えます。 わかりやすいボタンの形状はユーザーによって違う まず，前回とほぼ同じ絵を用います。Webシステムの操作方法への「熟知度（PCリテラシ）」を縦軸，「提供したいサービスに対する知識」を横軸とします。そして，それぞれの「軸」に対して，受け入れやすいと思われる「ボタン」の形状を例記しました。 上図の【A】や【B】のタイプに当てはまるPCリテラシの高いユーザーは，ボタンの“ラベル”に「submit」と書かれていようが「GO」と書かれていようが，ボタンを認識することはさほど苦ではありません。 しかし，PCに