2007-05

一昔前のVisualBasicと今のPHPは同じ立場？

まー、どんなに言われても普及してるのは普及してるんだし、使う人もまだまだ増えるだろう。
JavaからRubyに鞍替えするくらいなら、JavaからPHPに移行したほうが多くの開発者はすんなり行くんだろうし。

確かにPHPは作る側には向かないかもしれないし、いじる楽しさが少ないのも分かるけど、その代わり一般人には浸透しやすいよね。

Lisperが他の言語を物足りないと言うのと同じ原理で徐々にたどっていくと、行き着くはけ口はPHPになるってことなのかなぁ。

久々に読んで、やっぱり良い本だなーと思った。

アイデアのつくり方

posted with amazlet on 07.05.18

ジェームス W.ヤング 今井 茂雄
ティビーエス・ブリタニカ (1988/03)
売り上げランキング: 990

おすすめ度の平均:

核心を端的に衝くとは
良書
アイデア作成に王道が無いのを気づかせてくれる素晴らしい本。

Amazon.co.jp で詳細を見る

確かに第一段階とか第二段階をちゃんとやっていなくて、「ひらめかない」とか言ってる人が多いのは分かる。
真面目に第一、第二を実施して、第三段階を意識するといいアイデアが出やすいのも分かる。
これだけでもこの本の価値は偉大だし、私自身もものすごい役に立った。

ただ、特に組織が大きくなればなるほど第五段階をクリアすることにすごい時間がかかって、アイデアの種はみんなの意向を汲んでエッジの立たないものになり、スポイルされて最終的なアウトプットがいけてないものになることが多い･･･と、この本を読んだ人がちゃんと意識してるかな？
もともとアイデアの種が良くないから結局ダメなんだよ･･･ともいえるのかもしれないけど。

「アイデアの作り方」という本の中で著者が意識してあえて第五段階を定義した上で、そこでお蔵入りしてしまうことが多いというのはすごい。

ここを乗り越えるためには、論理的思考能力だけでなくコミュニケーション能力とか、その他いろいろ必要なんだろう。

まー、ここをどうやって乗り越えるのかというアイデアを出すのも、「アイデアの作り方」が参考になるのかもね。
なんてね。

最近自分が悩んでることをあえてエントリーにしてみた。

mapやfilterはそのままだからすぐに内包表記でOK。
本当ならreduceもループじゃなくってリスト内包表記で書けたらいいのに。

>>> a = [1, 2, 3, 4, 5, 6, 7, 8, 9, 10]
>>> b = 0
>>> def funcA(x):
… global b
… b += x
… return b
…
>>> [funcA(x) for x in a]
[1, 3, 6, 10, 15, 21, 28, 36, 45, 55]
>>> b
55
>>>

うーん。
globalよりはClassのほうがまし？

>>> a = [1, 2, 3, 4, 5, 6, 7, 8, 9, 10]
>>> class ClassA:
… b = 0
… def funcA(self, x):
… self.b += x
… return self.b
…
>>> c = ClassA()
>>> [c.funcA(x) for x in a]
[1, 3, 6, 10, 15, 21, 28, 36, 45, 55]
>>> c.b
55
>>>

うーん。。。。。。
普通にループにするか、複雑な処理だったらリストを処理する関数(中身はループだけど)を書いたほうがましかな。

※ 2007/5/19 5:00ちょっと前 追記
今、夢の中で誰かが破壊的代入がダメなんだよと言ってたので、ちょっと考えてみた。

普通にreduceだったらこう。
>>> a = [1, 2, 3, 4, 5, 6, 7, 8, 9, 10]
>>> def funcA(x, y):
… return x + y
…
>>> reduce(funcA, a, 0)
55
>>>
で、さっきはreduceっぽい処理をグローバル変数への破壊的代入でなんとかしようとしてみた。
じゃー、破壊的代入をしないとこんな感じ？
>>> def funcB(func, xs, init):
… if len(xs)==0:
… return init
… elif len(xs)==1:
… return func(xs[0], init)
… else:
… return func(xs[0], funcB(func, xs[1:], init))
…
>>> funcB(funcA, a, 0)
55
>>>
これをどうにかして無理やり内包表記でやろうとすると、、、
無さそうですね、少なくとも私にはわかりません。。。

やっぱり夢は夢だったということで。
さっきは酔っ払ってて、今は寝ぼけてて、あんまり筋の良くない話になってるのかな。

無理矢理でもいいので、だれかreduceの代替案を知ってたら教えてください。

※追記 2007/05/21
reduceが廃止されたらやだなーと思って酔っ払って勢いで書いてしまった記事です

どうやらWebLoadという負荷テストツールがオープンソース化されたらしい。
ウノウラボ Unoh Labs: オープンソース戦略により、無償で使えるようになった負荷テストツール

ちょっと大き目のサイトで負荷テストすると、負荷かけクライアント側も気をつけないとボトルネックになってしまうから始末が悪い。
しかも、負荷をかける量、というか仮想ユーザー数で課金されたりしてコストパフォーマンスがすこぶる悪くなってくる。

オープンソースというのは嬉しいけど、比較表のScalabilityあたりを見ると大規模な負荷テストで使うのは厳しいのかな。

ちなみに私が負荷テストしたときは、httperfを使ってた。
いいツールだったと思うけどコマンドライン起動しかないから、シェルで起動スクリプトを作って、リモートシェルで複数マシンから同時に負荷をかけたりしていた。

商用ツールを使うとそういう手間も軽減されるんだろうか？
データ収集とかシナリオ作成とかも簡単にできるんだと嬉しいな。

そのうち機会があったら試してみよう。
ただ、商用ツールになるとびっくりする値段になる（ことが多い気がする）から、費用対効果はどうなのかな？

ブルーオーシャン戦略、ザ・ゴールなど、ビジネス書(?)8冊の内容をまとめて簡単に解説している本があった。

大人のたしなみ「ビジネス理論」一夜漬け講座

posted with amazlet on 07.05.16

渋井 真帆
宝島社 (2006/12/19)
売り上げランキング: 5121

おすすめ度の平均:

とても良いです
現代人には時間がない？！
読みやすいが8冊のほんの目次なのかなぁ

Amazon.co.jp で詳細を見る

すでに読んでいる本はあるものの、読んでない本も取り上げていたので読んでみた。
今まで読んだ本は解釈がどう違っているのか見たかったし、他の本も普通に表面的になぞって面白そうだったら実際に読んでみればいいのかなーなんて思ったし。

一夜漬けというのは客引きの言葉だとして、本の内容は普通。それぞれの本を読む導入として内容をなぞってみるという目的だったら悪くないと思った。1300円にしては高いと思う人もいるかもしれないけど。

内容の話はそれぞれの本をなぞったものになってしまうので気になったところだけ。

199ページ（富の未来の解説の中の一文）

読むのに相当な気合が必要なので、これは最後にとっておこう、となって他の七冊を読み終えてからこの本に取り掛かりました。

235ページ（おわりにの中の一部）

私はここ数ヶ月、八冊の本に没頭し何度も読み返しました。社会人になって以来、こんなに真剣に本を読んだのは初めてかもしれません。

うーん。まさかこの本を書くために八冊の本を読んだわけじゃないですよね？
いろいろな自分の経験と、さまざまな本を読んだ結果この八冊を選んだんじゃないんですか？
まさか本を書くためにまさに一夜漬けで本を読んだんじゃないですよねぇ？
そうだったら悪いというつもりも無いですが、その辺のブロガーが解説とか書評を書いていたりとか、研究室の学部生が輪読したりするのと同じじゃないですよね？

あと気になったのは、こういう本を書くのにそれぞれの本の著者とはどういう連絡を取ってるんだろう。
それから、やっぱりこの八冊もだれか仕掛け人が選んだのかなーと勘繰ったり。

内容とは別のところでいろいろ考えさせられた(?)本だった。

2004年4月にPMP合格しているので、3年サイクルは今年の12月31日までのはず。

PDU（Professional Development Unit）について

各PMPは、資格取得の翌年から3年間で60PDU以上を取得する必要がある。（例；1998年5月にPMP資格取得の場合、PDPサイクルは1999年1月～2001年12月となる。但し、1999年以前に取得したものも加算できる）

せっかくだから維持したほうがいいのか、別に資格が大事なわけじゃないから維持するの止めてしまうか悩む。

会社は資格を取れというけど、その後は基本的に自主判断っぽい。いいほうに考えると、基本をちゃんと抑えるという目的でPMBOKを勉強させてるのかな。

普通にPM関連の仕事をしていれば、通常業務と自主学習（これくらいはちゃんとしてますよ）を合わせて3年間で30PDU。
全部で60PDU必要だから、残り30PDUは研修を受けるか、その他のPM関連活動で取得しなきゃいけない。

研修も単純なPMBOKの座学とかPMP試験対策みたいなのじゃ意味なさそうだし、その他のPM関連の活動もちょっと敷居が高いと感じちゃうし。

まじめに役に立ちそうな研修探して受けるくらいしか思いつかない。

PMIで活動しているような人を除く普通の人は、どうやって維持してるのかな。やっぱり研修とかE-Learningとか？
維持するコスト(お金＆時間)とPMP保持メリットを、みんなどう判断してるんだろう？

PDUは維持のために仕方なくやるものじゃなくって、自分の知識とか知見を身に付けるためのものだよ･･･という正論もあるとは思うけど。

僕と僕のサル以外、みんな何かを隠してる : Django を Apache で動かす（挑戦！）

Django という Python ベースの Web フレームワークがある。なんとか Apache で動かそうと思い、ドキュメントを見て悪戦苦闘している。
mod_python も Django もインストールされているのだが、どうしても EnvironmentError: Could not import settings と表示されてしまう。さて、どうしたものか・・・。

そういえば私も同じ状況になったことがある。
思えば基本的なことなんだけど、設定が微妙に間違ってたんだな。

例えば、/home/myuser/src/ に myproject というプロジェクトを作ったとすると設定はこんな感じかな。


SetHandler python-program
PythonPath “['/home/myuser/src'] + sys.path”
PythonHandler django.core.handlers.modpython
SetEnv DJANGO_SETTINGS_MODULE myproject.settings
PythonDebug On # 実運用はもちろんOffで



自分が間違っていたポイントは３つ。
１．PythonPathを設定していなかった
２．DJANGO_SETTINGS_MODULEの設定が「myproject/settings」となっていた
３．Apacheユーザーがディレクトリを読むパーミッションがなかった！！

当たり前と言えばそうなんですが、プロジェクトの置いてあるディレクトリをちゃんとPythonPathに設定して、DJANGO_SETTINGS_MODULEは普通にモジュールをimportするのと同じようにドット区切りで書けばOKのはず。
３はご愛嬌と言うことで許してください。

windowsでもパスをちゃんとwindows流の書き方をするだけで動くと思う。
[trac][Django][Subversion] trac と Django アプリケーションをapache+mod_pythonで

※ トラックバックを上手く送れなかった。うーん。

おとといの記事のNTTデータの社長の話でも、ちょっと契約形態の話が出ていた。

今、日本SIで通常行われている契約は大きく分けて委任契約と請負契約だ。

要件定義 or 基本設計までは委任で、開発は請負でというのが一応セオリー。
現状のシステム部門とSIerにとっては、これがお互いに一番リスクが少ないんだと思う。

上流部分はシステム部門もある程度関与を高めてコントロールし、開発自体はSIerに任せて自分たちは決められた予算を守れるようにする。
SIerからすると、海のものとも山のものとも分からない上流は委任でリスクを減らし、開発は請負契約しておいてできるだけコストダウンをはかり利ざやを稼ごうとする。

次は幾分偏見というかうがった見方も入っているけど、予算をオーバーしそうなときの言い訳をまとめてみる。

予算を超過しそうなときのシステム部門の言い訳は･･･
上流では･･･ユーザー部門が決めてくれなかった
開発では･･･SIerのせい、自分たちに非は無い（予算的にもそれほど痛くない、スケジュールは痛いけど）

ではSIerはというと
上流では･･･決めてくれないから仕方ない、かかった分だけ請求する
開発では･･･マネジメントして利ざやを稼ぐポイント、リスクを減らすために自分たちも請負で協力会社に依頼する

すべてがこんなにひどいわけじゃないけど、これじゃーだめなの分かるよね。
リスクを見すぎていいものを作ろうという観念がさっぱり抜けている。
これを体現した契約形態がNTTデータの社長のインタビューに現れていると思う。

ちなみにPMBOKの契約の項を見ると、日本流の契約形態とは違うことが書いてある。中でもインセンティブという考え方は日本ではほとんど無いと思う。
（日本流の契約とPMBOKで言うところの契約の違いはこのページによくまとまっていた）

開発コストを抑えながら、しかも良いシステムを作るためには、いまのままの契約方法では限界があるのかもしれない。
ある程度発注側もリスクを負って、委任＋インセンティブ契約などを考えていくべきなのかもしれない。
SIerもリスクを負って、発注側のシステム効果による成果報酬契約を考えるというのもありえる。

ネット企業のようにビジネスとシステムが直結しているときには、外注せずに内製が一番いいこともあるだろう。
（これなら従業員にインセンティブを与えやすいし）

何はともあれ、発注側もSIerもリスクをとってでも、新たな価値を生み出していかないといけない時代になっている気がする。
今までの慣習を壊すのが難しい or 失敗する可能性も高いのは分かるけどね。

何も考えずにソースをmakeしてインストールしちゃったけど、普通にパッケージになってるじゃん。
yum install erlang
ほんの少しバージョンは古いかもしれないけど、これでOKですね。すいません。
あとあと面倒くさいことにならないようにyumで入れ直しとこ。

自分用のメモだけど一応make installで入ったファイルはこれ。
cd /usr/local/lib/erlang && ./Install -minimal /usr/local/lib/erlang
　
for file in erl erlc epmd run_erl to_erl dialyzer typer escript; do \
rm -f /usr/local/bin/$file; \
ln -s /usr/local/lib/erlang/bin/$file /usr/local/bin/$file; \
done

家のLinuxが入っているマシン（Fedora Core6）にErlangをインストールした。
解説するまでも無いけど手順は以下のとおり。
wget http://www.erlang.org/download/otp_src_R11B-4.tar.gz
tar xvzf otp_src_R11B-4.tar.gz
cd otp_src_R11B-4
./configure
make
make install
で一応動いた。

# erl
Erlang (BEAM) emulator version 5.5.4 [source] [async-threads:0] [hipe] [kernel-poll:false]
　
Eshell V5.5.4 (abort with ^G)
1> 1 + 2.
3
2> io:put_chars(”Hello World\n”).
Hello World
ok
3>

ソースをダウンロードして10MB以上あったので覚悟してたけど、makeに思った以上時間がかかった。
Creating initial PLT (will take several minutes; please be patient)
とか言われたあとかなり待たされたのは、英語が読めなくて忍耐が無いだったら固まったと思って処理をとめちゃったかもしれない。（←たぶんこんな人はいないと思うけど）

これから少しずつ触っていってみるつもり。