It’s a persistent statement: controllers should have as little code as possible because they’re difficult, nay impossible, to test. Developers should force most of their code into the models instead, where business, validation and other logic can take place. This way, the models are reusable and the code is easily tested in isolation. After all, if the controller can’t be adequately tested, then the controller can’t be expected to contain very much crucial logic. The controller becomes just a data and information traffic cop.
But this is not true. Controllers are no more or less testable than any other kind of code. What’s more, the fact that people believe controllers are largely untestable is an excuse for writing untestable code, not a valid design decision.
Some months ago, the Socorro team agreed that our current mix of REST API middleware calls and direct SQL calls from the web interface simply wasn’t meeting our needs. We were faced with an increasing number of data sources, including the coming addition of Elastic Search to the data storage system, and maintenance was becoming a problem. Thus, the decision was made to move our data layer to our REST API exclusively, removing all direct access to data storage from the web interface.
This is the second such project I’ve been on where an external API has been used for the retrieval of all data in an application. It’s a novel concept, but one that takes some getting used to to be sure.
About a year ago, I was introduced to Zend Framework as the framework I was going to be working with almost every day. And for nearly a year now, every day I have worked closely with Zend Framework, learning it’s intricacies and dealing with its warts. I sat down in March of last year and wrote a case study about learning Zend Framework. A year after adopting it seemed like a good time to reevaluate the framework and reflect.
Learning Zend Framework was a daunting, challenging experience that tested myself and those I worked with. I learned a few lessons that I think are important, and I think are worth sharing.
The explosion of the concept of “web services” has generated a debate over what “web services” actually are. An article by Raj Mishra tries to limit the concept of “web service” to a strict ten-point list, insisting that a web service have a WSDL and uses SOAP. While this is a perfectly fine sentiment (even the one endorsed by WC3), it certainly is a limiting description.
The reality is that the definition of “web service” has grown, and Mr. Mishra’s list is both inaccurate and misleading.
Now that your application is running at peak performance and you’ve decided that it’s time to scale, let’s talk about the right setup.
The modern age has brought us lots of new ways to take a growing site and scale it. From Amazon Web Services to cloud computing and grid computing, to Mosso and Akamai, there are lots of options we should consider. This article won’t make a recommendation as to which you should pick; it will simply discuss what each service has to offer and leave it up to you.
In 2007 I wrote a blogging program from scratch. I was really proud of it, too. It was all my own invention, with a little help that I got from a Facebook developer I knew, and I worked really hard on it. Spent the whole summer writing it so I’d be able to launch it in time to blog from Washington, when I moved here. When I started looking for coding jobs, I gave them the website address as an example of my work.
Turns out that it’s great they didn’t ask for a code sample.