甲午战争中日本战胜清廷靠的是先进的理念,不仅仅是军事理念 (思想)

一直都觉得这个例子很受用. 其实任何情况的竞争都存在这样的情况, 从国家/民族的竞争历史来看, 近代以前更注重的是工具/生产力的竞争, 但近代以后的竞争更多的是思想观念上的竞争. 大的东西说不好, 但即便是类似公司里/学校里的这种个人竞争, 很多时候也是这样. 最一开始可能是"后勤"起着重要的作用, 但最后即便两个人都有电脑这种更先进的工具, 也会因为mindset上的落后导致个人竞争中落败.

教育小孩子也是这样的, 工具和硬件条件可以不用过多, 足够即可, 更多的是好的思想. 在初期能种一棵好种子(mindset), 至关重要.

担心的几点：

1. 是否真的是需要被资助的人

2. 中介机构是否能够给一个定期的资金使用情况（一定的行政费用是可以接受的）

3. 没有互动，感觉就是每月少点钱

想过找一些只针对助学的项目，比如资助小孩从初中到高中毕业的学费，只有学费。这样可以让钱的用途透明，并且可以让捐助人对小孩/学校更了解，进而再去了解家庭。我自己的一个观点吧 - 只有那些愿意让小孩读书的家庭我才愿意捐助，如果只是把钱给贫困家庭贴补家用不是我要/能解决的问题。应该找ZF。另一方面，捐助中介机构目前还是不够多，选择很有限。

第二个问题，貌似目前在国内是无解的，从来没见过红十字会的审计报告，而在不支持NGO的大环境下对NGO们要求这个也不现实。

第三个问题，愿意捐助的那部分人（除了沽名钓誉的某些名人外），还都算是有点社会责任感的，组织一些类似“多背一公斤”这样的走入贫困山区学校的活动，甚至长期的和被捐助小孩的交流，会让更多人真正感觉到自己做的事的意义。

可能有人觉得，你丫想捐就捐，要求哈多。呵呵没办法，你丫对别人没要求的话，对任何人 - 自己/被捐助的小孩/捐助机构都没有好处。最怕的是伤到心，就像某国的某十字会一样。

之前和同事聊的时候, 曾提过"新兵训练营/群英会更像是一种仪式", 通过这样的仪式可以让人不知不觉信了,不知不觉的执着(或者执迷不悟). 其实人的情感是很脆弱的,当仪式很神圣的时候人们会很自然地把自己和自己以后要做的事情想的很神圣 - 不知不觉的被同化. 而一个人觉得仪式有多神圣是和他的生活经历/背景/教育程度相关的. 当然仪式还有问题是 - "当场有效", 回家后该怎么做还怎么做.

我经常会问教会的兄弟姐妹们的是"为什么要信",有一定经历的人会说是在他最困难的时候听到了神的感召, 比较年轻的人会说"觉得很神圣","和家里人一起来的", 有时候 我倒很想听到"没有为什么,就是信"这样的答案.

（摘自：http://www.williamlong.info/archives/2907.html）

理解人类的需求并提出解决方案：

• 1. 沟通——与人建立联系的能力，能够同他人亲密的交谈，并有勇气去尝试分享自己的观点。
• 2. 意图——从谈话中提取有用的信息，理解并使之有意义。
• 3. 逻辑——为不懂让步的计算机整理、剔除那些人类思想中含糊而有争议的内容。
• 4. 创造力——挖掘、转变人类的想法，从而创建优秀的解决方案。
• 5. 构思——利用人类友好的接口和便捷的互动性来包装编程思想。
• 6. 大局观——清楚解决方案是如何适应全世界的用户、企业以及其他，从而使你的程序更有用。

告诉计算机该做什么，并建立解决方案：

• 1. 逻辑（再次强调）——把程序员的想法组织整理成有凝聚力的软件思想和计算机指令
• 2. 技术——发现并理解科技黑箱（对于99%的人来说是黑箱）。
• 3. 编程语言——学习美观的、富有逻辑的、清晰明了的语言，从而把程序员的想法提供给电脑。
• 4. 算法——精通让计算机完成任务最高效的方法。
• 5. 建模——在软件代码中建立抽象和模型，从而掌握并操控想法。
• 6. 实践（比如代码重构、单元测试、持续集成）——周期性活动，以保持系统可靠、健康与可改变。

面向人类和面向硬件对象/系统的程序员有很大不同。

不与人沟通的程序员不是好程序员。一个优秀的解决方案需要计算机世界与人类世界的双重技能。只有连接起两个世界，才能成为一个真正的优秀程序员。

一直以来对南亚和东南亚国家都有一些蔑视，也许是因为对历史的一知半解加上一直以来的愤青情结加上一些不自信导致的自大情绪。来之前抱着“比朝鲜好一点，比咱发展晚十年”的先入为主。

可到了岘港，貌似有了不一样的发现。随处可见的wifi，干净整洁的街道，原始淳朴的人们，休闲的生活状态。虽说也可以看到建筑工地和破败的房子。也许仅仅是因为不一样？表面的不一样？也许是拿上海这样的大都市和旅游城市比较不太合理，但想想那些国内的中小城市，走在路边看到最多的也是混凝土的颜色，而岘港不是。走在街边总是很有看头，一副欣欣向荣的样子。

去看了阮氏皇朝最后一个皇帝的陵墓, 和故宫, 所见所听感觉越南历史就是一个缩小版的中国，无论是那个自称故宫但规模赶不上清朝王爷府,还是那个软弱可悲的"末代皇帝".

当我们抱着优越感调侃着那位普通话不标准的导游时候是否应该低头看看自己, 我们的优越感来自哪里?

OK，也许仅仅是“不一样”。

--补发

简单列下来（和原文一样，从后往前列）

10. 让用户用的爽

9. 清晰，开放，实事求是

8. 不浪费用户时间在一些不必要的信息和操作上 - 减少浪费时间的噪音

7. 帮助用户建立对你的信任 - 专业的界面设计/可以打的通的电话，甚至留一个地址

6. 有一个明确的退货政策 - 有这样的政策可以打消用户的疑虑

5. 让用户随时知道进度

4. 提供各种付费方式

3. 提升访客价值 - 推送相关产品和服务

2. 让用户记住你

1. 铭记你的USP（Unique Selling Point）

后续作者又补充了9条（有点务虚了）（http://www.addedbytes.com/online-marketing/nine-more-ways-to-improve-your-website-conversion-rate/）

9. 知道观众是谁，并保持沟通顺畅

8. 不要害怕犯错误/承认错误

7. 不要草率结论

6. 跟踪记录一切

5. 把持续改进变成习惯

4. 充分利用网站空间，但避免杂乱

3. 不要给用户制造障碍来使用网站

2. 谨慎使用折扣券/折扣码

1. 清楚你的定价策略

到了电影院，有专门的取票机，输入手机号码/取票密码，电子票直接打印出来。期间除了觉得票价和到电影院买的完全一样以外，没觉得什么特别不爽。

可是晚上回来就崩溃了，上邮箱截图：

不用这样吧！！本来挺好的从线下回线上的idea，就因为这么个小小细节毁掉了。

记下比较经典的几个观点，有些观点可供参考，但并非全部赞同。

1. 不做事

砍掉应该砍掉的东西，什么东西应该砍掉 ？ 低产出的项目和产品。说起来有点残酷，但这里有个前提，被砍掉项目并非是砍人，一个优秀的人自然可以找到好的项目发挥能量。这个应该和国企裁人是两码事，不应该上升到个人感情。

砍掉以后，focus

做事方法不重要，只要能够保证focus，“怎么做”可能取决于不同的vision，比如乔布斯做pc和盖茨做pc的套路就是两种，但都是成功的。因为二者的vision从开始就不一样，乔布斯想让所有人都有酷的，方便的电子设备，让科技走向大众消费领域，然后才是技术平台/生态圈；而盖茨就想让pc用起来爽，而且可以有很多应用，然后才是酷的，好玩的，炫的。基本可以说是帅哥和宅男的路数。

2. 捡西瓜而不是芝麻

虽说一看到这个标题我就很自然的冒出一句：“哪里有那么多西瓜啊！”

其实这个观点和“不做事”类似 - focus在有潜力/重要的产品上，但说回来，想要找到有潜力的点并能制造出壁垒避免被腾讯模仿，然后成功突围，在现时的中国还是有点难度。

壁垒是什么 - 先进的工具/管理理念，或者应该还有一个“牛逼的团队”

总的来说，从促进创新的角度来说，“边吃芝麻，边找西瓜”还是应该鼓励的。

3. 中国的工程师都是4流5流

吴军博士对工程师的定义很宽泛，本田宗一郎是一流工程师，Linus是二流偏一流工程师。。。我等鼠辈真是汗颜，距3流应该还是有一定距离的。三流的定义是可以定义产品并能带领团队开发完成。这样的在国内还是有一些的。不知道马哥是几流的？

其实到大可不必纠结自己倒是几流，认识到差距就是了。差距无非几个：1.耐性 2.表达 3.不畏惧权威（这个是我加的）

耐性在中国是一个很大的问题，真正能够耐着性子坚持的软件工程师不多，改善也没有多少。

美国的教育从小注重表达，无论是书面还是口头。这个和教育体系也有关系。

4. 未来的行业格局总是有历史可以参照的

每一波“浪潮”都必备的几种元素：

冤大头 - 最早的创意，先烈

主角 - 真正把握机会并垄断行业数年

千年老二 - 紧跟主角，无法撼动主角的位置，但依然可以活的不错

转型后居上者 - 从其他行业跳过来，通过不同的扩张手段站得一席之地（促进了不同行业间的互相换血）

小配角 - 模仿者，跟风者，企图通过微创新撼动主角地位的，

期待下一期！

如果使用充血模型，你的代码读起来就好像：今天他来了，然后他死了。 - he.goto(Place,TrafficTool); he.died(DeadReason);

而贫血模型的话，读起来就像是：一辆大巴载着他来了，然后死神带走了他。 - bus.taketo(He,Place); death.takeaway(He);

“他”就是模型，在整个编程模型中怎么理解他至关重要，否则在开发团队里就存在混用的情况。用哪种模型完全取决于个人喜好。

一般充血模型比较适合逻辑不是很复杂，比如大多数都是单表，不存在复杂的关联的情况。贫血模型的使用范围比较广，用着也简单，但代码看起来多，而且读起来吞吞吐吐。毕竟充血模型需要在扩展时非常清楚合理地把行为定义到正确的模型上。