@hpowen 收费的企业级知识管理wiki。
相比Media Wiki等面向词条的wiki来说，Confluence以树状结构组织页面（类似与目录层级）。
以前用Evernote什么的，在一个Notebook中不能搞多级结构，把笔记平铺下来的话，积攒多了就很难查找、阅读。我知道有些人的Evernote已经退化成记录的工具了。

@wynemo 数据主要就是页面的文字内容保存在mysql中、附件在特定目录下。
Confluence支持导出到pdf，脚本只是模拟手动操作，能自动完成这个事情而已。

不能停留在记笔记，甚至是弱爆了的做题应试阶段啊。
建议
1. 整理知识点、每个知识点评估标准（是否掌握、掌握程度）
2. 提供系统，学生可以按照自己的喜好制定学习计划，跟踪学习进度，从中享受成长的乐趣（可视化方式看到学习成果）

逛街都认真不起来，学习能认真？
要学习上咖啡厅去，原因很简单，在那里，出了学习啥也干不了。你的mm没法支使你去洗水果、不会让你去做饭、不会…… 顶多就偶尔调调情而已

@mlzboy 好吧，我这周改改后提交到github上

python，自动把Confluence所有的空间内容导出为PDF，算是最后一个备份。
除此之外，Confluence其他的备份有：自带备份机制、定期mysqldump、TimeMachine；
有了这些备份才能彻底放心去记录各种笔记。

使用Confluence wiki感觉良好。
一切不方便立即写入Confluence的场合，使用纸笔+康奈尔笔记系统。事后根据记录结果考虑是否编辑到Confluence中。

Confluence

@zealot 对了，我大半年没用Chrome了。。。。

jsonview
btw: 不设置Content-Type: application/json头的json接口都是流氓

我就会用.download作为隐藏目录放片

考驾照那个不能找个包教包会，一次性交的报名费里包括饭费的那种。
考不过就天天过去学车、蹭饭啊
http://news.51xueche.com/news_htm/20096/1200966115835.htm

@tokki 刚满25，7、8年没玩星际了，没有了高中那种一起翻墙溜出去玩星际的人、条件和兴致了。

@chairo 如果这样理解：RD只是PD实现想法的工具。那么不要趟创业这趟水，IBM/Oracle(中国)或许更合适。
p.s. PD参不参与市场分析这个得分公司，不同公司有不同的组织结构。

修改：创业公司里独立产品线(不是项目)走事业部制最理想了

@chairo
我的想法绕来绕去就那些，不逐条回复了
还是些个人暂时的想法

文档粒度
"足够细粒度"的文档，在我看来既不是很好的定义，也没办法执行；除非补充一下详细说明：细化到伪代码粒度。产品经理做High Level的设计就好了，细节根据任务特点分别由美工和研发做更专业、更自由。至于产品经理职责不是设计产品，而是分析产品、用户行为等，设计产品是指一个产出而已。所以非常细的粒度完全没有必要，但文档是必要的、变更记录是必要的，产品回顾、效果分析与分享是必要的。
开发、测试、产品、运营坐在一起办公，很多问题都能解决掉了。我说的”一起“意思是旁边或对面，有问题靠吼来解决，而不道社区讨论，比如站起来，冲旁边经常一起踢球的产品经理吼“你他妈的上午刚提的需求，我都要开发，怎么下午就要改了？”
创业公司里独立项目走事业部制最理想了

复制代码问题
这个我完全不认为复制代码提高效率，即使短期效率提升也未必。这个我很难三言两语说清我的想法。长期来说自然没好处：1）维护性差，很多复制代码风格、实现方式没法融入 2）不求甚解的复制最可怕 3）没有学习和理解，到头来终究是有报应的 短期也未必提升效率：1）N多次帮人调代码都是赶在上线前发现拷贝的代码根本没理解，出了问题不会调试不会解决 2）相当一部分bug出在复制代码上 3）复制代码就是花20%时间完成80%的开发，外加100%的时间去调试和解决bug，再加300%的时间去解决上线后的bug，再花不知道多少时间去重写

产品经理(PD)和研发分工(RD)，再扯上美工(UE)
这个不同公司、不同的职责定位都有差异，我更倾向于PD做产品分析、用户行为分析，而不是去纠结用户名最长多少字节，不是纠结实时性服务延迟1分钟还是1分半。最牛叉的PD，我也不敢跟着他拍脑袋决定的想法去干活。如果可以的话，我更希望知道做个产品、加个特性究竟是为什么，而不是说这个人经验丰富。
要我做PD，RD问我用户名最长多少，那就不限制最好了；实时服务延迟多长时间能接受，是个做产品设计的都希望不要延迟；
再回到用户登陆用例上来说一下我想象中的分工
1) 假设用户登陆长远来看并非重要功能，仅仅只是产品中若干个地方真的依赖注册用户，那就随意设计就好了，当面跟UE、RD聊一下想法，记录下来UE作图、RD按照自己的想法去做。不重要的内容PD就不用太关心、纠结细节了。至于担心页面风格不伦不类，那是UE职责，相信他；至于安全、开发细节等相信RD；至于若干功能细节，讨论前整理一些基本资料，开会确定一下就好了。
2) 如果用户中心是个非常重要的功能的话
我希望PD能够知道（或调研）一下各种方案，包括中文用户、英文用户还是邮箱作为用户名；注册页面是ID+密码，还是再加详细信息；是立即注册，还是填写订单后再注册；是否采用OAuth登陆；分析优缺点，结合产品属性与规划，做出相应决策；；同样，用户名长度不是重点。
RD需要知道（或调研）各种实现细节，比如OAuth；安全，比如密码保护、加密方法；是否采用https等。最重要一点：在技术上给PD提供参考与建议。比如单点登陆、https等有些技术，或者某些新技术PD可能不知道，这时候就是RD参与产品设计的一个点。
UE去页面美工、交互，比如js验证一下用户名长度等

补充一个：
产品经理也是人，不要指望产品经理有多年的经验就可以拍拍脑袋，搞出来个火爆的产品
创业团队小改动应该是持续的、经常的，但是没有合理的AB Test方案、不做日志统计、不做分析、不做回顾、总结与分享，那所有的改动就是扯淡
同一团队、同一个目标。产品经理不应该是PRD上的那个作者，程序员不应该是死开发。一起并肩作战，兄弟一样的感情和沟通才是创业团队应该有的气氛。

一点看法
1) 产品经理任何情况下都不应该随时改需求
2) 产品经理不应该只是讲想法，而且要为自己的想法写下文字记录、说明，以及期望的目标
3) 产品经理只要给出产品结构上的信息就行，比如”在用户名称旁边放置一个头像“，结构如何安排。细节交个UE、开发完成，但是产品经理需要去协调
4) 开发人员需要参与产品设计，不然去大公司、死板的公司做螺丝钉好了，不要趟创业的水
5) 开发人员(尤其是前端)需要重点参与产品细节设计，工程师不关注web上的细节设计，工作状态停留在”A需求？可以做；B需求？做不了“，那哪来HTML5？哪来IE7？哪来进步？
6) 研发人员一天天对着代码，光靠文档就能了解需求？不懂需求哪来系统设计？