naoyaのはてなダイアリー
ときどき、たまたま自分がそのとき考えていたことについてそれを補強するような材料が偶然たくさん集まってくる、なんてことがあります。そんな出来事があったので、ちょっとブログを書いてみようかなと。 以前に HBFav を作ったときこんなことを書きました。 Mark Zuckerberg は、いずれみんな、ニュースは友人知人経由で知ることになるだろうと言っていました。自分もそうなるだろうと思います。 4年ぐらいが経ちましたが、その思いは以前よりも増して確信めいたものになってきています。 ところで先日、Twitter の iOS アプリに「ニュース」という機能が追加されました。人によっては出てないそうなのでまだテスト中か、もしくは既に削除されているのかもしれないですが。 この機能についての自分の感想は以下のようなものでした。 もうすこし補足します*1。 Facebook や Twitter のような
naoyaのはてなダイアリー - Perl のクロージャ
いつもお世話になってるあの人とかあの人とかが山口家の逆襲->perl-解説->クロージャというクロージャの解説ページをブックマークしてるのをきっかけに、 Perl のクロージャについて自分もちゃんと理解できてるのかというのを考えてみましたが、どうも微妙です。 クロージャについて、何でいまいち理解しきれてない感じがあるのかというと、クロージャがどういうものであるかは知ってるけど、クロージャをどういう時に使うと良いのかが具体的にあれとこれという感じで思い付かないからなのではないかと思った。 なので、Perl でクロージャを使ってる実装とかを見て、どんなときに使われるものなのかをリストアップして理解を深めてみよう..のコーナーです。 クラスにデータを保持するためのクロージャ 僕がぱっと思いついたのは Class::DBI の中で使われている Ima::DBI におけるデータベースハンドラのキャッ
pmtools - naoyaのはてなダイアリー
Journal of Mark Leighton Fisher (4252) で Tom Christiansen が 1999 年に書いた pmtools なるツール群があるという話が挙がってました。pmtools という名前を初めて聞いたもんで、試しにインストールしてみました。 pmtools は Perl のモジュールや POD に関する小さなコマンドラインツールがいろいろ同梱されてるパッケージです。インストールはアーカイブ落としてきて perl Makefile.PL; make; sudo make install で OK。それぞれのコマンドの使い方は README 見るなり man 見るなりで見ることができます。 基本的に Perl のコード数行からなる簡易ツールで、ワンライナーとかでやることが多いものをコマンドひとつで呼べるようにしてるとか、そういうものがほとんどでした。1
GNU screen いろいろまとめ。 - naoyaのはてなダイアリー:
先日人力検索で GNU screen の設定TIPSについて質問してみたところ、かなーり役立つ設定とかをたくさん教えてもらうことができました。みなさん感謝。 そんで、教えていただいた通りにカスタマイズした結果、こんな感じのスクリーンショットが撮れました。MacOSX のターミナルです。 おかげさまでかなり便利になって作業効率が上がったと思います。いろいろ教えてもらったお礼とまではいきませんが、やった設定とかをはまりどころとかも交えて紹介してみます。名付けてリバースNDOメソッド。ちなみに、知ってる人にはごく当然のことが当たり前のように書いてるので、あんまり役に立たないかもしれません。 hardstatus alwayslastline で最終行にウィンドウ一覧を表示 これは今回の質問とは直接関係ないのですが、やるとやらないとでかなり使い勝手が違うので。 hardstatus alwaysl
派手なデバッグスクリーン / ディフェンシブ・ウェブデザイン - naoyaのはてなダイアリー
Catalyst, SubWay, Rails などのモダーンな Framework では、デバッグモードで Internal Server Error が起きるとスタックトレースなどをド派手な HTML で表示してデバッグを助けるような仕組みを持っています。 But, Sledge にはそれが無い！なんてこった！この事実がバレる前にはやくその機能をつけないと！ つーわけで、Sledge::Plugin::DebugScreen とかいうものを作ってみました。 こういうの重要。はてなフレームワークも派手なの出してます。 色使いが 37Signals っぽいのは単なる僕の趣味です。 37Signals と言えば、昨日 37Signals のデザインの本を読みました。ディフェンシブ・ウェブデザインの技術。 フォームでのエラーから訪問者を立ち直らせ、自社サイトで確実に Subscribe しても
naoyaのはてなダイアリー - xinetd 経由で SQL をたたくためのデーモン
Perlネットワークプログラミング―ソケットの使い方からクライアント/サーバーシステムの開発まで を読んでたら Chatbot::Eliza を使った簡単なスクリプトを、inetd 経由で動かしてデーモンとして動かすみたいな話がありました。inetd はその中で、標準入力や標準出力をクライアントとのソケットへ再オープンして、指定されたコマンドをデーモンとして実行するので、標準入出力を扱う簡単なプログラムを修正なしにデーモンとして動かすことができる、といったもの。 ということで、試しに簡単な Hack をしてみました。 #!/usr/local/bin/perl use strict; use warnings; use DBIx::DWIW; $| = 1; my $db = DBIx::DWIW->Connect( DB => 'mysql', User => 'nobody', Pas
Catalyst::Engine::HTTP::Resterter における自動再起動サーバーの実装
前の話の続き。新しい server.pl は -r オプションをつけたときに、自動的にファイルの修正を検知して再起動してくれる機能が付いてます。 いままでの server.pl だと、デーモン上で perl が永続化してるためにモジュールを書き換えてもそれが再読込されず、一度 ^C で止めてまた起動とかする必要がありました。で、それが必要なくなったと。先日 Rails を試しにいじってたんですが、Rails 付属の WEBrick なサーバーは、クラスの更新も検知してくれてスゲー便利だったので、server.pl がこの仕様になったのはすごくいいです。 どういう実装でこれを実現してるのかなーと思って見てたんですが、やっぱりそこは Catalyst、ちょっと面白い実装になってました。手元にある 5.33 からだと Catalyst::Engine::HTTP::Restarter Catal
Catalyst の開発版の Helper - naoyaのはてなダイアリー
PowerBook にインストールして使ってる Catalyst は 5.33 なんだけど、このところすごい勢いでバージョンアップしているらしい。 それはさておき、svn から開発版のソースを拾ってきて Catalyst::Helper のコードを眺めていたら server.pl がずいぶんパワーアップしていることに気づく。 Options: -d -debug force debug mode -f -fork handle each request in a new process (defaults to false) -? -help display this help and exits -host host (defaults to all) -p -port port (defaults to 3000) -k -keepalive enable keep-alive con
MySQL の order by rand() - naoyaのはてなダイアリー
MySQL のレコード取り出しの際に、ソートをランダムにできないものかと調べていたら、あった。 SELECT * FROM table ORDER BY RAND()こんな感じで。ソートを RAND にすれば良いという… そうそう、僕もこれは最近知ったんですが。Haropy でエントリーをランダムに取り出すのにも order by rand() を使ってます。Class::DBI::mysql に retrieve_random というメソッドがあって、ランダムに一見取り出すことができるという。これも中では order by rand() limit 1 をやってます。 ただ、この rand() はデータ量が大きいテーブルには使いづらいという罠。 mysql> explain select id from entry order by rand() limit 1 ?G *********
MVCフレームワークにおける Web API 実装 - naoyaのはてなダイアリー
ちょっと前に miyagawa さんが 12 Things I dislike with Sledge という(数字で始まる Web つーぽいんとおーチックなタイトルで) Sledge の次期バージョンへの要望なんかを書いてます。この中で 10. REST な API や Basic 認証、XML-RPC、Atom などをうまく処理できない と、Sledge における Web API (XML-RPC/AtomPP) のハンドリングについての言及がありました。これからの MVC フレームワークに求められる必要条件の一つとしてこの Web API を処理しやすいかどうかというのは重要な気がします。 フレームワークに Web API 用の API が載っていて、その扱いが容易かつプロトコルの実装を知らなくても使えるようなアーキテクチャになっていると、開発者が Web API を公開するための敷
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
