タグ

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

  • エンジニアにとって良い組織とは何かを知りたい? - naoyaのはてなダイアリー

    エンジニアにとって良い組織体制ってどんなものですか? お話を伺いたいのですが・・・」と依頼をいただくことがあるが、都合上全部を受けてはいられない。ので、そういう疑問を持たれた方は以下のを読むと良いかと思います。 How Google Works (ハウ・グーグル・ワークス) ―私たちの働き方とマネジメントposted with amazlet at 14.10.18エリック・シュミット ジョナサン・ローゼンバーグ アラン・イーグル 日経済新聞出版社 売り上げランキング: 19 Amazon.co.jpで詳細を見る 小さなチーム、大きな仕事〔完全版〕: 37シグナルズ成功の法則posted with amazlet at 14.10.18ジェイソン・フリード デイヴィッド・ハイネマイヤー・ハンソン 早川書房 売り上げランキング: 7,579 Amazon.co.jpで詳細を見る Tea

    エンジニアにとって良い組織とは何かを知りたい? - naoyaのはてなダイアリー
    bongkura
    bongkura 2014/10/22
  • 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のはてなダイアリー
    bongkura
    bongkura 2014/08/26
  • Sqwiggle が良いという話、またはリモートでアジャイル開発をどう進めるか - naoyaのはてなダイアリー

    KAIZEN platform Inc. は、新しい働き方をいろいろ試してみようという会社でそのひとつにリモートワークがある。リモートワークの良さあるいは良くないところについては、以前に Rebuild.fm の ep.32 でも話した。 ちかごろは、オンラインミーティングのための道具、情報共有のための道具もクラウドサービスがたくさんあるので、その辺を使って工夫すれば一昔前に比べてだいぶリモートワークも現実的になってきている。実際、KAIZEN には大阪からリモートワークしている人とか、最近リモートワークを前提に都内から鎌倉に引っ越したメンバーなんかもいる。 リモートワークアジャイル開発 HipChat、Google Hangout や Qiita Team なんかを使うことで、日常の会話、ミーティングや情報共有についてはもともと特に困ったこともあまりなかった。特に Qiita Team

    Sqwiggle が良いという話、またはリモートでアジャイル開発をどう進めるか - naoyaのはてなダイアリー
    bongkura
    bongkura 2014/06/01
  • Aho Corasick 法 - naoyaのはてなダイアリー

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

    Aho Corasick 法 - naoyaのはてなダイアリー
  • 「Web開発者のための大規模サービス技術入門」という本を書きました - naoyaのはてなダイアリー

    自分が作ったWebサービス、将来大きくなってもシステムは大丈夫なんだろうか? そんな不安を抱きながらWebサービス開発に携わっている方も多いでしょう。あるいは、毎日毎日システムが悲鳴を上げる、どうしたらこの状況を看破できるんだろう? 成長したWebサービスを前に、困っている技術者の方もいるかもしれません。 筆者も、まったく同じ経験をしてきました。 月間1,500万人が訪れる、はてなというサイト。その大規模システムの開発と運用に、筆者らは取り組んでいます。1,000台のホストが、その負荷を捌きます。100万人以上のユーザによってブログやソーシャルブックマークに投稿され続けるデータは日々大きくなっていき、サーバリソースを逼迫させます。ギガバイト、テラバイト単位のデータ量が技術者たちを悩ませます。それでもトラフィックの波は収まることを知りません。 (中略) どうしたらこの怪物、大規模サービスを抑

    「Web開発者のための大規模サービス技術入門」という本を書きました - naoyaのはてなダイアリー
  • 第11回 Kansai.pm / スペルミス修正プログラムを作ろう - naoyaのはてなダイアリー

    昨日は第11回 Kansai.pm でした。 今回は無理を言って自分がホストを担当させていただきましたが、面白い発表が多く開催した自分も非常に満足でした。 PFI の吉田さんによる Cell Challenge での計算機に合わせたアルゴリズムのチューニング手法の発表 (発表資料) は圧巻でした。伊奈さんの文抽出の話 (発表資料)、はこべさんのコルーチンの話 (発表資料)、いずれも難解になりがちなところを凄く分かりやすく解説されていて、さすがだなと思いました。各々ショートトークも、いずれも良かったです。 スペルミス修正プログラムを作ろう 自分も 20 分ほど時間をいただいて、スペルミス修正プログラムの作り方について発表しました。 スペルミス修正プログラムを作ろうView more presentations from Naoya Ito. スペルミス修正プログラムについてはずばり スペル

    第11回 Kansai.pm / スペルミス修正プログラムを作ろう - naoyaのはてなダイアリー
  • MapReduce - naoyaのはてなダイアリー

    "MapReduce" は Google のバックエンドで利用されている並列計算システムです。検索エンジンのインデックス作成をはじめとする、大規模な入力データに対するバッチ処理を想定して作られたシステムです。 MapReduce の面白いところは、map() と reduce() という二つの関数の組み合わせを定義するだけで、大規模データに対する様々な計算問題を解決することができる点です。 MapReduce の計算モデル map() にはその計算問題のデータとしての key-value ペアが次々に渡ってきます。map() では key-value 値のペアを異なる複数の key-value ペアに変換します。reduce() には、map() で作った key-value ペアを同一の key で束ねたものが順番に渡ってきます。その key-values ペアを任意の形式に変換すること

    MapReduce - naoyaのはてなダイアリー
  • B木 - naoyaのはてなダイアリー

    昨年から続いているアルゴリズムイントロダクション輪講も、早いもので次は18章です。18章のテーマはB木(B Tree, Bツリー) です。B木はマルチウェイ平衡木(多分木による平衡木)で、データベースやファイルシステムなどでも良く使われる重要なデータ構造です。B木は一つの木の頂点にぶら下がる枝の数の下限と上限を設けた上、常に平衡木であることを制約としたデータ構造になります。 輪講の予習がてら、B木を Python で実装してみました。ソースコードを最後に掲載します。以下は B木に関する考察です。 B木がなぜ重要なのか B木が重要なのは、B木(の変種であるB+木*1など)が二次記憶装置上で効率良く操作できるように設計されたデータ構造だからです。データベースを利用するウェブアプリケーションなど、二次記憶(ハードディスク)上の大量のデータを扱うソフトウェアを運用した経験がある方なら、いかにディ

    B木 - naoyaのはてなダイアリー
  • さくらインターネット移行記#5 久しぶりの移転作業

    だいぶ間が空いてしまいましたが、久しぶりのデータセンター移行記です。 アンテナ、カウンター、検索を移転 完全移行もぼちぼちゴールが見えて来た今日この頃ですが、先日もサーバーの移行作業を行いました。はてなアンテナの巡回システム周り一式、はてなカウンター、はてな検索などをまとめて移行しました。今回の移行も深夜作業。夜の 2:00 に集合して作業開始です。上の写真は僕のメンテナンス時の作業着です。 サーバールームからサーバーを運び出します。台車が大活躍です。 ぎっしりサーバーが詰まっていた旧サーバールームも、だいぶ閑散としてきました。まだ 70 台近くのサーバーが残っていますが、開発機などを除くと残り 40 台程度になりました。年内には全部移行できるのではないかと思います。 アンテナやカウンターともなるとはてなの中では古いサービスなので、使っているハードも古い。移転にあたって古いサーバーはハード

    さくらインターネット移行記#5 久しぶりの移転作業
  • Web::Scraper - naoyaのはてなダイアリー

    Today I've been thinking about what to talk in YAPC::EU (and OSCON if they're short of Perl talks, I'm not sure), and came up with a few hours of hacking with web-content scraping module using Domain Specific Languages. 使ってみたよ! #!/usr/local/bin/perl use strict; use warnings; use FindBin::libs; use URI; use Web::Scraper; use Encode; use List::MoreUtils qw/uniq/; my $links = scraper { process 'a.key

    Web::Scraper - naoyaのはてなダイアリー
  • 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のはてなダイアリー - 負荷とは何か
  • Apache 2.2.0 + mod_proxy_balancer - naoyaのはてなダイアリー

    Apache 2.2.0 がついにリリースされまして、かねてから期待されていた mod_proxy_balancer が安定版で使えるようになりました。mod_proxy_balancer はその名のとおり Apache でロードバランスするための proxy モジュールです。詳しい解説は yappo さんがしてくれてるのでそちらを。 実は mod_proxy_balancer 使ってみるかーと思って Apache 2.2.0 をインストールしようとしたらいきなり躓きました。APR 1.2.0 が入ってないから駄目だよ! と configure に叱られまして、でも APR 1.2.0 って Apache 2.2.0 インストールしないと入らなくね? みたいな矛盾が発生しました。なので、まず最初に srclib にある APR をコンパイル & インストールして、その後 Apache2 の

    Apache 2.2.0 + mod_proxy_balancer - naoyaのはてなダイアリー
  • 1