cocos2dx JavaScript Bindings の websocket

cocos2dx に xhr と websocketが実装されました。
cocos2d-x ver 2.1.4 が神アップデートすぎる件について

javascriptでopenglのパフォーマンスが得られるのは素敵なのに
通信ができないんじゃ使えないじゃん。
って思ってましたが、実装されちゃったので早速使ってみます。

twitterのstreaming api を流してみます。
こんな感じ↓

作るものの妥当性

正解ではなく妥当。
ふわっとしてていい言葉ですね。

僕らが作るもの(アプリとかwebサービス)にはだいたい二つの妥当性があります。

一つは経済のレイヤーにある妥当性。
簡単にいうと仕様通りに動くかどうか。
妥当でなければお金がもらえません。
こちらはお客さんとともに詰めていくもので、いろんなトレードオフの上に成り立ちます。
職能別の作業単位(責任)に明確に分けて考えれるものです。

もう一つは質(クオリティ?)のレイヤーにある妥当性。
これは自分らが作ったものとして世に出していいのかという判断。
経済レイヤーの妥当性とはあまり関係がありません。
自分らと作るものとの関係です。
主に全体としての納まりという所なので
コンテンツ、挙動、デザイン、コンセプト等々をまるっと考えて仕上げていく必要があります。

経済レイヤーの妥当性と関係がないとはいえ質のレイヤーにある妥当性をちゃんとしようとすると
やはり時間やお金(工数とよばれるもの)はかかります。なので僕らはここで戦いますが、
それだと食ってけない論が正論すぎて、反論できません。
そんな日々に慣れすぎると質のレイヤーの妥当性を忘れてしまいます。

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(@"リストア完了！");
 };

tail -f をブラウザで表示

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

まーよく使いますね。

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

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

データソースの抽象化

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

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

よくあるパターン

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

よくありますね。

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

目標

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

今回のサンプル

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

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に変更しましたが。）

サーバー側のプロセス的には結局アップロードが完了するまで掴みっぱなしなのであまり意味はないですが、使い方次第では簡単にユーザビリティを上げられるのでオススメです。

何よりロジックを変えなくていいのが良い！

ただしまあ問題もありまして。

エラーハンドリングが困難なのが一番の問題ですねえ (･ω･ ;)(; ･ω･)

上記のファイルアップロードなどの場合、先にレスポンスが返ってしまうので、画面上は正常にアップロードされたと表示されているにも関わらずサーバー側でコケている的なことが起こり得ます (´･ω･`)

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

ではでは。

新しい仲間が増えました

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

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

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

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