How to remove Trend Officescan without password?

安裝 trend officescan後，想要移除，卻發現須要密碼，如何不須密碼移除趨勢科技 trend officescan，步驟如下：
1. 打開工作管理員，強迫關掉以下程式 Tmlisten.exe NTRtscan.exe ofcpfwsvc.exe 及 暫存執行檔(前兩個字母及最後一個字母是大寫英文，第三、四、五個字母是數字)
2. 修改registry
\HKEY_LOCAL_MACHINE\SOFTWARE\TrendMicro\PC-cillinNTCorp\CurrentVersion\Misc\ 將 Allow Uninstall 值改為 1
3. 至〔控制台〕的〔新增移除程式〕中，移除 Trend Officescan。

[From huang987's Memo: 如何不須密碼移除趨勢科技officescan(How to remove Trend Officescan without password？)]

Handy dandy pop-up dictionary

In any app that uses Cocoa text widgets (Safari, for example), you can hover the mouse cursor over a word and press cmd-ctrl-d to get a tool-tip like bubble that shows the word’s definition and a button to open Dictionary.app to that word. Try it on an archaic word the comprehension of which eludes you before I get overly loquacious.

[From Finer Things in Mac, Handy dandy pop-up dictionary]

This is much better than the 金山詞霸 that my colleagues are using. "You" get to decide if you want to look up the meaning of a word, instead of letting a background process hog your CPU on every mouse-over English word, bravo!

The 18 Mistakes That Kill Startups

6. Hiring Bad Programmers

I forgot to include this in the early versions of the list, because nearly all the founders I know are programmers. This is not a serious problem for them. They might accidentally hire someone bad, but it's not going to kill the company. In a pinch they can do whatever's required themselves.

But when I think about what killed most of the startups in the e-commerce business back in the 90s, it was bad programmers. A lot of those companies were started by business guys who thought the way startups worked was that you had some clever idea and then hired programmers to implement it. That's actually much harder than it sounds—almost impossibly hard in fact—because business guys can't tell which are the good programmers. They don't even get a shot at the best ones, because no one really good wants a job implementing the vision of a business guy.

In practice what happens is that the business guys choose people they think are good programmers (it says here on his resume that he's a Microsoft Certified Developer) but who aren't. Then they're mystified to find that their startup lumbers along like a World War II bomber while their competitors scream past like jet fighters. This kind of startup is in the same position as a big company, but without the advantages.

So how do you pick good programmers if you're not a programmer? I don't think there's an answer. I was about to say you'd have to find a good programmer to help you hire people. But if you can't recognize good programmers, how would you even do that?

[From The 18 Mistakes That Kill Startups]

This somewhat echoes The Problem with Design and Implementation where the author of the other article complained about the separation of the domain expert and the implementor.

Defining a 'good programmer' relies not only on the programmatic skill, but also the intellectual ability to understand and study domain-specific knowledge, you can't really program a bond calculator without knowing the underlying math that defines a bond. It would be naive to vaguely describe a bright idea and expect the programmer to 'just get it' and do it right. It is not that easy.

The Problem with Design and Implementation

Last, but not least is something I haven't touched on too much, but it is implied. Software is not trivial work. As such getting good people and training them is essential. You cannot separate the specification or design or knowledge from the code. The latest fad is something called a 'subject matter expert (SME)'. I say this is a fad as it assumes that you can separate the person doing the coding from the person that 'knows stuff.' In the networking world, this is the person that knows the protocols and specifications down to a tee. No worries though. They don't program. That is just the trivial matter left to the mundane implementers. I had such an experience recently at a company I worked for. They had a PHD who was supposed to be a subject matter expert. Of course there were the programmers actually writing the code, debugging issues, working on interoperability, coding which bits need to be set, what values go in what fields, and so on. The programmers ended up having to know more about the specification than the SME himself. Do I really need to rewrite the article on the futility of separating the SME from the programmer? In the end, it is your programmer who will debug issues, solve problems... They need to be experts in the subject matter. I suppose you could have an SME who does not code. It's just that the programmer would have to bother them for every line of code. In the end, the SME would probably be better off just writing the code themselves.

[From The Problem with Design and Implementation]

Exactly the case! The "SME" knows nothing about tech details and actually makes it more difficult to work sometimes.

REVELATION: [FW]李維史陀 (Levi-Strauss) 摘句

智者不是提供真實的答案的人，智者是問出真實的（或真正的）問題的人。
« Le savant n'est pas l'homme qui fournit les vraies réponses, c'est celui qui pose les vraies questions. »

[From REVELATION: [FW]李維史陀 (Levi-Strauss) 摘句]

Reminds me of How to Ask Questions The Smart Way

No, I won’t fix your computer

No, I won’t fix your computer
我才不要幫你修電腦 No!No!No!No!
No, I won’t fix your computer
我才不要幫你修電腦

[From No, I won’t fix your computer | zonble’s promptbook]

今天下午搭著 Ben 的車從正大廣場扛了曬衣架回家的路上，接到一通電話

「喂～我是某某某(*1)的朋友，我的朋友買了一台 iMac，可是用BT抓檔案速度都是0，請問你何時有空能來幫我們電腦教學？」

我回答

「最近都很忙，10/1以後才會有空，這樣吧，你自己看一下你的軟體設定，網路上都有討論區的」

這位打電話給我的小姐我只見過一兩次面，而且後來也很少聯絡；MSN上會接到她的 MSG 都是問電腦問題，問 iMac 好不好用、Mac 上用 Windows 軟體怎麼辦、Mac 上有沒有某某 Windows 軟體等等，我看了這些問題，覺得如果她都不會自己找電腦 resource，以後一定是一個茶包，所以我後來直接挑明了說：「你還是用PC吧！」

不過看來我給的建議對她來說沒什麼效果，她的朋友還是買了 iMac。

其實我並不太討厭幫人修電腦，但是重要的是要看這個人是誰。

我不太喜歡替長輩修電腦，因為通常長輩的電腦都會有很神祕的問題，那是怎麼修都修不好的，而且長輩都會問一些我無法回答的問題，或是說，很難用簡單的概念回答的問題，例如：『為什麼我的 Windows 一直當機？』『為什麼我的電腦一直中毒？』『為什麼這個軟體會卡住？』長輩的特色就是無法接受電腦並不是完美的，電腦也會壞，軟體也會當機，或者說，they cannot accept that sometimes the problem is between the chair and the keyboard.

我也不太喜歡幫不熟的人修電腦，一來人家的使用習慣我不熟悉，又不能強迫別人主動學習拉裡拉雜的電腦知識，萬一沒修好說不定還會以為我是故意的或是修不好，加上軟硬體環境千變萬化，誰能保證第二天會不會又因為 user 作了什麼事情又不能動了。

所以囉，不熟的這位同學，平常我們也沒有常吃飯碰面唱歌出遊的，說實在也沒多大的交情（某某某，是不是你陷害我的？），一通電話就要我去現場電腦教學，而且還不是你本人的電腦，而是「你的朋友」的電腦，除非你要出一天 US$800 的 consultant fee 囉～

我想，還是請你去網路論壇上找答案吧～

*1：某某某，下次你來上海要請我吃飯壓驚

重點根本不是用什麼拼音

教育部次長呂木琳今天說，政府推動漢語拼音進入第二、三階段，努力營造友善國際生活環境，以韓國為例，韓國境內全是韓文，讓人看不懂，「這不是很友善的環境，應引為借鏡」。

[From 中時電子報｜即時新聞｜推動漢語拼音 營造友善國際生活環境]

這個邏輯看起來就是不通；如果不是記者腦殘，那我真的懷疑我們是怎麼讓這種人當上教育部次長的。

他舉的例子是韓國，「因為韓國都是韓文，我們去韓國都看不懂，這樣不太友善」，那不是應該變成「如果寒果人都把寒果文翻譯成中文，這樣我們去寒果就會覺得比較友善，因為我們看得懂」

依照這樣的邏輯，我們要做的是把僅有中文標示的招牌、指引加註「正確的英文」，而不是推什麼漢語拼音，漢語拼音能做的只是告訴大家某些「名詞」的近似念法，木柵動物園是 Mucha Zoo 還是 MuZha Zoo 或是 Mak-sa Zoo 其實對外國人來說不是太重要，重要的是他要知道那個是個 zoo，他該怎麼方便地靠大眾交通工具到達 zoo。

中國在推廣漢語拼音之後有個笑話，是說上海為了吸引外賓，必須把某個招牌上的說明全篇譯成英文，可是被交代辦事情的人，其實根本不懂英文，也不知道去哪裡找翻譯。所以，他就自作聰明把整個招牌用漢語拼音寫了一次，最好是歪果人這樣看了會懂。

中國用了這麼久的漢語拼音，有因為這樣而變成一個對外國人比較友善的環境嘛？還不是照樣出現「Translate Server Error」

教育部次長有這種邏輯，我們以後會不會看到動物園被標示成「Mu Zha Dong Wu Yuan」，或是「Jin Zhi Hong Deng You Zhuan」？

Jan Chipchase - Future Perfect

But in many instances the cash-poor, slightly savvy consumer wants to own the brand, doesn’t or won’t pay the premium charged so they head to the, usually sizable used/fake/stolen phone market to pick up a bargain.

[From Jan Chipchase - Future Perfect]

This was what I have been saying for the past 15 years about piracy. "If they don't buy the fake, they won't buy the real either", period.

How XML Threatens Big Data : Dataspora Blog

Three Reasons Why XML Fails for Big Data

I. XML Spawns Data Bureaucracy

In its natural habitat, data lives in relational databases or as data structures in programs. The common import and export formats of these environments do not resemble XML, so much effort is dedicated to making XML fit. When more time is spent on inter-converting data — serializing, parsing,translating — than in using it, you’ve created a data bureaucracy.
Indeed, it was what Doug Crockford called “impedance mismatch inefficiencies” that sparked him to create JSON - standardizing Javascript’s object notation as a portable data container.

II. Yes, Size Matters for Data

Size matters for data in a way it does not for documents. Documents are intended for human consumption and have human-sized upper bounds (a lifetime’s worth of reading fits on a thumb drive). Data designed for machine consumption is bounded only by bandwidth and storage.

XML’s expansiveness — for even when compressed, the genie must be let out the bottle at some point — imposes memory, storage, and CPU costs.

III. Complexity Carries a Cost

I never fail to sigh when I open a data file and discover an army of tags, several ranks deep, surrounding the data I need. XML’s complexity imposes costs without commensurate benefits, specifically:

In-line, element-by-element tagging is redundant. Far preferable is stating the data model separately, and using a lightweight delimiter (such as a comma or a tab).

Text tags are purported to be self-documenting, but textual meaning is a slippery thing: it’s rare that one can be sure of a tag’s data type without consulting its DTD (in a separate document).

End-tags support nested structures (such as an aside (within (an aside)). But to facilitate data exchange, flattened out structures are preferable, and arbitrary levels of nesting are best using sparingly.

XML’s complexity inflicts misery on both sides of the data divide: on the publishing side, developers struggle to comply with the latest edicts of a fussy standards group. While data suitors labor to quickly unravel that XML format into something they can use.

[From How XML Threatens Big Data : Dataspora Blog]

xkcd - A Webcomic - Tech Support Cheat Sheet

[From xkcd - A Webcomic - Tech Support Cheat Sheet]

If this is in Chinese, I'd print it out big and hang it on the wall!