開発メモ: オリジナル英単語帳を作って語彙学習を効率化するツール
自分がまだ習得していない語に絞った英単語帳を作成して、効率的に語彙力を強化することができるツールを作ってみた。難易度別の英単語が次々に表示されるので、意味を確認しつつ、苦手なものにマークをつけて行く。マークをつけたもの一覧を印刷すれば、あなたの苦手な語に絞った英単語帳のできあがり。 背景 英語で書かれた新聞や雑誌やWebサイトを読みこなすために、最低限覚えておかなければならない語彙の水準がある。上級者は毎日それらのコンテンツを読むことで語彙の維持と強化ができるのだが、中級者以下だとそうはいかない。楽しく英文を読めるという段階にまだ達していない我々は、単語集を使って最低限の語彙セットを身につける作業と、実力に見合った英文を読む作業を並行して行なっていくのが一般的だろう。 単語集を使うと必要な語彙を網羅的に記憶していけるが、それだけだと様々な文脈に合わせた実際の使い方を習得することができない。
開発メモ: Kindleで快適に英和辞書（英辞郎）を使うための手順
Kindleで洋書を読みたいが、俺は英語があんまり得意でないので、デフォルトの英英辞書だとちょっとつらい。そこで、英辞郎を使えるようにしてみた。その方法をメモしておく。 背景 先日サンタさんからKindle Touchを貰った。ちっこくて可愛いし、文字も見やすいし、お気に入りのデバイスである。英語が苦手な俺も、文中の知らない単語をタッチするだけで意味がわかるから難しめの洋書もスラスラ読めちゃう。…はずだったが、付録の英英辞書は辛すぎる。仮に "explosion" がわからないとして、辞書を引いてみると、"a violent and destuctive shattering or blowing apart of something, as is caused by a bomb." という説明が出てくる。これを読んで「爆発」ってことだなと理解するのには1分くらいかかりそうだ。もちろんそ
開発メモ: Kyoto Tycoonによる高可用性DBサーバの構築
Tokyo Tyrantで実装していた非同期レプリケーションをKyoto Tycoonでも実装したので、高効率かつ高可用性を備えるデータベースサーバとして使えるようになったよという話。 高可用性の実現に向けて ハードウェア障害をはじめとする予期せぬ事態が起きても正常にサービスを運用し続けられる能力のことを高可用性（high availability）と呼ぶ。Tokyo Tyrantの記事で薀蓄を書いたのでそちらをご覧いただきたい。要は、ホットバックアップと更新ログとレプリケーションを使うと、大規模Webサービスの負荷にも耐えられる高可用性のデータベース運用ができるようになるということ。 KTの開発当初はプロクシを使ったレプリケーションを計画していたのだが、更新ログが重すぎるので分離したいニーズよりも、まずは普通に1対1の非同期レプリケーションをしたいというニーズの方が多いと判断して、TTと
開発メモ: KVSとシグナル機構でジョブキューを実現する
いわゆるkey-value storeを使っている際に、レコードの挿入もしくは更新を検知して即座に何らかの処理を行いたくなることはないだろうか。俺はあんまりないけど、結構そういう質問が来るので、きっと巷にはそういう要求があるのだろう。Kyoto Cabinetでそれを実現してみた。 ジョブキュー もうちょい具体的な例を挙げると、ジョブキューである。ここで、「foo」という名前のタスクを考えてみる。読み出し側（ワーカ）は、適当な名前をつけた条件変数を常に監視していて、そこにシグナルが飛んできたら即座にレコードを取得して処理を行いたい。しかし、「一定の間隔毎にレコードの検索を繰返して発見したら処理を行う」というポーリングスタイルにはしたくない。操作にどうしてもタイムラグが出るし、ポーリングのための無駄なトラフィックが発生するからだ。 シグナル待機処理と該当レコードの取得処理を行う擬似コードは以
開発メモ: ハッシュDB上の並列イテレータ
技術ブログ英語版をFAL Labsサイトの直下に移した。つか、英語の記事が全然読まれないので、日本語でも書く。 MapReduceを含むKyoto Cabinetのイテレータ群はシングルスレッドだということを、ioremap.netの中の人が嘆いていたのを私は見つけた。それは真実であり、私はその話題が非常に面白いと思う。私はハッシュデータベースの並列イテレータについて二つのモデルを考えた。 背景 マルチスレッドによる並列イテレータは、イテレータを異なるレコードに分散させるためのインデックスを必要とする。各イテレータの仕事量を平準化するには、イテレータの飛び先を各々ができるだけ離れるように設定するべきである。残念ながら、Kyoto Cabinetはそのようなユースケースのために設計されておらず、そういったインデックスは存在しない。しかしながら、ハッシュテーブルのバケット配列をインデックスの代
新卒で就職したSEを辞めたい？５つの辛い理由と辞める決断を下す前に考えたい注意点 ｜ fallabs tech
「新卒で就職したSEを辞めたい…でも本当に辞めていいのか、今後の社会人人生、キャリアに影響はないのか心配。」 こんな疑問、悩みに答えます。 本記事では「新卒で就職したSEを辞めたいと考えている新卒SE」に向けて、以下の内容・目的で記事を書いていきます。 本記事で分かること 新卒で就職したSEを辞めたいと感じる理由 新卒SEの仕事を辞める決断を下す前に考えたい注意点 仕事を辞めたい時に取るべき適切な対処法とおすすめの転職先 新卒で就職したSEを辞めたい時、どうすればいいのか？ 辞めたい気持ちは高まっても、具体的なアクションがわからないと、先へは進めませんよね。 現職のSEを辞めるにしても、今の会社に留まって別のキャリアを模索するにしても、やるべき対処法は決まっています。 本記事では、新卒で就職したSEを辞めたい理由と辞める決断を下す前に考えたい注意点や適切な対処法について詳しく解説していきま
開発メモ: アラインメント問題とDebianパッケージ化
考察 考察ってほどでもないが、個人的に興味深いと思う点を挙げておこう。第一に、少なくともi386だと、推奨アラインメントと構造体の最小オフセットが異なるということだ。オブジェクトのサイズと推奨アラインメントが同じになるのは直感的に理解できる（そうでないと配列がうまく扱えないから）が、構造体の中にメンバを配置する際には、推奨アラインメントよりも低いアラインメントでオブジェクトを詰めて配置することがあるということだ。つまり、i386では、8バイト幅であるlong longのオブジェクトを4の倍数のアドレスに配置しても正常に評価ができるということだ。理由はよくわからんが、メモリ使用量の節約のためとか後方互換性のためとかそんなところなのだろう。 第二に興味深いのは、i386だと、long doubleのサイズが12バイトで推奨アラインメントが4だということだ。doubleの推奨アラインメントは8な
開発メモ: Kyoto Cabinetのロック機構の改善
Kyoto CabinetはIO負荷が高い場合にCPU負荷も高くなりがちだという指摘を受けて、それを解決すべくロック機構を見直したという話。 スロットロック ハッシュテーブルの操作はハッシュバケット毎に完全に独立して実行できるのが強みだ。ハッシュテーブルは計算量が有利なだけでなく、並列性にも優れるということ。実際には下層のファイルIOで実装依存の排他制御が行われることになるが、ハッシュ層だけ見れば理想的な並列性を備えている。ただし、同じバケットに連なるレコード群の操作は互いに依存関係があるので、それらは一括して排他制御してやる必要がある。となると、バケット毎にロックを用意するのが理想だが、実際にはメモリを節約するために、予め決めた数のロックを用意して、ここのロックに複数のバケットを割り当てる構成をとる。リソース空間をスロットに分けるというイメージから、これをスロットロックと呼ぼう。 スロッ
生活メモ: 就職することにした
長らくニートだったが、就職先が決まったということで、代官山のレストランで妻と娘にお祝いしてもらった。うれしい。そして、新しい道に踏み出すという新鮮な気持ちが何とも心地よい。 2011年2月1日付けで、Googleに入社する。その経緯について記述しておく。個人的事情をわざわざ晒す必要もないのだが、お世話になっている皆様やOSS関連や個人事業関連で関わりのある方々への報告ということでキーを叩く。 経緯 昨年7月末に前職を辞して、自作のOSS製品のデュアルライセンス販売で食っていくべく開発作業や事務作業を半年ほど行ってきた。しかし、地価と物価の高い東京という都市に妻子とともに暮らせる収入を継続して得ていくにはあまりにも頼りないビジネスモデルであるため、それを本業にすることは断念した。 より正確に言えば、当初からOSSで食っていけるとは思っていなかったので、ライセンス販売は妻に任せて俺は就職できる
開発メモ: DBサーバのnoreplyオプションによる高速化
Kyoto Tycoonやmemcachedにてnoreplyオプションを使ってパフォーマンスを上げる話。 noreplyの功罪 DBに対する更新操作はその成否を真偽値などとして呼出側に返すのが通常であるが、それを省略することでパフォーマンスを上げることができる。memcachedではnoreplyオプションとして知られている。KTの最新版からは、memcachedプラグインと独自バイナリプロトコルでもnoreplyオプションをサポートすることにした。 noreplyを有効にするとなぜ高速化するのか。クライアントはクエリをsendしただけで、recvをせずに次の処理に移れるからだ。sendシステムコールに渡したデータはカーネルが非同期に処理するので、カーネルとアプリケーションは並列に処理を進めることができる。recvをした場合にはその時点で両者の待ち合わせが発生してしまうのだが、それをしな
開発メモ: スレーブエージェントによるKTからMySQL等へのレプリケーション
Kyoto TycoonからRDBMS等の他製品に対してレプリケーションを行う方法について述べる。 カスタマイズ機能群の最後のパーツ 以下のイラストのように、Kyoto Tycoonには、カスタマイズ性を高めるための様々な機能が実装されている。 HTTPの既存プロトコル上で任意のデータベース操作処理を実現するための「スクリプト言語拡張」。ユーザ定義の任意のプロトコルで任意のデータベース操作処理を実現するための「プラガブルサーバ」。既存のデータベース操作指示に対して任意の処理を行うための「プラガブルデータベース」。これら3つの機能を使えば、KTのほぼ全ての機能の振る舞いをユーザ定義のものに差し替えることができる。かなり究極的なカスタマイズ性を既に備えていると言える。 今回加わったのは、KTの外部の別システムとKTを連携させるための機能である。KTで更新ログを有効にすると、KTのデータベースに
開発メモ: Kyoto Tycoon普及大作戦
手前味噌だが、Kyoto CabinetおよびKyoto Tycoonは、かなりいけてるソフトウェアに仕上がっている。されど、いまいち普及していないのが現状である。よって、今後は普及活動を本格化させる。 まずはKyoto Tycoonを普及させたい。Web屋さんがみんな大好きなmemcachedのユースケースをほぼ100%カバーしていて、機能性や空間効率でのアドバンテージを提供できるので、お勧めしやすい。memcachedプロトコルのプラガブルサーバを使えば、ユーザの既存のWebアプリケーションに一切手を加えることなく、KTをインストールしてサーバを再起動するだけで乗り換えが済む。非常にわかりやすい筋書きだ。 memcachedを置き換えるだけでなく、ファイルDBによる永続化によって新たな価値を提供することができる。さらに、レプリケーションなどのHA機能群によって、その価値を補強することが
開発メモ: memcachedプロトコルをKTにプラグインする
高効率キャッシュサーバ兼データベースサーバであるKyoto Tycoonのネットワーク通信機構をプラグインで切り替えられるようにして、memcachedプロトコルにも対応したというお話。 プラガブルサーバ Apacheは、様々なモジュールを後付けのプラグインで組み込むことで、非常に柔軟に機能追加を行えるようになっている。MySQLもストレージエンジンをプラグインで切り替えられるようになっていて、非常に柔軟なソリューションが提供できるようになっている。そのようなプラグインできるモジュールをプラガブルモジュールと呼ぶことにしよう。 同じように、KTでもストレージエンジン（DBM層）をプラガブルモジュールにする予定ではあるが、今回はストレージエンジンの話ではない。逆に、ネットワーク層をプラガブルモジュールにしてしまうのだ。そうすると、任意のプロトコルでデータベースを操作できるようになる。 DBM
開発メモ: memcachedとKyoto Tycoonの空間効率
Kyoto CabinetおよびKyoto Tycoonに新たに導入された「StashDB」を使うとmemcachedよりも空間効率を向上させられるという話。 StashDBとは 前回の記事で説明したように、Kyoto CabinetではローカルMapReduceのキャッシュとしてTinyHashMapというクラスを実装して省メモリ化を図っている。丁寧にシリアライズしてデータを詰めていくとかなりメモリを節約できるものなのだ。 同じ構造をDBMのインターフェイスにしたのがStashDBである。ProtoHashDB, ProtoTreeDB, CacheDB, GrassDB, HashDB, TreeDB, DirDB, ForestDBに続く第9番目のDBMということになる。もちろん、マルチスレッドセーフにして、レコード単位の粒度でロックを施して一貫性を確保し、VisitorやCurso
開発メモ: ローカルMapReduceの性能
Kyoto CabinetにMapReduceを実装したという話は前回書いたが、そのLuaバインディングでもMapReduceをサポートした。また、Kyoto Tycoonとそのスクリプト言語拡張でもMapReduceをサポートした。今回はその性能について解説する。 ローカルMapReduceのツボ 世に言うMapReduceは分散処理のフレームワークだけれども、KC/KTの「ローカルMapReduce」は分散処理を行わない。分散処理をしなかったらデータ処理能力が上がらないじゃないかと思うかもしれないけれども、そうとも限らないのだ。前回も書いたけども、MapReduceフレームワーク部分をうまく実装すると、時間効率と空間効率の双方を向上させることができる。特にキャッシュとソートの部分に工夫がある。 MapReduceは、リポジトリ内（KCではデータベースファイル内）の各レコードからキーと値
開発メモ: トップNソートの検討
上位N件をソートした状態で取り出すという、いわゆる「トップNソート」の効率的な実装について検討してみた。 背景 データベースに対して、ある順序でソートした時の最初の何件かが欲しいというクエリを投げることはよくあるだろう。SNSで言えば、誰かのコンテンツの最新10件を表示するとかいう場合だ。SQLだと "ORDER BY xxx LIMIT yyy" とかいう感じ。同じような操作は全文検索システムのスコアリングでも定番である。俺もよく自分で実装するわけだが、その度に適当な試行錯誤をして時間がもったいないので、今回は入念に調べて決定版を出そうじゃないか。 全体をソートして上位を取り出せば目的は満たせるのだが、それだと無駄な計算が多い。100万件の中から上位10件だけ欲しい場合に、残りの99万9990件まで律儀にソートする必要はない。ということで、上位N件をソートして取り出すという「トップNソー
Technical Memo: Memory Saving Associative Array by Kyoto Cabinet and MessagePack
Kyoto Cabinet features on-memory database which can be used as associative array of strings. MessagePack is a binary-based efficient object serialization library. Combination of the two provides you associative array to contain generic objects. Space Efficiency of Kyoto Cabinet Let's suppose that we should manage 1 million simple records whose key and value are 10 bytes strings. The following is a
開発メモ: オンメモリB+木による省メモリ連想配列
Kyoto Cabinet 1.2.2から加わったGrassDBは、オンメモリでページ管理を行うB+木を実装してメモリを節約しちゃう仕組みである。それを使ってJava、Python、Ruby、Perlなどのハッシュ（連想配列）機構を鬼のように省メモリにしてみる。頑張ればなんと20分の1になる。 前提 B木やその変種のB+木などは、キーの順序が近いレコード群を「ページ」という単位にまとめてシリアライズしてストレージに書き込むことで、入出力の頻度を減らして高速化することを意図している。メモリに比べて低速なストレージの上で大量のデータを管理するために使われる。多くのRDBMSやいくつかのDBMがB+木をサポートしているのはそれが理由であろう。一方で、メモリ上で検索可能なデータ構造を表現するためには、二分探索木やその特殊例である赤黒木が使われる。STLのstd::mapの実装にも赤黒木を使うのが一
開発メモ: 50行のC++コードでWebサーバを実装する
「Kyoto Tycoonの設計 その四」改め、50行でWebサーバを書く方法を解説する。前回実装した「多重I/Oマルチスレッド汎用TCPサーバ」の上にHTTPの処理を行う層をつけて、「多重I/Oマルチスレッド汎用HTTPサーバ」を司るクラスを実装してみたので、それを使ってちょちょいとやる。 URLクラス HTTPと言えばURLが使えないと意味がない。URLは単なる文字列として扱ってもよいのだが、様々なシーンで分解や加工が必要になり、その処理はなにげに複雑で面倒なので、予めクラスとして導出しておいた方がよいだろう。 class URL { public: // 文字列のURLを解析して内部構造を作る void set_expression(const std::string& expr); // スキーム要素を設定する void set_scheme(const std::string&
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
開発メモ: 各種ロックのベンチマークその弐