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