日本国内のperlエンジニアに朗報！！ 初心者にもやさしい、日本人向けのperlエンジニアのためのチャットができたみたい！ ▼ http://lingr.com/room/perl_jp/ ゆるふわなかんじで perl の話題をするためのチャットルームをつくってみた – tokuhirom’s blog. ぼくもログインしてみたけど、チャットの中にいる人たちは、perlを使ってＷＥＢの世界を支えているTOPエンジニアの方が多くいた。 （ＷＥＢ＋ＤＢ ＰＲＥＳＳや書籍を出版しているような人達） もしperlに関する情報源を探しているなら絶対に参加すべきだと思う。perlエンジニアの人達は優しいことで有名だから、きっと力になってくれると思う。 残念ながらphpのシェアが圧倒的に多い ＷＥＢプログラミング言語の世界では、PHPのシェアが圧倒的に多い。 W3Techsのデータによると、サーバーサイ
Homebrew で groonga をインストールしている前提のお話。 and GROONGA_LIBS to avoid the need to call pkg-config. See the pkg-config man page for more details. とか出てたら、GROONGA_CFLAGS と GROONGA_LIBS を指定してあげる。 GROONGA_CFLAGS="-I/usr/local/include/groonga" \ GROONGA_LIBS="-L/usr/local/lib -lgroonga" \ brew install https://raw.github.com/mroonga/homebrew/master/mroonga.rb --use-homebrew-mysql
世の中はGoogleリーダーで盛り上がってる中、Livedoor Readerに移行した@HIROCASTERでございませう。 そんななか、ひっそりと git 1.8.2 がリリースされました。 リリースノートを眺めていたら知らない機能があったので書いておきます。 git check-ignore * “git check-ignore” command to help debugging .gitignore files has been added. 1.8.2からの新機能です。 .gitignore ファイルに記述されてい内容と実際のファイルが該当するかチェックできます。 例えば .gitignore ファイルに /tmp と書いたとします。 $ git check-ignore -v ./tmp .gitignore:1:/tmp ./tmp のように1行目の設定に該当して、exc
追記 2012/06/22 公式ページを作りました。そちらも参考にしてくださいませ GrowthForecast - Lightning fast Graphing / Visualization http://kazeburo.github.com/GrowthForecast/ Kansai.pmのLTでも紹介したんだけど、APIを叩く事でグラフを更新するツールを書きました。話の発端としては「cloudforecastのグラフを外からAPIで更新したい」ということでしたが、cloudforecastではグラフの追加が重い処理になってしまうので、別のプロダクトとしています。 サーバの負荷などのメトリクスを収集し、グラフ化することで、システムに掛かっている負荷を把握し、パフォーマンスに影響がでるまえに対策をうったり、改善の結果を知る事ができますが、同じ事はシステムだけではなく提供しているサ
GrowthForecast - Lightning fast Graphing / Visualization 研究室で各サーバと部屋の温度をグラフ化して，値が異常ならメールで通知しろみたいなタスクが降ってきた． もともと各サーバの統計値をMuninでグラフ化していたけれど，VMware VSphereが入ってる物理サーバの温度とれるようなプラグインないし，自分で書かないといけない感じになったり，Muninの設定とか調べるのだるい感じになってきたから，最近コード眺めてたGrowthForecastを使ってグラフ化しようと思った． lm-sensorsやVsphereのAPI叩いて温度を取得し，GrowthForecastのAPIにPOSTする感じのスクリプトを作成して，各ノードからcronで定期実行すればできそう． OSはUbuntu 12.04． curlをインストールしておく． 実行
最近 SPDY と WebSocket がアツいですね。 再来週の SPDY & WS 勉強会 も、定員100名に対して 参加者が 247 名とかなりアツいことになっています。 その予習というわけでもないですが、最近 WebSocket を実サービスへの 導入方法を考えながら遊んでいたので、 WebSocket の負荷分散方法について 考えていることを書いておこうと思います。 ステートフルな WebSocket アプリケーション HTTP サービスは基本的にステートレスな実装になっており、リクエストが来るたびに DBサーバーや memcached などのバックエンドから情報を取得して返していました。 この構成では Web アプリ自体は完全にステートレス化することができているので、 負荷分散機はラウンドロビン等のアプリケーションを無視した負荷分散をすることができました。 しかし、 WebSo
簡単な表記だと色々な書籍に載っているのだが、 全部が網羅されているわけではないので、 あまり使用しない表記に出くわしたら、ぐぐるしかない。 しかし、$(ダラー)、:(コロン)、=(イコール)などの記号が混じった表記は ぐぐりづらいので、ちょっと整理してみた。 表記 意味 $NAME 変数NAMEを表す。 $1, $2, …, $9 各引数を表す。順に1番目、2番目、…、9番目を意味する。 ${10}, ${11}, … 10番目、11番目、… の引数を意味する。 $0 実行されたシェルスクリプトのファイル名を表す。 $# 引数の数を表す。 $@ 引数をスペース区切りで表す。 $* 引数を環境変数IFSで区切って表す。IFSが空の場合、スペース区切りとなる。 $? 直前に実行された処理の終了コード値を表す。 $$ 現在実行中のシェルのプロセスID値を表す。 $! 直前に実行された処理のプロセ
I intentionally excluded modules like WWW::Mechanize, which provide higher-level functions. Web::Magic was close to failing that test! I'll look at each module in turn, then present results of comparing the modules, and finally which module you should use when. In comparing the modules, I'm looking at the following: Does it provide a clean simple interface? Can you make https requests? Which HTTP
開発メモその3です。今回は Perl のおはなし。 何年も前に作ったウェブアプリケーションのコードを開いてみたら黒歴史なコードが出てきて憂鬱な気分になる、そんな経験ありませんか。私はあります。ずっとそんな現実から目を背けて生きてきました。 さて、先日 Perl + CGI で書いて Apache::Registry で高速化している、実行環境が Apache に癒着した CGIアプリケーションを発見しました。おえ〜っ。一から作り直したい気持ちをぐっと堪えて、これを Plack 化したりとリフォームしていくとしましょう。その過程を以下記します。劇的ビフォア・アフター! ･･･とかは期待せず、地道な変更を積み重ねていくのがコツです。 方針 いきなりコードをがりがり書き換えていくというよりは、試行錯誤のしやすい環境に移行させていきながらリフォームを進めます。遠回りですが、結果的にその後の運用が楽
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
