Rails Rails 从入门到完全放弃再到重新找回

tkvern · 2016年07月21日 · 最后由 posee 回复于 2018年10月04日 · 9578 次阅读

Rails 从入门到完全放弃再到重新找回

转载地址: Rails 从入门到完全放弃再到重新找回

前言

这是一篇关于Rails的开发经历的文章,旨在将Rails中遇到的各种问题分享给还未接触Rails或是已经上路的朋友。虽说做Rails的开发时间不长,刚好一年多。但是,在这一年的时间中,该使用的技术架构,Ruby-China 推荐的Gem包,都尝试过使用过了,也为业务开发了一些Gem包。谈不上精通Rails,如果把Rails作者定为最高等级,他是F1赛车手,我该是个跑出租的老司机。

背景

早前有做过Java,PHP,.Net的开发,相信玩Rails的朋友多多少少也都有写过,不过主要还是以前端为主。早在IE7/IE8 时代做前端开发,那时NodeJS还没火起来,前端成了低技术含量又耗体力又没地位的活。不过,还好有NodeJS,让我赶上了这个时代。

怎么接触到Rails

当公司的一个PHP的多人即时聊天项目接近尾声时,我们在思考能不能将程序员生产力解放出来?是不是可以尝试一些其他的技术架构。很快,经过多方研究,发现Rails是单兵作战的神器。相比PHP,可以达到Rails : PHP = 1 : 4 的效率。但对于一个技术架构成熟的技术团队来说,放弃原有的技术架构去使用一个从未接触过新技术,时间成本和决心是很重要的。但挑战往往会带来意想不到的收获。

在深大图书馆的 Rails之道

学习新技术的第一件事就是去找学习资料。在google上找了很久,发现深大图书馆有各种各样的技术书籍,果不其然,在这里找到了Ruby元编程Rails之道敏捷开发之道这些书籍,但是版本比较老。为了能够掌握最新版本的知识,下载了相应的英文版PDF,一起结合。修炼Rails的过程是痛并快乐着的,因为要转变思维模式,去接受新的思想,去了解诸多的语法糖因何而生。学累了就躺会,饿了就上个外卖,脑袋成浆糊了就洗把脸。其实接触一门新语言并不是多难,这是一个循序渐进的过程。好在前端底子厚,学习ERBUJSRJS的过程比较轻松,但是Turbolinks对于前端工程师来说就是噩梦,一直到现在我都用的Pjax。不喜欢Turbolinks的做法,Pjax显得很机智。关于TurbolinksPjax我并不是挑起战争,仁者见仁,智者见智。

用Rails对电商的探索

在构建电商系统的时候,很自然就 pull 了ECShop的源码来学习。 业务上的问题并不大,有现成案例,结合需求来订制开发很快。 同时在开发过程中Ruby-China社区也提供了许多帮助。类似查询 N + 1问题,CanCanCan权限问题.....

文件上传

上传图片

对于图片等资源的处理,最开始没有选用Carrierwave的方案,而是使用七牛云存储JS SDK,开始接触的时候,发现并没有多少参考文档,于是想是不是这个东西比较简单也比较少人用,还是Ruby-China 社区的朋友太懒。后面深入研究后发现,这类云存储的方法还是用得比较多,也比较便捷,但对于新手还是有一定门槛,所以做完之后顺带写了相应的教程造福社会。

富文本编辑器上传图片

在富文本编辑器中Froala可以说是佼佼者,我们选用了Froala。但是遇到一个问题,Froala中的图片上传仅支持Amazon云,因此不得不改造Froala的源码。幸运的是这个过程并不困难,我将改造后的Froala用策略模式做成了一个Gem: wysiwyg-rails-qiniu,又一次造福社会。

猴子补丁

在使用will_paginate的时候,分页的结构与样式与Materia UI的风格并不相符,并且没有找到合适的Gem,所以大胆的用起了打开类的法术,并且纪录了这一过程《 为什么重写will_paginate

Pjax

使用Pjax的过程相对比较顺利,在听完Rei大神对Turbolinks的讲解之后,还是坚定不移的使用Pjax,值得注意的是在使用WiceGrid的时候,会存在初始化组件问题,当时是使用data-skip-pjax解决。不过现在前后端分离,前端使用React + Redux操作DOM比以往轻松多了。事实上WiceGrid的筛选方式对于用户并不友好。

Devise 和 OmniAuth

这两个Gem的使用不多,在尝试过Devise之后,还是得自己手写一遍登录等功能,第三方登录开始有考虑用,后面发现还用不上就没有研究了。

china_city

在使用china_city的时候发现一个小问题。

(($) ->
  $.fn.china_city = () ->
    @each ->
      // 下面这一行选择.city-select的时候没有限制为select
      // 如果class有冲突会出现bug.
      // 所以更正为 $(@).find('select.city-select')
      selects = $(@).find('.city-select')
      selects.change ->
        .
        .
        .
)(jQuery)

前端css框架

在开发中多次切换了前端技术栈。只想告诉大家,Materia UI并不适合后台使用,而且与诸多的Gem包存在兼容问题,Rails中大部分跟前端有关的Gem都是基于Bootstrap。所以觉得Bootstrap审美疲劳的朋友,还是继续用着吧。

前端JS处理

随着JS的增多,维护起来会越来越难,在Rails的项目中并没有做JS模块化,而是将JS用工厂模式汇集到了一起,新的功能代码会放到工厂车间去,在使用的时候 new 一个工厂,调用需要的功能即可,同时保证了可复用性。

部署

其实Rails的应用部署相对比较容易,没有太多的内容。只要注意配置文件加后缀防止被新的commit覆盖就好了,一般来说,写好shell脚本实现一键部署也并非难事。

微信支付

现今主流的是微信支付和支付宝支付,银联的太蛋疼了。相比与微信支付,支付宝的文档真心不友好,看到吐,而且申请流程繁琐。如果你有打算在项目中使用支付宝支付,最好提前两个月做申请。虽然我不太喜欢马化腾,但是微信支付的文档我给32个赞,使用起来也方便。微信支付的申请流程更加透明一些,每个节点都很快。使用下面的Gem

gem 'wechat'
gem 'wx_pay'

但是也有一个问题待解决,就是在支付时取消订单,数据库状态更新,而微信支付的数据状态未更新,再进行支付的时候就会出现订单号已存在的error

微信支付虚拟键盘

在便利店用过微信支付的朋友应该知道, 好近这样的第三方支付商的虚拟键盘。开始做虚拟键盘的时候想扒一下好近的源码,奈何用微信开发调试工具根本拿不到。所以只能自己写,遇到的第一个问题就是点击事件延迟300ms,虽说可用Tap事件,被搞得不要不要的。先后尝试了JqueryMobile.TapFastClick等解决方法,仍然是在Android上延迟超高,IOS流畅。后面灵感闪现,我为什么要给用户一个完整的点击事件呢?一碰到就触发键盘不是可以让用户得到的反馈跟好么。索性偷懒了一把。

$(element).on('touchstart', function(e){/* do something */}

Rails 的问题

Rails从诞生到现在,已有经年。开发过程中最拖慢开发进度的不是需求变动,也不是技术点,使用了assets pipeline的话,在调试页面的时候资源加载总是很慢。实在受不了的时候尝试了结合NodeJS,用Gulp browser sync,来代理资源,虽说速度快超多,但不是官方集成的方案,多多少少让强迫症的人很难受。对于业务复杂的电商系统来说,Rails标准的Action肯定不够用,而自定义的写出来感觉不伦不类,可能是功夫不到家,但是没有找到更好的编程参考。其他的就是性能问题了,了解Elixir的朋友应该就知道了。

跟着Peter学Meteor

响应Peter的号召,我也全情的投入到了MeteorReactRedux 的大军中去了。虽说没用Meteor做过大型项目,但是小应用做起来是得新应手了。好像也没有看到有多少大型项目用Meteor + React + Redux 技术栈的。用上React前端代码思路和结构变得清晰多了。也可以使用诸多的React组件了。类似于AmazeuiAnt Design,这些优秀的设计,连UI的费用都省了。

我与Elixir 和 Phoenix 不能说的秘密

Elixir不用我说,相信大家都有耳闻了,函数式编程是未来。一个专业前端的Rails工程师切换到Elixir的过程没有第一次经历的痛苦,当你接受了函数式的思想之后相当顺畅。社区里面有的人说PhoenixRails的,我并不认同,Phoenix传承了敏捷开发的思想,也为开发者提供了诸多的便利,像Hot load的技术也被集成进来,对于Socket的支持也是相当的好。融合Elixir的特性,让多线程成为利器,利好多多,如果可以,你应该像我一样去深入研究下Phoenix,还有你们常用的Devise也是Phoenix的作者写的。当Rails老了,你还有Phoenix

结束语

AD:你错过了房地产,错过了网购,错过了炒股,别再错过Elixir Phoenix React Redux。 作者:本猿不才,文采平平,且读切珍惜。

共收到 58 条回复

rails开发者呵,不要被gems束缚了心灵

  1. Assets pipeline 换成 webpack + npm 来打包
  2. 项目太大(业务复杂),可以尝试微服务 + 容器化

Elixir 轮子还是不太够的样子,感觉 go 社区就好很多。

#2楼 @small_fish__ Elixir已经到1.3版本了。

#3楼 @tkvern 社区工具,比如好的 mongo driver.

不过来篇 ruby off rails 文章 http://rwdtow.stdout.in/

rails 不用 gem 会被人说『造轮子』

典型的玩啥错过啥 😅

这是来发革命的么,同志们揭竿起义吧😄

ruby党么 群起而。。。。。。。。。

万能的marc

抬举 抬举 😄

#2楼 @small_fish__ 有推荐使用webpack + nam的gem不?我也觉得目前用Assets其实不方便了,要找某个js的gem很多都不更新了,如果自己加入js,感觉也不方便。

万恶的Marc。

神一般的Marc,ruby党们开喷模式开启😄

是不是有bug,已经屏蔽了marc,怎么还能看到他😂阴魂不散

#16楼 @huacnlee 楼主一心想搞一个“大新闻” 😆

#5楼 @ywjno 是滴,有时出现一个问题求解,总会被回复:怎么不用 XXX Gem?

口水的力量是巨大的,对楼主强大的心理素质表示深感佩服😄

#19楼 @marc 拥有一颗强大的心,才能不被束缚

佩服,你继续😄

elixir 现在的包还是有点少,希望以后慢慢发展起来,多一个选择

#23楼 @nil 使用elixir该丢掉Rails 中 Gem 的束缚。。很多开发中的需要,作者都已经考虑进去了。 特别是Phoenix,你可以多去了解下

#11楼 @QueXuQ web pack结合assets pipeline一起用,webpack很方便,还提供common js, 打包部署则交给assets pipeline,有了

webpack就不用再用打包成gem的js插件了,那个实在是不方便。

26楼 已删除

请教楼主 Elixir+Phoenix+React+Redux,这个技术栈在国内有没有比较成熟的应用案例?

Marc的黑粉红粉在哪里,揭竿吧😄😄

就正文列举的点 Elixir 只能更难啊。。。

  • china_city 好久没更新了,js确实有问题,我现在用的是自己hack掉的版本(但是耦合有点紧没法发PR)
  • wx_pay 是我写的嘛...当然后来绝大多数功能都是贡献者贡献的了,已经可以帮绕过很多坑了,Elixir这轮子得自己造吧,况且看描述遇到的是业务问题
  • 前端 CSS 框架,跟BS也没啥关系,前端框架很多,Rails跟前端MVC配合确实会稍微有些坑
  • devise应该不需要你重写登录的业务部分了(除非你有什么特别复杂的交互需要定制),至于第三方登录和Omniauth集成的现成代码一大片吧
  • 前端js重不是问题,而且通常几M的js压完了也就2-300k,也有技巧去拆(公共+页面特有)
  • will_paginate 好久没用了,应该跟 kaminari 一样定制UI,继承个类就搞定应该

作者还是对Rails不够了解,但是可以先在 Elixir+Phonenix 的道路上走走看,然后再回头看看这些点立的客观不....

楼主大大的坏,标题是个“转载”,意图躲避火力,点进去转载地址一看,正准备战斗,尼玛,不还是你自己吗?

统一回复各位哈,文中有说小猿用Rails的时间不长,一年而已。过程中无大牛指导,无老司机带路,全靠几本教程自己摸索,实属不易。可能同样问题,在资深Rails玩家看来比较简单,但消息渠道有限,并不知已成熟的解决方案。在教程中所提到的技术点已全然用在项目之中。所以,要吐槽的朋友请,切吐切珍惜。

我能说我主要还是个前端工程师么?

#27楼 @adamshen 尚不知,但我目前正在做,做出来应该就有了。。 后端使用Phoenix提供API,前端React + Redux。。使用蚂蚁金服的Ant Design组件。

#32楼 @tkvern 如何确保刚做出来就能够成熟?需求复杂吗?不需要迭代吗?

#33楼 @adamshen 迭代与框架不关啊,除非刚出来就死了。 #11楼 @QueXuQ https://github.com/mipearson/webpack-rails

35楼 已删除

有些东西,万变不离其宗

使用者的故事

使用者是乐于分享的,更乐于比较,比较各自的金斧头,银斧头,桃木,榉木和刚果采摘的无花果

使用者可以一口气讲三天三夜,比较工具的 feature 和 使用的心情,甚至自己的生活和醒生活。

这对一小撮使用者有很大的影响。 而对于那些深知 《小马过河》故事的使用者,影响不大。

小马过河讲的是... 一天,一只小马,背着袋粮食,遇见一条河... 第二天又背着袋粮食,在河边把粮食吃了...

小马过河的故事,说明一个道理:

与其尝试 语言或者工具的深浅,不如关注与问题本质, 把本质吃透,吃进肚里,有可能就不需要过河了。

#38楼 @oth 很有哲学

期待楼主的下一篇是「Elixir + Phoenix + React + Redux 从入门到放弃」 :D

现在流行传教时只把别的教派批判一番而又不加任何干货?真的好用请先输出干货,不要总是一句xx大法好,毕竟传教也要按照基本法啊。

入门了么? 已经放弃了!

期待楼主的下一篇是「Elixir + Phoenix + React + Redux 从入门到放弃」 :D

楼主适合干前端: 够浮躁。

做电商可以参考下spree这个项目

杀鸡还是用杀鸡的刀比较好。

😆 读完感觉LZ的主要目的是想写一篇文章可以放在blog里……

#49楼 @raven 可以确定的一件事,你是认真读了文章的。

#46楼 @u1440247613 楼主是前端兼Rails

#47楼 @lehug 有过了解,谢谢分享

#41楼 @zackteng 后续章节会补上一些干货的!

从我们项目的角度看,Rails比较适合做web开发的,但我们一部分系统正从rails中剥离出去,但是Elixir不是我们的选择,主要解决问题的一些库不全,例如处理消息中“@”的库,我们过去利用的twitter提供的库,他们只有ruby和java的版本。最后我们选择用java8 + akka来重建部分系统,Elixir还在密切关注。未来云计算肯定是趋势,万物互联也是趋势,分布式计算更是趋势,但ruby在这方面明显发展比较滞后,期待ruby 3.0能实现actor的架构。

看了楼主的个人信息 95 后小鲜肉,感觉懂得比我还多,大家嘴下留情啊 😄

楼主现在一定在拥抱elm吧😎

然而我还没入门。。。

tkvern Dva + Ant Design 前后端分离之 React 应用实践 中提及了此贴 02月04日 17:36

纯JAVA和.net程序员,只是干私活时使用过grails及django,目前正在学习phoenix.整体感觉还行,除了对纯函数式编程还不是太适应外(python在这点上还是有优势的,无论你是oo还是fp,都能找到让自己舒适的方式),无论学习曲线、配置、开发及发布上,elixir还是给了我不少的惊喜。相信未来会有一席之地的,目前我最看好的,可能也就是elixir和nodejs.

unless u r making stuff like discord... https://blog.discordapp.com/scaling-elixir-f9b8e1e7c29b I don't see the value of doing this with e-commerce apps

Shopify花5年时间让他们的Rails app达到了80k RPS e-commerc还可以学习spree & solidus这两个gem

DHH: https://m.signalvnoise.com/ruby-has-been-fast-enough-for-13-years-afff4a54abc7 Rails能满足绝大多数使用场景,剩下来的场景就不是“用什么框架”这么简单的问题了

tkvern 学习 Rails 有感 中提及了此贴 10月03日 19:24
mizuhashi 回复

不要被gems束缚,意思是自己造gem?

需要 登录 后方可回复, 如果你还没有账号请点击这里 注册