好漂亮的妹子，不错的团队，cool~

服务器太危险了 哈哈哈~

1. 7 点出发，9 点到，9 点下班
2. >=￥30/per day

@haitongz 我不太知道有没有这样的开源项目，原来我们做的那套，也有很多不完善的地方，因为内部使用，求快，有些地方没有去斟酌，用起来还是蛮好的，管理员收到一个求批准的邮件，在 iphone 上点下放行，就开了个后端的服务器在线上工作。需要结合自己的业务去改善，比如@ruohanc提到的，是否有实时需要考虑的，这个实时得多实时，然后你的脚本的安全性，通用性等需要去做一定的设计，比如你可以在 shell 脚本中包含一些模板标签，web 系统下单的时候去替换或者批量生成一些脚本等...还是有很多细节需要去想。

经常听到某些人说 1-2 个星期就能运用某种语言或者框架，听罢一笑而过。

接外包，如果不熟悉的，可以签个合同，或者预付什么的，否则不接。如果真想给你做，也不在乎这点麻烦。如果不愿意，就得好好考虑一下了。

使用 rails 完成界面和交互，使用 bash shell 去完成真正的工作，在 web 里面提交表单记录操作日志和驱动脚本 (调用 shell 脚本可以在输入 sidekiq 等队列服务器中去进行)，脚本和 rails 可以通过文件、数据库通讯，原来实现的一套在 aws sdk 上管理云服务器的小系统和你描述的需求很相近。其实这个实现跟用不用 rails 没有太大的直接关系。

即便是脚本写的再优秀，有时候状态不好，敲错命令也会铸成大错，使用 web 可以更好的避错，也可以将脚本的执行能力扩散给更多的队友。

@zj0713001 @dddd1919 @bhuztez 对客服工作人员来说，使用 desktop 的界面会比较好，这里面还有选择客服的仲裁等细节，具体一些设计业务算法的实现，在 web 里弹个框，或者在后台，对客服较为不方便，我现在打算使用 node-webkit 实现一个简略版本的给客户使用。

原来如此...

怎么没人 follow 呢？

erb，暂时没体会到 haml 的美妙~~

你这是技术选型吧，何来架构？

默认支持中文吗？记得上次用的时候不支持，我当时用的 9.0.0，现在是 9.0.6，可能是哪儿没搞对。

WOW，真是一次不错的体验。

国内外不一样，国外全不 care ie8 了，http://zurb.com/article/1265/ie8-is-going-the-way-of-the-dodo-so-why-s

pattern 分类做的不错，很多效果很有意思，但是因为追求语义化和简单的类名标签，低版本的浏览器不支持，比如 nth-child，官网上的对比标签比 bootstrap 少很多，但是没有提及浏览器兼容性的问题，不过这确实是个非常不错的项目，连 comments 都是 pattern 了，提高效率，样式没有那么多，不用大量的 override，是谁说 theme should be built on top of framework....来着...

看起来不错，合适的上。

1. 在里面装个虚拟机
2. 客户需要教育

其实每行每业都这样的，不只是程序员，只不过我们是这个群体的一个成员，自然听到的这类抱怨就多，还是要找到工作中真正让你兴奋的点。如果你足够强大（可以是有钱，也可以是精神强大，也可以是其他的任何方式）就不会这么有感概了；否则的话，还是抓紧时间变得争取变得强大起来。

没有数据校验和安全加解密部分 (application_controller 覆盖 render 实现)，可以考虑复写非 200 等状态的数据，将异常也转化成 json 等要求的格式。想使用同一个请求路径的话，api 就设计成命令模式，根据 cmd_str 再去分发，避免客户端需要调试不同的 api 路径。

非常感谢分享的链接，好好读一下，THX。

Kabam 是不错的公司。

感谢，决定看看 Nesta

同意 #20 楼 这儿就有个，一个函数 10 多个 if，嵌套层次很深，也是架构师，难以理解。架构应该是慢慢积累的，还要在项目中取检验，不同的项目因环境和数据量、业务场景不同而无法 copy 架构，但是别人的架构是可以欣赏的、可以借鉴和学习的。#21 楼说的很对哈。

你们的网站好有爱，哈哈。

Good luck!