RSS feed [root] /misc /weblog



title search:


Sat Sep 29 13:32:37 HKT 2018


(google search) (amazon search)
download zip of files only

Sat Aug 25 17:06:38 HKT 2012 From /weblog/misc


(google search) (amazon search)

Tue Jul 03 23:25:27 HKT 2012 From /weblog/misc


Most popular articles at first half of 2012 -[..]3_h&elq=261e891d30f543eca821acb24f7eefaf

(google search) (amazon search)

Tue Feb 21 00:24:03 HKT 2012 From /weblog/misc


Listen to Your Community, But Don't Let Them Tell You What to Do

1. 90% of all community feedback is crap.
2. Don't get sweet talked into building a truck.
3. Be honest about what you won't do.
4. Listen to your community, but don't let them tell you what to do.
5. Be there for your community.[..]t-dont-let-them-tell-you-what-to-do.html

(google search) (amazon search)

Tue Jan 31 00:22:59 HKT 2012 From /weblog/misc


A nice overview (with detailed reference) about how computer operate on floating point number -[..]2006/08/12/floating_point_approximation/

Why we should never use float / double for money -

(google search) (amazon search)

Sat Oct 22 23:35:20 HKT 2011 From /weblog/misc


Some tips help you to build effective support -[..]7/03/29/streamline-your-product-support/

Tips for arranging support tasks for agile tasks, look like a separate supporting team is still required -[..]7/12/12/handling-support-in-agile-teams/

Downtime handling -[..]time-today-heres-what-im-doing-about-it/

DevOps movement -[..]lad-dressing-sometimes-you-need-shake-it

(google search) (amazon search)

Sun Oct 16 23:42:53 HKT 2011 From /weblog/misc

theory or practice

Should we work more or should we think more?

Data beats Math, result beats theory? -[..]/jeff_jonas/2011/04/data-beats-math.html

(google search) (amazon search)

Mon Aug 15 00:58:02 HKT 2011 From /weblog/misc


Patent of using internet to support learning -

Patent issue of microsoft and bluej -

(google search) (amazon search)

Sat Jun 04 01:00:40 HKT 2011 From /weblog/misc


Collabrative wise coming from independence thinking -

(google search) (amazon search)

Fri May 06 23:48:13 HKT 2011 From /weblog/misc


How to make customer easy to give feedback

  • Set up a customer advisory program

  • Conduct regular surveys

  • Encourage responses to your email newsletters instead of having the reply-to address go to an unmonitored or nonworking email address

  • Publicize email addresses and phone numbers– customer service, technical support, and even your own personal email address

  • Better yet, make those phone numbers toll free

  • Hand out business cards at trade shows

  • Start a blog and allow comments

  • Add a feedback link on every page on your web site

  • Monitor and post to relevant discussion lists and message boards

  • Encourage your sales staff to provide your contact information directly to customers who want to provide more input

  • Contact people who are talking about your product already — in blogs and on mailing lists — and follow up to get more feedback

  • Every time you talk to a customer, ask them to refer you to someone else who can give you additional feedback, and encourage them to pass your contact information along


Other related blog -[..]onate_users/2007/03/user_community_.html

Some will think non-feedback, uncall feedback are more important -

(google search) (amazon search)

Wed Mar 02 01:04:12 HKT 2011 From /weblog/misc


Confilct between work and working on opensource application -[..]e-project-mean-committing-career-suicide

(google search) (amazon search)

Thu Feb 17 22:14:30 HKT 2011 From /weblog/misc


(google search) (amazon search)

Fri Apr 30 01:40:27 HKT 2010 From /weblog/misc


A detailed overview of POP, IMAP and GMAIL -

The 12 steps to cure e-mail addiction
  1. Admit that e-mail is managing you. Let go of your need to check e-mail every ten minutes.
  2. Commit to keeping your inbox empty.
  3. Create files where you can put inbox material that needs to be acted on.
  4. Make broad headings for your filing system so that you have to spend less time looking for filed material.
  5. 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.
  6. Set a target date to empty your in box. Don't spend more than an hour at a time doing it.
  7. Turn off automatic send/receive.
  8. Establish regular times to review your e-mail.
  9. Involve others in conquering your addiction.
  10. Reduce the amount of e-mail you receive.
  11. Save time by using only one subject per e-mail; delete extra comments from forwarded e-mail, and make the subject line detailed.
  12. Celebrate taking a new approach to e-mail.

I think 5 and 6 is useful...[..]20/email.addiction.steps.reut/index.html

How to control emails? -

(google search) (amazon search)

Sun Feb 14 22:49:40 HKT 2010 From /weblog/misc

treat the developer good

Joey think that developer is the abstraction of a software company, what do you think then?[..]com/articles/DevelopmentAbstraction.html[..]editors/archives/2006/04/happy_home.html

(google search) (amazon search)

Sat Jan 30 12:01:47 HKT 2010 From /weblog/misc


(google search) (amazon search)

Tue Jan 12 17:21:09 HKT 2010 From /weblog/misc


Resource of parsing unstructure data -

Compare and explanation between parsing and regex, 100x performance difference is a big point to notice -[..]/jmd-markdown-and-brief-overview-of.html

(google search) (amazon search)

Tue Jan 12 15:41:54 HKT 2010 From /weblog/misc


How program use memory[..]blog/post/anatomy-of-a-program-in-memory[..]9/12/09/layout-of-a-program-in-memory-2/

(google search) (amazon search)

Wed Nov 11 02:09:58 HKT 2009 From /weblog/misc


Healthcare Information Integration, Considerations for Remote Patient Monitoring -[..]ept_url=/hpc-high-performance-computing/

(google search) (amazon search)

Wed Oct 21 12:23:22 HKT 2009 From /weblog/misc


Some general comment and information about PDF -[..]o-convert-a-word-document-to-a-pdf-file/[..]ist-of-pdf-editing-tools-for-ubuntu.html

(google search) (amazon search)

Tue Sep 29 18:57:43 HKT 2009 From /weblog/misc


How to write good user guide?[..]onate_users/2007/03/the_best_user_t.html

Ron Jeffries' opinions of documentation in XP -[..]s-for-writing-an-effective-tutorial.aspx

(google search) (amazon search)

Sat Sep 19 10:18:46 HKT 2009 From /weblog/misc

architect and developer

Difference between an architect and a developer, also discuss how to be a good developer/architect -

97 Things Every Programmer Should Know -[..].com/wiki/index.php/Edited_Contributions

(google search) (amazon search)

Sat Jan 10 00:26:38 HKT 2009 From /weblog/misc

Rule Engine

* 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.

(google search) (amazon search)

Tue Dec 09 02:06:53 HKT 2008 From /weblog/misc


(google search) (amazon search)

Thu Sep 04 23:33:42 HKT 2008 From /weblog/misc


How to work with wiki -

Arguement about the pros and cons about review and approval process of editing -

(google search) (amazon search)

Thu Jun 12 23:59:07 HKT 2008 From /weblog/misc


ASCII Pronunciation Rules for Programmers -

(google search) (amazon search)

Tue Mar 18 01:25:30 HKT 2008 From /weblog/misc

IT myth

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

(google search) (amazon search)