成都重新定义了不辣

这一届选择成都是非常明智的, 300+ 的参与人群证明大家是很热爱这里的 😃

事实证明, Ruby 社区一直是一个友爱, 认真, 不断成长的社区. 加入 Ruby, 就加入了整个社区, 分享整个社区的资源和帮助.

我在这里主要讲讲主题演讲的情况与内容, 以便没有时间或机会参加的朋友了解概况.

主题一: Rei 分享的 Turbolinks 与 关于它的 Native 方案

• Rails 的哲学 Omakase
• Turbolinks 对比前后端分离框架的速度优势( RubyChina 800ms VS Discourse 2.8s )
• Turbolinks Native = Native + Web

优势: 可复用 responsive web page, 大量节省开发成本 缺点: 仍然需要 Native Code 配合. web 与 native 交互是一个不爽的点.

总而言之, 这是一个 Rails 工程师值得学习的点. 现在 RubyChina 的 iOS 版与 Android 版均已发布. 开源代码也已经释出. 对大家而言是一个不错的充电的方向之一.

主题二: 知人( 一个的HR使用的 [企业级] 产品 )模型构建经验分享

前提:

每个公司对于工资单的计算都不一样. 没有一个通用的模型进行计算工资

模型设计:

一切皆可重算

原始数据 + 计算规则 = 工资单

计算规则可以用一系列策略模型进行抽象. 目前日活 10 万+.

除模型, 还讲了一些关于内部用的 rails generator 等经验.

我个人有不错的收获: 当遇到一些不明的规则的需求时, 如何设计你的应用数据模型.

主题三: 陈金洲关于重构的主题 - 重新理解和设计 RESTful

金洲是一个吐嘈大师, 这点体现在了演讲了各个环节 😃

这个 REST 的主题是一个很远之前的观点, 大约在 2007 年 DHH 就有一篇这方面的讨论. 但渐渐地, 大家又忘了它的本来面目.

纯正的 REST 就是 CRUD + resources, 如何将 CRUD 之外的操作也抽象为资源, 是关键. 做的好, 就可以让每个 controller 清晰干净.

在这个 slide, 有一个新观点: 架构就是克制 - 陈金洲

我个人观点: API 接口的设计是一门艺术, 不是每一个程序员都能把它搞好, 尤其是BAT那些人. REST 虽好, 但也不建议过度极端. 否则资源的抽象是一个非常有挑战的事. 并且 REST 适合对外的API, 但对内, GraphQL 这种思路反而能让用户体验更好.

主题四: I18n 经验谈

Rails 原生的 i18n 解决方案的优缺点, 以及为什么要选用 gettext 方案进行 i18n 设计.

如何构建一个全球化的 i18n 流程, 包括团队招募, 流程制定等.

Rails 原生的方案不错, 但也不适用于大规模的 i18n 团队需求.

相信这个主题对于有这方面需求的团队将会很有帮助.

主题五: Rails 应用廋身

namespace 抽离 gem 微服务化

微服务化的优点与缺点, 如何应用

谢文威是一个资深的讲师, 将这些问题一一个深入浅出做了分析, 这几年有一种把微服务神话的感觉, 但实践来看, 这个也不是万能的方案. 有时候反而导致了更多的复杂性.

对于 Rails 应用开始复杂起来后的处理方向做了探讨, 非常具备思考性.

主题六: 定位 Rails 内存泄漏的问题

讲述如何定位到 Timeout.timeout 方法 在 Redis 某个版本中导致的内存泄漏问题

这是一个非常技术化的话题, 对于一个致力于提高个人技术能力的同学来说, 剖析问题的根因的思路是必不可少的. 这也让我想到几年前的自己也是经常沉迷于具体的某个技术难点.

但我听完 timeout 导致泄漏的原因还是差了最后一点点深度... 希望能进一步析出为什么短时间 timeout 对象集中创建而不释放...

这种追根的思路希望对听众们有帮助.

主题七: Elixir 的介绍

Elixir 语法与 Ruby 的异同. 介绍了 Erlang 的进程模型, service.

什么是 OTP

有人评论, Elixir 除了太新之外, 没有其他缺点. 这个介绍初步给大家普及了 Elixir 的语法与特点.

不过我认为, 在 RubyConf 这样的大会可以更多分享一些思想性的内容. 毕竟演讲时间不长, 大家也没有充分准备.

主题八: 在 Rails 下如何给用户提供 API, 技术选型等

对比了 Rails API 和 Grape.

如何做 auth

总结: 没有最好的方案, 只有更适合的场景.

Terry Tai 也是个老司机了, 讲的非常流利. Rails 中提供 API 在社区中也是老话题了, 之前就有很多讨论. 这次做了集中的讨论和方向的思考. 这种思考方式是每一个老司机 Rails 工程师应该有的.

也希望这个演讲能够让你掌握到 Rails 中有哪些个方案来实现 API 编写. 以及各种利弊.

第二天

一. deppbot 自动更新你的 gem

Juanito 是一个台湾的同胞, 这个主题介绍了如何实现一个可以让你的应用自动做 bundle update 的产品之路.

非常真诚与有效的介绍, 既分享了 deppbot 的产品本身, 也分享它本身的故事.

我也有这方面的需求, 但更新 gem 也非常依赖良好的测试覆盖率, 不然会出现意外之外的问题.

大家一方面可以使用这个产品. 也可以了解一下如何做成一个产品以及背后的故事.

二. 如何重构

先估api数量 api 测试 model test ci

Xdite 用大量的经验实践出来的重构之路, 相信对于一个接手烂摊子的程序员能够解决燃眉之急 😃

注意流程, 一定是先评价工作量, 再上基本的 API 测试, 最后才去重构. 老板是对的: 一切围绕着商业目标.

三. 环境变量 Ruby 快十倍

RUBYOPT -rbundle/setup

bundler/setup 的执行过程

潘旻琦的主题演讲非常有趣解释了为什么在 Rails 应用中执行 system 程序会非常慢的原因.

弄清楚 bundler 的执行过程是每一个高级 Ruby 工程师的必经之路, 希望大家可以掌握和了解它.

四. 介绍使用 Rails5 快速开发高体验性的 wechat APP 的经验

这是我的主题的主旨. Rails5 在 turbolink5 和 actioncable 支援下已经变成一个完全全面的 web 开发框架, 也是极致开发效率的代表者了.

选型 Rails5 做快速的原因, 以及 Rails5 如何让我们用低成本的方案, 并且开发出的应用是用户极致体验的. 都是这个主题要讲述的故事.

希望对大家对 Rails5 的认识能够更加全面.

我在这里提出一个观点: 每一个 Rails 工程师都应该拥有一个长期维护的项目

ps: 我们正在启动一个 Rails5 远程教学产品: 80学院, www.80academy.com 有兴趣学习的同学可以来仔细看看并和我们交流.

五. actioncable 与实时交互

曹总的话题一开始我以为是我的主题的全面解读, 后面发现并不是...

个人觉得一开始讲的非常不错, 但后面偏题了啊...

ActionCable 从接口设计上我认为是非常不错的, 应用起来非常简便有效. 我认为它必须是 pub/sub 方式的. 要异步的啊.

它解决的主要问题:

• 要与 Rails5 一致性, 所以可以直接 render 回 html 片断, 和读取 cookie
• 接口要接近 rails5 风格, 所以用了类似于 RPC 的封装.

当然也有一些问题:

• 布署有些复杂
• 本身也较为复杂

整体而言, 是值得为 Rails5 立本的, 有了它, Rails5 才全面和完整.

六. 函数式 Ruby 编程介绍

欧阳继超的演讲让我们认识到函数式编程在 Ruby 中的体现. 不过由于个人对函数式编程理解还不深, 不做过多评论.

有兴趣的朋友可以进一步了解.

七. 介绍 Ruby 在逐渐扩大规模的团队中的应用

赵明是一个电商团队的技术负责人, 为我们分享了他在团队中对 Ruby 方方面面的应用. 可以说他的能力非常全面, 是 Ruby 和 Rails 在团队中深度应用的体现, 个人以为很受用.

用 Ruby 定义规范, 而不是文档, 是一个非常好的技术化思维,

在此, 他介绍了内部用 Rails 开发自用的 、用户系统、权限系统、基础 API、前端框架等.

每个主题讲师介绍可以直接看 这里, 后续官方应该会释出每一个主题的 slide 链接.

以上是两天里主题演讲的一些情况, 希望对没能前往的朋友有所帮助.

赶忙之作, 难免有错误, 再更新.

再次感谢主办方的辛苦付出.