#33 楼 @jasl 小团队 3 年前 4 个 ruby 开发，3 年后还是 4 个 ruby 开发……去年一波实习生最后都去前端投入了 node 的怀抱，说 ruby 语言级太复杂了（小声语 JavaScript 在语言级不是更复杂吗……）。这么缺人理论上做培训不是应该很赚钱么= =

#4 楼 @zhzyc142 不过说实在的在数据统计这方面 py 真的是好用……

#1 楼 @realwol pandas 是数据分析库，numpy 是矩阵计算库 http://sciruby.com/ 应该年久失修很长时间了吧。。。这些事情还是交给 py 去做吧

前端选型几大原则

1. 找自己和团队熟悉的来，所有工具都有坑，本质无太大区别。
2. 没一个熟悉的话，先看 github 上活跃程度，然后谷歌其名称加教程关键字来判断学习难度
3. 最后如果发现好像自己对现在的 js 一无所知的话，用 jquery 肯定没错！

大学实习期在电信跟着师傅折腾过 cpp，我师傅是大神我不是……我只能根据我自己的学习经验来分享一些 CPP 的经验。 《Essential C++》也是入门阶段读的书，比 Primer 要薄很多。Primer 两套书 c 和 c++ 总体来说都是很不错的书，大而全点很细，如果打算好好打好语言级的基础两本书还是都好好看几遍，做点笔记吧。这两本侧重都是教会我们怎么用 OO 和编译器的角度来思考代码，而不是用 C++ 来做应用程序。（好像说了什么又好像什么都没说）。 PS. 最好的学习方式是找个同样在学的哥们一起学，不知道多少有效率……

我觉得这个就看项目的投资与回报比啦。 1.像 bootstrap 这种 css 的手工下载也无妨 2.gems 方式是最容易马上看到效果使用的方法，对一些不是很精通的库这种方式是最好的 3.当然有了进阶自定义需求的时候就会体验到 npm 和 bower 的好处……话说 bower 还是有不少暗坑的如果没有“现代化”的 js 经验很容易被一些很奇葩的问题坑进去。

明明我们使用第三方库是为了去避免问题，但是总是会因为使用了不太成熟的第三方库去“创造”更多的问题。

= 3=龙华绿地莫 哪天跑客户路过，能不要脸地上来蹭口水莫 ^_^

jenkins 一键云集成版的定位吗

一个工程的报价主要成本有三块

1. 研发风险成本，火箭上天跟水火箭上天都是上天，但是风险不一样
2. 客户开发、售前、实施及售后，这块其实最多只占成本的 60%……
3. 时间及运营成本，做项目不给时间周期都是耍流氓……1 个人做 3 个月和 3 人做 1 个都是 3 个人月，但是产出会差距很大…… 甲方买乙方的“成熟方案”买的不只是代码，同时还能降低第一和第三对应两种成本。如果对方是个人 15 万是高的，如果对方是一个企业报价 15 万便宜了，公司报价没有个 200%~300% 的溢价，行情不好的时候就等着倒闭吧…… 怎么衡量买的系统贵不贵，给你这点预算你自己有 100% 的把握搞定售前、调研、设计、开发、实施、随叫随到的售后及漫长讨尾款的成本。

#4 楼 @nightire yes，你说的很对。可能是我表达的方法不同。其实我想表达跟你是一样的观点，ng 工程化靠人，ember 工程化靠框架。可能是 ng 的门槛看上去很低，导致我见过各种诡异的组织方式。ng 是一个在熟悉了 ng 的加载模式和开发规则（angluar clean code) 之后生产会陡然上升的框架。

如果楼主是零经验的话，我这里找不出相关的资料不过可以提供一些关键字信息； 1.搞懂下 jenkins master-slave 模式； 2.搞懂下 docker 容器间的编排； 3.编排一下一个 jenkins master 的 docker 和一个 jenkins slave（CI 构筑用）container 环境； 4.在 master 节点安装一下 git 和 gitlab 的插件； 5.在 Gitlab 那边配置一下 ssh key 和 callback 的路径（gitlab 插件上有教程）

jenkins 官方网站上应该可以搜到我说的所有内容，整个过程第一次折腾的重点多半在 docker 上 最后推荐顺便把 jenkins、gitlab 与 slack 的通知也开了……

#2 楼 @tvallday ng 和 react 很大的特点就是结构松散（react 全家桶不算的话），拿 ng 来说，不知道 npm、不知道 bower、不知道 module 和注入原理一样可以写一个简单的 demo 出来。ember 则太面向工程，很多黑魔法和约定，入门阶段就挡住不少人。类比 rails 的话，就好比曾经想学习 rails 的同学，一多半在了第一个 bundle install 上就放弃了…… 一定要类比的话就类似生写 php 和用 rails 来写 web 工程一样。

#28 楼 @tangmonk 可能你需要的是 npm install -g。。。

如果你又要 api 又要 html view，我觉得就不要用 grape 了吧。。直接用 rails 的 json builder 吧= =controller 看上去会舒服很多。

#19 楼 @rei 如果 rei 也是在阿里云上机器做一堆 build，然后 image build 再在 container run 的话，这真的是炼狱模式。 我们曾经选过很多种方案来解决这个问题，首先我们的环境是下图这样的，LB 后接了 ECS 上跑 Docker Container。

美 (zuo) 丽 (si) 的计划 1.0

1.在开发环境上调度 jenkins 的 SCM 或者其他规则来触发 slave 机上的 build docker image； 2.然后用 docker push 然后推到一个私有的 register 上 3.使用集群工具调度部署的容器来更新与重启。 然后我们操作中纠结了……我们是不希望 ECS 有流出流量去外网访问 private 的……

更 (zuo) 美 (da) 丽 (si) 的计划 2.0

我们想，要不我们放一台有外网的机器负责调度所有的节点更新呗？ 然后发现 docker 的 register 真的是挺深的坑，在整个部署环节我至少还需要考虑回滚，更新，版本控制等一些列问题，只是给我一个仓库啥的完全没用…… 正在我们欢乐地“浪费”几个工作日后，突然有个童鞋弱弱的说声，要不我们就导出 image ftp 过去更新呗……

docker export
docker import

经过以上一系列完 (zuo) 美 (si) 的尝试，得出以下一些不太成熟的认知： 1) 在 docker container 数量和类型不够多的时候，收益不大 2) 用了 docker 不进行持续集成和持续部署，就好比做了敏捷开发不去写测试用例一样变扭； 3) 如果整个流程跑通了，运维部署的同学每天就只要刷刷 B 站好了； 4) 数据库部分个人觉得还是不要 Docker 化了，找问题各种麻烦

我们的做法是把 image 作为交付单位的，dev 开发完推上代码仓库，SCM 抓代码 build image，然后调度上 container。现在使用 docker 后，感觉最大的问题是以下几个命令

npm install
bower install
docker pull/push
git pull/push
bundle install
mvn install

谁用谁知道

会 ruby 大部分 java 水平都不低。一个人做产品和十个人做产品需要考虑的不只是快。 想不通就问经理为什么用 java。

楼上好多吐槽四版的…四版的质量太瞎了。最后我靠三和谷歌勉把所有代码跑通，副产品是篇四版避坑指南。 单从书内容来说很好，有设计分析有编码，有测试，小步迭代开发。

#4 楼 @jasl py2 和 py3 的之间大概隔了一个 angular2.x 与 angular1.x 的距离…… #5 楼 @jiacai2050 JDK5 是个里程碑，JDK8 也是一个里程碑……如果还在抱着 JDK5 估计都是债很深不敢轻易动的项目。就说修改了 PermGen space 这种坑就是很多人的福音……

感谢我大腾讯啊

JPA 有自动生成 ddl 的功能，算不算呢…

问题 1.如果是单节点 Master 情况请看一下启动 java -jar jenkins.jar 的用户是不是有 ruby 的权限，检查一下 workspace 的文件件权限。 问题 2.如果是 slave 的话，请查看一下 ssh 过去的用户有没有权限 最后，jenkins 走 slave 的话而且用 rvm 管理的话，经常不靠谱……最好还是老实点在脚本前面把环境变量都写了吧

09 年 3500，上海，每天在小机上与 alc 编译器作斗争…好开心的时光

#6 楼 @alucardpj jenkins 有 gitlab 的插件，基本流程是事件后触发钩子，jenkins 负责构筑，然后 jenkins 会在 mr 的评论区新增一条评论，并且修改 build result 的信号灯。但是所有 ci 信息都需要去 jenkins 去看，gitlab 的 ci build 是看不到的，这是缺点。

绝对不是拆 gitlab 的台，= 3= 当时看了 CI 的文档就觉得好复杂，然后就毅然决然的投入了 Jenkins 的怀抱…… 术业专攻，CI 方面用 Jenkins+ 一堆插件 + 一堆 docker 的 slave 真的是好爽…… 在 Gitlab8.0 之后 Jenkins 也有插件可以利用 gitlab 新的 CI Feature 去更新 build result，其实也是很不错的选择

#13 楼 @zhangsm spring-boot 真是一个相当重的框架呐，只能说 spring 好全，基本上什么场景的应用都可以搞一下。rails 就比较擅长 WEB 啦。Java 的好处可能好似够工业化吧，毕竟编译器能消灭很多脑袋短路的错误。缺点也很明显，人生三分之一的时间在编译和重启……

#2 楼 @judi0713 应届 ruby 不好找工作的原因并不在 ruby...现在市场是难招人，合格的工程师，语言只是工具，别迷信。自己走自己的路，ruby 显然比 java 要用的爽…相信我…

为了找工作请选择 java,php,swift… Ruby 是为了让我们喜欢工作…

#17 楼 @riskgod 一般手机 api 额外带点 device 的信息…我觉得也是一套维护的，总不能大家公用一套 service 代码吧… #23 楼 @whosv 招聘是个双向选择的过程的，不如把一些软性福利贴出来吧