Teamtoy on Binary Life

SSH 配置解析

Sat, 14 Dec 2013 14:09:00 +0800

使用 git (ssh 模式)和 scp 等 ssh 相关命令时也遵从该配置

vim ~/.ssh/config
Host github.com
User git # 使用 github 时的默认用户名
IdentityFile ~/.ssh/id_rsa.github # 为不同的 host 配置不同的 key
Host gerrit.work-host.com
User work-name # 使用公司 gerrit 服务时的默认用户名
IdentityFile ~/.ssh/id_rsa.work # 为不同的 host 配置不同的 key
# ssh mctx => ssh urakalee@192.168.1.1
# 不需要配系统 host, 不过除 ssh 相关命令外, 该 host 不起作用
Host mctx
HostName 192.168.1.1 # 私人服务器 ip
User urakalee # ssh 到私人服务器时的默认用户名
IdentityFile ~/.ssh/id_rsa.urakalee # 为不同的 host 配置不同的 key
# ssh workstation 和 ssh 10.0.0.1 同时生效
# 不需要配系统 host, 不过除 ssh 相关命令外, 该 host 不起作用
Host workstation 10.0.0.1
HostName 10.0.0.1 # 公司 workstation 服务器 ip
User work-name # ssh 到公司 workstation 服务器时的默认用户名
IdentityFile ~/.ssh/id_rsa.work # 为不同的 host 配置不同的 key

vim ~/.ssh/known_hosts
# 通过用户认证的主机列表, 一行一个
<主机名>,ip1[,ip2]...[,ipN] ssh-<加密方式> <主机指纹>

vim ~/.ssh/authorized_keys
# 设置本机允许那些用户登录, 一行一个
ssh-<加密方式> <公钥> [user@host]

Code Style

Sat, 07 Dec 2013 18:07:00 +0800

代码风格

代码是给人看的, 偶尔也在机器上跑一跑
代码应该越写越少: Write Less Do More
所有源代码文件(包括 html/css/properties/readme 等)均为 utf-8 无 bom 格式, unix 换行
禁用tab, 所有源代码文件一律使用 4 空格缩进

Java

内部规范

第三部分
- 每行不超过 120 字符, 一个文件不超过 600 行
- 愿意遵循每行不超过 72 或 80 字符的也可以, 但不超过 120 是必须的
第四部分
- 再次强调每行不超过 120 字符, 一个文件不超过 600 行
- 换行是检验代码可读性的重要标准
第六部分
- 一行声明一个变量
第七部分
- 语句块即使只有一行也要有括号
- 尤其是 if 语句!
第九部分
- 类名为首字母大写格式
- 包名均为小写, 视觉上应为一个倒置的域名, 比如 com.domain.codename
- 常量为全大写, 下划线分隔
第十部分
- 善用 TODO, XXX, FIXME
其它
- 避免 magic number
- 禁用 System.out.print, 使用 logger
- 如果可能, 避免使用 ++, 无论是前 ++ 还是后 ++, 而是用 += 1来替代
- 文件结构: 将功能和方法分为命令和查询两类, 并将两者分别放在一起
  - 也可以分成更多类, 比如 override/implement/public/private/getter/setter 等
  - 定义 code template 是个好办法, 但关键还是在于所有人都能坚持遵循
- 包结构: 包内文件不超过 10 个, 接口的实现要放在对应的 impl 目录下
- Singleton (helper): 需要初始化
- 静态函数集合 (utils): 不需要初始化, 或者有瞬间又无异常的static初始化

防御

警告就是错误!
报告所有的异常, 传播不能处理的异常, 禁止空 catch, 即使是临时这样做也不行!
在异常发生之前使用断言, 可以避免更严重的问题(比如数据不一致)

测试

单元测试就是最可信的文档
刚刚开始 TDD 时要用最简单的方式编写 TestCase, 而不是不断引入新的类, 否则你会强迫自己保留和使用它们
像重构代码一样重构测试
测试用例以 Test 开头, 测试一个类用 TestClassName, 测试一个包用 TestPackageName (为了遵循类命名规范, 包名需要首字母大写)

调试

善用 debug 模式, 而不是 log, 更不是 print
但是, 在运行着的系统中 log 还是很有用的, 所以 log 中要展示有用的信息
实验用例以 Run 开头, 后面同测试用例, 通常每个实验用例都只有一个 main 函数, 主要用来做实验

Html/Css/Javascipt

html 的 id 为驼峰格式, 形如 abcXyz
html 的 class 为全小写, 形如 abc-xyz

How to Wiki

Sat, 07 Dec 2013 17:35:18 +0800

什么是 wiki

wiki 是一种网络应用
遵照一定的格式, 使用纯文本书写, 输出 html 文档
方便的内链接, 在多个内部页面之间跳转
多人编辑, 支持版本历史

如何创建一个 wiki 页面

访问一个不存在的 url, 建立一个新的页面
- 比如 /APageDoesNotExist
页面的名字必须是 首字母大写 的, 首字母大写的名字可以被 wiki 识别为内链接
点击 “创建页面”, 编辑
书写语法见 /WikiFormatting
编辑完点击 “预览”, 查看输出的 html 是否符合预期
如果没问题, 点击 “提交改动”, 即生成一个新的 wiki 页面

添加附件

wiki 允许增加附件
打开一个存在的 wiki 页面, 点击页面底部的 “附件”
选择文件并上传
如果可能, 尽量书写一份 wiki 文档而不是上传一个 word 文档作为 wiki 的附件

规划 wiki 文档的层次结构

wiki 中使用 = 到 ====== 代表 h1 到 h6 标签, 标识文档的层次结构
书写 wiki 文档时, 需要合理地规划层次结构, 增加文档的可读性
需要合理地使用表格, 列表等 html 元素, 增加文档的可读性
更多格式语法见 /WikiFormatting
当一个文档过长时, 可以考虑切分成几个文档, 或者当成一个项目

如何创建一个项目的 wiki 页面

一个项目通常有很多内容, 需要创建多个页面
先创建项目首页, 比如 /NewProject
再创建子页面, 比如:
- 设计文档: /NewProject/Design
- 如何部署: /NewProject/Deploy
每个子页面可以根据需要再创建子页面
编辑项目页面, 在底部加入下面的代码, 即可在项目页面上看到所有子页面:

== 文章列表 ==
[[TitleIndex(NewProject)]]

Work Style

Sat, 07 Dec 2013 15:20:01 +0800

工作模式(暂行)

4 天计划, 前紧后松
CoC, 主动 & 高效, 跨职能的技术团队
执行 敏捷开发 和 文档驱动
- 每日站会, 详见 45个习惯 第 8 章
- 代码集体所有制, 详见 45个习惯 第 8 章

CoC: Convention over Configuration

习惯优于配置
达成目标的方式有很多种, 可以灵活配置, 但遵从习惯可以降低沟通成本
- 版本控制: Git
- Java 包管理和部署: Maven
- 文档管理: wiki (Trac)
- 项目管理: Trello
习惯可以改, 只要好处 » 成本

主动&高效

主动提问, 站会匆匆而过, 没听明白的一定要问
主动沟通, 有问题超过 1h 搞不定, 就应该想想能找谁帮忙解决
主动通知, 邮件是广播 & 存档, 不能指望每个人都会看邮件, 但至少让 Ta 有地方去看
4 天做完 1 周的事, 剩下一天提高团队战斗力, 或者爱干嘛干嘛
一图抵万言, 确保大家说的 A 是同一个 A, 理解的 B 是同一个 B

跨职能

为了大家都能做一些爱做的事, 需要大家都做一些不爱做的事
每项工作都需要有至少 2 个人了解, 避免某件事情由于某个人不在就搞不定

技术团队

关注解决方案, 尽可能的解决问题
让 “这个很难”, “这个搞不定” 越来越少
领取 个人项目, 作为 bonus

借鉴 Scrum 敏捷开发框架

每周一个 Sprint, 按照大版本规划 Sprint
持续交付, 每个 Sprint 产出的结果对于最终用户都是有用的
每个 Sprint 需要分拆成最小 0.5D, 最大 2D 的任务
每天 10 ~ 20 分钟同步进度, 解决问题
使用 Trello 进行项目管理

文档驱动

任何 三个月后还有用的东西 都需要文档
文档需要回答的问题: 如果我完全不了解这个项目, 我想知道什么
- 怎么用: 如何部署/运行, 提供什么接口
- 怎么开发: 代码结构/核心算法/核心模块和逻辑(数据流图)

How to Git

Wed, 04 Dec 2013 09:37:29 +0800

Git 入门资料

windows 客户端: http://git-scm.com/download/win
Pro Git 中文版(书, 可能被墙): http://git-scm.com/book/zh
Pro Git 中文下载版(pdf): http://ishare.iask.sina.com.cn/f/23292123.html
图解 Git (推荐阅读): http://my.oschina.net/xdev/blog/114383

windows 下 Git 的配置和使用

以下命令都在 Git Bash 中运行
生成公钥/私钥
- ssh-keygen -t rsa
- 生成的密钥对的位置在 C:\Users\<user-name>\.ssh
- id_rsa 为私钥, id_rsa.pub 为公钥
配置 Git 的用户名和邮件

git config --global user.name <your-name>
git config --global user.email <your-email>

进阶配置

编辑 <git-install-path>\etc\gitconfig
1. 修改autocrlf = input, 确保提交的文本都是 utf8 编码
2. 在文件末尾增加下面的代码, 使 Git GUI 能显示中文

[gui]
encoding = utf-8

编辑 <git-install-path>\etc\git-completion.bash
1. 在文件末尾增加下面的代码, 使 Git Bash 能显示中文

alias ls='ls --show-control-chars --color=auto'

Git 使用规范

禁用中文文件名
所有文本文件使用 utf8 编码
所有文本文件使用 unix 换行 (\n), 而非 windows 换行 (\r\n)

Git 分枝管理

master: 稳定可编译/测试通过的代码
test: 测试环境的代码, 通过测试后merge到master
pri-xxx: 个人开发代码 (private), 由于可能需要到部署到服务器上, 因此允许 push 到 remote
dev: 开发环境的代码
在 pri-xxx 上开发的代码, 可能需要 merge 到开发环境上验证
验证通过后, 禁止直接把 dev merge 到 test, 而是应该从 pri-xxx merge 到 test
由于 dev 代码在多人 merge 后可能出问题, 所以定期会从 master 重开 dev 分枝

Git 注释规范

所有注释, 除了 merge 时系统自动生成的, 均应符合以下规范
1. 格式为 <OPERATION>: description
2. OPERATION 包括 ADD/MOD/DEL/FIX/MERGE/REFACTOR/CLEAN, 全部大写, 后面跟着冒号
3. description 需要是全英文, 包括标点
一次提交可以有多个 OPERATION, 但最好只有一个
- 多个 OPERATION 一行一个

OPERATION	何时使用	description应该写什么
ADD	增加功能/文件	增加了什么功能/文件(文件太多可以写目录)
MOD	修改功能/文件	修改了什么功能/文件, 以及修改原因
DEL	删除功能/文件	删除了什么功能/文件, 以及删除原因
FIX	修复 bug	bug 列表中有的, 可以只写 bug 号, 没有的需要说明
MERGE	手动合并	从哪里合并到哪里 (from x to y), 如何解决了冲突
REFACTOR	重构	重构了什么
CLEAN	清理	清理了什么

How to code review

Sun, 01 Dec 2013 21:17:33 +0800

引

版本控制工具：Git
代码 review 工具：ReviewBoard
代码 review 需要积极评估代码的设计和清晰程度，项目 owner 还要确保被review 代码的逻辑正确性，而不仅限于命名和格式

准备工作

用 ldap 账号登录
确保参与 review 的人都需要登录过，否则会找不到人
确保你要 review 的代码的 git 已经加入 reviewboard
确保你要 review 的代码基点已经 push 到 git 服务器
- 代码基点: git diff <src-rev> <tgt-rev> 中的 <src-rev>

提交一个 review

生成diff
- git diff <src-rev> <tgt-rev> > d1.diff
  - 一般来说src是tgt的父节点
- 如何得到 <src-rev>
  - 对于开分枝 / 开发 / merge 的工作模式而言
    - <src-rev> 就是你开分枝时分枝点的版本
    - 可以用 git merge-base <src-branch> <tgt-branch> 得到 <src-rev>
      - 比如你要从 work 分枝 merge 回 master，则执行 git merge-base master work 得到 <src-rev>，前提是你没有 merge 过
      - 但如果你已经 merge 过，这样得到的 <src-rev> 是从最后一次 merge 的版本
  - 对于在一个分枝上持续开发的工作模式
    - 查看git log 找到需要的 <src-rev>
  - 应该尽量在代码稳定时再 merge：勤开分枝，慎重 merge
  - 应该尽量使用 amend，减少 commit，git log 才好找
访问 reviewboard，点击 New Review Request
选择 Repository，选择 diff 文件，点击 Create Review Request
点击 View Diff，查看上传结果是否和预期一致
填写 Summary / People / Description，注意 people 是 ldap 账号名，用 tab 补全，别按回车
确认提交，系统会发邮件给 people，通知他们来 review

更新一个 review

修改代码提交之后生成新 diff
- git diff <src-rev> <tgt-rev2> > d2.diff
- 注意确保在一次 review 中，所有 diff 的 <src-rev> 都是同一个
访问 reviewboard，打开要更新的 review
- 只能更新自己提交的 review
点击 Update 下拉菜单中的 Update Diff，选择 diff 文件，点击 Upload
点击 View Diff，查看上传结果是否和预期一致
填写本次更新的内容，确认提交

review 别人的代码

点击邮件通知中的链接，登录 reviewboard
点击 View Diff，查看被修改的代码
点击有问题的行，填写有什么问题
继续 review，直到所有代码都 review 完毕
点击页面上方悬浮条中的 Edit Review，预览所有你填写的内容
如果没有问题，点击 Publish Review
- 如果需要修改，可以直接在预览页面上修改
- 如果需要增加，点击 Cancel，增加，再 Edit Review
如果代码较多，可以 review 一页提交一页

根据别人的 review 修改代码

别人提出的每个问题都会生成一个 issue
对照这些 issue 修改代码；如果 fix 了，就点 fixed；如果有异议，可以回复讨论；如果确认不需要改，就点 drop
修改完成后，提交代码，生成新的 diff
更新 review，继续，直到所有 issue 都 fixed 或 drop

我的 Git 配置

Thu, 28 Nov 2013 20:35:55 +0800

vim ~/.gitconfig
[color]
ui = true
diff = true
status = true
branch = true
interactive = true
[alias]
st = status
ss = status -s
ci = commit
ca = commit --amend
co = checkout
ll = log --graph --color --format=format:'%C(bold)%h%C(reset) -%C(bold)%d%C(reset) %C(white)%s%C(reset) %C(bold red)- %an' --abbrev-commit
ft = fetch
pl = pull --rebase
br = branch
cp = cherry-pick
mg = merge
rb = rebase
dci = dcommit
sbi = submodule init
sbu = submodule update
sbp = submodule foreach git pull
sbc = submodule foreach git co master

我的 Vim 配置

Thu, 28 Nov 2013 20:25:20 +0800

vim ~/.vimrc
# 行号
set nu
# tab 转空格
set ts=4
set expandtab
set autoindent
# 语法高亮
syntax enable
set background=dark
colorscheme solarized

solarized 是一套很棒的配色方案，请参考 vpsee 中的方法进行配置。