第7回Android勉強会での発表資料として、以下のような資料を作ってみました。
といっても、あまり時間をかけれなかったので,リンク集のような感じになっています。
去年のXperiaタッチ&トライイベント参加者が20人強だったのに比べ、今年のIS01タッチ&トライイベントでは50人の申し込みがあるなど,やはりAndroidは盛り上がってきてるなぁという印象です。
第7回Android勉強会での発表資料として、以下のような資料を作ってみました。
といっても、あまり時間をかけれなかったので,リンク集のような感じになっています。
去年のXperiaタッチ&トライイベント参加者が20人強だったのに比べ、今年のIS01タッチ&トライイベントでは50人の申し込みがあるなど,やはりAndroidは盛り上がってきてるなぁという印象です。
Androidにはバーコードスキャナってゆーアプリがあります。
オープンソースなんですがGooglerが作っているようで、Android本体の標準アプリになってもおかしいくないような品質のアプリなんですが,こいつはカメラでバーコードを写して解析するような動作しかサポートしておらず,静止画として既にバーコードなどがファイルとして手元にある場合(ネットからダウンロードしたなど)の時には使えるものではありませんでした。
で、先日ついったーで「IntentにBitmap込めて送ったら、結果が帰ってくるようなヤツ欲しいなー」とつぶやいてる人がいたので、作ってみました。
と言っても、一晩で作ったものなので,ちゃんと動いているか怪しいですが。いや、実際一部動いてないですが(汗)
欲しい人もたくさん居るっぽいので、とりあえず出来たもののAndroidプロジェクトをそのまま配布します。ライセンスは元のApache licenseを踏襲ということで。
Bitmapから解析する機能を付けたバーコードスキャナのプロジェクト
Bitmapから解析する機能を付けたバーコードスキャナ本体(デバッグキー版)
で、本来はAndroidマーケット上で流れているアプリに取り込まれてくれたほうが楽だと思うので,Google Code上のプロジェクトにパッチを提供しました。テスト用のActivityも付けたので,使い方知りたい方はこちらも御覧ください。
このページの☆を増やしてもらえると、本体に取り込まれるのも早くなるかも!?
たぶんどっかバグってると思うのですが、あまりマジメに直す気はないので、おかしいところを見つけた場合は教えてください。GitHubにでもブランチ作ります。
この資料は第二回札幌IT飲み会で発表した資料です。
たぶん、スマートフォン向けのアプリ(iPhone/Android/WindowsPhone問わず)をクライアントに提案したり、もっと進んで外注しようとしたことって、無いもしくは少ないと思うんですが,なんとなーくスマートフォンにはどんな機能があるのかは知っていても,どれくらい(時間と価格)で作れるものなのかが、いまいち感覚的に解らないのが原因なのかなーと、常々思っていました。
一番手っ取り早いのは、対応可能な企業から見積りを取ることなのですが、まだ企画段階なのに見積りを取ることに気が引けたり、どんなアプリにするかまだまとまってなかったりしていて、ウヤムヤになってしまうことが多いんじゃないでしょうか。
そこで作ってみたのが、超概略無責任見積りです。
まーもちろん正確な見積りとは程遠いですが,プログラムのことは全然解らなくても,なーんとなくの超概算ぐらいはつかめるんじゃないでしょうか。
とはいいつつ、この見積りへ入力する条件として、画面数やボタンの数などを把握する必要があるので,紙に画面を書けるぐらいの知識(Webシステム見合いでOK)は必要となるので,実際にはWeb屋さんが使うための手法となります。
手法としては,
の2つを考えてみました。
詳しくはこちら。
ここで使っているシートは超概略無責任見積り計算シートにアップロードしてありますので,ご自由にお使いください。OpenOfficeで作ってますがodsなので何でも開けるはずです。ただし、見積り精度的に困ったことが起きても、知らんぷりしますが。。。詳しくはスライド確認のこと
で、こんなの作っちゃったら、詳しい人から「全然ちげーよバーカバーカ」って言われるのは目に見えていますw。まぁ当然全然違うと思ってるのですが,逆にスマートフォンプログラマの目線で、受注金額と単価から逆算して、単位日数の精度を向上させることができると思うのです。
上記計算シートの2ページ目に、(至極簡単ですが)プログラマ向けに逆算用のシートを用意したので,自社案件に置き換えて単位日数を逆算してみてください。
もし可能なら、精度向上に向けたサンプルとして逆算した単位日数を教えてもらえると嬉しいです。一応収集用としてフォームを用意してあります。
もしサンプルがある程度集まりましたら、改訂版を公開しようと思っています。
最近このブログは発表資料置き場になってますけど、まぁいっか。
今日はGoogle App Engine ja NightというGAE好きな人の集まりに参加してきました。東京では盛り上がってるみたいだけど,地方では大阪に続き札幌で2箇所目なんだって。札幌も盛り上がればいいねぇ。
最近AndroidばかりでGAEに触れてないのだけど,勢いで過去の発表資料+ちょびっとググって資料を作って発表してきました。
折角なのでここに貼っておきます。
ただ、参加者の多くはJava使いの方らしく、RubyやPHPをやっている人はほぼ居なかったので、ネタとしては外していたなぁと反省…
先日札幌IT飲み会、そしてその翌日にオープンソースカンファレンス2010北海道(OSC2010Do)に参加してきました。
IT飲み会ではプレゼンタイムというのがあって、本当は2回目から参加資格があるような感じらしいのですが、初参加の当日いきなり「作ってきましたー」と手を上げて話してきました。
んで、翌日は毎年参加しているOSCがあったんですが、日本Androidの会ブースでほぼ同様のものを展示していました。
一部からこの資料公開してよーという声があったので、このブログに貼っておきます。
内容は、 非プログラマ向けにAndroidの現状というか空気感を感じてもらえるかなーと思って作ったものです。最近Androidってどう?って思ってる人は、気軽に呼んでみてください。内容もさらっとしてますし。
先日第4回日本Androidの会北海道支部勉強会で講演したんですが、その時のプレゼン資料を公開します。
内容は、データってクラウドに「も」持たせた方が何かと便利だよねーって話と、じゃーライブラリ作って定型化したらみんな使いやすいかもねーって話と、具体的な使い方の話です。
次のような使い方を前提としています。
ライブラリとサンプルアプリはオープンソースとして公開しています。
前日に「まだ枠が余っているから話してみたら?」と言われたので、LT開始3時間前から資料を作り、開始直前に会場入りして、LT終わったらすぐ帰ってきた(娘の迎えがあった)。
LT自体は途中で時間切れだったので残念だったけど、せっかくなので資料晒します。
「Ajaxなサイトでもスクレイピングできるのがイイ!」で締めたかったんだけど、そこまで伝えられなかったかも。
Android MLで WebViewとJavaScriptを使ったスクレイピング ってゆートピックを見つけたんだけど、現在進行形で正しくこのアーキテクチャを使ってプログラムを書いているところだったので、フォロー入れます。つーか入れずに居られない。
なんのこっちゃという方は、こちらを見てください。
WebViewを使ったスクレイピング / scraping a page using the WebView in a Service
まず、自分の場合は特定ページのHTMLを定点観測するためにパーサーを書く必要があったんだけど、Javaに慣れてないので以下のような問題をどう超えようか悩んでいました。
ぶっちゃけ、対象ページが固定されていればあまり問題にはならないのですが、今後のため汎用的に作れないかなぁと思っていました。
んで、まぁいろいろ悩んだのですが、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に出会う確率はぐっと減ります。
ざっと思いつくのはこんな感じでしょうか。
といいつつAndroidのWebViewも万能ではない。
試行錯誤から得たノウハウをちょっとだけ。(出し惜しみではなく、もうハマリポイントを忘れたため)
長くなったので、まとめてみる。