今天参加了传说中的IBM笔试，呵呵，以前在网上看人家说时间多紧多紧的，没什么体会，这次体会了一下——真的很紧！！！这次的非技术笔试有三部分（跟网上介绍的一样，没变），都智力题一类的。分别是13m、4m、15m，每部分都是10题。除了第二部分在思考下做完了，其他两部分都不怎么样，剩了好多，ft。40分钟下来，很累，加上天气还有点热，搞得跟跑了个400米似的。这次笔试，感觉最主要的问题还是英语，阅读速度跟不上，所以理解题意上花的时间比较多，以后还要加强加强啊~

    听前一天笔的说只有一场，结果我们今天是两场。。。第二场是技术类的题，这个还好，1一个小时48题，也是全英文的。这个好在都是熟悉的东西，英文也熟点。不过郁闷的是，还没从第一场的节奏中缓过来。。做快了，还差三题的时候看表还剩二十分钟，ft。结果做完了又回过来检查。IBM的技术题出的面比较广，我做的是Java，其中一半是基础问题，一半涉及都是具体技术的，不知道就没办法了。

    总体感觉这种大企业的笔试还是相当不错的，题就是那些题，但是卡时间，所以还是能有一定区分度的。感觉不错，呵呵，有机会再去看看其他的。

一篇Sun官方网站上介绍JConsole使用的文章，前段时间性能测试的时候大概翻译了一下以便学习，今天整理一下发上来，有些地方也不知道怎么翻，就保留了原文，可能还好理解点，呵呵，水平有限，翻的不好，大家多多包涵。

JConsole毕竟是JDK自带的东西，功能虽然没有一些商业软件那么强大，但是稳定性好，在大压力情况下也不会发生什么问题。而且，提供了相对全面的系统监控功能，还是值得一用的。

 

JConsole

JConsole是一个基于JMX的GUI工具，用于连接正在运行的JVM，不过此JVM需要使用可管理的模式启动。如果要把一个应用以可管理的形式启动，可以在启动是设置com.sun.management.jmxremote。例如，启动一个可以在本地监控的J2SE的应用Java2Demo ，需输入以下命令：

   JDK_HOME/bin/java -Dcom.sun.management.jmxremote -jar JDK_HOME/demo/jfc/Java2D/Java2Demo.jar

JDK_HOME需要是一个含有JDK5.0的目录。

要启动JConsole，运行
   JDK_HOME/bin/jconsole

一个用于连接的对话框将会打开。对话框的Local标签列出了所有本地正在运行的JVM，还包含进程的ID等信息。

Figure 2: Local Tab.

JConsole可以以三种方式连接正在运行的JVM：

• Local：使用JConsole连接一个正在本地系统运行的JVM，并且执行程序的和运行JConsole的需要是同一个用户。JConsole使用文件系统的授权通过RMI连接器连接到平台的MBean服务器上。这种从本地连接的监控能力只有Sun的JDK具有
• Remote：使用下面的URL通过RMI连接器连接到一个JMX代理：

             service:jmx:rmi:///jndi/rmi://hostName:portNum/jmxrmi

        hostName填入主机名称，portNum为JMX代理启动时指定的端口。JConsole为建立连接，需要在环境变量中设置mx.remote.credentials来指定用户名和密码从而进行授权。


• Advanced:使用一个特殊的URL连接JMX代理。一般情况使用自己定制的连接器而不是RMI提供的连接器来连接JMX代理，或者是一个使用JDK1.4的实现了JMX和JMX Rmote的应用。

当JConsole成功建立连接，它从连接上的JMX代理处获取信息，并且以下面几个标签页呈现信息。

• Summary tab. 监控JVM和一些监控变量的信息。
• Memory tab. 内存使用信息
• Threads tab. 线程使用信息
• Classes tab. 类调用信息
• VM tab. JVM的信息
• MBeans tab.所有MBeans的信息

MBeans tab展示了所有以一般形式注册到JVM上的MBeans。MBeans tab允许你获取所有的平台信息，包括那些不能从其他标签页获取到的信息。注意，其他标签页上的一些信息也在MBeans这里显示。另外，你可以使用 MBeans标签管理你自己的应用的MBeans

 

使用MBeans Tab监控和管理MBean

注册到JMX代理的平台或者应用的MBeans，可以通过MBeans标签获取。例如,内存的MBeans如下面定义

	public interface MemoryMXBean {
	    public MemoryUsage getHeapMemoryUsage();
	    public MemoryUsage getNonHeapMemoryUsage();
	    public int         getObjectPendingFinalizationCount();
	    public boolean     isVerbose();
	    public void        setVerbose(boolean value);
	    public void        gc();
	}

内存的MBean包括四个属性：

• HeapMemoryUsage. 用于描述当前堆内存使用情况的只读属性
• NonHeapMemoryUsage. 用于描述当前的非堆内存的使用情况的只读属性
• ObjectPendingFinalizationCount.用于描述有多少对象被挂起以便回收。
• Verbose.用于动态设置GC是否跟着详细的堆栈信息，为一个布尔变量

内存的MBean支持一个操作——GC，此操作可以发送进行实时的垃圾回收请求。

Figure 3: MBeans Tab.

左边的树形结构以名字的方式展示了所有MBeans的列表。一个MBean对象的名字由一个域的名字和一串关键字属性组成。例如，JVM的平台的MBeans是在“java.lang”域下的一组，而日志的MBeans则在"java.util.logging"域下。MBean对象的名字在javax.management.ObjectName 规范中定义。

当你在树中选中一个MBean，属性，方法，或者通知等一些信息会再右边显示出来。如果属性是可写的（属性被标志为蓝色），你可以进行设置。你可以操作在Operations tab中列出的操作。你也可以看到由MBean发送出来的通知：默认情况，如果你不订阅通知的话，JConsole不会收到MBean发生过来的通知。你可以点击"Subscribe"(订阅)按钮来堆通知进行定义，而使用"Unsubscribe"按钮来取消订阅

Figure 4: MBeans Notification.

 

监控内存

内存标签页通过读取内存系统、内存池、垃圾回收的MBean来获取对内存消耗、内存池、垃圾回收的情况的统计。
图：

上图展示了内存随时间变化的使用情况。有对堆的、非堆的以及特殊内存池的统计。内存池信息是否能被获取，取决与使用的Java虚拟机。下面列表展示了HotSpot虚拟机的内存池情况。

Eden Space (heap)： 内存最初从这个线程池分配给大部分对象。
Survivor Space (heap)：用于保存在eden space内存池中经过垃圾回收后没有被回收的对象。
Tenured Generation (heap)：用于保持已经在 survivor space内存池中存在了一段时间的对象。
Permanent Generation (non-heap): 保存虚拟机自己的静态(refective)数据，例如类（class）和方法（method）对象。Java虚拟机共享这些类数据。这个区域被分割为只读的和只写的，
Code Cache (non-heap):HotSpot Java虚拟机包括一个用于编译和保存本地代码（native code）的内存，叫做“代码缓存区”（code cache）

详细信息区域给出一些当前线程的信息：
Used ：已使用：当前的内存使用量。使用的内存包括所有对象（能被获取和不能被获取的）所占用的内存。

Committed ：分配量：Java虚拟机保证能够获取到的内存量。分配内存（committedmemory）的量可能随时间改变。Java虚拟机可能释放部分这里的内存给系统，相应的分配的内存这时可能少于初始化时分配的给它的量。分配量总数大于或等于已使用的内存量。

Max :内存管理系统可以使用的最大内存量。这个值可以被改变或者不做设定。如果JVM试图增加使用的内存到大于分配量（committedmemory）的情况，内存分配可能失败，即便想使用的内存量小于或者等于最大值（如：系统虚拟内存比较低时）

Usage Threshold The usage threshold of a memory pool. This field will only beshown if the memory pool supports usage threshold.
GC time :垃圾回收使用的总时间和调用垃圾回收的次数。它可能有好几行，每行代表JVM使用的垃圾回收算法。(

右下角的棒状图表显示了被JVM的内存池消耗的内存。如果内存使用超过 usage threshold,则棒会变红。usagethreshold是用于支持内存检查的Memory Pool MBean的一个属性。MemoryPoolMXBean定义了一系列方法用于检查内存。
public interface MemoryPoolMXBean {
....
// Usage threshold
public long    getUsageThreshold();
public void    setUsageThreshold(long threshold);
public boolean isUsageThresholdExceeded();
public boolean isUsageThresholdSupported();
// Collection usage threshold
public long    getCollectionUsageThreshold();
public void    setCollectionUsageThreshold(long threshold);
public boolean isCollectionUsageThresholdSupported();
public boolean isCollectionUsageThresholdExceeded();
}

每种内存池可能有两种内存初始话支持： usage threshold和collection usage threshold特殊的内存池可能两种都不支持。

Usage Threshold

usage threshold是内存池中一个可管理的属性。它使用低负荷的内存监控。设置usage threshold为正值则usage threshold检查内存池。设置usage threshold为零，则关闭检查。默认值由JVM设置。JVM一般让usage threshold在最合适的时候检查内存，典型的在GC的过程中和某些分配内存的时候。如果JVM发现当前的内存使用超过了usage threshold，它将会把UsageThresholdExceeded属性设置为true
有些内存池可能不支持usage threshold。你可以使用UsageThresholdSupported属性来判断一个内存池是否支持usage threshold。例如，一个比较完善（generational garbage collector）的垃圾回收器（如HotSpot的虚拟机），most of the objects are allocated in the young generation，从eden内存池中产生。eden pool被设计成可以被装满；再eden pool中执行垃圾回收将会释放他

Collection Usage Threshold

Collection usage threshold是可进行垃圾回收的内存池的一个可配置属性。JVM堆一个内存池进行垃圾回收以后，此内存池中的一些内存仍然被那些没有被回收的对象占用。collection usage threshold仅允许你在垃圾回收后对内存进行检查。如果JVM发现可用内存超出collection usage threshold，它将会设置CollectionUsageThresholdExceeded属性为true。
你可以使用CollectionUsageThresholdSupported属性来控制内存池释放支持 collection usage threshold.
usage threshold 和collection usage threshold是MBean标签中的一组。例如，在左边的树形结构中选择TenuredGen，设置tenured generation memory pool的usage threshold为6m。如下图所示

Figure 6: Setting Usage Threshold.

当 TenuredGen memory pool的内存使用超过6MBytes时，代表 TenuredGen memory pool的柱状图将会呈现红色来代表使用的内存超过了usage threshold。代表堆内存的柱状图也将变为红色。你可以选择柱状图或者在图表中指定内存池来查看某个指定内存池的信息。如果把鼠标房子柱状图上，将会显示出内存池的名字

Figure 7: Low Memory.

 

开启/关闭虚拟机的详细跟踪

如上所述，内存系统的MBean定义了一个叫做Verbose布尔变量，让你能动态的打开或关闭详细的GC跟踪。详细的GC跟踪，将会在JVM启动时显示。默认的HotSpot的GC详细输出为stdout.

Figure 8: Setting Verbose GC.

 

死锁检查

线程标签页提供关于应用的线程运行信息

Figure 9: Threads Tab.

左下角列出了所以正在运行的线程。如果你在过滤器中输入一个字符，线程列表将仅显示线程名字包含你输入字符的线程。通过点击某个线程，你可以获取这个线程的相关信息。

线程的MBean标签提供了一些Thread标签没有提供有用的操作。

• findMonitorDeadlockedThreads. 如果发生线程死锁，可以通过这个检查出来。操作返回一组死锁的线程ID
• getThreadInfo. 返回线程的信息。包括线程的名称、堆栈信息，导致当前线程阻塞的锁，如果有的话，还返回哪儿线程持有这个锁，和这个线程信息的统计。
• getThreadCpuTime.返回指定线程消耗的CPU时间。

为使用上面这些属性，可以到MBeans标签下，在MBeans树上选择Threading MBean。它列出了当前监控的JVM所有属性的操作。

Figure 10: MBeans Tab Threading.

为检查你的应用是否进入死锁（例如,你的应用挂起），你可以使用findMonitorDeadlockedThreads操作。

Figure 11: Find Deadlocked Threads.

一旦你选择了findMonitorDeadlockedThreads按钮，将会有一个弹出窗口显示结果。在上面例子中，JConsole连接了一个存在3个死锁线程的示例应用SampleTest。如上所示，检查出ID为12，10和11的线程死锁。想查询更多的线程信息，可以使用getThreadInfo操作。线程的MBean支持getThreadInfo操作的四种形式，

• 对一个给定的线程ID，给出最深的堆栈情况
• 堆一系列的线程ID，给出最深的堆栈情况

• Of a given thread ID with no stack trace.
• Of an array of thread IDs with no stack trace.

对应死锁情况，你一般会比较关系堆栈情况。你可以在getThreadInfo操作的第一个参数中输入死锁的线程ID和你想跟踪的堆栈深度。

Figure 12: ThreadInfo for Thread ID = 12.

双击stackTrace属性的值域将会显示一个复合对话框，你可以在堆栈中来回查看。图13，14显示了死锁线程-1的复合对话框中的第一层堆栈和第二层堆栈。

Figure 13: Top Frame of the Stack Trace of DeadlockedThread-1.

Figure 14: Second Frame of the Stack Trace of DeadlockedThread-1.

线程标签页提供了一个友好的界面供查看线程的堆栈。你可以找到死锁线程的名字，使用getThreadInfo 查找线程信息。然后又可以使用线程标签页来分析死锁。

 

控制日志等级

Logging MBean定义了LoggerNames属性，用于描述日志名称。为找到你的应用的日志，可以选择在MBeans树中java.util.logging 下的Logging MBean，双击LoggerNames属性

Figure 15: List of All Logger Names.

Logging MBean也支持三种操作：

• getParentLoggerName. 返回指定logger的父logger
• getLoggerLevel. 返回指定logger的日志等级
• setLoggerLevel.设置指定logger到一个新的等级

所有三个操作都把日志名称作为第一个参数。

Figure 16: Setting Log Level.

 

获取操作系统资源信息-Sun平台下的扩展

JDK5.0扩展了操作系统的MBean，以此可以获取一下系统资源的信息，如：

• 处理的CPU
• 总共的和空闲的物理内存
• 可获得的虚拟内存。（即保证可以分配给运行的进程的虚拟内存）
• 总共的和空闲的交换区
• 打开的文件总数（只能在Unix下使用）

当打开MBeans标签下的Operating System MBean，你可以看到平台可以执行的所有属性和操作。你可以监控任何一个属性随时间的变化——如，CPU时间-双击属性的值域部分。

Figure 17: MBeans Tab OS.

除此之外，VM标签和Summary标签提供了操作系统资源的一些信息

管理应用的MBean
被监控的SampleTest应用有它自己的Hello MBean：

com.sun.example:type=Hello
如果CacheSize 属性发生改变，Hello MBean将会发送一个通知。你可以和管理平台的MBeans一样使用MBeans标签页来管理你的应用的MBean。例如，当CacheSize 属性变化的时候你想监控。你首先可以在
Notification标签页中订阅。如果你改变CacheSize，你可以看到一个通知被发送。

Figure 18: Notifications.

 

相关信息

• Monitoring and Management for the Java Platform
• Monitoring and Management Tools

    JProfiler是一款Java的性能监控工具。可以查看当前应用的对象、对象引用、内存、CPU使用情况、线程、线程运行情况（阻塞、等待等），同时可以查找应用内存使用得热点，即：哪个对象占用的内存比较多；或者CPU热点，即：哪儿方法占用的较大得CPU资源。我使用的是4.3.2版本，以前试用过3**版本，不过那个bug比较多，容易死，4**版本稳定多了。

     有了上面那些信息对于系统的调优会有很大帮助。这里提供有几篇文章供参考：获取、介绍，简单入门，使用JProfiler解决实际问题。这几篇文章基本介绍了常见东西了，下面说点心得。

1. JProfiler监控是要消耗系统资源的，所以一般情况下不要用于性能测试时候的监控。
   
2. 如果要用于相对大压力情况下，可以有选择的打开监控项，不用所有都打开。主要有两个，一个是内存监控，打开的情况下可以查找内存分配热点。一个是CPU监控，打开的情况下可以查看CPU使用热点。
   如图所示，红笔标注部分。如果两个都关闭的话，还是可以跑一定压力的，同时还可以监控对象数量。
   
3. 个人认为最好用的（也是用的最多的）是查询当前的对象的数量。数量监控很重要，如果你使用了单例，那么你只会看到有一个对象存在，如果多了就说明程序有问题了。同样，如果应用进行一系列操作，检查一下该销毁的对象是否还继续存在，如果没有释放，就得考虑是否存在内存溢出了。
   
4. JProfiler还提供了一个比较好的检查内存溢出得工具。他可以查找某个对象的引用情况，即：当你发现某个该释放掉的对象没有释放，就可以看一下哪个实例在引用它，找到了根即找到了溢出点。
   具体操作如下：在 “Memory Views”界面中右键选择你要监控的对象，选择第一项“Take Heap Snapshot for Selection”，选择完成后会进入“Heap Walker”界面，界面下面提供几个功能，选择“References”即可 。如图：
   
   
5. JProfiler提供不同的观察粒度，提供对类的监控、对包的监控、对J2EE组件的监控，同时过滤器也比较好用，直接定位你关注的包或类即可。
   
6. JProfiler的监控可能与应用之间存在一定时间差，所以有些时候需要等待刷新，才能显示正确系统情况。

    昨天暴雪公布他的星际2了，我想这对于很多同时代的人来说都是一个好消息。1998年暴雪出品的星际毫无疑问是一个跨时代的作品。与星际同时代的即时战略游戏到现在都已经没落了，但是唯有星际一枝独秀，而且也有很多人都还在在玩。不可思议啊。同样，暗黑破坏神也是 2000年出的2，现在仍然很多人在玩。对于暴雪，有这样的说法“暴雪出品，必是精品！”。星际2什么时候正式发行不好说，不过我想最有很能明年吧，这样算了刚好十年，可谓“十年磨一剑”啊！

    暴雪的这种精品策略其实很值得我们学习。大到公司，小到个人，各方各面都涉及可以这个问题。目前的社会，物质生活已经发展到一定程度，对于你的某种需求，可能有N种选择来满足，所以，在这种情况下，人们能够记住的往往只是那些精品。

    说道这里，想说下Google。说起Google你能想到什么呢？虽然Google有这么多的服务，但是我能想到的就是一，搜索；二，Gmail；或许还能加上Google Eeath。虽然Google做了很多东西，但是能堪称精品的，我想就只有他的搜索和Gmail，两个东西都已经是好多年以前的了，这点却是有点遗憾。我想以Google财力、技术，更应该去打造一些精品，做一个就能被人们记住一个！

    再说是韩国，说道韩国我们能想起很多。三星、现代、LG，还有韩剧，呵呵。这些东西都是韩国倾整个国家之力打造的精品，想不为人认识都难。想想国内吧，海尔一个算一个国家打造的品牌吧，不过相比韩国我们就差太远了。就连电视剧也是，大街小巷随便这个老太太都是说出几个韩剧的名字来，而国内呢？除了能数出几个被人鄙视的来，其他的我还真不知道。差在哪里？细节啊！！！剧本差一点、编剧差一点、化妆差一点、演员差一点、特技差一点，我们不缺人，但是我们缺精品，什么都差一点，出来的东西就差远了。相反，什么都仔细一点，结果就决然不同!

    再说个人，感觉又跟上一篇扯一块儿了。细节跟效率，我选择细节，很多东西，还是需要时间来沉淀的。我们总瞅着国外技术牛人一把一把的，国内怎么就没什么大牛？其实想想，人家40岁还在写代码，而我们呢？35岁前就得考虑转管理了...不过么，国情不一样，这也没办法。

    说来说去，感觉原因还在整个社会。整个社会都处在一种浮躁，这种情况下，很难出精品啊。或许正处于国家的转变时期吧...

    晕，扯着扯着就远了，呵呵。期待星际2，到时候重新配个机器~~

一篇好文，不能不转啊：）上面的评论也很精彩！

 

你应当如何学习C++(以及编程)

By 刘未鹏(pongba)

C++的罗浮宫(http://blog.csdn.net/pongba)

Javascript是世界上最受误解的语言，其实C++何尝不是。坊间流传的错误的C++学习方法一抓就是一大把。我自己在学习C++的过程中也走了许多弯路，浪费了不少时间。

为什么会存在这么多错误认识？原因主要有三个，一是C++语言的细节太多。二是一些著名的C++书籍总在（不管有意还是无意）暗示语言细节的重要性和有趣。三是现代C++库的开发哲学必须用到一些犄角旮旯的语言细节（但注意，是库设计，不是日常编程）。这些共同塑造了C++社群的整体心态和哲学。

单是第一条还未必能够成气候，其它语言的细节也不少（尽管比起C++起来还是小巫见大巫），就拿javascript来说，作用域规则，名字查找，closure，for/in，这些都是细节，而且其中还有违反直觉的。但许多动态语言的程序员的理念我猜大约是学到哪用到哪罢。但C++就不一样了，学C++之人有一种类似于被暗示的潜在心态，就是一定要先把语言核心基本上吃透了才能下手写出漂亮的程序。这首先就错了。这个意识形成的原因在第二点，C++书籍。市面上的C++书籍不计其数，但有一个共同的缺点，就是讲语言细节的书太多——《C++ gotchas》，《Effective C++》，《More Effective C++》，但无可厚非的是，C++是这样一门语言：要拿它满足现代编程理念的需求，尤其是C++库开发的需求，还必须得关注语言细节，乃至于在C++中利用语言细节已经成了一门学问。比如C++模板在设计之初根本没有想到模板元编程这回事，更没想到C++模板系统是图灵完备的，这也就导致了《Modern C++ Design》和《C++ Template Metaprogramming》的惊世骇俗。这些技术的出现为什么惊世骇俗，打个比方，就好比是一块大家都认为已经熟悉无比，再无秘密可言的土地上，突然某天有人挖到原来地下还蕴藏着最丰富的石油。在这之前的C++虽然也有一些细节，但也还算容易掌握，那可是C++程序员们的happy old times，因为C++的一切都一览无余，everything is figured out。然而《Modern C++ Design》的出世告诉人们，“瞧，还有多少细节你们没有掌握啊。”于是C++程序员们久违的激情被重燃起来，奋不顾身的踏入细节的沼泽中。尤其是，模板编程将C++的细节进一步挖掘到了极致——我们干嘛关心涉及类对象的隐式转换的优先级高低？看看boost::is_base_of就可以知道有多诡异了。但最大的问题还在于，对于这些细节的关注还真有它合适的理由：我们要开发现代模板库，要开发active library，就必须动用模板编程技术，要动用模板编程技术，就必须利用语言的犄角旮旯，enable_if，type_traits，甚至连早就古井无波的C宏也在乱世中重生，看看boost::preprocessor有多诡异就知道了，连C宏的图灵完备性（预编译期的）都被挖掘出来了。为什么要做这些？好玩？标榜？都不是，开发库的实际需求。但这也正是最大的悲哀了。在boost里面因实际需求而动用语言细节最终居然能神奇的完成任务的最好教材就是boost::foreach，这个小设施对语言细节的发掘达到了惊天地泣鬼神的地步，不信你先试着自己去看看它的源代码，再看看作者介绍它的文章吧。而boost::typeof也不甘其后——C++语言里面有太多被“发现”而不是被“发明”的技术。难道最初无意设置这些语言规则的家伙们都是oracles？

因为没有variadic templates，人们用宏加上缺省模板参数来实现类似效果。因为没有concepts，人们用模板加上析构函数的细节来完成类似工作。因为没有typeof，人们用模板元编程和宏加上无尽的细节来实现目标… C++开发者们的DIY精神不可谓不强。

然而，如果仅仅是因为要开发优秀的库，那么涉及这些细节都还是情有可原的，至少在C++09出现并且编译器厂商跟上之前，这些都还能说是不得已而为之。但我们广大的C++程序员呢？大众是容易被误导的，我也曾经是。以为掌握了更多的语言细节就更牛，但实际却是那些语言细节十有八九是平时编程用都用不到的。C++中众多的细节虽然在库设计者手里面有其用武之地，但普通程序员则根本无需过多关注，尤其是没有实际动机的关注。一般性的编码实践准则，以及基本的编程能力和基本功，乃至基本的程序设计理论以及算法设计。才是真正需要花时间掌握的东西。

学习最佳编码实践比学习C++更重要。看优秀的代码也比埋头用差劲的编码方式写垃圾代码要有效。直接、清晰、明了、KISS地表达意图比玩编码花招要重要…

避免去过问任何语言细节，除非必要。这个必要是指在实际编程当中遇到问题，这样就算需要过问细节，也是最省事的，懒惰者原则嘛。一个掌握了基本的编程理念并有较强学习能力的程序员在用一门陌生的语言编程时就算拿着那本语言的圣经从索引翻起也可以编出合格的程序来。十年学会编程不是指对每门语言都得十年，那一辈子才能学几门语言哪，如果按字母顺序学的话一辈子都别指望学到Ruby了；十年学习编程更不是指先把语言特性从粗到细全都吃透才敢下手编程，在实践中提高才是最重要的。

至于这种抠语言细节的哲学为何能在社群里面呈野火燎原之势，就是一个心理学的问题了。想像人们在论坛上讨论问题时，一个对语言把握很细致的人肯定能够得到更多的佩服，而由于论坛上的问题大多是小问题，所以解决实际问题的真正能力并不能得到显现，也就是说，知识型的人能够得到更多佩服，后者便成为动力和仿效的砝码。然而真正的编程能力是与语言细节没关系的，熟练运用一门语言能够帮你最佳表达你的意图，但熟练运用一门语言绝不意味着要把它的边边角角全都记住。懂得一些常识，有了编程的基本直觉，遇到一些细节错误的时候再去查书，是最节省时间的办法。

C++的书，Bjarne的圣经《The C++ Programming Language》是高屋建瓴的。《大规模C++程序设计》是挺务实的。《Accelerated C++》是最佳入门的。《C++ Templates》是仅作参考的。《C++ Template Metaprogramming》是精力过剩者可以玩一玩的，普通程序员碰都别碰的。《ISO.IEC C++ Standard 14882》不是拿来读的。Bjarne最近在做C++的教育，新书是绝对可以期待的。

P.S. 关于如何学习编程，g9的blog上有许多精彩的文章：这里，这里，这里，这里… 实际上，我建议你去把g9老大的blog翻个底朝天 :P

再P.S. 书单？我是遑于给出一个类似《C++初学者必读》这种书单的。C++的书不计其数，被公认的好书也不胜枚举。只不过有些书容易给初学者造成一种错觉，就是“学习C++就应该是这个样子的”。比如有朋友提到的《高质量C/C++编程》，这本书有价值，但不适合初学者，初学者读这样的书容易一叶障目不见泰山。实际上，正确的态度是，细节是必要的。但细节是次要的。其实学习编程我觉得应该最先学习如何用伪码表达思想呢，君不见《Introduction to Algorithm》里面的代码？《TAOCP》中的代码？哦，对了它们是自己建立的语言，但这种仅教学目的的语言的目的就是为了避免让写程序的人一开始就忘了写程序是为了完成功能，以为写程序就是和语言细节作斗争了。Bjarne说程序的正确性最重要，boost的编码标准里面也将正确性列在性能前面。

此外，一旦建立了正确的学习编程的理念，其实什么书（只要不是太垃圾的）都有些用处。都当成参考书，用的时候从目录或索引翻，基本就对了。

再再P.S. myan老大和g9老大都给出了许多精彩的见解。我不得不再加上一个P.S。具体我就不摘录了，如果你读到这里，请务必往下看他们的评论。转载者别忘了转载他们的评论:-)

许多朋友都问我同一个问题，到底要不要学习C++。其实这个问题问得很没有意义。“学C++”和“不学C++”这个二分法是没意义的，为什么？因为这个问题很表面，甚至很浮躁。重要的不是你掌握的语言，而是你掌握的能力，借用myan老大的话，“重要的是这个磨练过程，而不是结果，要的是你粗壮的腿，而不是你身上背的那袋盐巴。”。此外学习C++的意义其实真的是醉翁之意不在酒，像C/C++这种系统级语言，在学习的过程中必须要涉及到一些底层知识，如内存管理、编译连接系统、汇编语言、硬件体系结构等等等等知识（注意，这不包括过分犄角旮旯的语言枝节）。这些东西也就是所谓的内功了（其实最最重要的内功还是长期学习所磨练出来的自学能力）。对此大嘴Joel在《Joel On Software》里面提到的漏洞抽象定律阐述得就非常漂亮。

所以，答案是，让你成为高手的并不是你掌握什么语言，精通C++未必就能让你成为高手，不精通C++也未必就能让你成为低手。我想大家都不会怀疑g9老大如果要抄起C++做一个项目的话会比大多数自认熟练C++的人要做得漂亮。所以关键的不是语言这个表层的东西，而是底下的本质矛盾。当然，不是说那就什么语言都不要学了，按照一种曹操的逻辑，“天下语言，唯imperative与declarative耳”。C++是前者里面最复杂的一种，支持最广泛的编程范式。借用当初数学系入学大会上一个老师的话，“你数学都学了，还有什么不能学的呢？”。学语言是一个途径，如果你把它用来磨练自己，可以。如果你把它用来作为学习系统底层知识的钥匙，可以。如果你把它用来作为学习如何编写优秀的代码，如何组织大型的程序，如何进行抽象设计，可以。如果掉书袋，光啃细节，我认为不可以（除非你必须要用到细节，像boost库的coder们）。

然后再借用一下g9老大的《银弹和我们的职业》中的话：

银弹和我们的职业发展有什么相干？很简单：我们得把时间用于学习解决本质困难。新技术给高手带来方便。菜鸟们却不用指望被新技术拯救。沿用以前的比喻， 一流的摄影师不会因为相机的更新换代而丢掉饭碗，反而可能借助先进技术留下传世佳作。因为摄影的本质困难，还是摄影师的艺术感觉。热门技术也就等于相机。 不停追新，学习这个框架，那个软件，好比成天钻研不同相机的说明书。而热门技术后的来龙去脉，才好比摄影技术。为什么推出这个框架？它解决了什么其它框架 不能解决的问题？它在哪里适用？它在哪里不适用？它用了什么新的设计？它改进了哪些旧的设计？Why is forever. 和 朋友聊天时提到Steve McConnell的《Professional Software Development》里面引了一个调查，说软件开发技术的半衰期20年。也就是说20年后我们现在知识里一半的东西过时。相当不坏。朋友打趣道：“应 该说20年后IT界一半的技术过时，我们学的过时技术远远超过这个比例。具体到某人，很可能5年他就废了”。话虽悲观，但可见选择学习内容的重要性。学习 本质技艺（技术迟早过时，技艺却常用长新）还有一好处，就是不用看着自己心爱的技术受到挑战的时候干嚎。C/C++过时就过时了呗，只要有其它的系统编程 语言。Java倒了就倒了呗，未必我不能用.NET？Ruby昙花一现又如何。如果用得不爽，换到其它动态语言就是了。J2EE被废了又怎样？未必我们就 做不出分布系统了？这里还举了更多的例子。

一句话，只有人是真正的银弹。职业发展的目标，就是把自己变成银弹。那时候，你就不再是人，而是人弹。

最后就以我在Bjarne的众多访谈当中摘录的一些关于如何学习C++（以及编程）的看法结束吧（没空逐段翻译了，只将其中我觉得最重要的几段译了一下，当然，其它也很重要，这些段落是在Bjarne的所有采访稿中摘抄出来的，所以强烈建议都过目一下）：

I suspect that people think too little about what they want to build, too little about what would make it correct, and too much about "efficiency" and following fashions of programming style. The key questions are always: "what do I want to do?" and "how do I know that I have done if?". Strategies for testing enters into my concerns from well before I write the firat line of code, and that despite my view that you have to write code very early - rather than wait until a design is complete.

译：我感觉人们过多关注了所谓“效率”以及跟随编程风格的潮流，却严重忽视了本不该被忽视的问题，如“我究竟想要构建什么样的系统”、“怎样才能使它正确”。最关键的问题永远是：“我究竟想要做什么？”和“如何才能知道我的系统是否已经完成了呢？”就拿我来说吧，我会在编写第一行代码之前就考虑测试方案，而且这还是在我关于应当早于设计完成之前就进行编码的观点的前提之下。

Obviously, C++ is very complex. Obviously, people get lost. However, most peple get lost when they get diverted into becoming language lawyers rather than getting lost when they have a clear idea of what they want to express and simply look at C++ language features to see how to express it. Once you know data absreaction, class hierarchies (object-oriented programming), and parameterization with types (generic programming) in a fairly general way, the C++ language features fall in place.

译：诚然，C++非常复杂。诚然，人们迷失其中了。然而问题是，大多数人不是因为首先对自己想要表达什么有了清晰的认识只不过在去C++语言中搜寻合适的语言特性时迷失的，相反，大多数人是在不觉成为语言律师的路上迷失在细节的丛林中的。事实是，只需对数据抽象、类体系结构（OOP）以及参数化类型（GP）有一个相当一般层面的了解，C++纷繁的语言特性也就清晰起来了。

Well, I don't think I made such a trade-off. I want elegant and efficient code. Sometimes I get it. These dichotomies (between efficiency versus correctness, efficiency versus programmer time, efficiency versus high-level, et cetera.) are bogus.

I think the real problem is that "we" (that is, we software developers) are in a permanent state of emergency, grasping at straws to get our work done. We perform many minor miracles through trial and error, excessive use of brute force, and lots and lots of testing, but--so often--it's not enough.

Software developers have become adept at the difficult art of building reasonably reliable systems out of unreliable parts. The snag is that often we do not know exactly how we did it: a system just "sort of evolved" into something minimally acceptable. Personally, I prefer to know when a system will work, and why it will.

There are more useful systems developed in languages deemed awful than in languages praised for being beautiful--many more. The purpose of a programming language is to help build good systems, where "good" can be defined in many ways. My brief definition is, correct, maintainable, and adequately fast. Aesthetics matter, but first and foremost a language must be useful; it must allow real-world programmers to express real-world ideas succinctly and affordably.

I'm sure that for every programmer that dislikes C++, there is one who likes it. However, a friend of mine went to a conference where the keynote speaker asked the audience to indicate by show of hands, one, how many people disliked C++, and two, how many people had written a C++ program. There were twice as many people in the first group than the second. Expressing dislike of something you don't know is usually known as prejudice. Also, complainers are always louder and more certain than proponents--reasonable people acknowledge flaws. I think I know more about the problems with C++ than just about anyone, but I also know how to avoid them and how to use C++'s strengths.

In any case, I don't think it is true that the programming languages are so difficult to learn. For example, every first-year university biology textbook contains more details and deeper theory than even an expert-level programming-language book. Most applications involve standards, operating systems, libraries, and tools that far exceed modern programming languages in complexity. What is difficult is the appreciation of the underlying techniques and their application to real-world problems. Obviously, most current languages have many parts that are unnecessarily complex, but the degree of those complexities compared to some ideal minimum is often exaggerated.

We need relatively complex language to deal with absolutely complex problems. I note that English is arguably the largest and most complex language in the world (measured in number of words and idioms), but also one of the most successful.

C++ provides a nice, extended case study in the evolutionary approach. C compatibility has been far harder to maintain than I or anyone else expected. Part of the reason is that C has kept evolving, partially guided by people who insist that C++ compatibility is neither necessary nor good for C. Another reason-- probably even more important--is that organizations prefer interfaces that are in the C/C++ subset so that they can support both languages with a single effort. This leads to a constant pressure on users not to use the most powerful C++ features and to myths about why they should be used "carefully," "infrequently," or "by experts only." That, combined with backwards-looking teaching of C++, has led to many failures to reap the potential benefits of C++ as a high-level language with powerful abstraction mechanisms.

The question is how deeply integrated into the application those system dependencies are. I prefer the application to be designed conceptually in isolation from the underlying system, with an explicitly defined interface to "the outer world," and then integrated through a thin layer of interface code.

Had I had a chance to name the style of programming I like best, it would have been "class-oriented programming", but then I'm not particularly good at finding snappy names. The school of thought that I belong to - rooted in Simula and related design philosophies - emphasizes the role of compile-time checking and flexible (static) type systems. Reasoning about the behavior of a program has to be rooted in the (static) structure of the source code. The focus should be on guarantees, invariant, etc. which are closely tied to that static structure. This is the only way I know to effectively deal with correctness. Testing is essential but cannot be systematic and complete without a good internal program structure - simple-minded blackbox testing of any significant system is infeasible because of the exponential explosion of states.

So, I recommend people to think in terms of class invariants, exception handling guarantees, highly structured resource management, etc. I should add that I intensely dislike debugging (as ah hoc and unsystematic) and strongly prefer reasoning about source code and systematic testing.

Pros: flexibility, generality, performance, portability, good tool support, available on more platforms than any competitor except C, access to hardware and system resources, good availability of programmers and designers. Cons: complexity, sub-optimal use caused by poor teaching and myths.

 

自己的一点意见：

       细节跟效率之间确实存在矛盾。不过这种矛盾对个人来说是矛盾，但是如果放到一个企业中来说就不是矛盾了。目前的软件生产，正在趋向于一种社会化大生产的时代，也就是说“一个人”在整个软件开发的过程中的作用越来越小。质量更好的，开发更快的往往是那些协作的更好的软件。同样，那些具备良好文档的，易上手的框架往往会受到企业的青睐，企业的青睐自然也会影响到企业的员工。一个很好的例子就是Struts，因为他的易用，文档齐全而广为流行，企业的青睐而成为一种学习的推动力量。当然，对于一个企业而言，迟早会碰到“细节”问题的，但是一个企业，总有这么一些牛人可以依靠，所以，找对了资源，问题自然能够迎刃而解。对于企业而已，效率是80，而细节是20.

     对个人而言，我觉得细节体现了你的探索精神，而效率体现了你的学习能力。两者缺一不可。而我觉得，更能体现一个人的价值的还是“细节”（这里得看怎么定义这个细节了）。细节代表了一个人对一个领域得认知程度，什么是专家？专家就是对某个领域认识很深得人。而怎样才能体现这个深呢？我觉得就是从细节来体现的。所以，你说博士很牛，牛在哪儿，不是牛在他的知识面，而是牛在他对问题了解的深入程度。编程也是如此，很多问题如果只停留在表明的话永远不可能知道一门语言的真髓，而追求细节往往是一个从量变到质变的不可缺少的过程。

     在这样一个社会化大生产的背景下，更体现一个人的价值的，我想应该更是这些细节。而效率只是对企业而言的，如果个人也只追求效率而不追求细节的话，那么永远都是一颗可被替换掉的螺丝钉。

     从上面看，个人更倾向于“细节”，或许刚好跟文章想说的东西相反了。再读文章，我想文章想说的应该是不应该追求那些抛开本质细节。

  Foxit

     相当好用。最明显的就是速度很快，而且支持在原PDF的基础上做标记（如：下划线，加亮，注释等），可以用来做笔记。

    Java的编码问题挺烦的，以前总弄不清除，现在理了一下算是清晰一点。做个总结吧～

1. 编码问题的由来
    这个问题网上资料很多的，这里不多说了，推荐几篇吧。Java编码问题详解，计算机编码大全，转:谈谈Unicode编码，简要解释UCS、UTF、BMP、BOM等名词。说的还是比较清楚了。下面主要用程序说说。
   
2. String是什么？
   以前一直不清楚Java编码转来转去转的是啥。原来是因为不知道String是啥。在Java里，一个String就是一串Unicode编码的字符串。也就是说，Java在整个处理过程中，字符都是以Unicode编码的。具体使用的是UTF-16也就是双字节的Unicode编码。这就解释了Java中为啥有个16bit的char类型。String就是由一个个char组成的。一个char中存的就是一个对应字符的Unicode编码。
   所以，Unicode在Java中成为一种“中间码”，因为他覆盖了基本上所有的字符。而其他编码的转换都可以通过他来完成。
   PS:话说回来，用双字节的话还是无法覆盖整个字符集的（因为有UTF-32），所以以前曾怀疑过char是否真是用来放Unicode字符的，只有16的话以后扩展怎么办？现在确定了，扩展问题目前不用考虑。。。
   
3. 转什么？怎么转？
   这里再说一个东西——byte。为啥说它？因为所有的转来转去都是在转它。为啥转它？因为他是字符编码的最小单位。一个byte 是8bit，所有编码方式都是由整数个byte组成的。所以，同一个String的不同编码方式可以理解为同一个字符的不同byte数组表示而已。所以，自然而然我们就可以看到这样的代码了：
       String S = "测试"
       s.getBytes("utf8");
       s.getBytes("GB2312");
       s.getBytes("GBK");
       通过这种方式就可以获得任何编码的byte数组。所以，在知道了一个byte[]数组，和它的编码方式的情况下，我们就能获得对应的String，所以有了下面的代码：
       byte[] b = *****;
       String s = new String(b, "utf8");
       s = new String(b, "gb2312");
   通过上面可以看出，从String可以获得任何编码的byte数组，但是从byte数组到String就要小心了，必须知道对应的编码方式才能进行。可以这么说，byte数组告诉了我们这个字符的内容，而编码方式告诉了我们如何去读这个byte数组才能获得我们需要的信息。
   
4. 什么时候转？
       一句话——有IO的时候。编码问题主要出现在文件读取，网络传输等，可以说只要有信息传递的地方都存在这个问题。而在Java中，所有信息的获取（发送）已经被抽象为“流”的概念，所以，这就解释了为什么Java的IO中又加入了Reader和Writer。就是为了能让上层直接面对你所需要的信息，即：字符（char）；同时，提供统一的接口解决编码问题——想想看如果以上面String的形式来解决编码问题将会是一件多么可怕的事情～
   一个sample：
   public String dataReader(byte[] bytes, String charset) throws Exception {
        Reader reader = new InputStreamReader(new ByteArrayInputStream(bytes), charset);
        int c;
        String result = ""
        while( (c = reader.read()) != -1) {
           result += (char)c;
        }
        reader.close();
        return result;
   }
   
   public byte[] dateWriter(String value, String charset) throws Exception {
       ByteArrayOutputStream out = new ByteArrayOutputStream(1024);
       Writer writer = new OutputStreamWriter(out, charset);
       char[] chars = value.toCharArray();
       for (int i = 0; i < chars.length; i++) {
            char c = chars[i];
            writer.write(c);
       }
       writer.flush();
       writer.close();
       return out.toByteArray();
   }
   上面sample与前面的从String获取byte数组和从byte数组生成String功能是一样的。流的实现虽然复杂，但是因为流抽象，所以可以很容易的替换为其他数据来源（如文件，网络等），而不用更改相关的处理代码。
   
5. 为什么是“？”号
   编码转换出问题时，最常见的是一个“？”。原因是当出现Java不认识的编码时（即UTF-16不能编码），则对应为一个“\ufffd”，对应“？”号。此时再转换为其他部分编码时，则为“3F”。
   
6. 神奇的“ISO-8859-1”
   其实并不神奇，只是有点特殊而已。此编码只针对单字节（一个byte）进行编码，所以编码具有还原性。即不论何种编码的byte数组，使用此编码编码后，再使用此编码解码，可以还原到原来的byte数组。这是其他编码方式所不具备的。
   

呵呵，一点看法，欢迎大家讨论。

    五一gf来北京，我们一起去的欢乐谷。人很多，但是总体感觉还是不错的，下次有机会还要去玩玩。以前没去过这类的主题公园，所以这次感觉很好。欢乐谷融合了自然景观，人文表演，大型娱乐以及很多小型的游戏，所以即便没有玩上大型项目，赏赏风景，看看表演都还是不错的。

   我们早晨10点半到的，晚上九点半离开的，玩了4个大项目，看了两场表演，在高空赏了三次风景，呵呵，还是对得起那160的票了。贴照片吧，哈哈。

雪域金翅 

    就是过山车了，欢乐谷有3、4种过山车，这种算是比较狠的了。我们第一个玩的项目，排一个多小时的队，最后1分钟玩完。很刺激的，不过从某种程度上说就是自虐，第二天我两个肩头疼死了。

 

天地双雄 

    这个相当的爽！！！体验自由落体的感觉。62米高的塔，四五秒钟就到下面了。左边的是慢速上升快速下落的，右边那个是快速上升、快速下落的。下回有机会试试右边的。哈哈

 

特洛伊木马

    这个也是相当爽。可以体验一下面向地面，自由下落的感觉。就是我胆子比较小，手不敢放开，哈哈。

 

聚能飞船

 

    左边那个就是。这个人比较少，我们来回坐了3次，前两次拍照，后一次观景，呵呵。

 

欢乐谷远景

   呵呵，还不错吧。聚能飞船上拍的。

 

激流勇进

 

    这个很爽，但是人也很多。下午去的时候要排4个小时！！！！居然还有人在排。。。。赶下次吧。这玩意激起的大浪居然也成为一道风景线，呵呵，有意思。

 

夜景

  晚上还是很漂亮的。 

 

总结一下

    呵呵，说几点游经吧。

1.    网上说欢乐谷9点半开门，可是这次去了才知道，8点半就开了，我们整整晚了两个小时，有点亏。要多两小时还能多玩两项目。
2.    那些大项目还是很爽的，没有体验过可以尝试一下，很多看着怕，上去了其实也没啥。就这么一两分钟的事情。强烈推荐天地双向，特洛伊木马
3.    园子还是很大的，所以去的早可以往里走，先玩里面的项目，下午点再到离门口近的玩，那时人很少的。我们下午的项目排队基本没有超过一个小时的。
4.    欢乐谷的表演还是不错的，累的话可以找个表演看看，同时还能休息。
5.    夜景也不错的，千万多玩会儿，哈哈。过山车天黑了也开的哦～～
6.    里面的水居贵，所以还是多点水吧。吃的可以少带，每次少吃点，玩项目前一个小时最好别吃。我做特洛伊的时候差点没吐了。
7.    注意看看公园的电子告示排，会实时公布每个项目的排队时间的，呵呵，挑点时间少的排吧。