2010年8月7日土曜日

Google App Engine ja Night Sapporo (gjns)で発表しました

最近このブログは発表資料置き場になってますけど、まぁいっか。

今日はGoogle App Engine ja NightというGAE好きな人の集まりに参加してきました。東京では盛り上がってるみたいだけど,地方では大阪に続き札幌で2箇所目なんだって。札幌も盛り上がればいいねぇ。

最近AndroidばかりでGAEに触れてないのだけど,勢いで過去の発表資料+ちょびっとググって資料を作って発表してきました。

折角なのでここに貼っておきます。

ただ、参加者の多くはJava使いの方らしく、RubyやPHPをやっている人はほぼ居なかったので、ネタとしては外していたなぁと反省…

2010年6月29日火曜日

意外に知られていないANDROIDに関する7つの常識

先日札幌IT飲み会、そしてその翌日にオープンソースカンファレンス2010北海道(OSC2010Do)に参加してきました。

IT飲み会ではプレゼンタイムというのがあって、本当は2回目から参加資格があるような感じらしいのですが、初参加の当日いきなり「作ってきましたー」と手を上げて話してきました。

んで、翌日は毎年参加しているOSCがあったんですが、日本Androidの会ブースでほぼ同様のものを展示していました。

一部からこの資料公開してよーという声があったので、このブログに貼っておきます。

内容は、 非プログラマ向けにAndroidの現状というか空気感を感じてもらえるかなーと思って作ったものです。最近Androidってどう?って思ってる人は、気軽に呼んでみてください。内容もさらっとしてますし。

2010年3月26日金曜日

AndroidとGAEの同期に関する講演資料を公開します

先日第4回日本Androidの会北海道支部勉強会で講演したんですが、その時のプレゼン資料を公開します。

内容は、データってクラウドに「も」持たせた方が何かと便利だよねーって話と、じゃーライブラリ作って定型化したらみんな使いやすいかもねーって話と、具体的な使い方の話です。

次のような使い方を前提としています。

  • ユーザはAndroid端末1台と、GAE上のサービスを同期できる。(複数台と同期できる方が楽だけど、同期方法が複雑になるので断念)
  • アクセス元のAndroid端末は、電話番号やシリアルを使って自動認識させる。(これはポン付けで動く)
  • Android内のSQLiteに保存されたデータを、そのままの形でGAE上のDataStoreにも入れておき、必要であればリカバリもできる。(データ構造によりカスタマイズが必要)
  • 基本的にHTTPリクエスト(実際にはhttps)を使ってデータを送り、そのレスポンスに対してコールバックを使って制御する。
  • RESTっぽい使い方で、CRUDあたりまでは簡単に使えそう。
  • 詳しい使い方はサンプルアプリのソースを読むべし。たった300行強(SyncTestActivity)だし。

ライブラリとサンプルアプリはオープンソースとして公開しています。

SyncTester

2010年2月14日日曜日

LDD'10 WinterのLTに飛び込んできた

前日に「まだ枠が余っているから話してみたら?」と言われたので、LT開始3時間前から資料を作り、開始直前に会場入りして、LT終わったらすぐ帰ってきた(娘の迎えがあった)。

LT自体は途中で時間切れだったので残念だったけど、せっかくなので資料晒します。

「Ajaxなサイトでもスクレイピングできるのがイイ!」で締めたかったんだけど、そこまで伝えられなかったかも。

2010年2月12日金曜日

WebViewを使ったスクレイピングの使い道

Android MLで WebViewとJavaScriptを使ったスクレイピング ってゆートピックを見つけたんだけど、現在進行形で正しくこのアーキテクチャを使ってプログラムを書いているところだったので、フォロー入れます。つーか入れずに居られない。

なんのこっちゃという方は、こちらを見てください。

WebViewを使ったスクレイピング / scraping a page using the WebView in a Service

スクレイピングにあたっての問題点

まず、自分の場合は特定ページのHTMLを定点観測するためにパーサーを書く必要があったんだけど、Javaに慣れてないので以下のような問題をどう超えようか悩んでいました。

  1. PullParserなどよりXPathを使いたい(使用されるリソース量よりコーディング手間の方が優先。とりあえず形にするにはコレ重要)
  2. 対象のページで使用される文字コードがなんだか分からない場合でも、なんとかしたい。(特にHTTPヘッダーで示される文字コードと、HTMLヘッダーで示される文字コードと、実際に使われている文字コードが違うような変態ページにも対処したい)
  3. XHTMLに準拠してないページでも、なんとかしたい。準拠してなくてもXMLパーサがなんとか使える程度ならいいんだけど。
  4. 壊れているHTML(閉じ忘れ)などでも、なんとかしたい。

ぶっちゃけ、対象ページが固定されていればあまり問題にはならないのですが、今後のため汎用的に作れないかなぁと思っていました。

解決策

んで、まぁいろいろ悩んだのですが、Android向けのアプリを書いていたのでWebView(WebKitをJNI経由でコントロールするためのGUI部品)を使えば、ほぼクリア出来るということがわかりました。

思い起こせば、昔Rubyでスクレイパーを書いていたとき、もじらのHTMLパーサ使おうかなぁと悩んだことがありまして、 理由は全く同じでした。特にHTMLが壊れていても、なんとかなるのが大きい!

特に上記2・3・4なんかはJavaでやってたら死ねたと思います。(単なる知識不足ですが)

補足

一応補足しておくと、上記1ですが、結局XPathは見送りになりました。上記2・3・4のメリットとの天秤でしたが、XPathを使うためには、Javaの外部ライブラリを使うか、JavaScriptの外部ライブラリを使うか、HTML5対応ブラウザの標準関数を使う必要があり、Androidに載っているブラウザはHTML5にはまだ対応出来ていないため、どれもちょっと微妙でした。自分の場合はDOMを使ってパースすることにしました。(DOMを使う場合でも、他の手段と比べてかなりコード量は減るはずです)

2についてはWebKit側で自動的に推定してくれます。精度はレガシーなページ(EUCやShiftJISなページ)をブラウザで開いてもまぁまぁきちんと表示されることから、まぁまぁ良いぐらいでしょうか。

3についてはブラウザ内のJavaScriptを使うことで解決しています。DOMでもXPathでも使えるはずです。個人的にはJavaでパーサを書くより好きです。

4については、WebKitが対象のHTMLを取得し、レンダリングのためWebKitのHTMLパーサーに渡した時点で、文法的に明らかにおかしい(trを閉じてないのにtableを閉じたなど)は、自動的に修正してくれます。ブラウザ内のJavaScriptからアクセス可能なのは、このパース後(修正後)のHTMLなので、スクレイピングに支障をきたすほど壊れたHTMLに出会う確率はぐっと減ります。

使いどころ

ざっと思いつくのはこんな感じでしょうか。

  • レガシーなページを含む場合のスクレイピング。最近のHTMLはXHTMLに対応しているこが多いけど、昔からある個人運営のページや、携帯向けページは未だにスクレイピングしづらいものがある。
  • 上記の発展として、「(単純にタグを除くだけの全文検索タイプではなく)タグ構造を考慮に入れたサーチエンジン」のためのクローラ&パーサ。まともにHTML解析機を作ってると死ねると思うので。
  • オートパイロット。例えばヤフオクなどで、ログインしてなかったら(特定文字を検出したら)オートパイロットモードになってログインし、指定されたページに入札を行うなど。同様のことはHTTPリクエストだけでも行えるが、今何が起こっているのか見えるのでユーザは安心かと。
  • Ajax前提のサイトなど、JavaScriptが動いてくれないと必要なデータを取得できないような場合。これが今まで出来なかった! Androidエライ!!
  • HTTP的なお作法に厳しいページへのスクレイパー。Railsなどはリダイレクトを多用するけど、自分でリダイレクト対応のコードを書くのは面倒だよね。Cookieも自動的に処理してくれるから、セッション管理が楽。Basic認証とかSSLとか数え上げれば切りが無いほど、「フツウ」にHTMLに触れるのはメリット。

で、デメリット

といいつつAndroidのWebViewも万能ではない。

  • WebViewはViewクラスを継承しているので、いわゆるUIスレッドでなければ正常に動かないかも。(下記Tips参照)
  • Javaのメリットって、比較的簡単にマルチスレッドを使えるってのがあるだろうけど、上記理由によりマルチスレッドでは動かない(可能性が高い。やり方によるのかも)
  • 上記理由により、意味不明に落ちることがある。そんときのバックトレースから、Looperの仕組みなどをきちんと理解する必要があるのかもしれない。ハマると抜け出すのに苦労する。
  • リソース大食い。ServiceからWebViewを使うことにした場合、これは頻繁に虐殺されることを指す。殺されないための手当と、殺された場合にシームレスに復活するための手当を要す。これはこれで結構面倒(かつノウハウがあまりWeb上に蓄積されていない)。また、このせい(リソース食い過ぎ)で他のServiceがまともに動かない可能性も。
  • (PCを含めた)スクレイパーとしては致命的に重い。Android内に限っても、、、やっぱり重いかも。特にHT03AのCPUではそう感じる。1GHzぐらいあればあまり気にならないかも。
  • 2つのWebViewを同時に動かすと落ちる? 不安定になる?(調査中)  JNI使う場合は、行儀良くしないとアプリではなくOSが落ちます。
  • Androidに載ってるJavaScriptエンジンって、V8じゃなかったような。。。感覚的にはJavaでXMLパーサを使うより、ブラウザ内でJavaScriptを使ってパースする方が、2〜3倍遅い気がする。(あくまで感覚値)
  • UTF8でXMLやXHTMLを返すとわかっている場合は、JavaでHTTP叩いてXMLパーサを通した方がきっと早くてリソース消費も少なくてマルチスレッドで動く。なんでもばっちこいな場合のみ、WebViewが使えるのかも。特にAndroid上で動かす必要が無いならば、他の方法とよく比較検討した方がいいかも。

Tipsというかバッドノウハウ

試行錯誤から得たノウハウをちょっとだけ。(出し惜しみではなく、もうハマリポイントを忘れたため)

  • 自分の場合、Serviceクラス(の派生)からWebViewクラス(の派生)を呼んでも、正常に動きました。WebViewを使ったスクレイピングのようにレンダリングやパラメータは調整しましたけど。この状態でActivityにバインドして毎分リクエストして24時間ぐらいは平気で連続取得に耐えていますので、お作法的にはよろしく無いかもしれないけど、実際には使えると思っています。まぁ、少なくともアプリが自分のコントロール下にある(ソースをいじれる)うちは、ServiceでWebView使ってもいいかなぁとか。
  • JavaからWebView.loadUrl("javascript:ごにょごにょ;");で、今開いているページに対して追加でJavaScriptを動かせることができる。ブックマークレットみたいな感じ。ちなみに、ここで渡すJavaScriptは相当長くても動いてくれる。
  • WebKitのHTMLパーサーにかけた後の、修正済みHTMLをJavaScript経由でJavaに取り込むこともできる・・・ハズ。JavaScriptでHTMLタグのinnerHTMLを取得するなど。ハズっつーのは、実際にやってみたけど尻切れになっちゃうから。HTMLタグの子供をループしてのinnerHTML取得だと、もう少し取れるけど、完全に取れたか確認出来ないし。。。うまくいった方はやり方教えてください。
  • ってか、NDK使って、WebKitの文字コード推定&コンバートとHTMLパーサ部分だけを使うJNI作っちゃえばいいのかも。ってか、コレAndroidの標準ライブラリに入れてくれないかなぁ。

まとめ

長くなったので、まとめてみる。

  • やんちゃなページを相手にスクレイピングを仕掛けたいならWebViewに限る
  • とくにAjaxなヤツを相手にするなら現状WebView以外の選択肢は無いように思える
  • でもこいつはクセが強いぞ。心して掛かれ

2009年6月2日火曜日

OSC2009北海道の歩き方(Webプログラマな方編)

オープンソースとして公開されているソフトウェアを一堂に集め、セミナー形式で理解を深めたり、出品ブースなどでソフトウェアに触れてみたりなどなど、オープンソース関係のお祭りであるオープンソースカンファレンス2009北海道(以下OSC2009北海道)が今年も開催されます。

日程:2009年6月20日(土)10:00-18:45

会場:札幌市産業振興センター 産業振興棟2F&技能訓練棟3F

費用:無料

OSC2009北海道には、さまざまな立場で参加する方がいらっしゃいます。OSC運営側でもそれは認識しており、どんな人が来場しても楽しめるようにオススメコースというコンテンツを用意したりしています。

これに倣って、Webプログラマコースを考えてみました。

どんな人にオススメか

まず、自分の立ち位置をまとめてみましょう。これと同じような人だと結構良い感じにオススメできると思うのです。

  • Webアプリのプログラマ。開発言語はRubyとかPHPとかJavaScriptとかActionScriptなど。Flexも使う。AndroidやiPhoneも手を出している。
  • 必要なサーバは自分でセットアップする。昔はネットワークとかサーバの構成から設計を始めたけど、技術の進化スピードが速くて数年で陳腐化したり、以外と管理に手間が掛かったり、納期まで時間が掛かる事に嫌気がさしている。
  • サーバ仮想化の技術や、クラウド(Amazon EC2/Google App Engineなど)に切り替えを実行中。
  • 一般的なWebアプリなら、自分一人で構築することができる。ソースコードのバージョン管理や、バグトラッキングシステムなどは既に業務フローに組み込まれている。
  • Webアプリに関する興味対象は、カスタマイズ可能な全文検索エンジン、集合知・レコメンドエンジン、地理情報系、自然言語解析・統計・画像認識系、少額決済系、アプリケーションレベルの負荷分散系、クラウド環境での効率的なプログラミング、Webアプリのフレームワーク(RailsとかCakePHP系)などなど
  • デザインに関してはデザイナ任せであるものの、最近のWebアプリはブラウザ互換性や、設計段階でデザインなHTML/CSSの知識を必要とするため、フォローが必要だなぁと思っている
  • なんだかんだ言っても、ソフトの世界だけで完結するモノだけじゃなく、電流を流してモーターを駆動させたり、センサーの値を読み取ってイベントを派生させるようなものが、実業務ではまだまだ必要だなぁと思っている

どんなコース?

こんな自分が自分で見たいなぁと思うOSC北海道のオススメコースとその理由を考えてみました。ただし、自分の知識レベルと興味範囲でのチョイスです。

  • 9:50 会場に到着して「ほへ〜」と言う。1FのETロボコンを見て「すげ〜」と言う。そういやGainerボードが埃被ってるけど、久々になんか作ってみるかなぁとか思う。とりあえず始まるまでパンフをふむふむ読む。
  • 10:15〜11:00 「システム監視の画期的コストダウン、今、新概念のオープンソースZABBIX/ZABICOMが課題を解決」というセミナーに参加。root貰えるレンサバやEC2などでも、システム監視は必要なので、最新動向を追う必要はあるかなと。どれくらい画期的コストダウンなのかタイトルに釣られてみる。
  • 11:15〜12:00 「textsearch_jaで全文検索」というセミナーに参加。これってPostgreSQL 8.3から標準で使えるのかな? 個人的に地理情報を扱う場合などはPostgreSQL+PostGISの独壇場だと思っているので、この組み合わせに耐えうる情報はフォローと。
  • 12:00〜13:00 昼休み。隣のイーアス札幌であんかけやきそばか、インドカレー+ナンを食う。どっちにするかは当日の気分次第。早く飯食ってブースでもゆっくり見ようかな。昼休みにミニセミナーあるかも知れないし?
  • 13:00〜13:45 「エンタープライズCMS「TYPO3」の機能紹介」というセミナーに参加。なんかあちこちで良い評判を聞くんだけど、実際には触ったことがないTYPO3。でも、知識だけあれば打ち合わせの席で「それTYPO3でやりませんか?」と言えるかも?
  • 14:00〜14:45 迷う時間帯。Git使ってなければまずそこを狙うべきだけど、もう実業務で使っているので興味なし。メール関係もノウハウの蓄積が必要な分野だと思うけど、いちいちメルサバのチューニングするより、Google Appsとかレンサバの機能を使うようにしないと、保守に手間取るしなぁ。ブースでもゆっくり見ようか?
  • 15:15〜16:00 「ホスティング徹底比較」というセミナーに参加。EC2は最低1万円/月ぐらいコストがかかるので、root要らないような案件ならレンサバの方がいいかも。国外レンサバは激安が多いけど、国内のレンサバ事情も押さえておかないと。
  • 16:15〜17:00 「[企画セッション/断絶を越えて] 技術者も覚えておくべきクロスブラウザ対応コーディングのポイント」というセミナーに参加。実は結構迷う時間帯で、Redmineを使ったこと無ければソレを、Google App Engineを使いたければDjangoを取りに行くのが良いかも。個人的にはGoogle App Engineは見送ったのでPythonを追う必要性を感じず、Redmineはワークフローに入っているので、クロスブラウザの情報を追う方が良いかなぁと。
  • 17:15〜18:45 閉会式でジャンケンして商品ゲットぉ
  • 20:00〜懇親会で飲んだくれる。実際去年の懇親会で隣だった人って、今勉強会に行ったら良く顔を見る人だったりするので、知り合い増やしたいなら参加するべき。

妄想の世界だとこんな感じだけど、実際はOSCスタッフ&Androidの会スタッフとして動かなければいけないので、セミナーに参加はできないのさぁ;-)

OSC2009北海道に参加したい方は

セミナーは予約制です。

もう既に定員近いセミナーもありますので、興味ある方は早めに申し込みどうぞ。

オープンソースカンファレンス2009 Hokkaido - 行くしかないっしょ?!

2009年3月4日水曜日

技術系勉強会に非プログラマを取り込む方法について考えてみた

非プログラマにリーチしたいというのは、技術系イベント主催者にとっての目標の一つでもあると思うので、デザイナとスーツを呼び込むためのキーワードとして、デザイナとスーツについて個人的に思っていることをまとめてみました。

例えば、技術的に濃い話をする場合でも、以下のような切り口で語れば、非プログラマにもリーチするのではないでしょうか。

何か企画をするときの参考になればと思います。

デザイナが興味ありそうなこと(とその理由)

ここでは、デザイナの定義は、Webデザイナとします。

  • メールやFTPなどの基本的なサービスのざっくりとした動作原理。目に見えるインフラ(プログラムと連動するときの考え方の基礎となるので)
  • Webシステムを構築するとき、どういう点に注意すれば効率が良く開発を進めることが出来るか(システム構築フローと、それぞれのプロセスのコスト感覚が把握できていないので)
  • 自分の能力の伸ばし方。将来構想。将来設計。自分ブランド(絵を描いたりデザインすることは人間しかできない特殊な能力なのに、その商業的な価値についてあまり深く考えてないので)
  • 使いやすいUIに対する知識(本来はUIデザインはデザイナの仕事のハズなのに、現状その知識を持っている人は僅かなので)
  • GPL系、MIT系、CCライセンスの要点とビジネス的な存在意義(基本的にはスーツと同じ理由だが、現場に近い割にライセンスに対する知識がないので)
  • CCライセンスの素材の使いどころ(ライブラリ化してうまく使えば仕事が楽になるはずなのに、うまく取り込めていないので)
  • jQueryなど、ブラウザ上でJavaScriptを使った何かを作る上で、HTMLやCSSコーディングにおいて注意した方が良い点(各種JavaScriptライブラリに対する知識が足りないので、どうやって動くのかが理解できていない)
  • 純HTMLなWebアプリ、AjaxなWebアプリ、Flashなアプリ、Windows上のGUIアプリ、モバイルアプリなどの限界と使いどころ(それぞれの知識が足りないので)

スーツが興味ありそうなこと(とその理由)

ここでは、スーツの定義は、経営者・キャピタリスト類・営業企画・OSSを使っていない企業プログラマとします。

  • どんな技術が今後伸びてくるか。その市場規模と確度(ビジネスモデル立案のヒントとするため)
  • どんな技術/OSSを使うと、どんな分野にどういう効果があるか。どういう分野に向いているか(特定技術/OSSの意味をちゃんと理解していないので)
  • OSSでどこまでできるか。どんなことはプロプライエタリ製品を使った方がよいか。その境界線についての具体例(OSSに対する経験がないので)
  • OSSを使っていて、サポートの提供が無いために困ったことの具体例。その回避策(OSSに対するリスクの把握)
  • GPL系、MIT系、CCライセンスの要点とビジネス的な存在意義(メリットやリスクを含め、ライセンスに対する知識が足りないので)
  • 自社開発OSSを使ったビジネスモデルの事例(OSSの開発が有効な自社広告となりえるという可能性は理解できるが、実際の成功可能性が想像できないので)
  • 日本以外の国でのIT事情と最新動向(ビジネスモデル立案のヒントとするため。特に相手を東京に限定しない分、道民にとってはメリットが高いように思う)
  • 市場調査やプロモーション活動や効果計測についての実際。特にコスト方面(ディレクションする上での基礎資料として)
  • IT以外での広告活動におけるコスト感覚と使い分け(テレビ・ラジオ・新聞・チラシ・勧誘員などなど。コンサルティング基礎資料として)
  • 各用途においてオススメのOSS(比較検討するコストやスキルがないため)

デザイナ・スーツ共通

  • 技術寄りの話はデザイナやスーツには届かない。同じ内容のセッションでも、非技術用語だけを使ってタイトルを付けて、その流れを使った切り口で語れば、デザイナやスーツにも届くのでは?
  • 中・長期的な技術変化の予想(リスク把握。舵切り)

使用上の注意

元々オープンソースソフトウェア(OSS)のイベントに、どうやってデザイナなどを呼び込むか、といった議論用にまとめたものです。上記「OSS」と限定している部分は、他の固有名詞(Androidとか)に置き換えても成立するかも知れません。

色々反論あるでしょうが、あくまで個人的なイメージです。何かあればコメントにどうぞ。