マテ

さて秋だ。西語の勉強を再開だ。それではまず、マテ茶だな。っつう訳で買ってきた。
本当を言うと、いつもコーヒー豆を買う店で売っているのを見つけただけ。あの穴開きストローもあるとよかったのだが、なかった。とりあえずティーバッグに入れて水出し中。
ストロー(ボンビージャ)は別で探すか。どっか売ってない?この辺のご当地な店なんかにありそうだけど。ねえか。

太陽の男

もっかい貼る。

太陽の男たち・ハイファに戻って (現代アラブ小説全集)

なんたる筆致。「太陽の男」は粗筋を知っていてもビリッビリ来る。「彼岸へ」「ハイファに戻って」に出てくる祖国や人間の像は、一日で過去と未来の全てを失ったり、敵の子を拾い育てたり、育った子と相対しても、決して卑屈にならず、過去も許しも釈明もなしに、自分を説明しようとする人間やその居た/居る国の事だ。お涙ちょうだいも死んでもらいますも、この紋所もナシだ。...いや止めた。ものすごく色々書きたいがすごく我慢(笑)している。とにかく素晴らしいな、これ。
もう少し軽い(笑)見方。今から30年前にこんだけの困窮も交流も交渉も戦争も、政治も考察も攻撃も議論も既にあって、それを冷静に咀嚼して、こんな完成度の小説にもできているのだよ。パレスチナ問題がこれで全部わかる訳ではもちろんない。なにしろ作り話だ。でも、まずこれは是非。


やっと週末。横浜駅の喫茶店に入り、予定の一週間遅れで本を開き読み出した。「太陽の男」を読み終わって体が固まって居るところに、ちょっと趣味の良い、典型的な都会の女子高生が、たぶん買ったばかりの秋冬向けジャケットを着込んで「アルバイトの面接を受けさせていただきませんか」と入ってきた。声は出ているが、緊張で言えてないのがご愛嬌。
続く「悲しいオレンジの実る土地」からの短篇に翻弄されまくりながら顔を挙げると、面接待ちで一応行儀よくしつつ、携帯でメールを打ったり道往く人を眺めたりしている。普段なら「めんこいもんですね」と気楽に眺めるものであるが、今おじさんはハミードはどうして先生に嘘をつくのか気がかりなもんで、また本へダイブ。
そのままがんがんと「彼岸へ」まで読んでリュックへしまい、レジへ向かった時も、その子はまだ真面目に待っていた。年末に遊べるくらい稼げるといいね、とは思ったが、オイラは感動の洟を我慢するのに大変でそれどころじゃなかったよ。たはは。
これアラブ現代小説全集の一巻なんですね。他も読んでみようかな。

ごあいきょう

の変換一発目が「ゴア異境」であるUbuntu Edgyのanthyについて。

構成管理

拝見しているかくたにさんのところで、やっと邦訳が出たのを知った。ありがとうございます。

パターンによるソフトウェア構成管理 (IT Architects’ Archive―ソフトウェア開発の課題)

以前偉そうに書いたが、うちは結構製品や改変リリースの回数が多いうえ、開発サイトが離れがちなので、これを一人で勉強してポリシーや用語をもらった運用を作ってやっている。でも、英語だとほかの誰も読んでくれないんだよね(苦笑)。ほんと助かるわー。これ。意外にね、会社だと、最後の各ツールの対応表が役に立つよ。SCM関係ないオヤジが「くりあけーす」とか言ってくるでしょう、金ないのに。そういうときとか、あとはアレ、会社や国によって「やっぱすたーちーむ」「しなじーっしょ」なんて言われた時。ツールにだけはやたらクチ挟むやつに有効。svnユーザはCVSんとこ見せれば、ツールはどっちでもまず文句を言いません(笑)から大丈夫。
ツール話だけじゃあれだから、職場ローカルなパターン実装の実例を挙げておきます。完全オヤジなネタ。

• Codeline Policy(12)は計画書として書く。せめてチームのWikiには明記。絶対いつでも見える所に置き厳守する。
• Mainline(4)、ADL(5)は従来の案件から見て、同じもの(trunk)に統合する。
• 同様に製品リリースの作業を見て、Release-Prep Code Line(18)だけ使い、Release Line(17)は紹介せず、RPCL(18)を代わりに「リリースライン」と言う。
• Private Workspace(6)は「ワークスペース(svn coしたもの)」、Repository(7)は「リポジトリ」、Third Party Codeline(10)は「ベンダーブランチ」と言う。
• Private System Build(8)、Integration Build(9)は「ビルド」で統一し、ビルド時間がかかるなら分ける。分けたことないけどね。デベロッパが分けるのを嫌がる事もある。
• Somke Test(13)、Unit Test(14)、Regression Test(15)は、うちは組み込みなのもあって、全部まとめて「実機(基板)テスト/それ以外」の2つだけに分割。みんな自動テストにすれば書くし、実機じゃ本気のCPU例外投げることもあって'F'すら表示できないからな。
• Private Versions(16)、Task Branch(19)は原則禁止。あまり支障が無いのもあるが、ブランチ避け(ローカルルール)もある
• Task Level Commit(11)は「コミッタ(デベロッパ)が守るべきこと」と、コツとして説明。大体、あとで泣くのはコミットした本人だから。「なんでA直すとBつぶれんだよこのカス」と俺に責められるし。

あとはローカルルール。

• バージョン番号ルールも(以前書いたように)計画書なりに明記。厳守。じゃないとスクリプトが書けない。
• ブランチを切っていいのは、そのブランチが本線から切ってあり、以下のいずれかを満たした時だけ。
  • そのブランチはある具体条件を満たしたら捨てられる
  • そのブランチはある具体条件を満たしたらtrunkにマージされる
  • そのブランチはある具体条件を満たしたらtrunkになる

最後のルールは今、あらゆるブランチに適用している。あんまりまずい事もないんだけど、パターンには無い。もちろん、うちだけだとは思ってるんだけど、なんかまずい事例ってあるのかな。Release(-Prep) Codelineもこれに含まれると思うんだけどな。根拠は、経験です。「おれブランチ」や「階段ブランチ(よくあるブランチの悪い例)」排除。
あとはまあ、もちろん、裏ルールに

• Codeline Policy(12)に沿わないものはいくら動くと言われても、営業がどうほざこうが拒否し、チーム外にはNamed Stable Buildsしか見せない
• Private System Build(8)、Integration Build(9)の結果とバイナリは、決してチーム外に見せない

あたりもあるがね(笑)。
まあそういう背景で開発ルールを書いていて、これだとCodeline Policy(12)にバージョン番号も入れておかねえと結構面倒臭いだろうな、と思って書いたのがその以前書いたエントリなんだが、意外に参照してくださる方が多かった。こういう所に日記を書いている本人にとって、見られるのはとてもうれしかったのだが、今回の邦訳で背景にある事が見えてもっと役に立つなら、本当にうれしいですわ。まだここ読んでる人が居るかという話もあるがな(笑)。本と酒とライブの話ばっかりだから。