昼間に外を歩いていたら、すごく良い梅の花の香りがしました。おやっ？と思って周囲を見回すと、綺麗な梅の花が！


from overlast using Panasonic DMC-FX100

そういえば、梅の花をこんなに至近距離で見たのは小学校の時以来。

以下の記事を読んだら、一回も読んだ事のないアルゴリズムの講義資料が2つ紹介してあったのでメモ。

無料で全文をダウンロードして内容を確認できるので気楽。

《続きを読む》

今日は朝早く起きて調べもの。その後朝食を食べて、直後に寝落ちして、3時間睡眠。

昼も調べものをした後、おしるこを作って食べ、週末の買い物を済ませたら夕方。

夕方は、かなり山盛りなラーメンを作って食べた。

夜の20時頃から調べもの作業に集中でき始めたので調べものが終わった。

家を見回すとぐっちゃぐちゃ。整頓しなきゃ。整頓が終わったら、多分もう23時ですよ。

来月は今月よりも生活の質を向上しよう。。。

集中力。もっと、あったらいいなぁ。

ちょっと調べるだけで、自分の集中力の波を今よりも押さえつつ高くキープできるに越したことはないと思ったので、「集中力」というクエリでGoogle検索をして、上から文書を読みました。あと他にもちょろちょろと。

「体調を整えたり制御したりして集中力を高めよう」系の記事は根拠が不明なものが散見されたので取り上げないことにしました。

《続きを読む》

今日も5時に飛び起きたんだけど、寝ぼけながら「あっ、買わなきゃいけない本があったんだ」と思いついてしまい20分くらい無駄にしてしまった。


from overlast using Panasonic DMC-FX100

朝の目覚めがもっとスッキリするようにしたいな。

ワインバーグ関連の本をコツコツ読んでいます。今日から「スーパーエンジニアへの道」を読みます。

スーパーエンジニアへの道 - 技術リーダーシップの人間学

[Amazonで詳細を見る]

以下は、第一章の「リーダーシップとは、結局のところ何なのか」の読書メモです。

この章は「人間が完全に理解不能な複雑な状況を許容し、変化を恐れず柔軟に行動しよう」ということを述べています。

たぶん、一回読んだことがある人しか分からないメモになっていると思います。

《続きを読む》

Perlのワンライナーは超便利ですが、今日は「-i」を使いまくり。

「-i」はパッケージを落としてきたら、パッケージ内の複数のソースコード中に書き換えなきゃなおらないバグを見つけてしまった、みたいなときに便利。

ヘルプの「-i」オプションに関する説明には「file in place」というフレーズがあるけど、これは「file existingand ready to be used」という意味です。ロングマン英英辞典に書いてありました。そんな意味でplaceを使ったことなかったです。

それはさておき、こんな感じで「-i」を使うと、処理結果の出力先が入力元ファイルになります。

入力元ファイルにはワイルドカードも使えるので、カレントディレクトリのcファイルを全て入力に使うなら「./*.c」と書けば良いです。

さらに以下のように「-i」オプションの引数に文字列を与えると、その文字列を入力元ファイル名の末尾につけたファイル名でバックアップをとり、その後で入力ファイルを処理します。



この例だと、なんとか.bakファイルができあがって、入力元ファイルには処理内容が適用されます。

Perl便利だなぁ。

関連商品

初めてのPerl 第5版

[Amazonで詳細を見る]

昨日22時に寝落ちしてしまったので3時半に目覚めました。ちょっと早すぎますがすっきり起きたので良いことにします。

今日も早めに寝るぞ。

ワインバーグ本を順番に読んでいます。今は「ライトついてますか」の読書メモをつけています。

ライト、ついてますか - 問題発見の人間学

[Amazonで詳細を見る]

以下、第6部の20「ある特務」に関するメモです。

この節は「自分が内面的に納得できる解き方を選び、問題に関する調査を怠らず、最初からベストを尽くすこと。ただし解答には副作用がともなうものなので、注意をはらうこと。」ということが書いてあります。

一回読んだことがないと何を書いてあるのか分からないと思います。

《続きを読む》

はるか昔[2007-05-05-3]に、Googleの技術講演会でソフトウェア開発体制について講演されたことに言及しました。そのときはDesign Docが結局どんな感じなのか、は分かってませんでした。今回は、Design Docってどんな感じなのかを調べてみます。また、今後長期にわたり自分用テンプレを書いて、育てていこうと思います。

いろいろ調べてみると数千人規模のエンジニアを抱える企業において「開発速度の低下や手戻りによる無駄」や「エンジニアが開発以外の作業に時間を使いすぎること」を防いだりするための一つの解決策としてDesign Docは機能しているのではないかと思いました。

Design Docは、ある程度詳細に書けばプロジェクトが管理不能に陥らないギリギリのラインの情報量を詰め込めるので、様々な用途に同時に対処できるのが良い気がします。

Design Docを読む必要に迫られる従業員が全員一定水準以上のコードを書ける状況を実現できる大企業は少ない気がしますけど、実現できるなら問題なさそうです。

参考資料

- 鵜飼文敏さんの講演「ハッカーのソフトウェアエンジニアリング」：ITpro
-- http://itpro.nikkeibp.co.jp/article/Watcher/20070924/282781/

- WebKit Web Socket design doc
-- http://docs.google.com/View?id=dfm7gfvg_0fpjg22gh

- Google の Design Doc について - フリーフォーム フリークアウト
-- http://d.hatena.ne.jp/cou929_la/20091116/1258373100

- Googleのdesign docを眺めてみる - kenmazのはてな
-- http://d.hatena.ne.jp/kenmaz/20090712/1247401684

- へ～たのめも:Google のソフトウェア・エンジニアリング
-- http://blog.livedoor.jp/heitatta/archives/54439839.html

Design Doc って？

- Googleのエンジニアがソフトウエアを開発する際に必ず書くドキュメント。
- アイディアが出たら書く。
- プロジェクト立ち上げ時に1、2週間かけて書く。
- あるソフトウエアについて，何を・なぜ・どのように作るかを端的に記す。
- 長く、または、詳細を書く必要があるときは、別のプロジェクトを立ち上げるとき。

どこまで書けたら実装をはじめるの？

だいたい背景、目的、インターフェイス、が書けたら実装に着手して良いようだ。
何かの作成に取り組むことを、プロジェクトと呼んでいるのかな。ともかくプロジェクトの進行方向とゴールが明確になるように書く。
他方、Docに処理のフローを自然言語で書くのは大切なようだ。

既存の公開されているDesign Docを元にしたテンプレ

参考文献を組み合わせて全部入りのテンプレを書いてみる。用途に合わせていらない項目を削ったり、項目を前後にずらしたり、新しい項目を挿入したりする。

テンプレ

[＊＊＊]のような部分は、中のメッセージに従い書きかえる。

 ** [プロジェクトのタイトル。例：作成するライブラリの名前は？]

 ** プロジェクトの目的
[何を実現するの？]

 ** プロジェクトの背景
[どんな背景があるから実現するの？]

 ** ハイレベルアーキテクチャ
[コードだけでは分からない作成物のアーキテクチャを画像などで]

 ** プロジェクトの参加者
[連絡先が大切。誰が参加するのかを明らかにしよう]

 ** 仕様（とくに従うべき仕様がなければ飛ばす）
 *** 実装する仕様
[事前に仕様が決まっていたら]

 *** 既存のものとの相違点
[既存のものと何が違うのか、比較対象の仕様があれば言えるだろう。]

 *** 関連する仕様
[関連する仕様があれば]

 ** 各クラスの概要
[各クラスの概要を書く。]

 ** 実装
 *** インターフェイス
[各クラスのインターフェイスの概要。hファイルや、javadocやpod形式かな。関数や構造体を定義するコードとコメント。]

 *** 処理フロー
[「どのように処理をおこなうか」を各関数内の処理フローを上記で説明したインターフェイスに基づき、自然言語で詳細に書く]

 *** 作成物の使用例
[おもにサンプルコード]

 ** セキュリティやプライバシーについての考察
[考えられる問題と、それに対する対処方法]

 ** 既知でオープンな問題
[事前にわかっている様々な課題]

 ** テスト計画、モニタープラン
[思いついたテストを思いついただけ書く]
[テストケースの記述]
[運用時の考慮。障害の発見方法や、復旧方法など]

 ** 参考文献
[参考文献を書く]

 ** レポジトリ
[サーバのアドレスや位置]

 ** Docの編集の履歴
[編集日、編集者、何をしたのか、の3つ組を書く]

気をつけるポイント

- いらない項目は削除。詳細だけど無駄がないようにする。
- コードを書いていくと、コードとDocが解離していく。
-- できるだけ解離しないようにアップデートする

気づいたこと

- Design Docは、全く謎な新しいことをするときに、見えないものを手探りで作るのではなく、機械的にゴールを生成するためのフォーマット。
- 実装する前に最適なものを作りにくいような書類を極力作らずに、かつ「ドキュメント = ソース」にならないようにする工夫。
- 参考文献を眺めていると、きっちり押さえなければいけない部分以外はかなり自由に項目を作っているみたい。Design Docは論文などに近いなと感じた。
- 作るべきものの形が見えると、作業者は着手したときにやる気がでるし、作業者の上司や同僚は安心感を得られるのでは。

関連リンク

あとで追加する。

友人が次々に「確率と計算」を購入しています。僕は当面読みませんが、そのうち読む日がくると思うのでメモ。

確率と計算 ―乱択アルゴリズムと確率的解析

[Amazonで詳細を見る]

原著どれだろう？と思って調べたら、コレでした。

Probability and Computing: Randomized Algorithms and Probabilistic Analysis

[Amazonで詳細を見る]

中身とは関係ありませんけど、原著の方が表紙が可愛い気がします。和訳版は渋いですね。

今朝は起きれたけど、ちょっと貧血気味。おまけに自宅に忘れ物しちゃった。


from overlast using Panasonic DMC-FX100

日の出は大体6:00くらいかな。6:30ちょっと前が一番綺麗。

今日はあまり夜更かししないでサッサと寝よう。

追記：22:00に寝落ちしちゃいました。

ワインバーグ本を順番に読んでいます。今は「ライトついてますか」の読書メモをつけています。

ライト、ついてますか - 問題発見の人間学

[Amazonで詳細を見る]

以下、第6部の19「政治には忍耐が必要」に関するメモです。

この節は大変短く、メモを見れば大体何が書いてあるかわかると思いますけど、一回読んだことがないと何を書いてあるのか分からないと思います。

読書メモ。

- 自分の努力に対する、自分の力の及ばない空間で行われる他人のサボりから免れられる者はいない。
-- 自分の努力の結果は、他人にとっての真の問題の解答とは限らないから

- 他人の問題を解く際の、問題定義に関する教訓第2番
-- あとから調べてみれば、本当に問題を解いて欲しかった人は、そんなにいないものだ。

---

あああ。耳が痛いです。

今日は5時の目覚ましで起きあがって、一気やるとを消化。それにしても、昨日より風が強ので体感温度が昨日より低い気がします。

ただ体調は万全ではなく、9時頃から急激に眠くなりました。今日はあまり無理をしないで生活します。

今年も年賀はがきの当選番号をチェックする日がきました。

いつもどおり、たつをさんのとこで番号のチェック法をゲット。

- [を] 年賀はがきの当選番号 2010
-- http://chalow.net/2010-01-25-6.html

なる。

さて手元の年賀状を調べたら、なんと今年は切手シートが当たりました！！
やった！！

関連リンク

- 当せん番号｜お年玉賞品のご案内｜郵便年賀.jp
http://yubin-nenga.jp/otoshidama/number.html

確定申告の季節ですね。2009年度の確定申告は2010年3月15日（月）まで。

今年もきちんとと申告します。

多少、気が重いですが、まずは1月末までに経費に回せるレシートを月ごとに分類します。余裕があれば日付ごとに整頓しておきます。

書類は会計ソフトを使うと毎年アップデート代がかかってイライラするので、今年はExcelで頑張ってみようと思います。2月前半に書類作成終わるといいな。

関連商品

【2009-2010年度版】図解 フリーランスのための超簡単!青色申告

[Amazonで詳細を見る]

フリーランスを代表して 申告と節税について教わってきました。

[Amazonで詳細を見る]

関連リンク

- 国税庁 平成21年分 確定申告特集
-- http://www.nta.go.jp/tetsuzuki/shinkoku/shotoku/tokushu/index.htm

echizen_tm さんが ポメラ DM20 を買ったので見せていただいた。ついでに僕のポメラ DM10 とも比較。その差に驚いた。


from overlast using Panasonic DMC-FX100

もう、全然ちがう！DM10 完敗。

《続きを読む》

今朝は、いつもどおり5時に起きました。でも、ちょっと疲れがとれていなかったので、6時半まで2度寝しました。


from overlast using Panasonic DMC-FX100

何にしろ起きてからエンジンがかかるまでに、だいたい2時間くらいかかるので今日はちょっとスロースタートかな。1日が短そう。。。

追記：今日は一日が短かったです。終わるの早過ぎ。

ワインバーグ本を順番に読んでいます。今は「ライトついてますか」の読書メモをつけています。

ライト、ついてますか - 問題発見の人間学

[Amazonで詳細を見る]

以下、第6部の18「トム・タイヤレスのおもちゃいじり」に関するメモです。

この節は「問題を解決するには問題が何かを知ることだ。他人の問題を解決する際に、相手はこちらが問題を一旦解くまで何が欲しいか分からない、ことを念頭におこう」ということが書いてあります。

一回読んだことがないと何を書いてあるのか分からないと思います。

読書メモ。

- 問題とは
-- 人が望むところと、物事がどうなって見えるかの差

- 問題を抱えていることを認識することと、問題が何かを理解することは全く別
- 前者は感じ方の程度の話。後者は問題解決能力の話。

- 問題が何なのかを分かることが重要
- 問題を解決・解消すること
-- 問題が何かが分かってしまえば、取るに足らない作業なのだ

- 我々が真の問題を解いていないとしても、それを我々が解きたいと思うことで、それは真の問題となる
-- 例：駄目なものに捕まって、駄目なものをせめて活用しようとするとき

- 我々の道徳的な権利：「ほかの連中にされたように、ほかの連中にもしてやれ」

- 人が他人に伝えられないこと
-- 自分が知らないこと
-- 自分が知りたいとは思わないこと

- 他人の問題を解く際の、問題定義に関する教訓第一番
-- ちょっと見たところ違って人々は、くれといったものを出してやるまでは何が欲しかったか知らぬものである
# ということは、結果を1手ずつ出すのは大変有効ですね

---

この章を読んで、もっと早く読みなおしていればよかったなぁ、と大後悔しました。

渋谷のパルコで開催中の、MOE 絵本フェスティバルに行ってきました。


from overlast using Panasonic DMC-FX100

会場内にも、僕ですら名前を見たことのある有名作家さんの原画が展示されていました。@jugoya さんが好きなダヤンの原画がたっぷり展示されていましたよ。

僕はポニョの美術監督の吉田 昇さんがMOEの本誌に掲載するために書き下ろした絵本「ポニョがやってきた海辺の町」の原画をながめていました。1時間くらい眺めていましたが、全然見飽きませんでしたよ。幸せなひとときでした。

関連商品

MOE (モエ) 2010年 02月号

[Amazonで詳細を見る]

関連リンク

- MOE web[2008年9月号]
-- http://www.moe-web.jp/magazine/mo0809.html

- MOE絵本フェスティバル ｜ 白泉社
-- http://www.moe-web.jp/moefes/index.html