Graffiti Pro(広告なし) Release!

一部の要望があった、広告なし有料版Graffiti、GraffitiProでました!

先のコメントを書いたときは出てるのを知らなかったのですが、いつの間にか出てました。げーるさん、朗報です。でも見てないかな。

私も買って使ってみましたが、たしかに広告がない以外は動作は変わっていないようです。「n」だけで「ん」に変換できないとかの細かい点は改善されてません。忙しいようだけど、よろしく!>担当エンジニア

しかし謎なのが今までのGraffiti for Android。なぜかうちの Nexus Sではマーケットに表示されなくなってしまいました。機種によっては表示されるとの話もあります。どうなってんだろう。

試しに使ってみたい、って人のために無料版もあるといいと思うんですけどねえ。

放置しててすみません

色々と私事で忙しくて、放置しててすみません。どうせspammerしか来てないだろうと思っていたら、まだGraffitiの記事にコメントが付いていて嬉しかったです。
で、私事で忙しかったというのは、実は去年転職しました。ACCESS社の中の人ではなくなったので、Graffitiなどについてどうなるか言える立場ではなくなりました。いや、今までもそんなに言えた立場でもなかったのですが。
ただ、一ユーザとしてこれからもGraffiti for Androidは使っていきます。皆様と一緒に改善に手伝えればいいと思っています。
これからは放置しないようにしたいのでよろしくおねがいします。

dagezi

Google Waveの一人反省会

Waveが終了するらしいですね。GoogleI/O 2009に参加し、 Waveが発表される瞬間の興奮を味わった身としては残念な限りです。 例えていうと、Oh! PASOPIAが休刊になったときの様な寂しさです。 多分多くの人にはちっとも伝わらない譬えでしょうが。 officialに終わることが分かっていても、 なんとか有志で生き延びさせられないか、そういう思いです。

実際、Waveはある程度は open sourceなので、 そこらへんを持ってきて完成させることはできる。 とはいうものの、Waveにおける完成を定義できる存在が いなくなってしまったのだ。

Waveというのは融通無碍なシステムであり、なんでもできると いいつつ何ができるのかわからなかった。

• １文字ごとに表示される realtime chat applicationであり
• 様々な applicationをプラグインとして埋め込める環境であり
• 編集履歴を保存できるちょっと richな文書共同編集ツールであり
• Syndicateを使い、他の domainのサーバとも交信する分散システムであり

いろいろな側面を持っていて、いろいろな人がいろいろな「完成した Wave」 像を持っていた、あるいは持っていなかった。

例えば、自分にとってはやはり Openな環境として (Mailシステムの 敷衍として) 3rd party server も参加できる syndicationが 興味があった。 その礎としての protocolとか、応用としての Emacs clientとか そう言うのができないかな、と期待してました。 本当に Mail + alphaのシステムとして。

本来だったら Googleが音頭をとってそこをすり合わせるはずだったのに、 それを放棄してしまった。 OpenSourceで技術的には発展できるとしても、それを一つの Waveというシステムにまとめ上げる人ができなくなってしまった。

合意のとれない OSSは弱いものです． ましてや、Waveという、まねもんを作るのではない新しいものを 作ろうという projectでは。

ということで反省会に至るまえに結構書いてしまったので、 とりあえずここら辺で postしときます。 次に元気になったら反省会するかも。 待て次号。

元祖 Graffiti for Android

宣伝 entryです。

Graffiti for Android というものを、 弊社で開発しました。 弊社って言うほど会社を代表した立場じゃないんですが、 ちょこっとだけ関わった身としてもうすこしネット上での 露出が上がるといいんじゃないかなあ、と思うのです。 本命は欧米 (というかアメリカ) なので日本語で グチグチかいててもだめな気もするけど。

閑話休題。Graffiti というのは 10年ぐらい前、Palm という PDAで流行った手書き用のアルファベットの入力方式です。 以下のような特徴があります。

• ほとんどの文字を一筆書きで入力できるため高速
• アルファベットを元にしてるため覚えやすい
• 識字率は高い。なれれば百発百中
• 単純なので当時の低速CPUでも充分処理できた
• 1とi, 0とo など区別来にくい数字と英字は、書く場所をわけるというコロンブスの卵的対処

このシステムは Palm → PalmSource → ACCESSと流れて、 弊社の所有物であります。つまりソースコードから 辞書から何からあります。

それをただいま一部で話題沸騰の Androidに乗せてみたのが、 この Graffiti for Androidです。 つまりあの遣いやすい Graffitiを input methodとして いろいろな Android applicationの上で使えるのです!

NexusOneや Expedia、Android 1.6 以上にあげた G1とかで動きます。 各種iPedおよび互換機 ではためしてません。そもそも Android Marketで 表示されるんでしょうか?

ちなみにこのGraffiti は、original のもので Graffiti 2ではありません。 Xeroxとの係争はちゃんと解決しているので大丈夫です。 私は old Graffiti ユーザなのでうれしいですが、Graffiti 2 になれてしまった ユーザは i とかにお気をつけください。

個人的には NexusOneで使ってるんですがかなりいい感じです。 片手で持って親指でサクサクと入力できます。 1.5文字/秒 ぐらいの感じでしょうか。 ソフトキーボードなんかよりは早いです。 ただ、ミスると先行入力したのを消さなきゃいけなくて 一気に落ちますが。

まだかな漢字まじり文とかは入力できないんですが、 多分このままいくと対応するんじゃないんでしょうか。 でも、それには dawnloadされて皆様の声が上がるのが 必要かと思うので、 ここでひっそりと宣伝したりする次第です。

Bluetooth ヘッドフォン

Bluetooth ヘッドフォンをかうに当たって、いろいろ学んだのでまとめをかねて

プロファイル

Bluetoothの機能はいろんなプロファイルに対応している。 例えば以下のようなプロファイルがヘッドフォンには使われる。

A2DP

オーディオ転送用のプロファイル。実際にどんなフォーマットで転送されて るんだろう? SBCってのが 最低ラインらしい。

AVRCP

リモコンようプロファイル。iPhoneは今のところ対応していない。

HSP

マイクつきヘッドフォンとしてのプロファイル。 ふつうの Bluetoothヘッドセットがサポートしてる

HFP

電話を受けたりかけたりするためのプロファイル。

ほかにもいろいろあるらしいが、WikiPediaでも みるといい。

そのたのキーワード

2.0 と 2.1

最近の deviceは Bluetooth 2.0 と 2.1があるらしい。 大きな違いは WikiPedia によると、SSPっていう paring のための機構があるらしい。

EDR

Bluetooth 2.0の目玉でありながら、optionalである高速転送機能。 論理的には3倍になるらしい(1Mbps → 3Mbps)。

A2DPの対応codec

いまさらこれが結構問題かもしれないと思い始めた。 最低スペックである SBCは、多分そんなに圧縮率は高くないのだろう。 つまり SN比が低い環境では切れやすかったり。

class

単純に電力のよう。class 2が最大 2.5mW、10mぐらいでの利用を 想定していて一番多いか

実際

Logitechの LBT-HP110C2を買った。 まあ、型落ちでやすかったのと、小さかったから。楽天で 3981円 。

Nexus-oneと簡単に繋がった。AVRCPも対応してて、次の曲にとべる。

しかし聞いてみると while noiseがする。 だらだら聞いてる分には気がつかないが、ちゃんと聞くと気になる。

たまに「ピー」といって音が切れる。WiFiつかいながらなのが いけないのかもしれない。 それにこれは EDRをサポートしていなかったり、codecが SBCしか 対応していないのがいけないのかもしれない。 やはり型落ちの品にはそれなりの理由があるか..

最新の LBT-HP120C2は、Bluetooth 2.1 + EDRにも対応してるし。 codecまではのってないが。

ま、とりあえずしばらく通勤に使ってみてから、 どうしても使えないようだったらクーリングオフでもするかな..

「外国語を身につけるための日本語レッスン」批判、もしくは「主語はどこだ」

外国語を身につけるための日本語レッスン(三森ゆりか)
という本を読んで、だらだら考えたので。

まず、この本の趣旨には賛同する。
いや、この本の趣旨に倣えば「この本の趣旨に私は賛成する」と
書かねばならないのかもしれない。

この本の趣旨は、単純にまとめてしまえば
「英語などの外国語を学ぶより先に、コンテキストを
共有しない他者と日本語で意見を交換できるようにしろ」
ということだ。
そうしないと英文法や発音を練習しても、意味のある文を
英語を始めとした外国語で喋れるようにならない。

さて、上の文節でも、私は曖昧にするための日本語のレトリックを
使ってしまった。第二の文「そうしないと〜ならない。」が、
私の意見なのか本の趣旨なのかの判断を読者に委ねてしまっている。
いちいち「というのが趣旨だ」などと書くと煩雑なので省いてしまっている。
そしてさらに本の趣旨と自分の意見が同じことを暗喩しようとしている。
まさに「曖昧な日本の私」だ。

とはいうものの、この本のなかにも誤りがある。
それは単に用語的な誤りであるともいえるのだが、
「日本語をうんぬんする本の中で基本的な用語を間違えてしまっている」
という事実が、日本語に関する暗部をさらしているともいえる。

それは「主語」という単語についてだ。
この本ではよくあるように「文の主語をはっきりさせよう」といっている。
そして、その例として、まずは次の文のように「私は」をつけることを
提案している:

(私は) どこにいるか分からなくなってしまいました。

しかし端的にいえば「私は」は主語ではない。「どこにいるか(が) 」が
この文の主語だ。

「分かる」は、理解する対象を主語にとる。「道が分かる」「やり方が分かる」
などだ。理解する人物を主語にとるわけではない。
そりゃ、英語では「I got lost」で Iが主語にくるかもしれないが、
日本語はそもそも違うのだ。そこで「主語」を強調してもしょうがない。

では「私は」はなんなのかというと、日本語文法上定説はないのではないか。
20年ほど前に読んだ三上章の「象は鼻が長い」では、「主題」と
読んでいたが、これが定説になったということは聞いていない。

いずれにしても、そういった三井が強調する、そしてだれにでも大切だと
思われる文法要素にちゃんとした定説もない、
その事実が日本語作文の暗部をしめしているようにも思えるのだ。
やれやれ。

webloogger.el の C-xC-sが動かないけどよく分からん

前回のpost で C-cC-s が動かないと書いた件の続報です。

調べて見たところ、weblogger-entry-mode-mapは 定義されてるけど使われてない (use-keymapされてない) ことがわかりました。

これはなんでそうなってるのかよくわかんのです。 以下の変更で comment-outされてるんだけど.. なんでだろう?

revno: 23
committer: Mark A. Hershberger <mhershberger@intrahealth.org>
branch nick: emacsweblogs
timestamp: Mon 2009-12-07 16:13:58 -0500
message:
  Add submit-bug function and mode toggling functionality.

ちなみに変更されたのは 2ヶ月程前なんで、それ以前の sourceを 使った人は効いてるはずですね。

いずれにしても所詮開発途中のものだからしょうがないという ことでしょうか。不可解だけど適当にごまかしつつつかいます。

weblogger.el で postしてみる

と言うことで weblogger.elを入れてみました。

動いてます。いい感じです。 当然最初から何もしなくても JIS-X0208も通ります。 苦労したのがアホみたいです。

設定も簡単です。こんなんでいいのかってぐらい。

苦労したのは MacPortsで bzrをいれるときぐらいです。 port install bazaarだと version 1.4 が入ってしまった。

色々コマンドもあるんでしょうが、とりあえず成功したよってことぐらい。 さて、うまく publishされるかな..

うーん、どうも C-c C-s で post&publishされないみたい。 よく分からないのでまた今度調べよう。

emacs用 weblog client

mt.el をいじって遊んだわけではありますが、
よくみるとあんまり保守されてない気もする。
2002年だし。track backとかもないし。

と言うわけで新しい MovableType clientがないかと捜したら
時代は既に
weblogger.el
のようですね。
すでに日本語での
運用実績もあるみたいだし。うーん、時間を無駄にした。

まあ、emacsの multibyte-stringとか変なところを学べたから
いいってことにしよう。うん

mt.el で editができるようになった。

前回の記事では
失敗していた既存postの editができるようになりました。
例によってgitHubから
どうぞ。

結構悩みましたが、原因は emacsにおける unibyte-string と
multibyte-stringの相互変換にありました。

mt.el が xml-rpc.el 経由で使う url.el という libraryでは、
扱うデータは unibyte-stringでなくてはいけないという policyのようです。
これはurl-http.el のソースにも書いてある。

しかし xml-rpc.el は、そこんとこあんまり真面目に考えている風がない。
そもそも文字コードなんか 8bitをまるまる渡せばいいじゃん、ぐらいの
西欧お気楽主義にしか見えない。

そこをいじるのも面倒で、自分は xml-rpc.el も unibyte-stringだけを
受け付けると見なし、xml-rpc.el に渡す前に UTF-8 で encodingするように
しました。しかるに、そこに穴があって、一部の文字列が multibyteで
残っていたのです。

xml-rpc.el で、引数をまとめて一つの XML文字列にするとき、
一つでも multibyte stringが残っていると concatするときに
'make-string-multibyte' で全部変換されちゃうらしいっす。
そして前述の url-http-create-request 関数内で 'string-as-unibyte'
で変換しなおすと余計な byteがついて UTF-8としてただしくないものに
なってしまうという落ちでした。

で、今回はかなり場当たり的に xml-rpc.el に mutlibyte-stringを
渡してるところを塞いだけど、これだとまだ穴がありそうだなあ。

本当は xml-rpc.el で multibyte-stringの扱いをどうするか policyを
ちゃんと決めなきゃいけないんだろうけど。
unibyteしか扱えないというのは制限としてきつそうな気がする。
でも XML RPC で blob的なものを使いたかったりするとそういう
APIにしとくしかしょうがないかなあ。
いや、XMLで blobってのがナンセンスか。

と言うことで煮え切りませんが、とりあえず一歩前進したということで