なぜ私はVMWareでGentooを動かすのに3日もかかったのか 2

Posted by kenchan 2009-02-19 22:23:00

1週間ほど前の話ですが、WindowsホストのVMWareにGentooを入れようとチャレンジしたのですが、HDDから起動するまでに3日もかかってしまったのです。

それはなぜか。

インストール時はHDDが/dev/hdaだったのに、いざ起動したら/dev/sdaだったから。

これって、こういうものなんですか?

gentooのインストールはオフィシャルマニュアルのままで、カーネルのマニュアルビルド、genkernel、マニュアルビルドと、3回もインストールするはめになりました><

一度目は、起動したらkernel panicになったのでビルドに失敗したのかと思い、今度はgenkernelでビルドしてみました。それでもkernel panicになってしまい、よく見ると/dev/sdaというログがでていたので、grubで/dev/sdaからbootするように書き換えたら動くではないですか。

というわけで、何とかブートはしたんですが、portageの仕組みとか全然わからんで死にそうです。

 

次回「なぜ私はrailsを動かすのに1週間もかかったのか」(嘘)(だといいな)

EclipSKY200902

Posted by kenchan 2009-02-15 23:43:00

今回はよういちろうさんをお迎えして、OSDEを題材にプラグインのコードリーディングの進め方や、OSDEの開発で苦労した点などをお話していただきました。

ざっくりととったメモを貼り付けるだけの簡単なまとめにしておきます。

  • 国内のSNS事情
    • PCは、mixi一人勝ち
    • 携帯は若干異なる
    • 国内ではgooホームが最初のOpenSocial対応になる
  • OpenSocial
    • アプリケーションの広報活動をSNSに移譲できる!
    • mixiアプリとmixiコネクト
      • mixi年賀状はRestで郵政省とmixiをバックエンドで繋いでいた
    • 登記簿をおくればSandboxがつかえる
    • まったく他人の情報を使うことは出来ない?
      • SNSのポリシーによって異なる
      • ポリシーを取得するAPIも当然ある
        • このSNSではどこまで情報が取得できるか
  • OpenSocial開発者

      • Socialグラフがないとだめ(友人が必要)
      • sandboxが提供されていないといけない
      • アプリケーションのコードを置くサーバが必要
      • キャッシュが邪魔になる
    • このへんの問題を解決するために開発したのがOSDE
  • Plugin開発Tips
    • Actionではなく、Commandを使おう
      • 竹添本も修正が入ってる
    • 外部プロセスの起動
      • JavaアプリケーションならRunの中に作るのがいい
      • DebugUIで起動すると、コンソールビューが割り当てられるのでおすすめ
      • 但し、DebugUIはスレッドセーフじゃないんじゃない予感
      • H2 -> Shindigと連続起動するとClassPathが壊れているという例外
      • どうやって起動完了を確認するか
        • 出力から起動完了メッセージを拾う
        • 何秒か待つ
        • タイムアウトを設定してポートをスキャンする
    • エディタを含むマルチページエディタ
      • StructuredTextEditorでは、ソースタブがクリックされたイベントが通知されない
      • エディタに米をつけるのは、durtyフラグを自分で制御する
      • EditorInputを実装するのが後で楽になるのでは
      • マニフェストエディタはソース読むのがきつい
    • EclipseForms
      • SWTっぽくないUIコンポーネント
      • 左側の変更で右側の表示項目が変更されるような場合に有効

 

因みに、噂によると次回はAQUBIさんによるAIR GREAでのデバッグ機能実装についてらしいですよ!

バレンタイン

Posted by kenchan 2009-02-14 23:07:00

妻から手作りシュークリーム。うまかった!ドメインに合わせたのかどうかは不明。

 

デブサミ2日目

Posted by kenchan 2009-02-14 22:19:00

2日目は、セッション2つを聞いて、デブサミふりかえりのお手伝いをしてました。

アート・オブ・アジャイル デベロップメント

木下将軍もとい、ダークナイトのセッション。

会場で先行発売していたアート・オブ・アジャイル デベロップメント ―組織を成功に導くエクストリームプログラミングの中から、テストと顧客のビジネス、価値についてのお話。

  • アジャイル開発で重要なのは続けること
  • アジャイルとテスト
    • ディベロッパーテスト
      • ペアプロで効率が落ちるのはナビゲータがサボってるから
      • Think->Red->Green->Refactor
      • 5行以下で実現可能かThinkするのがナビゲータ
      • ピンポンペアリング
        • Think->Redの時点で交代
    • QAテスト
      • プラクティス「バグなし」ができないなら必要

アーキテクトってなんですか

マイクロソフト認定アーキテクトを取得した際の経験から、アーキテクトとは何なのか、PMとは何が違うのか、そのあたりをお酒っぽい何かを呑みながら熱く語ってらっしゃいました。

  • アーキテクトの仕事
    • 何でも
    • 技術的な責任を持つ人
  • アーキテクトとPM
    • アーキテクトは父
      • システムとビジネスをつなぐ
      • 先頭を走る
      • 技術で引っ張る
    • PMは母
      • お金
      • 裏方でどっしり
      • リソースを管理
    • PMとアーキテクトの視点を合わせることで最大になるように
      • 兼任では1人分の視点しか
  • アジャイルとアーキテクト
    • アジャイル開発者がいると心強い
    • アジャイルの導入は失敗できない
      • 「やっぱりだめじゃん」と言われる

デブサミふりかえり

デブサミの最後に、2日間での気付きをふりかえり、そして共有しようという企画でした。

裏番組が強力すぎたので、正直思ったより人がすくなかったのですが、参加した方々に「こうしてふりかえれてよかった」と言ってもらえたときはとてもうれしかったです。(準備などまったく手伝えなかった人が言うことじゃないですが)

途中からスタッフも中に入ったんですが、皆さんの熱気がすごかった!そして、4人中2人が帰って社内勉強会を立ち上げると!すごいパワー!

俺も負けてられない、というか、もっとがんばらなきゃ!そんな風に思ったふりかえりでした。

 

さて、デブサミを終えて強く思ったことが一つあります。

「俺もいつかあの壇上に立ちたい!」

今はまだ無理だけど、いつか、近い将来、あそこに立つためにがんばろう。

 

(ここから心の声)

やばい!書いちゃった!書いたら後戻りはできない!突き進むのみ!

デブサミ1日目 1

Posted by kenchan 2009-02-14 21:22:00

1日目に参加したセッションは次の4つ。

  • iPhone開発者座談会
  • カードゲームでプロマネ疑似体験
  • Eclipse-way
  • オブジェクト指向エクササイズのススメ
  • LT大会

iPhone開発者座談会

iPhoneどころか、touchも持ってないけど、興味本位で聞いてきました。

  • 審査がかなり厳しい
    • UIがいけてないとだめ
    • 文言が悪いとだめ
    • あらかじめ、軽いアプリでアカウントを作っておくのがオススメ
  • iPhoneに向いている、向いていない
    • 80%の人が使う機能だけを入れる
    • 単機能
    • 最初は細かい機能をごっそり落とす
    • 何かを見るアプリが向いてる
  • 開発する上での注意など
    • タッチポジションは大きめに。指は1ドットではない。
    • アップルのアプリをよく見る
      • なぜここにボタンがないのか
    • コードの美しさ vs パフォーマンス
    • ドキュメントのないAPIが肝
    • Twitterで情報共有しよう

カードゲームでプロマネ疑似体験

yattomの手作りカードゲーム面白かったです!

  • プロジェクト開始時点で、実は勝負が決まっている!?
  • 手札が多い序盤に、リスクのあるカードを処理するのが正解?

相手の方から「ゲームが進むにつれて、リスクが上昇するのはどうなんだろう。開発が進むにつれてリスクは減っていくのでは?」というところが気になったようです。

Eclipse-way

ついこの前、codezineにも記事が載ったJazz(とRationalのツール)のお話。

分散開発におけるリポジトリの考え方はよくまとまってて面白かったです。改めて分散バージョン管理に移ろうと心に決めたのでした。

  • IBMの開発プロセスウォーターフォールからRUP、そしてAgileに
  • 分散Agileやってます
  • Jazzのサイト自体が分散Agileの実例となっている
    • 何を作るのか
    • 何を決めるのか
    • どういう粒度の成果物を作るのか
  • Eclipse-wayとは、Eclipseの開発プラクティス
    • OSSならではのプラクティス
    • 大規模開発のプラクティス
    • 分散開発のプラクティス
  • ドッグフード重要
  • 分散開発のポイント
    • リポジトリの管理
      • コードをコミットするための明確な完了基準
      • SVNを分散っぽく使う
      • メインリポジトリと個人のワークスペースとローカルスペース
      • 個人のワークスペースはサーバ上、ローカルリポジトリはローカルマシン
      • ちょっとした変更でも共有やレビューができるように、サーバ上にワークスペースをおいている
      • ワークスペースとローカルリポジトリは常に同期されている

 

オブジェクト指向エクササイズの進め

ThoughtWorksアンソロジーのエッセイの一つを紹介してました。

かなり厳しい制限を加えることで、普段思いつかないようなクラスが抽出できたり、チームのメンバーに眠っている知識を引き出したり、責務の再分配ができたりと、かなりの効果があるとのことでした。

何よりも、実際にこの制限化でアプリケーションを開発しているチームがThoughtWorksにはあるというが一番の驚きでした。

  • 9つ制約の効果
    • 責務の再配分
    • 新しいクラスの発見
    • 設計がゆれる(いい意味で)
    • 議論を引き出す

 

LT大会

終始ドラ娘専属カメラマンになってました。

まったく知らないコミュニティの方々のLTを見れて、かなり新鮮でした。職人系が少なかったのもよかったです。

 

2日目に続く。

角谷さんに言及してもらうと

Posted by kenchan 2009-02-05 01:23:00

http://twitter.com/kakutani/status/1157947145

  • アフェリエイト童貞を卒業できました!(ちゃんと書評を書きましょう)
  • 当日の訪問者数が8倍になりました!(今までが少なすぎです)

これが俗に言う「角谷効果」というやつですか!

aep

[読了]アジャイルな見積りと計画づくり

Posted by kenchan 2009-02-05 01:02:00

今週、先週の通勤時間はほぼ全て本書に捧げました。

気になった箇所やあとで読み返したいところなどに付箋をつけていったらこんなんなりました。(色は特に意味はないです)

P1000625

特に興味深かったのは、作業量の見積りと期間の見積りを分けて考えるという所と、狩野モデルの紹介の部分でした。

ということで、個人的には第三部、特に11章が目から鱗でした。 本書を読んで、みなさんもよい見積りを!