2010年1月26日星期二

Share Two Google Calendar App

Calendars
1) Daily English
ID
gfn0kpsechk859laf5effn31uo@group.calendar.google.com
preview
http://www.google.com/calendar/embed?src=gfn0kpsechk859laf5effn31uo%40group.calendar.google.com&ctz=Asia/Shanghai


2) Beijing Weather
ID
oiio53f5pflo33a3nd328gfics@group.calendar.google.com
preview
http://www.google.com/calendar/embed?src=oiio53f5pflo33a3nd328gfics%40group.calendar.google.com&ctz=Asia/Shanghai

How to use
step 1
go to your Google Calendar and paste the ID above into the text box title with "Add a friend's calendar" at left;
step 2 (optional)
Add SMS as a Notification for the calendar, then you can receive Daily English/Beijing Weather everyday!

Copyright
Daily English piped from dict.cn
Beijing Weather fetched from weather.com.cn

More
Tell me what you want, I'm pleasure to pipe it into your SMS :)

2010年1月24日星期日

Ubuntu 9.10 remember last boot choice

http://ubuntuforums.org/showthread.php?t=1195275

step 1
sudo gedit "/etc/default/grub"
change
"GRUB_DEFAULT=0"
to
"GRUB_DEFAULT=saved"

step 2
sudo update-grub

step 3
reboot

2010年1月17日星期日

Reading about Refactoring

I'm reading a book about refactoring these days, and found some good points useful in my work.
1. Definition
Refactor do not change any observable behavior of software
//But new features are needed, they are mixed in time, but should not mixed in mind. They are two things!
//Programmers should never add any new feature without PM design while refactoring.
2. Aim
Improving the design
//Performance
//Data Consistency
//Reuse the logic
Make the code easy to understand
//Not easy, because the logic is really complicated sometimes. We should try.
Find bugs
//Clarifying the assumptions of each unit!
Move on fast
//Decayed design is a huge burden. Without it, we can move fast!
3. When and when not
Three strikes and you refactor.
//I used to refactor at two strike, and always find it unnecessary in the end.
Right time: adding new features, fixing bugs, doing a code review
Wrong time: Need to rewrite, near to deadline
//Stop refactoring on branch since staging release
4. Limitation
DB, interface
//change them carefully. Data migration is always dangerous. Other team depend on your interface, so if you change it, they have to change!
Design
//The feature design is sometimes lead to bad structure of program. Engineers are obliged to reduce the bad design.
5. Bad smell
Long parameters list
//Erlang program is easy to be writen into these style
Switch statement instead of polymorph
//Erlang has no switch, it is good! I love polymorph
Lazy class
//Someone loves it, but I never use it
Use member fields as global variable
//I hate it very much, although I do it sometimes
//Member fields are state of an instance, rather than a basket holding the mess you do not know where to put it.
Data classes
//All the time I wish all small data struct can be thrown into protobuf, but sometimes they need quick lookup or other functions. It is difficult to trade off.
6. Test
When you get a bug report, start by writing a unit test that expose the bug.
//I'm not sure if all the refactoring can be covered by unit test. I love TDD, however, I find it hard to maintain the unit tests because the inner interfaces changed frequently. Unit tests turn from my proud into my burden that I have to change accordingly. So I think writing too much unit test is not a good idea. Today I agree that unit tests have two major purpose: 1) Code coverage, 2) reported bugs coverage

2010年1月5日星期二

2010 Resolution

Many resolutions around, even a generator was found:p

My wish list this year

Healthy
Weekly sweat
Gain weight
Tech
Expert in Linux Shell/Python/C++
Get start with Design Pattern
Sci
Keep on following Recommendation Algorithms
Get start with Microeconomics
Sandbox
Dig into App Engine/GData
Popularize my Blog