わふうの人が書いてます。

iOSアプリケーション開発、BLEのファームウェアとハードウェア試作のフリーランスエンジニア。

Octpressインストールメモ

Macbook Air 11(2012 mid)にOctpressを導入したときの、メモ。

octpressを使うと:

  • Markdown記法(Markdown syntax guide)で書いたテキストを、ローカルで静的にHTMLに変換できる。
  • ソースと静的に生成されたウェブページはGitで管理できる。
    • ローカルで編集して好きなタイミングでリリースできる。
  • テーマやプラグインがあり、見た目のいいブログサイトを手間なく構築できる。カスタマイズもできる。

みたい。

プログラミング関連の記事を書くときに必要なソースコードのハイライト表示等が設定なしで使えるのが便利そう。
オフラインで書いて、そして静的に生成されたページは、ローカルのウェブサーバでプレビュでき、Gitで管理できるから、オンラインエディタを使う時のネットワークの切断を気にしなくてもいいのは、ストレスがなさそう。

環境構築
-

octpressインストールガイドの手順に従えばできる。octpressはruby 1.9.3以降を必要とするが、Macのは1.8系。そのためRubyの環境構築が必要になる。

octpress SetupでrbenvもしくはRVMを使う方法が紹介されているが、私は使い方がわからなかった。Homebrewで環境構築をした。

GitはXcodeのCommandline toolをインストールしていたので、すでにインストール済。
まずhomebrewをインストールして:

1
$ ruby -e "$(curl -fsSkL raw.github.com/mxcl/homebrew/go)"

rubyをインストール。

1
2
$ brew doctor
$ brew install ruby

~/.bash_profile にパスを設定して、1.9.3のRubyを先に見つけるようにする。

1
export PATH=/usr/local/bin:$PATH

コンソールを新しく開いて、先ほどの環境を反映させて、rubyのバージョンを確認する。

1
2
3
4
5
$ ruby --version
ruby 1.9.3p327 (2012-11-10 revision 37606) [x86_64-darwin12.2.1]

git clone git://github.com/imathis/octopress.git octopress
cd octopress

先ほどインストールしたruby関連コマンドを実行:

1
2
/usr/local/Cellar/ruby/1.9.3-p327/bin/gem install bundler
/usr/local/Cellar/ruby/1.9.3-p327/bin/bundle install

octpressがプレビューに使うコマンドを、実行パスにシンボリックリンクで置く。

1
2
3
4
5
6
7
cd /usr/local/bin	
ln -s ../Cellar/ruby/1.9.3-p327/bin/jekyll ./
ln -s ../Cellar/ruby/1.9.3-p327/bin/compass ./
ln -s ../Cellar/ruby/1.9.3-p327/bin/rackup ./

cd path/to/octpress
rake install

設定
-

Rakefileと_config.ymlの設定項目を書く。ブログのタイトルや、メールアドレス、Githubのアカウントなど。ここに設定しておけば、その関連情報を適当に表示してくれる。

ブログを書く
-
コマンドラインで新規ページを作れる。

1
rake["octpress-install-memo"]

source/_posts/ 以下にファイルがあるので、それにコンテンツを書く。プレビュー時や、deployするときは、ファイルが変更されると静的なページが自動生成/更新される。書いている途中に、それを禁止しておきたい時は、

1
published = false

ヘッダにこの1行を入れておく。

編集環境
-
Macで動作するMarkdowプレビュ・エディタを使うと、レンダリング結果を見ながら書ける。また、Markdownの記法に従いハイライトされるので、読みやすい。

編集とプレビュー
-
ファイル編集が完了したら

1
% rake generate

プレビュにしておくと、ブラウザで表示結果を確認できる。Markdownのソースファイルが変更されたら、変更を検出して、自動的に静的にページを生成する。コンソールのコマンドでプレビュを立上げる。これはCtrl-cで終了する:

1
% rake preview

WEBrickが4000番ポートで立ち上がるので、ローカルで http://127.0.0.1:4000 を開いて確認する。

iPad miniでプレビュ

iPad miniなど、外部から確認するときは、IPアドレスを調べて、開く。例えば:

1
2
3
4
$ ifconfig
en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
inet 10.0.1.9 netmask 0xffffff00 broadcast 10.0.1.255
^^^^^^^^^^^^^^ この端末のIPアドレス

無線ルータが割り当てたこの端末のIPアドレスは10.0.1.9なので、iPad miniから、http://10.0.1.9:4000 で開く。自宅で無線ルータを利用しているならば、MACアドレスに対してIPアドレスを指定して、同じ端末に同じIPアドレスが割り当てられるようにしておけば、常に同じURLでプレビュができるので、便利。

公開
-
ソースファイルはsourceブランチにある。Github pagesを利用しているなら、

1
% rake deploy

でmasterブランチに静的にHTMLファイルを生成、githubにpushする。これでuser-name.github.com でページが見られる。このページなら、http://reinforce-lab.github.com

その他
-

画像を入れるには?

octpressで画像を表示するには、画像プラグインで画像のURLを指定する。
私は、画像ファイルもmarkdownテキストと同じレポジトリで管理したい。そこでoctopressのsourceにpost_imagesというフォルダを作り、そこに画像ファイルを置いた。octpressは、sourceフォルダ以下に置いたフォルダとファイルを、自動的にサーバ側にコピーしてくれるみたい。

1
2
3
cd octopress/source
mkdir post_images
mv img_1261.jpg ./

img_1261.jpgはこのエントリで使った画像のファイル名。この画像を読み込むには:

1
{% img /post_images/img_1261.jpg %}

‘/’で始まるURLは、サーバのルートに置換してくれる。画像の幅だけ指定しておけば、縦横比はそのままで表示される。

レポジトリの扱い:今あるファイルがdeployされる

Gitpagesは、masterブランチにpushされたmarkdown形式およびhtmlのファイルを、jekyllで処理して静的に公開する仕組み。

‘rake deploy’で、今のローカルにあるファイルが、静的にhtml変換されて、masterおよびgithubにpushされる。sourceブランチにpushする必要はない。だから、一時的なお知らせのようなページも、sourceブランチにpushせず一時的に変更したままの状態で、’rake deploy’でgitpagesに公開できる。

Octpressのソース・ファイルはsourceブランチで管理されている。masterブランチは、ローカルから見えなくしてあり、’rake deploy’で、生成したhtmlファイルをmasterブランチにpushして、それをGitpagesにpushしてくれる。

部分的なファイルの読み込み

リンク・リストや、著作権表示のような、様々なページが参照する共通の情報や定形文章には、[render partial]機能を使う。
Jekyllは、ファイル名もしくはフォルダ名がアンダースコアで始まるものは、レンダリングの対象外にする。

利用方法:共有するリンク集

[render partial]を使い、ブログで頻繁に参照するリンク・リストを、別ファイルにして共有する例。
まず_source/_link.markdownというファイルを作り、

1
[render partial]: http://octopress.org/docs/plugins/render-partial/

そこにリンクのリストを書く。この書き方は、テキストタグとURLをリンクさせるmarkdownの記法で、本文中の[render partial]は、自動的にURLリンクに変換される。
そして本文の適当な場所に

を入れておく。先程のリンク集が本文によみこまれ、そこリンク集のタグを’[タグ]’で使える。相対パスの始点は、sourceフォルダなので、パスの頭に”_posts/“が必要。

岐阜人材育成講座 ~はじめるにあたり~

これは

2012年の岐阜県、スマートフォンアプリ開発関連人材育成事業でiOSアプリ開発の講師をしています。その講義で口頭で話した内容の概略メモです。
情報工学を受講したことがなく、C言語などは知らない方に、iOSアプリ開発に参加する上で知っておくべき、プログラミングの概念と技術の概要を伝えるのが、目的です。
このテキストは、講義を受けた方が、あとで内容を思い出すためのメモです。思い出すための糸口として概略をまとめています。

受講内容と想定している受講者

講義回数はは、1週間に2回、ほぼ1日の講義を、2ヶ月、全16回の予定です。
受講者は、C言語を知らない、またC++などで開発経験があるなど、スキルはさまざまな、経歴もさまざまです。

ぶっちゃけゼロから作れる開発者になるのは困難だと思っています

iPhoneの登場初期のような、真っ白な画面を表示するだけのアプリが”照明アプリ”として何十万ダウンロードを達成する時代は、大昔に終わっています。
iOSが出てから5年ほどですが、iOSアプリを企業また個人で作っている人の中には、10歳からプログラミングをしている人が、ゴロゴロいます。

そのなかで仕事としてiOSに関わるならば、たった数十時間で開発者になれる、という言葉の内容と意味を、自分が今まで受けた教育や蓄積した経験をもとに、考えてください。
私は、開発者になるのは困難だと思っています。無理だと言ってもいいでしょう。

しかし、iOSアプリの価値は、気持ちいい絵と音楽とユーザインタフェースです。純粋な開発者はそれを支える縁の下の力持ちです。この状況は、Windowsのような業務アプリとは全く違い、おそらくは、ゲーム開発会社に近いでしょう。その世界では、開発者の仕事が理解できて、アニメーションのパラメータ設定であれば自分で”コードを触れる”ことには、意味があります。

自分にとっての、iOSの知識と経験の活用を考えてください。また、自分が10時間でできることは、他人も10時間でできます。しかし、5年前に10時間でやったことをもとに、5年間の経験と蓄積を重ねているならば、その5年間はだれがやっても5年間かかります。その意味で、知識と経験の活用を、考えてください。

達成目標

習熟の目標設定は:

  • Obj-Cの言語仕様が”だいたい”わかる
  • サンプルコードをいじり(アニメーションの動きなどを変化させる)、そのいじった内容を論理的に他人に説明できる。

です。

テキストと資料

このほか、Appleの開発者サイト[https://developer.apple.com/devcenter/ios/index.action]には、ドキュメントおよびフォーラムがあります。

”プログラミング”の経験がある方は、”動くからいい”、を捨ててください

ProcessingやArduino、MAXなど、何かしらの動作制御やデータ処理をコンピュータでした経験があるならば、それはプログラミングの経験と呼べます。
この講座を受ける方は、”動くからいい”、”動けばいい”、という考えを捨ててください。

  • 考えて作らない
  • 経験を蓄積しない
  • 非効率な開発をする

考えて作らない

コードを書いたなら、それが当たり前に動くから、プロとしてやっていけます。それは、目の前で動くのみならず、仕様の範囲での”ありとあらゆる状況”で動くもので、あるはずです。
しかし自分の想定と違って、思ったように動いていない場合は、よくあります。
その場合は:

  • 開発時の、こう考えて、こう作れば、こう動くはずだ、を再確認する
  • その確認に基づいて、思ったような動きをしていない部分の、コードを読み直す、またデバッグなどでその部分を特定する
  • その部分の動きを確認する、予想と照らしあわせて、差異を見つける

手順を取ります。そして、修正します。
”動くからいい”と考える場合は、このフローが身につかない人が多いと、私は思っています。

経験を蓄積しない

動かない場合も、上記のフローを通して、なぜ動かなかったかを、知識として整理して、それが発生する状況を把握して、はじめて経験となります。

非効率な開発をする

iOSの開発に使うXcodeは、ステップ実行、ブレークポイントなど、アプリケーションの実行状態を直接確認できるデバッグ機能があります。

アプリケーションを1行づつ実行して、値の変化を追って、”動くようにした”という方がいるかもしれません。おそらく、それは、とても時間のかかる作業だったでしょう。
しかしそれは”作業”です。開発者に徹夜をして欲しいと思う人は、誰もいません。徹夜の回数を誇られても、残業代がかさんだなとか、トラブルメーカーになりそうだから、次の仕事ではこいつは外しておこうと、思うだけです。

もしも最初から、上記フローを使い、また経験を活用して、原因箇所を限定すれば、コードをよく読みなおすだけで、修正できたかもしれません。
動くものを作ることが仕事です。その結果に至るまでの、最も楽ができる、最も効率的な開発手法を、自分以外の人でも使える汎用なフローとして、身につけてください。

”プログラミング”をするまえに

概念を理解してください

概念はとても大切です。

  • それは、どんな概念か、
  • 歴史的な変遷もふくめて、どこから、どうして、その概念が生まれたのか、またそれが、こうして教え継がれる価値はなにか、

を吸収してください。

実作業の前準備が仕事の8割を決めます

目の前にある作業、コードを書くとか、Xcodeで何か作業をするとか、は肉体的な充実感があり、仕事をした気になります。
ですが、実作業をする前に、このクラス設計は正しいか、自分がこれから書こうとしているコードは、どこでどうつかわれるかを、理解しているか、”わかっているか”をチェックしてください。

英語は必要です

英文を読むことにアレルギーがあるなら、それを克服するか、この仕事は諦めてください。
ここでの”英語が必要”は、文章を読み開発に必要な情報を自分で吸収できること、です。

  • 英語構文の知識は、中学3年で十分です。
  • 技術用語およびわからない単語は、都度調べて覚えてください。
  • プログラミングガイドのような、長文を読むときは、文章の構造を利用して、短時間に無駄なく、どの詳細の階層を読んでいるかを意識すると楽ができます。
    • 英語は重要な情報が頭にくる、そして詳細が後ろに続く言語です。
    • タイトルと見出しは内容を濃縮した情報です。じっくり読んで全体を把握します。
    • タイトルに続く”概要”は、だれにむけて、どんな情報を、どう書いているのか、それを読むと何が得られるのか、をまとめています。読むべきか否かを判断するのに十二分の情報がここに含まれています。
    • 段落は、先頭の1行がその段落の内容を表しています。1行を読むのも時間が惜しい時は、接続詞と主語と助動詞(must, may, shall, そしてnotの有無)そして動詞を見ます。

独学はよいのですが独善になっていないか気をつけましょう

プログラミング言語でソースコードを書くときの、変数や関数の命名、また設計パターンは、何十年の先人が経験を蓄積してきた、定番の方法があります。独学はよいのですが、この点で、独善にならないように気をつけましょう。
プログラムのソースコードは、必要な機能をプログラミング言語で人間が読んでも分かりやすく表現する活動です。ソースコードで、他人が読みにくい”おりじなりてぃー(笑)”あふれるソースコードは、害悪です。もしも私がマネージャをしているなら、そのようなメンバーは即時はずします。それは、”開発後期”になって、原因が分かりにくい不具合を混入させる、その人のソースコードが読みにくい場合は他のメンバーにゼロから書きなおさせることになると、経験が告げるからです。
独善にならないよい方法は:

  • 事前にコーディング規則に目を通すこと、
  • 開発チームで良いコードを書くと言われている方のソースコードをよく読むこと、
  • チーム内でレビューを重ねてお互いにわかりやすいか、悪い意味で属人性の強い書き方になって
    いないかを指摘をもらうこと、

です。

1次資料、2次資料、3次資料を使い分けましょう

ここでは、

  • 1次情報:Appleが公式に出している情報およびAppleが運営するサイト
  • 2次:の情報が1次、著作物を残したりStackOverflowで評価が高い開発者の回答
  • 3次:その他のGoogleなどの検索で出てきた情報

とします。

1次資料は、例えばフレームワークの全体から詳細までを網羅した情報です。何かを開発するとき、”わかったつもり”にならず、公開されている1次情報の読むべき該当情報は、ひと通り目を通します。
開発をしていると、”個別の”、うまくいかないことや、どう作ればいいのかわからないこと、にぶつかります。そのような個別の情報は、Appleの1次ドキュメントから読み取ることは、大変です。そんなときは、Q&AサイトやGoogle検索を使います。

StackOverflowは回答の質を評価し、評価が高い回答が上位に表示されていて、役に立ちます。Google検索は site:http://stackoverflow.com と検索対象サイトを限定するのもよいでしょう。

Google検索で漠然と検索するときは、時間の使いすぎに注意します。検索1ページ目に回答そのもののページが見つからない場合は、検索ワードを変えるなどしましょう。もしも、検索結果ページに目を通しだしたら、脱線も含めて、回答が得られるまで3時間かかること、つまり今日の仕事の半分の時間はそれに通夜してしまうことを、を覚悟してからにしましょう。

検索の前に自分の状態を把握しましょう

2次、3次情報を探すときは、自分の状態を確認してからにします:

  • エラー発生箇所もエラーメッセージも分からない
    • 検索以前に自分が何をしているかが把握できていません。自分の能力を超えている仕事です。自分にはできないかもしれないと悟り、他の方と相談するなり、他の手段を考えましょう。
  • エラー発生箇所とエラーメッセージを読み取ったが、内容が理解できない
    • エラーメッセージは、同様の事例検索の強力なキーワードです。望むらくはそのエラーメッセージが、あまりにありきたりで、ありふれていて、数多くの様々な原因が、そのエラーメッセージを出さないものであることを、祈りましょう。
  • エラーの発生条件やエラーメッセージが把握できていて、SDKのバグではないか?など、自分なりに原因推定がついている、
    • 裏付けがほしい、程度で情報を検索するレベルです。おそらく1時間もかからずに、解決できるでしょう。

PassKit雑感メモ

Pass Kit 技術利用の予測

これは

6月13日に作成した、PassKitの技術概要から、iOS6が登場する2012年9月後半からの、動きの勝手想像。
PassKitについては、プログラミングガイドを参照

クライアントにメールで送ってたのだけど、ふっと見つけたので、ここに公開。

要点

iOSをプラットホームとして、電子メール、ウェブ(URL)、アプリから、ユーザにカードを提供する仕組み。

ビジネスなモデルは、i-mode。コンテンツを提供するインフラ。時代が違うのは、ユーザに直接かつリアルタイムに働きかけ行動を制御できる、チケットという概念を利用した、コンテンツとノーティフィケーションな代物。そのカードの提供には、Appleへの手数料はかからず、カード情報は、提供者自身のサーバから提供する。強いリアルタイム性が利用できる。

ユーザに広告チラシを渡して、それを所持し続けてもらえる感じ。その広告チラシ、メンバーズカードを通して、通知や提案ができて、それらがデバイスIDでヒモ付されている。

概念として、通知専用のウェブアプリをユーザヒモ付でワンクリックインストールする仕組みと理解すれば、応用の発想がしやすいだろう。

ユーザが、スマートフォンを持っていれば自動的に提案がくる、自動機械になる大きな転換点。もう、検索したり、操作したり、能動的なわざわざやらねばならない行動は面倒なだけな、強い方向性の提示。所持しておけば後は自動的に快適なものを提供する、糸口としてのモバイルなデバイス。

技術的には:

  • ビジュアルなカードを通知する、ノティフィケーション
  • 提供者は、自前のRESTfulなウェブサービスを通じて、JSON+画像をアーカイブ、電子署名した情報を、提供する
  • URLにはデバイス識別子が含まれる(デバイスの個別識別が可能)
  • 提供者は、パスをユーザのデバイスに、挿入、更新、削除、ができる
  • 扱いは、アプリへのノティフィケーションと同様。Appleに支払う手数料は発生しない。

Appleが提案する利用場面:

  • (航空券などの)チケット、クーポン、メンバーズカード
  • ユーザへの行動の催促、あるいは制御:(お店など)位置近接、(搭乗や上映)時間

ブレスト

  • こんなサービス提供しているところ、今までなかった?
    • インフラ的に提供しているとこは、しらない。Grouponとかが業態近いけど、メール保存のいちいちクリックでウェブなチケット表示?
  • アプリでもできたよね?
    • 自社アプリで同様のことはできた。アプリのインスト不要で、URL踏めばチケットなのが、違い?

ぱっと思いつく感じ、どんな感じ

  • 毎月、おすすめ商品写真がかわるメンバーズカード
    • 美容院の担当の方、予約可能時間が分かる、ワンボタン予約機能付きメンバカード
    • 先着100人限定クーポン
      • 100人きたら、クーポン消滅。もしくは、有効期限が翌日に伸びる。
  • キャンセル待ち予約チケット
    • キャンセルが出たら予約確定させます?な表示が出るチケットとか
  • 中古本売り買いだと
    • メンバーズカードー>買取価格をポイント化で10%アップ。
    • 購入した履歴にあわせた、在庫ありのおすすめ画像をカードにアップデート表示。限定キャラ絵とかもいいよね。
    • 買って売るユーザには、適当なタイミングで買取の提案してもいいかも。
  • チケット会社へのインパクト
    • 個人にチケットヒモ付により、自動的な転売屋の排除。

動き

対応する会社

  • POSなシステム (チケット管理システムとして、ウェブとアプリとその運用を必要とする)
  • チケット会社(ぴあ、セゾン)
  • イベント参加なウェブ会社 (ATND)
  • プリペイド発行会社

ギーク

  • 6月末には、ウェブサービスの基本ライブラリとサンプルアプリコードを使いこなすだろう
  • NDAで外には出せないので、社内やうちわで評価するだろう

技術手段な会社

  • Parse.comなどのノティフィケーションの代行サービスは、PassKitの代行サービスを提供するだろう。
  • iOSのPassKitを使いやすく、また同時にAndroidに同様なサービス提供できる形で、かつiOSのPassKitを一般の人が使えるウェブサービス会社が登場するだろう。
  • PassKitの代行会社は、ユーザの行動履歴を手にするだろう。ビックデータから、いかに適切にかつ好まれる提案ができるか、高い解析能力とセンスがあるところが、大きな成長を遂げるだろう。

機器メーカ

  • バーコードに限らず、汎用の画像を表示できるので、液晶画面のその表示を読み取ることで、既存のPOSを利用できるだろう
  • システム自体に組み込むことは容易なはずだが、iOSに必要なウェブサービスまでを開発/運用する能力はないだろう。→ 外注もしくは外部委託

特需?

  • 既存のメンバーズカード発行会社が、組み込むには。富士通とかあのあたりのものに増設。システムを分離すればいいから、難易度は低いが、動きは遅いだろう。ー> 食い込むチャンスかも
  • ビックデータでユーザの行動履歴分析のフラグが立っているから、NTT系列あたりが、システムごと移行でしかければ、楽かも
  • ヤマダ電機が、自社ポイントでゲーム、自社のポイントを仮想のゲームに投入して引当金を現金化させず、かつユーザを自社に惹きつけ留めようとするところは、利用価値、ありそう。

チケットなサービスの移り変わり

Grouponがサービス提供をするだろうが、後発のウェブサービスのみにしぼった後発の会社の登場で、衰退するだろう。
自身の店のチケットを発行する、低価格でだれにも使いやすいウェブサービスが登場するだろう。それは、iOSおよびAndroid(独自アプリ)を通じて、パスを発行し、またアップデートをするだろう。その手数料はとても安く、Grouponに支払う手数料分を、さらに割引に使うことが可能になるだろう。
ウェブサービス提供者は、デバイスを個別に識別するIDにひもづけられた行動履歴を入手するだろう。それは、より的確なクーポンの提案を可能とし、ウェブを見ない人に、消費活動を引き起こすだろう。

Googleは対応しない

Googleは対抗しないだろう。
PassKitが提供するクーポンは、極めて低価格になったチケット発行と管理コストでういた広告コストで、さらなる割引を可能とする。これは、ユーザに魅力的な広告だが、しかしウェブサービスを通さず、ユーザに直接届く。チケットが作る市場は、ローカルの流通に、入り込むだろう。
これは、Googleが欲しいが、手に入れられない市場だろう。だが、もしも、広告手数料を収入とするGoogleが参入するとすれば、iOSのプラットホームで3rdパーティが提供するウェブサービス自体を含めて、Androidで、提供することになるだろう。しかしそれは、Androidに露骨な利益を誘導する自社サービスをいれることであり、端末メーカはそれを許さないだろう。

開発特化な会社としてのやり方は

技術:汎用。最初の切り込み方向はi-mode向けのシステム会社がたどったような感じだろう。サーバやコンテンツのアップデートをサービス提供。ただし、ユーザの行動履歴が取れるので、その分析をする/しないで、本質i-mode時代とは違うものになれる。ただ、それがチケットなサービスから切り込めるかどうかは、知らない。最適チケット発行で食い込んで、そのうち、これいいじゃんと気づかせて、本社のカードなシステムに食い込む感じだろうけど。

囲い込み:弱い。立ち上げの開発コスト。たぶん、プロトなら2週間x6人。ウェブとアプリ開発者+ディレクタ構成で。1000万はかからないイメージな、むちゃ安。だから、どこもやるだろう。iOS6 NDAがとけた時点で、外に出るんだろうけど。システム自体は、いちどやったら、初期立ち上げの手間があるから、最初にやって、囲い込んだもの勝ちかしら。

Android向け開発:とりあえず独自アプリで同じチケット環境提供でやればいいだろう。Androidは無視はできない。アプリでAndroidのほうの、囲い込みにもなるし。Googleが本気でやれば、半年で実装して出すだろうけど、その時はそちらを利用に切り変えればいいくらい。

雑記

2010年にAppleが出したConnect Ticket+、パテント。
http://www.patentlyapple.com/patently-apple/2010/04/apple-introduces-us-to-a-new-itunes-concert-ticket-system.html

”クラウド チケット”で検索すれば、いろいろ出てくる。やることは、おんなじだよな。費用が、初期10万、月額〜、とか、かなり属人的に消耗戦な課金。
おそらく、初期導入費用ゼロで、使った分だけ課金な商売をやったところが、勝つのかな。