通貨代用証券というのは、

小切手（自分で振り出したものは除く）

送金小切手（遠方の取引相手に代金を送るための小切手）

郵便為替小切手（遠方の取引相手に代金を送るための郵便為替小切手）

期限到来済みの公債利札・社債の利札（国債、地方債などの公債や、会社が発行する社債の利息の支払を受ける札）

配当金領収書（配当金がある株を持っている場合に、株式を発行している会社から送られてくる配当金の引き換え券）

以上のようなもので、銀行などに持参すればいつでも通貨（現金）に変えてくれるものの事を言います。 これらは、仕訳では「現金」勘定を用いて処理します。

たとえば、公債の利息50,000円を受け取った、とします。

その場合の仕訳は、

と、なります。

また、たとえば株の配当金領収書3,000円が送られてきた、とします。

その場合の仕訳は、

と、なります。

これらの直接的な処理はあまり簿記の問題でも出てきませんが、「現金」勘定で処理をする、ということだけは覚えておく必要があります。

久々にRailsプラグインの紹介です。

BackgroundFu は、Jacek Becela氏による、時間がかかる処理をバックグラウンドプロセスで実行するためのRailsプラグインです。

使い方ですが、まずはインストール。

   1  % svn export https://svn.trix.pl/public/background_fu vendor/plugins/background_fu

続いて、各種ファイルを生成するGeneratorを起動します。

   1  % ./script/generate background

バックグラウンド処理の情報を管理するテーブルを作成するためのmigration ファイルが生成されるので、マイグレーションを実行します。

   1  % rake db:migrate

これでひとまず準備完了。あとは、lib/workersの下に生成されている exampleファイルや README を参考にしながら、Workerクラスを作ります。

Workerクラスの例

   1  class ExampleWorker
   2    def add(a, b)
   3      a + b
   4    end
   5  end

このWorkerを呼び出す場合は、以下のようにします。

   1  Job.enqueue!(ExampleWorker, :add, 1, 2)

単純に時間がかかる処理を裏で実行したいだけならこれでOKです。 簡単ですね。 必要であれば、JobのIDを使ってもうちょっと複雑な処理も実行可能です。

Workerプロセスの起動は、以下のコマンドで行います。

   1  % ./script/daemons start

stopで停止、restartで再起動です。RAILS_ENVを指定する場合は、

   1  % RAILS_ENV=production ./script/daemons start

こんな感じですね。デフォルトではdevelopment環境になります。

See Also

• BackgroundFu: Threadを使って時間がかかる処理を行う

These days, I have been thinking about OpenID. It is able to gather privacy informations at one place and they would be maintained easily. On the other hand, thus it may become easy to cause a security crisis.

In order to find the solution, I have thought for a while. I think that the secret sharing scheme (SSS) could be useful for solving this problem. In other words, it could be reasonable way for achieving convenience and security to share the encrypted privacy informations between several OIPs by using SSS.

But I have no idea to make it run on the current OpenID spec. Hmm.

しばらく前からOpenIDについていろいろ調べているのですが、 個人情報が一箇所に集中することで、便利になる反面、 セキュリティ上のリスクが高まるという指摘があります。

確かにその通りで、対策を考えていたのですが、 マスターキーを秘密分散方式で複数作るのが、妥当な解決策かもしれないと思いました。 ２つ鍵穴があるドアのイメージですね。 どちらか一方を奪われても安全なわけです。 セキュリティ強度の必要に応じて３つ、4つと増やしても良いですね。

現状のOpenIDの仕様の上でうまいこと運用できないかなあ。

See Also

• 注目の情報管理方式「しきい値秘密分散法」