2009年09月
2009年09月20日
2009年09月08日
最近、Youtubteの英語レッスンの動画が充実しているのを知ったので、良く見ています。
ただ、一つ残念に思うのは、英語字幕の中に分からない単語があっても、簡単に意味を調べることができないことです。
私は、Webブラウザを使うときは、FirefoxのMouseover Dictionaryを使っていますが、これは、ブラウザ上のテキストの英語にマウスを当てると辞書引きしてくれるというもので、非常に便利です。
以前からDVDを見ているときにも、Mouseover Dictionaryと同じようなことができないかなあと残念に思っていました。
そこで、少し方法を調べてみたのですが、動画をDVDに限定すれば、SubRipというツールを使って、比較的簡単に字幕部分をテキスト化できるみたいですね。
というわけで、自分専用に、字幕の英単語辞書引きの機能をもったDVDプレイヤーを作ろうと計画しています。
DVDプレイヤーの機能としましては、以下となります。
・普通にDVDの再生ができる
・SubRipで抽出した字幕を付けれる
・字幕の上の単語にマウスを重ねると、Mouseover Dictionaryと同じように、辞書引きができる
ただ、一つ残念に思うのは、英語字幕の中に分からない単語があっても、簡単に意味を調べることができないことです。
私は、Webブラウザを使うときは、FirefoxのMouseover Dictionaryを使っていますが、これは、ブラウザ上のテキストの英語にマウスを当てると辞書引きしてくれるというもので、非常に便利です。
以前からDVDを見ているときにも、Mouseover Dictionaryと同じようなことができないかなあと残念に思っていました。
そこで、少し方法を調べてみたのですが、動画をDVDに限定すれば、SubRipというツールを使って、比較的簡単に字幕部分をテキスト化できるみたいですね。
というわけで、自分専用に、字幕の英単語辞書引きの機能をもったDVDプレイヤーを作ろうと計画しています。
DVDプレイヤーの機能としましては、以下となります。
・普通にDVDの再生ができる
・SubRipで抽出した字幕を付けれる
・字幕の上の単語にマウスを重ねると、Mouseover Dictionaryと同じように、辞書引きができる
2009年09月05日
この二週間は、仕事で色々とプログラムを作っていました(7000行くらいかな?)。
・昔作った通信サーバの部品を流用したサーバプログラム
・組み込みLinux用の通信プログラム
・strus2を使ったWebアプリ
・DB操作用ライブラリ
全部自分で設計する状況で、一つ一つ良く考えて作った7000行ですので、得たものは大きいです。
DB操作用ライブラリについては、今まで使っていたものが少し使いづらくなっていたので、再設計しました。
DBの操作は、一見簡単なのですが、三つの根本的に異なる要素を含んでいるように思います。
(1) 通常テーブルのCRUD操作
(2) 複数テーブルのJOIN検索
(3) 排他制御
また、多分、4番目以降の要素もあると思います(例えば、テーブルスキーマの変更)。
プログラムから使う場合は、データはオブジェクトとして扱うことになりますが、オブジェクトとリレーションのマッピングについては、上記の三つの要素を良く考えて、あり方を考える必要があると思います。
私の個人的な見解としましては、十分に正規化されたテーブル同士の関係は、十分に設計されたオブジェクト同士の関係と同様の分かりやすさを持ちます。したがって、オブジェクトありきでなくて、テーブルありきで設計する方がいいような気がします。
また、テーブル上のデータがどう使われるか(何と何がどうJOINして、どういうデータを構成するか)は、利用のコンテキストによって異なるので、型の緩いレイヤ(汎用的なマップ型)を用意して、その上にオブジェクトデータ構造のレイヤを用意すると分かりやすいと思います。(この課題を、ORマッピングツールで自動的に解決しようとするといつもハマリます。)
排他について。目指すところは、「このライブラリを使って、こういうポリシーで設計したら、無難な動作効率で動き、データに矛盾が発生せず、デッドロックが起こらないことが自然と保障される。」ということです。
まずは、設計ポリシーとして、基本的なことが2点あるかなと考えています。(3-1) DBの外部キーを有効活用する。(3-2) トランザクションは、サービスの単位にする(利用者に対して、「要求の失敗 → 副作用なし」を保障する)。
DBのロックの機構としてはテーブルロックがありますが、より効率の良いロックの機構として、行ロックの機構があります。行ロックは、変な使い方をすると、データに矛盾を発生させたり、デッドロックの可能性を生むので、少し扱いが悩ましいですね。→検討中です
・昔作った通信サーバの部品を流用したサーバプログラム
・組み込みLinux用の通信プログラム
・strus2を使ったWebアプリ
・DB操作用ライブラリ
全部自分で設計する状況で、一つ一つ良く考えて作った7000行ですので、得たものは大きいです。
DB操作用ライブラリについては、今まで使っていたものが少し使いづらくなっていたので、再設計しました。
DBの操作は、一見簡単なのですが、三つの根本的に異なる要素を含んでいるように思います。
(1) 通常テーブルのCRUD操作
(2) 複数テーブルのJOIN検索
(3) 排他制御
また、多分、4番目以降の要素もあると思います(例えば、テーブルスキーマの変更)。
プログラムから使う場合は、データはオブジェクトとして扱うことになりますが、オブジェクトとリレーションのマッピングについては、上記の三つの要素を良く考えて、あり方を考える必要があると思います。
私の個人的な見解としましては、十分に正規化されたテーブル同士の関係は、十分に設計されたオブジェクト同士の関係と同様の分かりやすさを持ちます。したがって、オブジェクトありきでなくて、テーブルありきで設計する方がいいような気がします。
また、テーブル上のデータがどう使われるか(何と何がどうJOINして、どういうデータを構成するか)は、利用のコンテキストによって異なるので、型の緩いレイヤ(汎用的なマップ型)を用意して、その上にオブジェクトデータ構造のレイヤを用意すると分かりやすいと思います。(この課題を、ORマッピングツールで自動的に解決しようとするといつもハマリます。)
排他について。目指すところは、「このライブラリを使って、こういうポリシーで設計したら、無難な動作効率で動き、データに矛盾が発生せず、デッドロックが起こらないことが自然と保障される。」ということです。
まずは、設計ポリシーとして、基本的なことが2点あるかなと考えています。(3-1) DBの外部キーを有効活用する。(3-2) トランザクションは、サービスの単位にする(利用者に対して、「要求の失敗 → 副作用なし」を保障する)。
DBのロックの機構としてはテーブルロックがありますが、より効率の良いロックの機構として、行ロックの機構があります。行ロックは、変な使い方をすると、データに矛盾を発生させたり、デッドロックの可能性を生むので、少し扱いが悩ましいですね。→検討中です






















