ユメのチカラ: 楽天テクノロジーカンファレンスに行ってきた。
カーネル読書会番外編ディストリビューション大集合＠楽天テクノロジーカンファレンスに参加するために、楽天に行ってきた。今回はいろいろサプライズ(後述)があって、それはそれで楽しかったんだけど、ちょっと感想かなんかを記す。 勉強会メソッドとして、(1)質問をする、(2)懇親会でいろいろな人と繋りを持つというのがある。 米国でのワークショップなんかだと非常に活発に質疑応答があって、発表そのものより質疑応答の方が重要だったりする。ところが日本の場合は、講師が一方的にしゃべるだけで、質問時間がまったくなかったり、あっても実におざなり。そもそも質問する人もほとんどいなかったりする。 で、わたしは、そーゆーのは面白くないし、活発な議論からクレイジーなアイデアが生まれ、それがブレークスルの源泉になっていると思うので、可能な限り質問をするようにしている。また、そーゆー自由闊達な議論の場というのをこの地に根付
ユメのチカラ: 初めてのRuby
「初めてのRuby」は、他のプログラミング言語の経験があるプログラマ向けのRuby入門書である。プログラミングの入門書ではない。この明確なターゲット読者の設定がこの本の特長であり成功の要因である。 すくなくともわたしにとって、他言語(C言語)でのプログラミング経験があるものにとって、これほどまでにコンパクトかつ明解にRubyの真髄を語っている本書ほど、ありがたいものはない。 わたしはかねてからプログラミング言語の文法書は50ページ以内であるべきだと思っている。プログラミング言語の構文はシンプルであればあるほどいい。道具はシンプルな方が応用が効く。 それはともかく、プログラミング経験者にとって、第二、第三のプログラミング言語を学習するということは、計算機の入門、例えば計算機はどう動くかとか、メインメモリ、CPU、外部記憶の機能はどうだという事を学んだり、プログラミングの入門、アルゴリズムとか
ユメのチカラ: 取締役退任。生涯一プログラマ宣言。
6月30日臨時株主総会において、ミラクル・リナックス株式会社の新取締役として、児玉崇、伊東達雄を選任し、それに続く、取締役会議により、新しい代表取締役として児玉崇を選任した。佐藤武前代表取締役社長は、取締役会長へ、わたしは取締役を退任した。 ここにご報告する。 さて、ここからが本題(？)である。取締役を退任したからといってミラクル・リナックスを辞めるわけではない。今後は経営者という責任ある立場を退き一技術者としてミラクル・リナックスに貢献していく。 2000年6月にミラクル・リナックスを創業以来8年にわたって取締役CTOとしてミラクル・リナックスとともに歩んできたが、取締役というよりも、技術屋としてミラクル・リナックスのV1.0の開発、OSDL (Open Source Development Lab -- The Linux FOundationの前身)への参画、そしてAsianuxプロ
【モバイルネット端末】ＭＩＤ端末（必要なアプリケーションはブラウザ）
本日インテルがモバイルインターネット端末(MID)向けの「インテルCentrino Atomプロセッサ・テクノロジ」と同テクノロジに掲載されるMID向けプロセッサ「インテルAtomプロセッサ」の発表をおこなった。 弊社のAsianux Mobile MidinuxはインテルCentrino Atomプロセッサ・テクノロジ向けのモバイルOSである。 今回、吉田共同社長のプレス発表の壇上で弊社のMidinux上で動くGoogle Mapをデモする機会を得た。 モバイルインターネット端末とは何か。携帯でもPCでもないどんな端末なのか？ 端的に言えばワイヤレスブロードバンドに常時接続をすることを前提としたモバイル端末である。 携帯との違いは、データ通信を高速かつ定額で行なうことを前提とする。 PCとの違いはインターネットを街中に持ち運ぶサイズである。 i-modeによって携帯からインターネットを簡
ユメのチカラ: なぜメリークリスマスが禁句なのか？
1989年年末、わたしは米国ニューハンプシャー州にいた。米国DECのRdb開発チームに出向になっていて、せっせとアジア版Rdbのコードを本体へマージしていた。 日本人で米国ニューハンプシャー州ってどこにあるのか知っている人は少ない。初対面の人となんかでニューハンプシャー州に居たんですよという話になって、ああ私も実はなんてことになると、一気に盛り上がってしまう。マサチューセッツ州の北にある、縦長の州で、米国独立時の13州のうちの一つである。ニューイングランド地方の一つである。紅葉が綺麗だ。 80年代は、日本の産業が実力以上に元気で、米国とは経済摩擦を引き起こしていた。半導体は日本のメーカーがトップ10のうち多くを占めていたし、銀行もぶりぶり言わせていた時期である。日本企業が米国の資産を買いあさっていたバブルのころである。 ニューハンプシャー州のナシュアという田舎町で働いていたころ、会社の帰り
ユメのチカラ: 若い人に人気のない産業は減衰する
未来をイメージできない産業に人は集まらない。IT産業は人がすべてである。魅力のない産業は減衰する。 IPAフォーラム2007 【討論会】 「学生から見たＩＴ産業」と「ＩＴ産業から見た学生」 ～ＩＴ産業は学生からの人気を回復できるか～ http://www.ipa.go.jp/event/ipaforum2007/program/discussion.html#tou-1 参加者がすごい。業界の重鎮。岡本晋氏（TIS株式会社 代表取締役社長）、浜口友一氏（社団法人情報サービス産業協会 会長、株式会社NTTデータ 取締役相談役）、藤原武平太氏（IPA 理事長）。 当日、このパネルディスカッションに参加していないので、下記の報道で様子を窺うしかないのであるが、「業界の重鎮もたじたじ」だったそうである。 IT業界不人気の理由は？ 現役学生が語るそのネガティブイメージ － ＠IT http://ww
ユメのチカラ: ソースコードの読み方（ニコニコ動画(RC2)で公開）
ユメのチカラ インターネットの時代になって、地球規模の知恵の集積が 可能になった。ソフトウェア開発においてもオープンソースソフトウェアのバザール的開発が注目されている。いまおきているその現実を現場の視点から記していきたい。 吉岡 弘隆 - よしおか ひろたか 日本OSS推進フォーラム ステアリングコミッティ委員 OSDL Board of Directorsを歴任 カーネル読書会主宰 2000年6月、ミラクル・リナックスの創業に参加。 95年～98年、米国OracleにてOracle RDBMSの開発をおこなっていた。 98年にNetscapeのソースコード公開(Mozilla)に衝撃をうけ、オープンソースの世界に飛びこみ、ついには会社も立ち上げてしまう。 2008年6月取締役CTOを退任し一プログラマとなった。
ユメのチカラ: ソフトウェアの作り方を考える
「開発工程を別々に担当してはいけない」は思いのほか多数のブックマークを頂いた。コメントやブックマークを拝見しながらあれやこれや考えた。わたしの飛躍する思考というか雑な議論で辟易している方もいらっしゃるかとは思うがもう少しお付き合いいただければ幸いである。 わたしの経験は、このブログの読者の皆さんはご存知かもしれないが、ソフトウェア製品の開発経験に偏っている。米国系ハードウェアベンダーでコンパイラやRDBMS製品を開発していた。その後西海岸のソフトウェアベンダーに転職してそこでRDBMS製品の開発に従事した。そしてOSSの可能性を信じてミラクル・リナックスの設立に参加したのが約7年前である。顧客向けアプリケーション、例えば社内システム構築（人事、財務、購買などなど）の経験はない。 さて先の「開発工程を別々に担当してはいけない」ではいろいろな論点をごった煮風に突っ込んだものだから分かりにくくな
ユメのチカラ: 開発工程を別々に担当してはいけない
古典的なウォータフォールモデルでは、ソフトウェア開発を要求仕様分析、概要設計、詳細設計、実装(コーディング)、内部テスト、統合テスト、運用、保守みたいな工程にわけ、通常は各工程を別々の人が担当するというような方法がよくおこなわれている。 特に、要求仕様の分析、概要設計などは上流工程などとよばれていて、詳細設計、実装とは別の人ないしは組織が担当する。実装とかテストは下流工程などとよばれている。 よくあるパターンとしては元請けが上流工程を、下請け、孫請けが実装やテストなどを担当し、人月単価も下流の方が安い。 ウォーターフォールモデルでは各工程毎に成果物(仕様書や各種ドキュメント、プログラム)が大量に生産される。各フェーズ毎に定義された成果物がそろってから次のフェーズに移行するというのが建前なので、各フェーズでのドキュメントはどうしても冗長になりがちである。 一度固定した文書は次のフェーズで変更
ユメのチカラ: プログラマの基礎体力
そもそも、プログラマの基礎体力ってなんだろう。学校でアルゴリズムの基礎を習うとか、プログラミング言語を習うとか、あるいはコンピュータの基礎を習うとかそういうことなのだろうか。 断片的な情報を獲得するのなら確かにインターネットや書籍でどうにかなる。しかし、職業プログラマとして一目置かれる存在になるための基礎体力ってなんだろう。 高校や大学などでプログラマの基礎体力は身につくのだろうか。 プログラムと言っても、ゲームのプログラムから、顧客の要求に従ったアプリケーションプログラム、組み込み機器の制御プログラム、あるいはOSやら、コンパイラやら、RDBMSやらの基盤ソフトウェアなど様々ある。 わたしの場合、子供の頃、初めてコンピュータに触る機会があって、その時のなにやら得体の知れない興奮みたいなものが結局のところコンピュータ関連の職業につくことになったのだが、知識０から鍛えるべきプログラマの基礎体
ユメのチカラ: プロのプログラマ
プログラマという職業。プログラムを作って給与を得る。が、定義かと思うけど、オープンソースを趣味で作っていてそれで所得を得ていない人は、じゃあ、プロのプログラマと言えないのか。 日本のIT産業のしょぼさは、ソフトウェア開発を人月単価でやりとりするところにあるというのが多くの人の指摘するところである。SIベンダーのエライ人が、学生の「大学では何を勉強すればいいですか」という質問に対して、「弊社では教育システムが完備していますから、大丈夫です」というような頓珍漢な答えをする。大学での専門的な勉強を期待しないということは、単に人を頭数で見ていることに他ならない。 「求人、プログラマ、未経験」を試しにぐーぐるしてみるとぞろぞろある。（求人 プログラマ 未経験 の検索結果 約 1,160,000 件中 1 - 10 件目 (0.08 秒) ） 誰でもできることをやっているとしたら、それはもう単価勝負に
ユメのチカラ: Latencyの隠蔽
プログラマたるものコンピュータの基礎的な知識は必要だと多くの人は言うのだけど、じゃあどこまでが必須でどこまでがオプション（？）なのかというと明確な線引きがあるわけではない。まあ、Kernelとかコンパイラとかをゴニョゴニョする人はCPUのキャッシュがなんたるかくらいは理解していないといろいろ大変かと思う。 時間と空間を交換するというのはコンピュータだけの世界ではない。街のコンビニだって、店頭に並んでいるものはすぐにアクセスできるけど、店頭にないものはすぐにアクセスできないので、在庫量がある一定水準を下回ったら発注のトリガーがかかる。コンビニはその発注サイクルがデパートとかに比べれば異様に多いので、クロックを上げて性能を出すPentium4みたいなものである。発注単位も非常に小さくて、それこそ弁当一個でも平気で発注しちゃうという感じである。在庫をほとんど持たないので、キャッシュミスした時のペ
ユメのチカラ: デバッグ方法論
実践的なデバッグ方法論（デバッグの仕方、事例研究）も強く求められている。デバッガーというツール依存のTipsではなく、ソフトウェアのデバッグというプロセスそのものの形式化である。 人々は誰に教わるでもなく自分のデバッグのスタイルを持っている。自分なりな定石を獲得している。しかしそれを明示化して人に伝えようと試みる人は少ない。伝承がまったく不可能なような議論も少なくない。 わたしはオープンソースの時代こそデバッグの方法論を広く共有できるチャンスに満ちた時代だと考えている。いくつか事例を紹介しつつ解説する。 優れたプログラマは優れたデバッグ方法論を持つ。そのデバッグ方法論をぜひ共有化したい。そのためには情報公開が要である。 デバッグとはプログラムの不具合を修正するプロセスである。テストなどによって発見された何らかの不具合を期待する結果に修正する作業である。テストとデバッグの区別が十分ついていな
ユメのチカラ: 闘うプログラマ
わたしが紹介するまでもなく、「 闘うプログラマー〈上〉」、「 闘うプログラマー〈下〉」はビル・ゲイツの野望を実現すべく雇われた「伝説のプログラマ」デイブ・カトラーのＮＴ開発物語である。 わたしはデイブ・カトラーに会ったことはないがDEC時代にいろいろ伝説は聞いていた。一番、有名な都市伝説は、Windows NT (WNT)というのはVMS (DECのベストセラーマシンVAXのOS)を一文字づつずらした名前にしたというものである。誰かがデイブ・カトラーにその真偽を問うメールをしたところ、今ごろ気がついたのかよ、という返信が来たという。90年代初頭にそのようなメールがでまわっていたような記憶がある。 それはともかく鬼軍曹のような風貌のプロジェクトリーダ率いるＮＴ開発物語はザカリーの筆力もありぐいぐいと人を引きつける。 それは栄光と挫折の物語である。20世紀最後の商用ＯＳ開発物語と言ってもいい。
ユメのチカラ: シリコンバレーの思い出
今から約10年くらいまえにシリコンバレーにいた。米国Oracleのデータベースエンジンの開発部隊にいた。さらにそれを遡ること数年前、米国DECのデータベースの開発部隊、これは東海岸(New Hampshire州Nashua)にあった、で開発していた。 われわれはよく欧米とか言う。欧州の国々の文化と米国の文化を一緒くたに議論したりしがちである。しかし、米国と英国ですら文化的には随分違うし、ドイツ、スペイン、スウェーデンなどなども相当違うのではないかと想像する。 米国ですら、東海岸と西海岸も生活してみて、これが同じ国かというほど違う。東海岸といっぱひとからげに言うのも語弊があるかもしれないが、ニューハンプシャー州の住んでいたところと、西海岸のシリコンバレーでは気候も回りの人々も随分違う。 東海岸の米国DECは典型的な垂直統合型ビジネスモデルで、会社の文化も、西海岸の水平統合型の米国Oracle
ユメのチカラ: LL魂
夏の祭典。LL Spirit (LL魂) に行ってきた。 個人的な感想など。 昨年のLLゴングのパイプ椅子は、おじさんには拷問に近いものがあったが、今年のホールの椅子は適度に座り心地もよく快適であった。実行委員会の皆様、ご苦労様でした(ぺこり)。 和田先生は、あいかわらづお元気そうでなによりだった。ステーブンレビーのハッカーズの話からはじまって(この本はハッカー倫理を知るうえで重要なテキストなのである)、ハッカーズ大辞典などを紹介しつつ、ハードウェアハック(微分機械(？)って何みたいな)のお話など、大変楽しい講演であった。帰宅してから先の2冊を本棚からとりだしパラパラめくったのは言うまでもない。 しかし、オレ様言語の作り方でパネルディスカッションができちゃうほど日本という地域にはオレ様言語をつくっている人がいっぱいいるのね。すげーな、本音できたよ。という感じである。 学校でコンパイラの
ユメのチカラ: 日本Ruby会議2007
行ってきましたよ。Rubyの祭典。日本Ruby会議2007。400以上のRubyistが集まりましたよ。御茶の水に。 2007年6月9日(土)、10日(日)という土日を2日間つぶすという会社員にとっては、それはそれなりに厳しいスケジュールであるが、仕事というよりも、ファンの集いみたいなものだから、這ってでも参加しないといけない。前日飲み過ぎだとしても。 それはともかく、参加記念のRuby会議公式トートバックをもらってうきうき、初日ささださんのRuby 1.9のお話などから聞く。ささださんの開発版(1.9)と卜部さんの安定版(1.8)それぞれのメンテナのお話はコードを書いてメンテナンスする人のご苦労がしのばれた。いろいろ大変なんだろうなあと。青木さんのリファレンス・マニュアルのお話も量的な問題があり、相当大変だというのはよくわかった。JRubyはSunがRubyの実装をするとこうなるよとい
ユメのチカラ: Who wrote 2.6.20? 誰がlinux 2.6.20を書いたのか？
http://lwn.net/Articles/222773/ 先週のカーネル読書会でGreg KHがLinux Kernel開発コミュニティのお話をしていて、その中で開発の量的な側面についていろいろ紹介していた。そのスクリプトを眺めていたら、元ネタは、Jonathan Corbetという人が書いた「Who wrote 2.6.20」というLWNの記事ということをREADMEファイルから発見した。そこで早速Googleしてみた。それが上のリンク。 その記事はざっくり言うと、Linux Kernel 2.6.20を誰が開発し、その人はどこの会社に雇用されているかというのをgit(Linuxのコード管理システム)のログから定量的に解析したものである。 Linuxは多くのボランティアの自発的な貢献によって開発されていると良く言われているが、それがどのくらい正しいのか、そうでないのかを検証している
ユメのチカラ: 若者との会話
びぎねっと主催のオープンソースパーティ2007に参加した。今年は120人を越える参加者ということで、会場がごったがえしていたので、落ち着いて話をすることはなかなか難しかったが、それでも懐しい顔にいっぱいあえて楽しかった。前日はカーネル読書会だったので2日連続で会う人も少なくなかった。特にオープンドリームの皆様には、あ、どーも、とか言う感じであった。 入口近くには、びぎねっと勢が陣どっていて、Linux World Expo3日間の疲れかテンション低くまったりとしていた。 その一人大内さんとお話をする。まだ10代のハッカーである。はりぼてOSの会で、自分OSを作っている若者である。 はりぼてOSの会は、「30日でできる！ OS自作入門」に触発されて自作のOSを作ろうという狂気(誉めています)の集団である。わたしみたいな人間はOSを自作しようなんていう発想にはまったくもってついていけないのであ
アジアのペンギン: VMware上で動作するLinuxの時刻が遅れる
社内向けサービスのテストサーバーは、VMwareServerを利用するようにしています。良いですよね、VMware Server。これほどのソフトウェアが無料で手に入る時代になるとは、ほんの数年前でも考えもしませんでした。 さて、そのVMware Server上でMIRACLE LINUX V4.0を動作させると、ものすごい勢いで時刻が遅れます。そのままで1週間も放置すると、1日程度の遅れは当たり前といった状態です。いくらテスト用サーバーとはいえ、時刻が遅れては使いものにならないため、解決方法を調査しました。 結論としては... Linux kernel 2.6では、時刻はタイマー割り込みをカウントすることで管理されており、その割り込みは1秒間に1000回行われています。仮想化されたバーチャルマシンでは、この速度の割り込みを処理することができず、結果として時刻が送れてしまうそうです。さらに
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
