因为电池的问题，决定买一部新手机，在Nokia 6300和Moto U9之间比较了以下，最后还是决定买Nokia 6300. 一是因为操作比较熟悉，二是外形我也比较喜欢，其实主要是被他的广告所蛊惑。

别了，我的6030；别了，毕业后买的第一部手机；别了，陪伴我四年的6030；别了，贴满无数贴纸，传递无尽爱语的对讲机。

实际上，在软件设计中有这样一条准则：

You ain't gonna need it

对于这些你可能用到的功能，如果不是用例的必须，另可不要。所以，坚持适可而止的设计，让你的类和项目尽量的保持苗条，这样，省时又省力。同样的，还有KISS原则。

"You aren't gonna need it" (or YAGNI for short) is the principle in extreme programming that programmers should not add functionality until it is necessary.^[1] Ron Jeffries writes, "Always implement things when you actually need them, never when you just foresee that you need them."^[2]

[edit] Rationale

According to those who advocate the YAGNI approach, the temptation to write code that is not necessary at the moment, but might be in the future, has the following disadvantages:

• The time spent is taken from adding, testing or improving necessary functionality.
• The new features must be debugged, documented, and supported.
• Any new feature imposes constraints on what can be done in the future, so an unnecessary feature now may prevent implementing a necessary feature later.
• Until the feature is actually needed, it is difficult to fully define what it should do and to test it. If the new feature is not properly defined and tested, it may not work right, even if it eventually is needed.
• It leads to code bloat; the software becomes larger and more complicated.
• Unless there are specifications and some kind of revision control, the feature may not be known to programmers who could make use of it.
• Adding the new feature may suggest other new features. If these new features are implemented as well, this may result in a snowball effect towards creeping featurism.

[edit] Balancing concerns

Judging to omit a feature due to the YAGNI viewpoint should be balanced against other concerns, such as benefits of refactoring code, anticipating upcoming features, team expectations (or fears), availability of part-time expert assistance, and providing for completeness of functionality.

Note that the concept of avoiding unnecessary work with the YAGNI principle must be tempered against the potential need for refactoring software modules to make them simpler or faster in the future. If a software module, or an entire software product, represents a dead-end effort at the time, then any further modifications (such as refactoring) can be viewed as YAGNI issues. However, this concern is somewhat obviated by the effects of YAGNI itself - that is, it is always easier to refactor simpler code.

Another restriction is the potential for enhanced features for the customer. A feature which might seem unnecessary, at an early point, might become part of a vital future enhancement adding value to the product. Such judgments, assessing current and future features, should probably involve discussions with multiple people to help determine a "yes" or "no" decision about implementing such features. Of course, YAGNI only applies to features that are known not to be needed.

Also affecting the decision is the impact of fear or confusion for the people involved with a new feature. An individual or team working on a new enhancement might face disappointment if the new work is denied, or demanded, against their personal expectations, either excited about the new work, or dreading the anticipated workload, associated with a particular feature. This concern should obviously be handled well prior to YAGNI principles being applied.

Yet another conflicting factor is the access to expert assistance, which might be limited. For example, experts might be available to design features X, Y, or Z, and also recommend another, but currently unneeded, feature W. A judgment call is needed to determine whether such expert design of an unneeded feature should be encouraged, while the expert is available, to support potential product enhancement in the future, where enhancements would be implemented by junior personnel after the expert has left. Perhaps a bigger concern stems from depending on outside expert assistance at all.

A logical conflicting factor is the notion of completeness, which tends to define missing options, or facets, mostly likely to be needed: for example, among features which allow adding items, deleting items, or modifying items, completeness could be used to also recommend "renaming items". The critical impact of completeness can be seen in some types of wiki-collaboration software which can add or delete image-files, but not rename images. Of course, YAGNI, by definition, would not apply to features that are needed to "complete" the project.

In general, the YAGNI viewpoint must be balanced against the other concerns, such as those of refactoring, upcoming vital features, team expectations, part-time expert assistance, and logical completeness.

A long time ago, it became fashionable, even recommended, to disable menu items when they could not be used.

Don't do this. Users see the disabled menu item that they want to click on, and are left entirely without a clue of what they are supposed to do to get the menu item to work.

Instead, leave the menu item enabled. If there's some reason you can't complete the action, the menu item can display a message telling the user why.

恩，看完之后，表示赞同！

告诉用户原因会有较好的可用性：因为我知道了为什么这个菜单不可以用，总比让我去猜测好。

从第一堂C语言课上的那个printf开始，格式化字符串就成了我的梦魇。此后我还在很多地方遇到过它们：fprintf，sscanf以及 CString的Format成员函数……。除了能记住%s（String的缩写）代表字符串，%d（Decimal的缩写）代表整数之外，每次用到格式 化字符串的地方我都要求助于MSDN。
    直到我看到C++的字符串格式化方式后，我决定从此抛弃C的那套格式化字符串的方法。
    在C++里格式化字符串，用到的最多的类是：ostringstream以及它的宽字符版本wostringstream。

    话不多说，如果要将一个整数n格式化成字符串以便输出之用
    CString的方式是这样的：


 CString str;
 str.Format(_T("%d"), n); 
    ostringstream的方式： 


ostringstream ost;
ost<<n;
string str = ost.str();
    抛开效率不谈，起码不用再去记%d代表整数，%f代表浮点数，当然还有更复杂的格式控制输出的那些%（此处省略200字……）。
    稍微复杂一点，如果要将整数以16进制的格式输出（这个恐怕是整数输出中最常用的功能了）


ostringstream ost;
ost<<hex<<showbase<<255;
    如果以16进制大写的格式输出：


ostringstream ost;
ost<<hex<<showbase<<uppercase<<255;
    可有时候希望以32位整数的方式来输出的时候，在前面通常要补上多个0，这时可以这样做：


ostringstream ost;
// 也许有更好的写法
ost<<"0X"<<hex<<uppercase<<setw(8)<<setfill(''0'')<<255;
    比起格式化字符串来输入的字母更多，但我觉得这种以人话写出来的方式比较好记:)

    对于浮点数，最长用的格式化功能莫过于在小数点后保留X位的做法。
    比如在小数点后保留6位：


ostringstream ost;
// 将输出1234.567800
ost<<fixed<<setprecision(6)<<1234.5678;
    保留3位


// 将输出1234.568，已经替我们做好了四舍五入
ost<<fixed<<setprecision(3)<<1234.5678;
    实现机制
    C++使用一种称为操控符的技术来控制格式化的输出。

    经典的Hello World的C++版本大概是这样的：   


std::cout<<"Hello World"<<endl;    这将在标准输出上输出Hello World后附带一个换行，并且刷新cout流。一个简单的endl包含了模板和运算符重载两个C++中极有分量的技术。

    对endl的输出将引发下面这个重载了的<<运算符的调用（摘自VS2008的ostream文件）：


_Myt& __CLR_OR_THIS_CALL operator<<(_Myt& (__cdecl *_Pfn)(_Myt&))
    ...{    // call basic_ostream manipulator
    _DEBUG_POINTER(_Pfn);
    return ((*_Pfn)(*this));
    }    而endl正好满足了这个重载的运算符的参数的格式：


_CRTIMP2_PURE

The Windows 7 Ribbon. Love it or Loathe it?

Survey period: 9 Nov 2009 to 16 Nov 2009

Do you like the Windows 7 (formerly Office 2007) Ribbon or do you loathe it?

Option Votes %  
I love it 208 19.85 
I like it 324 30.92 
I'm ambivalent or don't have an opinion 254 24.24 
I don't like it 149 14.22 
I can't stand it 113 10.78 
Total 1048   100%

从结果来看，半数参与调查的人对Ribbon界面抱着欢迎的态度，其中有约20%甚至是Love的程度。只有约10&的人比较讨厌Ribbon界面，看来是程序员中比较守旧的一部分。

v从结果上分析，微软在Windows 7中推出的二代Ribbon界面还是比较成功的，能够被多数人说认同和接受，Ribbon逐渐成为一种趋势，不再是一个空洞的口号。想当初，我写下Ribbon界面会成为趋势的时候，还在担心自己会成为历史的笑话呢。这些有些放心了。

实际上，我个人也是比较接受Ribbon界面的，虽然开发起来更麻烦。

　　软件是 运行在硬件之上的。当硬件发展了，软件也要做相应的变化，才能跟上时代的步伐。面对多核时代的到来，软件世界的并行计算开始兴盛起来。如何更加充分地利用 CPU的多个核心?如何发挥多核的威力，带来软件性能上的提升?如何改造现有的程序，让她更好地适应多核时代?如何简便地实现并行计算，使自己开发的应用 程序充分地利用硬件升级所带来的性能提升?这些问题，无不困扰着我们这些多核时代的程序员们。

　　现在崭新的Visual Studio 2010为我们带来了完整的并行计算解决方案，让我们可以从容面对多核时代的到来。

　　天下不再有“免费的午餐”

　 　在以往的计算机发展历史中，硬件技术的发展，特别是CPU频率的不断提高，总是给软件带来免费的性能提升。从386到586，从赛扬到奔腾，每次CPU 频率的提升，都带来软件性能的大幅提升，而软件无需做任何变动。如果有客户抱怨你的软件性能不佳，我们无需着急，只需要坐等Intel或者AMD推出更高 频率的CPU就可以了。程序员们把这形象地称为“免费的午餐”。

图1，多核时代

　 　当单核CPU的频率发展到3G之后，再往上发展就遇到了技术瓶颈，单核心CPU的发展已经到达一个极限，硬件厂商不得不转而向多核芯CPU发展，在一颗 芯片中加入两个甚至多个运算核心，通过核心的增加，来提高芯片总的频率。虽然在硬件厂商看来，这仿佛是一个创举，但是却给软件厂商带来了无尽的烦劳。程序 员们发现，进入多核时代后，这种“免费的午餐”再也没有了。这其中最主要的原因就是当前的应用程序几乎都是针对一个运算核心而设计的，当硬件通过增加运算 核心来提高性能时，由于受到其架构的影响，软件并不能充分地利于多个运算核心所带来的性能提升，甚至有的时候性能还有所下降。在这种情况下，开发者不得不 改变应用程序的架构和开发方法，以应对这种多核的趋势，使得自己的软件可以充分利于硬件升级所带来的性能提升。开发者希望有一个工具能够帮助他们分析应用 程序中的性能瓶颈，能够简便地将现有的业务逻辑并行化处理，从而更好地利用硬件，提升软件的性能。面对这样的需求，作为下一代开发平台，Visual Studio 2010加大了对并行运算的支持。微软正在使得尽量大的范围内的开发者都能高效而简便地进行并行计算的开发，不管他使用的是非托管代码还是.NET Framework。从而将开发者从繁琐而复杂的多线程开发中解放出来，将更多的精力放到业务逻辑上。在Visual Studio 2010中，我们将看到：

　　• Visual Studio IDE对并行计算开发的大量支持。比如，Visual Studio 2010的调试器知道代码的并行特性，并且能够在调试程序的不同执行单元的时候，表现应用程序的状态。

　　• 非托管的C++库和编译器对并行计算的支持

　　• .NET Framework 4.0对并行计算的大量支持，包括PLINQ、并行语言语句等等

　 　另外，Visual Studio 2010还提供了一个“并行性能分析器”，它可以帮助我们分析应用程序的性能瓶颈，找到需要并行处理和可以进行并行处理的地方，并以图形化的形式表现出 来。这样，“并行性能分析器”配合着Visual Studio 2010，我们就可以轻松地实现应用程序的并行化。

阅读全文：Visual Studio 2010对并行计算的支持

Party在学生宿舍的院子中举行，好像是个四合院一样

这是什么东西，一直没有搞明白？？？？

有吃有喝，同学们的生活是越来越好了啊

现场有很多群众在围观

哎，那天真不该穿黑色外套，根本都看不得我啊~~%>_<%

照例是最后的“茄子”

总的而言，玩的很开心。跟同学们在一起很开心啊。

 昨天在母校参与了Windows 7 Party，其中介绍了一些如何为Windows 7开发软件，如果将现有软件迁移到Windows 7上的知识，下面是讲演用的PPT，分享给大家。

Windows 7已经正式发布，从她的测试版本开始到正式发布，Windows 7都广泛地受到好评，或许，Windows 7会成为微软继Windows XP之后新一代的操作系统垄断者，越来越多的应用程序将开始迁移到Windows 7上，越来愈多的应用程序将开始基于Windows 7平台而设计。那么，为Windows 7而开发应用程序，我们需要了解哪些知识？下面的幻灯片可以给大家一个概要性的介绍，让大家清楚从哪些方面入手为Windows 7开发应用程序。