はじめての Chromium Land - steps to phantasien(2011-02-19)
はじめてまじめに ...といってもたぶん 500 行くらい... WebKit ではなく Chromium 側のコードを書いている. まだレビューをとおってないため現在形. でかすぎてビルドの遅い Chromium より Mac WebKit をいじる方が快適という同僚もいたけれど, コード自体は Chromium の方がだいぶモダンだよなあ. 普通に unit test が書けるありがたさといったらない. Developer testing まず gtest が良くできていて感心する. static initializer を使ってケースの登録を分散化したり, コマンドラインフラグでテストケースを一覧選別できたり, プロセスを分離してクラッシュに強くしたり, クラッシュしたテストケースの backtrace をだしたり. でかい C++ のコードベース相手にテストをスケールするための工夫
近況 - "チームがよくなる" 感じについて - steps to phantasien(2009-12-31)
2009-12-31 近況 プログラマとしての成長が感じられない一年だった. 目先の仕事に気をとられ, 問題についてよく考える時間をとらなかった. 過労を言い訳に勉強もしなかった. 情けない. 一方で仕事のチームでは成長を感じることができた. せっかくだから, "チームがよくなる" 感じについて書いてみたいとおもう. 最近, 私のいるチームはコードレビューをするようになった. 私はこれまで仕事の中でコードレビューを実施しょうと試行錯誤してきたけれど, チームに定着することは少なかった. コードレビューはそれなりに面倒な作業なので, 特に組織的な外圧がないところではさぼられがちだと思う. けれど今のチームは外圧なしでやっている. およそ一年間のプロジェクトを通じ, このチームがコードレビューをするに至った道程を振り返ると, チームが成長する様子をうまく捉えることができるかもしれない. フェー
八割の動詞 - Backnumbers: Steps to Phantasien
PC は忙しい時ほど壊れる. 先週は職場の PC にこの経験則が降りかかった. 頻繁にフリーズしはじめる VisualStudio 2008. VS 単体での修復では問題が直らず困り果て, 結局 OS から入れ直す羽目に. まあディスクが故障しなかっただけ幸いだと思おう... OS の入れ直しは生活習慣を見直し悪習を捨てる機会でもある. 私の Windows 生活で最大の悪習は cygwin だ. ホスト OS への敬意を欠く cygwin には以前から後ろめたさを感じていたが, 惰性でずるずると使い続けていた. 今回のトラブルは良き市民たれという神(シアトル在住)の思し召しかもしれない. 啓示に耳を傾け, しばらく cygwin なしでがんばってみたい. PowerShell cygwin を捨てるということはシェルを乗り換えるということだ. いま Windows 民の間でホットなシェル
steps to phantasien(2008-11-21)
The Decline and Fall of Agile を訳してみました. 例のごとく YukiWiki におかせてもらってます. 最近は短いのしか訳す根性がない... Agile 批判はよくあるけれど, これは割と良い指摘をしている気がした. 耳の痛い部分もある. たしかに日次のスプリントと月次の再計画は割と簡単に導入できて, チームも締まったかんじになる. けれどコードがよくなるわけじゃない. 一方で, この二つの trivial なプラクティスを取り込んだところで, 何かが悪化することはどのくらいあるんだろうか. 元記事の文脈を察するに, もともと重量プロセスがあったところに agile を持ちこみ, upfront の設計や計画がなくなって破綻したという話に思える. 数十人, 数百人のチームでソフトウェアを開発するプロジェクトには, おそらく何らかのプロセス, 秩序があるだろう
設計文書のうまい書き方 steps to phantasien t(2007-09-24)
訳して YukiWiki に置きました. 元は "How to Write an Effective Design Document". 友達が "最近, プロジェクトで設計仕様書を作ろうって話が..." と悩んでいた. そりゃ大変だねえと相槌をうち, 相槌ついでにぐぐっていたらみつけた記事. <design document> や <designdoc> と検索すれば ガイドラインだけでなく実物もじゃんじゃかみつかる. 玉石混交で面白い. 設計仕様書と聞くと, 設計する人と実装する人が異るような大規模開発をまず連想する. そっちの世界で文書が必要なのはわかるが, 一方で私は大規模開発をしたいと思わないし, 興味も湧かない. 元の記事も私の友達もそんな大規模開発を想定していない. 文書化した本人が実装も行う. それでもこの記事からは (訳しておいてなんだけれど) いまいち違和感が拭えない.
プロファイラのしくみ steps to phantasien t(2007-08-23)
UNIX 偏向文書 artu の中で "Measure Before Optimizing" と説く Raymond は, 同時にプロファイラの計測機構 (instrumentation) がもたらすノイズについて注意を促している. 私のプロファイラ信仰に不安が翳を落とす. gprof ノイズはさておき, そもそもプロファイラはどんな仕組みで速度を測っているんだろう. gprof のマニュアル によると, GNU 一族のプロファイラは次のように実装されている: まず "-pg" オプションつきの gcc でソースをコンパイルする. この指示を受けたコンパイラは各関数の冒頭に "mcount" という名前の関数呼出しを加える. リンクする C のランタイムも専用バージョン (gcrt0.o) に差し替わる. このランタイムは裏で profil() 関数を使いタイマを仕掛ける. そのタイマは発
C++ と DI - steps to phantasien t(2007-08-17)
Java と DI (Dependency Injection) の世界から C++ に戻ってくると気が滅入る. すべてがくっついている. ああ... "Working Effectively With Legacy Code" に従ってバリバリと依存を引き剥がすことになるんだけれど, もうウンザリ. せめて新たに書くコードはレガシー風味とさよならしたい. DI したい. C++ にも少しは DI コンテナの実装がある. Autumn Framework とか. ただリフレクションのない C++ では DI コンテナを使う有難味が薄い. Autumn Framework のチュートリアルを見ると無力感に襲われる. 閉じた型システムの再発明. C++ の限界もあるだろうから, あまり責める気は起きない. COM のような既存のオブジェクトシステムに DI を載せることはできるかもしれない.
反政府的 API - Backnumbers: Steps to Phantasien
勤務先のコードを見ていたら DeregisterXxx() という名前のメソッドがあった. そんな英語ないだろ ... とぐぐってみると, LKML のアーカイブがヒット. 投稿者の不満は私と同じだ. カーネルのコードに deregister_xxx () という関数がいくつもあるよ, いいの? という主旨. そうだそうだとスレッドを読み進めた私はある驚くべき事実を知る. Rik van Riel の返信: > "deregister" を使うに至った事情は何かあるんですか? 然り. 我々は反米国のテロリスト集団である. 辞書に無い新たな単語を大量に発明して米国経済を破滅に追いやろう. 連中の辞書産業に追従を許さず, 綴りを学ぶ余力を奪い, 英国との語彙戦争の中で溢れる語彙に沈め彼等の息の根を止めるのだ. なんてこった! (若干誇張あり.) deregister にそんな意図があったとは
TDD のアンチパターン - Backnumbers: Steps to Phantasien
訳した. 元ネタは TDD Anti-Patterns. ネタ元は reddit (だったはず). いつもどおり YukiWiki にお世話になります. 適当に直してやってくださいませ. 内容は思いあたりすぎて節々が痛いです. 解決策とセットになっていないのが悲しいところ. 続編を stay tuned しております. 以下愚痴. 私の中で最近深刻なのは "Excessive Setup". 最初に書いたセットアップコードをついコピペしてしまい, ノイズに加えて重複も増えている. コピペすら面倒がって "Free Ride" してしまうこともよくある. セットアップを再利用するコツがわかっていない弊害だなあ. しばらくコピペを禁じ手にしようか... ネットワークを使う単体(じゃないけど)テストだと, サーバのセットアップと同期する必要があったりで一筋縄じゃいかないんだよなー. "The S
steps to phantasien t(2007-07-06)
昔の同僚が退社してベンチャー仕事をやるという. 門出を祝う宴会に, 昔のよしみで呼んでもらった. ついでに古巣の近況を聞く. ひとつ嬉しい知らせがあった. 以下その自慢話. ある夏, 私は社内ライブラリのチュートリアルを書いた. そのチュートリアルが, 今でも改訂されながら参照されているという. のみならず新人プログラマの研修教材として広くとりいれられつつあるそうだ. 私はとても嬉しくなった. もちろん手柄は改訂を続け, 様々な改善を続けた彼らのものだ. それでもなお私は喜びを隠せない. 自分が去った今も文章だけが生き続けている. 私は平凡なプログラマだから, 自分のコードが生き残れるとは思えない. 一方ボランティアで仕事の合間に書いた文章は読み継がれている. 価値のあるものが生き残るのなら, 私のなした価値は(コードではなく)文書にあったことにある. プログラマとしては悲しいけれど, 会
steps to phantasien t(2007-06-13) - 最近使った boost
仕事で本腰を入れて C++ を使うになり, 久々に boost をさわっている. 以前より色々ライブラリが増えていて嬉しい. 今日は喜びの声をすこし. 普段から boost を使っている人にとっては当たり前の話題だと思います. boost::optional たとえば設定ファイルを扱うコードで, あるかどうかわからないオプションの扱いをを考える. "--log foo.log" と指定されたらログを foo.log に出力し, 何も指定されなければ標準エラー出力に書き出したいというような場合. けっこう悩ましい. よくある方法はこんなかんじ: class foo_config_t { ... bool has_log() const { return m_hash.contains("log"); } std::string logname() const { assert(has_log
steps to phantasien t(2007-06-01) ChangeLog の作法 つづき
Subversion の開発者が ChangeLog について面白い記事を書いている. 記事の要旨はこうだ: ChangeLog (Subversion なので commit log) を書くのは面倒だよ, メーリングリストもあることだし書かなきゃダメ? ってよく訊かれる. 書きましょう. バグトラックもあるけど, 書きましょう.これらのツールは補完しあっている. メーリングリストはノイズが多いし, 変更を特定するには情報が足りない. バグトラックはバグの記録がメインだからコードの話を細々書くのは邪魔になる. 変更については ChangeLog に書くのがいい. プログラマは ChangeLog を読む. 記録を検索して, どの関数に何が起きたかを調べるものだ. この類の記録は ChangeLog を読まないとわからない. 逆に ChangeLog を書く時は, それを特定できるように省略
最近みた TechTalks: Mercurial Project
Mercurial という分散 SCM の紹介. Python 製で, シンプル軽量スケーラブルが売り. 開発を初めたきっかけは linux の BitKeeper 事件だという. (だから GIT がライバルらしい.) OpenSolaris や OLPC など, けっこう採用実績があるのに驚いた. 私は分散 SCM を触ったことがない. SVK をちょっとつついたくらい. 話を聞く限り Mercurial はけっこう良さそう. (スライドは Wiki に公開されている.) 分散はさておき軽量なのがいい. たとえばレポジトリのためにわざわざ svnrepos みたいな別ディレクトリを作る必要がない. 作業コピーの中に .hg ディレクトリができて, ここに履歴が収められる. つまり作業コピーのディレクトリでレポジトリが閉じている. svn だとレポジトリを作るのが面倒でバージョン管理を先
いまどきのデスクトップ処理系 steps to phantasien t(2006-09-22)
いまどきのデスクトップは色々モダンになっている. ただモダン化は API の裏側で進んでいるため, あまり興味を持たれていないらしい. 一見いろいろウォッチしていそうな知り合いと話していてわかった. 利用者視点の話題では, いまどきのデスクトップというとたとえばウィンドウが ヘナヘナ揺れるといったアイ・キャンディばかりが連想される. でもそのアイ・キャンディに至るにはきっと山ほど苦労があったはず. そのへんをちょっとねぎらってみたい. 念頭にあるのは Windows Vista, Mac OSX, XGL あたり. まず共通の階層化されたアーキテクチャを想定し, ケーススタディを交えつつその層を下から上へ順にたどっていきます. 復習: デスクトップ処理系の階層構造 そもそもデスクトップの中味はどんな構成をとっているのか. ざっと眺めておこう. 典型的なデスクトップ処理系のアーキテクチャはだ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
