本を読む

　オビの惹句がすばらしすぎる。

無責任な奇想、ちゃちな人間描写、
知られざる傑作を詳細解説
ヘソにホクロのある兄を探すギョーザ娘が7人の恋人を手玉に取る「純情青ひげ娘」／源氏に敗れた平氏が、カニに変身して壇ノ浦の海底でロカビリーパーティを開く「壇ノ浦〇番地」／女になりたい男と、男になりたい女が皇居前でストリーキングする「シスター君とブラザー娘」／自分の父親が300余歳であることを信じてもらうために、息子が300年分の日記の出版交渉をする「快男児街を行く」／前半はホームドラマ、後半はなぜか女子大生が渋谷で市街戦を始める「我が家の妖精」他

　というぐあいに、昭和30年代に全盛を迎えて、消えていった「貸本小説」と、その作家たちを紹介する本。貸本屋では書店売りの本も扱っていたけど、そのうちレンタル専用の本を「貸本小説」としているとのこと。

　作品や作者について詳細に解説しているのはもちろんのこと、当時の貸本小説の立ち位置やビジネスモデル、衰退の様子についても説明している。「はじめに」のサブタイトルが「楽しんで、あとは忘れてぐっすり眠ってもらう」とあるように、TVや映画に金を払えない非インテリの若者向けに、まったくの娯楽として書かれた本。増刷は無縁で、とにかく数をこなすために校正もせず、植字の段階で「？」が付いている部分がそのまま印刷されてしまうというぐらい。そうした自転車操業の中から、上記のようなヤケッパチの奇想も生まれてくる。とはいえ、基本路線は健全な娯楽路線。やがて、貸本という形態から必然的に流通がサチってくるうえに、高度経済成長でTVや本が買えるようになると衰退して消滅していく。

　本書の中で、当時の貸本小説の装丁に触れた部分を読むと、白いカバーと背に筆っぽい字で書かれたタイトルと、まさに本書はそのままであるようだ。奥付に検印スペースもあるし。表紙イラストは貸本小説の定番、堂昌一氏。しまいには、当時の本の焼けぐあいを再現すべく、そういう紙を選んでいるとのこと。

　ちなみに、上記の「純情青ひげ娘」の作者は、本書によると、のちの童門冬二である。

　2008年10月24日に、第91回カーネル読書会「openSUSE 事始め ～ カメレオンは日本で何色に染まっていくのか…？」が開催された。講師はopenSUSEの松本さん。

　私は仕事で参加できなかったけど、さっそくビデオがニコニコ動画に上がったので（前半、後半）、見てみた。以下、ビデオ中で話されていた内容をメモしたもの。間違いがありましたらご指摘ください。

イントロ

• 自己紹介
  • 今年9月にメンバーシップ登録したばかり
  • それまではSUSE好きなただの人w

• 会場に質問：SUSEを使ったことある人
  • （けっこういたらしい）

SUSEとopenSUSE

• SUSEの歴史
  • 1990代前半にドイツで始まる
  • Software und System Entwicklung（ソフトウェアとシステム開発）の略
  • もともとSlackwareベースで、インストールパックとして販売していた
    • いまはRPMベースなのでRed Hat系っぽくもある
  • バージョン4.2から始まる。SFに出てくる数字が由来
    • （emasaka注:岩井さんの回のカーネル読書会によると「銀河ヒッチハイクガイド」のアレらしい）
  • ヨーロッパを中心に活動
  • 2003にNovellに買収されて転機
    • 2系統に
      • Professional（販売版）とPersonalがSUSE Linuxに統合
      • Enterprise版はSLESに
  • マイクロソフトの提携
    • 話題になった。裏切り論争（苦笑）
    • ユーザーの視点からいえばシームレスに使えるほうがいいよね、と言ってくれる人もいる
  • 2005年 openSUSE発足
    • 10.2から名前もopenSUSEに
      • 11.1がもうすぐ出るよ
      • SLES 11のベースに

• タテマエとして「Novellが支援するコミュニティベースのプロジェクト」
  • あくまでNovellの下部組織ではない
    • まぁ、Novellの人がたくさんかかわっている
  • Ubuntu のCode of Contractが有名だけど、openSUSEにもGuiding Principles（基本方針、運営指針）があるよ
  • 運営組織としてはBoard、5名
    • 議長1名（Novellの中の人）ｌ
    • Novellから2名
    • それ以外から2名
  • 意思決定機関というよりは、世話人的な役割
• コミュニティでやることはオープンに討論
• 2008年2月、コミュニティマネージャーにJoe 'Zonker' Brockmeierが就任
  • 元オープンソース関連のジャーナリスト
• メンバーシップ
  • メンバーは世界中で現在212名
    • Guiding Principlesの支持を表明すること
    • 継続かつ実態のある貢献をした人
      • 目に見えるものであればよい
• Boardの第1回の選挙、10月25日しめきり
  • はじめてメンバーが選ぶBoard

openSUSEディストリビューション

• Red Hatに対するFedoraのようなもの
  • Cutting Edgeではない。それはFactory版がある
  • SLESのベース
  • 半年に1回マイナーバージョンアップ
    • メジャー番号は完成度というよりSLESの番号
  • 12.18あたりに11.1をリリース予定
    • が、Nürnbergの停電でデータセンターが止まった
    • 大丈夫か？

• 特徴
  • 派生（ローカライズ版とか）を作らない。
    • 世界中で単一
    • 派生っぽいものが出ると、メインストリームに集約
    • 肥大化の懸念もある
  • カーネルに貢献してきた人がたくさんいる
    • 特にデバイスの得意な人が多い
    • そのためデバイスの認識率が高いと思う
    • 社内MLで「サウンドカードが動かない」と言うと、岩井さんが出てきて解決w
  • ヨーロッパなのでもともとKDEと仲がいい
  • NovellがGNOMEを買収
    • 両デスクトップの最新機能をとりこみやすい
  • OpenOffice.orgのNovellバージョンも（日本人も参加）
  • 新しいものがとりいれられやすいディストリビューション
  • ルーチンワークの部分で楽できるディストリビューション
  • （3Dの円筒形にマップされた仮想デスクトップを見せた）

• SUSEといえば統合管理ツールYaST
  • いまYaSTのマスコットを作るコンテストが始まっているw
  • ひとつの共通したインターフェイスからほぼすべての設定ができる
    • これで楽ができる
  • インストーラもYaSTベース
  • YaSTの設定が手書きの設定を上書きすることがあるので注意
    • Yastにまかせられることはまかせる

• openSUSE Build Service（OBS）
  • Web上の公開サービス、誰でも使える
  • 開発者向け
  • 1つのソースから複数のディストリビューションやバージョン、アーキテクチャのパッケージにビルド
    • openSUSEであればその場から、依存関係こみでインストールできる
    • JDのパッケージを作った例
  • Fedora、Debian、Ubuntuなどのパッケージも作れる
  • アプリ開発者がディストリビューションに売り込む道具にできる

• Q：.debとかになるか？
  • A：ちゃんとDebian用とかになるはず。ただ、自分ではDebianパッケージを作ってないので詳しくはわからない
• Q：バイナリだけが公開される？
  • A：作成者ごとのプロジェクトとしてページが作られる。そこに、ソースやパッチも公開され、パッチの投稿も受け付けられる
• Q：.debパッケージだけ生成される？ それに必要なソースも？
  • A：パッケージは生成される。ソースもアクセスできる
• Q：ライセンスチェックは？
  • A：その機能は持っていない

日本の openSUSE コミュニティ

• コミュニティと名前が付けられる前
  • Mike Fabian
  • 物理学者だったけど食うために偶然SuSEに入社したらハマった
    • 毎日、家に帰ってからボランディアベースでこつこつ日本語化
    • MTAの略が比較的最近まで「メール転送機能体」になっていたとかもあるけどw
  • 2002年に日本語メーリングリスト開設
    • このごろ松本さんが、Live CDで日本語入力ができなかったことをMLに投げたら、Mikeさんからすぐ返事が来た。新鮮なよろこび
  • 2003年、マイクさん歓迎会
    • 以降、年1回
    • ある意味、openSUSEコミュニティの前身？
• コミュニティといえるかどうかというぐらいゆるい集まり
  • 2007年春のOSCで「何かやる」ことになったのが、コミュニティのはじまり
  • その後、Linux WorldやOSCに出展
  • イベントごとに手伝ってくれる人が増える
  • 今年は地方や勉強会も
  • 10月にZonkerさんを呼んだ
  • 日本の情報の発信サイトGeeko.jpをNovellスポンサーで開設を進める
• 自分がコミュニティの一員だと思えば一員

Novellとコミュニティの関係

• 「コミュニティの意見ではなく、個人的に感じていること」
• Novell側の問題
  • いままでコミュニティとの付き合いがなく、どうしたらいいかわからない
  • 試行錯誤中。コミュニティが相談を受けている
• コミュニティ側の問題
  • Novellがなんでもやってくれると思いがち
  • 自分たちのことは自分でやるのが原則なのだが
  • 責任感が薄くなりがち
  • 2chで「Novell はやる気がない」とか書いたり
• 正直openSUSEのことはNovellはやる気がない（会場w）というかあまり口出ししない方針らしい
  • そのことがアナウンスされなかったので、Wikiやドキュメント、翻訳などが放ったらかしになってしまった
    • Wikiの編集アカウントをNovellの人しか持っていなかったり
• 最近は、Wikiやローカライゼーションについて日本のチームで責任者を立てるようになった
• 「待っているのではなくて、コミュニティでできることはどんどんやってっちゃおう」

• コミュニティにまかせるならNovellがそうはっきり言ってほしい。そのかわり動くために必要なリソースや権限は移譲してほしい
  • Wikiだけじゃなくて、ビルドサービスやダウンロードサイトの日本語化などもさせてほしい
  • その話を進めている

今後の課題

• 「ディストリビューション共通だと思う」

• OS目当てという人はそうとう変わり者w
  • 多くの人は、その上のアプリが目的で、OSはたまたま今使っているだけ。乗り換えにためらいはない。簡単にほかのディストリビューションに行っちゃう
  • その中でSUSEの魅力を出していかなくては。これはディストリビューション共通？
• SUSEは、よくも悪くも初心者が少ない
  • いろいろなディストリビューションを試した後にSUSEに来た人が多い
  • 「教えて君」がいないのも、それはそれで寂しいw
  • 気楽に相談する場所を作っていければいい
• ユーザを大切にしよう
  • 「使うことしか興味のない人」も
  • でも助けをさしのべてくれる意識のある人がいないといけない

• 本家との連携
  • まだまだ日本のことは軽く見られていると感じる
  • 11.0では、正式版で急に日本語インストールがコケるようになった
    • βでは出なかった問題
    • 直前にNightlyで見つけてbugzillaに報告したが、「CJKを使ってる人はそんなにいないから」（会場w）
  • そのため、今は日頃からがんがんバグを報告するようにしている
  • 最近ではopenSUSEのMLで、SPAMフィルタに日本語（を含むCJK）メールがひっかかりやすいという問題。報告したら「我慢しろ」（会場w）
    • 理解してもらいにくい問題
  • 問題点について常に声を出していかなくてはいけない

• 自分は、自分が積極的に動く宣言としてメンバーになった。そういう人をもっと増やしたい

質疑応答、議論

• SPAMメールフィルターの問題が伝わらないというのは、日本人のメールが少ないのか
  • 松本：アクティブな人が数人。そのうちの人が引っかかかった。フィルターにひっかかるとエラーにもならないので、ひっかかった人が顕在化しないかもしれない
• ML管理者にCJKの経験がないとわからないかもしれない。わかる人が管理者になって、ひっかかっているメールを発見してやる必要があるのでは
  • 松本：そう思う。よくはわからないが、欧文ならあるはずの半角スペースが少ないことが原因になっているらしい。欧米の人だとなかなかそういうことをわからない。フィルターをはずすのも、管理者になるのも、Novellの全社的なシステムなので難しい。
• Zonkerさんとかは仲介してくれないか
  • 松本：Zonkerにはまだ相談していない。まずはMLの窓口にコンタクトした。
• 同じ問題は日本以外でも？
  • 松本：それはわかならない。Wikiやマニュアル翻訳での問題は、ほかの国でも声が上がっているので、それらの問題をまとめて扱える場所を作ろうという話にはなっている

• マニュアルの翻訳について、openSUSEとNovellの切り分けは
  • 松本：openSUSEのマニュアルの翻訳について、Novellはまったく興味を持っていない
• openSUSEのマニュアルを元にNovellがマニュアルを作ったりとかはないか
  • 松本：エンタープライズ用の日本語マニュアルはあると思うが、そこの連携がとれていない。たとえば、YaSTは両方にあるので、それぞれでマニュアルをやっているとリソースでも用語統一でも無駄。そこをなんとかしようという動きができていない。Novellの人は、やるべきという人も一部にいるが、大多数の人は自分に振られたタスクしか興味がない。

• openSUSEの意思決定は
  • 松本：議決組織はない。だれかがMLやIRCで提案したことについて、いろいろな人が意見を言って議論して、Wikiでページができて、まずは動かして、批判が出たら変えていく、という走りながらのプロセス。
• よ：（会場に向けて）ちなみにFedoraとRed Hatの関係は
  • Fedoraの人：翻訳は基本的にコミュニティベース。ただ、人がいなかったりいろいろあってw 、実際にリードするのはRed Hatの人だったり、ものによってはRed Hatの人がぜんぶやったり。ただし、Red Hatも含め、どうするかをやりとりしながら。

• debianの人：（会場に向けて）オープンソース関連で翻訳をやったことのある人は…こんだけ？w ニッチな場所でもこんだけ？w みんなもっとやろうよ
• 松本：翻訳は苦労が多いわりにリスペクトされづらいというのもある
• debianの人：あと査読がほしい（会場うなづく）。勢いで訳したところを、どこかのスレで「誤字がある」とか書かれて「（笑）」とか「w」とか付いてたりw だったらお前やってくれと。日本語は読めるだろうと
• 翻訳の問題はカーネル読書会初期からの話題ではあるが、最近やっていないので、またそろそろ
• debianの人： 翻訳というと重い感じがするかもしれないので、まず査読とか
• オープンソース系のイベントでノートパソコンを持ち寄ってとか。マニュアルは使う人が読むものなので、わからなければわからないとその場で言ってもらえば翻訳者が直す。
• openSolarisでは、系統立ったかたちで、リーダーを立てて協力をつのる体制。査読もつのっている。著作権の問題の指摘なども
• 松本：のに子さんがかけあってくれて日本語サイトができたりして、一度翻訳チームっぽいものが立ちあがった。が、立ちあげるときは勢いがあるが、続けていくのが大変。「ここでやっている」と発信し続けていかないと、興味を持った新しい人がちょっと手伝おうと思っても、どこに行って何をすればいいかがわからない。同じような悩みはopenSUSE以外でもあると思うので、問題を共有していければと思う。
• コミュニティにWikiはあるか
  • 松本：みんなが編集できる
• レジストすれば誰でもてきるというのを説明したほうがいい。私はそれに気付くのに時間がかかった
  • 松本：MLでも質問があった。やはり、誰でもやっていいということは常に言っていないといけない
• 多くのサイトでは、案内ページが日本語であって、それを読めばいいようになっている
  • 松本：そうですね。本家でも構成を変えようという話がある。「何かしたい人」への案内とレスポンスする人を作りたいといっている。日本でもやっていきたい。もったいない。
• その話はどこでやっているか。MLはたくさんあるようだが。
  • 松本：主にZonkerのやっているmarketingのML、全体についてはprojectのML。また、marketingのチームとプロジェクトのチームは2週間に1回ぐらいIRCミーティングをやっている。先日、IRCを立ち上げたまま寝ちゃって、寝てる間に「このあいだはWeekly Newsを翻訳してくれてありがとう、またやってくれるね」と担当にされていた（会場w）。
• Weekly NewsはWikiで？
  • 松本：Wikiではない
• openSUSEは、多くのIRCミーティングがあって、そのログがみんな公開されているのだけど、いったいどれを見ればいいのかわからない。Weekly Newもどこで話しているかわからない
  • 松本：基本的にはmarketingとprojectのIRCで、そこから分岐していく。混乱するのは翻訳の部分もあって、openSUSEにはTransration TeamとLocalization Teamがあって（会場w）、Localization TeamがTransration MLを使って、Transration TeamがWiki MLを使ってたり、わけわかんない。
• 混乱させようとw
  • 松本：だから、相談しようとした人が、まずどこに投げたらいいか迷ってしまう。なんとかしようよと私も言っているが、わかりやすくする必要がある
• 日本に関しては一箇所にまとめるとか
• openSUSEはワールドワイドにコミュニティがある？
  • 松本：ある
• それと日本のコミュニティの関係とか、Webとの関係とかが、カオスだというのはわかった。この状態だと入ろうよと言われてもなかなか…
  • 松本：本家の話題で、各国に大使役になって本家と調整する責任者を一人置いて、ローカルの問題はローカルで解決しつつ本家につながていくようにしようじゃないかという話も。でも日本とかの問題は後回しになっちゃうことがあったりして。らちがあかなければ、日本の話、たとえばgeeko.jpの管理とかインフラとかは、Novellにやってもらったり。

• まとめ（よ）：今日はopenSUSEだけじゃなくてフリーのディストリビューションに共通する問題もあったと思う

人が人を殺しちゃいけない理由はな……
その償い方を誰もわからないからだ

　「新たなる神の娘」編完結。人を殺した若者たちのたどりつく先は…

　「世界の理が 今 終わる」という戦のはじまり。

　「CakePHP」のカンファレンス「CakePHPカンファレンス東京」が開かれた。CakePHPは、Ruby on Railsの影響を受けたPHPのWebアプリケーションフレームワーク。開発チームのプロジェクトマネージャをまじえて、けっこう踏み込んだ話がされていて、面白かった。

　Ustreamによるインターネット中継を一日聴いて、メモをとったので、以下に整理。間違いがあったらご指摘ください。

基調講演「国内でのCakePHPの利用状況について」（安藤祐介）

　まず、参加者に対して挙手によるアンケート。CakePHPを知っている人はもちろん100%（笑）、ほとんどの人がさわったことがあり、公開サービスで使ったことのある人もけっこう多かったらしい。

　改めてCakePHPの概要を紹介。「全てのレベルのPHPユーザーが使う高速開発フレームワーク」が特徴という。「高速開発」は、フレームワークを使った開発全体にいえること。フレームワークを使わない開発では、必要な処理をぜんぶ書くため、似たようなプログラムで同じ処理を何度も書く必要がある。また、プログラムの構造はプログラムによって異なる。一方、フレームワークを使った開発では、ルールにそった部品だけを作成するため、決まりきった処理を書かずにすむ。ほか、ほとんどのプログラムが同じ構造じとなるため、引き継ぎやチーム開発などで有利となる。つまり、生産性と保守性が向上する。

　ただし、フレームワークというと、初級者には難しい印象がある。CakePHPはフレームワークの中でもトップクラスの簡単さで、初心者でも使える。面倒なインストールや設定はほぼなしで、書くコードの量も少ない。サーバーやコマンドライン、ライブラリなどの前提知識が天弧盛りだと初心者は泣きたくなるが、CakePHPはそんなことはない。Ruby on Railsに似たMVC構成をとっているのもわかりやすい。その一方で、拡張しまくりたい上級者にも自由に使えるという、「全てのレベルのPHPユーザー」のためのフレームワークだと説明した。

　続いて、国内でのCakePHPの歩みについて解説した。黎明期は2005～2006年。p4lifeさんの「10分で作るCakePHPアプリ アプリケーション編」というスクリーンキャストが公開され、安藤さんを含め注目したPHPerが多くいた。そうしたPHPerによって、CakePHP.jpがオープン。CakePHP.jpではフォーラムが活発で、今でもおそらく日本でいちばん活発にCakePHPの話がされている。そうした中でCakePHPに関して書かれたブログが増え、CakePHPについて日本語で情報が読めるようになった。

　2007年は飛躍期。公開サイトで使われるようになった。「@ニフティトピックイット」というソーシャルニュースサイトが公開され、「CakePHPで作られている」という噂が聞こえてきたのでサポートに聞いてみたら本当だった。そんなことを聞かれてサポートも困ったと思うが（笑）。このころ、PHP勉強会でCakePHPネタをやったり、CakePHPに関する書籍がいろいろ出版されたりもした。

　2008年は発展期。CakePHP勉強会が始まり、このカンファレンスに至るまで、すごい勢いで参加者が増えている。世界を見ると、同じようにCakePHPのカンファレンスや勉強会が盛んになっている。「フェイス女学園」という、顔写真を投稿すると採点してくれるサービスが王様のブランチで紹介されたが、これもCakePHPで作られた。アシアルの調査した「いちばん使ってみたいPHPフレームワーク」でも1位をとり、去年から急激に伸びたようだ。

　ちなみに、PHPユーザー会の参加登録システムevents.php.gr.jpも、haltさんがえいやとCakePHPで作り直した。codereposにソースがあって、CakePHPなので手を入れやすいため、懇親会参加集計機能など便利な機能が追加されたりしている。CakePHPというと小規模サイト向けという印象があるが、このようにアクセスの集中するサイトでも使われている。Firefoxのアドオン配布サイトもCakePHPで作られており、信頼性が高くなってきた。

　最後に、CakePHPを始めるには。CakePHPは、あなたのPHP動作環境でもきっと動く、phpMyAdminと同じぐらい簡単と説明した。

　教材として、初心者限定のハンズオンをやったときの動画とスライドが公開されているので、入門にわかりやすい。また、公式マニュアルのbook.cakephp.orgは絶対にブックマークに入れましょうと紹介。日本語訳も整っていて、ブラウザ上から翻訳情報を投稿できるしくみで、コミットランキングもあり、協力して翻訳できるいいしくみ。中途半端に検索して古い情報を読むより、まず公式マニュアルを読んでからネットを探そうとアドバイスした。

　最後に、PHPを覚えたら、もう次はいきなりCakePHPを覚えるといいんじゃないかという言葉で締めた。

• Q：簡単といえ、それでもひっかかりやすい場所があれば
  • A：ハンズオンのときの経験でいうと、Apacheのmod_rewriteが有効になっているかどうか。設定ファイルの場所が環境によって違う。
• Q：stableの1.1を使うか、1.2を使うか、いつも迷う
  • A：きっと世界中で同じことを悩んでいるだろう。1.2は十分安定していると思う。events.php.gr.jpでも使っていて、負荷に耐えている。名前は言えないが企業のサイトでも1.2が使われている。迷ったら1.2。
• Q：1.2対応の「CakePHPガイドブック」の出版予定は（笑）
  • A：著者の間でも対応したいとはいっているが、未定

Agileな開発現場での実践例（岸田健一郎 永和システムマネジメント）

　アジャイル開発で有名な会社で、CakePHPを使って中小企業向け業務パッケージを開発した話。そこでXPをどう適用したかを、テスト駆動開発に絞って、かなり実践的に解説した。

　使ったCakePHPは、多言語対応のため1.2。5月から10月末まで2名で開発した。CakePHP自体に手を入れたのは、モデル名の表示の日本語化だけ。

　さて、CakePHPはテスト駆動開発向きかというと、実は向いてない（笑）。基本的に戻り値が連想配列なので、空の実装でアサーションするとエラーになる。なので、ある程度実装してからテストを書く。

　テスト駆動開発をKPTでふりかえると、Keep（続けたいよかった点）は、CakePHPがβ、RC1、RC2、RC3と変化しても影響度がすぐわかること。テストコードがあればアップデートしても追える。また、テストがあればデグレはほとんどない。さらに、テストコードがあれば、ほかのメンバーが書いたコードの意味を把握しやすいため、PHPを知らないRailsエンジニアが2か月で立派なCakePHPプログラマになった。

　Problem（改善したい問題点）は、テストケースもれがあったこと。また、Controllerのテストは書きにくいのであまり書いていない。さらに、テストコードが長すぎて失敗ケースだけやりたいのに時間がかかるということがあった。

　Try（次回の課題）は、Problemを受けて、テストコードを分割しようということ。テストの実行に3分以上かかるなら分割したほうがいい。また、MVCどこになにを書くか人ごとに違うので、パターン化してテスト漏れを防ぐ。さらに、メソッド単位でテストできるようにもしたい。

　こうした経験を受けて、CakePHPでテスト駆動開発するための「虎の巻」が語られた。

level 0 DBは$testで設定する

テスト用のDBを分けたいとき。'prefix'にDB名をセットする。

level 1 関連は自分でセットする

やらなくてもいいけどJOINされない。

level 2 名前づけ重要

CategoryTestのようなクラス名が被りがちなので、名前の規則をつけて被らないようにする。

level 3 fixtureに注意

テーブルも自動で作ってくれるが、スキーマ情報をインポートするとテーブルが自動生成しない。オレオレCakeTestFixtureを作ってしのいでいる。

level 4 コンポーネントは自分でセット

コンポーネントのテストで、そのコンポーネントを使っているところはテストされない

level 5 独自FormHelperは初期化が複雑

出力されるHTMLタグをテストするときなど。CakePHPのTestでいろいろ初期化しているので、それのコードを参考にするとよい。

Level 6 計算結果はassertidenticalで

assertだと「===」なので型がチェックできない。

Level 7 Shellテストの決まり

1.2からの機能。Shellクラスがない場合があるので、自分で書く

level 8 Controllerにロジックを書かないこと

Authなど依存関係が多い。なるべくComponentを使う

level 9 Mockは積極的に使おう

SimpleTestの機能。テストごとに条件を設定するための前工程をだらだら書くのはムダ。ただし、RC3からComponentの初期化がstartControllerより後になったので注意。実は、テスト用のコントローラにパラメータでさしかえられる。

　最後に、「面倒がらずに一度書けば何度でも役に立つのがテストコード」「初期化に罠が多いので注意しよう。逆にテストケース自体は普通の書き方」「Cake本体のテストコードがお手本」とまとめて、「これで明日（日曜だけど）からみんなTestでHappyに」と締めた。

• Q：テストを書くとそのぶん開発工数が増えるという声について
  • A：キャンペーンサイトなどの短い寿命のサイトなら必ずしも書かない場合も。自分たちがメンテするなら、バグ対応や再現が大変なので、テストを書く。ウォーターフォールで仕様がかっちり決まっているなら必要ないかもしれないが、Webのように仕様変更があるならテストを書こう
• Q：テストケース作成にどれぐらい割りあてているか
  • A：1アクションを1時間で、そのうちテストコードの実装は半分ぐらい。結合テストでバグが見つかるぐらいなら、倍かけてもいいと思う
• Q：倍がかかると、ボリュームがないと回収できないと思うが、線引きは
  • A：単体テストをしっかりやれば結合テストの時間は必ず削減できる。が、やはり周期の短いサイトでは厳しい。保守のコストも考える
  • （司会）OSSのフレームワークを使っていると、バージョンの変化があるので、テストがあるとフォローしやすい

午後のセッション前の小話

　挙手によるアンケートで、PHPを書くのに使っているエディタを質問。Eclipse、vim、Emacsが多いみたい。

Garrett J Woodworth氏 招待講演（Garrett J Woodworth：Cake Software Foundation）

　CakePHP開発チームのプロダクトマネージャによる講演。考えかたなどの抽象的な話をまじえつつ、わかりやすく説明していた。

　まずCakePHPの歴史を説明した。2005年の4月に、ポーランド人のマイケルさんがCakePHP 0.2を公開。このときはアイデアを形にしたという感じだった。同年の7月2日にはcakephp.orgが作られたが、7月6日にはマイケルがプロジェクトを離れた。Garretさんは9月5日に最初の投稿をして、10月4日にプロダクトマネージャになった。

　続いて、大学で哲学を専攻したという自分のバックグラウンドを語り、それを受けてCakePHPの思想を説明した。西洋の考えで「State of Nature」（自然の状態）という言葉がある。PHPのフレームワークができる前は、PHPもそうだった。それに対してフレームワークは社会のルール作りであり、CakePHPもカオス状態に秩序をもたらすという考えによるものだ。仕組みによって、より自由が得られ、問題に集中できるという考えだ。

　CakePHPのBest Principlesは、次のとおり。

intelligent defaults（理にかなったデフォルト）

書くコードの量が減る。必要なときだけ変更すればい。

simple readable code（短く読みやすいコード）

他の人がすぐにプロジェクトに参加できる。開発者すべてが短い時間に多くを達成できる。

limit the features（機能を制限する）

すべての機能をもりこむではなく、できるだけ多くの人が必要とする機能を。

make it work, make it will better

まず動くものを作り、あとから改善していく。

release early, release often

みんなからの反応が返ってくる。どんな使いかたがされているか、どんな問題があるかを早めにフィードバック。

　ここで、関数の設計の悪い例として、長い名前の関数に決まった引数を与える例をとりあげた。引数の種類ごとに関数が増えるし、機能が増えるとさらに関数が増える。そのかわりに、単純な名前の1つの関数に配列でオプションを与えるのがCakePHP流で、これなら柔軟だし、あとからオプションを追加できる。

　CakePHP開発チームは、みんなで話しあいをしてまとまっていくようにコーディングをしていく。ただ課題をのりこえるだけではなく、開発によってモチベーションを上げて経験と成長につなげていく。心がまえとしては、「be polite」（礼儀ただしく）、「design, test, review, document」（コードが取りいれられるまでの過程）、リファクタリングと最適化。

　CakePHPではチケットシステムを公開している。貢献度ごとに分けると、いちばん悪い例は、説明もろくになく、再現方法もなく、カテゴリもめちゃくちゃなチケット（笑）。それよりよいのは、説明あり、再現方法も書いてあるチケット。さらにがんばると、パッチもついている（笑）。もっといい努力は、テストケースがついていること。最高の努力は、テストケースとパッチの両方がついていること（笑）。

　さて、午前中に、1.1がいいのか1.2がいいのかという質問があった。1.1はstableで、フレームワークを使いはじめたばかりで問題にあいたくない場合や、波風をたて早く抜け出したいプロジェクト（笑）でおすすめ。リリース版は、earlyでoftenの考え方だが、プロダクションで使えるように、バグのチケットが出ているのにリリースすることはしない。

　リリース版以外では、trunk版は、挑戦的な開発者向けだが、それなりに安定しているもの。nightly build版は、その時点の開発版のスナップショット。branchは、開発のbleeding edgeで、バグがはいったり直したりしている現場だ。

　続いて、「Making Clean Code」の秘訣を語った。一番は、書く時間より長い時間を考えることに使うこと。また、話しあうことで、これまでに考えたこともなかったアイデアが出るかもしれない。そうして、コードを書く前に調査が済んで考えがまとまっている状態にする。「Think outside of box」、つまり、最善の答が、自分の慣れているパターン以外のところにある場合だってあるので、さまざまな可能性を考える。そして、チームには新しい機能をいれたがる人がいるかもしれないが、ちょっと待って細部まで考えることが大事だ。そうして考えたことや学んだ知識、ほかの人に伝えていくといい。

　ここで、「Bad cake」と「Good cake」を比較した。Bad cakeはControllerにコードがたくさん書かれているcake。テストが難しくなる。Good cakeはモデル部分がぶ厚くなって、フレキシブル。

　これからの予定は、1.2安定版がまもなくリリース。でもその前にRC4が出る。そのあと、1.3まではPHP4と5に対応する。機能も増やすので期待してほしい。

　2.0ではPHP5のみ対応にする。PHP5の機能を活用するためだ。3.0も将来的には出すだろうが、PHP自体もいろいろ変わるので、そのとき。

　book.cakephp.orgでは、日本のグループがNo.1なので、ほかの言語のグループの模範になってほしい。あと、bakery.cakephp.orgには、個人から投稿された技術記事がたくさんあるので、英語だけどぜひ参考にしてほしい。

　最後に、どのフレームワークがいいかという質問が世界中で飛びかっているということで、Zend FrameworkやSymfonyとCakePHPを比較してみせた。Garrettさんが使ったものさしは、バグトラッキングシステムでstable版に出されているバグチケットの数。ZendやSymfonyではstable版でもけっこうバグが残っているが、CakePHPではリリース前のRC3でも15バグ、これはバグがとれてからリリースするという方針によるものだと、CakePHPをアピールした。

• Q：「limit the feature」（秩序）と「think outside of the box」（可能性）のかねあいを、CakePHPコアの開発でどう考えているか
  • A：利用者のフィードバックが重要。チームでは日々話しあっている。たとえばプラグインシステム。プラグインシステムで新しい機能を開発できるし、ほかのプロジェクトでも使える。これをもっと簡単にできないかと考えている。
• Q：ControllerよりModelで書く、みたいなTipsをもうすこし
  • A：機能をどこに書くかを最初に決めておくのが大切。みんなが読みやすく、開発しやすい。1.2の機能として、同じコントーラでRSS、XML、JSONに対応できるようにしたので、コントローラを同じにしておくのが大事。1.2のAPIにいろいろ機能がつめこまれているので、それを理解するといいコードが書ける。
• Q：日本語には単数形と複数形はないが
  • A：Naming Conventionは重要。国を越えて開発者が理解しあえるだろう。
• Q：開発環境は
  • A：TextMate。
• Q：（英語の質問を聞きとれず）
  • A：No。チケットが残っているのにリリースすることはない。βからRC1までに時間がかかったのは、バグをつぶしたから。
• Q：機能拡張の要求に対して、判断基準は
  • A：まずチームで話しあって決める。機能がコンポーネントなどで実現できるならコアには入らないかもしれない。開発チームはみんな経験豊富なので、よい判断ができると信じている。

XoopsCubeなのにCakePHPを使う！（鶴岡直也 株式会社RYUS）

　「そろそろ眠くなったころかなと」とか「ビジネスの話」とか言いながら、軽妙な口調で濃いネタを話した。

　まず自己紹介。events.php.gr.jpやServices_Photozou、AuthKitten（ねこ認証）、Device_USB_MissileLauncher（USBミサイルランチャー操作）などを紹介して一部ビデオで紹介。で、EthnaからCakePHPに事実上乗りかえたと。

　前半ではXoopsCubeを紹介した。世の中のXoopsCubeで作られたサイトをいろいろ表示して、デザインがいろいろ変えられるところを見せた。XoopsCubeはモジュールで拡張できるCMSで、機能ごとにモジュールになっている。モジュールを一覧から選ぶだけで追加できて、PHPコードや設定が不要、ユーザーが業者なしでやれる（という夢を見れる）。

　ここで、カレンダーモジュールを例にXoopsCubeの内部構造を解説。基本は、index.phpからheader.phpとfooter.phpincludeして表示している。ここで実際にコードを画面に表示して、スーパーグローバル変数を参照しているとか、カオスとか、3,900行ぐらいあるとか解説した。

　ここから、モジュールとしてCakeアプリを載せるという話につなげた。前日に突貫で作った「CakeTwitter」をその場でインストール。が、ここでトラブル発生。コマンドラインのmysqlフロントエンドからdrop tableとかごにょごにょやってから、表示に成功した。

　ファイル構成を見ると、caketwitterフォルダの下がCakePHPでおなじみの構成になっている。Xoopsのindex.phpにしかけがしてあり、そこでCakePHPをレンダリングしている。ややこしいことしているのはindex.phpだけ。コードは、global xoopsUserだけXoopsで、あとはCakePHPのお作法。Xoops側のデータを使うために、XoopsのテーブルをCakePHPのモデルで使うには、useTableで直に指定。セッションがなやみどころで、Xoopsから呼ばれるのでCakePHPではセッションをスタートできないので切る。

　などなど、いろいろやっかいな点があるので、XoopsCube上でCakeを利用するためのモジュールの雛形として、「CubeCake」モジュールを作ったということが最後に発表された。CubeCakeをふつうにモジュールとしてインストールすると、CakePHPのデフォルト画面が表示される。あとはCakePHPとして開発する。その場で、「みなさんおなじみ、実務では使わないけど人に見せるときに使うコードです」ということで、var $scaffoldでデモしてみせていた。CubeCakeは、RYUS社のサイトに、社長にないしょで置いてあるとか（笑）。

• Q：MTみたいにぼこぽこ作れる機能があるといい
  • A：そのとうりだが、時間が足りなかった。
• Q：自分でもっと機能を持ったCMSを作ったほうがいいと思うことも
  • A：そんなふうに考えていた時期が私にもありました。が、やはりよくない。新しいものの学習コストがかかる。あるものを拡張して機能を追加するほうがよい。
• Q（Garrett）：外部とのやりとりをするコンポーネントを作ってそこでCakePHPとつなぐ設計は考えたことはあるか
  • A：今は考えていない。XoopsCubeには外部と通信する機能はあるので、そういうものと組みあわせると面白いかなとは思う。

LT：Tplcutterを用いた超高速ウェブサイト開発（MASA-P）

　ここからはライトニングトーク。一番手は、Viewを簡単に実装できるツール「Tplcutter」。

　デザイナーに制作依頼して、できたHTMLを元にViewを作る場合がよくある。このとき、デザイナーはhelperなどの部分を確認できない、いちどViewを作ったあとデザイナーに再変更してもらうのが難しい、更新すべきファイルが点在するためミスが入る、といった欠点がある。

　そこで、デザイナーからもらったファイルを丸ごとコピーするだけでいいように「Tplcuter」を作った。CakePHPでも使える。元のHTMlにコメントタグで指定を入れておき、所定のディレクトリにコピーしてコマンドを実行すると、Tplcutterがテンプレートとレイアウトに分割してくれる。ということで、実際にデモしてみせた。

LT：I love CakePHP（MODE A あおき）

　旅行会社のサイトをCakePHPで開発した話。メリットとして、Ajaxが簡単に書けた。いままでの旅行サイトでは旅行代金の計算のUIが使いづらいが、その場で確認できるようになった。

　開発にあたり、基幹系DBとしてマイクロソフトのSQLServerが動いていて、テーブル名やカラム名に日本語が使われていたが、動いてよかっった。

　最後に、1.1で開発したので1.2に移行したい、ということで、問題はどうやってクライアントからお金をもらうかだ（笑）ということでまとめた。

LT：CakePHPで連想検索（青木隆平）

　連想検索とは、「言葉相互の近接性を根拠とした連想結果を提供する検索エンジン」とのこと。利用法として、だれかの問いに新たな視点を投げかけるツールができるが、コンテンツホルダーが気軽に連想検索を利用できる機会はない。そこで、CakePHPで連想検索が気軽に使えるCMSを作るという「AssocPublisher」プロジェクトをやっていることを紹介した。現在開発中で、完成したらオープンソースで公開する予定。ブログで開発の顛末記を連載している。

LT：CakePHPerのためのBDDのすすめ（梶原大輔）

　BDD（Behavior Driven Development:ふるまい駆動開発）は、ふるまいにあわせて仕様を書く方法で、RubyのRSpecが有名。PHPでもPHPSpecがあって、ドキュメントも充実、インストールもPearで簡単だと紹介した。

　CakePHPはSimpleTestでユニットテストしているといいつつ、CakePHPでPHPSpecを使ってみせるところをデモしてみせた。今後、Webからできるようにするとか。

Garretに質問

　最後に司会者さんが、Garretさんに日本の開発者へのリクエストを質問。Garretは、今日の発表などいろいろ面白いので、日本語以外のCakePHPユーザーへも情報を発信していけるとうれしいと答えた。

　タイトルは若干釣りぎみ。オンラインニュースのvirtualization.infoより。

• Fedora 10にはXenが搭載されず、KVMの独走が続く（20081022-2） | virtualization.info

単なる偶然に過ぎないのかもしれないが、リリースされたばかりのFedora 10にはXenが搭載されていない。

　Fedora 10はまだリリースされていないと思いますが、それはさておき、Fedora 10 betaのインストールDVDを調べたらxenパッケージとかxen対応カーネルのパッケージとかは入ってませんでした。へー。

　ただし、rawhide（開発版）リポジトリには入っています。Fedora 7以降はFedoraのメインのリポジトリとextrasが統合されていて、公式パッケージがすべてインストールメディアに入っているわけではありません。オンラインで使えるフルセットのEverythingリポジトリには入るんじゃないかなぁと想像しています。

　…まぁ、プライオリティは下がっていますよねぇ、うちら外部から見ると。

追記2008-10-26： "There is pretty much zero chance that Fedora 10 will include a Xen Dom0 host." って言ってるのか。へー。

　さきごろ亡くなった、ワイドスクリーンバロックの旗手、バリントン・J・ベイリーの処女長編。ご多聞に漏れず大好きな作家だったので改めて読み直してみた。やっぱり面白い。R.I.P.

　基本的には、常にマントを身に着けて黄金の光線銃を持った宇宙海賊の物語。なんだけど、どんどん奇想がプラスチッキーで悪趣味に詰み重なるB・J・ベイリー世界になっていく。慣れないがゆえの描写の軽さも、かえってA・E・ヴァン・ヴォクトっぽくていい。ネタバレは避けるとして、構図としては秩序と非決定性の対立？

　ちなみに、ウィリアム・バロウズの小説「爆発した切符」で、本書が言及されている。以下、引用。

デッドライナーというのを思いついたのは『ニュー・ワールド・サイエンス・フィクション』……ノバ出版社・七グレープ通り・ハイ・ホルボーン・ロンドン・四九巻・六月号……に掲載されたある小説からだ……J・バリングトン・ベイリー著『スター・ビールス』からだ……この小説に出てくるデッドライナーたちは光年を旅する宇宙旅行者で、人間との接触が不可能で、恐怖感をも失っている。彼らは原子核ポーカー遊びをする。このゲームに加わるということはプレイヤー自身も家屋敷をも爆破されることだ……

　喰輪杯（クイリンピック）の第1回戦の続き。主人公の対決がまだ先で出ていないので、ステロタイプなのを活かしてテンポよく進む。さて、主人公は、どう盛り上げるか。

　へー、テレビドラマ化かぁ。

　それはともかく、推理マンガの最高峰「Q.E.D.」の最新刊。「眼の中の悪魔」と「約束」の2編を収録。今回は、Whodunnit（犯人）やHowdunnit（手口）が弱めで、塔馬君の行動を含めたWhydunnit（動機じゃなくて、それも含めてなぜそういう状況になったかのロジック）が中心になっていると思う。

　「眼の中の悪魔」は、若手研究者の資料が消えた事件を追うエピソード。推理のロジックもあるけど、どちらかというと科学者と倫理を描いている作品。

　「約束」は、冬山での約束と殺人事件の関連を探るエピソード。約束シーンのアレと、繰り返される「絶対できん」が、こう結びついたかとびっくり。ラストは切ない感じ。

　本書を読むまで、藤原氏は道長以後は衰退しちゃったのだと思っていた（←無知）。が、実は貴族が藤原氏だらけになったので家名で呼ぶようになり、近衛家・九条家・二条家・一条家・鷹司家の五摂家などが藤原氏であるとか。さらに、平安朝のはじまりとともに起こった藤原氏の摂関政治は、途切れることなく明治維新まで続いたんだとか（秀吉も藤原氏の名義で関白になった）。

　というわけで、藤原（中臣）鎌足にはじまり、藤原道長で頂点を極める藤原氏の歴史を、代ごとに、そのときの政権内部や天皇家にからめて語る本。政略で独占的な地位を築いていく飛鳥・奈良時代から、藤原氏内の勢力争いを経て「この世をばわが世と思ふ」に至る平安時代、それに比べると斜陽の武士政権時代などを、その代の人物の姿を中心に解説している。

　「カイジ」系というか、トリック対決モノのマンガ3本の新刊が、先月同時期に出た。

　「賭博覇王伝 零」は、「カイジ」の作者のマンガ。対決相手が主催者のせいか、出された問題を解いていくタイプのエピソードが多い。TV番組風というか。



　「LIAR GAME」は、3つの中ではテクニカル指向。今回も、表面上のルールの裏を読んでいく対決が続く。



　「嘘喰い」は、対決内容より、対決そのものがメイン。今回は、対決自体がトリックになっている。



　以上、書いてみるとごくあたりまえの感想だけど、あくまでメモとして。

　Lispコミュニティ「Shibuya.lisp」のテクニカルセミナーイベント「Shibuya.lispテクニカルトーク#1」が、2008年10月18日に開催された。参加したのでメモ。間違いがあったらご指摘ください。

　全体の感想として、アプリケーションにLisp処理系を組み込んで自由度の高い開発をする、といったような話がいくつかあり、Lispは研究言語ではなく実用言語なのだなと改めて思った。あと（自分も含めて）Emacsだらけ（笑）

Why Lisp（higepon）

　司会のharupiyoさんのあいさつのあと、higeponさんのオープニングスピーチ。まず「50って何でしょう」という質問に、客席のえんどうやすゆきさんから「Lisp生誕50周年」という答えが出た。そこからRubyやJavaとは年季が違うというジョークに。

　で、最近の日本ではLispの本やチャットなどがけっこう活発。しかも、日本にはなぜかScheme実装者がたくさんいる（会場笑）。へたするとユーザーより多いかも（笑）。

　最後に、「Lisp is hot now!」「Enjoy λ」ということで、会をスタートした。

50万行orderのプロジェクトを俺Lispで書く（mitamex4u）

　元々、ゼンリンの電子地図ソフトを開発した人だそうな。で、10年前と今の同様のソフトを比べると、ソフトの規模も大きくなり、2人で開発していたのがチーム開発になり、デスクトップアプリがサーバークライアントになり、といろいろ大変になっている。

　で、携帯向けの地図アプリを開発するにあたり、「楽をしたいから」Lisp処理系を作ってその上でアプリを動かしたというのが今回の発表。「Lispを目的としたものではない」と語っていた。どうしてLispなのかというと、携帯上でコンパイルができてREPL（read-eval-print loop）も動く動的言語はLispしかなかったから。Java VM上で動作し、必要があればホスト言語のJavaと書き分けられるようになっている。

　名前はL4uで、「Lisp for you!」の略。「最後の"!"は、現状に破壊的操作をするという意味です」というのはジョークか本気か。Lispになじみのないチーム全員に拒否反応なしで使ってもらえるように、Algol系ふう（というかちょっとRubyふう）の構文で書けるようになっている。これはプリプロセッサで変換しているので、S式で書いてもよい。実態はScheme。S式のパワーを活かして、XMLのかわりにS式で通信するので、XMlパーサーが不要でコードサイズが小さくなった。開発メンバーには、まずJSONでデータを返すように開発してもらって、それをS式に変換する関数をかぶせた（開場笑）。

　細かい仕様では、リストに似たタプルというデータ構造を取り入れた。「{a b}」のように波カッコで書き、評価すると自分自身を返すのがリストと違うところ。これによりSXMLで「(body {bgcolor #ffffff})」のように単純に書ける。

　また、携帯アプリはI/Oや描画、GPSなど非同期だらけということで、Erlangを目指してアクターモデルによる超並列を実装。共有メモリなしですべてメッセージパッシング。メモリがゆるすならスレッド100万個でもOK。「(parallel 式1 式2 ...)」で並行実行し、「target.send」でメッセージを送信、「(receive)」でメッセージをタプルとして受信する。アクターモデルには開発を切り分けられるメリットもあるとか。

　携帯からサーバーまで複数のプラットフォームで動作する。携帯ではDojaやMIDP。サーバーではLinuxやWindowsのJava VM。なんと.NET FrameworkのManaged C++／C#にも対応した。ホスト言語との連係が前提。実行するだけでプロファイリングして、遅い部分はJavaで書き換えるようになっている。オブジェクトのメソッド呼び出しはJavaふうにもCLOSふうにもObjective-Cふうにも書けるようになっているが、Javaに書きかえる前提だとJavaふうに書くのがよい。また、サーバーとクライアントの切り分けは、スループット重視の処理はサーバー側、レスポンス重視の処理は携帯側というところ。

　Lispにした理由のひとつが、携帯上でREPLが動くこと。実機デバッグできれば原因がすぐわかるのにとか、デザイナから細かい修正が来たときにアップロードが面倒とかいうときに便利。また、リモートデバッグも用意した。携帯からリモートデバッグのサーバーにHTTPでポーリングしてコマンドを受け取るという力技。

　へぇと思ったのが、Algol系ふう文法で関数呼び出しチェーンを見易くする工夫。ある式の後に続く式では、「it」という変数に前の式の値が束縛されている（なでしこの「それ」相当）。また、「式1 -> 式2」と書くと、左の式の値が右の式の第1引数になる（それにあわせてmapの引数の順番も逆にした）とか。

　そのほか、テンプレートシステムとか、同期動作版call/ccであるdelegate/cc（IME入力待ちなどで使用）とか、Cの「#define」や「#if」のような構文（携帯端末ごとにコードを切り分けるのに利用）とかいうのもあった。

　2009年オープンソースで公開予定、大人の事情でもうちょっと待ってね、とのことだった。

• Q: Rubyみたいな軽量処理系が携帯上で動くとしたらそちらを使う？
  • A: もう開発してしまったので乗りかえない。私はLisp面に落ちてしまったし（笑）
• Q: マクロは？
  • A: 未実装
• Q: どうやってまわりを説得したか
  • A: Lispといわずに「新しいスクリプト言語を作った」と（会場笑）

HyperSpecひとめぐり（NANRI）

　xyzzy lispのリファレンスの世話をしていた人。「HyperSpec」はANSI Common Lispの正式な仕様で、会場に多いであろうSchemeの人を対象に想定して、Common Lispの仕様のすごい部分を紹介した。

　Hyper SpecはLispwork社のサイトで公開されている。印刷すると1,300ページ超。ちなみに、CLtL2は途中の仕様で、これでも日本語訳で900ページ。

　NANRIさんが感心したところとしては、数の体系がある。整数、有理数、実数、複素数と、正確数と非正確数の区別がある。ふつうの言語では違う型の数値を演算すると結果は大きいほうの型になるが、CLでは逆の変換をする場合があるとして、有理数の正準化（分母が1なら整数に）と複素数の正準化（虚部が0なら整数に）を紹介した。さらに、複素数の虚部が0.0だと正準化されない（実数は非正確数）という仕様があり、これはSchemeではR6RSではじめて登場した仕様だとか。

　数の体系については、数学的な整合性が目的か、パフォーマンスのためか（虚数でないことがわかれば虚数演算ルーチンが不要になる）、といった話が質疑応答で話題に出ていた。

　また、ほかの言語になさそうな仕様としては、コンパイラが仕様に含まれること。disassemble関数もあり、デバッガも仕様に含まれる。エディタも仕様に含まれていて、「(ed x)」とするとエディタでxを開き、xが関数名なら関数定義を開く。どんなエディタが起動するかは処理系依存で、SBCLの場合は変数*ED-FUNCITONS*にエディタを開く関数を入れておく。

　後半は、Emacs上の開発環境SLIMEからSBCLをデモした。

Scheme on Pinball（fujita-y）

　Scheme処理系Ypsilonの実装の話。CPUアーキテクチャとからんだ高速化の話がばんばん出てきて、すごく面白かった。

　仕事でピンボールゲームを作っていて、Windows・Macのパソコンから、PS、ドリキャス、アーケード機などいろいろなアーキテクチャーに対応している。実装はC++。役物にバリエーションを持たせる必要があり、ピンボールコンストラクションキットを作りたい。GUIは簡単だが、ルールをコーディングするのが大変。そこで、Ypsilonを実装した。

　要求として、描画がフレーム間5msec以内。このスピードに対応してGCがある処理系ということで、Schemeを採用した。YpsilonはR6RS準拠のSchemeインタプリタでセルフコンパイル。マルチコア対応（ゲーム機はマルチコア）のコンカレントGCを使って極めて短いGC停止時間を実現。あと、アーケード機では電源を入れっぱなしにして動き続ける必要がある。コンセプトは、ポータブル（pthreadがあればいい）、メンテナンス性（OSが変更されてもちょっとコードをいじって対応）、デバッグ機能、不得意とするコードがない（下手なコードでもそこそこの性能）、そのうえで速く。

　で、最適化の話に。まず基本的な最適化として、Direct Threading、Super Instruction、Operand Fusion、Cache Accessを利用している。

　Direct Threadingは、間接分岐の分散により分岐予測のヒット率を上げ、Instruction Cacheの効率を上げる。そのために、AST（抽象構文木）にVM命令処理コードのアドレスを直接書き込む。ただし、GCに注意しなくてはならないため、アドレスのアラインメントをそろえて下位3bitで判別する（タグ不要）。さらにud2命令（未定義命令例外）でprefetchを抑制し、Bus TrafficとInstruction Cacheの使用を抑制した。これにより、takで7.8%、taklで11.8%の高速化を実現した。

　Super Instructionは、VM命令数を少なくして、Dispatchの回数を少なくする。これにより、Data Cacheの利用効率が上がる。コンパイラが命令を結合することで、VM命令の処理コードが長くなり、C/C++コンパイラによる最適化を期待できる。ただし、コードの局所性が失われる、使われないコードが局所的に集めたはずのメモリエリアを使うというトレードオフがあり、よほど頻繁に仕様されるコートでなければ逆効果になる。

　Operand Fusionは、Operandの固定された特化命令。動的言語ではOperandのタイプチェックが不要になる。ただし、Super Instructionと同じような効果とトレードオフがあり、Super Instructionと同時に使うと命令数が爆発するという問題もある。

　Cache Accessは、CPUの一番のボトルネックであるメモリアクセスをできるだけ少なくするもの。たとえば、構造体の中でメンバの順番を変えただけで速度が大幅に変わったりする。とくに、Intel Coreなどは、InstructionとDataでL2 Cacheが共通なので、Cahce Lineコンフリクトに注意する。VMではInstruction Cacheが一般プログラム以上に重要で、間接分岐が多いため投機的Prefetchも有効に働かない。Cacheのチューニングは、とにかくベンチマークで特定する。広範囲に発生する場合は優先的に解消。このときはvtuneはあてにならず、経験と勘と根性（笑）。特定の箇所で発生する場合は、CPUやコンパイラで変わったりするので気にしない（笑）。

　さらに、Scheme専用の最適化として、Stack GCとStack Closureを上げた。前置きとして、Schemeのスタックトレース表示では、末尾再起が最適化されるのでそこの呼び出し情報が消えてしまうが、Ypsilonではソースまで含めて表示できる、という話。これは、一般的なSchemeでは末尾呼び出しでスタックフレームをスライドさせて縮めるが、Ypsilonでは呼び出し時にスタックフレームを縮めずGCのフェーズで縮めるという方式（Stack GC）を採用したことによるもの。これにより、フレームのコピーを省略できることが、いまのCPUでは性能的に有利になる。いっぽう、末尾再起するだけでもGCが発生するのは弱点。そのほか、末尾呼び出しの呼び出しがスタックに残っているとGCによって回収できるフレームが少なくなるので、そんなコードを避ける。

　また、Schemeでは、Closureを作るたびにClosureをヒープに作成する実装が多い。しかし、自由変数がスタックの上側からしか参照されないClosureを検出できれば、スタックフレームのままでよい（Stack Clusure）。これにより、コピーのコストが不要になることや、ヒープのあちこちを参照しなくてよい局所化のメリットがある。ただし効率のよい実装にはStack Closureの併用が必要になる。

　さて、Ypsilonの売りであり、同時にいまでも苦労しているところがConcurrent GCだ。Mark&Sweep方式を利用。基本は簡単で、まずMutator（VM）を止めてMarkのルートになる要素を取る。そうしたらMutatorを再開してしまって並行してCollectorがMarkをする。VMはゴミにアクセスすることはないので、Sweepは並行してできる。Schemeは破壊的操作が少ないので、やりやすい。

　…と思ったが、そんな簡単に終わらなかった。試したところ、2コアのマシンでは普通のGCよりかなり遅く、1コアのマシンで普通のGCよりちょっと遅いという結果になった。これは、MutatorとCollectorが激しい競合をしていたため。アロケーション時にMarkビットを立てているのが、GCと競合していた。

　そこで、Incremental Updateにあっさり変更した。新規アロケーションに特別の処理が不要で、Mutatorの動作が速くなった。で、Mutatorが速くなったため、時間あたりのアロケーションも増え、メモリスタベーション（メモリ飢餓）になるという問題となった。Sweepで競合が起きていて、本来Sweepは競合しないはずだが、Collectorが巡回していない場所からメモリを確保する場合はMarkビットを立ててやる必要があり、その部分が競合していた。

　そこで、CollectorがSweepをすませたところからアロケーションするように変更した。で、Mutatorが速く（略）メモリスタベーションになるという問題となった。しかたがないので、VM自体を変更してアロケーションを減らす（Stack Closureもそう）ように変更したら、Mutatorが速く（略）メモリスタベーションになるという問題となった（会場笑）。で、どうしようと。

　最後に次回予告「スピンロックに失望」ということでまとめた。

• Q：もうピンボールに組み込んだか
  • A：バグがあって見送った。次から
• Q：スピード要件は
  • A：GCタイムが0.5msecぐらい（会場驚）
• Q：ピンボール全体をYpsilon化する計画は
  • A：力学パラメータの変更などを試せるようにしたい
• Q：Mark & SweepのGCの動作と、キャッシュや局所化は、反対の性質があるが、工夫はあるか
  • A：スラブアロケータでコンパクション。密にするコンパクションと、先頭に集めるコンパクションの2段階。が、実はヒープをコンパクションすると遅くなることも多い。これは、最初にリストを作るときにはセルが隣りに連続してくれることが多く（cdrコーディングのように？）性能がよいが、コンパクションしたときに並びがかきまわされてしまう

LT：世界のナベアツにGaucheで挑戦する（yshigeru）

　ここからLightning Talk。一番手はFizzBuzz問題ならぬナベアツ問題。なんと、問題をS式で表わし、「アホになる」というシンボルを動作登録の関数に、「3 の倍数なら」というシンボルを条件登録の関数にして、言語内DSLにしていた。で、そのS式をGaucheに与えて、みごとナベアツに。

　なお、ハイテンションでウケた発表に対し、司会がクールにまとめていたのがさらにウケていた。

LT：はじめてのScheme（masa.edw）

　「5分でわかるquine」ということで、quine（自分自身を表示するプログラム）をライブコーディング方式で作ってみせた。使ったのは、formatとlet1。formatに"format"を食わせると表示されるけど、増えたformatを表示するために"format"を追加するとまた…とイタチごっこ。そこでlet1を使ってみて、ここが同じだぞ、ではlet1した変数を使って、できた！ という発表だった。

LT：マイナーRPGはlispで（odaさん）

　2000年ごろに仕事で起きた体験談。ゲーム会社ではないのに、いきなりRPGを作ることになった。しかも、壮大すぎるストーリーに自由度の高すぎるゲームシステム。おまけに、2人で半年というムチャな要件。

　これをクリアするには、自在なデータ構造、インタラクティブ開発、メモリ管理、マクロが欲しい。これはつまり、「毎日使っているエディタに入っているアレだ」ということで、USIというLisp処理系を作った。部下

や手伝いが「Lispわかんない」というので、JavaScriptふう（一部Perlふう）のシンタックスシュガーも作った。

　という苦労をして、RPGを1年間で開発して出荷。とりあえず大きなバグは出なかった。オチは「売れなかったけどな（笑）」。

LT：ケーゾク小説（oskimura）

　暗黒通信団というサークルで、中身のない本とか、eの本とかを作ってコミケに出している。ISBNも取得済みで、Amazonでプレミア（笑）。

　次はSchemeで「継続小説」。AMB評価器を作ってマルコフチェーンとランダムウォークで文章を生成し、その場でプリントアウト、というネタだった（笑）

　最後に、実況板のテキストを元に生成済みのテキストをデモした。

LT：Gaucheのプログラムをもっと速くする方法（小黒直樹）

　マンデルブロの表示とプログラミング過程の自動表示（ttyrecか？）を使って洗練された感じのプレゼン。Gaucheだけでやると遅い局面があるので、Cで拡張モジュールを書いたりする。が、Windowsでは動かない拡張モジュールも多い、S式じゃない、インタラクティブじゃない。

　そこで開発したのがdyncomp。S式でCを表現して、組み込みのTCCでコンパイル、その場でインタラクティブに実行する。Gauche中にインライン化可能。Unix & Win対応。

　デモでは、マンデルブロ表示のSchemeコードをエディタで書いて実行し、それをその場でdyncompな関数で置きかえて高速化してみせた。

LT：CL/SCchemeの組み込み利用（mokehehe）

　Lispをリアルタイムアプリケーション（ゲーム）に組み込みたいので、いくつかためした体験談。

　まず試したのがECL (Embeddable Common Lisp)。バイトコードにコンパイルして実行したり、Cへトランスレートしたりできる。が、cygwinでmakeできず、ソース構成も難解だったのであきらめた。

　そこで、Gaucheをライブラリ化してみた。不必要なソースを除外し、必要な共有ライブラリや.scmファイルだけを配備して、呼び出し側のCコードを書いた。

　ここでDirect Xでデモ。Luaより速いが、ライブラリのサイズはLuaの9倍（笑）。ただ、GCがBohemで不安、例外がわからない、などの部分は未解決。で、Ypsilonはさらに倍の速度が、というところで時間切れ。

LT：初心者がgaucheでロボット制御（momo_dev）

　バンダイロボット研究所所属。自分が開発に参加している探査ロボット「NetTansor」をGaucheで操作してみせた。NetTansorにはLinuxが載っていて、カメラや障害物の距離を測るセンサーなどがついている。センサーの値はポート8081番、カメラ画像はポート80番のHTTPでとれる。

　ということで、gauche-gtkなアプリから会場でNetTansorをコントロールしてみせてデモしていた。Gaucheはスレッドとかも簡単に使えて実装しやすかったとか。

　面白そうなんだけど、価格は5万円。なお、今度出るニューモデルではなんと写真をとって文章を生成してブログに投稿する機能も追加されるとか。すごい。

LT：Reading Gaucheしてみませんか（ココサブ）

　すみません、最後の最後でノートPCのバッテリーが尽きてしまいました。以下、記憶で。

　Reading GaucheプロジェクトでGaucheのソースを読みすすめている。ひらメソッドを使う。トップダウンでWikiのページを作り、末端まで行ったらボトムアップで読む。これで、Gaucheの実装がわかった、ファイル分けなどのコツがわかった、LTに出られた（笑）

　Wikiでやっているので参加者募集中。終わったら、次はStalinかYpsilonか、それともcompile.scmか、あるいはGCCか。

　不覚にも「ナニ金」の続編が出てるとは知らなかった。書店の店頭で見て、よくある続編のトーンダウンっぷりを覚悟しつつ買ったのだけど、とりあえずいいほうに期待を裏切られた。物語として、あの「ステロタイプを追求することで生々しさを描く」路線を受けついでいると思う。本家に比べると、追い込みがヌルいとか、ステロタイプに徹しきれてないとか、シモネタで話を薄めてるとか、2巻で早くもペースが遅くなってるとかいうのはあるけど。なお、2巻では「あの男」が帰ってきた。

　手口のメモは、ネタバレなので、続きを読むで。

続きを読む »

　セサミストリート風というか、最近のNHK教育風というか、寸劇をうまく多用した入門書「Head First」シリーズに、SQLの入門書が登場した。このシリーズ好きなんだけど、いかんせん厚くて、量というより通勤電車では読みづらいため、なかなか通読できず、ようやく読み終わった（←いいわけ）。

　わかりやすいのはもちろんのこと、SQLそのものよりデータベース設計（正規化とか）の基礎についてかなりページを割いている正統派ぶりが、自分のような非IT系サラリーマンにも勉強になった。

　DebianのPerl 5.10な環境にHatena::Keywordモジュール（バージョン0.05）をインストールしようとした。が、make testが通らない。「HTTP::Message content must be byte」とかそんなエラーメッセージが出る。

　Hatena::Keywordの中を見ると、こんな処理がされていた。

    $body = pack('C0A*', $body); # hacking for utf-8 flag

　調べてみたら、数年前にShibuya.pm方面で流行った（？）技らしい。

　ためしにコード片を書いてみる。

#!/usr/bin/perl
use strict;
use warnings;
use utf8;

my $text = 'あいうえお';
$text = pack('C0A*', $text);
print $text, "\n";

　まずPerl 5.8で試す。

$ perl hoge.pl
あいうえお

　続いてPerl 5.10で試す。

$ perl hoge.pl
Wide character in print at hoge.pl line 8.
あいうえお

つまり、Perl 5.10ではこの方法でutf8フラグが落ちないようだ。さらに調べると、Kawa.netさんのブログで、packの仕様変更が詳しく解説されていた。

　結論として、手元ではEncode::encode()を使うよう書きかえるのがてっとりばやそう。

　仮面来訪神とイザナギ・イザナミ神話、鯨を結びつけた「鯨神」、神功皇后伝説とギリシャ神話を結びつけた「女帝星座」、渡り鳥が小枝をくわえて海を渡るという伝説を扱った「雁風呂」の3編。いずれも海に関係が深い。「雁風呂」は、第8集にひきつづき、テーマを薄めにしてドラマっぽい方向に振った路線。

　bashに関する逆引き形式の入門書。つまり、体系的というよりは、小技やTipsを軸に、どちらかというと即物的に解説していくスタイル。より体系的で踏み込んだ内容については、本書の「はじめに」でも書かれているように、「入門bash」あたりを併読することになると思う。

　シェルスクリプトとコマンドライン（readlineや補完設定を含む）のほか、ssh-agentやscreen、subversionなどのごく簡単な入門まで扱っているのが、いかにもbashらしい。共有ライブラリによる内蔵コマンドの追加も、ちょっとだけ扱っている。

　私はman bashや「入門bash」を拾い読み（通読ではなく）したぐらいの知識しかないので、いくつか参考になった。そのうち「入門bash」も通読しなくちゃ。

　以下、自分の勉強メモとして、知らなかった機能と、内容の補足。

知らなかった機能

レシピ2.14 複数のコマンドからの出力の保存またはグループ化

{ pwd; ls; } > /tmp/all.out

　いままで同じことをサブシェルでやっていた。知らなかった。

レシピ5.7 シェルスクリプトでのパラメータの使用

　$10は${10}ではなく${1}0と解釈される。やってみたら本当だ。

レシピ6.8 正規表現による評価

　bash 3.0以降では「[[ 文字列 =~ 正規表現 ]]」が使える。おお、正規表現が使えるのか、すばらしい。

$  [[ 'abcdefg' =~ a.*(c.).*g ]] && echo ${BASH_REMATCH[1]}
cd

　手元のman bashでは、日本語版には書いてなかったけど英語版には書いてあった。

レシピ10.5 関数の使用：パラメータと戻り値

　シェルの配列変数FUNCNAMEに、シェル関数の呼び出しバックトレースが入っている。$FUNCNAME（${FUNCNAME0]と同じ）でその関数自身の名前がとれる。

レシピ12.3 MP3プレイヤーのロード

　関数定義の本文は「{ }」（グループ化）でなくてもいい。へー。

function REDUCE()
(( FREE-=${1:-0} ))

レシピ14.3 安全な$PATHの設定

　getconfコマンドで変数の標準の値を調べる。

$ getconf PATH
/bin:/usr/bin

レシピ15.5 可搬性のあるforループの使用

　bash 3.0以降では、{n,m}構文が使える。「Re: コマンドラインで連番のファイル名を作る」でzshの例として指摘をいただいた方法の低機能版ですな。

$ echo a{1..5}  # 1桁の数字
a1 a2 a3 a4 a5
$ echo 1{a..e}  # 1桁の文字
1a 1b 1c 1d 1e

レシピ15.13　「引数リストが長すぎる」エラーへの対処

　コマンドの引数（を展開した結果）の個数はARG_MAXの制限を受けるが、forに指定するリストは受けない。へー。

レシピ16.12 シェル履歴オプションの設定

　bash 3.xでは、シェル変数HISTIMEFORMATを設定することで、履歴に日時を追加できる。

レシピ17.2 LinuxでのGNU TexinfoおよびInfoの使用

　「（Linux上のGNUツールでは）従来のmanpageはスタブにすぎない」。

レシピ17.10 diffとpatchの使用

　単語単位のdiffをとるwdiffコマンド。

レシピ17.16 一方のファイルにのみ存在する行の検出

　行ごとにファイル1、ファイル2、共通行をカラム表示するcommコマンド。

レシピ17.24数字の桁区切り

　printfの「'」フラグ。

$ printf "%'d\n" 12345
12,345

レシピ19.13 スクリプトのデバッグ

　bashのデバッガが作られているらしい。「The Bash Debugger Project」。DebianやUbuntuにあるbashdbパッケージってこれかな。

付録B bashに含まれているサンプル

　「./loadables/perl/　Perlインタープリタをbashに組み込む方法」。へー。

内容の補足

レシピ1.3 コマンドの検索と実行

　「解説」がtypeコマンドから説明しているのに、「解決」にはtypeが載ってない。

レシピ1.10 Linux用のbashの入手

　Debianでbashパッケージとbash3パッケージに分かれているとあるが、2008年10月現在のstableであるetch以降ではbashパッケージにbash 3.xが収録されている。原著の出版時期としてしかたがないけど。

レシピ2.11 ファイルの先頭または末尾だけの使用

　間違いではないけど、「head -<行数>」は最近ではGNUやBSDのmanからも削られている古い形式だと思う。

レシピ5.18 文字列の部分的な変更

　悪い例としてこう書かれているけど、

mv "${FN}" "${FN/.bad/.bash}"

例として上げられているような結果には、下のように書かないとならないと思う。

mv "${FN}" "${FN/bad/bash}"

レシピ6.1 シェルスクリプトでの算術演算の実行

　「$((式))」と「let 式」が紹介されてるなら、「((式))」が同じく並んでいてもいいと思った。man bashでも「This is exactly equivalent to let "expression"」とあることだし。

レシピ6.4 複数の属性の評価

　testで-oの前の式が真になったときだけ後の式のパラメータ置換を処理するには、「if文を2つのネストされたif文に分解すればよい」とあるけど、「[ 式1 ] && [ 式2 ]」でいいと思った。

レシピ7.3 検索結果からの真偽値の取得

grep findme bigdata.file > /dev/null
if [ $? -eq 0 ] ; then echo yes ; else echo nope ; fi

は、わざわざ$?を持ち出さなくてもいいんじゃないかと。

if grep findme hoge.sh > /dev/null ; then echo yes ; else echo nope ; fi

レシピ9.2 特殊文字が含まれたファイル名の処理

　findの結果をxargs -i '{}'に渡すことについて「findコマンドの-execを使用する利点は、特殊な文字に対処することだけである」とあるが、どちらでも同じ結果になるようだ。

レシピ10.2 inlcudeとsouceによるコードの再利用

$include $HOME/myprefs.cfg

が.inputrcではなくシェルスクリプト中で使えるのは、単にシェル変数「include」の値が空になっていて「$HOME/myprefs.cfg」がコマンドとして実行されているだけなのではなかろうか。

レシピ10.2 inlcudeとsouceによるコードの再利用

　「レシピ10.3で示すように」→「レシピ10.4で示すように」、かな。

レシピ13.1 シェルスクリプトの引数の解析

shift $(($OPTIND - 1))

　細かいけど、レシピ6.19でせっかく「$((...))式の内部で変数名に$を使用する必要はない」と解説しているので、OPTINDに「$」はなくていいんじゃないかろうかと。あってもいいけど。

レシピ13.9 1文字ずつの取得

　readで1行読んで文字列操作で1文字ずつ取り出しているけど、read -n 1でいいのではなかろうか。キーボードからの入力を除いて。

レシピ13.14 ホワイトスペースの削除

　ホワイトスペースが削除された出力の例にすべてホワイトスペースが残っている。

レシピ17.7 ログアウト時の画面の消去

　参照URLで「Faraday_cag」→「Faraday_cage」。

レシピ17.17 最後のN個のオブジェクトの維持

　「$files_to_nuke=$(shift_by 5 $(ls ?))」は「files_to_nuke=$(shift_by 5 $(ls ?))」だと思う。

　ノートパソコンで英語辞書「英辞郎」を使ってみようかな、と思っていたら、ちょうど「英辞郎 第四版」が発売されたのでCD-ROM版を買ってみた。ノートパソコンはLinuxだったのだけど、ダウンロード販売版⊂CD-ROM版だろうと思って。

　とりあえずEmacsのsdicから使おうと試す。

$ sudo apt-get install sdic sufary
$ sudo apt-get install sdic-eijiro

　…すみません、世の中を甘く見てました。CD-ROM版には、Linuxから見るかぎりでは、肝心のtext版辞書が入ってませんでした。

Building /usr/share/dict/eijiro.sdic ... /media/cdrom/eijiro/eijiro*.txt: No such file or directory

　いまさらダウンロード版を買い直すのも負担なので、「スコスコ blog: 英辞郎 第四版をEBViewで使うの巻」を参考に、いちどWindowsにインストールしたあとtext形式でぶっこ抜いて、nkf -W16 -sでShift_JISに変換。そのうえで、sdic-eijiroを-plowでインストールしなおす。

$ cd /var/cache/apt/archives
$ sudo dpkg-preconfigure -plow sdic-eijiro_2.1.3-15_all.deb
$ sudo dpkg -i sdic-eijiro_2.1.3-15_all.deb

　-plowの効果でtext版辞書のありかを聞いてくるので、ぶっこ抜いた辞書のディレクトリを手動で指定した。

　ノートパソコンのファンが騒がしく回るのを聴きながら待っていたら、うまくいったっぽい。