タグ

ブックマーク / naoya-2.hatenadiary.org (69)

  • はてなブックマークの作り直しについて - naoyaのはてなダイアリー

    id:naoya:20080320:1206009912 でも少し触れましたが、京都に来てからはてなブックマークの作り直しをしています。どういう意図を持って作り直そうとしているかを述べておきます。 まず大前提として、今のはてなブックマークに追加したい機能、変更したい仕様、来追加するはずが途中で頓挫したものが結構な数で山積みになっています。それを実現するための基礎作りです。 追加したい機能、変更したい箇所 おそらく新システムの最初のリリース時には、それほど大きく変わった、という印象にはならないかと思います。長く続いているサービスですし、インタフェースや使い方もリリース当初からそれほど大きくは変わっていません。既存システムからの極端な変更は歓迎されないだろうと思っており、まずはオリジナルが持っていた機能をしっかり再現することが重要です。 ただし、既存システムでも問題と思っている箇所は改善して

    はてなブックマークの作り直しについて - naoyaのはてなダイアリー
  • Google を支える技術 - naoyaのはてなダイアリー

    Google を支える技術 を読みました。 Google のバックエンドで動いている各種分散処理システムに関しては Google 自身から論文がいくつも発表されています。それらの論文をはじめとする比較的最近の情報ソースをベースに、ある程度かみ砕いて要所要所を紹介するという内容でした。加えて著者の西田圭介さんは OpenCobol (COBOL を C 言語に変換しコンパイルする gcc のフロントエンド) を開発された、技術的なバックグラウンドがしっかりしている方であるようで、内容は信頼できると思います。 自分はこれまで Google のバックエンドの各種ソフトウェアについては方々で耳にしていましたが、漠然と何をするものか程度のことしか知りませんでした。 Web 検索の基的な仕組みと それにまつわる Google が直面した問題、特に大規模処理 それを支えるために開発された各種ソフトウェ

    Google を支える技術 - naoyaのはてなダイアリー
  • ソフトウェア技術者としての残り時間 - naoyaのはてなダイアリー

    年始の NHK でのイチロー特集番組を見ていて一番印象に残ったのは、他の人の道具を絶対に触らないというイチローのこだわりでした。曰く、人の道具を触るとその道具の感覚が体に残ってしまい、自分の道具を利用するときの感覚の妨げになるから、ということでした。全体を通して、イチローは他のプレイヤーとの相対的な競争の中に身を置いているのではなく、絶えず自分を改良し続けるという過程の中にいるのだというのがよくわかる内容でした。良い番組だったと思います。 気づけば自分も 30 歳になりました。まだ若いとは思っていますが、さすがに 20 代の頃に比べると、病気や怪我の治りが少し遅くなったと感じることもあり、少しずつ自分の人生、「死」ということを考えるようにもなりました。時間は有限ということが少しずつ実感できるようになってきました。あるいは実感できるようになってしまった、と言った方が良いかもしれません。 ここ

    ソフトウェア技術者としての残り時間 - naoyaのはてなダイアリー
  • Perl でローカルのアドレスを取得する - naoyaのはてなダイアリー

    ifconfigの出力をsedでパース — ありえるえりあ まだ Linux を触り始めて間もない頃に、サーバーを構築していてローカルの IP アドレスをシェルスクリプトから利用する必要があって、どうやって取得するべきだろうかと小一時間悩んだのですが結局分からず Perl の正規表現で ifconfig を parse したことがありました。ioctl() を使ってデバイスを操作する必要がある、ということを知ったのは数年後、割と最近のことです。なんということでしょう。 では、Perl で IP アドレスを取得する場合ですがモジュールを使ってよいのであれば IO::Interface がよいだろうと思っています。IO::Interface は Pure Perl ではありませんが、XS で ioctl() を呼び出しているので比較的高速且つ素直な実装だと思います。 #!/usr/local/

    Perl でローカルのアドレスを取得する - naoyaのはてなダイアリー
  • フィボナッチ数列を計算するデバイスドライバ - naoyaのはてなダイアリー

    Amazon から プログラミング言語Erlang入門 が届きました。 どんな構成だろうね、と会社で同僚数人とわいわいやっていたら、「フィボナッチ数列を計算するサーバー」という例があって、みんなのツボに入りました。Erlang の並列計算処理能力とネットワークプログラミングのしやすさを示すという上で良い例だと思うのですが、「フィボナッチ数列を計算する」というのと「ネットワークサーバーを書く」、という二つのテーマの不思議なギャップが面白いのでしょう。 そういえば関数型言語が得意な id:maoe は、はてなの採用面接の際に、はてなのボーナス計算を計算するシステムを作ってきたのですが、なぜかクライアント/サーバシステム、ネットワークサーバーを Haskell で、クライアントを Scheme で書き、プロトコルが S 式という実装をみんなの前で披露して、周囲の笑いを誘っていました。 ちょっとし

    フィボナッチ数列を計算するデバイスドライバ - naoyaのはてなダイアリー
  • inetd の仕組みを見てみる - naoyaのはてなダイアリー

    inetd や xinetd (以下 inetd) はインターネットサービスをデーモン化するのに共通している処理を担い、ほとんどの時間をアイドル状態で過ごすその手のサービスに必要なリソースを節約する役割を果たします。 inetd のひとつ面白いところは、inetd でサービス化したいプログラムの標準入力/標準出力がクライアントソケットの入出力に接続されるところです。例えば daytime 相当のサービスを自分で作ろうと思った場合 #!/usr/local/bin/perl # daytime.pl use strict; use warnings; use DateTime; use IO::Handle; STDOUT->autoflush(1); STDOUT->printf( "%s\n", DateTime->now(time_zone => 'Asia/Tokyo') ); と標

    inetd の仕組みを見てみる - naoyaのはてなダイアリー
  • さくらインターネット移行記#4 はてなダイアリー移転 - naoyaのはてなダイアリー

    いきなり失礼しました。はてなのインフラチームの打ち上げは渋谷で焼肉と相場が決まっています。これは前回の打ち上げで行った焼肉屋での一枚。明後日にははてなダイアリーデータセンター移転打ち上げを開く予定です。 ...ということで、昨日ようやく、はてなダイアリーをさくらインターネットのデータセンターへ移転しました。恒例の写真で振り返る移転レポート、はてなダイアリー移転編です。 今回の移転は深夜に行いました。0:00 に会社に集合。移転にあたって一ヶ月くらいかけて準備をしてきたので慌てることもなく、サービス停止時間の 2:00 までわりとマターリ進行でした。僕は id:hideoki と PSP でモンハンしてました。 これは ENERMAX LIBERTY 電源。最近はてなの自作サーバーで愛用している電源です。はてなダイアリーの移転にあたり動いているサーバーを止められるチャンスだったので、これを期

    さくらインターネット移行記#4 はてなダイアリー移転 - naoyaのはてなダイアリー
  • Linux I/O のお話 write 編 - naoyaのはてなダイアリー

    write はページに dirty フラグを立てるだけなので決してユーザープロセスを待たせない って、当にそうなんでしょうか?(否定しているわけではなく、純粋な疑問です。) と質問をもらったので、最近追ったことをここでまとめます。かなり長文です、すいません。また、まだまだ不勉強なので間違っているところもあるかもしれません。ツッコミ大歓迎です。 まず、オライリーのカーネルの 15章 ページキャッシュ 15.3 汚れたページのディスクへの書き込み から引用。 ご存知のように、カーネルは、ブロック型デバイスのデータを含むページをページキャッシュに蓄えています。プロセスが何らかのデータを更新した場合は、必ず対応するページに汚れている印をつけます。すなわち、PG_dirty フラグを設定します。 UNIX システムでは、汚れたページのブロック型デバイスへの書き込みを遅延することができます。この方

    Linux I/O のお話 write 編 - naoyaのはてなダイアリー
  • naoyaのはてなダイアリー - Linuxのページキャッシュ

    世間では PHP が、Perl が、と盛り上がっているようですが空気を読まずまたカーネルの話です。今回はページキャッシュについて。 /dev/shm に参照系DBを持っていくと I/O 負荷が激減した件(当たり前だけど) - drk7jp で、ディスク上にあったファイルを /dev/shm (tmpfs) に移したら I/O 待ちがなくなって負荷がさがった、ということなんですがおそらくこれは tmpfs に置く必要はないかなと思います。Linux (に限らず他の OS もそうですが) にはディスクの内容を一度読んだらそれはカーネルがキャッシュして、二度目以降はメモリから読む機構 = ページキャッシュがあります。tmpfs にデータを載せることができた、ということは物理メモリの容量に収まるだけのデータサイズかと思うので、放っておけば該当のファイルの内容すべてがメモリ上にキャッシュされて io

    naoyaのはてなダイアリー - Linuxのページキャッシュ
  • *NIX初心者だったあの頃 - naoyaのはてなダイアリー

    ログインした。twm。ウィンドウを閉じようとしてもアイコンになる。途方に暮れる。 Emacs というのを使うと日語が打てるらしいと聞いた。日本語入力への切り替え方法がわからない。立ち上げた Emacs を終了できない。 Cannna というのを使えば日語が打てるらしい。apt-get install。他のパッケージのインストールが始まり混乱に陥る。 Emacs 使ってるって言ってたのに mule って書いてるよ? cat /var/log/messages | moer → command not found: moer apt-get install 中に Yes or No の質問をたくさんされる。よくわからないけど全部 yes にする。何が起こったかわからない。知らない振り。 X-Window のグレーバックの壁紙。解像度が適切に設定されてないせいでにじんでいる。設定方法がわから

    *NIX初心者だったあの頃 - naoyaのはてなダイアリー
    agw
    agw 2007/05/20
  • マルチコア時代のロードアベレージの見方 - naoyaのはてなダイアリー

    ちょっと煽り気味のタイトルですが、CPU がマルチコアになり 2個、4個と増えていく中 Linux の負荷の指針になるロードアベレージをどう読むべきか、という話です。気になったところを少し調べたのでそのまとめを。 http://d.hatena.ne.jp/naoya/20070222/1172116665 でも書いたとおり、Linux のロードアベレージは「ロードアベレージは過去1分、5分、15分の間の実行待ちプロセス数の平均数 = 実行したくても他のプロセスが実行中で実行できないプロセスが平均で何個ぐらい存在してるか」を示す値です。ボトルネックが CPU、メモリ、ディスク等々どこにあるかは関係なく、仕事の実行までにどれぐらい待たされているかを示す値なので、システムのスループットを計測する指標の入り口になる値です。 このロードアベレージですが、実装を見るとランキュー(待ち行列)に溜まった

    マルチコア時代のロードアベレージの見方 - naoyaのはてなダイアリー
    agw
    agw 2007/05/19
  • Perl and UNIX Network Programming (YAPC::Asia 2007) - naoyaのはてなダイアリー

    YAPC::Asia で Perl UNIX ネットワークプログラミングについての発表をしてきました。UNIX ネットワークプログラミングの基礎の概論、I/O多重化の話、Perl のモダンなネットワークライブラリの話です。資料を以下に置いておきます。 http://bloghackers.net/~naoya/ppt/070404Perl_and_UNIX_Network_Programming.ppt (ppt, 122k) なお、会場では口頭で触れましたが、資料中のソースは簡単のためエラー処理を飛ばしています。また、途中で出てくる図は例えば vfs のページキャッシュをはしょってあったりとこれも簡単のため省略事項がある点にご注意ください。 それからフォントが Consolas なので Consolas が入ってない環境だと変になる、かも。

    Perl and UNIX Network Programming (YAPC::Asia 2007) - naoyaのはてなダイアリー
  • WEB DB PRESS vol.38 - naoyaのはてなダイアリー

    WEB+DB PRESS Vol.38 の見誌が届きました。連載も今回で7回目。今回は POE の話の後編です。複数の HTTP サーバーに非同期で同時アクセスするクライアントプログラムを POE::Component::* に頼らずつくり、その後 POE::Component を紹介しつつ IRC bot を作る、という内容になってます。先日の前編の vol.37、それから先日の YAPC::Asia の資料とあわせてお読みいただけると理解が深まるかなと思います。 今月号は新連載が色々始まってたりして関心が高いわけですが、断固guy 小飼弾さん (http://blog.livedoor.jp/dankogai/) の Alpha Geek に逢いたいのゲストがIT戦記の id:amachang とあの"はまちちゃん"で、はまちちゃんの写真が載っていました。はまちちゃんの顔が見たい人は

    WEB DB PRESS vol.38 - naoyaのはてなダイアリー
  • naoyaのはてなダイアリー - さくらインターネット移行記#3 はてなブックマーク移転

    さて、移行記も #3 となりました。今回は先日作業を終えたはてなブックマークの移転について。 旧サーバールームからさくらインターネットのiDCへのサーバー移転作業にもだいぶ慣れて来たこのごろ。これまでは比較的はてな内の他サービスとの連携が疎になっていたり、負荷がそこまで高くないものであったりと移行しやすいものから持っていってましたが、そろそろ難しいところ手を付ける時期に来まして、はてなブックマークの移転です。 以前に書いた はてなブックマークの裏側その後 - naoyaのはてなダイアリー では 2006年10月時点で ユーザー: 60,000 人 ブックマーク数: 787万件 サーバー: 30台 となっていました。移転したこのごろはというと ユーザー: 80,000 人 ブックマーク数: 1,182万件 サーバー: 移転前約45台 (移転後 約25台) という具合になっていました。順調に伸

    naoyaのはてなダイアリー - さくらインターネット移行記#3 はてなブックマーク移転
    agw
    agw 2007/03/30
  • prefork サーバーと thundering herd 問題 - naoyaのはてなダイアリー

    Catalyst を POE で動かす Engine の Catalyst::Engine::HTTP::POE という実装が CPAN にあります。"Single-threaded multi-tasking Catalyst engine " だそうです。"Single-threaded" と言いつつも実装を覗いてみると環境変数 CATALYST_POE_MAX_PROC を 1 よりも大きく設定することで prefork する実装になってます。POEシングルスレッドではアプリケーション内で発生するブロックを避けることが難しいのでそのための実装じゃないかなと思います。 ところでこの Catalyst POE エンジン、prefork の実装はどのように行っているかというと POE から prefork と名の付いたイベントが発生するとおもむろに子プロセスを生成する、というのもの。複数の

    prefork サーバーと thundering herd 問題 - naoyaのはてなダイアリー
  • さくらインターネット移行記#2 VPN越しのMySQLレプリケーション

    前回さくらiDCに移転し始めた、ということを書いたのですが、あれから一ヶ月ちょっとが経過しましてその後も順調に iDC への移転が進んでいます。すでにラックもいくつか借りて、サーバーも数十台がさくら iDC で稼動しています。回線がこれまでよりも高速なバックボーンに接続されつつ、帯域幅も大きくなったことから、移転したサービスによってはこれまでよりもパフォーマンスが出ているサービスもあります。うち比較的大きなデータを扱うフォトライフも移転を完了していますが、おかげさまで画像の読み出しがかなり速くなったのが体感できるぐらいスループットが向上しました。 既存サービスを移転するにあたって、どういった構成でそれを行っているかをちょっと紹介してみようと思います。 移転当初は、既存のはてなのサービスとはあまり関係していないサーバー群から手を付けました。例えば広告のシステムといった、はてなのデータベースを

    さくらインターネット移行記#2 VPN越しのMySQLレプリケーション
  • naoyaのはてなダイアリー - Perlでモダンなネットワークサーバーを書くには

    Comet については、普及するかどうかという以前に、どう使えばいいのか、正しく使った場合に何をどこまでできるのか、という理解が共有されていないように思います。なので、(あくまで私見ですが) 使用したスライドの一部を公開したいと思います。よろしければごらんください。 サイボウズラボの奥さんによる Comet のサーバー周りの資料。すばらしい。C10K に対してどのようなアーキテクチャをとるのが良いかとの考察が特に勉強になりました。 また、問題や改善すべき点があれば、教えていただければ幸いです。 というので問題、改善すべきというわけではないですが Perl 周りの話で少し補足を。 資料中の「初心者へのオススメが PoCo::Server::HTTP でパフォーマンスが欲しい人には Sys::Syscall qw/:epoll/」の点。おそらく Perl でも epoll を使えますよというこ

    naoyaのはてなダイアリー - Perlでモダンなネットワークサーバーを書くには
  • naoyaのはてなダイアリー - 負荷とは何か

    調べごとをしたので blog に書いて理解を深めようのコーナーです。長文です。 Linux でシステム負荷を見る場合にお世話になるのが top や sar (sysstat パッケージに同梱されてるコマンド) などのツールです。 top ではシステム統計のスナップショットを見ることができます。今システムがどういう状態かなーというときは top が便利。 top - 08:16:54 up 3 days, 14:43, 6 users, load average: 0.18, 0.07, 0.03 Tasks: 43 total, 2 running, 41 sleeping, 0 stopped, 0 zombie Cpu(s): 18.2% us, 0.0% sy, 0.0% ni, 81.8% id, 0.0% wa, 0.0% hi, 0.0% si一方の sar では10分ごとのシ

    naoyaのはてなダイアリー - 負荷とは何か
  • DarwiinRemote でプレゼン - naoyaのはてなダイアリー

    そうそう、昨日のライブドアでのセミナーは ma.la と僕のプレゼンの二立てだったんだけれども、その ma.la が Wii コントローラをリモコン代わりにプレゼンを操作してました。 DarwiinRemote (名前がイカス) を使って早速の Hack。 http://blog.hiroaki.jp/2006/12/000433.html 人も特にその点にも触れてなかったし、後ろの方からだと気づきづらかったと思うのですが、昨日の面白トピックということで。 Wii コントローラは単体で買えて4,000円くらいだそうなので、普通のプレゼン用デバイス買うより安いしかっこいいんでない? なんて話をしてました。 Wiiリモコン メディア: Video Game購入: 2人 クリック: 138回この商品を含むブログ (68件) を見る

    DarwiinRemote でプレゼン - naoyaのはてなダイアリー
  • naoyaのはてなダイアリー - coLinux 上の Emacs の kill-ring の内容をWindowsのクリップボードと同期する by Perl

    Emacs を Meadow をやめて coLinux 上のものを PuTTY 経由で使うようにしたんですが、Emacs で killing にいれたものを Windows でペーストしたい、と思ったときに Meadow ですんなりできたそれができずにちょっとストレスになってました。そんな折、 http://d.hatena.ne.jp/odz/20061125/1164433815 http://d.hatena.ne.jp/odz/20061125/1164437987 Great Job! こういうのを Hack っていうんでしょうなあ。しかし、Python ! ここはいっちょ Perl で。 まず Windows 側に立てるサーバーを実装する。 ActivePerl + ppm で POE と PoCo::Server::IKC がすんなり入ったのでこれを使う。 クリップボードへの

    naoyaのはてなダイアリー - coLinux 上の Emacs の kill-ring の内容をWindowsのクリップボードと同期する by Perl
    agw
    agw 2006/11/26