Repy Blog

2013年4月7日に日本語フルキーボード for Tabletと専用Mozcエンジンをリリースしました。これにより、オフラインでも快適な日本語入力環境が利用できます。

Mozcエンジンは、辞書が巨大です。また、日本語入力という仕様上SDカードへの移動はできません。内部ストレージの容量が大きい端末にお勧めです。
また、PC向けMozcと同一辞書なので、携帯で入力する際にはあまり利用しない単語が上位に来る場合があります。話し言葉などが上位に来ない場合があります。
ユーザー辞書編集機能、予測学習機能はありません。これに関しては今後実装したいと思います。

カスタマイズのライブが最近多いので、ちょっと開発が停滞気味ですが、春の大型連休にはアップデートをしたいと思います。

日本語フルキーボード for Tablet with Mozcは問題なく動作した。

とりあえず動作するレベルにはなっているが、まだまだ公開できるレベルにはなっていないので、スクリーンショットだけあげておく。

「きょう」と入力して、「2013年4月1日」に変換できているので、Mozcの変換結果だと判別できると思う。

動作自体には全く問題ないが、問題なのは別の点にある。それはAPKサイズ。今までは、3MB弱であったものが、一気に21.3MBまでパワーアップ。
もともとMozcの辞書自体が15MB程度あり、ARM用・x86用・MIPS用のMozcライブラリを同梱したため、圧縮しても+18MBになってしまった。

21.3MBのサイズは、気軽にインストールできないので、別パッケージにしようと思う。
こう考えると、あの容量で日本語変換ができる、OpenWnnがすごいということが分かった。

Mozc for Androidエンジンを移植するため、ソースを見てみた。
結果、簡単に移植できないことが判明。実装には1か月はかかるかもしれない。もしくは、もっとかかるかもしれない。

理由について述べる前に、IMEを作るにあたって必要なことを書いておきたい。
IMEの仕事は大きく分けて4つほどある。

1. キー入力受付部分
2. 文字状態の認識部分
3. かな漢字変換部分
4. 表示部分

最初は、キー入力受付部分だ。
キー入力といっても、ソフトウェアキーボード・ハードキーボード・端末物理キー・OSのソフトキー・USBキーボードなど様々なデバイスがある。
それらのデバイスから送られる情報をもとに、何のキーを押されたか判定する必要があるが、デバイスごとに情報の形が異なるので、それらを共通化しなければならない。
この時点でデータを共通化することで、それ以降の処理を一本化している。

キー入力受付部分から、送られる情報は、aなどアルファベットや記号などの状態なのでこのままでは何もできない。
キー情報をもとにひらがなの状態を管理し、漢字変換後は漢字や読みの状態を管理しなければならない。それらを行っているのが、文字状態の認識部分だ。
この部分はさほど複雑ではないが、設定で変更したいという要望が多い部分なので、分岐コードがたくさん存在する。

かな漢字変換部分は、ひらがなを漢字に変換するだけだ。わかりやすいが、一番時間のかかるところだ。
日本語フルキーボード for Tabletでは、全く作っていない部分で、OpenWnnやGoogle CGI API for Japanese Inputなどから提供を受けている。

表示部分は、ひらがなの状態や漢字変換後は漢字や読みの状態を表示させているだけだ。
AndroidのIMEなら、キーボードの上に表示される。

つまり、日本語フルキーボード for Tabletに新たなエンジンを載せるためには、かな漢字変換部分だけが利用できると都合がよい。
しかし、Mozcの構成は、コミックにもなっている通り、文字状態の認識部分とかな漢字変換部分が一塊になっているため、そのままでは日本語フルキーボード for Tabletに載せることができない。
一度PC向けMozcを移植しようとしてつまずいた点でもあるので、今回も難易度があるかもしれない。

オープンソースになったMozcエンジンの搭載を目指します。

いままでオフラインエンジンはOpenWnnエンジンだったため、語彙力が低く、文節の区切り方もいまいちでしたが、次回のバージョンでMozcエンジン(ベータ)を搭載し、どちらでも利用できるように
できるように開発を行います。
ただし、開発工数によっては機能の一部有料化や広告表示率の調整を行わせていただくことになるかもしれません。

皆さんダウンロードしてください。

おかげさまで、日本語フルキーボード For Tabletが、15万ダウンロードまであと少しなところまで来ております。
また、有料オプションも多くの方にご購入いただいており、開発の励みとなっております。

現在、日本語フルキーボード For Tabletの大幅アップデートを計画中です。様々な意見をいただいておりますが、その意見のうち何を採用するかはまだ決めておりませんが、多くの意見を取り入れてより良いものを作っていきたいと考えております。

今週は、機能を2つ追加しました。
従来版でネットっワークエンジンを利用している場合、ネットワーク接続が不安定な場所ではキーボードが通信待ちを行いキーボードが応答不可能になるという現象が発生しているかと思います。今まではこちらでタイムアウトとリトライ回数を決めさせていただいておりましたが、新たにオプションで選択できるようになりました。通信環境に合わせて最適な値を探してみてください。
2つ目は、辞書機能が使いたいといった声にお応えして、OpenWnnエンジンの辞書編集に対応しました。OpenWnnエンジン利用時のみです。ネットワークエンジンは技術的な問題があり、対応予定はありません。

要望に関しては、こちらのサイトで受け付けていますので、どんどんお寄せください。

Javaでプログラミングしていると、byte配列(byte[])を16進の文字列に変換したいことは多い。
例えば、MD5やSHA-1,SHA-512などハッシュ値に置き換えるときや、バイナリデータのバンプなどがある。
上記のコードは、様々なところで紹介されているが、いったいどの方法が速いのだろうか？

VM環境は、Windows 7 + Oracle JRE 7 という、とても一般的な環境。
試したパターンは、10通り。そのうち比較として面白いものを4つ選んだ。
どのパターンも前提として、by:byte[]、sb:StringBuilder、とする。

//パターン1
for (byte b : by)
	sb.append(String.format("%02x", b));

//パターン2
for (int b : by) {
	sb.append(Integer.toHexString(b >> 4 & 0xF));
	sb.append(Integer.toHexString(b & 0xF));
}

//パターン3
for (int b : by) {
	int b2 = b & 0xff;
	if (b2 < 16) sb.append("0");
	sb.append(Integer.toHexString(b2));
}

//パターン4
for (int b : by) {
	sb.append(Character.forDigit(b >> 4 & 0xF, 16));
	sb.append(Character.forDigit(b & 0xF, 16));
}

実行結果は、以下のとおりである。

パターン	実行時間
パターン1	47817ms
パターン2	4313ms
パターン3	2310ms
パターン4	588ms

パターン1は、フォーマット文字列の解析があるので、明らかに遅くなるのは間違いない。ほぼ予想通りであるといえる。
パターン2とパターン3からいえることは、これらの処理の中でInteger.toHexString()が一番時間がかかるといえる。

結果としては、パターン4が明らかに速い。理由はOpenJDKのソースを見ると明らかだ。
Integer.toHexStringは複数の桁を検査し、それをnew String()している。
Character.forDigitは1桁目のみ検査し、それをcharで返している。
charはintと同様クラスではないので速いのだろう。Stringはクラスなので、生成にコストがかかる。

今回の調査でわかったことは、Stringの生成は意外とコストが大きく、StringBuilder.append()は速いということだった。
Stringの生成が遅いので作られたものがStringBuilderという点からしても当たり前か。

Enterprise JavaBeans 3.1 第6版

IT企業に転職して、1ヶ月たちました。公務員時代にはできなかったことをいろいろやるのが今年の目標です。

公務員時代には、公務員倫理規程で兼業禁止になっており、アプリの販売やサービスに課金ができませんでした。そのため、アプリやサービスの開発運営はすべて広告収入のみで賄っていたため、ほとんどが赤字事業です。
4月から民間企業に移り、アプリの販売やサービスに課金を行えるようになったので、いろいろなサービスを本格的に始めて月980円のVPSが借りられるくらいの収入が入るまで、成長させたいと考えています。

そこで、「日本語フルキーボード For Tablet」の新機能と、現在行っている事業を紹介したいと思います。

まず、「日本語フルキーボード For Tablet」の新機能は、広告非表示有料オプションの開始です。従来から要望されていた機能です。
現在は単純に広告が非表示になるだけの広告非表示オプションのみですが、今後いろんなオプションを備えて、すべて買うとATOK以上の価格にしようと企てています。

次に、現在行っている事業ですが、Webサービスが1サイトと、Androidアプリ3本のみです。
2ch to RSS(広告)
連続バーコードリーダー(広告)
Picasa アップローダー(広告)
日本語フルキーボード For Tablet(広告+販売)
現在、人件費以外の経費は0円なので、広告収入がそのまま人件費になりますが、時給換算で100円にも満たないので何とかしようと思います。

私Repy提供の連続バーコードリーダーや日本語フルキーボード For Tabletをダウンロードして使ってくださっているみなさんのおかげで今年も行くことができました。ありがとうございます。これからも便利なアプリを開発していくつもりなので、よろしくお願いします。

今年のGoogle Developer Dayの特徴はやっぱり缶バッヂ企画でしょう。最初に同じ種類の缶バッヂ10個を配布され、開発者との交流で別の種類の缶バッヂと交換して、いろいろな種類の缶バッヂを集めるというものでした。つまり、GDDはセッションがだけではなく、開発者の交流の場でもあるということです。自分も数人の開発者と交流しました。

かといって、メインはやっぱりセッションです。今年はAndroidメインで参加しましたが、あんまり変わったネタはなくすでにリリースされている内容が大半でした。
今回学んだことは、パーミションとプライバシーに関しては特に注意が必要ということです。
例えば、日本語フルキーボード For Tabletではインターネットアクセスとインプットメソッドの2つのパーミションが付いています。この2つのパーミションがあれば、インプットメソッドでユーザーさんが入力した内容を取得し、インターネットアクセスで悪意のあるサーバーに投げ、ユーザーIDやパスワードを不正に収集することができます。つまり僕がやろうと思えば、ユーザーさんのIDやパスワードを入手することもできます。
しかし、この2つのパーミッションのどちらかでも削ると日本語フルキーボード For Tabletは成り立ちません。こういう時にはプライバシーポリシーを公開することで、ユーザーの不安を少し和らげることができます。
今回、GDDに行ってきたあとインターネットアクセスのあるアプリにポリシーを策定しました。それぞれのアプリによって異なるのでマーケットの各アプリの説明をご覧ください。

よく見るとマーケット内には危険な可能性のあるアプリが多いことがわかる。そのうち本当に危険なアプリはどのくらいだろうか。また、セキュリティソフトは反応するだろうか。Android用セキュリティソフトではOSの設計上、上記のようなスパイウェアを認識できないと考えているので、僕は使っていない。

日本語フルキーボード For Tabletのバージョンアップ頻度を下げようと思う。

理由は2つ。
1つめは、必要と思われる機能をほぼ網羅したため。1.5.0.1のバージョンで、OpenWnnの学習機能とアルファベット変換機能を実装し、最低限必要と感じていた機能はすべて実装が完了した。
2つ目は、そもそも収益が低く開発費をねん出することができないため。個人開発なのでコストはかからないが、計算すると時給5円ぐらいにしかなっていない。最低でも時給100円ぐらいの収益はほしいところだ。

OpenWnnのエンジンは貧弱なので、使い勝手のいいようにGoogle IMEとYahoo! テキスト解析を追加した。それなのに、現在の要望に上がっているもののほとんどがOpenWnnに関する部分でやる気ゼロ。
Android IMEのオープンソースが誕生するか、OpenWnnのバイナリ辞書が大幅に進化すれば、使い勝手がよくなるのだが。

日本語フルキーボード For TabletのOpenWnnエンジン使用時に学習をするオプションを追加しました。バージョン1.4.5.0以降での対応となります。

OpenWnnの仕様で文節区切りの学習がされないので、使い勝手はさほどよくない。基本的にOpenWnnは予測変換がメインのエンジンなので仕組み上どうしようもない。
次回の目標は予測変換の実装である。