前回に続いてUI特許取得回避のための記事です。

Twitterアプリのタイムラインでプルダウンして指を離すと新着確認するUIがありますが、iBooksやPDFビューアなどのページ単位のナビゲーションをするアプリで、下図のように

• 上端位置からプルダウンして指を離す→前項の下端に移動
• 下端位置からプルアップして指を離す→次項の上端に移動

できるとスムーズなページ送りができて便利だと思います。

UI特許取得を避けるために書いておきます。

クリック／タップでボタンを外した場合に、もう一挑戦してまた外れた場合、タップ地点の近くにあるボタンなどのUI要素をクリック／タップしたことにすると便利だと思います。

3回失敗、4回失敗するごとに、徐々に探索半径を広げていっても良いかもしれません。

カンファレンス会場で最も貴重な資源は時間ですが、二番目はきっと電源です。
電力というのは普段は簡単に安く手に入る資源であるにもかかわらず、人が集まる場所では極端に供給が難しくなります。
このギャップはとても大きいので、ビジネスになるのではないかと思います。

非常に大雑把な計算ですが、
普通のノートPCを１日動かす程度電力が供給できれば良いので、
20000円程度で市販されている外部バッテリを年間100日レンタルできたとして、平均耐用年数が１年だったとしても、1日あたり200円です。

カンファレンス会場に据え置いてしまえば輸送コストはそれほどかかりません。カンファレンスはほとんどデイタイムに開催されるので、夜間の安い電力で一括充電できます。
一晩に一人で1000個のバッテリを充電できるとすると、時給2000円でも8時間で16000円/日。バッテリ一個あたり16円。
人件費を考慮しても十分安価にサービスを提供できるのではないでしょうか。

In these days, I am thinking about how web services can be provided without shutting down.
An answer I got is keep it small.
Small services can be provided without maintenances.
For example, the Formula (http://formula.s21g.com/) has been provided for more than a year. But it had virtually neither maintenances nor updates.
But it is used by someone sometimes.

The cost of keeping such services is about $50 a month.
It consists of only the cost of an EC2 instance.
An instance can offer several such services, so the cost would be shared by them.
So thus the individual cost becomes more low.

Suppose the cost is $20 a month,
we can gain it by a fund of $4800 if it earns 5% a year constantly.
If it is possible, it can be a new way for providing services such as the Formula.

Rails勉強会#40のセッションでも言いましたが、
エラーが発生した時等に表示されるbacktraceの表示は、
コンソールのように上から下に流れる画面上では
通常の逆順のほうが追いやすいと思います。

ということで、ちょっと試しにそのような挙動にしてみました。
以下のようなコードを実行するとテストできます。

ruby>>
class Exception
def set_backtrace(bt)
puts bt.reverse.map{|i|
i.sub(/^([/.\w]+):(\d+)/,
"\e[33m\1\e[m:\e[32m\2\e[m")
}.join("\n")
end
end

def foo
raise StandardError
end

def bar
foo
end

bar
<<--

こんな感じに、エラーが発生した場所に近い順に、
下から上にたどっていく感じに表示されます。

上から下のbacktraceに目が慣れてしまっているので、最初は追いかけにくさを感じますが、一旦慣れてしまえば、スタックが深くて相当スクロールアップしなければエラーの発生源までたどり着けないという場合には良さそうな気がします。

stackという概念のイメージのせいで、新しいものが上の方に来るようになっているのだと思いますが、実用上は新しいものが下にくるこのスタイルの方が便利ではないでしょうか。

Rakeでnamespaceなどを使った場合に、Rubyのシンボルをネストさせたい時があるのですが、

ruby>>
task :foo => :"bar:baz"
<<--

のように書くのが、DSL的にちょっとかっこうわるいです。
そこで、以下のようなものがあればちょっと奇麗に書けます。

ruby>>
class Symbol
def method_missing(method, *args, &block)
if args.empty? && block.nil?
[self, method].join(':').intern
else
super
end
end
end

:foo #=> :foo
:foo.bar #=> :"foo:bar"
:foo.bar.baz #=> :"foo:bar:baz"
<<--

いかがでしょう。

An Idea for Open Avatar Exchange

I am using GRAVATAR at github.com.
It is very interesting service that provides globally recognized avatar image from a hash of email address.
What is clever is a service using GRAVATAR can present its user's avatar without not exposing his/her email address.

But the GRAVATAR is not the only provider of such avatars.
For example,
twitter.com has huge database of mapping from email address to avatar image.
There are a lot of services which have such the database.

Imagine twitter.com, facebook, linkedin and so on provide their avatar images by the same manner.
We can provide avatar image for every user of which we know his/her email address everywhere and quite easily.
This is the principal advantage of this idea.

But what is advantage for provider?
That's the obvious question.
Answer is inter-service completion of avatar images.
In each service, not all users have his/her avatar image.
For such users, the service provides disappointing default avatar image.
But if there is the open avatar exchange, the service can try to find it in other services instead.

The way to make the exchange is really simple.
Provide REST API to map MD5 hash of email address to avatar image.
Block accesses from domains you don't want to exchange.

In addition, avatar providers can harvest stats of the sites that are using your avatar image.

なかなか実装する時間がなくて困ってるアイディアのメモ。

NATに近い。

SpaceguardはLAN内のどこかのPCにインストールされるローカルCometサーバ。
SATT（Spaceguard Address Translation Table）はSpaceguardを見つけ出すためのテーブル。

Spaceguardはグローバルから見える場所に設置することもできる。

ブラウザ（＝クライアント）は、最寄のSpaceguardか、見つからなければ直接従来のCometの仕組みに従ってCometサーバとXmlSocket（単にSocketでもいいけど）で接続する。
優先順位は、ローカルSpaceguard、グローバルSpaceguard、Cometサーバの順。
Firewallがあるような環境では、ローカルSpaceguardの設置を必須とすることも考えられる。

メリット

• Spaceguardをイベント通知のMUX/DMUXとして中継させることで、
  無駄な接続数を減らせる
• 一般にLAN内ではHTTP以外の通信ができると思われるので、
  ローカルSpaceguard⇔FlushクライアントによるXmlSocket/Socket通信を前提とすることができ、
  Cometクライアントの実装を簡素化できるかも

身の回りに溢れているほとんど全てのプログラムは、
静止状態の表現としてソースコードを持ち、
計算機上で実行され、そして終了します。
少なくとも、終了しようと思えばできるように作られています。

しかしながら、近年では、Webサーバやネットワークプログラムのように、
継続的に動作することが当たり前で、停止状態に移行する事自体が
例外とされるようなプログラムが珍しくなくなってきています。

RubyやPerl, Pythonなどの動的言語と呼ばれる言語が普及し、
プログラム言語の価値は、実行速度から開発速度で測られる
比率が高くなりました。
そんな中、去年ぐらいから、静的言語でも動的言語でもない、
新しいプログラミング言語のパラダイムの可能性について考えています。

• 走り続けるプログラム

はてしない物語。終了状態の無いプログラム。

停止することなく、動き続けることが想定されるService型プログラムを
記述することに特化した言語があってもいいのではないか。
そんな事を思うようになったのは、
Rubyistにはお馴染みの
irb
と
druby
を頻繁に使っていたからかもしれません。

NEPL ≒ irb + druby + Erlang + Sandbox

今のところ、open な druby サーバに対して irbで接続しに行くというのが、
一番それらしいものが得られる方法だと思います。
しかしながら、openなdrubyサーバを用意するのは非常にリスキーです。
ErlangのActorモデルや、エラー処理に関する哲学が参考になりそうです。

NEPL処理系が実現すると、
ソフトウェア開発のスタイルが大きく変わるのではないかと思います。

• ソースコードを書いて、リポジトリにコミットするのではなく、
  NEPL処理系に接続し、irb的なshellからActorを登録する。
• 仕様をActorの評価関数（計算機リソースの割り当て比率を決める）として定義する。
• バグを見つけてソースコードを修正するのではなく、
  バグを定義してActorに対する罰金（ペナルティ）を課し、終息させる。

何かとりあえず動くものを形にしてみるべきですね。
$SAFE = 4なrubyとdrubyをベースにするか、
JavaScriptを使ってやるか、そのあたりを考えています。

See Also

• Smalltalk勉強会レポート
• rush - Rubyが使えるOOPシェル
• BioRuby

This is a memo of an idea that I'd wanted to do for about a year since my starting to write some codes for a comet server.

By using Comet, JavaScript tests by various browsers can be automated. It's sure to be able to do even by any browsers to say nothing of the Firefox with MozRepl.

I've said in each place about this, but it has been hard to make a time to touch it, because too many exciting ideas struggled in my brain to make my hands type them out.

I wrote this entry with a hope that it might be going to be done by someone else.

前からやりたかったアイディアのメモ。
Cometを使えばMozReplみたいなのをFirefox以外のブラウザでもできるはず。
それを使って各種ブラウザでのテストを自動化する。

結構各所で言ってるんだけど、なかなか手がつけられない。
最近手がつけられないアイディアが多くなってきたので、
誰かが作ってくれるかもしれない希望を込めて書いておきます。

最近はJavaScriptを使っておれおれスクリプト言語の処理系を
実装するのが流行っていますね。
ちょっとその実用性について考えてみたのですが、
限定されたデータに対してだけアクセス可能な、
サンドボックス的なスクリプト言語というのは、Webサービスの
プラグイン記述言語（サイト内DSLと呼んでみる。
サイト内とDSが被ってる気がするけど気にしない）
としての需要があるきがします。

例えば、次のような特徴を備える言語が考えられます。

• Cookie情報にはアクセスできない
• 指定したDOM Elementの子要素にしかアクセスでいない
• 指定した種類のElementしか作成できない
• XmlHttpRequestオブジェクトを作成できない
• 指定した種類のイベントしかObserveできない

どうでしょう。Facebookのようにサードパーティが
アプリケーションを追加できるようなプラットフォームを
作る場合に、JavaScript自体ではなく、JSで実装された、
よりSecureなまったく別の言語を使うことで
より安全性を高めることができるのではないでしょうか。