把里面 folder 里所有的东西 mv 出来，然后把它删了不就好了？用上连接符，一行就搞定了。

把里面 folder 里所有的东西 mv 出来，然后把它删了不就好了？用上连接符，一行就搞定了。

把里面 folder 里所有的东西 mv 出来，然后把它删了不就好了？用上连接符，一行就搞定了。

把里面 folder 里所有的东西 mv 出来，然后把它删了不就好了？用上连接符，一行就搞定了。

@nash_su 第一课 Linux 基础操作开始有提到：上一讲是安装，但是好像没有相关的视频哦，是不是忘了放上去？

#6 楼 @346617552 你需要的是耐心，如果这一节让你头昏，那就站起来远眺，然后深呼吸，接着坐下来一句一句读懂他。

Edited

@JeskTop 你也觉得应该按需加载，那么你为什么要相信别人说这样就失去了 assets pipeline 的意义？如果使用 assets pipeline 的意义只在于把所有的代码压缩到一个文件里去，那我倒真要鄙视 Rails 了。然而，事实是我看了很多的视频，演讲，国外的大牛们并不是这样看待 assets pipeline 的，在 Rails 里写 javascript，一样可以很好的实现模块化按需加载，否则像 backbone 和 require.js 这样的东东就不能在 Rails 里用了？

我觉得还是不要人云亦云的好。回到 LZ 的这个例子，即使只有一行的 jQuery 调用，也应该独立出去，而不是生生嵌套进页面模板。事实上，如果你对应用的设计规划做得好的话，任何一句 js 都应该或者都完全可以从属或响应某个模块，于是就没有理由让它们像野草一样东一句西一句的到处塞。

#6 楼 @JeskTop 并非如此，如果依赖于 assets pipeline 全部 build 到一个文件里去，当然会如你所说。但是，Javascript 不是这么玩的，特别是大一点的项目，模块化的按需加载是一定要做的。比如说可以用 require.js……关键看你怎么写。

#6 楼 @wity_lv 那本书的目的不是让读者 7 周“完全”学会 7 种语言，我记得书的副标题好像是：理解多语言编程范式。能领悟多少，那还是看个人，仅从读书角度来看，7 周都算长的。

#4 楼 @Rei yes，问题当然没有，只是 best practise 习惯而已，看不惯。:)

我勒个去，为啥要把 JS 嵌套进页面？本来就不应该这么写。

@lgn21st 一直关注 RubyConfChina 下来，慢慢了解了组织类似活动的艰辛……只想说声：谢谢你，以及所有幕后推动 Ruby 在中国的推广的朋友。也真心希望自己能尽一份力量，有需要之处请算我一份。

#38 楼 @reducm 我也和你一样做了很多笔记放在 github 上，不过你为什么不用 markdown 呢？

楼主的文章写得很棒，可以作为初学者的一个测试引导了，我推荐。

还有一种方案可以启用 CLI 的 vim 模式，如果熟 vim 的话会很爽。

它页面中间好像有个地方要读 T 和 F 的计数吧，如果不翻墙会卡很久甚至超时，翻墙的话木有任何问题。

#10 楼 @cqcn1991 我觉得你的问题是没有理解 RESTful，建议读一下相关资料。

#32 楼 @yedingding 我 24 小时不停开，开机启动的 #33 楼 @zhex 是我打错字了，从来也没有出现在左上角过，是右上角，从没有等待 10 秒的状况

#30 楼 @nouh 是啊，我回帖之后还担心是不是我没有更新，但事实上我之后特意更新过，结果也是一样的，没有那些所谓恶心的提示。莫非你们不是从 App Store 购买的？（虽说是“购买”，但也是免费版）

奇怪……我一直用着 Dash 的免费版本，从它的第一个 Beta 测试开始到现在，从来没有开到全部文字变红？点导航强制等待 10 秒？ 仅仅就是左上角有一小行红字：Purchase Dash，还有最下面偶尔会有一行红字闪过而已（而且内容还挺有趣的） 有没有你们说的那么夸张啊？难道我们用的不是同一款？ #26 楼 @yedingding

#25 楼 @346617552 呃，拜托～不要叫大师，我差几万条街去了……关于测试，其实我最近也才开始系统的学习，主要是看 The RSpec Book 这本书。所以说我还达不到讲解的水平，因为我自己还没完全理顺，我就讲几点目前我感受比较深的吧。

一开始我和大多数初学者一样，认为“测试”是一种质量保证工序，毕竟字面意义上来看的确是这个意思。但随着了解增多我慢慢领悟到一件事情：测试驱动开发（Test Driven Development）这个概念当中，最重要的不是“测试”，当然也不是“开发”，而是“驱动”。

这句话怎么理解呢？“开发”是目的，“测试”是手段，“驱动”则是连接二者的桥梁，我们在测试过程当中使用的每一个技巧，每一行代码都是为了达到“开发”的目的。

假设你要为自己的项目开发一个功能，我们可以将这件事情分解成三个阶段：

1. Context

   字面意义上：Context 指的是上下文或者说情景，在这里是指目前你所处的状况。通俗地讲：你要开发一个功能，是因为你遇到了某个问题或需求，你要解决或满足它，这是前置条件。你应该注意到写测试的时候总是要“描述”（describe）这些“情景”（context），对吧？

2. Procedure

   第二个阶段就是实现它的过程啦，这里我先跳过，后面反过来会讲到。

3. Result

   最后我们获得了结果，这是毋庸置疑的。

如果没有测试驱动开发，上述三个阶段会顺序走下来（1-2-3），但是阶段 3 的结果是不可控的，有可能成功，也有可能失败，还有可能表面上成功了但实际上没能满足一些极端情况（通常称作“边缘案例”，edge case），又或者隐藏了一些难以发现和排查 Bug，再或者实现不够简洁导致性能底下……等等。

简而言之，就是不但阶段 2 会走的比较辛苦（要解决的问题越困难越复杂，就越辛苦），阶段 3 的成果还未必很令人满意。

那么测试驱动开发能帮我们做了什么？

我的看法是这样的：使用“测试驱动开发”的理念和方法来进行开发，最关键的一点就是把解决问题的思路和习惯逆转过来，采用倒推法。

当你处于阶段 1 的时候，阶段 2 对你来说是未知的，你完全无法预见这个过程会经过哪些考验，你的代码会变成什么样子，但是阶段 3 却是你可以预见的。也就是说，当你面对一个陌生的问题需要去解决的时候，你无法预见你会如何去解决，但是你可以预见到一旦解决后的结果如何。

所以，你先写结果，也就是你提到的“断言”。你可以对自己说：我推断，一旦我实现了这个解决方案，那么我可以获得这样的结果。

神奇之处就在于，测试驱动开发的框架真的可以帮你验证这个结果，并且告诉你“距离你期望的这个结果还有多少路要走”。

我们来举一个非常简单的例子。假设你要做一个功能，根据给出的条件显示不一样的信息：（以下都是伪代码）：

1. 你所处的“情景”是：当我给条件 A，显示 C；给出 B，显示 D，所以：

   describe Dosomthing do
     context "given condition A" do
     end
   
     context "given condition B" do
     end
   end
   

2. 接下来，执行代码并传入不同条件（注意此时DoSomething根本就是空的，什么都没做）

   describe DoSomthing do
     context "given condition A" do    // 实例化，传入条件B
       result = DoSomething.new(A)
     end
   
     context "given condition B" do    // 实例化，传入条件B
       result = DoSomething.new(B)
     end
   end
   

   此时，测试驱动框架所做的事情就是帮你执行你要的代码，然后获取执行的结果。在这里有一个问题值得初学者留心：它是去哪里执行的呢？它怎么知道这里执行的DoSomething.new就是我们想要做的的那个DoSomething？

   如果你做的是一个 Rails 程序，那么答案就在环境变量里，你还记得 Rails Tutorial 里有一个spec_helper.rb文件吗？你还记得每次写一个测试文件都要在开始处声明request 'spec_helper'吗？没错，它的作用就是帮你载入应用程序里的文件（准确说，是载入 test environment），如果测试框架能找到DoSomething，它就执行。

   如果是 Ruby 程序或者其他的什么情况，那么你可能需要手动请求你的实际代码所处的文件，就象这样：require 'lib/do_something.rb'，如果不做这件事情，那么测试框架也搞不懂你到底要测试什么的。

3. 好，现在测试框架知道你要测试的目标和执行的方法了（其实在背后，它也能够获得执行你的代码的结果了），最后一步就是告诉测试框架，你期望的结果是什么？也就是你的“断言”：

   describe DoSomthing do
     context "given condition A" do
       result = DoSomething.new(A)  
       result.should equal_to(C)    // 这个实例返回的结果应该等于C
     end
   
     context "given condition B" do
       result = DoSomething.new(B)
       result.should equal_to(D)    // 这个实例返回的结果应该等于D
     end
   end
   

当你运行测试，它可能会告诉你：找不到DoSomething（或者是result is nil？反正一个意思吧，记不清了，呵呵）

OK，我忘了定义我的类和构造器了，要么就是我们把文件加载进来；

然后它就说：“我期望看到 C，但是现在是空”之类的，那么你就要去满足它，让它看到 C！Just do whatever you can.

你当然不能指望测试框架告诉你：你应该“if A then C, elsif B then D...”——这不可能，它还没聪明到这个地步——如果真这样了还要开发者做什么？还要开发程序做什么？

不过，虽然它们没那么聪明，但至少从上面的例子里我们可以看到几个很明显的优点：

1. 测试为你指明路径，你可以清楚的知道“我现在在哪儿？”，“下一步应该去哪儿？”
2. 测试为你掌握界限，人的注意力往往只能集中在事物的一面，你或许一直在琢磨 A-C，但忽略了还有 B-D；又或者你尽力的左右兼顾，但却没想到可能还有 C-D（所以你应该尽可能为所有的 edge case 写测试用例）
3. 测试帮你放心重构，当你完成了功能之后却发现代码还可以写得更好，但是你又害怕改动代码会导致程序失效或者引入新的 Bug 怎么办？没关系了，因为测试就在那里放着，你不确定就跑一遍看看呗。

我艹……不知不觉又扯这么长，不带这样的啊，这些东西多看看书应该很容易理解的嘛……虽然测试还有很多好处和技巧，比如……我会告诉你我都知道吗？睡觉吧，哥～

very cool

#19 楼 @lgn21st 这就对了，专业的会场应该有这样的基础设施，只要能直接连电脑，那就可以直接录音，届时演讲者只需要佩戴上无线 mic，就可以随意走动也无碍了。然后 MS 的摄像头负责环境视频录制，SF 负责电脑录屏，齐活！周末去确定下吧，如果有不确定的地方，可以现场连线我，我的 Q: 909505454

Good luck～

#16 楼 @lgn21st 对的，我想视频部分这个摄像头应该不成问题，毕竟 Google 也用了的。我担心的主要是音频方面，如果细心的话都可以注意到类似 Google Dev 这样的会议，演讲嘉宾都是佩戴着领结式无线 mic 的，这说明音频部分是分开录制的，也只有这样才能良好的区分开环境噪音和演讲者的声音。

至于你说的这个变量，我需要了解以下几个细节：

1. 那根音频线的两端连接的是什么设备？我的意思是一头应该是连接着收音 mic 的，那么这个 mic 是有线的？无线的？
2. 如果是无线的，那最好。但是无线的设备也分手持式和佩戴式两种，对于演讲来说最理想的还是佩戴式，但实在没有也只能委屈演讲者一只手拿着了
3. 如果是有线的，那么 Mic 是否可以拿着到处跑？可以的话也行，还是委屈嘉宾；如果是固定的，那么就还是和微软的摄像头一个问题，也就是接收范围和指向性受限，无法保证所有的声音都良好接收——只适合演讲者固定不动的情况。
4. 音频线的另外一头是什么接口？如果是 3.5mm 接头，那么应该可以直接连入 MBP，然后随便用一个录音软件录音即可；如果是 XLR 或是大三芯，那就还需要一个外置音频接口做转接。我自己有一个 Apogee One 可以使用，但是也只有一个，无法同时满足两个会场的要求。不过我应该还可以找朋友借一个火线或者 USB 的外置音频接口

本次大会我是会去的，已经买了票了，我人在闵行区，只不过最近工作单位封闭开发不太方便随便出去，如果需要我帮忙的话，可以提前告诉我去现场的时间，我安排一下周末抽个半天一天的应该还行吧。

个人看法：我对微软的那个摄像头有点疑惑，主要是音频部分。如果是固定机位的设置，我想这东西可能是够用了，但问题是嘉宾的演讲会走来走去的，有的时候还会转身，或者去指投影上的东西。在这些情形下是否能够把语音录制下来？微软的那个摄像头对于声音录制的有效范围是多少？

音频的降噪是以切除底噪部分的信号为代价的，想要质量好，那就要保证录制的时候音源的信号电平足够好，这样降噪器才能有效的区别底噪和主信号电平。然而当主信号源处于不断移动甚至背转身去的情况下，很容易出现阈值覆盖的，后期处理的时候会无法听清这部分的声音（因为主信号的电平无限接近于底噪，所以降噪器一刀切没了……）

我觉得比较好的方案是租两台无线麦克风，演讲者佩戴在身上，无线麦克风自带有接收器，将接收器直接连 Mac 录制，这样的话无论演讲者如何行动，音源接受器都是固定的，这样可以保证最好的录音效果（当然成本也是尽可能低了）

视频就用 ScreenFlow 就足够了，保留原始的.screenflow 素材，后期还可以调整。而且用了 SF，嘉宾就是用 ppt 也无所谓啊，mac 上装个 Office2011 放就是了，统统录屏了。

至于降噪，这是小事情，如果需要的话我也可以帮忙，本人做过多年的录音师和舞台 DJ，只不过我现在受工作条件所限，不太方便跑来跑去，可以事前联系好。

#21 楼 @346617552 你谈到的这个问题在我个人看来是这样的：我从来不认为哪一个“疙瘩”是不重要的，仅仅是优先级有区别。一个“疙瘩”就是一个坑，如同我上文所说：如果你的志向就是这一行，就是要开发出卓越的产品，那么这些坑你迟早都是要填满的，因此在我看来所有的“疙瘩”都很重要。

只不过学海无涯而吾生有涯，或许我们没有那么多时间去填满所有的坑，更加明智的做法是排出个顺序来，一步一步的吃掉它们。

首先，大前提是我必须要清楚我的总体目标是什么。其次，在前进的道路上如果遇到了“疙瘩”，我会给自己一个时限去了解一下它是什么？它有多重要？它有多复杂？掌握它需要花费多少代价？通常我会给自己半小时时间去搜集这些信息。

这里我有一个个人的小技巧：我对面的墙上贴着一张大大的白纸，白纸的中心是我的目标，然后向四周延伸出去，每一条延伸线都代表了达成这个目标所必须要完成的路线，比如说：设计、前端、后端、部署、文档、商业模式……等等；之后每一条路线上都会有各种各样的分叉、再分叉、再再分叉……它们分别代表一个坑，或者说一个“疙瘩”。我花半个小时去了解一个坑，然后确定它属于哪一条分叉，并且写出它在我心中的优先级，这个优先级取决于几个因素：它对整体路线的影响力；学习它的难度和时间消耗程度；它是必须我独立掌握的，还是可以交由团队其他成员掌握即可等等。

然后，就放下它吧，继续你之前的进度，反正它已经在你的“黑名单”上了，逃不了的。更重要的是，我不能让它成为我的心结，不能老惦记着却不做任何事情。

一开始肯定会比较头大，因为“黑名单”太长了……不过请不要担心，一个人建立知识体系是漫长的过程，但是体系的节点之间总是有着千丝万缕的联系，经过一段时间有规划的学习之后，你就会发现实际花费的时间和精力总是少于你的事前估计的。

要相信自己，也要养成习惯，更重要的是：不要去想未来还有多长，专注于眼下吧，因为担心未来的功夫浪费的正是眼下的时间。