サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
TGS2024
kazuk-i.hatenadiary.org
先日、弊社CareerLink Vietnamにて、エンジニア職の新規求人を始めました。勤務地はベトナム・ホーチミン市。 東南アジア各国を飛び回るウェブ系エンジニアWanted!! [5/9 03:10 追記] WantedlyのURLが古く応募ができなかったようです。新URLに置き換えました。 日本人にターゲットを絞り、満を持してWantedlyに掲載したのだけれど、応募がない。 個人的には、南国ベトナムで開発に従事するというのは、なかなか魅力的な労働環境だと思うのだけれど、どういうわけか、日本から一向に応募がない。 なぜ応募が振るわないのか、理由を考えてみたが、労働環境に魅力が無いわけではないと思う。ただ、いきなり東南アジア勤務というのが若干ハードルが高く感じられるのかもしれない。 そこで、気を取り直して、現地ベトナムの雰囲気が伝わるよう、採用に関する補足事項等を、本エントリにまとめて
まず、両者はかなり性質の異なるプロダクトなので、以下の比較は筋違い。 筋違いであることを前提に、ストリームデータ処理プラットフォームとしての両者を比べてみる。 基本情報 fluentd http://fluentd.org/ 今をときめくログコレクター/イベントアグリゲーター。Rubyで実装されているが軽量高速。 RPC基盤ではなく、その下のレイヤーに位置するプロダクト。 Storm http://storm-project.net/ 分散RPC基盤。ストリームデータ版MapReduce風フレームワーク。Java+Clojureで実装されている。 概要については、下記のスライドがとてもわかりやすかった。 Twitterのリアルタイム分散処理システム「Storm」入門 ストリームデータ処理で何をするのかについて ストリームデータ処理のニーズについて、自分が理解している範囲での簡単な説明。 典
リポジトリ https://github.com/KazkiMatz/fluent-plugin-uniqcount 概要 fluent-plugin-uniqcountは、指定期間範囲において、設定で指定した属性ごとにイベント発生件数をユニークにカウントし、結果の上位N件を定期出力するfluentdプラグインです。SQLでいうところの: SELECT key1, COUNT(key2) AS key2_count, COUNT(DISTINCT(key2)) AS key2_uniq_count FROM records WHERE time BETWEEN T1 AND T2 GROUP BY key1 ORDER BY key2_count DESC LIMIT 0, N; に相当します。 fluent-plugin-uniqcountを使うと、 直近の60秒で、ユニークアクセスが最
jQueryヘビーなアプリケーションの問題点と、MVCによる構造化の必要性 jQueryは、ブラウザ上で動くJSアプリケーションの開発生産性を劇的に向上させました。DOM操作による動的なページ書き換え処理などは、セレクタを使ってちょろっとコードを書くだけで、ほんの数行で記述できてしまいます。 しかし、この方法の延長で、大規模なJSアプリケーションを構築することは果たして現実的でしょうか。例えば「GMail」や「New Twitter」程度の規模のJSアプリケーションを書かなければならないとしたら、どうでしょう? 大規模なJSアプリケーションを開発するには、こういった手法を延長するのではなく、より洗練されたデザインパターンを導入する必要があります。この目的にぴったりのデザインパターンが、「MVC」デザインパターンです。 MVCパターンは、Webの世界ではサーバサイドプログラミングで広く知られ
[注意:京都市左京区ローカルネタです] 一目見たら一生忘れることのできない異形の廃墟建造物、"メタボ岡崎"に引っ越したので、その魅力を写真でレポートしたいと思います。 夕日に映えるメタボ岡崎。左京区聖護院はとても住みよいところ。 とにかく外見にインパクトがある。 室内。とても窓が多くて開放的ながら、レイアウトがそこはかとなく奇妙である。 写真からはアラが見えにくいかもしれないけれども、外側も内側もボロボロの建物なので、家賃が非常にリーズナブル。 最大の特徴は全室にそれぞれ2つ用意されている出窓。各部屋には3ヶ所出っ張りがあり、そのうち2つが出窓に、残る1つはベランダにアサインされる。下層の部屋と入れ違いになるように割り振られるので、外から見ると凸凹して見える。 メタボ岡崎航空写真。二棟をエレベータ-階段エリアで接続した構成。室内からは、向こう側の棟が谷の向こうにある島の様に見える。 柱の位
VFSのところを担当してきました。 SlideView more presentations from Kazki Matsumoto.
RubyKaigiのLT枠を一つ頂くことができ、Lingoの簡単な紹介をさせてもらいました。 残念ながら時間管理が稚拙で、DEMOの途中で時間切れ>< それでも、Lingoについて色々な人に興味を持ってもらうことができ、懇親会等でお話できるきっかけになり、有難かったです。 使用したスライドは以下です。 Introducing the Lingo projectView more presentations from Kazki Matsumoto.
2009年度下期未踏でやらせていただいたLingoプロジェクト、 どんなソフトウェアなのかを紹介する動画(en)を作りました。 ※音量レベルが妙に小さくなってしまっています・・直す方法が見つかったら再アップロードしようかと思います。 音量レベルを調節し、アップデートしました。
8ヶ月間の未踏期間が終わり、「Lingo」の最終成果報告を行ってきました。 国費で自分のプロジェクトを思う存分にやらせていただくというチャンスをいただけたこと、納税者の皆様に改めて感謝申し上げます。一日も早くLingoを日本のために役立つソフトウェアへと昇華させ、幾らかでも国に還元できればと思っています。 また、手厚いサポートを頂けたこと、採択頂いた勝屋PMはじめ、IPA、管理組織の皆様に深く御礼申し上げます。 今後もLingoの開発にコミットし続け、可及的速やかにベータ版の一般公開を行う所存です。どうぞ温かい目で本プロジェクトを見守っていただければと思います。プロジェクトのステータスについては随時このブログで報告させていただきます。 以下、最終成果報告で使用したスライドです。 ※伝えたい事はスライドに書かず口頭で述べる様にしたので、スライドだけ見ても話の流れが分かりにくいかもしれません。
という題で、RubyKansai勉強会#43で発表させていただきました。 使用したスライドは以下です。 Async Programming on Ruby View more presentations from Kazki Matsumoto. 発表でも紹介しましたが、非同期WebフレームワークであるCrampがすごく使い易い。使い方については以下のチュートリアルが参考になります。 http://m.onkey.org/2010/1/7/introducing-cramp また、非同期Webフレームワーク上から利用するための、ロックしないGearmanクライアントをEventMachine上で実装しています。 http://github.com/KazkiMatz/em-gearman-client ひどく荒削りな状態ですが、お役に立てば。
OctoTiger(虎蛸):動物界軟体動物門哺乳綱八腕形上目ネコ科ヒョウ属に分類される食肉類。OctoCatと姉妹関係にある。イラストは某M下女史寄贈の力作。 新年明けましておめでとうございます(遅)。 私事ですが、昨年11月末でランゲート株式会社CTOの職を辞すことになりました。 退職後は、かねてからの目標である、高度な英文自動校正技術の実用化を成功させるべく、個人プロジェクト「Lingo」を立ち上げ、一人研究室状態で開発を進めていきたいと思っています。 このLingoプロジェクト、運良く2009年の未踏下期で拾っていただけたこともあり、これから本年8月までの半年余り、完全に専念するつもりでいます。プロジェクトの詳細については、追々このblogでもご紹介させていただきますし、DEMOサイトもできるかぎり早期に準備したいと思っています。 以上、簡単な近況報告ですが、たまにこのblogをチェ
という題で、RubyKansai勉強会#39で発表させていただきました。 内容はMapReduceとKVSの関係、および自作のMapReduce処理系であるTinyMapReduceの紹介について。実装にはDRubyを使っています。といってもTinyMapReduceはコードサイズ200行以下で、対障害性もなくサンプルの域を出ないものですが。。 TinyMapReduce標準添付のSampleは、1〜100万までの自然数の中に2の倍数と3の倍数がそれぞれいくつ含まれるかカウントするタスクです(結果保存にSimpleResourceを使っており、別途導入が必要)。Workerの数を増やしていくことで、タスクの実行時間がシームレスに短縮することがわかると思います。 というわけで、使用したスライドを置いておきます。 TinyMapReduce on rubyView more presentat
RDBの復権はしばらくないと思う 最近目にしたのは、「これからRDBが十分速くなっていくので、memcachedに代わってRDBがまた使われるようになる」という意見。これはしばらくの間は無いんじゃないかと思う。全データがオンメモリだったとしても、KVSはRDBより一桁以上速い(Memcachedで100,000req/sec出せるマシンで、MySQLのpkeyによる単純なSELECTをした場合、10,000req/sec出るかどうか)。SQLパーサやらなんやらを捨てない限りこの速さには対抗できない。RDBには、1コネクション1スレッドというモデルが持つ、接続数がスケールしないという制約もある。 また、memcacheプロトコルは、get_multiが使える。get_multiを効果的に活用した場合、RDBとの差はさらに広がると思う。 RDBで大丈夫なアプリも Viewキャッシュが効果的なア
KOFに参加、関西Ruby会議LTで話をさせてもらいました。 使用スライド張っておきます。 SimpleResourceのリポジトリはこちら(↓) http://github.com/KazkiMatz/SimpleResource Lang-8 got updated on SimpleResourceView more presentations from kazuki83.
Twitterがマネタイズするには、自社のマイクロブログサーバを、世界中の企業に販売すればよい - ちょうどMicrosoftがメールサーバのMS Exchange Serverを企業に売りつけているように - という記事がTechCrunchに出ていた。 Twitter Should Decentralize (And Make Money) Via Twitter Server ※追記 上記記事の和訳版が既に公開されていた。→ Twitterはスケールしない―MS Exchangeのように分散化してサーバを売るべきだ 記事ではまず、Twitterは現状「サービスの耐障害性」と「マネタイズ」の二つに問題を抱えており、これを解決するためには、そのアーキテクチャを中央集権型から分散型に移行すべし、と指摘。 We believe decentralizing Twitter solves tw
という題で、RubyKansai#37で発表させていただきました 内容は、WebアプリケーションのDBのスキーマレス化について。 スキーマレスなDBアクセスのための、拙作DBインターフェースライブラリ「SimpleResource」の紹介も合わせて盛り込みました。SimpleResourceは、スキーマレスなデータを保存するためのKVS DBインターフェースライブラリで、Rubyで書かれています。レコード単位のロック機構、インデックス機能等を備えている他、ActiveRecordに近い使い勝手で利用することができます。ストレージには現在MySQLとTokyoTyrantにのみ対応しています。(FriendFeedの同様の試みもかなり参考になりました。詳細はまた後日にエントリで上げたいと思ってます) SimpleResourceは、GitHub上で開発を続けていくつもりです。 http://
K6以来ずっとAMD党だったのだけれど、サーバにCore i7 920を導入しちゃったので、Phenom X4 9350eと比較する形で、簡単にサーバアプリケーション(ていうかLang-8)のベンチマークをとってみました。 Phenom X4と、Core i7は、どちらもQuad Coreなので、コアが4つ入っています。しかしCore i7では、Prescott時代に導入されていたHyperThreading(HT, SMT)が復活しているので、4*2で8スレッドの並列実行が可能になっています。ゲームやオフィスアプリでのCore i7のベンチ結果は随所で見かけるけれども(そしてHTの性能アップ寄与についての結果は大体芳しくない)、マルチスレッドがフルにスケールするサーバ系アプリケーションで、HTの効果がどれほどなのか気になるところ。というわけで、HTをOnにしたとき、Offにしたときの双方
先週末は上京してRubyKaigiに参加してきました。 運よくLT枠をいただくことができたので、タイトルのようなテーマで(結構紆余曲折があって、当初の想定から逸れてしまった...)プレゼンさせてもらうことができました。 話の流れとしては、 「WebアプリケーションのボトルネックはRDB」 ↓ 「RDBってAmazonEC2みたいなHaaSではスケールしないよね。」 ↓ 「本当に(アプリのコードをそのままで)スケールさせようと思ったら、AmazonSimpleDBのようなクラウドDBを使うしかない」 ↓ 「SimpleDBはMySQLより一桁以上遅いから、単純にRDBをSimpleDBに置き換えると、えらいことになる」 ↓ 「SimpleDBへのアクセスを極力少なくするため、リクエストはMemcachedとかでキャッシュしまくる必要があるね」 ↓ 「このあたりを今Lang-8で実験している。
そして、初日のLT枠で発表させていただきました。 しかし僕は日本語でスライド用意してたのに、ほかの人はみんな日本語-英語両記とかだったから焦ったなぁ。会場であわてて英語版を作り直した。。。 せっかく作ったのでスライド資料置いときます。 How to build truly scalable Rails appsView more presentations from kazuki83.
昨日開催されたRubyKansai#34で、発表させてもらいました〜。 使用したスライドは以下のものです。 ActiveResourceが面白すぎる件View more OpenOffice presentations from kazuki83. 初めてSlideShareにupしてみた。 SlideShareってフロントエンドにはRailsを使ってるっぽいかも。。
Googleの中の人たちがLang-8に遊びにきてくれました! 本社のProdcutManagerを中心に、16名程。総勢30名ほどで東アジアツアー(日本、中国、韓国、台湾)をしており、その最中に京都に立ち寄ったとか。 京都市内で二手に分かれて、うち一派がLang-8にきてくれたみたい。お昼前の一時間ほど時間をいただけることになり、Googleの中の人たちにプレゼンという、めったにない機会を得たので、どんな話をしたのか(したかったのか)を少し整理してみようかと。 まずオフィス室内に入ってもらい、熱気漂うサーバ群を眺めてもらう。 「ここでサービスを稼働させています」 GoogleGuys「この部屋、暑い。。。」 続いて共用会議室に移動してプレゼン。 Lang-8は、「誰もが先生になることができる、語学のためのコミュニティサイト」。Lang-8上では主に「書くこと(Writing)」を勉強する
IIR輪講@はてなで、第2章(The term vocabulary and postings lists)を担当してきました。 作成した駄訳とスライド資料を置いときます〜。ご自由に利用いただいてかまわないです。 第2章で登場したアルゴリズムのうち、[postings list intersection via skip pointer]と[positional postings list] について、Rubyで実装してみました(訳文内に載せてあります)。 第2章邦訳(The term vocabulary and postings lists) 発表スライド(OpenOffice Impressフォーマット) 原文はこちら: http://www-csli.stanford.edu/~hinrich/information-retrieval-book.html
デブサミ2009でid:secondlife氏が発表されたという資料を見てみました。 http://www.slideshare.net/hotchpotch/deb2009-1023281 はてぶをフルスクラッチでリニューアルした際に、従来のMVCモデルからさらに一歩進んで抽象化を進めたとのことで。 資料中、MVCの発展系として、MVACなる概念が提唱されているのですが、Aは「Applicaiont」??「アプリケーションレイヤの作成」という記述もあるし、たぶんApplicationのtypoですねきっと。 資料からは「データソース層」「サービス層」「アプリケーション層」の3層が「Model」「View」「Application」「Controller」にどう対応するのかよくわからなかったけど、おそらく「サービス層」を担当するのが「Application」なのでありましょう。 そして、「
前回の話は、一回のエントリーでは書ききれない内容でした。。以下もうすこし詳しく書き直してみます。 Webアプリ開発における「内部APIモデル」とは、ネットワーク越しに外部サイトのWebAPIを呼び出すかのごとく、自サイト内のリソースに対して内部専用のWebAPIでアクセスする仕組みを導入し、分散処理を行うモデルのことです。典型的なWebアプリでは、データベースがここでいうリソースに該当するかと思います。 図にすると以下のようなイメージです。 今回、Lang-8で実際に「内部APIモデル」を導入してみたので、気づきの点などをこのエントリーにまとめてみました。 ※導入のいきさつについては、前回のエントリーで触れています。 「内部APIモデル」を採用するメリット Webアプリ開発において「内部APIモデル」を採用するメリットは2つあります。 (1)言語やフレームワークの選択自由度が上がる 現在運
Rails導入の背景 永らくOpenPNEベースで開発を続けていたLang-8ですが、以下のような課題を抱え続けていました。 生産性が低い → フレームワークの力を借りて生産性を上げたい ページのAjax化に一苦労 → Ajax対応フレームワークでJS周りの開発効率を上げたい デバッグがやりにくい → テスト駆動開発を低コストで導入したい もうそろそろ、何かフレームワークを導入するべきだろうと。 スケールするの? フレームワークを選定する上では、DB周りがスケールするかどうかを最重要視しました。 たとえばRailsのO/RマッパであるActiveRecordは単一DBを前提にしており、スケールさせることが難しいらしい、なんて話を聞きます。メインのDBをActiveRecordで構築しなおすのはいやだなー、と。データ移行の手間もあるし。。。SNSにとってボトルネックは常にDBなので、サイトの
最近じゃmemcachedを活用してデータベース(RDB)の負荷を下げるって話、そこらじゅうから聞こえてくるけれど、memcachedの活用は、格納オブジェクトの”粒度”(granularity)がキモだと思ってます。 memcachedは、KeyとDataをペアで格納して、Keyが与えられると、関連付けられたDataを返すだけのシンプルなシステム。PerlやPHPの連想配列と同じ。このmemcachedをRDBのキャッシュとして活用してやる場合、memcachedに格納するキャッシュデータの単位、”粒度”をどう設計するかが重要になってくる。 RDBの場合、格納されるデータはRow(レコード)単位。じゃぁキャッシュもRow単位で作ってやればいいのかといえば、それではうまくいかないケースもたくさんある。RDBでは専用の問い合わせ言語であるSQLを使って、 SELECT * FROM hoge
Twitterのスケール関係で、面白い記事を発見したのでまとめ。 一時期「スケールしない」とか「動作が不安定」だとか言われ続けていたTwitter。5月ごろにslashdot.jpでも話題になっていた。論調は総じて「Twitterがスケールしないのは、Rubyを使っているから」というもの。 ところが同じ5月、「Why Can't Twitter Scale? Blaine Cook Tries To Explain(なんでTwitterってスケールしないの?)」という、blog紹介記事がSilicon Alley Insiderに掲載される。記事の元になったblogエントリは、Twitterの前チーフアーキテクトだったBlaine Cook氏によるもの。Cook氏によれば、TwitterのスケールとRubyは何の関係もないという。 Why Can't Twitter Scale? Blai
このページを最初にブックマークしてみませんか?
『Tous Les Jours 攻防記』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く