leondu (Leon Du)

送书 ---《Rails 5 敏捷开发》

leondu — Fri, 26 Jan 2018 10:26:13 +0800

感谢《Rails 5 敏捷开发》一书的译者 @andor_chen 和大疆以 @Rei 同学为杰出代表的审校团队，作为曾经翻译过小册子的人，深知翻译的辛苦。如果只是算计单位时间的产出，作为有能力写作和翻译的人来说，翻译和写书可能是最不划算的工作了。

我本人和现在的团队都从 Ruby 和 Rails 社区受益良多，为了表示对社区的感谢，也小小贡献一下，送出 5 本《Rails 5 敏捷开发》

规则如下：

包邮
请看完后把书送给需要的人
没了

预祝大家春节快乐，happy coding!

《Thoughtbot Playbook》中文版

leondu — Fri, 03 Mar 2017 09:54:30 +0800

playbook 的简介请参见之前的帖子： https://ruby-china.org/topics/31292

之前在 Ruby China 上连载过几篇翻译的文章，现在终于整理之后发布在 Gitbook 了，更方便阅读，也提供了 ePub，PDF，Mobi 格式下载。

链接： https://www.gitbook.com/book/beansmile-gitbook/playbook-cn/details

欢迎大家多多批评指正。

Playbook 中文版 -- 自动化你的开发环境

leondu — Fri, 28 Oct 2016 09:34:45 +0800

我们依赖编译器、数据库、编程语言、包管理系统、安装程序以及其他关键的程序来进行日常的开发活动。

Laptop 是一个用来设置 Mac OSX 或者 Linux 笔记本用来进行 Rails 开发的脚本程序。安装它应该不用 15 分钟。

使用自动化的配置帮助我们和最新的操作系统和程序保持一致。并且，由于它是标准化的，新的团队成员可以快速加入一个项目，而不用把时间花在从新配置开发机器上。

原文链接

英文原文链接

Playbook 中文版 -- Rails 帮助 web 产品快速推向市场

leondu — Fri, 28 Oct 2016 09:33:32 +0800

从我们的经验来看，使用 Ruby on Rails 框架的团队比使用其他工具的团队可以更快将产品推向市场，并且总体成本更低，因为这个框架以及围绕这个框架的社区拥抱“约定大于配置”的思想。这意味着 Rails 应用的代码库之间看起来很相似，使用 Rails 的团队会发现他们在熟悉的技术领域中，可以将注意力更多放到产品本身而不是和代码搏斗。在敏捷社区和 Ruby 社区之间也有很大的交集，这意味着 Ruby 程序员（除常规之外）更愿意写测试，使用面向对象设计，以及避免重复的代码。

或许我们能够给予 Rails 最大的赞誉莫过于我们在 2005 年就将公司的生死和 Rails 绑定在一起，将公司的未来赌在 Rails 身上，目前我们还活得好好的。

作为回报，我们很自豪能对我们的社区做出贡献，尤其是我们的开源项目，以及我们的Blog GIANT ROBOTS SMASHING INTO OTHER GIANT ROBOTS上的文章。

除了 Ruby 之外，我们使用其他的开源软件和 web 标准例如 HTML, CSS, Javascript，UNIX，Vim 以及 Postgres 因为他们：

高质量
避免锁定特定供应商提供了替换组件的灵活性
可以运行在多种设备上
经过实战考验
当关注的人数众多时 Bug 更少

Ruby on Rails 自带的特性减少了程序员在对抗安全攻击方面的负担，例如：

跨站脚本攻击 (XSS)
跨站域请求伪造 (CSRF)
SQL 注入
头部注入
日志中的敏感数据

Rails 帮助我们正确处理安全问题，但在安全问题上我们依然要用心、多知、并且充分测试。更多信息请参考： Ruby on Rails Security Guide.

我们支持 Internet Explorer 10.0+ 以及最新版本的 Firefox, Chrome 和 Safari。我们不支持 Internet Explorer 6, 7, 8, or 9。这些浏览器正在失去市场份额，他们有安全问题，并且在设计、开发和技术支持上非常耗时。

对于移动设备，我们支持 iOS Safari 7.1+, Android Browser 4.4+,以及最新版本的 Chrome for Android.

在有限的特殊情况下，用户统计表明需要支持老版本的 Internet Explorer。这些特例应该在早期被识别出来，我们会安排额外的时间和费用来支持这个版本。

原文链接

英文原文链接

Playbook 中文版 -- 在移动设备上原生至关重要

leondu — Wed, 19 Oct 2016 09:18:00 +0800

我们的移动开发工程师的经验是基于 Objective-C，最近是 Swift 编程语言以及 iOS 框架，例如 Cocoa.

我们不承接 Titanium or PhoneGap 项目，因为：

费用：对于我们的设计师来说，同时为 iOS 和 Android 平台设计是一个浪费的负担。不同的屏幕尺寸、分辨率、长宽比、期待的用户交互模式这些都需要不同的设计方案。
及时接触到更新：Apple 的 NDA 迫使像 Tianium 这样的第三方应用直到新版 iOS 发布了公开版本之后才能在它之上做开发。但是按照 Apple 推荐的方式来做，我们可以在几个月前提前尝鲜到新版本。我们可以使用新特性让 app 感觉更加现代。我们可以使用新方式来省掉大量的代码和时间。
质量：App 加速器，例如过去的跨平台技术 Adobe Air or Adobe Flash，提供一个最小公分母的用户体验。他们可能会被可能不会被编译成“原生”代码，不过他们几乎不肯能获得“原生”体验。

原文链接

英文原文链接

Playbook 中文版 -- “移动” 是指用户，而非设备

leondu — Wed, 19 Oct 2016 09:16:31 +0800

我们在思考如何设计移动应用时，其中的每一个点都要基于以上原则。让我们思考以下问题：

他们在移动吗？
他们是很放松地躺在沙发上吗？
他们的手指灵活吗？

我们尝试从最可用的平台开始。如果这个设备需要相机、日历或者地址簿，那么一个“原生”应用，例如 iPhone 或者 iPad 应用就是恰当之选了。

对于其他产品，尤其是内容类型的产品，例如文本、图片、视频、以及首屏，那么一个移动 web 应用就更加合理了，因为：

所有现代的智能手机都可以渲染 HTML
Bourbon 和 Neat使得响应式射界变得非常容易实现。
我们可以创建和快速迭代。
我们可以一天发布多个版本。

原文链接

英文原文链接

Playbook 中文版 -- 阶段 5：测试和反馈

leondu — Tue, 18 Oct 2016 08:15:44 +0800

最后，我们采访 5 位用户来验证我们对他们的理解，他们的情境，以及我们的原型。这不是可用性测试。在给他们看原型之前我们会开始一段对话作为采访。

我们的一个设计师会采访每一个用户。我们安排他们在一个房间中进行采访，采访会通过视频和音频直播到观察室，其他的相关人士会在观察室观看、讨论并在得分板上记录答案。

好的问题是开放式的，允许用户讲出故事。

可以告诉我们一次你给公益组织捐款的经历吗？

不要引导用户到你期待的答案上。

如果可以，你是否愿意给一个公校捐款？

不要结束谈话。

上个星期你给某个组织捐过款吗？

如果是新产品，几乎没有团队在第一个 sprint 就能定下来。最有可能的情况是找一些新用户再从发散或者是汇聚那一步开始过一遍。

经过一个或者两个 sprints，一般来说我们会有很多验证后的假设，一个清晰的关键路径，并且可以开始编码构建一个初始版本来面对更广泛的用户。

对于 web 应用，一般我们 4-6 个星期就可以发布第一个版本。对于移动应用，一般我们可以 6-8 周可以借助HockeyApp发布一个 beta 版本，8-10 周左右可以在 App Store 发布。

从上面的时间线可以看出来，多花 2 到 5 天进行第二次甚至是第三次裁剪过的产品设计 sprint 是值得的，否则就可能要多花 4 倍到 10 倍的时间和金钱。

另一个产出是不会产生明显的用户困扰，或者是商业模型非常不清晰，或者是我们以为我们知道的都被证明是错的。做产品设计是一个脑力震荡，但是这是一个成功。节省了时间和金钱。

这个阶段结束之后，我们就有了一个继续前进的计划。

原文链接

英文原文链接

Playbook 中文版 -- 阶段 4：原型

leondu — Tue, 18 Oct 2016 08:14:16 +0800

在召集大家再做一次推销练习之后，在这个阶段将不再会做类似活动。接下来所有的注意力都花在用恰如其当的保真度来制作恰如其分的原型来得到有用的测试结果。

这整个过程中，我们会要求客户在 Google Docs 中书写文案。他们要写真实的文字，而不是占位符，这样可以测试用户的理解程度和热忱。这些文字以后在推特推广、媒体、广告文案、登录页等等都很有用。

当我们的客户不断地沟通和打磨时，我们在埋头苦干做原型。我们不同的设计师会针对不同的项目挑选合适的工具来只做原型：

对于 web 产品原型，一些不错的选项有：

Squarespace templates
Bourbon + Neat + Bitters locally
Invision

对于移动应用，一些不错的选项有：

不要在这个 sprint 中来学习这些工具。在投资时间中熟悉他们。在这个 sprint 中，选一个你已经掌握的工具来使用。

原文链接

英文原文链接

Playbook 中文版 -- 阶段 3：汇聚

leondu — Mon, 17 Oct 2016 12:43:43 +0800

本阶段的活动强制我们停止再创造出新的方案，汇聚最好的方案，并开始为原型写测试。

首先，我们识别最佳方案中的假设。我们列出关于用户动机，商业模式，获取用户，以及我们在预算内完成方案的所有假设。这有助于我们去掉一些选项。

接着我们查看剩下的记事贴和用户流程和用户界面中的冲突：那些用不同方式解决同一个问题的方案。我们去除掉当前不能实现的方案。

接着我们决定我们是要做一个原型（一枪毙命）还是多个原型（殊死战）。多个原型意味着更多的初始工作，不过它可以揭示更多的绝境，帮助我们避免花更多时间在后续的 sprint 上。

然后我们就为每个原型准备故事板。这是一个漫画风格的故事书，其中我们的顾客会走遍关键路径。

最后，我们在 Google Docs 创建测试脚本，并在观察室的墙上放置得分板。脚本基于故事板创建，而得分板则被用来记录测试的结果。这会让我们尝试了解的对象更加地清楚和具体。

原文链接

英文原文链接

Playbook 中文版 -- 阶段 2：发散

leondu — Mon, 17 Oct 2016 12:42:39 +0800

在本阶段中，我们会用尽我们的想象力来想出潜在的解决方案来满足用户的需求。

在这个阶段之前，我们的团队一般会在房间走动，查看墙上覆盖满满的关键路径和告示贴卡片。

我们重来一次“推销练习”，和关键路径做对比。

接着我们让每个人画出 10 个以上的用户流程和用户界面。我们让大家把用户来源包含在内：Twitter? 博客文章？AdWords? 自动推荐？Drip email? 朋友推荐？推送通知？

如果产品被开发出来，这些来源最终会被Google Analytics’ “Acquisition Channels” report: 来衡量。

我们把这些草图贴到墙上并开始一轮沉默评判，观察并在流程和用户界面的各个位置放置“点数贴纸”，这有助于我们可视化地识别最佳创意。

接着我们进行小组评判。每一组解释他们的点数。作者可以补充额外的评论。我们在这个阶段不会否定或者筛选。这个投票过程可以让我们规避冗长的讨论，并做到群体设计。

最后，我们会使用一个大一点的红色点数贴纸进行“超级投票”。CEO 或者产品所有者在他们认为最好的创意上放一个“超级投票”。这有助于我们识别出他们的组织是如何做决定的以及确定他们的终极权威是谁。

我们的经验表明这个阶段是非常耗费脑力的。我们建议早点结束让大家回家好好充电。

原文链接

英文原文链接

Playbook 中文版 -- 阶段 1：理解

leondu — Fri, 14 Oct 2016 08:03:55 +0800

我们在这个阶段中的努力帮助我们理解用户的生活（消费软件）或者工作（商业软件）的需求，并产生共鸣。

这个阶段，人们常常在告示贴上记下笔记，并贴在房间的墙上。

我们以“推销练习”开始，客户像在向投资人推销他们的产品一样来讲解产品。这帮助我们识别用户，他们的问题，以及他们希望产品达到的功用。同时开始记录该领域的术语表。

接着我们查阅来自 Quora, Analytics, AdWords Keyword Planner, 访谈和调查问卷中的资料。这帮助我们理解用户的动机，市场漏斗，以及目标市场的规模。

最后，我们绘制出这个 sprint 接下来要关注的事项：软件的关键路径。这时，我们尝试尽可能少考虑实现细节，保持在一个高的层面来考虑。一个有助于创建关键路径的问题是：

用户拿这个产品来干什么？

在后续的阶段中，在进展中我们会编辑关键路径。

原文链接

英文原文链接

扫描关注乐豆说公众号可以获得文章更新推送：

Playbook 中文版 -- 阶段 0：准备

leondu — Fri, 14 Oct 2016 08:00:25 +0800

在这个 sprint 之前，我们的客户安排 5 个真实人员在我们最后一个阶段进行测试。毕竟他们比我们更懂他们的用户。

他们也从以下来源获取数据：

我们也会做一些（付费的）准备工作：

准备和进行用户面谈
进行一次简短调研，结果会在阶段 1 中使用。

通常我们会在第一天订早餐来让它觉得特别点，但是在这个 sprint 中，我们不订午餐。在这个 sprint，以及平时，我们认为不要进行“工作午餐”这事儿很重要。取而代之的是暂时从工作中抽身出来休息下大脑，或者呼吸下新鲜空气，和队友还有客户进行互动。

原文链接

英文原文链接

扫描关注乐豆说公众号可以获得文章更新推送：

Playbook 中文 -- 产品设计 Sprints 概述

leondu — Thu, 13 Oct 2016 08:31:36 +0800

产品设计阶段，通常是大家非常容易忽视的部分。我们见过太多头脑一热就匆匆开始的项目，这些项目的结果也不会太好。经过产品设计并不能保证你的产品必然成功，创造一个产品本身就是一个概率事件，经过认真设计和思考的产品，成功的概率要大很多。

再次提醒点击打开原文链接查看原文，其中有 Paul Graham 一篇很有参考意义的文章。

以下是翻译正文：

”大多数人误解设计是看起来是什么样子。人们认为它只是装饰—人们递给设计师一个箱子说，’把它弄的漂亮点！’。我们不这么想，设计不仅仅是看起来和摸起来的感受。设计是产品是如何工作的“ — 史蒂夫.乔布斯

产品设计 Sprints，是 Google Ventures’ design team 的发明，通过 5 个阶段的活动来更好地创造人们真正想要的产品。我们在开始真正昂贵的构建之前，先把虚假的自信变成验证后的自信。甚至，我们会发现根本不需要开始这个昂贵的构建。

Sprints 对于开始新项目和解决已有项目问题是同样有用的。通常需要 5 天左右，不过我们也有用少于 5 天时间完成过。我们会尽可能多地安排相关各方以及专家在同一个房间内参与活动。

产品设计 sprints 是测试驱动的。

英文原文

原文链接

Playbook 中文 -- 这是我们的 playbook

leondu — Wed, 12 Oct 2016 10:06:24 +0800

thoughtbot 是谁？

这是一家总部位于波士顿，在美国和伦敦有多个办公室的团队。他们有 10 多年的历史，他们开发自己的产品，也帮助客户（尤其是创业团队）不断获得成功。 Our San Francisco-based clients have raised more than $2 billion in venture capital, and today employ more than 5,000 people.

相信来自 Ruby、Rails 圈的开发人员没有不知道 thoughtbot 的，或者你不经意地用了他们开源的 factory_girls，shoulda，paperclip... 或者读过《Rails AntiPatterns》。

另外如果你用过 Hound，或者是最近的 FormKeep，那么你也是他家产品的用户。

下面就是 playbook 的中文翻译版连载，我们尽量做到翻译准确，有些实在是太过于常见而又没有很好的中文对应翻译的，我们就选择... 不翻译了 :D 下面进入正题：

我们和各种规模的团队合作，在 iOS、Android 和 Web 平台上设计、开发并推广他们的产品。

这是我们的 playbook

我们是thoughtbot..我们和世界各地的上百个产品团队合作过，他们中既有自筹资金的个人创业者，也有庞大的跨国公司。我们也创建了自己的产品，同时有若干个开源项目。

这是我们的 playbook。它解释了我们是如何创建成功的 Web 和移动产品，以及我们是如何运营公司的。书中充满了我们自身的经验以及研究其他团队的心得。

这是一份鲜活的文档，它位于 thoughtbot 的私有 Github repo 中，团队的每个成员都可以编辑它。

我们使用自由的 Creative Commons Attribution-NonCommercial 协议来分发这份文档，你可以学习或者在自己的公司运用我们的策略。虽然这些策略对我们有用，但是哪些工具和技术适合你自己的情况，相信你比我们更清楚。

产品设计 Sprint

我们的项目是设计导向的，从告示贴和草图开始，到设计以及代码实现为终结。我们使用设计 Sprint 和用户调查来理解我们客户的问题，验证关于产品的假设，从而构建以用户为中心的产品

介绍产品设计 Sprint

阶段 0：准备
阶段 1：理解
阶段 2：发散
阶段 3：汇聚
阶段 4：原型
阶段 5：测试和了解

选择平台

在产品的早期阶段，我们必须确定要使用的平台。选择哪个平台取决于我们对于解决用户问题的解决方案。当充分为用户考虑之后，对于我们而言，最佳的工具要有一个活跃的社区，让我们用起来开心，并且有助于我们创建及快速迭代产品。

“移动”是指用户，而不是设备
对于移动设备来说，原生应用很重要
Rails 可以帮助产品快速面世

笔记本设置

你的笔记本就是你的剑。不要上战场时忘记了带武器。

自动化你的开发环境
使用 dotfiles 来分享设置
使用可扩展的编辑器

计划

我们工作流程的一个主要目标是持续发布可以工作的小版本。我们通过频繁沟通和每周迭代来达到这一目标。

流程要因产品和团队而定
每日站立会议可以建立信任和保持动量
没有什么比面对面沟通更有效
使用轻量级流程来管理优先级和使得流程可视化
每周会面来讨论成果、错误和未来计划
一个高效的远程团队不是偶然的产物

设计

我们的项目常常是快速变动的。设计师要采用对应的工具和流程来应对这种情况。

总是带这个速写板
测试产品的可行性和可用性
什么是交互设计？
什么是用户界面设计？
什么是视觉设计？
使用 HTML 和 CSS 做线框图

开发

我们开发实践主要参考 Kent Beck 经典的Extreme Programming Explained: Embrace Change 以及 Gerald Weinberg 的The Psychology of Computer Programming. 我们尝试后发现，在大多数情况下使用其中大多数的原则改善了我们的工作质量，并提升了我们团队的幸福感。

验收测试
代码审查
持续集成
结对编程
重构
代码风格
测试驱动开发
版本管理

生产环境

我们生活在一个魔幻的新纪元，我们的很多问题都已经有了解决方案。我们尽可能地聚焦在产品的核心，尽量将可以分发出去的操作交给外部服务来做。

域名和 DNS
错误追踪
主机托管
Log 收集
交易处理
性能监控
产品清单
SSL 证书
事务性邮件

度量

度量的难点在于决定要追踪什么。Dave McClure 的 AARRR 框架提供了一个重要指标的总览。我们使用事件追踪等技巧来测量这些指标。

AARRR 框架
A/B 测试
功能旗标
测量
订阅量度量

我们的公司

我们相信可以不断找到更好的工作方式，我们期待可以找到它并和尽可能多的人分享。

招聘
运营
原则
销售
分享
时间

原文链接

英文原文链接

It's time to talk!

leondu — Wed, 12 Oct 2016 10:02:59 +0800

beansmile

事情要从 beansmile 说起。

2010 年的时候，两个 Ruby 粉走到了一起，创建了一个叫做beansmile 的团队（请忽视下图中左边的小胡子和右边的发型）。

6 年过去了，他们变成了下图中的模样：

团队也变成了这样（感谢亲友团助威）：

beantalk

在这几年里，我们和小伙伴们为北美、欧洲和澳洲的客户完成了电商、社交、媒体、数据可视化、移动 App 等上百个项目，近两年也开始和国内的一些优秀的创业者们一起合作，共同打造有价值的产品。

在完成商业项目的同时，我们也始终不忘初心，不断总结和分享我们在技术、团队、创业等方面的所思所想，我们的团队 Blog 积累了很多各种类型的文章，同时我们也在 GZRuby、珠三角技术沙龙、RubyConf China、还有 RubyConf TaiWan 等等技术大会都有分享和参与。

所以我们用业余时间搭建了 beantalk 这个平台，会在这里整理我们过往的一些经验和积累，记录我们前行的脚步，也会分享我们认为有价值的内容。更新的内容会在 beantalk.net 网站和“乐豆说”这个公众号上同步发布，

Next

接下来的一周多时间。首先会在这里连载 thoughtbot 公司的《playbook》中文翻译版作为开端。从产品设计、开发流程、团队等等各个环节，看看一个做得好的咨询团队是如何工作的。

这里没有什么宏大的目标，没有 KPI，也不需要喧嚣和热闹，希望和有着同样追求的你一起携手前行，守望相助。

It’s time to talk.

扫描二维码关注 beantalk 公众号（乐豆说）

焕然一新的讲稿网

leondu — Tue, 17 May 2016 12:00:37 +0800

焕然一新的讲稿网

几个月前我发过一个帖子，说我们重启了讲稿网项目，一个为活动提供讲稿托管的网站。几个月过去了，现在终于可以跟大家报告一下进展，大家可以点击打开一个全新的讲稿网 www.jianggaowang.com了。

更新动态

新的设计。包括对移动设备和各种屏幕的适配
注册功能。为了保证上传内容的质量，目前针对活动组织者开放，大家注册后和我们会联系确认，通过后可以创建活动和上传讲稿。
音频上传。在上传讲稿时可以同时上传录音，做到音画同时呈现，传递更大的信息量。
现有讲稿。已经上传了包括珠三角技术沙龙、前端大会、广州线下技术交流等多个活动的讲稿。

Desktop

Mobile

欢迎加入

如果你是活动组织者，欢迎点击注册，我们会尽快和你联系并开通上传权限。

如果你是开发人员，欢迎来clone 代码并贡献改进。讲稿网基于 Ruby on Rails 开发，欢迎大家一起来挑毛病找不同。

如果你是一般用户，有什么意见和反馈，欢迎提交 issue。

感谢团队的小伙伴们在忙客户项目的同时，还为社区开源项目贡献力量，给讲稿网换上了新衣服。

解决大家看讲稿的问题 ---再度萌芽的讲稿网

leondu — Mon, 28 Dec 2015 12:51:21 +0800

现在的技术大会越来越多，每次参会的讲师都会为自己的主题准备讲稿。对于参会人员来说，有一些比较感兴趣的主题总有一种意犹未尽的感觉，总想再重新对着讲稿温故一下。对于讲师来说，也想把自己的讲稿分享出来。

目前国内都没有一个基于活动分享讲稿的平台。每次都需要跑到国外的网站上去分享，可是国外的这些网站基本上都被墙了，每次访问都非常的缓慢，而且也不能分享到微博，微信等平台上。

身为程序员的 Martin 表示不服，想想为什么不能自己来搭建这样的一个平台了，说干就干，利用七牛云的 PDF 转换接口开发了讲稿网这个网站。但是七牛后来把这个接口给封了，一度很长时间都无法上传讲稿。

现在我们利用一些技术手段又把这个问题给修复了，讲稿网 (www.jianggaowang.com)又复活啦！

我们自己收集了之前一些活动的讲稿：

RubyConf China 2015 GZRUBY 第 24 次聚会活动总结 GZRUBY 第 26 次聚会 [微信开发专场] Techparty-广州 10 月 31 日 Docker 专场沙龙活动总结 Techparty-广州 8 月微信开发专题沙龙 Techparty-深圳 8 月创客与智能硬件专题沙龙 UPYUN • 架构与运维大会 [北京站] UPYUN • 架构与运维大会 [上海站] [深圳] UPYUN 架构与运维大会

以上讲稿是从 https://ruby-china.org/ http://techparty.org/ http://opentalk.upyun.com/show/issues 等地方收集过来的。讲稿网本身也是个开源项目，如果对讲稿有保留的，请联系我们，我们会采取措施移除或屏蔽相关内容。

目前的讲稿网还是以浏览讲稿为主，我们正在为它增加更多功能，稍后会开放注册，有兴趣的朋友可以发送邮件到：kevin@beansmile.com 申请内测。另外，讲稿网是一个开源项目，如果你也想加入到开发中来动手为它增加功能，欢迎 fork 并提交 Pull Request！ github 地址：https://github.com/beansmile/jianggaowang

新版的设计也已经做好了，我们尤其欢迎前端的同学加入来实现一个更美观的讲稿网！

ps，原文可见 Blog： http://beansmile.com/blog/posts/jianggaowang-com-reborn

为什么要参加 RubyConf China

leondu — Mon, 12 Oct 2015 09:32:38 +0800

昨天在会议间歇的午餐时，同事抛出这么一个问题，现在有那么丰富的文档、视频教程，也有很活跃的 Ruby China 论坛，那为什么还要千里迢迢（我们来自广州，还算是得了地利的）参加 RubyConf China？当时由于人多加上时间原因，当时只是给出了一个比较仓促的回答。昨晚返程一路在思考线下聚会的意义，早上借助一杯咖啡的动力，在懒癌发作之前挥笔写下自己的感触。

其实我们可以问另一个问题，现在也已经有很好的音乐 App，视频网站，你为什么还会买票去听一次现场演唱会？现在也有很好的转播机制，各种角度慢放加解说，你为什么会买票去看一场广州恒大的比赛？答案也很简单，参加演唱会是为了和自己的偶像近距离接触，现场看比赛是和同好们一起为心爱的球队加油助威，总结成三个字，就是『现场感』。

所以参加 RubyConf China 的理由也非常简单了，第一能够和国内 Ruby 界活跃的大牛们近距离接触，和我们圈子里的明星们面对面，看看他们是怎么回顾自己的技术成长之路，看看他们是如何抽丝剥茧地解决一个技术问题。这些现场的感觉，Raw 的感觉是你在网上读一篇四平八稳的技术文章时无法直接感触到的，以 Ruby China 的管理员们为例，华顺的不羁，国宁的随和亲切，Rei 的『偏执』，绝对是现场感十足。接触下来大家就会发现，论坛中的大牛、明星也是活生生有血有肉的平凡人，他们也有自己人微言轻的时候，也有发展中的苦恼，也有事业的波折，是不是一下子感觉更加亲近了，更进一步，是不是感觉原来大牛都是这么从小牛甚至不牛过来的，只要方法对头加坚持努力，有一天我也会成为小牛和大牛。

讲师合影

另外一个理由就是同好之间的交流，喜欢同一个明星，同一个球队的人，往往更加有共同语言。喜欢 Ruby 的程序员，品位通常差不到哪里，证据之一就是 Ruby 社区的各种网站都是开源社区中最漂亮的，今年华顺和 Rain 也分别给大家展示了为什么不会设计的程序员不是一个好厨师。程序员本身是一种比较奇怪的生物，他们聪明绝顶但是多数缺乏沟通技巧，在现实生活中他们既渴望交流又羞于开口，或者一开口就是大实话，还不如不开口，具体可以参考 TBBT 中的四位帅哥（其实是在说你 —>Sheldon）。但在 RubyConf 会场上，经过 Ruby 这么优雅的语言筛选过的，应该是趣味相投的一伙人，因此大家除了听各个精彩的 Topic 之外，在茶歇，撸串，夜聊中尽情畅谈，技术交流，合作机会，种种黑科技，厂厂黑历史，黑黑更持久，吐吐更健康。参加 Conf，如果只是呆坐在会场记笔记，把 Conf 硬生生变成了大学时期的阶梯教室，那么你就错失太多精彩了。

仰望星空的 Rubyist 们

正文结束，ps 一下，除了以上的『现场感』，如果你参加了几届 Conf，你会观察到『趋势』。什么叫做『趋势』呢？2012 年的时候举办 RubyConf China，场地一波三折，赞助费也是几经折腾，查看页面源代码找到赞助链接捐款的事情我是不会说的，哈哈。从那时的局促到现在 28 家赞助商的红火，大家看到的是 Ruby 社区在国内的蓬勃发展，程序员成为争抢的对象，作为一名老兵，『我很欣慰』（德云社版权所有）。

另一个趋势是技术层面的，这届大会大家越来越多地提到前后端分离、API 设计，不完全统计 FreeWheel、Beansmile、GitCafe 吴江、Strikingly、大疆等等的 Topic 都涉及到了这个领域。面对前端技术的繁荣发展带来的架构上的挑战，Ruby 界的当家花旦 Rails 如何应对，虽然在 Rails 5 中引入了 Rails API，但是否已经能够应对这种挑战，我抛个砖头，期待大家的精彩讨论。

再 pps 一下，回到『现场感』上，双十当晚的撸串之夜，浑身上下都敏感的投影仪遥控器，临近结束抽奖时的人肉电信 DDoS，你不在现场，又怎么发出会心的笑声？所以关注 Ruby China 上的讨论，加入下一届的 RubyConf China，一起到现场 Rock 吧！

最后是我们团队在 RubyConf 2015 Shenzhen 的照片，想要加入我们一起参加 Conf 的小伙伴请邮件过来 leon@beansmile.com 发份简历不费电，谢谢 :D

[2015年07月22日] GZRUBY 第 26 次聚会活动总结

leondu — Wed, 05 Aug 2015 22:59:20 +0800

广州的 Rubyist 们，7 月份的总结来了！

7 月 22 日我们在广州市海珠区的 T.I.T 创意园里的 CCIC 联合文创前厅举办了 GZRUBY 的第 26 次聚会，以下是本次活动的总结：

1. 邓怀涛 - 《Ruby 与微信开发那些事》

首先是由邓怀涛带来的微信开发那些事儿，邓怀涛是一系列流行的微信开发 gem 的作者，例如 weixin_rails_middleware 和 weixin_authorize等等。这些 gem 在国内有不少的使用者，包括一些已经初具规模的公司，有着广泛的影响。

邓怀涛的演讲中主要介绍了微信相关的系列 gem，以及做这一系列开源 gem 的初衷。同时他也分享了在做开源项目的一些感受，例如一个人维护代码库的辛苦，命名 gem 时（weixin_authorize）的纠结，由于时间和精力的限制导致的测试不够完备和文档不完备的问题。当然也少不了针对微信开发平台的吐槽，例如客服不专业，回答问题永远回答不到点上。文档往往成为"文挡"，不是敲门砖，而是拦路虎等等。我们也期待大家能够一起动手来维护和完善这些开源项目，众人拾柴火焰高，一起把微信开发的生态圈活跃起来。

2. Rain Chen - 《友约 v0.4 的开发经验总结 for gzruby》

接下来的主题是两个当红技术的结合，当微信开发平台遇到炙手可热的 React 之后，会擦出怎样的火花？Rain Chen是Beansmile团队 CTO，专注 Web 开发已有十余年经验。最近 Beansmile 在自己的内部项目友约中尝试了使用 React 进行微信开发，这次分享就是开发过程中的经验总结。

Rain 首先介绍了友约项目的由来，为什么要打造一款基于微信平台的朋友聚会签到工具。接下来的技术部分，主要讲到了微信平台的一些限制，例如只有备案之后才能在分享到朋友圈的页面执行 js 代码，非常见的 *.so 域名不能通过校验，如果说天朝已经是 Hell 模式，某种意义上微信平台是 Hell+ 模式。此外看起来很美的模板消息在使用起来时也是诸多限制。除了和上面邓怀涛提到的一样的文档不清晰问题之外，Rain 还着重探讨了如何调试微信平台应用。

和 React 结合部分，Rain 重点提到了自定义的 Img 这个 component 以及为此开发的一个 gem react-rails-img，欢迎 Ruby 党使用。此外 Rain 还探讨了 form field 默认值问题 (数据双向绑定) 以及 component 之间的通讯问题，详细内容可以从文末的讲稿下载链接中获取。

ps，图中有彩蛋

3. 杜小龙 [aka Kevin Du] - 《关于微信开发的一些思考》

Kevin 是Beansmile团队的产品经理，目前负责团队内部的"班级助手"项目开发。班级助手是一款基于微信的通知工具，Kevin 在打磨这款产品的时候，也对微信开放平台上适合做什么产品，适合什么样的场景做了深入的思考。

Kevin 的分享主要讲述了订阅号、服务号、企业号的不同，这些不同和限制分别会引导用户怎样使用基于微信平台开发出来的应用。对于订阅号，更多的是运营的需要，以内容来支撑。对于服务号，更多的是以推送功能为主，以推送消息触发用户使用。而企业号则是企业内部沟通的平台，但是企业号面临的挑战是工作生活分不开，这样会对部分用户产生干扰，毕竟微信的口号是一种"生活"方式，工作的内容掺杂进来是否合适，这是个值得探讨的话题。

延伸阅读：《微信会取代哪些 app？》

4. 校寻团队 - 《校寻互联网推广》

这是 GZRuby 为数不多的非技术性话题，以前 GZRuby 关注纯技术内容比较多，这次由校寻团队带来的推广案例也让大家得以管窥项目落地推广的流程，并能够对推广（尤其是校园推广）的成本有个大致的了解。

校寻团队的介绍从"小猪导航"这样的具体案例入手，说明即便是技术没有压倒性的优势，凭借着敏锐的市场嗅觉和良好的推广效果，还是能在市场上占据一席之地。接下来的推广方式介绍中，特别对比了扫楼、摆摊、社团、网络以及微信公众号等方式的投入产出比，相信对大家以后的产品推广有一定的借鉴意义。

放一些现场照片

小结和预告

本次活动的讲稿可以从这里下载，下次 GZRuby 的活动和本月的RailsGirls活动合办，希望大家踊跃报名，帮助女性朋友进入到程序开发的美妙世界！

[广州] 招聘 Ruby/Rails 开发人员

leondu — Sat, 05 Jan 2013 18:08:12 +0800

公司信息

公司名称：Beansmile 公司地址：广州市海珠区新港中路影城花园 C 座 2407 室 (客村地铁站 C 出口）联系方式：leon@beansmile.com 公司简介：Beansmile http://beansmile.com/ 是一家主要从事 Web 开发的软件公司，客户主要在欧洲和美国，项目类型包括电子商务、社交网络以及企业管理系统等。

招聘职位

Web 开发（初级）

薪资范围：3-5k

基本要求

熟悉并至少使用一门编程语言进行过 Web 开发，语言不限
了解一种数据库
了解 Linux 基本操作

加分项

了解 Ruby，Python，Coffeescript 任意一种
了解 Rails
有 github 帐号
有独立的技术 blog

Web 开发（中级）

薪资范围：5-8k

基本要求

1 年以上 Rails 开发经验
熟悉 Javascript，熟悉 jQuery 等框架
熟悉 git
熟悉 Linux，能够独立部署 Rails 应用

加分项

有 github 帐号
有独立的技术 blog
参与过开源项目并贡献代码

leondu (Leon Du)

送书 ---《Rails 5 敏捷开发》

《Thoughtbot Playbook》 中文版

Playbook 中文版 -- 自动化你的开发环境

Playbook 中文版 -- Rails 帮助 web 产品快速推向市场

Playbook 中文版 -- 在移动设备上原生至关重要

Playbook 中文版 -- “移动” 是指用户，而非设备

Playbook 中文版 -- 阶段 5：测试和反馈

Playbook 中文版 -- 阶段 4：原型

Playbook 中文版 -- 阶段 3：汇聚

Playbook 中文版 -- 阶段 2：发散

Playbook 中文版 -- 阶段 1： 理解

Playbook 中文版 -- 阶段 0： 准备

Playbook 中文 -- 产品设计 Sprints 概述

Playbook 中文 -- 这是我们的 playbook

It's time to talk!

焕然一新的讲稿网

焕然一新的讲稿网

更新动态

欢迎加入

解决大家看讲稿的问题 ---再度萌芽的讲稿网

为什么要参加 RubyConf China

[2015年07月22日] GZRUBY 第 26 次聚会活动总结

1. 邓怀涛 - 《Ruby 与微信开发那些事》

2. Rain Chen - 《友约 v0.4 的开发经验总结 for gzruby》

3. 杜小龙 [aka Kevin Du] - 《关于微信开发的一些思考》

4. 校寻团队 - 《校寻互联网推广》

小结和预告

[广州] 招聘 Ruby/Rails 开发人员

公司信息

招聘职位

Web 开发（初级）

Web 开发（中级）

地理位置

办公室

《Thoughtbot Playbook》中文版

Playbook 中文版 -- 阶段 1：理解

Playbook 中文版 -- 阶段 0：准备