Wrapper Objects & Object Reference

In JavaScript, primitive types behave like objects. They use dot expression to access certain methods. For example

var str = "abcd";
console.log(str.length); //4

But for object, every property is mutable. If we change the length to 10, it should be changed to 10. However, this is not the case.

str.length =10;
console.log(str.length); //4

This is because, primitive types don't actually have methods or properties. The access of those methods or properties invokes creation of their Wrapper Objects, which are String(), Numeric() and Boolean(). So when str.length is evaluated, something like this line is invoked.

var tmp_str = new String(str); return tmp_str.length; delete tmp_str;

After tmp_str is returned, it is destroyed. This is a wrapper object. It abstract the actual behaviours of primitive types, making it like a read-only object. Attempting to add/modify method or properties of primitive data types results in no effects. (because changes are only made to wrapper objects which are destroyed after access)

Another thing I learned about JS today is that, all objects in Javascript are "pass by reference". All primitive types are "pass by value".
Array are objects. so
var a=[1,2,3];
var b=a;
console.log(b); //[1,2,0]

So if there is a need to copy an independent object from another object, we have to write our own copy function.

function copyArr(a) {
    var b=[];
    for (var i=0;i<a.length;i++) {
        b[i] = a[i];        
    return b;
var a=[1,2,3];
var b=copyArr(a);
console.log(a); //[1,2,0]
console.log(b); //[1,2,3]


JavaScript Closure

一直在看David Flanagan的JavaScript: The Definitive Guide 6th Edition,收获颇丰。

Closure 中文叫做闭包,在JavaScript里函数都是有闭包的特性。

1.JS里面函数是first-class function,就是说函数跟class是一个级别的。 函数可以直接赋值到变量上,它的类型为"function",这个变量可以直接用来invoke函数。
function test1() {
func_var = test1;
console.log(typeof func_var); //"function"
func_var(); // invoked test1 -> '1'

2.JS使用lexical scoping,也就是一个函数的scope在它define的时候就确定了,而不是在invoke的时候才确定。

function test2() {
    var b = 1;
    return function () {console.log(++b);};
b = 10;  //无影响
test2()(); //2
test2()(); //2
func_var = test2();
func_var(); //2
func_var(); //3
func_var(); //4

这种closure使var b成为test2这个object的私有变量,把data hide起来,不受其他scope的影响。可以猜想,JS使用这种特性可以实现object-oriented programming。

PS: from SICP about first-class procedures
In general, programming languages impose restrictions on the ways in which computational elements can be manipulated. Elements with the fewest restrictions are said to have first-class status. Some of the ``rights and privileges'' of first-class elements are:
  • They may be named by variables.
  • They may be passed as arguments to procedures.
  • They may be returned as the results of procedures.
  • They may be included in data structures.
Lisp, unlike other common programming languages, awards procedures full first-class status. This poses challenges for efficient implementation, but the resulting gain in expressive power is enormous.

Javascript is like Lisp very much in this aspect.




原来是这样的,在 Inland Revenue Authority of Singapore的网站上有写,像我这种拿外国护照,工作不到182天的人叫做non-resident employee。我离职的时候,公司需要向IRAS申报税务审查( tax clearance) 同时要扣留我这个月的工资。然后审查结果会得到一个税款。从扣留的工资里面扣除这个税款之后,就多退少补。
作为non-resident empolyee,个人所得税的税率是高达15%。一般工作超过183天的resident emplyee只用付2%的税。所以,如果工作不满半年换工作在缴税这个问题上是相当吃亏的。可能新加坡就是用这种政策来防止频繁换工作吧。


Anyway, 换工作的事情告一段落了,如果这个礼拜EP下来,在11月之前我就可以到新公司报到上班了。

PS: 上交个人所得税是个人的义务,所以不要总是assume公司有帮你办,可以放心。有时候政策的变化,和一些你不知道的条款的加入会影响到最后的税款。所以定时的检查每月扣除的税款,和公积金是有必要的。这样你可以知道一些政策的变动,并作出相应的决策。

PS: 跟税务局说明我在新加坡读书好多年之后,他们觉得我应该算作是resident employee,然后归还我了1100块钱。这归还的钱显然是没有扣除resident employee的税钱,将近200块。难道我赚了,呵呵。新加坡税务局是相当的廉洁,开明和有同情心啊。


Code Complete 2nd Edition

Computer science has some of the most colorful language of any field. In what other field can you walk into a sterile room, carefully controlled at 68°F, and find viruses, Trojan horses, worms, bugs, bombs, crashes, flames, twisted sex changers, and fatal errors?
One of the main differences between programs you develop in school and those you develop as a professional is that the design problems solved by school programs are rarely, if ever, wicked. Programming assignments in school are devised to move you in a beeline from beginning to end. You'd probably want to tar and feather a teacher who gave you a programming assignment, then changed the assignment as soon as you finished the design, and then changed it again just as you were about to turn in the completed program. But that very process is an everyday reality in professional programming.


God and StackOverflow

Everybody should have a god in his heart. This god is not necessary to be Jesus or Buddha.
Generally accepted idolism gave us an abstract interface, it's up to us to implement our own God. Jesus and Buddha is just some excellent examples. Even these famous implementation of idolism exhibit certain variations in different country. This is because many people also extend or override the original beliefs. For example there are 2.1 billion Christian in the world today. But many of them do have their own call of Christian. Chinese Christian call themselves Christ Follower.

I would also like to have my own implementation of God, who could give guidance in some authoritative name. It's just a simple function, easy to do. And no name for me.
So the first guidance I would like him to give is "Don't give up, Don't be depress, Everything will be fine".


Why some people at stackoverflow has such a high reputation??
I guess one reason is because they really have answered people's question.
Another reason maybe they have another account and use that account ask some question that they think other people would find useful and answer it themselves. Just a guess.



This article appeared in C/C++ Users Journal, 19(9), September 2001.


This month, I want to present up-to-date answers to two recurring questions about virtual functions. These answers then lead directly to four class design guidelines.

The questions are old, but people still keep asking them, and some of the answers have changed over time as we've gained experience with modern C++.

Virtual Question #1: Publicity vs. Privacy?

The first of the two classic questions we'll consider is this: "When should virtual functions be public, protected, or private?" The short answer is: Rarely if ever, sometimes, and by default, respectively - the same answer we've already learned for other kinds of class members.

Most of us have learned through bitter experience to make all class members private by default unless we really need to expose them. That's just good encapsulation. Certainly we've long ago learned that data members should always be private (except only in the case of C-style data structs, which are merely convenient groupings of data and are not intended to encapsulate anything). The same also goes for member functions, and so I propose the following guidelines which could be summarized as a statement about the benefits of privatization.

Guideline #1: Prefer to make interfaces nonvirtual, using Template Method.

Interestingly, the C++ standard library already overwhelmingly follows this guideline. Not counting destructors (which are discussed separately later on under Guideline #4), and not double-counting the same virtual function twice when it appears again in a specialization of a class template, here's what the standard library has:


6 public virtual functions, all of which are std::exception::what() and its overrides


142 nonpublic virtual functions

Why is this such a good idea? Let's investigate.

Traditionally, many programmers were used to writing base classes using public virtual functions to directly and simultaneously specify both the interface and the customizable behavior. For example, we might write:


// Example 1: A traditional base class.
class Widget
  // Each of these functions might optionally be
  // pure virtual, and if so might or might not have
  // an implementation in Widget; see Item 27 in [1].
  virtual int Process( Gadget& );
  virtual bool IsDone();
  // ...


The problem is that "simultaneously" part, because each virtual function is doing two jobs: It's specifying interface because it's public and therefore directly part of the interface Widget presents to the rest of the world; and it's specifying implementation detail, namely the internally customizable behavior, because it's virtual and therefore provides a hook for derived classes to replace the base implementation of that function (if any). That a public virtual function inherently has two significantly different jobs is a sign that it's not separating concerns well and that we should consider a different approach.

What if we want to separate the specification of interface from the specification of the implementation's customizable behavior? Then we end up with something that should remind us strongly of the Template Method pattern[2], because that's exactly what it is: [Later note: Actually it's a more restricted idiom with a form similar to that of Template Method. This idiom deserves its own name, and since writing this article I've switched to calling the idiom the Non-Virtual Interface Idiom, or NVI for short. -hps]


// Example 2: A more modern base class, using
// Template Method to separate interface from
// internals.
class Widget
  // Stable, nonvirtual interface.
  int Process( Gadget& ); // uses DoProcess...()
  bool IsDone(); // uses DoIsDone()
  // ...

  // Customization is an implementation detail that may
  // or may not directly correspond to the interface.
  // Each of these functions might optionally be
  // pure virtual, and if so might or might not have
  // an implementation in Widget; see Item 27 in [1].
  virtual int DoProcessPhase1( Gadget& );
  virtual int DoProcessPhase2( Gadget& );
  virtual bool DoIsDone();
  // ...


Prefer to use Template Method to make the interface stable and nonvirtual, while delegating customizable work to nonpublic virtual functions that are responsible for implementing the customizable behavior. After all, virtual functions are designed to let derived classes customize behavior; it's better to not let publicly derived classes also customize the inherited interface, which is supposed to be consistent.

The Template Method approach has several benefits and no significant drawbacks.

First, note that the base class is now in complete control of its interface and policy, and can enforce interface preconditions and postconditions, insert instrumentation, and do any similar work all in a single convenient reusable place - the nonvirtual interface function. This promotes good class design because it lets the base class enforce the substitutability compliance of derived classes in accord with the Liskov Substitution Principle[3], to whatever extent enforcement makes sense. If efficiency is an issue, the base class can elect to check certain kinds of pre- and postconditions only in a debug mode, for example via a non-debug "release" build that completely removes the checking code from the executable image, or via a configurable debug mode that suppresses selected checking code at runtime.

Second, when we've better separated interface and implementation, we're free to make each take the form it naturally wants to take instead of trying to find a compromise that forces them to look the same. For example, notice that in Example 2 we've incidentally decided that it makes more sense for our users to see a single Process() function while allowing more flexible customization in two parts, DoProcessPhase1() and DoProcessPhase2(). And it was easy. We couldn't have done this with the public virtual version without making the separation also visible in the interface, thereby adding complexity for the user who would then have to know to call two functions in the right way. (For more discussion of a related example, see also Item 23 in Exceptional C++[4].)

Third, the base class is now less fragile in the face of change. We are free to change our minds later and add pre- and postcondition checking, or separate processing into more steps, or refactor, or implement a fuller interface/implementation separation using the Pimpl idiom[4], or make other modifications to Widget's customizability, without affecting the code that uses Widget. For example, it's much more difficult to start with a public virtual function and later try to wrap it for pre- and postcondition checking after the fact, than it is to provide a dumb passthrough nonvirtual wrapper up front (even if no checking or other extra work is immediately needed) and insert the checking later. (For more discussion of how a class like Widget is less fragile and more amenable to future revision and refactoring, see the article "Virtually Yours"[5].)

"But but but," some have objected, "let's say that all the public nonvirtual function does initially is pass through to the private virtual one. It's just one stupid little line. Isn't that pretty useless, and indeed haven't we lost something? Haven't we lost some efficiency (the extra function call) and added some complexity (the extra function)?" No, and no. First, a word about efficiency: No, none is lost in practice because if the public function is a one-line passthrough declared inline, all compilers I know of will optimize it away entirely, leaving no overhead. (Indeed, some compilers will always make such a function inline and eliminate it, whether you personally really wanted it to or not, but that's another story.) Second, a word about complexity: The only complexity is the extra time it takes to write the one-line wrapper function, which is trivial. Period. That's it. C'est tout. The interfaces are unaffected: The class still has exactly the same number of public functions for a public user to learn, and it has exactly the same number of virtual functions for a derived class programmer to learn. Neither the interface presented to the outside world, nor the inheritance interface presented to derived classes, has become any more complex in itself for either audience. The two interfaces are just explicitly separated, is all, and that is a Good Thing.

Well, that justifies nonvirtual interfaces and tells us that virtual functions benefit from being nonpublic, but we haven't really answered whether virtual functions should be private or protected. So let's answer that:

Guideline #2: Prefer to make virtual functions private.

That's easy. This lets the derived classes override the function to customize the behavior as needed, without further exposing the virtual functions directly by making them callable by derived classes (as would be possible if the functions were just protected). The point is that virtual functions exist to allow customization; unless they also need to be invoked directly from within derived classes' code, there's no need to ever make them anything but private. But sometimes we do need to invoke the base versions of virtual functions (see the article "Virtually Yours"[5] for an example), and in that case only it makes sense to make those virtual functions protected, thus:

Guideline #3: Only if derived classes need to invoke the base implementation of a virtual function, make the virtual function protected.

The bottom line is that Template Method as applied to virtual functions nicely helps us to separate interface from implementation. It's possible to make the separation even more complete, of course, by completely divorcing interface from implementation using patterns like Bridge[2], idioms like Pimpl (principally for managing compile-time dependencies and exception safety guarantees)[1] [4] or the more general handle/body or envelope/letter[6], or other approaches. Unless you need a more complete interface/implementation separation, though, Template Method will often be sufficient for your needs. On the flip side, I am arguing that this use of Template Method is also a good idea to adopt by default and view as a necessary minimum separation in practice in new code. After all, it costs nothing (beyond writing an extra line of code) and buys quite a bit of pain reduction down the road.

Former communist countries are learning the benefits of privatization, in those cases where privatization makes sense. The lesson of healthy privatization is likewise not lost on good class designers. For more examples of using the Template Method pattern to privatize virtual behavior, see "Virtually Yours".[5]

Speaking of that article, did you notice that the code there presented a public virtual destructor? This brings us to the second topic of this month's column:

Virtual Question #2: What About Base Class Destructors?

The second classic question we'll consider is that old destructor chestnut: "Should base class destructors be virtual?"

Sigh. I wish this were only a frequently asked question. Alas, it's more often a frequently debated question. If I had a penny for every time I've seen this debate, I could buy a cup of coffee. Not just any old coffee, mind you - I could buy a genuine Starbucks Venti double-Valencia latte (my current favorite). Maybe even two of them, if I was willing to throw in a dime of my own.

The usual answer to this question is: "Huh? Of course base class destructors should always be virtual!" This answer is wrong, and the C++ standard library itself contains counterexamples refuting it, but it's right often enough to give the illusion of correctness.

The slightly less usual and somewhat more correct answer is: "Huh? Of course base class destructors should be virtual if you're going to delete polymorphically (i.e., delete via a pointer to base)!" This answer is technically right but doesn't go far enough.

I've recently come to conclude that the fully correct answer is this:

Guideline #4: A base class destructor should be either public and virtual, or protected and nonvirtual.

Let's see why this is so.

First, an obvious statement: Clearly any operation that will be performed through the base class interface, and that should behave virtually, should be virtual. That's true even with Template Method, above, because although the public interface function is nonvirtual, the work is delegated to a nonpublic virtual function and we get the virtual behavior that we need.

If deletion, therefore, can be performed polymorphically through the base class interface, then it must behave virtually and must be virtual. Indeed, the language requires it - if you delete polymorphically without a virtual destructor, you summon the dreaded specter of "undefined behavior," a specter I personally would rather not meet in even a moderately well-lit alley, thank you very much. Hence:


// Example 3: Obvious need for virtual destructor.
class Base { /*...*/ };

class Derived : public Base { /*...*/ };

Base* b = new Derived;
delete b; // Base::~Base() had better be virtual!


Note that the destructor is the one case where the Template Method pattern cannot be applied to a virtual function. Why not? Because once execution reaches the body of a base class destructor, any derived object parts have already been destroyed and no longer exist. If the Base destructor body were to call a virtual function, the virtual dispatch would reach no further down the inheritance hierarchy than Base itself. In a destructor (or constructor) body, further-derived classes just don't exist any more (or yet).

But base classes need not always allow polymorphic deletion. For example, in the standard library itself,[7] consider class templates such as std::unary_function and std::binary_function. Those two class templates look like this:


template <class Arg, class Result>
struct unary_function
  typedef Arg    argument_type;
  typedef Result result_type;

template <class Arg1, class Arg2, class Result>
struct binary_function
  typedef Arg1   first_argument_type;
  typedef Arg2   second_argument_type;
  typedef Result result_type;


Both of these templates are specifically intended to be instantiated as base classes (in order to inject those standardized typedef names into derived classes) and yet do not provide virtual destructors because they are not intended to be used for polymorphic deletion. That is, code like the following is not merely unsanctioned but downright illegal, and it's reasonable for you to assume that such code will never exist:


// Example 4: Illegal code that you can assume
// will never exist.
void f( std::unary_function* f )
  delete f; // error, illegal


Note that the standard tut-tuts and declares Example 4 to fall squarely into the Undefined Behavior Pit, but the standard doesn't actually require a compiler to prevent you or anyone else from writing that code (more's the pity). It would be easy and nice - and it wouldn't break any standards-conforming C++ programs that exist today - to give std::unary_function (and other classes like it) an empty but protected destructor, in which case a compiler would actually be required to diagnose the error and toss it back in the offender's face. Maybe we'll see such a change in a future revision to the standard, maybe we won't, but it would be nice to make compilers reject such code instead of just making tut-tut noises in standardish legalese.

Finally, what if a base class is concrete (can be instantiated on its own) but also wants to support polymorphic destruction? Doesn't it need a public destructor then, since otherwise you can't easily create objects of that type? That's possible, but only if you've already violated another guideline, to wit: Don't derive from concrete classes. Or, as Scott Meyers puts it in Item 33 of More Effective C++,[8] "Make non-leaf classes abstract." (Admittedly, it can happen in practice - in code written by someone else, of course, not by you! - and in this one case you may have to have a public virtual destructor just to accommodate what's already a poor design. Better to refactor and fix the design, though, if you can.)

In brief, then, you're left with one of two situations. Either: a) you want to allow polymorphic deletion through a base pointer, in which case the destructor must be virtual and public; or b) you don't, in which case the destructor should be nonvirtual and protected, the latter to prevent the unwanted usage.


In summary, prefer to make base class virtual functions private (or protected if you really must). This separates the concerns of interface and implementation, which stabilizes interfaces and makes implementation decisions easier to change and refactor later. For normal base class functions:


Guideline #1: Prefer to make interfaces nonvirtual, using Template Method.


Guideline #2: Prefer to make virtual functions private.


Guideline #3: Only if derived classes need to invoke the base implementation of a virtual function, make the virtual function protected.

For the special case of the destructor only:


Guideline #4: A base class destructor should be either public and virtual, or protected and nonvirtual.

True, the standard library itself does not always follow these design criteria. In part, that's a reflection of how we as a community have learned over the years.



1. H. Sutter. More Exceptional C++ (Addison-Wesley, 2002).

2. Gamma, Helm, Johnson, and Vlissides. Design Patterns: Elements of Reusable Object-Oriented Software (Addison-Wesley, 1995).

3. B. Liskov. "Data Abstraction and Hierarchy" (SIGPLAN Notices, 23(5), May 1988).

4. H. Sutter. Exceptional C++ (Addison-Wesley, 2000).

5. J. Hyslop and H. Sutter. "Virtually Yours" (C/C++ Users Journal Experts Forum, 18(12), December 2000).

6. J. Coplien. Advanced C++ Programming Styles and Idioms (Addison-Wesley, 1992).

7. ISO/IEC 14882:1998(E), Programming Languages - C++ (ISO and ANSI C++ standard).

8. S. Meyers. More Effective C++ (Addison-Wesley, 1996).

My Notes:
In C++ every class function is final by default.
In Java every class function is virtual by default.
This is one reason Java is slower than C++.
virtual functions add much overhead.


Today I told my boss, I m gonna leave.

Just some thought I have in mind after I talked to my boss: I think small companies that have frequency movement of manpower should set up a logging system that track the experience of each of such manpower. This is very beneficial to the company because it reduces the cost of re-learn stuffs that previous people has encountered. Imagine, if an employee spent 3 days solving a bug which no one else knows. Then he left the company after a few weeks. And the one who continues his work would also encounter this bug. If he is more skillful, he may solve it in 2 days. But anything more than a search and answer is a waste of effort. In other word, documentation for small company is a crucial performance improver as well as money saver (time is money).


Truely inspirational to any tech guy

Steve Jobs has passed away, tech world mourns

October 5, 2011, 5:22 PM PDT

Apple co-founder and long-time CEO Steve Jobs has passed away today after a long fight with pancreatic cancer. Jobs resigned as CEO in August and didn’t appear yesterday at Apple’s launch of the latest edition of the iPhone.

Statement from Apple

Here is the public statement from Apple’s board of directors:

We are deeply saddened to announce that Steve Jobs passed away today.

Steve’s brilliance, passion and energy were the source of countless innovations that enrich and improve all of our lives. The world is immeasurably better because of Steve.

His greatest love was for his wife, Laurene, and his family. Our hearts go out to them and to all who were touched by his extraordinary gifts.

Tribute on

Apple has placed a simple tribute to Steve on its homepage:

Statement from Jobs’ family

The family of Steve Jobs released this statement:

Steve died peacefully today surrounded by his family.

In his public life, Steve was known as a visionary; in his private life, he cherished his family. We are thankful to the many people who have shared their wishes and prayers during the last year of Steve’s illness; a website will be provided for those who wish to offer tributes and memories.

We are grateful for the support and kindness of those who share our feelings for Steve. We know many of you will mourn with us, and we ask that you respect our privacy during our time of grief.

Tim Cook’s email to Apple employees

Here is the email message that CEO Tim Cook sent to his employees at Apple:


I have some very sad news to share with all of you. Steve passed away earlier today.

Apple has lost a visionary and creative genius, and the world has lost an amazing human being. Those of us who have been fortunate enough to know and work with Steve have lost a dear friend and an inspiring mentor. Steve leaves behind a company that only he could have built, and his spirit will forever be the foundation of Apple.

We are planning a celebration of Steve’s extraordinary life for Apple employees that will take place soon. If you would like to share your thoughts, memories and condolences in the interim, you can simply email

No words can adequately express our sadness at Steve’s death or our gratitude for the opportunity to work with him. We will honor his memory by dedicating ourselves to continuing the work he loved so much.


Note from Bill Gates

Jobs’ longtime friend and rival Bill Gates of Microsoft released the following statement:

I’m truly saddened to learn of Steve Jobs’ death. Melinda and I extend our sincere condolences to his family and friends, and to everyone Steve has touched through his work.

Steve and I first met nearly 30 years ago, and have been colleagues, competitors and friends over the course of more than half our lives.

The world rarely sees someone who has had the profound impact Steve has had, the effects of which will be felt for many generations to come.

For those of us lucky enough to get to work with him, it’s been an insanely great honor. I will miss Steve immensely.

Note from Steve Ballmer

Microsoft CEO Steve Ballmer offered the following statement:

“I want to express my deepest condolences at the passing of Steve Jobs, one of the founders of our industry and a true visionary. My heart goes out to his family, everyone at Apple and everyone who has been touched by his work.”

Notes from Google founders

Google CEO Larry Page made this statement:

“I am very, very sad to hear the news about Steve. He was a great man with incredible achievements and amazing brilliance. He always seemed to be able to say in very few words what you actually should have been thinking before you thought it. His focus on the user experience above all else has always been an inspiration to me. He was very kind to reach out to me as I became CEO of Google and spend time offering his advice and knowledge even though he was not at all well. My thoughts and Google’s are with his family and the whole Apple family.”

Google co-founder Sergey Brin made this statement:

“From the earliest days of Google, whenever Larry and I sought inspiration for vision and leadership, we needed to look no farther than Cupertino. Steve, your passion for excellence is felt by anyone who has ever touched an Apple product (including the macbook I am writing this on right now). And I have witnessed it in person the few times we have met.

On behalf of all of us at Google and more broadly in technology, you will be missed very much. My condolences to family, friends, and colleagues at Apple.”

Note from Marc Andreessen

Web pioneer Marc Andreessen said that Jobs beamed products from 10 to 20 years in the future.

“He was the most amazing product visionary our industry had or will ever have.”

Note from President Obama

U.S. President Barack Obama released the following statement:

Michelle and I are saddened to learn of the passing of Steve Jobs. Steve was among the greatest of American innovators – brave enough to think differently, bold enough to believe he could change the world, and talented enough to do it.

By building one of the planet’s most successful companies from his garage, he exemplified the spirit of American ingenuity.  By making computers personal and putting the internet in our pockets, he made the information revolution not only accessible, but intuitive and fun.  And by turning his talents to storytelling, he has brought joy to millions of children and grownups alike. Steve was fond of saying that he lived every day like it was his last.  Because he did, he transformed our lives, redefined entire industries, and achieved one of the rarest feats in human history: he changed the way each of us sees the world.

The world has lost a visionary. And there may be no greater tribute to Steve’s success than the fact that much of the world learned of his passing on a device he invented. Michelle and I send our thoughts and prayers to Steve’s wife Laurene, his family, and all those who loved him.

CNET video tribute

CBS News video tribute

Steve Jobs on mortality

In his commencement address at Stanford University in 2005, after he had just came back from cancer the first time, Jobs said:

“Your time is limited, so don’t waste it living someone else’s life. Don’t be trapped by dogma — which is living with the results of other people’s thinking. Don’t let the noise of others’ opinions drown out your own inner voice. And most important, have the courage to follow your heart and intuition. They somehow already know what you truly want to become. Everything else is secondary.”

Here is the video of the full 15-minute commencement speech at Stanford:

My take

A century from now, people will still marvel at how Steve Jobs changed the world by humanizing technology. That will be his legacy.

zt. from TechRepublic



情感的禁区 刘德华
曲:天野滋 词:陈浩贤

常令你独垂泪 弄得爱路极崎岖

今天的你已跟他去 心已被窃取
踏快车 雨中追 但愿停车跟你聚
但我知 你的心 尽是情感的禁区

连夜我未能睡 内心悔恨如有罪

当天的你已消失去 心若冷水
愿你知 我空虚 但愿重新跟你聚
但我知 你的心 尽是情感的禁区

都怪我 刘德华
作词:高枫 作曲:高枫






fuking "data type mismatch in criteria expression" error

Seem like many people have encountered this daunting "data type mismatch in criteria expression" error, so do I. Some people have this when they wrote VB scripts in MS Access, but my case is not related to any code at all. I encounter it just when I try to output some data from mysql table to a static report in MS Access. So many solutions on the web could not fit into my situation.

After several days of pulling hair, I finally find the cause.

I used BigInt as one of my Mysql table field type. It seems MS access or ODBC doesn't recognize this type. After I change it to int, everything works fine now.

Microsoft really should provide more information to this bug. The error message given is too general which doesn't help in such complicated situation.