Repy blog

高校と中学校で時期は違うがここ2～3年で、本格的に学習指導要領にプログラミングの指導が含まれるようになり、教科書にもがっつり記述されるようになった。また、来年の大学入試共通テストより情報Iが追加され、国公立大学を受けるにはプログラミングは必須となる。 しかし、それを教える人材である技術・情報の教員の大半は、大学時代にプログラミングを少しやった程度の人が多く、教えなければいけない内容に対して、教えられない人が多数発生している。 当然そのような状態を見越して、ビジネスチャンスと考えた民間会社が様々な教材を作って販売している。多くの教材は、eラーニングスタイルの教材で、Web上でPythonのコードを学べる環境にPythonの実行環境を組み合わせたものが大半である。 ライフイズテックレッスンもeラーニングで学べる教材の一つである。ライフイズテックレッスンは、生徒の進捗も簡単に追え、また、理解度チェックワークといった問題も用意されており、実際採用してみると、今後これなしでプログラミングの単元をできないといえるくらい完成度が高い。 しかし、教材を渡してやっとけだけで、プログラミング能力が付いたら、街のプログラミング教室やオンラインのメンター付きプログラミングスクール（TechAcademy、CodeCamp、DMM WEBCAMPなど）なんか存在しない。つまりは、結局は教材ではなく人が教えているのである。ライフイズテックレッスンを使ってどのように教えるかが重要である。 実際に２年ライフイズテックレッスンと使って感じた、効果的な使い方を説明したいと思うが、その前にライフイズテックレッスンの機能を確認しておく。 教員向けスライド 前回の復習や発問等で生徒をレッスンに集中させるための前座コンテンツである。 レッスンの終了後にも今日のまとめが入っている。 レッスン 教材の本体である。 当然レッスンの進捗は生徒によってさまざまである。 理解度チェックワーク レッスン終了後に対して実施し、生徒の理解度を測定する。 では、それぞれの機能の強みを見ていく。 機能 強み 弱み 教員向けスライド 教員がコンテンツに対して補足説明できる 生徒全員に話すことになるので、生徒の進捗によっては、まだレッスンが終わっていない場合がある。 レッスン 教員がサポートせずに、生徒自ら進め...

最近、Java(JDK11)環境でHTTP通信しているときに気が付いたのだが、Javaアプリケーションの通信の多くはIPv4で通信している。IPv6対応のサービスに接続してもIPv4通信している。Javaのドキュメントを見ると、IPv6対応をうたっており、通信できないわけではない。 実際、IPv6のアドレスを直接打って通信させると問題なくIPv6で通信する。 IPv6が使われない理由は、Javaのデフォルト設定だとIPv4とIPv6の両方対応している場合、IPv4を優先して利用するようになっているためである。 IPv4とIPv6の両方対応しているとはどういうことなのか？ ここからはJava固有の話ではなく、インターネット通信全般の話になる。 そもそも、IPv6とIPv4は全く互換性がなく相互通信できない。つまり、IPv4のネットワークとIPv6のネットワークは完全に分離されており別物である。したがって、IPの世界で両方対応するということは不可能である。 そのため、両方対応するにはDNSのデュアルスタックという技術が一般的に利用されている。 DNSの仕様で、IPv4のアドレス解決はAレコード、IPv6のアドレス解決はAAAAレコードを登録することになっている。IPv4/IPv6デュアルスタックとは、同じホスト名に両方のレコードを登録することである。 IPv4ネットワークに接続している端末からは、DNSでAのクエリを発行し、IPv4アドレスに変換する。IPv4アドレスが判明するので、IPv4ネットワークでサーバーに接続しに行く。 IPv6の場合も同様で、IPv6ネットワークに接続している端末から、DNSでAAAAのクエリを発行し、IPv6アドレスに変換する。IPv6アドレスが判明するので、IPv6ネットワークでサーバーに接続しに行く。 つまり、IPv6とIPv4の両方に接続している端末が、最初にAレコードとAAAAレコードのどっちを投げるのかで、IPv4/IPv6のどっちのネットワークに接続するかが決まる。 サーバー側は、IPv4とIPv6で別のサーバーを用意してもいいし、1台で両方のネットワークに接続してもよい。両方のネットワークにサーバーを用意して、DNS設定さえすればいい。 やっと、本題。JavaでIPv4とIPv6どっちを優先するかの設定は、以下のJVMプロパテ...

JavaでカスタムプロトコルのURLStreamHandlerを登録する方法として、ネット上で挙げられている方法は URL.setURLStreamHandlerFactory である。 しかし、このメソッドは大きな欠点があり、複数回setURLStreamHandlerFactoryを呼びさせない仕様にしてある。つまり、複数のURLStreamHandlerFactoryが登録できない。複数のURLStreamHandlerを登録したいときには、一つのURLStreamHandlerFactoryで、すべてのURLStreamHandlerを登録しなければならない。 しかし、ドキュメントをよく読むと、カスタムプロトコルのURLStreamHandlerを登録する方法がもう一つ存在すると示されている。 以前にアプリケーションが URLStreamHandlerFactory のインスタンスをストリーム・ハンドラ・ファクトリとして設定している場合は、そのインスタンスの createURLStreamHandler メソッドがプロトコル文字列を引数として呼び出されて、ストリーム・プロトコル・ハンドラを作成する。 まだ URLStreamHandlerFactory が設定されていない場合、あるいはファクトリの createURLStreamHandler メソッドが null を返した場合は、コンストラクタが次のシステム・プロパティの値を探す。 java.protocol.handler.pkgs このシステム・プロパティの値が null でなければ、値は、垂直スラッシュ文字「 | 」で区切られた、パッケージのリストとして解釈される。コンストラクタは次の名前を持つクラスをロードしようとする。 < package >.< protocol >.Handler ここで、< package >にはパッケージの名前が入り、< protocol >にはプロトコルの名前が入る。このクラスが存在しない場合、あるいはクラスは存在してもそれが URLStreamHandler のサブクラスではない場合には、リストにある次のパッケージを試すことになる。 以上の手順でもプロトコル・ハンドラが見つからなかった場合、コンストラクタはシステム...

もともとGlassFish 3を利用していたが、Java EE 7サーバーに切り替える際にWildFly 8に乗せ換えた。 しかし、乗せ換えは単純にいかなかったので、今後挑戦する勇者のために、うまくいく作業記録を記すことにした。 wildflyのインストール・起動まで あまり難しい作業でない。 ただし、RedHat系の作業手順であるので、Debian系の場合一部異なる。 chownをしているのは、wildfly.confでJBOSS_USER=wildflyと設定したため。 wget http://download.jboss.org/wildfly/8.1.0.Final/wildfly-8.1.0.Final.tar.gz tar xzvf wildfly-8.1.0.Final.tar.gz cd wildfly-8.1.0.Final ./bin/add-user.sh cp ./bin/init.d/wildfly.conf /etc/default/wildfly.conf cp ./bin/init.d/wildfly-init-redhat.sh /etc/init.d/wildfly vi /etc/default/wildfly.conf chown -R wildfly:wildfly . chkconfig --add wildfly service wildfly start wildflyの設定コンソール ./bin/jboss-cli.sh connect DerbyのJTA登録 一番つまずくところは、module追加時のdependencies設定をするところである。入れ忘れると謎のエラーに悩まされる。 GlassFishと違いJNDIは必ず[java:]で始まらければならない。そのため、WARも修正が必須になる場合が多い。 module add --name=derbyclient --resources=/......./derbyclient.jar --dependencies=javax.api,javax.transaction.api,javax.servlet.api :shutdown(restart=true) /subsystem=datasources...

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円にも満たないので何とかしようと思います。

私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は予測変換がメインのエンジンなので仕組み上どうしようもない。 次回の目標は予測変換の実装である。

日本語フルキーボード For Tabletをバージョンアップしました。 公式サイト オープンしました。 要望管理が煩雑になったため、 要望窓口 を一本化します。 1.2.00～1.2.2.0までの変更点をお知らせします。 　　 1.2.00 広告枠の掲載 拡大縮小キーの状態保存 全角半角状態の保存と状態可視化 　　 1.2.1.0 バイブレーションを実装 [要望] 文節移動の設定を実装 バージョン番号の付け方変更 　　 1.2.2.0 CTRL,ALT,SHIFTの状態可視化 [要望] マッシュキーの動作を少し変更 [要望]

日本語フルキーボード For Tabletをバージョンアップして、候補をタップで選択できるようにしました。要望にあがっていた機能です。 今回は日本語フルキーボード For Tabletの内部構造を少し紹介します。 内部では大きく分けて、次の4つに分かれています。 1.キーボード部 日本語フルキーボード For Tabletのキーボード部分の実装は、ハードキーボードと全く同じに作っています。 Aのキーを押すと、インプットメソッドサービス部に、Aのキーコードを飛ばします。 2.インプットメソッドサービス部 AndroidのIMEには必ず実装しなければならない部分です。そのため、この中はあまり実装はしていません。 やっていることは入力されたキーコードを読み取って、文字なら変換部に文字データを、文字じゃないならアプリにキーコードを飛ばしているだけです。 3.変換部 変換部は、入力された文字を日本語変換エンジン部に投げます。 また、候補ビューを作成し、変換状態の管理を行う部分です。 4.日本語変換エンジン部 ローマ字・ひらがな ひらがな・文節 文節・漢字 の変換を行うところです。 この３つのメソッドさえあれば、他のエンジンにも載せかえられます。 できるだけ依存コードを減らし、別のエンジンやキーボードをのせられるように設計しています。

日本語フルキーボード For Tablet バージョン1.0.00をリリースしました。 このバージョンでは要望があった機能を色々搭載しています。過去の要望とそれに対する対応もあわせて紹介します。 投稿日： 2011年8月16日 内容： 変換結果等がもう少し選択しやすく 対応： 未定 実装するとしたらバージョン2.0.00ぐらいでの対応となります。ここまで大幅な変更はしばらくお待ちください。 投稿日： 2011年8月20日 内容： Del/Home/End/PgUp/PgDn/Ctrlなども詰め込んで欲しい。 投稿日： 2011年8月24日 内容： [ctrl]と[esc]が有れば 対応： 0.9.13?1.0.00 CTRLキーは0.9.13で対応しました。これによりAndroid 3.0以降では、CTRL+Cでコピー、CTRL+Xで切り取り、CTRL+Vで貼り付けができます。 ESC/DEL/HOME/END/PAGEUP/PAGEDOWNキーは1.0.00で対応しました。これによりAndroid 3.0以降では、HOMEで行頭移動、ENDで行末移動、PAGEUPでページアップ、PAGEDOWNでページダウンできます。 投稿日： 2011年8月20日 内容： Shiftを押しながら矢印で範囲選択したい。 対応： 0.9.12 Android 3.0以降では、これとCTRLキーを使えば、範囲選択してコピーが簡単にできます。 投稿日： 2011年08月27日 内容： マッシュルームキーの仕様変更 対応： 1.0.00 僕はあまり誤入力することは無いのですが、要望があったので長押しでの動作にしました。Simejiも、当初は短かったのですが要望で長くした経緯があります。 投稿日： 2011年08月27日 内容： メインのキーサイズ拡張等 対応： 1.0.00 僕も使っていて小さいと感じることが多かったので採用しました。 メインのキーのピッチを4.6%大きくしました。これ以上の拡大はBSキーや全半キーを移動させないと不可能なので採用しません。 投稿日： 2011年09月01日 内容： キーボードのバイブレーション 対応： 近日？ 実装するのは簡単なのでやろうと思いますが、アクセス権が変更されるので少々お待...

日本語フルキーボード For Tablet のダウンロード数が想像以上の伸びで、作者としては驚きです。そもそも自分が使用するために作ったものなので、そこまでダウンロード数が伸びるとは思っていませんでした。要望もバグ報告も、たくさんいただいております。 最近更新していない理由は、以下の理由で開発環境のPCが使えない状態にあるためです。 Google Developer Day 2011 Japanの参加登録を行ったところ、連続バーコードリーダーのおかげでTop Favorites枠にみごと当選した。去年に続き2年連続のTF枠での参加だ。 現在は、TF枠に落ちた人と応募しなかった人と参加登録が遅れた人がSH枠を取り合う、DevQuizが行われている。去年はパックマンを作る時間がなくSH枠は諦めたが、今年は時間があるので「既に Top Favorites 枠で当選しています。 クイズの成果にかかわらず、Google Developer Day Japan 2011 に参加することができます。」と表示されているが挑戦している。 今年の難問はスライドパズルだ。これは、数学的にもあまり解明されていないのでコンピューターの処理能力をガンガン使って、正解を探す必要がある。そのため、メインPCがAtom 330である自分にはとても厳しい。Intel Core-i7 2600Kだと1日ほどで終わりそうなプログラムを作り、Atom 330に10日かけて計算させている。 PCが無いと生きていけない自分にはこの10日はとても辛い。最近買ったacerのICONIA TAB A500があるのでメールやブラウジングやYoutubeなどは問題はないが、プログラミングが出来ないのはやっぱり辛い。 あと3日ほどの辛抱だ。

昨日、「 日本語フルキーボード For タブレット 」をAndroid Marketにアップロードし、即日公開しました。 これを作成した理由は、ICONIA TAB A500を購入したが、タブレットに合ったIMEが無かったからである。 勿論、ICONIA TAB A500には、Simeji for ICONIA TABがプリインストールされている。 ただ、Simejiには欠点があった。ランドスケープ時に左右キーが表示されない。日本語入力時には、ほとんどの記号と数字が画面を切り替えないと入力できない。つまり、タブレットの画面の大きさを有効利用できない。不便だった。 Androidなので、気に入らないなら入れ換えてしまえばいい。 そこで、有料アプリ売り上げNo1を独走しているATOKを試してみた。左右キーも存在し、数字も記号も多くが表示されている。タブレット用に調整しているのだろう。さすが有料アプリである分作り込みが深い。キーの高さを調整できるオプションもあり、とても使いやすい。 だが、上下キーが実装されていなかったので、複数行の長文を打つときには不便である。 それなら、自分でIMEを作ろう。 でも、そう簡単には作れないので、オープンソースのOpenWnnを改造することにした。しかし、ソースをダウンロードし中を見てみたところ、どうしようもないくらいこんがらがっていた。１ヶ月かかっても読めそうにない。 改造は諦め、サービス部分とUI部分を１から自作し、日本語変換エンジンのみを借りることにした。それでも色々苦労した。OpenWnnが予測変換重視のエンジンであるため、複雑な仕組みになっていたからだ。（もっとわかりやすい仕組みにしてくれとOpenWnnに言いたい。） 日本語変換エンジンをサービスやUIから完全分離した設計にしたので、OpenWnn以外のエンジンにも載せ換えやすいコードになった。今後は、他のエンジンと切り替えられるようにしようと思っている。 この長文は、すべて自作 「日本語フルキーボード For タブレット」で入力した。 自分で作っておいて言うのもなんだが、長文が入力しやすい。

最近、登山や鉄道だとプライベートでも忙しいことをしていますが、このたびPicasa アップローダーをリリースしました。 Android Market でダウンロードできます。 このアプリを作ることになったのは、 日本通信(b-mobile)の制限事項 のためである。この制限で、Picasa Web AlbumsへHTTP通信をしていたアプリが使えなくなり、代替アプリを探したが存在していないことがわかり、自分で開発することとなった。 このアプリの特徴は、Picasa Web Albumsへの通信を全てHTTPSで行っており、盗聴などの心配が無い。また、Googleアカウント認証もOAuthを利用しており、パスワードの漏出が無い。 twiccaのメディアアップロードプラグインとしての実装も行っており、twiccaで画像付きツイートを行うときにインテントで連携できる。 開発していて感じることは、Androidのよいところはインテントという仕組みで他アプリと簡単に連携できるところだ。