这是一篇关于Rails的开发经历的文章,旨在将Rails中遇到的各种问题分享给还未接触Rails或是已经上路的朋友。虽说做Rails的开发时间不长,刚好一年多。但是,在这一年的时间中,该使用的技术架构,Ruby-China
推荐的Gem包,都尝试过使用过了,也为业务开发了一些Gem包。谈不上精通Rails,如果把Rails作者定为最高等级,他是F1赛车手,我该是个跑出租的老司机。
早前有做过Java,PHP,.Net的开发,相信玩Rails的朋友多多少少也都有写过,不过主要还是以前端为主。早在IE7/IE8 时代做前端开发,那时Node.js
还没火起来,前端成了低技术含量又耗体力又没地位的活。不过,还好有Node.js
,让我赶上了这个时代。
当公司的一个PHP的多人即时聊天项目接近尾声时,我们在思考能不能将程序员生产力解放出来?是不是可以尝试一些其他的技术架构。很快,经过多方研究,发现Rails是单兵作战的神器。相比PHP,可以达到Rails : PHP = 1 : 4 的效率。但对于一个技术架构成熟的技术团队来说,放弃原有的技术架构去使用一个从未接触过新技术,时间成本和决心是很重要的。但挑战往往会带来意想不到的收获。
学习新技术的第一件事就是去找学习资料。在google上找了很久,发现深大图书馆有各种各样的技术书籍,果不其然,在这里找到了Ruby元编程
,Rails之道
,敏捷开发之道
这些书籍,但是版本比较老。为了能够掌握最新版本的知识,下载了相应的英文版PDF,一起结合。修炼Rails的过程是痛并快乐着的,因为要转变思维模式,去接受新的思想,去了解诸多的语法糖因何而生。学累了就躺会,饿了就上个外卖,脑袋成浆糊了就洗把脸。其实接触一门新语言并不是多难,这是一个循序渐进的过程。好在前端底子厚,学习ERB
,UJS
,RJS
的过程比较轻松,但是Turbolinks
对于前端工程师来说就是噩梦,一直到现在我都用的Pjax。不喜欢Turbolinks
的做法,Pjax
显得很机智。关于Turbolinks
和Pjax
我并不是挑起战争,仁者见仁,智者见智。
在构建电商系统的时候,很自然就 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的过程相对比较顺利,在听完Rei
大神对Turbolinks
的讲解之后,还是坚定不移的使用Pjax
,值得注意的是在使用WiceGrid
的时候,会存在初始化组件问题,当时是使用data-skip-pjax
解决。不过现在前后端分离,前端使用React + Redux操作DOM比以往轻松多了。事实上WiceGrid
的筛选方式对于用户并不友好。
这两个Gem的使用不多,在尝试过Devise
之后,还是得自己手写一遍登录等功能,第三方登录开始有考虑用,后面发现还用不上就没有研究了。
在使用china_city的时候发现一个小问题。
(($) ->
$.fn.china_city = () ->
@each ->
// 下面这一行选择.city-select的时候没有限制为select
// 如果class有冲突会出现bug.
// 所以更正为 $(@).find('select.city-select')
selects = $(@).find('.city-select')
selects.change ->
.
.
.
)(jQuery)
在开发中多次切换了前端技术栈。只想告诉大家,Materia UI
并不适合后台使用,而且与诸多的Gem包存在兼容问题,Rails中大部分跟前端有关的Gem都是基于Bootstrap
。所以觉得Bootstrap
审美疲劳的朋友,还是继续用着吧。
随着JS的增多,维护起来会越来越难,在Rails的项目中并没有做JS模块化,而是将JS用工厂模式汇集到了一起,新的功能代码会放到工厂车间去,在使用的时候 new 一个工厂,调用需要的功能即可,同时保证了可复用性。
其实Rails的应用部署相对比较容易,没有太多的内容。只要注意配置文件加后缀防止被新的commit
覆盖就好了,一般来说,写好shell脚本实现一键部署也并非难事。
现今主流的是微信支付和支付宝支付,银联的太蛋疼了。相比与微信支付,支付宝的文档真心不友好,看到吐,而且申请流程繁琐。如果你有打算在项目中使用支付宝支付,最好提前两个月做申请。虽然我不太喜欢马化腾,但是微信支付的文档我给32个赞,使用起来也方便。微信支付的申请流程更加透明一些,每个节点都很快。使用下面的Gem
gem 'wechat'
gem 'wx_pay'
但是也有一个问题待解决,就是在支付时取消订单,数据库状态更新,而微信支付的数据状态未更新,再进行支付的时候就会出现订单号已存在的error
。
在便利店用过微信支付的朋友应该知道, 好近
这样的第三方支付商的虚拟键盘。开始做虚拟键盘的时候想扒一下好近
的源码,奈何用微信开发调试工具根本拿不到。所以只能自己写,遇到的第一个问题就是点击事件延迟300ms,虽说可用Tap
事件,被搞得不要不要的。先后尝试了JqueryMobile.Tap
,FastClick
等解决方法,仍然是在Android
上延迟超高,IOS
流畅。后面灵感闪现,我为什么要给用户一个完整的点击事件呢?一碰到就触发键盘不是可以让用户得到的反馈跟好么。索性偷懒了一把。
$(element).on('touchstart', function(e){/* do something */}
Rails从诞生到现在,已有经年。开发过程中最拖慢开发进度的不是需求变动,也不是技术点,使用了assets pipeline
的话,在调试页面的时候资源加载总是很慢。实在受不了的时候尝试了结合Node.js
,用Gulp
browser sync
,来代理资源,虽说速度快超多,但不是官方集成的方案,多多少少让强迫症的人很难受。对于业务复杂的电商系统来说,Rails标准的Action
肯定不够用,而自定义的写出来感觉不伦不类,可能是功夫不到家,但是没有找到更好的编程参考。其他的就是性能问题了,了解Elixir
的朋友应该就知道了。
响应Peter
的号召,我也全情的投入到了Meteor
+ React
+ Redux
的大军中去了。虽说没用Meteor
做过大型项目,但是小应用做起来是得新应手了。好像也没有看到有多少大型项目用Meteor
+ React
+ Redux
技术栈的。用上React
前端代码思路和结构变得清晰多了。也可以使用诸多的React
组件了。类似于Amazeui,Ant Design,这些优秀的设计,连UI的费用都省了。
Elixir
不用我说,相信大家都有耳闻了,函数式编程是未来。一个专业前端的Rails工程师切换到Elixir
的过程没有第一次经历的痛苦,当你接受了函数式的思想之后相当顺畅。社区里面有的人说Phoenix
抄Rails
的,我并不认同,Phoenix
传承了敏捷开发的思想,也为开发者提供了诸多的便利,像Hot load
的技术也被集成进来,对于Socket
的支持也是相当的好。融合Elixir
的特性,让多线程成为利器,利好多多,如果可以,你应该像我一样去深入研究下Phoenix
,还有你们常用的Devise
也是Phoenix
的作者写的。当Rails
老了,你还有Phoenix
AD:你错过了房地产,错过了网购,错过了炒股,别再错过Elixir
Phoenix
React
Redux
。