イノベーションはどっかで起こっている（東京で） - 未来のいつか/hyoshiokの日記
昔DECという会社があった。米国のハードウェアベンダーだ。それでもIBMの次に大きいコンピュータベンダーだった。80年代前半飛ぶ鳥を落とす勢いでVAXというコンピュータを引っさげてIBMを追撃していた。年率二桁成長を何年も続けていた。コンピュータ産業は垂直統合の会社に支配されていた。ハードウェア（VAX）、OS（VMS）、コンパイラ、RDBMS、各種ミドルウェア、開発ツール（エディタ、リンカ、デバッガなどなど）、アプリケーションすべて上から下まで自社製品だった。 何か問題があれば、それがプロセッサの問題でもOSの問題でもRDBMSの問題でも、何から何まで自社で完結していたのでどーにかなった。どーにかした。それが垂直統合というわけだ。あこがれのエンジニアは社内にいた。VAXのアーキテクトもVMSのアーキテクトもVAX FORTRANのプロジェクトリーダもVAX Rdb/VMSのプロジェクトリ
そろそろUnicodeについて一言いっておくか - 未来のいつか/hyoshiokの日記
文字コードの標準化について日記を書いたのだが、内容がいまいちだったのでボツにして気を取り直してUnicodeについて一言いっておくことにする。先日、といっても昨年(２００８年)の10月なんだけど、その中でちょと文字コードの標準化について話をしている。*1 もう1つ自分の経験としてあるのが、漢字の文字コードがあるんですけど、番号で言うとJIS X 0208とか0212とか規格の番号で皆言うわけなんですけど、実は1988年にその日本語の文字コードの改正の委員会にいたんですね。 その当時、私は 30歳ぐらいなんですけど、「富士通」とか「日立」とか「NEC」の部長さんぐらいの偉い人たちが来てて、私なんか外資系で且つ30前後のぺーぺーだから、全然格下なんですよ。 そういうところで議論の主軸を担ってるのは、「富士通」「日立」「NEC」「日本IBM」「東芝」「沖」、外資でいえば「ユニシス」とかの錚々たる
デブサミで考えた。基盤技術のカンファレンスの必要性。 2009-02-14 - 未来のいつか/hyoshiokの日記
デブサミは本当に素晴しいカンファレンスだった。いろいろな人と出会い、いろいろな話をした。そして考えた。わたしは、このようなカンファレンスが必要だ。だけど、何かが足りない。自分の場所と違うなにかを感じた。それは何かを考えた。 端的に言えばワクワクするものとワクワクしないものだ。 バズワードは全然ワクワクしない。カネにもあんまりワクワクしない。例えば、猫も杓子もクラウド、クラウドと言うが全然ワクワクしない。 しかし、クラウド(何それ)を構成する要素技術には、ワクワクする。OSの技術、CPUコアを増やすとそれに比例してスケールするOSとかRDBMSとかWebサーバとかアルゴリズムにはワクワクする。大規模サービスを提供するためのCPU技術(それって何だ？)、RDBMS、Web技術。キャッシュ、コンパイラ、JIT、VM、省電力プログラミング、省メモリプログラミング、有用なアルゴリズム、枚挙にいとまが
ユメのチカラ: 先行評価(Eager Evaluation)勉強法とトラブルシューティング
新人プログラマのよしおかです。どうぞ、よろしくお願いいたします(ぺこり)。という日々を送っている。日々のトラブルシューティングの話なんかをここに記したい。 そもそもAsianux Mobile Midinux 2.5Jというのは、Intel Moblin(http://www.moblin.org)準拠なのでいろいろお作法が違う。 debianのパッケージング方法なんかも一から勉強である。最近はインターネットのおかげで高速道路が整備されているので、必要なマニュアルは全てオンラインで入手できる。debianのドキュメントの充実度は目をみはるものがある。一見遠回りのようでいても、ドキュメントをひととおりざっと眺めてみることは、重要である。何か問題にぶちあたったときにググって断片的な回答を発見するのではなく、まづマニュアルにあたってじっくり仕組から理解をする。すぐに回答にたどりつかないように見え
ユメのチカラ: 取締役退任。生涯一プログラマ宣言。
6月30日臨時株主総会において、ミラクル・リナックス株式会社の新取締役として、児玉崇、伊東達雄を選任し、それに続く、取締役会議により、新しい代表取締役として児玉崇を選任した。佐藤武前代表取締役社長は、取締役会長へ、わたしは取締役を退任した。 ここにご報告する。 さて、ここからが本題(？)である。取締役を退任したからといってミラクル・リナックスを辞めるわけではない。今後は経営者という責任ある立場を退き一技術者としてミラクル・リナックスに貢献していく。 2000年6月にミラクル・リナックスを創業以来8年にわたって取締役CTOとしてミラクル・リナックスとともに歩んできたが、取締役というよりも、技術屋としてミラクル・リナックスのV1.0の開発、OSDL (Open Source Development Lab -- The Linux FOundationの前身)への参画、そしてAsianuxプロ
ユメのチカラ: 開発工程を別々に担当してはいけない
古典的なウォータフォールモデルでは、ソフトウェア開発を要求仕様分析、概要設計、詳細設計、実装(コーディング)、内部テスト、統合テスト、運用、保守みたいな工程にわけ、通常は各工程を別々の人が担当するというような方法がよくおこなわれている。 特に、要求仕様の分析、概要設計などは上流工程などとよばれていて、詳細設計、実装とは別の人ないしは組織が担当する。実装とかテストは下流工程などとよばれている。 よくあるパターンとしては元請けが上流工程を、下請け、孫請けが実装やテストなどを担当し、人月単価も下流の方が安い。 ウォーターフォールモデルでは各工程毎に成果物(仕様書や各種ドキュメント、プログラム)が大量に生産される。各フェーズ毎に定義された成果物がそろってから次のフェーズに移行するというのが建前なので、各フェーズでのドキュメントはどうしても冗長になりがちである。 一度固定した文書は次のフェーズで変更
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
