xdite

無編程經驗的新手，如何在四周開發實戰等級產品 (長文)

xdite — Fri, 16 Sep 2016 13:59:12 +0800

本篇文章原载于我的博客：http://blog.xdite.net/posts/2016/09/16/newbie-with-no-experience-programming

分享一下最近两个月的教学生活与体悟。＝＝＝＝＝

昨天是中秋节，也是我们全栈班的最后一天。全班大多数同学都更新了自己的心得，我自己也决定来更新自己的结业心得。

我过去几个月都没有更新博客，有一些人应该纳闷，我干嘛去了？

这两个月呢？我把台湾的班都停了。跑去北京搞新生大学全栈营去了。

全栈营的起因是这样：李笑来老师，某天在网路上发了一个感悟「一年可以成长为全栈工程师」。但莫名其妙的这句话，就在大陆被黑出了翔。

在我这个外人看起来很莫名其妙的原因，其实是因为在矽谷呢，说这句话根本没多少人会大惊小怪，甚至是把你黑出翔，但在中国莫名其妙的就变成了政治不正确。

随便找了一下 Quora，看到这种题目也没被战....大家还积极讨论？ How can I be a full stack web developer in one year?

全栈工程师的定义，以及所需成长时间

一年可不可以成长为全栈工程师？可以！如果你找到够好的前辈带你，以及在够好的实战环境，肯定可以。
再来是「全栈」，有没有一个定义？ - 是在前端、后端、CSS、机器调效都练到大牛等级？ - 还是在创业公司，可以一个人全搞定这些，产品还可以快速前进？ - 还是心中想开发一个产品，可以自己一人从零到有生出来顺利上线？

好吧。如果我们先不管这些。

若求「一组无经验新手，是否可以在八周之内搞出一个实战等级产品并上线」，这件事何以可行？

许多人也许觉得「现实世界不可能发生」。但就我以前带产品以及带徒弟的经验，我却认为「这应该是有可能的」。（注意，这里是讲「应该有可能」）

快速带出职业选手，本身就是业界常态

我本身在业界多年，我是知道这几件事的事实存在：

几乎稍微成熟的 Rails 公司是有带徒弟的套路的。（你不可能招一个零经验新手，手把手教三个月，才能跟资深程序员一起写，许多公司如 Facebook 甚至有新人 Bootcamp）
所有的互联网产品，其实都是有开发流程套路的。只是依不同公司的开发团队资质，需时从 2 个月到 9 个月。
很多厉害的 developer，本身不是计算机本科出身的，公司一样带的起来...

所以，理论上、理论上，如果找到「学习上的瓶颈」「开发上的瓶颈」的相关答案的话。理论上、理论上，应该有一套方法，可以让这件事（「一组无经验新手，在八周之内学会编程，并搞出一个实战等级产品上线」）发生。

我自寸已经知道这其中大多数问题的答案。问题是：我真没试过，是不是能够把这些答案组起来，放到一个团队，按照这样流程跑，就能达到同样的效果？而且，即便这应该是可行的，可真没人相信我。

况且，这世界不存在这样的公司，也不存在这样的团队与机会。

如果我说要开个班说能办到这事呢，估计许多人都会认为这是大忽悠。

全栈营其实是一场教学上的实验

这个机会起源于：当时在 Twitter 上，当所有人都在骂李老师时，只有我无心的回一句，我认为绝对是可以的（因为这在西方世界很正常嘛）。

所以李老师就把我叫去北京了解看看，这到底要怎么搞？毕竟这事要是干成了。就是编程教学的一大突破。

而我当然是一口答应这个机会的。因为：

四周内培养职业 Rails 工程师，能独立开发个人产品。这事肯定是能干成的。我在台湾这样的班就办了快十期。
其余关于做产品所需的相关知识与坑，这几年来我做了深入的研究。在我的心中反正是这样想，我已经离所有的答案都只差最后一步了，只差有人自愿让我做实验而已。

能有人帮我推最后一哩路，我当然是极其开心的。

最后我就接下这个挑战的任务，甚至还跟李老师大胆的说：

我不需要三个月，我只需要两个月。

（估计那时候脑子应该是烧坏的）

但是，我想先在这里先跟大家透露最后的结论：

其实不需要八周，只需要七周。。。。。。。。。。。

我是如何设计课程的

全栈营的课程表，这样说吧，真是写好玩的。这个营，在课表上列的知识都会教，只是绝对不是按照课表上的进度走。这个课表只是为了「政治正确」写的。

这个营真正的课表是这样的：

前三周，新兵基础训练（我有一套特制的教材保证打底，至于运作原理，那就不在这篇文章范畴之内，改天再提）。这段期间，同学会开发好几个「个人」项目，确保自己最少有办法做到独立的开发。
后五周，团体协作训练。同学要自己想办法想出有趣的产品，制作 Landing Page，利用 Landing Page 招募至少四个同学一起实作，然后用课堂上教的专案管理技巧，小组进行敏捷开发实作。最后呢，再利用 Onboarding 技巧收尾。

我压根就不走也不信全世界培训班都在做的那一千零一套（也就是上课花了大把时间教基础知识，毕业前两三周再做一个玩具 project）。这个班，我就打算走我研究认为有效的那一套，而且要做结业 project 就是全玩真的。

而且，我是开学第一天，才跟班上同学说，上课贴的课表都是假的。不算数，我走的是这一套。他们都懵了。（毕竟学费不是小数目）

这帮学生远超过大家的想像

前三周的进度，我是非常有把握的。我在台湾就已经能够这样干，一点都不担心。

但后五周的设计，其实我是完全没把握的，哈哈 XD

我只是猜「应该可以吧......」，就这样干了，但不行也得搞看看。所以我就真的这样做了....

猜猜到第七周学生跟我抱怨什么？

「老师我们把项目已经做完了，下周要做什么？」

老师，我觉得班上毕业气氛太早了，不太好」

……这也太狂了。我压根没想过他们能够提前做完，还提前一个礼拜！！搞得我最后一周，只好临时去写一些投影片垫档讲课 -_-|||

学生作品 1:

人才火箭 http://talent-rocket.herokuapp.com

学生作品 2

HackSchool https://hackschool.herokuapp.com

学生作品 3

GrowthHackCN http://growthhackcn.herokuapp.com

学生作品 4

约霸 http://online-ask.herokuapp.com （留学咨询项目）

2 天 Hackathon 作品

在毕业那一周，同学还干了一件更疯狂的事：两天 hackathon 又搞一个真实产品出来（含 landing page 与 onboarding）。

浓缩书：http://nongsuoshu.herokuapp.com/ ( by 人才火箭队组员）

你说这帮同学，两个月前没人会写代码（20 人内只有 3 人有过去编程经验），谁相信？

我真不怪其他人不相信，因为是我也不相信！但他妈的他们做到了！

全栈营教了什么

（基础期）基于认知心理学的编程学习法与正确的自学法。可以快速上手 Rails API，并独立
如何做 Landing Page
如何写 User Story，以及 run Standup Meeting 以及优先权排序
每天的收尾会议（仿 thoughbot 内部流程）。
每周的 Retrospetive Meeting
如何写干净的代码以及设计架构
如何做 Onboarding（如何让 RD 等级的「尸体级」产品，变成运营等级「活人」产品）
仿 Hackathon 的散弹枪开发法

读到这里，读者们如果识货（有做过编程工作），应该知道这是什么样等级的训练。其实甚至我都害怕他们承受不了这样高强度的技巧与操练。结果....

让我觉得果然教编程还是要教新手，新手没玩过这些东西就不知道害怕....

（P.S. 给没有做过编程开发的读者一些背景知识，这是有靠谱 V.P. of Engineering 的 A 级团队内部才能够这样高效的做产品，可以理解成为我在给新手吃人参）

为什么要这样教？

我自己也相当不认可一般培训营里面的课表设计，我认为那些课表是相当不靠谱的，一般人根本就记不住那些无聊知识。花了三个月只做出一个玩具，这是在浪费人的生命。
许多培训班的教学方法，是仿大学工业教育设计课表，只因为大家普遍认为大学这样教，竟然社会上就得这样教。问题是这根本不是业界培养开发者最有效的方式（社会上是师徒制以及做真 project 的带练）。既然这个方法不有效，为什么要这样教？
培训班不教真实的场景以及解题思路，以至于培训班学员毕业了以后，适应困难。社会上许多人对于培训班学员有几个印象 - 1) 没有办法按照真实需求，独立作业，脱离了培训之后就失忆 - 2) 在业界真实协作感到困难 - 3) 这些培训班学员之前没有计算机底子，所以自学远比野生程序员更慢...

种种原因造成了很多人听到求职者是培训班学员，就退避三舍。

所以我非常想照自己的思路，设计一个：我自认非常有效的学习途径（起码这条路上学的都是业界实务），培养真的社会上所需要的「容易合作以及善自学的好程序员」。而不仅仅是「只能够 CRUD。。。。。」。

为什么挑选这些题目教？

在台湾我做了快十期班，也成功带出很多程序员。其实我的教法已经非常有效率。

但是呢，我却发现一件事，这些班下来，我仅仅能教出能够独立「写功能」的程序员。

但是我教不出「能够做出有灵魂产品」的程序员。

所谓「有灵魂产品」的程序员：指的是他们做的产品一上线，就已经是打磨过的产品，而不是「只有功能，但却没人知道怎么使用的尸体」。也不是只会做功能，还要找运营、行销来回吵架产品一直搞不上线的程序员。

别说「能够做出有灵魂产品」的程序员了。因为很多时候，产品准时上线都相当困难。

在这个业界，捡到一个能够达到这样要求的程序员就是宝了。

所以，我一直在想，这样的人能不能够量产。我想要帮世界量产，这世界需要更多这样的「全栈程序员」。会项目管理，会做运营的程序员。。。。

这个班就是这样的实验。

我很幸运的，实验如我想像的成功，而且比我想像的还要成功（提前一周做完）。

如何在四周开发实战等级产品

其实我一直在挣扎，我要不要把这些秘笈公开出来。考量的点有几个：

一旦公开出来，应该就会有竞争者抄我怎么做。毕竟我在运营一个教学事业。
但是如果不公开出来？这世界明明就应该运营的更有效率，而且很缺程序员。连我自己都希望业界有大量的这样等级的程序员可以招。不写出来我内心始终觉得哪里很怪....

想了很久，最后决定还是把这个秘方写出来。我想至少至少，这套秘笈，可以让许多正在做产品的团队，加速内部产品开发的速度以及少走很多冤枉路。

做产品的步骤 Step 1: 做 Landing Page 吸引用户

五周的第一周第一天，我教 Landing Page 制作（以前在 GrowthHack 班有教）。

之所以为什么一开始教 Landing Page 而不是项目管理。是因为我以前在做产品时，发现一件事，很多程序员或创业者，做产品时往往都是一头热的就栽进去写 code，快上线了就...

直接上线，但是用户不会用，直接阵亡。（此称「尸体级」产品）
请营销搞了一个 Landing Page。但是营销写的文案与产品内装，差太远。营销认知的「产品价值」，与程序员写出的「产品功能」差得太远。首页文案变成诡异的四不像。

所以：

既然是要做有意义的产品。那不就得在第一天就要搞清楚自己能够 Offer 使用者的价值吗？
以清楚的价值观出发的产品，功能方向开发不是才不会歪吗？
如果连 Landing Page 都做不出来，表示自己根本不清楚这个产品的价值与这个市场的痛点？如果根本吸引不到用户使用，甚至队友一起开发？那么学敏捷，高效开发出一个垃圾有何意义？

学生必须先制作一个 Landing Page，成功吸引同学这是一个诱人的产品，然后同学进行投票，按照志愿分发到他想加入的组。

做产品的步骤 Step 2: 进行项目管理，只做「有价值的功能」

要做一个有价值的项目，是需要很多道加工的。

真实的世界，很多时候，用户虽然喜欢你能够解决的方案，但市场窗口是不等人的。必须得在市场窗口关闭之前，做出来并且上线。

所以：

小组进行 User Story Mapping，讨论什么是「Must Have」，什么是「Could Have」。其余程序员个人的「私心与贪心」全部扔到抽屉里，有空再做。
利用 Tower 进行项目分派。
利用 Pull Request 进行代码协作。

做产品的步骤 Step 3 : 建立程序员的公德心

产品团队为什么总是 delay 上线？鉴于这十年内我见过了形形色色的程序员，所以对于开发方向进行这样的闪坑指导：

大家在协作的主干 develop branch 必须要是「不会爆炸」的代码。
大家部署到 heroku 的 master branch 必须是「可操作可验收」的实际产品
每天晚上六点由团队主力程序员 Merge，部署 Heroku
每天课程助理会收「各组录制的产品功能 Gif」，确保队员交出的当天成果是「可用功能」而不是「乱写的功能尸体...」
每天早上 Standup Meeting，确保今天的主线是正确的
每周五早上有「产品展示会」，每周开发的产品功能要展示给全班同学看，给全班同学玩，让大家指教。如果周五交「尸体」的组，会被我在展示会时钉在墙上。。。。。
每周五下午 Retrospetive Meeting，重新检视每周项目版上的功能「什么是相对重要的」「什么相对是不重要的」
每周五下午要开「分享会」，同组成员分享「本周自己学到最好的知识」「本周最坑爹的事」

做产品的步骤 Step 4 : 对产品做 Onboarding，进行最后一道打磨工序…..

鉴于 Step 2 与 Step 3，所以同学的进度是很神速的。大概做到第三周快结束，领先组的同学突然就要求我加入他们的例会讨论救他们....。（我大概每周只参加他们的 Standup Meeting 一两次，确保方向不要歪得太夸张）

因为他们发现即使不管再怎么努力做功能，做出来的网站虽然精致，看起来还是像尸体。不知道要怎么往前推进。

所以我教了他们最后一招：Onboarding（以前 GrowthHack 班有教）。

User Onboarding「用户引导」，也就是要让新用户注册后，服务可以透过一系列的互动引导，具体的流程决定了用户是否会回养成使用产品的习惯并成为回头客。

利用一系列的 Onboarding 问题，抓老公、男朋友、别组同学、课程助理、微信朋友圈的路人，来当真实 User，对这个网站进行以使用者角度的批判。

不管什么角度都可以写，至少写出 50 条
团队再拿这 50 条，开个检讨会，一一把 solution 写出来。
重新检视这些 solution，哪些是可以做的，哪些事不能做的。
哪些功能做得正确，打磨得更为人性。哪些功能是冗余的，毫不留情地砍掉。

然后，他们再花一周，把这些「Bug 全修掉」。

以这样的步调，同学有一组是四周就把产品上线了....。最后一周就没事干了。

人才火箭 http://talent-rocket.herokuapp.com

乃至于这组最后一周，还花了两天的时间跟又硬干了一个小专案当 Hackathon 打，在毕业典礼上展示。两天能做出的成果真是相当披敌当年我去打 Hackathon 的功力。。。。。。

浓缩书：http://nongsuoshu.herokuapp.com/ ( by 人才火箭队组员）

队员日记：http://nfreeness.logdown.com/posts/2016/09/16/like-the-moon-not-the-same-mid-autumn-festival-of-9-15-journal

结语

分享这篇文章，其实真不是想炫耀这个班多牛逼，自己又多会教云云。说实话，我教学的技术并没有多厉害，我只是教同学：

一般公司应该就得这样做专案的方式
一个好的程序员，做事基本的态度
分享、检讨，才是前进的加速器
做任何产品与功能应该基于价值
自学的功夫，才是真正应该带走的精华

我的初衷是：

培养对这世界能做出贡献的程序员
学编程不该这么难，这么花时间。我觉得这世界应该有更有效的方式。
学生「努力」与使用「正确方法」的学习，远比有没有计算机背景更重要。

我更感谢同学愿意花这么多时间赌在这个班上，认真的一起搞这个实验的 Project。

更让我见识了大陆同学的认真与狠劲，这个班要是办在台湾，我真不知道有没人愿意一起玩命的这样「认真投入学习」。

最后，为什么会分享这一篇文章所谈到的教学技术？用膝盖想都知道我耗费了洪荒之力，才证明出来这个实验结果。我再会教，也量产也量产不出个什么鬼。

我只关注更在乎这个世界的编程教学法，是否能够被大幅改变

与其关注教学技术是否可以独占，我更在乎这个世界的编程教学法，是否能够被大幅改变。有更多的程序员诞生出来，这世界会变得更加有趣。我更希望人家 clone 我的教学法，一起去改变这个世界。

谢谢耐心看完这篇文章。若有兴趣交流，加我的微信号 xxddite

P.S. 2016/09/15 中秋节，这是人生当中过得最开心的一个中秋节。

Slide（全栈班毕业赠语）

https://speakerdeck.com/xdite/quan-zhan-ban-bi-ye-zeng-yu

学生的优秀博客

（周记每周更新）（基本上我们有 20 个博客，全发大家估计看不完...）

我的學習經驗

xdite — Thu, 16 Jun 2016 20:55:36 +0800

這一篇是上個月某個雜誌採訪我時的內容，但正式刊登時，篇幅真的太少了。我覺得當時分享的東西被埋沒太可惜了。所以跟採訪者要了逐字稿，整理出來。分享給大家。

希望對各位有一點幫助。

問：你是大學畢業後，開始自學程式嗎？

其實，我從十五、六歲就開始玩程式，但那時不叫「寫程式」，而是試圖怎麼樣「改別人程式碼」出自己想要玩的東西，但就是很玩票。我一直到大學時，才會想要怎樣變成專業人士「寫程式」。

問：大學時，就立下這個目標嗎？中間有發生什麼事情導致你想這麼做？

像我十五、六歲時，台灣 BBS 很盛行，我也有管學校的 BBS，只是處理站務改改程式碼而已。但我對於改程式這件事沒有很厲害，那時候不會寫程式，只是會改 C 程式、調一下，架站這樣。以現在的標準，那不叫會寫程式，那叫會改程式。

大學時，玩網路連線遊戲，那時是文字型的，叫 MUD，是文字介面。

當時覺得這個滿有趣的，因為很多人寫程式都是從玩遊戲開始的，然後試圖想要改遊戲、做遊戲這樣子，我那時覺得這個很好玩。但我都沒動變成職業開發者的念頭，因為學校沒有教怎樣做這件事。

問：妳是念那一個系的。

文化大學應用數學系。會念應用數學系是因為，在高三時，問在 mud 時認識的朋友（清華應數），如果要寫程式的話，要念哪一個系？

他就說念應用數學或資工皆可。所以，我在大學填志願時，是應用數學系與資工系交叉填寫，只填這兩個系。其實在台灣早期，大學只有應用數學系，數學可以運用到很多領域，而當中有一門電腦科學，後來電腦科學變得很大，就拆出去變成資科系。我很慶幸後來念了應用數學系，後來有發現們台灣這一行寫程式非常強的人，很多都是應用數學系的。因為應用數學系在我們大學時，幫我們打下了很好的邏輯底子，寫程式需要邏輯。

以前我們練數學要寫證明題，假設一個證明題有 1-10 個步驟，若你答題只這樣寫「1,2,7,8」的話。這樣老師只會給 1,2 的分。若你跳答，老師就知道作弊了。

這樣強制養成數學系的人，做事情都要從根本想起，把問題想透的習慣。

問：你第一個學的程式是？為什麼？

C 語言。因為那時大家都在玩 BBS，BBS 是由 C 語言寫成的，我第一個接觸的就是 C 語言，十五、六歲時就會寫 C 語言。

問：所以你是十五、六歲管 BBS，然後再念大學時對寫程式有興趣，現在才變成職業程式設計師？

人長大之後會發現自己的能力有限，發現自己沒辦法沒門路進入自己想要的職業，做不到。所以其實我中間是有放棄這個念頭。

我念大學時，想要變成程式設計師，但又自覺沒天份。因為大學都教作業系統、資料結構，數位電路，卻沒教你怎樣規畫一個大型程式，只有教你寫基本的程式語言、物件導向程式、資料結構、演算法而已。那時候也沒有 MOOC 這種東西。

光靠學校教的東西，就會覺得很絕望，覺得念大學好像變不了像外面這樣很厲害的程式設計師。那時候從學生角度去看業界的開發者，就覺得超厲害。自然我就覺得我好像沒有天份。

但我發現我會管機器，我那時候比較有天賦的是管 Linux / FreeBSD 上面的服務。寄信郵件，網路伺服器，這是我真正擅長的事。但說到寫大型網站程式，老實說我沒辦法，我也不知道怎樣入門。

問：你當時有辦法想像到你現在變得那麼厲害嗎？

完完全全沒有辦法。變成現在這樣，根本是超乎我百倍預期。要是我大學時代就能知道我變成現在這樣，可能會心臟停止吧。

問：所以，你當時並沒有立志要寫程式？

我沒有立志要寫程式改變世界，而且我也學不會，那時候很挫折。我出道時不是天才設計師。

問：你那時學寫程式時遇到的最大挫折是什麼？

我根本不知道怎樣才能變成一位程式設計師，我沒有認識這樣的人，網路上找不到資源，學校也沒有教，好像這整個個世界跟我沒有丁點關係。

問：所以妳怎麼走出來？那不是等於毫無任何人可以幫你？

對。我剛大學畢業那一、兩年，那時在流行 PERL 寫程式，就是用寫動態的 CGI 網頁，後來又有 PHP，我就去學做簡單的開發。當時無名小站、PIXNET 開始起來。然後我就去學 PHP，PHP 比較簡單，但我也只會做非常簡單的開發，我不知道怎樣做架構。

後來，我去參加 Open Source 社群，我去聽一個演講，有人介紹有一套程式式軟體叫 Ruby on Rails。架站速度非常快，就是外國有一個流行的框架正在興起，它號稱 5 分鐘就可以做一個部落格。

不是微軟的拖拉工具，而且是 open suorce 的，我現場看他們示範，就真的 5 分鐘。回來就自己玩玩看，也是真的 5 分鐘，那時我覺得我找到一道門了，竟然可以我改一改就有東西出來，讓自己覺得好有成就感，好像天才。雖然只是 CRUD，可以新增、刪除一些網頁，做一些玩具等級的網站。

但是我還是不知道怎樣做大型的網站。後來我去買了一本書，心想現在很流行無名小站這種社群網站，我要是用 Ruby on Rails 做這個網站，如果可以做出來去求職，應該會很順利。我原本認為無法把書上的習題做完，沒想到不到兩周就做完了，就自信心爆棚，都在瘋狂地練習，做功能。

問：一般人遇挫折就算了不學，為何妳沒被打敗？

我不是完全學不會。我覺得我應該學得會，只是我一直找不到門可以打開這個世界。

問：妳心裡想變成什麼樣的人？

那時做 BBS、做一網站是很開心的事，因為 BBS 讓大家上去流覽看板，站長可以管看板，就像現在的 PTT 一樣，修改上面的服務，提供給人家用。我覺得這樣子很厲害，我想要變站長。但 C 語言太難了，你要做成一個 BBS 非常難。就想說做網頁，也是很困難。我就想說怎樣才可以做一個論壇，當時的願望只要這樣子，因為我可以做一個服務很多人用，這樣子而已。

問：後來有達成？

有算達到。因為有經營一個部落格平台 LOGDOWN，那是讓程式設計師發表技術文章的平台。

問：從那時 LOGDOWN 到多久了？

2006-2012 年，6 年．我中間還有做很多網站，LOGDOWN 算是覺得最個人產品的一個。

問：聽演講、買書，兩周做完一個社群網站，是第一個作品嗎？

我不知道能不能算，因為那是書上的範例網站。

問：兩周學會，滿快的？

對。它就一步一步，我照著上面打 CODE，再修改成我要的。它的例子很實際，我算遇到很少的困難，做出來的東西又有模有樣，這是在出社會一年多的事情。

我是在 2007 年開始學的。

一開始有點難。難度在於，它的安裝環境在 WINDOWS 裝不起來，只能在 MAC 或 LINUX 系統。這對大部分的新手來說很難，因為不熟悉 LINUX 系統指令環境，而且要裝系統套件，但這對我來說不是問題，因為我剛好是做系統網管的，要非常熟 LINUX 系統指令列。所以我剛好就沒被打倒，這個對一般人來說天一般高的門檻，對我來說剛好不是門檻。

然後，裝機對我來說也不難。Ruby on Rails 當時更新很快，套件不斷推出，套件若爛掉就無法做用，但對於我來說，平常解這些問題解習慣了，根本不是什麼問題。我只要聚焦在怎樣做網站就好了，其他的系統問題根本擋不住我。

問：你花多久時間學會？

半年。因為那時候只有一台 WINDWOS 電腦，因為上班的地方只有這一台，用它來寫有很多的 BUG，沒有辦法解，薪水也很少，系統工程師的薪水只有 3.5 萬，當時一台 MAC 電腦要價 4 萬元，我去辦分期付款，每個月要還 6000 元，買一台 MAC，下班時間使用。

因為我沒有錢，上網自學書的錢便宜，但沒錢買電腦。很多人覺得我現在怎麼這麼順利，但他們不知道的是我當時連買電腦的錢都沒有。那時就聽說學 Ruby on Rails 一家要用 MAC，而且可以少掉很多阻力，我實在被那些亂七八糟的事搞煩了，因為開發的人都活在 mac 世界。

問：所以不是來自程式本身，而是資源？

對。

問：學習 Ruby on Rails 有什麼好處？

Ruby on Rails 的好處是，它是一個框架。語言與框架不同。Ruby 本身是語言，那 Rails 是程式框架。框架可以讓一般人可以透過工具、模板做出、改出你想要的東西。像木頭與積木的不同。就像樂高積木也是已經打造了某些基本的素材，你不需要從頭開始。

Ruby on Rails 可以存活到現在沒被淘汰，是因為創辦人有很強的哲學。他說，Convention Over Configuaration。寫程式都有一些好的習慣、好的 Pattern，那我們應該在框架上實行這些東西，讓後續寫程式可以輕易打造複用的工具，不用重新發明輪子。

用別人的東西，修改好再 Feedback 回去，例如，當你要做一個網站的登錄系統時，你可以用人家做好的登錄系統修改。有點像蓋房子一樣。因為它的東西很多都是固定、現成的，當你不需要重新發明輪子的時候，你的學習挫折感會降低，當你去看人家的套件時，就會學到很多。而且這個社群就是愛分享。

問：Ruby on Rails 社群與其他社群有什麼不一樣？

在其他社群比較挫折的狀況，像是 PHP 或 NODJS 社群，每個人的方法都不同，組起來也不能動，新手的挫折感就會非常地大。去問 A 框架裡面的東西，B 就會鄙視你，新手的挫折感很大。就像你可能在 PHP 中學了 A+ 的寫法，去 B+ 不能用。

Ruby on Rails 寫的東西都差不多，就好像你有許多好強的同事在幫你，你不需要真的去國外厲害公司，你在這個社群就可以很快成長。有一個框架約束，大家可以很快做事，就可學得更快。

問：你覺得 Ruby on Rails 初學得快、慢的關鍵差異在哪？

不肯買 MAC，因為好的資源都在上面。

問：前半年沒 MAC 電腦，後來才發現。

對。因為 MAC 很友善，頂尖的程式設計師開發很多工具。好用工具與慣例都在上面。

問：你這次創業的原因是？

這次做這個公司是無心插。，我因為喜歡 Ruby on Rails，所以就在有 Ruby on Rails 職位的公司任職，收了很多徒弟，培養的開發者很厲害，後來有一些人說要來「我的公司上班」，不管這個公司是不是我創立的，或是其他人雇用我。但問題這些人來學，只是對 Ruby on Rails 想學，對公司沒有愛，可能學完就跑了。

對於我或公司來講，這都是很傷的一件事，因為我們希望為社群創造出更多人才，但這不是辦法，這是開公司不是學校。於是就開了 GROWTHSCHOOL，別人是教你入門，我是教你變成職業選手。因為我之前陪養出很多的職業選手，所以我很清楚入門技能、方法、職業需要哪些。

問：在學程式語言過程中，有遇過撞牆期嗎？

有。這跟學程式比較沒有直接關係。

為何我教 Ruby on Rails，又教專案專案，之後又教 growth hacking，其實這也是我之前的一些學習歷程。

因為我覺得學程式就要懂產品，我後來找到 Ruby on Rails，寫大型程式的速度才有辦法提升，升職也很快。但之後發現，自己寫程式很快沒有用，要很多人一起寫才有用。但問題來了，那時我底下帶了三、四個人很難有效溝通，我發現要讓一個網站快速發展就要學專案管理，因為很多事情混亂，效率無法提升。

後來將專案管理練到極致，又發現問題，所有你需要的東西會在時間內出現。那沒問題，問題是公司產品死掉了，因為成員沒有熱情了，他是按照專案經理的指示去做而已。

那我就去想為什麼會這樣？發現專案當中很多是是 PM 或老闆妄想的規格，不是公司產品會成長的關鍵。

要成長就要學 GROWTH HACKER，程式設計師跟產品行銷結合，這是一個突破過程。

問：你在那一間公司遇到這個瓶頸？

其實我發現大家都有這種瓶頸。

問：怎麼解決上述問題？行銷與程式不容易結合？

大部份人都以為行銷就是廣告，在這個階段 Acquisition 叫做獲得客戶的眼球，但後面其實還有幾個階段叫 Activation 買你的東西。下一個是 Rention，變成長期訂戶。

但很多人，只在意曝光行銷。成長是客人一直成長，同時也會有人流失。怎樣降低流失的人，衝高成長的技術，叫 GROWTH。

更重要的是要有常客，幫你推銷。但舊世界的人很少意識到這一點。下面這一段反而是好控制的，你都有數字的，可以調查，他們喜歡什麼。例如 NPS，願意把這項產品推薦給家人使用嗎？例如，推薦 XXXX 月刊……

這個技術是有辦法用工具去做的。技術可以與行銷結合，公司也可以快速發展。但台灣很多人做行銷只在乎曝光。

問：對於一個新手而言，想學程式語言，如何選擇標的？

新手選擇學習程式時，都有一個盲點，只想學最能幫他找到工作的程式。

比如說，現在的寫手機程式的 iOS 或是 Ruby on Rails，比較能幫他找到工作，他就想學這個，而且他只想跟大師學。但他忽略掉了一件事情，他自己真的適合嗎？有些人學了之後才發覺這不是他真正想要的，我覺得學一個語言最好是學一個初級班的程式，拿一本快快樂樂地學 Ruby on Rails 之類的，去找那一個你做了有成就感的，沒有成就感的沒用。

問：為什麼？

因為如果你一開始就學太難的東西，像我就是剛開始一直犯這種錯，一開始去學太難的就仆街了。

還有些新手只想跟大師學，問了一個問題，希望大師回答你。但大師回答有大師的風格，如果你問的問題太蠢太無俚頭的話，大師沒有興趣跟你聊天，所以就會挫折。然後新手就會懷懝是自己的問題，還是大師的問題。但事實上根本都不是，而是你自己沒有到那個境界，頻率不到，問問題的方式也不對。

大家都只想挑遠大的目標，但學習事實上是你要挑適合的目標。

比如說，我自己要學專案管理好了，我去書店時，我一定會挑新手如何第一次做好專案管理，我一看覺得這個我會，就很開心照著這樣子看，幾乎我那個時代的管理書籍我都看遍了，但我是從淺的買到深的，因為我看了以後，我回去用它來管，然後真的有得到效果，我才會繼續啊。

問：一般人的想法是，對找工作、增加錄取率沒幫助的就不學？你呢？你的學習哲學是什麼？

這是我跟別人不同的地方，我的哲學是會被別人鄙視的，我是「短視」哲學。

怎麼說呢？因為大家都會問我學哪些技術有沒有辦法讓我找到工作或是升職。我覺得問這些東西都還太遠了。

我日常工作最常見的問題可能如何讓底下的人聽我的話，讓團隊一起向前，效率有效提升，公司產品如何成長這一些很實際的問題。

我只專注解決眼前的問題，後面那麼遠的問題，我甚至不知道該怎樣走。要是我真的說我知道該怎樣走，我都認為這樣的說法是太自大了。

我不知道為什麼其他人有那樣的自信說「我知道學 XXXX 可以幫我找到工作」，怎麼有可能，等你「刻苦紮實打底」搞不好人家都用別的語言了。

是你有沒有辦法學會眼前這些程式解決你現在的問題，這樣子才能往前進啊。

我當時去學 Ruby on Rails，根本不是為了找工作啊。因為那時候台灣根本沒有工作可言，太早了，根本沒有 for Ruby on Rails 的工作存在。當時還只是實驗性的東西，我只是覺得我可以做一個網站給別人玩，那是我的夢想。那時候，人家還嘲笑說 Ruby on Rails 禁不起大流量。但是，這我不在乎啊，要是你的東西都沒有人上來用，管「大流量」幹嘛？但做出來第一步了之後，就很開心，就自然後面有辦法找到方法解決「大流量」的方法了。

「先做出可以解決問題的東西」，我的哲學是這樣。

我學很多技術都是這樣的初衷，沒什麼心機，就是去學「解決問題」的技術。

問：Ruby on Rails 主要哪些網站有採用？

做網站，比如 T 客邦、AIRBNB、彭博後面的部落格，也是用這個框架做的，就是做大型的商業程式，幫人家快速開站，因為它是後端程式。手機是前端用 IOS 寫的，後面要去接 API，呼叫程式，後端也是用 Ruby on Rails 寫的。職缺是真的很多。

問：新手該訂什麼自我學習目標嗎？

如果生活上有什麼問題，比如說有人想要做記帳軟體、減肥軟體，試著用程式思維去解決你現在的問題，然後去找一門語言解決這件事情。因為這件事情可能你沒有辦法用手動去解決，你可以試著用程式去解決看看。

問：創業有建議從哪邊切入嗎？

我建議從本身問題出發。我發現台灣人不論是創業或是寫程式，都有同樣的一個問題，那就是看別人在開發這個產品，他就跟著抄襲。如果要他真的想一個原創題目的話，他想不出來。台灣人缺乏生活體驗，想不出東西來，所以只能抄。

我認為只要專注在自己生活領域遇到的問題，其實就會想出這些解決方案來。

我會開發 Logdown，是真的因為被貼 code 問題搞煩了。想開發一個部落格軟體，可以貼程式語法而已。因為有人對這些事有困擾，而且想要解決，就會有商機。學程式是為了解決生活困擾，我希望大家認清一件事情，就是你一定要去學程式「解決問題」，因為未來程式需求只會越來越多而已。

既然無論如何都要學程式，那就去學一門程式解決你的問題。

問：但學程式很辛苦吧？可能要一直不斷的學習？

每個學習程式語言的人都會焦慮這件事情，因為我們學 Ruby on Rails 後，又有 IOS 出來，那我們就會猶豫要不要學，後來決定不追。

但我發覺大家也搞錯一件事情，程式作品是「結果」，程式語言是表達你想法的「工具」。開發程式，是一個把日常慣用的交易模式，變成一個實際上可以自動執行交易化的結果。

重點是你怎樣想出「解決問題」的方法，然後把它具體化，跟語法無關。

這可能是程式教學界，比較流行的話叫 Computational Thinking。用那一門程式，不是重點，重點是 Computational Thinking。這不是說學會怎樣寫程式，而是教你如果拆解問題的方法。 Computational Thinking 第一步，就是把未知的問題列下來，找出已有的模式、已有的問題，再用有效率的方法，比如寫程式的方式，拆成小樣的難題再去解決，再從中學會。

比如說，資深的編輯會有自己的工作模式，遇到一個陌生的人，你應該知道會有那樣的問題，再去解。不論哪一行都會有 Computational Thinking，只是不叫做 Computational Thinking，而程式設計師只是 Computational Thinking 特別發達，如果不會這個，他根本不會寫程式。

比如說，老闆叫你做「購物車」，你要去想購物車的原理、運作，怎樣對應到程式，所以重點不是學程式，而是及早具備有 Computational Thinking 的能力。

問：所以練習「解決問題」的能力很重要？

對，但職場上的人都不太注意到這件事才是最重要的。如果你有這個能力，就算軟體不斷推新，你還是可以用同一套方式去做就可以走出自己的路，跟你用什麼語言無關。

例如，我現在在學 ios 開發，跟我之前接觸的語言無關。我也是用同一套方法，把每一個難題控制在我可以稍微解決的問題。因為若不這樣子的話，我沒有辦法克服眼前學習上的難關，也就無法繼續下去，會非常挫折。

我其實就用這樣的方式，學到新的技能。

問：完全沒有程式底子人也適用？

對。像我現在教人家學程式，第一堂課上的是 Computational Thinking。我用一個 user story 的手法來教。

問：如果我是第一堂來上課的人，你怎麼教？

比如說，要做一個購物網站就要有購物車、訂單系統、上架系統，還有廣告界面，但你不知道要怎樣把它做出來，所以，就會上網找怎樣做購物車，就會看到一大堆怎樣做的方法，但你也看不懂，所以就問 pm，他也不懂，所以做不出來。

user story 的方法則是從人的角度去想，會怎樣操作。比如用戶故事，當誰誰誰在這個軟體他應該做什麼事完成訂單需求。假設以訂單系統來說好了，消費者在購買產品後，應收到一張訂單，並收到購物信，然後他再把這個產品放進購物車並結帳。

你就要這個流程一條一條寫下來，好處是可以釐清係統會發生什麼事情，誰會發生什麼需求。因為做網站時最常發生需求與供給不合，人去用的時候，每個人的想像不同，工程師是按規格去做，比如訂單系統，工程師可能會按照他去購買時的訂單系統，但業主在做的時候卻說怎麼沒寫後台，你怎麼沒有做呢？我們還有訂單出貨之類的，你怎麼沒做？因為 RD 根本不知道還有後台操作這樣的人存在，如果不知道有這樣的需求。

所以，一開始就要想這些事情會有哪些人進來參與，他們會遇到哪一些場景，會遇到那問題，如何解決。就可以拆解出來，接下來，就可以預期有什麼狀況。對於一個新手，雖然還不會寫程式，但卻可以用這個方法，把問題列出來，用一條條問題去問人，如果問「怎樣做購物車？」高手會比中指。

問：到這裡都還沒寫程式，都是人可以懂的東西？

對，一直拆故事，要拆到可以寫出程式為止。

問：舉例？

管理者要可以登錄後台，上架產品。管理者有哪些？使用者分一般顧客、管理者。要做使用者系統。這時就發現有兩種人了。

管理者要登錄系統才能管理後台，這時候就要有帳密了。管理者再拆上架編輯、退換貨

第一堂就是在拆這個。

問：這是一路學下來的思路與結果？

對。USER STORY 是很高階的設計師用的技巧，但我覺得這技巧，低階程式設計師也要學，它很重要，應該要教他們這個工具。

問：談談撞牆期。有哪一時間點上想放棄？怎麼突破？

到一個程度你會覺得技術開發上好像沒東西可以學。就覺得到頂就是那樣了，要不要改學新程式語言。後來發現那是因為在台灣可以玩的「狀況」不夠。所以等級上不去，所以我後來就去上國外的課程、研討會。學會新技術、新視角。

因為台灣大型架構經驗跟公司太少了，當書無法、國內工作無法滿足我的時，我會去國外上課，他們很多元視角。我剛從 rails 研討會回來。就有人分享 Rails 教學該怎麼教，她是高中教師出身，他的觀點切入就讓我大開眼界。

我真的覺得，看書、研討會、工作坊、去學別人的經驗是最快最便宜的。因為「自學」要花「時間」，「時間」是不可逆貨幣，太貴了。

問：跟別人學程式的部分？可以舉個例子嗎

像我剛在 Rails 研討會，學會到怎樣設計到 API 技巧，怎麼設計得完美漂亮，而且同事也可以做出厲害程式文件。對方示範了可以寫一次程式文件，然後就用這份文件，轉成假後台。需要改程式就直接先改文件。這個想法我從來沒有過，很震撼。

這如果在台灣，可能去你同領域討論半天都學不到，因為別人也沒有這種經驗。可能我們在原地自幹 5 年，但是去要跟厲害你太多的人學、去跟大師學，可能大師講到一個突破點，你瞬間就成長好幾倍。

省下三、五年的原地打轉。有時候真的一個程式設計師就卡在這裡，上都上不去。

問：要怎麼成為厲害工程師？

當出色的碼農比較簡單，符合效能、維護性，就行了。但是碼農可能只能寫程式，做出來的是就沒有價值的「產品」

「產品」價值很低，但「商品」是有價值的。「產品」只是產出而已。

駭客松第一名可能也沒什麼，如果不會團隊合作，其實有可能把自己搞死。所以，不能只會程式這東西，還需要有別的。有的人只知道寫出程式，但不知為何當初被吩咐要這樣子做，把它當成一件工作而已。這樣很可惜。

其實這個世界還有很多方面你可以去想辦法讓你的「寫程式技巧加分」。比如說專案管理、產品打磨，在有效的時間點內做出足夠好的產品，讓人買單。

問：如何讓自己寫程式快速進步？

找一個你可以「有非常多熱情」的領域，用程式去解決問題，用程式去影響其他人，當你想要讓別人變得更好，你會進步得很快。

進步得很慢的狀況，通常是你只把這一份工作當作是「碼農...」。

問：你覺得寫程式會很辛苦嗎？

不會啊。這是我的休息娛樂。像我昨天寫了 10 個小時，突然有種放假的感覺。寫程式竟然是發洩與休息。

問：每一種程式的語法都不同？

對。

問：新手要學那種類型？

我覺得學熱門的，有文件的比較好，才不會求助無門。這樣你可以很容易找到有人肯回答你的問題，會覺得這個世界還有救。學程式有人願意幫你有成就感很重要。

[RSpec] 一次講清 stub / mock / double / spy

xdite — Sat, 11 Jun 2016 12:46:30 +0800

(也是趁端午節時間很多寫的....）

http://blog.xdite.net/posts/2016/06/11/rspec-advanced-concept-part-0

很多新手在經歷一兩年的開發經驗後，開始覺得寫測試很重要。想要入門學習測試。但是看到這些名詞：

stub
mock
double
allow
receive
expect

就覺得很頭痛。特別是 RSpec 2.1 與 RSpec 3 一些語法升級，又造成了更大的混淆。所以我希望寫一系列的文章，解釋清楚這些名詞。想辦法把測試這個主題講清楚。

這一個系列，我會嘗試以以下的順序講解以下主題：

Part 1: 測試的種類
Part 2: stub V.S. mock
Part 3: 使用 stub
Part 4: 使用 dobule
Part 5: Stubbing
Part 6: Mocking V.S. Spying

[RSpec] 一次講清 subject , expect , context, is_expected, be_xxx

xdite — Sat, 11 Jun 2016 12:44:45 +0800

趁端午假期寫的。

一次講清 subject , expect , context, is_expected, be_xxx

http://blog.xdite.net/posts/2016/06/10/rspec-subject-expect-context-is-expected-be

產品的系統性成長 ( Growth ) 方法

xdite — Mon, 01 Feb 2016 13:24:50 +0800

這是我 2015 研究 Growth Hack 一整年的心得與心法。而且實際應用在我的新 Startup 上。

具體成長數字：

原文連結：http://blog.xdite.net/posts/2016/02/01/grow-product-systematically

=========

將產品分為幾個階段

首先，你必須認知到自己的產品到底屬於哪一個階段。

10 分：沒人用
20 分：Minmal Viable Product
40 分：可以跟顧客收錢
60 分：Product Market Fit
75 分：客戶回流高
90 分：壟斷市場

使用 NPS 量測：

產品 40 分以上的產品，NPS 必須是正的。
產品 60 分以上的產品，NPS 必須要超過 20 分。
產品 75 分以上的產品，NPS 必須要超過 40 分。
產品 90 分以上的產品，NPS 必須要超過 50 分。

值得注意的是，免費與低價的產品，通常 NPS 太高沒有真正的價值。

如果你的產品價格正常，NPS 還是時常遠高於 70，那可能收費太便宜了。

創業第一階段如何挑選主題，並找到客戶

1) 挑選快速 PMF 主題

自己很熟
或者週遭很需要

相關文章：如何挑選正確的創業題目？

2) 建立介紹產品的著陸頁面 ( Landing Page )

一句話形容自己（的「價值」而不是「功能」）
使用這個服務的三大好處
How it works
使用者見證 / 報導
CALL TO ACTION
消除疑慮

3 ) CALL TO ACTION 的後續

用工具蒐集 "Leads" （Email List 銷售機會）
或直接購買產品

4 ) 放上 online chat 軟體

Churn 也包括流失的銷售機會。所以你一定要放上 online chat 軟體捕捉這些人

Intercom
Zopim

Notes:

Q: 為什麼要找快速 PMF 主題？ A: 因為你才找得到真實的 Customer「使用」。（不是「試用」，而是「使用」）

不付錢的客人跟付錢的人 feedback 天差地別。（參考李笑來的文章 http://36kr.com/p/5039695.html）

Q: 我找不到第一批用戶怎麼辦？ A: 要是你是這一行專家或者是周遭很缺這方案的話。你一定找得到。找不到勸你轉行了。我的理論是每個人都是周遭 50 個人內的某樣事專家。所以你一定有辦法把你的生意廣播出去。

沒人理你可能是轉換率太差。所以你要做一個 Landing Page 介紹你自己，而不是「我是專業，你一定得相信我」。

要做到光靠口語就相信，要馬你在原先專業上一定要有 80-90 分，要馬對方跟你很熟。如果你有好一點的 Landing Page，可能專業能力 50 分就有人相信了。

Q: 曝光不夠多怎麼辦？ A: FB 花個三千買第一批用戶

Q: 但是只能做完第一單第二單，就沒了怎麼辦？ A: 大家都在觀望。所以你只有兩單的機會做起來。這時候你需要在這兩次的機會，把你的 onboarding 做起來。也就是把原先的產品從 0 -> 20 -> 40。

所以還是要重講一下，要是你的主題不是能快速 PMF，拜託別進來玩。你玩不出結果的。

Q: 如果我的產品概念很新，怎麼行銷？ A: 你可以搞一些 Content Marketing。不賣東西。純粹傳播知識。讓對方「想到你是專家」時，第一選擇就是你。（關於 Content Marketing 還有很多東西可以寫，這邊我先省一些篇幅）

產品 20 分階段 ( MVP )

1 ) 做 onboarding

如果你是重複提供服務的朋友。請按照心法班的三大原理七大步驟，把你的 onboarding 步驟描繪出來。進行服務調整。

如果你是 SaaS，很好。你可以用 Intercom 去抓到那個 Cycle 並寄信。如果你不是 SaaS，也沒關係。重點是你要在「正確的時機」說出「正確的話」。

2 ) Run NPS

NPS 是一個很重要的工具。被稱之為 The Ultimate Question。你只要用這一題就可以找出「你的服務爲什麼口碑散不出去」的真正原因。

3) 大量修正你的服務（價格、TA、內容）

這個階段會有大量的 Churn。所以這一階段的任務就是瘋狂修正。但是 Churn 主要有幾個原因：

你的服務爛
客戶不知道怎樣用，所以自殺。（相信我，他們會以你沒有辦法想到的角度，錯誤使用產品）
錯的 TA 用到你的產品

這時候你要想辦法把你「不要的 TA」踢掉。真的，不適合的 TA 盡量踢掉沒關係。最重要的是你要「找到正確的人」，「最大化傳遞價值給正確的 TA」。

所以這階段其實你是在做

修正 TA 的範圍
補強產品缺失
增進產品傳播口碑

要想辦法把 NPS 從負的，修到至少 +30。沒有 +30 不能停。我自己測試的結果，~50 最好。

如果你的服務是一開始就 70 以上，那不正常。表示你沒收錢，或是太便宜。

要漲價的話，我覺得 NPS 是一個很好的指標。太便宜你就漲價，漲價 NPS 就會狂跌，然後你再反覆修正，拉回超過 50。一直進行。

拉到「自然而然」有「主動」的口碑效應。這時候你就到了 PMF 階段。

Notes:

Q: 什麼時候找北極星？ A: 這時候找。因為你要找出你的產品對「哪些人」、「最有價值」。把 NPS 給你 6-7 的人找出來，丟掉他們。

Q: 客戶的 AH-HA Moment 怎麼找？ A: 答案藏在 NPS 9-10 的人的答案。你問他們就有答案。

Q: 調整 Onboarding 要花多久時間？ A: 我認為再小的服務都至少要 3 個月以上。

在這當中，你會發現其他額外的事：

你沒有想過的第二第三 TA 族群
你沒有想過的「自己的價值」
你沒發現的「有效」的傳播 Channel

產品 60 分階段 ( PMF )

具體檢測指標

一些具體檢測指標，在這個階段我建議各位檢查你是否有達到這些條件的其中三個：

現金流至少養得起「足薪」的「3 個」員工六個月以上
明確的第一大第二大 TA
外部有一看就懂的 Landing Page
內部有 Onboarding SOP
- 不需要做 Referral Program 就有還可以的口碑效應

如果你有這些具體的條件。恭喜你，你已到達 PMF 狀態。

如何繼續強化

這時候我會建議你導入幾項手段

Measuring。跑 retention cohort analysis
A/B Testing

Measuring

矽谷很多人為什麼說，建議 PMF 後才導入 Growth Hack。（這是 2013-2014 左右的觀念，其實有點過期了，2015 尾大家已經在說 Growth Hack is dead, Long Live Growth）

很簡單，GH 也是 Marketing 的一種。實作非常花資源。在你的產品養得起額外的員工之前，你沒有心力去搞這些，太早搞只是死光光而已。

在 PMF 之前，你只需專注一件事，那就是 Growth，瘋狂的 Growth。Paul Graham 說每週至少 7%。創業者應該要用這個指標去逼自己。

Growth = Conversion - Churn。拼面拉高 Conversion，拼命降低 Churn。

當你站穩，你才有心力與餘裕去挖掘「你沒有想過的部分」。其餘，只要靠「商業直覺」去做就好了。如果你沒有「商業直覺」，其實不可能光靠自己的力量就站到 PMF 這端來，創投給的資金只是假象而已。

到了 PMF 後，可以用 Measuring 工具，找出你的 Growth Model。在此之前，你只需要 Measuring 工具幫你找斷點就可以了。

找到 Growth Model 找到 viral loop 後，就盡量放大這條 loop 上的效應。因為你要做的是 Massive Scaling。

這時候你可以開始玩 paid marketing。很多玩 Growth Hack 的人鄙視 Paid Marketing。這是不對的。Dave Mcclure 其實非常鄙視這種「鄙視 Paid Marking」的創業家。

https://twitter.com/davemcclure/status/351708892314611712 https://twitter.com/davemcclure/status/351708892314611712

Paid Marketing 沒有不好。事實上你請工程師實作 GH 是成本，你寫文章做 Content Marketing 也是成本。每一件事情都是成本。Paid Marketing 的好處其實是容易操控變因，成本可控，幾乎沒有上限（因為 Channel 很大）。

過了 60 分之後，你要做的事其實是運用 Channel 操縱成長的槓桿。

所以產品有沒有 60 分真的很重要。有 60 分才有 retention，才有錢，才能做你想做的事。

A / B Testing

在 60 分之前，我認為你只需要 focus 在一群 TA 就好。在這個過程中，你會看到很多第二第三第四的 TA 族群。你可以選擇先放著。

等你有 60 分後，再去對這些 TA 實驗。

60 分後，你可以具體的用 A/B Testing 工具，去實驗不同的手段，對不同的 TA 是否有效。

Notes:

Q: 我是 mobile 軟體，也適合這樣的 cycle 嗎？ A: 很不幸的。Mobile 不適合這樣的 cycle。因為修正速度太慢。所以一開始上線就要插 measuring 工具做 onboarding，跑 retention chhor analysis。因為真的太難修正產品。

Q: 我需要把網路上創業建議的 marketing 都做一遍嗎？ A: 不需要。

其實你只要找到自己的黃金 channel 即可。可以是你的 FB、可以是你的粉絲專頁、可以是你的 Email List、可以是你的 Content Marketing、可以是 Paid Marketing。

但真的，不需要全做。因為 Channel 的招數不是在 A 有用，B 就有用。而且可能還會分散。開拓 Channel 是最後一件需要做的事（但也可能不需要）。

產品 75 分階段 ( 回流率高 )

這一段你該加強的就是 Referral、Onboarding

可以具體參考的服務是 Airbnb。我真的認為想要組建 Growth Team 的人，都應該去看 Airbnb 怎麼做他們的 Onboarding 以及 Referral。

他們的 Referral Program 之極致。是我看過做 Referral 做得最好的團隊。幾個可以看的地方：

他們怎麼樣極大化曝光他們的 Referral Program
他們設計 Referral Program 的獎勵機制
客戶住宿的表單問卷。（對 Host 以及對 Airbnb 的 NPS 問卷）
雙方 onboarding 的機制
Airbnb 的 Referral Landing Page 怎麼樣設計
Airbnb 如何使用 deep link 讓手機 app 操作與 web 體驗無縫接軌

當你的服務超過 60 分後。其實 Landing Page 的重要性就變得相對的低（但也請不要讓不懂 Growth 的 PM 隨意亂改毀了他）。

你需要專注的地方，就是 Onboarding、Referral、Onboarding、Referral、Onboarding、Referral。

這當中你可以開始導入 Gamification、UX，進行更極致的設計。但這一切都只適合 75 分。

Summary

我在帶過幾班 Growth Hack 實作班之後的感想。BTW，Growth Hack 實作班教的是

如何在一個早上就設計出「洗腦」的 Landing Page（通常要三週）
如何在一個下午就設計出「貼心」的 Onboarding 流程（通常要三週）
如何解讀 NPS 意義以及應對。

（這篇文章不是要打廣告。因為下一班要在四月以後開或是不開了。我三月要先做其他事。）

我發現大家最常犯的錯誤就是

把自己的「功能」當做是「對客戶的價值」
在 Onboarding 信裡面，無斷的說自己多好多好，推銷賣東西

說實在這只會讓客戶一秒就關掉瀏覽器而已

Hubspot 在他們的用戶測試裡面也跑出一個令人震驚的數據：

30% 的人是因為「沒有感受到產品價值」而離去
30% 的人是因為「不會使用這個軟體」而離去
10% 的人是因為產品爛而離去
10% 的人是因為競爭對手比較好，而離去

Landing Page 做的是什麼？其實就是利用 4P 原則 ( Picture -> Promote -> Prove -> Push）傳達你的價值，讓對方信服，進而買單。

Onboarding 做的是什麼？其實就是讓客戶「懂得使用你的軟體」「了解你的服務的價值」，然後在快失誤之際，想辦法幫客戶補血。

一切都圍繞著價值而生。這兩個手段都是增強價值。

Peter Thiel 說，競爭是給 Loser 的。「創造公司永久的價值，壟斷才是唯一的途徑。」

什麼是「壟斷」？就是在你有價值的領域、適合的 TA，這一塊做到最好。這就是壟斷。

你唯一的競爭對手只有「過去的自己」。

公司會做到死掉，不是因為競爭對手太強，而是你一直在退步。

Rails 101 改版 (仍然持續免費)

xdite — Mon, 15 Jun 2015 06:41:31 +0800

經過社群朋友 sdlong 協助，Rails 101 從一本書改成一套教材了。

當然，還是完全免費。

改成課程的好處結構是，做過的人遇到坑與問題可以直接在上面就得到求助與答案。

新的網址在這裡：http://growth.xdite.net/courses/rails-101

How to Growth Hack?

xdite — Tue, 12 May 2015 02:09:38 +0800

最近都在玩 Growth Hack 的東西。稍微有一點心得。我看中文世界裡面都沒有太多人在寫這些，分享給大家自己寫的兩篇簡單入門。

What is Growth Hack? http://blog.xdite.net/posts/2015/05/06/what-is-growth-hack How to Growth Hack? http://blog.xdite.net/posts/2015/05/11/how-to-growth-hack

RailsPacific 2014 影片全數壓制完成

xdite — Wed, 10 Dec 2014 15:51:02 +0800

https://www.youtube.com/channel/UCLioRClE90iKQMLaFf36aDQ

比照 Confreaks 規格出雙機拍攝，1080p HD 壓制。

Rails Pacific 2014 籌辦祕辛與心得

xdite — Sun, 05 Oct 2014 23:33:35 +0800

上個禮拜剛辦完，所以我寫了一篇心得。

http://blog.xdite.net/posts/2014/10/05/rails-pacific-2014-organizing-secrets-and-tips

有部分 Link 與 Video 在 Facebook 與 Flickr，需翻牆。

明年在高雄，歡迎大家過來玩！

（請辦自由行，會比商務簽證快很多）

另外一本寫給 Rails 開發新手的新書 : Rails 102

xdite — Sun, 15 Jun 2014 08:23:33 +0800

https://www.gitbook.io/book/rocodev/rails-102

免費。

我和同事合著的。事實上這本書三年前就開始寫了。只是打掉重練很多次....

Rails 101 now free

xdite — Tue, 03 Jun 2014 07:26:27 +0800

http://blog.xdite.net/posts/2014/06/03/rails-101-now-free

簡單來說，現在不用錢了。

RailsConf 2014 最強 Lighting Talk : Let me Code

xdite — Sun, 11 May 2014 01:33:47 +0800

本屆 RailsConf 最強 Lighting Talk 影片出來了！Let me code

http://www.confreaks.com/videos/3461-railsconf-let-me-code

這場 LT 是大會排第一個講。

當音樂響起來（Let It Go ) 時我們還不知道講者想幹嘛，結果原來是當場唱歌播 MV！！

插了超多 Ruby 梗在這 MV 裏面。當大家意識到他想幹嘛時，已經播了四五張投影片了，所以網路流傳版本大概都少了一段。

這是大會釋出的清楚正式版。他唱完之後，全場起立鼓掌了幾十秒。

超太殘酷的。

LT 第一場就這麼強，直接洗臉後面十幾個 LT 講者.....

Rails 2014 Conf 心得

xdite — Tue, 06 May 2014 11:12:44 +0800

http://blog.xdite.net/posts/2014/04/25/railsconf-2014-1 http://blog.xdite.net/posts/2014/04/25/railsconf-2014-2 http://blog.xdite.net/posts/2014/05/06/railsconf-2014-3

我有生以來參加過最棒的 Conf

以下是朋友 Bruce 的：

http://ascendbruce.logdown.com/posts/195380-railsconf-2014-chicago-what-i-learned http://ascendbruce.logdown.com/posts/195687-railsconf-2014-chicago-tourism-part

返璞歸真 -- 以最適當的方式設計軟體

xdite — Mon, 28 Apr 2014 08:05:14 +0800

http://blog.xdite.net/posts/2014/04/28/back-to-basic

關於 DHH 的 TDD 文的一點淺見。敬請指教。

Rubyconf PH 2014 心得

xdite — Fri, 25 Apr 2014 23:12:17 +0800

http://blog.xdite.net/posts/2014/04/25/rubyconf-ph-2014-travels

上個月去 Rubyconf 菲律賓的心得。

另外值得說的一件事：2015 的 PH Conf 會在長灘島舉行

再來 3 招實用 Asset Pipeline 加速術

xdite — Sat, 04 Jan 2014 14:59:14 +0800

http://blog.xdite.net/posts/2014/01/04/another-three-asset-pipeline-speed-up

=======

前年我寫過一篇 3 招實用 Asset Pipeline 加速術。

這次打算再追加三招。

1. 加上 cache_store

(如果打算在遠端 Compile Asset 的話）

Rails 3

在 config/enviorments/production.rb

config.assets.cache_store = :dalli_store

Rails 4

在 config/enviorments/production.rb

config.assets.configure {|env|
  env.cache = ActiveSupport::Cache.lookup_store(:dalli_store)
}

http://damon.theidealweb.com/development/rails/2013/08/13/correct-way-to-set-config-assets-cache-in-rails-4.html

2. 換成在 local compile asset

asset compile 往往卡在遠端的機器不夠力，所以編譯很慢。但是現在大家的開發機 Mac 系列，其實都是遠遠比遠端的機器快上許多的....

capistrano-local-precompile 這個 Gem 可以協助你在 local compile 再 sync 到遠端機器，再自動清掉本地端殘留。

Rails 3

效率會提升一些。

Rails 4

提升非常多倍。（我有一個 project 提升 120 秒以上）

這主要是因為自 Rails 4 起，Sprocket 又進行了大重寫。效率有非常非常顯著的提升....

如果有興趣在 Rails 3 上跑 Sprocket 2 的話，可以參考前幾天我這篇在 Rails 3 project 上跑 Rails 4 的 Asset Pipeline。

3. 把靜態檔案從 assets/images 下搬出來。

換成 Sprockets2 + local compile 後，我觀察到本地的 log：

Writing /Users/xdite/my_projects/logdown/public/assets/icons/cloud-download-3ddd0707f2f307ba14c27f28e0b293a2.png
Writing /Users/xdite/my_projects/logdown/public/assets/icons/file-image-081d8086dbbde1b8a014b48ab7d78f9b.png
Writing /Users/xdite/my_projects/logdown/public/assets/icons/pen-c0e637cd3afab39f2e71fa3aa281f26e.png
Writing /Users/xdite/my_projects/logdown/public/assets/icons/search-488fbba73b9cc2d919b788a75f11f6f6.png
Writing /Users/xdite/my_projects/logdown/public/assets/icons/shield-b985accbe4b4f9e642de39af2feb1e62.png
Writing /Users/xdite/my_projects/logdown/public/assets/icons/suitcase-eb8f22fb62c98151fe0baa921a944ec6.png
Writing /Users/xdite/my_projects/logdown/public/assets/icons/user-2481c420fc2240c17a86fc39d4dcbfc2.png
Writing /Users/xdite/my_projects/logdown/public/assets/search-icon-b446fa9eac4881a0ffef79cd2f9e3ba5.png
Writing /Users/xdite/my_projects/logdown/public/assets/themes/compiling-e416cf4231664a0b4328f0f9225eb844.jpg
Writing /Users/xdite/my_projects/logdown/public/assets/tours/built-in-theme-083f3cc5f7b6a8adc66c0570ae60cc9b.png
Writing /Users/xdite/my_projects/logdown/public/assets/tours/custom-domain-url-84997f582135b96f0438a34aa456dbdf.png
Writing /Users/xdite/my_projects/logdown/public/assets/tours/custom-themes-5e03d9edc032c5073093805e4c93326c.png

也就是 app/assets/images 下的東西其實都是會進行編譯的。編譯這些東西需要耗時間。

而根據 sprockets https://github.com/rails/sprockets-rails 官方的解釋，從 Rails 4 之後值得注意原則是：

Only compiles digest filenames. Static non-digest assets should simply live in public/.

也就是不需要 compile 的 Asset 鼓勵開發者搬到 public 底下去...。

套用以上這三個原則，應該可以幫你在編譯 Asset 時又省下「幾分鐘」的時候。

在 Rails 3 上跑 Rails 4 Asset Pipeline

xdite — Wed, 01 Jan 2014 15:31:42 +0800

http://blog.xdite.net/posts/2014/01/01/rails-3-project-with-rails-4-asset-pipeline

這是我新年的一個 Hack。不過要提醒大家這樣做的風險。

雖然 deploy 會變得無敵快，但是有些舊 asset 寫法可能要重來過。

最糟的 Greeting 信

xdite — Fri, 22 Nov 2013 13:24:33 +0800

http://blog.xdite.net/posts/2013/11/21/lean-saas-worst-greeting-letters

（我就不打書啦。純貼文章。聊聊技術創業者的問題）

==============

我曾經在 Inside 的專訪裡面透漏過，在開發 Logdown 時，我們收到巨量的使用者來信。

這些巨量的使用者來信是我們後來得以能夠快速修正打造產品的秘密武器（我們寄了 Geeting 信）。不過雖然 Email 是個很好獲取使用者心聲的好手段。但是不是「寄一封信」出去就會有這樣的好效果。以下是有些需要注意的事情：

1. 用個人名義發出。

（略）

2. 不要寄 Getting Started 類型的信

最好的信件內容類型要像是一封話家常的信，不經意的問問，使用者有什麼意見。

而最差的信件內容是：

Hi。感謝你註冊了本服務。

我們的使用指南在 OO 地址。

我們的 Support 在 XX 地址

我們的 Business Hour 是 XX:XX - YY:YY。

如果你有任何問題,在以上區間內,我們會在 ZZ 個工作小時候內給你答覆。

歡迎隨時給我們來信。

這樣的內容看起來很正常。

但其實這封信的內容嚴重透漏出了幾個訊息：

我們把該寫的東西都放上去了。你這傻 B, 還不會用的話先 RTFM (Reading The Fucking Manual)。你還不會用絕對是你個人的問題。
我們目前很忙，你先給我們寫個 Issue。等我們有空再回覆你。切記！不要直接寫信給我們! 上 Support 提問！
我們是人！也要休息的! 不要在非營業時間來煩我們！我們不會馬上回信。

試想。這樣的內容怎會讓人有興趣專程向你提意見呢？

MVP 的 M

xdite — Tue, 19 Nov 2013 00:54:35 +0800

http://blog.xdite.net/posts/2013/11/19/lean-saas-mvp-m

（我就不打書啦。純貼文章。聊聊技術創業者的問題）

=====

最近幾年，興起 Lean Startup 的風潮。主要的訴求是創業者應該先把重點放在打造一個 Minimum Viable Product (MVP)，觀察市場的需求，再行調整變化商業主軸成長。

說起來簡單，但沒人敢篤定的說，這個 Minimum 的 M 到底要做到什麼程度才足夠。討論一個點子，快速製造出一個原型，然後讓使用者快速反餽調整？這樣做的人很多，但卻不是人人 work。

更普遍的是你見到一個「草率」的產品上線，然後從此就快速沉寂消聲匿跡。

M 不代表草率

很多創業者在製作產品的過程中，常常不自覺得把「MVP」這三個字拆開來看，亦即只完成了「M」，以為實作了「Mininum」的產品規格，就可推出觀看市場反應。事實上，市場上有人會要的東西是 MV（Minimum Viable）。如果你的產品並沒有解決了任何有價值有意義的問題，只是一堆精美的介面功能，那麼是沒有人會買單的。只是浪費了時間浪費了金錢，生出一堆沒有用的程式碼。

相反地，若提供的解決辦法對某些人很重要，那麼就算產品介面再怎麼 crappy，他們還是有興趣停下來試用，甚至付錢給你希望開發者將把它做得更加完善。

M 的 scope

回到正題。我們終歸要討論 M 的 scope 到底在哪裡。

我的建議是：

不會寫程式的作法

如果你不會寫程式的話。先去找一個「會用」的工具湊出一個勉強能夠動的流程，解決問題，然後開始找人試用。

如果你找不到現成的工具可以兜，那麼還有一個方式。你可以拿非常仿真的 Mockup 工具，如 Axure XP、Balsamiq，把「可以解決問題」的流程和出現的畫面畫出來。

不要覺得這樣的步驟很麻煩，因為到這裡為止，還是只有梳理工作流程而已。

你可以從這樣的流程，粗略的知道後面將要面臨多麻煩的事。以想要開一個商店來說，你就會知道商店：

需要一個上架介面
需要傳圖介面
需要結帳介面
提供哪些結帳選項
提供哪些寄送方式，如何選擇
要用哪種條列方式管理使用者訂單

會覺得製作這些畫面很花時間對吧？這些都只是畫面而已。要寫出後面的程式可能是畫一張畫面「五倍」甚至是「十倍」的時間。

透過把畫面與流程畫出來的方式，可以讓你 (很清楚的）知道要製作這個東西要花多久的「成本」（不管是時間上還是金錢上）。

不要因為覺得很麻煩，就使用「功能列表條列」、或者「單張畫面，列出滿滿按鈕與分頁去表示所需功能」的方式去估算工作時間。

因為事實上，在列表上，一個功能你都只會以為需要一小時或一天就能完成。而真實會發生的情形是，一條功能至少要開發 7 天。

當你一旦理解到要執行這個計畫所需成本可能是多麼巨大的時候，自然就會毫不猶豫的把不需要的功能砍掉，只專注在「必要的解決手段」。就這個例子，甚至最可能的情形，是上去 Shopify 上面開一個網路商店，或者是註冊一個 Wufoo (線上表單服務）payment integration Plan。

會寫程式的作法

會寫程式的作法反而相反。我相信各位開發者都很威，開發軟體的成本對你們來說都超低。但，請千萬千萬忍住，只做一個功能就好。思考哪個功能是「解決問題手段裡面絕對不可以沒有的」，只做這一個就好了。以 Logdown 這種部落格平台來說，標準就是只做一個編輯器，以及簡單的文章系統就好了。

（真的不要擔心作太少，一上線你就會知道就算只有「一個」也是會操掛你。相信我，實際試一次就知道了）

因為技術創業者都是「很會寫程式」才會出來創業的人。所以往往的毛病就是不打 idea 草稿，邊寫邊想。又以 Ruby on Rails 開發者（哈，在說我自己）最容易有這壞毛病，因為開發程式太快。所以 generate model, generate controller, 套個版，就覺得這東西可以上線，上線就等於可以開始收錢發財了。

然後，就沒有然後了。

作產品跟上班、接案做的東西驗收標準完全是不一樣的。上班、接案，你只要按照 issue tracking 上的「指示」完成工作就可以了。但是「產品」的「完成」標準，是「順利」的「幫 End User 解決他的問題」。而要做到這件事，產品需要花上大量的時間打磨：介面要做到讓用戶可以理解不會迷路。程式不會出現詭異的錯誤。按照 End User 的需求調整加強，甚至打掉重練。

一開始就作太多功能的問題是：開發者以為這些功能都已經「完成」了。但事實上，他們每一個對使用者來說幾乎都是「未完成」的。也許使用者可以從這麼多的功能列表「猜」出開發者想要提供什麼服務，但是實際上他們不會繼續用下去。因為這個網站爛透了，每一個功能都是「未完成」。沒有解決到任何一丁點問題的網站，沒有人有興趣繼續用下去。

那麼你說，沒關係，我可以之後照使用者的反饋調整網站。但是問題又來了，做了那麼多功能「都有問題」，使用者的回報意見，自然涵蓋了所有板塊。那麼你該如何判斷出什麼問題沒做好才是最嚴重的呢？優先權該放在哪個模組呢？有些厲害的模組甚至是當初花了很多心血做的。結果使用者劣評如潮，你思考了下徘徊在投入心血改進和不如砍掉兩個選項。但狠的下心嗎？

然後，就沒有然後了。被第一次進來的 Customer Feedback 打爆，就沒有然後了。

所以，只做一個能夠解決問題的功能。只做這樣就好了。

Recap

Minimal "Viable" Product
不會寫程式：Write down User Story
不會寫程式：用手邊可以兜出的方案實作
會寫程式：只寫一個「可以解決問題」的功能就上線。

Rails 101 : 11 月最新更新

xdite — Mon, 11 Nov 2013 03:54:28 +0800

Rails 101 https://leanpub.com/rails-101

2013/11

– 修復 Bootstrapper, 更新專案至 Rails 4.0.0 書中錯誤，加上程式碼的 Repo http://github.com/xdite/groupme – 加上 Helper 章節 – 加上 Partial 章節 – 加上 Scope 章節 – 加上 Capistrano 章節 – 加上 Asset Pipeline 章節 – 加上 Rails 4.0.0 production hack

這本書應該算是目前唯一一本支援 Rails 4.0.0 + Ruby 2.0.0 的中文 Rails 開發書。

很抱歉上一個版本到現在拖了幾個月。

主要是 Rails 4 本身是一個不怎麼好「維護」的題目。Rails 4.0.0 從 beta1 -> rc1 -> 4.0.0 -> 4.0.1。這其中的 API 一直在反覆的改變。

因為 3 -> 4 跳板號的關係，裡面很多 gem 在頭幾版的書裡面原先是可以動的，結果一改版就爆光光了。而且 4.0.0 加上了一些嚴格的限制，比如 strong_parameter，這東西搞上 devise，就必須在指南裡面寫一些新手其實未必也了解的 hack。還有 compass 與 asset pipeline 的戰爭，一路從 Rails 3.1 一直打到 Rails 4.0.0 目前還在打...。為了解決專案 deploy 的問題，我的頭髮白了幾根...

最近 OSX 又上了 Maverick，我操......

為了要讓裡面「所有的程式碼」都能執行，中間掉了幾十個坑都有吧。

總之，這本書完成程度已經 95% 了。用來自學 Rails 4.0 應該是綽綽有餘。歡迎購買。另外，Rails 101 小漲了一些，來到了 12.95 USD。

不過裡面送了一張 Logdown 的 $10 USD 折價卷...稍微補償一下。

xdite

無編程經驗的新手，如何在四周開發實戰等級產品 (長文)

全栈工程师的定义，以及所需成长时间

快速带出职业选手，本身就是业界常态

全栈营其实是一场教学上的实验

我是如何设计课程的

这帮学生远超过大家的想像

学生作品 1:

学生作品 2

学生作品 3

学生作品 4

2 天 Hackathon 作品

全栈营教了什么

为什么要这样教？

为什么挑选这些题目教？

如何在四周开发实战等级产品

做产品的步骤 Step 1: 做 Landing Page 吸引用户

做产品的步骤 Step 2: 进行项目管理，只做「有价值的功能」

做产品的步骤 Step 3 : 建立程序员的公德心

做产品的步骤 Step 4 : 对产品做 Onboarding，进行最后一道打磨工序…..

结语

我只关注 更在乎这个世界的编程教学法，是否能够被大幅改变

Slide（全栈班毕业赠语）

学生的优秀博客

我的學習經驗

問：你是大學畢業後，開始自學程式嗎？

問：大學時，就立下這個目標嗎？中間有發生什麼事情導致你想這麼做？

問：妳是念那一個系的。

問：你第一個學的程式是？為什麼？

問：所以你是十五、六歲管 BBS，然後再念大學時對寫程式有興趣，現在才變成職業程式設計師？

問：你當時有辦法想像到你現在變得那麼厲害嗎？

問：所以，你當時並沒有立志要寫程式？

問：你那時學寫程式時遇到的最大挫折是什麼？

問：所以妳怎麼走出來？那不是等於毫無任何人可以幫你？

問：一般人遇挫折就算了不學，為何妳沒被打敗？

問：妳心裡想變成什麼樣的人？

問：後來有達成？

問：從那時 LOGDOWN 到多久了？

問：聽演講、買書，兩周做完一個社群網站，是第一個作品嗎？

問：兩周學會，滿快的？

問：你花多久時間學會？

問：所以不是來自程式本身，而是資源？

問：學習 Ruby on Rails 有什麼好處？

問：Ruby on Rails 社群與其他社群有什麼不一樣？

問：你覺得 Ruby on Rails 初學得快、慢的關鍵差異在哪？

問：前半年沒 MAC 電腦，後來才發現。

問：你這次創業的原因是？

問：在學程式語言過程中，有遇過撞牆期嗎？

問：你在那一間公司遇到這個瓶頸？

問：怎麼解決上述問題？行銷與程式不容易結合？

問：對於一個新手而言，想學程式語言，如何選擇標的？

問：為什麼？

問：一般人的想法是，對找工作、增加錄取率沒幫助的就不學？你呢？你的學習哲學是什麼？

問：Ruby on Rails 主要哪些網站有採用？

問：新手該訂什麼自我學習目標嗎？

問：創業有建議從哪邊切入嗎？

問：但學程式很辛苦吧？可能要一直不斷的學習？

問：所以練習「解決問題」的能力很重要？

問：完全沒有程式底子人也適用？

問：如果我是第一堂來上課的人，你怎麼教？

問：到這裡都還沒寫程式，都是人可以懂的東西？

問：舉例？

問：這是一路學下來的思路與結果？

問：談談撞牆期。有哪一時間點上想放棄？怎麼突破？

問：跟別人學程式的部分？可以舉個例子嗎

問：要怎麼成為厲害工程師？

問：如何讓自己寫程式快速進步？

問：你覺得寫程式會很辛苦嗎？

問：每一種程式的語法都不同？

問：新手要學那種類型？

[RSpec] 一次講清 stub / mock / double / spy

[RSpec] 一次講清 subject , expect , context, is_expected, be_xxx

產品的系統性成長 ( Growth ) 方法

將產品分為幾個階段

使用 NPS 量測：

創業第一階段如何挑選主題，並找到客戶

1) 挑選快速 PMF 主題

2) 建立介紹產品的著陸頁面 ( Landing Page )

3 ) CALL TO ACTION 的後續

4 ) 放上 online chat 軟體

我只关注更在乎这个世界的编程教学法，是否能够被大幅改变