コアテクの路地: 作業ログの取り方
このブログをご覧のみなさんは、おそらく何らかの形で開発作業、あるいは設定作業の経験をお持ちだと思います。みなさんは、日々の作業の記録をどのように取られているでしょうか?もし、作業ログを取る習慣がない、あるいは忙しすぎて作業ログをとることに気が回っていないのであれば、作業ログを確実に取る習慣をつけることをお奨めします。この習慣は、きっとあなたの作業の信頼性を上げ、作業効率向上に貢献するはずです。 ●作業ログがなぜ必要か まず最初に、なぜ正確な作業ログをとる必要があるのでしょうか? その答えは簡単です。再現性を確保するためです。自分が不具合報告を受ける立場で考えてみてください。もし、部下やユーザから「動きません」や「バグです」という報告を受けた場合、すぐに問題があると判断するでしょうか? ほとんどの人は、まず報告されている状況を正確に理解したうえで判断したいと考えるのではないでしょうか? ●作
ユメのチカラ: 取締役退任。生涯一プログラマ宣言。
6月30日臨時株主総会において、ミラクル・リナックス株式会社の新取締役として、児玉崇、伊東達雄を選任し、それに続く、取締役会議により、新しい代表取締役として児玉崇を選任した。佐藤武前代表取締役社長は、取締役会長へ、わたしは取締役を退任した。 ここにご報告する。 さて、ここからが本題(？)である。取締役を退任したからといってミラクル・リナックスを辞めるわけではない。今後は経営者という責任ある立場を退き一技術者としてミラクル・リナックスに貢献していく。 2000年6月にミラクル・リナックスを創業以来8年にわたって取締役CTOとしてミラクル・リナックスとともに歩んできたが、取締役というよりも、技術屋としてミラクル・リナックスのV1.0の開発、OSDL (Open Source Development Lab -- The Linux FOundationの前身)への参画、そしてAsianuxプロ
ユメのチカラ: 勉強会のこと
ここのブログの読者の皆様にはご存知のこととは思うが、ほそぼそとカーネル読書会という名の宴会、もとい、勉強会みたいなものをやっている。 最近特に思うのだが、東京界隈ではそれこそ毎日のようにあちらこちらで勉強会など開催されている。定期的な開催もあれば不定期な開催もある。カーネル読書会のようなゆるゆるな運営もあれば、きちんとした運営のもと何百人もあつめるカンファレンス形式のものもある。 まあ、感覚的には結構頻繁にいろいろやっているよねと思っていたのだが、下記のIT勉強会カレンダーを見てほしい。 https://www.google.com/calendar/embed?src=fvijvohm91uifvd9hratehf65k%40group.calendar.google.com 本当に毎日毎日いろいろな勉強会をやっている。このカレンダーは、はなずきんさん(http://d.hatena.n
ユメのチカラ: YAPC::Asia 2007
Yet Another Perl Conference at Asia (YAPC::Asia) に参加した。 技術系カンファレンスというのは何のためにあるのか考えるいいきっかけになる。 なぜ、技術系カンファレンスに時間を作ってもいかねばならないのか。楽しいから、新しい技術を勉強、ネットワーキング、旧友にあう、有名人のサインをもらう、オライリーの新刊を立ち読みする、初対面の人となかよくなる、技術的な議論をする、気分転換、カーネル読書会の宣伝、技術系カンファレンスの運営について学ぶ、ついでにリクルーティングなどなど。 参加者はざっとみて400人弱くらいか。Shibuya Perl Mongersの人達が主体となってボランティで運営開催されている手作りのカンファレンスである。Ruby会議やPHPカンファレンス、LLなどと規模や運営方法が似ている。Linux World Expoのような企業によ
ユメのチカラ: Rubyで習作の性能評価
うひょ〜。大変なことになった。手習いで書いた初めてのRubyプログラムが大御所によってたかって添削指導をうけている。 確かに突っ込みどころ満載のゆるゆるのコードなので、弊社のrubistからの突っ込みくらいは想定していたが、まつもとさんや弾さんの登場までは想定外であった。多くの皆様のコメントに感謝したい。 実装についても、ArrayやらHashやらSetやらいろいろあった。そこで、ちょっと性能評価をしてみた。 具体的には time ruby -rprofile でruby自前のプロファイルをとってみた。 Array#includeはコストが高い。実行時間が21秒〜24秒くらいとなっていて、そのうち12秒〜13秒をArray#includeで消費している。 表の見方なのであるが、コストのかかっている処理のトップ3を表示した。左から、全体から比率、累積実行時間(秒)、実行時間(秒)、呼び出し回
ユメのチカラ: 大規模ソフトウェアをgdbを利用して微視的視点から理解をする
たまたま講読している php-dev というPHPの実装を日本語で議論するメーリングリストで「mbstring の新関数」というスレッドがあった。新規にmb_list_encodings_alias_names()という関数を追加したらしいのだが、既存のmb_list_encodings()とどう違うのかどうかという議論がわきおこっている。 ここでは、mb_list_encodings()を題材にどうやってphpの実装を理解していくか、そのプロセスを記述してみたい。もちろんこの方法がベストであるとか、この方法でなければいけないとか、いつでもこの方法が適用可能だなんてことを主張するつもりは一切ないが、一つの例として大規模ソフトウェアの微視的理解方法を理解いただきたい。 1) mb_list_encodingsがどこで利用されているかを知る。 $ cd /usr/src/php-5.1.4 $
ユメのチカラ: hyoshiok 2.0
技術がまったくわかっていない上司と最先端の技術をやすやすと使いこなす部下という凸凹コンビによる最強のチームワークが日本のお家芸みたいなもので、部下は部下で、「ったく、上は全然わかっちゃね〜」といい、上司は上司で、「近頃の若いやつは」と言う。デスマーチだなんだといいつつも、どーにかこーにか物はできあがって予定調和の世界である。この上司という人、技術はわかっていないフリをするのだが実はそんなことは百もお見通しで、プロジェクトを成功させるのは技術(だけ)ではなくて、人だということをしっかり理解している。部下に「ったく、しょーがねーなぁ」とぶつぶつ言わせるのはモチベーションをキープさせるための巧みな作戦で、部下はその作戦にまんまとのかっちゃっているのである。上司は技術はわからないが人は見ているのである。 そうすると、上司部下の凸凹コンビで、上司のパターンを技術力、人間力で分類すると4つになる。すな
ユメのチカラ: 日本語文字コードのお話
レガシーエンコーディングプロジェクトというのをやっていて昨日その検収があった。 開発そのものは一段落したのだが、まだ、事務処理が残っているので、全て完了というわけではない。 プロジェクトの背景として、Unicodeによるオープンソースソフトウェアの国際化が普及した結果として、日本語処理にいろいろな問題(文字化け)が発生したというのがある。奇妙に聞こえるかもしれない。Unicodeというのはソフトウェアの国際化のためにやっているのではないか？ソフトウェアが国際化すれば文字化けは解消するのではないか？話が逆じゃないのか？という疑問があるだろう。ところがだ、Unicodeによって解決した問題ももちろんあるがそれによって生じた問題もある。 例えば、日本語を表現する文字のエンコーディングとして、シフトJIS、日本語EUC、JISコードなど複数あるが、それぞれのコード変換で文字化けする場合がある。ある
ユメのチカラ: なぜソースコードを読むのか？
遥か昔に下記のようなものを書いた。1999年当時私はオラクルの開発部隊に所属していた。1998年に米国ネットスケープがそのコードをオープンソース化し、世間ではいったいオープンソースとは何かということが良く知られていなかった頃の話だ。当時の様子がよくわかるので再録する。ちょっと長くなるが読んでほしい。 日経ソフトウエア1999年9月号、77ページ 掲載 よしおか ひろたか Eric S. Raymondは、「The Cathedral and the Bazaar」という有名な論文で、フリー・ソフトウエア(後にオープン・ソース・ソフトウエアと呼ばれるようになる)がどのように開発されていくか、そして発展していくのか、一般の人々にもわかりやすい形で解説した。従来型の大規模ソフトウエアの開発を「Cathedral(大聖堂)」型開発、オープン・ソースの考え方に基づいた開発を「Bazaar(市場)」型
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
