Skip to content

Commit dbfd72e

Browse files
phodalphodal
committed
fix title
1 parent 27b3928 commit dbfd72e

File tree

5 files changed

+33
-49
lines changed

5 files changed

+33
-49
lines changed

‎chapters/01-introduction.md

Lines changed: 6 additions & 9 deletions
Original file line numberDiff line numberDiff line change
@@ -25,7 +25,6 @@ Wiki百科上是这么说的
2525

2626
等等。看上去像是大餐，但是你还需要了解点什么?
2727

28-
2928
###版本管理与软件部署
3029

3130
jQuery[^jQuery]在发布版本``2.1.3``，一共有152个commit。我们可以看到如下的提交信息:
@@ -36,8 +35,7 @@ jQuery[^jQuery]在发布版本``2.1.3``，一共有152个commit。我们可以
3635
- Build: Move test to appropriate module fbdbb6f
3736
- Build: Update commitplease dev dependency
3837
- ...
39-
40-
38+
4139
###Github与Git
4240

4341
> Git是一个分布式的版本控制系统，最初由Linus Torvalds编写，用作Linux内核代码的管理。在推出后，Git在其它项目中也取得了很大成功，尤其是在Ruby社区中。目前，包括Rubinius、Merb和Bitcoin在内的很多知名项目都使用了Git。Git同样可以被诸如Capistrano和Vlad the Deployer这样的部署工具所使用。
@@ -46,8 +44,7 @@ jQuery[^jQuery]在发布版本``2.1.3``，一共有152个commit。我们可以
4644
4745
[^jQuery]: jQuery是一套跨浏览器的JavaScript库，简化HTML与JavaScript之间的操作。
4846

49-
##提高
50-
47+
##用好Github
5148

5249
###敏捷软件开发
5350

@@ -64,7 +61,7 @@ jQuery[^jQuery]在发布版本``2.1.3``，一共有152个commit。我们可以
6461
6562
当只有一个人的时候，你只需要明确知道自己想要什么就够了。我们还需要的是CI、测试，以来提升代码的质量。
6663

67-
##测试
64+
###测试
6865

6966
通常我们都会找Document，如果没有的话，你会找什么?看源代码，还是看测试?
7067

@@ -122,7 +119,7 @@ lettuce.js | 98.58% (209 / 212)| 82.98%(78 / 94) | 100.00% (54 / 54) | 98.58% (2
122119

123120
本地测试都通过了，于是我们添加了``Travis-CI``来跑我们的测试
124121

125-
##CI
122+
###CI
126123

127124
虽然node.js不算是一门语言，但是因为我们用的node，下面的是一个简单的``.travis.yml``示例:
128125

@@ -144,7 +141,7 @@ lettuce.js | 98.58% (209 / 212)| 82.98%(78 / 94) | 100.00% (54 / 54) | 98.58% (2
144141

145142
CI对于一个开发者在不同城市开发同一项目上来说是很重要的，这意味着当你添加的部分功能有测试覆盖的时候，项目代码会更加强壮。
146143

147-
##代码质量
144+
###代码质量
148145

149146
像``jslint``这类的工具，只能保证代码在语法上是正确的，但是不能保证你写了一堆bad smell的代码。
150147

@@ -193,7 +190,7 @@ CI对于一个开发者在不同城市开发同一项目上来说是很重要的
193190

194191
这就意味着我们可以对上面的代码进行重构，他们是重复的代码。
195192

196-
##重构
193+
###重构
197194

198195
不想在这里说太多关于``重构``的东西，可以参考Martin Flower的《重构》一书去多了解一些重构的细节。
199196

‎chapters/02-github-fundamentals.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -1,4 +1,4 @@
1-
#基本知识
1+
#Git基本知识与Github使用
22

33
##Git
44

‎chapters/03-analytics-01.md

Lines changed: 7 additions & 10 deletions
Original file line numberDiff line numberDiff line change
@@ -1,11 +1,8 @@
11
#Github项目分析一
22

3-
##用matplotlib生成图表
3+
##生成图表
44

5-
如何分析用户的数据是一个有趣的问题，特别是当我们有大量的数据的时候。
6-
除了``matlab``，我们还可以用``numpy``+``matplotlib``
7-
8-
###python github用户数据分析##
5+
如何分析用户的数据是一个有趣的问题，特别是当我们有大量的数据的时候。除了``matlab``，我们还可以用``numpy``+``matplotlib``
96

107
数据可以在这边寻找到
118

@@ -17,11 +14,11 @@
1714

1815
要解析的json文件位于``data/2014-01-01-0.json``，大小6.6M，显然我们可能需要用每次只读一行的策略，这足以解释为什么诸如sublime打开的时候很慢，而现在我们只需要里面的json数据中的创建时间。。
1916

20-
==这个文件代表什么？
17+
==,这个文件代表什么？
2118

2219
**2014年1月1日零时到一时，用户在github上的操作，这里的用户指的是很多。。一共有4814条数据，从commit、create到issues都有。**
2320

24-
###python json文件解析##
21+
###数据解析
2522

2623
```python
2724
import json
@@ -70,7 +67,7 @@ minuteswithcount = [(x, dataarray.count(x)) for x in set(dataarray)]
7067
[(0, 92), (1, 67), (2, 86), (3, 73), (4, 76), (5, 67), (6, 61), (7, 71), (8, 62), (9, 71), (10, 70), (11, 79), (12, 62), (13, 67), (14, 76), (15, 67), (16, 74), (17, 48), (18, 78), (19, 73), (20, 89), (21, 62), (22, 74), (23, 61), (24, 71), (25, 49), (26, 59), (27, 59), (28, 58), (29, 74), (30, 69), (31, 59), (32, 89), (33, 67), (34, 66), (35, 77), (36, 64), (37, 71), (38, 75), (39, 66), (40, 62), (41, 77), (42, 82), (43, 95), (44, 77), (45, 65), (46, 59), (47, 60), (48, 54), (49, 66), (50, 74), (51, 61), (52, 71), (53, 90), (54, 64), (55, 67), (56, 67), (57, 55), (58, 68), (59, 91)]
7168
```
7269

73-
##matplotlib
70+
###Matplotlib
7471

7572
开始之前需要安装``matplotlib
7673

@@ -186,7 +183,7 @@ draw_date("data/2014-01-01-0.json")
186183
8474, 7984, 12933, 13504, 13763, 13544, 12940,
187184
7119, 7346, 13412, 14008, 12555
188185

189-
###python 数据分析
186+
###Python 数据分析
190187

191188
重写了一个新的方法用于计算提交数，直至后面才意识到其实我们可以算行数就够了，但是方法上有点hack
192189

@@ -235,7 +232,7 @@ def get_month_total():
235232

236233
接着我们需要去遍历每个结果，后面的后面会发现这个效率真的是太低了，为什么木有多线程？
237234

238-
###python matplotlib图表
235+
###Python Matplotlib图表
239236

240237
让我们的matplotlib来做这些图表的工作
241238

‎chapters/04-analytics-02.md

Lines changed: 9 additions & 21 deletions
Original file line numberDiff line numberDiff line change
@@ -3,7 +3,7 @@
33

44
让我们分析之前的程序，然后再想办法做出优化。网上看到一篇文章[http://www.huyng.com/posts/python-performance-analysis/](http://www.huyng.com/posts/python-performance-analysis/)讲的就是分析这部分内容的。
55

6-
##time python分析
6+
##Time Python分析
77

88
分析程序的运行时间
99

@@ -21,9 +21,6 @@ $time python handle.py
2121

2222
##line_profiler python
2323

24-
这是
25-
##Mac OS X 10.9 line_profiler Install##
26-
2724
```bash
2825
sudo ARCHFLAGS="-Wno-error=unused-command-line-argument-hard-error-in-future" easy_install line_profiler
2926
```
@@ -85,17 +82,15 @@ Line # Hits Time Per Hit % Time Line Contents
8582

8683
于是我们就发现我们的瓶颈就是从读取``created_at``，即创建时间。。。以及解析json，反而不是我们关心的IO，果然``readline``很强大。
8784

88-
##memory_profiler python
85+
##memory_profiler
8986

90-
###memory_profiler install
87+
首先我们需要install memory_profiler:
9188

9289
```bash
9390
$ pip install -U memory_profiler
9491
$ pip install psutil
9592
```
9693

97-
###memory_profiler python
98-
9994
如上，我们只需要在``handle_json``前面加上``@profile``
10095

10196
```bash
@@ -128,7 +123,7 @@ Line # Mem usage Increment Line Contents
128123

129124
##objgraph python
130125

131-
###objgraph install
126+
安装objgraph
132127

133128
```bash
134129
pip install objgraph
@@ -226,8 +221,6 @@ def get_count(username):
226221

227222
这个数据库文件有**905M**，不过查询结果相当让人满意，至少相对于原来的结果来说。
228223

229-
##Python SQLite3
230-
231224
Python自带了对SQLite3的支持，然而我们还需要安装SQLite3
232225

233226
```bash
@@ -254,7 +247,7 @@ sudo zypper install sqlite3
254247

255248
不过，用yast2也很不错，不是么。。
256249

257-
##Pythont Github Sqlite3数据导入
250+
###数据导入
258251

259252
需要注意的是这里是需要python2.7，起源于对gzip的上下文管理器的支持问题
260253

@@ -310,8 +303,6 @@ def build_db_with_gzip():
310303
311304
``executemany``可以插入多条数据，对于我们的数据来说，一小时的文件大概有五六千个会符合我们上面的安装，也就是有``actor``又有``type``才是我们需要记录的数据，我们只需要统计用户的那些事件，而非全部的事件。
312305
313-
##python 遍历文件##
314-
315306
我们需要去遍历文件，然后找到合适的部分，这里只是要找``2014-03-01``到``2014-03-31``的全部事件，而光这些数据的gz文件就有1.26G，同上面那些解压为json文件显得不合适，只能用遍历来处理。
316307
317308
这里参考了osrc项目中的写法，或者说直接复制过来。
@@ -334,11 +325,7 @@ date_re = re.compile(r"([0-9]{4})-([0-9]{2})-([0-9]{2})-([0-9]+)\.json.gz")
334325
335326
更好的方案？
336327
337-
###redis
338-
339-
结合了前面两篇我们终于可以成功地读取出用户数据、处理，再接着可以找相近的用户。
340-
341-
##Python Redis
328+
##Redis
342329
343330
查询用户事件总数
344331
@@ -387,7 +374,7 @@ pipe.execute()
387374
388375
到这里我们算是知道了OSRC的数据库部分是如何工作的。
389376
390-
###Python redis 查询
377+
###Redis 查询
391378
392379
主要代码如下所示
393380
@@ -430,7 +417,8 @@ def get_vector(user, pipe=None):
430417
431418
osrc最有意思的一部分莫过于flann，当然说的也是系统后台的设计的一个很关键及有意思的部分。
432419
433-
##Python Github
420+
##邻近算法
421+
434422
邻近算法是在这个分析过程中一个很有意思的东西。
435423
436424
>邻近算法，或者说K最近邻(kNN，k-NearestNeighbor)分类算法可以说是整个数据挖掘分类技术中最简单的方法了。所谓K最近邻，就是k个最近的邻居的意思，说的是每个样本都可以用她最接近的k个邻居来代表。

‎chapters/06-create-pull-request.md

Lines changed: 10 additions & 8 deletions
Original file line numberDiff line numberDiff line change
@@ -9,11 +9,13 @@
99

1010
##Google Ngx Pagespeed
1111

12-
else
13-
cat << END
14-
$0: error: module ngx_pagespeed requires the pagespeed optimization library.
15-
-Look in obj/autoconf.err for more details.
16-
+Look in objs/autoconf.err for more details.
17-
END
18-
exit 1
19-
fi
12+
```
13+
else
14+
cat << END
15+
$0: error: module ngx_pagespeed requires the pagespeed optimization library.
16+
-Look in obj/autoconf.err for more details.
17+
+Look in objs/autoconf.err for more details.
18+
END
19+
exit 1
20+
fi
21+
```

0 commit comments

Comments
 (0)