Fri Apr 30 01:40:27 HKT 2010
From
/weblog/misc
A detailed overview of POP, IMAP and GMAIL -
http://www.macdevcenter.com/lpt/a/6702 The 12 steps to cure e-mail addiction
- Admit that e-mail is managing you. Let go of your need to check e-mail every ten minutes.
- Commit to keeping your inbox empty.
- Create files where you can put inbox material that needs to be acted on.
- Make broad headings for your filing system so that you have to spend less time looking for filed material.
- Deal immediately with any e-mail that can be handled in two minutes or less but create a file for mails that will take longer.
- Set a target date to empty your in box. Don't spend more than an hour at a time doing it.
- Turn off automatic send/receive.
- Establish regular times to review your e-mail.
- Involve others in conquering your addiction.
- Reduce the amount of e-mail you receive.
- Save time by using only one subject per e-mail; delete extra comments from forwarded e-mail, and make the subject line detailed.
- Celebrate taking a new approach to e-mail.
I think 5 and 6 is useful...
http://www.cnn.com[..]20/email.addiction.steps.reut/index.html How to control emails? -
http://www.russellbeattie.com/notebook/1008869.html
(google search)
(amazon search)
Tue Jan 12 17:21:09 HKT 2010
From
/weblog/misc
Resource of parsing unstructure data -
http://discuss.joelonsoftware.com/default.asp?design.4.598330 Compare and explanation between parsing and regex, 100x performance difference is a big point to notice -
http://www.cforcoding.com[..]/jmd-markdown-and-brief-overview-of.html
(google search)
(amazon search)
Wed Nov 11 02:09:58 HKT 2009
From
/weblog/misc
Healthcare Information Integration, Considerations for Remote Patient Monitoring -
http://www.ddj.com[..]ept_url=/hpc-high-performance-computing/
(google search)
(amazon search)
Sat Jan 10 00:26:38 HKT 2009
From
/weblog/misc
* It does seem that it's important to limit the number of rules, indeed any system with enough rules to need sophisticated algorithms to get good performance probably has too many rules to be understood.
* Similarly I'm inclined to think one should be wary of rules that do a lot of chaining.
* As in many places, testing is often undervalued here, but implicit behavior makes testing more important - and it needs to be done with production data.
* While building a rules system, I'd look to do things that would cause EarlyPain with modifications of the rule base.
http://martinfowler.com/bliki/RulesEngine.html
(google search)
(amazon search)
Thu Sep 04 23:33:42 HKT 2008
From
/weblog/misc
How to work with wiki -
http://www.oreillynet.com/lpt/a/6646 Arguement about the pros and cons about review and approval process of editing -
http://martinfowler.com/bliki/WikipediaDeath.html
(google search)
(amazon search)
Tue Mar 18 01:25:30 HKT 2008
From
/weblog/misc
IT Myth 1: Server upgrades matter
Reality: Don’t pay extra for upgradability; you’ll never need it
IT Myth 2: Eighty percent of corporate data resides on mainframes
Reality: Try 50 percent, or even less
IT Myth 3: All big shops run multiple platforms
Reality: This 'myth' is closer to fact than fiction
IT Myth 4: CIOs and CTOs have a greater need for business savvy than tech expertise
Reality: Tech chops matter more than ever
IT Myth 5: Most IT projects fail
Reality: It all depends on how you define failure
IT Myth 6: IT doesn't scale
Reality: Virtually any technology is scalable, provided you combine the right ingredients and implement them effectively
http://www.infoworld.com/infoworld/reports/33SRmythsofit.html
(google search)
(amazon search)
Tue Mar 18 01:25:30 HKT 2008
From
/weblog/misc
Another notice about shuffling collection with random order -
http://www.codinghorror.com/blog/archives/001008.html with detailed analysis-
http://www.codinghorror.com/blog/archives/001015.html unique => not statistically independent and not uniformly distributed,
cannot be generated by normal Random Number Generator.
You may consider way like shuffling (for example, put 100 integer into an
ArrayList, calls Collections.shuffle(), get the numbers sequentially).
Most of the time unique random number can be replaced by hashCode() of
something because hash seldom (at order of magnitude 10^-100 for MD5) crash,
if you don't require it to be "ALWAYS" unique, you may consider hashCode()
as well.
"BlueJean"
撰寫於郵件新聞:4305552c$1@news.3home.net...
>> Hi Hi,
>>
>> I would like to write a method to generate a number of random and unique
>> number. I try to do it myself as following. It's work but seem to be
>> stupid.
>>
>> I try to found it at java.util.Random API but I didn't found out a better
>> solution. Please comment. Many thx
>>
>> Random generator = new Random();
>> Vector randomVec = new Vector();
>>
>> int r = 0;
>>
>> try {
>> do {
>> r = generator.nextInt(100);
>>
>> if (!randomVec.contains(new Integer(r).toString())) {
>> randomVec.addElement(new Integer(r).toString());
>> j++;
>> }
>> } while (j < 20);
>> } catch (Exception e) {
>> e.printStackTrace();
>> }
(google search)
(amazon search)