<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Notes on Non-Convex Notes</title><link>https://hongyi.sh/tags/notes/</link><description>Recent content in Notes on Non-Convex Notes</description><generator>Hugo</generator><language>en</language><lastBuildDate>Thu, 23 Jul 2026 23:43:22 -0700</lastBuildDate><atom:link href="https://hongyi.sh/tags/notes/index.xml" rel="self" type="application/rss+xml"/><item><title>一周笔记</title><link>https://hongyi.sh/posts/2016-07-31-weekly3/</link><pubDate>Sun, 31 Jul 2016 00:00:00 +0000</pubDate><guid>https://hongyi.sh/posts/2016-07-31-weekly3/</guid><description>&lt;h2 id="how-to-write-a-lisp-interpreter-in-python"&gt;&lt;a href="http://norvig.com/lispy.html"&gt;(How to Write a (Lisp) Interpreter (in Python))&lt;/a&gt;&lt;/h2&gt;
&lt;p&gt;老文章。来自Peter Norvig 的用 Python 写个 lisp 解释器。代码和解释都很完美。记得有公司出面试题出类似的，如果用这文章里的思路解决就秒杀啊。&lt;/p&gt;
&lt;h2 id="dns-the-good-parts"&gt;&lt;a href="https://www.petekeen.net/dns-the-good-parts"&gt;DNS The good parts&lt;/a&gt;&lt;/h2&gt;
&lt;p&gt;比较详细的介绍 DNS 的文章&lt;/p&gt;
&lt;h2 id="2016年科技阅读列"&gt;&lt;a href="https://zhuanlan.zhihu.com/p/20472545"&gt;2016年科技阅读列&lt;/a&gt;&lt;/h2&gt;
&lt;p&gt;一系列架构和大数据文章的集合，质量良莠不齐，偶尔也有好玩的。&lt;/p&gt;
&lt;h2 id="高并发性能调试经验分享"&gt;&lt;a href="https://zhuanlan.zhihu.com/p/21348220"&gt;高并发性能调试经验分享&lt;/a&gt;&lt;/h2&gt;
&lt;p&gt;最喜欢看这种调试的文章了，特别是这篇『在多线程和高并发环境下，如果有一个平均运行一百万次才出现一次的bug，你如何调试这个bug』，连思路带工具一路娓娓道来，非常值得一读。&lt;/p&gt;
&lt;h2 id="penetration-testing-tools-cheat-sheet"&gt;&lt;a href="https://highon.coffee/blog/penetration-testing-tools-cheat-sheet/"&gt;Penetration Testing Tools Cheat Sheet &lt;/a&gt;&lt;/h2&gt;
&lt;p&gt;渗透工具 cheatsheet，初入安全的朋友可能会用得到。&lt;/p&gt;
&lt;h2 id="heading"&gt;&lt;a href="http://www.informit.com/articles/article.aspx?p=1941206"&gt;&amp;ldquo;The Best Programming Advice I Ever Got&amp;rdquo; with Rob Pike&lt;/a&gt;&lt;/h2&gt;
&lt;p&gt;Rob Pike 谈论 Ken Thompson 给他的编程建议：&lt;/p&gt;
&lt;blockquote&gt;
&lt;p&gt;Ken taught me that thinking before debugging is extremely important. If you dive into the bug, you tend to fix the local issue in the code, but if you think about the bug first, how the bug came to be, you often find and correct a higher-level problem in the code that will improve the design and prevent further bugs.&lt;/p&gt;</description></item><item><title>一周笔记</title><link>https://hongyi.sh/posts/2016-06-05-weekly2/</link><pubDate>Sun, 05 Jun 2016 00:00:00 +0000</pubDate><guid>https://hongyi.sh/posts/2016-06-05-weekly2/</guid><description>&lt;h2 id="the-software-development-poverty-trap"&gt;&lt;a href="http://alexandros.resin.io/the-software-development-poverty-trap/?utm_source=wanqu.co&amp;amp;utm_campaign=Wanqu+Daily&amp;amp;utm_medium=website"&gt;The Software Development Poverty Trap&lt;/a&gt;&lt;/h2&gt;
&lt;p&gt;软件开发中的马太效应，越是差劲的团队越缺乏长期规划，用老旧的技术，写 ad-hoc 的代码，优秀的工程师越容易离开（斜眼看我司）。&lt;/p&gt;
&lt;h2 id="把程序写好这回事"&gt;&lt;a href="http://mp.weixin.qq.com/s?__biz=MzA3MDMwOTcwMg==&amp;amp;mid=2650004561&amp;amp;idx=1&amp;amp;sn=967c3816e3b0993b5517799183efb3be&amp;amp;scene=0#rd"&gt;“把程序写好”这回事&lt;/a&gt;&lt;/h2&gt;
&lt;p&gt;来此余晟的微信公共号（对，就是翻译正则表达式的那哥们）。很多程序员在学校和工作中编程，但不知道如何写好程序，貌似也没有学校教如何『写好程序』。写好程序绝不是编译通过，跑过测试，符合 coding style 那么简单。文中提到的『荣誉感』还是挺重要的，我写代码的时候就会想着对自己的每一行代码负责，通过 code review 看别人的代码质量也会潜移默化影响我对这个人的评价，和对待他的态度。&lt;/p&gt;
&lt;h2 id="what-every-programmer-should-know-about-memory"&gt;&lt;a href="https://www.akkadia.org/drepper/cpumemory.pdf"&gt;What every programmer should know about memory&lt;/a&gt;&lt;/h2&gt;
&lt;p&gt;挺长的，从偏硬件的角度讲解内存的原理。前面几章在各个 OS 教科书上都能找到，后面的内容就比较贴近现实，看着很有意思。&lt;/p&gt;
&lt;h2 id="the-little-manual-of-api-design"&gt;&lt;a href="http://people.mpi-inf.mpg.de/~jblanche/api-design.pdf"&gt;The Little Manual of API Design&lt;/a&gt;&lt;/h2&gt;
&lt;p&gt;记得 GoogleTechTalk 里著名的一集 &lt;a href="https://www.youtube.com/watch?v=aAb7hSCtvGw"&gt;How To Design A Good API and Why it Matters&lt;/a&gt; 么，这个 manual 可以看作那个 talk 的扩展读物。API Design 在程序设计中的重要性相比于架构不遑多让，看看这些 best practices 有益身心~~&lt;/p&gt;
&lt;h2 id="what-powers-instagram-hundreds-of-instances-dozens-of-technologies"&gt;&lt;a href="http://instagram-engineering.tumblr.com/post/13649370142/what-powers-instagram-hundreds-of-instances?utm_source=wanqu.co&amp;amp;utm_campaign=Wanqu+Daily&amp;amp;utm_medium=website"&gt;What Powers Instagram: Hundreds of Instances, Dozens of Technologies&lt;/a&gt;&lt;/h2&gt;
&lt;p&gt;一篇老文章，介绍 Instagram 早期时候（2012）的架构。我最喜欢这种早期架构的文章，看别人在高速增长期如何用快糙猛的方法解决问题。里面给的小部分技术在今天看来有些过时了，但大部分还很有借鉴意义。比如提到的 gunicorn 和 Fabric，是 Python web 开发中的标配（还有 supervisor）；vmtouch （查了下发现是一个超级light weight的内存数据管理工具，代码也写的很棒）；Munin，Pingdom 监控，Sentry 报告错误。&lt;/p&gt;</description></item><item><title>一周笔记</title><link>https://hongyi.sh/posts/2016-05-21-weekly1/</link><pubDate>Sat, 21 May 2016 00:00:00 +0000</pubDate><guid>https://hongyi.sh/posts/2016-05-21-weekly1/</guid><description>&lt;h2 id="第二周"&gt;第二周&lt;/h2&gt;
&lt;p&gt;这周 RSS 里没啥非常好的文章，就把以前的笔记里翻出来几篇凑数。&lt;/p&gt;
&lt;h2 id="elevate-yourself-with-side-projects"&gt;&lt;a href="https://slackhq.com/elevate-yourself-with-side-projects-acbc43229422#.12qjef3av"&gt;Elevate yourself with side projects&lt;/a&gt;&lt;/h2&gt;
&lt;p&gt;爱因斯坦的在专利局工作时候的 side project 是相对论论文，学校门卫波洛克（对，现代艺术甩泥点子那位）的 side project 是画画，Slack 一开始也是游戏公司的 side project 聊天工具。Side project 能真正有效促进一个人的专业进步（深有同感）。不是有句话说么，这年头在湾区没有一两个 side project 都不好意跟人打招呼。&lt;/p&gt;
&lt;h2 id="what-every-computer-science-major-should-know"&gt;&lt;a href="http://matt.might.net/articles/what-cs-majors-should-know/"&gt;What every computer science major should know&lt;/a&gt;&lt;/h2&gt;
&lt;p&gt;压箱底的老文章。 知名博主 Matt Might的一篇长文，很详细的列出了一个合格的 CS 学生应该学习和掌握的知识，任何一个学 CS 的学生都应该看看这篇文章。&lt;/p&gt;
&lt;h2 id="peer-code-reviews-at-loose-cannon"&gt;&lt;a href="http://scottbilas.com/blog/peer-code-reviews-at-loose-cannon/"&gt;Peer Code Reviews At Loose Cannon&lt;/a&gt;&lt;/h2&gt;
&lt;p&gt;技术博客大多谈的是如何学习新技术，如何设计架构，如何找工作，却很少谈如何正确的 Code Review 的。Code Review 在工作中非常重要，是有效的学习/分享知识，增进办公室人际关系的途径。这一系列文章就很详细的谈了如何 Code Review。附赠这篇 &lt;a href="http://www.kevinlondon.com/2015/05/05/code-review-best-practices.html"&gt;Code Review Best Practices&lt;/a&gt;。&lt;/p&gt;
&lt;h2 id="香草冰淇淋世界末日与烧鹿骨"&gt;&lt;a href="http://chuansong.me/n/123723"&gt;香草冰淇淋，世界末日与烧鹿骨&lt;/a&gt;&lt;/h2&gt;
&lt;p&gt;这是一篇我很喜欢的非技术文章。从顾客离奇的投诉『新车会对香草冰淇淋过敏』说起，分析了一些显式因果关系和其背后看似荒诞的理性依据。原文链接已经失效，给的链接是别的网站转的。&lt;/p&gt;</description></item><item><title>一周笔记</title><link>https://hongyi.sh/posts/2016-05-16-weekly0/</link><pubDate>Mon, 16 May 2016 00:00:00 +0000</pubDate><guid>https://hongyi.sh/posts/2016-05-16-weekly0/</guid><description>&lt;h2 id="什么是一周笔记"&gt;什么是一周笔记&lt;/h2&gt;
&lt;p&gt;这是经女朋友提醒，准备每周一篇，阅读的技术博客，文章等的简短评论，干货收集，读书感想及各种好玩的事儿。&lt;/p&gt;
&lt;h2 id="模仿-oreilly-风格插图"&gt;模仿 O&amp;rsquo;Reilly 风格插图&lt;/h2&gt;
&lt;p&gt;一直觉得O&amp;rsquo;Reilly书系的示意图简洁美观，希望写博客或者presentation的时候也能用，今天花时间查了下，字体用的是 Myriad，编程字体用的是 Ubuntu Mono，用 Keynote 画了几个简单的图形，供日后使用。&lt;/p&gt;
&lt;p&gt;&lt;img src="http://i.imgur.com/Iqq2QFG.png" alt=""&gt;&lt;/p&gt;
&lt;h2 id="questions-to-ask-your-interviewer"&gt;&lt;a href="https://rkoutnik.com/articles/Questions-to-ask-your-interviewer.html"&gt;Questions to ask your interviewer&lt;/a&gt;&lt;/h2&gt;
&lt;p&gt;每次面试时候最后面试官都会问 &amp;ldquo;Do you have any questions?&amp;quot;，然后大多数人都只是问一些隔靴搔痒的问题，这篇文章比较深入的探讨这个问题，怎样让问面试官问题成为你的加分点，哪些问题能反映出这个公司的开发流程和工程师文化（关系到是否值得加入），面试必备的好问 （Victoria 同学翻译成了&lt;a href="http://victoriahong.com/2016/05/question-to-ask-your-interviewer-translation/"&gt;中文&lt;/a&gt;）。&lt;/p&gt;
&lt;h2 id="cron-best-practices"&gt;&lt;a href="https://sanctum.geek.nz/arabesque/cron-best-practices/"&gt;Cron best practices&lt;/a&gt;&lt;/h2&gt;
&lt;p&gt;Cron通常用来每隔一段时间跑一个脚本，但大多数人都只是用来检查重启服务器或者备份。本文介绍了一些 Cron 的高级玩法，输出错误码，发送邮件，设置 timeout，等等。BTW，这个作者还有一些 Linux Crypto 的文章，也很值得一看。&lt;/p&gt;
&lt;h2 id="choosing-a-linux-tracer"&gt;&lt;a href="http://www.brendangregg.com/blog/2015-07-08/choosing-a-linux-tracer.html"&gt;Choosing a Linux Tracer&lt;/a&gt;&lt;/h2&gt;
&lt;p&gt;介绍了一堆Performance monitoring &amp;amp; tunning 的工具，来自 Netflix senior performance architect。我查 systemtap 的时候翻到这哥们的博客，发现此人文章很棒，然后和我们司的performance engineer 聊文章中的问题，发现这博主是他当年在 Sun 的同事 &amp;hellip; &amp;hellip;&lt;/p&gt;
&lt;h2 id="latency-numbers-every-programmer-should-know"&gt;&lt;a href="https://gist.github.com/jboner/2841832"&gt;Latency Numbers Every Programmer Should Know&lt;/a&gt;&lt;/h2&gt;
&lt;p&gt;这个介绍不同存储器性能的表格历史悠久，这个 gist 及其评论里很多人贡献了他们知道的相关的文档和视频，很多都很有意思。一些常用的还是很有必要背下来的（比如 CPU， 内存，硬盘， SSD 读取速度的倍数关系），对于初学编程的人能更好的了解 &lt;a href="https://www.wikiwand.com/en/Locality_of_reference"&gt;locality&lt;/a&gt; 的重要性。&lt;/p&gt;</description></item><item><title>Scrape data the right way Part:1</title><link>https://hongyi.sh/posts/2014-05-06-scrape_way/</link><pubDate>Tue, 06 May 2014 00:00:00 +0000</pubDate><guid>https://hongyi.sh/posts/2014-05-06-scrape_way/</guid><description>&lt;p&gt;There is frequently a need to scrape data. Obviously, Python is a good choice for this. The famous libraries like &lt;a href="http://www.crummy.com/software/BeautifulSoup/"&gt;BeautifulSoup&lt;/a&gt; provides a bunch of functions to do these stuffs. But personally, I prefer &lt;a href="http://lxml.de/"&gt;lxml&lt;/a&gt;.&lt;/p&gt;
&lt;h2 id="why-lxml"&gt;Why lxml&lt;/h2&gt;
&lt;p&gt;There already has some &lt;a href="http://stackoverflow.com/questions/4967103/beautifulsoup-and-lxml-html-what-to-prefer#"&gt;comparison&lt;/a&gt; about pros and cons of each library. As &lt;a href="http://lxml.de/elementsoup.html"&gt;lxml document&lt;/a&gt; said:&lt;/p&gt;
&lt;blockquote&gt;
&lt;p&gt;BeautifulSoup uses a different parsing approach. It is not a real HTML parser but uses regular expressions to dive through tag soup. It is therefore more forgiving in some cases and less good in others. It is not uncommon that lxml/libxml2 parses and fixes broken HTML better, but BeautifulSoup has superior support for encoding detection. &lt;strong&gt;It very much depends on the input which parser works better.&lt;/strong&gt;
&amp;hellip; &amp;hellip;
The downside of using this parser is that it is &lt;strong&gt;much slower than&lt;/strong&gt; the HTML parser of lxml. &lt;strong&gt;So if performance matters, you might want to consider using soupparser only as a fallback for certain cases.&lt;/strong&gt;&lt;/p&gt;</description></item><item><title>Notes of Git</title><link>https://hongyi.sh/posts/2012-12-30-progit/</link><pubDate>Sun, 30 Dec 2012 00:00:00 +0000</pubDate><guid>https://hongyi.sh/posts/2012-12-30-progit/</guid><description>&lt;p&gt;&lt;em&gt;&lt;strong&gt;Pro Git&lt;/strong&gt;&lt;/em&gt; is an excellent book about Git, and these are my reading notes.&lt;/p&gt;
&lt;p&gt;This is a brief notes about some points of &lt;a href="http://www.amazon.com/gp/product/1430218339"&gt;&lt;em&gt;&lt;strong&gt;Pro Git&lt;/strong&gt;&lt;/em&gt;&lt;/a&gt;. It only contains first 3 chapters (contains most commonly used commands of Git). I will maintain this article and keep revising it. Hope it might helpful to you.&lt;/p&gt;
&lt;p&gt;##Before Running Git&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;
&lt;p&gt;&lt;strong&gt;Snapshots, Not Differences&lt;/strong&gt;&lt;br&gt;
The major difference between Git and any other VCS (Subversion and friends included) is the way Git thinks about its data. Conceptually, most other systems store information as a list of file-based changes.&lt;/p&gt;</description></item><item><title>笔记:把时间当做朋友</title><link>https://hongyi.sh/posts/2012-12-05-timeasfriend/</link><pubDate>Wed, 05 Dec 2012 00:00:00 +0000</pubDate><guid>https://hongyi.sh/posts/2012-12-05-timeasfriend/</guid><description>&lt;p&gt;李笑来的书《把时间当作朋友》，讲的还不错。&lt;/p&gt;
&lt;h2 id="chap-0-困境"&gt;&lt;strong&gt;Chap 0 困境&lt;/strong&gt;&lt;/h2&gt;
&lt;ul&gt;
&lt;li&gt;
&lt;p&gt;我们总是因纷繁的外物所打扰，以至于在deadline前惊呼“没时间了！”。人是“既勤奋又懒惰”的，我们应该管理的不是时间，而是自己&lt;/p&gt;
&lt;/li&gt;
&lt;li&gt;
&lt;p&gt;要经过自己认真思考获得知识。&lt;/p&gt;
&lt;/li&gt;
&lt;/ul&gt;
&lt;blockquote&gt;
&lt;p&gt;人们很难接受与已有知识与经验想做的信息或观念，因为既有的知识与观念都是经过持有者反复筛选的。&lt;/p&gt;
&lt;/blockquote&gt;
&lt;ul&gt;
&lt;li&gt;“一切都靠积累”&lt;/li&gt;
&lt;/ul&gt;
&lt;h2 id="chap-1-醒悟"&gt;&lt;strong&gt;Chap 1 醒悟&lt;/strong&gt;&lt;/h2&gt;
&lt;h2 id="chap-2-现实"&gt;&lt;strong&gt;Chap 2 现实&lt;/strong&gt;&lt;/h2&gt;
&lt;ul&gt;
&lt;li&gt;
&lt;p&gt;忍受一定程度的未知。有问题解决不了的时候，先记下来，而后继续前行。&lt;br&gt;
&amp;ldquo;foo&amp;rdquo;、&amp;ldquo;bar&amp;rdquo; 什么意思&lt;/p&gt;
&lt;/li&gt;
&lt;li&gt;
&lt;p&gt;心怀“梦想”的时间越长，它的沉没成本越高。最终，很多人都在无意之间被自己的“梦想”所绑架。&lt;/p&gt;
&lt;/li&gt;
&lt;li&gt;
&lt;p&gt;接受现实，用正确的方法做正确的事情。&lt;/p&gt;
&lt;/li&gt;
&lt;li&gt;
&lt;p&gt;承认资源稀缺。时常把自己的一些年头记录下来，然后与这几条显示对照，看看它们是否与这些现实相符。&lt;/p&gt;
&lt;/li&gt;
&lt;/ul&gt;
&lt;h2 id="chap-3-任务管理"&gt;&lt;strong&gt;Chap 3 任务管理&lt;/strong&gt;&lt;/h2&gt;
&lt;ul&gt;
&lt;li&gt;估算时间。在任务中遇到“意外”，从而开始新的征程。所以需要&lt;strong&gt;分辨任务的属性——它是熟悉的还是陌生的&lt;/strong&gt;
&lt;ul&gt;
&lt;li&gt;熟悉的则像WBS(Work Breakdown System)一样，细分为小步骤，注意关键点，考虑如何完美完成任务。&lt;/li&gt;
&lt;li&gt;陌生的，平静看待遇到的“意外”，尝试一次。&lt;/li&gt;
&lt;/ul&gt;
&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;我们必须处理未知，而从陌生到熟悉，需要花费时间去学习，不可逾越。如&lt;a href="http://norvig.com/21-days.html"&gt;《Teach yourself Programming in Ten Years》&lt;/a&gt;&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;
&lt;p&gt;任何领域的卓越成就都必须用一生的努力才能取得；稍微低一点的代价都是换不到的。“&lt;a href="http://en.wikipedia.org/wiki/Outliers_(book)"&gt;10000小时&lt;/a&gt;”理论&lt;/p&gt;
&lt;/li&gt;
&lt;li&gt;
&lt;p&gt;及时行动：**现在就开始！！！**迟迟不开始的最本质原因在于恐惧。&lt;/p&gt;
&lt;/li&gt;
&lt;li&gt;
&lt;p&gt;直面困难，很多人只是&lt;/p&gt;
&lt;/li&gt;
&lt;/ul&gt;
&lt;blockquote&gt;
&lt;p&gt;做出了努力的样子，或者显得比较努力而已。
因为他们回避困难。任何任务都可以被划分为相对简单的部分和相对困难的部分。我自己的看法：Eat the frog first.先做最困难的部分。&lt;/p&gt;
&lt;/blockquote&gt;
&lt;ul&gt;
&lt;li&gt;
&lt;p&gt;人做事的动机来自于：&lt;strong&gt;奖励与惩罚&lt;/strong&gt;。很多人实际上不知道自己所谓的“喜欢做某件事”实际上更可能只不过因为那件事相对简单、容易获得奖励而已。&lt;/p&gt;
&lt;/li&gt;
&lt;li&gt;
&lt;p&gt;关注步骤：把任务拆分成一个个细小的捕捉，越细越好，每个小任务都能独立完成。核心是&lt;strong&gt;具体化&lt;/strong&gt;和&lt;strong&gt;细分拆解&lt;/strong&gt;，并在此过程中反复询问为什么要这么做。&lt;/p&gt;
&lt;/li&gt;
&lt;li&gt;
&lt;p&gt;时间片方法：25min工作 + 5min休息。pomotodo番茄法。关键就是&lt;strong&gt;拆分任务&lt;/strong&gt;&lt;/p&gt;
&lt;/li&gt;
&lt;li&gt;
&lt;p&gt;感知时间：相信我，你并不孤独。&lt;a href="http://book.douban.com/subject/1115353/"&gt;《奇特的一生》&lt;/a&gt;柳比歇夫的“是件-时间日志”(Event-time Log),记录事件，和该事件所花费的时间。这样遇到不好的结果的时候，更容易找到缘由&lt;/p&gt;
&lt;/li&gt;
&lt;li&gt;
&lt;p&gt;再此基础上，制作预算。这个任务的完成是否对目标达成确实有益&lt;/p&gt;
&lt;/li&gt;
&lt;li&gt;
&lt;p&gt;计划，&lt;strong&gt;可行&lt;/strong&gt;&lt;/p&gt;
&lt;/li&gt;
&lt;li&gt;
&lt;p&gt;列表。纸和笔，要随手可及。&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;最重要的任务永远只有一个。&lt;/li&gt;
&lt;li&gt;有新鲜主意的时候，专门记载一个下一阶段任务列表中，然后专注于当前该完成的任务上。&lt;/li&gt;
&lt;li&gt;列表一旦开始执行就一定要执行到底。&lt;/li&gt;
&lt;/ul&gt;
&lt;/li&gt;
&lt;li&gt;
&lt;p&gt;将要做的事情的整个过程在脑子里语言一遍甚至多遍（&lt;em&gt;尤其是重要的！&lt;/em&gt;）&lt;/p&gt;
&lt;/li&gt;
&lt;li&gt;
&lt;p&gt;验收：做事之前，拿出纸笔记录下每一个预定的验收标准。&lt;/p&gt;
&lt;/li&gt;
&lt;/ul&gt;
&lt;h2 id="chap-4-学习"&gt;&lt;strong&gt;Chap 4 学习&lt;/strong&gt;&lt;/h2&gt;
&lt;ul&gt;
&lt;li&gt;
&lt;p&gt;获取知识最为起初的手段就是“体验”，更高级的就是“试错”(Trial and Error)。而“阅读”，是一种非常有效的体验。&lt;/p&gt;
&lt;/li&gt;
&lt;li&gt;
&lt;p&gt;哥白尼 “很多时候，人们的善良出自于软弱，而他们的残暴出只不过来自于恐惧。”&lt;/p&gt;
&lt;/li&gt;
&lt;li&gt;
&lt;p&gt;自学能力的基础技能是阅读理解能力，检索能力是建立在相当熟练的阅读能力基础上的能力。&lt;/p&gt;
&lt;/li&gt;
&lt;li&gt;
&lt;p&gt;**写作能力在自学能力中占据着重要的地位：**写出写出简捷、有效、朴素、准确、具体的说明性说理性文章的能力。&lt;/p&gt;
&lt;/li&gt;
&lt;li&gt;
&lt;p&gt;实践能力是自学能力最终能够转化为真正价值的根本。&lt;/p&gt;
&lt;/li&gt;
&lt;/ul&gt;
&lt;h2 id="chap-5-思考"&gt;&lt;strong&gt;Chap 5 思考&lt;/strong&gt;&lt;/h2&gt;
&lt;ul&gt;
&lt;li&gt;
&lt;p&gt;独立思考：当别人告诉你一个结论的时候，你自己动脑重新推演一遍得到结论的过程，看看有没有漏洞，有没有不合理的地方，衡量一下那结论到底有多少道理。&lt;/p&gt;</description></item></channel></rss>