8歳の息子と一緒に風呂に入った。
風呂で息子が歌った歌。
アンパンマーン、そこはだめーよ、だーいじなところ
ソーセージ、ミートボール、おいなりさんのかわー
息子の教育に一抹の不安を感じる今日この頃。
8歳の息子と一緒に風呂に入った。
風呂で息子が歌った歌。
アンパンマーン、そこはだめーよ、だーいじなところ
ソーセージ、ミートボール、おいなりさんのかわー
息子の教育に一抹の不安を感じる今日この頃。
21日にメール誕生25周年記念Eric Allman来日セミナーに行ってきたので、そのメモ。
同じ日に第5回インターナショナルGPLv3カンファレンスがあったので、Stallmanの話しを聞き終わったところで秋葉原から大手町に急いで移動して参加。なんでこういう会が重なるかなぁ。
会場にはEric Allmanの人生のパートナーであるMarshall Kirk McKusickも来ていた。昔BSD magazineでインタビューしたときに比べて、痩せていたし、年をとったように見えた。McKusickの横にいた若い白人の男の子は、彼らの養子かな?
講演は、年代順にメールに関わるトピックをあげて説明していくというもの。残念ながらSendmail社のサイトには講演の資料が公開されていないみたいだ。しかし、Eric Allman早口すぎ。同時通訳がまったくおいついていけなかった。この日も片耳で英語、片耳で同時通訳の日本語を聞いていたので、頭の中大混乱。;-(
以下、役に立たないメモ。
・sendmail以外にもいろいろなプロジェクトや研究に関わっていた。Syslog、Trek(ゲームだ!)、INGRES、RDBMS、ニューラルネットワーク、etc
・1969年9月2日:Arpanetの最初のノードができた。UCLAの1台のホスト。
・1971年後半:最初のメールが送付された。同年、UNIX 1.0リリース。
・1974年:Delibermail、エリック・シュミットが作ったもの。
・1978年:最初のスパムメールが送信された。DECの人間が新製品について告知したもの。後にこのメールを送った人間は謝罪した。
・1981年:ビル・ジョイに言われてsendmailを作る。当時、ビル・ジョイとは怒鳴り合ったりしていたとか。
・1982年:4.1BSDとともにsendmailをリリース。RFC821, 822がパブリッシュされた。
・1983年:4.2BSD
・1987年:UUNETが設立された。初の商業プロバイダ。
・1988年:初のインターネットワームが現れた。
・1988年:Make Money Fastチェインメールが現れた。Good Timesウィルス、初のメール添付ウィルス。
・1989年:Tim Berners-LeeがWWWを提案。
・1991年:CIX
・1992年:MIME
・1993年:Mosaicリリース。Berkeleyに戻り、sendmail 8.0をリリース。
・1994年:Netscape設立。グリーンカードスパムが現れた。意図的かつ謝罪せず。
・1995年:sendmail consortium設立。S/MIME
・1996年:Hotmail
・1997年:Yahoo!
・1998年:Sendmail Inc.設立
・1999年:Melissaウィルス
・2000年:USA政府、暗号化規制の緩和。milter、メールフィルター。
・2001年:Postfix。とてもよい技術だと思う。ただ、まだ足りない部分が多く、sendmailのライバルではない。
・2003年:Yahoo! Domain key
・2004年:Microsoft Sender ID、DKIM
・sendmail.cfがなぜあんなに複雑になってしまったのか? という質問に答えて。
sendmail.cfが複雑になってきて、まずいなと思ったとき、sendmailは20台くらいのマシンで動いていた。これを全部アップデートするのはめんどうだったので、そのままにしておいた。
21日、22日の二日間、GPLv3のカンファレンスに参加してきた。
参加する前は、GPLv3について法律的な議論をガンガンやる会議だと思っていたので、参加するべきかどうか迷っていたのだが、参加してみたらそういうものではなかった。ちょっと拍子抜けというか、もともとそのようなものではなかったらしい。もっと気軽にGPLv3も含めてフリーソフトウェアについて話し合う場ということだ。
下記にメモをあげておく。ただし、片耳で英語の発表を聞きつつ、片耳で同時通訳の日本語を聞くという離れ業(?)をやっていたので誤解もあるはず。上記サイトに資料もアップロードされているので、そちらを見てほしい。
・g新部さんが英語で発表するのを聞くのは初めてだ。とっても新鮮。
・GPLv3.fsf.orgのサイトはZope/Ploneで作られている。
・産総研内で、自由ソフトウェア武門というのをやっている。英語では、Free Software Fiters Group?
・日本のハッカーの数は、3000〜5000ぐらい(SourceForge.jpからの推測)。
・自分の興味はアプリケーションレイヤーから始まって、どんどん下へ下へと下がっていっている。
・ハードウェアにおけるフリーソフトウェアを提案したい。
・ハードウェアにおけるハッピーハッキング!
・ヨーロッパでは政府関係などでのフリーソフトウェアの採用が増えている。
・ヨーロッパで最も裕福な町の1つであるミュンヘンでもフリーソフトウェアへの移行が進んでいる。
・ミュンヘンの市長とビル・ゲイツの会話
市長「私たちにとって、これは独立するということなんです。」
ビル「いったい誰から独立したいのですか?」
市長「あなたからですよ。」
・ドイツの裁判所でGPLv2(英語)が認められた。この意義は大きい。
・ヨーロッパは大きくて強力なフリーソフトウェアのコミュニティを持っている。
・FSFE(Free Software Foundation Europe)は六人を専任で、二人をパートタイムで雇っている。
・現在、GPLv3の専門家の育生をしようとしている。
・Freedom Task Force(FTF)を作った。ライセンスの教育、ライセンスの普及が目的。
・フリーソフトウェアは大きな変化の時期にきている。
・GPLv3では国際化を進めた。多くの国の弁護士と一緒に仕事をした。
・distributionという言葉を使うのをやめ、propagete、conveyという言葉を使うようにした。
・GPLv3はApacheライセンス、Eclipseライセンスと互換性があるので、これらと統合できる。
・Tivoでは、GPLv2に従ってLinuxのソースコードが公開されているがハードウェアが変更されたカーネルの起動を許さないため、実質的にソフトウェアの変更ができなくなっている。
・Tivoのようなものを「裏切りのコンピューティング」と呼ぶ→コンピュータは普遍的にプログラム可能なマシンでなければならない。
・ある研究によるとLinuxカーネルは287の特許違反をおかしている。
・GPLv3にはMozillaライセンスをもとにした特許ライセンスが含まれている。
・GPLv3への移行期間などはない。GPLv3とGPLv2は混在して使用されるだろう。
・会場からOpen Sourceライセンスとの互換性についての質問がでるや、すかさず、
「Open Sourceにはなんの興味も無い。私と話しがしたければFree Softwareについて語ってくれ。」
と。Stallman節炸裂。Stallman元気だなぁ。さらに、
「Open Sourceはソフトウェアの開発技法にすぎない。Free Softwareは社会運動だ。」
と、いつもの主張も忘れずに。
1日目は、Stallmanの話しを聞いたところで別会場で行われたメール誕生25周年記念のEric Allmanの講演を聞く為に会場を後にした。
2日目は午前中は会社で仕事。午後に行われたパネルディスカッション2つを聞いた。以下、2日目のメモ。
・まつもとさんのパネル
RubyはArtistic-likeとGPLv2のデュアルライセンス。
正直、ライセンスのことはあまり考えたくない。シンプルでわかりやすいものがよい。
今はBSD Styleライセンスにしておけばよかったと思っている。
DRM、ソフトウェア特許、Webサービスの問題をライセンスで解決するのは難しい。ライセンス以外の方法で解決すべきだろう。
・岡村さんのパネル(難しいので、あまりメモしなかった)
GPLv3では、アメリカにはない著作者人格権についての配慮が必要か。
GPLv3は大学院で著作権を教えている人間にとっても難しい。素人が理解するのは困難。
・裕信さんのパネル
アメリカでの著作権はもともとアイデアを広く広めるために作られた。
しかし、本来の目的を忘れ、よくない方向に変化してきている。
Digital Millennium Copyright Act(DMCA)は大問題
DRMの問題。第三者がコントロールしてしまうため、我々は何もできなくなってしまう。
DRM = Tech + Law
Digital Gianism
・このセッション、あまりメモしてない。唯一メモしたのが、竹岡さんの発言。
ハリウッドの会社は、データバスからデータをリッピングされてしまうのでデータバス上を流れるデータを暗号化してほしいと言っている。
10月19日にjusの勉強会「現場力を高める見える化手法 プロジェクトファシリテーション」に参加してきた。
http://www.jus.or.jp/benkyokai/06-10.html
ずいぶん日にちがたってしまったが、メモをまとめておこう。
講師は株式会社永和システムマネジメント/株式会社チェンジビジョンの平鍋健児さん。
株式会社永和システムマネジメント株式会社チェンジビジョン
オブジェクト倶楽部
平鍋さんのブログ:An Agile Way
平鍋さんは、マインドマップとUMLを融合させたJUDEというJavaの開発ツールを作っている。JUDEには以前から注目していたので、今回の勉強会は楽しみだった。講演は期待以上におもしろかったし、懇親会では平鍋さんといろいろ話せてよかった。
以下、講演のメモ。・プロジェクトの成功はMoving Target
・ゆれるはしごに乗ってゆれるリンゴをつかむようなもの
・見えなければ制御できない。適応できない。改善できない。
・情報がぱっとわかる
・「現在の状況」も「結果」もわかる
・野球のスコアボード:静の情報が1カ所に大きく書かれていて、選手も客も審判もこれを見ている
・見える化はアナログでやる
・みんなが見る
・進捗の見える化
・行動をうながすツール
・異常を見えるようにする→レッドゾーンを作る
・1週間ごとに作る
・繰り返しのリズムを作る
・作業の見える化
・やることをリストアップ(ボードに付箋を貼る)
・ToDo(未実施)、Doing(実施中)、Done(テスト完)の3列に分けて管理する
・自分で付箋を取ってサインする→モチベーションがあがる。責任感、コミット
・ポータブルかんばんも便利(スーツにもベストフィット!)
・ソフトウェア開発は目で見にくい→物理的な物に置き換えて見えるようにする
・作業の明確化
・毎朝やる、リズムを作る
・かんばんの前で行う
・立ったままでやる
・時間は15分間
・議論が起きたら2次会へ回す
・部外者は参加させない(ピッグは参加、チキンは参加させない)
・ピッグ:自分の身を削ってベーコンを作る
・チキン:自分の身は削らず、卵を出すだけ
http://www.ObjectClub.jp/community/pf/
・異常の見える化
・異常を後に伝えない。その場で止める。
・欠陥の長期滞在を排除
・トヨタのやり方
・全受け入れテストを自動化し、バッチで流す。異常があれば即表示、原因追及。
・例:テストが通らないと点灯するランプ
・例:トラブルが起きると点滅、トラブルの内容をメンバーに周知すると点灯、トラブルを解決すると消灯
・このような道具をXFD(eXtreme Feed Device)と呼ぶ
・目標の見える化
・だるまの目は、beginとend
・ペアの討議内容の見える化
・小型のホワイトボード、1人1枚ずつ持つ
・「これはお前の問題だろう」を避ける
・2人でホワイトボードに書かれた問題に向かう(問題vs.私たち)
・100円ショップでホワイトボードのシールを売っている
・ソフトウェア内部構造の見える化
・UMLでなくてもよい
・ソフトウェアの全体構造がわかるものを壁に貼る
・指で指せるようにする
・日本でUMLを使っているのは10%くらい
・1週間の最後にやる
・改善の気づき
・Keep(良い点)、Problem(悪い点)、Try(次回挑戦)を出す
・ホワイトボードをKeep、Problem、Tryに3分割して行う
・Keepは定着する。ProblemはTryを生み出す
・定着した物には名前を付ける
・カジュアルな雰囲気で全員が発言するようにする
・「問題vs.私たち」にする。あなたと私の話にしちゃだめ
・イテレーション=1週間
・プロジェクトやリリースの回顧
・ふりかって前を向く
・ホワイトボードにプロジェクトの時間(日付)を書き、ここに個人の物語を付箋に書いて貼る
・付箋の色で感情を表す。青=喜び、赤=怒り、黄=驚き
・自分の物語からぼくらの物語にする
・プロジェクト終了後のヒーリング
・このあと打ち上げをやる。飲み会重要!
・頭の中の見える化
・思い出す為のフックになる。プレイバック効果
・時間がなかったので、このトピックは話してもらえなかった
・建設/土木現場で行われるリスク管理手法
・これも上記同様、話してもらえなかった
・複数人の頭の中を一気にまとめる
・チームのムードを見える化
・帰宅時の気分をシールで表して貼って帰る
・気持ちよく仕事を終えられた、普通、だめだめ、の3種類
・とにかく壁に貼れ
・進捗はバーンダウンで
・日々の作業はかんばんで
・朝会を行い、作業を自発的に宣言
・異常はあんどんで
・見える目標をおいて
・ペアボードで話し合い
・アーキテクチャは色付きUMLで
・イテレーションごとにふりかえり
・アイデアはマインドマップで
・リスク管理はKYミーティングで
・複数人のナレッジをSKMSで
・平鍋さんの造語
・プロジェクトの中でのファシリテーションのあり方
・ファシリテーションとは、促進する、助ける、円滑にする、場を作る
・5つの原則:見える化、リズム、名前付け、問題vs.私たちの構図、改善
デッドフィッシュ:デスマーチになると会議をやっている真ん中に死んだ魚がいるのに、だれもその魚について話さなくなる。腐ってプンプン臭っているのに! →話せ!
トラックナンバー:プロジェクトのメンバーが何人トラックに轢かれてもだいじょうぶか? という数。ハネムーンナンバーとも言う。
・JUDE(http://jude.change-vision.com/)
・TRICHORD(http://trichord.change-vision.com/)
・簡単なものからやってみる
・工夫する
・押し付けない
・若い人と一緒にやる
・ポストイットや模造紙くらい自分で買おう
・Life Hacks
・水にぬれずに泳ぐことはできない
・禅:修行と悟りは同じ
・やることとわかることは同時に起こる
・『トヨタ生産方式 ——脱規模の経営をめざして』大野 耐一
・『XPエクストリーム・プログラミング入門 ——変化を受け入れる』ケント・ベック
・『リーンソフトウェア開発 ——アジャイル開発を実践する22の方法』メアリー・ポッペンディーク
・"Crystal Clear: A human-powered Methodology For Small Teams" Alistair Cockburn
・『アジャイルプロジェクトマネジメント ——最高のチームづくりと革新的な製品の法則』ジム・ハイスミス
・『達人プログラマー ——システム開発の職人から名匠への道』デビッド・トーマスほか
なんかもううんざりしてきたので、この話題はこれが最後。
いろいろエントリが増えているけど、下記の2つだけ。あいかわらずこの人の文章は意味がよくわからないのだが、たぶん以下のようなことを言っているんだと思う。
フルバッチ、数式組版の標準化と写研が広げた制作手法の狭間で(5)
大学の先生のなかに、TeXの生原稿を印刷所に入稿し、この出力の品質をTeXの限界を超えて(?)上げるように要求する無茶な先生がいる。このような無理な要求をする先生のおかげで、印刷所はたいへんな苦労を強いられている。
今後の自動組版システムは、
Word(Mathtype)→xml→MC-B2(モリサワの組版ソフト)
というものになる。 TeXの原稿はいったんWordに変換してから処理すればよい。しかし、組版システムをかえたからといって、上記の問題が解決するとは思えない。どんな技術にも限界はある。その限界を顧客(大学の先生)にきちんと説明できないようでは、どのような技術を採用したところで問題は生じるだろう。
結局問題なのは、顧客との間に信頼関係を築けていないことだ。印刷所は立場が弱いから、というようなことが書いてあるが、たとえ立場が弱くても言わなければいけないことはあるし、顧客が納得するまで話し合わなければいけないことがある。それができないというなら、泣くしかない。
ようするにこれは技術の問題ではなく、コミュニケーションの問題だ。
コミュニケーションの問題を技術の問題にすりかえて、「このシステムを導入すれば解決できます」みたいな言い方をするのはまちがっていると思う。
vm_converterさんからトラックバックをもらったので、こちらからもトラックバックを返しておこう。
私もBSD magazine付録のストラップを今でも使っていますよ! (^^)
で、ここから本題。
「TeXは悪くない」で取り上げた話のネタ元のブログをいろいろ読んでみた。
確かに、これからの数式は、あまりに多様化してばらばらになってしまったTEXから、という発言をするのも当然だろう。TeXに対して否定的であってもなにも不思議ではない。
Wordにも掲載されたMATHTYPEがメインになるだろうと言われています。
なんかよくわからん議論が続いている。
「TeX入稿についての誤解」についての誤解まだソフトバンククリエイティブのWebサイトには出ていないみたいだけど、決定らしい。
ほかにも12月で休刊になるLinux/OSS関係の雑誌が数誌あるとか。
UNIX USERからの誌名変更パーティーに出たのは、ついこの間だったよなぁ。1年ほどしかもたなかったか。
IT系の技術雑誌が壊滅するのは、たんに時間の問題なんだよね。そんなことは数年前からはっきりわかっている。
実売部数の低下と広告料金の減少をくい止める術が無い。
問題は紙の雑誌をつぶした後に何をやるかなんだけど。今のところ答えが見つかっていない。
@ITのまねごとやっても、LinuxやOSSでは広告が集まらないだろうし。
結局、広告がつかない情報は、個人がボランティアで出すもの以外流通しなくなってしまうってことか。
いかん、ぐちになってしまった。
しばらくほっておいた某サーバのZopeを2.8.5から2.8.8へアップデートした。
以下、手順のメモ。
・まずはzope.orgからZope-2.8.8-final.tgzをダウンロードして解凍する
・次に解凍してできたディレクトリで、
./configure --prefix=/usr/local/Zope-2.8
make
としてzopeをビルドする
・次にrootになって
make install
としてzopeをインストールする
・ここで古いzopeのインスタンスをディレクトリごとバックアップしておく
mv zope zope.old
・次にインストールしたzopeのディレクトリ以下のbinディレクトリにあるmkzopeinstance.pyを起動してzopeのインスタンスを作成する
/usr/local/Zope-2.8/bin/mkzopeinstance.py
として、インスタンスのインストール先ディレクトリ、管理者の名前、パスワードを答えればインスタンスディレクトリが作られる
・バックアップしておいた古いzopeインスタンスのvarディレクトリのData.fsを新しいインスタンスのvarディレクトリにコピー
・必要なプロダクト(Plone 2.1.4, jaMailHost, ejSplitter)を新しいインスタンスのProductsディレクトリにコピー
・chownコマンドでインスタンス以下のオーナーをzopeを起動する一般ユーザに変更
・zopeを起動する一般ユーザで再ログインして、インスタンスのbinディレクトリにて
./zopectl start
として、zopeを起動する
・Ploneをアップデートしたので、その処理をして終了
Plone 2.1.4が出ているので、このブログサイトを2.1.3からアップデートした。
以下、メモ。
・plone.orgからPlone-2.1.4.tar.gzをダウンロードして解凍
・とりあえずData.fsをバックアップ
・Productsディレクトリに解凍してできたフォルダをまとめて上書きコピー
・ZMIからZopeを再起動
・Ploneの管理者でログインしてZMIにアクセス
・!マークのついているportal_actにアクセスして、Version_Migrationタブを開き、Upgradeボタンをクリック
・同様に!マークのついているportal_migrationにアクセスして、Migrateタブを開き、Upgradeボタンをクリック
・Ploneの「サイト設定」から「プロダクツを追加・削除」にアクセスして、改訂版がでていると表示されている部分を順番にクリックしてアップグレード
以上で、アップデート終了。
とにかく濃い3日間でした。はい。
35人という大人数で、しかもあの濃さはなんでしょう(笑)。
オブジェクト指向入門という初心者向けセッションがあったので助かりましたが、これがなかったらついていけずにかなりつらかったかも。
和訳プロジェクトは増田さんから浦郷さんにバトンが渡されました。2.5の和訳、浦郷さんはじめスタッフの皆さん、がんばってください。
和訳には本当にお世話になっているので、よろしくお願いします。いつも感謝しております。
Djangoは熱かったですね。TurboGearsのほうは人がcoolなのかな。今回は人数的にDjangoの人が多かったよう。
帰りはJackさん、阿部さん、竹内さんと私の車で帰りました。でも運転はほとんどJackさん。
Jackさん、ありがとうございました。同乗したみなさん、うなぎはなんとかなったので、ご安心を(笑)。
主催者の柴田さん、プログラミングスタッフの皆さん、お疲れさまでした。すばらしいCampをありがとうございます。
冬にも開催予定とのことで、今から楽しみです。参加者の皆さん、冬にまたお会いしましょう。
Python Developers Camp 夏、最終日朝の成果発表のメモ。
各自手を動かしながら自主トレに励んだ
初心者の質問をもとにドキュメントをまとめた
翻訳スプリントでは各自が選んだPEPの翻訳を行った。発表者には先着順でSpamをプレゼント!
(以下出てくる番号はPEPの番号)
阿部:遅刻しました。すみません。245と246をやろうとした
245は言語拡張の話、246はアダプテーションの話
内容が難しく、難航しそう。
ただ、ZopeやTwistedでもアダプテーションは利用されている。
また、GuidのPythonに静的な型を入れようとする提案にも関係するので、なんとかしたい。
Jack:うう、早すぎてメモとれず。
Jackさんのやった翻訳が公開された(http://ns.jk.to/zwiki/Nikki/PEP0263)
浦郷:357をやった。どのオブジェクトでもスライスに利用できるという話。
小倉:関数デコレータをやろうと思ったが、英語が難しすぎたので、try exceptのPEP 341?をやった。
小田切:333 WSGI? をやろうとしたが、量が多かったので、現状1割もいっていない。Webサーバとアプリケーションを結ぶ話。
一人でやるのはつらいので、皆さんの力を貸してほしい。
竹内:339をやった。CPythonのコンパイラの情報。英語の意味はわかるけど、日本語の適当な訳語を思いつかないものがあった。
ドラゴンブックの日本語版を読んで訳語を見直したい。
柴田:PEP3000シリーズ、Python 3.0で言語の中身を変更する予定なので、具体的にどこが変わるのかを書いてある。4つある。
3つ目までは訳してある。4つ目をやろうとしたが酔って眠ってしまったので、これからやる予定。
増田:354、列挙データの話。200行くらい。2日でやるにはいいサイズ。
石田:TurboGearsでシンプルなチャットシステムを作った。ブラウザから2秒おきにリクエストを投げている。
安井:TurboGears、CherryPyを使った。裏でsocketを張りっぱなしにしている。
課題はいろいろあるが、TurboGearsである必要がないのが一番問題。
でも、CherryPyやMochiKitをうまく利用できるのがTurboGearsのいいところだと思う。
田原:zope3を使った。zope3はテストドリブンなフレームワーク。朝いじったらテストが通らなくなった、でもプログラムは動いている。
露木:DjangoとTwistedを使おうと思ったが、今回はDjangoのみで作った。AJAXでポーリングをしている。
Djangoのテンプレートはすごい。継承が使いやすい。管理画面がすごい。Django勉強会開催中。
山下:Djangoを使った。昨晩Twistedをはじめてさわって、ぜひ使いたいと思った。
今回はまにあわなかったが、Djangoからキックして、Twistedからブラウザにデータを送るようにしたい。
柴田:Pythonic Chatを作った。TurboGears 1.0ベータを使った。TurboGearsの管理画面もDjangoにまけていない。
Djangoはエンドユーザに近い人が使うフォームまで自動生成しているが、TurboGearsではwidgetを使ってごりごり作るようになっている。
Pythonic Cahtは関数型チャットシステム。チャット中に関数を定義できる。チャットで関数を定義し、これを実行できる。
定義した関数はデータベースに保存される。ただし、インターフェースの制限から関数は1行で書かないといけない。
増田:Mimimal Django Chat、DateBased Generic Viewを使った。モデルとテンプレートを書くだけでOK。
さっき9時ごろから作り始めた(メモを取っている時間は11時26分!)。テーマはやっつけ!
おおたに:席をはずしていたのでメモとれず。
村岡:Twistedは素人にはお勧めできない。英語力が必要。マニュアルの翻訳がほしい。
SQLAlchemy、O/Rマッパー、使いやすい。クライアント→Twisted→SQLAlchemy
Django、TurboGearsでも使うようになるので、勉強しておくとよい。
ZopeInterfaceとは、Pythonにインターフェースとアダプタ機能を加える為にZope 3チームが作った
インターフェースとは定義と実装の分離
目的は多重継承によるクラスの誤用を防ぐ
インターフェースはインスタンス
アダプタとは、あるクラスのインターフェースを異なる他のインターフェースへ変換するAdapterパターン
インターフェースはアダプタを実現する為の呼び出しが可能
インターフェースは__adapt__メソッドを実装
コンポーネント指向の実現を目指している
静的な型をPythonに導入する事で「実行が遅い」「実行しないとエラーが発見できない」というデメリットの解決をはかろうとしている
def foo(x: int, y: int) -> int:のように書く
誰も成功していない動的言語における静的な型の導入
Python Developers Camp 2006 夏の2日目夜に行われたライトニングトークのメモ。
小田切篤
クラスもオブジェクト
クラスのクラスがメタクラス
Pythonの中ではtype関数を使って動的にクラスを作ることができる
typeはクラスなのでサブクラスを作ることができる
このとき、selfではなくclsを使う
契約による設計
事前条件
事後条件
不変条件
関数デコレータ
まにあわなかった
私には難しすぎる内容
田原悠西
デコレータはPython 2.4から入った機能
@の次にcallableなオブジェクトの名前を書く
基本的には単なるシンタックスシュガー
デコレータは合成関数を作るもの
デコレータは縦に並べることもできる、適用は下から
フレームワークでデコレータが提供されている場合が多い
もっと使いこなすならdescriptorを勉強すること
西尾泰和
Pythonワンライナーのお話、LLRingでやったやつ
JythonとはJava VM上で動くPythonの実装系
以下デモンストレーション。なかなかおもしろかった
GRINEditのWebサイト(http://www.nishiohirokazu.org/grinedit/index.html.ja)
石坂忠広
.Net Framework上で動くPythonの実行環境
.Net Framework上で動作する最初の本格的なスクリプト言語
Jythonを作ったJim Hugnin氏がMicrosoftで開発している
Microsoftのプロジェクトだが、オープンソース?
.Net Framework 2.0ランタイムが必要
Iron Python 1.0のインストールが必要
Python 2.4のインストールも必要
Mono 1.2版がでるという話
コンパイルなしで動くのは気持ちいい
Windowsアプリが簡単に作れる
WMIの機能を使用した管理スクリプトが書ける
COMとの相互運用も可能
x64対応が何も考えずにできる
さよならVB Script(石坂さんはMicrosoftから認められたVBのMVP)
基本的にはCPythonと同じ
ライブラリの中でC言語のライブラリを使用しているものは使えない
おいしいところは実は使えない
文字コードはUnicodeしか使えない
CodePlexからダウンロードできる(http://www.codeplex.com/Wiki/View.aspx?ProjectName=IronPython)
Mixiにもコミュニティがある
www.isisaka.com/blog/石坂さんのブログ
日本語の情報はほとんどない
Windowsのexeが作れる
Visual Studioに入るかどうかは微妙、ユーザがどれくらい増えるかにかかっているかも
Monoとの互換性には問題がある。特にXML。Monoは標準にこだわるが、MSは動く事が最優先。
発表資料(http://www.isisaka.com/Portals/0/Iron%20Python%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6.pdf)
Python Developers Camp 2006 夏、2日目の午前中に行われたオブジェクト指向入門セッションのメモ。
森亮靖
ウォーミングアップ
Pythonにおけるオブジェクト指向はあくまでもオプション
オブジェクト指向を知らなくてもプログラムが書ける
継承の概念を理解するのが重要
classステートメントで作るオブジェクトはビルトインオブジェクトによく似ている
Pythonのオブジェクト指向プログラミングはC++やJavaに比べると易しい
ダイナミックな型付けのおかげで前もって変数を宣言する必要がない
type()を使って、オブジェクトの型を調べることができる
dir()を使うとオブジェクトの属性を調べることができる
IDLE環境でビルトインオブジェクトをいろいろ調べると勉強になる
IDLE環境でタイプ中にポップアップするヒントは学習にとても便利
クラスとインスタンス
クラスとは自分で作れる型だと思えばよい
listなどのビルトイン型は外から見ている限りクラスのように見える
listを呼び出すとインスタンスオブジェクトができる
listを継承してサブクラスを作ることができる
listが便利だと思えれば、クラスの便利さも理解できる
classステートメントが実行されるとクラスオブジェクトが作成される
このクラスオブジェクトがビルトイン型と同じような働きをする
メソッド
オブジェクト自身が持っている自身に対する操作
Python的にはclassステートメントのボディーにネストされたdefステートメントで定義
self引数を理解する、インスタンスを渡す
1つだけの要素のタプルを使うときは(a,)のように,をつける。初心者がはまりやすい。
コンポジション
オブジェクトのなかにオブジェクトを組み込むこと
あるクラスのメソッドのなかで他のクラスのインスタンスを作成する
このようなクラスをコンテナオブジェクト、メソッドをコンテナメソッドと呼ぶ
演算子のオーバーロード
名前の前後に2つのアンダースコアがついた特殊なメソッドを使う
このようなメソッドをフックメソッドと呼ぶ
たくさんあるので、それぞれ調べると便利
コンストラクタ
インスタンス作成と同時に何か処理をしたいときは、__init__という名前のメソッドを使う
__init__をコンストラクタと呼ぶ
IS-A関係
スーパークラスとサブクラスの関係
HAS-A関係
コンポジション
ポリモーフィズム
同じ名前のメソッドでもクラスによって意味が変わる
抽象クラス
機能の一部をサブクラスに依存するクラス
サブクラスで機能を実装しないといけない
継承の話
デリゲーション
委任、委譲などと訳される
コンポジションの話
Pythonでは__getattr__というメソッドを使う
処理をあるオブジェクトからそのオブジェクトに組み込まれた他のオブジェクトへ委任すること
カプセル化
カプセル化とデータの隠蔽は別の話
カプセル化とはクラスの中にデータ/メソッドを封じ込めること
Pythonではデータの隠蔽はできない
クラスやインスタンスの属性はあらゆるプログラムで利用でき、値の抽出、値の変更を自由にできる
データ隠蔽は不要という意見もある
ファクトリ
クラスを渡すとインスタンスが返ってくるという関数
C++などではむずかしいが、Pythonでは簡単に作れる
非結合メソッド
<クラス名>.<メソッド名>という形で呼び出されたメソッド
第一引数にインスタンスを指定する必要がある
結合メソッド
<インスタンス>.<メソッド名>という形で呼び出されたメソッド
自動的にインスタンスが渡される
新スタイルクラス
ビルトイン型を継承したクラスは新スタイルクラス
そうでないものはクラシッククラス
適当なビルトイン型がないときはobjectというビルトイン型を指定すればよい
多重継承のときのオブジェクトツリーの検索順が違う
__slots__属性
インスタンス属性の名前を特定のものに限定することができる
スペルミスしたときに新しい属性を作ってしまわないようにできる
Python Developers Camp 2006 夏、2つ目のセッションのメモ。
増田泰
和訳プロジェクトのサイト(http://www.python.jp/Zope/pythondoc_jp/)
自分は時間が取れなくなってきたので、後進にがんばってほしい。
なぜ和訳するのか
自分のため
何度も英語を読み直すのはめんどう
コンテンツが人と情報を引き寄せる
他人のため=自分のため
頼れるリファレンスの存在はローカルコミュニティの起爆力になる
試行錯誤のコードが減る→信頼性が増す
和訳ドキュメントに何が必要か
有益:お得感はユーザの向上心をあおる
可読:より広範なユーザを獲得できる
正確:正確な情報はソフトウェア自体の信頼性も高める
ドキュメントどおりにやってうまく動かないとソフトウェアの問題にされる
完全:完結したドキュメントは読み手にも書き手にも安心感をもたらす
一部だけいつまでも翻訳されずに残っていると不安をもたらす
新鮮:更新され、改良され続ける技術にこそ価値がある
Pythonの和文情報
標準ドキュメント
2ch:Pythonのお勉強まとめWiki
オンラインドキュメントリンク集
日本語PEP集
標準ドキュメント
Pythonソース配布物についてくるドキュメント
15000行、6Mbytes、1608ページ(CVS HEAD)
ドキュメントの形式
書式はLaTeX
python.sty(pythonjp.sty)
ページサイズ設定、主要なマクロ定義
manual.cls/howto.cls(manualjp.cls/howtojp.cls)
構成(目次の有無など)設定
make, python, perlを使ってビルド
PDF, HTML, isilo, CHM対応(日本語ではisiloは出せない)
PS/PDF:latex(2e), Ghostscript, dvipdfm
ビルドシステム
TeXのソース(euc)からUTF-8のPDFを作る
同じくTeXのソースからsjisのHTMLを介してCHMを作る
和訳ドキュメント固有の特徴
TeXソースはeuc-jp-unixで記述
和訳プロジェクト
標準ドキュメントの和訳とメンテナンス
成果物はPSF Licenseで公開
PEPや3rd partyモジュールのドキュメント和訳も公開
翻訳スタッフは随時募集
2.4を訳了したけどしんどかった。
2.5が出ているが、3000行くらい追加で訳さないといけない
現スタッフは息切れぎみ、アクティブな人が減っている
アクティブに動く人があと5人くらい欲しい
ビルドシステムのただ乗り(すでにシステムがあるのでこれをそのまま利用できる)
mkhowto_jpを起動する
mod_pythonのビルドMakefileを使う
必須:Python + Perl
和訳ドキュメントソース
python mkhowto_jp (options) toplevel.texで作れる
ReStructuredTextの翻訳
利点
ビルドしなくても読める。配布できる
PDFやHTMLに変換できる
PEPや多くのモジュールのREADMEで採用
注意すべき事
推奨文字コード:euc-jp
タイトルやテーブルの幅:ワイドグリフ
マークアップの境界をASCII文字にする
日本語タイトル
ReSTドキュメントのビルド
rst2html.pyを使う
私的和訳の進め方
エディタは等幅フォントを表示できないとだめ
辞書:おすすめはリーダースCD-ROM
日本語力は英語力より重要
googleで英語と日本語の和訳の候補を入れて検索して、その訳が妥当かどうかを検証する
翻訳する底本を選ぶときは、できればバージョン管理されているものを選ぶ。リポジトリから差分がとれるので、便利。
必ずライセンスを調べる。わからないときは著者に問い合わせる。無反応なときは暗黙の了解ができたと考える。
注意すること
一貫性:最低、用語と文体をそろえる
背景知識:勉強になる
可能な限り原文を尊重する
私見を入れない
和文/英文リンクの併記
やってはだめなこと
翻訳ソフトを使う→甘えのもと
翻訳ソフトの訳は後でいくらいじってもまともにならない
訳し終わったら
原文作者に連絡を取る
MLなどに宣伝
手放したければリポジトリを公開するのがいい
和訳にもっとも必要なもの、それは愛だ!
Pyhon Developers Camp 2006 夏へ参加してきたので、メモを公開。
まず1日目のセッション1つ目。
おおたにさん
Twistedって何?
グロテスクです。
イベント駆動型のネットワークプログラミングのフレームワーク/ライブラリ
Twistedを使っているアプリケーション
BitTorrent
AppleのiCal WebDAVサーバ
Xen
Zope3
ほかにもいろいろある
ネットワークプログラミングのスタイル
・同期型
ブロッキングIOを使っている
・非同期型
ノンブロッキングIO
select/poll
イベント駆動
非同期型
Connectをコールしたときに待たない
Connectが成功したときにイベントがあがる
ネットワークが読み書きできるとイベントがあがる
同期型はプログラミングが簡単
非同期型はとってもめんどくさい。とくにTwistedを使わないとめんどくさい。
めんとくさいものを使う理由
ネットワークとCPU効率の問題
ネットワークプログラミングはとにかく待ちが多い
スレッド/プロセスのコンテキストの切り換えはコストがかかる
同期型で効率を考えると→スレッドをたくさん作る
非同期型だと1つのスレッドで複数の接続を処理できる
非同期でやりたい理由
マルチスレッドの処理はスレッド間の同期がたいへん。人がやるプログラミングじゃない。
WebChat + AJAXの場合
・同期型
AJAXで定期的にPolling
AJAXで送信専用接続と受信専用接続
・非同期型
AJAXで送信専用接続と受信専用接続(新たなデータがきた時点でレスポンスを返す)
普通のWebサーバじゃできない
非同期の問題
すべて1つのスレッドで行う
重い処理があるとプログラム全体がブロックする
重い処理はスレッドを別に作らないと効率がかえって落ちる(スレッド間の同期問題が発生してたいへん)
結論
どちらが優れているかは一概には言えない
どちらのプログラミングモデルを使うかは作りたいものによる
魔法の杖は今のところない
非同期プログラミングというと
Twisted
標準ライブラリのasyncoreがある
標準ライブラリじゃだめなのか?
1つの処理だけなら十分
複数の接続+複数のプロトコルを扱うと力不足
asyncoreはAPIが嫌い
Twistedは?
複数の接続、複数のプロトコルを統一的に扱える
低レベルから高レベルまでAPIが用意されていて、好みに応じて使い分けられる
例レベルなAPIが好き
Twistedの恐ろしいところ(すごいところ)
ネットワークはTCP/UDP/Unix Socketなどをサポート
ファイルアクセスも非同期で処理できる
データベースも非同期で処理できる
Linuxならコンソール(標準入出力)まで非同期で処理できる(でもめんどくさい、お勧めしない)
待ちが発生しそうなことはたいてい非同期で処理できる
select/pollを使わずにWin32のイベント処理に置き換えられる
Twistedの基本
Reactor
Deferred
Factory
Protocol
この4つがわかっていれば、ほとんどのことはできる
Reactorとは?
イベントループ
イベントに応じてコールバックを実行
スケジュール管理
select/pollだけじゃなく、Win32, GTK1,2, QTなどのevent loopなども使用可能→クライアントのGUIプログラミングと親和性が良い
Twistedを使ってクライアントを作る場合、WindowsだとWin32のイベントループをReactorに置き換えることで既存のコードをあまりいじらずに利用できる
Deferrdeって?
コールバック関数、エラーバック関数を複数登録
登録したものが順次実行される
factoryとprotocol
Factoryは接続が確率されたときにprotocolオブジェクトを作る
protocolオブジェクトは接続中は生存。接続が終わると破棄
protocolオブジェクトは、ネットワークに送受信されるデータのハンドリングを行う
protocolオブジェクト間のデータの受け渡しはfactoryを介して行う
高レベルなこと
自分でHTTPやSMTP, IRCのプロトコルを書くのはめんどう
Twistedのサブプロジェクトが多くのプロトコルをサポートしている(ものによってできはさまざま)
Web関係はHTTP Protocolの上にさらに独自のフレームワークが用意されている
さらに高レベルなこと
独自のスクリプトの仕組みがある、文法はほとんどPythonと同じ
アプリケーションのフレームワークがある。
UnixのデーモンやWindowsのサービスに簡単にできる
おまけ
Twistedはサーバで使える
クライアントでも使える
クライアントではTwistedとpy2exeとかを使えば配布が楽
質疑応答
止めるのはどうやるのか?
stopというメソッド?がある
Win32がわかっているプログラマでないときつい。特に問題が起こったときにたいへん。山のようにコールバックが帰ってきてわけがわからなくなる。どうやって解決しているのか。
どうしているんでしょうねぇ(笑)。
Mac OS X上のPython開発環境を整えようと、Python Developers Campの前夜に思いついて四苦八苦。
まずは最新のPython 2.5(python-2.5-macosx.dmg)をPyJUGのサイト(http://www.python.jp/pub/ftp.python.org/python/2.5/)からダウンロードしてインストール。これで、/usr/local/binにPython 2.5が入る。
ただこのままだと/usr/binにあるPython 2.3が先に呼ばれてしまうため、PATHの検索順序を変更して/usr/binよりも/usr/local/binを先に検索するようにしないといけない。通常のUnixであればホームディレクトリの.cshrcなり.bashrcなりにPATHの設定を書けばいいのだが、Mac OS XでこれをやってもemacsからPythonを呼ぶと/usr/binのPython 2.3が呼ばれてしまう。
結局、ホームディレクトリに~/.MacOSX/environment.plistというファイルを作って、これにPATHを設定することで解決。
設定内容は下記の通り。
<?xml version="1.0" encoding="UTF-8"?>参考:http://developer.apple.com/qa/qa2001/qa1067.html
<!DOCTYPE plist SYSTEM "file://localhost/System/Library/DTDs/PropertyList.dtd">
<plist version="0.9">
<dict>
<key>PATH</key>
<string>/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/X11R6/bin</string>
</dict>
</plist>
M-TAB | 補完 |
C-c C-c | バッファの内容を Python で実行 |
C-c C-r | リージョンの内容を Python で実行 |
C-c C-s | 任意の式を Python で実行 |
C-c C-z | Python の出力を表示 |
23日の土曜日は調布の布田天神のお祭りだった。
先日入隊したスカウトのリーダーから参加するように誘われたので、息子をつれていく。
息子は、友達と一緒にお祭りのはっぴを着て、豆絞りのはちまきを締めて、半日太鼓を引っ張って布田の町を練り歩いた。
最後にお菓子をたくさんもらって大満足かな。途中でスーパーボールすくいもやらせてもらったようだ。
私も妻も地方出身なので、ここでは完全なよそ者だ。しかし、スカウトに入隊したことで地元のコミュニティに息子を参加させることができるようになった。これは、うれしい副作用だ。
これからも機会があれば、どんどん参加させよう。
お祭りを見て歩いていた妻が、KENNY'sというアイリッシュパブを見つけた。
なにせ夫婦で、調布にはギネスの生を飲ませる店がないと嘆いていたところだったので、さっそく夕飯を食べにいく。(^^)
ギネスとキルケニーの生を1パイントずつと、ミックスナッツ、フィッシュアンドチップス、シェアードパイを食べる。満足、満足。
お店の人に聞いたところ、今年の6月に開店したばかりだとか。これからごひいきにするので、ぜひつぶれずにがんばってもらいたいものだ。
KENNY's http://chofu.shop-info.com/kennys/
数年前にも同じようなことがあって、ずいぶん不愉快な思いをしたことがある。
しかし、ヘッドハンターというのは相手の職業も知らずにハントするのかね?
あまりといえば、あまりにも馬鹿すぎ。
鈴木嘉平です。
やはりわかっていないように思います。
私は出版社に勤めている編集者ですよ。ITエンジニアではありません。
XXXX wrote:
> 鈴木様
>
> ご連絡ありがとうございます。
> それでは早いお話ができるかと存じましたが、前回は良いお話ではなかったのですね。
> 職業までは把握しておりませんが、今はガリガリ現場的なことをなさっていなくとも、
上流工程、ビジネスコンサルができる知識をお持ちと伺っております。
>
> -----Original Message-----
>
> XXX 様
>
> 鈴木嘉平です。
>
> 以前、ヘッドハンティングを受けた経験はあります。ただ、先方が私の職業を完
> 全に勘違いしていてひどい目にあいました。
> あなたは私の職業がなんであるか、きちんと把握されているのでしょうか?
>
>
XXXX wrote:
> 鈴木様
>
> 突然のご連絡、大変失礼いたします。
> 私、XXXと申します。
> 当社は、東京は溜池山王に事務所を構えております外資系人材紹介会社です。
> (是非当社WebサイトXXXにもアクセスしてみて下さい)。
>
> この度、大手外資系金融企業からのご依頼でインフラスペシャリスト(プロジェクトリーダー、
マネージャー、及びビジネスコンサルタントクラス)を探しておりまして、当社のヘッドハンティングを
目的として活動しているリサーチチームより、貴殿が現在大変ご活躍されていると伺いまして、ご連絡
させていただきました。
> 今までにヘッドハンティングを受けたご経験はおありでしょうか?
>
> 詳細は近いうちに、直接お会いしてご説明したいと思っておりますので、よろしければご都合の宜しい
日時をお知らせ頂けませんか。
>
> もし今すぐのご転職をお考えでなくても、一度お会いさせて頂いて情報の一つとしてお話しさせて頂け
ましたら幸いです。
>
> ご連絡いただけますことを心よりお待ちしております。
> 宜しくお願い致します。
9月17日は息子のカブスカウトの入隊式だった。
スカウトの制服に身を包み、団旗に左手を沿え、右手を高く上げて誓いの言葉を述べる息子を見ていると、自分の子供の頃を思い出す。私は小学校5年生から高校卒業までスカウトとして活動していた。キャンプやナイトハイクなど、楽しい思い出がいっぱいある。
息子もスカウトとしての活動を楽しんでほしいと思う。まず最初は赤い羽根の募金活動かな。
9月16日に行われたOpen Source Summit 2006に行ってきた。
特に何も書かずにいたわけだが、きんねこさんが
参加プロセスがオープンでないイベントなので、参加者はフィードバックはオープンにしないとね(^^)。
と言っているので、何か書いておこう。
Summitという名前はどうかと思うが、オープンソース関係の濃い人たちが集まったことはたしか。全部で40人くらいか。IT系の出版社からも各一名ずつ参加者がいたのが、ちょっと不思議。
以下、メモを取っていなかったので軽く感想なんぞを。
最初に行われたライトニングトークで印象に残ったのは、日本Sambaユーザ会太田さんの話。
というコミュニティのライフサイクルを感じてしまった。
あと、NoBUG佐々木さんの地方とオープンソースの話。
企業に行って、「オープンソースを導入しましょう」と言うと、「そういうの決められるのは東京なんだよね」と言われちゃうと。これは結構つらいな。
あとの発表については、吉岡さんの日記を見てもらいたい。
ライトニングトークの後自由討論になったわけだけど、どんな本なら売れるのかね? といった、どちらかというと出版関係の話をしてしまった。そのテーマで原稿書ける著者が日本にいるの? とか、誰それさん原稿書かない? とか。我ながら編集者っていうのは、しょうもない人種だよな。どこでもいつでも著者探しだ。;-(
5時半からは飲み会。スタート早い!
飲み会では、きんねこさんに会えたのがうれしかった。でも、聞いたのはつらい話だった。二年前の夏から行っている歯列矯正だが、ここにきてちょっと停滞気味。前歯がうまく動いてくれない。
医者曰く、
「舌の裏側の筋が短すぎて、舌の位置が正しくならないため、舌が歯を押してしまって矯正できない。矯正を進めるためには舌の筋を切って、舌の位置を正す必要がある。」
とか。実は、舌の筋が短いという話は歯列矯正を始めた当初から医者に指摘されていたのだが、意識的に無視してきた。
だって、生まれて45年、一度だって舌の筋が短くて困ったことなんてないし、舌の位置が悪いと言われてもおいそれとは納得できない。
しかし医者に言わせると、歯並びの悪い人の多くが舌の動かし方に問題があるそうで、出っ歯になる人のほとんどは舌で歯を押す癖があるんだとか。だから歯列矯正をする際には、機械で歯の位置を直すのと同時に舌の正しい動かし方の訓練をして、矯正した歯並びを再度悪くしないようにすると。
で、私の場合、舌と下顎をつないでいる筋が短いため、舌が正しい位置にない。舌の動かし方の訓練以前に、筋を切って舌の位置を正しくする必要がある、というわけ。いろいろ考えたが、医者を信じて手術を受けることにした。
今日がその手術の日。
まず舌の裏側に麻酔注射をして、麻酔が効くのを待つ。そのあと医者が舌を持ち上げて筋を切る(見えなかったけど、たぶんメスで)。
すると、ザクザクッと舌を切る感覚がはっきり伝わってきた、ひぇぇぇぇっ! 怖いよ!
手を固く握り締め、足をつっぱらせて、必死で耐える。
このあと、切った傷跡を糸で結んで手術は終了。だいたい30分くらいだったろうか。医者は気楽なもので、
「ちょっと切るのが浅かったかも。ま、必要なら2~3年後にもう一度切りましょう。」
とか言っている。
絶対にいや! もう二度とやらない。もう十分。
今日はあまりしゃべらないように言われているので、一日おとなしくしているつもり。いやぁ、歯列矯正はたいへんだ。
秋葉原ダイビルの産総研の会議室で行われたERP5のセミナーに行ってきた。
ERP5はフランスのNexedi(ネクセディ)という会社が開発しているオープンソースのERPソフトウェア。
以前、NexediのCEOであるジャン・ポールさんがPlone研究会で説明してくれたことがある。
今回はNexediのCTOをしているおくじさんによる解説。
おくじさんのブログ enbug diary
おくじさんとは数年前からメールのやりとりがあったのだが、お会いするのは今回が初めて。背広姿にちょっととまどったが、「ビジネス」のセミナーですからね。(^^)
会場には、Zope/Plone関係者の姿が多い。やっぱり皆気になっているんだ。
以下、セミナーのメモ。
・Nexediはパリから少し北のリール?という町にある。アフリカのセネガルにも支社がある。
社員数は二十人くらい、できてから5年位。
・ERPで重要なのは、業務に必要なデータ(見積書、請求書など)を関連付けて管理できること。
ERPは、インストール後にカスタマイズ/トレーニング/コンサルティングなどの仕事がはじまる。
少なくとも3ヶ月くらい必要で、億単位でお金がかかる。
企業内では、さまざまな部署間で多くのデータをやりとりしている。
データのやりとりを手動でやっていると時間とコストがかかる。
ERPがあれば、データの取得にほとんど時間がかからずにすむ。
結果的にコストを下げることが可能になる。これがERPの魅力。
・ERPはアプリケーションというよりフレームワーク。この上にアプリケーションがのっかることになる。
Webパブリッシング(CMS)やオンライン取り引きなどもERPに統合しようとしている。
統合しないとデータの重複が起こって、問題になる。
・自分は普段はフリーソフトウェアといっているが、ビジネスではオープンソースというようにいわれている。
最近のERPではオープンソースが流行。表面的なカスタマイズだけでは不十分。
コアシステムまで手を入れられるオープンソースが重要。
・Nexediのはじまりは、水着の会社(Coramy)がプロプライエタリなERPを使っていたところ、そのベンダが倒産してしまい、にっちもさっちもいかなくなったこと。
Coramyは、Nexediの最初の顧客。
・オープンソースだからといって、すべてを公開する必要はない。配らなければ公開しなくても問題なし。
どこまで公開して、どこまで隠すかが重要。
・ERP5は、フレームワークと、その上で利用するBusiness Templatesからなる。
Templatesは、ビジネスアプリケーションを作るための汎用のもの。これはXMLで書かれている。
・フランスの経営者向けのIT雑誌の2004年のERP部門で最優秀賞をもらった。
ドイツのInfoterraという偵察衛星を使って写真を販売している会社でも採用されている。
中央銀行や病院、フランスの水道局、セネガル共和国の公的機関、フランスの地方自治体、などでも利用されている。
・プロジェクトの推進は、Nexediとパートナーと顧客で行うことが多い。
・ERP5を利用する場合、
* 顧客がすべて自分でやる
* トレーニングを受けた顧客が自分でやる
* Nexediあるいはパートナーに発注する
という3種類がある。
・ERPの技術的なおもしろさ
* ミッションクリティカル
* データの種類が多い(50〜300が普通)
* データ量が多い
* 書込が頻繁(CMSでは全体のトランザクションの1%、ERPでは2割)
・ERP5の99%はPythonで書かれている。
残りのほとんどはC。
大きな声ではいえないが、Javaで書かれている部分もある。
・Pythonを採用した理由
* オブジェクト指向。
* classを自動生成するようなメタプログラミングができる。
Rubyもメタプログラミングができるが、大規模開発に向かない点があるので、利用していない。
この点については、まつもとさんに伝えてある。
・Zopeを採用している理由
* ZODB。
* Through The Web(TTW)、Web上で開発ができる。開発者にはあまり人気がないが、ユーザーには重要。
・ZSQLCatalog
オブジェクトのインデックス化をする。
ZCatalogと互換性がある。MySQLを利用している。
MySQLとPostgreSQLを比較したところ、8倍MySQLのほうが速かった。
O/R Mappingは一度作ったあとの変更に極めて弱い。
O/R Mappingのその他の問題点
* 列が多すぎ→性能低下
* ロックの粒度が粗すぎ
* 表が多すぎ→ロジックの分散
オブジェクトデータベースはオブジェクトを復元しないと検索できない。
ZSQLCatalogでは、オブジェクトの変更はオブジェクトデータベースでおこない、このオブジェクトデータベースをインデックス化してMySQLに入れて、検索する場合はこちらに検索をかける。インデックス化は遅延評価でOK。
結果、変更に強く、検索が速くなる。低速なインデックス作成は後回しにできる。
ZSQLCatalogは複数のデータベースに接続できるように作ってある。アダプタがあれば、どのようなデータベースにも接続できる。
・一応、日本でのローカライズもおこなったことがある。
ERP5は日本の会計システムにも問題なく対応できる。
・通常、半年から一年かかる会計プロジェクトが3週間程度でできる。
なぜこんなに早くできるかというと、ERP5が優れているから!
・ZODBにかわる高機能なオブジェクトデータベースを開発している。
将来的にはこれをフリーにして公開する予定。
・Nexediのメンバーは技術を理解していないといけない。20人全員が開発経験あり。
・SAPはもともと巨大なシステムがあって、そこから不必要な部分を削って使いものになるシステムを作っていく。
ERP5は逆で、赤ちゃんのような小さなところから作り上げていく。
SAPもOracleも会計ベースのシステムになっている。これだと現実とシステムの間にずれが生じてしまう。
ERP5では現実に生じたことを記録していくことで、ずれを生じさせないようになっている。
ERP5はシミュレーション系のERP。業務をシミュレートして、将来の財務などの予測ができる。
・ERP5の情報は下記から得られる。
http://erp5.org/
・Nexediは現在人材募集中
* 日本でERP5のために働いてみたい方
* 日本でNexediと一緒に働いてみたい企業
* フランスに遊びにいきたい方
セミナー後の懇親会では、ずーずーしくもおくじさんのとなりに座り込みいろいろと話をさせてもらった。
迷惑だったかもしれませんが、とても楽しかったです。おくじさん、どうもありがとうございました。
たかのりさんのサイトにならって、RSS配信を開始した。たかのりさんのサイトにはお世話になりっぱなしだ。
たかのりさん、ほんとうにどうもありがとう!
上記サイトの情報にしたがってindex.rdfとindex.xmlを追加し、headerにリンク情報を埋め込めばOK。
さて、うまく配信できるかな。
COREBlog2になる前のCOREBlogでは、エントリidが1, 2, 3, ……のように連番になっていた。COREBlog2では、エントリidがタイトルから自動生成されるように変更された。
これはこれで何も問題はないのだが、
という2点から以前のCOREBlogのようにエントリidを連番にすることにした。ショートネームの変更から、エントリidを手動で連番にすることも可能だが、やっぱりめんどくさいし、忘れがちだ。
たかのりさんがエントリidを連番にするコードを公開してくれているので、これを導入した。
1. まずPloneのサイト設定からZMIに入り、portal_skins/COREBlog2/getEntryIdにアクセスする。ここで「Customize」ボタンをクリックし、表示されるコードから
return None
を削除する。次に、たかのりさんのサイトにある下記のコードを挿入する。
coreblog = context.aq_parent
if coreblog.hasProperty('entryid'):
coreblog.manage_changeProperties(entryid=coreblog.entryid + 1)
else:
coreblog.manage_addProperty('entryid', 1, 'int')
return str(coreblog.entryid)
「Save Changes」をクリックしたところシンタックスエラーがあると言われてびっくりした。よく見ると、コピー&ペーストした際にインデントが狂っているではないですか!
ちょいちょいとインデントを修正して、再度「Save Changes」をクリックすればOK。
2. 次にZMIからCOREBlog2のインスタンスにアクセスし「Properties」タブを表示する。ここで、下記のような設定でentryidを追加する。
Name:entryid
Type:int
Value:一番新しいエントリのid番号(私の場合は145)
以上で、エントリidが連番で振られるようになる。
コメントスパムがやたらにくる。いちいち消していたのではたまらないので、対策をすることにした。
なごすいさんのブログのエントリを参考にPloneCaptchaを導入する。
以下、導入方法のメモ。
1. http://captchas.net/ へアクセスして、アカウントを作る。しばらくするとメールで、user nameとsecret keyが送られてくる。
2. PloneCaptchaをhttp://plone.org/products/plonecaptcha/からダウンロードし、解凍してできたファイルをディレクトリごとzopeインスタンスのProductsディレクトリに移動する。
3. zopeインスタンス/Products/PloneCaptcha/config.pyのなかの
CAPTCHA_USER = 'demo'
CAPTCHA_PASS = 'secret'
の部分のdemoとsecretを先ほどメールで送られてきたuser nameとsecret keyに置き換える。
4. zopeをリスタートし、Ploneの「サイト設定」→「プロダクツを追加・削除」でPloneCaptchaをインストールする。
5. Ploneの「サイト設定」→「Zope管理インターフェース」でZMIに入り、portal_skins/COREBlog2/cbcomment_formを表示して「Customize」ボタンを押す。
cbcomment_formが編集できるようになるので、
<div class="field"
tal:define="error errors/captcha| nothing;"
tal:attributes="class python:test(error, 'field error', 'field')">
<label i18n:translate="label_captcha_help">Verification Code</label>
<div class="formHelp" i18n:translate="help_plone_captcha">
This helps us prevent automated spamming.
</div>
<div tal:content="error">Validation error output</div>
<div metal:use-macro="here/captcha/macros/edit" />
</div>
をremember_cookieの定義の前に挿入する。
6. 次にZMIからportal_skins/COREBlog2/cbentry_viewを表示し、Validationタブをクリックする。ここで、Add a New Form / Script Validator Overrideを下記のように設定して「Add」ボタンを押し、Validatorを追加する。
Context type: Any
Button : 空白のまま
Validators : validate_captcha
7. 上記と同様に、portal_skins/COREBlog2/cbcomment_previewにもValidatorを追加する。
以上で、コメント欄に文字を含む画像が表示され、コメントの認証が行えるようになる。
画像を見て文字を入力するというのは視覚障害者を排除することになるので、できればやりたくなかったのだが、コメントスパムの多さに辟易して導入することにした。
敗北だな。;-(
3月の末にサーバに使っていたPowerMac G3がお亡くなりになってから3ヶ月以上も死んだままだったが、なんとか復活。
PowerMacではMac OS X Serverを使っていたが、今度は古いPCにFreeBSDを入れてみた。ついでといってはなんだが、COREBlogも念願のCOREBlog2に移行した!
FreeBSDにPython、zope、Plone、Apacheを入れてあれやこれやして、COREBlogからCOREBlog2にデータを移して、なんだかんだと書かなきゃいけないことは山ほどあるんだが、今日はもう疲れたのでいや。(^^;
ちなみに昔のサーバのバックアップには3月20日までのエントリしか残っていなかったため、23日と26日のエントリはインターネット上からサルベージした。
26日のエントリは無事に入手できたのだが、23日のエントリは一部しか入手できなかったため、後半になにが書いてあったのかわからない。
ま、しょうがないか。
まだPloneデフォルトのままだし、やりたいことは山ほどあるけど、とりあえず今日はここまで。
このサーバが数日前からアクセスできなくなっていた。気が付いてはいたのだが、忙しくて何もできないためほっておいた。
土曜日は休めたのだが、前日の徹夜の疲労で息子と一緒に寝込んでしまって何もできず。
今日はなんとか回復したので、午前中は肺炎と水疱瘡を併発している息子を連れて大学病院へ。水疱瘡はだいぶ良くなっているが肺炎はまだ残っているとのこと。2時間ほどかけて点滴をしてから家に帰る。
昼食後、久しぶりにMac OS X Serverにコンソールからアクセスしてみると、システムディスクの空き容量がほとんどないと文句をたれている。
まぁ、もともと8GBしか容量がないからなぁ。とりあえず不要なログファイルを消したり、使わないアプリケーションを他のディスクに移したりしてなんとか空きを確保。
ついでにData.fsをパックしてみたら、20MBちょっとあったものが3.6MBになった。
システムを再起動して動作を確認。これで今日のメンテはおしまい。
13日の朝、息子がかわいがっていたジャンガリアンハムスターのチビ丸が他界した。
二年半くらいを一緒に生きたことになる。ハムスターとしては長生きをしたほうだと思うし、大往生と言えるだろう。合掌。
13日は時間が取れなかったので、14日の朝に息子と妻と三人で多摩川の川原にチビを埋葬しに行った。お菓子の空き箱に花と大好きだったひまわりの種と一緒に入れ、大きな松の木の下に埋めてあげた。
息子は大粒の涙をボロボロこぼして泣いていた。息子にとっては、初めてのつらい別れだ。
チビ、二年半、ほんとうにありがとう。そしてさようなら。