2013年5月31日金曜日

iphoneの課金処理を見通しよくする

objective-cには無名クラスが無い(たぶん)。
なのにだいたいインタフェースがオブザーバー。
その都度処理かえるのがめんどい。

ということでBlocksインタフェースをつけちゃいます。
今日はStoreKit。

目標

課金処理の見通しよくする

使う側をこんな感じに

課金処理で結局何がしたいかというと、
・課金をリクエストして成功したか失敗したか。
・リストアをリクエストして成功したか失敗したか

controller.m

// 購入処理
 SLSK* slsk = [SLSK getInstance];
 slsk.onFail = ^(NSError* error){
    NSLog(@"%@", error.debugDescription);
 };
 slsk.onPurchaseSuccess = ^(NSString* productIdentifier){
    NSLog(@"%@ 購入完了", productIdentifier);
 };
 [slsk puchase:@"com.subakolab.tyarintyariiiiiiin" /*productIdentifier*/];
// リストア
 SLSK* slsk = [SLSK getInstance];
 slsk.onFail = ^(NSError* error){
    NSLog(@"%@", error.debugDescription);
 };
 // リストア対象のアドオンの数だけ呼ばれる
 slsk.onRestoreSuccess = ^(NSString* productIdentifier){
    NSLog(@"リストアアドオン:%@", productIdentifier);
 };
 // リストアが全部終わったら呼ばれる
 slsk.onRestoreComplete = ^(){
    NSLog(@"リストア完了!");
 };

2013年5月29日水曜日

tail -f をブラウザで表示

tail -f /var/log/httpd/access_log 
tail -f /var/log/httpd/error_log

まーよく使いますね。

ディレクターとかお客さん(プログラムわかりませんの人)とかでもデバッグ中にログ流しながらできたら、デバッグしてますっぽい雰囲気出て楽しいんじゃないかと思ったけど、
sshつないでもらうの怖いしなー。
っていうことでブラウザにログを流してみましょう。

実際やるときはパーミッションとか認証とかちゃんとがんばってください。

データソースの抽象化

はじめまして、先週からスバコラボでお世話になっています。
好きなものはお酒、嫌いなものはプログラミングです。

手があいて暇なので
データソースの抽象化について書いてみます。

よくあるパターン

webAPIからデータを拾って表示するネイティブアプリ。
フォーマットもURLも決まってなくてモックが作れない
結合のときにやたらばたばたする。
APIがミスってるのかアプリがミスってるのか分かりにくい。
デザイン確認したいだけなのにAPIがバグっててアプリが落ちる

よくありますね。

このあたりをなんとかするために
モデルからデータソースを抽象化してみます。

目標

データソースの実装に引きずられないように

今回のサンプル

記事(Article)一覧をデータソースから読み込んで表示する

2013年5月23日木曜日

railsでの簡易遅延実行

※この記事の内容は、あくまで遅延実行を実装するための方法であり、マルチスレッドやバックグラウンドプロセスとは異なります。よって、herokuなどの30秒timeoutの壁はこの方法では破れません。諦めてdelayed_jobやcarrierwave_backgrounderを利用してください。

お久しぶりです ヾ(o・ω・)ノ

最近時間がないせいか記事がなくて寂しいので書いてみようと思います。
また、iOSネタしかなかったので、たまにはrailsネタで。

以下のソースコードで遅延実行が実装できます。

# Gemfile
gem "rack_after_reply"


# app/controllers/hogehoges_controller.rb
def hogemethod
  env["rack_after_reply.callbacks"] << lambda {
    # 時間のかかる処理
      
  }
  # 202 Accepted を返す
  format.html { render status: :accepted }
end

これだけ。

いやー、簡単ですねー。

仕組み的には代表的な Rack サーバー(Mongrel, Passenger, Thin, Unicorn, WEBrick )が各リクエストを処理するメソッドをフックして、コールバックを実行しているとのこと。

herokuはリクエストのタイムアウトが30秒に制限されているのでいくら遅延実行しても無理でしたが、AmazonEC2経由でS3に大容量ファイルをアップロードする機能はこれで実装出来ました。
(まあアップロードにcarrierwaveを使っているので最終的にcarrierwave_backgrounderに変更しましたが。)
サーバー側のプロセス的には結局アップロードが完了するまで掴みっぱなしなのであまり意味はないですが、使い方次第では簡単にユーザビリティを上げられるのでオススメです。
何よりロジックを変えなくていいのが良い!

ただしまあ問題もありまして。
エラーハンドリングが困難なのが一番の問題ですねえ (・ω・ ;)(; ・ω・)
上記のファイルアップロードなどの場合、先にレスポンスが返ってしまうので、画面上は正常にアップロードされたと表示されているにも関わらずサーバー側でコケている的なことが起こり得ます (´・ω・`)

なので、遅延実行に入る前に、可能な限りデータチェックはしておきましょう。

ではでは。

2013年5月20日月曜日

新しい仲間が増えました

お世話になっておりますスバコラボです。

スバコラボに新しい仲間が増えました。
お金大好きでプログラミング嫌いなK君。
まあ、うちの社員は一人除いて全員K君なんですけどね。

そろそろ、部屋が狭くなって来ましたがギリギリまで
このアパートで頑張りたいと思います。

それではごきげんよう。。