眠る開発屋blog

Web解析Hacks ―オンラインビジネスで最大の効果をあげるテクニック & ツール
仕事上このへんの話が多いので、会社で購入してもらうかもしれない。

スケーラブルWebサイト
一時期、話題になった「Building Scalable Web Sites」だが、日本語版が去年の年末に出ていたらしい。
一応原書は購入したのだが、英語弱いので買いなおそうかな。。。

Windows Developer Power Tools (Power Tools)
原書なのだけどもそのうち日本語版出るのかな。
目次を見てみれば分かると思うのですが、Windows向けの開発ツール紹介本らしい。
なにげに目次だけでも「ツール集」として結構価値があるのではないかと。（Linux版も出ないかな）

あと、これだけオライリー本じゃないのだが、
Nagios 2.0オープンソースではじめるシステム&ネットワーク監視
監視ツールNagiosの本。
Nagiosを導入しているWebサイトも結構多いと思うよ。

PlaggerのPHP版「Prhagger」がリリース
なんか誰かがPHPでPlaggerを作るという噂は聞いたことがあるのだが、遂に登場した。
これで隣の青い芝生を指をくわえて眺めてなくても済んだわけだ。

ってか、誰かそろそろapacheで動作するmod_plagger なんて作ってくれないかね。

はじめてPlagger使ってみた。

やりたかった事の一つ目は、最近全然目を通せていないOpenIDのメーリングリストを、忙しくても話の方向ぐらいはざっくり掴めるよう、翻訳されて届くようにすること。

やっぱりPlaggerなんですかね。
やってみようかな。

「デザイニング・インターフェース」を購入した。
今読書中。

どうも日本の企業社会は時間を安く見積もる傾向があるような気がして、
「４０時間のものを１６時間に値下げしろ」みたいな話が平気で通ってしまうのはどういうことか。

社員の時間を全て何らかのタスクに紐付けさせて、生産性測定の手段に使っている企業もあると思う。
が、横にタイムキーパーでもついてくれて、本人が意識せずとも勝手に計測してくれるならまだしも、
細かなトレースすること自体が結構な負荷がかかるとなるとどうにもこうにも。

「一日の時間はこのタスクで３割、このタスクで２割、このタスクで１割」ぐらいにざっくり切る程度であれば、それほど大変だとも思えないし、まぁうまくいくのかな。

また、案件ごとに時間を束ねるようにすると、当然、火を噴いている案件とかはとんでもない人ｘ時間数になっていたりする。
「これなんとかしなきゃまずいじゃん」と誰でも分かるので、「見える化」効果でいいかもしれない。

久々に面白そうなニュースが飛び込んできた。

Firefox3.0はOpenID対応、OpenID認証のApacheモジュール

元ネタには当たってないのでアレなのだが、この２つの意味するところは非常に大きい。

1つは、どうもFirefoxが3.0からOpenIDに対応するらしい、ということ。

また、ついにOpenID認証のApacheモジュールが出ました。

SNS業界に大きなインパクトを与えるのは当たり前の話だけども、それ以上の広がりを持つ可能性がある。

そもそも個人認証やその管理についてはMSPassport と LibertyAllianceという規格があるのだが、両者とも（MS或いは複数の）ベンダーが主導というイメージが強く、誰でも手軽に使える程、広く解放されていたとは言い難い。
OpenIDがもしその代替物となりえるのであれば、Webに与えるインパクトは相当大きなものになるだろう。

ってかこれは個人的に気になるのであとでソースを見てみよう、と。
ModAuthOpenID

いつもより30分早く起きたけど、
朝の忙しいときに30分という時間は微妙な単位で、
何もすることがないので会社に行くことにしました。

ぽっかりと時間が空くと使い道に困るよね。

1/19の「大機・小機」というコラムを読んで思ったこと。
前から薄々感じてはいたが、日経新聞はホワイトカラーエグゼンプション導入に前向きみたい。

半年ぐらい前（2006年の秋口頃）の話だけども、とある事情からblogサイトのレンタルサーバ移転を行うことになって、そのとき経験したことをざっくり書いてみる。

• 当たり前のことなのだけども、新しいところでもサイトが動作するようにあらかじめ準備しておかなきゃいけない。
  新しいサイトの動作はドメインが向いてなくても、hostsファイルで検証できる。
  （そのときはブログ＋簡単なフォームしかなかったので、DBの整合性とかあまり気にしなくて済んだ）
• 元々、ドメイン管理もレンタルサーバにお任せだったのだけども、ドメイン移管は移転元・移転先の業者ともに対応してくれていたので、それもお任せ。
  多分有名どころのレンタルサーバは対応してくれる気がする。
• ドメイン移管作業というのは、JPドメイン名の場合、JPRS(日本レジストリーサービス)に対して、移転先業者が行うものらしい。
  移転元、移転先業者同士の話は勝手に進めてくれるみたいなのだが、あらかじめ移転先業者に移転元業者の(JPRSの）登録者番号を教える必要があった。
  実際に何が必要でどれくらいかかるのか？ということは移転先に確認してみるのがいいかも。
• 移転先業者のドメイン移管作業も時間がかかる（そのときは１〜２週間ぐらい）みたいなので、一ヶ月ぐらい前から業者に問い合わせるとか準備しておくのがいいと思う。
• JPドメインだったからかもしれないけど、移転先へ作業費用で払ったのは確か２０００円とか３０００円とか。
  移転元への費用は発生しなかった。
  これは業者によって変わってくるのかも。
• ドメイン移管中の受信メールは考えるのがめんどくさかったので、確か転送にしておいた。

レンタルサーバって一頃に比較して相当値段が下がっていると思うので、めぼしいのがあれば移転を考えてみてもいいかと思うよ。

最近、知人と話していて出た言葉。
「初期リソースは少なめにして、とりあえず開発し、軌道に乗ってきたらより多くのリソースを投入する」
（この場合のリソースは要員）
Web開発がSI開発とは異なるアプローチをするのは理解できるのだが、初期開発の投資を少なめにするというのはどうもしっくりこない。
というか、運用開発に初期開発以上のコストをかけるのがイメージが湧かない。
とりあえず初期システムを完成させたとしても、技術的負債が残ってしまう。
リスクなどを鑑みると、初期＋運用の全体的なコストは上昇してしまう気がするのだが。

ってか、あれか、初期開発=プロトタイプか。
Webサイト運用計画が明確になった時点では、スクラップアンドビルドでOKってことか。
それなら合点がいく。

とはいえ、本稼動を目論んだ開発においては、ある程度のリソースを投入する必要がある。
「走りながら作る」のはYes。
ただそれを可能にするシステム･･･「拡張性」の維持はやはりある程度のリソースを投資しなければならないのでは。
確かに「どこまで拡張性をもたせるか？」の追求はリソース及びスケジュールとのバランスなのだが、ここの部分を見誤り、過大な技術的負債を作ってしまうと、後々にっちもさっちもいかなくなる。
そして、そのツケは開発担当者や運用担当者の過負荷労働と顕在化してくるのである。
そもそもシステムの目的は自動化であるため、「初期フェーズの確保リソース<運用フェーズの確保リソース」というのは本末転倒な気がして仕方ないのだが。