YAPCでおもしろ発表してきた - hitode909の日記
YAPCでおもしろ発表してきた． はてなブログの開発を振り返って設計の進化と最高の設計を紹介するという話． speakerdeck.com なぜか大人気発表みたいになってて，会場満員で，すみませんこんなところに来ていただいてすみませんというかんじだった． 紹介した本はこちら．予約投稿で仕込んであって，発表終わったら，こちらから買ってくださいとかやろうと思ってたけど，すっかり忘れてた． YAPCの発表で紹介した本 - hitode909の日記 質問たくさんいただいて，よいかんじにおさまったと思う． 「難しくて挫折するという問題がありますよね」「歯を食い縛って実装しろって書いてあった」 #yapcasiaE— そらは (@sora_h) 2015, 8月 21 Q: 「コメントの良い書き方は？」 A: 「オブジェクト指向入門下巻に書いてあります」 ↓ 「買って読みます。」 #yapcasiaE
MySQL データベースからテーブル定義書を生成する - わたねこコーリング
ネクタイ締めて SE らしきものをやってた頃はコードよりドキュメントのほうを山のように書いてたもんですが、限りなくプータローに近いフリーの身になってからはそんな苦行も今は昔… と言いつつ、タマに「DB の仕様書下さい」「ダンプした DDL でいいっすよね」「…え?」「え?」てなこともあります。 てな訳で、既存の MySQL データベースをソースに、よくあるテーブル定義書を生成するのが今日のお題。車輪の再発明を避けるべくグーグル先生に相談してみたら SQL::Translator という、様々な DBMS の SQL をこれまた様々なフォーマットに変換する、正にうってつけの CPAN モジュールがあったので、これを使ってみます。全体的には mysqldump でテーブル定義を SQL 出力 SQL::Translator を使って SQL から XML に変換 XSLT で XML をテーブ
nginxのproxy設定ファイルも自動テストしよう - $shibayu36->blog;
最近nginxでリバースプロキシの設定を書いているんだけど、設定のたびに本番に緊張しながら反映していた。さらにその副作用として、nginxのファイルはリファクタリングされないという問題があった。 そこで反映する前にバグ等が見つかるようにnginx設定のテストを書きたいと考えた。今回はperlでテストを書いた。 どういうテストをしたいか やり方によってnginxの設定ファイルの分割の方法は違うのだけど、例えば以下の様なnginxの設定があり、それが別のファイルのhttpコンテキストの中にincludeされているという分割で考える。この時、この設定ファイルに書かれた内容が正しく動いているかテストを書きたい。 upstream app1 { server app1.host; } upstream app2 { server app2.host; } server { listen 8080;
YappoLogs: サービスをつぶさない為に Web アプリを書く時にやっとくと良い事2選
サービスをつぶさない為に Web アプリを書く時にやっとくと良い事2選 テンプレートのエラーが出た時にアプリケーションのログだけに書くのでは無く、誰にでも「ここがえらってるよ！」って見えるようにしとくと間違いが少なくなる傾向があるのでテンプレートエンジンでフック出来るようになっておいてたら、それをうまく使うと良い。 また、テンプレートエンジンがレンダリングしてるフェーズで DB にクエリが飛ぶような構造で書いてあると、非エンジニアのカジュアルにテンプレートいじる人が甚大なクエリを実装してしまう可能性があるので、これも早期に発見しないとサービスが止まってしまい会社の売り上げが下がってしまい社員が路頭に迷うケースが発生してしまうので、これらも未然に防がなければならない。 Text::Xslate + Amon2 ならこうかける。 package MyProje::Web; ...; { my
大規模なデータをそれなりに効率良く計数できる Algorithm::LossyCount を書いた
要旨 Algorithm::LossyCount というモジュールを書きました。これを使うとそこそこメモリ効率良く大規模なデータの計数ができます。アクセスランキング集計とかに使えるんじゃないでしょうか。 Github MetaCPAN 動機 例えばブログホスティングサービスで HTTP サーバのアクセスログを集計して人気のあるブログ記事ランキングを出したいとします。 Perl でデータの出現頻度を計数するのはハッシュを使うのが鉄板なので、適当に書くとだいたいこんな感じのコードになると思います: #!/usr/bin/env perl use v5.18; my %access_counts; while (<>) { chomp; my $access_log = parse_access_log($_); next if is_article_request($access_log);
YAPC::Asia Tokyo 2013: 「本当にあったレガシーな話」と最近のlivedoorBlogの改修 : D-7 <altijd in beweging>
はい、というわけで自分のトークです： 昨年12月頃から関わってるlivedoorBlogのコードを触っていた時の憤りをスライドにぶつけてみました。 追記：スライドに「ログにマーカーをつける」というのは、（コード読んでないけど）多分こちらのエントリにあるLog::Minimal::Indentとだいたい同じ感じのヤツです ところでWeb上で見かける感想の中でこんなのがありました： 今年個人的に一番衝撃的だったのはやっぱ、livedoor blogのPlack化です。技術的な側面もさることながら、ああいう近視眼的には何のメリットもないし、逆にデメリットの方が大きそうな案件にリソースを割くジャッジができる会社としての姿勢が本当に凄いなと。 実はビジネス的にも意味はあるんだなー。 なかなか書くことができなかったんだけど、その内容というのがこちらと→ ブログのお引っ越し機能を大幅に強化しました！ （
uehatsu.info - uehatsu's tech blog | 忘れないうちに、cpanmのインストール方法
（追記）cpanコマンドでcpanmをインストールする方法を乗せました。参考にして下さい。 cpanmを使い出して、めっきりcpanコマンドを使わなくなったuehatsuです。 とりあえず、忘れる前にcpanmのインストール方法を書いておきます。 基本、CentOS 5や6ではrpmforgeなどがperlモジュールを色々と出しているので、そこからガンガンyumでインストールすれば良いのですが、バージョンが古かったり、新しすぎてstableでなかったりといろいろ。そこでcpanmをインストールして、モジュールをインストールしていきます。 $ cd /usr/bin/ $ sudo curl -LOk http://xrl.us/cpanm $ sudo chmod +x cpanm これでcpanmのインストールは終了、簡単ですね。ただし、色々と周囲のモジュールがアップデートされていますの
Rebuild: 7: Perl Community, YAPC (yusukebe)
Rebuild A Podcast by Tatsuhiko Miyagawa. Talking about Tech, Software Development and Gadgets. 0:00 miyagawa: ぼくが昔、Shibuya.pmを始めたときも、渋谷のビットバレーとか言われてた、ドットコムバブル時代に始めたっていうのがあったけど、そのときには渋谷にあって、一瞬六本木ヒルズ方面にバーっと分かれたけど、またヒカリエで戻ってきた感じですね。 yusukebe: ぼくはその辺のビットバレーの時代ってあまり知らないので、なんとなく聞いた話で憧れみたいのがあって（笑）。それが今に戻ってきたっていう、なんか面白い感覚ですね。 miyagawa: 日本のPerl使いの世代っていう意味で言うと、tokuhiromとかゆーすけべーとかは、ぼくらからすると第2世代的なイメージがあるんだけど。
本番環境でのperl/ruby/nodeのセットアップ - たごもりすメモ
本番環境にperlとかrubyとかnodeを入れるんだけど、もちろん system perl じゃやってられないので指定したバージョンのものを一般ユーザの管理下に突っ込みたい。 で、そういうのをこれまで perlbrew とか rvm とか rbenv とか nvm とか nodebrew とかでやってたんだけど、さすがに色々疑問が湧いてきた。バッチで単発実行するために eval "$(rbenv init -)" とかさすがにおかしくね？ みたいな。 ということで tokuhirom method 的にインストール用の簡単コマンドを使って実行、あとはパスを通せばいいじゃん、ということにしようかと思う。 参考: サーバーのセットアップは perlbrew とかじゃなくてよくね? という時のライフハック - blog.64p.org これ、今朝までは Perl::Build をどうにかしてC
サーバーのセットアップは perlbrew とかじゃなくてよくね? という時のライフハック - tokuhirom's blog
https://metacpan.org/module/TOKUHIROM/Perl-Build-0.06/bin/perl-build perl-build というコマンドをつかうと便利。 perl-build 5.16.2 /opt/perl-5.16/ とかで管理するとよい。 perl-build 5.16.3 /opt/perl-5.16/でのアップグレードもうごいている様子。 おためしあれー。 FAQ./configure -d -Dprefix=$path でよくね?それでもいいのですが、PatchPerl によるパッチがあたるので、古いバージョンも確実にはいるのが嬉しいところです。 あと、tar ball のフェッチとかまで自動的にやってくれるのも便利。
安定的な Perl アプリケーション運用のための perlbrew 運用テクニック - tokuhirom's blog
前提知識Perl5 は minor version 間ではバイナリ互換性が保証されているPerl5 の minor update では、bug fix しか基本的に行われないPerl5 Porters の保守的さ度合いは信用できるperlbrew でセットアップするときに気をつけることインストール名をデフォルトの perl-5.16.3 などとせず、perl-5.16 と minor version を含めないようにする。 例: perlbrew install perl-5.16.2 --as perl-5.16セキュリティフィックスがでた場合の処理chromaticの記事で知ったのだが、perlbrew には upgrade-perl というコマンドがあり、最新のバージョン(マイナーアップデートのみ)にアップグレードすることが簡単にできる。 perlbrew upgrade-perlこ
YappoLogs: perlbrew best practice
perlbrew best practice perlbrew には $ perlbrew upgrade-perlというのが実装されてるのがあまりにも有名ですが、これは現在使ってる環境の perl を、そのマイナーバージョンの中で一番新しいバージョンにアップグレードしてくれるんです。 perl-5.16.1 を使っていたら perl-5.16.3 に perl-5.14.2 を使っていたら perl-5.14.4 に。という具合ですね。 同じマイナーバージョンの Perl では XS バイナリの互換性とか保証されているので、すでにインストールされているモジュールはそのまま利用できる状態になっています。 だがしかし $ perlbrew install perl-5.16.2して作った環境を upgrade-perl すると 5.16.3 が入ってるのに perl-5.16.2 って名前が
perlbrewとextlibなアプリのcronとかdaemontools - As a Futurist...
perl は system perl じゃなくて perlbrew で入れて、アプリで必要な CPAN モジュールは全てアプリのディレクトリ下の extlib というディレクトリにインストールする方式は個人的にはいい感じだよなぁと思いつつ、cron とか daemontools がいつもどうやるのが正解なのか分からず困ってた。 またセットアップする機会があったので色々考えた結果、こんな感じなら割とすっきりした感じになった。 env このファイルがキモで、アプリのディレクトリに移動しつつ、いい感じに perl とか PATH とか@INC を設定して、渡されたコマンドを実行してくれる。 # perl -v This is perl, v5.8.8 built for x86_64-linux-thread-multi # ./env perl -v This is perl 5, versi
Kansai.pmに行ってCinnamonというデプロイツールについて発表しました - $shibayu36->blog;
http://www.zusaar.com/event/476003 に参加して来て、前作ったデプロイツールであるCinnamonについて発表して来ました。 発表したこと 以前capistranoの奥深さに毎回ハマっているのを怒りを覚えて、もっとシンプルなデプロイツールであるCinnamonをantipopさんと一緒に作ったのでその発表をしてきました。それなりに好印象っぽかったので、発表してよかったです。 スライド Cinnamon - simple deploy tool from Yuki Shibazaki デモで使ったサンプルコード https://github.com/shibayu36/cinnamon-deploy-sample 簡単に紹介すると CinnamonはMinimumというのと、Role x Taskというのを思想として持っている Minimum : デプロイの方
Sub::Rateと言うのを書いた - unknownplace.org
Sub::Rate - Rate based sub dispatcher generator - metacpan.org 確率に応じて処理を振り分けたいというような要件をカジュアルにクリアできる感じになっております。 たとえばいわゆるガチャ的なものを考えたときに、 my $rate = Sub::Rate->new( max_rate => 100 ); $rate->add( 0.1, sub { say 'Super rare' }); # 0.1 % $rate->add( 3, sub { say 'Rare' }); # 3 % $rate->add( default => sub { 'Normal' }); # 残り my $func = $rate->generate; みたいな感じで関数を生成できて、この生成した $func は呼ぶと確率に応じて登録された関数を呼び出
カジュアルにデータを確率とか優先度で処理する - Articles Advent Calendar 2012 Casual
こんにちは、こんにちは。カジュアルにPerl使っているkoba04 です。 Webアプリを作っていて、確率で処理を分けたり複数の要素を重み付けて選びたいことってありませんか？ 真っ先に浮かぶのはガチャみたいなものですが、それ以外にもランダムでバナーを出し分けてみたり、接続するサーバーを重み付けて選んだり色々と使い道が思い浮かびます。 そんな時に使える二つのモジュールをご紹介したいと思います。 詳しくは下記の作者の方のブログを見てください。 Sub::Rate Data::WeightedRoundRobin 以上！ でもいいのですが..順番に紹介してみたいと思います。 モジュールなしで実装 優先度を付けてデータを選びたい時はrandを使っての実装が思い浮かびますが、バグりそうな気もするし面倒だし出来れば書きたくないです。 (書き方が悪いという説もある) # 結果をdumpする関数 sub
HRForecast - もうひとつのデータビジュアライズツール - blog.nomadscafe.jp
ずいぶん前から作って動かしてはいるのですが、GrowthForecastの他にもうひとつのグラフ作成ツールを公開しています。 https://github.com/kazeburo/HRForecast デイリーで更新される数値のビジュアライズに使う事が出来ます。GrowthForecastにはない過去データの登録もできます。 モリスさんのスライドでも少し登場しています。弊社では主にHiveでの集計の書き出し先として使っています http://www.slideshare.net/tagomoris/log-analysis-with-hadoop-in-livedoor-2013 画面はこんな感じ 他のページにembedするHTMLの発行やCSVでダウンロードをサポートしています データの登録APIについて データの登録は、GrowthForecastと同じようにURIに対してPOSTリ
開発メモ#1 : Cinnamon によるデプロイ - naoyaのはてなダイアリー
このごろ作っているものが幾つかあるのだけど備忘録代わりにこの辺はこうしているということを書いて行こうかなと思います。 まずは Perl によるアプリケーションのデプロイについて。id:antipop と id:shiba_yu36 が開発した "Cinnamon" というミニマムなデプロイツールを利用しています。 Cinnamon - A minimalistic deploy tool https://github.com/kentaro/cinnamon シンプルで使いやすいデプロイツールです。 Capistrano? デプロイツールの定番といえば Capistrano で、最初は Capistrano を使っていました。けど、作っているものはほぼ Perl で書かれているのにデプロイツールだけ Capistrano で Ruby というのが、例えばモジュールの管理に Carton と
モダンPerl製サイトのベース解説書『Plack Handbook』を読んだ | hirobanex.net
Plack Handbookは、CGI以降の最近のPerlを使ったウェブサイトを作る上でベースとなるPSGIという仕様の実装であるPlackのまとまった(電子)書籍です。待ちに待ってましたという感じだったんですが、でやっと入手して読んだ感想とかをメモります。 といいつつPlackって何?詳しく教えて? 上述した通りなものがPlackなのですが、FTPでアップしてふんふんふん、という事をしている人にとって、いまいちピンとこないのがPlackだと思います。昔は、FTPを使って.cgiファイルみたいなのをアップしてちょっとした動的な動きをするページを作るには、PerlだとCGI.pmというCPANモジュールに準拠しながらいろいろと作っていたのです。ただ、ApacheのCGIという技術の上だと、何分毎回プログラムファイルの読み込みをとかを行うので遅かったりしたのです。そこで、FastCGIとかmo
perlbrewを使うにあたっていろいろな小細工をした件 - （ひ）メモ
最近perlbrewを使っています。で、いろいろ小細工をしたので問題点とその解決方法のまとめです。 補足すると、深遠な理由とかマリファナ海峡より深い事情とかがなければ、バッチ用、shebang用に(↓で書いてる)appperl的なラッパーを用意するだけでいけるんじゃないかと思います。 問題点 perlbrewのサイトを見るとビールがのみたくなる http://perlbrew.pl/ perlbrewedなperlの実行方法 対話シェル上で スクリプトのshebang (#!) cronで実行する場合 サーバーワイドな共通の@INC perlbrewedなperlの実行方法 perlbrewedなperlをどう実行するか、3つの局面にわけて考えます。 対話シェル上で 基本、~/.bashrcで $PERLBREW_ROOT/etc/bashrcを読めばOK。 なのですが、(深淵なる理由があ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
