• 过年40,天天在写ing

  • #6楼 @yingce ecshop, iwebshop据说也不错

  • #2楼 @Trump 呵呵

  • jQuery只是一个lib,并不是框架,拿来和框架对比,本身就不对了

  • @hging 这倒是一个好办法,我前面说的precompile,虽然在开发机上等,但终究服务器运算还是快,不过你刚才说的这个gem和楼上 @Trump 说的有异曲同工之妙,我太拘泥于cap的方式了,开发上的确cap还是上手快,不过我是可以继续尝试一下在docker上看如何借鉴二位说的方法了,多谢

  • #11楼 @hging 但是这样的话,每次编译就会在开发本机上做,这当然不是说不可以,不过compile这个过程也是非常耗时耗力的,有时候还是希望扔给服务器。 其实除了这个点,还有另外的一些点,比如说,migrate,还有bundle install,前者的问题是,跑的前提是image已经做好了,需要用一个新的容器来跑一下,后者的问题是,和assets类似,做不好,每次都是要重新安装,相对cap本身来说,速度会慢了很多

  • docker在rails项目的应用上,我一直很纠结的是,怎么能用上capistrano,尝试了几种方式,感觉都有点不舒服。

    之前尝试的是放弃capistrano,每次打包一个image,再部署,这个缺点是,asset和bundle install弄不好总是要全部重新写层,所以每次部署的时间都会很长。现在用的方式是,用docker开一个容器,然后对后开好ssh,通过 capistrano部署到这个容器中,部署路径用的是一个data volume,这样换容器没有影响。

    这样做,至少在开发阶段,部署的速度能和直接用cap一样了,但其实只是绕路了,和docker本身的意图有点背道。

    不知道大家在rails项目上使用docker有啥可以借鉴分享的吗

  • lz,说几句不好听的,创业公司最怕的就是碰到你这样的了,也许你再磨几年,回头看看自己的经历,会有不一样的感想。

    就谈rails,用在你目前的项目上,碰到的瓶颈究竟是什么?是性能吗?在我个人的项目里面,感觉在前端资源的处理中,其他语言的处理还不见得有rails的pipeline来的完备,而且,rails的pipeline等设计,包括开发模式和生产模式的一些处理,在我对其他语言其他框架的使用中,也总能找到各种影子,都是共通的。

    我为什么说开头那些话,我的理解是,对于很多公司而言,上了套系统,性能上可能远没达到rails和ruby处理不了的时候,然后开发就风风火火地开始用另外一个新潮的框架去了,结果最后用很炫的语法做出来一套东西,存在着一堆的问题,维护还没人跟的上,至于性能的提升,恐怕只有一堆hello world的比较了。

    当然如果在公司环境允许下,多尝试新的东西,这是绝对的好事,不过个人建言,慎言放弃,你可以不用它,但你更可以从中学到它的长处和短处

  • 素质高的国企里面一般混不好,国企里面混得好的肯定不是素质高,情商高,人脉高才是最重要的

  • #39楼 @lyfi2003

    "最好"二字太过牵强,当然你要一定这么认为也是你的自由,只是我个人感觉,你给你的这个模板,冠上了太多的个人感觉而已

曾经的.net程序员,java程序员,php程序员,python程序员,Siebel实施顾问,ios程序员,android程序员 目前玩ruby, node.js