Book Review: Good to Great

Good to Great: Why Some Companies Make the Leap... and Others Don't
by Jim Collins

Good to Great is a great business management book. The book is actual a 2nd part of Professor Collin's research report. In his early research's observation (also booked as "Build to Last"), the "Built to Last" companies he choose had always been great (for reasons, of course). In this book, he further analyze for those good companies (but not yet great) what's missing.

The Good-to-Great concepts are:

1. 5 Level Leadership: where leaders channel their ego needs away from themselves and into the larger goal of building a great company. Note: If Donald Trump is your role model I do not recommend this book for you.


2. First Who ... Then What: first get the right people on the bus, wrong people off the bus, right people in the right seats and then figure out where to drive. This is similar to Buckingham's "Select for Talent" and "Find the Right Fit" in his book First Break All The Rules.


3. Confront the Brutal Facts (Yet Never Lose Faith): have faith that you can and will prevail in the end, and at the same time have the discipline to confront the most brutal facts of your current reality.


4. The Hedgehog Concept: simplicity within the three circles of What you are deeply passionate about, What drives your economic engine and What you can be the best in the world at.


5. A Culture of Discipline: when you have disciplined people, thought and action, you don't need hierarchy, bureaucracy and excessive controls.


6. Technology Accelerators: technology should be used as an accelerator of momentum, not as a creator of it.


7. The Flywheel and the Doom Loop: building momentum over a span of time leads to breakthroughs while shortcuts seldom do.

I highly recommended this one...

Book Review: Execution: The Discipline of Getting Things Done

Execution: The Discipline of Getting Things Done
by Larry Bossidy, Ram Charan, Charles Burck

After reading the book, you can figure out the difference between a good company and a great company....and no guess it is leader's ability to execute -- it's a must have!!

The book has been rated high in Taiwan as well.

Book Review: Kotler on Marketing

Kotler on Marketing : How to Create, Win, and Dominate Markets
by Philip Kotler

Kotler is the maestro in marketing. In fact, he is one of first fews who gave the "new profession" a clear defintion and objectives.

The organization and prose of the book make it an enjoyable read, not at all academic and stuffy. Many MBA Marketing Strategy courses are using it as text, and it is comprehensive and insightful as to the new challenges of marketing.

The book is organized into four parts:

Part One: Strategic Marketing - including sections on building profitable businesses through world-class marketing; using marketing to understand, create, communicate and deliver value; identifying market opportunities and developing targeted value offerings; developing value propositions and building brand equity.

Part Two: Tactical Marketing - developing and using market intelligence; designing the marketing mix; acquiring, retaining and growing customers; designing and delivering more customer value.

Part Three: Administrative Marketing - planning and organizing for more effective marketing; evaluating and controlling marketing performance.

Part Four: Transformational Marketing - adapting to the new age of electronic marketing.

Whether you read the book from cover to cover, or add it to your reference library and just read specific sections, you will find it full of useful theories, practical advice and many current examples.

update: 1/11/2004
中文譯: 科特勒談行銷─如何創造、贏取並主宰市場

Data-binding to public fields... yes or no?

To bind or not to bind to fields? This seems to be a source of constant debate, with folks in both camps. I get a mail roughly every six months in one form or another on this one. Today was that day.

I happen to be in the camp that disagrees that we should support binding to fields, because public fields are not a recommended practice. While they maybe convenient for quick and dirty code, they do not version. Using properties instead allows you to change the access logic, and data storage behind the covers, as well as add validation logic when a value is assigned. Furthermore, accessing properties feels pretty much the same, and do not have any performance overhead. Thankfully we have an FxCop rule to call out public fields as errors. Another reason, why I happen to in the disagree camp is overall consistency within the framework. For example, the property grid does not display fields.

Aside: One of the reasons why data-binding support is limited to properties happens to be the fact that all of data-binding is built around PropertyDescriptors and not on direct reflection. This allows someone to implement ICustomTypeDescriptor to provide a different OM for the purposes of data-binding than the true set of properties present on the CLR type. For example, DataRowView implements ICustomTypeDescriptor to surface its columns as pseudo-properties that are visible to ASP.NET's data-binding infrastructure (such as GridView/DataGrid columns and DataBinder.Eval). Without this, DataRowView would have two properties - DataView and Index (and the second is the only one remotely interesting for data-binding).

The web service proxies generated using wsdl in v1.x however (and unfortunately) generated only fields, and not properties. This is probably the most significant argument in favor of supporting binding to fields. In Whidbey however, this has been finally fixed, and properties are also generated.

I am curious what the general opinion is, and whether there is any chance for consensus on this subject!

I'll take advantage of this opportunity to voice a small gripe I have with C#. I'd really like the language to provide a shortcut for implementing properties where the compiler generates the get/set accessors and underlying private field in much the same way it does for events. For example, when all you want is a simple read/write property:

public property int Count;

and this can then be converted to a full-fledged property without changing the public OM of the type as needed.

Home Party, 12/15/2002

Debug by 蔡學鏞

以下轉載自 Debug本文作者：蔡學鏞張貼日期：05/16/2002

Debug
吃燒餅不免會掉芝麻，寫程式不免會有 bug。再怎麼高明的程式員，也不敢保證寫出來的程式不會有 bug。當發現程式有誤，bug 隱身其中時，就是 debugger 出動的時候了。越是高明的程式員，越是能夠靈巧地使用 debugger，讓 bug 無所遁形。

Debug 的過程分成兩個步驟：
1. 找到 bug 所在地
2. 修正 bug

事實上，真正困難的地方在第一點，如果你能找到 bug 所在地，應該就知道怎麼修正 bug 了。本文章簡單地介紹 debugger 的用法，希望你再次遇到 bug 時，能夠不慌不忙地把這些技巧派上用場。

調整步伐
最不花腦筋的 debug 方式就是：逐行執行，每執行一行程式碼就暫停，立刻觀察這一行的執行結果是否如你所預期，沒問題的話就繼續執行下一行。

當你在逐行執行的時候，如果遇到了 method invocation（函式呼叫），你可以選擇要跳進此 method 或者不跳進此 method。欲跳進此 method，就使用 step in；欲一口氣執行完此 method，就使用 step over。至於要不要跳進去，你可以有自己的考量。一般來說，如果你認定該 method 應該不會有問題時，你就使用 step over，否則使用 step in。

如果已經在某 method 內，但是認為此 method 後面的程式碼不會有 bug，你可以透過 step out 來往上跳，跳離開這個 method。

在 debug 的時候，前進的步伐很重要，step over、step in、step out 三者必須好好搭配使用，才不會「自亂陣腳」。

控制疏密
光靠上面三種 step 方式，要找到 bug，就如同海底撈針一樣，並不容易。你還需要 breakpoint（中斷點）的輔助。

你應該先透過經驗來判斷，bug 最有可能出現在哪些地方。然後在這些地方的前後分別設定 breakpoint。為了加快 debug 的速度，我們經常同時在程式中設定多個中斷點。

在 debug 模式下執行程式時，遇到中斷點，程式就會暫停，我們可以利用這個機會檢視目前的執行結果是否符合預期，如果有差池的話，就表示剛才執行過的程式碼有問題，你已經找到了 bug 的區域，立刻停止此次的 debug 執行模式。接著再重來一次，繼續縮小範圍。當範圍已經很小時，可以改用 step 的方式來找 bug。

分析觀察
不管是導因於 breakpoint 或 step，程式在 debug 模式下暫停時，我們都需要「觀察」（watch）程式目前的狀態（state），據以判斷方才的執行過程有無錯誤。程式狀態其實就是資料的集合，所以我們的「觀察」對象就是程式中的變數值。Debug 工具可以讓我們很方便地觀察程式中各個變數的值，有些 debug 工具還可以讓我們輸入由變數組成的計算式（expression），輸出計算結果以方便我們觀察。

某些 debugger 甚至具有修改變數值的功能，可以讓你在程式暫停時，修改程式狀態，然後繼續執行。

理清頭緒

對於多執行緒（multi-thread）程式，debugger 依然能進行上述的 step、breakpoint、watch。通常 debugger 會在 watch 視窗中以樹狀結構區分出執行緒，然後才個別列出各個執行緒的區域變數，以免混淆。

為了因應撰寫 client/server 程式的需求，有些 debug 工具甚至可以同時幫助多個 process 進行除錯。

隔空抓藥
「捎來藥丸的，可是白鬍子的老公公？」我們姑且相信這個妖婦的確具備隔空抓藥的本事，但提到這樣的本事，許多 debugger 也不遑多讓。越來越多的 debugger 開始支援 remote debugging，讓程式員可以在一部 PC 上，debug 另一部 PC 上的程式。

以 Java 來說，早期 VisualCafe 就提供了自己專屬的 remote agent，來達到 remote debugging 的功能。現在，Sun 的 JVM 都支援 JVMDI（Java VM Debug Interface）以及 JDWP（Java Debug Wire Protocol），所以想設計出一個能隔空抓藥的標準 remote debugger 也不難，主流的 Java 開發工具也開始支援 remote debugging。

de 程式中的 bug，也 de 生活中的 bug

我們除了 de 程式中的 bug，也要 de 生活中的 bug（竊聽器也被稱做 bug）。中國大陸國家主席江澤民的波音 747-300R 座機被裝滿 bug，美鳳姊姊的座車和手機內也被裝了 bug。越是重要的人，周遭的 bug 就會越多，越是需要常常進行 debug。

如果無法確定生活中毫無 bug，請各位務必要做最壞的打算，試圖干擾任何可能存在的 bug，作法很簡單，例如：放大電視機音量、關燈，都很有效。那也就是為什麼，我向親近好友坦承「關燈版」的男主角其實就是我，至今仍然沒有人相信的緣故。

Book Review: Design Patterns

Design Patterns: Elements of Reusable Object-Oriented Software (Addison-Wesley Professional Computing Series) (Hardcover)
by Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides

Say no more...Gang of four's classic must read.