現在のrunlevelを知る

いまが、シャットダウンなのかリブートなのかを知る方法がないかなと思って調べる。


ずばり、runlevelというコマンドがあるのね。使ったことなかった。
もっとリアルに/procとかでわかるといいのに。
返り値は2つで、前のと現在のを表示する。
前のがNの場合は変更なしってこと。

Design Doc

http://blog.livedoor.jp/heitatta/archives/54439839.html
鵜飼さんの講演にGoogleの社内文書であるDesign Docの話があった。
企画書とか提案書相当のものだろう。

* Google で必ず書くことになっているドキュメント
* プロジェクト立ち上げ時の 1〜2週間をかけて書く。ある程度ポイントが書けたら、もうコーディングへ。
* 一般的にはあんまり長くない。詳細を書かなきゃいけなくなったら、それはまた別プロジェクトになることが多い
* Design Doc の内容
o プロジェクトの背景、目的
o おおまかな設計(コードを見ただけでは判らないような、アーキテクチャ)
o プロジェクトの参加者(このプロジェクトに関して、誰に連絡を取ればいいのか)
o セキュリティやプライバシーについての考察(問題と対処方法)
o テスト、モニタープラン(運用時の考慮。障害の発見と復旧手法など)
o レポジトリ上の位置やサーバのアドレスなど
* コードを書いていると解離していくので、できるだけ解離しないようにアップデート

Google でのソフトウェア開発体制

http://nanto.asablo.jp/blog/2007/04/29/1472377

  • OKR (Objectives and Key Results)
    • 四半期ごとに目標 (長期、短期) を立て、成果を評価する。これが各エンジニア、個別チーム (5 〜 6 人)、会社などさまざまなレベルで行われる。
  • 百聞はデモに如かず
    • 20% ルールでの成果など、とにかくデモを作る。それに対してチーム内外からフィードバックを受けられる。
  • Design Doc
    • 実際のコーディングへ移る前に、Why、How を書いておく。
  • Weekly Snippets
    • 週ごとに今週すること (したことだったかも) を書いておく。
  • 強大なインフラ
  • 何でも共有
  • ソースコードは全エンジニアに共有される。Design Doc、Weekly Snippets など、誰が何をしているのかという情報も共有される。

目標設定と評価がグループ単位で行われるというのは新鮮。
普通の会社ではセクション単位だけど、Googleではメンバは複数のグループにまたがっているから、評価レベルがより細かい。
こういう仕事のやり方をやっていると、自分自身の得意不得意もよくわかりそうだ。

地味なところですが

イオニアSTBの外付けとしてRHDが採用になってます。
http://www.watch.impress.co.jp/av/docs/20070614/catv.htm
http://www.iodata.jp/news/2007/06/07_pr013.htm
某B社外付けで決まっていたのをひっくりかえした格好になります。
もっと他でも使ってくれないかしらん。

白木印付属のコンソールケーブルがすごい件

http://www.gfi.co.jp/25ji_download/nama/nama_construction_guide_20070608.pdf
30個だから、マジでこれが付いてくるんだろうな...
秋月キットを組んだものかな。
あ、ケーブルは自分で用意しろってことなのか(^^;。


つーか、MACアドレスを自分で設定させちゃダメなんじゃないか?


ifdefに"CONFIG_ARCH_IODATA_UGR"なんて文字が見えるんだけど...