CloudForecastっていうリソース監視のツール／フレームワーク作った - blog.nomadscafe.jp
「クラウド」って言ってみたかった。今は反省していr 上のグラフは前回のエントリーを公開したときの、当blogを配信しているサーバのトラフィックグラフです。記事を公開した17時にぴょーんとトラフィックが伸びています。4時にも増えているけどこちらは謎。 実はこのグラフもCloudForecastを利用して取得しています。CloudForecastはサーバ等のリソース監視を行うツールもしくはフレームワークで、rrdtoolの薄いラッパーとして動作し、小規模から大規模なサーバ群を一括で管理できるように設計してあります。tokuhirom曰く、「perlが書けてrrdtoolがつかえるsysadminの人だったら使いやすいと思われる」というのがもっともしっくりくるような気がします。Perlとrrdtoolが使える運用者によるカスタマイズ前提なのがフレームワークと呼んでいる所以です。 CloudFor
ウェブリブログ：サービスは終了しました。
「ウェブリブログ」は 2023年1月31日 をもちましてサービス提供を終了いたしました。 2004年3月のサービス開始より19年近くもの間、沢山の皆さまにご愛用いただきましたことを心よりお礼申し上げます。今後とも、BIGLOBEをご愛顧賜りますよう、よろしくお願い申し上げます。 ※引っ越し先ブログへのリダイレクトサービスは2024年1月31日で終了いたしました。 BIGLOBEのサービス一覧
古い perl を perlbrew で管理する - tokuhirom's blog
perlbrew は本来、あたらしい perl をつかうことが主眼だが、古い perl でテストする目的にも使用することができる。 % perlbrew install perl-5.8.9 -D=usethreads -as perl-5.8.9-usethreadsのようにすると、オプションつけていろんな perl を生成することも簡単である。 perl5.6.2 や perl5.8.1 などはそのままではインストールできないが、そのような場合には、以下のように俺の repository からパッチ適用済のブランチを co してつかうと、とりあえず OK である。なんか git から直接インストールする仕組みもあるっぽかったけど、うまくつかいかたがわからなかったので力技。 git clone git://github.com/tokuhirom/perl.git cd perl git
簡単！たった１３行のコードでHTML取得＆解析をするPerlスクリプト - DQNEO起業日記
１３行のコードで、Yahoo!Japanのトピックス一覧を取得する！ PerlでHTML取得・解析したいときはLWP::UserAgentとHTML::TreeBuilderというのを使うと簡単にできます。 LWP::UserAgentを使うと、Webページの取得ができます。 HTML::TreeBuilderを使うと、HTMLのDOM解析ができます。 この２つのモジュールを使って、Yahoo!Japanのトピックス一覧を取得してみましょう。 コメント行と空行を除くとたったの１３行です。 use strict; use warnings; use LWP::UserAgent; use HTML::TreeBuilder; # urlを指定する my $url = 'http://www.yahoo.co.jp'; # IE8のフリをする my $user_agent = "Mozilla
第30回 Test::Class：ユニットテストに使うだけでなく | gihyo.jp
メタデータからテスト件数を取得する 前回はテストファイルやテストデータの数からテストプランを計算するモジュールを紹介しました。今回はその続きとして、テストファイルのメタデータからテストの数を求めるモジュールを紹介していきましょう。これらのモジュールの多くは1994年にケント・ベック（Kent Beck）氏がSmalltalk向けに書いたSUnitを祖先にもつ、いわゆるxUnit系のフレームワークに属するものですが、Perlにはそれ以前からTest Anything Protocolを使った独自のテスト手法が存在していたため、Javaなどで使われている同種のフレームワークとはやや毛色の違う部分もあります。一般的にはクラスをひとつ書くたびに対応するユニットテスト用のクラスを書くのがよいように言われていますが、ここではもっとゆるく、テストを自動的に検出してくれるだけでなく、テストの事前事後になん
第31回 encoding：いつまでもjperlから抜け出せない方に | gihyo.jp
いまさら使う人はいないと思っていますが かつて、jperlと呼ばれるものがありました。これは当時まだシングルバイト文字にしか対応していなかったPerl本体にパッチをあてて日本語（など）の2バイト文字をより直感的に扱えるようにしたもので、いまとなっては史料的価値しかありませんが、1990年代にはそれなりに重宝されていましたから、筆者を含めて、お世話になったことのある方も少なからずいることでしょう。 jperlはその後、ライブラリレベルで日本語対応できるようにしたjcode.pl（1992年）や、その流れをくむJcode.pm（1999年）を経て、2000年にリリースされたPerl 5.6からは本家のほうでUnicode対応が始まったことで、その歴史的役割を終え、開発も事実上終了したのですが、困ったことに、それから10年がたったいまなお、jperlを求めたり、勧めたりする動きはやまないようです
shirokaned - messagepack rpc + kyotocabinet + AnyEvent + Perl による適当な KVS の実装 - tokuhirom's blog
http://github.com/tokuhirom/shirokaned HTTP でデータを取得できる そして、その httpd を外部にみせても大丈夫インメモリデータベースLRU supportそれなりにはやい 同時1000接続程度で5000QPS程度でればいいかなーmater-master レプリケーションができる想定しているデータサイズは 4KB 程度で、レコード数は100万程度の LRU で OKキャッシュ用途なので、slave と master で一貫性は必要ないし、データの更新も一切ないvalue がなければ、再生成できるかんじってかんじの KVS があったらいいなあとおもった。 のでためしにかいてみた。 要素技術としては AnyEvent::MPRPC(AnyEvent を用いた messagepack rpc の perl 実装)daemontools(ロガーをつけた
はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
Perl 5は生き返った！ 新たな前進を再開したPerl
「Perl 5コアの開発はここ数年、負の連鎖が続いていた。リリースは滞り、開発者は去り、将来の見通しはどんどん悪くなっていった。ここで話すのは、Perl 5の開発におけるこの悪い流れがどのようにして、楽しく、前向きで、エキサイティングなものに変わったか、というストーリーだ」 Perl 5のコアデベロッパーで、ActiveStateの技術リードでもあるJan Dubois氏は、4月13日に同社のブログにポストしたエントリ「Perl 5 is Alive」で、このように書き出しています。 Perlは、機能が高度化し複雑になったPerl 5までのバージョンを見直し、新たに作り直そうと、2000年にPerl 6の開発が始まりました。しかしPerl 6は10年たったいまでもリリースされておらず（今月に最初のバージョンがリリースされるといわれていましたが…）、一方でPerl 6の開発が始まってからは、
リアルタイムWebのためのPubSubHubbub の Subscriber を構築する方法 - tokuhirom's blog
PubSubHubbub(以下PuSH)は、フィードの更新をリアルタイムに通知するためのプロトコルである。 ウェブ上にころがっている"PuSH"の情報は、"Pub" の部分を実装する方法か、「PubSubHubbub の本家GAE実装を手元でうごかしてみたよ」という記事しかなくて、"Sub"を実装する方法について解説しているブログなどはみあたらなかったので、ここに記す(英語だといくつかあった)。 基本的に、ほとんどの人が興味あるのは "Pub" の部分である。自分のブログの更新情報等をリアルタイムにおくりつけたいと考えるからである。実際、ほとんどのブログソフトウェアではすでに PuSH 対応がすんでいる。see MT-PuSH, etc. しかし、私は今まさに Subscriber をつくりたいとおもったのである。なぜならば、"friendfeed.com/cpan" の更新情報を PuS
Module::Build と EU::MM と M::I と dzil にかんする雑感(miscellaneous thoughts) - tokuhirom's blog
Module::Build の目標は make の排除だとおもうのだが、現実的には、EU::MM に依存している場合には make が必要だし、ある人のモジュールだけが make なしではいるようになってもとくにうれしくはない。 つまり、移行するメリットが薄い。よって、流行らなかったのだとおもう。 おぼえることがふえるのやだし。 EU::MM はもはや積極的に開発はされないようだが、普通に使う分にはもんだいないし、メンテナンスはされてる。 単純な pure perl のモジュールなら、これをそのままつかっても問題はない。 ただし、ちょっとこった実行時の処理などをやろうとすると、よみづらい Makefile.PL ができあがる傾向があるようにおもう。 クールなインターフェースを提供してくれる。プラガブルで拡張可能だ。 日本では、Plagger で M::I が採用されたことを契機に、一気にひ
いまからでも間に合う開発者テスト - mixi engineer blog
はじめまして。開発部じゃない加藤和良です。 最近、mixi では Buildbot をつかった継続的インテグレーションをはじめています。安定版の mixi のソースコードにコミットすると Buildbot がそれを検知し、自動的にテストが走るようになりました。 ここでの「テスト」は Test::Simple や prove(1) をつかった、Perl でかかれた開発者テストを指しています。mixi の開発者テストをとりまく環境は、ここ数年でかなり改善されました。今回はその歩みをふりかえりながら、テストの無いコードベースをどこからどうやって変えていったかという話をしたいと思います。 開発環境 はじめに、前提となる mixi の開発環境について説明します。mixi では複数人の開発者がひとつのマシンで作業を行います。それぞれの開発者は、あらかじめ割り当てられたポートで Apache を起動し、
第25回 Module::Starter：モジュールを書くためのテンプレート | gihyo.jp
モジュールを再利用可能にするためのツールたち Perl 4の時代まではいざ知らず、いまどきPerlのモジュールやアプリケーションを再配布しようと思ったら、CPANモジュールと同じ形式にしておくのがベタープラクティスです。たとえ一般には公開しない社外秘のモジュールであっても、Makefile.PLやBuild.PLを用意して、テストも書いて、できればREADMEやChangesなどの更新履歴もつけておけば、別のプロジェクトを立ち上げたときにコピー＆ペーストする必要もなくなりますし、業務の引き継ぎなども簡単になります。 とはいえ、モジュールを書くたびにMakefile.PLなどを一から書きおこすのは面倒な話。メタ情報の部分はモジュールごとに異なるとはいえ、それ以外の部分は（特にひな形の時点では）大差ないのがふつうですから、できれば省力化したいところです。 今回はそんなときに使われるひな形作成ツ
オススメCPANモジュールその1。 AnyEvent - TokuLog 改めB日記
というわけで、俺の独断と偏見によるオススメモジュールのコーナーです。 AnyEvent は poll/select/kqueue/epoll(4) などのイベントループを抽象化するライブラリです。似たような目的のものとして Danga::Socket, POE などがありますが、ライブラリ全体のインターフェースの完成度や速度などの点から AnyEvent を僕は一番押しています。 Pure Perl で利用できますし、インターフェースも安定しています。まだバリバリ開発されてますが、backward incompat な変更はされないようです。 作者が mlehmann 氏ということで、ドキュメントは丁寧ですが攻撃的な文章が目立ちますし、バグレポートすると異常な長文がかえってきたりするのでうっとーしかったりしますが、コードの品質はたかいので、気にする必要はないかとおもいます。コードの品質の前
Kazuho@Cybozu Labs: crontab を使って効率的にサービス監視する方法
監視とは継続的なテストである、という話 (もしくは cronlog とテストスクリプトを組み合わせた監視手法について)に続きます 今日ようやく、積ん読状態だった「Software Design 2010年1月号」を手に取ったのですが、特集が「今日から使えるスクリプト満載！ [プロ直伝]お手軽サーバ監視術」。興味深く拝読したのですが、もっと楽ができるのにと思うところも。ちょうど、昨年末に運用しているサービス「パストラック」のサーバを移転し、crontab と perl で書かれたスクリプト群を使った監視環境を構築したところなので、そこで使っているスクリプト cronlog を紹介したいと思います。 特集の前書きにも書かれていることですが、サーバやネットワーク機器が多数ある環境なら、Nagios を始めとする、専ら監視のために作られたソフトウェアを使って、監視システムを構築すべきです。逆に小規
YPUNをやりたい - D-6 [相変わらず根無し]
YPUNをやりたい 企画が出ただけの段階なので、まだなんとも言えないのですが、2010年5月〜7月くらいに東京以外の某場所でYet another Perl UNconference (YPUN)を開催しようかという話が出ました。 アンカンファレンスに関してはこちらを参照。 まだこれから諸々調整があるのでぼかした言い方ばかりで申し訳ないのですが、一応考えているのはこんな感じ： 某地方都市で泊まりがけキーノートだけこちらで設定地元企業もからめてBOFあとはアンカンファレンスで話したい内容を思い思いにPerlとはあるけど、ゆる〜〜〜〜〜い縛りでなるたけうまく方々と調整して参加者は基本的に交通費だけで済ませることができるようにしたい！今候補に挙がっている場所は某中部地方エリアうまくいくようなら定期的に地方都市で巡回開催したい！ちなみに直接の発案者は僕じゃないので、この企画が本当に通るかどうかは
tokuhirom blog
Blog Search when-present<#else>when-missing. (These only cover the last step of the expression; to cover the whole expression, use parenthesis: (myOptionalVar.foo)!myDefault, (myOptionalVar.foo)?? ---- ---- FTL stack trace ("~" means nesting-related): - Failed at: ${entry.path} [in template "__entry.ftlh" at line 3, column 25] - Reached through: #include "__entry.ftlh" [in template "entry.ftlh" at
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - mala/AnyEvent-Curl: AnyEvent + WWW::Curl
livedoor ReaderのクローラとStreaming APIなどの話
Webアプリケーションフレームワーク「Catalyst」入門一覧
