成都重新定义了不辣
这一届选择成都是非常明智的, 300+ 的参与人群证明大家是很热爱这里的 😃
事实证明, Ruby 社区一直是一个友爱, 认真, 不断成长的社区. 加入 Ruby, 就加入了整个社区, 分享整个社区的资源和帮助.
我在这里主要讲讲主题演讲的情况与内容, 以便没有时间或机会参加的朋友了解概况.
https://speakerdeck.com/chloerei/ji-yu-turbolinks-de-kua-ping-tai-kai-fa
优势: 可复用 responsive web page, 大量节省开发成本 缺点: 仍然需要 Native Code 配合. web 与 native 交互是一个不爽的点.
总而言之, 这是一个 Rails 工程师值得学习的点. 现在 RubyChina 的 iOS 版与 Android 版均已发布. 开源代码也已经释出. 对大家而言是一个不错的充电的方向之一.
https://speakerdeck.com/zchar/zhi-ren-shi-ru-he-suan-gong-zi-de
前提:
每个公司对于工资单的计算都不一样. 没有一个通用的模型进行计算工资
模型设计:
一切皆可重算
原始数据 + 计算规则 = 工资单
计算规则可以用一系列策略模型进行抽象. 目前日活 10 万 +.
除模型, 还讲了一些关于内部用的 rails generator 等经验.
我个人有不错的收获: 当遇到一些不明的规则的需求时, 如何设计你的应用数据模型.
https://speakerdeck.com/mechiland/reconsider-rest-chong-gou-jian-da-xing-railsying-yong-de-fang-shi
金洲是一个吐嘈大师, 这点体现在了演讲了各个环节 😃
这个 REST 的主题是一个很远之前的观点, 大约在 2007 年 DHH 就有一篇这方面的讨论. 但渐渐地, 大家又忘了它的本来面目.
纯正的 REST 就是 CRUD + resources, 如何将 CRUD 之外的操作也抽象为资源, 是关键. 做的好, 就可以让每个 controller 清晰干净.
在这个 slide, 有一个新观点: 架构就是克制 - 陈金洲
我个人观点: API 接口的设计是一门艺术, 不是每一个程序员都能把它搞好, 尤其是 BAT 那些人. REST 虽好, 但也不建议过度极端. 否则资源的抽象是一个非常有挑战的事. 并且 REST 适合对外的 API, 但对内, GraphQL 这种思路反而能让用户体验更好.
https://speakerdeck.com/danielglh/da-zao-guo-ji-hua-chan-pin-strikinglyde-i18nshi-jian
Rails 原生的 i18n 解决方案的优缺点, 以及为什么要选用 gettext 方案进行 i18n 设计.
如何构建一个全球化的 i18n 流程, 包括团队招募, 流程制定等.
Rails 原生的方案不错, 但也不适用于大规模的 i18n 团队需求.
相信这个主题对于有这方面需求的团队将会很有帮助.
https://speakerdeck.com/xiewenwei/ru-he-gei-rails-ying-yong-jian-fei-bo-he-wei-fu-wu-hua-shi-jian
namespace 抽离 gem 微服务化
微服务化的优点与缺点, 如何应用
谢文威是一个资深的讲师, 将这些问题一一个深入浅出做了分析, 这几年有一种把微服务神话的感觉, 但实践来看, 这个也不是万能的方案. 有时候反而导致了更多的复杂性.
对于 Rails 应用开始复杂起来后的处理方向做了探讨, 非常具备思考性.
https://speakerdeck.com/42thcoder/zhui-zong-rails-ying-yong-zhong-de-nei-cun-xie-lu
讲述如何定位到 Timeout.timeout 方法 在 Redis 某个版本中导致的内存泄漏问题
这是一个非常技术化的话题, 对于一个致力于提高个人技术能力的同学来说, 剖析问题的根因的思路是必不可少的. 这也让我想到几年前的自己也是经常沉迷于具体的某个技术难点.
但我听完 timeout 导致泄漏的原因还是差了最后一点点深度... 希望能进一步析出为什么短时间 timeout 对象集中创建而不释放...
这种追根的思路希望对听众们有帮助.
https://speakerdeck.com/qhwa/what-can-we-rubyists-learn-from-elixir
Elixir 语法与 Ruby 的异同. 介绍了 Erlang 的进程模型, service.
什么是 OTP
有人评论, Elixir 除了太新之外, 没有其他缺点. 这个介绍初步给大家普及了 Elixir 的语法与特点.
不过我认为, 在 RubyConf 这样的大会可以更多分享一些思想性的内容. 毕竟演讲时间不长, 大家也没有充分准备.
https://speakerdeck.com/poshboytl/building-api-for-the-rest-of-us
对比了 Rails API 和 Grape.
如何做 auth
总结: 没有最好的方案, 只有更适合的场景.
Terry Tai 也是个老司机了, 讲的非常流利. Rails 中提供 API 在社区中也是老话题了, 之前就有很多讨论. 这次做了集中的讨论和方向的思考. 这种思考方式是每一个老司机 Rails 工程师应该有的.
也希望这个演讲能够让你掌握到 Rails 中有哪些个方案来实现 API 编写. 以及各种利弊.
第二天
https://speakerdeck.com/juanitofatas/how-to-build-deppbot
Juanito 是一个台湾的同胞, 这个主题介绍了如何实现一个可以让你的应用自动做 bundle update 的产品之路.
非常真诚与有效的介绍, 既分享了 deppbot 的产品本身, 也分享它本身的故事.
我也有这方面的需求, 但更新 gem 也非常依赖良好的测试覆盖率, 不然会出现意外之外的问题.
大家一方面可以使用这个产品. 也可以了解一下如何做成一个产品以及背后的故事.
https://speakerdeck.com/xdite/refactoring-lesson-from-gpa-1-dot-4-to-gpa-3-dot-0
先估 api 数量 api 测试 model test ci
Xdite 用大量的经验实践出来的重构之路, 相信对于一个接手烂摊子的程序员能够解决燃眉之急 😃
注意流程, 一定是先评价工作量, 再上基本的 API 测试, 最后才去重构. 老板是对的: 一切围绕着商业目标.
https://speakerdeck.com/pmq20/huan-jing-bian-liang-wei-he-neng-rang-ruby-kuai-shi-bei
RUBYOPT -rbundle/setup
bundler/setup 的执行过程
潘旻琦的主题演讲非常有趣解释了为什么在 Rails 应用中执行 system 程序会非常慢的原因.
弄清楚 bundler 的执行过程是每一个高级 Ruby 工程师的必经之路, 希望大家可以掌握和了解它.
https://speakerdeck.com/windy/ru-he-li-yong-rails-zai-21-tian-dan-qiang-pi-ma-shang-xian-ge-chan-pin
这是我的主题的主旨. Rails5 在 turbolink5 和 actioncable 支援下已经变成一个完全全面的 web 开发框架, 也是极致开发效率的代表者了.
选型 Rails5 做快速的原因, 以及 Rails5 如何让我们用低成本的方案, 并且开发出的应用是用户极致体验的. 都是这个主题要讲述的故事.
希望对大家对 Rails5 的认识能够更加全面.
我在这里提出一个观点: 每一个 Rails 工程师都应该拥有一个长期维护的项目
ps: 我们正在启动一个 Rails5 远程教学产品: 80 学院, www.80academy.com 有兴趣学习的同学可以来仔细看看并和我们交流.
https://speakerdeck.com/shiningray/actioncablehe-shi-shi-jiao-hu
曹总的话题一开始我以为是我的主题的全面解读, 后面发现并不是...
个人觉得一开始讲的非常不错, 但后面偏题了啊...
ActionCable 从接口设计上我认为是非常不错的, 应用起来非常简便有效. 我认为它必须是 pub/sub 方式的. 要异步的啊.
它解决的主要问题:
当然也有一些问题:
整体而言, 是值得为 Rails5 立本的, 有了它, Rails5 才全面和完整.
https://speakerdeck.com/jcouyang/functional-ruby
欧阳继超的演讲让我们认识到函数式编程在 Ruby 中的体现. 不过由于个人对函数式编程理解还不深, 不做过多评论.
有兴趣的朋友可以进一步了解.
https://speakerdeck.com/zmbacker/da-zao-ruby-kai-fa-tuan-dui-de-hang-mu
赵明是一个电商团队的技术负责人, 为我们分享了他在团队中对 Ruby 方方面面的应用. 可以说他的能力非常全面, 是 Ruby 和 Rails 在团队中深度应用的体现, 个人以为很受用.
用 Ruby 定义规范, 而不是文档, 是一个非常好的技术化思维,
在此, 他介绍了内部用 Rails 开发自用的 、用户系统、权限系统、基础 API、前端框架等.
每个主题讲师介绍可以直接看 这里, 后续官方应该会释出每一个主题的 slide 链接.
以上是两天里主题演讲的一些情况, 希望对没能前往的朋友有所帮助.
赶忙之作, 难免有错误, 再更新.
再次感谢主办方的辛苦付出.