タグ

ブックマーク / blog.miraclelinux.com (15)

  • ユメのチカラ: 取締役退任。生涯一プログラマ宣言。

    6月30日臨時株主総会において、ミラクル・リナックス株式会社の新取締役として、児玉崇、伊東達雄を選任し、それに続く、取締役会議により、新しい代表取締役として児玉崇を選任した。佐藤武前代表取締役社長は、取締役会長へ、わたしは取締役を退任した。 ここにご報告する。 さて、ここからが題(?)である。取締役を退任したからといってミラクル・リナックスを辞めるわけではない。今後は経営者という責任ある立場を退き一技術者としてミラクル・リナックスに貢献していく。 2000年6月にミラクル・リナックスを創業以来8年にわたって取締役CTOとしてミラクル・リナックスとともに歩んできたが、取締役というよりも、技術屋としてミラクル・リナックスのV1.0の開発、OSDL (Open Source Development Lab -- The Linux FOundationの前身)への参画、そしてAsianuxプロ

    takatoshiono
    takatoshiono 2008/07/01
    カッコいい!
  • ユメのチカラ: 勉強会のこと

    ここのブログの読者の皆様にはご存知のこととは思うが、ほそぼそとカーネル読書会という名の宴会、もとい、勉強会みたいなものをやっている。 最近特に思うのだが、東京界隈ではそれこそ毎日のようにあちらこちらで勉強会など開催されている。定期的な開催もあれば不定期な開催もある。カーネル読書会のようなゆるゆるな運営もあれば、きちんとした運営のもと何百人もあつめるカンファレンス形式のものもある。 まあ、感覚的には結構頻繁にいろいろやっているよねと思っていたのだが、下記のIT勉強会カレンダーを見てほしい。 https://www.google.com/calendar/embed?src=fvijvohm91uifvd9hratehf65k%40group.calendar.google.com 当に毎日毎日いろいろな勉強会をやっている。このカレンダーは、はなずきんさん(http://d.hatena.n

  • ユメのチカラ: ちょっとした勇気と行動力(オフ会編)

    プログラマがプログラマとして楽しく生きるちょっとしたコツ。 プログラマがプログラマとして楽しく生きるには、ちょっとした勇気と行動力が必要だ。別にプログラマだけじゃなくて、営業だって、マーケだって、誰だって、それは必要だと思うのだけど、まあ、それはそれ。 例えば、Perlの最新動向を知りたくて、どっかの勉強会に出たとする。この時点で、すでに勉強会に出るという「ちょっとした勇気と行動力」を発揮している。素晴しい。その前向きな姿勢は、何もしないでモンモンとしているより何十倍も素晴しい。 さらに、懇親会(まあ、普通の宴会だと思えばいい)にも出てしまおう。知り合いを見つけて、やあやあやあとっちゃべる、というのも良いが、それはほどほどにして、最低限一人でも初対面の人と知りあいになろう。初対面の人に自己紹介するというのも最初はドキドキするものであるが、それもちょっとした勇気と行動力でのりきろう。社会人

  • ユメのチカラ: 自分が何をできるか

    対案のない批判は単なる床屋談義であり、新橋の飲み屋でやってくれという空気を感じたので、自分のできる事を考えた。 実のところ、新橋の飲み屋で楽しく飲むのは大好きである。飲めば飲むほど饒舌になる。単なるヨッパライのおやじである。ブログなんていうのは所詮世界規模のヨタ話である。閑話休題 まあ、偉い人を批判するのは簡単である。大企業を批判するのも簡単である。あー、すっきりした、という感じである。じゃあ、おまえは、どれだけエライのか。そーゆー感じである。ご説ごもっとも、おっしゃるとおりである。 わたしはコンピュータが好きだ。プログラムを読んだり作ったりすることが好きだ。こーゆー事を書くと、おめー頭おかしいんじゃないか、と思われたりするのだが、昔はそれを口外するのがはばかられた雰囲気があったのかもしれないが、この年になると憶面もなく、そーゆー事を声を大にして言う。別にそーゆーことを声を大にして言っても

  • ユメのチカラ: 若い人に人気のない産業は減衰する

    未来をイメージできない産業に人は集まらない。IT産業は人がすべてである。魅力のない産業は減衰する。 IPAフォーラム2007 【討論会】 「学生から見たIT産業」と「IT産業から見た学生」 ~IT産業は学生からの人気を回復できるか~ http://www.ipa.go.jp/event/ipaforum2007/program/discussion.html#tou-1 参加者がすごい。業界の重鎮。岡晋氏(TIS株式会社 代表取締役社長)、浜口友一氏(社団法人情報サービス産業協会 会長、株式会社NTTデータ 取締役相談役)、藤原武平太氏(IPA 理事長)。 当日、このパネルディスカッションに参加していないので、下記の報道で様子を窺うしかないのであるが、「業界の重鎮もたじたじ」だったそうである。 IT業界不人気の理由は? 現役学生が語るそのネガティブイメージ - @IT http://ww

  • ユメのチカラ: 開発工程を別々に担当してはいけない

    古典的なウォータフォールモデルでは、ソフトウェア開発を要求仕様分析、概要設計、詳細設計、実装(コーディング)、内部テスト、統合テスト、運用、保守みたいな工程にわけ、通常は各工程を別々の人が担当するというような方法がよくおこなわれている。 特に、要求仕様の分析、概要設計などは上流工程などとよばれていて、詳細設計、実装とは別の人ないしは組織が担当する。実装とかテストは下流工程などとよばれている。 よくあるパターンとしては元請けが上流工程を、下請け、孫請けが実装やテストなどを担当し、人月単価も下流の方が安い。 ウォーターフォールモデルでは各工程毎に成果物(仕様書や各種ドキュメント、プログラム)が大量に生産される。各フェーズ毎に定義された成果物がそろってから次のフェーズに移行するというのが建前なので、各フェーズでのドキュメントはどうしても冗長になりがちである。 一度固定した文書は次のフェーズで変更

  • ユメのチカラ: プログラマの仕事はプログラムを読むことである

    ソフトウェア開発コストのほとんどは保守のコストだと言われている。各種統計がそれを示しているわけだけど、自分の実感とも合う。 古典的なウォータフォールモデルでは保守というのが意識されないか、あっても一番下流なので、その重要性に対する認識が非常に薄い。 保守という言葉は若干大げさな響きを持つが、プログラムの不具合の修正や、ちょっとした機能変更、機能追加などなど、運用していけば、つまりそのソフトウェアが利用されていれば必ず必要なものである。保守されていないソフトウェアは早晩利用されなくなるか、既に利用されていないかである。 Unixの哲学を持ち出すまでもなく、優れたプログラマはプログラムを書くのではなく、再利用する。いかにしてプログラムを書く機会を減らすか虎視眈々としている。可能な限り再利用して、どうしても書かざるを得ない場合はリサイクルをしちゃったりする。(プログラマにとってのReduce/R

  • ユメのチカラ: メモリアクセスは遅い

    多くのプログラマにとってメモリアクセスの速度を気しなければならない状況というのはめったに無いが、OS、ライブラリ、コンパイラ、RDBMSなどの実装をする時には意識をしなければならない場合がある。 IA-32 Intel Architecture Optimization Reference Manual (order number 248966) をひもとくと6章にOptimizing Cache Usageというのがある。 マイクロベンマークの定番 lmbench http://www.bitmover.com/lmbench/ では、一次キャッシュ(L1)や二次キャッシュ(L2)を測定してくれる。例えば、わたしが利用しているノートだと、L1が1.776nsでL2が5.3490ns、メインメモリアクセスが139.4nsである。 Memory latencies in nanosecond

  • ユメのチカラ: 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

  • ユメのチカラ: 若者との会話

    びぎねっと主催のオープンソースパーティ2007に参加した。今年は120人を越える参加者ということで、会場がごったがえしていたので、落ち着いて話をすることはなかなか難しかったが、それでも懐しい顔にいっぱいあえて楽しかった。前日はカーネル読書会だったので2日連続で会う人も少なくなかった。特にオープンドリームの皆様には、あ、どーも、とか言う感じであった。 入口近くには、びぎねっと勢が陣どっていて、Linux World Expo3日間の疲れかテンション低くまったりとしていた。 その一人大内さんとお話をする。まだ10代のハッカーである。はりぼてOSの会で、自分OSを作っている若者である。 はりぼてOSの会は、「30日でできる! OS自作入門」に触発されて自作のOSを作ろうという狂気(誉めています)の集団である。わたしみたいな人間はOSを自作しようなんていう発想にはまったくもってついていけないのであ

    takatoshiono
    takatoshiono 2007/06/05
    リストを作る
  • ユメのチカラ: 勝手に性能評価(Lingr編)

    週末にLingrを利用したチャットイベントがあったそうだ。[JTPA] Lingrイベントの顛末/My Life Between Silicon Valley and Japan昨日のオンラインサロンは、参加者が集まるにつれてLingrが重くなってしまって残念ながら中止となりました。実のところLingrの実装がどうなっているかは全く知らないのだが、何百人もわらわら集まってチャットをやろうという心意気が楽しい。素晴しい。やってみてスケールしなかったというのも主催者側は若干凹むかもしれないが、それもいい経験で、むしろそーゆー得難い経験を得られたと考えた方がいい。 Lingrの開発者の江島さんは、梅田さんのブログで再挑戦を表明しているので楽しみにしたい。 さて、今回の経験から江島さんら実装者の皆さんは何を学んだのだろうか?ぜひ情報公開をしてほしいと思うのだが、わたしだったらどうするか勝手に記して

  • ユメのチカラ: 大規模ソフトウェアの効率的な理解

    大規模ソフトウェアの開発が大企業によって行なわれていた太古の時代、新人はそのプロジェクトに配属されるや膨大なドキュメントを渡され、とにもかくにもそれを読むことを要求された。わからないことは隣の先輩に聞いて覚えた。失敗はどやされるが、それがいい経験になって少しずつ大規模ソフトウェアの全貌を理解していった。すぐそばにその大規模ソフトウェアを作った人がいるから細かいところも突っ込んでわかるまで聞くと言うことができた。大規模ではあるが秩序だった管理システムがあり見通しは悪くなかった。ある意味牧歌的な時代であった。変化もそれほど激しくなかった。 一方OSSの場合、一人のコア開発者がこつこつ自分の興味の赴くままその核となる部分を開発する。ある程度、機能もそろったところで、アルファ版みたいなものを公開する。サイズもそれほど大きくない。ソースコードもまだごちゃごちゃしていないので、構造を理解することはそれ

    takatoshiono
    takatoshiono 2006/08/02
    確かに隣に聞く人がいるって言うのはすごく安心感があるな
  • ユメのチカラ: デバッグの話(昔の日記から)

    わたしは、90年代にシリコンバレーにいたとき、シリコンバレー日記と言うものを書いていてWebで公開していた。今そのサイトはないのであるが、インターネットのWebアーカイブにその内容が残っている。先日「プロセスプログラミングの実践方法」というエントリでデバッグの話を書いたので、それつながりということで、当時、記した日記を全文転載し、ちょっと長くなるが後書き的な解説を加えたい。文体が微妙に違うがご愛嬌と言うことでご勘弁願いたい。 転載始まりデバッグ 誰もが使っている言葉なんだけど,実のところよく分からない言葉というのがある.少なくとも,なんとなくの定義はあるのだけど厳密な全員が納得できるような定義があるようでない言葉というのがある. デバッグというのも実はわかったようでいてよく分からない.とりあえづ,デバッグというのはプログラムのバグを直す作業だとしよう.そうするとプログラムのバグとは何か?と

  • ユメのチカラ: プロセスプログラミングの実践方法

    学ぶ方法を学ぶことは重要だ。知識は陳腐化する。しかし、学ぶ方法というのは、道具立てが変わってもかなり安定的で変化は少ない。 インターネットのおかげで確かに知識の取得方法は劇的に変化した。量的な変化が質的な変化に転換した。なんでもかんでもインターネットで検索してからことをはじめるという感じになってしまった。あんまりじっくり考える機会がなくなったような気がしないでもない。 かつてプロセスプログラミングと言う概念が流行った。最近ではあんまり言わないがソフトウェア開発の究極の姿だと言われた。ソフトウェアは人が作るのだが(当たり前だけど)、そのプロセスを厳密に記述していければ、つまりコンピュータが理解可能なくらい精密に記述できれば、ソフトウェア作製も自動化できるのではないかというアイデアである。随分荒唐無稽なことを言うとあなたは思うかもしれないがあながち夢物語ではない。 例えば、ソフトウェア開発では

    takatoshiono
    takatoshiono 2006/07/23
    を保存する
  • ユメのチカラ: OSS時代の人材育成

    Unisys BITSでパネルディスカッションをした。メンバーは旧知のテックスタイルCEO、岡田さん、日HP、宇佐美さん、IPA、OSSセンター長、田代さん、主催者側からはユニアデックスの松隈さん、そしてわたし。 ユニアデックスはユニシスグループの中ではサポート部隊という位置付けでメインフレームビジネスが主なビジネスモデルである。そのような会社がLinuxやOSSをどのように位置付けるかと言うのがパネルの裏のテーマである。 パネルの中で人材育成というのが議論になった。 従来のメインフレームベンダは、ハードウェア、OS、ミドルウェア、アプリケーション、SIなどすべて自社で請け負う。典型的な垂直統合型ビジネスである。 それがオープンシステムの時代になって、プロセッサはインテル、OSはマイクロソフト、RDBMSはオラクルなど、それぞれのコンポーネントがそれぞれの分野のトップシェアのベンダが担う

    takatoshiono
    takatoshiono 2006/06/17
    外に目を向ける
  • 1