Skip to content

Commit 077965e

Browse files
committed
add milestone
1 parent 0fda63e commit 077965e

File tree

3 files changed

+234
-66
lines changed

3 files changed

+234
-66
lines changed

chapters/11-milestone.md

Lines changed: 62 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,62 @@
1+
GitHub 里程碑
2+
===
3+
4+
写在GitHub 的第 19999 个 star 时
5+
---
6+
7+
> Star 虽好,可不要贪杯哦。
8+
> 两年前在做 Annual Review 订下一年的目标时,想着写一个开源框架。去年订下今年的目标时,仍然继续着这样的想法。今年又要制定下一年的目标,2333~~
9+
10+
不久前,在 GitHub Ranking 上看到自己的 star 数(star 不是设计用于做“点赞”的,而是用来收藏的)时,发现已经快 20000 了。然后把自己的项目过了一遍,发现没有一个比较好的**代表性框架,**要么是应用,要么是电子书。
11+
12+
前 8 个项目里,除了 Growth 应用以外,其他的都是电子书内容——六本电子书加起来的 star 数有 **10619**,果然是骗 star 的。我只能尽力地去想想:为什么事情会变成这样了?
13+
14+
### 从创建开源框架说起
15+
16+
创建开源框架和创建创建开源项目是不一样的,前者你服务于开发者,后者你服务于用户。
17+
18+
两年前在做 Annual Review 的时候,想着未来的一年里可以做一个开源框架试试。那时刚毕业不久,对开源世界的各种游戏规则不是很了解:**开源并不是将代码提交上去,然后就会一下子火起来**。虽然我们可以在短期内赚上一些眼球,但是真正要将它采用到项目上的人不多。
19+
20+
当时,我遇到的最主要的问题是:**想参与到项目的人并没有遇到足够的能力**。你还需要花费大量的时间去教他们,鼓励 GitHub 新手并不是一件容易的事。有时我需要在接受他的 PR 后,再修改他的代码。并且人们提交 PR 可能是出于不同的原因。
21+
22+
然后,知道了开源世界还有一个游戏规则是:**谁的影响力大,谁就能产生更广泛的影响**。如 Virtual Dom 并不是 Facebook 首创的,但是却因为 FB 火的; 松本行弘在写下 mruby 的 README 时(印象中是这个项目),star 数就已经过 1k 了。这种例子数不胜数,要么是在推广上花了力气,要么个人、公司有着更大的影响力。
23+
24+
一年前,稍微改变了下策略:暂时以**培养人为主**,同时想着做一个合适的开源框架——只是在今年看来,前端领域已经没有合适的地方可以造轮子了。
25+
26+
在 GitHub 上有一个很常见的问题是,**大多部分项目的维护者就是发起人**——如果这个发起人发生意外了,那么这个项目怎么办。如果这是一个很火的项目,它就存在着巨大的风险;同时这可能也说明了,缺乏一套合理的机制。
27+
28+
你的开源项目不仅仅需要一个使用文档,还需要一个相关设计思想的文档、路线图、未来计划等等。
29+
30+
去年年底写总结的时候,想到可以 RePractise 文章为基础来培养人,于是就有了 Growth 的三个项目:
31+
32+
- 应用:[Growth](https://github.com/phodal/growth)
33+
- 电子书:《[Growth:全栈增长工程师指南](https://github.com/phodal/growth-ebook)
34+
- 电子书:《[Growth:全栈增长工程师实战](https://github.com/phodal/growth-in-action)
35+
36+
如今 Growth 已经有了过万的用户,每天活跃的用户数也接近 300 了。第一步看上去很成功,但是下一步怎么走呢?
37+
38+
### 下一个开源项目
39+
40+
后来我开始在思索一个问题,创建一个开源框架是必须的吗?
41+
42+
在编写 Growth 电子书的时候,我发现一个好的软件工程实践远远比一个易上手的框架重要多了。框架本身是易变的东西,过去你在用 Backbone,现在你在用 React.js;过去你在用 Angular.js,现在你在用 Vue。会不会使用某个框架,并不是区分你是不是一个有经验的开发者的标准。
43+
44+
一直将焦点关注于**学习不同的框架的使用**是有问题的,一个在校生可以轻松地比你了解某个框架的原理——你白天在工作,而他整天在学习。这时你很容易就失去竞争力了,你需要从框架之外了解更深层次的东西。**一个好的框架并不能让你写出一段好的代码**
45+
46+
> 如果中国人的思想不觉悟,即使治好了他们的病,也只是做毫无意义。
47+
48+
这算是我为自己在 GitHub 下的 Markdown 的自辩吧——谁让我一直有写作的冲动呢。
49+
50+
不过我仍然还有一些想法,只是还没有抽出足够的时间去思考这样的事。
51+
52+
**GNU/Linux 的桌面**。这是几年前的一个想法了,当时 GNU/Linux 的那些操作系统上都没有一个好玩的桌面,不过感觉这个坑太深了,就没有进行了。
53+
54+
**家居智能中心**。我仍然对于大学学的知识有点念念不忘,虽然已经写了一本书,但是硬件还是相当的刺激。唯一的问题是:连房子都没有,怎么做智能家居。
55+
56+
**图形框架**。这是我之前在做一个图形界面的时候,发生没有一个合适的框架可以满足我的要求。然后我就在想,还是自己做一个吧。
57+
58+
不过,最好的开源项目就是自己平时用的。于是,我开始将写各种工作来提自己使用——如现在在用的这篇微信编辑工具:[mdpub](https://github.com/phodal/mdpub)
59+
60+
最后,我做了一个简单的 HTML 5 动画来记录这一时刻,作为这一个里程碑的记念:
61+
62+
[https://phodal.github.io/20k/](https://phodal.github.io/20k/)

github-roam.md

Lines changed: 63 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -2931,3 +2931,66 @@ OnMap项目是为了让我用Nokia Lumia 920拍照的照片,可以在地图上
29312931

29322932
如果你也想提高自己,不妨从创建你的 ideas 项目开始,如我的[Ideas](https://github.com/phodal/ideas)项目一样,上面已经有了大量的 Idea。然后,我们还可以依据这一个个的项目,创建出一本电子书,即 [ideabook](https://github.com/phodal/ideabook)。
29332933

2934+
2935+
GitHub 里程碑
2936+
===
2937+
2938+
写在GitHub 的第 19999 个 star 时
2939+
---
2940+
2941+
> Star 虽好,可不要贪杯哦。
2942+
> 两年前在做 Annual Review 订下一年的目标时,想着写一个开源框架。去年订下今年的目标时,仍然继续着这样的想法。今年又要制定下一年的目标,2333~~
2943+
2944+
不久前,在 GitHub Ranking 上看到自己的 star 数(star 不是设计用于做“点赞”的,而是用来收藏的)时,发现已经快 20000 了。然后把自己的项目过了一遍,发现没有一个比较好的**代表性框架,**要么是应用,要么是电子书。
2945+
2946+
8 个项目里,除了 Growth 应用以外,其他的都是电子书内容——六本电子书加起来的 star 数有 **10619**,果然是骗 star 的。我只能尽力地去想想:为什么事情会变成这样了?
2947+
2948+
### 从创建开源框架说起
2949+
2950+
创建开源框架和创建创建开源项目是不一样的,前者你服务于开发者,后者你服务于用户。
2951+
2952+
两年前在做 Annual Review 的时候,想着未来的一年里可以做一个开源框架试试。那时刚毕业不久,对开源世界的各种游戏规则不是很了解:**开源并不是将代码提交上去,然后就会一下子火起来**。虽然我们可以在短期内赚上一些眼球,但是真正要将它采用到项目上的人不多。
2953+
2954+
当时,我遇到的最主要的问题是:**想参与到项目的人并没有遇到足够的能力**。你还需要花费大量的时间去教他们,鼓励 GitHub 新手并不是一件容易的事。有时我需要在接受他的 PR 后,再修改他的代码。并且人们提交 PR 可能是出于不同的原因。
2955+
2956+
然后,知道了开源世界还有一个游戏规则是:**谁的影响力大,谁就能产生更广泛的影响**。如 Virtual Dom 并不是 Facebook 首创的,但是却因为 FB 火的; 松本行弘在写下 mruby 的 README 时(印象中是这个项目),star 数就已经过 1k 了。这种例子数不胜数,要么是在推广上花了力气,要么个人、公司有着更大的影响力。
2957+
2958+
一年前,稍微改变了下策略:暂时以**培养人为主**,同时想着做一个合适的开源框架——只是在今年看来,前端领域已经没有合适的地方可以造轮子了。
2959+
2960+
在 GitHub 上有一个很常见的问题是,**大多部分项目的维护者就是发起人**——如果这个发起人发生意外了,那么这个项目怎么办。如果这是一个很火的项目,它就存在着巨大的风险;同时这可能也说明了,缺乏一套合理的机制。
2961+
2962+
你的开源项目不仅仅需要一个使用文档,还需要一个相关设计思想的文档、路线图、未来计划等等。
2963+
2964+
去年年底写总结的时候,想到可以 RePractise 文章为基础来培养人,于是就有了 Growth 的三个项目:
2965+
2966+
- 应用:[Growth](https://github.com/phodal/growth)
2967+
- 电子书:《[Growth:全栈增长工程师指南](https://github.com/phodal/growth-ebook)》
2968+
- 电子书:《[Growth:全栈增长工程师实战](https://github.com/phodal/growth-in-action)》
2969+
2970+
如今 Growth 已经有了过万的用户,每天活跃的用户数也接近 300 了。第一步看上去很成功,但是下一步怎么走呢?
2971+
2972+
### 下一个开源项目
2973+
2974+
后来我开始在思索一个问题,创建一个开源框架是必须的吗?
2975+
2976+
在编写 Growth 电子书的时候,我发现一个好的软件工程实践远远比一个易上手的框架重要多了。框架本身是易变的东西,过去你在用 Backbone,现在你在用 React.js;过去你在用 Angular.js,现在你在用 Vue。会不会使用某个框架,并不是区分你是不是一个有经验的开发者的标准。
2977+
2978+
一直将焦点关注于**学习不同的框架的使用**是有问题的,一个在校生可以轻松地比你了解某个框架的原理——你白天在工作,而他整天在学习。这时你很容易就失去竞争力了,你需要从框架之外了解更深层次的东西。**一个好的框架并不能让你写出一段好的代码**
2979+
2980+
> 如果中国人的思想不觉悟,即使治好了他们的病,也只是做毫无意义。
2981+
2982+
这算是我为自己在 GitHub 下的 Markdown 的自辩吧——谁让我一直有写作的冲动呢。
2983+
2984+
不过我仍然还有一些想法,只是还没有抽出足够的时间去思考这样的事。
2985+
2986+
**GNU/Linux 的桌面**。这是几年前的一个想法了,当时 GNU/Linux 的那些操作系统上都没有一个好玩的桌面,不过感觉这个坑太深了,就没有进行了。
2987+
2988+
**家居智能中心**。我仍然对于大学学的知识有点念念不忘,虽然已经写了一本书,但是硬件还是相当的刺激。唯一的问题是:连房子都没有,怎么做智能家居。
2989+
2990+
**图形框架**。这是我之前在做一个图形界面的时候,发生没有一个合适的框架可以满足我的要求。然后我就在想,还是自己做一个吧。
2991+
2992+
不过,最好的开源项目就是自己平时用的。于是,我开始将写各种工作来提自己使用——如现在在用的这篇微信编辑工具:[mdpub](https://github.com/phodal/mdpub)。
2993+
2994+
最后,我做了一个简单的 HTML 5 动画来记录这一时刻,作为这一个里程碑的记念:
2995+
2996+
[https://phodal.github.io/20k/](https://phodal.github.io/20k/)

0 commit comments

Comments
 (0)