開発メモ: オリジナル英単語帳を作って語彙学習を効率化するツール
自分がまだ習得していない語に絞った英単語帳を作成して、効率的に語彙力を強化することができるツールを作ってみた。難易度別の英単語が次々に表示されるので、意味を確認しつつ、苦手なものにマークをつけて行く。マークをつけたもの一覧を印刷すれば、あなたの苦手な語に絞った英単語帳のできあがり。 背景 英語で書かれた新聞や雑誌やWebサイトを読みこなすために、最低限覚えておかなければならない語彙の水準がある。上級者は毎日それらのコンテンツを読むことで語彙の維持と強化ができるのだが、中級者以下だとそうはいかない。楽しく英文を読めるという段階にまだ達していない我々は、単語集を使って最低限の語彙セットを身につける作業と、実力に見合った英文を読む作業を並行して行なっていくのが一般的だろう。 単語集を使うと必要な語彙を網羅的に記憶していけるが、それだけだと様々な文脈に合わせた実際の使い方を習得することができない。
開発メモ: EngHelper version 0.5
ここ数ヶ月間コツコツ作ってきた辞書ユーティリティを集大成して、EngHelperというオープンソース製品として公開した。Web上の英和辞書と任意のWebコンテンツに和訳ルビを振るシステムを連動させる。辞書の作成手順も大幅に簡略化した。プログラムのインストール方法や使い方については以下のプロジェクトページを作ったので、そちらをご覧いただきたい。 http://fallabs.com/enghelper/ ---- 使い勝手 和訳ルビ振りシステムに関しては、多分、TOEIC600点から900点くらいの人には嬉しいシステムになっていると思う。600点以下の読解力の人は単語の意味だけわかっても複雑な英文を読むことができないので、先に単語集をやった方がいいだろう。一方で、900点以上の読解力の人にとっての難解語はルビの和訳で理解できるものではなく、個別に辞書を引いた方がいいということになる。そんなわ
開発メモ: ディレクトリデータベースの設計その壱
Kyoto Cabinetでファイルシステムのディレクトリ内に個別のファイルとしてレコードを格納するデータベースを実装したらどうなるだろうという検討をしてみた。 ディレクトリDBとは 全てのレコードを1ファイルに収めるのがKCやTCの「ファイルハッシュDB」である。ファイルハッシュDBは大きくても数KB以下の小さなレコード群を効率的に管理するための仕組みであるため、レコード毎のフットプリント（レコードメタデータ）ができるだけ小さくなるように工夫している。典型的なユースケースとして64バイト以下くらいの小さいレコードを大量に扱うことを想定している。例えばWebサイトのタイムスタンプやその他のセッションデータなどである。 TCやKCだけでなく多くのDBM実装が小さいレコードに最適化されているわけだが、その理由はなんだろうか。レコードがでかい場合は、DBMを使わずにファイルシステムを使えばよいか
開発メモ: Kindleで快適に英和辞書（英辞郎）を使うための手順
Kindleで洋書を読みたいが、俺は英語があんまり得意でないので、デフォルトの英英辞書だとちょっとつらい。そこで、英辞郎を使えるようにしてみた。その方法をメモしておく。 背景 先日サンタさんからKindle Touchを貰った。ちっこくて可愛いし、文字も見やすいし、お気に入りのデバイスである。英語が苦手な俺も、文中の知らない単語をタッチするだけで意味がわかるから難しめの洋書もスラスラ読めちゃう。…はずだったが、付録の英英辞書は辛すぎる。仮に "explosion" がわからないとして、辞書を引いてみると、"a violent and destuctive shattering or blowing apart of something, as is caused by a bomb." という説明が出てくる。これを読んで「爆発」ってことだなと理解するのには1分くらいかかりそうだ。もちろんそ
開発メモ: Wikipedia日本語版で英辞郎を鍛える
Wikipedia日本語版をMeCabで解析して作った頻度DBで、英辞郎の説明文を並び替えることでポップアップ辞書への最適化をさらに推進してみた。 背景 Kindleで使える英和辞書を作っている。元ネタとしては英辞郎を利用し、収録語の選別をCOCAとWikipedia英語版から作ったN-gram頻度DBで行い、WordNetで品詞を補完したところで、かなり実用性の高い辞書ができた。とはいえ、人間の欲は限りなく、使い込むほどに改善点が浮んでくるものである。 一つの語が複数の意味を持っている場合、一般的によく使われる順に並んでいてほしい。ポップアップ表示した際の表示文字数は限られているため、最初の方に特殊な用法が並べられると、そのビューでは意味が把握できない。ポップアップの中にある「show full description」ボタンを押せば全部の意味を見ることができるが、そこに時間をかけではポ
開発メモ: Kyoto TycoonでテーブルDBを実現する
Kyoto Tycoonで、RDBMSのテーブルのように複数のコラムを持ったレコードを扱ったり、特定のコラムを対象にセカンダリインデックスを張ったりすることもできるという話。 テーブルDB Tokyo CabinetおよびTokyo Tyrantでは、テーブルDBという実装があった。最も率直なKVS（永続化連想配列）の実装としてお馴染みのTC/TTではあるが、valueに構造を持たせることによってマルチコラムを実現し、さらに更新処理にフックをかけてセカンダリインデックスを自動的に管理できるようにもしていた。結果として、「ドキュメント指向DB」とか「スキーマレスDB」とかいったような、ゆるふわな感じの用途で便利に使えるツールになっていると思う。 しかし、KyotoシリーズではテーブルDBは実装しない方針である。多機能すぎてメンテが大変だからだ。アプリケーション寄りの機能を提供するということは
開発メモ: GPL + 特定OSSライブラリのリンク例外
「真のオープンソース」祭りの中、自分のOSS製品のライセンスについて探る日々である。GPLリンク例外の実運用について真面目に考えているので、ご意見をいただけると幸い。 GPL製品と非コピーレフトOSS製品の混用 IT企業に所属している開発者などがOSS開発を行う場合には、GPLでなく、修正BSDライセンスやApache 2.0ライセンスなどの非コピーレフトなオープンソースライセンスを選択することが多い。その方が自社のプロプライエタリ製品に組み込んで配布するのに都合がいいからだ。 一方、我がKyoto CabinetのライセンスはGPLなので、プロプライエタリ製品に組み込んで配布することはできない（配布はできないだけで、サービス内で使うことはできる）。OSSな方々には自由にお使いいただき、プロプラな方々には商用ライセンスをお買い上げいただくというモデルである。 さて、OSS開発者からすらも結
開発メモ: KVSとシグナル機構でジョブキューを実現する
いわゆるkey-value storeを使っている際に、レコードの挿入もしくは更新を検知して即座に何らかの処理を行いたくなることはないだろうか。俺はあんまりないけど、結構そういう質問が来るので、きっと巷にはそういう要求があるのだろう。Kyoto Cabinetでそれを実現してみた。 ジョブキュー もうちょい具体的な例を挙げると、ジョブキューである。ここで、「foo」という名前のタスクを考えてみる。読み出し側（ワーカ）は、適当な名前をつけた条件変数を常に監視していて、そこにシグナルが飛んできたら即座にレコードを取得して処理を行いたい。しかし、「一定の間隔毎にレコードの検索を繰返して発見したら処理を行う」というポーリングスタイルにはしたくない。操作にどうしてもタイムラグが出るし、ポーリングのための無駄なトラフィックが発生するからだ。 シグナル待機処理と該当レコードの取得処理を行う擬似コードは以
開発メモ: トップNソートの検討
上位N件をソートした状態で取り出すという、いわゆる「トップNソート」の効率的な実装について検討してみた。 背景 データベースに対して、ある順序でソートした時の最初の何件かが欲しいというクエリを投げることはよくあるだろう。SNSで言えば、誰かのコンテンツの最新10件を表示するとかいう場合だ。SQLだと "ORDER BY xxx LIMIT yyy" とかいう感じ。同じような操作は全文検索システムのスコアリングでも定番である。俺もよく自分で実装するわけだが、その度に適当な試行錯誤をして時間がもったいないので、今回は入念に調べて決定版を出そうじゃないか。 全体をソートして上位を取り出せば目的は満たせるのだが、それだと無駄な計算が多い。100万件の中から上位10件だけ欲しい場合に、残りの99万9990件まで律儀にソートする必要はない。ということで、上位N件をソートして取り出すという「トップNソー
開発メモ: 「OSSライセンス例外」の考察
Kyoto CabinetはGPLv3と商用ライセンスのデュアルライセンスにして、プロプラな製品に組み込む際にはお金をいただくという事業をやっていこうと思っている。 GPLv3を採用したことで、プロプラ製品によるフリーライドを抑止する力が働くのは好都合なのだが、一方でどんどんフリーライドしてほしい他のOSS製品に対しても同様の抑止力が働いてしまうことがあり、ちょっと勿体ないなと思っている。 他のOSS製品にもっと気軽にKCを採用してもらいたい。具体的には、ネットワーク越しにアクセスする「データベースサーバ」的な製品に、もっとKCを採用してもらいたい。もっと具体的に言えば、kumofsとかROMAとかflareとかその他何たらクラウドとかに採用してもらえるようにしたい。それにあたって、ライセンス上のハードルを取り除きたい。 そこで、「OSS製品とKCをリンクする場合において、その製品をGPL
開発メモ: Kyoto Tycoon + Luaスクリプティング拡張 = 最強
Kyoto Tycoon 0.8.1をリリースした。データベースサーバ上でスクリプト言語Luaを動かす「スクリプティング拡張」機能を搭載している。 TT+Luaの問題点 Tokyo TyrantにもLuaを搭載していた。Lua言語の処理系は、組み込み演算子と組み込み型と標準ライブラリのいずれもが貧弱だという欠点はあるが、非常に高速に動作するという利点がある。複数の処理系インスタンスを使えばネイティブスレッドとの親和性も高い。機能的な貧弱さはC言語の関数を呼ぶことで補うことができる。そのようなLuaをTTと組み合わせることで、ユーザが定義した任意のデータベース操作を実行するのに適した環境を提供できたと思っている。 ただし、以下の欠点が気になっていた。これらはいずれも機能不全を示すものではなく、工夫すれば乗り越えられるものだが、工夫しないと所望の機能が実現できないというのはストレスだ。 引数や
開発メモ: Kyoto Tycoonのプロトコル仕様
TTではpure Ruby版とpure Perl版のクライアントライブラリを自分で実装していたが、KTでは各種pure実装は自分では書かないことにする。私はC++版のクライアントライブラリを作成しメンテナンスするが、その他の言語に関しては、その言語で生活していて腕に覚えのある方々にお任せしたい。その前提として、プロトコルを明らかにしておく必要がある。英文の仕様書を後で書くが、そのたたき台としてまずは日本語で書いてみる。 ---- 概要 KTのサーバプログラム（ktserver）は、HTTPに基づいてクライアントと通信を行う。デフォルトのサービスポートは1978番だが、ユーザの設定によって変わることもある。サーバは、HTTP/1.0およびHTTP/1.1のリクエストを解釈することができ、それに対応するレスポンスを返す。 HTTP/1.1のリクエストにおいてContent-Typeヘッダの値が
開発メモ: Kyoto Tycoonベータ版リリースすた
ここのところ必死こいて作り込んでいたKyoto Tycoonだが、主要機能を実装しきって文書もそこそこ書けてきたので、ベータリリースということにした。プロジェクトページもちゃんと作ってある。 公式には英語の文書しか作らない方針なのだが、それだと国内ではなかなか使ってもらえないので、この場でチュートリアルを書いてみる。 Kyoto Tycoonとは プロセス組み込み軽量データベースライブラリであるKyoto Cabinetをネットワーク越しに利用できるようにするためのツールキットである。KCのデータベースを内部に持ったサーバプログラムと、それに接続してデータベースを操作するためのクライアントライブラリからなる。また、コマンドラインからサーバにアクセスするためのユーティリティもついてくるので、簡単に使い始められる。 製品コンセプトは、「永続的キャッシュサーバ」もしくは「memcachedの永続
開発メモ: TSV-RPCでお気楽ネットワークプログラミング
古き良きタブ区切りテキストを使って簡単かつ効率的にRPCを実現してみた。単純なユースケースではXML-RPCより便利に使えるよ。 チュートリアル ともかく実際に体験してもらうのがわかりやすいと思う。DBMライブラリTokyo Cabinetと永続キャッシュサーバKyoto Tycoonをまずはインストールしていただきた。KCを入れてから、KTを入れる。両者とも、ソースアーカイブを展開したディレクトリに入って以下のコマンドを実効すればビルドとインストールが完了する。 $ ./configure $ make $ sudo make install で、TSV-RPCサーバの典型的な実装例であるところのKyoto Tycoonサーバを起動する。端末で以下のコマンドを実行するだけでよい（終了するには端末にCtrl-Dを入力）。 $ ktserver デフォルトの設定では、オンメモリのキャッシュデ
開発メモ: Kyoto Tycoonのプロトコル再設計
HTTPベースで任意のRPCコールができるように、プロトコルを汎用化したい。KT以外のユースケースでも、パラメータ等の解析部分は同じコードを使いまわしたい。その考察。 動機：実装を簡単にしたい 前回述べたHTTPServerクラスを作ったことで、HTTPベースのサービスを作るのが非常に容易になった。そしてその目的は、Kyoto Cabinetのデータベースを操作する各種メソッドをRPCで操作することである。でも、まてよ、「RPCで操作する」ってとこだけ抜き出してもう一段抽象化した方が、実装が簡単になるし、後々のメンテナンス性が良さそうだ。そうしよう。 RPCといっても処理の流れが同期なのか非同期なのかとか、データの受け渡しがブロックなのか、エラーの返却はどうするのかといった決定の組み合わせによって多様性があるわけだが、今回は最も単純な組み合わせを選択する。すなわち、リクエスト受信からレスポ
開発メモ: Kyoto Tycoonのスクリプト言語拡張
前回の議論で、HTTPベースでRPCを実現する環境を整えた。KCに対する既定かつ単一の操作を行う関数をリモートから容易に呼び出すことができるようになったわけだ。今回は、ユーザが定義した任意の機能を組み合わせてサーバ側で実行するためのスクリプト言語拡張について考察する。 先に結論を言っておくと、acceptはRPCでは提供しない。その代わり、いかなるリソースにも関連づけられていないスクリプト関数を呼び、その中でacceptを呼んでもらうことにする。 acceptをRPCで実装するとどうなる？ Visitorと呼ばれる任意のプログラムを単一のレコードに対してアトミックに適用するというのがacceptメソッドの仕事である。acceptも単なるRPCの関数に過ぎないので、acceptをどう実装するかは実は今のプロトコル設計にとってはどうでもいい話である。入力と出力の形式が決まっていれば、中身はどう
開発メモ: 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&
開発メモ: Kyoto Tycoonの設計 その壱
memcachedのように一時的なデータを高速に扱えながらもデータをファイル上に永続化できるサーバとして、「Kyoto Tycoon」という製品を開発することにした。もちろん、Kyoto Cabinetをストレージにしたネットワークサービスを提供するものである。実のところ、決まっているのはその点と名前だけで、設計は何も決まっていない。ここにあーだこーだ書きながら詰めていこう。 背景 先に明言すべきは、これはKyoto CabinetをストレージにしたTokyo Tyrant相当の製品ではない。TTはキャッシュサーバではないので、memcachedで言う所のexpireをサポートしていない。しかし、Kyoto Tycoonはキャッシュサーバとしての利便性を追求し、もちろんexpireをサポートするとともに、レプリケーションなどの重量級の機能は割愛する。 なぜこれを作るかという理由は大きく二つ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
FAL Labs
fallabs.com