第三のペンギン: Debug Hacks Conference 2009
syoshidaです。 今日(4/25)くらいから、一般書店にDEBUG HACKSが並ぶと聞いています。 先日のDebug Hacks Conference 2009で発表した際の 私のプレゼン資料を公開します。 DebugHacksHacks.xulをダウンロード 今回は初めて、高橋メソッド(高橋メソッドなプレゼンツール in XUL リターンズ)で作ってみました。 #基本的(リターンズ無しでも十分)な機能しか使ってませんが。 高橋メソッドは、やはり短めのライトニングトーク的なプレゼンを作るのに 向いてますね。 カンファレンスのご感想、ご意見、皆さんのDEBUGネタ等あればこちらや、 吉岡のblogにコメントやトラックバック頂けるとありがたいです。 私も、カンファレンス直後からblog等に書かれているのを見つけては楽しんでいます。 好意的な評判が多く、ありがたいです。 また、カンファレ
ユメのチカラ: 勉強会のこと
ここのブログの読者の皆様にはご存知のこととは思うが、ほそぼそとカーネル読書会という名の宴会、もとい、勉強会みたいなものをやっている。 最近特に思うのだが、東京界隈ではそれこそ毎日のようにあちらこちらで勉強会など開催されている。定期的な開催もあれば不定期な開催もある。カーネル読書会のようなゆるゆるな運営もあれば、きちんとした運営のもと何百人もあつめるカンファレンス形式のものもある。 まあ、感覚的には結構頻繁にいろいろやっているよねと思っていたのだが、下記のIT勉強会カレンダーを見てほしい。 https://www.google.com/calendar/embed?src=fvijvohm91uifvd9hratehf65k%40group.calendar.google.com 本当に毎日毎日いろいろな勉強会をやっている。このカレンダーは、はなずきんさん(http://d.hatena.n
ユメのチカラ: ソースコードの読み方
ソフトウェア工学の標準的なカリキュラムにソースコードの読み方というのがあるのかないのか知らないが、プログラマとして最も重要な資質の一つにコードの読解力というのがある。 ついでに言えば、大学や専門学校であまり教えられているとはいえないけど、実践では常に必要とされているものとして、テストの方法論、デバッグの方法論、性能向上の方法論、メモリなど各種資源の削減方法論などなどがある。国際化、移植性なども重要な単元であるがソフトウェア工学の中で教授されていると言う話はあまり聞かない。コードのハック一般についてどこかで議論されているのだろうか。経団連あたりで議論しているのだろうか？ 閑話休題。 ソースコードの読み方ということで、最近では「コード・リーディング」というそのものずばりの教科書も出ているので状況は好転しつつある。コードの読み方はオープンソースの時代になり、間違いなく広く情報を共有できるようにな
ユメのチカラ: オープンソースソフトウェアの本当の使い方
リナックスアカデミーの濱野賢一朗さんと日立の鈴木友峰さんの新書である。献本ありがとうございます。 鈴木さんとは、日本OSS推進フォーラムのワーキンググループなどでいつもお世話になっていて、IPAでやったOSSの評価プロジェクトなどではご一緒させてもらったりした。 本書も単なるOSSの解説だけではなく、IPAのOSS評価プロジェクトで得られた知見などをおりこみ類書にない特徴をだしている。(第4章など) 第5章で「OSSの課題」にふれているが、OSSミドルの発展はリナックスのようにはいかないだろうとしている。リナックスの開発の多くが最近はハードウェアベンダなどに勤務するOSの専門家によってなされているというのはよく知られているが、OSSミドルにはそのようなメカニズムがはたらきにくい。例えば、データベース管理システムの専門家はOracleのような専業ベンダーに多数いるが、彼らがOSSのデータベー
ユメのチカラ: ムーアの法則を理解すること（その２）
アーキテクチャの設計寿命でもふれたが、Alpha AXPのアーキテクチャの設計ゴールは下記のとおりであった。 http://blog.miraclelinux.com/yume/2007/02/post_e9f1.html 1. 高性能 2. 寿命が長い事 3. VMSとUnixが動くこと 4. VAXおよびMIPSからの容易なマイグレーション １と２については達成されたと考えていいだろう。３および４はDECが当時おかれていた状況から考えてまっとうな設計要求である。しかし、このゴールはDECという会社が消失してしまった以上達成はかなわなかった。 高性能のアーキテクチャを設計することは緻密なエンジニアリングを行っていれば、（もちろん簡単ではないが）達成不可能ではない。むしろ容易な範疇にある。 本当に難しいゴールと言うのは、マーケットに求められているものをタイムリーに提供し市
ユメのチカラ: どうでもいいプチ蘊蓄、i18nの話
読者の皆様、これはブックマークだ。 baccus-dのブログを見ていたらi18nのお話が出ていたので、i18nの起源というプチ蘊蓄を語る。 この起源についての質問はインターネットでも時々間欠温泉のようにわきあがるいわばFAQみたいなものなのだが、90年代初頭にはつかわれていたとかいう証言がえられるが、なかなか起源まで行きつくものは少ない。 これはずばり85年頃のDEC (Digital Equipument Corporation) (後にコンパックに買収され、その後コンパックはHPに買収された)にScherpenhuizenという人がいて、彼のマシン(VMS/DECNET)名にS12Nという名前をつけていた。当時のVMS/DECNETはノード名の制限が6文字だった。なんでS12NかというとScherpenhuizenという名前は最初のSから最後のnまでに12文字あるからである。 この長い
ユメのチカラ: マルチプロセッサ向けソフトウェアパラダイムとは？
年末に会社の机を整理して、(席替えがきっかけだったのだけど)、読もうとおもってコピーしていた論文なんかを書類置きの下の方から発掘した。一度スタックにつまれてしまうと時々ゴミ集め(GC -- Garbage Collection)して整理しないと二度と発見されない。 半年ぶりにこんにちはの論文たちよ。その一つに"Ideas on improving Linux infrastructure for performance on multi-core platforms", Maxim Alt というのがある。 最初の会社に入社したのは20年以上前の話で、その頃わたしは、「ムーアの法則」などという言葉を知らなかったが、その会社は間違いなく「ムーアの法則」という事を正しく理解している会社であった。VAXというミニコンで一時代を築いた会社で、PDP-11という16ビットコンピュータのベストセラーマ
ユメのチカラ: コードを読むな、理解しろ
コードを読まないで理解するというと何やら心眼で読めとかテレパシーを使えとか、そーゆー荒唐無稽な方向に走れという事ではなく大局的に理解しましょうという話である。 カーネル読書会のネタで今回はmallocのお話だったのだが、そこでRubyのささださんがいらっしゃっていて、GC(ごみ集め)と記憶域管理の関係について熱い議論が沸騰し、その後いろいろブログなどでフォローされていたりする。 わたしもRubyでmallocやGCがどう実装されているか興味があったのでoprofileで実行プロファイルをとってみたりした。日頃利用しているノートPCでRubyのテストプログラム(test/runner.rb)を実行してoprofileしたのは先日ブログに書いたとおりである。 「それとわたしのノートPCではキャッシュミスを測定できないので、Xeonのマシンでキャッシュミスを測定すると面白いと思った。GCの時ぼろ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
