Netscapeがすごい会社だった頃の話（1996年前後）。 - 未来のいつか/hyoshiokの日記
夏休みなので、たまたま読んでいたCoders at Work プログラミングの技をめぐる探求という本の中にJamie Zawinskiのインタビューが載っていた。この本は著名なプロラグマを集めたインタビュー集で、Unixを創ったKen ThompsonやらDonald Knuthやらすごい人たちが登場している。 その中でJamie Zawinskiはそれほど著名でもなければ誰もが使っているすごいシステムを開発したというわけでもない。私が彼の名前を知ったのはNetscapeのソースコード公開時にMozilla.orgを仕切っていた頃なので、20年近く前である。 彼はxemacsの開発者としても著名で、当時GNU Emacsではなくてxemacsを日常的に使っていたので馴染みにある名前だった。xemacsとGNU Emacsはのちにマージされるのだけど前者が今で言う所のバザール型開発で、後者が
日本IBMの売上推移 2012-04-08 - 未来のいつか/hyoshiokの日記
先日、日本IBMの社長交代のニュースがあって、それを聞いて驚いたのが、社長が日本人ではなくなるということではなく、この10年で売上が半分近くに下がったという業績であった。*1 わたしの世代ではIBMという企業はコンピュータ業界の超エクセレントカンパニーで仰ぎ見る遠い存在、憧れの存在でいわばロックスターである。コンピュータ興亡史でいえば、IBMが先頭にいて、DECがそれを追撃するもかなわず、Sunが80年代華々しくデビューして、90年代一世を風靡する。90年代にはいると時代はMicrosoftとIntelが支配していた。90年代前半に巨像IBMは泥沼に足をすくわれもがき苦しむが、ガースナーによって復活する。メインフレーム・ハードウェアを主軸とした事業構造から、ハードウェア、ソフトウェア製品、サービスという3本柱に見事に転換させた。 若い人達には実感がないかもしれないが、GoogleやFace
ロートルの嘆き、アジャイル開発って何 - 未来のいつか/hyoshiokの日記
20数年前に大学を卒業しプログラマになって、この変化のとっても早い業界でまだ禄を得ている。最近でこそコードを書くことはないが（今でも職業としてコードを書きたいと強く思っている）、それでも、ソフトウェア開発について20数年前に得た知識、経験、スキルが役に立っているように思える。 日進月歩で日々新しいバズワードが登場し、若い人たちはそれをフォローするのにひーひー言っている。クラウドだアジャイル開発だなんだかんだ。 プログラマの一日は、会社に来て、テストを書いて、テストをして、不具合があればコードを修正し、またテストをして、問題がなければコード管理システムにチェックインする。その作業を淡々と日々こなす。この日常の流れというのは、使う道具立てこそ変わったとしても、基本的に変化がないように思える。コードを書くのは20数年前も今もプログラマだし、テストを書くのもそうだし、テストを自動化することは20数
TOMOYO Linuxに学ぶ説得術 - 未来のいつか/hyoshiokの日記
昨日、TOMOYO Linuxメインライン化記念合同勉強会（カーネル読書会、セキュアOSユーザ会、まっちゃ445）に行ってきて、小崎さんが匿名掲示板でガチでレビューしていたお話を聞いたので、早速過去ログを読んでみた。http://tomoyo.sourceforge.jp/2ch/thread-2.txt （追記：2009/7/4 21:03 なぜか後半部分、アスキーアートの後が切れてしまったので、前半部分を若干カットして（略）の部分、その２を追加しました。） LKML (Linux Kernel Mailing List)というのはLinuxカーネルの技術的なことを議論するもっとも権威（？）あるメーリングリストで、ここで議論され合意されたものがLinuxの本体に取り込まれることになる。このLinuxの本家本元の本体（くどいな）のことをメインラインと呼ぶ。Linuxを創ったLinusさんに
Debug Hacks - 未来のいつか/hyoshiokの日記
4月下旬にオライリージャパンから「DEBUG HACKS――デバッグを極めるテクニック＆ツール」を出版する。http://www.oreilly.co.jp/books/9784873114040/ ミラクル・リナックス株式会社の精鋭エンジニアたちが、長年のLinuxカーネル開発の経験で培ったデバッグテクニックを詳解。こころがまえから、準備、必要な知識、バグの原因をすばやく特定し修正するために便利なテクニックとツール、高度なデバッグ技まで惜しみなく披露します。多くの事例に基づいた実際的実用的な技が満載です。効率良くかつクオリティーの高い開発のために必須の一冊です。 オライリーのページから目次を見ていただければわかるが、アプリケーションからカーネルのデバッグまで幅広く、記述している。デバッグに関する書籍が、あんまりなかったので、ミラクル・リナックスのエンジニアと約10ヶ月にわたって喧々諤々議
オープンイノベーションとオープンソース 2009-01-03 - 未来のいつか/hyoshiokの日記
オープンイノベーションというのはカリフォルニア大学バークレー校のヘンリー・チェスブロウ教授が提唱した用語である。従来の閉鎖的イノベーションが、企業の研究機関内で研究開発されたのに対し、オープンイノベーションは、社外の知識、研究などを積極的にとりこもうというのが特徴である。垂直統合型研究開発モデルではなく水平分業型研究開発モデルというのが特徴になる。 イノベーションをビジネスにするためにビジネスモデルを必要とするが、オープンイノベーションの場合、ビジネスモデルと対になって議論される。 近年オープンイノベーションというモデルの成功事例としてオープンソースがよくひきあいにだされる。社外にR&Dと価値の源泉を見いだすという意味でオープンソースはオープンイノベーションに他ならない。しかし投資に見合うリターンをどのように確保するかという確固たるビジネスモデルを確立しているとはいいがたい。 Linuxな
2008-09-22 - 未来のいつか/hyoshiokの日記
第90回カーネル読書会(9/16開催)は、やまねさんの「Debian 60分クッキング」だった。 Debianパッケージの作り方を一から教えてくれる。すばらしい。Linux ConferenceのUbuntu+Debian BoF(9/11)の席で急遽、開催が決定したといういわくつき(？)のネタである。 Ubuntu+Debianの作る人というかパッケージをメンテナンスする人を恒常的に募集しているのであるが、ここもオープンソースのプロジェクトの例にもれづ慢性的な人手不足である。 なんとなくとっつきにくいパッケージの作成方法について入門の入門をやって作る人を増やしてみようという魂胆で今回のカーネル読書会は急遽開催の運びとなった。木曜日(9/11)のBoFから火曜日(9/16)のカーネル読書会という日程も月曜日が休日という事を考えると実質一営業日での開催という事になる。 会場をおさえ、YLUG
機械語ではマシンの挙動は理解できない - 未来のいつか/hyoshiokの日記
実のところ機械語はマシンに対する高レベルな挙動を示す命令であって実行を厳密に写像したものではない。（何を言っているんだわたしは？） 「マシン語ってどんな感じか知りたくなった方へ」という大人気のエントリと、ニコニコ動画を見て、昨今の最新マイクロプロセッサでは機械語がもはや機械の挙動と一対一に対応しなくなっちゃったのである、というツッコミをしたくなった。http://d.hatena.ne.jp/shi3z/20070913 「水野拓宏のTK-80講座」これが素敵すぎる。http://www.nicovideo.jp/watch/sm1048903 最近のプロセッサ(Pentium 4とかXeonとか)は機械語を機械が直接実行するのではなく（じゃあ、なんで機械語というだよというツッコミは諸般の事情で却下（ｗ））、機械語をμOPという機械語と一対Nに対応する命令に変換し実行するのである。Java
豆知識/hogehoge-jp - 未来のいつか/hyoshiokの日記
日本のOSSのコミュニティの名前で、本家がhogehogeだとhogehoge-jpという名前にする事が多い。hogehogeの日本支部みたいな感じである。例えばDebian JP Projectなんてのがある。 このjpつーのは何かというと、日本という地域をあらわすコード(ISO 3166)である。 http://www.iso.org/iso/en/prods-services/iso3166ma/02iso-3166-code-lists/list-en1.html 一方、hogehogeという英語のドキュメントを日本語に翻訳したとして、その名前をhogehoge-jaとしたりする。このjaというのは、日本語という言語をあらわすコード(ISO 639)である。http://www.w3.org/WAI/ER/IG/ert/iso639.htm 日本語のドキュメントなのにhogehog
雇用規制は学歴差別を助長するか - 未来のいつか/hyoshiokの日記
2006年4月28日の日経新聞「経済教室」で政策研究大学院大学教授福井秀夫氏が、わが国の厳しい解雇規制について「学歴偏重を助長し、所得階層を固定し、格差を拡大させる」として、その見直しが必要と主張している。(id:roumuya:20060428) 古新聞をひっくり返して連休中に読んでみた。 福井氏のロジックは、 労働者の解雇に関しては、厳しい要件が課されているため、労働者の生産性が低くても使用者は容易に解雇できない。 一定期間、実際に雇用して観察しない限り、労働者の生産性を正確に判定することは困難である。 そのため、例外は多数あるが、確率的に生産性の高いブランド大卒者を重点的に正規雇用することが、使用者にとって合理的な選択となる。 このため、次のような問題を生んでいる。 就職市場での学歴による差別の極端な助長 職を得てしまった生産性の低い正規雇用労働者の極端な保護 そのコストを賄うことに
2006-05-06
あなたのブラウザは①（まるいち）を表示できますか？ Windowsで見ている人は多分表示できる。UnixないしLinuxの人はどうだろうか？ ブラウザの文字コードをEUC-jpにしている人は多分表示できない。なぜか、①（まるいち）がEUC-jpというエンコーディングには入っていないからだ。そんなばかな？Windowsのエンコーディングは通常CP932（シフトJISという人もいる）というが、それには①（まるいち）とか㈱（(株)）とかの文字種を持っているがEUCと呼ばれているエンコーディングにはそのような文字種がないからである。CP932に表現できる文字種を全部EUCで表現してしまえばこの問題は解決するが、いろいろ議論はつきない。 Unicodeで表現すればいいという人もいるが、UnixやLinuxの場合、昔からEUCで運用していたりすると、簡単にUnicodeに諸般の事情で移行できないので、
コミュニティの作り方 - 未来のいつか/hyoshiokの日記
ソフトウェア開発における破壊的技術はバザールモデルによるソフトウェア開発だと思う。単なるソースコードの公開だけではなく、自発的意思を持った多数のプログラマによるコラボレーションによるソフトウェア開発が破壊的である。 バザールになるのかならないのかは多数のプログラマの興味を引きコミュニティが構築できるかどうかにかかっている。多くのOSSはコミュニティの構築までたどり着かない。田舎道の野菜の無人売りみたいなものでお客も売る人もいない状態である。バザールになってお祭り騒ぎになるのはごくごく一部である。関係者（？）というかサクラを集めて人だかりがあるように演出したとしてもなかなか長続きはしない。企業発のOSSがなかなか難しいのは企業の予算が切れたとたん閑古鳥が鳴くという状態で持続しにくい。つまり企業の予算に依存していて、コミュニティが自立していないとそのような状況になってしまう。 コミュニティを支
2006-04-17
パソコンで最もよく利用されているエンコーディングの一つがシフトJISなのだが、その誕生については、なかなかまとまった資料がない。当時の関係者の証言を断片的にまとめたものしかない。 まづ小形さんの以下のBLOGとコメントを読む。当時の当事者が証言をしている。 http://d.hatena.ne.jp/ogwata/20051228/p1 シフトJISを発明したのは誰か？ http://d.hatena.ne.jp/ogwata/20051229/p1 シフトJISを発明したのは誰か？(2) http://d.hatena.ne.jp/ogwata/20051230/p1 「BASIC80を漢字化した経理専用マシン」のこと http://d.hatena.ne.jp/ogwata/20060102/p1 たくさんのコメント、ありがとうございます 安岡さんの日記も参考になる。 http://s
Pugsを読む。:未来のいつか/hyoshiokの日記
Haskellを勉強するためにPugsのソースを読むというのは、Cの勉強をするためにUnixのカーネルの読むようなものだ。いいねいいね、この主客転倒ぶり。*1 Pugsのホームページから、Downloadをクリックして、http://search.cpan.org/dist/Perl6-Pugs/へ。最新コードは下記の最初に公開されたコードに比べてかなり複雑化している。最初に公開された昔のコードは随分シンプルだ。で、１０ファイルしかない。 抽象構文木あたりから行くのがいいのではないだろうか？特に根拠はないけど。 Haskellの文法書(翻訳）。入門書などを参考にする。 *1:Lionsの本(Lions’ Commentary on UNIX (Ascii books))はCのいい教科書でもある。 Cでどのように表現するかという勉強になるしね。
asmlinkageとは - 未来のいつか/hyoshiokの日記
会社でカーネル勉強会を夕方やっていたので、ふらっと参加してみた。エライ人がでると自由な議論ができなくなるとか、若手がやりにくいとかいろいろ言われそうではあるが、楽しそうだから、そーゆー雑音は聞かなかったことにしてお話を聞く。セマフォがどうだとか共有メモリがどうだとかいう話をしていてプロジェクタにはsem.cだかなんだかのソースコードがうつされていたりする。 質疑応答で、「ところで、このasmlinkageってなんですか」というのが出る。ソースコード上、お馴染みなフレーズであるが、まあこんなものだろうということで深くは追求したことがなかった。 疑問はGoogleに聞け。 まづ、「asmlinkageとは」では、所望の回答はみつからない。*1 そこで、「asmlinkageというのは」で、検索したところ、 https://www.codeblog.org/blog/gniibe/2006022
レガシーエンコーディングと標準 - 未来のいつか/hyoshiokの日記
さっそくid:kazamaさんよりトラックバックありがとうございます。（d:id:kazama:20060316:p2） これらの問題については，たとえば以前にも情報交換記述言語調査研究委員会において，MicrosoftやApple Computerなどのベンダや，W3C，Unicode Consortium，国内のJIS漢字コードの委員会などの関係者を集めて議論したことがあるが，結局は次のような結論になってしまった， http://www.y-adagio.com/public/jttc/chrcode_map/chrcode_map.htm ご指摘のとおりde jure標準委員会との調整はおこなっていない。はたしてOSSにおいて従来の権威ある標準設定プロセスというのが有効なのかどうかというのはこれからホットに議論されてもいい分野だと思う。ぜひ、議論したい。 インターネットの世界では、ラ
開発者をどう作るか？ - 未来のいつか/hyoshiokの日記
いろいろ妄想する。OSSの開発者が数人いたらそこそこすごいことができる。そのようなチームが数十あれば定番のOSSのかなりの部分をカバーできる。せいぜい数百人のOSS開発者がいれば世界を変えられる。その数百人をどう育てるか？ 大学教育のソフトウェア演習の一つとしてOSSの開発に参加するというのはどうだ？一クラス数十人としてそのうちの一人でも二人でもOSSに興味を持ってもらうだけでいい。そのようなクラスが全国に数十あれば、年間100人程度のOSS開発者が誕生する。どうだろうか？人数が少なすぎる？ Asia諸国まで場を広げれば年間数千人くらいのOSS開発者をデビューさせることはあながち不可能ではないような気がする。どうだろうか？妄想がすぎるか？ 実現不可能な話ではないように思う。どう実行するかだけのような気がする。 日々是開発:SQS Developmentさん、http://sqs.cmr.s
未来のいつか/hyoshiokの日記 OSSにおける成功したプロジェクトと開発者数
先日Rubyのまつもとさんと話をする機会があったので、Rubyの開発者像について聞いてみた。現在のChangeLogには130人くらいの人の名前が載っているのだけど、実際にごりごりコードを書いていす人はまつもとさんともう一人の方くらいで、あとはちょっとしたパッチを書いて送ってきた人が多数であるらしい。厳密な意味で言うとバザール（多くの人がよってたかって一見無秩序にコードを提供し、優しい独裁者がコードを受け入れる）という感じではないが、ユーザコミュニティや開発者コミュニティ、Rubyを紹介するエバンジェリスト、Rubyでのキラーアプリ(例えばRuby on Rails)、頻繁な継続的なリリースなどなど、成功したOSSであることは間違いない。上に書いた厳密な意味でのバザールなるものがあるとしたらLinuxくらいになってしまうので、ちょっと狭い定義かもしれない。それはともかくRubyのエコシステ
開発者はどこにいるのか？ - 未来のいつか/hyoshiokの日記
FLOSS-JP オープンソース / フリーソフトウェア開発者 オンライン調査日本版 (http://oss.mri.co.jp/floss-jp/)というのが２００３年ごろに行われている。既に２年以上たっているわけだが日本におけるオープンソース／フリーソフトウェア開発者の実情(？)を知る上での基礎的な資料なので引いてみた。わたしのイメージするOSS開発者と調査した三菱総研の比屋根さんや飯尾さんのイメージするOSS開発者とは微妙に異なる可能性はあるが、日本のOSS開発者の実態を調査した唯一（？）のサーベイなので非常に貴重である。 アンケートは合計547人回答を得ている。開発時間をみてみよう。http://oss.mri.co.jp/floss-jp/report.html#Q6 図(Q6) 週平均OSS/FS開発時間 5時間以下が61.7%と大半をしめる。0時間も8.5%である。むむむ？開
未来のいつか/hyoshiokの日記 若者の情報産業離れとオープンソース
日本OSS推進フォーラムのサーバ部会の性能評価のプロジェクトも佳境を迎えつつある。各種ベンチマークデータもそろいプロジェクトメンバーと毎週毎週がしがし議論を重ねている。先日はUN社の16CPUマシンでのスケーラビリティ検証データのレビューなどをプロジェクトメンバとやったが非常に楽しかった。 UN社はメインフレームの老舗U社の子会社ではあるがビジネスはSIとかサービスなので必ずしもOSとかRDBMSそのものに専門性があるというわけではない。PostgreSQLと言えば、各社にもそこそこPostgreSQLのコードを読んだことがある人はいるけど、業界的にはSRAの石井さんが重鎮になっている。石井さんを交えoprofileデータを分析した。 わたしなんかはPostgreSQLに関してはド素人、だけど昔は某社製RDBMSを開発していたから、そこそこ土地鑑はある。 RDBMSの性能があがらないのは、
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
