download here
Thu Mar 25 02:07:15 HKT 2010
From /weblog/design
Date handling look simple but easy to fail in trap. Even worst is this is easy to have bad data which hard to fix. Here is an example - http://blogs.msdn.com/jensenh/archive/2005/11/23/496246.aspx One tip for testing application with time dependence, treat it as random - http://googletesting.blogspot.com[..]pot.com/2008/04/tott-time-is-random.html Explanation of issues of Joda-time, basically it still haven't map the human view of time close enough than machine view of time - http://www.jroller.com/scolebourne/entry/why_jsr_310_isn_t Screencast of how to driven a fluent Date API - http://tedyoung.blogsome.com[..]-apis-in-java-episode-1-comparing-dates/
(google search)
(amazon search)
Thu Mar 11 14:55:11 HKT 2010
From /weblog/design/concurrency
Intel Guide for Developing Multithreaded Applications - http://software.intel.com[..]or-developing-multithreaded-applications Difference ways to stop a thread - http://www.ddj.com[..]ept_url=/hpc-high-performance-computing/ Interesting, I am not sure if I agree, but chrome ( which use fork ) are really cool in performance: There’s another problem with Unix programming in Ruby that I’ll just touch on briefly: Java people and Windows people. They’re going to tell you that fork(2) is bad because they don’t have it on their platform, or it sucks on their platform, or whatever, but it’s cool, you know, because they have native threads, and threads are like, way better anyways.
Fuck that.
Don’t ever let anyone tell you that fork(2) is bad. Thirty years from now, there will still be a fork(2) and a pipe(2) and a exec(2) and smart people will still be using them to solve hard problems reliably and predictably, just like they were thirty years ago.
MRI Ruby people need to accept, like Python (you have seen multiprocessing, yes?), that Unix processes are one of two techniques for achieving reliable concurrency and parallelism in server applications. Threads are out. You can use processes, or async/events, or both processes and async/events, but definitely not threads. Threads are out. http://tomayko.com/writings/unicorn-is-unix
(google search)
(amazon search)
Tue Feb 02 15:07:01 HKT 2010
From /weblog/design
Arguement of overuse interface, I trend to support - http://blog.sidu.in[..]ramming-to-interfaces-strikes-again.html A very long discussion related, Test-friendly, but not caller-friendly? - http://www.nabble.com[..]ring-your-development--t2039307i120.html Comparison of interface vs. abstract class - http://blogs.sun.com[..]ry/api_design_interfaces_versus_abstract Some issue of marker interface, may be annotation can help. However, I don't think those so call issue are really problem, those just poor usage of marker interface - http://java.dzone.com/articles/are-marker-interfaces-dead
(google search)
(amazon search)
Thu Jan 21 01:46:26 HKT 2010
From /weblog/design/IoC
When these containers talk about how they are so useful because they implement "Inversion of Control" I end up very puzzled. Inversion of control is a common characteristic of frameworks, so saying that these lightweight containers are special because they use inversion of control is like saying my car is special because it has wheels. http://www.martinfowler.com[..]ticles/injection.html#InversionOfControl This guy think IoC is going to use is more and more place as GC. However, I will think quit a lot of time IoC is use incorrectly, somebody even try to use it everywhere and replacing constructor... - http://howardlewisship.com[..]endency-injection-mirror-of-garbage.html IMHO jetty is the first widely used program about IoC idea, even before spring - http://kasparov.skife.org/blog/2004/08/30/ Explain when IoC is overkill - http://blog.objectmentor.com[..]010/01/17/dependency-injection-inversion
(google search)
(amazon search)
Wed Jan 06 01:47:53 HKT 2010
From /weblog/design
A Theory of Compatible Versions, and introduction of how and why difference versions are comptible or not - http://www.xml.com/lpt/a/1684 XStream offers some support for refactorings (aliases can help). But very soon you will run into big troubles and will have to make some decisions. Either avoid refactorings (just a little tweak here and there, will weaken your architecture over time) or start implementing workarounds – e.g. custom converters (much work, bad code). - http://blog.cedarsoft.com[..]ts-wrong-with-xstream-and-similar-tools/
(google search)
(amazon search)
Thu Dec 31 00:46:40 HKT 2009
From /weblog/design/interview
Lessons Learned From Java EE’s Evolution, discuss about value of standard and opensource - http://www.infoq.com/presentations/Lessons-Learned-from-Java-EE
(google search)
(amazon search)
Sat Nov 28 18:22:14 HKT 2009
From /weblog/design
A comment about jsch library, discuss about how the author compare this with commerice library, how easy to use, what make it easy or not easy to user, and how to make it easier a nice reading for writing library http://www.logemann.org[..]?permalink=jsch_a_SFTP_java_library.html A simple implementation of cache - http://weblog.plexobject.com/?p=1568 Good examples of bad codes - http://isagoksu.com[..]ike-a-senior-developer-about-clean-code/
(google search)
(amazon search)
Wed Nov 25 01:22:31 HKT 2009
From /weblog/design/distribute
1. Use Cloud for Scaling 2. Use Cloud for Multi-tenancy 3. Use Cloud for Batch processing 4. Use Cloud for Storage 5. Use Cloud for Communication http://horicky.blogspot.com/2009/11/cloud-computing-patterns.html http://horicky.blogspot.com/2009/11/nosql-patterns.html
(google search)
(amazon search)
|