Design Patterns in Dynamic Programming

Peter Norvig's presentation

Tags Database Schemas

analysis here
flickr architecture here

Containers and WebApplications

from here:
NanoWar works by having a hierarchy of containers, one at the application scope, one in each session whose parent is the application container, and one is created for each request with the parent as the appropriate session container.
...
This model allows for stateful components in the meaningful scopes -- if you have session state, it is stored in a component scoped to the session. Actions can be stored at any level -- stateless ones (a la Struts or SpringMVC) may be defined in the application level scope, one-off actions (a la WebWork) can be defined in the request scope container. Wizard style ones (if you don't have a concept of wizard scope) can be session scoped, and use a state machine to figure out what is next.

Could Rails have been built without Ruby?

from here

Nice discussion about dynamic/static typing,
LISP-like languages, metaprograming, design patterns.

"..in the OO world you hear a good deal about "patterns." I wonder if these patterns are not sometimes evidence of case (c), the human compiler, at work. When I see paterns in my programs, I consider it a sign of trouble. The shape of a program should reflect only the problem it needs to solve. Any other regularity in the code is a sign, to me at least, that I'm using abstractions that aren't powerful enough - often that I'm generating by hand the expansions of some macro that I need to write."

"Code Complete" Quotes

"A software metaphor is more like a searchlight than a road map. It doesn't tell you where to find the answer, it tells you how to look for it."

"When you look at the architecture, you should be pleased by how natural and easy the solution seems. It shouldn't look as if the problem and the architecture have been force together with duct tape"

"You might think of the lines between subsystems as being hoses with water running through them. If you want to reach in and pull out a subsystem, that subsytem is going to have some hoses attached to it. The more hoses you have to disconect and reconnect, the more wet you're going to get. You want to architect your system so that if you pull out a subsystem to use elsewhere, you won't many hoses to reconnect and those hoses will reconnect easily"

"A class is a lot like an iceberg: 7/8 is under water, and you can see only the 1/8 that's above the surface"
-- Steve McConnell

Pico Container Good Citizens

What is a good citizen in OO:

from here

As a good citizen, I...

• Keep a consistent state at all times - init() or populate() is a code smell.
• Have no static fields or methods
• Never expect or return null.
• FailFast - even when constructing.
• Am Easy to test- all dependent object I use can be passed to me, often in my constructor (typically as Mock Objects).
• Accept dependent object that can easily be substituted with Mock Objects (I don't use Concrete Class Dependency).
• Chain multiple constructors to a common place (using this(...)).
• Always define hashCode() alongside equals()
• Prefer immutable value objects that I can easily throw away.
• Have a special value for 'nothing' - e.g. Collections.EMPTY_SET.
• Raise checked exceptions when the caller asked for something unreasonable - e.g. open a non-existant file.
• Raise unchecked exceptions when I can't do something reasonable that the caller asked of me - e.g. disk error when reading from an opened file.
• Only catch exceptions that can be handled fully.
• Only log information that someone needs to see.

Classes that are designed for Constructor Injection are better citizens than those that are not.

txt2tags

PicoContainerBook and txt2tags.
txt2tags seems perfect for small-scale, revision controlled, documentation.

Java is not a framework language

Extended Abstract, Poster

More at Dragos Manolescu's Writings