Perlベストプラクティスのベストプラクティスじゃないやつをまとめてみた | おそらくはそれさえも平凡な日々
Perlベストプラクティス Perlベストプラクティス(略してPBP)という良い本があります。僕自身もPerlを学ぶ過程で非常にお世話になった本なのですが、以下の様なことが度々指摘されています。 bestって書いてあるけど「著者の」bestプラクティスなので偏りがあることも 「決して」とか「必ず」とかが多いけどあんま真に受けてはいけない この本を書くために書かれたであろうCPANモジュールとかがあって、しかも公開されてないものまである 致し方ないけど現在の状況にマッチしない古い情報もある なので、PBPの何がベストじゃないのかについてまとめてみることにした。前からやりたかったんだけど、思い立ってやった。 まとめてみたら、思っていたほどには項目が上がってこなかったので、やっぱPBPは良い本だなと改めて思いました。なので、このエントリーがこれからPBPを読む人の助けになれば良いなと思います。
Yokohama.pm #11 でライブコーディングしてきました | おそらくはそれさえも平凡な日々
発表資料 リポジトリ CPAN 動画 一時間強の長きにわたってお付き合いいただいいた皆様有難うございました。 今回ライブコーディングを引き受けた上で考えたのは以下の点。 いつもの開発っぽい雰囲気ですすめたい ちゃんとテストは書きたい 普段どのように開発しているかの雰囲気と、どういうタイミングでテストを書いているのかとかを、普段テストを書き慣れていない人にもできれば勘所が分かるようにしたいなーとか思っていました。 実際は結構内容を詰め込んでしまって駆け足になってしまったりとか、コンソールでの作業が長かったのでちょっとイメージを掴みづらい人も多かったかもしれないなと反省しています。 最初1時間もらった時は長すぎだと思っていたのですが、実際は全然足りませんでした。あれ以上長くやっても、見ている方もダレると思うので、もっとうまくまとめてできるようになりたい。 またやりたくなった。YAPC::Asi
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
List::Util#pairmap|pairkeys が便利 (Re: ハッシュっぽい配列からkeysだけ取り出したい) 追記有り | おそらくはそれさえも平凡な日々
List::Util#pairmap|pairkeys が便利 (Re: ハッシュっぽい配列からkeysだけ取り出したい) 追記有り http://hisaichi5518.hatenablog.jp/entry/2013/03/25/151942 Github::Hooks::Manager作ってるときに、HTML::Shakanに手を入れたりしてて、その流れでHTML::Shakanのオーナーになったりしてたのですが、その際に知った List::Util#pairmapが便利だった。 PSGIのSPECでも使われていたりしていることも関連しているのか、最近key valueのペアが入った配列を見かける頻度が上がってきたように思います。 で、そういうのを上手く扱う方法が無いのかなーとかみんな思っていたかとおもうのですが、灯台下暗し、List::Utilにpairmap()ってのがありまし
おそらくはそれさえも平凡な日々: サーバーマシンのコア数に応じてworker数を調整する方法
PSGI/Plackアプリケーションの起動方法いろいろと本番環境アレコレ 便乗ポスト。最近は、上記内の「シェルスクリプトでラップする方法」で運用していることが多いです。その場合のone more tips. appサーバーごとにマシンスペックが違う場合がたまにあって、その場合マシンごとに worker数を調整したいけど、deployの都合上サーバー起動スクリプトは同じやつを使いた いってことがあります。 そこでおすすめなのが、CPUコア数に応じてworker数を計算する方法です。 シェルスクリプトの場合、 % cat app.sh #/bin/sh NCPU=`getconf _NPROCESSORS_ONLN` WORKERS=$(expr $NCPU \* 5) exec plackup -E production -s Starlet --max-workers=$WORKERS と
おそらくはそれさえも平凡な日々: CPANモジュールのパッケージングの歴史
最近同僚が次々とCPAN Authorになってて良い流れだなーとか思っています。 ただ、CPANへのモジュールの上げ方がわからないとか、M::Iを使えばいいのか M::Bを使えばいいのか、それらがそもそも何やってるのか分からないという話も 聞くので、僕自身もその辺の知識を整理してアップデートしました。 とりあえず、今はModule::Buildを使っておけば良いんじゃないかと 思っていますが、そこに至る歴史的経緯をまとめてみます。 大体、以下に書いてあることに加えて、最近の動きを書いています。 Module::Build：MakeMakerの後継者を目指して PerlでCPAN形式のモジュールを配布する場合は、Makefile.PLなりBuild.PLなりを モジュール作者が用意して、それがインストールに必要なファイル類を自動生成 するという流れになっています。 既存の雛形を使うと色々ファ
おそらくはそれさえも平凡な日々: 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=300
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
