download zip of files only
Fri Dec 14 04:03:17 GMT 2007
From /weblog/design
Show a design of how to write a map that store data at disk and do sorting - http://mattfleming.com/node/53 User friendly sort , "100" should be sort after "10" - http://www.codinghorror.com/blog/archives/001018.html
(google search)
(amazon search)
Wed Dec 12 10:38:08 GMT 2007
From /weblog/design
2007 summary, include discussion about distributed, dsl, arhitecture, XP, ... and many others - http://www.infoq.com/articles/qconsf-2007-summary
(google search)
(amazon search)
Sun Nov 11 15:32:58 GMT 2007
From /weblog/design/interview
The discussion of "Flexibility and Complexity" and "Flexible versus Reusable" answer my long question of how to have flexibility code with simple design. http://www.artima.com/intv/flexplexP.html Another interview - http://www.infoq.com/presentations/modifiability-fowler
(google search)
(amazon search)
Sun Nov 11 15:30:06 GMT 2007
From /weblog/design
Where do you start your design? UI? flow? Data? This is a very interesting discussion about this http://www.theserverside.com/news/thread.tss?thread_id=44883 I think most likely start with UI is better, because it probably representing domain closer
(google search)
(amazon search)
Wed Sep 12 18:01:25 GMT 2007
From /weblog/design
Someone say the basic idea behind transactional memory is that memory is shared by all the threads in a read-only manner. Threads modify data by "committing" objects to shared memory. If a thread commits on top of a dirty object then it has to "rollback" and retry. http://research.sun.com[..]007/2007-08-13_transactional_memory.html http://www.hpcwire.com/hpc/1196095.html
(google search)
(amazon search)
Thu Aug 09 17:59:30 GMT 2007
From /weblog/design/interview
Erich Gamma: A pattern is always a problem-solution pair that can be applied in a particular context. Although the solutions might look similar in different patterns, the problems they are solving are different. In fact from ten thousand meters most patterns solve a problem by adding a level of indirection. What is interesting is how this indirection comes about and in particular why it needs to happen. Therefore if you just look at the solution to the problem, it isn't that enlightening and everything starts to look the same. When we wrote design patterns we often had this feeling??hey all started to look like the Strategy pattern. http://www.artima.com/lejava/articles/patterns_practice.html
(google search)
(amazon search)
Thu Jul 12 11:35:52 GMT 2007
From /weblog/design/IoC
Discuss the problem of using springs framework, it mainly complaint about the complication of spring, I will think people know what they are using, if it is too complex, just pick other http://crazybob.org/2006/01/i-dont-get-spring.html Another discussion complaint about spring - http://www.theserverside.com[..]_id=46041&asrc=EM_NLN_1757981&uid=703565 Some counter opinions to those complaints - http://jroller.com/page/wiradikusuma?anchor=5_reasons_why_i_won
(google search)
(amazon search)
Thu Jul 12 08:20:21 GMT 2007
From /weblog/design/exception
Mostly agree, however, why do we need NoSuchMethodException? Why we don't just don't implement that method? If this is required by the interface, why we implement an interface but not complete the contact? http://today.java.net[..]/06/exception-handling-antipatterns.html http://softarc.blogspot.com[..]06/exception-handling-anti-patterns.html
(google search)
(amazon search)
Wed Jun 13 17:14:39 GMT 2007
From /weblog/design/exception
Checked or unchecked? Not sure, seen all exception is unchecked are ok for me To summarize Java orthodoxy: checked exceptions should be the norm. Runtime exceptions indicateprogramming errors. I used to subscribe to this view. However, after writing and working with thousands of catch blocks, I've come to the conclusion that this appealing theory doesn't always work in practice. I'm not alone. Since developing my own ideas on the subject, I've noticed that Bruce Eckel, author of the classic book Thinking in Java, has also changed his mind. Eckel now advocates the use of runtime exceptions as the norm, and wonders whether checked exceptions should be dropped from Java as a failed experiment http://www.mindview.net/Etc/Discussions/CheckedExceptions Other discussion of checked or unchecked - http://www.theserverside.com/news/thread.tss?thread_id=35586 http://www.infoq.com[..]2007/05/removing-java-checked-exceptions
(google search)
(amazon search)
Sun Apr 15 11:26:55 GMT 2007
From /weblog/design/interview
Interview of netbean developers, I feel this is a lot more promotion than sharing of technology. However, these still valuable - http://blogs.sun.com[..]ree_interviews_with_language_programmers
(google search)
(amazon search)
Tue Feb 27 04:31:48 GMT 2007
From /weblog/design/exception
This blog discuss the code at finally can affect code at catch block - http://mult.ifario.us/articles/2006/07/26/java-brain-teaser ExternalResource resource = resourceManager.open(); Throwable e1 = null; try { // Use the resource (stream, db connection, ...) } catch (Throwable e) { e1 = e; } finally { try { resource.close(); if (e1 != null) throw e1; } catch (Throwable e2) { // Pretend e2 doesn't already have a cause... if (e1 != null) e2.initCause(e1); throw e2; } } http://bagotricks.com[..]06/02/06/dropping-the-ball-er-exception/ or this, can be better looking try { InputStream is = new FileOutputStream("hello.txt"); try { is.write("hello"); finally { is.close(); } } catch (IOException e) { e.printStrackTrace(); }
http://jroller.com/page/davinci?entry=finally_in_catch
(google search)
(amazon search)
Thu Oct 12 07:52:27 GMT 2006
From /weblog/design
A great reading of the fundamental design decision: inherence or composition? http://groups.yahoo.com/group/extremeprogramming/message/67018 Delegation means that you include an instance of another class as an instance variable, and forward messages to the instance. It is often safer than inheritance because it forces you to think about each message you forward http://www.norvig.com/java-iaq.html#del2
(google search)
(amazon search)
Thu Oct 12 07:49:07 GMT 2006
From /weblog/design/interview
Have anyone read "Effective Java"? Compare the "item 10: Override clone judiciously" with this interview is fun http://www.artima.com/intv/issuesP.html No perfect design because we need difference design trade off for difference task, like performance, time, resource, .... No perfect design because difference user have difference expectation of API .... No perfect design because requirement change by time http://www.artima.com/intv/perfect.html
(google search)
(amazon search)
Thu Oct 12 07:48:27 GMT 2006
From /weblog/design/interview
*Dave Thomas*: You have to accept the fact that you're not going to get it right the first time. And you're not going to get it perfectly right the second or third time. You'll never get it perfectly right, but along the way you can get better and better . To do that, you have to discipline yourself to apply a reflective process to what you do. *Bill Venners*: What do you mean by reflective process? *Dave Thomas*: You always have to look back at what you did and ask, "How did I do that? Could I have done it better? Did I have to do it at all?" Get into the habit of doing that with everything you do. That way, you're consciously forcing yourself to reevaluate the way you do things. Full message: http://www.artima.com/intv/metadataP.html
(google search)
(amazon search)
|