2009年06月27日

突然すいません。
livedoorの広告の多さにちょっと嫌気が差してしまい
はてなに引っ越すことにしました。

http://d.hatena.ne.jp/mobylet/


今後はこちらでよろしくお願い致します。
(お手数をお掛けしてすいません。。。)

mobylet at 04:49コメント(0)トラックバック(0) 

2009年06月25日

mobyletにはブラウザサイズ(特に横幅)のxx%のサイズで画像を動的に変換/出力/表示する機能があります。
今日はここに着目して色々試してみたのですが。。。

0.1.0バージョンではGIF/PNGに対して処理を掛けると
非常に粗いものになって、使い物にならなくて。
特に透過GIF/PNGの場合はひどいものでした。。。


Java標準やJAI/JMFといったJavaの画像処理ライブラリはいくつかありますが
mobyletはあくまでも「簡単に導入できてすぐ使える」をポリシーにやっていきたいので
やるならJava標準(javax.imageあたり)で出来るところまでやってみようと思い
今日は一日中、画像と格闘していました。


結果的にはそこそこマシなレベル
(実際に使えるかと言われれば、使っても良いと判断する人もいるだろうくらい)
にはなったと思います。(JPEG/GIF/PNG共に)


実際mobyletに内包しているリサイズ処理はこんな感じ
※0.7.0-SNAPSHOT


-----

BufferedImage sourceImage = ImageIO.read(imgStream);
int imgWidth = sourceImage.getWidth();
int imgHeight = sourceImage.getHeight();
if (width != null && height != null) {
    imgWidth = width;
    imgHeight = height;
} else if (width != null && height == null) {
    imgHeight = (int)(imgHeight * (double)width/(double)imgWidth);
    imgWidth = width;
} else if (width == null && height != null) {
    imgWidth = (int)(imgWidth * (double)height/(double)imgHeight);
    imgHeight = height;
}
//Dest-Image
BufferedImage rescaledImage = null;
if(sourceImage.getColorModel() instanceof IndexColorModel ) {
    rescaledImage =
        new BufferedImage(
                imgWidth,
                imgHeight,
                sourceImage.getType(),
                (IndexColorModel)sourceImage.getColorModel());
} else {
    if(sourceImage.getType() == 0) {
        rescaledImage =
            new BufferedImage(
                    imgWidth,
                    imgHeight,
                    BufferedImage.TYPE_4BYTE_ABGR_PRE);
    } else {
        rescaledImage =
            new BufferedImage(
                    imgWidth, imgHeight, sourceImage.getType());
    }
}
//Alpha-Setting
if(rescaledImage.getColorModel().hasAlpha() &&
        rescaledImage.getColorModel() instanceof IndexColorModel) {
    int transparentPixel =
        ((IndexColorModel)rescaledImage.getColorModel()).getTransparentPixel();
    for(int i=0; i<rescaledImage.getWidth(); ++i) {
        for(int j=0; j<rescaledImage.getHeight(); ++j) {
            rescaledImage.setRGB(i, j, transparentPixel);
        }
    }
}
//Draw
rescaledImage.getGraphics().drawImage(
        sourceImage.getScaledInstance(imgWidth, imgHeight, Image.SCALE_AREA_AVERAGING),
        0, 0, imgWidth, imgHeight, null);
boolean result =
    ImageIO.write(rescaledImage, codec.name(), outputStream);

-----


色々調べたのですが、やはり透過GIF/PNGの場合の画像変換に関しては正攻法ではなかなか上手く出来ず、
上でのコメント「Alpha-Setting」部分で変換後画像の全pixelにカラーモデルを指定することで
なんとか透過を表現することが出来ました。
(画像のタイプ次第ではこれすら上手く効かない場合もあるらしいですが)


ここの処理はinterface化された部分で
別の実装を挟み込むことも出来るようになっているので
実際にはImageMagickを叩くような感じの実装を差し込んで
本番運用するのが現実的かもしれませんね。


また、これに伴って0.7.0-SNAPSHOTでは以下の実装も盛り込みました。

(1) URL(HTTP/HTTPS)指定の画像も動的にリサイズ可能になりました
(2) ファイルキャッシュ機能も搭載


(1)は別サーバや別システム上に存在する画像「http://hoge.com/image.jpg」などを指定すると
その画像を端末ブラウザに合わせたサイズに変換して表示できるようにしたというもの。

(2)はローカル、URL指定関わらず、一度加工したサイズの画像をファイルキャッシュして、
同じサイズを指定したリクエストが来た場合は、そのファイルデータを返却するというもの。
これで2回目以降のリクエストに大して、ものすごくサーバの負担が減りました。

実際にはローカルファイルの場合は最終更新日時、URL上の画像の場合はLast-Modifiedヘッダの値を見て、
以前キャッシュした情報と、日時が一致していればキャッシュを使い、
一致していなければ新しい画像を読み込んで、変換した画像をキャッシュし直すという構造を取っています。


ただ悩ましいのがこれだとキャッシュファイルがどんどん増えていくので
Deleteする必要があるかなぁと思っているところです。
フレームワークでDeleteってちょっぴり抵抗感があります。。。



ここの画像変換系の機能は
結構期待してくださってる方が多いので
もうちょい頑張って、実運用に耐えるレベルまで押し上げたいと思います。

mobylet at 02:16コメント(2)トラックバック(0) 

2009年06月24日

先日の0.6.0のリリースに伴い
地味にドキュメントも少しずつアップデートしています。
昨日、一番力を入れたページがこちら

http://mobylet.sandbox.seasar.org/guides/


初めてmobyletを使う方向けのガイドページ。


リファレンスとかも充実する必要があるのは承知しているのですが
現状では使ってもらう、触って貰うことが先決だと思うので
まずはこれを見て、触って貰えたら嬉しいです。


今日はひとつ機能のリクエストがあったのでそれを唸りながら作ってました。
内容は
「HTTP通信先の画像をリサイズして表示したい」
というなかなか素敵な機能。

これと画像リサイズファイルのキャッシュ化の両機能を一気に片付けようと思って
えっちらえっちらやっておりました。


機能的にはURLを指定して、その画像をブラウザサイズに合わせて表示することはもちろん
ローカルディレクトリも指定できて、FileInputStreamベースで取って来た画像も
普通に指定出来ると良いだろうと思って作ってたのですが
後者は「クエリ次第でどんなパスでも指定できたらセキュリティ的に問題」なので
ベースのパス(設定可能)配下以下しか見れないように実装してみました。
ちょっと不便かもしれませんが、OSコマンドインジェクションまがいの攻撃が出来てしまうより
ずっとマシかな、という風に思っています。


前者のURL指定の方はProxyを指定出来ないと
色々困る人がいるだろうなぁと思い(自分が一番困った。。。)
そのあたりの指定が出来るようにコンフィグファイル(mobylet.xml)の項目を増やしたりしていました。
(そろそろちゃんとDTDも作った方が良いかな)


-----

なんでイキナリ0.6.0になったんですか?と聞かれたのですが
Webとメールがmobylet的には2大機能群になり、
そのそれぞれの機能の根幹部分は大方出来たので
1.0.0がイメージしている便利機能も含めたフルセットリリースと考えて逆線を引くと
現在はα1版で0.6.0くらいかな、という風に位置どったところです。

※最初の0.1.0はカンファレンスに間に合わせるためのものという感じでしたし。


こっからは機能拡張や新機能を繰り返しながら0.7、0.8と上げながら
BugFixをマイクロバージョンでアップしていきたいと思います。


晴れて1.0.0になるまでは
ひとまず猪突猛進な感じで頑張っていきます。

mobylet at 02:36コメント(0)トラックバック(0) 

2009年06月23日

ちょっと最近疲れ気味なので
「癒し」なデザインに変えてみました。

猫になりたいにゃー。

mobylet at 00:45コメント(2)トラックバック(0) 
先ほどmobylet-0.6.0をリリース致しました。

一番大きな機能としては

・ 絵文字を含むメール送信I/Fを搭載
・ Google App Engine for Javaに対応(一部)

というところになります。


一旦大筋はこの0.6.0の機能でしばらくFixして
ちょっとした便利な機能をちょこちょこ付け足して行こうと思っています。
(画像オートリサイズ機能のファイルキャッシュ化とか)


あとはドキュメントが山盛り残ってます。。。。
ホントはこれを仕上げてからリリース告知したかったんだけど
もし、使ってくれる人がいるなら待たせるのもどうかな、と思って先にライブラリの公開をしました。


-----

Mail送信部分のドキュメントが間に合ってないので
このブログでちょろっと書かせてください。

mobylet-mail-0.6.0.jarをdependencyに入れて貰ったら取り合えずOK。
送信ロジックはこんな感じ。


MobyletMessage message =
        MobyletMailer.createMessage("test@docomo.ne.jp");

MessageBody body = new MessageBody();
body.setHtml("<html><body>テストHTML</body></html>");
body.setText("テストTEXT");

message.from("info@mobylet.org")
    .subject("テストメール")
    .setBody(body);

MobyletMailer.send(message);



一応これでデコメールになります。
(全然デコレーションされてないけど。。。)


bodyにsetTextしかしなかったらtext/plainのメール。
逆にsetHtmlしかしなかったらtext/htmlのメール。
両方したらデコメール、という訳です。


件名や本文に絵文字を入力してもOKです。
createMessageの引数に宛先を入れるんだけども
そのメールアドレスを解釈して、勝手にそのキャリアの絵文字に変換してメールしてくれます。

※他に宛先を追加したければmessage.to()メソッドで追加可能。
※但し、文字コードはcreateMessageの引数に指定したキャリアで固定。


-----


チュートリアル作るのしんどいなぁ。。。
手伝ってくれる方いれば是非!

mobylet at 00:42コメント(0)トラックバック(0)リリース&告知 

2009年06月18日

いやー、しかしメールの疎通テストが大変です。。。
mobylet→携帯へのメールです。

Webとかだとちょろっと立ち上げて
携帯実機で確認するのが大変とは言っても
emobileを持ってたりすると結構簡単です。

■emobileでノートを簡単サーバ化(Tomcatバージョン)
(1)Tomcatのserver.xmlでHTTPのポートを8080→80に変える。
(2)ipconfigなんかで自分のIPを調べる。(http://ddo.jp/とかにアクセスするのもアリ)
(3)EclipseでTomcatを起動。(携帯実機のアクセスでデバッグできる)
(4)IP直叩きでアクセスする。


以上。簡単でしょ?

ポートを80に変えるのは一応emobileでもポート制限を掛けているらしく
普通にやったら8080でアクセスできないみたいなのです。
(オープンする方法あるのかな?)

なので80番を開けるのですが
80ならemobileも想定ポートのようで、何もしなくても普通にListen出来ます。
(Windowsでやる場合は80をファイヤーウォールでブロックしないように変更しないといけない)


とまぁ、WEBだとあまり気にすることないのですが
メールだとそうも行かない問題があります。


■SPFレコード
基本的にメールのなりすまし防止策として強固なSPFレコード照会というものを各キャリアでやってます。

docomo:
http://www.nttdocomo.co.jp/service/communication/imode_mail/notice/sender_id/
au:
http://www.au.kddi.com/service/email/support/chui/spf_record.html
SoftBank:
http://mb.softbank.jp/mb/information/details/060328.html


厳しさで言うと
docomo, au > SoftBank
です。


docomoとauは、
ユーザの設定次第でDNSにSPFレコードをきちんと設定してないとメールが届かない!という事態になります。
なのでこのあたりもしっかり実験くんをしようと思うと非常にしんどい感じです。。。

SoftBankは受信可否の設定は無いような気がしますが。。。
(あるのかな?)


あとは所感なのですが
どうもSPFレコードを登録していないEnvelope-FROMからメールを送ると
docomoとauはやたら受信までの時間が長いように感じます。。。
これは気のせいなのかなぁ。。。
(場合によっては数分〜数十分くらい)


そもそもローカルのメールサーバ立てるのも苦手なので
四苦八苦しながら頑張ってます。
早く絵文字入りのメールがしっかり飛んでくれ〜。


-----

ちなみにSPFレコードを作るのがしんどい人はここがオススメ。
http://www.openspf.org/



mobylet at 22:51コメント(0)トラックバック(0) 

2009年06月17日

今日はめっこりメールとにらめっこです。
ホントに携帯のメールはしんどいですね。。。

携帯メールも思いっきり絵文字と文字コードと格闘するのですが
その理由を携帯メールの仕様と一緒に紐解いてみます。

■携帯が受信可能な文字コード(content-typeに記述するcharset名)
docomo:
    shift_jis、iso-2022-jpで受信可能
au:
    shift_jis、iso-2022-jpで受信可能
softbank(3G):
    utf-8、iso-2022-jpで受信可能

他にも端末を限定すれば受信出来る文字コードはあるのですが
全体的に大丈夫と言える文字コードは上に書いたものくらいです。

さらには

■携帯が絵文字を受信可能な文字コード
docomo:
    shift_jis
au:
    shift_jis、iso-2022-jp
softbank:
    utf-8

となります。
これで大体ひとつに決まったのですが、auだけ決まっていないので
諸々楽な方法でmobyletはshift_jisを選択しました。

しかし、実はauにはとんでもない落とし穴があって
「Webで使う絵文字と、メールで送る絵文字のコードが違う」
という非常に残念な仕様があるのです。。。。


実際、Webのsjisの絵文字コードと、メールのsjisの絵文字コードには
次のような関係があります。

Web(sjis)の絵文字1バイト目のコード値→メールの絵文字1バイト目のコード値
F6→EB
F7→EC
F3→ED
F4→EE
※2バイト目はどちらも同じ


このあたりではまった人でないと良く分からないとは思いますが
こんな感じでマッピングを変えないといけないのです。


続いて、今度はJavaMailとの相性なんですが
mobyletではauのメール用の文字コードを「x-mobylet-mail-sjis-au」という名前で持っています。
普通にメールに対してこの文字コードを適用しようとすると
content-typeにこの文字コードを指定しなくてはいけないのですが
そうすると今度は端末が「x-mobylet-mail-sjis-au」を読めず(読めるわけがない。。。)
メールが文字化けして見えてしまいます。。。


なのでJavaMail Ver 1.4以上を使用して
次のような感じでcontent-typeと実際の文字コードを別のものにしてあげれば
やっと送りたかったメールの形が作れます。

---------------------------------------------------------------------
        ByteBuffer buf = null;
        try {
            buf = ByteBuffer.wrap(source.getBytes("x-mobylet-mail-sjis-au"));
        } catch (UnsupportedEncodingException e) {
            throw new MobyletRuntimeException("Unsupported Charset = " + encodingCharset, e);
        }
        DataSource dataSource =
            new ByteArrayDataSource(
                    buf.array(), APPLICATION_OCTETSTREAM
            );
        MailPart part = new MailPart(new DataHandler(dataSource));
        part.addHeader(TRANSFER_ENCODING, ENCODING_7BIT);
        part.addHeader(CONTENT_TYPE,
                TEXT_PLAIN + "; charset=\"" + "shift_jis" + "\"");
---------------------------------------------------------------------


と、そんなこんなで絵文字入りのメールを送信するためのライブラリも
本日ようやく多少動作するものになりました。
(subjectに絵文字が入ったりするのも一応頑張って対応しました)

しかし、GAE/JのMailApiは上手く動いてくれないので
一旦GAE/Jは非対応という形でメールのライブラリを公開する方向で進みたいと思います。


まだテストが不十分なのでもう少し叩いてみますが
ある程度動作すれば公開しようと思うので
もうしばらくお待ちください。

-----

(番外編)
昔、docomoに絵文字入りのメールを送信するために
なんとかiso-2022-jpで送信出来ないものか?と苦悩したことがあります。
結果、出来たのですが、その方法が今考えると凄くて
絵文字を除く2バイトコードをx-windows-iso2022jpでencodeして
絵文字をJISでいう単バイトコードと扱わせて(SI/SOしない形)
その絵文字のみSJISでエンコードしたバイナリをぶちこんでみたら
ビックリ仰天、docomoの端末で読めたのです。
携帯の世界は奥が深いです。。。

mobylet at 22:32コメント(0)トラックバック(0) 

2009年06月16日

竹内(stakeuchi)です。

昨日GAE/Jに対応したと思っていたら(0.1.1-SNAPSHOT)
うっかり絵文字関連のインターフェースを確かめてなかったので
#完璧に忘れていて。。。
慌ててWebApplicationのlibフォルダに突っ込んだら
普通に効いた。

mobyletの仕様として
文字コードがロード出来なかった場合、
docomoとauのデフォルト文字コードをUTF-8として解釈し、
絵文字の変換処理を行わないようにしていたので
絵文字を使わないモバイルサイトを構築する場合は
mobylet-charsetが無くても問題無いようになっているのです。


なので「動作したー」と思って完璧に忘れていたのですが。。。


そもそも、何で文字コードのjar(mobylet-charset)を
lib.extフォルダに突っ込んだり、-D.ext.lib.dirを指定しなきゃいけないかって話を
カンファレンスで出来なかったので
備忘録を兼ねてここに書いておきたいと思います。


■CharsetはSystem-ClassLoaderが読み込む
Charset.forName("charsetName")
のメソッドでCharsetインスタンスを取得出来るようにするためには
java.nio.charset.spi.CharsetProviderが初期化する際にCharseの存在を知らししめる必要があるので
以下のことをしないといけません。

(1) キャラセットのjarの中にMETA-INF/services/java.nio.charset.spi.CharsetProvider
というファイルを作って、自作したProviderクラスを記述しておく。
(2) 自作したProviderから自作したCharsetを呼び出し、charset名を関連付けておく
(3) 最下位のクラスローダ(System-ClassLoader)が読む位置にjarを配置する


Tomcatなどの場合
System-ClassLoaderの上に
Tomcatの共通モジュールを読むClassLoaderが居て(common/lib)
その上にTomcatの各AppのClassLoaderが居ます。(WEB-INF/lib)


このためTomcatレイヤーにjarを配置してもCharsetProviderが読めずに
文字コードが使える状態にはなりません。
なのでJRE_HOME/lib/extフォルダに配置するか
それが難しい場合、JVMパラメータを指定してext.lib.dirを指定して、文字コードをロードさせる必要があります。


これが一般的なのですが
JettyやGAE/Jの場合(GAE/Jの本体はJettyなのか何なのか分からないけど)
WebAppサーバ自体がスタンドアロン型でjavaからキックされていて
webapp上に配置したライブラリもSystem-ClassLoaderで読み出しているように見えます。
このため、GAE/Jでは文字コードが上手くロードされたのだと思います。


このあたりはしっかりドキュメント化したいですね。
#ハマルと酷いところなので。

-----

今日はメールのインターフェース(mobylet-mail)を作ってました。
一度激しく携帯メールのI/Fライブラリは作ったことがあるので
ナレッジだけはあるのですが、さすがに激しく大変です。。。


とりあえず各キャリアに絵文字入りの単純なテキストメールが送れるようなI/Fが出来たら
一度SNAPSHOTででも公開しようと思っています。

mobylet at 23:31コメント(0)トラックバック(0) 
竹内(stakeuchi)です。
お疲れ様です。

今日は暇を見つけてはGAE/J(Google App Engine for Java)対応をしていました。
リンクを押して英語のサイトが出てくるという
日本人には非常にモチベーションが落ちるGoogle先生のサイトに泣かされながら
なんとかかんとかやってました。

-----

まだまだ最低限の機能しかないmobyletですが
GAE/Jで動かそうとすると、いきなりJarの中にあるリソースファイルが読めずに吹っ飛びます。

mobyletには現時点で主要なリソースファイルが3種類(全7ファイル)有り、
(1) mobylet.properties
(2) 端末情報プロファイル(3種類)
(3) 絵文字変換マッピングXML(3種類)
これらのファイルをリソース外から、絶対パスで読めるような仕組みを作らないと
しっかりとしたGAE/J対応にはならないなぁというところに行き着きました。

そもそもの(1)がclasspathの通っているディレクトリ上から読むという
いきなりイケテナイ作りだったので、まずここをMobyletFilterのInitParameterでも書けるように変更。(↓こんな感じ)

---------------------------------------------------------------------
    <filter>
        <filter-name>mobyletFilter</filter-name>
        <filter-class>org.mobylet.gae.http.GaeMobyletFilter</filter-class>
        <init-param>
            <param-name>mobylet.config.dir</param-name>
            <param-value>WEB-INF/resources/</param-value>
        </init-param>
    </filter>
---------------------------------------------------------------------

残りの二つもmobylet.propertiesでディレクトリを指定できるようにして、一先ずオッケイ。

#そもそもリソースファイルへのパスをどう指定すれば良いか分からず色々実験して
#結果「war」ディレクトリからの相対パスでいけることを発見。
#ということで「WEB-INF/resources/」で不可視ディレクトリへの配置と読み込みが出来ました。


しかしその後いろんなことにはまる。。。。

■web.xmlで<jsp-config>の<include-prelude>が効かない
■<%@page pageEncoding="UTF-8"%>って書かないと文字化け
■jpgへのアクセスでFilterを通過しない


画像の動的リサイズ(端末のブラウザ幅に合わせて)機能は一つのウリなので
これがGAE/Jで使えないとちょっと痛いなぁと思いながら
主にここの対応に情熱を使いました。


色々調べるとGoogleにImage APIがあるので素直にそれを使うようにした方が良さそうだったので
mobylet-gaeextensionプロジェクトを立ち上げて
Servletを通過させるような形で画像リサイズが出来るようになりました。


もしこのあたりの実装で気になる方がいらっしゃったら
mobyletのSVNに「mobylet-example-gae」があるので
こちらから全貌を見ることが出来ます。

そしてこのサンプルは今実際に動作してます。

【mobylet-GAE/J対応】
http://mobylet-example-gae.appspot.com/index.jsp
#Ver 0.1.1-SNAPSHOT



やはりJavaで携帯サイトってハードルが高くて

■絵文字周りの実装の難解さ
と共に
■ちょっと試してみるにもGlobalに公開しないと実機で見れない
■安いレンタルサーバなんかはJavaAppServerのインフラが無い(お金がかかる)

なんていう問題があると思うんです。


でもこれが「mobylet+GAE/J」の組み合わせでハードルが下がれば
モバイルコンテンツ市場を牽引するくらいの
Javaエンジニアのモチベーションを下げない施策になるんじゃない?
なんて個人的に思いながら今回対応していました。


個人的にGAE/Jは制限多くて好きじゃないですが
これで簡単にJavaで作った携帯サイトを検証出来ると思うと
非常に使えるなぁー、と一人わくわくしています。

-----

近いうちにmobyletのサイト
http://mobylet.sandbox.seasar.org/
にもexampleをアップするので
是非みなさん遊んでみてください。

mobylet at 00:19コメント(0)トラックバック(0) 

2009年06月14日

お疲れ様です、竹内(stakeuchi)です。

Seasar Conference 2009 Springに行ってきました!
半分喋ること、半分聞くことを目的に行ってきました。

-----

今までOSSのコミュニティのようなところには顔を出すこともそう無かったので
しっかりとこういう雰囲気を感じるのは初めてで、新鮮でした。

。。。というか大学から理系で今こんな仕事していて
土曜とはいえ法政大学のキャンパスには「普通の女の子」がいてビックリしました。
ああ、普通の人はこういう世界で生きているんだろうか、と
ちょっぴり浮世離れした自分がいるような気がしたりと、
そんなことを考える経験も出来ました。

-----

さて、本題に戻りますが
お仕事でお付き合いのある久保さん(DBFlute)、竹添さん(S2Click他)、菅谷さん(S2Portlet他)と
久々(?)に会って他愛も無い話をしたり、情報交換したり、
楽しくも有益な時間を過ごしながら
彼らのセッションを軸に見てきました。

竹内はDBFluteユーザでかつmavenユーザでもあるので
今回のmaven-pluginは画期的でした。
菅谷さんの印象が「片手間に作ってみました」くらいの印象だったのですが
ビックリするくらい高機能で、シビれました。
早速うちの今の案件で使ってみたいと思います。

竹添さんのセッションは事例紹介枠ということで15分。
残念ながら面白そうな部分がタイムリミットで割愛。。。。
これは非常に残念でした。。。

-----

さて、自分の方はというと
スライドが45枚にデモ有りということで、さすがにちょっと速めの展開になってしまいましたが
なんとか時間いっぱいいっぱいに収まりました。

前半がモバイルのお勉強、後半がmobyletの話だったのですが
前半に30分程度使ってしまったので、
あまり詳しくmobyletの話が出来なくて
「こんなんで使って貰えるのだろうか。。。」
という一抹の不安を残してしまいましたが
まだ、ver 0.1なので、次のカンファレンスでリベンジして、布教活動頑張りたいと思います!

今回の目玉(?)というかポイントだった
■QRコードでデモが触れる
■たった2行で現在地がGoogle Mapで表示できる
■ブラウザサイズに合わせて動的に画像をリサイズさせられる
というところで、
反響をいただけたのが嬉しかったです。

何より、良し悪し関わらず反響があったというのは
それだけJavaで携帯WebAppを作る(作ったことがある)人がいるということだと思うので
ニーズがあるのか分からないものを作っていた僕としては
それが何より嬉しいことでした。

これからも頑張れそうな感じです。

-----

セッションのスライドは、近くSeasar Conferenceのページにアップされると思うので
是非そちらもごらんになってください。
(一部、あまり口外出来ないスライドは削除しています)

これからは
メールインターフェースの部分とGAE対応に精を出しつつ
ドキュメントのクオリティとボリュームを上げていきたいと思います。


最後に
本日はmobyletのセッションにご来場頂き、本当に有難う御座いました!

mobylet at 00:03コメント(8)トラックバック(0) 
記事検索
プロフィール

stakeuchi

月別アーカイブ
  • ライブドアブログ