zt写给Git初学者的7个建议

https://blog.jobbole.com/50603/

本文由伯乐在线 – 吴鹏煜翻译自 sixrevisions。欢迎加入技术翻译小组。转载请参见文章末尾处的要求。

当我刚刚开始使用Git的版本控制时，我根本不确定我付出那么多时间是不是会得到回报。Branch、Stage、Stash，这些Git名词对我来说都非常陌生。

而今天的我已不能想象生活没有Git会变成什么样。Git不仅提供了我非常需要的版本控制功能，还让我变成一个更优秀的程序员。

这里有一系列可以帮助你的小贴士，可以让Git成为你开发工作中非常重要的一部分。

第一条：花时间去学习Git的基本操作

学习Git的基本操作并不是要求你把整个Git文档从头到尾读完（但如果这就是你的方式，我也不会反对）。

Git里面有太多的教育内容，我很确定里面一定有对你胃口的最佳学习方式。

看一下以下这些Git学习资源吧：

怎么快速开始使用Git
试试Git – 15分钟的Git交互教程
提示和技巧（Ry的Git教学）是常见Git功能的实践教程
Git简单指南
Git Ready是一个收藏有许多简单而简短的Git提示的网站
Git作弊码
Git Tower学习区是一个在我的网站上的Git学习资源列表
Git官方教程
Training: Git Basics (视频)是YouTube上的一个视频列表
Pro Git一本让你深入了解Git的在线书籍

第二条：从简单的Git工作流开始

少即是多。

常常的，Git会和一个复杂的工作流联系起来。不过我可以这么说：你还暂时不需要为了Git的诸多好处，而一下子变成Git大师。

Git的工作流是可以非常简单的 —- 而且在许多情况下你需要的就是这么简单。你当然可以用multiple remote repositories、issue pull request、rebase changes等等，但是你不想用这些的话完全可以不用。

从简单的工作流入手也会使日后添加复杂性或者使用Git高级功能变得简单。当你需要使用这些功能的时候，Git已经准备好了。

这里有一些不同的Git工作流的例子，你可以从他们的想法中得到启发

总的来说：不要因为觉得Git什么都要学就压力很大，你完全可以从今天开始使用Git。

第三条：不要再害怕犯错误

Git最出色的一点是：它几乎是100%易上手误操作的。

记住以下几点会让你晚上睡得更香：

Git基本上不删除数据。即使是那些看起来是删除数据的操作，实际上是为了让你更快的撤销删除，而在向系统添加数据。
Git基本可以撤销所有操作。我鼓励你更多的实验和探索你的想法，因为这就是使用版本控制系统系统的最主要的好处之一。
你团队的每一个成员都在他／她的计算机中有各自的副本。本质上这更像是整个版本控制项目中的冗余备份（包括包括整个历史纪录），你捅了大娄子而且还没办法还原这种情况是极其少见的。

第四条：理解分支概念

在Git里面，分支这个概念是你一开始能学到的最有用的东西了。分支允许你隔离开发你的项目，而要想成为一个高效的Git用户，这是非常关键的一点。

一开始这听起来好像不是什么大事，但一旦你完全的理解了分支概念，你会开始想没有这个你怎么活下去。

尽管其他的版本控制系统也会使用分支概念，Git是第一个实现它，并让它变的好用的系统。

这里有一些有助你了解Git分支概念的资源：

LearnGitBranching!是一个Git分支的交互式教程
Git基本分支和合并
分支术是一个Git分支和合并的简短介绍
Git分支是一个很多绘图的Git教程
一个成熟的Git分支模型

第五条：学习暂存区

当你的提交里面只包含一些相关的变化时，版本控制会变的非常有用[b]，它保证了你的提交可以被没有任何副作用的回滚，经常提交的习惯也可以让你的同事更好的了解你的进度。

Git有个功能叫暂存区让这一切都变为可能

学习使用暂存区，并爱上它，因为这是Git里面最重要最独立的一个模块。

为什么暂存区那么有用
用暂存区的好处在哪 —- 一个有关Git暂存区的讨论主题
啊哈！学习Git的那些时候 —- 一篇博客文章
Git上有关暂存区的简短教程

第六条：用Git图形界面

尽管使用图形界面绝对不会是一个要求，但我还是高度推荐使用。

使用图形界面让大多数操作都变得简单，让你在项目开始时便占尽优势。

不管怎么说，使用Git不应该只是记住各种命令和参数，而是改进你的编程工作流。如果图形界面可以做到这一点的话，没有理由让简单的事变的困难嘛。

看一下这些Git界面吧：

Tortoise Git – Windows平台下的开源Git图形界面
GitX(L) – Mac OS X下的开源Git客户端
SourceTree – Windows和Mac下的免费Git或Mecurial界面
git-cola – 一款开源Git界面
Tower – 我们公司为Mac用户所出的Git界面

使用图形界面并不能减轻你学习Git基础的负担，不过一旦你快乐的征服了Git，使用这些工具会让你的生活变得更轻松。

第七条：对自己承诺你会用Git

使用一个新工具一开始会让人非常头疼，走过这条学习曲线的方法只有一个：继续走下去。

做一个充分的承诺，不要回头。在你平常的工作流里引入Git很快就会被证明这是你近期做的最大的，最有意义的决定。

避免这种情况：「我会在这个项目里使用Git，但其他项目就再说了。」至少一开始不要这样。

充分承诺的这种心态会让你有更多的机会去练习，让事情变得更加简单，因为你知道你现在这个项目用了版本控制系统。而更重要的是，让Git成为你的编程习惯。

未来不久，你就会看到只有那么一些情况不需要用到Git，

对自己做一个100%的承诺，作为Git征服之路的开始。

转载-玩转Trello

https://sbbs.me/view_article/5225fb0f60e794ae6c000004#

“软件开发，长夜漫漫，何以脱困，唯有Trello！”

在最近的一段时间，开始全面采用Trello管理团队的开发工作，并因此对敏捷软件开发，有了一些新的思考…

为何选择Trello

软件开发的管理工具，千千万万，为何会选择Trello呢？别人选择的理由，也许各有不同，而我的选择，则来自于我对于软件管理的基本看法：

开发管理的本质不是管理，而是培养良好的习惯；
好的工具，有助于团队成员养成良好的习惯，而糟糕的工具，只会给人带来痛苦；
软件开发是一个不断迭代的过程，一个团队的软件开发的效率与质量，也应该是一个不断改进提高的过程，好的工具，能够帮助团队不断改进提高；
管理过程中的透明度极为重要，无论是团队内的透明，还是对外、对上的透明，都意义巨大；

基于以上这些理由，我们选择了Trello，容我细细道来。

一分钟入门

Trello是一个非常容易使用的Web应用，当然他还有iPhone、iPad、Android的移动版本。上手最简单的办法，是使用Google Account登录，连注册都不需要了。

登录Trello以后，有一个Welcome Board，演示了一些最基本的用法，也可以看一看视频：

定义协作模型

Trello可以用来管理很多不同的个人事务、团队任务，而每一种类型的任务，其协作模型是大不相同的。这正是Trello最令人赞叹的地方，其他所有类型的管理工具，都没有这么方便的自定义流程模型的能力。

在定义协作模型时，我强烈建议在每个work环节之间，设置一个等待环节。这种设置的原因，有一个简单的解释，以及一个复杂的理论支撑。

简单的解释就是：当我完成了自己这个阶段的工作，并不意味着下个阶段即刻开始，放入等待区，可以表明由下一阶段的人员挑选的含义。如果直接拖入下一阶段，可能会造成下个阶段的人正在同时忙很多事情的假象。

详细的解释，可以参考《精益开发实战——用看板管理大型项目》一书。

在我们的实际开发中，定义了一下几个List：

需求区
开发等待区
开发
测试等待区
测试
发布等待区
发布

基本流程

所有的需求，首先出现在需求区；
每周一，开一个周例会，将本周计划完成的卡片，拖入开发等待区；
每天，每个开发人员只会从开发等待区中，拖一张卡片到开发区，并且将任务分配给自己；
只有在一个卡片开发完成，并且由开发人员拖入测试等待区之后，才能再拖一张卡片到开发区；
每天，每个测试人员会从测试等待区，拖一张卡片到测试区，并且将任务分配给自己；
只有在一个卡片测试完成之后，测试人员才能将这种卡片拖入发布等待区；
在卡片的功能发布成功之后，发布人员将卡片拖入发布区；

label颜色的用法

目前，我们的用法是，不再区分内测、外测、压测等各个阶段，而是给卡片标上不同颜色的label，代表它通过了什么样的测试。

目前看来，似乎可行。不过，我总感觉不是太对。

另一个选择是：用label代表不同的卡片类型，比如功能、bug、hotfix等等，不过目前来看，还没有总结出较为稳定的实践经验，也期待与其他trello用户多多交流。

管理中的基本要点

每天早上，我们都会开一个晨会，讨论今天的工作。开发人员先轮流发言，告诉大家自己打算开发的卡片；然后测试人员再轮流发言，根据之前遗留的卡片以及今天可能新增的卡片，计划今天的测试工作；
在开发人员与测试人员都发言结束后，由一个专门的同事，总结今天的计划发布上线的卡片（这就是今天的整个团队的目标了）
除了每天的工作交流，更加重要的工作，是反复强调、不断完善工作中的小习惯与小规范。

举例之一：每天的任何时候，只有自己正在做的工作，才拖入自己的List，不要提前拖入，不要忘记拖走；
举例之二：不要提前分配任务，而是到当天开完晨会之后，再做分配；
举例之三：在测试之前，较为复杂的卡片，测试人员与开发人员，需要在一起讨论，并将测试的要点，记入CheckList
举例之四：不要拖入下一个环节，而是放入等待区，否则无法准确的计算工作时间
举例之五：测试发现bug，要将卡片拖到开发等待区，而不是直接拖入开发区

总之，在使用Trello的过程中，我们一直在讨论，更好的用法，以及更加习惯的用法。

直观情况下能够发现的问题

Trello是一个非常直观的工具，仅仅通过肉眼观察，就可以发现很多管理中的问题，并及时加以改进。

1、等待区的大量堆积，通常都意味着出现了问题。

如果开发等待区出现堆积，尤其是到了临近周末，依然有很多卡片没有拖走，则意味着一周的开发计划，在周一时制定得过于乐观了。
如果测试等待区出现堆积，则意味着开发的进展超过了测试的进展，当团队的两个部分效率不一致时：总是需要警惕的状况。
如果发布等待区出现堆积，则意味着明明已经开发完成的功能，却不能及时发布，通常是由于功能之间相互依赖，而在制定开发计划时，对于版本规划做得不够清晰的原因。

2、工作区的卡片数量，应该与工作人数相等，如果超过工作人数，则说明使用不规范了。

3、某些List空了，从表面来看，是工作完成了的好现象，但如果一直空着，也是问题。

开发等待区空了：如果在周五出现这个现象，那是好事。如果在上半周就出现这样的问题，则意味着工作计划过于保守。
测试等待区空了，甚至连测试区都空了：开发环节多半出了问题，测试人员现在已经没活干了。
发布等待区空了，如果是长时间一直空着，则意味着已经好久没有测试完成的卡片了，可能测试遇到了瓶颈。

量化分析——Trello API

Trello是个看板系统，但是，仅仅像这样的直观的观察看板，是不够的，我们需要对自己的工作有更加深入的了解。还好，Trello提供了非常强大的API：Trello API Documentation

非常简单的一些代码，就可以访问Trello的Board数据，然后将这些数据导出来，做进一步的分析。

从我们的需要出发，有两个数据结构需要深入了解：

在OAuth登录之后，访问：https://api.trello.com/1/boards/board_id/cards 可以得到一个Board中的所有的卡片的数据。其中一个卡片的数据结构如下：

  {
    id: "50bc61474d0451697100116f",
    badges: {
      votes: 0,
      viewingMemberVoted: false,
      subscribed: false,
      fogbugz: "",
      checkItems: 0,
      checkItemsChecked: 0,
      comments: 0,
      attachments: 0,
      description: false,
      due: null
    },
    checkItemStates: [],
    closed: false,
    dateLastActivity: "2012-06-03T14:02:18.556Z",
    desc: "",
    descData: null,
    due: null,
    idBoard: "50bc61474d04516971001162",
    idChecklists: [],
    idList: "50bc61474d0451697100116b",
    idMembers: [],
    idMembersVoted: [],
    idShort: 1,
    idAttachmentCover: null,
    manualCoverAttachment: false,
    labels: [],
    name: "Welcome to Trello!",
    pos: 65536,
    shortLink: "2px9lS4p",
    shortUrl: "https://trello.com/c/2px9lS4p",
    subscribed: false,
    url: "https://trello.com/c/2px9lS4p/1-welcome-to-trello"
  }

而访问一个卡片的所有Actions，则可以通过以下API：https://api.trello.com/1/card/card_id/actions?filter=all 其中一个Action的数据结构如下：

  {
    id: "5229ee9e68a889bc250020ee",
    idMemberCreator: "50bc61464d04516971001161",
    data: {
      board: {
        name: "Welcome Board",
        id: "50bc61474d04516971001162"
      },
      card: {
        idShort: 7,
        name: "Invite your team to this board using the Add Members button",
        id: "50bc61474d0451697100117c"
      },
      text: "test"
    },
    type: "commentCard",
    date: "2013-09-06T15:02:54.629Z",
    memberCreator: {
      id: "50bc61464d04516971001161",
      avatarHash: "",
      fullName: "zhuangbiaowei",
      initials: "庄表伟",
      username: "zhuangbiaowei"
    }
  }

量化分析——本地数据结构

通过Trello API，我可以将数据导入到本地的一个SQLite3的数据库中，表结构如下所示：

CREATE TABLE cards (
  id text,
  cat1 text,
  cat2 text,
  cat3 text,
  name text,
  closed boolean,
  last_date date,
  last_list text
);
CREATE TABLE actions (
  id text,
  card_id text,
  type text,
  data text,
  date date,
  creator text
);
CREATE TABLE card_move (
  id text,
  card_id text,
  before text,
  after text,
  date date,
  creator text
);
CREATE TABLE card_time_count (
  card_id text,
  user_id text,
  time_count float
);
CREATE TABLE card_wait_time(
  card_id text,
  list_id text,
  time_count float
);
CREATE TABLE work_time(
  card_id text,
  user_id text,
  end date,
  work_time float
);
CREATE TABLE last_date(
  last_date text
);

一张卡片的生命周期

从卡片被创建开始，将会经历很多的改变，这些改变都会被记录为一个一个的Action，在Action的JSON数据结构中，有一个type属性，代表着action的类型。其中createCard、updateCard、addMemberToCard、removeMemberFromCard较为重要。

当卡片被创建时：createCard；
当卡片被移动时：updateCard；
当某人被安排加入某卡片的工作时：addMemberToCard；
当某人不再参与某卡片的工作时：removeMemberFromCard；

具体的生命周期将是这样的：

在日常的工作中，我们会在需求区创建一张卡片->createCard
然后在每周一将这张卡片移入开发等待区->updateCard
每天的工作开始时，开发人员将这张卡片移入开发区->updateCard
同时将自己加入这张卡片->addMemberToCard
当他开发完成时，将这张卡片移入测试等待区->updateCard
测试人员在空闲时，将会把这张卡片，移入测试区->updateCard
同时将自己加入这张卡片->addMemberToCard
测试人员完成测试时，将卡片移入发布等待区->updateCard
发布人员完成发布后，将卡片移入已发布区->updateCard

以上描述的，是一张卡片最正常情况下的生命周期，而事实上，还可能存在很多种不同的情况。

测试发现bug，卡片移入开发等待区
发布发现问题，卡片移入测试等待区
人员重新安排工作时，需要removeMemberFromCard，再addMemberToCard
因为需求表述不清，卡片可能重新回到需求区
因为需求较为复杂，一张卡片可能被分解为多张卡片
需求不明确的卡片，可能被直接删除

一张卡片能够产生出的时间与数值

卡片从最初被创建，到最终移入发布区，是整个卡片的生命周期，这代表一张卡片最终需要花费多长的时间，才会被完成。（LifeTime）
卡片从首次进入开发等待区，到最终移入发布区，代表工作时间长度。（WorkTime）
在开发区停留的时间（可能多次进入开发区），可以称为（DevTime）
在测试区停留的时间（可能多次进入测试区），可以称为（TestTime）
DevTime+TestTime=RealWorkTime，代表实际工作时间
WorkTime-RealWorkTime=WaitTime，代表由于多任务并行或其他原因，卡片等待的时间
RealWorkTime / WorkTime，代表这张卡片的实际开发效率（被浪费的等待时间，越少越好）
RealWorkTime / LifeTime，代表这张卡片的受重视程度（被排入开发计划之前的等待时间越少，则越受重视）
当卡片停留在开发区时，这张卡片的Members中，开发人员的时间被计算。如果只有一个开发人员，则只加这一个人的工作时间，如果有多人同时是这张卡片的开发人员，则每人都计算相同的一段工作时间。可以称之为(DevWorkTime)
当卡片停留在测试区时，情况与开发区类似，只是针对特定的测试人员，可以称为（TestWorkTime）
DevWorkTime+TestWorkTime=TotalWorkTime，代表这张卡片的实际投入工作量
正常情况下，卡片只会从左向右移动，如果出现了向左移动的情况，则代表开发过程出现了问题，可以计算LeftMoveTimes / LifeTime，代表这张卡片的工作顺利程度

卡片的命名规范

怎么到现在才来讨论命名规范呢？因为，关于命名的问题，是在卡片多了以后，才浮现出来的。

卡片多起来了，分别属于不同的项目，不同的模块，不同的版本；这时候，我们小组面临另一个选择：就是每个项目开一个Board，然后分别管理。

但是，这个构想被迅速的否决了，因为这些卡片的工作都是交替进行的，我们衍生出了一个“主工作Board”的概念，90%的小组工作，都在一块板上体现出来，而不是散落在各个不同的地方，否则，总会有漏看的时候。

于是，我们的命名规范是这么定的：[部门-项目-模块]卡片名。这是我们目前的用法，其实还有两个纠结：

在命名中是否要明确标出一个卡片是不是bug？

第一个问题，目前我们没有明确标明，不过感觉今后应该更加规范起来，但是如何规范，是用命名还是用颜色label，还在犹豫中。

在命名中是否有版本号？

第二个问题，介于我们现在的具体工作，很少能够划分清晰的版本号，所以也没有使用。

卡片的粒度把握

对于一张卡片的粒度，我们其实没有什么仔细的“把握”，实际的做法是：借助数据统计工具，不断追求缩短每张卡片的完成时间（这样做的后果是，卡片的粒度会越来越趋于微小。）；另外从测试的角度，确保每一张卡片，可以被独立的、有效的测试。（这样的后果是，卡片的粒度，不会无限制的越来越小。）

最小可测试单元，是我们发明的一个新概念，通过将开发工作划分为一个一个的最小可测试单元，我们将最大限度的减少工作环节之间的等待情况。

以一张卡片来举例：如果一张卡片，需要8小时才能完成，那么测试人员，最快也要在8小时后开始测试；如果8小时的卡片能够分解为4张2小时的卡片，那么测试人员最快在2小时后，就能够开始工作。

就好比在瓶子里装石头，石头的颗粒越小，则瓶子内的空间才能够被越充分的利用，这就是通过减少浪费与等待，从而实际提高工作效率的办法！

多卡片的统计指标

上文描述了一张卡片的生命周期，而在实际的开发过程中，我们肯定会面对很多很多张卡片，这些卡片除了有各自的生命周期，更组成了一共不断生长的树状结构。

我们可以参照WBS（工作分解结构）来理解这些卡片，企业有多个产品、每个产品有多个版本，每个版本有多个需求和多个bug，每个需求有可能分解为多张卡片来开发测试。

当我们根据某种规范来命名卡片以后，再将数据导入到本地的数据库，就可以很方便的做出一个统计表格，来统计各个项目的当前状况：

这样的统计，当然还只是一个很初级的静态汇总。更加深度的玩法可以有：

每周进展统计，分项目、模块，统计在一周内，分别有哪些卡片，各自前进了多少阶段。
资源投入百分比统计，分项目、模块，统计在某个阶段内，分别投入了多少开发时间、多少测试时间。

估算能力指标

所谓估算能力，不是用来衡量普通开发者的，而是用来衡量开发管理者的。一个模块、一个需求，在最初被分解为多少张卡片，这是一个初始估算。

随着团队开发效率的逐步稳定，我们可以切实的根据分解卡片的数量，对整个项目的工作量，做出预估。

到了项目结束时，我们可以得到一张图表：“卡片增长趋势图”，一个团队管理者的能力，就在于是否可以尽早的、尽可能准确的估算卡片的数量。如果，卡片在开发后期出现意外增长，则意味着一开始的估算，出现严重偏差。

这也是开发管理者，需要不断提高估算能力的地方。

除了规模估算能力，还有进度估算的能力。在不了解真实的开发效率的情况下，开发管理者通常有两个选择：高估以保护手下、低估以后压榨手下。

这两种方法，是典型的过犹不及，都不是什么好事。正确的做法是：根据实际的工作量与工作类型分布，推出一个开发团队的进度模型，进而对实际的需求，进行进度估算。

在此之前，所有的估算，都不过是耍流氓而已。

功能点？价值点！

直白一点说吧，我反对功能点估算这种学院派的算法，无比复杂，却毫不实用。只适合用来考试，根本不适合用来工作。

不考虑具体技术实现的工作量估算，根本就是在耍流氓。他们那14个所谓的调整因子，也不过是纸上谈兵而已。

在我看来，IFPUG这种组织，也无非是搞了一个巨复杂的标准规范，然后搞认证考试来赚钱罢了。

说说我的看法吧：在项目具体实施之前，越是过去没有尝试过的、缺乏经验的新项目，越是难以估算工作量与预期时间，强行估算工作量，只会增加更多无谓的“估算工作量”。

另外一个指标，我倒是建议需求方，认真估算一下：就是某一个项目、某个功能、某个User Story，可能带来的价值回报。换句话说：如果能够花钱购买这个Story，我愿意出多少钱？

传统的估算，通常都是工作量估算，一个项目30个人月。然后项目组开始拼死拼活的去干。就算一切顺利，我们10个人，干了3个月，做完了30个人月的一个项目，然后呢？无非是投入了那些工作量而已。于是，老板的眼睛就会一直盯着每日考勤统计表，看看这帮家伙，是不是每天都在加班，如果他发现没人加班，就会痛感自己“压榨得还不够”。

如果我们采用价值点估算，一共100个Story，价值100万。我们10个人，第一个月就完成了价值50万的Story。作为老板，根本不必关心我们是在一个月里，每天干10小时做完的；还是每天干6小时做完的。相对而言，如果我们能够每天6小时就干完，只怕他应该更高兴，因为这样为他省电了。

做早饭与超越敏捷

前段时间的某一天早上，我因为机缘巧合，居然早早的就醒了，于是突发奇想，决定主动为家里人，做一顿早饭。我打开冰箱，查看了里面的存货，然后略微思索，最后做了炒鸡蛋、蒸馒头、以及煎葱油饼三个高难度的动作。

经过妻儿试吃，评价居然尚可，我顿时有种洋洋得意的感觉。

我是多么的敏捷啊！在短短的30分钟时间里，我根据现有的条件，做出了兼具营养与美味，而且足以果腹的一顿早餐。所谓看菜做饭，不就是敏捷里的高效快速迭代吗？我们不做计划，但是，我们可以随时灵活调整。

不过，我并没有自我陶醉太久。进一步的思考涌上心头：

一个称职的妈妈，会像我这样吗？
如果冰箱里没有东西怎么办？（称职的妈妈早就提前买好了）
如果营养不协调怎么办？（称职的妈妈会考虑全家人的健康）
难道不需要考虑家庭支出吗？（称职的妈妈会每个月精打细算）
难道不需要事先考虑个人的口味吗？（称职的妈妈会了解每个人的口味，甚至还会不断花样翻新）

抄一段我过去的文章吧：

后来，软件大师们，发明了一个新的办法：既然不能指哪打哪，那就打哪指哪。既然不能在给定的时间内完成任务，那么就反过来画个圈，这个阶段咱们完成的任务，就是咱们的阶段目标。

在给这种“掩耳盗铃”开发模式，起了一个漂亮的名字之后，这种敏捷开发的方式，在全世界流行起来了！

但是，真正“精明”的老板，是不会上当的！在敏捷开发模式下，开发人员永远是无可指责的！所有的开发进度，开发人员拥有无可争辩的主导权：“每一个Story的开发工作量都已经被估算出来了，产品经理能够选择的，仅仅是在下个阶段先实现哪几个Story而已。”

老板们通常会说：“三个月内，我要看到这个上线，不要告诉我不可能！公司的信条是：没有借口！”

所以，像我这样做早饭是不够的。

所以，仅仅敏捷是不够的。

所谓敏捷，不过是由于软件开发过程中，各种因素难以估算，而采取的权宜之计。真正的解决之道，不是打哪指哪，而是通过合理的工具，掌握真实的开发情况，进而做出切实的工作量估算与进度计划。

这样的解决之道，我认为Trello也许是一个极好的开始！

iBistu获得全国移动互联网应用大赛三等奖

由我校网络管理中心组织师生自主开发的校园移动应用iBistu参加了全国移动互联网应用大赛，获得评委肯定入围决赛。在8月23日、24日的现场决赛中，我校代表参加了比赛进行现场展示和答辩，最终获得了三等奖，并获得价值3万元的云测基金。

全国移动互联网应用大赛由中国电子学会主办、现代教育技术分会承办，大赛的首席科学家、大赛组委会竞赛委员会主席由中科院梅宏院士担任，小灵通之父吴鹰担任高级顾问，来自各地的知名高校教授、基础教育界专家、移动互联网资深软硬件专家担任评委。工信部领导、中国科协领导和业界知名企业家和学会总部领导参加了颁奖仪式并致辞，新华社、人民日报、光明日报、中国青年报、中国教育报等多家媒体参会报导。

iBistu已经在苹果Appstroe应用商店上线，欢迎师生下载使用。Android用户可以访问https://r.bistu.edu.cn下载（详细获奖名单见：https://www.csmet.org.cn/cms/xwdt/172.htm ）。

提问的智慧 How To Ask Questions The Smart Way

提问的智慧（How To Ask Questions The Smart Way）一文最早是由Eric Steven Raymond所撰写，说明了作者所认为一位发问者事前应该要做好什么，而什么又是不该做的。作者认为这样能让问题容易令人理解，而且发问者自己也能学到较多东西。

此文在网络上受到欢迎，被广泛转载而广为人知甚至奉为经典。该文也有简体中文与正体中文的翻译版本被流传着，所以在华人界也是很有名的文章。著名的两个缩写STFW（Search the fxxking web）以及RTFM（Read the fxxking manual）就是出自本文。

英文版 https://www.catb.org/~esr/faqs/smart-questions.html
中文版 https://www.wapm.cn/smart-questions/smart-questions-zh.html

引言

在黑客的世界里，你所提技术问题的解答很大程度上取决于你提问的方式与解决此问题的难度，本文将教你如何提问才更有可能得到满意的答复。

开源程序的应用已经很广，你通常可以从其他更有经验的用户而不是黑客那里得到解答。这是好事，他们一般对新手常有的毛病更容忍一点。然尔，使用我们推荐的方法，象对待黑客那样对待这些有经验的用户，通常能最有效地得到问题的解答。

第一件需要明白的事是黑客喜欢难题和激发思考的好问题。假如不是这样，我们也不会写本文了。如果你能提出一个有趣的问题让我们咀嚼玩味，我们会感激你。好问题是种激励与礼物，帮助我们发展认知，揭示没有注意或想到的问题。在黑客中，“好问题！” 是非常热烈而真挚的赞许。

此外，黑客还有遇到简单问题就表现出敌视或傲慢的名声。有时，我们看起来还对新手和愚蠢的家伙有条件反射式的无礼，但事情并不真是这样。

我们只是毫无歉意地敌视那些提问前不愿思考、不做自己家庭作业的人。这种人就象时间无底洞──他们只知道索取，不愿意付出，他们浪费了时间，这些时间本可用于其它更有趣的问题或更值得回答的人。我们将这种人叫做 “失败者（loser）” （由于历史原因，我们有时将“loser”拼写为“lusers” 。）

我们意识到许多人只是想使用我们写的软件，他们对学习技术细节没有兴趣。对大多数人而言，计算机只是种工具，是种达到目的的手段而已。他们有自己的生活并且有更要紧的事要做，我们承认这点，也从不指望每个人都对这些让我们着迷的技术问题感兴趣。不过，我们回答问题的风格是为了适应那些真正对此有兴趣并愿意主动参与解决问题的人，这一点不会变，也不该变。如果连这都变了，我们就会在自己能做得最好的事情上不再那么犀利。

我们（大多数）是自愿者，从自己繁忙的生活中抽时间来回答问题，有时会力不从心。因此，我们会毫不留情地滤除问题，特别是那些看起来象是失败者提的，以便更有效地把回答问题的时间留给那些胜利者。

如果你认为这种态度令人反感、以施惠者自居或傲慢自大，请检查你的假设，我们并未要求你屈服──事实上，假如你做了该做的努力，我们中的大多数将非常乐意平等地与你交流，并欢迎你接纳我们的文化。试图去帮助那些不愿自救的人对我们简直没有效率。不懂没有关系，但愚蠢地做事不行。

所以，你不必在技术上很在行才能吸引我们的注意，但你必须表现出能引导你在行的姿态──机敏、有想法、善于观察、乐于主动参与问题的解决。如果你做不到这些使你与众不同的事情，我们建议你付钱跟别人签商业服务合同，而不是要求黑客无偿帮助。

如果你决定向我们求助，你不会想成为一名失败者，你也不想被看成一个失败者。得到快速有效回答的最好方法是使提问者看起来象个聪明、自信和有想法的人，并且暗示只是碰巧在某一特别问题上需要帮助。

（欢迎对本文指正，可以将建议发至 [email protected] 或 [email protected]。请注意，本文不想成为一般性的网络礼仪指南，我一般会拒绝那些与引出技术论坛中有用的回答不特别相关的建议。）

提问前

在通过电邮、新闻组或论坛提技术问题以前，做以下事情：

尝试在你准备提问论坛的历史文档中搜索答案
尝试搜索互联网以找到答案
尝试阅读手册以找到答案
尝试阅读“常见问题文档”（FAQ）以找到答案
尝试自己检查或试验以找到答案
尝试请教懂行的朋友以找到答案
如果你是程序员，尝试阅读源代码以找到答案

提问时，请先表明你已做了上述事情，这将有助于建立你不是寄生虫与浪费别人时间的印象。最好再表述你从中 学到的东西 ，我们喜欢回答那些表现出能从答案中学习的人。

运用某些策略，比如用谷歌（Google）搜索你遇到的各种错误提示（既搜索谷歌论坛，也搜索网页），这样很可能直接就找到了解决问题的文档或邮件列表线索。即使没有结果，在邮件列表或新闻组寻求帮助时提一句“我在谷歌中搜过下列句子但没有找到什么有用的东西” 也是件好事，至少它表明了搜索引擎不能提供哪些帮助。将搜索关键词与你的问题及可能的解决方案联系起来，还有助于引导其他有类似问题的人。

别着急，不要指望几秒钟的谷歌搜索就能解决一个复杂的问题。读一下常见问题文档。在向专家提问之前，先向后靠靠放松一下，再思考一下问题。相信我们，他们能从你的提问看出你做了多少阅读与思考，如果你是有备而来，将更有可能得到解答。不要将所有问题一股脑抛出，只因你的第一次搜索没有结果（或者结果太多）。

认真地思考，准备好你的问题。轻率的提问只能得到轻率的回答，或者压根没有。在提问时，你越是表现出在此前做过思考与努力去解决自己的问题，你越有可能得到真正的帮助。

注意别提错问题。如果提问基于错误的假设，某黑客多半会一边想 “愚蠢的问题……”，一边按将错就错的答案回复你，并且希望这种只是得到你自己“问的问题”而非真正所需的解答，给你一个教训。

永远不要假设你 有资格 得到解答。你没有这种资格，毕竟你没有为此服务付费。如果你能够提出有内容、有趣和激励思考的问题──那种毫无疑问能够向社区贡献经验，而不仅仅是消极地要求从别人那获取知识的问题，你将“挣到”答案。

另一方面，表明你有能力也乐意参与问题的解决是个很好的开端。“有没有人能指个方向？”，我这还差点什么？”，“我应该查哪个网站？”，通常要比 “请给出我可以用的完整步骤”更容易得到回复，因为你表明了只要有人能指个方向，你就很乐意完成剩下的过程。

提问时

仔细挑选论坛

要对在哪提问留心，如果你做了下述事情，多半会被一笔勾销或被看成“失败者”：

张贴与论坛主题无关的问题
在面向高级技术问题的论坛上张贴肤浅的问题，或者反之。
在太多不同的新闻组同时张贴
给既非熟人也没有义务解决你问题的人发送你私人的电邮

为保护通信的渠道不被无关的东西淹没，黑客会除掉那些没有找对地方的问题，你不会想让这种事落到自己头上的。

因此，第一步是找对论坛。谷歌和其它搜索引擎还是你的朋友，可以用它们搜索你遇到困难的软硬件问题最相关的项目网站。那里通常都有项目的常见问题（FAQ）、邮件列表及文档的链接。如果你的努力（包括阅读 FAQ）都没有结果，这些邮件列表就是最后能取得帮助的地方。项目的网站也许还有报告臭虫的流程或链接，如果是这样，去看看。

向陌生的人或论坛发送邮件极有可能是在冒险。譬如，不要假设一个内容丰富的网页的作者想充当你的免费顾问，不要对你的问题是否会受到欢迎做太乐观的估计──如果你不确定，向别处发或者压根别发。

在选择论坛、新闻组或邮件列表时，别太相信名字，先看看 FAQ 或者许可书以明确你的问题是否切题。发贴前先翻翻已有的帖子，这样可以让你感受一下那里行事的方式。事实上，张贴前在新闻组或邮件列表的历史文档中搜索与你问题相关的关键词是个极好的主意，也许就找到答案了。即使没有，也能帮助你归纳出更好的问题。

别象机关枪似的一次性“扫射”所有的帮助渠道，这就象大喊大叫一样会令人不快，温柔地一个一个来。

弄懂主题！最典型的错误之一是在某种致立于跨平台可移植的语言、库或工具的论坛中提关于 Unix 或 Windows 操作系统程序接口的问题。如果你不明白为什么这是大错，最好在搞清楚概念前什么也别问。

一般来说，在仔细挑选的公共论坛中提问比在私有论坛中提同样的问题更容易得到有用的回答。有几个道理支持这点，一是看潜在的回复者有多少，二是看论坛的参与者有多少，黑客更愿回答能启发多数人的问题。

可以理解，老练的黑客和一些流行软件的作者正在承受过多的不当消息。就象那根最后压垮骆驼背的稻草一样，你的加入也有可能使情况走向极端──已经好几次了，一些流行软件的作者退出了对自己软件的支持，因为伴随而来的涌入其私人邮箱的垃圾邮件变得无法忍受。

面向新手的论坛和互联网中继聊天（IRC）通常响应最快

本地的用户组织或者你所用的 Linux 发行版也许正在宣传新手取得帮助的论坛或 IRC 通道（在一些非英语国家，新手论坛很可能还是邮件列表），这些地方是开始提问的好去处，特别是当你觉得遇到的也许只是相对简单或者很普通的问题时。经过宣传的 IRC 通道是公开邀请提问的地方，通常可以得到实时的回复。

事实上，如果出问题的程序来自某发行版（这很常见），最好先去该发行版的论坛或邮件列表中提问，再到程序本身的项目论坛或邮件列表，（否则）该项目的黑客可能仅仅回复“用 我们的 代码”。

在任何论坛发贴以前，先看看有没有搜索功能。如果有，就试着用问题的几个关键词搜索一下，也许就有帮助。如果在此之前你已做过全面的网页搜索（你应该这样去做），还是再搜索一下论坛，搜索引擎有可能没来得及索引此论坛的全部内容。

通过论坛或 IRC 通道提供项目的用户支持有增长的趋势，电子邮件交流则更多地为项目开发者保留。所以先在论坛或 IRC 中寻求与该项目相关的帮助。

第二步，使用项目的邮件列表

当某个项目存在开发者邮件列表时，要向列表而不是其中的个别成员提问，即使你确信他能最好地回答你的问题。查一查项目的文档和主页，找到项目的邮件列表并使用它。采用这种办法有几个很好的理由：

向个别开发者提的问题（如果）足够好，也将对整个项目组有益。相反，如果你认为自己的问题对整个项目组来说太愚蠢，这也不能成为骚扰个别开发者的理由。
向列表提问可以分散开发者的负担，个别开发者（尤其是项目领导）也许太忙以至于没法回答你的问题。
大多数邮件列表都要存档，那些存档将被搜索引擎索引，如果你向列表提问并得到解答，将来其它人可以通过网页搜索找到你的问题和答案，也就不用再次发问了。
如果某些问题经常被问到，开发者可以利用此信息改进文档或软件本身，以使其更清楚。如果只是私下提问，就没有人能看到最常见问题的完整场景。

如果一个项目既有 “用户” 也有“开发者”（或 “黑客”）邮件列表或论坛，而你又不摆弄那些代码，向“用户”列表或论坛提问。不要假设自己会在开发者列表中受到欢迎，那些人多半会遭受你的噪音干扰。

然尔，如果你确信你的问题不一般，而且在“用户” 列表或论坛中几天都没有回复，可以试试“开发者”列表或论坛。建议你在张贴前最好先暗暗地观察几天以了解那的行事方式（事实上这是参与任何私有或半私有列表的好主意）

如果你找不到一个项目的邮件列表，而只能查到项目维护者的地址，只管向其发信。即便在这种情况下，也别假设（项目）邮件列表不存在。在你的电子邮件中陈述你已经试过但没有找到合适的邮件列表，也提及你不反对将自己的邮件转发给他人（许多人认为，即使没什么秘密，私人电子邮件也不应该被公开。通过允许将你的电子邮件转发他人，你给了相应人员处置你邮件的选择）。

使用有意义且明确的主题

在邮件列表、新闻组或论坛中，主题是你在五十个或更少的字以内吸引有资格专家注意的黄金机会，不要用诸如 “请帮我” （更别提大写的 “请帮我！！！！”，这种主题的消息会被条件反射式地删掉）之类的唠叨浪费机会。不要用你痛苦的深度来打动我们，相反，要在这点空间中使用超级简明扼要的问题描述。

使用主题的好惯例是“对象──偏差”（式的描述），许多技术支持组织就是这样做的。在“对象”部分指明是哪一个或哪一组东西有问题，在“偏差”部分则描述与期望的行为不一致的地方。

愚蠢：: 救命啊！我的笔记本视频工作不正常！
明智：: X.org 6.8.1 扭曲鼠标光标，MV1005 型号的某显卡芯片组
更明智：: 使用 MV1005 型号的某显卡芯片组在 X.org 6.8.1 的鼠标光标被扭曲

编写 “对象──偏差”式描述的过程有助于你组织对问题的细致思考。是什么被影响了？仅仅是鼠标光标或者还有其它图形？只在 X.org 中出现？或只是在其 6.8.1 版中？是针对某显卡芯片组？或者只是其中的 MV1005 型号？一个黑客只需描一眼就能够立即明白什么是你遇到的问题，什么是你自己的问题。

更一般地，想象一下在一个只显示主题的文档索引中查找。让你的主题更好地反映问题，可以使下一个搜索类似问题的人能够在文档中直接就找到答案的线索，而不用再次发贴提问。

如果你想在回复中提问，确保改变主题以表明你是在问一个问题，一个主题象 “Re: 测试” 或者 “Re: 新臭虫”的消息不太可能引起足够的注意。同时，将回复中与新主题不甚相关的引用内容尽量删除。

对于列表消息，不要直接点击回复（按钮）来开始一个全新的线索，这将限制你的观众。有些邮件阅读程序，比如 mutt，允许用户按线索排序并通过折叠线索来隐藏消息，这样做的人永远看不到你发的消息。

仅仅改变主题还不够。mutt 和其它一些邮件阅读程序还要检查邮件头主题以外的其它信息，以便为其指定线索，所以宁可发一个全新的邮件。

在论坛，因为消息与特定的线索紧密结合，并且通常在线索之外不可见，好的提问方式略有不同，通过回复提问并不要紧。不是所有论坛都允许在回复中出现分离的主题，而且这样做了基本上没有人会去看。不过，通过回复提问本身就是令人怀疑的做法，因为它们只会被正在查看该线索的人读到。所以，除非你只想在该线索当前活跃的人群中提问，还是另起炉灶比较好。

使问题容易回复

以“请向……回复”来结束问题多半会使你得不到回答。如果你觉得花几秒钟在邮件客户端设置一下回复地址都麻烦，我们也觉得花几秒钟考虑你的问题更麻烦。如果你的邮件客户端程序不支持这样做，换个好点的；如果是操作系统不支持所有这种邮件客户端程序，也换个好点的。

在论坛，要求通过电子邮件回复是完全无礼的，除非你确信回复的信息也许是敏感的（而且有人会为了某些未知的原因，只让你而不是整个论坛知道答案）。如果你只是想在有人回复线索时得到电子邮件提醒，可以要求论坛发送。几乎所有论坛都支持诸如“留意本线索”、“有回复发送邮件”等功能。

用清晰、语法、拼写正确的语句书写

经验告诉我们，粗心与草率的作者通常也粗心与草率地思考和编程（我敢打赌）。为这些粗心与草率的思考者回答问题没有什么好处，我们宁可将时间花在其它地方。

清楚、良好地表达你的问题非常重要。如果你觉得这样做麻烦，我们也觉得注意（你的问题）麻烦。花点额外的精力斟酌一下字句，用不着太僵硬与正式──事实上，黑客文化很看重能准确地使用非正式、俚语和幽默的语句。但它必须很准确，而且有迹象表明你是在思考和关注问题。

正确地拼写、使用标点和大小写，不要将“its”混淆为“it’s”，“loose”搞成“lose”或者将“discrete”弄成 “discreet”。不要全部用大写，这会被视为无礼的大声嚷嚷（全部小写也好不到哪去，因为不易阅读。Alan Cox [注：著名黑客，Linux 内核的重要参与者] 也许可以这样做，但你不行。）

一般而言，如果你写得象个半文盲似的傻子，多半得不到理睬。也不要使用即时通讯中的简写，如将“you”简化为“u”会使你看起来象一个为了节约二次击键的半文盲式的傻子。更糟的是，如果象个小孩似地鬼画桃符那绝对是在找死，可以肯定没人会理你（或者最多是给你一大堆指责与挖苦）。

如果在非母语论坛提问，你的拼写与语法错误会得到有限的宽容，但懒惰完全不会被容忍（是的，我们通常看得出其中的差别）。同时，除非你知道回复者使用的语言，请使用英语书写。繁忙的黑客一般会直接删除用他们看不懂语言写的消息。在互联网上英语是工作语言，用英语书写可以将你的问题不被阅读就被直接删除的可能性降到最低。

使用易于读取且标准的文件格式发送问题

如果你人为地将问题搞得难以阅读，它多半会被忽略，人们更愿读易懂的问题，所以：

使用纯文本而不是 HTML（超文本标注语言）（关闭HTML 并不难）
使用 MIME（多用途互联网邮件扩展）附件通常没有问题，前提是真正有内容（譬如附带的源文件或补丁），而不仅仅是邮件客户端程序生成的模板（譬如只是消息内容的拷贝）。
不要发送整段只是单行句子但多次折回的邮件（这使得回复部分内容非常困难）。设想你的读者是在80个字符宽的文本终端阅读邮件，设置你的行折回点小于 80 列。
但是，也不要用任何固定列折回数据（譬如日志文件拷贝或会话记录）。数据应该原样包含，使回复者确信他们看到的是与你看到的一样的东西。
在英语论坛中，不要使用’Quoted-Printable’ MIME 编码发送消息。这种编码对于张贴非 ASCII 语言可能是必须的，但很多邮件程序并不支持。当它们分断时，那些文本中四处散布的 “=20”符号既难看也分散注意力，甚至有可能破坏内容的语意。
永远不要 指望黑客们阅读使用封闭的专用格式编写的文档，诸如微软公司的 Word 或 Excel 文件等。大多数黑客对此的反应就象有人将还在冒热气的猪粪倒在你门口时你的反应一样。即使他们能够处理，也很厌恶这么做。
如果你从使用视窗的电脑发送电子邮件，关闭微软愚蠢的“聪明引用”功能，以免在你的邮件中到处散布垃圾字符。
在论坛，勿滥用“表情符号”和“HTML”功能(当它们提供时)。一两个表情符号通常没有问题，但花哨的彩色文本倾向于使人认为你是个无能之辈。过滥地使用表情符号、色彩和字体会使你看来象个傻笑的小姑娘。这通常不是个好主意，除非你只是对性而不是有用的回复更有兴趣。

如果你使用图形用户界面的邮件客户端程序(如网景公司的 Messenger、微软公司的 Outlook 或者其它类似的)，注意它们的缺省配置不一定满足这些要求。大多数这类程序有基于菜单的“查看源码”命令，用它来检查发送文件夹中的消息，以确保发送的是没有多余杂质的纯文本文件。

描述问题应准确且有内容

仔细、清楚地描述问题的症状
描述问题发生的环境(主机、操作系统、应用程序，任何相关的)，提供销售商的发行版和版本号（如：“Fedora Core 7”、“Slackware 9.1”等）
描述提问前做过的研究及其理解。
描述提问前为确定问题而采取的诊断步骤。
描述最近对计算机或软件配置的任何相关改变。
如果可能，提供在可控环境下重现问题的方法。

尽最大努力预测黑客会提到的问题，并提前备好答案。

如果你认为是代码有问题，向黑客提供在可控环境下重现问题的方法尤其重要。当你这么做时，得到有用且及时回复的可能性将大大增加。

西蒙.泰瑟姆（Simon Tatham）写过一篇如何有效报告臭虫的文章，我强烈推荐各位阅读。

量不在多，精炼则灵

你应该（写得）精炼且有内容，简单地将一大堆代码或数据罗列在求助消息中达不到目的。如果你有一个很大且复杂的测试样例让程序崩溃，尝试将其裁剪得越小越好。

至少有三个理由支持这点。第一，让别人看到你在努力简化问题使你更有可能得到回复。第二，简化问题使你更有可能得到 有用的 回复。第三，在提纯臭虫报告的过程中，你可能自己就找到了解决办法或权宜之计。

别急于宣称找到臭虫

当你在一个软件中遇到问题，除非你 非常、非常 的有根据，不要动辄声称找到了臭虫。提示：除非你能提供解决问题的源代码补丁，或者对前一版本的回归测试表现出不正确的行为，否则你都多半不够完全确信。对于网页和文档也如此，如果你（声称）发现了文档的“臭虫”，你应该能提供相应位置的替代文本。

记住，还有许多其它用户并未经历你遇到的问题，否则你在阅读文档或搜索网页时就应该发现了（你在报怨前已经做了这些，是吧？）。这也意味着很有可能是你弄错了而不是软件本身有问题。

编写软件的人总是非常辛苦地使它尽可能完美。如果你声称找到了臭虫，也就置疑了他们的能力，即使你是对的，也有可能会使其中的部分人感到不快。（此外，）在主题中嚷嚷“臭虫”也是特别不老练的。

提问时，即使你私下非常确信已经发现一个真正的臭虫，最好写得象是你做错了什么。如果真的有臭虫，你会在回复中看到这点。这样做的话，如果真有虫子，维护者就会向你道歉，这总比你弄砸了然后欠别人一个道歉要强。

低声下气代替不了做自己的家庭作业

有些人明白他们不应该粗鲁或傲慢地行事并要求得到答复，但他们退到相反的低声下气的极端：“我知道我只是个可怜的新丁，一个失败者，但……”。这既使人困扰，也没有用，当伴随着对实际问题含糊的描述时还特别令人反感。

别用低级灵长类动物的办法浪费你我的时间，相反，尽可能清楚地描述背景情况和你的问题，这比低声下气更好地摆正了你的位置。

有时，论坛设有单独的初学者提问版面，如果你真的认为遇到了肤浅的问题，到那去就是了，但一样别低声下气。

描述问题症状而不是猜测

告诉黑客是什么导致了问题是没用的（如果你的诊断理论是了不起的东西，你还会向别人咨询求助吗？）。所以，确保只是告诉他们问题的原始症状，而不是你的解释和理论，让他们来解释和诊断。如果你认为陈述自己的猜测很重要，应清楚地说明这只是你的猜测并描述为什么它们不起作用。

愚蠢：: 我在编译内核时接连遇到 SIG11 错误，怀疑主板上的某根电路丝断了，找到它们的最好办法是什么？
明智：: 我组装的电脑（K6/233 CPU、FIC-PA2007 主板[威盛 Apollo VP2 芯片组]、Corsair PC133 SDRAM 256Mb 内存）最近在开机 20 分钟左右、做内核编译时频繁地报 SIG11 错，但在头 20 分钟内从不出问题。重启动不会复位时钟，但整夜关机会。更换所有内存未解决问题，相关的典型编译会话日志附后。

由于以上这点许多人似乎难以掌握，这里有句话可以提醒你：“所有的诊断专家都来自密苏里州”。美国国务院的官方座右铭则是“让我看看”（出自国会议员威勒德.D.范迪弗［Willard D. Vandiver］在1899年时的讲话：“我来自一个出产玉米、棉花、牛蒡和民主党人的国家，滔滔雄辩既不能说服我，也不会让我满意。我来自密苏里州，你必须让我看看。”）针对诊断者而言，这并不是怀疑，而只是一种真实而有用的需求，以便让他们看到与你看到的原始证据尽可能一致的东西，而不是你的猜测与总结。（所以，）让我们看看。

按时间先后罗列问题症状

刚出问题之前发生的事情通常包含有解决问题最有效的线索。所以，记录中应准确地描述你、电脑和软件在崩溃前都做了什么。在命令行处理的情况下，有会话日志（如运行脚本工具生成的）并引用相关的若干（如20）行记录会非常有帮助。

如果崩溃的程序有诊断选项（如-v详述开关），试着选择这些能在记录中增加排错信息的选项。记住，“多”不等于“好”。试着选取适当的排错级别以便提供有用的信息而不是将阅读者淹没在垃圾中。

如果你的记录很长（如超过四段），在开头简述问题随后按时间先后罗列详细过程也许更有用。这样，黑客在读你的记录时就知道该注意哪些内容了。

描述目标而不是过程

如果你想弄清楚如何做某事（而不是报告一个臭虫），在开头就描述你的目标，然后才陈述遇到问题的特定步骤。

经常出现这种情况，寻求技术帮助的人在脑袋里有个更高层次的目标，他们在自以为能达到目标的特定道路上被卡住了，然后跑来问该怎么走，但没有意识到这条路本身有问题，结果要费很大的劲才能通过。

愚蠢：: 我怎样才能让某图形程序的颜色拾取器取得十六进制的 RGB 值？
明智：: 我正试着用自己选定数值的颜色替换一幅图片的色表，我现在知道的唯一方法是编辑每个表槽，但却无法让某图形程序的颜色拾取器取得十六进制的 RGB 值。

第二种提法是明智的，它使得建议采用更合适的工具以完成任务的回复成为可能。

别要求私下回复电邮

黑客们认为问题的解决过程应该公开、透明，此过程中如果更有才能的人注意到不完整或者不当之处，最初的回复才能够、也应该被纠正。同时，作为回复者也因为能力和学识被其它同行看到而得到某种回报。

当你要求私下回复时，此过程和回报都被中止。别这样做，让 回复者 来决定是否私下回答──如果他真这么做了，通常是因为他认为问题编写太差或者太肤浅，以至于对其它人毫无意义。

对这条规则存在一条有限的例外，如果你确信提问可能会引来大量雷同的回复时，那么“向我发电邮，我将为论坛归纳这些回复”将是神奇的句子。试着将邮件列表或新闻组从洪水般雷同的回复中解救出来是非常有礼貌的──但你必须信守诺言。

提问应明确

漫无边际的问题通常也被视为没有明确限制的时间无底洞。最有可能给你有用答案的人通常也是最忙的人（假如只是因为他们承担了太多工作的话），这些人对于没有止境的时间无底洞极其敏感，所以他们也倾向于讨厌那些漫无边际的问题。

如果你明确了想让回复者做的事（如指点方向、发送代码、检查补丁或其它），你更有可能得到有用的回复。（因为）这样可以让他们集中精力并间接地设定了他们为帮助你需要花费的时间和精力上限，这很好。

要想理解专家生活的世界，可以这样设想：那里有丰富的专长资源但稀缺的响应时间。你暗中要求他们奉献的时间越少，你越有可能从这些真正懂行也真正很忙的专家那里得到解答。

所以限定你的问题以使专家回答时需要付出的时间最少──这通常与简化问题还不太一样。举个例，“请问可否指点一下哪有好一点的 X 解释？”通常要比“请解释一下 X”明智。如果你的代码不运行了，通常请别人看看哪有问题比叫他们帮你改正更明智。

关于代码的问题

别要求他人给你出问题的代码排错而不提及应该从何入手。张贴几百行的代码，然后说一声“它不能运行”会让你得不到理睬。只贴几十行代码，然后说一句“在第七行以后，本应该显示<x>，但实际出现的是<y>”非常有可能让你得到回复。

最精确描述代码问题的方法是提供一个能展示问题的最小测试样例。什么是最小测试样例？它是对问题的展现，只需要刚好能够重现非预期行为的代码即可。如何生成一个最小测试样例？如果你知道哪一行或哪一段代码会产生问题，将其复制并提供刚好够用的外围支撑代码以构成一个完整的样例（够用是指源码刚好能被编译器、解释器或任何处理它的程序所接受）。如果你不能将问题缩小到特定的段落，复制源码并去除那些与问题无关的代码段。你能提供的最小测试样例越小越好（参见量不在多，精炼则灵）。

生成一个非常小的最小测试样例并不总是可能，但尽力去做是很好的锻练，这有可能帮助你找到需要自己解决的问题。即使你找不到，黑客们喜欢看到你努力过，这将使他们更合作。

如果你只是想让别人帮忙审一下代码，在最开头就要说出来，并且一定要提到你认为哪一部分特别需要关注以及为什么。

别张贴家庭作业式问题

黑客们善于发现“家庭作业”式的问题。我们中的大多数人已经做了自己的家庭作业，那是该你做的，以便从中学到东西。问一下提示没有关系，但不是要求完整的解决方案。

如果你怀疑自己碰到了一个家庭作业式的问题，但仍然无法解决，试试在用户组、论坛或（作为最后一招）在项目的“用户”邮件列表或论坛中提问。尽管黑客们会看出来，一些老用户也许仍会给你提示。

删除无意义的要求

抵制这种诱惑，即在求助消息末尾加上诸如“有人能帮我吗？”或“有没有答案？”之类在语义上毫无意义的东西。第一，如果问题描述还不完整，这些附加的东西最多也只能是多余的。第二，因为它们是多余的，黑客们会认为这些东西烦人──就很有可能用逻辑上无误但打发人的回复，诸如“是的，你可以得到帮助”和“不，没有给你的帮助”。

一般来说，避免提“是或否”类型的问题，除非你想得到 “是或否”类型的回答。

不要把问题标记为“紧急”，即使对你而言的确如此

这是你的问题，不要我们的。宣称“紧急”极有可能事与愿违：大多数黑客会直接删除这种消息，他们认为这是无礼和自私地企图得到即时与特殊的关照。

有一点点局部的例外，如果你是在一些知名度很高、会使黑客们激动的地方使用程序，也许值得这样去做。在这种情况下，如果你有期限压力，也很有礼貌地提到这点，人们也许会有足够的兴趣快一点回答。

当然，这是非常冒险的，因为黑客们对什么是令人激动的标准多半与你的不同。譬如从国际空间站这样张贴没有问题，但代表感觉良好的慈善或政治原因这样做几乎肯定不行。事实上，张贴诸如“紧急：帮我救救这个毛绒绒的小海豹！”肯定会被黑客回避或光火，即使他们认为毛绒绒的小海豹很重要。

如果你觉得这不可思议，再把剩下的内容多读几遍，直到弄懂了再发贴也不迟。

礼貌总是有益的

礼貌一点，使用“请”和“谢谢你的关注”或者“谢谢你的关照”，让别人明白你感谢他们无偿花时间帮助你。

坦率地讲，这一点没有语法正确、文字清晰、准确、有内容和避免使用专用格式重要（同时也不能替代它们）。黑客们一般宁可读有点唐突但技术鲜明的臭虫报告，而不是那种有礼但含糊的报告。（如果这点让你不解，记住我们是按问题能教我们什么来评价它的）

然尔，如果你已经谈清楚了技术问题，客气一点肯定会增加你得到有用回复的机会。

（我们必须指出，本文唯一受到一些老黑客认真反对的地方是以前曾经推荐过的“提前谢了”，一些黑客认为这隐含着事后不用再感谢任何人的暗示。我们的建议是要么先说 “提前谢了”，事后再对回复者表示感谢，要么换种方式表达，譬如用“谢谢你的关注”或“谢谢你的关照”）。

问题解决后追加一条简要说明

问题解决后向所有帮助过的人追加一条消息，让他们知道问题是如何解决的并再次感谢。如果问题在邮件列表或新闻组中受到广泛关注，在那里追加此消息比较恰当。

最理想的方式是向最初提问的线索回复此消息，并在主题中包含“已解决”、“已搞定”或其它同等含义的明显标记。在人来人往的邮件列表里，一个看见线索 “问题 X”和“问题 X-已解决”的潜在回复者就明白不用再浪费时间了（除非他个人觉得“问题 X”有趣），因此可以利用此时间去解决其它问题。

追加的消息用不着太长或太复杂，一句简单的“你好──是网线坏了！谢谢大家──比尔”就比什么都没有要强。事实上，除非解决问题的技术真正高深，一条简短而亲切的总结比长篇大论要好。说明是什么行动解决了问题，用不着重演整个排错的故事。

对于有深度的问题，张贴排错历史的摘要是恰当的。描述问题的最终状态，说明是什么解决了问题，在此之后 才指明可以避免的弯路。应避免的弯路部分应放在正确的解决方案和其它总结材料之后，而不要将此消息搞成侦探推理小说。列出那些帮助过你的名字，那样你会交到朋友的。

除了有礼貌、有内容以外，这种类型的追帖将帮助其他人在邮件列表、新闻组或论坛文档中搜索到真正解决你问题的方案，从而也让他们受益。

最后，此类追帖还让每位参与协助的人因问题的解决而产生一种满足感。如果你自己不是技术专家或黑客，相信我们，这种感觉对于你寻求帮助的老手和专家是非常重要的。问题叙述到最后不知所终总是令人沮丧的，黑客们痒痒地渴望它们被解决。“挠痒痒”为你挣到的信誉将对你下次再次张贴提问非常非常的有帮助。

考虑一下怎样才能避免他人将来也遇到类似的问题，问问自己编一份文档或 FAQ 补丁会不会有帮助，如果是的话就将补丁发给维护者。

在黑客中，这种良好的后继行动实际上比传统的礼貌更重要，也是你善待他人而赢得声誉的方式，这是非常有价值的财富。

如何解读回答

“读读该死的手册”（RTFM）和“搜搜该死的网络”（STFW）：如何明白你已完全搞砸

有一个古老而神圣的传统：如果你收到“读读该死的手册”（RTFM）的回复，发信人认为你应该去“读读该死的手册”。他或她多半是对的，去读一下吧。

“读读该死的手册”（RTFM）有个年轻一点的亲戚，如果你收到“搜搜该死的网络”（STFW）的回复，发信人认为你应该“搜搜该死的网络”。那人多半也是对的，去搜一下吧。(更温和一点的说法是“谷歌是你的朋友！”)

在论坛，你也可能被要求去搜索论坛的文档。事实上，有人甚至可能热心地为你提供以前解决此问题的线索。但不要依赖这种关照，提问前应该先搜索一下文档。

通常，叫你搜索的人已经打开了能解决你问题的手册或网页，正在一边看一边敲键盘。这些回复意味着他认为：第一，你要的信息很容易找到。第二，自已找要比别人喂到嘴里能学得更多。

你不应该觉得这样就被冒犯了，按黑客的标准，回复者没有不理你就是在向你表示某种尊敬，你反而应该感谢他热切地想帮助你。

如果还不明白……

如果你看不懂回答，不要马上回复一个要求说明的消息，先试试那些最初提问时用过的相同工具（如手册、FAQ、网页、懂行的朋友等）试着搞懂回答。如果还是需要说明，展现你已经明白的。

譬如，假如我告诉你：“看起来象是某输入项有问题，你需要清除它”，接着是个不好的回帖：“什么是某输入项？”。而这是一个很好的跟帖：“是的，我读了手册，某某输入项只在 -z 和 -p 开关中被提到，但都没有涉及到如何清除它们，你指的是哪一个还是我弄错了什么？”

对待无礼

很多黑客圈子中看似无礼的行为并不是存心冒犯。相反，它是直接了当、一针见血式的交流风格，这种风格对于更关注解决问题而不是使别人感觉舒服而混乱的人是很自然的。

如果你觉得被冒犯了，试着平静地反应。如果有人真的做了过格的事，邮件列表、新闻组或论坛中的前辈多半会招呼他。如果这没有发生而你却光火了，那么你发火对象的言语可能在黑客社区中看起来是正常的，而你将被视为有错的一方，这将伤害到你获取信息或帮助的机会。

另一方面，你会偶而真的碰到无礼和无聊的言行。与上述相反，对真正的冒犯者狠狠地打击、用犀利的语言将其驳得体无完肤都是可以接受的。然尔，在行事之前一定要非常非常的有根据。纠正无礼的言论与开始一场毫无意义的口水战仅一线之隔，黑客们自己莽撞地越线的情况并不鲜见。如果你是新手或外来者，避开这种莽撞的机会并不高。如果你想得到的是信息而不是消磨时光，这时最好不要把手放在键盘上以免冒险。

（有些人断言很多黑客都有轻度的自闭症或阿斯伯格综合症，缺少用于润滑人类社会“正常”交往所需的脑电路。这既可能是真也可能是假。如果你自己不是黑客，兴许你认为我们脑袋有问题还能帮助你应付我们的古怪行为。只管这么干好了，我们不在乎。我们喜欢现在这个样子，并且一般都对病号标记有站得住脚的怀疑。）

在下一节，我们会谈到另一个问题，当你行为不当时会受到的“冒犯”。

别象失败者那样反应

在黑客社区的论坛中有那么几次你可能会搞砸──以本文描述或类似的方式。你会被示众是如何搞砸的，也许言语中还会带点颜色。

这种事发生以后，你能做的最糟糕的事莫过于哀嚎你的遭遇、宣称被口头攻击、要求道歉、高声尖叫、憋闷气、威胁诉诸法律、向其雇主报怨、忘了关马桶盖等等。相反，你该这样去做：

熬过去，这很正常。事实上，它是有益健康与恰当的。

社区的标准不会自己维持，它们是通过参与者积极而公开地执行来维持的。不要哭嚎所有的批评都应该通过私下的邮件传送，这不是事情运作的方式。当有人评论你的一个说法有误或者提出不同看法时，坚持声称受到个人攻击也毫无益处，这些都是失败者的态度。

也有其它的黑客论坛，受过高礼节要求的误导，禁止参与者张贴任何对别人帖子挑毛病的消息，并声称“如果你不想帮助用户就闭嘴”。有思路的参与者纷纷离开的结果只会使它们变成了毫无意义的唠叨与无用的技术论坛。

是夸张的“友谊”（以上述方式）还是有用？挑一个。

记着：当黑客说你搞砸了，并且(无论多么刺耳地)告诉你别再这样做时，他正在为关心你和他的社区而行动。对他而言，不理你并将你从他的生活中滤除要容易得多。如果你无法做到感谢，至少要有点尊严，别大声哀嚎，也别因为自己是个有戏剧性超级敏感的灵魂和自以为有资格的新来者，就指望别人象对待脆弱的洋娃娃那样对你。

有时候，即使你没有搞砸（或者只是别人想象你搞砸了），有些人也会无缘无故地攻击你本人。在这种情况下，报怨倒是真的会把问题搞砸。

这些找茬者要么是毫无办法但自以为是专家的不中用家伙，要么就是测试你是否真会搞砸的心理专家。其它读者要么不理睬，要么用自己的方式对付他们。这些找茬者在给自己找麻烦，这点你不用操心。

也别让自己卷入口水战，大多数口水战最好不要理睬──当然，是在你核实它们只是口水战、没有指出你搞砸的地方，而且没有巧妙地将问题真正的答案藏于其中之后（这也是可能的）。

提问禁忌

下面是些典型的愚蠢问题和黑客不回答它们时的想法。

问：我到哪可以找到某程序或 X 资源？
问：我怎样用 X 做 Y？
问：如何配置我的 shell 提示？
问：我可以用 Bass-o-matic 文件转换工具将 AcmeCorp 文档转为 TeX 格式吗？
问：我的{程序、配置、SQL 语句}不运行了
问：我的视窗电脑出问题了，你能帮忙吗？
问：我的程序不运行了，我认为系统工具X有问题
问：我安装 Linux 或 X 遇到困难，你能帮忙吗？
问：我如何才能破解超级用户口令/盗取通道操作员的特权/查看某人的电子邮件？

问：	我到哪可以找到某程序或 X 资源？
答：	在我找到它的同样地方，笨旦──在网页搜索引擎上。上帝啊，难道还有人不知道如何使用谷歌吗？
问：	我怎样用 X 做 Y？
答：	如果你想解决的是 Y，提问时别给出可能并不恰当的方法。这种问题说明提问者不但对 X 完全无知，也对要解决的 Y 问题糊涂，还被特定形势禁锢了思维。等他们把问题弄好再说。
问：	如何配置我的 shell 提示？
答：	如果你有足够的智慧提这个问题，你也该有足够的智慧去 “读读该死的手册”（RTFM），然后自己去找出来。
问：	我可以用 Bass-o-matic 文件转换工具将 AcmeCorp 文档转为 TeX 格式吗？
答：	试试就知道了。如果你试过，你既知道了答案，又不用浪费我的时间了。
问：	我的{程序、配置、SQL 语句}不运行了
答：	这不是一个问题，我也没有兴趣去猜你有什么问题──我有更要紧的事要做。看到这种东西，我的反应一般如下：你还有什么补充吗？噢，太糟了，希望你能搞定。这跟我究竟有什么关系？
问：	我的视窗电脑出问题了，你能帮忙吗？
答：	是的，把视窗垃圾删了，装个象 Linux 或 BSD 的开源操作系统吧。注意：如果程序有官方的视窗版或者与视窗有交互(如 Samba)，你可以问与视窗相关的问题，只是别对问题是由视窗操作系统而不是程序本身造成的回复感到惊讶，因为视窗一般来说太差，这种说法一般都成立。
问：	我的程序不运行了，我认为系统工具 X 有问题
答：	你完全有可能是第一个注意到被成千上万用户反复使用的系统调用与库文件有明显缺陷的人，更有可能的是你完全没有根据。不同凡响的说法需要不同凡响的证据，当你这样声称时，你必须有清楚而详尽的缺陷说明文档作后盾。
问：	我安装 Linux 或 X 遇到困难，你能帮忙吗？
答：	不行，我需要亲手操作你的电脑才能帮你排错，去向当地的 Linux 用户组寻求方便的帮助（你可以在这里找到用户组列表）注意：如果安装问题与某 Linux 发行版有关，在针对它的邮件列表、论坛或本地用户组织中提问也许是恰当的。此时，应描述问题的准确细节。在此之前，先用 “linux”和所有被怀疑的硬件 [作关键词] 仔细搜索。
问：	我如何才能破解超级用户口令/盗取通道操作员的特权/查看某人的电子邮件？
答：	想做这种事情说明你是个卑劣的家伙，想让黑客教你做这种事情说明你是个白痴。

好问题与坏问题

最后，我将通过举例来演示提问的智慧。同样的问题两种提法，一种愚蠢，另一种明智。

愚蠢：我在哪能找到关于 Foonly Flurbamatic 设备的东西？: 这个问题在乞求得到 “搜搜该死的网络”（STFW）式的回复。
明智： 我用谷歌搜索过“Foonly Flurbamatic 2600”，但没有找到什么有用的，有谁知道在哪能找到这种设备的编程信息？: 这个人已经搜索过网络了，而且听起来他可能真的遇到了问题。

愚蠢： 我不能编译某项目的源代码，它为什么这么破？: 提问者假设是别人搞砸了，太自大了。
明智： 某项目的源代码不能在某 Linux 6.2 版下编译。我读了常见问题文档，但其中没有与某 Linux 相关的内容。这是编译时的记录，我做错了什么吗？: 提问者已经指明了运行环境，读了常见问题文档（FAQ），列出了错误，也没有假设问题是别人的过错，这家伙值得注意。

愚蠢： 我的主板有问题，谁能帮我？: 某黑客对此的反应可能是：“是的，还需要帮你拍背和换尿布吗？”，然后是敲下删除键。
明智： 我在 S2464 主板上试过 X、Y 和 Z，当它们都失败后，又试了 A、B 和 C。注意我试 C 时的奇怪症状，显然某某东西正在做某某事情，这不是期望的行为。通常在 Athlon MP 主板上导致某某事情的原因是什么？有谁知道我还能再试点什么以确定问题？: 相反地，这个人看来值得回答。他或她展现了解决问题的能力而不是坐等天上掉馅饼。

在最后那个问题中，注意“给我一个回答”与“请帮我看看我还能再做点什么测试以得到启发”之间细微但重要的差别。

事实上，最后那个问题基本上源于 2001 年 8 月 Linux 内核邮件列表（lkml）上的真实事件，是我（Eric）当时提了那个问题，我发现 Tyan S2462 主板有神秘的死机现象，邮件列表成员给我提供了解决此问题的关键信息。

通过这种提问方式，我给了别人可以咀嚼玩味的东西。我设法使之对参与者既轻松又有吸引力，也表明了对同行能力的尊敬并邀请他们与我一起协商。通过告诉他们我已经走过的弯路，我还表明了对他们宝贵时间的尊重。

事后，当我感谢大家并评论这次良好的经历时，一个 Linux 内核邮件列表的成员谈到，他认为我得到答案并不是因为我的名字挂在列表上，而只是因为我正确的提问方式。

黑客们在某种方面是非常不留情面的精英分子。我想在这事上他是对的，如果我 表现得 象个不劳而获的寄生虫，不管我是谁都会被忽略或斥责。他建议将整个事件作为对其它人提问的指导，这直接导致了本文的编写。

如果得不到回答

如果得不到回答，请不要认为我们不想帮你，有时只是因为被问到的小组成员的确不知道答案。没有回复不等于不被理睬，当然必须承认从外面很难看出两者的差别。

一般而言，直接将问题再张贴一次不好，这会被视为毫无意义的骚扰。耐心一点，知道你问题答案的人可能生活在不同的时区，有可能正在睡觉，也有可能你的问题一开始就没有组织好。

还有其它资源可以寻求帮助，通常是在一些面向新手的资源中。

有许多在线与本地的用户组织，虽然它们自己不编写任何软件，但是对软件很热心。这些用户组通常因互助和帮助新手而形成。

还有众多大小商业公司提供签约支持服务（红帽与 SpikeSource 是两家最出名的，还有许多其它的）。别因为要付点钱才有支持就感到沮丧！毕竟，如果你车子的汽缸垫烧了，你多半还得花钱找个修理店把它弄好。即使软件没花你一分钱，你总不能指望服务支持都是免费的。

象 Linux 这样流行的软件，每个开发者至少有一万个以上的用户，一个人不可能应付这么多用户的服务要求。记住，即使你必须付费才能得到支持，也比你还得额外花钱买软件要少得多（而且对封闭源代码软件的服务支持与开源软件相比通常还要贵一点，也要差一点）。

如何更好地回答

态度和善一点。问题带来的压力常使人显得无礼或愚蠢，其实并不是这样。

对初犯者私下回复。 对那些坦诚犯错之人没有必要当众羞辱，一个真正的新手也许连怎么搜索或在哪找 FAQ 都不知道。

如果你不确定，一定要说出来！ 一个听起来权威的错误回复比没有还要糟，别因为听起来象个专家好玩就给别人乱指路。要谦虚和诚实，给提问者与同行都树个好榜样。

如果帮不了忙，别妨碍。 不要在具体步骤上开玩笑，那样也许会毁了用户的安装──有些可怜的呆瓜会把它当成真的指令。

探索性的反问以引出更多的细节。 如果你做得好，提问者可以学到点东西──你也可以。试试将很差的问题转变成好问题，别忘了我们都曾是新手。

尽管对那些懒虫报怨一声“读读该死的手册”（RTFM）是正当的，指出文档的位置（即使只是建议做个谷歌关键词搜索）会更好

如果你决意回答，给出好的答案。 当别人正在用错误的工具或方法时别建议笨拙的权宜之计，应推荐更好的工具，重新组织问题。

帮助你的社区从中学习。当回复一个好问题时，问问自己 “如何修改相关文件或 FAQ 文档以免再次解答同样的问题？”，接着再向文档维护者发一份补丁。

如果你是在研究一番后才做出的回答，展现你的技巧而不是直接端出结果。毕竟“授人以鱼，不如授人以渔”。

鸣谢

伊夫林.米切尔（Evelyn Mitchell）贡献了一些愚蠢问题例子并启发了编写“如何更好地回答问题”这一节，米哈伊尔.罗门迪克（Mikhail Ramendik）贡献了一些特别有价值的建议和改进。

The iOS Design Cheat Sheet

https://ivomynttinen.com/blog/the-ios-7-design-cheat-sheet/

这个blog的其他文章同样值得阅读。

With the release of iOS 7, app designers and developers will need to adjust their visual language to match the new “flat” design of iOS. In addition to the grid system, the dimensions of icons and commonly used elements, typography and iconography has been updated by Apple in many ways. That‘s why the old iOS Design Cheat Sheet that I published last year with the release of the iPad mini needs an update now. I decided to shift away from pure value-based tables about sizes of design elements towards a simple guide that should help to get you started with iOS 7 app design. As always I will update this guide over time, and if you think there is something important missing here, just let me know.

Since iOS 7 is not supported on older models of the iPhone and iPod (only 4+), this guide will only cover the supported devices. If you are looking for information related to these devices, you should take a look at the older iOS Design Cheat Sheet v2.

Resolutions & Display Specifications

Resolutions

Devices	Portrait	Landscape
iPhone 5	640×1136 px	1136×640 px
iPhone 4/4S	640×960 px	960×640 px
iPhone & iPod Touch1st, 2nd and 3rd Generation	320×480 px	480×320 px
Retina iPadiPad 3, iPad 4	1536×2048 px	2048×1536 px
iPad Mini	768×1024 px	1024×768 px
iPad1st and 2nd Generation	768×1024 px	1024×768 px

Displays

Devices	PPI	Color Mode	Color Temperature
iPhone 5	326	8bit RGB	Warm
iPhone 4/4S	326	8bit RGB	Cool
iPhone & iPod Touch1st, 2nd and 3rd Generation	163	8bit RGB	Warm
Retina iPadiPad 3, iPad 4	264	8bit RGB	Warm
iPad Mini	163	8bit RGB	Unknown
iPad1st and 2nd Generation	132	8bit RGB	Warm

App Icons

One of the biggest changes in iOS 7 is the new dimensions and the visual language used for app icons. Apple introduced a grid system, increased the general size of icons on your home screen and also masked icons with a different shape.

Dimensions

Device	App Icon	AppStore Icon	Spotlight Icon	Settings Icon
iPhone 5	120×120 px	1024×1024 px	80×80 px	58×58 px
iPhone 4/4S	120×120 px	1024×1024 px	80×80 px	58×58 px
Retina iPadiPad 3, iPad 4	152×152 px	1024×1024 px	80×80 px	58×58 px
iPad Mini	76×76 px	512×512 px	40×40 px	29×29 px
iPad1st and 2nd Generation	76×76 px	512×512 px	40×40 px	29×29 px

Rounded corners

iOS 7 App Icon Radius The old simple radii values for rounded corners are gone. Apple introduced a new shape, which got named “superellipse” byMichael Flarup (I think that‘s a great way to describe this shape). Since Apple did not release an official template of the shape, you will have to use one of the unofficial templates out there, which are replicating the shape in more or less accurate ways. The best I‘ve came across so far is the App Icon Template, which is definitely a very good starting point when you‘re designing an app icon for iOS 7. As always, the rounded corners should not be included in your final exported assets – but you might need them while your design process if you want to add effects, such as a stroke or shadows, which are aligned to the corner of the icon.

Grid system

iOS 7 App Icon Grid System Apple developed a golden ratio grid system, which can be used to size and align elements on your icon correctly. Anyways, the grid template got criticized a lot by the design community, and it seems like designers (even Apple designers) are not following the grid system very strictly. Feel free to break rules if your icon looks better without taking care of the new grid system.

User Interface

The biggest change in iOS 7 is definitely the all new flat user interface design language used across the whole operating system. While pretty much all gradients and shadows got removed from UI elements, the sizes of commonly used design elements got changed in some cases as well.

Commonly used design elements

Device	Height of Status Bar	Height of Navigation Bar	Height of Tab Bar	Width of Tables
iPhone 5	40 px	88 / 64 px	98 px	640 / 1136 px
iPhone 4/4S	40 px	88 / 64 px	98 px	640 / 960 px
Retina iPadiPad 3, iPad 4	40 px	88 px	98 px	dynamic
iPad Mini	20 px	44 px	49 px	dynamic
iPad1st and 2nd Generation	20 px	44 px	49 px	dynamic

Status Bar

iOS 7 Status Bar iOS 7 Status Bar in black While the size of the status bar is the same as in iOS6, the appearance of its content was slightly changed. You can control the background color to match the look of your app design or use the default color themes (white and black). In a lot of the default iOS 7 apps, the status bar is visually connected with the Navigation Bar without any separations.

Navigation Bar

iOS 7 Navigation Bar Grid iOS 7 Navigation Bar Landscape Grid The Navigation Bar usually includes a title as well as basic navigation and action buttons (such as back to previous view, create, edit, etc.). In landscape orientation, the height of the Nav bar is usually shrunk a bit (to 32pt) to allow more content to be displayed below it.

Table Views

iOS 7 Table Specifications Tables (or lists) are using the full width of the display now and are not any longer surrounded by a container that separates tables from each other. The only visual separation between different table views are headlines which appear on top of the table (as known from previous iOS versions) on top of the main app background texture/color. Items within a table are separated by a simple 1px line, which has a margin of 15pt to the left side of the screens but connects directly with the right side of the screen. Each item has an inner padding of 15pt to both sides.

Iconography

iOS 7 Tab Bar iOS 7 Share Icons Apple makes massive usage of icons without a fill color but only outlines with a thickness of 1pt, but “classic” icons with a color fill are still present and widely used in iOS 7. An often used style for active icons in the tab bar are inverted colors – while the inactive icon has often only outlines, the active one get‘s filled with a solid color while some strokes disappear or are inverted.

Typography

Helvetica Neue is still the default font in iOS, but normal text is usually displayed in the Light face instead of Regular or Bold now. Text that should appear more prominent is often displayed in Medium face (eg. the title in Navigation Bar). Of course, there are still a lot of alternative font faces available to make use of instead of Helvetica Neue. You can find the whole list here. In general (and likely because of the increased usage of Light font faces) the font size was increased for most design elements. Buttons often appear as simple colored text links. Now, they are no longer surrounded by a shape, which supports its metaphor.

Default Font Sizes

Label Type	Default Font Size	Default Font Weight
Navigation Bar Title	34 px	Medium
Regular Buttons	34 px	Light
Table Header	34 px	Light
Table Label	28 px	Regular
Tab Bar Icon Labels	20 px	Regular

转载-为什么你应该（从现在开始就）写博客

https://mindhacks.cn/2009/02/15/why-you-should-start-blogging-now/

（一）为什么你应该（从现在开始就）写博客

用一句话来说就是，写一个博客有很多好处，却没有任何明显的坏处。（阿灵顿的情况属于例外，而非常态，就像不能拿抽烟活到一百岁的英国老太太的个例来反驳抽烟对健康的极大损伤一样）

让我说得更明确一点：用博客的形式来记录下你有价值的思考，会带来很多好处，却没有任何明显的坏处。Note：碎碎念不算思考、心情琐记不算思考、唠唠叨叨也不算思考、没话找话也不算思考，请以此类推。

下面是我个人认为写一个长期的价值博客的最大的几点好处：

1) 能够交到很多志同道合的朋友。我自己既写博客，也读别人的博客，在这个时代，对于生活中的绝大多数人来说，拓宽朋友圈子的途径几乎只有一个，通过网络，而如何在网络中寻找到气味相投的朋友，如何判断别人和自己是否有共同语言？显然，通过天天在SNS上碎碎念的那些日记是难以做到的。我佩服的一些朋友几乎全都是长期用博客记录想法的人，因此，和他们即便不打照面，也是心照不宣。即便素未谋面也能坐下来就聊得热火朝天。

为什么博客在结交志同道合的朋友方面的潜力要远胜于原始的交谈方式？很简单，第一，博客无地域限制，整个互联网上从A到B只有一个点击的距离，而传统的建立朋友圈子的方法则受到地域限制。第二，也是更重要的一点，即如果按照以前结交朋友的方式，需要互相聊天，交流观点，然后才逐渐熟悉起来，这需要一个较长的过程，而且更糟糕的是，当你遇到另一个陌生人，又要把整个过程重复一次，表达你已经对老友表达过的那番想法。可博客却做到了“一次表达，无数次阅读”，当我看到一个写了好几年的博客，看完了之后我仿佛和这个人交谈了很久，用程序员们喜欢听的话来说就是，“博客极大地增强了话语的复用性”。

我曾在CSDN上写了近六年的博客，在一年半前建立了一个Google Groups（TopLanguage），由于我的博客的长期阅读者都是互相有共同语言的，因此这个Group一开始就热火朝天，而高质量的技术讨论则进一步吸引了更多的牛人的参与，雪球滚起来之后，就很难停下来了，将近一年半下来，从这个Group的讨论中我获益良多[1]。而对于非程序员朋友，科学松鼠会则是一个很好的例子。

2) 书写是为了更好的思考。我在《书写是为了更好的思考》里面详细总结了书写的好处，这里就不拷贝粘贴了。有些想法如果不写下来，也就忘掉了，有一个广为流传的《数学牛人们的轶事》（荣耀属于ukim）里面讲了希尔伯特的一个故事：一次在Hilbert的讨论班上，一个年轻人报告，其中用了一个很漂亮的定理，Hilbert说“这真是一个妙不可言（wunderbaschon）的定理呀,是谁发现的？”那个年轻人茫然的站了很久，对Hilbert说：“是你.……”。

3) “教”是最好的“学”。如果一件事情你不能讲清楚，十有八九你还没有完全理解。绝大多数人应该都知道在程序员行业面试官经常要求你讲解一个东西给他听，他会说他不懂这个东西（他如果真的不懂的话效果其实是最好的），而你的任务则是说到让他理解为止。

为了让一个不明白的人做到明白，你必须要知道从明白到不明白他究竟需要掌握哪些概念，这就迫使我们对我们大脑中整个的知识体系来个寻根究底，把藏在水面之下的那些东西统统挖出来，把大脑中的那些我们知道、但不知道自己知道的潜在概念或假设（assumptions）都挖出来，把它们从内隐记忆拉扯到外显记忆中。因为只有完全知道、并知道自己知道一切来龙去脉的人，才能真正把一件事情讲得通通透透。

但是，你可能会怀疑，那除了能够讲清楚之外，弄清自己到底知道哪些东西还有其他什么好处吗？如果没有其他好处，那我又何必费这个劲呢？我又不当老师。

TopLanguage上的一位朋友sagasw曾经讲了这样一个小故事：据说在某个著名软件公司里，开发组的桌上会放着一只小熊，大家互相问问题之前，先对着小熊把问题说一遍，看能不能把问题描述的清晰，基本上说的比较有条理以后，答案也就随之而来了。当然，你不一定要对小熊说，你可以在大脑中虚构一个听众，一个不懂行的听众，然后你说给他听。这是可行的，我经常在路上用。不过如果你能坐下来，我建议你还是说给实际的听众听——即写下你的思考，因为书写是更好的思考。

我们的绝大多数知识在绝大多数时候都隐藏在潜意识中，其实我们意识的窗口很小，我们的工作记忆只能容纳寥寥数个条目（记得那个“看你能够记住屏幕上同时闪现的多少个数字”的flash小游戏吗？），我们平时所作的推理过程很大部分都是自动的，发生在潜意识中，而我们只能感知到一些中间结论。不信你回忆一下你在和别人讨论问题的时候有多少次觉得“反正就是这样，我感觉得到它是对的，但是你问我，我也说不清到底怎么回事”，对此你不觉得很奇怪吗？如果你都不能从逻辑上支持你的结论，你怎么就能确信它是对的呢？仅仅因为你的直觉强烈地告诉你它是对的？那如果旁边有另一个人，他和你持相反的观念，而他的直觉也强烈地告诉他他是对的。这时候你又怎么想？“他的直觉错了，我的直觉是对的”？难道你这么自信你的直觉是世界上最可靠的？

我自己则是非常珍惜类似这样的机会，即当“我强烈地觉得它是对的，但我却说不出所以然来”，这时候往往是到大脑中翻箱倒柜的时候，弄清来龙去脉的时候，深入反思的时候，纠正一直以来错误的潜在前提假设的时候。另一方面，“我强烈地觉得这个说法有问题，但我却说不清它为什么有问题，到底哪有问题”，这也是一个极有意义的瞬间，它几乎总是意味着你对一个问题的认识有潜在的偏差，肯定是在你自己都没有觉知到的地方引入了一个潜在的假设、偷换了一个重要的概念，等等。而这种时候就是深入反思的时候，当你终于潜到问题的底层，触摸到问题的实质，把水面之下的冰山整体看清了的时候你会有一种通体舒泰的感觉。

为什么说以上这些？因为刚才说的是你必须等待这样的反思机会，但如果你选择经常总结自己的知识体系，并说出来给你的读者听，你就会发现你自己创造了这样的机会。如果我们平时不反思，我们觉得很多事情都是当然的，但结果如果要你一开口说给别人听，常常会发现事情就开始变得不那么明显了，你说着说着，就开始莫名其妙地发现自己需要用到“反正”这个词了。

于是，反思的机会就来了。

一旦你把自己潜意识里面的东西从幕后拉出来，你就有了面对并反思它们的可能，而不是任它们在幕后阴险地左右你的思维。很多时候我们的思路出了问题并不是我们不会反思，而是不知道自己的思维中有那些隐含的假设（assumptions），如果你只感觉到答案，却不知道你大脑得到这个答案之前做了哪些推理，你又怎么知道哪一环可能出了问题呢？另一方面，一旦你弄清了自己到底是怎么想的，离意识到问题就不远了，很简单的道理——如果别人和你争辩的时候总是只摆立场，你就很难和他辩，但如果他把自己的推理过程原原本本暴露给你，批判起来总是容易得多的。（也正因为这个原因有很多人总是把逻辑藏在背后，不敢暴露出来）

绝大多数时候其实我们都会不假思索地得出一些结论，就像上了发条的自动机，但其实我们并不知道这些结论到底怎么来的，在思维的背后到底发生了哪些事情，故而当我们发现我们的结论错了的时候，一头雾水，没法着手寻找到底在哪错了。如果你注意一下很多人的发言（论坛、博客等等），如果你把他们的发言分为“前提”、“假设”、“逻辑”、“结论”这四个部分，你会发现一大堆人只会不停地下结论，摆立场，却见不到这些结论或离场的前提、假设和个中逻辑，倒也不是他们不愿意写出逻辑，而是因为反思自己的思维过程实在是一件困难非常的事情，我们的推理过程很大一部分发生在意识的水面之下，只有当有了重要结论的时候这条逻辑链才会浮出来冒一个泡，让我们的意识捕捉到。更何况绝大多数时候我们用的其实并不是完整严密的逻辑思维，而是思维捷径。

去教一个完全不懂的人，则是一种最最强大和彻底的反思途径——因为他没有任何预备的知识，所以要让他弄懂你所知道的，你就必须彻底反思你的知识体系，弄清这座大厦的根基在什么地方，弄清它的骨架在什么地方，一砖一瓦到底是怎么垒起来的，你不能自己站在11层上，然后假设你的读者站在第10层，指望着只要告诉他第11层有那些内容就让他明白。你的读者站在第一层，你必须知道你脚下踩着的另外10层到底是怎么构造的。这就迫使你对你所掌握的、或之前认为正确的那些东西作彻彻底底的、深刻的反思，你的受众越是不懂，你需要反思得就越深刻。

4) 讨论是绝佳的反思。另一方面，很多时候我们并不是有机会说给完全不懂的人听，更大的可能性是说给同领域有一定基础的人听，这个时候并不代表就不能促使反思了，实际上，你会发现，如果你公开你的想法，几乎总能看到与你持不同意见的人，然后你通过比较你和他的观念之间的差别，会发现你们在一开始的思路上就存在差异，差异从哪里来的？在进一步讨论中你们就会不断地迫使对方拿出更深层次的理由，这同样也是一种非常有效地促使自己反思的方法，在讨论的过程中双方的理由自然会变得越来越深入，越来越接近问题的本质，一些平时难以注意到的深层面的差异性就会逐渐浮现出来，你也就多了一次难得的机会去审视自己的思维中到底存放了哪些错误的信息。

5) 激励你去持续学习和思考。如果你没有持续学习和思考的习惯，你的博客很快就会没有内容可写，就只能整点碎碎念或者转载，然后你就会失去读者，然后你就会关掉博客，然后一旦关掉博客之后你也就死了写博客的心，然后就少了一条激励你去思考和总结的途径，然后你变得更不高兴总结和思考，然后…

为了打破这个死循环，不要永久停止更新你的博客，就算你两个月，三个月都不写，只要你每篇都是写自己思考的产物，写有价值的东西，在互联网上，金子的确总是会发光的，因为有无数的信息聚合平台在期待这些有价值的内容，有搜索引擎为你的内容提供海量的潜在读者，有海量的人肉在手动挖掘和转载那些有价值的东西。我们所能做的最差的一个决策莫过于停止做一件没有任何坏处，却有一大堆好处的事情。

为了让你的博客有价值，你必须不断总结自己学习的结果，你必须不断思考，给出比别人深刻、独到的见解。这看起来有点本末倒置，但很快本和末就会正过来。

6) 学会持之以恒地做一件事情。很多人在生活中容易觉得迷失，不知道想要做什么，是因为没有一件能够持续地做的事情，用俗话来说就是没有主心骨。用积极心理学的话来说就是没有一件能够创造流体验的事情，而书写自己的思想则是一件容易产生流体验的事情，在书写的时候，特别是理性地书写的时候，大脑逐渐进入推理分析模块，一切不愉快的情绪，烦躁感都会逐渐消隐下去。不过前提是你得开始，并且坚持过一开始的困难期，以后的一切便成了习惯成自然。

7) 一个长期的价值博客是一份很好的简历。这里的“简历”并非是狭义上的求职简历，毕竟现在还没有到价值博客的时代，很多人写博客都是到处转载或者干脆碎碎念，正因此面试官未必拿个人博客当成了解一个人的更可靠窗口。这里的“简历”是指一个让别人了解自己的窗口，虽然我们未必做得到像罗永浩、Keso这样的博客，个人的影响力已经足以支撑出一份事业（牛博和5gme），但至少你会因此而结识更多的人，你的博客价值越高，你结识的人就越牛，跟牛人交流又会让你的眼界得到极大的开阔，打开一扇又一扇你原本不知道的门，于是你就变得更牛… 这是一个良性循环。

（二）怎么做到长期写一个价值博客

注意到我并没有说“怎么做到长期坚持写一个价值博客”，因为当思考和总结成为习惯之后，诉诸文字以及借助书写来进一步思考就变成了一件自然而然的事情，就变成了一件“因为你在思考和总结从而必须书写下来”的事情，博客就变成了副产品。

一开始的时候你是因为要写博客而去使劲地思考和总结，指望给出令人眼睛一亮的东西，到了后来，就变成了因为你习惯了思考和总结，因为你意识到书写是更好的思考，你就必须使你的想法成为文字。至此本和末就会各归原位，不再颠倒。

怎样做到长期写一个价值博客？也许有人会给出很多有趣有用的小技巧来提供动机和激励，譬如如何做SEO，如何鼓励读者留言等等，但是这些我都不想说，我只想说最最重要的，那就是：

让你自己成为一个持续学习和思考的人，并只写你真正思考和总结之后的产物，其他一切就会随之而来。

就像那句经常被人传阅的话：只做你最感兴趣的事情，钱会随之而来[2]。

这方面的具体例子大家可以留意一下，随处可见，就不一一举了。我想再重复一下的是，千万不要碎碎念，我能理解每个人都想偶尔发发牢骚的冲动，但是现在已经有了一个很好的窗口：twitter，所以立即停止在你的博客上碎碎念，阅读博客的人希望得到信息而非噪音。如果实在忍不住想碎碎念的话不妨换一下位置，这么来告诉自己：如果你看到别人博客来上这么一段，你会有兴趣看吗？

（三）可能出现的问题以及怎样应付

即便上文给出了N条写博客的理由，但有时候只要一条不写的理由就会让人停止做一件事情。所以我特别加上一节“可能出现的问题以及怎样应付”，《影响力2》[3]第五章雄辩地证明，“Much of Will is Skill”，意志力很大程度上来源于有正确的方法，而非天生。

1) 担心别人认为没有价值。事实是，你面临过的问题总会有人面临过，你独立思考了，别人没有，你的文章对他们就会有价值。当然，肯定会对某些人没有价值，他们早就知道了，但就算你再厉害，也总是有人比你厉害的，不能说因为这些原因就不记录你自己的想法了，你自己思考了之后理解得最深刻，就算有别人想过了，总有人没有想到的。况且，思考成了习惯，你的思考能力也会越来越强，你的文章也会越来越有价值。重复，无论你面临什么困惑，总会有很多人同样面临过，于是你苦苦思索之后的结果，肯定会对很多人有意义。

或者，你想通了之后觉得其实也很简单于是不愿意或者不好意思写了，但要知道，问题在想通了之后总是简单的，问题的困难程度不在于想通了之后还觉得有多难，而在于从你觉得它难到你觉得它简单需要耗费多少思维体力，你耗费的时间越长，说明有越多的人最终还是没有想明白（路越长走到底的人越少）。

最后，虽然我现在看一年前的文章觉得挺不成熟，但是如果没有那些不成熟的思考，也不会有现在更成熟的思考，我几年后来看现在写的东西，还是会觉得不成熟。

2) 担心想法太幼稚或有漏洞等等被别人笑话。人非圣贤。正是因为单个人的想法总是有漏洞，才值得拿出来交流（《书写是更好的思考》，讨论是绝佳的反思），被别人指出问题正是改进的空间，藏着掖着的想法永远不可能变得更成熟。

Much of intelligence is knowledge，有这么一个非常发人深省的经典心理学实验[4]：

将孩子们分成两组，通过给他们不同的阅读材料让一组相信智力是天生的，不可在后天改变的，另一组则让他们相信智力其实只是知识和技能的代名词，完全是后天习得的。接下来让他们做一组任务，那些被相信智力天生说的孩子，倾向于回避困难的任务，选择较容易的任务，这里的逻辑想必是这样的：如果做困难的任务，就增大了失败的几率，就在降低了自己在别人和自己心目中的智力的值。为了保护这个智力的值不被降低，应该避免那些有失败风险的项目。而另一组孩子则对于有挑战性的事情跃跃欲试，并且在失败的时候明显没有前者沮丧，因为失败也是学得新的东西，不管怎样都是“智力”的提高。

况且，只会批判乃至嘲笑别人的人是最不知道怎么建设的人，忽略他们。

3) 得不到激励。这其实是个最无聊的问题了，只有写碎碎念的博客才会面对“激励”的问题。如果写自己的总结，写自己独立的思考，那么书写下来、理解通透，本身就是一个极大的激励。就算放在自己的私密笔记本里面也一样有成就感。况且，如果你真做到了书写价值博客，那么绝对不用担心你的观点得不到传播，也许一开始会耗时长一点，但是这在任何事情上都是必要的初始阶段，Gmail小组的核心人物、FriendFeed创始人Paul Buchheit，和编程界名博Coding Horror的博主Jeff Atwood都曾经感叹过：Overnight success takes a long time （(1)，(2)），不过对于价值博客来说，现在网络上的聚合类服务这么多，机器的、人肉的、半人肉的都有，情况又要好得多了，而且我相信情况还会越来越好。

4) 写不出来。这个问题也比较无聊，思考本不是一件急于求成的事情。长期订阅我的博客的朋友知道我一般发文频率在一个月三五篇，实际上有不少次我个把月也不发布文章，原因很简单，要么是有手头的事情要处理思考的时间被压缩了，要么是遇到比较大或者比较困难的问题需要长时间的思考和积淀，没有关系，如果没有想清楚就再想想，爱思考的人和不爱思考的人有一个本质的区别，前者在生活中总是挂着几个问题在大脑中，它们时常都会冒出来骚扰你一下，让你琢磨琢磨，不爱思考的则是没事不主动想问题，遇到问题还要先想想是否能找捷径（找人帮忙）解决。

无论如何，不用急于求成，在一个主题上深入下去思考，总能挖到别人挖不到的角落。你能让一个问题在大脑中停留的时间越长，就越是能够发现新的东西，一般来说，我认为有价值的问题我会让他在意识或潜意识中待短则一个星期，长则一个月（视问题大小而定），利用走路吃饭的时间琢磨（我发现很多我佩服的人也都有这个习惯），有时即便已经想通了写下来了发出去了，大脑仍然还是会在回味问题，还没有把它撤出潜意识，然后看到某篇文章或某本书的时候忽然又有所新的感悟。

能够把问题长时间停靠在潜意识中是一种技能，能够带来很大的好处，停留得越长你越琢磨得透彻，比别人看到的就越多。我们必须要带着问题的眼镜看待事物才能发现新的视角，否则就会出现视而不见效应，别的不说，广为人知的例子是阿基米德的“尤里卡！”，如果不是长时间琢磨着一个问题，一直把它放在思维中，是不会从洗澡领悟到“排水测体积”的，否则他洗了那么多年澡怎么不早发现呢？[5]

所以，如果你习惯了思考问题，就总会有东西写，先有思考，然后有总结，然后在总结中进一步思考。

当然你也可以试试把不成熟的想法写下来，试图整理成条理清晰的文字，然后看看能否在整理的过程中走得更远。这往往是可行的。比如这篇文章在我的简记里面原本其实只有三行字（包含大约十来个备忘关键词），而最初在我的大脑里面其实只有一个走路时冒出来的问题——为什么要写博客？

–

[1] 你可以看一下我收藏的一些精彩主题。

[2] 尽管我并不完全同意这句话本身，但它这种解决问题链上更基本环节的问题的精神是我赞同的。

[3] 《影响力2》这个名字起得很聪明，其实它并不是《影响力》的作者写的。

[4] 我忘了这则实验的出处了，但实验的精神是记忆犹新的，哪位同学记得原始出处的麻烦提醒我一下。

[5] 对于阿基米德这个故事的真实性是有争议的，毕竟几千年久远的事情谁弄得清呢。但是故事的道理是很本质的，我们平时也经常有类似的体验，加上阿基米德的“尤里卡”实在太出名了，所以我相信用用无妨。

转载－优质课程

原文 https://www.yangzhiping.com/tech/mac6.html

背景

这是个好时代，原本离我们很远的优质课程垂手可得；这是个坏时代，数字鸿沟渐渐加深。善用网络与沉迷网络，区分开两类人群。

这篇帖子侧重介绍：

有哪些优先级别较高的优质课程？
如何批量下载它们？
如何管理这些优质课程？
如何组建家庭影院播放它们？

其实谈及的技巧，并非Mac不可，在Windows上照样可行。

1.有哪些优质课程？

这方面的帖子，我写过太多了，请重点参考：

重点而言，这些优质课程值得收藏、收藏再收藏：

1.1 适合所有人

Coursera.org：名校课程汇集
TED: Ideas worth spreading：尖峰创想，启迪心智

1.2 适合开发者或者极客

Code School

Learn by Doing – Code School：

应该是我定过的课程中最好的了。比Railscast更系统与更深一点，比peepcode更有趣与更短一些。

RailsCasts

Ruby on Rails Screencasts – RailsCasts：

作者是ruby社区的老黄牛，绝对英雄。坚持了多年，每周一个免费视频。很多人都是通过他的视频入门的。更牛的是，作者一切内容都尽可能开源。

PeepCode

PeepCode | Programming and Development Tutorial Screencasts for Web Developers and Alpha Geeks：

近期刚刚被收购。这个公司出品的教程质量偏高，部分视频有一定难度，介绍的内容，比如Backbone.js，node.js这些，总是先人一步，代表了开发者社区未来的一种倾向。里面的play by play 栏目非常有趣，录制了Zed shaw等世界级优秀程序员实时工作的屏幕。可以看到他们的vim、textmate等等：）

confreaks

confreaks.com

confreaks是一个录制各个技术大会的网站。包括去年的openstack、历年的Ruby与Rails大会等录制。

1.3 适合科研工作者

videolectures：

众多高质量，包括诺奖得主参与的学术会议视频、ppt合集。也不仅仅是学术会议。包括众多高质量课程。遗憾的是，网站本身对Html5等支持较差，难以通过ios等设备查看。

2.如何批量下载它们？

为什么要批量下载？

因为，批量下载有这么多好处：

跨设备同步进展方便，比如，在没有网络的环境下浏览
分享与进一步处理方便
更容易获得随机点播带来的惊喜

我将批量下载它们的方法收集在一个项目中：ouyangzhiping/metacourse。目前已经添加了批量下载它们的方法：

courera
railscast
TED

未来将补充完善其它优质课程的网站。当然，现在也有更简单的办法，就是使用我已经解析之后的下载源。以广受大众欢迎的TED来举例，如何批量下载。

3.如何批量下载一千个TED中文视频

我们的目标是下载一千多个TED中文语言版本的视频，并且文件名最好重命名为作者_演讲标题这种格式。如果是其它语言，方法完全类似。

3.1 前提

有迅雷离线账号
有150g以上的硬盘闲置空间

3.2 开始下载

下载地址文件：TED_download.list

将其下载下来，然后使用迅雷打开即可。没什么特别需要注意的，小提示：

请务必使用离线与加速功能。这样，你可以享受到我已经加速过的部分视频，其它网友也可以享受到你带来的好处。
将这一千多个视频都保存在一个文件夹里面。

下载好了，效果是这样的：

P9397877

文件名是：HonorHarger_2011S-480p-zh-cn.mp4 这种 作者_年份_事件_解析度_语种的命名规律。

4.如何管理这些优质课程？

这些优质视频，我们该如何管理它？没有简介，未来如何标记哪个看过、哪个没有看过？

仍然以TED为例。小技巧来了！

第一步：打开iTunes，点击：iTunes Store，找到播客栏目，在搜索中，输入TEDtalks，如下图所示：

P9398002

首先随便订阅一个中文语种的TEDTalks的podcast，例如TED财经：

P9398007

然后，再将我们之前的一千多个批量下载的TED视频导入到资料库中，

P9398011

我们发现，所有之前下载的TED视频的文件名全部根据zh-ch这个界定，自动更新为中文名称了：

P9398016

P9398017

并且有中文摘要了！

P9398024

打开finder，iTunes保存这些TED演讲的文件夹位置，我们发现，一切都变为中文了，更适合小孩与家人一起来看了：

P9398111

如果需要纯英文版与拿它来作英文学习怎么处理？参考这两个网站的下载源;

5. 如何组建家庭影院播放它们？

买一台几百元的apple tv3，直接通过airplay功能投放到电视机大屏幕上即可。步骤如下：

1）在iTunes中，打开家庭共享功能。

P9398141

2）在apple tv3中，打开家庭共享功能，输入你的iTunes所使用的apple id账号即可。

一切完事！然后可以舒舒服服，坐在沙发上，用遥控器来看自己想看的优质课程。

P9398073

6. 其它

以上方法适用于一切批量下载的优质课程，同样，我们还可以直接使用iTunes U功能，即大量优质课程，如TED的itunes u课程尤其值得参与：

CA Expo 2013

云计算及跨平台IT管理供应商CA Technologies今天宣布CA Expo（中国站）将于8月13日及15日分别在北京富力万丽酒店和上海金茂君悦大酒店盛大举行。今年CA Expo的主题为“IT所见，大势所趋（GO BIG, IT with IMPACT）”，呼吁亚太及日本地区的CIO及IT领导者们，拥抱云、移动化、社交和大数据等颠覆性技术，推动业务创新。
　　如今，对IT领导者而言，仅维护IT服务是远远不够的。在中国，CIO们正在管理日趋复杂的IT环境，不但要面对用户对IT服务更高的期待，还要不断自我加压，“花小钱办大事”。
　　一年一度的CA Expo是CA Technologies在亚太及日本地区的旗舰活动。本次活动上，CA Technologies将会同客户和合作伙伴分享最新的IT管理愿景、解决方案和服务。今年的CA Expo（中国站），CA Technologies从全球到地区的高级管理者，包括亚太及日本地区总裁Lionel Lim先生、中国区总经理孙志伟先生等，将为参会的IT决策者解读市场，洞察技术。
　　CA Technologies亚太及日本地区总裁Lionel Lim表示：“如今CIO们在利用成熟的颠覆性技术（云、移动化和大数据等）推动业务创新方面拥有独特的机遇。CA Technologies正处在这个创新时代的中心。我们已经规划出了新的战略，并开发了全新IT管理解决方案和服务，来协助IT领导者取得成功。我们十分期待在CA Expo（中国站）期间与用户及合作伙伴有更多、更深层次的交流。”
　　CA Technologies将会在CA Expo（中国站）公布全新IT管理解决方案和服务。
　　欲参加CA Expo 2013（中国站），请点击注册：
　　北京站：https://www.ca.com/cn/lpg/Events/CA-Expo-13-Beijing.aspx
　　上海站：https://www.ca.com/cn/lpg/Events/CA-Expo-13-Shanghai.aspx

转载-大学生创业为什么会挂掉？——来自2年实际孵化工作的总结

来源 https://www.36kr.com/topics/401

虽然是针对学生创业的，但是对小团队项目开发的同学也很有参考意义。

———————————————————————————-

简单背景：

从2011年7月开始，我有幸得到导师的支持，在离北邮不远的小西天拥有了一块面积130㎡的空间，开始了我的大学生创新创业孵化工作。

接近2年的孵化工作中，我前后孵化过的团队有16个，成立6个月后存活的有7个，成立1年后存活的仅有4个，其中一个被技术收购了、一个没融资但实现了收支平衡、一个苦苦支撑着马上能获得天使了、最好的一个马上就A轮融资了。

12个失败项目和4个相对成功案例，总结出来10个大学生创业教训：

1. 学生创业不要做上下游对接很重的产品

云端科技是一个很有意思的项目，他目标是帮你的钱包瘦身，将所有的优惠卡、会员卡、积分卡都放到一个app上。可是项目最后失败了。原因是：这是资源导向性的项目。他们相当于商家和消费者之间的桥梁，满足消费者的需求这点已经很难做，更何况他们需要大量的商家在你的app上登记、更新。而后者偏偏是需要大量社会资源，大学生往往无法凭借“努力”就能补上的短板。

所以，大学生项目一般只做对接一类用户。比如，Facebook最初只做大学生，超级课程表也是只针对大学生。

2. 如果你创业方向不是你的兴趣爱好，请谨慎

俗话说“兴趣是最好的老师”，行话也有说“隔行如隔山”。最靠谱的学生项目首先是源自创业者的兴趣和爱好。一个不爱看书的团队，做的却是书友间的兴趣社区；一个自己不玩游戏的人，却异想天开做游戏。真正进入一个行业，需要时间成本，了解新概念、了解用户习惯、了解潜规则。时间是创业的最大成本，进入一个行业和做你的项目，你能兼顾吗？

大学生阶段，大部分学生对“产品”的掌控设计能力、对“人性”的理解尚未形成系统的知识。凭着一股热情，大家应该从最熟悉、最经常接触的方面入手，发现过程中很麻烦、很不便利、很难堪的地方，利用互联网、科技的方式来优化这个过程，使大家（用户）的生活更加美好。不错，无论app、网站，都只是一种优化的方式（这是一个月前的理解，最近对互联网的本质是什么又有了新的体会），他并不是生活的主题。

3. 人员稳定性是学生团队的最大杀手，而队长则是决定项目成败的重中之重

在每个团队的最初最关键6个月，有超过一半以上（9/16）的团队发生人员变更。回想文章开头的那个数据：创业6个月后失败的团队数（9/16），冥冥中还是有关系的。两个数据的团队不是重合，我们通过观察可以了解到，团队某个成员因为个人发展目标并不在此，6个月或者一学期过后，他们会由于现实的压力（保研、考研、托福、GRE）而选择放弃。并且因为这些成员承担着项目某一重要部分，而导致项目不得不中止。除非，团队本身的执行力很高，6个月以内已经做出产品。这个很难，详细看第4点。

原因很简单：社会创业者承担着失败的风险，创业这事对自己的家庭、未来有着举足轻重的影响；而在校学生创业，他们没有忧患的意识，更多地是试一试的心理。请问，两军对战心理如此，何方可胜？

而过了6个月后，项目的产品出来了，这时是队长发挥作用的关键时刻，项目成败也取决与队长。队长承担着一个这么重要的角色：产品设计、部分技术工作、市场营销、战略发展、团队协调。6个月后产品面向用户、面向市场，技术研发已经变成一个次要的因素，怎么在有限时间内使项目获取到一个好的数据、好的口碑，甚至是好的收入，需要队长超强的前瞻性，指挥好队员的工作。一个好的项目，他们的队长无疑都是杰出的，让人觉得nb的。

4. 第一次做项目？别想多了，就当积累经验吧。

最初的时候，我认为大学生能够凭借自身的学习能力，即使是第一次做项目也能创业成功。但事实告诉我，学生缺乏经验是最主要的原因。具体表现有：进度无法保证、时间表无限延后，一个学期（半年）都没做出一个demo，从而团队心思散涣，进而团队解散。16个项目中，有7个团队第一次做项目，最后仅有1个团队存活（XL-View）。这个存活的团队也不是一帆风顺，期中曾发生一次团队震荡，幸好负责人和我及时地重组团队。

所以，想参加创业团队或者组建创业团队的同学，看看你这个团队以前是否都有集体项目经验（不是学校那种创新实践项目），而是有否承接过外包？有否做过别的项目转型而来？如果没有，你又很想在这个团队中共事，先别太心高气傲，第一个项目，先练练手吧。

5. 社交、电商和平台

太多同学都有一个美好的愿景，但这个愿景也是他们当前的目标。这造成了愿望太美好，无法实现。他们描述项目最常见的三个词“社交、电商、平台”，没有一个项目天生就该如此，这3个词只是你以后发展的方向。

任何的愿景都是一步一步叠加而成的。Facebook当初也只是一个Facemash（比比两个人中谁更漂亮），没有社交、没有分享、没有登录。只有2个按钮，A漂亮还是B漂亮。Facebook也是在这个的基础上一次一次的迭代、改善、改版做出来的。Twitter同样也是。这些故事都可以网上搜到。

缺乏将愿景细化成一个核心功能真正落地的能力。只做一个核心功能，能够使你集中力量把这个功能做到最好，一个100%优秀的功能，无疑比10个10%的功能更加吸引人。

6. 优雅地死去

新产品出来前后的运营是学生很大的薄弱点，他们会问怎么告诉你的用户呢？

一个百万PV的网站，用户并不是天生的。微博火的时候，去利用热点新闻吸引眼球、去做微博应用然后想办法上首页，新浪腾讯2家都多少流量了；微信公众账号自动回复功能编写了几百个条；各大论坛、贴吧刷帖，老被删就去摸GM的上线习惯利用时间差发帖多存留点时间……

“优雅的”学生团队连去开水房贴上温馨提示并附上二维码都不愿意去做。他们守着他们的网站，等待用户的上门。这些脏活、累活，不屑于去做，那些邪门歪道你们更加鄙视（不提倡呵呵），那么你们凭什么而活？

创业就像一群人去争地盘。你可以选择优雅得像个Gentleman，掏出手帕擦擦枪头，讲究仪式，而流氓上来抡起拳头就开干了。Live or die, make your choice。想想这句话后面的镜头你就懂了。

7. 活着，比一切重要

同学们一直幻想着这个事情：坐在电脑前，埋头苦干几个月，做出一个惊世骇俗的产品，用户蜂拥而至，投资争先恐后。或者说，不愿意赚钱，也未曾想过要赚钱，认为只要用户多，以后肯定有盈利的方法。问题是，你能活到以后吗？

你可以不要冠冕堂皇的办公场地，但一定要找到一个能够挤下你团队办公的小地方；你可以鄙视各种作秀的创业比赛和电视节目，但一定要抓紧每一次能够给公司带来收入的机会；你可以不拿工钱，但一定要推出一些服务来赚钱，即使是小钱。

因为每一分钱，可能帮你解决一个难题。能用钱解决的问题都不是问题，但你连用钱就能解决的问题都解决不了，你又如何能解决更难更复杂的问题呢？

投资人的钱是把双刃剑，在损害你们团队的利益的前提下使你们能够得到生存。这个需要团队负责人好好思量一下了。

8. 投资人不是创业者的赚钱机器

我们算算学生项目初期需要多少金钱：服务器（100/月）、开发书籍（300）、开发者认证（iOS $99，Android $25）、域名（200/年）加上团队建设（400）的费用，一年费用大概￥2000元。这是研发的基本费用，可以算多，也可以算不多。但大部分的同学抱着这样的想法：自己不愿意掏这笔钱，等着“投资人”出吧。创业是自个的事情，靠自己的双手打拼，遇到困难，首先是自己想办法尽努力地去解决，而不是寄望于别人帮助。要知道，每换回来一次好处，就要给对方相应的回报，没有人天生义务帮你的。

另外说一个案例，某创业大赛里面，一个团队从演讲到展示环节都表现得十分好，到了问答环节：“你们通过什么方式盈利？”回答“融到100万”。不知可笑还是无奈，投资人成为创业团队的“赚钱方法”。其实投资人并不是最后给你产品买单的人，投资人是认同你团队的方向，投入金钱跟你们一起把项目做起来的“合伙人”，你们的区别是，投资人付出金钱，团队付出实际劳动。

9. 前途十分美好、市场非常宏大

两年来，收到无数来自全国各地大学生的邮件，最常见的一封邮件就是只有一行字“我的想法\产品前途十分美好、市场非常宏大，请问可以获得XXX支持吗？”这里要吐槽两点，一是凭什么是“美好”、“宏大”的？数据呢？行业呢？证据呢？另外，往往大学生项目存在深深的臆想中，没有找过客户、没有跑过市场，在学校里在电脑前YY。

二是，如果你要寻求帮助，请务必将你的想法、产品、计划、目前的阶段给对方说明白。我自认为还算比较热心，这样的邮件都一一回复了。如果你的发送对方是你的客户、投资人，他们会百忙中会如何处理？——垃圾邮箱或者直接删除。大学生，请锻炼你的社交能力，起码明白基本社交礼仪。

10.技术能帮到你什么？

13个失败项目中，不乏技术导向型的团队，利用自身在实验室的工作而获取到的特殊技术，想转化成面向用户的产品，而这样的团队往往是失败的。前面讲过“技术是一种方式”，换言而之，技术仅仅一种提升程度的手段，人们并不需要活在技术中；观察市面上流行的app，并不需要多厉害多高超的技术，他们抓住的是用户的最不舒服的场景，提供最贴心的功能。同时，技术导向型团队更多是“工程师”思维，为了实现功能而去做功能，缺乏设计和用户体验，用户还没体验到该技术的厉害，就早已关掉应用了。

另外说一下，技术导向而成功的项目，一般具有2个特征：1是技术做到极致或行业内顶尖；2是面向的用户群不是普通大众，而是第三方开发商。清华的face++团队是这样的例子，他们拥有优秀的人脸识别技术团队，他们把技术做成开放接口供其他第三方调用。这种类似PaaS（平台即服务）的做法，是技术型创业团队要好好参考的出路。

综上所述，我个人总结了具有成功潜质的学生创业团队应当满足的3个条件：

队伍稳定，不一定要成员齐全，起码队伍里面的人能够在6个月内以创业这件事为主；

队长/负责人必须懂产品，且创业方向是他所擅长的；

团队高效的执行力。

16个曾经支持的团队里面，我见到完全符合3点的有1个（V电影），符合其中2点的有3个（云印、XL-View、半次元）。一件事要成功，不在于做的事情，而在于“人”本身。各位年轻人，你们认同么？

当然，不是说方向和做的事情不重要，我简单归纳了一下未来一年很有可能爆发的点，希望能帮到大家：

1. 降级

别盯着北上广了，二三线城市中都是机会，java机时代的电子小说就是一个例子；别只做互联网应用了，想想传统行业有什么弊端和不便，利用互联网的特性将它改进。

2. 手机作为入口，服务作为商业模式

纯app扩大用户量这种重视线上产品是互联网老一套的玩法。相信将会涌出一批这样的公司，重视并提供优质的服务，拥有忠实的用户，app的地位下降只作为入口。

3. 软硬结合

这是一个机遇，也是一个大坑。机遇在开源硬件的兴起、纯app市场的饱和、新工业革命的即将到来，坑在这类的项目迭代周期和链条相当长，即使有开源硬件，耗时耗钱耗精力也是相当厉害的。参考案例：各种手环、智能手表、极路由。

后记：

2年了，自己本身不爱写东西，但是得给我和我的小伙伴，还有以后的小伙伴一个交代；终于憋出来这个。挺佩服自己，能将一篇总结从接近2周年写到过了2周年。2年的心得肯定不止这些，我也不确定自己能不能写。所以，欢迎大家跟我探讨吧：）留下评论或者邮箱我dennisbear#gmail.com

目前我的孵化方向除了互联网以外，开始跳另一个坑：软硬项目。去过深圳、去过创客空间、了解过这些创业团队，也准备联合几家大公司在北邮成立软硬开放实验室。虽然这是个大坑，但我先跳了，后面再跳的人就有我垫背，他们不至于摔得那么疼：P

感谢16个团队，也感谢你们对我的包容和理解，我爱你们：

云印、XL-View游戏工作室、云端科技、这的云、点睛、老少联、potato游戏工作室、来钱快、半次元、V电影、偶遇先生、的感觉工作室、书友汇、易买卖、拯救小扎、QiaQia