北から南や西を見て思うこと

オープンソースなんですがGooglerが作っているようで、Android本体の標準アプリになってもおかしいくないような品質のアプリなんですが，こいつはカメラでバーコードを写して解析するような動作しかサポートしておらず，静止画として既にバーコードなどがファイルとして手元にある場合(ネットからダウンロードしたなど)の時には使えるものではありませんでした。

やりましょう!

で、先日ついったーで「IntentにBitmap込めて送ったら、結果が帰ってくるようなヤツ欲しいなー」とつぶやいてる人がいたので、作ってみました。

と言っても、一晩で作ったものなので，ちゃんと動いているか怪しいですが。いや、実際一部動いてないですが(汗)

欲しい人もたくさん居るっぽいので、とりあえず出来たもののAndroidプロジェクトをそのまま配布します。ライセンスは元のApache licenseを踏襲ということで。

Bitmapから解析する機能を付けたバーコードスキャナのプロジェクト

Bitmapから解析する機能を付けたバーコードスキャナ本体(デバッグキー版)

で、本来はAndroidマーケット上で流れているアプリに取り込まれてくれたほうが楽だと思うので，Google Code上のプロジェクトにパッチを提供しました。テスト用のActivityも付けたので，使い方知りたい方はこちらも御覧ください。

送ったパッチのissueページ

このページの☆を増やしてもらえると、本体に取り込まれるのも早くなるかも!?

たぶんどっかバグってると思うのですが、あまりマジメに直す気はないので、おかしいところを見つけた場合は教えてください。GitHubにでもブランチ作ります。

スマートフォンの超概略無責任見積りの算出方法を考えてみた

2010-09-19T11:12:00.002+09:00

この資料は第二回札幌IT飲み会で発表した資料です。

問題点

たぶん、スマートフォン向けのアプリ(iPhone/Android/WindowsPhone問わず)をクライアントに提案したり、もっと進んで外注しようとしたことって、無いもしくは少ないと思うんですが，なんとなーくスマートフォンにはどんな機能があるのかは知っていても，どれくらい(時間と価格)で作れるものなのかが、いまいち感覚的に解らないのが原因なのかなーと、常々思っていました。

一番手っ取り早いのは、対応可能な企業から見積りを取ることなのですが、まだ企画段階なのに見積りを取ることに気が引けたり、どんなアプリにするかまだまとまってなかったりしていて、ウヤムヤになってしまうことが多いんじゃないでしょうか。

やりましょう!

そこで作ってみたのが、超概略無責任見積りです。

まーもちろん正確な見積りとは程遠いですが，プログラムのことは全然解らなくても，なーんとなくの超概算ぐらいはつかめるんじゃないでしょうか。

とはいいつつ、この見積りへ入力する条件として、画面数やボタンの数などを把握する必要があるので，紙に画面を書けるぐらいの知識(Webシステム見合いでOK)は必要となるので，実際にはWeb屋さんが使うための手法となります。

手法としては，

積み上げ
Webシステムの見積からのコンバート

の2つを考えてみました。

詳しくはこちら。

スマートフォンの超概略無責任見積りの算出方法を考えてみた

ここで使っているシートは超概略無責任見積り計算シートにアップロードしてありますので，ご自由にお使いください。OpenOfficeで作ってますがodsなので何でも開けるはずです。ただし、見積り精度的に困ったことが起きても、知らんぷりしますが。。。詳しくはスライド確認のこと

おしえてエライ人!

で、こんなの作っちゃったら、詳しい人から「全然ちげーよバーカバーカ」って言われるのは目に見えていますw。まぁ当然全然違うと思ってるのですが，逆にスマートフォンプログラマの目線で、受注金額と単価から逆算して、単位日数の精度を向上させることができると思うのです。

上記計算シートの2ページ目に、(至極簡単ですが)プログラマ向けに逆算用のシートを用意したので，自社案件に置き換えて単位日数を逆算してみてください。

もし可能なら、精度向上に向けたサンプルとして逆算した単位日数を教えてもらえると嬉しいです。一応収集用としてフォームを用意してあります。

単位日数サンプル入力フォーム

もしサンプルがある程度集まりましたら、改訂版を公開しようと思っています。

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

2010-08-07T01:48:00.001+09:00

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

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

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

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

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

JavaじゃないあたりのGAE事情

View more presentations from Yusuke Ohmichi.

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

2010-06-29T11:32:00.001+09:00

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

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

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

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

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

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

View more presentations from Yusuke Ohmichi.

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

2010-03-26T12:51:00.001+09:00

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

Androidとクラウドでデータを同期させるライブラリを作ってみた

View more presentations from Maimuzo.

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

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

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

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

SyncTester

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

2010-02-14T03:44:00.002+09:00

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

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

Androidのブラウザでスクレイピング

View more presentations from Maimuzo.

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

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

2010-02-12T11:46:00.003+09:00

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

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

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

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

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

PullParserなどよりXPathを使いたい(使用されるリソース量よりコーディング手間の方が優先。とりあえず形にするにはコレ重要)
対象のページで使用される文字コードがなんだか分からない場合でも、なんとかしたい。(特にHTTPヘッダーで示される文字コードと、HTMLヘッダーで示される文字コードと、実際に使われている文字コードが違うような変態ページにも対処したい)
XHTMLに準拠してないページでも、なんとかしたい。準拠してなくてもXMLパーサがなんとか使える程度ならいいんだけど。
壊れている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以外の選択肢は無いように思える
でもこいつはクセが強いぞ。心して掛かれ

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

2009-06-02T18:38:00.001+09:00

オープンソースとして公開されているソフトウェアを一堂に集め、セミナー形式で理解を深めたり、出品ブースなどでソフトウェアに触れてみたりなどなど、オープンソース関係のお祭りであるオープンソースカンファレンス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-03-04T19:24:00.002+09:00

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

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

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

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

ここでは、デザイナの定義は、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とか)に置き換えても成立するかも知れません。

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

仕事が忙しくても好きなもの作って発散させたらいいと思いますです

2009-02-26T22:56:00.001+09:00

年度末で何かと忙しい時期かとは思いますが、このブログを読んでいるような人は仕事がプログラマで、趣味がプログラミングという特殊な方が多いと思いますので、仕事が忙しくても好きなもの作って発散させたらいいと思いますです。

そのきっかけになりそうなイベントをさっくりご紹介しますので、興味ある方はご一緒どうでしょうか? (Androidに偏ってるのは趣味です)

第7回北海道開発オフ

いわゆる開発集会です。おのおの好きなお題を立てて、もくもく作ってます。自分の知らない分野も覗けるので、何気に楽しいかも。

まいむぞうがAndroidでAR関係のアプリを作ってたり、SladjReaderな方と一緒したり、組み込みでAndroid触ってる方が居たりと、何気にAndroid関係者が多いのも、おいら的には居心地良いです。Rubyistが多かったりね。

何か作りたい気持ちはあるけど、家に居ると邪魔する人や誘惑が多くてダメだと思ってるような人は、ちょうど良いイベントだと思います。

日時 / DATE : 2009/02/28 10:00 to 18:00

定員 / LIMIT : 20 人

会場 / PLACE : 有限会社オープンソース（札幌市中央区南3条西8丁目2番1号）

URL / URL : http://groups.google.co.jp/group/DevDo/

参加費 : 無料（食事などは各自手配、持込も外食も可

集合方法 : 当日現地集合

開催にあたって:

PC（＋開発環境）は持ち込みオンリー。しょぼいデスクトップはあります、使用は可ですが、インストールは不可。
ネット環境は，有線があります。無線ハブを繋ぎます。
室内飲食可、自販機もあります。

※詳しくは、こちらをご覧ください。

Sapporo Java Days 2009 Winter

日本Androidの会北海道支部が活動の拠点としている、札幌Javaコミュニティのイベントです。

浅海さんとひがさんとをお招きして、モデリングやSeasar関連のセッションを予定しています。

Android関連では、コミュニティトークとテクニカルショートセッションとして、それぞれ10分づつぐらい話すことになってます。(アプリ紹介と10分ライブコーディングを予定)

まいむぞうはスタッフとして参加する予定です。

開催要項

日時　　3月7日（土）10:00～（受付9:30）

会場　　札幌コンベンションセンター　201-202会議室

参加費　1,000円

最寄り駅　地下鉄東札幌駅（徒歩１０分）

主催札幌Javaコミュニティ

セッション概要　マインドマップ・モデリング、Agile Modegramming for Cloud、Slim3のすべて、Seasar2のすべて

※詳しくは、こちらをご覧ください。

ガラパゴスケータイにできてandroidにできない事

2009-01-31T01:08:00.000+09:00

おいらはauのW51Hを持っていて、androidが出たら買い換えようと思っています。

･･･が、冷静になってみると、iPhoneの時のように、ガラパゴスケータイに出来て、androidに出来ない事って結構あって、しかも結構致命的なモノもあるんじゃないのかな?と思ってきました。

まぁ、当然日本のキャリアさんもちゃんと考えているとは思うのですが、一応心構え+ビジネスチャンス的な意味も含めて、整理してみます。

なおケータイ使いこなしている訳じゃないので、比較対象に上がってないモノもありますし、下記は自分のケータイに付いてる機能の比較なので、キャリアや機種が違う場合は抜けがあるかも。まぁ、キャリアが違っても機能は横並びでしょうから、ガラパゴスキャリア vs Androidの構図には変わりないかと。

てか、Androidで通話してるわけじゃないし、設定画面の全メニュー調べた訳じゃないから、勘違い含んでると思うので注意!!(汗)

EZアプリから

EZメール読み上げ(使ったこと無いけど。まだandroidでは日本語読み上げは出来ない)
デコメール相当のHTMLメールの表示(いや、emailアプリでは出来るのかも知れないが、使ったこと無いので。Gmailアプリだけで十分じゃん。ケータイにおけるそれは金儲けの手段だったんだろうし、これに意味があるかどうかはわからない)
EZニュースフラッシュ(待ち受け画面にプッシュでニュースを流すティッカー。標準で付いてるアナログ時計アプリのようにティッカーも作れると思うんだけど、まだ待ち受けアプリ相当のモノは出てない。コレ何気によく使う)
EZナビウォーク(これが無いとおいら東京出張できない。androidのマップアプリと比較すると、完成度が段違いに良い)
EZ助手席ナビ(EZナビウォークの車載版。走行可能な道のみルート選定に使ったり、ナビ音声のタイミングやマップがコンビニやGSなど車用にチューニングされている。ロジックは同じでデータやパラメータは全部差し替えてある感じ)
EZテレビ(androidはまだワンセグ視聴できない)
EZFM(androidはまだラジオを聴けない。ただ、あんまり必要性も感じない)
EZ安心ナビ(ケータイを落としたときなどに場所を特定し、遠隔ロックなどの操作を行う。この機構はまだandroidには無い。これ必須だと思うんだけど･･･)
バーコードリーダー&メーカー(androidは標準状態ではQRコードを読み書きできない。Android Marketからアプリを入れれば対応可能)
live earth(地球儀アプリ。使ったこと無いけど。必要性も感じないけど。まだandroidにはgoogle earthは無い)

ブラウザ方面から

Flashが動かない(必死に対応中という話は聞こえてきた。PC版と同じ規格で動かないと意味がないので、大きな山と言える)
FlashLiteも動かない(そもそも必要ない気はする)
Javaアプレットも動かない(最近は動かなくてもあまり困らないけど)
PCサイトを見れるとはいえ、FlashもJavaアプレットも動かないので、実用にならない場合もあるかも
てかニコニコ動画見れないのは死活問題
機種固有番号に相当するモノがない(WebKitを拡張しちゃえばいいのに)
まとめて支払い系の少額決済サービスが無い(結構致命的。いや、キャリアさんは頑張ってくれるハズ)
ブラウザから位置情報を扱えない(ケータイの位置情報付きリンクのような機能が無い→Webアプリベースでは不利。どこかのキャリアとタグ仕様を合わせて、WebKitを拡張しちゃえばいいのに)
モバイルバンキング関係はPCから使えないところもあるのかも(PCサイトがあればいいけど。機種固有番号やIP縛りをしているケータイサイトもあるので)
iKnowモバイルアプリがまだ無い(androidアプリのスペック的にはPC版iKnowが作れそうではある)
日本の情報がちゃんと出る地図付き乗り換えアプリがない(時間の問題だと思う)

メール方面から

絵文字がない(必須。女の子は「特定キャリアの絵文字がカワイイ」という理由で乗り換えません)
厳密ではプッシュ配信ではない(Gmailアプリなどはバックグラウンドでプルするのであまり実害は無い。けど頻繁にやりとりするには辛いかも)
メールフィルターがない(Gmailならスパムフィルターはついてるけど、PCが無いと実用的な設定はできない。まぁ、近く解決するだろうけど)
メールアドレスの変更が出来ない(必須!! Gmailをメインに使うことを考えれば、複数のメールアドレスを切り替える機能が欲しい。POP3/IMAPなら現状で良いのかも。使い勝手知らないけど)
何かにつけてPCで設定してAndroidは使うだけ、という思想が見える(ので、android単体で買うと痛い目に遭う。現状振り分けもPCからのみ設定できる)
メールの分類や検索やソートがイマイチ弱い(基本的にGmailのタグと検索で行けるはずだけど、まだ使い勝手が悪い。ソートは対応して欲しいなぁ)
宛先入力時にアドレス帳から選択できない(ただし先頭文字からの補完機能はある。けどやっぱりアドレス帳から選ぶという選択肢も欲しいよねぇ)
宛先入力時に送信履歴や受信履歴から選択できない(やっぱこれ欲しいよね)
顔文字(普通の文字だけで顔やアクションを示したやつ)の辞書機能がない(やっぱこれ欲しいよね)
メール→添付から新規写真や新規ムービー・新規録音などへ連動できない(やっぱこれ欲しいよね)
GPS情報付加機能がない(個人的にはすごく痛い。auに慣れたせいだろうけど。現在地をgoogleマップのURLで表現したモノを出力できるようになればいいのかな。naviウォークやnavi time連動・PC向けgoogleマップ連動・ガラパゴスケータイ向けgoogleマップ連動などを選べるようになってればOK。てかそんなアプリ作ればいいのか)
アドレス帳の内容貼り付け機能がない(これも痛い。よく使うよね)
送受信履歴からのアドレス貼り付け機能が無い(これも痛い。よく使うよね)

標準機能から

モバイル辞書機能がない(Android Marketだとたぶん有料)
そもそもまだ標準機能では日本語入力できない(近く対応予定ではある)
日本語入力できないので、変換用辞書という概念も無い(将来的には必須だと思う)
キャリア側のサーバへのデータお預かりサービス的なモノがない(これは微妙。androidの仕組み上、アプリ個別ではなく、全体を通してのバックアップは難しいかも知れない。なので対応するならシステム側に仕組みが必要。バックアップは出来た方がいいよね)
アラームはまだ機能が弱い(アプリの問題。じきに解決すると思う)
日本の休日・祝日に対応してない(これ大問題。主にカレンダーアプリの話だけど、アラームなど他の機能にも影響するので)
タスクリストがない(標準搭載のToDoアプリのこと。Android Marketには腐るほどある)
テレビの番組ガイドがない(アプリがないというだけ。たぶんすぐに解決する)
標準ではテキスト編集アプリがない(Android Marketには腐るほどある。googleDocs互換のアプリでも標準で付ければいいのに)
単語登録・定型文登録・顔文字登録ができない(まぁ近く解決する気はする。特に定型文は忘れやすいID/パスワードを登録したりするので、この機能が無いとかなり不便)
エニーキーアンサーが無い(受話ボタン以外のキーを押しても受話させることが出来る機能。これぞガラパゴスの心配り)
エクステンションモードが無い(電池が残り少ないときに音やバイブを停止するバッテリ温存モード。これぞガラパゴスの心配り)
防犯ブザー(アプリがないだけ。でもまだAndroid Marketにも無い気がする･･･)
ホットダイアル(特定番号へのショートカットキーでの発信する機能。緊急時用。これぞガラパゴスの心配り。いやまて、androidのショートカット+それ用アプリ作ればできるかも)
時刻補正機能がない(G1には付いてないと思う。未確認だけど。ntpを使うのが正しい解決法かな?)
番号付加設定がない(発信時において自動的に先頭に特定の番号を付加して発信する機能。国際番号とかサービスとか?　これぞガラパゴスの心配り)
オート着信がない(正しくは未確認。イヤホン使用時に自動的に着信する機能)
着信転送サービスが無い(正しくは未確認。あんまり使わないけどね)
番号通知リクエスト(非通知番号時に番号通知で書けて欲しい旨の自動応答をする機能。まぁ欲しいよね)
割り込み通話サービス(いわゆるキャッチホン。どうすんだろね、これ)
プロフィール機能がない(必須!! よく使う機能なのに、なんで無いんだ?)
ガイドがない(いわゆるヘルプアプリ。取説見合いのテキスト+検索ができる。何気に使うかも)

設定画面から

現時点での通話料金照会などができない(キャリアさんに期待)
キャリアと契約したプランごとの料金目安やシュミレーション機能がない(キャリアさんに期待)
オンラインでの各種申し込み・変更ができない(キャリアさんに期待)
Cメールが多分送受信できない(SMSに相当。androidにはSMSアプリはあるんだけど、ホントどうするんだろう?)
音/バイブ/LEDに関しては、全体を一括設定することはできない(androidでは完全に個々のアプリごとの設定となる。ので統一感的なモノは少ないかも。理想としてはUI的にはマスターセッティングがあって、個々のアプリごとにオーバライドするのがいいんだろうけど)
全体を通してのフォントサイズ変更(androidではこういう全体的な設定変更は難しい)
メニューなどの多言語対応(今は英語だけだけど、近く色々な言語に対応予定ではある)
着信拒否やメール受信拒否など(必須だけど、どうするんだろう?　アプリ側で対応?)

ハード方面

サブディスプレイが付いてない(時間や留守電/メールは見れた方が便利)
二つ折りじゃないので、ディスプレイに傷が付きやすい。落としたとき死ねる(まぁしょうがないのかも)
FeliCaに対応してない(明らかな弱点だけど、日本独自の問題だからなぁ･･･)
ケータイクーポンに対応してない(FeliCa応用の一種。使ったこと無いけど･･･)
指紋認証がない(W51Hの独自機能。なんだかんだで使わなくなるんだけどね)
赤外線送受信できない(大問題。名刺交換代わりに自分のプロフィールを目の前と人と交換するよね)
メディアスタンドがない(大問題。G1やDevPhoneはUSB刺さないと充電さえ出来ない。不便すぎる)
キー照明がない(暗闇ではキーボードは操作できない)
物理キーでマナーモードに切り替えできない(ポケットに手を突っ込んでマナーモードにしたいよね)

どのレイヤーでサポートすべきか解らない機能

留守電って必須機能だけど、ソフト側で対応?キャリア側で対応?(これホントどうするんだろうね?)
androidはまだ動画を撮れない(近く対応予定ではある)
インデックスプリント指定や部数設定など、写真印刷のサポート機能がない(アプリがないだけの話か･･･)

はい、まとめ

ええと、予想通り、ガラパゴスケータイはすごいです。

なんつーか、揉まれて育ってきてるので使い勝手がよいのです。その点androidは筋は良いけど荒削りなのが目立つかな。

上記は勘違いも含むでしょうし、au独自の話もあるでしょうけど、それにしてもガラパゴスケータイに出来てandroidに出来ない事の数が多すぎです。

まぁ、それを補完するandroidアプリを用意できれば済む話も多いので、1/3ぐらいまで減らすのは簡単でしょうけどね。

逆に言うと、ここがビジネスチャンスなのかも。こういう風に書き出さないと、みなさん気づかない事も多いですよね。日本のケータイは進んでて、そのユーザの目も肥えていると自覚し、そこに追いつき追い越せが目下の目標かもね。ビジネスになりそうなネタも含んでいることだし、日本でのandroid端末発売時点までに、上記問題点のリストが半分になってればいいですね。(androidの強みを生かせるようにインテントで連動できるようにうまーく設計してくださいね)

AndroidでSQLiteの使い方を調べてみた

2009-01-30T22:59:00.001+09:00

まーなんせ、Androidで自立型の何かを作ろうと思ったらデータベースを使いたくなるんで、まずはSQLiteの使い方を調べてみました。

SQLiteの参考資料を探す上での注意

2008年8月中旬頃にリリースされたβ0.9とそれ以前(〜M5)で結構書き方が変わっている。サイト上のサンプルや書籍では以前の方方のものが多く、SDK 1.0ではそのままではコンパイルエラーとなってしまう。変更点はandroid情報まとめ @ ウィキ - Tips あたり参照のこと。

既存の資料と比較すると、データベースをオープンする時の方法が変わっているだけで、オープンした後は同じような使い方みたい。ここさえ押さえれば、あとはググって出てきた資料を追えば流れが解るかも。

読むべきドキュメント

android.database.sqlite.SQLiteOpenHelper

名前の通り、データベースオープンに絡む細々とした処理のヘルパークラス。

SQLiteはファイルベースのデータベースであり、MySQLみたいにサーバを持たないので、ロック制御などはアプリケーションで面倒を見なければならない。(じゃないと壊れる)

とはいえ、これは結構面倒なので、便利クラスを用意してくれたという感じみたい。

SQLiteOpenHelperのインスタンス生成に伴い、

データベースのオープン
データベースが存在しないなら、CREATE TABLE文などの任意SQLを実行可能
データベースのバージョン(SQLiteのバージョンではなく、Railsのマイグレーションのバージョンのような感じ?)が違うなら、マイグレーション用の任意SQLを実行可能

これらも一気に処理してくれて、かつ更新処理ならgetWritableDatabase()を使ってデータベースファイルのロックもしてくれる。(たぶん)

android.database.sqlite.SQLiteQueryBuilder

さらっと眺めたら、サンプルソースで使い方をイメージしてみよう。

サンプルソース

NotePadProvider.java

･･･ってな記事を1ヶ月前に書きかけて、忘れていた(汗)　かなり中途半端だけど、いいや、公開しよう。

勉強会 - 日本Androidの会（日本アンドロイドの会）にSQLiteの使い方に関するチュートリアルを書いたので、参考にすると良いかも。

Android&Java新年会@札幌を開催しました

2009-01-26T13:03:00.001+09:00

1/24に日本Androidの会北海道支部と、札幌Javaコミュニティ合同の新年会を行いましたので、どんなもんだったかレポートします。一応AndroidとJavaの合同新年会だったのですが、自分の興味範囲であるAndroidを中心に書きます。Web事業者視点なのも悪しからず。

まず、「日本Androidの会北海道支部」と言っても、現状では実際にAndroidに興味を持って集まっている人は少ないのです。いつもは札幌Javaコミュニティの勉強会に、Androidに興味があるプログラマが集まって1セッション行うような感じだったのですが、今回は後に新年会が控えていることもあり、ハードに強い方も勉強会に参加していただけました。ちょっと新鮮。

月刊Android周辺にぅす

まず、おいらが毎月やると宣言した月刊Android周辺にぅすを貼っておきます。

android_news_in_hokkaido_200901

View more presentations or upload your own. (tags: hokkaido android)

にぅすタイムラインは小さくて見えないと思うので、PDFとしてダウンロードしてから見るのが良いかも。

Androidって、Android on ケータイとAndroid on 組み込み機器という2つの視点があると思うんですが、上記はon ケータイ、以後はon 組み込み機器視点の話です。

アットマークテクノさんの講演+質疑応答

その後、アットマークテクノ実吉さんから講演いただきました。

内容は昨年11月のAndroid勉強会+αといった内容だったのですが、おいらは昨年の勉強会でスタッフをしていたこともあり、あまりちゃんと聞けてなかったので、今回は大満足でした。

新年会までの空き時間があったため、30分ぐらい質疑応答の時間があったのですが、雑談っぽく色々な話が出ました。

組み込みにおけるプログラミング技術は10年前とあまり変わってない、とか
組み込み向けLinuxでさえ最近で市民権を得てきたという世界に、Androidが入ってきたってのは刺激的、とか
ARMプロセッサとATOMプロセッサの将来性、とか
流通経路を持った大量生産と、業務用機器としての小ロット生産の考え方やコストの違い、とか
組み込みでAndroidが活かせるシチュエーションってどんなん?、とか
カーナビ屋さんは結構本気でAndroid検討しているみたいですよー、とか
Androidが載ったネットブックと、UMPCって被るよねきっと、とか
Beagle Boardってどう?、とか(これをアットマークテクノさんに聞くのってどうよ?とか)
あとなんか忘れたけど色々

後になって思ったんだけど、この延長線上で

どんな用途であれば、CPUやメモリなどのコスト増と、Androidを採用することでのソフト開発費用減(外注費含む)、もしくはクオリティ向上による価値増が釣り合うのか? (同一案件でのAndroid採用可能性検討、及びざっと数値化してみた基礎比較資料)
現状のAndroidを組み込み機器上で使う場合、足りない機能や余計な機能
流通経路を持った製品の場合、製品の特徴付けをハード的(デバイスや形状)に行うのと、ソフト的に行う(使い勝手やネットとの融合)のは、どっちがコストかかりますかね? (一概には言えないでしょうけど、ある製品について脳内で超ざっくり試算することは出来そうで、それも楽しそうかなって)
ビデオ録画で詰まるようなジジババでも容易に使えるUIってAndroidで実現できないですかね?(音声付きのタッチスクリーンを使った対話で操作するとか)

なんかをみんなで話し合えたら面白いかなぁと思いました。

質疑応答30分ってのも、新鮮で良かったかも。質問ありきのこんな感じのヤツやりたいスね。

カジュアルな勉強会の進め方 - IDEA*IDEA ～百式管理人のライフハックブログ～

BeagleBoard買うべき

osabohさんがBeagle Boardを持ち込んでLTっぽく紹介してくれました。

Beagle board 買った - でっどろっくにっき

おいらハードは全然なため、ビーグルボードって何?って感じだったのですが、ゲーム機をベースにした安価+小型の評価用ボードだったんですね。実物見て、その小ささと機能に驚きました。「Armadillo-500 の 1/5 以下」と聞いて2度ビックリした。(いろんな意味で)

当然アットマークテクノさんの前で話していたのですが、osabohさんが「自分の会社でもarmadillo-500使ってますし、業務でAndroidを使ったボードを使うなら、アットマークテクノさんをオススメします」と閉めるまで、ちょっとドキドキしちゃいましたw

新年会

ぽんぽこたぬきのかくれ家で行ったのですが、この店予想通り大人気で、みんな狭いところにギュウギュウで呑んでました。

結局新年会参加者は10人で、JavaとAndroidに分かれるかな、と思ってたら結構みなさんワイワイと楽しんでいただけたようでした。

この辺で出てた話題

組み込み技術者は、Cで自作ライブラリなどを使ってスクラッチで組むことが普通なので、Androidのようにフレームワークを使った開発に慣れてない。ってかそもそもリソースって何?ってレベルだよね、とか
ハードを統一規格にハメちゃうと安いものしか売れなくなって特色が無くなってしまうので、ハードは少々尖ってても、それを比較的安価に調整できるソフトウェアレイヤーで均すべきじゃないかなぁ、とか
まだ組み込み機器としてAndroidを採用した事例は聞いたこと無いなぁ、とか
組み込み機器として使うとなると、やっぱり誰がケツ持つかが重要だよねー、とか
札幌Javaコミュの3月のイベントは、まだ知れ渡ってないのか応募少ないんだよねー、とか
遅れてきたハドソン遠藤さんは、きっとバグ出して遅れたんだぎゃはは(←みんな酔ってる)、とか
でもやっぱり遠藤さんはいろんなノウハウを持ってるはずなので、勉強会で裏話とか聞きたいよね、とか
オセロだと版権にひっかかるけど、リバーシだとセーフなんだって、へー、とか
Web屋にとってゲームの設計というかコードってどう書けばいいのか全然想像できないんだけど、なにか良いサンプルないですかね?、とか(オープンソース漁るぐらいですかねぇ)
OSC2009北海道では何かAndroidイベントできないですかねぇ、とか
中国はオリンピック後不況で、庶民はPC買うお金が無いからみんな携帯を買っている。今が狙い時じゃね?、とか

あっという間に終わってしまいましたが、「楽しかった。また参加したい」という声を頂けたので、定期的に呑み会を開きたいと思います。(やった!! 嫁に良い口実が出来たw)

あまり交流がない業界が混じって呑んでたので、それが良かったのかなぁと。

個人的には、ゲーム業界と組んで面白いこともできるんじゃないかなぁと思うので、遠藤さんともっと呑みたいなぁ。北海道でゲーム作ってる方他に居ませんか?

「あ、そうなんだ」と思ったこと

個人的に「あ、そうなんだ」と思ったのは、組み込み技術者はフレームワークを使った開発(ひいては、最近主流の開発手法とか、ネットワークに乗せるとどんなサービスが実現できるかなど)に慣れて無くて、何をどう作ればどんな価値が生まれるのか解らないという点でした。

逆においらの様なWebから入った人は、組み込みにおけるコスト感覚や技術的難易度、受発注の流れ、特にデバイスの特色や制限について何も知りません。

これってギャップとして結構大きいかもなぁ。もっとお互いに理解を深めるべき。で、そこからビジネスモデルを探るべき。

また、Androidが得意な分野ってヒューマンインターフェイス(というか、人間と複雑なやりとりを行う所)にあると思うので、うまく普及していけば、大昔に夢見たユビキタスな世界がやってくるかもなぁとか思いました。

以下妄想

ってか、ユビキタスなんて良くわからない抽象的な世界じゃなくて、例えば冷蔵庫にアプリをダウンロードして機能強化する(バーコードリーダ付けてクラウド上で鮮度管理とかね)ような世界も、BeagleBoardの小ささとAndroidのパワーがあれば結構実現可能性高くね?
ってか、おいら達Web屋からしてみれば、クラウド(の概念)なんてものは何も珍しいモノではなく、サーバ側でコアロジックの並列処理が必要なものじゃなければ、今まで何個も作ってきたよねコレ、って感覚なんですが･･･(これが珍しく見えること自体がギャップですよね)
で、その過程で「こんな端末があればこんな事が出来るのに」と構想は持ちつつ、色々な障壁が高くて事業化できずに放置していたエリアに、いきなりスッと入れるようになった(ような気がする)感覚というか･･･
ってか、ブラウザ上のWebサービスなんて、もうそろそろ飽和状態に見えるし、その原資も枯れてきているように思えるので、主戦場をブラウザから移して、その高まったクオリティとハードの力(可能性)を掛け合わすような戦い方にシフトすべきだと思うなぁ
もっと言えば、もう家電なんて差別化できないんだから、いっそオープンソース的なコンセプトを取り入れて、家電としての基本機能(冷蔵庫であれば冷やす凍らす氷を作る)とそれを制御するAPIだけ用意して、その上で動く制御ソフトは自由に交換可能な様に作れば、どっかのギークが面白い仕掛けを仕込んでくれる気がするんだけどなぁ
Android端末からビデオ出力できれば、ヘッドマウントディスプレイと合わせて面白いこと出来そうじゃないですか?　通勤中にニュースやメールや読書するとか(←個人的には一番興味ある)
上記のような、「(あんまりお金になりそうにない)サービスありきの思想」と「(まだあまり理解できてないけど)ハードの制約に縛られず、その可能性を発揮させたいという思想」が混じり合うあたりがフロンティア(というか次期戦場)なのかなぁと

色々言っても、一番大きいのは「Web屋とゲーム屋とハード屋が同じ話題で呑めるようになった事」であって、双方の理解が進むにつれて、これを発端に色々面白い世界が開けてくるかもなぁと思いました。

ということで、楽しくて色々収穫のある新年会でした。

北海道にお住みのAndroidに興味のある方、次回ご一緒しませんか?

Android&Java新年会@札幌やります

2009-01-19T10:56:00.000+09:00

最近Androidがお気に入りでして、androidあぷぷとか作っちゃったりしてる訳なんですが、やっぱり地方に住んでると流れの外に居る気がしてちょっと寂しいのも事実です。

(札幌Ruby会議01で高橋会長も言ってたように、「(北海道から)東京への距離と、世界への距離が等しいと言う意味で好ましい(というような趣旨のこと)」という利点はあるのですが)

で、オンラインで活動している分にはどこに居ても関係ないのですが、やはりビジネスとなったり困ったりしたときは、ある程度気心の知れた知り合いが居た方が良いというのも周知の事実です。

ということで、北海道におけるAndroid&Java関係技術者を集めて新年会を行います!!

詳しくは新年会@札幌のご案内 - 日本Androidの会 | Google グループを参照して欲しいのですが、この新年会は「名刺交換会&親睦会」的な意味合いを持たせていますので、興味ある方はどなたでも参加いただけます。

で、実は今日(1/19)仮締め切りなんですが(ごめんなさいごめんなさい)、今のところAndroidに関しては、ハードの話もソフトの話もできるメンバーが揃いつつあります。android実機やBeagleBoardも持ち込まれるようです。

参加方法はgoogleグループのjava-sapporoに参加後、勉強会&新年会スレッドにて受け付けています。

当日飛び入りもwelcomeなのですが、お店が一杯だったらごめんなさいになりますので、予定が確定できるならお早めの登録をお願いします。

(立場上Android押してますが、Javaな方もばっちこいです)

gemspec.infoのソースコードをgithubで公開しました

2009-01-12T18:35:00.001+09:00

基本的にはβ2の状態からいじってません。

というか、自分的にちょっと熱が冷めてきた(というかandroidに移った)ので、あまり時間もかけれないし、公開しちゃえという感じです。

ライセンス書き忘れとか、このパスワード公開しちゃっていいの?ってのも含まれている可能性もあるので、見つけた人はこっそり教えてくださいw

機能予定にあってまだ出来ていない部分があるので、時間が取れたらアップデート入れます。

gemspec.info自体の運営は続けますし、有用なパッチなどがあれば反映させていきたいと思います。

GitHub上のgemspecリポジトリ

見所

参考にならないかも知れないけど、こういう組み合わせの実装もあるよ、ということで。サンプルソースとして使ってもらえれば。

単一テーブル継承をしつつ、ポリモーフィック関連を使っている
プラグインが提供するモデルをいじってる
RailsモノのサイトでのOpenID対応サンプルとして(あまりWebに資料がなかったので)
open_id_authenticationを拡張して、ホワイトリストとブラックリストに対応させている
cronでバッチ用クラス(lib以下参照)を呼んでいる。この時の引数を切り替えることで、動作内容を変えている
WebAPIを使ったリンク対象ページのサムネイル取得
ExtractContentを使ったリンク先本文の取得(これはフィードを先に見て、見つからなかったときの動作の方が好ましいかも)
ユーザごとにトラックバックURLを作ることで、ユーザに紐付いたトラックバック受付&スパム防衛
サーバ上のユーザ名とかパスワードなどを切り出してある

んーもー内容忘れたなぁ。

コードの大半がlib以下にあることを見ても、表面は平凡な感じなんだなぁと再認識した。

中途半端な所

やっぱ仕事じゃなくて趣味でやると、必要最低限しか作らないなぁと再認識した。

RDoc生成関連は、事実上Macでの動作に限定されているかも。だってRDoc テンプレート使いたかったんだもん。
全文検索機能がついてない。(時間が空いたら作りたい)
Gettextは組み込んであるけど使ってないw potファイルぐらいは作ったかもw
gemspec.infoのクローンサイトとの連係機能は何も出来ていない。設計さえ出来てないw
色々なモデルでinclude GemspecARExtendしてるのはイクナイ
テスト無いのもイクナイ
GitHub対応がちょっと進んでる?かも?(本家がどうとか考えないで取り込んじゃった方が良いのかも)
SEO対応方面は手を付けてないかも
てかちゃんといろんなブラウザでテストしろよ、と

まーそんな感じ。

大掃除で出てきた本をプレゼントします

2009-01-05T10:49:00.000+09:00

年末の大掃除で不要な本が出てきましたので、取りに来る、または勉強会などで手渡し可能な人に限り、無料でお譲りします。

基本的に、保存しておく価値が低い(流行モノもしくは読んで頭に入ったもの)なので、それなりの内容だとご理解ください。中古でありますが、書き込みや破れなどは無いと思います。(確認はしてませんが)　以下のリンクは説明のために付けておきますが、版は違う可能性があります。

せっかくなので、短評を沿えて。

"AJAX Webアプリケーションアイデアブック" (羽田野太巳)

この本はAJAXの基礎部分が理解できる本です。

純粋にJavaScriptだけを使ってバックグラウンドで通信を行う流れを説明していますので、AJAX系のライブラリは使えるけど、実際はどうやって動いているんだろうとか、AJAX系のライブラリの内どこまでがJavaScriptの基本機能なんだろう、と思ったときに理解の助けになると思います。

"はじめてのRuby on Rails 2 (I・O BOOKS)" (清水美樹)

Rails 2.x系を主題にした本です。 Rails 1.2.x系はあえて持ち出さずに、「多言語でWebアプリは作れるけど、Rubyは使えてもRailsは使ったことがない人がRails 2.xを触ってみた」みたいなノリで話が進行します。

とりあえず触ってみて覚える系なので、リファレンス的に使いたい人には物足りないと思います。

"オープンソース徹底活用 EclipseによるPHPスクリプト開発 (オープンソース徹底活用)" (上ヶ迫勝憲)

Eclipseプラグインを使ってPHPアプリを書くための本です。

PDTではなくWebStudio 0.3.4だったり、Eclipseも2.1.1だったり、PHPも4.3.2だったりと、今となっては筆者の環境はちょっと古くて使えない感はありますが、PHP+Eclipseという組み合わせの数少ない本ですので、読んでおいて損はないかも知れません。

"絶対わかる!新・ネットワークセキュリティ超入門 (日経BPムック―ネットワーク基礎シリーズ)" (日経NETWORK)

どちらかというと、ネットワーク屋さんや、サーバ管理者が知っておくべきセキュリティ関係のトピックスを扱った本です。

Webプログラマにおいては、この本を読んでおけば十分なんじゃないでしょうか。

"Flexでさわっておぼえるリッチクライアント Flashベースの次世代Webアプリケーション" (株式会社電通国際情報サービス, ひがやすを, マクロメディア株式会社)

Flex1系の本です。

Flex3とは周辺状況がかなり異なっているので、レガシーシステムを保守しなければならないような人にどうぞ。

"MASHUP++" (鹿倉公維, 澤久裕昭, 原央樹, セトウナオ, タナカミノル, 三宅涼, 宮下剛輔, さうなまん)

マッシュアップを主題に、マッシュアップアプリを一部コアソース付きで10本紹介しています。

WebAPIはなんとなくわかったけど、具体的にどうやって作ったら良いんだろう?って方は、一読してみると流れが掴めるんじゃないでしょうか。

"図解標準最新UNIXハンドブック" (伊藤和人)

Unix/Linux系のコマンドライン操作の解説本です。

シェル操作はまとまって書籍化されているモノが少ないので、一読していくと全体的な流れが理解できて良いかも知れません。

"MythTV活用ガイド" (伊藤ぽん太, 吉川敦)

Linuxにビデオキャプチャボードを付けて録画サーバにしてしまうためのソフトであるMythTVの解説本です。

単純に録画や再生だけなら便利なモノはたくさんありますが、組み込み向けなど自分で録画システムを作らなければならないときには便利かも知れません。

以上8冊、1月中に連絡くれた人にはプレゼントしますが、2月になったら捨てちゃいますので、欲しい人はお早めに。

連絡は、ここのコメントに書くか、プロフィールあたりからメールアドレス探してメールください。

ちなみに、当方札幌市白石区ですよー。

androidでJUnitを使ってテストケースを書く方法

2008-12-29T19:40:00.000+09:00

テストケースは、まぁ書けるとして、どうやってテストを実行するんだ? ってところで詰まったので、調べてみました。

androidにおけるUnitテストの資料

2008/12/28現在では以下のような状況でした。

googleのAPIドキュメントで見つけたのはこんな感じ。
でも、テスト実行の方法はちゃんと書いてない。
ググっても日本語ではあまり情報が出てこなかった。(情報が断片的すぎてよくわからない)
androidの本家MLで同様の質問が出ていましたので、英語読める方はまずはこれを読んでもらうのが良いと思います。
- Confused by Android testing framework - Android Developers | Google グループ
このスレッドのまとめチュートリアル。現時点では一番まとまってます。
- Diego Torres Milano's blog: Android: Testing on the Android platform - ApiDemos tests
テストケースのサンプルとして、展開したAndroidSDKの中にSDK_HOME/samples/ApiDemos/tests/というディレクトリがあり、この中にApiDemo用のテストケース(の一部)が納められています。これで流れを掴むのがよいかも。

で、日本語でまとめるとどーよ?

ざっくりまとめるので、詳しくは上記資料を読んでね。

まずはApiDemosのテストケースよんどけ
テストケースも1つの独立したプロジェクトとしてapkファイルを作ってエミュレータなどに転送する必要がある。要はテスト対象と、テスト本体で2つのプロジェクトを作る必要がある。
activityとかservice用のテストケースが用意されているので、それを使うと結構幸せになれる。このへん参照android.test.InstrumentationTestRunner - Android
テスト用のAndroidManifest.xmlが必要。書き方はApiDemos/testsのやつを参照
テストの実行は、エミュレータからならDevToolsというアプリのInstrumentationから好きなテストを選べば実行できる。
このDevTools→Instrumentationの中には既に何個かテストが入っているので、どんなことが出来るか実行してみると良いかも
コマンドラインから$ adb shell am instrument -w com.example.android.apis.tests/android.test.InstrumentationTestRunnerなどとしても起動できる。これにはオプションがいっぱいあるのでandroid.test.InstrumentationTestRunner - Android参照
テスト結果は$ adb logcatまたはamコマンドでの出力値として返される
INSTRUMENTATION_FAILEDとか言われる場合は、エミュレータ内でテスト用パッケージを認識できているか、$ adb shell pm list packagesを使って確認すると良いかも

Android端末間の互換性が問題になりそうな雰囲気なので、テストファーストで開発してテストをたくさん書いておくと、将来幸せになれるかも知れません。

OpenOffice3.0のWriterがひどく使いづらい件について

2008-12-28T10:56:00.000+09:00

MS OfficeのWordに慣れた身にとって、ひどく使いづらいと感じた事があるので、ここで文句を言うw

ちなみに、MacOSX 10.5 + OpenOffice 3.0.0での話です。

したかったこと

ブログ読んでいて、「あ、これいいな。印刷しておこう」と滅多に思わないことを思ってしまったので、手持ちのOpenOffice3.0を起動してWriterを選んだ。

HTMLから該当箇所をwriterにコピペする。元HTMLから多少文体が異なってしまったが、まぁいい。

ちょちょこ直した。

さぁ印刷と思ってプレビューを見てみる。

あれ、最後の行が次ページにはみ出てる。

直さなきゃ。

ここから悪夢が始まる

１ページの行数を増やせばいいな、と経験から思ったので、「ファイル」メニューから「印刷設定」を探す。

あれ、そんなメニュー無い。

しょうがないので「ファイル」メニューから「プロパティ」を開いてみる。

ここにも行数の設定画面がない。こりゃファイルシステム上のプロパティを編集する画面か。

じゃあどこだ?

あれれ?　それらしいメニューがない。

プレビュー画面ボタンにあるのかな?

･･･プレビュー画面開いたけど、そんなボタンない。

わからん。

機能的には無いと非常に不便だから、無いはずはないんだけど･･･。見たことがある気もするし。

しょうがないから、メニューを1つ1つ開いてみるか。

(しばらく探す)

あ、あった。「書式」メニューの「ページ」ね。もーこんな所に置くなよー。

更に悪夢は続く

んーと、行数の設定は･･･「行数と文字」タブか。

「行数だけ指定」を選んで、「ページ単位の行数」は・・・26行?　A4に入る行数ってそんなもんだっけ?　まぁいいや。確定。

うがっ、やっぱり行数が少なすぎて3ページまで伸びちゃった。

元の設定画面に戻って･･･と。

でも、26行以上増えないなぁ。

(しばし、がちゃがちゃ)

あれ? 「ルビ文字の最大サイズ」を減らしたら「ページ単位の行数」が31行まで増えた。

えー?　「ルビ文字の最大サイズ」とか「1文字の最大サイズ」を指定してからじゃないと、「ページ単位の行数」を自由に指定できないの?

まじで?

うーめんどくさー。まーいーや、ルビなんて無いし、1文字サイズも使っているフォントサイズまで下げちゃえ。

あれれ?　それでもまだ印刷したい文書は1ページに収まらないや。

うー。見た目では、まだまだ行間空きすぎなので、この行間を削りたいんだけどなー。

どこで調節するんだ?

(かなり格闘)

うー、いくら調整しても、「標準の文字数を使う」を選んでデフォルト設定を使った方が収まりがいい･･･。

うがー、わからん。こんなに時間かけてられない。やーめた。

てか、胸くそ悪いから、ブログに書いてやろう。←いまココ

ユーザインタフェース上の問題点まとめ

OpenOfficeはその存在意義として「MS Officeの代替えを無料で目指す。(=MSやっつける)」であったはずですが、このインタフェースじゃあMS Officeから流れてきた人はOpenOfficeのwriterで絶望して「しょうがないからMS Office 2007でも買おうか」となる気がします。

具体的な問題点は以下の点です。

MS Officeと同じ機能が同じメニュー構成となっていない。これは、「基本的なメニュー構成や機能は、違うアプリ間においても同じ配置になっているべき」というMS WindowsのUI思想に反していて、元Windowsユーザにとっては非常にフラストレーションが溜まります。(MS Office 2007はここで反感をかったわけですが)
大抵の人のプロセスとして、「適当に文書を書く」→「1ページに収めたいところがあったらページの行数を増やす」→「システムが行数に合った行間隔などの周辺パラメータを適当に設定する」→「まだ気にくわなかったら周辺パラメータを微調整」といった流れで作業するのに対し、OpenOfficeのwriterは「適当に文書を書く」→「システムが行数に合った行間隔などの周辺パラメータを適当に設定する」→「1ページに収めたいところがあったらページの行数を増やす」→「まだ気にくわないので、さらに行間隔などの周辺パラメータを適当に設定する」→「1ページに収めたいところがあったらページの行数を増やす」→「まだ気にくわないので(以下何度か繰り返す)」となっていて、「1ページに文書を収める」という目的達成まで非常に時間を要します。
いくらがんばっても目的を達成できず、かつデフォルト設定の方が自分の目的に近い。サイアクです。

MS Officeでは簡単に実現できたことを、OpenOfficeでは色々試して結局実現できなかったという体験は、絶望以外は生まないでしょう。(たぶん自分ももうwriterは使いません)

とか言いつつ、マイナーバージョン上げたら直ってたりしてね。

Web上で1円を決済させる方法

2008-12-25T19:25:00.001+09:00

おいら今更ながらウェブ進化論を読んだんですが、読みながら「そういえば、まだ人々から1円づつ徴収するようなビジネスモデルって出てきてないなぁ。ウェブ進化論っていつ書かれた本だっけ? 景気悪化から広告費が削られるのは目に見えてるんだから、まさに今必要なのに。たとえば、1円決済モデルを行うメソッドさえ実現できるなら、おいらのようなフリーランサーが自分で食べるのに困らないぐらい稼ぐことは簡単だと思えるのに」と思っていた。

てなところで、定額決済の話題がホットになってきたので便乗してみる。

前提

「失敗して当たり前」な有料Webサービスの条件 - インターネットください

「サイト存続のため、アバター買って」　カフェスタが異例の呼び掛け - ITmedia News

「タダが当たり前」の時代は終わる？　カフェスタが「お金払って」と呼び掛けた理由 (1/2) - ITmedia News

有料ネットサービスが成功しないたったひとつの理由 - いつか作ります - 断片部

コンテンツで収入を得ていける仕組みをみんなで考えよう - novtan別館

有料サービスが抱える課題　−　少額決済について - この先、しばらく道なりです

ポイント購入制が有力かも!?

有料サービスが抱える課題にある通り「ポイント購入制」が現実解に思える。

コメント欄にある通り、Value-Domain なんかは昔からクレジットカードでサイト内ポイントを購入して、そこから少額決済(といっても数百円単位)してるし。表から見る分には良いモデルだと思う。(飼い囲み的に)

でもValue-Domainはあくまで「ドメイン屋さん」で、よっぽどじゃないと少額決済を広めようという気は起きないと思う。(し実際ムリだと思う)

それに、今から使用額決済システムを作って、市場に受け入れられるかは不明だよね。APIどうすんの?の他にも、そもそも信用問題とかとか。

こんなのどうかな?

で、自分が思うに、OpenIDと絡むのが「少額決済」的にも「OpenIDの発展」的にもいいと思う。

おいらgemspec.infoを作ったときにOpenIDの事をそれなりに調べたんだけど、あれって認証したときにユーザ情報を一緒に渡すことが出来て、かつその付加情報って拡張可能だった気がする。(や、深く調べてないからわかんないんだけど)

要は、OpenIDプロバイダがやる気になって独自拡張すれば、グローバルなIDに紐づけられた決済手段として使えると思うんだよね。

ちなみに、

日本の企業で
有名で
既にユーザが多く
かなりの割合の人が既に決済手段を登録済みであり(←超重要)
クレジットカード会社側もある程度の少額決済を容認しており
もちろんOpenIDプロバイダとして稼働していて
決済手段を登録しているが故に、IDの身元確認もしっかりしている(と期待されている)

という意味で、Yahoo! JAPANがOpenIDを使った決済機能提供元の最有力候補に思えるんだけど。

で、以下はヤフオクユーザを対象に考えていくことにする。

OpenIDを使った決済の流れ(脳内)

あらかじめ設定しておくこと

ヤフオクユーザである時点で決済手段は登録済みなので、後は･･･

自分のOpenIDを発行する
自分のOpenIDを使って決済を行うことを許可しておく。この際、デフォルト決済手段も指定しておく。

の2点だけ設定しておく必要がある。

少額を何回も決済されることを、カード会社が嫌うなら(普通嫌だよね)、そこにポイント制を導入しなければならないと思うので、先にポイント購入しておき、自動チャージの設定などもしておくのが理想なんだろうな。

外部サイトで決済するときの流れ

外部サイトで「決済金額」と「Yahoo! JAPANが発行した自分のOpenID」を入力して決済ボタンをクリック。(ただし、ログイン済み状態ならOpenIDの入力は必要ない)
外部サイトのシステムがOpenIDをパースし、決済情報と一緒にエントリポイント(Yahoo! JAPAN)へのリダイレクトを行う。もちろんSSLを使う。
Yahoo! JAPANのOpenIDログイン画面が表示されるので、ログインする。(ログイン済みであれば省略)
Yahoo! JAPAN上で決済金額と支払先(外部サイト名)が示され、Yahooに登録済みの決済方法のうち、どれから支払うかを選択する。(確認無しに決済を行う設定になっていれば省略)
Yahoo! JAPAN上での決済が無事完了すれば、外部サイトに再度リダイレクトされる。この際、決済を特定できる決済IDも一緒に渡す
外部サイト側で、決済IDを保存して完了。または決済できていなければエラー処理を行う。
決済IDを使って決済状況などを確認することが出来る(ユーザ、外部サイト共に)

2のリダイレクト時に、外部サイト側を確認するため、なんらかの認証手続き(RSA認証とか)を使っておくと良いんじゃないかな。

ちなみに、外部サイトで販売するものは、「物理的な商品」でも良いし、「情報」でも良いし、「一定期間のサービス使用権」でもいいと思う。

整理すると

ユーザは(設定と認証状況にも寄るが)、金額を確認して決済ボタンを押すだけ(最短1クリック)で決済完了できる可能性がある。
この時の条件は、「外部サイトにOpenIDを使ってログイン済みで、Yahoo!JAPANにもログイン済みで、Yahoo!JAPANにOpenID経由で決済リクエストがあったときのデフォルト決済手段が登録済みであり、決済リクエストがあったときに確認無しで決済を通すように設定されていること」の4点。
外部サイト側で対応すべき事は、OpenIDを使ったログイン処理+αぐらいの処理であり、全然楽。ユーザのパスワードもクレジットカードのナンバーも(手に入らないので)気にすることはない。あー、決済可能なOpenIDプロバイダをホワイトリストでフィルタリングする必要はあるかな。
一方、Yahoo! JAPAN側は、規格の策定から関係団体への折衝からカード会社への説明からAPI公開から保守まで対応する必要があり、結構というか相当大変だとは思うけど、実現できたら「一人勝ち」状態でしょうね。

OpenIDなら、1つのYahoo! IDから「決済画面に進めるOpenID」と「決済できないOpenID」を用途によって使い分けることが出来るしね。(今のYahoo! JAPANの仕組みじゃ出来ないんだろうけど)

OpenID側のメリット

OpenID対応サイトを作ってみて分かったんだけど、今のOpenID界って結構混沌としてて、「あっちのOpenIDプロバイダだとコレができるけどアレができない」「こっちは日本語使えない」とか、OpenID対応サイトもホワイトリスト的に利用可能なOpenIDプロバイダを絞ってるので、結局あちこちのOpenIDプロバイダにIDを2・3個登録して、OpenID対応サイトも複数のOpenIDを登録しちゃうことになってしまう。

同じサイトなのに、別のOpenIDでログインしちゃって、「あれー? おいらのデータはドコいった?」とかね。(実話)

でも、これって当初のOpenIDの目的に反してる。ぜんぜん便利じゃない。便利じゃないからOpenID対応サイトも増えない。

イクナイ。

で、Yahoo! JAPANが少額決済メソッドの実装できたらどうなるか?

少なくとも日本のECサイトでは「Yahoo! JAPANのOpenIDを使った決済方法」に対応するところが次々に出てくる。(Webマネーに次々に対応したように)
普通のWebサービスでも「Yahoo! JAPANのOpenIDを使った決済方法」に対応するところが現れる。
いったん「普通のWebサービス」で受け入れられると、決済手法として爆発的に普及する。(だって利用料取りたいもんねぇ)
「Yahoo! JAPANのOpenIDを使った決済方法」がデファクトスタンダードとなる。
決済機能に支えられてYahoo! JAPAN発行のOpenID利用者が増える
ユーザシェア拡大に伴い、数多のOpenID対応サイトではYahoo! JAPANのOpenIDをホワイトリストに追加しなければならなくなるので、ユーザはとりあえずYahoo! JAPANのOpenIDを取得し、使うようになる。
Yahoo! JAPAN発行のOpenIDがデファクトスタンダードとなる。

てな具合に、Yahoo! JAPANの商売的にも、OpenIDの普及のためにも、ECサイト運営者にも(決済方法の拡充と集約)、Webサービス運営者にも(広告モデルからの脱却)、ユーザの利便性(OpenIDと少額決済)向上のためにも、みんなにすんごいメリットがある気がする。

こうなったら、おいらも他のOpenID捨ててYahoo!一本に絞るね。

Yahoo! JAPANさん、がんばってくださいよー。

でもマテよ?

あれー?

なんかうまく行きそうじゃねー?

おっかしーなー、なんで今まで生まれてこなかったんだ?　どっかに穴があるな、こりゃ。

ツッコミ求む!!

12/26更新

はてブやコメントで指摘いただいたので補足。

「日本では銀行以外が送金業務を行うことは違法」については、これが送金業務に当たるかどうか微妙だけれど、2005年初頭にYahooがあおぞら銀行を傘下におさめて、銀行業務に参入してたみたいなんで、これの流れがあるのかなぁとか。

「オークションを使ってない(相当数の)人たちは使えない」と言うのは視点が違う気がします。全ての人がアカウントを持っている銀行なりクレジットカード会社なんて存在しないので、どんな方法にせよ、新規に「クレジットカードなり銀行引き落としにつなげるための登録」をする必要があるんでしょうけど、ヤフオクを使える人(Yahoo! JAPANプレミアム会員)なら新たに登録しなくてもそのまま使えるよ、って話です。Yahoo! JAPANプレミアム会員ではない人は、新たに会員登録すればいい話なので、マイナス位置じゃなくてゼロ位置ですよね。

「クレジットカードなり銀行引き落としにつなげるための登録」って、ユーザにとってすごく障壁が高い行動なので、(簡単な設定ぐらいで)何もしなくてもそのまま使えちゃうユーザ(Yahoo! JAPANプレミアム会員)が居るのって、超重要だと思うのです。

「決済手数料の問題」については、運営元の判断(直接マネタイズするのか、他社より優位に立てればそれで良しとするか)に寄るんでしょうけど、「ヤフオクはやらなくても、少額決済には使いたい」って人もプレミアム会員に流れるでしょうから、新規に増加する会員の月額利用料(346円)分は売り上げがあがるんじゃないかな。

現実問題として、決済手数料無しで使わせるのは難しいんだろうけど、ポイント制で行くならそんなにバカみたいに高いシステム構築費にはならないと思うから、その分手数料を安くできるだろうし、極端な話手数料が安ければ、定額制にしてプレミアム会員に負担させるとかって話でもいい気がする。外部サイトなどに手数料を負担させることが結局支払い価格に乗ってくることを伝えれば、理解も得られるんじゃないかな。あと、Yahooから外部サイトへの支払いも、「末締め翌月末払いで1万円単位」ぐらいで縛って、ここから数パーセントのマージン取れるんじゃないかなぁ。

･･･でもなんか、もっと現場寄りの泥臭い話が根幹にある気もする。

月刊android周辺にぅす2008年12月版

2008-12-24T22:15:00.000+09:00

日本アンドロイドの会北海道支部ができたのはいいけど、どんな活動しよっかなーと思っていたんですが、androidの経験の少ないおいらでも出来そうな事として、毎月(札幌Javaコミュニティの活動日)Android周辺ニュースをおいらなりにまとめて公開しようと思っています。

生い立ちと対象読者

日本では端末さえ出ていないAndroidですが、G1が発売されてからはAndroid界も慌ただしくなってきていて、新たにAndroidに興味を持った人がいたとしても、周辺事情を抑えるのでさえも一苦労かなと。

Androidに興味を持っている(けどよくわからないから手を出していない)Web系プログラマというのは、結構な数存在すると思うのですが、そういう人向けに毎月コンテンツ開発者視点でニュースランキングを配信することには意味があると思ったので、「飽きるまで」やってみようかと思います。

特に、(端末が発売されていない状況なので当たり前なのですが)現状ではコンテンツ開発者よりも、組み込み開発者(このハード構成でAndroid動いたーみたいな)の方が盛り上がっているように見えるので、これをきっかけにAndroidに興味を持ってくれるWeb系プログラマが増えて、コンテンツ開発者間も盛り上がってくれればいいなぁと思っております。

なお、おいら北海道人なので、視点が北海道からのものになっています。前提が札幌Javaコミュでの発表資料なので、この辺は許してくださいね。

公開資料

なお、資料はSlideshareを使って公開していますが、今のバージョンは相当腐っているらしく、Macからアップロードはできないわ、プロフィールやファイルの属性編集もできないわで、酷い状態です。

かなり適当な状態でアップロードされていますが、ご容赦くださいまし。

なお、内容については、(一応android系ニュースは追っているものの)おいらが直感的に確認も取らずてきとーに突っ込んでいるだけなので、もし間違っていてもAndroidの会は無関係です。悪しからず。

android_news_in_hokkaido_200812

なお、11月以前のAndroid周辺事情は(大雑把ですが)android勉強会 in 札幌+android周辺事情のまとめを推しておきます。

あと、ニュースソースはandroid情報まとめ@ウィキなので、「一ヶ月も待ってらんねー」という方や「何言ってるかわかんねー」という方はそちらをどうぞ。

で、反省

初回なので、あまりうまく行くとは思ってなかったのですが、本当にイマイチだったので、反省しておきます。

トップ10である必要はないかも。みんなが知っておくべき大事な要素って、トップ5に収まる気がする。
スライド1枚ぐらいの内容で、今月何があったのか、時系列で示しておいたほうが理解しやすいかも
コメントがやっつけっぽいよね
札幌Javaコミュ内のAndroidに興味を持っている人のレベルに合わせた方がいいのかな
やばい、このニュースだけじゃ呑み会に繋がらない気がする

こんなの欲しいみたいなご要望ありましたら、コメント欄にどうぞー

勉強会配信セットを作ってみました

2008-12-14T19:14:00.002+09:00

パチンコで勝ったので、このアブクゼニが無くならないうちに勉強会をUst配信するために必要な機材をバック1つにまとめたセット(以下勉強会配信セット)を作ってみました。

方向性としては、

配信に必要なものがバック1つに収まること
最低限のクオリティを確保しつつ安価であること
勉強会間で貸し借り可能なこと(LOCALで管理する前提でまとめました)
ネットワーク回線は調達方法がいろいろあるし、責任問題が付きまとうからセットには含めない

としています。

「ちょっと○○配信したいから貸してよー」「ほーい」と簡単に貸せるセットとして使いたいのです。

以下にセット内容と選定理由と購入価格と短評をまとめてみます。

Webカメラ

"Logicool キューカムプロ9000 QCAM-200S" (ロジクール)

購入価格 : 約8000円

購入理由 : 勉強会配信に関して異常な技術力を誇るRuby札幌がお勧めしてたから。

どうよ? : カメラ性能はWebカメラとしては良い方だと思う。注目すべきはマイクの性能で、質疑応答はマイク無しでもなんとか聞き取れる程性能がよい。ただ、カメラ固定用の穴がないので、三脚などのへの固定には工夫を要する。(ガムテープとかね)　Windowsなら高画質モードがあるみたい?(未確認)

参考 : メーカーリンク

三脚

"SLIK 三脚 800G-7 SLIK800G-7" (スリック)

購入価格 : 約4000円

購入理由 : まぁなんでも良かったんだけど、安くて、カメラの高さが地面から1.5m以上にあって、軽いこと(700g)が決定要因だった。

どうよ? : んー。普通に良い。特に困ったことはないなぁ。

参考 : メーカーリンク

三脚を設置する場所が無いとき用の固定器具

"ケンコーカメラ用三脚 JOBY ゴリラポッド 086821" (JOBY)

購入価格 : 約3000円

購入理由 : レイアウト的に三脚が置けない場合があると思うので、ポールや天井への固定用に買ってみた。JOBYゴリラポットSLRかSLR-ZOOMというグレードなら、それぞれ800g/1.5kgまでの加重に耐えられるのだが、一番低いグレードはくにゃくにゃしてて使い物にならないので注意。おいらはSLRを買ったので800gまでだけど、これならスタビライザーを付けても実用十分。

どうよ? : まだ実践未投入。でもまぁ、三脚が使えるならそれが一番かもね。セッティング楽だし。

参考 : メーカーリンク

Webカメラ固定用台座

"Manfrotto カメラスタビライザー 797 Modopoket" (manfrotto)

購入価格 : 約3000円

購入理由 : キューカムプロ9000 QCAM-200Sはカメラ固定用の穴が無いので、三脚にならガムテープでなんとか固定できるものの、ゴリラポットは流石にムリ。汎用性を確保したいならカメラ側に細工をするべきだと思ったので、これを買ってみました。まぁ、固定用の面積稼ぎですわ。

どうよ? : 現状買って正解でした。ただ、まぁ、結局はテープで固定なので、カメラ固定用の穴と同じ山が切ってあるプレートを自作した方が安上がりでしょうね。ちなみに、ゴリラポットと組み合わせた状態はこちら。

USB延長ケーブル

"バッファローコクヨサプライ Arvel USB2.0対応リピーターケーブル 5.0M グラファイト AUR09GR" (バッファローコクヨサプライ)

購入価格 : 約2000円

購入理由 : キューカムプロ9000 QCAM-200SはUSB接続なんだけど、ケーブルが1.5mぐらいしかないので、三脚の隣にPCを置く必要があって、レイアウトがかなり制限される。そこでUSB延長ケーブル(オス-メス型)が必要になるんだけど、5m延長するならリピータ機能付きの方がなんとなく安心かなーと思って買ってみた。

どうよ? : うん。普通に使えた。やっぱりケーブル長いと楽だわ。

配信用ソフトウェア

配信中は結構CPU負荷かかるなぁ。理想的には配信専用PC+配信担当者がいた方がいいでしょうね。

Ustream 〜言わずと知れた動画配信サービス。Webカメラで撮った動画をライブ中継しながら録画できる。IRCを使ったチャット機能付き。プロジェクタに余裕があればIRCの内容を勉強会にフィードバックできて、盛り上がる。利用は無料。
CamTwist 〜Mac用。動画にエフェクトをかけたり、スクリーンキャストできたりする。そもそもドライバがないためMacは標準ではキューカムプロ9000 QCAM-200Sを扱えないが、このアプリを経由すると使えるようになるため必須。詳しくはCamTwist - UstreamまとめWiki 参照。

その他雑多

雑多なので100均を中心に揃えたものです。イヤホン以外必須ではないですけどね。

携帯用バック〜30cm四方ぐらいのバックなら、三脚が飛び出すぐらいで収まる。家に余っていたもの。
Webカメラ用ポーチ〜レンズ傷ついたらヤだからね。100円。
固定用テープ〜100均で打ってるガムテープで良いかも。Webカメラの固定の他、あると何かと便利。
カッター〜テープを切るためのもの。無いと上手に切れないので。
イヤホン〜Ust中継中に画像は簡単に確認できるけど、音声はイヤホンか無いと確認できないので必要。(周りの迷惑になるからね)
Windows用ドライバCD〜キューカムプロ9000 QCAM-200Sに標準でついているもの。Windowsの場合はドライバが必要らしいので。Macの場合はドライバはいらないけど別途CamTwistが必要。貸し出す前提なので。
簡易マニュアル〜セット一覧とUstream.tvの簡単な使い方をプリントアウトしたもの。貸し出す前提なので。

その他PCとか電源タップとかLANケーブルとかは当たり前に必要だけど、それは準備できるでしょ。

まとめ

と、いうことで、約2万円ぐらいで勉強会配信セットを作ることが出来ました。

実用十分です。

先日PHP勉強会を配信してきたので、実際どんなもんか確認してみてください。(配信用回線は施設からレンタルしたものです。配信用アカウントも勉強会側から借りたものです)

欲を言えば、ネットワーク越しに勉強会に参加している人のフォロー用に、IRCを投写できる携帯プロジェクターがあれば言うこと無しですね。(このためにわざわざもう一台プロジェクターを用意するのは大変ですし)

あ、そうそう。勉強会をUst中継する場合、配信チャンネルが決まっていることが多いと思うけど、そのチャンネルを使うことが出来るUstreamのユーザ名とパスワードは事前に確認しておいた方が良いかもしれません。

CPIのrootがもらえる格安VPSであるVS-01を試してみた

2008-12-13T10:04:00.001+09:00

個人的には「運用やバックアップを考慮して機器構成を考えて、サーバマシンを買って、セットアップして、データセンターに設置、そして保守管理」という作業に嫌気がさしているので、レンタルサーバで済ませることが出来るならそれでいいじゃんと思ってます。

で、費用対効果的に

1万円/月程度でrootがもらえて実用的に使えるamazon EC2
400円/月程度でrootは無いけどRailsが動く(けど共用サーバなので重いときがある)HostingRails.com

の2枚のカードが手元にあり、使い分けによってどちらもそれぞれ良いサービスなんだけど、この中間にあたる「rootをもらえて月1000〜3000円」というゾーンにもちょっと興味がありました。(あと、上記は英語圏のサービスなので対応にちょっと不安がありました)

格安VPSに求めること

自分の使い方だと以下の点を満足するVPSサービスである必要があります。(EC2とHostingRailsを比較対象とした最低ライン)

技術サポートが日本語
日本からのネットワーク距離が近く速度やレスポンスが良い
Railsが実用的に動く(mongrel_cluster+mem_cachedやバッチ処理がちゃんと動く)
ネットワーク転送料制限やストレージ容量が極端に少なくないこと
それなりにメジャーなディストリビューションを使っている(個人的にCentOSはギリギリ。debian系がいいなー)
共用サーバではないので自分でメンテナンスをしなければならないので、パッケージシステムが便利に使えること。およびディストリビューションがちゃんとパッケージをメンテナンスしていること。

これ以外はrootがもらえるなら、なんとかなるかなと。

CPIという会社が格安VPSサービスを始めた

KDDI系でCPIという会社があるらしい(おいらあまり詳しくない)のですが、そこで2000円/月でrootがもらえるVPSサービスを始めたらしく、期間限定でお試しサーバを貸してくれるらしいので、早速申し込んでみました。

スペックはこちら

CPI | Virtual Private Type Rental Server VPSスケーラブルプラン

試したのは一番安いVS-01プランです。

で、どうだったか?

用意してもらったVS-01のテストサーバにSSHで繋いで色々いじってみましたが、結果的に自分の使い方ではVS-01は採用に至りませんでした。

その理由をざっとまとめておきます。

VS-01以外ではコストメリットが低いので検討に値しない(あくまで主観)
VS-01のテストサーバは、スペック通り完全に立ち上がった状態で空きメモリが約180MBあるんだけど、このメモリ量ではyumがまともに動かない。yum無しでサーバを管理するのは辛いなぁ。てかこのテストさえまともに出来ない
自分のPCからscpで動画ファイルを転送してみたら、最初は1MByte/secぐらいでるものの、10MB〜30MBぐらい転送したところでストールしちゃった。帯域制限かけてるのかな?(当たり前に使用状況によるのでこんなことがあった程度に捉えてください)

個人的にはyumが使えないのが決定的でした。メモリ180MBって結構小さいんですねぇ。

といっても、マニュアルさえちゃんと見てないので、操作方法間違えてる可能性もあるのですが。

でも、標準状態でapache/PHP/qmail/bind/mysqlあたり動いてるので、特殊なプログラムをコンパイルしてPHPから使うような用途なら十分なのかも知れません。

どちらにせよ、気になるならお試しサーバ使ってみると良いですよ。