System Architecture

There are 30 posts filed in System Architecture (this is page 1 of 5).

The myth of the untestable controller

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.

Continue reading →

Is Your Site Hacker News Ready?

Years and years ago, somebody coined the term “slashdotting.” In essence, it’s the experience when your website is linked to by a larger website, overwhelming your servers with a crush of traffic.

Hacker News can have this effect, especially if your website reaches the front page for any length of time.

Continue reading →

An Intro To Zend_Navigation

This past week I had the need to integrate Zend_Acl with a navigation and menu system. Unfortunately, the documentation took a couple reads for me to understand how Zend_Navigation worked; given this, I wanted to write a primer that others could use to get started with Zend_Navigation. This is a short guide to how Zend_Navigation works, and how you can use it to improve your application.

Some Critical Vocabulary
There is some critical vocabulary that needs to be understood about Zend_Navigation and its use. For starters, Zend_Navigation makes a distinction between pages and containers. A page is a page in your application, either internal (Mvc) or external (Uri). A container is anything that stores pages. The confusing part of this is that pages are containers in themselves. This allows you to build trees of pages.

Continue reading →

Why Active Record Isn’t A Bad Design Pattern

Were I writing this as an article for a newspaper, the subhead would be “Design Patterns Don’t Cause Application Slowness.” The point of this piece isn’t to defend Active Record per se; it’s to discuss the fact that design patterns aren’t to blame for your application’s problems, and more to the point, design patterns aren’t the problem.

This discussion stems from a discussion with a friend of mine who swore up and down that Active Record was a terrible design pattern that was inefficient, poorly designed, and ill-suited for use by developers. As a PHP developer, it’s easy to embrace this call, especially since it’s always fun to trash Ruby on Rails folks; however, I’m not willing to take the position that design patterns are the cause of performance problems.

Continue reading →

Why Every Developer Should Write Their Own Framework

Lots of people have the itch to write their own frameworks. They think that they can do better than Zend, Cake, Symfony, or application-level frameworks like Drupal. They’re convinced that those designers and developers made fatal flaws, and they can improve upon them. They’re just itching to give it a shot.

So for those of you wanting to write your own frameworks, feel free. But don’t even think about putting it in production until you’ve read this blog post.
Continue reading →