Repy blog

2013年4月7日に 日本語フルキーボード for Tablet と 専用Mozcエンジン をリリースしました。これにより、オフラインでも快適な日本語入力環境が利用できます。 Mozcエンジンは、辞書が巨大です。また、日本語入力という仕様上SDカードへの移動はできません。内部ストレージの容量が大きい端末にお勧めです。 また、PC向け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つほどある。 キー入力受付部分 文字状態の認識部分 かな漢字変換部分 表示部分 最初は、 キー入力受付部分 だ。 キー入力といっても、ソフトウェアキーボード・ハードキーボード・端末物理キー・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 //パターン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.forDig...

IT企業に転職して、1ヶ月たちました。公務員時代にはできなかったことをいろいろやるのが今年の目標です。 公務員時代には、公務員倫理規程で兼業禁止になっており、アプリの販売やサービスに課金ができませんでした。そのため、アプリやサービスの開発運営はすべて広告収入のみで賄っていたため、ほとんどが赤字事業です。 4月から民間企業に移り、アプリの販売やサービスに課金を行えるようになったので、いろいろなサービスを本格的に始めて月980円のVPSが借りられるくらいの収入が入るまで、成長させたいと考えています。 そこで、「日本語フルキーボード For Tablet」の新機能と、現在行っている事業を紹介したいと思います。 まず、「日本語フルキーボード For Tablet」の新機能は、広告非表示有料オプションの開始です。従来から要望されていた機能です。 現在は単純に広告が非表示になるだけの広告非表示オプションのみですが、今後いろんなオプションを備えて、すべて買うとATOK以上の価格にしようと企てています。 次に、現在行っている事業ですが、Webサービスが1サイトと、Androidアプリ3本のみです。 2ch to RSS (広告) 連続バーコードリーダー (広告) Picasa アップローダー (広告) 日本語フルキーボード For Tablet (広告+販売) 現在、人件費以外の経費は0円なので、広告収入がそのまま人件費になりますが、時給換算で100円にも満たないので何とかしようと思います。