This implementation uses an indoor solar powered cholesteric LCD screens that read data from your google calendar via IEEE 802.15.4 wireless communication.
This would meet the low power requirements, or you could get one of the eink dev kits and hook that up instead. If you're using gCalendar then you have a prebaked solution, if not you would have to figure that out. Most calendar apps support exporting as iCalendar so that would be a good starting point.
I agree with your approach, but I also combine it with one other step, which Feathers also suggests.
one of the most useful ideas I got from the book was using automated refactoring tools for throw away refactorings in order to understand code. But he also makes the point that automated refactoring tools can be used to tame legacy code, without needing to write tests.
Wrap the legacy code in an api as you describe. As much as possible create suitable tests for it.
Then use the automated refactoring tools provided by your favourite IDE (blah blah blah vi, blah blah blah emacs) to make the changes. Feathers points out that automated refactoring tools are intended to leave behind functionally equivalent code. So in theory you do not need to worry about the refactored code - you can treat it as being the same as the legacy code.
There are some caveats:
- it's only worth doing this for code that you deal with frequently and the you know you are going to have to change at some point
- it takes some time to trust the refactoring tools. Even now I still have a hard time believing that they changed _something_ but I haven't been bitten yet.
- it also takes time and practice to do the automated refactoring. 90% of the time it's extract method or extract interface/class but there's a skill in picking suitable parts out. Practice!
- Do NOT manually edit anything. Only provide method/class names when prompted. Again, this seems counter intuitive, but is necessary. Rely on the automated refactoring tool. Any intervention by you breaks the spell and introduces the risk of error.
- once done, you do need to start looking at unit testing the refactored code, but at least you have something reasonable to work with that you also have some level of trust in.
Slashdot Mirror
You could try doing something like this - http://code.google.com/apis/gdata/articles/radish.html
This implementation uses an indoor solar powered cholesteric LCD screens that read data from your google calendar via IEEE 802.15.4 wireless communication.
This would meet the low power requirements, or you could get one of the eink dev kits and hook that up instead. If you're using gCalendar then you have a prebaked solution, if not you would have to figure that out. Most calendar apps support exporting as iCalendar so that would be a good starting point.
one of the most useful ideas I got from the book was using automated refactoring tools for throw away refactorings in order to understand code. But he also makes the point that automated refactoring tools can be used to tame legacy code, without needing to write tests.
Wrap the legacy code in an api as you describe. As much as possible create suitable tests for it.
Then use the automated refactoring tools provided by your favourite IDE (blah blah blah vi, blah blah blah emacs) to make the changes. Feathers points out that automated refactoring tools are intended to leave behind functionally equivalent code. So in theory you do not need to worry about the refactored code - you can treat it as being the same as the legacy code.
There are some caveats:
- it's only worth doing this for code that you deal with frequently and the you know you are going to have to change at some point
- it takes some time to trust the refactoring tools. Even now I still have a hard time believing that they changed _something_ but I haven't been bitten yet.
- it also takes time and practice to do the automated refactoring. 90% of the time it's extract method or extract interface/class but there's a skill in picking suitable parts out.
Practice! - Do NOT manually edit anything. Only provide method/class names when prompted. Again, this seems counter intuitive, but is necessary. Rely on the automated refactoring tool. Any intervention by you breaks the spell and introduces the risk of error.
- once done, you do need to start looking at unit testing the refactored code, but at least you have something reasonable to work with that you also have some level of trust in.