重点摘记了Part I的一些tips，顺带推荐一些blog

1 Chapter 2

    The less you interact with your computer, the faster you can go.
    luanching applications more quickly
    finding files faster
    using the mouse less.
    Concentrate on essence, not ceremony.
    The usefulness of an application list is inversely proportional to its length.
    Eye candy looks good but isn't nutritious.
    Typing is faster than navigation.
    Prefer typing over mousing.
    The address bar is the most efficient Windows Explorer interface.
    Clipboarding in batches is faster than clipboarding serially.
    Those who remember their history aren't doomed to type it again.
    Embedded command prompts give you access to the best of both worlds.
    Embed the command prompt with Explorer to make it easier to switch contexts.
    Programming(except for user interface design) is a text-based activity, so you should strive to keep your hands on the keyboard as much as ppossible.
    When coding, always prefer the keyboard to the mouse.
    Learn IDE keyboard shortcuts in context, not by reading long lists.
    When you type a complicated construct for the second time, templatize it.
    The more times you perform a particular operation on a chunck of text, the greater the likelihood you'll do it again.
    Don't type the same commands over and over again.
    Spend a little time each day to make every day more productive.

2 Chapter 3

    Kill Distractions: you are a knowledge worker, meaning you are paid for the creative and innovative ideas you produce. Dealing with constant distractions, both at your desk and on your desktop, can threaten your best contributions to your projects. Developers crave a state known as flow, discussed in lots of places(it even has an entire book devoted to it, written by Csikszentmihalyi). All developers know this state: it's when you are so focused that time disappears, you develop an almost symbiotic relationship with the machine and the problem you are attacking. This is the state you've been in when you say, "Wow, have four hours passed? I didn't even notice." The problem with flow is that it is fragile. One distraction pulls you out, and it takes effort to get back in. It also suffers from inertia. Late in the day, you have to fight harder to get back to that state, and the more times you are abruptly pulled out, the harder it becomes. Distractions kill your focus on the problem at hand, making you less productive. Fortunately, you can effectively block distractions in a few simple ways.
    The higher the level of concentration, the denser the ideas.
    How many of the emails you receive in the course of a day really require an immediate response?
    The bigger the haystack, the harder it is to find the needle.
    Replace file hierarchies with search.
    Try simple searching before resorting to "hard target" searching.
    Use links to create virtual project management folders.

3 Chapter 4

    wget –mirror –html-extension –convert-links -P dir
    curl -d "birthday=1905&press=%200K%20 www.hotmail.com/when/junk.cgi
    ant and gant
    rake
    selenium
    I have encountered some system administrators who write bash scripts for every task they perform. They do this for two reasons. First, if you do it once, you're almost certainly going to do it again. Bash commands are very terse by desigin, and it sometimes takes a few minutes even for an experienced developer to get it right. But if you ever have to do that task again, the saved commands save your time. Second, keeping all nontrivial command-line stuff around in scripts creates living documentation of what you did, and perhaps why you performed some task. Saving everything you do is extreme, but storage if very cheap–much cheaper than the time it takes to recreate something.
    Justifying automation is about return on investment and risk mitigation.
    Timebox speculative development.

4 Chapter 5

    Always keep the entire universe required to build your software in version control(minus the operating system, and even that is possible with virtualization)
    Keep a single copy of everything you don't build in version control.
    Use a Canonical Build Machine
    The other process required in every development shop is continuous integration. Continuous integration is a process where you build the entire project, run tests, generate documentation, and do all the other activities that make software on a regular basis(the more often the better, generally you should build everytime you check in code to version control). Continuous integration is supported by software of the same name. Ideally, the coninuous integration server runs on a separate machine, monitoring your check-ins to version control. Every time you perform a code check-in, the continuous integration server springs to life, running a build performing a full build, setting up the database for testing, running the entire suite of unit tests, running code analysis, and deploying the application to perform a "smoke test.". The continuous integration server redirects build responsibilities from individual machines and creates a canonical build location.
    The canonical build machine should not include the development tool you use to create the project, only the libraries and other frameworks needed to build the application. This prevents subtle dependencies on tools from creeping into your build process.
    No matter what you are copying and pasting, reuse by copy and paste is evil
    Always keep code and schemas in sync.
    Use migrations to create repeatable snapshots of schema changes.
    Out-of -date documentation is worse than none because it is actively misleading.
    For managers, documentation is about risk mitigation.
    Always keep "living" documentation.
    Anything that takes real effort to create makes its creator irrationally attached to it.
    Generate all the technical documents you can.
    Never keep two copies of the same thing(like code and diagram describing it).
    SchemaSpy
    Repetition is the single most diminishing force in software development.

5 Chapter 14

    If Java had included a foreach keyword from the outset, no one would have cared about the index number of arrays. Of course, Java finally did get a foreach operator(called, confusingly enough, for, just like the other one), and it took only eight years.
    Java includes a depressingly large number of strange quirks and idioms, some anew from the Java creators, some existing as baggage from a previous life. All languages are like that, to varying degrees. Is there a way to escape this madness?

6 Chapter 15

    Find your perfect editor and learn it inside and out.
    Don't make round trips when you can batch.

一些有用的blog：
pluskid: http://lifegoo.pluskid.org/wiki/index.html
4G space: http://blog.youxu.info/2011/01/24/keyboard-only-thoughts-one-year-later/

我自己也在写，不过写的有点慢，最近正在学习APUE等大部头，学习下底层原理后再来完善：
http://cnlox.is-programmer.com/posts/31971.html