坛子里有没有仔细研究 RubyMotion 的同学？

iOS-Dev 社区很多人都有 Ruby\Rails 的经验，但 RubyMotion(包括 MacRuby) 貌似并不是很流行。我想原因可能是很多人不喜欢黑盒子，如果弄不清盒子里面是怎么工作的，用起来总是怕怕的，一旦出问题就死定了。 不知道使用 RubyMotion 有没有这种问题。

老家也有 Ruby 聚会了....

别说 xib，就是一般的 source code 文件，频繁出现两人同时修改的情况，就应该反思以下，是这个 class/文件是不是该拆分以下了，或者是不是和 partener 分工不太协调。

我们的经验是：

1. 在 UI 的动态条件不是太多的情况下，用 xib 能更加直观、更易维护，另外对 universal(iphone/ipad) 支持起来也方便。
2. 单 xib 包含的 view 复杂度，应该根据实际情况进行调整，宜小不宜大。有公用的就抽取出来。

至于冲突的情况

1. 大规模增删项目文件，应跟 partener 打好招呼，让他们先 check-in, 防止 project 文件冲突。
2. xib 文件最好自己修改自己的

一般规模的 iOS 项目，三个 coder 以上就该分角色了 (UI/交互层/动画效果), coding 时大家各忙各的。

#26 楼 @fleuria 你说的乌云那个？还是http://ww1.sinaimg.cn/large/7cc829d3gw1dxb5e12xacj.jpg 这个。乌云号称拿到漏洞但不敢下手。后者是铁道部网站货运服务的，跟订票的关系不大吧。

不过以网站的粗糙程度，不排除订票服务里也会手写 SQL。

有重度国内“中底”用户的网站是不能用 Alexa 做流量估计的。这点上 Alexa 严重不靠谱。

新浪微博上喷 12360 都不是很专业，找的一堆问题都是外围模块的，跟订票没啥关系。

这种高并发的业务，比支付宝不相上下。短短 1 天，要接受上千万的订票需求。天极在这上面没多少积累。话又说回来，国内公司有几个有这种积累的？

另外 3 亿这个数字，如果是真的话，那铁道部真是”太廉洁“了，资金利用率最起码再 80% 以上，只拿 20% 的回扣？打死我不信。

#5 楼 @linjunpop

我没有尝试将 em-apn 放到 thin/mongrel/unicorn 上。我认为这么做貌似不太合适。

我的做法是将 em-apn 做成一个独立的进程，并使用 EM.add_periodic_time 每秒从 JobQueue 中取一个 APNS 任务。

代码如下：

EM.run do
  client = EM::APN::Client.connect
  # client.deliver(EM::APN::Notification.new(token, "alert" => alert))

  client.on_error do |response|
    EM::APN.logger.info "response #{response.inspect}"
  end
  max_reconnect = MAX_RECONNECT
  client.on_close do
      if $running
        if max_reconnect>0
          EM::APN.logger.info "attempt reconnect,  reconnect avaliable: #{max_reconnect}" 
          conn = client.connection
          conn.close_connection
          client.connect
          EM::APN.logger.info "success reconnected!" 
          max_reconnect-=1
        else
          EM::APN.logger.info "max reconnect reached, exsit"
          EM.stop_event_loop
        end
      end
    end
  # Hopefully give ourselves enough time to receive a response on failure.
  # Wish there was a better way to do this. Or at least a more timely way.  
  EM.add_periodic_timer($interval) { 
    while job = $em_apns_worker.fetch_job
      client.deliver(job.to_notification)
    end
  }
end

他们的 App 也是你们做的？不错哎。

#1 楼 @bl0ckme 大量使用 block 貌似会 retain 住调用方，导致很多对象无法释放。不知道你遇到过这个问题没。

#1 楼 @allenwei apn_sender 不支持 enhence_format，属于单向的 socket 写入，没有获取 socket 上行数据的功能。

我后来在 em_apn 上做了些改造，基于 event_machine, 性能和稳定性提高了不少，很少出现 APN 无故失效的情况了。另外用 enhence_format 也可以知道消息发出去 apple 的应答，便于发现问题及时调整。

另外一个很容易出问题的地方：订阅 Feedback 删除失效 token 时，一定要判断失效日期，否则很有可能把一个正常的 token 删除掉。

#33 楼 @sunfmin @huacnlee 下次是啥时候啊。能不能提前 gtalk 通知我一下。都错过了三次了，恨啊！ 我 gtalk: come2u at gmail.com

Looks Great! 神器。

我提个不同的看法：只要是产品方向正确，每个阶段的预期目标 (用户量等) 都能达到，不愁团队难带。 否则不管你怎么忽悠，人家该走还是走，该打酱油还是打酱油。

用一些三方库是基于自己了解已有 SDK 的基础上。建议你还是多看一下 Xcode 自带的 document 和 sample.

整体上想有所了解，可以看看 stanford 的视频教程。网易和 itune-U 都有的下载。

最重要的：找一个自己感兴趣并且自己能用到的功能需求，做一个简单的 App。兴趣是最好的老师。

哈哈，貌似离我家很近。

貌似支持 client(iphone/android) 通过 submit form 的方式直接上传唉...

有这方面的成功案例么？

#22 楼 @huacnlee 实在不行就扩大 Cache 范围，尽可能的把 Render 之后的 Html Cache 起来。

另外，Rails3.1 的 memecahed Cache 貌似有性能问题，跟 memery_cache 有数量级的性能差别。不知道是不是因为我用的 dalli 的缘故。Rails3.1 类似的性能陷阱还有不少。

弄个专版呗。从 Ruby 转到 iOS 和 Android 的不在少数啊。