The email sent will contain a link to this article, the article title, and an article excerpt (if available). For security reasons, your IP address will also be included in the sent email.
This is a question asked on the
ycombinator list and there are some good responses. I gave a quick response, but I particularly like neilk's knock out of the park insightful answer:
Read Cal Henderson's book. (I'd add in Theo's book and Release It! too)
The center of your design should be the data store, not a process. You transition the data store from state to state, securely and reliably, in small increments.
Avoid globals and session state. The more "pure" your function is, the easier it will be to cache or partition.
Don't make your data store too smart. Calculations and renderings should happen in a separate, asynchronous process.
The data store should be able to handle lots of concurrent connections. Minimize locking. (Read about optimistic locking).
Protect your algorithm from the implementation of the data store, with a helper class or module or whatever. But don't (DO NOT) try to build a framework for any conceivable query. Just the ones your algorithm needs.
Viewing an application as a series of state transitions instead of a blizzard of actions and events is a way under appreciated design perspective. This is one of they key design approaches for making robust embedded systems. A great paper talking about this sort of stuff is Mission Planning and Execution Within the Mission Data System - an effort to make engineering flight software more straightforward and less prone to error through the explicit modeling of spacecraft state. Another interesting paper is CLEaR: Closed Loop Execution and Recovery High-Level Onboard Autonomy for Rover Operations.
In general I call these Fact Based Architectures. I'm really glad neilk brought it up.
Return to Article
