タグ

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

  • Reverse Proxy がなぜ必要か - naoyaのはてなダイアリー

    フロントエンジニアに知ってもらいたいリバースプロキシの重要性 | RickyNews この記事が目に入って読んでみた。なるほど、昨今は Reverse Proxy は便利な L7 ルーター的なものとして認識されているのだな、と思った。URL の Rewrite や、VirtualHost 云々。確かに Reverse Proxy の便利な側面ではある一方、それらは Nginx などの Reverse Proxy でなければ実装が不可能かと言えばそんなことはないものでもある。 自分は Reverse Proxy はもうすこしサーバー/インフラ的な側面でその役割を捉えている。今更何をというものでもあるが、昼休みがてら時間があるので簡単に書いてみよう。 Reverse Proxy はWebシステム全体のリソース最適化のためのパーツ Reverse Proxy のインフラ的な視点での役割は「Web

    Reverse Proxy がなぜ必要か - naoyaのはてなダイアリー
  • インフラの継続的デリバリー - naoyaのはてなダイアリー

    事前に断っておくがここでいう「インフラ」はレイヤ的には OS より上の話。 少し前に GitHub 時代のデプロイ戦略 - naoyaのはてなダイアリー で、GitHub を介したデプロイを実践しているということを紹介した。普段の開発を Pull Request ベースでやっているので、デプロイもまた Pull Request を契機に実行させると色々捗る、という話。 このプラクティスの対象領域をインフラにまで拡大してみました、というのが今回の話。 DNS レコードを Pull Request を merge した契機に自動で更新 AWS を利用している場合、ドメインの管理も Amazon Route 53 を使うといろいろと都合がいい。 Route 53 での DNS レコードの更新はこれまでブラウザから操作していた。これだと誰がいつ作業したかわからないし履歴もトラックしづらい。また変更

    インフラの継続的デリバリー - naoyaのはてなダイアリー
  • 権限委譲、リーダーシップ、チーム - naoyaのはてなダイアリー

    いいか、覚えておけ。おれにしてもお前にしても、それなりに成功するってことは、なにかは得意なんだ。でも大体のことは不得意極まりない。全部自分でやろうとするな。自分よりも何かで優れている人たちが、その何かでお前のためにチカラを貸したいと思うような人間になれ。 それがリーダーってもんだよ。 この記事が話題になってた。リーダーシップというのは力を貸してやろうと相手に思われることだという、いい話。 この手の話は、誰もが否応なしに社会で経験することだから、みんなそれぞれ自分の考えを述べたくなる・・・という話題でもありますね。例に漏れず、自分も少し経験から感じることを書いてみよう。 「権限」を「委譲」する? 「上司が何かを部下に任せる」という文脈でいくと、このストーリーは「権限委譲」の話にもみえる。確かにテーマとしてはそうなのだが、自分は一般で言う「権限を委譲する」という考え方そのものにちょっとした落と

  • 2013-02-07

    いいか、覚えておけ。おれにしてもお前にしても、それなりに成功するってことは、なにかは得意なんだ。でも大体のことは不得意極まりない。全部自分でやろうとするな。自分よりも何かで優れている人たちが、その何かでお前のためにチカラを貸したいと思うような人間になれ。 それがリーダーってもんだよ。 この記事が話題になってた。リーダーシップというのは力を貸してやろうと相手に思われることだという、いい話。 この手の話は、誰もが否応なしに社会で経験することだから、みんなそれぞれ自分の考えを述べたくなる・・・という話題でもありますね。例に漏れず、自分も少し経験から感じることを書いてみよう。 「権限」を「委譲」する? 「上司が何かを部下に任せる」という文脈でいくと、このストーリーは「権限委譲」の話にもみえる。確かにテーマとしてはそうなのだが、自分は一般で言う「権限を委譲する」という考え方そのものにちょっとした落と

    2013-02-07
  • LTSV FAQ - LTSV って何? どういうところが良いの? - naoyaのはてなダイアリー

    LTSV って何? Labeled Tab-Separated Values という、テキストのフォーマットの仕様です。CSV や TSV や JSON そのほかと同じ、テキストデータのフォーマット名。主にログ、特に httpd のアクセスログなどに適用すると便利です。 仕様は http://ltsv.org にまとまっています。随時更新中です。 LTSV は単なるログのフォーマットであって、それ以上でもそれ以下でもありません。 LTSV ってタブ区切りで値に名前を付けただけのもの? はい、そうです。 これが 127.0.0.1 - frank [10/Oct/2000:13:55:36 -0700] "GET /apache_pb.gif HTTP/1.0" 200 2326 "http://www.example.com/start.html" "Mozilla/4.08 [en] (

    LTSV FAQ - LTSV って何? どういうところが良いの? - naoyaのはてなダイアリー
  • LTSVフォーマットなログを fluentd + GrowthForecast で料理 - naoyaのはてなダイアリー

    ここ数年のデータ解析の重要性の高まりから、ログに関するソリューションが方々で活発に探求されている昨今でございます。ウェブサーバーの単純なアクセスログをそのまま保存するではなく追加情報を添加してみたり、あるいはアプリケーションから直接ログを吐いてそれらをデータウェアに投げ込んで・・・というのも当然のように行うようになりましたね。 しかしあまり自由度のない access_log の combined フォーマット。さてどうしたもんか・・・ ここで id:stanaka の登場です。 Labeled Tab Separated Valueというのは、はてなで使っているログフォーマットのことで、広く使われているTSV(Tab Separated Value)フォーマットにラベルを付けて扱い易くしたものです。はてなでは、もう3年以上、このフォーマットでログを残していて、one-linerからflue

    LTSVフォーマットなログを fluentd + GrowthForecast で料理 - naoyaのはてなダイアリー
  • Vagrant - naoyaのはてなダイアリー

    先日 Vagrant を触ってみたら便利すぎて鼻血が出ました。しばらく見ないうちに色々進んでるもんですねえ、いやはや参っちゃいました。 Vagrant は仮想マシンの VirtualBox のフロントエンドに相当する、ruby で書かれたツールです。vagrant コマンドなどを使ってコマンドラインから簡単に新しい VM を作れる。 % gem install vagrant % vagrant box add centos http://developer.nrel.gov/downloads/vagrant-boxes/CentOS-6.3-x86_64-v20130101.box % vagrant init centos % vagrant upこれだけで CentOS の Linux box をローカルマシン内に立ち上げることができる。*1 *2 なにこれすごい。 % vagra

    Vagrant - naoyaのはてなダイアリー
  • 近頃の開発環境 : Mosh、z、tmux、Emacs、Perl について - naoyaのはてなダイアリー

    昨日は年始の挨拶ついでに ELPA について脈絡もなく突然書きましたが、引き続き近頃の開発環境についてもだらだらと書いてみよう。 Mosh mosh というと一部の人間はひげなんとかさんが開発しているモナー的なあれを思い浮かべるかもしれないがそうではなく、mobile shell のことである。 思い切り簡略化して言うと「快適なssh」。回線が不安定な所でもエコー遅延など全く気にせず使えるし、Mac をスリープさせて復帰させたときもリモートホストにそのまま繋がりっぱなしのように見せかけてくれたりする。 詳しくはこの辺を。 mosh: MITからモバイル時代のSSH代替品 - karasuyamatenguの日記 インストールはリモートとローカル両方に必要ですが、まあ大概パッケージがあると思います。EC2 の Amazon Linux でも yum レポジトリの EPEL を有効にすれば y

    近頃の開発環境 : Mosh、z、tmux、Emacs、Perl について - naoyaのはてなダイアリー
  • 実践ハイパフォーマンスMySQL 第2版 - naoyaのはてなダイアリー

    オライリー・ジャパン から実践ハイパフォーマンスMySQL 第2版が発売されました。第2版の出版にあたって、弊社の id:stanaka, id:hideoki と自分の3人で監訳を担当させていただきました。 実践ハイパフォーマンスMySQL 第2版 作者: Baron Schwartz,Peter Zaitsev,Vadim Tkachenko,Jeremy D. Zawodny,Arjen Lentz,Derek J. Balling,伊藤直也(監訳),田中慎司(監訳),吉川英興(監訳),株式会社クイープ出版社/メーカー: オライリージャパン発売日: 2009/12/14メディア: 大型購入: 17人 クリック: 373回この商品を含むブログ (45件) を見る 好評だった初版は確か、自分がはてなに入社した直後ぐらいに読んだ記憶があるのでもう 5 年も前になります。はてなの MySQ

    実践ハイパフォーマンスMySQL 第2版 - naoyaのはてなダイアリー
  • Canonical Huffman Codes - naoyaのはてなダイアリー

    1999年出版と少し古い書籍ですが Managing Gigabytes を読んでいます。理解のために 2.3 で出て来る Canonical Huffman Codes の習作を作りました。 ハフマン符号は情報圧縮で利用される古典的なアルゴリズムで、圧縮対象データに出現するシンボルの出現確率が分かっているときに、その各シンボルに最適な符号長の接頭語符号を求めるものです。 通常のハフマン符号はポインタで結ばれたハフマン木を構築して、ツリーを辿りながら各シンボルに対する接頭語符号を計算します。このハフマン木には曖昧な箇所が残されています。ハフマン木は木の辺を右に辿るか左に辿るかで符号のビットが決まりますが、右が 0 で左が 1 などというのはどちらでも良いという点です。(曖昧だから駄目、という話ではありません。) 従って、ハフマン木から生成される符号は一意には決まりません。 ここで各シンボル

    Canonical Huffman Codes - naoyaのはてなダイアリー
  • Logarithmic merging - naoyaのはてなダイアリー

    IIR の第4章 Dynamic indexing では検索用のインデックスにおいて対象とする文書に頻繁に更新が発生する場合にどうそれを扱うべきかという話題を扱っています。ここで "Logarithmic merging" という話が出てきます。以前に読んだ際に良く理解できなかったので、改めて復習してみました。 Dynamic indexing 頻繁に検索対象の文書群に更新が発生する場合の問題点は、(postings ファイルはディスク上にあるので) 転置インデックスをその都度構築し直すコストが高くなってしまうというところです。かといって更新をしないと、検索結果が古いままでヒットすべきものがヒットしなくなってしまいます。そこで Dynamic indexing の戦略を採ります。ディスク上の大きなインデックスであるメインのインデックスに加えて、インメモリの小さな補助インデックスを用意し、更

    Logarithmic merging - naoyaのはてなダイアリー
  • HITS, 主成分分析, SVD - naoyaのはてなダイアリー

    ウェブグラフのリンク解析によるページの評価と言えば PageRank が著名ですが、もうひとつ Jon Kleinberg による HITS (Hyperlink-induced topic search)も有名です。最初の論文 Authoritative Sources in a Hyperlinked Environment は 1999年です。IIR の 21章で、この PageRank と HITS についての解説がありました。 HITS HITS はウェブページの評価に二つの軸を用います。一つが authority スコア、もう一つが hub スコアです。 例えば「Perl の情報が欲しい」という検索要求に対しては CPAN や 開発者である Larry Wall のホームページなどが重要度の高いページかと思います。これらのページは「Perl に関して信頼できる情報源」ということ

    HITS, 主成分分析, SVD - naoyaのはてなダイアリー
  • Latent Semantic Indexing - naoyaのはてなダイアリー

    情報検索におけるベクトル空間モデルでは、文書をベクトルとみなして線形空間でそれを扱います。この文書ベクトルは、文書に含まれる単語の出現頻度などを成分に取ります。結果、以下のような単語文書行列 (term document matrix) が得られます。 d1 d2 d3 d4 Apple 3 0 0 0 Linux 0 1 0 1 MacOSX 2 0 0 0 Perl 0 1 0 0 Ruby 0 1 0 3 この単語文書行列に対して内積による類似度などの計算を行って、情報要求に適合する文書を探すのがベクトル空間モデルによる検索モデルです。 見ての通り、単語文書行列の次元数は索引語の総数です。文書が増えれば増えるほど次元は増加する傾向にあります。例えば索引語が100万語あって検索対象の文書が 1,000万件あると、100万次元 * 1,000万という大きさの行列を扱うことになりますが、単

    Latent Semantic Indexing - naoyaのはてなダイアリー
  • Wavelet Tree - naoyaのはてなダイアリー

    圧縮全文索引の実装などでしばしば利用される Rank/Select 辞書と呼ばれるデータ構造があります。詳しくは参考文献を参照していただくとして、今回は一般の文字列に対して効率的に Rank/Select を可能とするデータ構造である Wavelet Tree (ウェーブレット木) のライブラリを作りました。 http://github.com/naoya/perl-algorithm-wavelettree/tree/master my $wt = Algorithm::WaveletTree->new("abccbbabca"); is $wt->rank(6, 'a'), 2; is $wt->rank(6, 'b'), 3; is $wt->rank(9, 'b'), 4; is $wt->select(0, 'a'), 0; is $wt->select(1, 'a'), 6;

    Wavelet Tree - naoyaのはてなダイアリー
  • 1