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で言語の中身を変更する予定なので、具体的にどこが変わるのかを書いてある。４つある。
３つ目までは訳してある。４つ目をやろうとしたが酔って眠ってしまったので、これからやる予定。
増田：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。
さっき９時ごろから作り始めた（メモを取っている時間は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行くらい追加で訳さないといけない
現スタッフは息切れぎみ、アクティブな人が減っている
アクティブに動く人があと５人くらい欲しい
ビルドシステムのただ乗り（すでにシステムがあるのでこれをそのまま利用できる）
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などに宣伝
手放したければリポジトリを公開するのがいい
和訳にもっとも必要なもの、それは愛だ！
Pyhon Developers Camp 2006 夏へ参加してきたので、メモを公開。
まず1日目のセッション1つ目。
おおたにさん
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がわかっているプログラマでないときつい。特に問題が起こったときにたいへん。山のようにコールバックが帰ってきてわけがわからなくなる。どうやって解決しているのか。
どうしているんでしょうねぇ（笑）。
