第一个函数改成

def get_attr_by(path,name)
    `/usr/libexec/PlistBuddy -c  'print #{name}' #{path}`
end

Ruby 语法中 双引号是标记字符串的 而当使用了反引号之后 已经默认里面就是字符串了 不需要再额外加上双引号

性能以及安全上的考虑

#48 楼 @gene_wu 哦 好吧。。

#45 楼 @gene_wu 礼拜一要上班的 看球就算了。。再说不是我感兴趣的。。

#37 楼 @gene_wu 有吃晚饭的话太好了

楼主有无彻查过 ice 的源码 究竟是什么造成了不兼容。一般来说 语言造成不兼容的问题都是易修复的 因为涉及不到组织架构的高层次问题。

果然没赶上 呵呵

楼主做医生明明蛮好的嘛～我爹也想让我做医生。。

#19 楼 @xmonkeycn 那还是再开一场吧

#16 楼 @lgn21st #14 楼 @gene_wu #5 楼 @zgm 考虑延后或者再开一场？

#31 楼 @billy 嗯 通常 A 作为初创项目也通常是核心项目 二的发生概率会较高 让 B C 调用 A 的 API 这种事我们也做过 后来发现的问题 一是 A 性能撑不住了，这个可以当然通过横向扩展来解决 二是 A 作为核心项目开发力度通常比较大 还要满足 B 和 C 的需求 最后成了瓶颈 这个问题我们至今都没有解决。。 还有一种场景是 B 和 C 是从 A 项目分裂出来的 在这种情况下 如果是共享数据库的话开发速度就快了很多。

#26 楼 @billy 我不反对 API 是个比共享数据库更好的办法 如果性能允许，并且 API 也恰好设计得满足所有人的要求，并且 API 开发的速度从来不会成为其他项目的瓶颈，那当然更好。共享数据库是一种妥协式的设计，只是比共享 Model 相对更好些，相对于设计一套完整的 API 系统更节约时间，也更简单易用，适合项目早期快速开发，没有太多技术负债的时候，一般由 DBA 负责 Schema 的修改，如果要修改或者删除 Column，当然要那些依赖这个 Column 的项目做好准备，只是一般不会影响太多。当然，毫无疑问的，API 总是架构演变的最终结果。

#24 楼 @billy 我不认为数据库完整性由应用来保证是什么好的 Practice AR 只是提供人性化的反馈 数据完整性由数据库自己保证，无论是架构还是性能都是最好的。

#22 楼 @billy 问题一的解决方案是数据库 constraints 问题二的解决方案是数据库 trigger 既然是数据库共享 很多逻辑就尽可能放在数据库层面了。

#7 楼 @billy 结论就是不要共用 model 的代码 一开始挺高兴，后来全成了负担 你可以把复杂的数据库逻辑包装在 Procedure 里，然后每个项目各自维护自己所需要的 model 代码，各个项目分工好的话 不会有太多冗余的，但是负担大大降低了呢。

我能说我们公司几十个项目共用数据库嘛

@lgn21st

看看实现不就得了 为何要看书。。

看上去不错的样子 马克

玩了两年多了。。

#44 楼 @ane 是的 所以弄成常量感觉很怪 还不如叫const呢

之前买书的人不哭死。。

#2 楼 @Tony612 我也觉得 RubyMotion 不行了。。

现代编程语言一般都这么几招 不过 let 表示常量从哪里学来的？我记得 Lisp 里 let 是表示临时变量的 新版 JS 也是呢

很早以前就觉得应该弄成这样了。。

#61 楼 @kgen 是啊 但是我老有一种没有完成的书没有看的必要的想法。。大概是小时候中华小当家看多了。。

#52 楼 @kgen 我觉得不靠谱。。每次从 Leanpub 上买的书总给我一种还没有完成的感觉。。结果都没怎么读。。

一年读 100 多本书的同事 超过犹太人了。。。

#6 楼 @lgn21st 你可以在 VMware 里使用 Docker 嘛～～

10 块能买咖啡？