mirror of
https://github.com/phodal/github
synced 2026-05-22 00:29:47 +00:00
fix title
This commit is contained in:
Fengda HUANG
parent
27b3928211
commit
dbfd72ee91
5 changed files with 33 additions and 49 deletions
|
|
@ -25,7 +25,6 @@ Wiki百科上是这么说的
|
|||
|
||||
等等。看上去像是大餐，但是你还需要了解点什么?
|
||||
|
||||
|
||||
###版本管理与软件部署
|
||||
|
||||
jQuery[^jQuery]在发布版本``2.1.3``，一共有152个commit。我们可以看到如下的提交信息:
|
||||
|
|
@ -36,8 +35,7 @@ jQuery[^jQuery]在发布版本``2.1.3``，一共有152个commit。我们可以
|
|||
- Build: Move test to appropriate module fbdbb6f
|
||||
- Build: Update commitplease dev dependency
|
||||
- ...
|
||||
|
||||
|
||||
|
||||
###Github与Git
|
||||
|
||||
> 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。我们可以
|
|||
|
||||
[^jQuery]: jQuery是一套跨浏览器的JavaScript库，简化HTML与JavaScript之间的操作。
|
||||
|
||||
##提高
|
||||
|
||||
##用好Github
|
||||
|
||||
###敏捷软件开发
|
||||
|
||||
|
|
@ -64,7 +61,7 @@ jQuery[^jQuery]在发布版本``2.1.3``，一共有152个commit。我们可以
|
|||
|
||||
当只有一个人的时候，你只需要明确知道自己想要什么就够了。我们还需要的是CI、测试，以来提升代码的质量。
|
||||
|
||||
##测试
|
||||
###测试
|
||||
|
||||
通常我们都会找Document，如果没有的话，你会找什么?看源代码，还是看测试?
|
||||
|
||||
|
|
@ -122,7 +119,7 @@ lettuce.js | 98.58% (209 / 212)| 82.98%(78 / 94) | 100.00% (54 / 54) | 98.58% (2
|
|||
|
||||
本地测试都通过了，于是我们添加了``Travis-CI``来跑我们的测试
|
||||
|
||||
##CI
|
||||
###CI
|
||||
|
||||
虽然node.js不算是一门语言，但是因为我们用的node，下面的是一个简单的``.travis.yml``示例:
|
||||
|
||||
|
|
@ -144,7 +141,7 @@ lettuce.js | 98.58% (209 / 212)| 82.98%(78 / 94) | 100.00% (54 / 54) | 98.58% (2
|
|||
|
||||
CI对于一个开发者在不同城市开发同一项目上来说是很重要的，这意味着当你添加的部分功能有测试覆盖的时候，项目代码会更加强壮。
|
||||
|
||||
##代码质量
|
||||
###代码质量
|
||||
|
||||
像``jslint``这类的工具，只能保证代码在语法上是正确的，但是不能保证你写了一堆bad smell的代码。
|
||||
|
||||
|
|
@ -193,7 +190,7 @@ CI对于一个开发者在不同城市开发同一项目上来说是很重要的
|
|||
|
||||
这就意味着我们可以对上面的代码进行重构，他们是重复的代码。
|
||||
|
||||
##重构
|
||||
###重构
|
||||
|
||||
不想在这里说太多关于``重构``的东西，可以参考Martin Flower的《重构》一书去多了解一些重构的细节。
|
||||
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
#基本知识
|
||||
#Git基本知识与Github使用
|
||||
|
||||
##Git
|
||||
|
||||
|
|
|
|||
|
|
@ -1,11 +1,8 @@
|
|||
#Github项目分析一
|
||||
|
||||
##用matplotlib生成图表
|
||||
##生成图表
|
||||
|
||||
如何分析用户的数据是一个有趣的问题，特别是当我们有大量的数据的时候。
|
||||
除了``matlab``，我们还可以用``numpy``+``matplotlib``
|
||||
|
||||
###python github用户数据分析##
|
||||
如何分析用户的数据是一个有趣的问题，特别是当我们有大量的数据的时候。除了``matlab``，我们还可以用``numpy``+``matplotlib``
|
||||
|
||||
数据可以在这边寻找到
|
||||
|
||||
|
|
@ -17,11 +14,11 @@
|
|||
|
||||
要解析的json文件位于``data/2014-01-01-0.json``，大小6.6M，显然我们可能需要用每次只读一行的策略，这足以解释为什么诸如sublime打开的时候很慢，而现在我们只需要里面的json数据中的创建时间。。
|
||||
|
||||
==这个文件代表什么？
|
||||
==,这个文件代表什么？
|
||||
|
||||
**2014年1月1日零时到一时，用户在github上的操作，这里的用户指的是很多。。一共有4814条数据，从commit、create到issues都有。**
|
||||
|
||||
###python json文件解析##
|
||||
###数据解析
|
||||
|
||||
```python
|
||||
import json
|
||||
|
|
@ -70,7 +67,7 @@ minuteswithcount = [(x, dataarray.count(x)) for x in set(dataarray)]
|
|||
[(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)]
|
||||
```
|
||||
|
||||
##matplotlib
|
||||
###Matplotlib
|
||||
|
||||
开始之前需要安装``matplotlib
|
||||
|
||||
|
|
@ -186,7 +183,7 @@ draw_date("data/2014-01-01-0.json")
|
|||
8474, 7984, 12933, 13504, 13763, 13544, 12940,
|
||||
7119, 7346, 13412, 14008, 12555
|
||||
|
||||
###python 数据分析
|
||||
###Python 数据分析
|
||||
|
||||
重写了一个新的方法用于计算提交数，直至后面才意识到其实我们可以算行数就够了，但是方法上有点hack
|
||||
|
||||
|
|
@ -235,7 +232,7 @@ def get_month_total():
|
|||
|
||||
接着我们需要去遍历每个结果，后面的后面会发现这个效率真的是太低了，为什么木有多线程？
|
||||
|
||||
###python matplotlib图表
|
||||
###Python Matplotlib图表
|
||||
|
||||
让我们的matplotlib来做这些图表的工作
|
||||
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@
|
|||
|
||||
让我们分析之前的程序，然后再想办法做出优化。网上看到一篇文章[http://www.huyng.com/posts/python-performance-analysis/](http://www.huyng.com/posts/python-performance-analysis/)讲的就是分析这部分内容的。
|
||||
|
||||
##time python分析
|
||||
##Time Python分析
|
||||
|
||||
分析程序的运行时间
|
||||
|
||||
|
|
@ -21,9 +21,6 @@ $time python handle.py
|
|||
|
||||
##line_profiler python
|
||||
|
||||
这是
|
||||
##Mac OS X 10.9 line_profiler Install##
|
||||
|
||||
```bash
|
||||
sudo ARCHFLAGS="-Wno-error=unused-command-line-argument-hard-error-in-future" easy_install line_profiler
|
||||
```
|
||||
|
|
@ -85,17 +82,15 @@ Line # Hits Time Per Hit % Time Line Contents
|
|||
|
||||
于是我们就发现我们的瓶颈就是从读取``created_at``，即创建时间。。。以及解析json，反而不是我们关心的IO，果然``readline``很强大。
|
||||
|
||||
##memory_profiler python
|
||||
##memory_profiler
|
||||
|
||||
###memory_profiler install
|
||||
首先我们需要install memory_profiler:
|
||||
|
||||
```bash
|
||||
$ pip install -U memory_profiler
|
||||
$ pip install psutil
|
||||
```
|
||||
|
||||
###memory_profiler python
|
||||
|
||||
如上，我们只需要在``handle_json``前面加上``@profile``
|
||||
|
||||
```bash
|
||||
|
|
@ -128,7 +123,7 @@ Line # Mem usage Increment Line Contents
|
|||
|
||||
##objgraph python
|
||||
|
||||
###objgraph install
|
||||
安装objgraph
|
||||
|
||||
```bash
|
||||
pip install objgraph
|
||||
|
|
@ -226,8 +221,6 @@ def get_count(username):
|
|||
|
||||
这个数据库文件有**905M**，不过查询结果相当让人满意，至少相对于原来的结果来说。
|
||||
|
||||
##Python SQLite3
|
||||
|
||||
Python自带了对SQLite3的支持，然而我们还需要安装SQLite3
|
||||
|
||||
```bash
|
||||
|
|
@ -254,7 +247,7 @@ sudo zypper install sqlite3
|
|||
|
||||
不过，用yast2也很不错，不是么。。
|
||||
|
||||
##Pythont Github Sqlite3数据导入
|
||||
###数据导入
|
||||
|
||||
需要注意的是这里是需要python2.7，起源于对gzip的上下文管理器的支持问题
|
||||
|
||||
|
|
@ -310,8 +303,6 @@ def build_db_with_gzip():
|
|||
|
||||
``executemany``可以插入多条数据，对于我们的数据来说，一小时的文件大概有五六千个会符合我们上面的安装，也就是有``actor``又有``type``才是我们需要记录的数据，我们只需要统计用户的那些事件，而非全部的事件。
|
||||
|
||||
##python 遍历文件##
|
||||
|
||||
我们需要去遍历文件，然后找到合适的部分，这里只是要找``2014-03-01``到``2014-03-31``的全部事件，而光这些数据的gz文件就有1.26G，同上面那些解压为json文件显得不合适，只能用遍历来处理。
|
||||
|
||||
这里参考了osrc项目中的写法，或者说直接复制过来。
|
||||
|
|
@ -334,11 +325,7 @@ date_re = re.compile(r"([0-9]{4})-([0-9]{2})-([0-9]{2})-([0-9]+)\.json.gz")
|
|||
|
||||
更好的方案？
|
||||
|
||||
###redis
|
||||
|
||||
结合了前面两篇我们终于可以成功地读取出用户数据、处理，再接着可以找相近的用户。
|
||||
|
||||
##Python Redis
|
||||
##Redis
|
||||
|
||||
查询用户事件总数
|
||||
|
||||
|
|
@ -387,7 +374,7 @@ pipe.execute()
|
|||
|
||||
到这里我们算是知道了OSRC的数据库部分是如何工作的。
|
||||
|
||||
###Python redis 查询
|
||||
###Redis 查询
|
||||
|
||||
主要代码如下所示
|
||||
|
||||
|
|
@ -430,7 +417,8 @@ def get_vector(user, pipe=None):
|
|||
|
||||
osrc最有意思的一部分莫过于flann，当然说的也是系统后台的设计的一个很关键及有意思的部分。
|
||||
|
||||
##Python Github
|
||||
##邻近算法
|
||||
|
||||
邻近算法是在这个分析过程中一个很有意思的东西。
|
||||
|
||||
>邻近算法，或者说K最近邻(kNN，k-NearestNeighbor)分类算法可以说是整个数据挖掘分类技术中最简单的方法了。所谓K最近邻，就是k个最近的邻居的意思，说的是每个样本都可以用她最接近的k个邻居来代表。
|
||||
|
|
|
|||
|
|
@ -9,11 +9,13 @@
|
|||
|
||||
##Google Ngx Pagespeed
|
||||
|
||||
else
|
||||
cat << END
|
||||
$0: error: module ngx_pagespeed requires the pagespeed optimization library.
|
||||
-Look in obj/autoconf.err for more details.
|
||||
+Look in objs/autoconf.err for more details.
|
||||
END
|
||||
exit 1
|
||||
fi
|
||||
```
|
||||
else
|
||||
cat << END
|
||||
$0: error: module ngx_pagespeed requires the pagespeed optimization library.
|
||||
-Look in obj/autoconf.err for more details.
|
||||
+Look in objs/autoconf.err for more details.
|
||||
END
|
||||
exit 1
|
||||
fi
|
||||
```
|
||||
Loading…
Reference in a new issue