From 4366779d3543345f7535cf00efd8a8ceb69359c8 Mon Sep 17 00:00:00 2001 From: Bashamega Date: Thu, 23 May 2024 15:01:57 +0300 Subject: [PATCH] route update --- chapters/01-start-project.md | 4 +-- chapters/02-github-fundamentals.md | 12 +++---- chapters/05-create-project-documents.md | 6 ++-- chapters/06-refactor-project.md | 2 +- chapters/08-github-marketing.md | 22 ++++++------ chapters/10-git-tools.md | 8 ++--- chapters/11-analytics.md | 10 +++--- chapters/13-read-code.md | 16 ++++----- chapters/14-streak-your-github.md | 46 ++++++++++++------------- chapters/18-get-star.md | 10 +++--- chapters/readme.md | 4 +-- 11 files changed, 70 insertions(+), 70 deletions(-) diff --git a/chapters/01-start-project.md b/chapters/01-start-project.md index 7e200a8..6d246fb 100644 --- a/chapters/01-start-project.md +++ b/chapters/01-start-project.md @@ -31,7 +31,7 @@ 如下是不同开源许可证的市场占有率及使用情况。 -![License 使用情况](./img/permissive-vs-copylift-license-2.jpg) +![License 使用情况](../img/permissive-vs-copylift-license-2.jpg) 又比如，在我们看到的一些外版书籍上，如果拥有代码。那么作者一般就会在前言或者类似的位置里，指明书中代码的版权所属。如： @@ -39,7 +39,7 @@ 于是，选择一个合理的 LICENSE，就变成了一个有趣的话题。为此，笔者做了一个如何进行开源协议选型的流程图： -[![如何选择 License](./img/licenses.png)](https://github.com/phodal/licenses) +[![如何选择 License](../img/licenses.png)](https://github.com/phodal/licenses) 简单地来说，这些 License 之间是一些权利的区别，如当你把代码放置到公有领域，就意味着任何人可以修改，并且不需要标明出注；可如果你想要别人标明出处及作者，你就需要 MIT 协议；而你希望别人闭源的话，那么你就需要 MPL 协议等等。 diff --git a/chapters/02-github-fundamentals.md b/chapters/02-github-fundamentals.md index 76a92df..61b6b41 100644 --- a/chapters/02-github-fundamentals.md +++ b/chapters/02-github-fundamentals.md @@ -56,11 +56,11 @@ $git status 来看现在的状态，如下图是添加之前的： -![Before add](./img/before-add.png) +![Before add](../img/before-add.png) 下面是添加之后 的 -![After add](./img/after-add.png) +![After add](../img/after-add.png) 可以看到状态的变化是从黄色到绿色，即 unstage 到 add。 @@ -111,11 +111,11 @@ jQuery[^jQuery] 在发布版本``2.1.3``，一共有 152 个 commit。我们可 接着,我们试试在上面创建一个项目： -![GitHub Roam](./img/github-roam-create.jpg) +![GitHub Roam](../img/github-roam-create.jpg) 就会有下面的提醒： -![GitHub Roam](./img/project-init.jpg) +![GitHub Roam](../img/project-init.jpg) 它提供多种方式的创建方法： @@ -208,10 +208,10 @@ CLA 即 Contributor License Agreement，在为一些大的组织、机构提交 以下是我为 Google 提交的一个 PR -![Google CLA](./img/google-cla.png) +![Google CLA](../img/google-cla.png) 以及 Eclipse 的一个 PR -![Eclipse CLA](./img/eclipse-cla.png) +![Eclipse CLA](../img/eclipse-cla.png) 他们都要求我签署 CLA。 diff --git a/chapters/05-create-project-documents.md b/chapters/05-create-project-documents.md index f653dc5..69525b0 100644 --- a/chapters/05-create-project-documents.md +++ b/chapters/05-create-project-documents.md @@ -9,19 +9,19 @@ 通常这个会在项目的最上方会有一个项目的简介，如下图所示： -![GitHub Project Introduction](./img/github-intro.png) +![GitHub Project Introduction](../img/github-intro.png) ## README README 通常会显示在 GitHub 项目的下面，如下图所示： -![GitHub README](./img/readme-example.png) +![GitHub README](../img/readme-example.png) 通常一个好的 README 会让你立马对项目产生兴趣。 如下面的内容是 React 项目的简介： -![React README](./img/react-intro.png) +![React README](../img/react-intro.png) 下面的内容写清楚了他们的用途： diff --git a/chapters/06-refactor-project.md b/chapters/06-refactor-project.md index 4e736f8..c87ecbc 100644 --- a/chapters/06-refactor-project.md +++ b/chapters/06-refactor-project.md @@ -335,7 +335,7 @@ public class replaceTemp { 选中 ``basePrice`` 很愉快地拿鼠标点上面的重构 -![Replace Temp With Query](./img/replace.jpg) +![Replace Temp With Query](../img/replace.jpg) 便会返回 diff --git a/chapters/08-github-marketing.md b/chapters/08-github-marketing.md index ad57838..b7a21f7 100644 --- a/chapters/08-github-marketing.md +++ b/chapters/08-github-marketing.md @@ -33,7 +33,7 @@ Vue 不是因为好用，而一下子火了。这一点我印象特别深，当 除此，还有一种可能是，你的 ID 不够 fancy，即你在社区的影响上比较少。此时，就需要**一点点慢慢积累人气**了。当你积累了一些人气，你就能和松本行弘一样，在创建 mRuby 的时候就有 1000+ 的 Star。并且，在社区上还有一些相关的文章介绍，各个头条也由他的粉丝发了上去。如，一年多以前，我创建了 [mole](https://github.com/phodal/mole) 项目。 -![Mole](./img/mole.png) +![Mole](../img/mole.png) 当时，是为了给自己做一个基于 GitHub 云笔记的工具，在完成度到一定程度的时候。我在我的微信公从号上发了相关的介绍，第二天就有 100+ 的 Star 了，还接收到一些鼓舞的话语。对应于国内则有： @@ -60,7 +60,7 @@ Vue 不是因为好用，而一下子火了。这一点我印象特别深，当 GitHub 的 Description 是我们在 Hacking News、GitHub Trneding 等等，第一时间看到的介绍。也是我们能快速介绍给别人的东西，如下图所示： -![GitHub Trending](./img/github-trending-example.png) +![GitHub Trending](../img/github-trending-example.png) 这一句话，必须简单明了也介绍，它是干什么的。 @@ -78,7 +78,7 @@ Vue 则是：A progressive, incrementally-adoptable JavaScript framework for bui > Most machines on internet communicate with each other via TCP/IP. However TCP/IP only guarantees reliable data transmissions, we need to abstract more to build services: -![RPC 开源项目](./img/rpc-example.png) +![RPC 开源项目](../img/rpc-example.png) 以上便是这个项目能解决的问题，不过这个项目能解决的问题倒是比较长，哈哈哈。 @@ -86,7 +86,7 @@ Vue 则是：A progressive, incrementally-adoptable JavaScript framework for bui 当我们有 A、B、C 几个不同的框架的时候，作为一个开发人员，就需要对比他们的特性。如下是 Go 语言实现的 MQTT 示例： -![GO MQTT 示例](./img/go-mqtt.png) +![GO MQTT 示例](../img/go-mqtt.png) 这个项目只支持的 Qos 级别为 0。如果我们需要的级别是 1，那么就不能用这个项目了。 @@ -101,7 +101,7 @@ numbers, objects, strings, etc. Lodash’s modular methods are great for: 你会怎么写？脸皮够厚的话，可以直接写一下，与其它项目的对比，blabla： -![对比其它项目](./img/comparison.png) +![对比其它项目](../img/comparison.png) 当然了，这种事不能太过，要不然会招来一堆黑。 @@ -131,7 +131,7 @@ app.listen(3000); 好在这里的安装工作只有两步，而不是： -![Lan 安装过程](./img/lan-example.png) +![Lan 安装过程](../img/lan-example.png) 对于那些需要复杂的安装过程的软件，应该简化安装过程，如提供 Docker 镜像，或者直接提供一个可运行的 Demo 环境。以免用户在看完 README 之后，直接放弃了使用该库。 @@ -142,7 +142,7 @@ app.listen(3000); 由于，之前在某一个项目，经历过一个第三方 API 文档的大坑——文档中只罗列了 API 的用法。如下 Intellij Idea 生成的结构图： -![API 示例](./img/api-examples.png) +![API 示例](../img/api-examples.png) 文档中上，罗列了每个函数，以及每个函数需要的参数。我使用 Intellij Idea 直接反编译 jar 包，看到的信息都比文档多多了。文档上，没有任务示例，甚至连怎么初始化这个库的代码都没有。 @@ -152,7 +152,7 @@ WTF！ 对于一个复杂的开源项目来说，文档上要写明安装、编译、配置等等的过程。如下图所示： -![Python Social Auth 文档](./img/python-social-auth-example.png) +![Python Social Auth 文档](../img/python-social-auth-example.png) 并且在我们发布包的时候，就要不断地去重复这个过程——如果你使用了自动化测试，那么这个过程便自动完成了。 @@ -160,7 +160,7 @@ WTF！ 并且，我们可以将文档直接入到代码里。它可以有效地减少文档不同步，带来的一些问题。 -![Lodash 示例](./img/lodash-code-example.png) +![Lodash 示例](../img/lodash-code-example.png) 上图是使用了 JSDoc 的 Lodash 示例。 @@ -172,7 +172,7 @@ WTF！ 反正，除了一个 hello, world，你还要有各种场景下的示例： -![Redux](./img/redux-examples.png) +![Redux](../img/redux-examples.png) 没有这么多示例，敢说自己是好用的开源项目？ @@ -193,7 +193,7 @@ WTF！ 这一点可以在 README，以及介绍上体现： -![Feel free to contribute!](./img/feel-free-to.png) +![Feel free to contribute!](../img/feel-free-to.png) 哪怕只是一个错误字的 PR，那么你也可以 merge，啊哈哈~。然后，就有人帮你宣传了，『我给 xxx 项目一个 PR 了』。刚毕业的时候，我也是从这种类型的 PR 做起的~~。 diff --git a/chapters/10-git-tools.md b/chapters/10-git-tools.md index 6cb94c2..17a9fd1 100644 --- a/chapters/10-git-tools.md +++ b/chapters/10-git-tools.md @@ -8,7 +8,7 @@ Git 命令行增强 ### [diff-so-fancy](https://github.com/so-fancy/diff-so-fancy) -![diff so fancy 截图](./img/git-diff-screenshot.png) +![diff so fancy 截图](../img/git-diff-screenshot.png) ### [git-extras](https://github.com/tj/git-extras) @@ -66,11 +66,11 @@ SourceTree 方便用来查看一些非我写的项目，寻找其中的一些问 gitflow 分支合并、查看 -![SourceTree 截图](./img/sourcetree.jpg) +![SourceTree 截图](../img/sourcetree.jpg) ### GitHub Desktop -![GitHub Desktop](./img/github-desktop.jpg) +![GitHub Desktop](../img/github-desktop.jpg) Git 娱乐 --- @@ -132,4 +132,4 @@ Set up your git name and email, this is important so that your commits can be id ### Gource -![Gource 历史](./img/gource.jpg) +![Gource 历史](../img/gource.jpg) diff --git a/chapters/11-analytics.md b/chapters/11-analytics.md index b92ca09..1f28638 100644 --- a/chapters/11-analytics.md +++ b/chapters/11-analytics.md @@ -10,7 +10,7 @@ 最后效果图 -![2014 01 01](./img/2014-01-01.png) +![2014 01 01](../img/2014-01-01.png) 要解析的 JSON 文件位于``data/2014-01-01-0.json``，大小 6.6M，显然我们可能需要用每次只读一行的策略，这足以解释为什么诸如 sublime 打开的时候很慢，而现在我们只需要里面的 JSON 数据中的创建时间。。 @@ -138,7 +138,7 @@ draw_date("data/2014-01-01-0.json") 继上篇之后，我们就可以分析用户的每周提交情况，以得出用户的真正的工具效率，每个程序员的工作时间可能是不一样的，如 -![Phodal Huang's Report](./img/phodal-results.png) +![Phodal Huang's Report](../img/phodal-results.png) 这是我的每周情况，显然如果把星期六移到前面的话，随着工作时间的增长，在 GitHub 上的使用在下降，作为一个 @@ -150,7 +150,7 @@ draw_date("data/2014-01-01-0.json") 看一张分析后的结果 -![Feb Results](./img/feb-results.png) +![Feb Results](../img/feb-results.png) 结果正好与我的情况相反？似乎图上是这么说的，但是数据上是这样的情况。 @@ -446,7 +446,7 @@ pipe.execute() 结果大致如下图所示： -![SMTWTFS](./img/smtwtfs.png) +![SMTWTFS](../img/smtwtfs.png) 看看主要的事件是？ @@ -456,7 +456,7 @@ pipe.execute() [[('PushEvent', 154.0), ('CreateEvent', 41.0), ('WatchEvent', 18.0), ('GollumEvent', 8.0), ('MemberEvent', 3.0), ('ForkEvent', 2.0), ('ReleaseEvent', 1.0)]] >>> -![Main Event](./img/main-events.png) +![Main Event](../img/main-events.png) 蓝色的就是 push 事件，黄色的是 create 等等。 diff --git a/chapters/13-read-code.md b/chapters/13-read-code.md index 9cef3ac..9277135 100644 --- a/chapters/13-read-code.md +++ b/chapters/13-read-code.md @@ -18,11 +18,11 @@ 在我阅读的前端库、Python 后台库的过程中，我们都是以造轮子为目的展开的。所以在最开始的时候，我需要一个可以工作，并且拥有我想要的功能的版本。 -![it-works-cms.png](./img/it-works-cms.png) +![it-works-cms.png](../img/it-works-cms.png) 紧接着，我就可以开始去实践这个版本中的一些功能，并理解他们是怎么工作的。再用 `git` 大法展开之前修改的内容，可以使用 IDE 自带的 Diff 工具： -![pycharm-diff.jpg](./img/pycharm-diff.jpg) +![pycharm-diff.jpg](../img/pycharm-diff.jpg) 或者类似于 `SourceTree` 这样的工具，来查看修改的内容。 @@ -33,7 +33,7 @@ 我最早阅读的开源软件是 Linux，而下面则是 Linux 的 Release 过程： -![linux-history.png](./img/linux-history.png) +![linux-history.png](../img/linux-history.png) 表格源自一本书叫《Linux内核0.11(0.95)完全注释》，简单地再介绍一下： @@ -61,25 +61,25 @@ 一、先 Clone 它。 -![clone-flask.png](./img/clone-flask.png) +![clone-flask.png](../img/clone-flask.png) 二、从 Release 页面找到它的早期版本： -![flask.png](./img/flask.png) +![flask.png](../img/flask.png) 三、 从上面拿到它的提交号 `8605cc3`，然后 checkout 到这次提交，查看功能。在这个版本里，一共有六百多行代码 -![flask-0.1.png](./img/flask-0.1.png) +![flask-0.1.png](../img/flask-0.1.png) 还是有点长 四、我们可以找到它的最早版本： -![flask-init.png](./img/flask-init.png) +![flask-init.png](../img/flask-init.png) 然后查看它的 `flask.py` 文件，只有简单的三百多行，并且还包含一系列注释： -![flask-init.png](./img/flask-init.png) +![flask-init.png](../img/flask-init.png) 五、接着，再回过头去阅读 diff --git a/chapters/14-streak-your-github.md b/chapters/14-streak-your-github.md index 6f2eb62..4d55b7b 100644 --- a/chapters/14-streak-your-github.md +++ b/chapters/14-streak-your-github.md @@ -5,7 +5,7 @@ GitHub 连击 我也是蛮拼的，虽然我想的只是在 GitHub 上连击 100~200 天，然而到了今天也算不错。 -![Longest Streak](./img/longest-streak.png) +![Longest Streak](../img/longest-streak.png) ``在不停地造轮子的过程中，也不停地造车子。`` @@ -17,7 +17,7 @@ GitHub 连击 对比了一下 365 天连击的 commit，我发现我在 total 上整整多了近 0.5 倍。 -![365 Streak](./img/365-streak.jpg) +![365 Streak](../img/365-streak.jpg) 同时这似乎也意味着，我每天的 commit 数与之相比多了很多。 @@ -43,7 +43,7 @@ GitHub 连击 这也就是为什么那个 repo 有这样的一行： -![Repo Status](./img/repo-status.png) +![Repo Status](../img/repo-status.png) 做到 98% 的覆盖率也算蛮拼的，当然还有 Code Climate 也达到了 4.0，也有了 112 个 commits。因此也带来了一些提高： @@ -57,7 +57,7 @@ GitHub 连击 有意思的是越到中间的一些时间，commits 的次数上去了，除了一些简单的 pull request，还有一些新的轮子出现了。 -![Problem](./img/problem.jpg) +![Problem](../img/problem.jpg) 这是上一星期的 commits，这也就意味着，在一星期里面，我需要在 8 个 repo 里切换。而现在我又有了一个新的 idea，这时就发现了一堆的问题： @@ -84,7 +84,7 @@ GitHub 连击 今天是我连续泡在 GitHub 上的第200天，也是蛮高兴的，终于到达了： -![GitHub 200 days](./img/github-200-days.png) +![GitHub 200 days](../img/github-200-days.png) 故事的背影是：去年国庆完后要去印度接受毕业生培训——就是那个神奇的国度。但是在去之前已经在项目待了九个多月，项目上的挑战越来越少，在印度的时间又算是比较多。便给自己设定了一个长期的 goal，即 100~200 天的 longest streak。 @@ -128,7 +128,7 @@ GitHub 连击 [Google Maps solr polygon 搜索](http://www.phodal.com/blog/google-map-width-solr-use-polygon-search/) -![Google Maps solr](./img/solr.png) +![Google Maps solr](../img/solr.png) 代码：[https://github.com/phodal/gmap-solr](https://github.com/phodal/gmap-solr) @@ -145,7 +145,7 @@ GitHub 连击 - jQuery - Gulp -![Skill Tree](./img/skilltree.jpg) +![Skill Tree](../img/skilltree.jpg) 代码：[https://github.com/phodal/skillock](https://github.com/phodal/skillock) @@ -159,13 +159,13 @@ GitHub 连击 - Knockout.js - Require.js -![Sherlock skill tree](./img/sherlock.png) +![Sherlock skill tree](../img/sherlock.png) 代码：[https://github.com/phodal/sherlock](https://github.com/phodal/sherlock) #### Django Ionic ElasticSearch 地图搜索 -![Django Elastic Search](./img/elasticsearch_ionit_map.jpg) +![Django Elastic Search](../img/elasticsearch_ionit_map.jpg) - ElasticSearch - Django @@ -176,7 +176,7 @@ GitHub 连击 #### 简历生成器 -![Resume](./img/resume.png) +![Resume](../img/resume.png) - React - jsPDF @@ -189,7 +189,7 @@ GitHub 连击 #### Nginx 大数据学习 -![Nginx Pig](./img/nginx_pig.jpg) +![Nginx Pig](../img/nginx_pig.jpg) - ElasticSearch - Hadoop @@ -224,7 +224,7 @@ GitHub 连击 > 给你一年的时间，你会怎样去提高你的水平？？？ -![GitHub 365](./img/github-365.jpg) +![GitHub 365](../img/github-365.jpg) 正值这难得的 sick leave（万恶的空气），码文一篇来记念一个过去的 366 天里。尽管想的是在今年里写一个可持续的开源框架，但是到底这依赖于一个好的 idea。在我的 [GitHub 孵化器](http://github.com/phodal/ideas) 页面上似乎也没有一个特别让我满意的想法，虽然上面有各种不样有意思的 ideas。多数都是在过去的一年是完成的，然而有一些也是还没有做到的。 @@ -256,9 +256,9 @@ GitHub 连击 在我写 [EchoesWorks](https://github.com/echoesworks/echoesworks) 和 [Lan](https://github.com/phodal/lan) 的过程中，我尽量去保证足够高的测试覆盖率。 -![lan](./img/lan.png) +![lan](../img/lan.png) -![EchoesWorks](./img/echoesworks.png) +![EchoesWorks](../img/echoesworks.png) 从测试开始的 TDD，会保证方法是可测的。从功能到测试则可以提供工作次效率，但是只会让测试成为测试，而不是代码的一部分。 @@ -295,7 +295,7 @@ GitHub 连击 我在写 [lan](https://github.com/phodal/lan) 的时候，也是类似的，但是不同的是我已经设计了一个清晰的架构图。 -![Lan IoT](./img/lan-iot.jpg) +![Lan IoT](../img/lan-iot.jpg) 而在我们实现的编码过程也是如此，使用不同的框架，并且让他们能工作。如早期玩的 [moqi.mobi](https://github.com/echoesworks/moqi.mobi)，基于 Backbone、RequireJS、Underscore、Mustache、Pure CSS。在随后的时间里，用 React 替换了 View 层，就有了 [backbone-react](https://github.com/phodal/backbone-react) 的练习。 @@ -341,7 +341,7 @@ GitHub 连击 当然如果你连做梦也在写代码的话，那么我想 500 天就够了，哈哈~~。 -![Gtihub 500](./img/github-500.jpg) +![Gtihub 500](../img/github-500.jpg) 虽然不是连击次数最多的，但是根据 [Most active GitHub users ](http://git.io/top) 的结果来说，好似是大陆提交数最多的人，没有之一。再考虑到提交都是有意义的——不是机器刷出来的，不是有意识的去刷，我觉得还是有很大成就感的。 @@ -357,7 +357,7 @@ GitHub 连击 如下图所示的就是情绪周期： -![情绪周期](./img/qingxu.jpg) +![情绪周期](../img/qingxu.jpg) 简单地来说，就是**有一个时间段写代码的感觉超级爽，有一个时间段不想写代码**，但是如果换一个说法就是：**有一个时间段看书、写文档的感觉很爽，有一时间段不想看书、写文档的感觉**。这也就是为什么在我的GitHub首页上的绿色各种花。不过因为《物联网周报》的原因，我会定期地更新一个相关的开源项目。 @@ -376,7 +376,7 @@ GitHub 连击 在一些日子的练习后，我发现这还是太无聊了。天生就喜欢一些有意思的东西，有趣才更有激情吧~~。不过，像下图的打字练习还是挺有意思的： -![打字练习](./img/huovd.png) +![打字练习](../img/huovd.png) 还是能打出了一堆错误的字符。但是对比了一下大多数人的人，还算不错，至少是盲打。但是，还是存在着很大的提升空间。 @@ -412,7 +412,7 @@ THE ONLY FAIR IS NOT FAIR . ENJOY CREATE & SHARE. 而这些并不是一种容易的事，很多时候有一些模式，我们都很难有一个好的实践。只是这些东西都不是一些可以生搬硬套的，我们更需要的是知道有这些东西的存在，以便于在某一天，我们可以从我们的仓库里将这些知识取出来。 -![10000 hours](./img/10000.png) +![10000 hours](../img/10000.png) 我们的刻意练习加上我们的持之以恒总是会取得长足的进步。不过在我们练习之前，你需要有一个目标。这个目标可以是一个 Idea、一个设计模式、一个模仿等等，这些内容都可以以 Issue 的好好管理着。 @@ -425,7 +425,7 @@ THE ONLY FAIR IS NOT FAIR . ENJOY CREATE & SHARE. 通常在这种情况下，我们知道自己不知道什么东西，当我们处于不知道自己不知道、不知道自己知道时，那我们就需要网上的各种技能图谱——如StuQ的技能图谱。 -![skilmap](./img/skillmap.png) +![skilmap](../img/skillmap.png) 然后了解图谱上的一个个的内容，尽可能依照此构建自己的体系——以让自己走向知道自己不知道的地步，然后我们才依此来展开练习。 @@ -437,7 +437,7 @@ THE ONLY FAIR IS NOT FAIR . ENJOY CREATE & SHARE. 时间：2014.10.08-2014.12.30 -![2014.png](./img/2014.png) +![2014.png](../img/2014.png) 在这一段时间里，我创建的项目大部分都是一些物联网项目： @@ -458,7 +458,7 @@ OnMap 项目是为了让我用 Nokia Lumia 920 拍照的照片，可以在地图 #### 2015年 -![2015.png](./img/2015.png) +![2015.png](../img/2015.png) 整个区间就是刷各种前端的技术栈，创建了各种有意思的项目： @@ -478,7 +478,7 @@ OnMap 项目是为了让我用 Nokia Lumia 920 拍照的照片，可以在地图 #### 2016 年 -![2016.png](./img/2016.png) +![2016.png](../img/2016.png) 我们有了 Growth 系列的电子书、App，还有 Mole，几个极具代表性的项目就够了。 diff --git a/chapters/18-get-star.md b/chapters/18-get-star.md index ad459cf..06fc6a0 100644 --- a/chapters/18-get-star.md +++ b/chapters/18-get-star.md @@ -34,7 +34,7 @@ GitHub 是一个非常有意思的地方，也常常变得非常有争议。有 因此开始之前，我们先看张图就能知道怎么获取流量。如下是《GitHub 漫游指南》最近两周内的流量来源统计（GitHub 通过 Google Analysis 来统计）： -![GitHub 漫游指南](./img/github_traffic.png) +![GitHub 漫游指南](../img/github_traffic.png) 从上图中可以看出，流量主要来源于几部分： @@ -46,7 +46,7 @@ GitHub 是一个非常有意思的地方，也常常变得非常有争议。有 总的来说，在这一周里，累计有 1,266 次访问，其中有 735 个独立访客。看这数据不错，而实际上 Star 率 就有点低。根据 Star History 网站（https://star-history.t9t.io ） 的统计，在过去的近两个月里，才涨了 38 个 Star。 -![GitHub 漫游指南 Star 历史](./img/github-star-history.png) +![GitHub 漫游指南 Star 历史](../img/github-star-history.png) 从我的分析来看，大抵原因有两个： @@ -55,7 +55,7 @@ GitHub 是一个非常有意思的地方，也常常变得非常有争议。有 而我最近在玩的 New Project Checklist（[https://github.com/phodal/new-project-checklist](https://github.com/phodal/new-project-checklist) 的转化率看上去，还算可以： -![GitHub New Project Checklist](./img/github-new-project-checklist.png) +![GitHub New Project Checklist](../img/github-new-project-checklist.png) 在 999 个独立访客里，获得了 202 个 Star，转化率差不多是 20%——大家真的对这个项目感兴趣。 @@ -73,7 +73,7 @@ GitHub 是一个非常有意思的地方，也常常变得非常有争议。有 实际上，在上一小节里，我们已经介绍了相关的内容。若是想获得来自于 Google 等搜索引擎的访问，那么要掌握的技巧有： -![Google New Project Checklist](./img/google-new-project-checklist.png) +![Google New Project Checklist](../img/google-new-project-checklist.png) - 简单实用的项目名。项目名在 Google 搜索结果里是放在最前面的部分，它与 URL 同在。 - 写好项目的 ``Description``。不管怎样，你一定要为你的项目写好 Description，让看到的人知道它在做什么。 @@ -107,7 +107,7 @@ GitHub 是一个人的简历，**而开源项目的 README，就好像是一个 **更新状态**。当我在写一个大家感兴趣的开源项目时， 我会在我的社交账号上，如微博、知乎想法，定期的更新相关的状态。诸如： -![微博 MoPass](./img/mopass-weibo.png) +![微博 MoPass](../img/mopass-weibo.png) 万一有人感兴趣，就会随之而来——主要是我也不知道微博要怎么玩。 diff --git a/chapters/readme.md b/chapters/readme.md index 60897d6..bf49ea3 100644 --- a/chapters/readme.md +++ b/chapters/readme.md @@ -38,7 +38,7 @@ 我的微信公众号： -![作者微信公众号：phodal-weixin](./img/wechat.jpg) +![作者微信公众号：phodal-weixin](../img/wechat.jpg) 我的 GitHub 主页上写着加入的时间——``Joined on Nov 8, 2010``，那时才大一，在那之后的那么长的日子里我都没有登录过。也许是因为我学的不是计算机，到了今天——``2015.3.9``，我才发现这其实是程序员的社交网站。 @@ -68,7 +68,7 @@ 当然，后来是审阅完了，书上有我的英文简介。 -![Phodal Huang Introduction](./img/phodal-intro.jpg) +![Phodal Huang Introduction](../img/phodal-intro.jpg) 一个月前，收到 MANNING 出版社的邮件（PS：也是在 GitHub 上），关于 Review 一本[物联网](iot)书籍的目录，并提出建议。