Text::MicroTemplate を拡張してみた
最近は Text::MicroTemplate (TMT) をよく利用するようになったのですが、使用するにつれ不満なところが出てきたのでそれを解決するために少し拡張してみました。
実際には拡張したのは Text::MicroTemplate ではなく、Text::MicroTemplate::File です。
http://github.com/typester/text-microtemplate-extended-perl/tree/master
現在二つの機能を追加してあるのでそれを以下にまとめておきます。
テンプレートの継承機能を追加
テンプレートを分割するような規模になってくると現状の TMT では
<?=r $self->render_file('header.mt') ?>
ここにコンテンツ
<?=r $self->render_file('footer.mt') ?>
などのように書くことになりますが、これは TT の wrapper 機能などに慣れていると少しめんどくさい。
追記: TMTでもwrapperはつかえるみたいです。> $mtf->wrapper_fileそこで、TMT でも wrapper 機能をつかえるように!! ・・・しようかと思ったのですがやめて、代わりに Django のテンプレートなどで採用されている継承という仕組みを実装してみました。
詳しい説明は Django のテンプレートのドキュメントがとても詳しいのでそちらを参照するといいと思います。
で、上記の Django ドキュメントにあるテンプレート継承の例をこの拡張版 TMT で書くとどうなるかというと、base.html (base.mt) が
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<link rel="stylesheet" href="style.css" />
<title><? block title => sub { ?>My amazing site<? } ?></title>
</head>
<body>
<div id="sidebar">
<? block sidebar => sub { ?>
<ul>
<li><a href="/">Home</a></li>
<li><a href="/blog/">Blog</a></li>
</ul>
<? } ?>
</div>
<div id="content">
<? block content => sub {} ?>
</div>
</body>
</html>
child.html (child.mt) は:
text
のようになります。
TT のような wrapper という方式と、このような継承という仕組みはどちらも一長一短ありますが、柔軟にテンプレートを定義できるのは継承の方かなぁと感じてます。
ちなみに Django テンプレートに実装されている block.super
相当の機能はまだ実装できていません。
テンプレートに名前付き引数を渡せる機能を追加
もう一つ、テンプレートに名前付きで値を渡せる機能も追加しました。オブジェクトを作成するときに
Text::MicroTemplate::Extended->new( include_path => ['.'], template_args => { foo => 'bar' } );
などのように template_args パラメータにハッシュリファレンスを渡しておくと、テンプレート中でこのハッシュのキーを
<?= $foo ?> # => bar
と参照することができるようになるという機能です。
SBankNotify for android
android アプリケーションの習作に、iPhone脱獄アプリSBankNotifyを android に移植してみました。
インストールするだけで自動的に機能が有効になります。必要がなくなったらアンインストールしてください。 機能の詳細などは上記の本家SBankNotifyのページを参照ください。
アプリは android マーケットにアップしてあるのでマーケットアプリで「SBankNotify」と検索するとこのアプリが見つかると思いますが、正直めんどくさいのでこのサイトのQRコードを「BarcodeScanner」で読み取ってマーケットのアプリページに飛ぶのが簡単です。
将来気が向いたら設定ダイアログも作ろうと思っています。通知のON/OFFとかその方法の選択とかですね。
というわけで僕的 Hello Android World! でしたが、目的が不明なものを作ってしまった。。。今度はもう少しまともなアプリに挑戦します。
ソースコードは github に置いています。
lighttpd だけで多言語サイトを作る方法
lighttpd 1.4.21 以上では $HTTP["language"]
という新しい変数(?)が設定の中で使えるようになり、これを使用するとクライアントの Accept-Language
に応じて lighttpd の設定を変えることが可能になります。
これを利用して多言語化しているサイトとしては opensource.kayac.com が有名です。
このサイトは以下のような設定で動作しております。
$HTTP["url"] !~ "^/(?:(?:css|js|img|images?|static|tmp)/|[^/]+\.[^/]+$)" {
$HTTP["url"] !~ "^/(en|ja)(?:$|/)" {
$HTTP["language"] =~ "(en|ja)" {
url.redirect = ( "^/(.*)" => "/%1/$1" )
}
$HTTP["language"] !~ "(en|ja)" {
url.redirect = ( "^/(.*)" => "/en/$1" )
}
}
}
ちょっとややこしいですが、
$HTTP["url"] !~ "^/(?:(?:css|js|img|images?|static|tmp)/|[^/]+\.[^/]+$)" {
で、cssやjsディレクトリ、もしくはルート直下のファイルへのアクセスはそのまま。
$HTTP["url"] !~ "^/(en|ja)(?:$|/)" {
で、すでに /ja/
や /en/
へのリクエストであればそのまま。
上記に該当しなかった場合、
$HTTP["language"] =~ "(en|ja)" {
url.redirect = ( "^/(.*)" => "/%1/$1" )
}
で、Accept-Context
が en か ja の場合はそれに応じてリダイレクト先を振り分ける。それ以外の時(対応していない言語の場合)は
$HTTP["language"] !~ "(en|ja)" {
url.redirect = ( "^/(.*)" => "/en/$1" )
}
で、デフォルトの言語(ここではen)にリダイレクトする。
というような感じで動作しております。
このような使い方以外にもさまざまな使い方ができそうですね。覚えておくともしかしたら使えるかもしれません。
.ppkファイルとか渡されて困ったとき
PuTTY 独自の形式の .ppk ファイルで鍵ペアを渡されて困ったときのためにメモ。
PuTTY に付属している puttygen コマンドで普通の公開鍵・秘密鍵に分離できる。
Debian 系なら putty-tools
パッケージをインストールするだけでいいらしい(未確認)
OSX だと ports 使うか自分でビルドする。
ぼくは自分でビルドした。
wget http://the.earth.li/~sgtatham/putty/latest/putty-0.60.tar.gz
tar zxvf putty-0.60.tar.gz
cd putty-0.60/macosx
make puttygen
で puttygen だけビルドできる。っていうか全体 make はぼくの環境では失敗した。まぁこれさえビルドできればOK。
秘密鍵を取り出す。
./puttygen unko.ppk -O private-openssh -o private_key
公開鍵
./puttygen unko.ppk -O public-openssh -o public_key
ひさびさ
やっと引っ越し先のネット環境が整ったのでまたここを更新できるようになった。
ネットがない間は自分のメモを Google Cache 経由で読むという謎の状況になっていた。つらい。
カヤックxクックパッド主催 技術者交流会で発表してきた
これ
オーディエンス的にperlの話よりいいと思ったので、もっと概念的な、もっといろいろオープンにしてこうぜ!っていう話をしました。
スライドはこちら
以下感想
ElectricCafe.js 村式 中川さん
js でポリゴン。写真を元にポリゴン化。すごい!
村式と言えば鎌倉小町通り沿いにオフィスを構えたご近所さん。こんなところにこんな変態がいたとは!!(褒め言葉)
また遊びに行かせてください!
イケメンCTOの画像検索、全然出ないし!!! だまされた!
誰かが質問してたけど、特徴点をjsだけで自動で出せたら面白いなー。
プログラミングの【さしすせそ】 kwappa.net 塩谷さん
- 料理
- つくる -> たべる -> おいしい!
- プログラミング
- つくる -> うごかす -> たのしい!
どっちも楽しい。幸せを作る作業 だといっていた。いい言葉ダナー;;
さて、どちらもやはり基礎が大事だよね!
- 料理
- さしすせそ
- プログラミング
- コンピューターサイエンス
というわけで、基礎を勉強するコミュニティをつくったらしい。おわり。えー!
詳細はこちら
Railsメールウェア Cookpad インターン中村さん
Cookpadに「つくれぽ」という機能がある。
レシピを公開してる人に対し、つくってみたよー、とかおいしかったよー、とかいうのを送れる機能らしい(たぶん)。ネーミングセンスいいなー。
で、それを携帯で送れたらいいよね!っていうことになり、インターンの中村さんががんばったよっというお話。
Javaの James を参考に Ruby で同じような物を実装したとのこと。すごいなー。
perl だと qpsmtpd とかみたいなイメージかな。個人的には最近は qpsmtpd で受信してジョブキューにつっこんであとはゆっくりそっちで処理。というパターンをよく使うな。
皮肉なことに James をホストしてる apache.org のメールサーバーは qpsmtpd だったりするのよねー。
というわけで歓談タイムにqpsmtpdをプッシュしまくっておいた。
あと作ったものを公開はしないんですか? と聞いたところ stable になったら公開したい! とのことなので期待。
カヤックxクックパッド イケメンCTO二人 + 技評 馮さんのトークセッション
クックパッド、何をするかを決めるときに何がベストかをすごい慎重に決める。何かをやるための時間を決めたらその 1/3 は計画に使う。
そして驚いたのは、その計画は全員が納得するまでやるといっていたところ。気持ち悪くなると言っていた。
そして計画で決めるのは仕様ではなく指標。ロジックとなる部分。
完璧なロジックには反対できない。
しかしそれでも会議の結論に対して全員が納得できるというのは相当なことだなーと思って、そのためにどういう手法をとっているのか質問した。
3つあるという答え
- 会議の前に共有された3つの前提条件がある
- この3つがそろったものしかやらない
- EOGS (Emotion Oriented Goal Setting)
- ユーザーの欲求をもとにしてゴールを設定するための指標シート
- ロジックツリー (マインドマップ)
- 前述の通り決めるのはロジック
質問したくせに、3つの前提条件の内容を失念してしまったのでググったところ、 ryo_katsuma さんのナイスな記事がひっかかった。
Ruby on Rails セミナーに参加してきました - blog.katsuma.tv
- Bestなことを見つけるまでのの3つの輪
- やりたい(情熱を持ってとりくめること)
- できる(世界で1番になれること)
- やるべきこと(儲かること)
ってことかな?
やっぱり会議前から前提条件をしっかりそろえて会議のコンテキストをそろえること、会議中も正しくゴールに近づけるようなシステムがある。
広げるだけ広げて、収束しない会議ってよくあると思うんだけど、そういう人たちは参考にするといいと思った。僕もここはもう少し掘り下げてみたい。
あと、イベント終了後にすこしお話しさせてもらったときに、「数値化して比較する」っていうことも最近はやってるとおっしゃっていた。どっちの方法が良いのか迷ったときに、効果や費用などすべてを数値化することで客観的に判断できる。なるほど。
まとめ
料理とプログラミングは似ている。
cookpad 面白い会社。
グラハム・エーカー氏が実在した件
今日はあるエントリに心を奪われた。
新人プログラマーがプロのプログラマーとして独り立ちするための7つの条件 - ハックルベリーに会いに行く
「無理を通して道理を引っ込ませてこそプロのプログラマー」ということだった。
カッコイイ!
しかし、ん?どっかで聞いたことある台詞だなと思ったら
同じこと言ってる!
Tさんは現代のグラハム・エーカーと言えよう。会ってみたいなー。
Mouse なクラスと subtype
今日 Mouse を最新版にしたら書いていたコードが動かなくなった。
subtype していたところで、
The type constraint 'Ark::Request' has already been created in Mouse::Util::TypeConstraints and cannot be created again in Ark::Context
というエラーになってしまう。これは Mouse の subtype のところのコードを読めばすぐわかるが、違う場所で重複定義しようとしたときに出るエラーだ。
subtype 一回しか書いてないのに重複定義とは何事か、と思ったが、今の Mouse では Mouse でクラスを作るとそのクラスに class_type
が設定されるようになってるみたい。
つまりこの場合は Ark::Request
は Mouse なクラスなのですでに class_type
されているのだが、それをさらに subtype で定義しようとしてエラーになってたというわけ。
こちらの挙動が Moose と同じで、いままでの Mouse のほうがちょっと互換性がなかったということみたい。
というようなことを Mouse メンテナーであるところの tokuhirom 氏や、MouseX ファウンダーであるところの ikasam_a 氏に教えてもらった。ありがとうございます!
あわせて読みたい:
Yokohama.pm Tech Talk #4 行ってきた
もう4回目か。。
qudo x skinny (id:nekokak)
qudo
はクドーと読む。キュードーだと思ってた!(& キュードーのが良いなぁ)
Skinny は前回(?)も発表したORM。SQL::Parser
がしょぼい&遅いので捨て、ルールベースにしたとのこと。
それはいいんだけど、DSL まくっててちょっと個人的にはやだなぁ。DSL は覚えるのが大変。DSLは ::Declare
とかで別途やって欲しい感じ。どちらでも使えるのがいいと思います!
現状は一部足りないところもあるけど、だいたいのところ(id:nekokakさんが普段使う領域)はうごくレベルらしい。
Qudo は TheSchwartz みたいなジョブキュー。TheSchwartz の不満なところを直して、欲しかった物をつけた感じの物。
- ORM に依存しない
- DB 以外にも memcached とかキャッシュサーバーをバックエンドにも使える(予定)
- 適度なHookポイントをつけてプラッガブル!
- エラー処理管理しやすく (イイネ)
- 管理系コマンドも充実 (イイネ)
- テストモジュールも用意 (イイネ)
というかなり良い感じの物になってるので、TheSchwartz つかってる僕としては触ってみたいなと思った。ORM 対応とかは正直 DBI にさえ対応してくれればいいんだけど。。
ZIGOROu さんがMacBookになってる!!
DI x Perl! (id:lestrrat)
DIよくわかってない。
オブジェクトの自動組み立てのことをいうらしい = 依存関係を満たしつつ初期化。
。。。というと?
自分で依存関係を考慮してコーディングしなくていい。なるほど。
どうやるか? 普段どおりのクラス定義 + 依存性定義ファイル + アセンブラ(なんだろこれ、前二つを結びつけて組み立てる物)
Bread::Board の実際のコード例。見てもよくわからん。
lestrrat化後はどうなるか (今後取り込まれる予定のもの)
クラス構造使いやすく。(こっちの例はいい感じ)
- Bread::Board (coreモジュール、いままでのようにDSLではない)
- Bread::Board::Declare (いままでのようなDSLインタフェース)
- MooseX::Bread::Board もつくったよ
lestrrat化したあとのものは僕にとってもわかりやすく、一度試してみたい。依存性を全く考慮することなくコーディングできるなら確かに楽なのかもしれないなぁ。
やってみないとわからないので、これは取り込まれたら使ってみる。
WAF のつくりかた (id:dann)
おなかすいた。
いろんな言語のWAFの特徴。最近Djangoってる僕としてはPythonのWAFについてまったく調べてないんじゃないの!! と思ってしまったw Django 面白い機能いっぱいありますよ。
で、それらをいいとこ取りしたのが Angelos!
フックポイントは大文字! きもい!
デフォルトセットの概念は良い。 Module::Setup のフレーバーで定義。いいね。
amazon の MapReduce エラスティックなんちゃら (id:lopnor)
mapper or reducer スクリプトから CPAN モジュールを使用するための方法。
local::lib して jar でかためて云々すれば普通に使えるらしい。
Simo (id:perlcodesample)
Moose とかみたいなやつ。Mouse が存在しなかったら触ってみたかも。
Moose/Mouse との比較があるとよかったかもなぁ。機能比較はもちろんだけど、速度比較とかも。
機能としては MOP 的なものが全くなさそう(?) なので、Moose/Mouse からの移行はなかなか難しそう。
CAPとBASEとEventually Consistent (id:yohei)
職業にふいたw
赤ラクダ本とかしらない>< MogileFS とか Perlbal とかの brad プロダクトを使ってるらしい。 MogileFS の運用話は聞いてみたかったけど懇親会で話す機会なかったなぁ。
CAP定理! どれもとりたいジレンマ。どれかを妥協せざるを得ない。
Webアプリだとたいていの場合 C (Consistency) を妥協。
その C の中の Eventually Consistent というのについての話。これについては「結果整合性」でググれば一番良いページがいちばんうえにくる! ここ?
BASE とか CAP とか全く知らなかったけど、Eventually Consistent 的な手法というのは Web 開発においてはよくつかわれていて、全然わかる話ではあった。
自分の身近では実際の方法論などばかり話されるばかりで、あういう概念的な話は全く出ないので面白かった。もう少し知りたい。
あわせて読みたい:
LT
MacBookのバッテリー切れてメモがない。
id:IMAKADO の perl-completion.el の説明。早口で perl-completion ユーザーの僕としても難しかった。非ユーザーは理解できなかったかも。
ジョブキューは Qudo で良いよって言う結論。(うろ覚え)
AAFind おもろいw やる男がやるプレゼンは新しい。
まとめ
Django本にサインもらった。うれしい
my clmemo設定
このメモは clmemo.el で書いてるわけだけど、もっと個人的なメモとるように、MacBookにもインストールしてみた。
で、僕のつかってる clmemo のフォーマットは、タイトル行に書いた時間をいれる、本文は Markdown というような物になっていて、この時間を入れるためにこんなパッチを当てていた。
けど今見てみたらそんなパッチ当てる必要もないことがわかった。
こんな感じ、
(require 'clmemo)
(setq clmemo-file-name "~/clmemo.txt")
(setq clmemo-time-string-with-weekday t)
(setq clmemo-subtitle-char "[")
(setq clmemo-subtitle-punctuation-char '(" [" . "]"))
(defadvice clmemo-get-title (after clmemo-get-title-with-time () activate)
(setq ad-return-value (concat (format-time-string "%H:%M ") ad-return-value)))
でやればこのメモのフォーマットになる。いいね!
clmemo.el のソースも昔は意味不明だったけど今はだいたいわかるし。やっぱり emacs つかうなら elisp 理解できないと損というか、もったいないなぁ。ということがわかった。