自分のプログラムは怖い

nakagamiさんの

そんな車には乗りたくない

を読んで思い出した事があるので書いておこう。



十数年前、ある組み込み系プログラマから聞いた話。なんでも彼が制御プログラムを書いた工場用ロボットの初お披露目の会に開発担当者として呼ばれたそうな。彼自身はなんとか出席せずにすむように画策したらしいが、努力も虚しく出席するはめになったと。

「あのですね。工場関係の偉い人たちと一緒にヘルメットを被って、工場のそのロボットの前で式典なんかをやるんですよ。それで、ロボットを実際に動かして、みんなで拍手とかするわけですよね。お偉いさん達はうれしそうに笑ってましたけど、私は生きた心地がしませんでしたよ。

　なにせ目の前でロボットの鋼鉄のでっかい腕がブンブン動いているんですよ。しかも、そのプログラムを書いたのは私なんですから。もしもどこか一カ所でもまちがっていたら、腕が動く半径が数メートルずれたとか、右に動くはずが左に動いたとか、全員鋼鉄の腕につぶされてあの世行きですよ。

　そりゃ、テストはやってますよ、テストは。でも、どんなにテストしたって安心なんかできませんよ。あんなところにプログラマを呼んだりしちゃいけませんよ。まちがってます。ええ、まちがってますよ。」



当時は笑って聞いていたけど、最近笑えなくなってきている。自動車をはじめとして、身近にプログラムで制御される機械がどんどん増えているし、誰かの書いたプログラムのバグで死ぬ可能性は増える一方だ。怖い世の中になったもんだなぁ。

「TeXは悪くない」の続き（最後）

なんかもううんざりしてきたので、この話題はこれが最後。

いろいろエントリが増えているけど、下記の2つだけ。あいかわらずこの人の文章は意味がよくわからないのだが、たぶん以下のようなことを言っているんだと思う。

フルバッチ、数式組版の標準化と写研が広げた制作手法の狭間で(5)

大学の先生のなかに、TeXの生原稿を印刷所に入稿し、この出力の品質をTeXの限界を超えて（？）上げるように要求する無茶な先生がいる。このような無理な要求をする先生のおかげで、印刷所はたいへんな苦労を強いられている。

フルバッチ組版。最適なこれからのソフトウェアの紹介(10)

今後の自動組版システムは、

Word(Mathtype)→xml→MC-B²（モリサワの組版ソフト）

というものになる。 TeXの原稿はいったんWordに変換してから処理すればよい。

しかし、組版システムをかえたからといって、上記の問題が解決するとは思えない。どんな技術にも限界はある。その限界を顧客（大学の先生）にきちんと説明できないようでは、どのような技術を採用したところで問題は生じるだろう。

結局問題なのは、顧客との間に信頼関係を築けていないことだ。印刷所は立場が弱いから、というようなことが書いてあるが、たとえ立場が弱くても言わなければいけないことはあるし、顧客が納得するまで話し合わなければいけないことがある。それができないというなら、泣くしかない。

ようするにこれは技術の問題ではなく、コミュニケーションの問題だ。

コミュニケーションの問題を技術の問題にすりかえて、「このシステムを導入すれば解決できます」みたいな言い方をするのはまちがっていると思う。

「TeXは悪くない」の続き

vm_converterさんからトラックバックをもらったので、こちらからもトラックバックを返しておこう。
私もBSD magazine付録のストラップを今でも使っていますよ！　(^^)

リンクとか備忘録とか日記とか

で、ここから本題。
「TeXは悪くない」で取り上げた話のネタ元のブログをいろいろ読んでみた。

http://blog.goo.ne.jp/tmlarao

このブログの著者は
荒尾 稔さんといって、株式会社 トータルメディア研究所という会社の代表取締役をされている。


株式会社 トータルメディア研究所

この会社がなにをやっているかというと、Microsoft WordでOpenTypeのすべての全角字種を使えるようにするアドオンソフトとか、WordからXMLデータを作成する（フィルタなのか？）ソフトとかを開発／販売している。
まぁ、こういう商売をしている会社の社長さんなのだから、

確かに、これからの数式は、あまりに多様化してばらばらになってしまったTEXから、
Wordにも掲載されたMATHTYPEがメインになるだろうと言われています。

という発言をするのも当然だろう。TeXに対して否定的であってもなにも不思議ではない。

荒尾さんのブログでは、いまだにTeX関連のエントリが増え続けているが、彼の文章には意味不明な部分が多くて、彼が何を言いたいのかどうもよくわからない。また、文章を読む限りでは、荒尾さんはTeXやxmlについて技術的にはあまり詳しくないようだ。

技術的に詳しくなくても別にいいけど、荒尾さんのブログを読んで、

「TeXはいろいろ問題が多いし、印刷所でも扱ってもらえないようだから、使わないほうがいいだろう」

なんて思う人が増えてしまうとしたら、実に悲しい話だ。次のエントリでTeXの位置づけについて語ってくれるらしいけど、なにを言うのかなぁ。

TeXは悪くない

なんかよくわからん議論が続いている。

日本のフルバッチシステムで著名なTEXについて

TEX原稿を印刷業会で持てあましている件

TeX入稿についての誤解

「TeX入稿についての誤解」についての誤解

まず第一にTeXの生原稿を印刷所に渡すというのは、いくらなんでも常識はずれだと思うので論外。
次に、TeXで組版したデータをもとにしたPostscriptやPDFが出力できないというのはTeXの問題じゃない。

Postscript/PDFと一口に言っても、実はそれらにはさまざまな形式があり、さらにそれらを作成するソフトウェアによって細かい仕様の違いがあるため、Postscript/PDFだからといって一概に出力できるわけではない。

ということが問題なわけだ。

これはPostscript/PDFというデータ形式が抱える問題であって、組版ソフトであるTeXの問題ではない。
PostscriptやらPDFの問題をTeXに転嫁して、TeXを悪者扱いするのはやめてもらいたいものだ。

ちなみに私が所属しているアスキーでは、十数年前からTeXを核にしたEWB(Editors Work Bench）という独自のDTPソフトウェアを開発／保守／利用している。私自身、アスキーに入社以来十数年に渡ってEWBを使って本を作ってきたし、今現在も作っている。
もしTeXの出力を印刷所が扱えないというなら、アスキーは書籍の大半を作れなくなってしまうことになる。そんなこたぁ、ありえない。
EWBでは、TeXで組版した後、dvipsでPostscriptデータを作成して、これを印刷所に入稿している。細かいトラブルは何度か経験しているが、出力不能というような大きな問題は生じていない。

使用するフォントの問題やPostscript/PDFの問題から、素人が解決するにはハードルが高いとは思うが、解決できない問題じゃない。
「dvipsでPostscriptにした後、Acrobat DistillerでPDF/X-1aにしてください」というだけでも、かなり解決できるんじゃないかと思うが、どうだろうか？

オープンソースマガジン休刊

まだソフトバンククリエイティブのWebサイトには出ていないみたいだけど、決定らしい。

ほかにも12月で休刊になるLinux/OSS関係の雑誌が数誌あるとか。

UNIX USERからの誌名変更パーティーに出たのは、ついこの間だったよなぁ。1年ほどしかもたなかったか。

IT系の技術雑誌が壊滅するのは、たんに時間の問題なんだよね。そんなことは数年前からはっきりわかっている。

実売部数の低下と広告料金の減少をくい止める術が無い。

問題は紙の雑誌をつぶした後に何をやるかなんだけど。今のところ答えが見つかっていない。

@ITのまねごとやっても、LinuxやOSSでは広告が集まらないだろうし。

結局、広告がつかない情報は、個人がボランティアで出すもの以外流通しなくなってしまうってことか。

いかん、ぐちになってしまった。

某サーバのZopeをアップデート

しばらくほっておいた某サーバの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にアップデート

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の「サイト設定」から「プロダクツを追加・削除」にアクセスして、改訂版がでていると表示されている部分を順番にクリックしてアップグレード

以上で、アップデート終了。

Python Developers Camp 2006 夏 感想などなど

とにかく濃い3日間でした。はい。

35人という大人数で、しかもあの濃さはなんでしょう（笑）。

オブジェクト指向入門という初心者向けセッションがあったので助かりましたが、これがなかったらついていけずにかなりつらかったかも。

和訳プロジェクトは増田さんから浦郷さんにバトンが渡されました。2.5の和訳、浦郷さんはじめスタッフの皆さん、がんばってください。

和訳には本当にお世話になっているので、よろしくお願いします。いつも感謝しております。

Djangoは熱かったですね。TurboGearsのほうは人がcoolなのかな。今回は人数的にDjangoの人が多かったよう。

帰りはJackさん、阿部さん、竹内さんと私の車で帰りました。でも運転はほとんどJackさん。

Jackさん、ありがとうございました。同乗したみなさん、うなぎはなんとかなったので、ご安心を（笑）。

主催者の柴田さん、プログラミングスタッフの皆さん、お疲れさまでした。すばらしいCampをありがとうございます。

冬にも開催予定とのことで、今から楽しみです。参加者の皆さん、冬にまたお会いしましょう。

Python Developers Camp 2006 夏 成果発表

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で言語の中身を変更する予定なので、具体的にどこが変わるのかを書いてある。４つある。
　　３つ目までは訳してある。４つ目をやろうとしたが酔って眠ってしまったので、これからやる予定。
　増田：354、列挙データの話。200行くらい。2日でやるにはいいサイズ。

Webチャットスプリント

　石田：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。
　　さっき９時ごろから作り始めた（メモを取っている時間は11時26分！）。テーマはやっつけ！

　　増田さんの発表の動画（http://static.everes.net/related/stuff/devcam2006s.divx）

Twistedスプリント

　おおたに：席をはずしていたのでメモとれず。
　村岡：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 夏 ライトニングトーク

Python Developers Camp 2006 夏の2日目夜に行われたライトニングトークのメモ。

Pythonメタクラスプロトコル

小田切篤

クラスもオブジェクト
クラスのクラスがメタクラス
Pythonの中ではtype関数を使って動的にクラスを作ることができる
typeはクラスなのでサブクラスを作ることができる
このとき、selfではなくclsを使う

契約による設計
　事前条件
　事後条件
　不変条件

関数デコレータ
　まにあわなかった

私には難しすぎる内容

デコレータっていいよね

田原悠西

デコレータはPython 2.4から入った機能
@の次にcallableなオブジェクトの名前を書く
基本的には単なるシンタックスシュガー
デコレータは合成関数を作るもの
デコレータは縦に並べることもできる、適用は下から
フレームワークでデコレータが提供されている場合が多い
もっと使いこなすならdescriptorを勉強すること

GRINEditの紹介

西尾泰和

Pythonワンライナーのお話、LLRingでやったやつ
JythonとはJava VM上で動くPythonの実装系
以下デモンストレーション。なかなかおもしろかった

GRINEditのWebサイト（http://www.nishiohirokazu.org/grinedit/index.html.ja）

Iron Python

石坂忠広

.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 夏 オブジェクト指向入門

Python Developers Camp 2006 夏、2日目の午前中に行われたオブジェクト指向入門セッションのメモ。

Pythonでオブジェクト指向入門

森亮靖

ウォーミングアップ
　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 夏 和訳プロジェクト

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行くらい追加で訳さないといけない
現スタッフは息切れぎみ、アクティブな人が減っている
アクティブに動く人があと５人くらい欲しい

ビルドシステムのただ乗り（すでにシステムがあるのでこれをそのまま利用できる）
　mkhowto_jpを起動する
　mod_pythonのビルドMakefileを使う
　必須：Python + Perl
　和訳ドキュメントソース
　python mkhowto_jp (options) toplevel.texで作れる

ReStructuredTextの翻訳
　利点
　　ビルドしなくても読める。配布できる
　　PDFやHTMLに変換できる
　　PEPや多くのモジュールのREADMEで採用
　注意すべき事
　　推奨文字コード：euc-jp
　　タイトルやテーブルの幅：ワイドグリフ
　　マークアップの境界をASCII文字にする
　　日本語タイトル

ReSTドキュメントのビルド
　rst２html.pyを使う

私的和訳の進め方
　エディタは等幅フォントを表示できないとだめ
　辞書：おすすめはリーダースCD-ROM
　日本語力は英語力より重要
　googleで英語と日本語の和訳の候補を入れて検索して、その訳が妥当かどうかを検証する

　翻訳する底本を選ぶときは、できればバージョン管理されているものを選ぶ。リポジトリから差分がとれるので、便利。
　必ずライセンスを調べる。わからないときは著者に問い合わせる。無反応なときは暗黙の了解ができたと考える。

注意すること
　一貫性：最低、用語と文体をそろえる
　背景知識：勉強になる
　可能な限り原文を尊重する
　　私見を入れない
　　和文／英文リンクの併記

やってはだめなこと
　翻訳ソフトを使う→甘えのもと
　翻訳ソフトの訳は後でいくらいじってもまともにならない

訳し終わったら
　原文作者に連絡を取る
　MLなどに宣伝
　手放したければリポジトリを公開するのがいい

和訳にもっとも必要なもの、それは愛だ！

Python Developers Camp 2006 夏 Twistedセッション

Pyhon Developers Camp 2006 夏へ参加してきたので、メモを公開。

まず1日目のセッション1つ目。

Twistedのお話

おおたにさん

Twistedって何？
　グロテスクです。
　イベント駆動型のネットワークプログラミングのフレームワーク／ライブラリ

Twistedを使っているアプリケーション
　BitTorrent
　AppleのiCal WebDAVサーバ
　Xen
　Zope3
　ほかにもいろいろある

ネットワークプログラミングのスタイル
・同期型
　ブロッキングIOを使っている
・非同期型
　ノンブロッキングIO
　select/poll
　イベント駆動

非同期型
　Connectをコールしたときに待たない
　Connectが成功したときにイベントがあがる
　ネットワークが読み書きできるとイベントがあがる

　同期型はプログラミングが簡単
　非同期型はとってもめんどくさい。とくにTwistedを使わないとめんどくさい。

めんとくさいものを使う理由
　ネットワークとCPU効率の問題
　　ネットワークプログラミングはとにかく待ちが多い
　　スレッド／プロセスのコンテキストの切り換えはコストがかかる
　同期型で効率を考えると→スレッドをたくさん作る
　非同期型だと１つのスレッドで複数の接続を処理できる

非同期でやりたい理由
　マルチスレッドの処理はスレッド間の同期がたいへん。人がやるプログラミングじゃない。

WebChat + AJAXの場合
・同期型
　AJAXで定期的にPolling
　AJAXで送信専用接続と受信専用接続
・非同期型
　AJAXで送信専用接続と受信専用接続（新たなデータがきた時点でレスポンスを返す）
　普通のWebサーバじゃできない

非同期の問題
　すべて１つのスレッドで行う
　　重い処理があるとプログラム全体がブロックする
　　重い処理はスレッドを別に作らないと効率がかえって落ちる（スレッド間の同期問題が発生してたいへん）

結論
　どちらが優れているかは一概には言えない
　どちらのプログラミングモデルを使うかは作りたいものによる
　魔法の杖は今のところない

非同期プログラミングというと
　Twisted
　標準ライブラリのasyncoreがある

標準ライブラリじゃだめなのか？
　1つの処理だけなら十分
　複数の接続＋複数のプロトコルを扱うと力不足
　asyncoreはAPIが嫌い

Twistedは？
　複数の接続、複数のプロトコルを統一的に扱える
　低レベルから高レベルまでAPIが用意されていて、好みに応じて使い分けられる
　例レベルなAPIが好き

Twistedの恐ろしいところ（すごいところ）
　ネットワークはTCP/UDP/Unix Socketなどをサポート
　ファイルアクセスも非同期で処理できる
　データベースも非同期で処理できる
　Linuxならコンソール（標準入出力）まで非同期で処理できる（でもめんどくさい、お勧めしない）
　待ちが発生しそうなことはたいてい非同期で処理できる
　select/pollを使わずにWin32のイベント処理に置き換えられる

Twistedの基本
　Reactor
　Deferred

　Factory
　Protocol
　この４つがわかっていれば、ほとんどのことはできる

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がわかっているプログラマでないときつい。特に問題が起こったときにたいへん。山のようにコールバックが帰ってきてわけがわからなくなる。どうやって解決しているのか。
　どうしているんでしょうねぇ（笑）。