Posts

本文仅用于有洁癖者(本人)统一 markdown 风格, 以及 check style 行文 标点 除非必要, 所有标点都使用英文标点 强调 说明性的词和短语用双引号("")强调 提示性的词和短语用双星号(**)强调 结论性的短语和句子用三星号(***)强调 删除 ~~删除的文字~~ -> 删除的文字 空格 第一级列表标记(比如*)前不需要空格 英文单词的前后都需要空格 行首不需要前面的空格, 句尾不需要后面的空格 如果英文单词在括号里, 则前后的空格写在括号外, 比如 " (abc) " 或 " (abc 很不错)" 左引号前和右引号后都需要空格 行首不需要前面的空格, 句尾不需要后面的空格 强调标记的前后都需要空格 行首不需要前面的空格, 句尾不需要后面的空格 链接 行文中需要文字的, 使用引用方式 直接贴链接不影响行文的, 可以直接贴连接 比如 少量 不是很长 且 在行尾 的链接 比如 少量 不是很长 的链接列表 其它情况均需要使用引用方式, 引用需要集中写在文章或段落末尾 [Display Name][name] ... [name]: http://external.link "Link Description" [name]: /blog/yyyy/MM/dd/internal-link/ "Link Description" 更新 在文档末尾添加 **** Update@yyyy.MM.dd: 更新的内容 大小写 TODO 用词 举例时用 “比如”, 不用 “如”; “比如” 后面不加冒号, 除非后面跟着列表 并列时用 “和”, 不用 “及”; 除非需要使用 “以及” “其他” 修饰人, “其它” 修饰非人 代码 单行模式 一行可执行代码使用变音符号(`)单行模式 一行文本内容使用变音符号单行模式或 pre-code 多行模式 特殊记号使用变音符号单行模式 比如文件路径 C:\Windows 比如代码元素 ++ -- 变音符号单行模式的空格规则同引号 可执行代码和支持代码高亮的文本 使用变音符号(`)多行模式 支持代码高亮的语言列表: http://pygments.org/docs/lexers/ 不支持代码高亮的文本内容 使用 pre-code 多行模式 打开该文本文件的命令可以写在一起, 命令和文本之间空一行

使用 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]

安装 下载安装后, 需要更新到最新版本 不更新可能会遇到一些奇葩问题 如果能直接更新或者翻墙更新的, 请直接更新 不能更新的, 请参考下列文章手动更新 http://www.cnsecer.com/842.html http://blog.csdn.net/hil2000/article/details/11395485 关键命令 java -classpath AI-<old-edition>-<new-edition>-patch-<os>.jar com.intellij.updater.Runner install . 新建项目 新建一个项目时, 视选择的 SDK 版本, 可能会失败, 原因是包不全 打开 SDK Manager, 勾选需要的包, 点击 Install X package[s]… 注意: 接受协议时可能需要在弹出的对话框里逐个接受, 才能一并下载 模拟器 以下问题仅限于 windows, Mac 用户可以直接放弃模拟器… 运行模拟器失败, 需要把 X盘/.android/avd 拷贝到 C盘/用户目录/.android 下 运行模拟器慢, 需要下载和安装 intel x86 emulator, 创建 avd 时也要选这个 用 SDK Manager 下载 intel x86 emulator 和对应的 rom 注意: 下载 emulator 后需要安装, 可执行文件在 sdk/extras/intel 中 数据目录 Android Studio 目前还不太稳定, 偶尔折腾, 甚至需要把数据目录清空 下面的内容摘自 Intellij 官网, 只要把路径换成 AndroidStudioPreview 即可 Mac ~/Library/Application Support/IntelliJIdeaXX contains the catalog with plugins. ~/Library/Preferences/IntelliJIdeaXX contains the rest of the configuration settings. ~/Library/Caches/IntelliJIdeaXX contains data caches, logs, local history, etc. These files can be quite significant in size. 9.0+ ~/Library/Logs/IntelliJIdeaXX contains logs Windows ~\.IntelliJIdeaXX\config that contains user-specific settings. ~\.IntelliJIdeaXX\system that stores IntelliJ IDEA data caches. Update@2015.04.13: Android Studio 在升级到 1+ 之后奇葩问题少多了 Update@2016.03.10: 模拟器建议使用 Genymotion

常用命令 find find . -name "*.xyz" find . -name "*abc*" -delete grep grep -i "abc" * # 忽略大小写 grep -R "abc" . wc wc -l find -name "*.java" # 统计 java 代码行数 权限 chmod u+x <file> # 设为可执行文件 chown <name> <file> chown -R <name> <dir> chgrp ... # 格式同 chown 系统工具 ssh ssh-add -D删除所有记住的key 解决 Mac 下所有使用过的 key 都会被记住，删除 key 文件没用的问题 链接库 查看链接库是否缺失: ldd <可执行文件> 修改系统加载库 vim /etc/ld.so.conf /sbin/ldconfig

坦诚 信任（支持） 尊重 包容（耐心）

概述 这本书并没有告诉我们应该确立什么样的人生目标, 但书中的观点可以帮助我们衡量目标的可行性, 并关注实现目标的过程中可能发生的问题 目标: 资源•应用流程•价值取向 资源是 Ta 所利用的东西 应用流程是 Ta 做事的方法 价值取向是 Ta 做某件事的动机 -> 用于评估什么样的目标可以实现, 什么样的目标遥不可及 衡量目标的可行性: 资源是否足够, 如果不够, 可能需要一个更短期的目标来增加资源 实现目标的方法已经有了吗? 可能没有, 那么需要 “根据机遇权衡计划” 目标是否符合你的价值取向, 如果不符合, 那么可能需要放弃这个目标 每天都会面临的基本挑战: 接受哪些信息 采纳哪些建议 忽视哪些问题 去做哪些事情 -> 这些挑战归结为: 如何选择 目标 - 选择 所谓目标, 虽然分长期和短期, 却依然很难直接指导具体的选择 相反, 选择的过程往往体现了 “资源•应用流程•价值取向” 这三要素 实现目标过程中可能会发生的问题: 重点不明确, 要关注你的价值取向中最重要的那部分 “根据机遇权衡计划” 既然是重点, 就要分配资源 战略: 重点•根据机遇权衡计划•分配资源 战略, 是指为实现某种目标而制定的大规模, 全方位的长期行动计划 战略是长期的事情, 短期的事情不能通过战略搞定, 但应符合战略需要 重点 重点是你做决策时的核心标准 薪水是一个基础因素, 不是动力因素 工作满意和没有不满是两回事 权衡 “哪些假设条件需要得到验证, 才能说明这个战略有效” 根据机遇权衡计划的重点是小成本尝试和拥抱变化, 是一个情况多样, 难以控制的连续过程, 很可能不是一开始就想到的 没有哪个方法一经提出就更好或更糟, 而是要根据你走到哪个阶段来确定 分配资源 任何一个战略 - 不论是企业战略还是个人生活战略 - 都是从数百次日常决定中产生的, 它是关于如何安排时间(人)和金钱(物)的决定 生活中的每一个有关如何分配时间盒金钱的决定, 都表明了你真正在乎的是什么 你可以尽情地谈论自己的生活, 谈论有什么清晰的目标和战略, 但是如果你投入的资源和你的战略方向不一致, 这些谈论都毫无意义 如果最终不能有效实施, 你的战略只能是一个良好的愿望 -> 如果家庭是重点, 就要家庭建设上分配资源 我的目标 我的目标是帮助家人(包括自己)过上满足的生活 谈 “幸福(的生活)” 太虚幻, 说 “满足” 比较实际 满足某些欲望并不能真的让人满足 为了生活得满足, 我需要更有竞争力, 更有效率; 所以 重点是生活 重点 生活包括兴趣(工作), 收入(工作), 家庭 兴趣(工作)使生活有成就感? 家庭也能使生活有成就感, 但我还是不愿意放弃兴趣(工作)的成就感 收入(工作)让生活更有质量 家庭是生活的保障 权衡 兴趣需要投入时间 收入的多少虽然不直接与时间发生关系, 但间接需要投入时间去争取(比如加班) 家庭建设需要投入时间, 可能还需要人脉 人脉需要时间, 也需要金钱? 目前金钱不是关键问题, 如果真的是关键, 也拿不出来… 持续性是生活中潜在的重要因素, 也是人的基本需求(安全感) -> 当前战略的主要问题是如何分配时间 分配资源 兴趣: 4hr 收入: 4hr, 包括理财 学习是支撑兴趣和收入的基础 家庭: 1~1.5hr 人脉: 0.5~1hr 身体是一切的基础: 1hr 关于家庭 好钱和坏钱 在事业刚起步阶段, 你或许还不知道公司策略是否能够成功, 你必须耐心等候公司成长, 同时把目光放在获利上面; 如此一来, 就要用最少的资金找到一个可行的策略, 不至于花了很多钱才知道走错了路; 如果投入资金之后, 急于看到成长而非获利, 则是 “坏钱” 在所有成功的企业当中, 有93%都必须改变最初的策略; 也就是说一定会有拐点, 所以需要提前准备; 准备的方式则是投入 “好钱” 家庭生活会有类似的问题, 同样需要提前准备, 投入"好钱"; 常见的问题是对孩子的教育 奶昔是被雇佣来做什么的 学校是被雇佣来做什么的: 获得成功的感觉, 每天都会有朋友 你是被雇佣来做什么的 -> 不要将未来外包出去 家庭文化 家庭文化是父母与孩子共同价值取向的保证 文化, 是人们朝着一个共同的目标一起工作的方式, 这种方式一直以来被大家所沿用并且一直行之有效, 以至于人们根本不会想到要以另一种方式去做事 特定文化一经形成, 人们就会自动地区做要取得成功需要做的事 问题出现时, 要做的不仅仅是解决问题本身, 还要在解决问题的过程中明确什么事重要的, 在这个过程中形成了对价值取向的理解, 并学会如何去实践这一价值取向 -> 文化是在 处理问题的过程和做选择时的价值取向被一个组织不断重复使用, 且被证明有效 的基础上形成的 一个组织的文化是否健康, 需要看该组织的成员需要选择如何去做一件事情时, 他们的选择是不是组织的文化所要求的? 收到的效果是否也符合组织文化的要求? 我的父母没为我做的事 孩子们在成长过程中很少有机会负担重要的责任, 也很少有机会能为自己或他人解决复杂的问题 “我不害怕面对这个问题, 我相信自己能解决它”, 这样的自信不是来自丰富的资源, 而是来自完成某件困难且重要的事情 我们将孩子保护起来, 让他们远离生活中出现的各种问题, 但是却无意中阻止了孩子掌握成功所需的 “应用流程” 和 “价值取向” 孩子们在自己准备好学习时才能学到东西, 而不是在我们准备好教导他们的时候 孩子在各种 “经验学校” 中学到了什么, 是比奖励或奖品更能保证他们在外面世界的冒险中取得成功的关键 其它 第一代必须要辛苦一些, 不过 “要与人交流” 这件事情应该与是否第一代无关 第一代只是资源匮乏一些, 应用流程与价值取向方面还是一样的, 都要靠实践 总结 资源•应用流程•价值取向 -> 目标 是确立目标的过程 重点•根据机遇权衡计划•分配资源 -> 战略 是实现目标的过程 价值取向和重点决定了方向, 应用流程和权衡决定了成败, 资源分配是杠杆

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

什么是 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)]]

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

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 修改autocrlf = input, 确保提交的文本都是 utf8 编码 在文件末尾增加下面的代码, 使 Git GUI 能显示中文 [gui] encoding = utf-8 编辑 <git-install-path>\etc\git-completion.bash 在文件末尾增加下面的代码, 使 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 时系统自动生成的, 均应符合以下规范 格式为 <OPERATION>: description OPERATION 包括 ADD/MOD/DEL/FIX/MERGE/REFACTOR/CLEAN, 全部大写, 后面跟着冒号 description 需要是全英文, 包括标点 一次提交可以有多个 OPERATION, 但最好只有一个 多个 OPERATION 一行一个 OPERATION 何时使用 description应该写什么 ADD 增加功能/文件 增加了什么功能/文件(文件太多可以写目录) MOD 修改功能/文件 修改了什么功能/文件, 以及修改原因 DEL 删除功能/文件 删除了什么功能/文件, 以及删除原因 FIX 修复 bug bug 列表中有的, 可以只写 bug 号, 没有的需要说明 MERGE 手动合并 从哪里合并到哪里 (from x to y), 如何解决了冲突 REFACTOR 重构 重构了什么 CLEAN 清理 清理了什么