« 2012年8月 | メイン | 2012年10月 »

2012年9月30日

YAPC::Asia Tokyo 2012とスピーカーデビューと

今年もYAPC::Asia Tokyo 2012終わりましたね。毎年のことながら、素晴らしい場を提供してくださっているスタッフの皆様には本当に感謝申し上げます。

前夜祭からひたすら飲み食いして、夜もさくら水産で大ジョッキ連発。初日は懇親会の後まで呑んだくれ。最終日も呑んだくれた挙句終電を逃しタクシーで帰宅するという非常に過酷な3日間でした。

今年の個人的なビッグニュースは間違いなくスピーカーデビューです。スライドは以下。

http://songmu.github.com/slides/yapcasia2012/start.html

しかしかなり緊張してしまってひどいもんでした。最初は足がガクガクしていて、かなり早口になってしまい、途中で持ち直したものの、25分程度で終わってしまいました。

結構話慣れていたつもりなんですがYAPCともなりますと全然違いますね。まあ、時間帯の関係もありたくさんの人に聞いていただけて非常に嬉しかったです。

事前に練習した感じだと

  • 40分を少しオーバーしていた。
  • 最後の方のスピリチュアルトークの途中で終わるのは嫌だった。

というのがあって最初は早めに話すつもりではあったのですが、あまりにも飛ばしすぎました。トーク後@fujiwaraに「緊張すると早口になるからそれを考えたほうが良いよ」とか言われてなるほどなーと。知らず知らずのうちに早口になってるのに、更に早く話そうとするとしどろもどろになるのは当たり前ですね…。

前半は初・中級者向けに、現状PerlでWeb開発する上での僕の思う「一般的な構成」のオーバービューを丁寧に話したかったのですが飛ばしたせいでちゃんと伝わってないかもしれないなーと残念な思いもあります。

色々反省点があるので来年頑張りたい。

あと、なんか「カジュアルにdisってる」とか何人かに言われましたが、disは多くの場合愛です。

今年は例年に比べると割とスピーカーの入れ替わりがあった印象で、多くの人の身の丈にあったトークの割合も取れていてバランスが良かったですね。

何よりLTThonは素晴らしかった。あそこまでみんながカジュアルに発表したいと思える雰囲気作りをしたのは本当に奇跡的ですね。多くの人がやろうとして挫折してきた雰囲気作りを完璧に実現していたと思います。

今年はスピーカーになった関係でチケットが余り、嫁に「来る？」と聞いたら「行く行く」と二つ返事。僕のトークも聞きに来てくれましたが、なにより、普段僕が話しているスーパースター達の話を直接聞けたのがかなり面白かったようです。

Perl今昔物語をメモを取りながら聞く真面目ぶりで、その後も「じゃ、次はdankogai見に行くから！」とかノリノリで僕を残して移動してました。

今も「来年も行くからスピーカーやってチケット余らせてね」とか言っております。

ということでYAPCは非エンジニアも楽しめる素晴らしいお祭りだということを身を持って実感いたしました。

23:37

2012年9月23日

Jenkinsをカジュアルに5分で立てる

プロジェクトの共同開発サーバー兼CIサーバーみたいなところにJenkinsを立てることが多い。その場合、Jenkinsを立てるのはwarを起動するコマンドをdaemontoolsなりで管理するのがベタープラクティスかなーと思っている。

事前にやることはjavaを入れるのと、jenkins.warをwgetしておくだけ。

runスクリプトはこんな感じ。

#!/bin/sh
JENKINS_USER=app
JENKINS_HOME=/home/$JENKINS_USER/jenkins

exec 2>&1
exec setuidgid $JENKINS_USER \
    env JENKINS_USER=$JENKINS_USER
    env JENKINS_HOME=$JENKINS_HOME \
    java -jar $JENKINS_HOME/jenkins.war 
         --httpPort=3002 \
         --httpListenAddress=127.0.0.1

あとはNginxでプロキシさせたりする。

リポジトリ追加すればyum等のパッケージ管理システムでjenkinsを入れられるようになるけど、

  • /etc/init.d に入るのはなんか大げさ
  • 実行ユーザーもjenkinsユーザー固定になってしまう
  • WebUIの「自動アップグレード」が動かない(動くかも) (動いた。気のせいだった)

という感じなので個人的にはあまりおすすめしない。

war起動にすれば、

  • 一般ユーザー権限でカジュアルに実行可能
  • 「自動アップグレード」がカジュアルに利用可能
  • $HOME/jenkins で完結しているので可搬性があり、バックアップもしやすい

というメリットがある。

Jenkinsはごてごてしていて複雑でわかりにくそうで敬遠してしまう部分があるかもしれないけど、とりあえずこんな感じでカジュアルに立ててみて色々いじってみるのをおすすめします。

慣れてきたらjenkins-cliとか使って構成テンプレートとか作ってセットアップ自動化とかしてみれば良いんじゃないですかね。僕はまだやってないけど。

話は変わるけどhomebrewでさくっとdaemontoolsが入るのが便利。LaunchDaemonsとかよくわからないし、xmlとか書きたくない。

00:59

2012年9月 7日

たとえばgetを避ける

プログラムでは複数の意味を持ちうる単語は避けるというのがある。noとかrightとかが良い例だ。個人的に最近はgetも気をつけたほうが良いと思っていて、メソッド名にgetを使いたくなったときは大体間違えている。

Javaなんかのgetter/setter的なやつは、オブジェクト指向以前のパラダイムの名残でしかないと思ってる。手続きの内容をメソッド名にしているという、手続き型のパラダイムを引きずっている感。

例えば、

user.get_money

みたいなコードがあった場合に、ユーザーがお金を獲得するのか、ユーザーの所持金額を取り出したいのかが分からない。オブジェクト指向的には前者が正しいのだけど、歴史的経緯から後者の意味合いで使わえる事が多い。プロパティの値を取り出すことが期待されてしまう。それが気持ち悪いので、getは極力使わないようにしている。

オブジェクト志向では、メソッド名はオブジェクトのやりたいことに即した命名にするべきで、プログラマーのやりたいことに即するわけではない。スピリチュアル的に言うと「オブジェクトの気持ちになる」ことが大事ですね！？

Javaとかだとプロパティとメソッドがはっきり分かれていて、プロパティは名詞、メソッドは動詞、みたいな感覚もあるんだと思う。だからproduct.priceに金額を代入しておくけどそれは直接使わずに、product.getPrice()で税込金額を返すみたいな処理が書かれてしまう。

プロパティをそのまま外部から使うようにしておくと、後で内部処理に変更があった場合に困るからメソッドでラップしておきべきだけど、メソッドは動詞にしておくべきとか、思考停止でgetXXXとかつけてしまうとかそんな理由だと思われる。

その点、Perlだとプロパティもメソッドも全部関数だから、シンプルな分柔軟なのかな、とか思う。

ちなみに、どうしてもgetを使いたくて代替案も思いつかない場合はretrieveを使うようにしている。あとはcurrentとかも便利な単語ですね。

てことで、とにかくgetをプログラム内で使うのは避けましょう。

01:20

grepのかわりにperlを使おう

ackを使うと良いと思います。perlで書かれていてperlの正規表現を使えるから最高ですね(これしか言ってない)。.ackrcとか作れば自分好みの設定もできます。

実際のところ、.svnとか.gitとかバイナリファイルをスルーしてくれるから高速に動作しますが、大きなログファイルを絞り込むとかそういう場合は、grepの方が多分高速なんで使い分け重要。

00:27

sedのかわりにperlを使おう

あのmoriyoshiさんもこんなこと言ってます。

https://twitter.com/moriyoshit/status/184241026028941314

sed -i より perl -i -pe を覚えた方がきっと有益でしょう。

% perl -i -pe 's/hoge/fuga/g' **/*.mt

とかやれば一括置換ができます。perlの正規表現が使えるから最高です。

大体これをやってgit diffで差分を確認して、まずったらgit reset —hardという運用になっております。

00:24

2012年9月 4日

エディタ編集したファイルを整形してPocketIOでリアルタイムプレビュー

すぎゃーんが以前書いてるやつを参考にさせてもらってとりあえず適当に書いてみた。

% perl md_preview.pl markdown.md

とかやってhttp://localhost:5000/にアクセスするとリアルタイムプレビューできるはず。

Text::Markup::Anyを使っていて、

% perl md_preview.pl xatena.txt --markup=Xatena

とかやればText::Xatenaでも試せます。

Text::Markup::Anyの使いドコロみたいなのをなんとなく示したかった。

02:15

軽量マークアップ記法を使い分けたいあなたのためにText::Markup::AnyをCPANに上げた

Markdownはシンプルな分、拡張実装が乱立している。他にも軽量マークアップ言語(とか言うらしい)は数多くある。

人によって好みもあるので差し替えたりとかできると嬉しいんじゃないかと思ってText::Markup::Anyというものを書いた。

使い方は簡単。以下SYNOPSISまんま。

use Text::Markup::Any;

# OO Interface
my $md = Text::Markup::Any->new('Text::Markdown');
my $html = $md->markup('# hoge'); # <h1>hoge</h1>

# Functional Interface
my $tx = markupper 'Textile'; # snip 'Text::' in functional inteface.
my $html = $tx->markup('h1. hoge'); # <h1>hoge</h1>

Functional Interfaceと言うよりかはSyntax sugarの提供ですね。以下2行は同じ意味になります。

my $md = Text::Markup::Any->new('Text::Xatena');
my $md = markupper 'Xatena';

現状対応してるモジュールは以下のとおり。

  • Text::Markdown
  • Text::MultiMarkdown
  • Text::Markdown::Discount
  • Text::Markdown::GitHubAPI
  • Text::Xatena
  • Text::Textile

02:10

2012年9月 3日

Text:Markdown::GitHubAPI書いてみた

githubのmarkdown rendering APIの話をちょくちょく聞くのでPerlから使うやつを書いた。

https://github.com/Songmu/p5-Text-Markdown-GitHubAPI

使い方は、Text::Markdownとかとほとんど同じです。これでgithubのmarkdownがお手元でも！

微妙にCache::LRUとか使って頑張っちゃってる。なんで最近こんなMarkdown期なのか自分でもわからない。

そういや、Plack::App::Directory::MarkdownはyusukebeがYomicoっていう同じようなのをだいぶ前に書いてた。

15:46