Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
GitRadar——毕业论文答辩
Search
Shuai Liu
June 30, 2014
Programming
0
160
GitRadar——毕业论文答辩
Shuai Liu
June 30, 2014
Tweet
Share
More Decks by Shuai Liu
See All by Shuai Liu
Auto-Layout.pdf
liushuaikobe
2
110
Python-intro-2
liushuaikobe
0
58
Python-intro-1
liushuaikobe
0
52
NoSQL & MongoDB
liushuaikobe
0
100
Other Decks in Programming
See All in Programming
技術的負債と向き合うカイゼン活動を1年続けて分かった "持続可能" なプロダクト開発
yuichiro_serita
0
300
良いユニットテストを書こう
mototakatsu
11
3.6k
はてなにおけるfujiwara-wareの活用やecspressoのCI/CD構成 / Fujiwara Tech Conference 2025
cohalz
3
2.8k
PHPで作るWebSocketサーバー ~リアクティブなアプリケーションを知るために~ / WebSocket Server in PHP - To know reactive applications
seike460
PRO
2
770
watsonx.ai Dojo #6 継続的なAIアプリ開発と展開
oniak3ibm
PRO
0
170
各クラウドサービスにおける.NETの対応と見解
ymd65536
0
250
Package Traits
ikesyo
1
210
DMMオンラインサロンアプリのSwift化
hayatan
0
190
traP の部内 ISUCON とそれを支えるポータル / PISCON Portal
ikura_hamu
0
180
KMP와 kotlinx.rpc로 서버와 클라이언트 동기화
kwakeuijin
0
300
Lookerは可視化だけじゃない。UIコンポーネントもあるんだ!
ymd65536
1
130
React 19でお手軽にCSS-in-JSを自作する
yukukotani
5
570
Featured
See All Featured
Typedesign – Prime Four
hannesfritz
40
2.5k
Building Your Own Lightsaber
phodgson
104
6.2k
Designing on Purpose - Digital PM Summit 2013
jponch
116
7.1k
Cheating the UX When There Is Nothing More to Optimize - PixelPioneers
stephaniewalter
280
13k
Why You Should Never Use an ORM
jnunemaker
PRO
54
9.1k
A Philosophy of Restraint
colly
203
16k
BBQ
matthewcrist
85
9.4k
The Art of Programming - Codeland 2020
erikaheidi
53
13k
Principles of Awesome APIs and How to Build Them.
keavy
126
17k
Producing Creativity
orderedlist
PRO
343
39k
Art, The Web, and Tiny UX
lynnandtonic
298
20k
Put a Button on it: Removing Barriers to Going Fast.
kastner
60
3.6k
Transcript
基于GitHub开放数据的 开发者能力评价系统 刘帅 1103710207 指导教师
计算机科学与技术学院 吴晋 的设计与实现
内容提要 • 项目来源 & 背景 • 需求分析 •
系统设计 & 实现 • 运行结果 & 性能分析 • 结论
项目来源 & 背景 为什么要做这个项目?
None
ü 招聘会 ü 评阅简历 ü 笔试 & 面试
ü 找的人真的靠谱?
None
为了解决这个问题… • 对GitHub上开发者的行为做分析 • 设计一个评价模型对开发者做评价 • 根据地域对开发者做分类
• 支持检索
行为数据的获取 h"ps://api.github.com/events h"p://www.githubarchive.org/
需求分析 这样的系统该有什么功能?
功能需求 • GitHub上开发者行为数据的处理 • 下载、归档、清洗、持久化 • 数据查询、可视化
• 为每个开发者生成能力评价报告
非功能需求 • 性能 • 数据处理 • 网络访问
• 可靠性 • 数据的可靠性 • 系统的可用性
系统设计 & 实现
系统功能结构模型图
GitHub上开发者评价模型设计 开发者 对 软件项目 做了操作 做了什么 软件项目 开发者 项目被star的个数 ×
star权重 + 项目被fork个数 × fork权重 PushEvent、 IssueEvent、PullRequestEvent 截止到某一时间点开发者的所有行为价值之和
总体实现方案 • Python • Node.js • MongoDB
+ Redis • 并发操作的实现:多进程 + 协程 • gevent + whoosh + Fluentd + SemanHc-‐UI + mapbox.js + high-‐charts
遇到的问题——规范化开发者地域信息 Harbin Heilongjiang China Harbin 中国黑龙江省哈尔滨市 … …
None
系统运行结果 & 性能测试 结果怎么样?
None
None
None
None
None
性能测试 • 每天行为总数量:50万(平均每小时2万) • 经过数据清洗后:12万(平均每小时5000) • 调用地名规范化的Web Service次数:≤800
• 缓存命中次数:≥7.5万,缓存数量:2.4万,命中率:98% • 平均每天数据处理所需时间:约300秒
性能测试 缓存命中率趋势图 每日数据处理时间趋势图
性能测试——nGrinder 简单页面虚拟用户为100时的TPS变化 复杂页面虚拟用户为30时的TPS变化
结论 总结
总结 • 利用GitHub开放的描述开发者行为的数据 • 设计了一个对开发者进行能力评价的模型 • 在前端对数据做了可视化
• 对系统做了测试,分析了系统的不足之处
对未来的展望 • 继续调整能力评价模型 • 对系统性能方面优化不足 • 提高系统的安全性
谢谢各位老师。
None