ユメのチカラ: 楽天テクノロジーカンファレンスに行ってきた。
カーネル読書会番外編ディストリビューション大集合＠楽天テクノロジーカンファレンスに参加するために、楽天に行ってきた。今回はいろいろサプライズ(後述)があって、それはそれで楽しかったんだけど、ちょっと感想かなんかを記す。 勉強会メソッドとして、(1)質問をする、(2)懇親会でいろいろな人と繋りを持つというのがある。 米国でのワークショップなんかだと非常に活発に質疑応答があって、発表そのものより質疑応答の方が重要だったりする。ところが日本の場合は、講師が一方的にしゃべるだけで、質問時間がまったくなかったり、あっても実におざなり。そもそも質問する人もほとんどいなかったりする。 で、わたしは、そーゆーのは面白くないし、活発な議論からクレイジーなアイデアが生まれ、それがブレークスルの源泉になっていると思うので、可能な限り質問をするようにしている。また、そーゆー自由闊達な議論の場というのをこの地に根付
ユメのチカラ: 取締役退任。生涯一プログラマ宣言。
6月30日臨時株主総会において、ミラクル・リナックス株式会社の新取締役として、児玉崇、伊東達雄を選任し、それに続く、取締役会議により、新しい代表取締役として児玉崇を選任した。佐藤武前代表取締役社長は、取締役会長へ、わたしは取締役を退任した。 ここにご報告する。 さて、ここからが本題(？)である。取締役を退任したからといってミラクル・リナックスを辞めるわけではない。今後は経営者という責任ある立場を退き一技術者としてミラクル・リナックスに貢献していく。 2000年6月にミラクル・リナックスを創業以来8年にわたって取締役CTOとしてミラクル・リナックスとともに歩んできたが、取締役というよりも、技術屋としてミラクル・リナックスのV1.0の開発、OSDL (Open Source Development Lab -- The Linux FOundationの前身)への参画、そしてAsianuxプロ
ユメのチカラ: 梅田望夫著「ウェブ時代 ５つの定理」
シリコンバレーという地域の競争力はどこにあるのだろう。あの底抜けの明るさはいったいなんなんだろう。と思う。 梅田望夫の［ウェブ時代 ５つの定理」はシリコンバレーの空気をビジョナリーの言葉によって表現しようと試みている。 梅田にならって、「ウェブ時代 ５つの定理」でYahoo!ブログ検索、Googleブログ検索をしてみた。このブログを書いている時点でYahoo!で318件、Googleで約272件とでた。発売されてから1週間たつかたたないかで約300件ほどの記事が執筆されたということになる。それを梅田はすべて読むという。 毎日毎日自著の感想を何時間もかけてへとへとになりながら読む。読み続ける。それはなぜだろうと思う。 素人が書きなぐった感想をひたすら読みまくる。 リトマス試験紙として、「コンピュータによって社会を変える」という言葉を考えよう。あるいは「コンピュータによって社会を変えたい」とい
ユメのチカラ: 技術セミナー「技術は会社のものではない。みんなのものだ」をYouTubeでも公開しました。
ユメのチカラ インターネットの時代になって、地球規模の知恵の集積が 可能になった。ソフトウェア開発においてもオープンソースソフトウェアのバザール的開発が注目されている。いまおきているその現実を現場の視点から記していきたい。 吉岡 弘隆 - よしおか ひろたか 日本OSS推進フォーラム ステアリングコミッティ委員 OSDL Board of Directorsを歴任 カーネル読書会主宰 2000年6月、ミラクル・リナックスの創業に参加。 95年～98年、米国OracleにてOracle RDBMSの開発をおこなっていた。 98年にNetscapeのソースコード公開(Mozilla)に衝撃をうけ、オープンソースの世界に飛びこみ、ついには会社も立ち上げてしまう。 2008年6月取締役CTOを退任し一プログラマとなった。
ユメのチカラ: 技術は会社のものではない。みんなのものだ。社内セミナーをニコニコ動画(RC2)で公開するまで。
先日、野村総合研究所向けに「技術は会社のものではない。みんなのものだ」というタイトルで社内セミナーをした。 オープンソースにまつわるソフトウェア開発方法論みたいな話である。まあ、中身は日頃わたしのブログをご覧の皆様にはおなじみなお話である。 野村総合研究所(NRI)の社員30人程度の皆様への社内セミナー(注)である。今回一つお願いをした。「講演を後に公開していただく事を前提にお請けします」。 セミナーを職業にしている講師にとってはありえない条件である。しかし、わたしは講演を公開することの経済的な損失というのはないし、むしろ自分の日頃の主張と行動に一貫性を持たせるという意味あいの方が強い。 講演内容を公開しろなどという講師は前代未聞である。大きな企業になればなるほど社内調整というやっかいなものが待っている。一度誰かが先例をつければ次の人はその道をフォローできるが、最初の一歩が困難にみえる。越
ユメのチカラ: さよならNetscape、こんにちはWeb 2.0
Netscapeのサポートがこの2月に終了するというニュースが昨年末に流れた。それを記念(？)して、「さよならNetscape」というイベントが先日開催された。 一時代を築いたブラウザが世を去るというのは感慨深い。 当日、所用があったので参加できないかと思ったが、帰宅途中渋谷で乗換だったので、ふと気が変って、そのままずんずんイベント会場へ行く自分がいた。 なぜ、そこに引き寄せられたのだろう。気がつくとイベント会場にいた。 会場にはお久しぶりの人達がいっぱいいて、神田さんが誰かが作ったブラウザの年表を見ながら90年代のインターネットの事を語っていた。 ビールを飲みながら皆さんのお話を聞く。NetscapeがAOLに買収されて10年後にサポートを終了する。まあ人はいろいろ失敗の理由を言うが、後づけの理屈のような気がする。 次のビールを飲んでいたらマイクがまわってきた。酔いも手伝って、「モジラの
ユメのチカラ: カーネル読書会、初めてのストリーミング中継
第83回カーネル読書会はささださんの「高速なRuby用仮想マシンの開発」というお題であった。Ruby 1.9.0リリース直後ということもあり、ミラクル・リナックスのセミナールームは立ち見の大入り満員であった。 今回のカーネル読書会の目玉はそれにもまして、初めてストリーミング中継を行なったことである。途中、若干中継が途切れることもあったが、概ね音声、映像とも問題なく中継ができたようだ。インターネット経由で参加した人は60人程度いたようである。こちらも満員御礼であった。 びぎねっとの伊藤さんはじめ撮影隊の皆さん、ありがとうございました。 下記のURLにあるPast Clipsをクリックすると録画した中継映像が見られる。 http://ustream.tv/channel/ylug-83th-kernel-reading-party ログインすると同時にチャットもできるので、ささださんのプレゼン
ユメのチカラ: ソースコードの読み方（ニコニコ動画(RC2)で公開）
ユメのチカラ インターネットの時代になって、地球規模の知恵の集積が 可能になった。ソフトウェア開発においてもオープンソースソフトウェアのバザール的開発が注目されている。いまおきているその現実を現場の視点から記していきたい。 吉岡 弘隆 - よしおか ひろたか 日本OSS推進フォーラム ステアリングコミッティ委員 OSDL Board of Directorsを歴任 カーネル読書会主宰 2000年6月、ミラクル・リナックスの創業に参加。 95年～98年、米国OracleにてOracle RDBMSの開発をおこなっていた。 98年にNetscapeのソースコード公開(Mozilla)に衝撃をうけ、オープンソースの世界に飛びこみ、ついには会社も立ち上げてしまう。 2008年6月取締役CTOを退任し一プログラマとなった。
ユメのチカラ: 自分が何をできるか
対案のない批判は単なる床屋談義であり、新橋の飲み屋でやってくれという空気を感じたので、自分のできる事を考えた。 実のところ、新橋の飲み屋で楽しく飲むのは大好きである。飲めば飲むほど饒舌になる。単なるヨッパライのおやじである。ブログなんていうのは所詮世界規模のヨタ話である。閑話休題 まあ、偉い人を批判するのは簡単である。大企業を批判するのも簡単である。あー、すっきりした、という感じである。じゃあ、おまえは、どれだけエライのか。そーゆー感じである。ご説ごもっとも、おっしゃるとおりである。 わたしはコンピュータが好きだ。プログラムを読んだり作ったりすることが好きだ。こーゆー事を書くと、おめー頭おかしいんじゃないか、と思われたりするのだが、昔はそれを口外するのがはばかられた雰囲気があったのかもしれないが、この年になると憶面もなく、そーゆー事を声を大にして言う。別にそーゆーことを声を大にして言っても
ユメのチカラ: 開発工程を別々に担当してはいけない
古典的なウォータフォールモデルでは、ソフトウェア開発を要求仕様分析、概要設計、詳細設計、実装(コーディング)、内部テスト、統合テスト、運用、保守みたいな工程にわけ、通常は各工程を別々の人が担当するというような方法がよくおこなわれている。 特に、要求仕様の分析、概要設計などは上流工程などとよばれていて、詳細設計、実装とは別の人ないしは組織が担当する。実装とかテストは下流工程などとよばれている。 よくあるパターンとしては元請けが上流工程を、下請け、孫請けが実装やテストなどを担当し、人月単価も下流の方が安い。 ウォーターフォールモデルでは各工程毎に成果物(仕様書や各種ドキュメント、プログラム)が大量に生産される。各フェーズ毎に定義された成果物がそろってから次のフェーズに移行するというのが建前なので、各フェーズでのドキュメントはどうしても冗長になりがちである。 一度固定した文書は次のフェーズで変更
ユメのチカラ: プログラマの仕事はプログラムを読むことである
ソフトウェア開発コストのほとんどは保守のコストだと言われている。各種統計がそれを示しているわけだけど、自分の実感とも合う。 古典的なウォータフォールモデルでは保守というのが意識されないか、あっても一番下流なので、その重要性に対する認識が非常に薄い。 保守という言葉は若干大げさな響きを持つが、プログラムの不具合の修正や、ちょっとした機能変更、機能追加などなど、運用していけば、つまりそのソフトウェアが利用されていれば必ず必要なものである。保守されていないソフトウェアは早晩利用されなくなるか、既に利用されていないかである。 Unixの哲学を持ち出すまでもなく、優れたプログラマはプログラムを書くのではなく、再利用する。いかにしてプログラムを書く機会を減らすか虎視眈々としている。可能な限り再利用して、どうしても書かざるを得ない場合はリサイクルをしちゃったりする。（プログラマにとってのReduce/R
ユメのチカラ: シリコンバレーの思い出
今から約10年くらいまえにシリコンバレーにいた。米国Oracleのデータベースエンジンの開発部隊にいた。さらにそれを遡ること数年前、米国DECのデータベースの開発部隊、これは東海岸(New Hampshire州Nashua)にあった、で開発していた。 われわれはよく欧米とか言う。欧州の国々の文化と米国の文化を一緒くたに議論したりしがちである。しかし、米国と英国ですら文化的には随分違うし、ドイツ、スペイン、スウェーデンなどなども相当違うのではないかと想像する。 米国ですら、東海岸と西海岸も生活してみて、これが同じ国かというほど違う。東海岸といっぱひとからげに言うのも語弊があるかもしれないが、ニューハンプシャー州の住んでいたところと、西海岸のシリコンバレーでは気候も回りの人々も随分違う。 東海岸の米国DECは典型的な垂直統合型ビジネスモデルで、会社の文化も、西海岸の水平統合型の米国Oracle
ユメのチカラ: The C Programming Language
プログラミング言語Cの教科書の定番と言えば、カーニハンとリッチーによるものが有名だ。K&Rと呼ばれていて、今だにそれを推薦する人もあとをたたない。 わたしの本棚にも2nd editionがある。黄ばんだ表紙の奥付を見ると95/8/12とメモしてある。渡米してすぐリファレンスとして購入したものだ。 プログラミング言語の入門書で最初の例がなにがなんでもhello, worldというもの、K&Rからの悪しき慣習である。 プログラミングの初心者が、プログラムをどう書くかという事を習う教科書として使うにはいただけない。いただけない理由は多分いくつもあるかと思うのだけど、プロフェッショナルから見てもいただけない記述がいっぱいある。 例えば if (c >= '0' && c <= '9') ... とかいうイディオムとか、 c - '0' なんていうイディオムがいたるところ(？)にでてくるのであるが、
ユメのチカラ: テストカバレージ
先日Ottawa Linux Symposiumに論文のproposalがとおったという話を書いたが、論文を鋭意執筆中である。今回crackerjackというリグレッションテストのフレームワークをうちの若手のkyagiさんがばりばり作ったのであるが、それから呼ぶbtraxというカバレージ測定ツールがこれまた凄い。これは日立の藤原さんというハッカーが実装したのだけどなかなか金銭ではなく琴線に触れるツールである。 ハッカーのバイブル、IA-32 Intel Architecture Software Developer's Manual, Volume 3: System Programming Guideの15章はおなじみのDebugging and Performance Monitoringである。わたしもhardmeterを実装する時は読みに読んだ。マニュアルがボロボロになるまで読んだ
ユメのチカラ: リグレッションテスト
プログラムを変更した際、予想外の影響があらわれる事があり、それをリグレッションあるいはディグレードと呼ぶ。そのようなリグレッションを発見する事を目的に作られたテストがリグレッションテストである。 リグレッションテストのコンセプトは非常に単純なのであるがその効果は絶大であり商用ソフトウェアの開発現場では日常的に利用されている。しかしながらOSSの世界では必ずしも利用されているとは限らない。Linuxについて言えば公式のリグレッションテストというのは残念ながら存在しない。バザールモデルの特徴である多くの目玉によってピアレビュー、テスト、運用によって問題点が発見される。 Linuxの場合、何か新機能を追加したいと思った人は、LKML (Linux Kernel Mailing List)にRFC(Request for Comments)という提案をメールし議論を開始する。多くのカーネルハッカー
ユメのチカラ: MySQLのマルチコアスケーラビリティとLinux
スラッシュドットの情報。FreeBSDとLinuxでsysbench(MySQLを利用している)の結果が出ている。結論から言うと8コアのAMD64のマシンでスレッド数を上げていくと8スレッドまではLinuxでの性能が良かったが、それ以上になるとがたっと性能が劣化して、FreeBSDのSMPngの実装が勝つ。 下記を参照してほしい。 http://jeffr-tech.livejournal.com/6268.html MySQL 5.0.2xではSMPスケーラビリティに問題があることは、われわれの性能評価でもあきらかになっていたが、(例：MySQLに対応した評価ツールDBT-1を利用したハードリソース変更によるパフォーマンスへの影響の考察を参照)、OSのSMPスケーラビリティ問題というよりMySQLの実装上の問題だと考えていた。 linux 2.6.18/2.6.20.1上でMySQL 5
ユメのチカラ: Linux World Expo/Tokyo基調講演「OSS進化論」
Linux Worldで基調講演をする。いまだにプレゼンテーション資料が出来上がっていない。（とほほ） 下記のようなお話をするつもりだ。ひょっとしたらがらっと変えるかもしれないけれど、コメントやトラックバック頂ければ嬉しいです。 OSSが登場して8年、Linuxが登場して15年。GNUプロジェクトから約20年。 何が変わって何が変わらないのか。次の10年の解決すべき課題は何なのか？ GNUプロジェクトが発足した当時、インターネットはまだ一般的ではなかった。GNUの成果を入手するには配布手数料をFSFに送金して配布用テープ、そう当時はテープでソフトウェアは配布されていた、を入手するしかなかった。CD-ROMすら一般的ではなかった。 LinuxがNetnewsで話題になっているころ、インターネットは学者、研究者のおもちゃであった。世界中にftpサイトはできつつあったが、インターネットにアクセス
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
