• 和测试有关的书 at 2014年05月02日

    #1 楼 @chenge :thumbsup:

    #2 楼 @lihuazhang 觉得有些基本的东西需要了解,比如 stub,mock,比如单元测试的原则什么的。

    #3 楼 @chankaward 又换头像了。。。

  • #12 楼 @sufish https://github.com/cloudwu/ejoy2d 这个似乎没有测试。。。

  • #9 楼 @ruby_sky 重点是大神好吗!!!sorry... 误会了 :)

  • 我其实,就是找个机会,说下自己对测试的看法。。。楼主忽略我吧!

    如果你写一段代码,会想着试一试你的代码(应该每个人都这么写代码吧?)。把这个代码写下来,觉得就是最简单的测试。好处显而易见,DRY。

    有些没必要写,有的用不好 stub。这些情况,都会拖慢开发。但,代码个人觉得,代码质量的问题,才是最大的问题。

    个人而言,半年来,写测试的时候,比我不写测试的时候要快,当然这也有可能是因为项目的特性以及记忆的不准确产生的偏差。但,我测试其实是覆盖不足那种。。。

    TDD 其实前面还有 BDD,没 BDD 确定你做的是正确的事,既,你没有用葫萝卜钓鱼。那么有些代码会被直接丢掉。。。你写不写代码,都意义不大。

    再者 TDD 不是说你写了测试,你就是 TDD,TDD 的流程,是 Red,Green,Refactor。你不重构,tdd 也没什么意思。

    TDD,1 是分析问题的方法,明确目的,具体化问题。就好比接数学题的时候,如果你能问自己问题是什么,和举一些具体的例子,有助于你解题,见《怎样解题》。 2,分解问题。问题被分解为,有什么样的结果,和怎样去实现,是比较合理的。但同时也增加了相当大的复杂度。和学习成本,看如何取舍了。 3,代码的正确性,由代码自身保证。人脑不喜欢做重复的事情,所以,将重复的事情,交给电脑,也应该是合理的。大脑也不擅长逻辑思维,和抽象的事物(见《Your Brain At Work》),而测试刚好代替了大脑的这部分工作。 4, debug 时间和写测试时间,哪个多哪个少,也是看个人了。我 debug 能力跟屎一样,我也懒得学,所以用测试弥补。

    释迦摩尼说过,不要相信任何人只凭听说的一切,当真正实践过,并且和自己的“原则”相符的时候,才去相信。

    如果真的在乎这个,去读读相关的书,《Test-Driven JavaScript Development》,比如《重构》。了解不同人的不同看法,反对的,支持的。 亲身实践。写测试也分人。写测试也需要经验积累。

    不写测试的,一样有牛人,比如云风似乎就不写,一样很牛,再比如 @ruby_sky 。写的,当然也有很烂的。

    测试是手段,不是目的。

    one more 如果,你写测试,不开心,不写测试,可能会更好。如果你 debug 不开心,不妨试试写测试。

  • Emacs 与 Ruby 之 :测试 at 2014年04月28日

    见过 python 的 doctest,感觉不算是单元测试,没 stub 什么的。但又是测试一个 function 的。。。也可能是写测试的人出于某种考虑,没有用到 stub 什么的吧? 没研究过 python 的 doctest,不知道第三方依赖是否是个问题?比如 respec 是不是每个文件都要引入?再比如 factory,觉得需要有单独的文件。

  • Emacs 与 Ruby at 2014年04月27日

    从 emacs 换成 sublime 又换回了 emacs。。。

  • #1 楼 @karmue 觉得覆盖要分哪种覆盖。如果是语句覆盖,90 是应该还是合理的。边界之类的,不在语句覆盖之内的,过早的考虑就是累赘。而且感觉这也不在 TDD 考虑范围内,TDD 有的观点只有,就是问题没有出现的时候,就不去考虑。

  • #4 楼 @chairy11 Master Boot Record 如果我记得没错的话(很可能是有错的。。但这个不是重点,真不是重点),想要加载系统先要“找到”系统所在的地方,所谓找,其实就是按照“门牌”找,而所有的门牌号都存在了 MBR 里,而 bios 启动的时候,会先找这个 MBR,然后通过 MBR 找到别的。。。

    而 bios 是,在此省略若干字。。。

    其实,我想说,我不知道如何解决你的问题。。。要是我的话就去找装电脑的了(羞。。。)。。。

  • 好像 fitter 和 goto 有点关系。。。

  • 推荐Engineering Long-Lasting Software 的第八章。 简单来说,就是先把项目跑起来,使用一下,有 user stroy 的看下 user story,没有的话看看 git commit 什么的也不错,最好能使用者交流下什么的,问问开发者什么的。之后注意下 models 的结构,有个 railroady 可以生成 ulm 图片。然后分离出具体问题,既你想要改或者要理解的部分。

    当然这个过程比较复杂繁琐,楼主不喜欢,就可以无视他。多试试,找到自己方法。

    先熟悉项目,了解需求,了解框架,找到相关部分,然后就是尝试着更改了。

    个人经验是,不其实我没啥经验(我看的源码少的可怜,不是必须的就不看。。。) 1,带着问题看,或者有很明确的目的。 2,越晚接触细节越好。 3,分解问题,解决问题。

    觉得我看代码的时候,一般都会看不懂。。。被逼着一定要看(一般是项目需要),才有可能看懂。。。

  • #10 楼 @ruby_sky #11 楼 @allenfantasy 我觉得叫涛哥也不错!霸气!

  • 我觉得我很大程度上是在远程。因为和我做东西有关的,就一个人,在美国,但我我的工作地点是在公司。 个人感觉。 交流 交流是最大问题。 你做的事情可能是没必要的。。。或者一些细节搞错。 1,是多问问题吧?有的时候把对方的话重新组织下,问问对不对(本人英文比较渣)。 2,大局优先,先画大框,而且怎么 simple 怎么来(有出现过,把问题搞复杂的情况,比如我昨天还做了一小部分不必要的事情。。。)。 3,如果必要资源没给出或者事情没确定,建议先协商好,可以直接 pending 住。我始终相信,在任何软件开中,时间最大的浪费是在做的不是别人想要的这块。而且,真心觉得做不需要的事情是浪费时间,浪费生命。 4,测试可以非常好的降低交流成本! 1),明确目的或者需求。 说的话不明确,语言比来就比较模糊。写成测试,就具体化了。觉得具体的东西都是好东西,哈哈。 大家应该都有感觉,写东西比说话难多了。书写,可以很好的帮助人思考。 2),动态文档(文档往往没办法跟着代码走)。 测试写的 ok 的话,大家也习惯测试的话,直接看测试,可以不需要跟你交流(当然这是理想的情况)。 3),代码最少化。 5,团队 DRY 如果有些坑,你踩过了,别人就没必要再踩一遍了。比如某个插件,我用的时候比较二逼,直接掉坑里了,如果别人也用这个插件,几句话就可以避免再踩这个坑。这个在远程比较不好搞。。。 如果遇到坑,第一时间在群里吼一声,没准就有人遇到过。如果团队有时差。。。自己解决吧。。。 一些配置。比如 emacs。。。如果公司别人也有用的,你配置起来会舒服很多。

    (未完)

  • 天亮了 at 2014年04月14日

    #12 楼 @chairy11 如果达成预期的话,人脑会释放多巴胺,而多巴胺促进大脑细胞之间每秒链接的数量,会看要到更多的可能性。 而没有达到预期的话,多巴胺会下降,而这会产生和疼痛很像的感觉,并且想要以逃跑来回应这种感觉(不想做了),影响你的逻辑思维和创造性思维。

  • 帮你顶下吧。

  • 话说至少半年前就看到楼主招在人了。。。

  • 觉得后半部分似乎可以这么写 post && post.title

  • 没法直接回答,但是我记得在 卡斯帕罗夫(陪深蓝玩那位)的 棋与人生 说有举行过人 + 电脑(深蓝有的时候也需要人来调整策略)辅助的国际象棋比赛,比较牛的,不是国际象棋大师,也不是很懂计算机的,而是两者都懂的人。但我记不清具体的规则是什么了。。。

    只知道最简单的方法是对所有可能尽可能的穷举,然后给每一种可能的情况一个评分(是否更有利),下一步是分数最多的那个。

    跑下题,卡斯帕罗夫有一次推算了 20 步 +(可能是 36 步吧。。。),但他自己也说忽略了大量的可能情况。

    再跑一下 还有某个大师,下着棋,大脑中有歌谣想起,于是收到了启发。。。于是赢了。。。人在想出很难的问题的答案的前一刻的大脑是非常平静,然后突然爆发。good idea 也许不是“想”出来的,而是“不想“出来的。

    随便一提,现在国际象棋方面,难点不是如何让计算机更厉害(据说的推算能力是 200 步),而是如何让计算机笨成不同等级。

  • #13 楼 @Rei #15 楼 @lidashuang 非常赞同!rails 提供了非常多的便利!觉得写 sinatra 是上手容易,但真正写好了,很困难,对程序员的要求很高!

    但如果只从学的角度考虑呢?觉得 web 开发,还要学习 html,css。这些相对简单,也容易上手,入门什么的应该也说的过去。php 的好处是直观(不框架什么的),php 直接嵌在 html 内,比较容易理解,再比如 url 也和文件有个简单的对应关系。而 rails 有很的封装和约定的东西,觉得对于新人理解起来并不容易。

    觉得学习来讲,循序渐进比较重要,当然这个也和人有关。当然,如果考虑到楼主需求的特殊性,学习 rails 也是不错的选择!

  • #2 楼 @Rei 我只知道 Sinatra 比 rails 简单。。。你的意思是说,资料什么的不全吗?我想我对 Sinatra 的看法是错误的。。。

    #6 楼 @lidashuang 能具体说明吗?

  • 为啥非要学 rails 啊? 如果楼主认准 rails 了,就忽略我下面的话吧 可以简单了解下比较小的框架,比如 Sinatra,比如 web.py。python 本来就比 ruby 精简很多。rails 又具大无比。 觉得还可以考虑下 head first 的 html 和 php。也是不错的选择。 觉得学习这东西始终挑最容易的学比较好。。。

  • 如果 Web 项目==音乐 at 2014年04月06日

    觉得数据库是 base

  • #1 楼 @tumayun :thumbsup: SOA

    #3 楼 @xiaoronglv 应该是好多年了,不好意思,没给出时间。。。那个网址里面应该有时间,我翻了,竟然还打不开,悲剧。。。

    #2 楼 @bhuztez 觉得也很有魄力(第 6 条)!

  • 多尝试,别犹豫。

  • #20 楼 @chairy11 伯克利的 cs169 改了。edx 的应该还是原来的。

    #21 楼 @oth 觉得作者理解问题很深,就是抓住最重要的东西,当然也确实不太容易理解。。。