はてなに入って2年くらい経ちました。CTOとかMackerelとか | おそらくはそれさえも平凡な日々
この度はてなのCTOが id:stanaka から id:motemen に交代しました。僕はチーフエンジニアとして引き続き頑張っていく所存です。 stanakaとMackerel stanaka にはチーフエンジニアやMackerelチームのディレクターを務める中で様々な指導をいただきました。 そのエンジニアリング能力、ビジネスも含めた視野の広さ、Mackerelに立ち上げたことに代表されるようなビジョンにはただただ圧倒される日々でした。 思い起こせば2年前、stanakaにMackerel事業の魅力やはてな東京オフィスでのエンジニアリングチームの立ち上げについて話をしていただきました。僕はそれらに魅力を感じはてなに入社しました。その後は、チーフエンジニア、Mackerelのディレクターなどの立場も与えてもらい、引き上げてもらったと感じています。 Mackerel事業にディレクターとして
Perlベストプラクティスのベストプラクティスじゃないやつをまとめてみた | おそらくはそれさえも平凡な日々
Perlベストプラクティス Perlベストプラクティス(略してPBP)という良い本があります。僕自身もPerlを学ぶ過程で非常にお世話になった本なのですが、以下の様なことが度々指摘されています。 bestって書いてあるけど「著者の」bestプラクティスなので偏りがあることも 「決して」とか「必ず」とかが多いけどあんま真に受けてはいけない この本を書くために書かれたであろうCPANモジュールとかがあって、しかも公開されてないものまである 致し方ないけど現在の状況にマッチしない古い情報もある なので、PBPの何がベストじゃないのかについてまとめてみることにした。前からやりたかったんだけど、思い立ってやった。 まとめてみたら、思っていたほどには項目が上がってこなかったので、やっぱPBPは良い本だなと改めて思いました。なので、このエントリーがこれからPBPを読む人の助けになれば良いなと思います。
おそらくはそれさえも平凡な日々: PerlのIdiomをCPANモジュールを使って可読性を高くしてみる
今年からKayac技術部では以前以上にPerlを推進する方向で進めています。そんな中でこれまでPerlを書いたことのないエンジニアにもPerlを書いてもらうことも多くなってきたのですが、PerlのIdiomがやはりわかりづらいんだなぁということを感じています。 割りとサクッとやっつけでコードを書くことが出来るのもPerlの良い点ですが、まあ分かりづらいよね...、と言うことで最近はPerlに慣れない人に対しても可読性が高くなるように多少心がけています。 てことで、PerlのIdiomとそれを読みやすくしたものを幾つか。 ファイル一気読み こんな感じで書いてしまうことが多いと思います。 use autodie; も併用することが多いので、or dieとかも書かない感じ。 my $content = do {local $/; open my $fh,'<:utf8',$file_name;<
Carton考2014 | おそらくはそれさえも平凡な日々
こうするのがいいかなーと思ってる。経緯は端折って大枠だけ。Webアプリケーションプロジェクトの場合です。 cpanfileちゃんと書いてコミット 今やどこでもやってますね。scan-prereqs-cpanfileも便利です。 開発者は各自carton installでモジュールをインストール。プロジェクトごとにPerlをビルドしたりしてる場合は、cpanm --installdeps .でも別に良い。 CI環境でcpanfile.snapshotを作る CI環境は必ず以下のとおりとする。 本番環境と同じアーキテクチャ 本番環境と同じバージョンのPerl まっさらな状態(Globalに何のモジュールも入っていない) CIにcarton installもさせて、必要なモジュールをlocal/に入れてテストさせる。毎回サラからcarton installしてたら時間かかるので、git pull
OrePAN2サーバーの話 | おそらくはそれさえも平凡な日々
最近はArkもCPANに上げたし社内OrePAN運用やってないんですが、OrePAN2サーバー的なのをどうすればいいんだ的なことをhirobanexさんが言ってたのでこんなんでいいんじゃないかという話。 こんな感じのpsgiを作ってplackupで立てて、 こんなふうにリクエストでも送ってやれば良い。 curl --data-urlencode 'module=git@github.com:Songmu/p5-App-RunCron.git' --data-urlencode 'author=SONGMU' http://example.com:5000/ 実際使うとするとコミットフックとかでタグ打たれた時にリクエスト飛ばすとかそういう使い方になるでしょうか。 orepan2-injectはgit URLを直で指定できるのがcoolですね。 追記：ちょっと手を入れてtarを直接受け取ること
おそらくはそれさえも平凡な日々: CPANで意図しない名前空間の取得を防ぐために
だいたいこのへんで教えてもらった話のまとめです。 http://lingr.com/room/perl_jp/archives/2013/04/03 CPANで名前空間を取るのは簡単です。今ならCPANに上げるコードベースの「どこか」に package Hoge; と書けば、CPAN Indexerにインデックスされていとも簡単にHoge名前空間のオーナーになれます。 (執筆時現在Hogeのオーナーはいません) これはlib/以下の.pmファイルやファイル先頭のpackage宣言だけに限った話ではありません。 例えば、example/MyApp.pmとかも対象です。 ちなみに誰がどの名前空間を持っているかは以下を見ることでわかります。 http://www.cpan.org/modules/02packages.details.txt 多くの場合この挙動に困ることはありませんが、以下の様な
おそらくはそれさえも平凡な日々: CSRFDefender的なやつでコンテンツフィルタはしないほうがいいんじゃないかという話
本日の組長のお話。 Ark::Plugin::CSRFDfenderに機能追加したりいろいろバグっていたりしたのに手を入れていたのだが、それに対して組長に意見を頂いた話。結論はタイトルの通り。 CSRF対策をフレームワーク側で入れるのは良いと思うが、フィルタしてformに自動的にhiddenを埋め込むのはあんまよろしくないんじゃないかという話です。 CSRFDefender的なやつには以下のような機能があるが、それぞれに関して述べる。 POST, PUT, DELETE時に自動でtokenチェックしてエラー画面強制表示 自動的にコンテンツフィルタしてform要素にhiddenを埋め込む POST, PUT, DELETE時に自動でtokenチェックしてエラー画面強制表示 OK。安全側に倒している。 自動的にコンテンツフィルタしてform要素にhiddenを埋め込む あまり好ましくない。厳密
おそらくはそれさえも平凡な日々: #isucon で優勝させてもらってきました
まずは、ライブドアの皆様、素晴らしいイベントの提供本当にありがとうございました。めちゃくちゃ楽しかったです。 Kayacのエンジニア3人 @fujiwara @sugyan @songmu の3人でチームfujiwara組を結成し、結果優勝することができました。 実際は周りの認識通り、@fujiwaraさんに優勝させてもらったようなもので、@sugyanと僕は手を動かしていただけです。まあ、空気にならずには済んだので、そこは安堵しています。 修正したisuconソースはフォークしてGithubに置きました。プログラムの修正部分のみで、my.cnfの修正なんかはここには反映されていません。 さて、@fujiwaraのコンテストでの動きや、帰宅後のBlogアップまであらゆる仕事が速くてビビるんですけど、詳しくは、#isucon で優勝してきましたを見てもらうとして、 どういうドタバタがあったの
おそらくはそれさえも平凡な日々: モダンなPerlを「読む」上で覚えておくとよい構文 第2回「リストを理解すれば配列とハッシュをより活用できる」
第1回から大分時間が空きましたが、なんと続きます。「次回は無名関数について書く」とか書いていましたが、先にリストについて言及することにします。 混同されがちですがこのエントリーでは「リスト」と「配列」を厳密に違うものとして扱います。結論を先に簡単に言ってしまうと、リストを配列に代入すれば配列になるし、リストをハッシュに代入すればハッシュになるということです。 Perlの式は値を返す サブルーチンに限らずPerlのあらゆる式は評価された値を返します。返された値は代入先があれば代入され、代入先がなければ捨てられます。 値を返さないケース ブロックは値を返しません(doを使えばブロックに値を返させることが出来ます)。例外的にuse文やpackage文は値を返しません。この二つはコンパイル時にコードを実行する前に最初に評価されるので値の返しようがありません。 さて、本題です。Perlの式の値の返し
おそらくはそれさえも平凡な日々: モダンなPerlを「読む」上で覚えておくとよい構文 第1回(?)
Perl学習者がある程度Perlに慣れてくると、他の人の書いたコードを読む機会も増えてきます。そこでつまづく人は多いのではないでしょうか。かく言う私自身がその一人です(笑) モダンなPerlはDSL(黒魔術?)的な書き方をしている部分も多く、雰囲気として処理内容をつかみやすいのですが、逆に文法的に構文を理解するのが難しいことも多いです。 「知っている人には当たり前、知らない人には黒魔術」 Perlにはそういうのが多いので、そういったところで悩んでいる人も多いのではないかと思い、このエントリーを書いてみることにしました。気が向けば続きも書きます。間違っている部分もあるかと思うので、ブクマコメ等でご指摘いただけると助かります。 本日の目標とサンプルコード 裸のワード(bareword)は怖くない encode cp932 => $str; sub PI(){3.1415926535} てことで
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
