林信行 2008/5/15 いまや、Mac一筋という熱狂的なユーザーだけでなく、「何か面白いことをしたい」と考えるエンジニアもMac OS Xを利用し始めている。いったいなぜなのか、その理由を探ってみよう(編集部) 最近、Macintoshを使う著名エンジニアをよく見掛けるようになった。 代表的なところだけでも、シックス・アパートの元CTOの平田大治さん(現News2U社取締役)や米マイクロソフトでWindows 98やInternet Explorerの開発に中心的な役割を果たした中島聡さん(現UIEvolution社チーフアーキテクト)、Lingrなどの開発で知られる江島健太郎さん(現インフォテリアUSA社長)、ニコニコ動画の技術コンセプト設計などを行った清水亮さん(現ユビキタスエンターテイメント社CEO)などが思い浮かぶ。 この傾向は、シリコンバレーに行くとさらに顕著だ。シックス・ア
Google Macチームは1月30日 (米国時間)、オープンソースプロジェクト支援サイト「Google Code」上で、Mac OS X用開発ユーティリティ集「Google Toolbox for Mac」をリリースした。ソースコードにはApache 2.0 Licenseを適用、オープンソースソフトウェアとして公開するほか、同チームが開発する「Google Data APIs Object-C Library」にも反映させる。 Google Toolbox for Macは、開発者用のユーティリティとサンプルコードにより成り立つ。機能別に「AppKit」と「Foundation」の2種に分類され、AppKitにはNSBezierPathの拡張など主にグラフィック関連の、FoundationにはNSStringの拡張やシステムバージョンのチェックツールといったさまざまな機能が収録されてい
古典的なウォータフォールモデルでは、ソフトウェア開発を要求仕様分析、概要設計、詳細設計、実装(コーディング)、内部テスト、統合テスト、運用、保守みたいな工程にわけ、通常は各工程を別々の人が担当するというような方法がよくおこなわれている。 特に、要求仕様の分析、概要設計などは上流工程などとよばれていて、詳細設計、実装とは別の人ないしは組織が担当する。実装とかテストは下流工程などとよばれている。 よくあるパターンとしては元請けが上流工程を、下請け、孫請けが実装やテストなどを担当し、人月単価も下流の方が安い。 ウォーターフォールモデルでは各工程毎に成果物(仕様書や各種ドキュメント、プログラム)が大量に生産される。各フェーズ毎に定義された成果物がそろってから次のフェーズに移行するというのが建前なので、各フェーズでのドキュメントはどうしても冗長になりがちである。 一度固定した文書は次のフェーズで変更
個々のクライアントがサーバに要求する処理量は小さなものでハードウェアの性能上は問題がなくても、あまりにもクライアントの数が多くなるとサーバがパンクする――。これが最近Web開発者の間で話題となっている「C10K問題」(クライアント1万台問題)だ。 プロセス番号が足りなくなる パンクするのは例えばプロセス番号だ。 Ajaxの実装として最近注目されている技術に“Comet”(コメット)と呼ばれるものがある。HTTPのセッションをあえて切断せずに、サーバとクライアント間でつなぎっぱなしにするテクニックだ。Cometを使えばクライアントからのリクエストに応えるだけでなく、サーバ側からも不定期に情報を送り出すことができる。例えば、Web上でチャットサービスを実装するには、通常はクライアント側からサーバに一定間隔でポーリングすることで、ほかのユーザーの発言分をサーバから取得して表示するが、Cometの
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く