你用了最新版本的框架，自然就要考虑应对插件是否跟上的问题，这不仅仅是 Rails 才会有的现象啊。我 Angular 升级 1.3 -> 1.4，立马有两个插件开始抛出异常，太正常不过了。

标准说：

The type attribute gives the type of the media resource, to help the user agent determine if it can play this media resource before fetching it.

也就意味着，HTML5 的 audio 是没有对支持的格式做任何限定的，然而能不能播放并不是由 audio 决定的，而是由浏览器决定的。我记得 .spx 应该是 Ogg Vorbis compatible 的吧？那应该可以直接播放的。不过你得先搞定你的服务器，HTTP Server 应能够在客户端请求的时候返回正确的 MIME Type 供浏览器识别。你的情况我不清楚，自己去搞定 server 端的配置吧。

#15 楼 @diguage 头像是 30 岁的留念，好几年过去了。隐藏职业神马的并不是刻意为之啊，你没发现但凡讨论 Ruby 为主的我都是旁观，但是和前端有关我就冒头了么……

@darkbaby123 握爪……哎哟你竟然是后端工程师，这藏得也够深的，我一直以为你和我同行来着。

@lgn21st 多谢鼓励，最近半年懒多了，哈哈

你至少说明一下是什么类型的文件吧？常见的带有 metadata（元信息）的文件都是好改的，比如各种音频／视频／图像／Office 文档等等。可以试试这个 gem：https://github.com/kig/metadata

#11 楼 @lips 没错，之前没干过。不过我有几个优势：第一，我以前就对计算机感兴趣，虽然没有学过编程，但我喜欢玩游戏，搞过破解（用现成的工具），拆装过硬件，也就是说对计算机这个物件我不陌生；第二，早年因为学习音乐制作（包括录／混／编曲／演奏等工作）我对复杂事物的学习和领悟有自己的一套，并且借此机会将英语自学成才；第三，另外一份工作是做广告设计策划，虽然我不是设计师，但是那段经历让我恶补了许多设计相关的知识，色彩／构图／排版／印刷等等。

以上条件使得我在三十岁开始学习编程的时候有着“起步晚但起点高”的特点。你可以认定我是一个特例，不过这么大才学编程本来就不是一件寻常的事情，没点底子的话我就只能靠“天分”了（但实际上就是个普通人）。

老婆有没有意见什么的我觉得你想多了。我现在已经 34 岁了，入行编程已走入第五个年头，敢说精通的语言也不过就是 HTML／CSS／Javascript 这几个，前两个在很大程度上还算不上完备的编程语言。“短时间达到神人级别”这纯属扯淡，但日积月累从量变产生质变是的确可能的，就看你用不用心了，而且功夫用到了点儿上根本就不需要不眠不休。我平时还要花好多时间看电影美剧，弹吉他，旅游神马的，干嘛要对我有意见呢？

你回复问的两个问题就显而易见没有领会我的意思。我给你举个例子，从 Ruby 到 Javascript 算不算一门语言从头开始？但是你的工作并不是从头开始，因为你的工作不是学语言，而是做开发。现在 Ruby 和 Javascript 都是广泛运用于 web 开发，对于做 web 开发的工程师来说，语言本身只占全部工作技能的一小部分，而且是可替换且极易替换的部分。你冲着某种语言去找工作，那你的“被替换成本”相对就很低，因为找一个和你同等语言水平的人不算太难；但如果你是因为精通 web 开发而工作，想替换你就相当难，语言水平比你强的工程能力干不过你，工程能力比你强的设计水平干不过你，设计水平比你强的编程语言干不过你……几经波折之后才明白：啊，原来 web 开发是如此复杂的一门综合学问（其他类型的开发也多是如此）。

现实的说，你怎么证明你是专家？凭你有什么证书？凭你看过多少本教程？都不是！是要看你做了什么东西出来，能做什么东西出来，或者看看你能解决什么问题，花所少成本／代价来解决这些问题。语言只是工具，这句话不知被多少人重复了多少次，若是还不明白那我也没办法了。

@ilarry2015 我有一些感受想同你分享。

我想指出你的想法里有一个误区，那就是为什么一定要找一份 Ruby 的工作呢？如果你是有经验的工程师并且擅长 Ruby 的话那我觉得可以理解，然而通过你的描述知道实际情况并非如此。你只是曾经在 Ruby（更准确地说，Rails）的门口逡巡过一阵子，如果我是一个招聘者遇到你这样的应聘人员，我心里的第一个疑问就是：他到底对 Ruby 了解几分？甚至抛开特定语言不谈，他到底对编程这件事情了解几分？

所以呢，我所说的误区就是：不要因为语言／工具／平台／框架等东西去找工作，而是因为工作需要才去学习，进而精通这些东西。

对于靠谱的公司来说，我聘你固然可能因为你熟悉某种语言或框架并且我们刚好用得上，但如果你并不专长我们所使用的语言也没有关系。因为对于入行且懂行的人来说，语言都有自身的优势／劣势，然而它们只是工具，只是途径——帮助我们做出东西来的工具和途径而已，所以我更看重的是你是不是一个“手艺人”，能不能做出东西来，而不是成天跟我扯“茴”字有多少种写法。即使你来应聘的时候还不足够好，但你如果有很强的学习能力，有对自己很清醒的认知，有厚积而薄发的毅力与信心，再加上你能和未来的同事们相处良好，那就足够了。

上述的话我曾经也跟别人说过，每次得到的第一反应几乎都是：“我说我学习能力很强，很有自信等等，但你怎么知道？我怎么证明？”那我也总是回答：“给你三个月最低薪酬试用期让你证明自己，敢不敢？”实际上，回答“敢”的，我都会给最高试用期薪酬，因为这是他自己挣来的。

而我自己学习编程的时候已经 30 岁了，所以你说你“大龄青年”这在我看来完全不是问题，问题是如果有个机会让你进入一个开发团队（以小白的身份），你拿什么在最短时间里证明自己在团队里的价值？凭你学过几天 Rails？看过 Rails Tutorial？那如果人家都不用 Rails 呢？总不能怪老天不长眼没给你一个期望中的团队吧？

我现在的工作让我没有机会使用 Rails（但我自己用 Ruby 做许多事情），那是因为我们公司清一色的 Java 后台，不过没有关系。我爱 Ruby 这门语言，它给我很多乐趣和有用的工具，我也爱这个社区和这里的人，所以尽管我是一个前端工程师我还是每天来这里看看（实际上这里谈论前端的东西也很多，你可以翻我以前的一些回复）。我在公司里很受尊重（虽然我资历并不深），一是因为我年纪大，二是因为我很有用，别人搞不定的任何 HTML／CSS／Javascript 的事情我一定会搞定，我教会大家用 Git、Sass 等工具（这都是 Ruby 社区教会我的），我做应用不需要设计师（或者说美工）……然而我当初来到这家公司的时候绝非以上任何原因，我学会编程也不是因为以上任何原因，如果有什么原因可以概括的那就是一句话：我想创造有用的东西。

不知道我有没有表达清楚我的意思？再说一件事情吧，我差不多做过六七种不同的职业，然而但凡是投简历的都没有成功过（可能因为我没什么学历背景），做过的职业一般都是因缘际会和当时的在公司里的人聊聊天之后就去了。这里面有三个工作是后来发现自己不适合或者没有想要做下去的渴望然后就离开的，剩下的都是从拿钱最少的底层开始干起然后很快（不超过半年）成为顶梁柱。了解我这些经历的人都会说我很“神”，而我的心得就是一句话：

Show them what you can do, not what you want to do, and once you've done that, you can do whatever you want.

So，以下是你要做的：

1. 别说：我年龄比较大；要说：我经历和经验丰富，做事沉稳，学习能力胜于刚出道的小年轻；
2. 别说：我要找一个用 Ruby／Rails 的工作；要说：我想做（例：web）开发工作，因为……（例：我擅长创造性工作并熟悉互联网／我对 web 设计有很不错的研究和造诣／我有扎实的 HTML……等功底，期望进一步提高，等），我觉得（Ruby 是一门很好的语言／Rails 是一个非常棒的 web 框架……等等），因为它（们）的 pros……and cons……；
3. 别说：我会努力的请相信我（关键不在于相不相信你，素昧平生的信与不信重要吗？）；要说：我确信我能在（例：半年内）达到并超越你们的用人要求（前提是你提前了解了这些要求），如果可以的话我愿意接受（例：三个月最低薪酬的试用期，等条件），届时若不满意我自动走人。

我不相信这样还找不到工作，除非对面是教条主义＋视力障碍。祝你好运！

#14 楼 @kgen 哦，我说的拿不到就是提交不成功，最后超时错误了，然后我回墙内再试成功了。当时我好像用的是 sg 的服务器吧，或许那边有阻拦也说不定。

#34 楼 @lgn21st 阮一峰吧

#27 楼 @leopku 呵呵，你在偷换概念哦～我说的是不向初学者推荐 yeoman，同样的道理放在 Rails 身上也是成立的。无论国内外都有这样的观点：Rails（或者 yeoman，或者其他类似的集大成者）方便、快捷、容易上手、适合快速搭建 xxx，但是不推荐初学者直接学习

有的人连最基本的 HTTP 都没过一遍就冲着 Rails“快”一头扎进去了，结果呢？排除个别人确实能力强三观正还能逐渐走得出来，又有多少人死在一堆坑里？

初学者就是初学者，有些事情必须得一步一步来。你说培养钻研精神那是绝对正确的，不过培养的时候不能忘了给他们恰当的环境和土壤。以前我也不太在乎这些，自从开始带实习生之后感触颇深：揠苗助长、欲速则不达。的确有很多工具不是为初学者设计的，遗憾的是绝大部分初学者没有这种分辨力和自律力，很容易就走上弯路尚不自知。

#8 楼 @cqcn1991

1. 每样东西都有自己的价值
2. 别人认为有价值的东西未必适合（或许现在的）你
3. 自己试，都不要你钱了，时间还懒得花？

#18 楼 @leopku 唔，我值得并非推广的效果，而是初学者一旦依赖 yeoman，便很难再去深入学习一些东西，因为 yeoman 把它们“黑盒化”了。当然实际中还是要看个人的主观能动性的，只不过多数人不具备这种特质罢了。

前段时间招聘的时候有遇到这样的童鞋，yeoman 玩得很溜，也会写自定义的 generators，但是让他维护一下我们内部项目的一些构建流程就抓瞎了，因为我们用 gulp 的，而且用的很深，写了许多专为复杂构建场景用的 modules，他看 gulp 脚本之后的反应就是几乎看不懂在干吗……我跟他解释了几个过程，他立刻就说：哦，这不就是 yeoman 里 xxxx 嘛！我反问他：那你为何一开始看不懂呢？他说 yeoman 里不是这么写的……我又问：那你清楚 grunt 和 gulp 的差别吗？他说大致清楚，但是他从来没有这样写过 gulp，我说这有多大区别呢？gulp 本质上就是 node.js 程序，本质上还是 javascript 啊，他回答：我 node 很差……

是的，我想说的就是初学者因为 yeoman 比较容易上手，反而会忽略对于平台（node）和语言（javascript）本身的重视，一旦离开了 yeoman 这样的集成工具，就回到了什么都不会的年代。

#10 楼 @leopku 恰恰相反，我觉得越是新手越不应该推荐 yeoman，有经验的想要快速上手的才值得推荐一下 yeoman

#9 楼 @peter 其实肌肉记忆没那么可怕，我在家里 HHKB，公司就变成 Das 标准键位，偶尔还带着一个紧凑型蓝牙键盘到处跑，还真没觉得有干扰。

LZ 也蛮欢乐的，声音小竟然还会压力大……我在家里是迫不得已用低噪音的，远离我心爱的青轴啪啪啪～

startify 的页首和页脚是可以配置的，也就是你想要的牛和下面帮助乌干达的部分，看帮助文档呀～

#33 楼 @xiongmaojames 你明不明白在前端工程里为什么会出现把 JS 文件打包成一个并且压缩这种“招数”？你想明白这个问题就一切就迎刃而解了。

明确的告诉你，理想的情况下肯定是不用打包也不用压缩才是“最应该”的！只不过这个理想的情况迟迟没有到来罢了，幸运的是它越来越近了，因为许多前提条件都在逐渐达成，细节在这里就不铺开了，自行研究吧。

requirejs 不是框架，是用来让浏览器实现异步加载模块的一个工具库，你想想看为什么要“异步”加载然后再想想我前面的问题吧。

甚至 angular 都算不上框架，不过它算是可以用来造框架的工具集，它由很多模块组成，但它本身并没有按模块加载的机制。

看来对前端的误解还是挺广泛的啊。

1. require.js 领不领先和 rails 里使用 js 是什么哲学没有直接关系，它们并不是互斥的。相信楼主也不是说这两者谁比谁更“领先”的问题，而是在 rails 的情景下如何应用异步加载。那么我建议你去搜索一下 rails + require.js，在这里扯起来就有点累了。

2. 楼主你的确缺少对 rails 的理解，而且即便抛开 rails，使用 require.js 也不一定要让每个模块都依赖于 domcontentready；更何况 rails 使用了 turbolinks 有提供另一套事件机制的，我敢打赌你没有看过相关的文档，所以也不要怪别人觉得你的问题有些莫名其妙。

后面的问题，关键点就在用好事件委托，on 方法只是形式，也是 jquery 目前提供的推荐接口……我好担心你们离开了 jquery 就没法干活了。

对大家而言，我觉得最好不要用纯 rails 的视角去看到前端的生态系统，反之亦然。有可能的话，最好两边都对照着理解一下，相互印证才能通晓其然，而具体到了使用场景则应该尊重既定事实的生态圈，除非你有能力改进它，融合二者的优点或改进某种的缺陷，相信到了那一步就会少去很多在这里发生的“偏见”。

你感觉不是很好，那可以先描述一下你觉得具体哪里不是很好吧，这样大家也可以对症下药。

out-of-the-box：开箱即用，意思是只需很少量的准备工作就可以干活了，也可引申为“很好的，很适用的……”

#4 楼 @MofeLee 可能是限时免费吧，收到 email 的时候是免费看的。

说不上为什么，我就不太喜欢这种类型的插件，倒不是觉得不够快或者不够方便，就是喜欢自己快捷键呼出 Dash，然后把要查的东西再亲手打一遍。对我来说，这个过程比结果更有意义：

1. 手写一遍，印象深刻（同样的缘故，我很少使用自动补全）
2. 在键入的同时，下边列表会不断闪现名称类似，或者同属于一个模块的其他属性／方法等；虽然只是一闪而过的瞬间，但时常会提醒到我一些事情
3. 有的时候并不是看到了不认识，而是有印象却忘记了细节，手写的方式有助于自己回忆起很多东西（而且会对该文档的结构更加清楚）
4. 就当练手速了……

当然，类似的插件我用 Vim 也有装，但使用率真是低的可怜；你倒是提醒我了，我这就去删了它……

#11 楼 @billy OK，如果只谈写应用的话，这么说无妨，不过这个前提很重要。另外我不觉得像这样的 API 有多 low level，否则的话 forEach 这样的方法也不要直接调用了，因为从标准来看它们之间没有什么 level 差，顶多说对于数据的操作应尽可能封装成高阶接口，可有时候用了这些原生 API 也不能就认为“有问题”，因为有时候应用场景就是很简单，我没必要引个库进来，这很常见。

即便是在大型应用中也不见得就不会有直接调用它们的场景，比如说在一个 angular 应用里，多数时候数据操作都是高度抽象的，但难免有时候要写个拦截器之类的东西对特定 http 响应做处理，这时候你要进入到数据处理层的内部，尽管不是和业务逻辑直接关联可也是前置需求的一部分。因此我说这个前提很重要，否则对于不熟悉前端的人来说看到你说的话说不定会吓的不敢写 JSON.parse 了。

#9 楼 @billy 这话说的不妥吧，jQuery 也无非就是调用了 parse。对于 JSON 来说就是一个 parse 一个 stringify 俩方法，这可是标准的 ecmascript API，做前端不可不知啊。而且用到它们的场景很多，也不能说代码就有问题，武断了些。

关注这个话题的筒子们可以移步看看我正在写的一篇东西：http://div.io/topic/950，然后你们就大概可以了解：

为了让 Angular 1.x 的前端工程能做到像 Ember CLI 现在能做到的（还不是全部）要费多大的功夫吧……

#6 楼 @lips 弱智问题，不予回答。

#3 楼 @lips 临时大写可以用 Shift，大量的大写则用转换功能，不知道 Emacs 是什么，Vim 里可以用到 ~/gU/gu 等功能。

如果交互式 rebase 有困难的话，简单一点也更好理解：

1. 建立一个分支
2. 回到 master（我假定你原来在 master），reset --hard 到 c2
3. cherrypick c6, c7 到 master，然后 push

另外那个分支不要了可以删掉，或者留着 reset --hard 到 c5，这样随时可以 merge 或 cherrypick 到 master

#6 楼 @flowerwrong 痛点之一，JS 是难点当然也是痛点。

是，任何 HTTP 方法都可以携带 body，比如 GET 也可以。但是这和常规有悖，而且如你所说一些框架会丢弃或无视非 POST 请求中携带的 entity body，因此设计 API 时应避免。

管理菜单里有组啊，设定好组之后在项目配置的成员里把组也当作成员添加进去就可以选了。

问题一：搜索 ascii art 问题二：就是要用 coffeescript 去写 js