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

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

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。 作者:本猿不才,文采平平,且读切珍惜。

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?

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