Exposing a service over HTTP does not make it REST.

Quoted: However, I think most people just make the mistake that it should be simple to design simple things. In reality, the effort required to design something is inversely proportional to the simplicity of the result. As architectural styles go, REST is very simple.

Quoted: REST is software design on the scale of decades: every detail is intended to promote software longevity and independent evolution. Many of the constraints are directly opposed to short-term efficiency. Unfortunately, people are fairly good at short-term design, and usually awful at long-term design. Most don’t think they need to design past the current release. There are more than a few software methodologies that portray any long-term thinking as wrong-headed, ivory tower design (which it can be if it isn’t motivated by real requirements).

Quoted: I've ported the Processing visualization language to JavaScript, using the Canvas element. The first portion of the project was writing a parser to dynamically convert code written in the Processing language, to JavaScript. This involves a lot of gnarly regular expressions chewing up the code, spitting it out in a format that the browser understands.

Quoted: Many people think of Operations as "a bunch of boring work... which I'm hoping someone else is doing." It often takes less time to set up a development environment than the tools and infrastructure needed to test, deploy, monitor, and scale new software. The survival of most projects depend on working software, at least initially, and so if there is money or time many people will spend it on development. Unfortunately, people say they will "figure that ops stuff out soon", but what they mean is "when we're totally screwed!!!" It doesn't have to be that way...

Some interesting points from Martin Fowler a few years ago on XP, patterns, design, etc. Was worth skimming through quickly.

Quoted: "enabling practices of continuous integration, testing, and refactoring, provide a new environment that makes evolutionary design plausible"

Quoted: "don't want to spend effort adding new capability that won't be needed until a future iteration. And even if the cost is zero, you still don't want to it because it increases the cost of modification even if it costs nothing to put in."

Quoted: " * Invest time in learning about patterns
* Concentrate on when to apply the pattern (not too early)
* Concentrate on how to implement the pattern in its simplest form first, then add complexity later.
* If you put a pattern in, and later realize that it isn't pulling its weight - don't be afraid to take it out again."

Quoted: "First keep in mind what you're drawing the diagrams for. The primary value is communication. Effective communication means selecting important things and neglecting the less important.
* keep them short
* don't try to address all the details (just the important ones)
* treat the resulting design as a sketch, not as a final design
"

dot from jacob

Quoted: Every programmer with a few years' experience or education has heard the phrase "premature optimization is the root of all evil." This famous quote by Sir Tony Hoare (popularized by Donald Knuth) has become a best practice among software engineers. Unfortunately, as with many ideas that grow to legendary status, the original meaning of this statement has been all but lost and today's software engineers apply this saying differently from its original intent. As computer systems increased in performance from MHz, to hundreds of MHz, to GHz, the performance of computer software has taken a back seat to other concerns. Today, it is not at all uncommon for software engineers to extend this maxim to "you should never optimize your code!" Funny, you don't hear too many computer application users making such statements. It is unfortunate that Hoare's comments have been twisted to imply that optimization is unnecessary.

Redot from jacob

Alexander's "Notes on the Synthesis of Form" was insightful, don't know why I haven't picked up and read "The Timeless Way of Building"