"I’ve been analyzing my process (and the process of those around me) and figuring out how best to structure code for projects on a larger scale. What I've found is a process that works equally well for sites small and large.

Learn how to structure your CSS to allow for flexibility and maintainability as your project and your team grows."

"While the term “DOM scripting” really just refers to the use of scripts (in this case, Javascripts) to access the Document Object Model, it has widely become accepted as a way of describing what should really be called “unobtrusive DOM scripting”—basically, the art of adding Javascript to your page in such a way that if there were NO Javascript, the page would still work (or at least degrade gracefully). In the website world, our DOM scripting is done using Javascript."

"You already have geniuses working on your infrastructure.  Listen to them.  This article is for people who don’t have any option between “code runs on developer’s laptop” and “code runs in production.”"

"In the present article we emphasize the importance of modeling time in the context of agent-based models. To this end, we present a (selective) survey of the Cellular Automata-literature on updating and draw parallels to the issue of agent activation in agent-based models. By means of two simple models, Schelling's segregation model and Epstein's demographic prisoner's dilemma we investigate the influence of choosing different regimes of agent activation. Our experiments indicate that timing is not a critical issue for very simple models but bears huge influence on model behavior and results as soon as the degree of complexity increases only so slightly. After a brief review of the way commonly used ABM simulation environments handle the issue of timing, we draw some tentative conclusions about the importance of timing and the need for more research towards that direction, similar to the concerted effort on updating in cellular automata."

"Work out which bits of the system you know least about. Create the scenarios and have conversations around those bits of the system. You don’t have to grow the system from the beginning – you can pick any point you like! Which bits of the system make you most uncomfortable? Which bits make your stakeholders most uncomfortable?"

"This memo considers three radical ideas applying to the Web, not necessarily as serious proposals (although given support they could be turned into such) but as thought experiments or fantasies meant to sharpen the discussion of the "meaning" of URIs and other current issues of web architecture. The first fantasy is the idea that a URI's meaning is in how it is used, not what it "identifies". The second is the prospect of second sourcing for URI behavior. The third is the idea of encyclopedia-style documentation for URIs."

"After a year using RSpec, I’m happy to share “(My) RSpec Best Practices and Tips”. Let’s make your specs easier to maintain, less verbose, more structured and covering more cases!"

"I am fairly obsessive about deleting prototype code. The code that I produced might be fine, it might not. It is more than likely that it is not great because I was learning something new and making mistakes along the way. I do not want to be in a position to be building on crap code. I alway build on the simplest thing that can possibly work. The only way to be sure of that (that I know of) is BDD."

"Every project I’ve worked on in the last two years has heavily involved the use of web APIs. Libersy at the time (no idea about now) had an architecture that was extensively API based, even for communication between internal applications (an architecture I strongly argued against, bee tea dubs). Since then I’ve futzed with web APIs almost exclusively. From very narrow focused uses like University of Michigan’s Bluestream Service, to more broad but still fairly local APIs like the Ann Arbor District Library’s soon-to-be-updated API, all the way to APIs of major web applications like Twitter and Flickr.

Constant exposure has turned me into a bit of a snob: I can’t stand working with a poorly designed API! If you’re about to design or release an API for the web and want to avoid the ire of your developers, I’ve summed up the best (and worst) of what I’ve seen into 8 rules:"

"Readers are encouraged to fight RBP as they read it, rather than just soaking up the information. Although I claim this book is about “Best Practices”, the only reason that is true is that it’s a result of countless conversations with folks who are deep in the Ruby trenches getting stuff done. The only way for RBP to remain current and relevant is to continue these discussions, using its content as a jumping off point for fresh ideas."

"When you call load or require a new file, Ruby searches through the files in its load path. This allows you to require files relative to the load path without specifying the files full system path."

"37signals not only constantly fine-tunes their products, they also think about the customer experience even when the customer is leaving.

I find that instructive, educational, and inspiring."

Ed, who's ever heard of that place?? The OWL in San Antonio NM has the best green chile cheeseburger in the WORLD.

Period.