Search: “parse”

昨日、ずっと枕を濡らしながらAWS Mobile Hubについて調べていたので、AWSとかさっぱりわからない人の視点で、Parseとの比較をしてみる。

そもそも僕はAWSを本格的に使ったことがなく、Voicepaperの音声ダウンロード先にS3を使っているぐらいだ。つまり、AWS童貞と言っても過言ではありません。

さらに、一応CakePHPでWebサービス作ったことはあるものの、そんなのは３年以上も前でもう忘れたし、その時のサーバはサクラのレンタルサーバである。つまり、バックエンドなんてわからない、残念なプログラマという位置付け。

そういう人だからこそParseをこよなく愛し、Taxnoteに自動同期つけようと4か月近くCoreDataとの連携をせっせと準備し、UIもいろいろできた、リリースするかといったところで、Parseご臨終の悲報を聞いたのが先日だったわけです。

いやあ、僕は自分のコードでバグないかとすごい心配してたけど、サービス自体がなくなるとは想定外でしたね。つい最近までダッシュボードをリニューアルとかしてて、そんな気配は微塵も感じなかったし。

いつものようにParseのダッシュボード開こうとしたら、悲しい告知文がでかでかとあり、ショックなんてもんじゃなかったですね。

ザッカーバークも育児休暇から帰ってきたら、気分が変わったのかな。

というわけで、AWSとかよくわからない人が、Parseからつい最近出たAWS Mobile Hubを数時間勉強した感想を書いてみます。

AWSマスターの人は全く役に立たないけど、似たような境遇の人にはちょっと役に立つかもしれない。

なぜAWS Mobile Hubなのか

いや、実はまだどれに移行するか、そもそもバックエンド自分で頑張るかなども含め、検討中なんですよ。

でも、正直、この分野はParseが圧倒的に使いやすく、有力な他の選択肢はいなかったという認識なんですね。偏見ですが。

さらに、バックエンドみたいな依存度の高いサービスで、またParseみたいな事態が起こったら怖すぎる。たくさん、似たようなサービスあるけど、３年後に生き残ってそうな安心感があるものはといえば、難しい。

と考えたところ、FirebaseかMobile Hubを触ってみようかと思い、Mobile Hubの方が、AWSのツールだからまだ安心感あるわと思って、こっちから勉強することになりました。

ちなみに、Parseの代替は？っていうリンク。いろいろあるんですね。
https://github.com/relatedcode/ParseAlternatives

AWS Mobile Hubの情報源

最近発表したばかりでベータなのもあり、日本語の情報源は少ない。英語の情報源も少ない。

日本語で、情報が多かったのはコレでした。
AWS Mobile Hubで超かんたんモバイルアプリ開発 (Android / iOS)

そして、英語も入れると、一番良いのは、Amazonの解説動画を見ることです。これを見たらだいたい概要つかめました。

そして、何より、Mobile Hubは実際に触りながら分かるという具合にできていて、自分が使いたい設定を選んでサンプルコードを生成してくれる。

だから、ざっと上記のリンクで概要掴んだら、いきなり触ってみるのが一番良さげ。

AWSのいろんな単語に戸惑う

まず、最初に戸惑ったのが、AWSのいろんな単語です。

やれ、Cogniteだ、Lamdaだ。初めての自分にはツールがありすぎて、どれがどれだかわけわかめ。

サービスの名称を見ても、何をしてくれる機能なのかはわからないものが多い。まるで、アプリを開いたら、アプリ独自のアイコンや名称ばかりで、どのボタンもタップするまで動きがわからないみたいな。

今思うと、なんでAWS DataStorageじゃなくて、S3っていう名前なんだろうか。

そして、説明を読んでもAWS童貞にはあまりピンとこないのも多い。

昨日わかったことは、AWSはいろんな便利ツールがあるけど、それをモバイルアプリ開発で、簡単に扱うツールというのがMobile Hubらしい。

Parseみたいなサービスを作るぜ！ってAmazonが新規に開発したという感じではなく、これ使うとAWSのツール群と簡単につながりますよみたいな。

Mobile Hubで出来ること

ユーザ認証 (Facebook、Googleなど)、プッシュ通知、S3使ったコンテンツ配信、ユーザのデータ保存(写真とか)、解析ツール、クラウド側のロジックを書く。

この６つが簡単に設定できると。

ユーザ認証はParseみたいに、洗練されたUIを使えるわけではなく、シュールなWebっぽいUI。そして、悩ましいのは、Facebook連携とかしない、メアドで独自のアカウント作成してもらう時は、自動でやってくれないみたいだ。

多分、何かと繋げればやれるのだろうけど、そのままだと出来ませんみたいな印象。

S3使ったコンテンツ配信は良さげ。何と、全世界のサーバ使ったCDNか、一つのポイントから配信するかの選択もできる。これはいい。

ユーザのデータ保存は、写真とか、そういうものを保存できる。

で、僕が最初に探したのは、CoreDataと連携して、データベースの自動同期をしたいので、このUser Data Storageというデータ保存機能はそういうことできるのかと。

調べた結果、できないみたいだ。それはDynamoDBというデータベースツールを使うらしい。それはMobile Hubには入ってないから、自分で設定してなみたいな位置づけらしい。

どう繋げるかは、まだよくわかってない。

AWS Mobile SDK

Amazonさんは、だいぶ前からAWSとモバイルアプリ開発を繋げるSDKを出していたようだ。調べて初めて知った。

それがAWS Mobile SDK！ これは、リレーショナルデータベースを使えるDynamoDBとか、S3とか、そういうものもiOS SDKから使える！

じゃあ、これ、Mobile Hubとどう違うのと。悩ましい。おそらく、Mobile Hubは連携の面倒な部分を一気にやってくれるんだろうけど、この二つをどう区別したらいいかが分かってない。

サンプルコードを見てみたら、メソッドとかがParseで慣れていると使いにくそうだというのが印象でした。Blocksの書き方とか、SaveEventuallyとか、そういう便利なメソッドはなさそうだ。

僕みたいな人がここで疑問に持つのは、じゃあ、AWS Mobile Hubって一体なんなのかっていうことだと思う。AWSのツール全部と繋げるわけでもなさそうだけど、やろうと思ったらAWSのツール全部使えるみたいな印象だし。Mobile SDKとの位置付けを説明してくれよと。

Amazon Mobile SDKのリンクがこちらなんだけど、飛んだら、なぜかMobile Hubのボタンが中央にあるぞ。この困惑のUXは如何なものか。
https://aws.amazon.com/mobile/sdk/

親切な人が教えてくれるかもしれないので、その時はこの記事をアップデート。

*親切な人が教えてくれました！
Mobile Hubは、環境構築 + テンプレートソースコード自動生成するものらしい。AWSのリソースは複数のサービスを連携して使用する必要があるため(例えば、LambdaとIAMを設定等)、それをサクッとやってくれると。

となると、Mobile Hubで環境構築して、AWS Mobile SDKを使うことになりそうなので、SDKの使いやすさがキモとなりそう。

AWSだけあって

AWSだけあって、いろんな有名サービスがアプリのバックエンドとして使ってるし、使いこなせば最強っぽい。

AWS Mobile Hubで最初から連携できることは限られているけど、AWSのいろんなツールに連携したら、いろいろできるみたいだし。

しかし、その使うための導入部分のUXとか、分かりやすいドキュメントとか、SDKの出来などがParseの強みだったんだけど、そういうのに慣れていると、結構頑張って、わかりづらいジャングルを突き進まないといけないイメージ。

多分、一発もののアプリならFirebaseとか使った方がサクッとやりたいことはできそうではあるが、長期的にやりたいプロジェクトとかなら、AWS使った方が良さそう。

いやあ、勉強しないといけないことは多そうだ。。でも、AWSはそんな簡単に亡くならないだろう。。多分。。

こういうインフラ依存とか、プラットフォーム依存って、ITビジネスの難しい問題ですね。全て自前でやるのは非合理な場合が多いし、依存したら一気に崩壊する危険性もあるし。

飛行機は乗りたくないけど、旅行するには、他の現実的な選択肢がないみたいな。ベルカンプさんは別だ。

Tweet

iOSでParseと Parse Local Datastore最近２ヶ月ぐらい触ってるので、わかったことを書いてみます。間違いがわかれば嬉しいので、突っ込み歓迎。

さて、Local Datatoreは発表された時から僕はワクワクドキドキしていて、そのドキドキ感をブログで書いてきました。

Parse Local Datastore for iOSがやっと出た

しかし、実際には使ったレポートは書いてなかったんですね。なぜなら使ったことがなかったから。

しかし、最近はというと、２ヶ月近く前から毎日ParseとCoreDataの連携するコードを書きまくっていて、いろいろわかってきたことがあったので書いてみる。

基本的には、ParseのForum、Google Group、StackOverFlowで書かれている先人の知恵を借りながら、そこで書かれている現時点のベストプラクティスを参考にコード書いてる。

@目的
Taxnoteっていう経費記帳アプリに自動同期機能つける。

@背景
元々はCoreDataオンリーのアプリ。CoreData + Parse (+ Local Datastore)で自動同期機能をつけようとしてる途中。

@目指す動き
オフライン時はローカルにデータを保存し、オンラインな時にサーバと同期する。ようは、オフライン時でもキビキビ動いて、ユーザは意識しないまま、勝手に裏で同期が動く。

いろいろググったけど、Parse Local Datastoreをまとめたブログ記事は英語でもあんまりないので、参考になれば幸いです。

というわけで、まずは、Parse Local Datastoreの話を中心に書いていきまして、その後に、Parseの普通のメソッドの話を書いていく。

CoreDataとParse繋げるライブラリないの？

そもそも、僕はあんまり自分でコード書くより、もっとプログラミングが上手い人のライブラリを使いたいんですが、残念ながら良さげなのがありませんでした。

FTASyncは数年前に書かれてメンテはされてないし、すごくベーシックなことしかできないみたい。また、NSIncrementalStoreを使ったライブラリも試してみたんだけど、これも今はメンテされてなくて、上手く動かなかった。

Local Datastoreがでたから、みんなこっち使おうね。みたいな流れらしい。ただ、Local Datastoreはパフォーマンスの面で致命的な問題があり、使えず、しゃあないから自分で書かないといけなくなったと。

あとは、同期ってデリケートだから、自分で書いたほうがバグとかも対応できていいかなと思ったら、予想以上に大変で時間かかってる。

Local Datastoreのパフォーマンス

100個ぐらいのデータなら問題ないけど、1000個ぐらいセーブした時点で遅くなる。1500個ぐらいのデータを一気に取得しようとする時、iPhone6Plusで2秒近くかかっちゃう。CoreDataと同じことしようとしたら、雲底の速度差。

なので、Taxnoteのメインのデータのクラスには使えず(仕訳帳のクラス)、大幅に書き直す羽目に。

Taxnoteだと、メインの入力していくデータには使わず、勘定科目リストなどのデータのみに使うことに。

なぜかというと、科目リストのクラスと、メインの帳簿クラスはRelationで繋がっているので、ParseにSaveするたびに、Relationの呼び出しする時にLocal Datastor使うと便利だから。

Pinを分けたらパフォーマンス改善しないの？

Local DatastoreにはPinといって、それぞれ保存する領域を分けられる機能がある。

これを使って、カテゴリクラスのpin、エントリクラスのpinみたいに、Pinを分けたらパフォーマンス改善するかなと思って試してみた。

結果的には改善せず、Local Datastoreのパフォーマンスはこの時点で諦めた。なので、Local DatastoreをCoreDataとか、オフラインデータベースの代替品として使おうとするのは無理ゲーだと思う。

最初は自分もそういうふうに使えんじゃねえかと夢想したけど。

Local Datastoreをsyncするメソッドないの？

これ、Local Datastore使い始めたら思うんだけど、ParseをLocalに保存したものを、サーバ側と同期するメソッドがないんですよ。

Local Datastore Syncみたいな。

オフラインの時はLocal Datastoreに保存して、まだサーバに保存されてない部分だけ明示的に同期するとか。そういうメソッドがあれば便利なんだけど、残念ながらない。

どうすりゃいいかというと、結局、Parseのモデルクラスで、needSyncみたいな項目を作って、自分で needSync = NOのやつを後から呼び出して、syncされてないやつだけちゃんと保存しておくとか。

こういう面倒なことをしないといけない。こういうメソッドは必要だろみたいなことは、Parseのフォーラムでも書かれてます。まじで必要。

ここまで、Local Datastoreの話で、以下は普通のParseのメソッドについての話。

SaveEventuallyの弱点

Parseには、SaveEventuallyっていう、データを保存した時、もしオフラインだったら、あとでオンラインなった時に勝手にサーバに保存しときますよっていう素敵なメソッドがある。

これは、ドキュメント読む限りでは神メソッドだ。

ただ、オフライン時に何回か連発で呼んだり、呼んだ後にアプリをタスクから強制終了させたりしたら、Parseサーバに反映されないデータが出たりする。

いろいろテストして、信頼性が低いので結局使わないことにしました。CoreData側でneedSaveとか、needSyncとかのattribute作って、自分でオフライン対応することに。

SaveInBackGroundもSaveEventuallyのようにオンラインなったら自動saveされる動きするので注意。

まあ、すごく厳密にデータSaveされなかった漏れがないようにしたかったから、Taxnoteでは使わないことにしたけど、そこまで厳密にする意味ないような時はガンガン使ってよいと思う。

たいていの状況では普通にあとからsaveされるし。

複数データを一回でsaveAllした時のリミット制限は？

Parseには、1秒間に何リクエストまでという制限がある。無料プランだと少なくて、有料で段階的に上げていける。

例えば、100個ぐらいのデータを PFObject saveみたいな感じで100回繰り返せば、100リクエストになっちゃうのはわかるとして、100個のデータをまとめて、PFObject saveAllで保存したらリミット制限にはどう影響するか？

これは、saveAllでまとめて保存しても、保存するデータを個別にカウントする。だから、無料プランで、1800個ぐらいのデータを一発のsaveAllで保存しようとすると、リミットにひっかかりましたのエラーが出る。

まあ、そんなことは起きないアプリなら問題ないんだけど、Taxnoteは二年分の仕訳帳データが既にあったら、全部で1800件ぐらいなっちゃうんですよ。それを自動同期使う時に一気にアップロードしようとすると、エラーメッセージでてわかった。

解決策は、有料プランでリミットを上げるか、複数回にリトライするか。今、ここやってる途中。

データ削除の設計

これが厄介なんだけど、デバイスAとデバイスBでのデータを同期する時、片方で一つのデータを削除したら、もう片方でもデータを削除しないといけない。

例えば、デバイスAである一つのデータを削除した時、サーバ側でそのデータを本当に削除しちゃうと、デバイスBで同期する時に、そのモデルクラスにある全てのデータをシンクロしないといけなくなるんです。

これはパフォーマンス的によろしくない。

というわけで、実際にサーバ上ではデータを削除せず、isDeletedみたいなカラムを作って、ソフトデリートというデータベース設計の手法を使うらしい。

これなら、デバイスBはisDeleted = YESとなっているのだけQueryで検索かけて同期し、デバイスAで削除されたデータをデバイスBでも同期した時に削除するという動きができる。

まあ、これがベストなやり方だとは思うんだけど、定期的にサーバ側でisDeleted = YESになっているデータをクリーンアップする必要があるんですよね。Cronとか使って。このタイミングが悩み中。

これはParseは直接関係ないけど、同期アプリ作る時はぶち当たる壁かも。

まとめ

Parse Local Datastoreは1000件ぐらい保存したら遅くなるので、この遅さが問題になるアプリなら使いにくい。結局、CoreDataとParseの連携部分のロジックを書かないといけない。

でも、局所的に使うには便利です。

Taxnoteだと、仕訳帳一覧のモデルクラスと、科目のモデルクラスでRelationsつなげないといけないので、科目の部分だけLocal Datasore使うのは意味あった。

ちなみに、TaxnoteはもともとCoreDataで作ってたけど、新しいアプリなら、Realm + Parseで作ってたかも。Realm評判いいし。

Tweet

先日、ParseのエバンジェリストであるEricさんに会いに行ってきたという記事を書いたけど、7月24日にParse Meetupを六本木で開催するらしい。

https://parsemeetuptokyo.splashthat.com/

Parse使ってるけど、Parse周りで情報交換したいとかいう人はオススメだと思う。

しかし、このイベントページ見た人はこう思うはずだ。

「あれ、これ全部英語なの？ここ、日本だし、僕日本人なんだけど？」

そうなんです。今のところ、英語オンリーの予定みたいだ。(同時通訳してくれる人が現れる可能性もあるけど)

場所は六本木のFacebookオフィスだから、この前お邪魔したあの高そうなビルですね。アークヒルズ仙谷山の森ビルだから、あのみんながイメージする、映画館とか隣接するでっかいほうの森ビルとは違うので注意。

Ericさんいわく、このビルの賃料はサンフランシスコより高いぜ！だとか。

このイベント、第一回なのもあり、かなり濃いメンツが集まりそうな予感がするので面白いと思う。ちなみに、このイベントページを作るサービスいいですね。Splashというのか。
https://www.splashthat.com/

Tweet

先日、Facebookが買収したモバイル開発者向けツール、ParseのエバンジェリストであるEric Nakagawaさんと会ってきた。

先日シリコンバレーに初めて行った時、一緒に行った写真右の加藤さんの友達のジョージさんと飯食って、そっからジョージさんが繋げてくれたという経緯でした。

東京にあるFacebookのオフィスに遊びに行ったんだけど、アーク森ビルとかいう賃料高そうなオフィスだった。Facebook金あるな。

Facebook Japanのオフィス

情熱に心動かされる

なによりも印象に残っているのは、EricさんのParseに対する情熱だ。もう、エバンジェリストはこうあるべきというお手本のようなお人で、Parseをどうやって広めていくかを凄い考えている。

どうすれば、日本でParse開発者が助け合うようなコミュニティーができるかを熱っぽく語っていて、話出したら止まらないエネルギーに溢れていた。なんか、こういう情熱があると、人間誰しも応援したくなると思う。

ちなみにEricさんは、シリコンバレーで起業して会社を売却した成功者なのでお金持ちなんだけど、自分もParseをずっと使ってきていて、今でも個人で小さなプロダクトを作る時にParseを使っているらしい。

「Parseが好きだし、Parseに入る前から使っていてよく知っていた。Parseのようなサービスがあれば、近い将来、デザイナとエンジニアの二人だけでも世界的に大きなサービスを作ることが出来るようになると思う。」という話を熱っぽく語っていた。

これは、僕も以前から思っていたことで、Parseのようなバックエンドやスケールを担当してくれるサービスを使い、下手したら一人で相当スケールする部分までやっていけるようになるんじゃないだろうか。

とにかく感じたのは、EricさんのParseラブな情熱で、どうすれば日本でもParseがもっと広がるか、よいParseコミュニティーが出来上がるかということを考えてた。

僕も、Parseは登場した時から、「こいつはすげえサービスだ！」と思い、このブログで何回か取り上げたり、Lisgoで月額課金試す時に使ったり、今せっせと作ってる新しいアプリでも使っている。

なので、Ericさんの話をうんうん聞きながら、自分の頭で、うーん、どうすればParseを日本で広めるいい方法はなんだろうなとJetDoでメモとりながら考えてた。

加藤さんと一緒に、こういうやり方はええんじゃないだろかとか、いろいろ話してたわけです。

Ericさんの存在と情熱を伝えるには

日本人からしたら、Parseって海外のサービスだし、どうしても遠く感じるんですよね。特に、データベースを扱うし、モバイルアプリだとWebサービスと違って簡単に後からスイッチができない。バージョンアップもインストールしてもらう必要があるし。

となると、どうしても海外のよくわからないサービスだと顔が見えづらいし、なんかあった時のサポートも不安という心理になってしまう。

だから、Ericさんのようなエバンジェリストの存在が重要で、最近の開発者向けサービスのスタートアップはコミュニティーマネージャ的な職業をすごく重視している。

実際僕も、Parseは便利なサービスだけど、なんか問題が起きた時にあまりノウハウもまだまだ少ないし、不安だなあと思っていた。

でも、「なんでも聞いてくれ！」みたいな情熱のある人がエバンジェリストとしていると凄く大きい。こういう情熱を持って開発者をサポートしたいという人がParseの中にいるんだと認知するだけでもでかいなあと話聞きながら思いました。

じゃあ具体的にどうすりゃいいのかなと。

イベントなどで露出する

まず真っ先に考え付くのがこれだと思う。

日本には開発者の勉強会が多く、そこで登壇して実際に日本の開発者と顔を会わせる機会があるだけで、だいぶ違う。Ericさんの母国語は英語で言葉の壁はあるのだけど、それでも大きい。

こういう事を言うと、「来日した時にイベントなどに出てもいいんだけど、よくあるのはさっと発表して、さっと帰るだけのマーケティング色が強いパターンが多いので、それは個人的に好きじゃないんだよね。ちゃんと、開発者の人たちと向き合って、コミュニティに貢献したい。」

というような返事が返ってきた。うーむ、自分が開発者としてやってきたのもあり、いろいろ考えているんですな。

いっそ、日本人のエバンジェリストを雇う

これは、適任者が見つかるかとか、ハードルが高いんだけど、最も効果的だとは思う。

例えば、Realmというモバイル向けデータベースのスタートアップに、iOS界ではGod的な存在である岸川さんが少し前にジョインした。

これは凄く大きな効果があって、iOS開発者の中では一気にRealm使ってみようかなという人が増えたと思う。

日本でのRealm関連の勉強会も増えたし、Realm関連の日本語での記事もよく見る気がするし、今までアメリカのスタートアップのサービスという遠い存在だったものが、みんな知っている岸川さんが窓口になったという心理的安心感はでかい。

でも、岸川さんみたいに技術力が高くて、なおかつコミュニティに顔が広い適任者なんてそうそういないよねっていうのは現実なので、他の案もいろいろ考えました。

技術系サイトのインタビューに出る

これならそこまで大変じゃない。

Ericさんがエンジニア向けサイトのインタビューに出て、「これから日本のParseコミュニティをサポートしていきたい」といった、僕たちにランチしながら熱く語ったような話をするだけでもでかい。

ああ、日本人のコミュニティも考えてくれてるんだなとも思うだろうし、Ericさんが日本に来日してる時に、Parseユーザ向けのオフィスアワーをそこで宣伝してもよいし。

来る人をある程度スクリーニングするという意味では、ParseのTipsをブログで書いてくれた人を優先的に抽選でオフィスアワーとか。

日本語ブログ、ヘルプの翻訳家

これはコストかかるからすぐにはできないけど、確実に効果ある。

ちなみに、Parseを使って、将来スケールした時に、AWSとかに移行するノウハウを詳しく書いて欲しいと個人的に提案しました。

ほとんどのサービスは失敗するので、Parseから移行する必要なく終わるだろうけど、人間心理としてParseを導入する時に、誰もがスケールした時のことを考えるんです。

その時、他のサーバに移行する時のノウハウがネット上にはあまりないので、それなら最初からAWS使おっかていう人は少なくないと思う。

もちろん、大きくなってもParseを使っていくという選択肢を取るかもしれないけど、移行の方法を詳しく解説することにより、逆にParseを使い始めやすくなるといった考えを話した。

Parseのコミュニティ

ちなみに、Parse使っている人の不安点として、以前あったParseの公式フォーラムが止まっていて、StackOverFlowで質問してくれみたいになってるんですよね。

これが、Parse公式のサポートがほぼ停止しちゃってんじゃないかっていう不安感あるという事を話したら、現在はParse Googleグループが一番活発なサポートコミュニティらしい。知らなかった。

最近ではサポートにSlackも使われ始めてるらしい。確かに開発者向けサービスなら相性よさそうだ。

ちなみに、最近できたFacebookグループ、Parse.com Developers Japanもあります。ここはほぼ日本語。Ericさんも入っている。

Parseを会社サービスの規模で運用しているnohanaのエンジニアの人の話とか、すげえ内容が濃くてやばい。この前、第一回の飲み会を恵比寿でやったのだけど、相談できるコミュニティがあるとやっぱいいですね。

Ericさんが登場するAsk Parse Anything。

Tweet

やっと出た。やっと出た。

以前ブログで紹介してからというもの、ずっと今か今かと待ちわびていたParse Local DatastoreのiOS版がついにリリースされた。

http://blog.parse.com/2014/12/09/parse-local-datastore-for-ios/

半年以上前にこの機能は発表されて、Android版しか出てなかった。iOS版はいつ出るのと思って忘れた頃にやってきた。

Continue reading

Tweet

先日Facebookのf8とかいうイベントがあった。僕は去年のf8はそこまで注目してなかったのだけど、Parseがf8に買収されたので今回は楽しみにしてました。

そしたら期待のParseからこりゃいいねという発表が２つあった。

ひとつはParseの料金体系が変わり、安くなったこと。もうひとつはオフライン時のデータベースを扱うParse Local Datastore。

特にLocal Datastoreはオフラインで使えるデータベースを実装しつつ、他のデバイスとの同期も実現したいモバイル開発者にとって死ぬほど期待の機能。ワクテカが止まらない。

なぜかAndroidのみ使えて、iOSは近日公開らしい。待ちきれん！

Parseの新しい料金体系

今までは月に一定の回数のアクセス以上は有料になりますよっていうシステムだったけど、今度は一秒間に30requestsまでだったらいくら使っても無料になった。

一秒間に40requestは月100$といった感じで、スケールしていったら高くなる。これはいいかも。ただ、気になるのはオートスケールしてくれるかってところだ。

ドキュメントを読むと、無料プランで制限を超えるリクエストが一秒間にあったらエラーが出ると。

じゃあ、普段は無料で余裕で使えてて、突然なんかの拍子でバズって、いきなりアクセス殺到してエラー連発だったら困る。こういう時に自動的にスケールして頂きたい。

でも、リミットはつけておきたいので、100$のプランにしておけば制限をその月に一回でも超えなければ自動的に無料になって、超える時があればその月は100$払うっていうシステムなんだろうか？

ここが気になる！Parseの新しいシステムでPriceの設定を見たりドキュメントを読んだかぎり、ハッキリとわからない。

100$のプランにするボタンがあるのだけど、このボタン押したら一気にその月に100$の請求来るのか怖くて試せない。

ということで、質問しておいた。
The 30 requests/second price plan can be scaled automatically?

※アップデート
残念ながらオートスケールしないみたい。100$のプランにすると、30req/sを超えてなくても請求くる。つねにエラーをチェックしてくれという悲しい返信がきた。

iPhoneアプリ同期機能の面倒さ

iPhoneアプリにデータベース機能をつける時はCoredata使うのが一般的なんだけど、アプリを他のデバイスでも同期できるようにする時に、Coredataをサーバ側のデータベースとシンクロさせるのが凄い手間。

データベースはサーバ側のみとすると楽だけど、それだと毎回読み込みが発生するので遅いし、オフライン時に使いかってが悪い。

アップル製品だけで同期すればいいという方針だとiCloudがあって、長らくぶっ壊れてて使えないと評判だったiCloud + CoredataもiOS7でいくらかましになったらしい。

でも、それでも構造上の問題でまだまだ鬼門だと海外の有名な開発者のブログとかで書いてました。僕は面倒なので、有名な人がまだまだ面倒だと言ってたら自分でチャレンジする気も起きずに悶々と過ごしてた。

理想はiOS側ではオフラインでもさくさくデータベースに保存できて、バックグラウンドでネットに繋がってたら自動で同期して、iPhoneとiPadがシンクロするといった形。

この問題で期待をしてるのが、ParseのLocal Datastore。

ParseのLocal Datastore

ParseのSDKって凄くよくできてて、データベースの実装とか本当に分かりやすく直感的なコードで書けるんですよ。

iOSのCoredataとかで書いたらすごく面倒なコードを長々と書かないといけないけど、ParseのSDKだと分かりやすくて短いコードでちゃちゃっと。

でも、Parseはもともとクロスプラットフォームで同期するためにサーバにデータをその都度送信する前提で作られてる。

一応、ParseのSDKにはキャッシュで保存する、saveEventuallyみたいなメソッドもあるんだけど、このキャッシュ機能は貧弱なもんなので、Coredata使った時みたいにはオフラインで保存して検索とか使うのは無理だった。

だから、iOSでオフラインでもサクサク保存したり、検索したり、フェッチしたりするには結局CoreData使わないといけないねっていう結論になって、iPhone/iPadで自動同期機能つけたい僕もCoredata使ってた。

で、Parseの掲示板見ても、サクサクオフラインで動くようにCoredataを使いつつ、同期機能のためにParseとCoredataを繋げる実装をみんな四苦八苦しながら頑張るという苦しみを訴えている人がたくさんいた。

Parseチームは、「今、この問題に取り組んでます。」とか一年前に書いてた。そして、一年ほどたって、Local Datastoreがやっと発表されたので期待せずにはいられない。

Coredataいらないぐらい強力だったら最高

まだiOSには対応してないから試せないのが悲しい。出たら速攻で試したい。

Local DatastoreのAndroidのサンプルコード見た限りだと、普通にParseの保存、検索などの機能がオフラインでも動きますよといったように見える。

それだと、将来同期機能を予定しているアプリに、最初からParseSDKでデータベース作ってCoredataを代替できるようになるかもしれない。

CoredataとiCloudとか、CoredataとDropboxAPIとか、CoredataとParseを上手くつなげてシンクロ機能を上手く動かすというめんどいことが一気に解決しそうなので、これは期待するなというのが無理というものです。

LocalDataStoreのコメント欄には興奮した開発者たちが、「おお、これが出たらもうCoredataとParse繋げるために今苦労してる実装いらなくなるから、いつ出るか教えてくれ！」とかみんなも期待度マックスのようです。

その気持ちは本当にわかる。僕もTaxnoteやZenyでiPhoneとiPadの自動同期機能をつけたいんだけど、実装に入るのはこれが出るまでちょっと待とうかと悩み中。

この動画の14分55秒あたりからParse創業者の発表がある。Parseの料金体系、Local Datastoreの実際のコード、AppLinkとかのデモなどがざっと全部見れるので、オススメ。特にAppLinkのデモは一見の価値あり。

※Facebook Updates Parse With Lower Prices, Improved Analytics, Offline Capabilities

Tweet

僕はiPhoneアプリの開発してるんだけど、Taxnoteという、確定申告の帳簿入力アプリに自動同期機能を付けて欲しいという要望が前から多かったんです。

なので、去年の9月ぐらいにParseという、自分みたいなサーバサイドできない人のためのサービスを作ってペチペチ3ヶ月ぐらい作っていたのだが、残念ながら、ザッカーバーグが育休から戻って来たと同時にサービス停止を決めてしまった。

ザッカーバーグは育児にちょっと疲れて、その勢いで僕の三ヶ月の努力を潰そうと決断したに違いない。

とまあ、そういうわけで、今年に入ってからRuby on Railsでバックエンドを作ろうと、久々に新しい言語というか、フレームワークを勉強してました。僕はあんまり勉強とかするのが好きではないので、どうやったら少ない時間で目的が達成できるか考えて、試したところ、すごく自分には効果があった方法が見つかったので、それについて書きたい。

厳密にはペアプロではないけど、ペアプロ風味な勉強方法でした。

突然、大海原に放り出される瞬間

前々から思ってたんだが、プログラミング学習というのは、最初の最初の教材やらチュートリアルやらは揃っているが、その後に、さあ、こういうサービス作りたいぞと思った瞬間に、突然難易度が跳ね上がってみんな途方にくれると思う。

僕の場合、まずドットインストールという素晴らしいサイトのRailsチュートリアルを最初にやった。Ruby言語の勉強はすっ飛ばした。Rubyの文法は必要に応じてググればよいので。

iPhoneアプリもそうだけど、言語の文法なんて検索したらすぐわかるけど、一番時間かかるのはCocoaとかRailsとかフレームワークの使い方の部分だからです。

そして、田口さんが作った素晴らしいサイトのおかげでRailsって、こんなんか、なるほど、CakePHPを5年前ぐらいにやったけど、それと似ているな、ちょっと懐かしいわと思って、なんかできそうな気配がしてきた。

しかし、さて、iPhoneのCoreDataの同期のためのAPIを作ろうとなった時、いきなりわからなくなる。Rails + iOSとかいう本とか、RailsでAPI作成動画みたいなのをtreehouseとかいう学習サイトで見てみたけど、どうもよくわからない。

よくわからないというのは、自分がなにをわかってないかがまずわからないという状況だ。未知の未知というやつです。ユーザ認証するにはどれがベストプラクティスなのか、この本にはこう書いてるけど、これは古いやり方なのか。

そもそも、俺が今進んでいる方向は合ってるのか、誰か助けてください、お願いしますといった具合です。

というわけで、お友達のKさんに教えてもらったCodeMentorというサービスでまず聞こうということにした。その話はこちら。

プログラミングでハマったら有料相談できるCodementorを使ってみた

しかし、上のリンク読めばわかるけど、このサービスは高い。高すぎる。スポットで使うにはいいんだけど、今自分に必要なのは、2時間ぐらいマンツーで方向性を示してくれる家庭教師である。CodeMentorとか使ってたら、2時間で３万ぐらい飛ぶ。

というわけで、Upworkというサービスで募集することにした。ちなみにUpworkというサービスは合体を繰り返しているので、ほんと名前がころころ変わる。

Upworkで先生を募集したら候補者がいっぱい

さて、Upworkで先生を募集するわけなんだけど、募集する時は出来る限りこちらの状況、やって欲しいことを詳しく書いたほうが応募もしやすいだろうと思い、徹底的に詳しく書いた。

これは、ITの求人とかを読んだ時、本当に知りたい事が全然書かれてない場合ばっかりで、こんなんじゃ効率悪いだろと常々思ってたので、その思いをぶつけたのもある。

まず、Taxnoteのリンク貼って、このアプリのデータ同期のAPIを作りたいから、その勉強してる旨、今の自分はチュートリアルを２つぐらいやって、本1冊読んだ程度。でも、iPhoneアプリでプログラミングは４年ほどやってるなどなど。

なおかつ、今途中までやったRailsのプロジェクトをアップして、今の疑問はこのデータベース設計が正しいかとか悩んでるとか、認証はどのGem使えばいいかわからんとか、

やって欲しいのは、スカイプで動画共有して、自分がやりたい事や質問をこっちで見ながら話すから、それを実際にコード書きながら説明して欲しい、ようはペアプロの相手になって欲しいということを書いた。

Upworkの時給のレンジを書く欄があったので、中ぐらいの、20ドル~40ドルのレンジで選んだ。時間帯は、日本時間の朝9時から夕方5時ぐらいまでの間ならいつでもできまっせと書いておいたけど、できれば頭の冴えてる午前中で、夕方とかにやりたくないなとは思っていました。

すると、インドとか、北欧とか、ロシアの方面からの応募者がいっぱいきました。全部で12人ぐらい。テンプレメッセージで応募してる人もいれば、僕の要項を読んだ上でメッセージしてくれる人もいた。

そして、自分のスキルを書く欄には、各々の経験が書かれていて、時給15ドルで応募してきてるインドの人から、時給45ドルで応募してきてるクロアチアの人まで様々である。

ペアプロで教えてもらってみた

まあ、最初は安い時給の人にやってもらおうかなと思い、時給20ドルぐらいだったインドの人と時間を決めてスカイプでやってみた。時間は昼の12時ぐらい。

この方はすごく丁寧でよかったんだけど、いかんせん、英語が聞き取り難く、なおかつネット回線もそこまでよくないので、それだけでレッスンの進み具合が遅くなってしまった。

後から気づいたんだけど、UpworkというグローバルなITフリーランス業界では、英語がちゃんと喋れるというのもレジュメに結構強調してる人が多かった。綺麗な英語でコミュニケーションが取れる人はそれだけ時給も高くなるようだ。

肝心のプログラミングの知識に関しては、CodeMentorでRails先生のトップランクの人とのペアプロを経験してるだけに、これは明らかに見劣りしてしまうなというのがあった。

何が一番違うかというと、よい先生は、「ああ、こういうことしたいなら、このgemがいいよ。ああ、これは綺麗なやり方じゃないから、こうしたほうがいいよ。」という具合に、どんどんベストプラクティスを提案してくれて、それこそ自分が求めているものだった。

でも、こうやりたいと言った事は、あまり綺麗ではなさそうなやり方でとりあえず動くように書くといった感じだったので、「うーむ、他の人より安いけど、他を当たろう。」となりました。

次にお願いしたのは、時給45ドルのクロアチアの人だった。この人は、レジュメもメッセージでも、「俺は経験もあるし、ちゃんとできるぜ！」風で自信ありげである。それでも、CodeMentorより安くなるなと考えてしまうあたり、アンカリング効果とは恐ろしい。

名前はMさんとする。このMさんとは、日本時間15時に約束して、あっちは朝8時の時間にスカイプすることになった。

するとMさんはめちゃくちゃ知識豊富で、CodeMentorでRails先生のトップ評価の人に勝るとも劣らない印象を受けた。つまり、「ああ、これはこうするんだよ。これはこっちのほうが綺麗なやり方だ。」といった感じで、いろいろ綺麗なRailsの書き方を教えてくれて、ものすごく効率よく勉強できてる気がして興奮した。

しかし、それだけに、毎回のセッションの2時間はものすごい脳みそが疲れて、終わる頃にはへとへとでした。ちなみに、Railsはバリデーションとか含めて、コードをあまり書かなくても簡潔にやりたいことが出来上がっていくのにびびった。

というわけで、Mさんに教えてもらうことにし、今まで一回のつき2時間、全部で4~5回ぐらいペアプロしたと思う。

最初の段階ほど効果が高い

具体的にどういうふうにペアプロしたのかを書いてみる。

まず、自分で勉強できるところは自分で勉強したほうが早いので、とにかく、「詳しい人に聞いたほうがはやい」という部分を教えてもらうことに集中した。

例えば、Databaseモデルの設計についてアドバイスをもらったり、自分のコードを見てもらって、もっと洗練した書き方に直してもらうとか。

あと、認証はどのgem使うべきかとか、教えてもらいながら、自分の知らないデバッグツールやサービスを教えてもらうなど、自分一人ではなかなかわからない、知らないという分野を学習することに集中した。

そして、ペアプロは動画共有して、ひたすら自分は相手のコーディングを見ることに専念した。相手に指示されながら自分が作業するより、はるかに濃密な時間になるからである。でも、最初はもうあっちの操作が早すぎて、すごい疲れた。

ついでに、説明受けている途中で、後から自分で独学したほうがよさそうな部分は、リンクだけ貼ってもらって後で復習するわとして、次に進むようにした。

レッスンの終わりにコードをBitbucketのレポジトリにあげてもらって、その次の日に、自分の環境で相手がやっていたコードを読み直して復習するといった具合。

これで、チュートリアルのあと詰まっていた部分が、一気にまったく詰まらなくなり、ガンガンと進むようになって、「おお、これは最高だ。大成功だわ。」となりました。

最初のほうはまだRailsのこと全然わからないから、レッスンの後の3日後の第二回のレッスンを受けたりしてたんだけど、わかるにつれて、自分で進められる範囲が多くなるので、第三回のレッスンの後は一週間ぐらい自分で進めて、質問を貯めておくといった具合になっていった。

今は、第４回ぐらいになると、もうだいたいやりたいことができてきて、疑問に思うこともピンポイントになってきて、ここからはStackoverflowさんに質問できるようになってきた。

Stackoverflowに質問するにはもやっとしすぎている段階でこそ、ペアプロの価値が高いなと再認識。

プログラマを探す時にもいいかも

やりながら思ったけど、この、実現したい事を説明して、コード書いていくのを画面共有で見るというのは、できるプログラマな人を探すのにもすごくいい気がする。時間がちょっとかかるけど、これはいい。

なにかに詰まった時のネットでの調べ方も参考になるし、問題解決のプロセスやら、なんでそうするかの説明を聞いてるだけでもその人の実力が結構わかったりする。

なおかつ、自分も新しいやり方を覚えられるし、自分がやって欲しいことをやるわけだから、そのプロセスもそこまで無駄にはならないし。Taxnoteのアンドロイド版を作るとしたら、このやり方でまずプログラマを探して、途中からは任せるといったやり方にしようかなとか思った。

なんにせよ、Railsは前々からやりたかったけど、新しい事を覚えるのは面倒だし、億劫だし、ああ嫌だと思ってただけに、ザッカーバーグがParseをシャットダウンしたのは、結果的にRails覚えられてよかったかもしれない。結果オーライと考えようと思う。

Tweet