Emacs実践入門読んで設定見直した
Emacs実践入門 ～思考を直感的にコード化し、開発を加速する (WEB+DB PRESS plus)
posted with amazlet at 12.03.25
読んだ。いままではバッファロー本をすすめていたが、今後はこちらをすすめる。
経歴はvim -> emacs -> vim -> emacs という感じでvimでもemacsでもそれなりにコード書いている。
一点だけ、やってみてELPAはまだ使い物にならないなと感じた。Mac OS Xでhomebrewでいれたemacs 23.3.1で試したがpackage.elでpackageの削除ができない。それに扱えるpackageが少ないので結局auto-installや手動でのインストールをすることになる。Emacs24で標準になってpackageが充実したら使おう。
まあ、設定に関しては好みがあるので、使いそうなものだけ選んで設定するのがいいと思う。一例であり全てしたがう必要はない。
Kindleで英和辞書を使う
最近Kindleで英語の本を読んでいるが、内蔵の英英辞書だとすこしきついので英辞郎を加工してKindleで使えるようにした。
使わせてもらったのはこちら。
http://fallabs.com/enghelper/
英辞郎のデータが当然必要になるが、基本的に書いてある通りに実行していけば使えるようになる。環境は
- Mac OSX
- Ruby 1.9.3
やってみると、使ったマシンがMacBook Airだったためか、結構時間がかかった。Kindle用の辞書作成にだいたい1時間半くらいかかった。途中でメッセージが出るには出るがプログレス的なものではないので処理が進んでいるのかわからず、何度か途中で止めてしまったりもした。無事にデータが作成できたらWindows上でKindle用に変換して、Kindleのディレクトリに置いてKindleの辞書設定で選択するだけ。
使ってみた感想はやっぱり読む速度が向上した気がする。ただ、おれが無印Kindleを使っているからか、カーソルを移動させて選択する際に、目的の単語に到達する前の単語を検索してしまい、その後目的の単語を検索するので、単語の表示に少し時間がかかる。Kindle Touchを使えばこういうことはないんだろう。Kindle Touchが欲しくなるな。
JSON::RPCをPlack::Testでテストするの法
app.psgiの中でこんな感じにSYNOPSISみたいに書いて
use strict;
use warnings;
use JSON::RPC::Dispatch;
use Router::Simple::Declare;
my $router = router {
connect 'test' => {
handler => 'Test',
action => 'test'
};
};
my $dispatch = JSON::RPC::Dispatch->new(
prefix => "MyApp::RPC::Handler",
router => $router,
);
sub {
my $env = shift;
$dispatch->handle_psgi($env);
};
適当にhandler書いて
MyApp/RPC/Handler/Test.pm
package MyApp::RPC::Handler::Test;
use strict;
use warnings;
sub new {
my $class= shift;
my $self = bless {}, $class;
return $self;
}
sub test {
my $self = shift;
return "Test Test";
}
1;
99_rpc.tとかで
use strict;
use warnings;
use HTTP::Headers;
use HTTP::Request;
use JSON;
use Plack::Test;
use Plack::Util;
use Test::More;
use URI;
my $app = Plack::Util::load_psgi('app.psgi');
test_psgi $app, sub {
my $cb = shift;
my $coder = JSON->new;
my $headers = HTTP::Headers->new( Content_Type => 'application/json' );
my $uri = URI->new('http://localhost');
my $post_content = $coder->encode( {
jsonrpc => '2.0',
method => 'test',
params => { hoge => 'foo' },
user_id => 'bar',
id => 1,
} );
my $req = HTTP::Request->new(
POST => $uri, $headers, $post_content);
my $res = $cb->($req);
ok $res->status_line, 'test';
};
done_testing;
とかやると、以下のようにエラーになる。
Can't call method "request" on an undefined value at /path/to/perl5/perlbrew/perls/perl-5.14.2/lib/site_perl/5.14.2/Plack/Test/MockHTTP.pm line 29.
で、まあちょっと調べてみるとどうやらPlack::Test::MockHTTPの中では、PSGI response array refを要求してるけどhandle_psgiはPlack::Responseを返している様子。なのでapp.psgiの最後で
my $res = $dispatch->handle_psgi($env); $res->finalize;
してやると無事にテストが通った。
まあ、JSON-RPCの002_basic.t見ろって話ですか。あれもしかしてみなさん、周知の事実ですかそうですか。
shipit Amon2::Setup::Flavor::Teng-0.03
@tokuhiromさんから Improvements & Bugfixes いただいたのでリリースいたしました。
ありがとうございました。
スケジュールとタスクと見積もりと
あせって招待してもらったわりに、一度もPOSTしてなかった。
ずっと前から考えていて、最近また感じたのでここに記す。
開発を仕事としていると、必ず似たようなことがあると思いますが
「〇〇が欲しいんだけど、期間とタスクを出してくれ」
というようなことをよく聞かれます。
これが私には非常に難しい。
見積もりの話なんかは結構書籍があったりするので
Manage It! 現場開発者のための達人式プロジェクトマネジメント
アート・オブ・プロジェクトマネジメント ―マイクロソフトで培われた実践手法 (THEORY/IN/PRACTICE)
アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~
ソフトウェア見積り―人月の暗黙知を解き明かす
あたりを読んだんですが、私にはどれも「何々がほしい、いつまでにできる？」
という会社からの問に、すぐ答えられるような方法はないという風に感じました。
過去の開発から、定量的なデータをもちいて、次のプロジェクトの予測を
立てるということもある程度はできるとは思います。そういった点から修正などは、
まだ期間の予測が立ちやすく正確性があるものが出し易い(大幅な修正とかは別だが)
とは思います。ただ、程度の差こそあれ毎回違う物を作っていて、違う技術を
使っているような場合にはほとんど役に立たないと思うわけです。
なにかしら作るものがあり、仕様みたいなものがあったりなかったり
会社によって様々だと思いますが、最初の段階でわかっていることは実は
とても少なく、プロジェクトが進行するとともに、仕様にしろ、実装にしろ
理解が進んでいくのが普通だと思うわけです。
そういった点では、唯一プロトタイプは予測するのに有効に働く気がしています。
ただ、それはコードを書いて動かしてみないとわからないということで、できたときが
リリースするときだとほぼ同じなんではないかと。
他に問題として、会社や上司がこういった事に理解がない場合があり、なんで
スケジュール守れないのかとか、なんでこんな長い期間かかるんだとか
言われる場合があるわけです。そもそも正確性なんかほとんどないものを見て。
会社は売上や利益を上げるために、適切なタイミングで商品を出す必要がある
ということは重々わかっています。そんなもんなんとなくで、あとはがんばって
間に合わせろよこのヘタレという意見もあるかと思います。
ただ怖いのです。聞かれてなんの根拠もない数字をひねり出すことが。
最初はなにも決めずに作り始めて、進むたびにスケジュールが更新され
リリースできる日の確度が高くなっていくような形にはできないものだろうか。
Web+DB Press 総集編を読んだ
買ってあったんですが、読んでなかったので読みました。どのエッセイもすばらしかったんですが、特に森田創さんはブログのほうも読んでいて、なぜか洋書を翻訳したような雰囲気がただよう感じとか、内容の濃さとか読んでいておもしろいなと思いました。
そんななか、いろんなかたのエッセイが載っているんですが、増井俊之さんが書かれたスジの良い生活というエッセイで「以前はPerlを使う人がたくさんいたものですが、RubyやPythonが存在する現在、あえてPerlを使い続けるメリットはありません。」と書かれていました。確かに、RubyやPythonでもPerlと同じことはできるし、書きやすさとか可読性とかで優れているのかもしれませんが、本当にPerlを使い続けるメリットはないんでしょうか。
私はYAPCとかでJesseの話やRJBSの話を聞いていると、そんなことはないんではないかなと思っています。リリースサイクルが改善されて、後方互換を保ちつつも、新しい機能を追加していくことが可能になったPerlの開発は今も進んでいるし、CPANモジュールもまだまだ増え続けています。(5.8とかのころのままだったらやばかったのかもしれない)
Perlに限らずこういった言語の今の状態は、実はそれをメインに使っていて、さらにそういった情報を追っている人にしかわからないところがあるのかなと最近思っています。メインでない言語の情報も追っている人はたくさんいると思いますが、やはり追いきれない部分がどうしてもでてきてしまうと自分でも思っています。
なので少なくとも、まだ選択肢として残っててもいいんじゃないかなと思っています。
逆に言うと私が知らなくて、Perl以外の言語で実はPythonとかRubyとかPHPとかすごい進化してて、Perlはオワコンという事になっているのかもしれませんけどねｗ
YAPC::Asia 2011にスピーカーとして参加してきた
※画像は偽物だというウワサがありますがたぶんhidekさん
参加は4回目で、スピーカーとして参加したのは、2009のLTしたとき以来です。会場の東工大も工事が終わっていて、綺麗になっていました。前夜祭は仕事で参加できず。この時期にリリースをするのは今後避けたいですね！一日目はひたすらセッションを聞いて回ってました。どれを聞きに行くか毎年悩むんですが2日間合わせて特に印象に残ったのはこの辺でした。
Perl5.16 and beyond
Perl5.14 For Pragmatists
hakobeさんのLT
Hacking with metacpan
Managing A Band Of Hackers
聞けなかったのはあとで録画で見たいと思います。
懇親会でも、16歳の高専生、高校生とちょっとお話できて、なんでPerl使い始めたんですかとか聞けてよかったです。なんかしっかりしてておっさんやばいと思いました。今年は芝生コンにも参加できて(誘ってくれた@kyannyさんありがとうございます)楽しかったです。
2日目の２本目、ローヤルブルーホールの最初だったんですが、朝から雨風すごくて心配してたんですが、会場の移動時間ももらえて無事発表できました。なんか時間が結構余ってしまって、あとからあれ言うの忘れたなとか思ったんですが話したい内容は話せたのでとりあえずよかったかなと思います。
ちなみに発表資料はこちらから見れます。
http://dl.dropbox.com/u/5738997/YAPCASIA2011/index.html#intro
発表した直後になんか録画うまくいってないとスタッフ(同僚)から伝えられ、まあ残念だけど生で見てくれた人もいるし、まあいいかと思ってたんですがどうやら勘違いしていたようで、前半ほんのちょっとだけ録画できてないとのことでお騒がせしました。その直後にgihyoレポートの@ytnobodyさんにレポート書きます！って力強く言われたときにうれしくて泣きそうになったのは内緒なんだぜ。
あとは毎年のことですが、コードもっと書かないとなと思いました。一時的なものにしないで継続したいですね。
今年もスタッフとして手伝ってくれた@wittroありがとう。来年はスピーカー目指したらいいよ。会場提供の東工大、スタッフ、スピーカー、ゲスト、スポンサー、JPAの方達、941さん、lestrratさん今年も楽しかったです。ありがとうございました。
