技術全般 Archive

この話は至極もっとも。
ただし、例が極端すぎてネガティブな反応が多いのかなぁ。

従来のソフトウェア工学が決定的に間違っている点 - kwatchの日記

最後にもう一度。高度な仕事になるほど個人に依存するのは避けられないし、属人性を排除すべきではない。属人性を排除して各人の能力を均一化して扱おうとしたソフトウェア工学は根本的に間違っている。

プロジェクトで優秀（だと思われる人）にアーキテクトっぽい仕事を任せたり、共通部品を作らせたりして整備した後に、それ以外の人にサポート、例えばドキュメント作成や大量生産系の仕事を任せる、なんていうのは普通にプロジェクトマネジメントとして考えると思う。
逆にこれすら考えておらず、それでうまくいったプロジェクトを見てみたい。
うまくいったとかいっていても、実はOSSのプロダクトやフレームワークなどを活用していてそれで生産性があがっていたりして。それはOSSを作った優秀な人の仕事の上に成り立っているんだけどね。

とはいっても理想は遠く、本当に優秀な人をピックアップするのが難しかったり、本当に優秀な人は請負のソフトウェア開発などやらない人だったり、自動化で大量生産を行うことの難易度が高すぎたり（単純に能力が足りないのかも）ということはあるだろう。
それでも、以下のどちらの世界を目指すのが良いのか？というサジェスチョンが元ネタの議題ではないかと思う。

• できるだけ属人性を排除し、誰が入れ替わっても事業が存続していくようにしたい。
  そのためには、みんなが均一な能力を発揮し、誰が入れ替わってもうまくプロジェクトが進むような仕組みが必要
• できるだけすばらしい成果を出したい。
  そのために、優秀な人が最大限の力を発揮し、高度な成果を達成できるような体制が必要

このどちらが正しいと思うかは、ソフトウェア開発の仕事をどちらの仕事ととらえるかにかかっていると思う。

• 車の組み立て工程
• 車のコンセプト設計、デザイン

前者の仕事は、職人的な部分もマニュアル化し、流れ作業でスムーズに作業が進むようにする。多少の能力差も最終品質に影響を与えるほどではないという認識になりそう。
後者の仕事は、単純にマニュアル化できない。主査など主要なメンバーの能力に依存するが、どんな人物を大事な役割に登用できるかが鍵という認識になりそう。

これは、ここに書かれている話しと同じ。
まつもとゆきひろ氏が語る「ビューティフルコード」セミナーに行って来た - Slow Dance

コードが工業製品と勘違いされているために、「ソフトウェアの生産」は車の生産ラインのように扱われることがある。

しかし、ソフトウェアは本質的には情報なので、流れ作業は0に等しく、生産ラインのような作業はない。実は、ソフトウェアの生産は車の作業工程でいう「設計 = デザイン」の部分にあたる。車を設計する時には、原寸大の粘度を削って車の形にする。そして、それが美しいとか議論されて最終的なデザインに落ちる。

では、SIという仕事はどっちなのというと、どちらかというとまつもとさんの言っていることが近しいのではないのと思う。
それはソフトウェア開発（SI含む）は本来クリエイティブで高度な仕事であり、つまり属人性を排除しきれないことを意味し、kwatchさんの言っている方向は正しいと考えられる。
少なくも私はそう思う。

なんとなくもやもやして、この辺の考えを整理しようと思いながら放置してたんだけど、現実世界にあわせて実にうまく説明している文章を見た。この人の話しはいつもうまく整理されていて参考になる。

不確定性を受け入れ突出した人材の力を引き出せるのが良い組織 - アンカテ

つまり、これからの組織のマネジメントは、

1. 属人性を排除した組織としてのパフォーマンス(業者と折衝して2億円を8000万円くらいにできる組織)
2. 組織内の突出した人材を活用したパフォーマンス(超属人的なスキルで2億円を820万円にする個人を中心にしたチーム)

の組み合せになるのではないでしょうか。

このニュース（見積もり2億円のIP電話を820万円で構築した秋田県大館市から学べること：ITpro）の話しだけど、これはすごく納得できる。
このニュースに対する論争の中で一番しっくりきた。

若干違う趣旨のことを言っている気もするけど、kwatchさんのいっていることと近いのではないだろうか。

こういうマネジメントを考えられる組織は強くなるだろうな。

追記
元ネタではSIではなく、ソフトウェア開発の話しをしていたが、SI業界大手はソフトウェア工学好きに見えるし、反論もSIっぽいプロジェクトを意識したものが多そうだったのであえて混同して記述しています。

勢いでMTをバージョンアップしてみました。

まず、伏線としてスパムコメントが大量に発生していたという事実があります。
で、スパムがDBに負荷をかけているとの理由で、さくらインターネットに迷惑をかけてしまいました。
すいません。

対応としてはmt-comment.cgiのパーミッションを緊急対応でいじってもらいました。

そんなこともあり、勢い余って予備知識も調査もなしに、かなりジャンプアップでバージョンアップしてみた訳です。

不安はたくさんありましたが、今日もお酒が入っていることもあり、あまり深く考えずに始めてしまいました。

結論
勢いでやらずにちゃんとやろう。

MTディレクトリをバックアップした後、思い切って元ディレクトリを消します。
そこへMT本体を展開しました。

案の定、再構築でエラーが出ます。

次に、プラグインを入れ直しました。MTPaginateとMTPingedEntryです。

で、スパムやだなーと思ってCAPTCHAを入れることを決心します。
入れたはいいけど、テンプレートにCAPCHA表示部分が記述されていないので、テンプレートに入れます。

コメントに CAPTCHA 認証を利用する | Movable Type 4 ドキュメント

でもなぜか画像がでない。
以下のページを参考にいじってみたり、新しいmt.jsを入れてみたりして、なんとか動いた。mt.jsは関係ないと思うけど。酔っぱらっていてよくわかりません。

MovableType、コメント時のCAPTCHA画像を表示させる - SHIMOM式 2.0

でもコメントのプレビューが出ない。
なにやら、コメント関連の仕様？がかわっているっぽい。
以下のページを参考にして、テンプレートモジュールやシステムテンプレートをいじる。

Nakamura’s Weblog: MovableType 4.1でのコメントフォームを更新

すると、なんとかプレビューはでたけど、当然デザインは崩れまくり。
どうしたものかと思いながら、今は明らかに忍耐がないので、プレビューへ遷移するボタンをコメントアウト。

ちなみに、コメント入力エラーのときのデザインもめちゃくちゃです。

というわけで、どこかでテンプレートの大掃除が必要そう。
稼働中なのは、嫁のブログと嫁実家のキャンプ場ブログかな。
デザイン刷新も含めて年末やるかなー。

まるごと Ruby! Vol.1

posted with amazlet at 08.06.08

るびきち arton 大場 光一郎 高井 直人 後藤 謙太郎 新井 俊一 瀧内 元気 cuzic 倉貫 義人 大場 寧子 久保 優子 十河 学 舞波
インプレスジャパン
売り上げランキング: 644

Amazon.co.jp で詳細を見る

この初心者お断りの姿勢が男らしい。
「もう一つのRuby入門」
って（世の中多くの人が思う）入門じゃねー。

JavaもRubyも初級者の私としては両方学べていい感じだったけど。

「Javaもちょっと業務でかじったし、よーしRubyやっちゃうぞー」
的なノリで表紙の優しい雰囲気＆入門という言葉でこの本を買っちゃった人は公開するかもしれない。

ひがさんの「ITゼネコンをぶっつぶせ」講演を聞いてきた。
内容は最近のひがさんのブログなどで語られている「Programming First Development」のこと。

で、感想＋会場の雰囲気から感じた課題感をつらつらと書いてみる。

内容には激しく同意。
できるようになれば、そしてできる人材が育てば、SIerも生き延びるチャンスがあるかなと思う。
（このままだと死ぬと思っているかどうかによって、「生き延びる」という表現に違和感がでるかな？）

もちろん、課題はまだまだある。
契約形態、テストに対する考え方、どこまでドキュメントを書くか、そんな人材ほんとに育つのか？
まだまだ経験を積みながら考えなければならないことは多い。
でも、枝葉末節にこだわらず、本質的なメッセージをとらえば明るい未来が見える良い内容。

ここからは、会場の雰囲気から感じた課題感。

インタラクティブにやりたいという冒頭のひがさんの言葉通り質問や意見が飛び交う
ただし、質問の内容がどちらかと否定的な見方や穴を探すような見方が多かったのが気になる。
（SIerの得意な態度だけど）

こういうセッションに参加するというのは、どちらかというと課題意識の高い人たちだと思うから、もっと響くと思ったんだけどな。
今までのSIerのやり方を真っ向から批判しすぎて拒否反応がでるのかな？
話題を集める目的では過激な方が良いが、啓蒙という観点から考えるともう少し別のやり方を考えた方がよいのかもしれない。

LLな人たちの考え方や態度とは、かなり隔たりがあるのを感じた。
LLな人からすると、こんなの当たり前じゃない？って思う話も多いかなーと。

どちらにしても、現場の開発者、SIerの偉い人たち、発注者の三者を啓蒙していかなければ、取り組みは成功しない。

それぞれに対するメッセージはこんな感じかな？

1.現場の開発者
・楽しく開発できる、成長できる。
・上流から下流まで全部それなりにできるようにしよう
・現場の人たちは啓蒙しやすいと思う

2.SIerの偉い人、(PM|上流)だけやればいいと思っている人
・売り上げのガサは減るかもしれないけど、利益は確保できる
・このままのやり方では、今後10年以内で破綻する

3.発注者（お客様）
・もっと安く早く、しかも良いシステムができる
・そのかわり、もっとシステム検討＋開発にコミットしてね

とりとめなく書いてしまったが、現在のSIerのやり方になれてしまった2,3の人たちをどう啓蒙するかが鍵。
一番は、ケーススタディーをたくさん作ることだと思う。

幸い、今業務でやっているところでは、お客様が乗り気で開発形態をひがさんの言っているような形態に変えようとしている。
これは、我々SIerにとってはかなりチャンス。
利益さえ確保できれば、少なくとも今の私の上司も納得するだろう。
金融のどでかいプロジェクトにくらべたらすごく小さい規模かもしれないが、それでも世の中に発信して注目を集める程度の規模と知名度はある。
今のプロジェクトが、SI業界を変えていく一つの要素になるようにしたい。

Ruby vs. Python は Lisp vs. Scheme に似ている k-watchの日記より

Ruby vs. Python は Lisp vs. Scheme に似ていると思うんだ。

確かにそうだよなー。そう思った。
Python の好きなところに言及があるけど、JavaScriptもScheme、Python陣営の仲間だよなー。
名前空間が変数と関数で分かれていないのも同じ。
仕組みが単純なのも同じ。

前回に引き続き、チケットとsvn commitを連携させる。

まずは、「trac-svn-commit-hook」を/path/to/trac/contribに配置。
インタアクトさんが配布している日本語バージョンを入れている場合は、ダウンロードファイルのcontrib配下にある。
実行権限をつけておくのを忘れずに。
trac-svn-commit-hookが見つからない場合は、以下のようにsvnからダウンロードすればいいはず。
svn export http://svn.edgewall.com/repos/trac/trunk/contrib/trac-post-commit-hook

次に、/path/to/svn/repos/hooksに「post-commit」を配置する。
tmplファイルがあるのでそれをいじればよいが、必要なのは以下の記述。


#!/bin/sh　#これはtmplファイルの１行目にすでに記述してある
TRAC_ENV=”/path/to/trac”
SVNLOOK=”/usr/bin/svnlook”
PYTHON=”/usr/bin/python”
export LANG=ja_JP.UTF-8
REPOS=”$1″
REV=”$2″
LOG=`$SVNLOOK log -r $REV $REPOS`
AUTHOR=`$SVNLOOK author -r $REV $REPOS`
${PYTHON} ${TRAC_ENV}/contrib/trac-post-commit-hook \
-p “$TRAC_ENV” \
-r “$REV” \
-u “$AUTHOR” \
-m “$LOG”
これも実行権限を忘れないように。

あとは、コミットする際のコメントに入れる以下の二つのコマンドを覚えればOK。

fixes #1
refs #1

チケットをクローズしたいときは「fixes」、チケットにコメントを追加したいときは「refs」を使う。
#1はチケット番号。53番のチケットをクローズしたいなら「fixes #53」とやればよい。

コマンドの書き方は他にもあるけど、やってることは同じなのでとりあえず上記を覚えれば大丈夫だと思う。

Subversionとtracの設定を久しぶりに行ったので、メモ。

• Subversionとtracの認証は同一で管理したい
• それぞれhttpを利用して公開する（SSLは今回は除外して考える）
• 更新は登録ユーザーしか行えないが、閲覧はどのユーザーでも行えるようにする
• 認証にはdigest認証を利用する
• digest認証のレルムはrealmとする

以下の前提。
リポジトリ：/path/to/svn/repos
リポジトリURL：http://example.com/svn/repos
tracディレクトリ：/path/to/trac
trac URL: http://example.com/trac/repos

まずはリポジトリの作成
$ svnadmin create /path/to/svn/repos

※リポジトリ内のプロジェクト構成についてはここでは触れません。

次にApacheの設定を行う。
svn用Apacheの設定はhttpd.confに以下の設定を追加する
※ディレクトリ単位で詳細に権限を設定する場合は、AuthzSVNAccessFileを利用するがここでは割愛する。
※参考URL：Subversionのインストールと設定

DAV svn
SVNPath /path/to/svn/repos
AuthType Digest
AuthName “realm”
AuthUserFile /path/to/svn/repos/.svndigest
#リポジトリの読み込みに必要なメソッド以外は、認証を必要とする

Require valid-user

#読み込みに対しても認証を必要とする場合は、LimitExceptは必要なし 以下は例
#Require valid-user


複数リポジトリの場合でも、上記設定をリポジトリごとに行うのが吉。
SVNParentPathは設定が楽そうに見えて、柔軟性が無くあとでどうせ変更することが多い。

svnを利用するにあたり以下のようにモジュールをロードする必要有り。
LoadModule dav_module modules/mod_dav.so
LoadModule dav_svn_module modules/mod_dav_svn.so
LoadModule authz_svn_module modules/mod_authz_svn.so

authz_svn_moduleはAuthzSVNAccessFileを利用しない場合は必要なし。

digest認証のユーザーは以下のコマンドを使って作成する
$ htdigest [-c] /path/to/svn/repos/.svndigest realm username
ファイルを初期作成する場合は、cオプションをつけるが、それ以外はcオプション必要なし。

次ぎにtracとの連携。
$ trac-admin /path/to/trac initenv
で、コマンドプロンプトでいろいろ聞かれるので普通に答える。

tracのApache設定は以下のとおり。ここではmod_pythonを利用しているものとする。

SetHandler mod_python
PythonHandler trac.web.modpython_frontend
PythonOption TracEnv /path/to/trac
PythonOption TracUriRoot /trac/repos


AuthType Digest
AuthName “realm”
AuthUserFile /path/to/svn/repos/.svndigest
Require valid-user


複数レポジトリをtracで扱う場合は、上記設定（trac-admin path initenv 〜 Apache設定まで）を別のレポジトリに対しても行うのが吉。

tracの権限設定は、以下のコマンドで利用可能
$ trac-admin /path/to/trac permission list #全権限のリスト
$ trac-admin /path/to/trac permission remove 権限 #TRAC_ADMIN、BROWSER_VIEWなど
$ trac-admin /path/to/trac permission add 権限 #TRAC_ADMIN、BROWSER_VIEWなど

※新規でtracを立ち上げた場合、デフォルトでanonymousに強大な権限が与えられているため注意。
※基本的に、anonynousは*_VIEW権限のみ残す。
※その他の権限は、trac-adminを利用して作成する。
※権限グループも設定が簡単 ⇒ グループ名称をユーザー名と同等に扱い、ユーザーへの権限付与はグループ名をそのまま利用できる。
ex)
$ trac-admin /path/to/trac permission add member TRAC_ADMIN ...
$ trac-admin /path/to/trac permission add nakamura member

コマンドラインでパーミッションを設定するのは面倒だが、WebAdminプラグインを入れておけばPermissionメニューから簡単にパーミッションを変更できる。

これでApacheとtracの連携ができ、認証情報も共用できている。

svnのチケットとtracの連携は次回。

やっぱりDjangoみたいなフルスタックのフレームワークは分かりやすくて、何かあったときにも追いやすい。
DjangoかPythonかどっちかの話だけすればいいから。（DBとかWebサーバーとかもちろんあるけど）
それに機能が過剰すぎるわけでもないし、そのやりかたに縛られなくても簡単に独自実装を入れられる。その辺も分かりやすさの一因だろう。

TurboGearsを初めて触ったときに感じた分かりにくさの一つに、フルスタックではなくそれぞれの優秀なプロダクトを集めて作ったというところがあったんだと思う。それはそれぞれ設計思想が違うとかそういうことではなく、単純に一つにまとまってドキュメントが無いとかそんなレベルのことも関係していたと思う。

で、SAStrutsを触っているとそれがもっと加速する。
SAStrutsなのか、Strutsなのか、その他Seasar2関連の話なのか。
Javaの言語仕様の話なのか、Javaの作法の話の話なのか。
はたまたEclipseみたいなIDEの話なのか（これはJava作法の話に含まれるのか？）。

Djangoはデザイナーに推薦して裾野を広げることもできるけど、SAStrutsは無理だよね。
もちろんターゲットとしているところは全然違うはずなので、それは望まないことだと思うけど。

それなりに経験を積んできて分かっている人には問題にならないことでも、人によってははまるような問題になる。

もちろん利点になることもある。
フレームワークの開発自体が素早くなるのはもちろんだろうし、それぞれのいいとこ取りで成長していけば一緒に成長してきている人にとっては分かりやすくて非常にいいフレームワークになるんだろう。

何が言いたいのか分からなくなってきたけど、薄いフレームワークと言っても受ける印象が(人|習熟度|場面)によってだいぶ異なるんだろうなー。

SICPとプログラミングGauche。

両方手元にはある。
いろいろ時間がとれてなくて進みが遅いけど、30過ぎても新しいことを身につけられるぞ、と示したい。

ここらでちゃんと基礎を身につけたい。

今担当しているとある企業のサイトについて、マネジメントとか企画～要件定義くらいを手伝っているわけだが、そろそろシステムもちゃんと見直そうぜという雰囲気になりつつある。

裏側の業務システムまで含めるとかなりの規模なので、いきなり全部キレイに作り直しというわけには行かないけど、プロトタイプで一部機能を作り直してみたいなぁ。
アクセス数が少な目の機能ならいきなりパフォーマンス問題にぶつかることも少ないだろうし。

で、問題になるのが何で作るか。

現在はC。Perlではパフォーマンスがきつくて、Javaはこなれていなかった時代の名残。
個人的にはPython＋Djangoを推したい。
開発者を確保したいという意味ではPHPとかJavaが強く推されそう。
Railsも絶対推す人がいるはず。
パフォーマンスや障害対応を気にして、フレームワーク自作案とかもありえそうだし。
大穴はPerl＋Catalystとか？

うーん。

まずは、この辺の選択肢を並べて検討ボードにのせようと思う。
・現在のまま、フレームワークの改善を実施
・Python＋Django ← オススメ
・Java＋Struts ← やだ
・Ruby on Rails
・PHP（簡易フレームワークを自作）← 一番受け入れられる可能性が高そう、でもやだな

あとはインフラ構成も考えないと。
こっちは別の人にお願いしたいけど、いろいろ面白いの提案したい。

これ以上いろいろ書けなくなりそうだけど、書けることがあればまた書きます。