2009 年 11 月 20 日
突然ですが、通常のＰＣ以外(mixi,iphone,android)でのビジネスについて、考察をひとつ。とりあえず重要な課金体系にしぼった考察。（mixiアプリは最近イケてるらしいので考慮の対象に）
課金プラットフォーム別の比較
■mixiアプリ
課金プラットフォーム: あり
アプリ内課金(個別課金): あり。最近。
課金手数料: 20%
技術的には実質はWEB
■iphoneアプリ
課金プラットフォーム: あり
アプリ内課金(個別課金): あり
課金手数料: 30%
■androidアプリ
課金プラットフォーム：なし
mixiおよびiphoneアプリに関しては、課金形態の選択肢が２つある。
ひとつは、それぞれの課金プラットフォームを使用する。その場合、課金手数料が20～30%徴収されることが最大のデメリット。たとえば、本体アプリのダウンロードは無料で、個別のものだけ課金するなどが考えられる。
もうひとつは、それぞれの課金プラットフォームを使用せず、独自の課金プラットフォームを採用する。その場合は、課金部分だけは実質WEBのインターフェースになるため、課金登録は別途WEBブラウザで行って、認証だけアプリから通信する形になることがデメリット。ただし、課金システムがこれらデバイスからアクセスできる、もしくはサーバサイドとの通信だけで完結できることが前提。もしこれらデバイスで課金できないのであればこの選択肢はなし。ただし、そもそもmixi,appleがこのようなビジネスを許していないのであれば選択肢としてなしですね。
androidに関しては、もともとオープンなため、mixiおよびiphoneアプリで述べた後者の形式になる。
また、アプリとしてではなく、完全にブラウザ(javascript)で実装することももちろん可能（インターフェースをそれぞれのデバイスに合うようにデザインする）であるが、アプリの機能としての表現の自由度が落ちる、また完全に勝手サイトとなるため（そもそももはやアプリではないが）、apple storeなどのプロモーションの場に登場できないなどのデメリットがある。ただし、実装は通常のＷＥＢなので非常に楽である。
webが得意なら、mixiアプリがバランス的にはいいのですかね？
アプリを作る場合は、それ相当の工数がかかる（つまりコストがかかる）ので、このあたりの方向性をあらかじめ決めておくのは非常に重要かなと思います。そもそもwebアプリと単体アプリを比べてること自体ナンセンスかもしれないですが、あれもこれもやれる体力がありません。。
くしくも本日GoogleからChromeOSのソースコードが公開され、プレゼンによりある程度の内容が公開されました。プラットフォームはますます複雑化する様相。GoogleはAndroidとは別物だと言ってますが、ChormeOSのすべてをクラウド上で完結させるというコンセプトに基づけば、携帯にChromeOSが搭載されてもおかしくないので、今後のプラットフォーム（とくにソフトウエア）をとりまく展開は、ほんとのところは誰にもわからないのかもしれないですね。
カテゴリー: 未分類 | コメントはまだありません »
2009 年 7 月 1 日
私のように古い人間は、インターネットで通信することのすばらしさ、ドキドキ感を他の人よりも存分に味わっている。それは絶対そのとおり。
まして、プログラミングを経験してきた人は、普通の古い人よりさらにドキドキ感を味わっている。
（アマチュア無線などやっている人は、そのあたりの感覚がいい意味で古いままで、おそらく近い感覚なのでは思います）
冷蔵庫を半分に割ったような巨大なコンピュータの大きなスイッチをガチャンと押すと、ブイーンという大きなファンの音が始まり、10分くらいすると、ディスプレイに「login: 」のプロンプトだけが出る。そんな時代から当たり前のようにあったインターネット。hello worldから始まって行き着くのがsocket。こっちで送った文字列が、あっちの画面にそっけなく一行表示される。うーん、感動です！
（その前にインターネットじゃないけど、日本で通信と言えば、忘れてはいけないパソコン通信！ニフティサーブ。ちょっと前まで現役だった。あらためて感動をありがとう！あとダイアルQ2ね。）
現在は、生まれたときからいろいろあるので、おそらく感動の度合いは絶対に違う。
プログラミングにしたって、最初から全部揃っているし、極端な話サーバ、クライアントを意識しなくても目的は果たせる場合がある。
知り合いの話だが、社会人になり業務でwindows系のweb開発を2，3年やってきた人は、いまコーディングしている部分がサーバサイドなのか、クライアントサイドなのかを意識するようなことはないと言っていました。うーん、そういうものかと。それでは感動はないですね。
webの仕事が増え始めたころは、それまで単体動作のプログラムばかり組んでいたせいか、サーバサイドでプログラミング（C言語でCGIもしくはwebサーバのAPIでの通信）したことが、クライアントに反映される不思議な感覚があって、慣れるまでに時間が掛かった思い出がありますが、まさにいまどきのwebエンジニアとは逆の感覚があったのかもしれません。
まあ、とにかくそういう感動を味わったことが、現在の職にも通じているわけで、そういう時代に生まれて興味を持てたことは、ほんとにラッキーだと思います。
ただ、かなりまえから業務の性質のせいか、正直、
ＤＢに情報格納 => 取り出す =>見せる
のサイクルに飽きてきている自分がいる。感動が薄れてきてる気が。。
初心忘れべからず！
タグ: nifty, socket, インターネット, クライアント, サーバー, パソコン通信, 通信
カテゴリー: 未分類 | コメントはまだありません »
2009 年 6 月 30 日
だいぶ前の話なので恐縮ですが、若い人と話す機会増え、びっくりしたこと。
いわゆるケータイ世代の人たちは、ケータイで普通に動画を見ているらしい。びっくりしたのは、動画はＰＣで見るものという概念が全くないこと。そもそもＰＣは持っていない。
ちょうどyoutubeが流行ってきたころに、そいう人がいるのであれば、是非youtubeを見せてあげたい！ということで、youtubeのflvを携帯用にフォーマットして見せてあげるというサイトを立ち上げました。
思ったとおり、どこで知ったか最初から大量のアクセスがあって、作った側としては自己満足に浸っていた覚えがあります（現在はyoutubeが完全に日本向け携帯に対応したのでお役ご免です）
で、技術的にはどうかというと、かなり厄介です。
自分で動画変換したことのある方ならわかると思いますが、さまざまなソフトが出ているのでそれを使ってごりごりするのが一般的かと思います。
ただ、それをサーバサイドでやる場合を考えると、かなり厄介です。一般的なソフトはＵＩを備えた個人向けツールなので、さすがにそれらをキックするような使い方はなんか気持ち悪い。
コマンドラインで動く有名どころはffmpegだが、各キャリア毎にファイル内部に独自のタグが必要であることから、ffmpegで変換したファイルは、キャリアや端末によってはうまく再生できないなど限界あり。
ただ、それでもドコモとソフバンはバイナリをゴリゴリするなどして、プログレッシブダウンロードとして再生可能なところまでなんとかいけたので、ついでに尺の長いやつを分割する機能など盛り込んでサイトとしました。
ただ、そこまでやったのなら、全キャリア対応して、さらに動画に限らず他メディアもコンバートするサイト（WEBメディアコンバータ）まで持っていくコンセプトとしました。
で、とりあえず動画コンバート関連で行き着くのが各キャリアが公式ツールとして認めているQuickTimeなのですが、これも一癖あって一筋縄ではいかない。
まず、フツーにAPIを使ってwindows上で動かす。flv => 3gpp, 3gp2などに変換。と思ったらいきなり躓く。windowsでは内部ライブラリのライセンスの関係で3gppへの変換ができない。macなら大丈夫とのことで、macでやり直し。macは開発言語がObjectiveCなのでC++のソースは使えず、コーディングしなおし。
とりあえず、ものはできたが、macをサーバとして動作させる、もしくはmacサーバを用意する、サーバ回線をどうしようなどなど、なんかこれもげんなりしてしまい、いまのところ一般公開なしで。
そのうち一部有料とかでサイト立ち上げたらよいかなとも思っていましたが、そうこうするうちに携帯のハードもネットワークも進化して存在価値が無くなるのだろうなと。
なんか、やってることが中途半端なんだよなあ。。というか個人レベル、自己満足がキーワード化してしまっている気が。。
タグ: 3gpp, 3gpp2, flv, QuickTime, youtube, 動画, 変換、ffmpeg, 携帯
カテゴリー: 未分類 | 2 件のコメント »
2009 年 6 月 30 日
仕事で大量テキストの処理に困って、複数サーバでの分散処理に手を出さないといけなくなるなあ。。と考えてたのですが、今回重い腰をあげてみようと、前々からこれにしようと決めていたApache Hadoopを導入してみました。
hadoop 0.18とhbase（hadoopをベースに使った分散データベース）をセットで使用。
（バージョンは合わせる必要があるようです。ただ少し古の話なので、情報としては古いかも）
hbaseにテキストを大量に放り込んで、そこから取り出してテキスト処理するプログラムをhadoopのmap、reduceで書くという流れ。
ハードウエアは、貧弱なlinuxサーバ2台のクラスタリングの構成。
結論だけ言うと、hadoopのプロセス自体非常に遅いため、サーバ2台程度だとかなり遅くなってしまう。
かなりというのは体感なので厳密ではないですが、たとえば、1台のサーバでシーケンシャルに一プロセスで処理する、もしくは2台のサーバでDBをクラスタリング構成にするなどしたほうが断然に早い結果になると思います。（ベンチマーク的なものをどこかで見つけた気がするのですが。。確かGoo Labが出してたような。。）
使用目的として大規模なものを想定することが本来の姿なので、今回試したような小規模なシステムではオーバースペックなのです。
あと、気づいた点としては、
ドキュメントがとにかく少ない。これは、まだバージョンが浅いので今後整理されていくのだと思いますが、商用の環境で使おうと思ったら、障害が起きたときのリカバリー方法とか、自分でノウハウを作っていくくらいの覚悟が必要だと感じました。
まあ、物は使いよう、豚に真珠ということで。私には敷居が高すぎました。
タグ: apache, hadoop, hbase, テキストマイニング
カテゴリー: 未分類 | コメントはまだありません »
2009 年 6 月 30 日
2010年に向けて実装が進められているHTML5ですが、例のごとくいい加減な個人的な感想をつれづれと(プログラム実装の視点から。デザイン視点はからっきしダメ々なので)
紆余曲折いろいろあるようですが、W3Cが本腰入れて、MSもここに来てIE8で積極的に導入を考えているようで。。
5の主な機能強化
・フォーム強化
※バリデーションチェック機能はコーディング量を減らせるのでよいですが、実際はサーバサイドでのチェックは必要でしょう。
・メディア再生タグ
うーん、まあいろいろなobjectタグを覚えるよりかは確かに楽。
・キャンバスによる2D,3D描画
Javascriptでゴリゴリよりは楽か？
・クライアントストレージ
Cookieというストレージはあるが、使い方次第かな。サーバサイドがあることが前提だったら、同期やセキュリティーの問題が複雑化しそう。
・ソケット通信
これも、上記のような問題が。。
・スレッドのバックグラウンド実行
どれも、「それあったほうが作る側は楽だよね」という機能。実際、そういうニーズが発端になってHTMLのバージョンUPの話に行き着いているわけなので、当たり前の話なのですが（すでに、ほとんどのブラウザでなにかしらサポートされているようです）
アプリケーションプラットフォームと言ってもよいようなのですが、HTML4の機能追加バージョンと言うのが正しい気がします。
なぜなら、ほとんど既存のテクノロジーで当たり前のように実現されているものばかりだから。
唯一、スレッドバックグラウンド実行はブラウザ単体ではできない機能なので、これは大きな進化だと思います（非同期通信で擬似的に実行可能ですが）
どうせなら、HTTPとの組み合わせも変更しちゃうくらいドラスティックに変更したらどうなるのだろう。テキストを基本ワンタイムでやりとりするプロトコルはもういいのでは。
あと、タグとjavascriptという異なる概念が混在しているのも、この際どれかに統一されたほうがすっきりしてよいです。全部タグで吸収できないかな？または、もはやマークアップ言語ではなくなるがaction scriptみたいにMVCに徹底するとか。
さらに追記。
日本のケータイはどうする？最近javascriptが動き始めたばかり。ＰＣ、ケータイの垣根がある以上、HTML5が当たり前になっても、相変わらずしばらくの間はどちらのコードも書かないと。。技術革新時はそういうものだけど、実際作業する立場としては。。うー、しんどい。
まったく関係ないけど、サーバサイドの技術もこのところすごいみたい。
http://jp.techcrunch.com/archives/20090616videos-otoy-in-action-you-have-to-see-this/
3Dのハイクオリティゲームをブラウザで出来るようなのですが、これって本当？
タグ: HTML5
カテゴリー: 未分類 | コメントはまだありません »
2009 年 6 月 29 日
さてさて、今回はAndroid携帯のお話。
もうだいぶ前にdocomo、auなどが参戦を表明してましたが、いよいよdocomoから発売になるようです。以外に早かった印象です。
ＨＴＣ製のHT-03A。欧州向けのものをdocomo用にカスタマイズした模様。
ですが、今回の仕様を見て、一年半前の発表時に感じた不満というか、もやもや感というか、「うーん、やっぱりそこ止りだよね」という感想は変わらずです。残念です。
恐らく最初は「スマートフォン」的な位置づけになるだろうと予想してましたが、そのままなのでなんとも期待はずれです。
公式サイトに代表される課金プラットフォームとそれにまつわる機能はＮＧ、日本のメールの代名詞、絵文字もダメ。
直接関係ないですがFlash3.0のiモードブラウザ対応のときも思いましたが、既存のインフラとビジネスの保守を考えると、なかなか急には変わらない（変えられない）というのが現実かな。
（Flash3.0の目玉が根こそぎそぎ落とされていて失望した）
ライブチャットやtwitterなどリアルタイム通信バリバリ、キャリア課金無視して、もっと面白いものがフリーでバリバリ動くものがスタンダードになった日には、既存インフラ、ビジネスの崩壊になりかねませんね。キャリアはＣＰ守らないといけないですからね。
しかーし、これではビジネス的にはやはり蚊帳の外。本気でソフト作る気がしない。
でも、まあ日本で堂々とAndroidで３Ｇできるわけですから、はじめの一歩とポジティブに考えればいいのかな。少しずつ変わってくれれば。。いや、変わらなければ！昔、外国人に着信音が着メロっていうだけで面白がられた経験がありますが、日本先行、独自路線で突っ走れたのはいままでの話、気が付けばもうすでに技術的にも、ビジネス的にも米国、欧州、中国に抜かれてます。。
正式発売日はいつなのか、値段は？なんだかんだいって気になってます！
タグ: Android, スマートフォン, 携帯
カテゴリー: 未分類 | コメントはまだありません »
2009 年 6 月 12 日
どうも、浦島です。
前回に続き「Windowsのプログラミング環境」についてです。
今回の開発で、ツールが今も昔も「VisualStudio」だったのが救いでしたが、最新(VS2008)ってリソース周りのツールがひどく完成してないですね。一番びっくりしたのは、32bitのアイコンを扱えないところ。
ＭＳからするとそこは聞かないで！っていいたくなるところだと思いますが、ぐーぐるに聞いてみたら、皆さん面倒なことして対応してました。
VS2010に期待と、
先人に感謝です！
タグ: MFC, visual studio 2008, windows
カテゴリー: 未分類 | コメントはまだありません »
2009 年 6 月 12 日
こんにちは、おれです。
勝太郎作るのに久々にwindowsのプログラムを組みましたが、15年ぶりくらいだったので、完全に「浦島」状態でしたよ。
.Net Frameworkが主流だとかなんとか、.Netってなんだって？、そこからかよって、かなりげんなり。
MFCがまだ生き残ってたけど、なんか最近いきなりMSがやる気出して復活の兆しみたい。
たしかに、.Netで書けない最新の機能があって魅力的。
でも、普通に比較したら、作業量の少なさで.Netで書きたくなる。
うっー、どうしよう って迷ってたら、DataLabで必要なＡＰＩがＭＦＣ前提だった。
あと、純正のドッキングウインドウ使いたいっていう、まったく本質的でない部分が決め手でＭＦＣでゴリゴリいきました。
webだったらphpで3日で目的果たせるのになぁ。Windowsプログラマーはご苦労様です。
タグ: MFC, visual studio 2008, windows
カテゴリー: 未分類 | コメントはまだありません »
