@clowwindy echo... XCode4 每天不 crash 三次以上，就说明我这一天没怎么玩代码

还想起windows下一个很牛的工具，作为VisualStudio的插件安装的，review代码的窗口上可以直接在代码旁边加comments，就像word文档中加comments一样。
因为连接服务器太慢，我个人基本上不太用，以至于现在都想不起名字了。不过确实很不错的工具。
不知这个有Mac版么？

哦对了，tfsodd还有很强的一个，是可以比较两个shelveset之间的差异。
因此第一次review提意见，改了，再做一个shelveset，然后reviewer可以光看新的改动。

这个不知道什么Mac下什么工具能做到
或者，能用若干命令拼接起来达到这个效果么？（当然我并不希望reviewer机器上得要多份workspace）

@adow 我的意思是让可以安全忽略的警告不要在左边窗口中显示出来。
在C＃中是这样的：对于可以忽略的警告，可以在方法／属性／类／全局的范围添加一句
[SuppressMessage rule="[the rule ID e.g. CA001]" justification="[the reason why choose to ignore the error here]"]
这样在编译的时候我就不会再看到这条错误。
这么做有两个好处：
1,我可以强制 treat warning as error，从而从流程提升整个团队代码的质量
2,对于那些可以安全忽视的警告，我只需要思考一次就够。不至于在今后每次编译的时候我都要检查一下是不是多了几个警告，还得仔细找出多了哪几个

@adow iOS 代码里如何忽略某一具体警告？我是指忽略某一特定规则针对某一行／段特定代码的警告。同样这条规则在其它代码中的不要 suppress，同一段代码中其它规则检查的警告也不要 suppress。

@Livid 那对于 Analyze 报告的问题呢？
目测，大量 warning 还是无关紧要的，Analyze 上的可能有些确实是 crash 的元凶。
另：有没有 suppress 某一特定 warning 的方法？这样就可以把那些安全的确实有理的 warning 给压制了让它们别在警告栏中出现。

@Elix 三天才用喂一次？那看来我能养。

最近正打算弄个大鱼缸放家里，弄个小小鱼缸放办公桌上。@Elix 问你哦，养这种小鱼的话，如果周末两天没人打理要紧么？最长可以坚持几天没人管呢？

啊，生日快乐，明天儿童节快乐:D
你现在在哪个国家哪个城市呢？

更好的解决方法如这里所说 http://stackoverflow.com/questions/1620375/cross-compile-libgcrypt-for-the-iphone-linker-error-cant-seem-to-find-fwri
对模拟器版本的，编译时加上 -mmacosx-version-min=10.3
花了点时间读http://developer.apple.com/library/mac/#releasenotes/Darwin/SymbolVariantsRelNotes/_index.html 总算明白了

好吧搞定了。那个sleep$UNIX2003 需要加在.c 文件中，其它的如.cpp,.m,.mm,.h啥的都无效

哇，想起了好几年前的一大包牛肝菌。真美味啊。
上海今天下雨了，去草地走走，应该能看到不少蘑菇。

新鲜茶树菇很脆很能，我超喜欢啊

找到一本书 iPhone SDK Application Development (《AppStore 掘金》)，代码全都是手工写的。看了眼它的例子，还真是所有界面相关的内容都在 loadView 中，根本就没有写 View 的子类
那看来，ViewController 虽然名字中带个“controller”，其实是更应该是 MVC 中的 V，包含 View 中的那些 code behind （不知道这个词在 iOS 开发中应该怎么说，在 WPF／Silverlight的世界，就是指对应于 .xaml 文件的 .cs 文件中的内容）。

这样看待 ViewController，那对于简单的不值得单独写一个 View 子类的V （并且也没有 .nib 来画界面），让 loadView 包含各种位置、大小之类的代码也可以接受。我刚又去看了眼我接手的项目，发现：
对简单的要重用的小控键，只有 View 子类；
对复杂的但不重用的大界面，只有 ViewController 子类；
项目中暂时没有找到同时存在对应的 View 和 ViewController。
我想如果有复杂的但是又需要重用的控键，比如 @wtl 举的 slider 的例子，就应该同时有 View 和 ViewController 吧，当然对于外界调用来说只需知道一个 View。

好了，不纠缠在这些概念上了。虽然还是觉得在一个名为Controller的类中看到大量位置数值的代码，很不符合我的审美，可至少知道了它的原委，换个角度来看也可以理解了。Coding 去啦⋯⋯

恩，@Smartype 和我的理解是一致的。我上面说的这个例子，在我看来，要么建一个 AView 把 label, button 和 BSubView 都放进去，要么，干脆让 BSubView 本身就包含 label 和 button, 并且有设置是否显示 label/button 的属性，ViewController 只需要设两个布尔值即可。

像 @wtl 举的关于 slider 的例子也一样，对于外边的创建、调用来说，只需要管一个 View。不过，在 slider 的内部实现，它的 viewController 到底该不该包含计算数值、位置的代码，还真是不太好说。感觉 slider 有那么一点点特殊，因为它的一大部分逻辑就是和位置相关的。

粗粗看了眼 @lldong 提到的 nib2objc，忽然想到，是不是对用这类工具转化得到的代码，最方便的处理方式就是一古脑儿塞到 viewController 的 loadView 函数中呢？

谢谢 @Yonsm 让我知道为啥 IB 很好用可还是有不少人会选择手写。

@adow 握个手！xaml 真是很强大。你也是先前做 WPF／Silverlight 的呀，看来我以后有问题可以盯着你问。我从 VS 转到 XCode，还很不适应呢。

@iEggache 看了下，如果是 .nib 的话手工敲出来还真不太可能。

对比 iOS 和 微软的 WPF，我感觉：
一方面，XCode 的IB做得真好（我用的是最新版的写 storyboard 的），拖拽很方便。相比之下，VisualStudio 内的 Xaml Designer 真是悲剧，以至于要么是做界面设计的人用 Expression Blend 画，要么是作开发的直接敲 xml 文件画。
另一方面，WPF 中定义界面的 .xaml 文件真是强大，我光敲xml文件就能很迅速的作出好看灵活功能强大的界面，比用 .cs 代码方便很多。相比之下，.nib 真是弱爆了，完全不是给人读／写的嘛。粗粗一看觉得 .storyboard 可读性提高不少，不过看来还是没到可以手工写的地步。

看来还是喜欢 IB 的多一些啊。

@Livid 关于viewController 的 LoadView 方法的运用，我还是有不同理解。
我觉得若我有一个AView，它可以纵向也可以横向，它可以允许外层有导航栏也可以没有，那在相应的 ViewController loadView 函数中，就需要设置它的纵横属性，设置它的最外围的 Rect。
但是，这个 view 中有一个 label，有一个 button，有一个 BSubView，这些东西原本是该在 .nib 中的，去掉了 .nib, 也还是应该单独写个 AView 类来画出来吧，怎么可以全部放到 iewController 里呢？
现在我看到的代码，就是有 BSubView.h/.m, 可是没有 AView.h/.m，所有关于 AView 的实现全部都在 AViewController 中。

View 和 ViewController 的职责界限到底在哪里呢？我觉得 ViewController 中除了告诉对应的 view 一个最外围坐标（也就是，把这个 view 恰当的 load 起来），就不该出现任何和坐标相关的代码了。

老家在苏州下面的小城吴江，从我家出发，无论是去我外婆家、我舅家、我哥家，还是在城里到处闲逛散步个30分钟或3小时，，都能做到70％以上路程是在公园或街边大片绿地经过。虽然没有特别出彩的风景，可环境确实是很棒。

物价取决于生活方式。我妈在上海、一日三餐自己做、娱乐活动就是在家带孩子的这些日子，我真心觉得上海物价也挺便宜的。所谓小城物价低，更多的，是因为小城的生活节奏让你容易选择低消费的生活方式。

只可惜，小地方，适合生活，不适合工作。

我的感受是：你需要一套行之有效的知识管理、时间管理的方法，最好能上升到理论高度，能适用于大量群体的（否则软件太小众只有你自己用）。然后，再跟据你的方法，来开发出相应软件。
首先是方法，然后才有工具。
就像我前几天一个回帖说的，用过很多效率类、记事类的软件，到最后却发现最简单有效的，就是将邮箱充分利用起来。