タグ

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

  • Chef Solo の Environments - naoyaのはてなダイアリー

    今年3月に入門Chef Soloを書いた時点では、Chef Solo は Environments の機能をサポートしてなかったため解説は省略しました。 その後、Chef はバージョン 11.6.0 (現在は 11.8.2) で Chef Solo での Environments をサポートし、入門Chef Solo で推薦している knife-solo も 10月末にリリースされた 0.4.0 から Environments をサポートしました。というわけで、現状 Chef と knife-solo が最新版であれば Environments を利用することができます。 たまたま今手をつけている仕事で Environments のことを調べたので備忘録的に記しておきます。 Environments とは Chef の Environments は、例えば development や pr

    Chef Solo の Environments - naoyaのはてなダイアリー
    hirose31
    hirose31 2014/07/10
    Environments
  • 宮川さんPodcast ep6、KDP での本の作り方 - naoyaのはてなダイアリー

    第6回は伊藤直也さん (@naoya_ito) をゲストに迎えて、Kindle 出版、GitHubGoogle Reader などについて話しました。 ほぼ週一くらいで配信されている @miyagawa さんの Podcast、第6回目のゲストで出演しました。第1回目に続き、これで自分は2回目ですね。だんだん往年のいいともみたいになっていくのだろうか。 それはともかく、内容は先日だした Kindle の 入門 Chef Solo に絡めて KDP (Kindle Direct Publishing) の話、それから Google Reader にまつわる RSS の話に関して。二人とも KDP での出版経験があるのと、RSS に関しては昔二人でを書いたりした当時のホットな話題でお互い良く知ってるしというので、面白く話せました。 Chef が実際 KDP でどのくらいダウンロードされて

    宮川さんPodcast ep6、KDP での本の作り方 - naoyaのはてなダイアリー
    hirose31
    hirose31 2013/03/21
  • 退職 - naoyaのはてなダイアリー

    グリー株式会社を退職しました。昨日が最終出社日でした。 最終日の昨日はちょうど四半期の〆の日ということもあって、開発部全体での納会 (飲み会) の中で盛大に送り出していただきました。いただいた花束が自分の身長の半分もあろうかというくらい大きさで、徒歩で帰宅途中、通行人にまじまじと見られるという、なかなか得難い経験をさせていただきました。 在職期間は一年半とちょっとと短かったのですが、その中でもたくさんのことを経験することができました。iOS / Android のスマートフォン版の立ち上げに始まり、SNSの開発、直近では US に出張したりしつつグローバル化の推進ですとか。何より、入社当時3名だったチームを一年半で 50人強まで拡大させる中、その人事権をまるごと任せてもらえたのは大きかったです。一緒にやっているメンバーには、自分の試行錯誤で振り回してたくさん迷惑をかけました、ごめんなさい

    退職 - naoyaのはてなダイアリー
  • 退職のお知らせ - naoyaのはてなダイアリー

    日8月31日をもって、はてな退職しました。 入社は2004年9月1日でしたから、今日でちょうど6年です。6年間の間に、はてなブックマークをはじめとする各種サービスの企画開発やディレクション、インフラの構築、技術チームのマネジメント等々、色々な経験を積むことができました。その一方で、なかなか自分の思うようにはサービスを成長させる、会社を伸ばすことができず自分の力量不足を感じる毎日でもありました。その足りない能力と経験を埋め合わせる日々が、成長を促してくれたとは思います。 この6年は、はてなという会社が、個人あるいは家族のような繋がりから組織に変っていく過程でした。会社というものが何なのかを全然知らなかった自分が、Webサービスの開発と運営に、組織がなぜ必要かというのを体で知ることになりました。なかなかに得難い経験でした。 遠回りもありましたが、はてなは組織になりました。新サービスは日々ユ

    退職のお知らせ - naoyaのはてなダイアリー
    hirose31
    hirose31 2010/08/31
    ウホw
  • YAPC::Asia 2日目 「はてなブックマークのシステムについて」 - naoyaのはてなダイアリー

    2日目の発表も終えました。資料を公開します。 はてなブックマークのシステムについてView more presentations from Naoya Ito. 今日も少し駆け足気味でした。YACP::Asia 2009、今年も楽しかったです。Hackathon 出ずに京都に戻らなければならなかったのが悔やまれます。 発表の様子 撮影: id:hirose31

    YAPC::Asia 2日目 「はてなブックマークのシステムについて」 - naoyaのはてなダイアリー
    hirose31
    hirose31 2009/09/12
    会期中いちばんいいかんじに撮れた一枚
  • Aho Corasick 法 - naoyaのはてなダイアリー

    適当な単語群を含む辞書があったとします。「京都の高倉二条に美味しいつけ麺のお店がある」*1という文章が入力として与えられたとき、この文章中に含まれる辞書中のキーワードを抽出したい、ということがあります。例えば辞書に「京都」「高倉二条」「つけ麺」「店」という単語が含まれていた場合には、これらの単語(と出現位置)が入力に対しての出力になります。 この類の処理は、任意の開始位置から部分一致する辞書中のキーワードをすべて取り出す処理、ということで「共通接頭辞検索 (Common Prefix Search)」などと呼ばれるそうです。形態素解析Wikipediaはてなキーワードのキーワードリンク処理などが代表的な応用例です。 Aho Corasick 法 任意のテキストから辞書に含まれるキーワードをすべて抽出するという処理の実現方法は色々とあります。Aho Corasick 法はその方法のひと

    Aho Corasick 法 - naoyaのはてなダイアリー
    hirose31
    hirose31 2009/04/06
    打倒「ごはんですよ」ときいて
  • 贈りもの - naoyaのはてなダイアリー

    『サーバー/インフラを支える技術』を一緒に書いた id:hirose31 さんからはてなブックマークリニューアルの贈り物が届きました。 微妙に見えていますが、箱を開けてみると... 自分の大好物のカルボナーラでしたwww ちょうどおなかが空いた頃合いなので今からべます。ありがとうございます! ブックマークリニューアル状況 リニューアルの方は不具合修正とパフォーマンス調整を中心に作業を進めて行ってます。しばらくは品質向上に注力していく予定です。特にサーバーサイドのパフォーマンスが十分でないので、最優先で取り組んでいます。至らないところも色々ありご迷惑をおかけしております。 落ち着いて来た頃にでも裏話的なことをお話したいなと思っています。

    贈りもの - naoyaのはてなダイアリー
    hirose31
    hirose31 2008/11/27
    つまらないものですがッ!どぞッ!!
  • Shibuya.pm#10 を京都でも - naoyaのはてなダイアリー

    そこで「Shibuya Perl Mongersテクニカルトーク#10 京都サテライト会場」として、弊社・はてなの京都オフィスは、関西在住のPerl Mongersのみなさんや、技術的な話に興味のある方々が集ってshibuya.pmを楽しむ会場を提供いたします。 10回目を迎えた Shibuya.pm のテクニカルトーク。毎度のことながら人気のイベントですのであっという間に埋まってしまったそうです。 この Shibuya.pm は東京で開催ですが遠方の参加もなんとかしよう、サテライト会場を設置して楽しもう、ということになりました。京都は弊社スタッフの id:antipop が中心になって弊社オフィスをサテライト会場として開放することに。京都近郊のみなさま、11/27 ははてなの京都オフィス越しに Shibuya.pm に参加してみるのはいかがでしょう? なお、Shibuya.pm は名前こ

    Shibuya.pm#10 を京都でも - naoyaのはてなダイアリー
    hirose31
    hirose31 2008/11/20
  • naoyaのはてなダイアリー - カレーを作りました

    なんだか無性にカレーいたくてしょうがない日々が続いたので、昨日は夜にカレーを作りました。餃子とカレーとハンバーグは自分で作るのが一番うまい。餃子とハンバーグは知らないけど、カレーはどんな店より実家のカレーが一番だっていう人が世の男性諸君の8割以上を占めるそうです。(電通調べ。うそ。) ということで10家庭あったら10の作り方があると言われる中から、伊藤家のカレーの作り方です。といっても僕のカレーはそんなに特別なことはしてないです。 たまねぎをたくさん入れる たまねぎはみじん切りにしてトロトロになるまで火を通す。たまねぎは入ってることが分からないぐらいまでするのが伊藤家流 具は個別に炒める (にんじんと肉だけ一緒) 最後に牛乳を少し入れる ぐらいかな。多分伊藤家風の味つけにするコツはたまねぎだと思います。 たまねぎをたくさん入れて、 と、あめ色になるまで火を通す。ほんとはもっとあめ色にな

    naoyaのはてなダイアリー - カレーを作りました
  • サーバ/インフラ Tech Meeting の資料など - naoyaのはてなダイアリー

    金曜日は サーバー/インフラを支える技術出版記念イベント サーバ/インフラ Tech Meeting の日でした。自分は「Linuxカーネルの読み方」と題して、自分なりにまとめたカーネルのソースコードを読むコツについてお話させていただきました。 発表資料を以下にアップロードしました。 http://bloghackers.net/~naoya/ppt/08080924svr_techmeeting.ppt (ppt) http://www.slideshare.net/naoya1977/how-to-read-linux-kernel/ (Slide Share) 同じく著者のひろせさんからはなぜこのを書いたか、どういうなのかという概論 (One more thing もありました)。Klab の安井さんは DSAS について、特に「ダイナミック」をキーワードにした幾つかのインフラ構

    サーバ/インフラ Tech Meeting の資料など - naoyaのはてなダイアリー
  • サーバー/インフラを支える技術 - naoyaのはてなダイアリー

    『サーバ/インフラを支える技術』という書籍を執筆しました。明日 8/7 に発売です。 [24時間365日] サーバ/インフラを支える技術 ?スケーラビリティ、ハイパフォーマンス、省力運用 (WEB+DB PRESS plusシリーズ) 作者: 安井真伸,横川和哉,ひろせまさあき,伊藤直也,田中慎司,勝見祐己出版社/メーカー: 技術評論社発売日: 2008/08/07メディア: 単行(ソフトカバー)購入: 133人 クリック: 2,270回この商品を含むブログ (288件) を見る 書名にもあります通り、インターネットサービスのサーバ/インフラ周りについての書籍で、Klab さんのエンジニアの方々と一緒に書きました。ただし、サーバーと言っても少し特殊で、如何にコストをかけずに堅牢なサーバー環境を作るかというのが書籍に一貫している姿勢です。 Linux、LVS、DRBD、Squid、Nag

    サーバー/インフラを支える技術 - naoyaのはてなダイアリー
  • はてなブックマークの関連エントリー機能開発、PFI さんとの合宿 - naoyaのはてなダイアリー

    はてなブックマークに関連エントリーを配信する機能を追加しました。詳しくは 告知日記で。 この関連エントリーは、株式会社プリファードインフラストラクチャー (以下 PFI) の技術者のみなさんと一緒に開発しました。週末に2泊3日で京都で合宿をしてコア部分を作り、その後京都と東京に分かれてオンラインで連絡を取りながら2週間ほど作り込みをして、今日リリースです。 この合宿では何チームかに分かれて、今回の関連エントリーの機能以外の開発も行っています。その辺の成果はまた後日にリリースできるのではないかと思います。 はてなブックマークの一つの問題として、昔のエントリーがデータベースに埋もれてしまうという点がありました。その問題の解決策としての類似記事抽出、それから検索機能の強化を以前から考えていました。PFI のメンバーのみなさんは情報検索技術のスペシャリストです。アカデミックな研究の成果を製品化を通

    はてなブックマークの関連エントリー機能開発、PFI さんとの合宿 - naoyaのはてなダイアリー
  • Linux のプロセスが Copy on Write で共有しているメモリのサイズを調べる

    Linux は fork で子プロセスを作成した場合、親の仮想メモリ空間の内容を子へコピーする必要があります。しかしまともに全空間をコピーしていたのでは fork のコストが高くなってしまいますし、子が親と同じようなプロセスとして動作し続ける場合は、内容の重複したページが多数できてしまい、効率がよくありません。 そこで、Linux の仮想メモリは、メモリ空間を舐めてコピーするのではなく、はじめは親子でメモリ領域を共有しておいて、書き込みがあった時点で、その書き込みのあったページだけを親子で個別に持つという仕組みでこの問題を回避します。Copy-On-Write (CoW) と呼ばれる戦略です。共有メモリページは、親子それぞれの仮想メモリ空間を同一の物理メモリにマッピングすることで実現されます。より詳しくは コピーオンライト - Wikipedia などを参照してください。 この CoW に

    Linux のプロセスが Copy on Write で共有しているメモリのサイズを調べる
    hirose31
    hirose31 2008/02/25
    <プロセスのメモリ空間中の CoW で共有されている領域がどの程度あるかを計測する方法> RSS BSS top
  • マルチスレッドのコンテキスト切り替えに伴うコスト - naoyaのはてなダイアリー

    また Linux カーネルの話です。 Linux では fork によるマルチプロセスと、pthread によるマルチスレッドでの並行処理を比較した場合、後者の方がコストが低く高速と言われます。「スレッドはメモリ空間を共有するので、マルチプロセスとは異なりコンテキストスイッチ時にメモリ空間の切り替えを省略できる。切り替えに伴うオーバーヘッドが少ない。」というのが FAQ の答えかと思います。 が「オーバーヘッドが少ない」と一言にいわれても具体的にどういうことなのかがイメージできません。そこで Linux のスレッド周りの実装を見て見ようじゃないか、というのが今回のテーマです。 3分でわかる(?) マルチプロセスとマルチスレッド まずはうんちく。マルチプロセスとマルチスレッドの違いの図。以前に社内で勉強会をしたときに作った資料にちょうど良いのがあったので掲載します。Pthreadsプログラミ

    マルチスレッドのコンテキスト切り替えに伴うコスト - naoyaのはてなダイアリー
  • ithreads でスレッドプール - naoyaのはてなダイアリー

    マルチスレッドなサーバー実装を色々模索していて、Perlithreads で遊ぶ。ithreads は Linux の pthread にリンクさせた perl なら一応 NPTL で動いてくれるので、pthread アプリケーションの設計を試すのにも良い。 試しににやってみたのは、たとえば mod_perl とかで重い SQL でブロックするのが嫌なときとかにそれを別プロセスに丸投げしてやる、その丸投げされる側のサーバー実装。(やりたいことだけに関して言うと、TheSchwartz に似てる) クライアントとサーバーの IPC は UNIX ドメインソケット メッセージングのプロトコルは JSON サーバーはクライアントからのリクエストをバッファリングしたら、SQL を実行する前にクライアントとの接続を切断 この時点でクライアントは制御が戻る サーバーは内部ではフロントエンド /

    ithreads でスレッドプール - naoyaのはてなダイアリー
    hirose31
    hirose31 2007/09/05
    pthreadとの違い:・ブロック抜けるとunlock・cond_signalの前にlockするのが推奨/詳しくないすけど、MT safeとか心配かも?
  • さくらインターネット移行記#4 はてなダイアリー移転 - naoyaのはてなダイアリー

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

    さくらインターネット移行記#4 はてなダイアリー移転 - naoyaのはてなダイアリー
    hirose31
    hirose31 2007/06/27
    おつかれさまでしたー [焼肉食べたい]
  • Linux I/O のお話 write 編 - naoyaのはてなダイアリー

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

    Linux I/O のお話 write 編 - naoyaのはてなダイアリー
    hirose31
    hirose31 2007/05/24
    感動巨編 read write ページキャッシュ pdflush sync あとで書く
  • naoyaのはてなダイアリー - Linuxのページキャッシュ

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

    naoyaのはてなダイアリー - Linuxのページキャッシュ
    hirose31
    hirose31 2007/05/22
    ページキャッシュといえばpdflushが最大で8こ立ち上がる理由/意図がわからない中。スピンドルごとには独立してブロックされずにflushできるから、ま、何個があげとっかなーぐらいの雰囲気なのかしらん。
  • マルチコア時代のロードアベレージの見方 - naoyaのはてなダイアリー

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

    マルチコア時代のロードアベレージの見方 - naoyaのはてなダイアリー
    hirose31
    hirose31 2007/05/19
    load average lav なる >4CPU ならロードアベレージ 4.00 まで OK というのは鵜呑みにはできなそう
  • 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のはてなダイアリー
    hirose31
    hirose31 2007/05/11