www.carfield.com.hk: design

Have read this article long time before: http://www.martinfowler.com/ieeeSoftware/failFast.pdf However, the more I work on programming the more I find that reasonable default (may be with logging) work better in some cases, but really need to beware about the cost of debugging if there is problem....

Another discussion about failfast vs. failsafe - http://www.certpal.com[..]009/09/iterators-fail-fast-vs-fail-safe/

(google search) (amazon search)

Sat Sep 19 01:37:37 HKT 2009 From /weblog/design

concept

http://www.butunclebob.com[..].UncleBob.ArchitectureIsaSecondaryEffect

sunday-school truth: if you don't do well in small think, you will do worse at big thing: http://udidahan.weblogs.us/archives/035032.html

Wait for best solution - http://www.threeriversinstitute.org/blog/?p=374

(google search) (amazon search)

Sun Sep 13 00:33:22 HKT 2009 From /weblog/design

language

Issues of annotation dependence test framework, usually new language feature come out to solve some problem people get excited. However people found that the problem it bring are not less than the problem it solve, it take time to proof the value - http://jroller.com[..]tmotion?entry=annotations_suck_a_lot_and

Compare OO feature of difference language - http://www.derangedcoder.net[..]ral/comparingObjectOrientedFeatures.html

Comparing C# and Java - http://www.25hoursaday.com/CsharpVsJava.html

Discussion about extending standard API - http://www.codinghorror.com/blog/archives/001151.html

Few good suggestion when thinking of design a language, Consider using ML, Don't be afraid of being the same - http://www.plsadventures.com[..]programming-language-design-is-hard.html

(google search) (amazon search)

Sun Sep 13 00:05:27 HKT 2009 From /weblog/design

delete

I think there's perfectly reasonable scenarios for both soft and hard deletes, with and without audit trails.

1. Soft delete:
A user signs off of your service, but you need to keep (anonymized) stats data consistent for your customers - here you cannot remove the entire user, you just blank his personal data (name, email, phone, ...) and keep the anonymized statistical data (country, birth year, profession).

2. Soft (or super-soft) delete with audit trail:
Any financial transaction data, even if entered by error, may only be corrected by adding a correction entry, not by deleting the erroneous entry, or the IRS will be all over you. So either you flag it as deleted (soft delete) or you correct it by adding another entry ("super-soft delete").

3. Hard delete with audit trail:
A user unsubscribes from your newsletter. No need to keep the info "he once was subscribed to it" in the live database, but need to keep the info somewhere accessible in case he sues you for spamming and you can prove "but back in August when you got the mail, you were still subscribed".

4. Hard delete with no audit trail:
Personal data as in #1 if your local data protection laws require. (This means *no* more storing, *anywhere*, technically speaking not even in last month's backup, but that's another issue altogether.)

http://ayende.com/Blog/archive/2009/08/30/avoid-soft-deletes.aspx

And Udi think is real life, people usually never really delete something - http://www.udidahan.com/2009/09/01/dont-delete-just-dont/

(google search) (amazon search)

Sat Sep 12 15:54:31 HKT 2009 From /weblog/design/distribute

distribute

In one sentence, here's why: humans are notoriously bad at keeping "self" distinct from "other". Egomania, projection (transference), and enmeshment are well-known symptoms of this problem. OK, so I hear you saying, "yeah, but what does this have to do with programming?" It certainly seems absurd to suggest that if we are bad at something we know the most about (our "selves"), how could we possibly say that we have a good approach for the programming analogues - objects, modules, etc. - http://www.artima.com/weblogs/viewpost.jsp?thread=46706

Argue why space base design is better than n-tier design - http://www.google.com[..]0The%20End%20of%20Tier-based%20Computing

Some key research of google for distributed computation - http://www.infoq.com/news/2007/06/google-scalability

Someone think we are not yet (per Oct 2007) have good language support for distibuted computing - http://kasparov.skife.org/blog/2007/10/11/

A blog contain a lot distributed computing information - http://www.highscalability.com/

How Wikipedia manage their site - http://dammit.lt/uc/workbook2007.pdf

Google tutorial for Design Distributed System - http://code.google.com/edu/parallel/dsd-tutorial.html

http://en.wikipedia.org/wiki/Distributed_hash_table

The Hadoop Distributed File System: Architecture and Design - http://hadoop.apache.org/core/docs/r0.18.0/hdfs_design.html

http://www.metabrew.com[..]-a-list-of-distributed-key-value-stores/

(google search) (amazon search)

Thu Sep 03 00:28:22 HKT 2009 From /weblog/design

composition over inheritance

Good example of composition over inheritance - http://www.javablogging.com/comparable-vs-comparator/

(google search) (amazon search)

Sat Aug 08 13:58:17 HKT 2009 From /weblog/design/distribute

scalability

There are two key primary ways of scaling web applications which is in practice today.
1) “Vertical Scalability” - Adding resource within the same logical unit to increase capacity. An example of this would be to add CPUs to an existing server, or expanding storage by adding hard drive on an existing RAID/SAN storage.
2) “Horizontal Scalability” - Adding multiple logical units of resources and making them work as a single unit. Most clustering solutions, distributed file systems, load-balancers help you with horizontal scalability.

Scalability can be further sub-classified based on the “scalability factor”.
1) If the scalability factor stays constant as you scale. This is called “linear scalability“.
2) But chances are that some components may not scale as well as others. A scalability factor below 1.0 is called “sub-linear scalability“.
3) Though rare, its possible to get better performance (scalability factor) just by adding more components (i/o across multiple disk spindles in a RAID gets better with more spindles). This is called “supra-linear scalability“.
4) If the application is not designed for scalability, its possible that things can actually get worse as it scales. This is called “negative scalability“.

http://www.royans.net/arch/2007/09/22/what-is-scalability/

Report of building web application with 55k pageload with rail - http://shanti.railsblog.com[..]mongrels-handled-a-550k-pageview-digging

XMPP a IM protocol about scalability - http://www.process-one.net[..]icle/the_aol_xmpp_scalability_challenge/

Presentation and resources of making you website more scalable - http://www.scribd.com[..]9/Real-World-Web-Performance-Scalability http://www.theserverside.com[..]lications&asrc=EM_NLN_3990118&uid=703565 http://www.theserverside.com[..]ionsPart2&asrc=EM_NLN_3990119&uid=703565

Brian Zimmer, architect at travel startup Yapta, highlights some worst practices jeopardizing the growth and scalability of a system:
* The Golden Hammer. Forcing a particular technology to work in ways it was not intended is sometimes counter-productive. Using a database to store key-value pairs is one example. Another example is using threads to program for concurrency.
* Resource Abuse. Manage the availability of shared resources because when they fail, by definition, their failure is experienced pervasively rather than in isolation. For example, connection management to the database through a thread pool.
* Big Ball of Mud. Failure to manage dependencies inhibits agility and scalability.
* Everything or Something. In both code and application dependency management, the worst practice is not understanding the relationships and formulating a model to facilitate their management. Failure to enforce diligent control is a contributing scalability inhibiter.
* Forgetting to check the time. To properly scale a system it is imperative to manage the time alloted for requests to be handled.
* Hero Pattern. One popular solution to the operation issue is a Hero who can and often will manage the bulk of the operational needs. For a large system of many components this approach does not scale, yet it is one of the most frequently-deployed solutions.
* Not automating. A system too dependent on human intervention, frequently the result of having a Hero, is dangerously exposed to issues of reproducibility and hit-by-a-bus syndrome.
* Monitoring. Monitoring, like testing, is often one of the first items sacrificed when time is tight.

http://highscalability.com/scalability-worst-practices

Useful Corporate Blogs that Talk About Scalability - http://highscalability.com[..]l-corporate-blogs-talk-about-scalability

Overview of mapreduce and how it compare with other distributed programming model -http://natishalom.typepad.com[..]0/is-mapreduce-going-to-main-stream.html

Paper of data store at amazon http://www.allthingsdistributed.com/2007/10/amazons_dynamo.html

Discuss how haven't sync can cause performance issue - http://www.theserverside.com[..]lications&asrc=EM_NLN_6273194&uid=703565 http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6423457

Discussion about Cloud Based Memory Architectures - http://highscalability.com[..]ased-memory-architectures-next-big-thing

http://highscalability.com[..]alability-and-performance-best-practices

(google search) (amazon search)

Sat Aug 01 20:13:46 HKT 2009 From /weblog/design

write shy code

Writing shy code is just a small start at preventing the introduction of bugs, but it really helps. Just as in the real world, good fences make good neighbor - as long as you don't peek through them.

http://www.computer.org/software/homepage/2003/s1const.htm
http://www.pragmaticprogrammer.com/ppllc/papers/1998_05.html

Other than that, there is also security risk if you show too much to other - http://www.indicthreads.com[..]_or_objects_java_security_problem_1.html

An example of why passing Map around is wrong and show solution of that example - http://antagonisticpleiotropy.blogspot.com[..]spot.com/2008/01/hashmap-temptation.html

Quoting from Getting Method in Beck’s 1997 Smalltalk Best Practice Patterns (emphasis his): “Here’s the real secret of writing good Getting Methods - make them private at first. I cannot stress this enough. … There are cases where you will publish the existence of Getting Methods for use in the outside world. You should make a conscious decision to do this after considering all the alternatives. It is preferable to give an object more responsibility, rather than have it act like a data structure.”
Quoting from Setting Method: “Everything I said once about Getting Methods, I’d like to say twice about Setting Methods. Setting Methods should be even more private. It is one thing for another object to tear out your state, it is quite another for it to bash in a new state.”

http://tech.groups.yahoo.com[..]om/group/domaindrivendesign/message/5701

East: Clean and DRY, an example of why tell don't ask help - http://jamesladdcode.com/?p=294

(google search) (amazon search)

Sat Jun 20 11:12:11 HKT 2009 From /weblog/design

work with legace

Simple ways to improve legacy code - http://www.onjava.com/lpt/a/4805

One approach to work with legacy code, instead of phrase by phrase or part by part, identify and improve the domain part first - http://gojko.net[..]-efforts-to-replace-legacy-systems-fail/

(google search) (amazon search)

Wed Jun 10 01:14:06 HKT 2009 From /weblog/design

dsl

A paper show the evolution of a DSL - http://www.mockobjects.com/files/evolving_an_edsl.ooplsa2006.pdf

A stock trading order example of DSL - http://debasishg.blogspot.com[..]05/designing-internal-dsls-in-scala.html

What is the difference between API / DSL if we don't write a parser for our language? From Martin Fowler's blog - http://martinfowler.com/bliki/DslReadings.html , it is mentioned:

Piers Cawley makes the point that a key characteristic of DSLs is their narrow focus on a domain.

I think this is a very good summary, usually if most of the APIs are getXXX() , setXXX(), loadXXX() , createXXX() ........ Then we mostly design APIs that expose low level detail to the API user to work on, which, is work but user probably work nicer if we can come up with language like API that allow users to do their work in more descriptive level.

I think if API design like that usually it will reduce the code duplication, what ever real duplication or conceptual duplication. It probably already apply "Tell, don't ask" style - http://c2.com/cgi/wiki?TellDontAsk

A discussion about applying "Tell, don't ask" which lead to message passing architecture - http://beautifulcode.oreillynet.com[..]07/10/do_messages_want_to_be_asynchr.php

And other discussion about "Tell, don't ask"
http://sriramnarayan.blogspot.com[..]/2008/11/demeters-law-tell-dont-ask.html
http://sriramnarayan.blogspot.com[..]part-two-demeters-law-tell-dont-ask.html
http://sriramnarayan.blogspot.com[..]rt-three-demeters-law-tell-dont-ask.html

One good sample with explaination -
http://hamletdarcy.blogspot.com[..]-it-really-domain-specific-language.html
http://nat.truemesh.com/archives/000727.html

Few links - http://dreamhead.blogbus.com/logs/17667876.html

From CRUD to DDD - http://www.udidahan.com[..]2/15/from-crud-to-domain-driven-fluency/

I like this: "XML abuse reduction (conducting an “XML Intervention”)" - http://www.lostechies.com[..]ps-internal-dsl-draft-outline-notes.aspx

(google search) (amazon search)

Tue May 26 00:50:58 HKT 2009 From /weblog/design/pattern

OO Design

http://g.oswego.edu/dl/ca/ca/ca.html

(google search) (amazon search)

Sat May 02 03:04:24 HKT 2009 From /weblog/design

Architecture

Top Ten Software Architecture Mistakes - http://www.infoq.com/news/2007/10/top-ten-architecture-mistakes

Discussion about the balance of upfront design - http://blog.objectmentor.com[..]4/25/the-scatology-of-agile-architecture

(google search) (amazon search)

Mon Apr 06 01:46:53 HKT 2009 From /weblog/design

immutability

Java Immutability - http://www.theserverside.com[..]_id=50161&asrc=EM_NLN_4133229&uid=703565

"A similar pattern is that with objects that you need to open before usage and make sure that they are closed on usage completion."

http://digerati-illuminatus.blogspot.com[..]2/initialize-pattern-and-open-close.html

Discussion of various approach that implement immutable class - http://discuss.joelonsoftware.com/default.asp?design.4.601499

(google search) (amazon search)

Fri Feb 06 00:22:30 HKT 2009 From /weblog/design

logging

http://www.codemonkeyism.com[..]08/12/16/7-good-rules-to-log-exceptions/ - look obvious but a lot of program still make those mistakes.

Do you prefer log more or log smarter? It is good to log smart but if you log more, even if you not smart enough, you still have the data. - http://www.codinghorror.com/blog/archives/001192.html

Basic log techniques - http://www.ddj.com/cpp/212902973?cid=RSSfeed_DDJ_All

(google search) (amazon search)

Thu Jan 29 01:09:55 HKT 2009 From /weblog/design

DTO

http://mrpmorris.blogspot.com/2009/01/data-transfer-objects.html

(google search) (amazon search)

1 2 3 4 5 6