Blog Entry
Eric Lamb is the developer of professional and enterprise grade ExpressionEngine add-ons. Founded in 2009 Eric’s company mithra62 aims to be a leader in ExpressionEngine add-on development and has a reputation for stability, usefulness, and being highly configurable. Check out Eric’s popular ExpressionEngine add-on Backup Pro.
When working on your average developer tool, a tool to help developers do their jobs as opposed to an add-on or script to add features, you can’t help but obsess over the meta. Normally, a lot of this stuff is just second nature, and rarely given more than a cursory thought, but with tool development, like the EE Debug Toolbar, you just can’t help it.
Take, for example. the question of “high quality in web development”. A couple months ago I had mentioned high quality as making sure “nothing was off about a project”. Not the best definition and certainly open to interpretation. Now that I’ve had some time to think about it I believe I have a better definition for what I consider a quality ExpressionEngine site to mean.
When building out a web project there are 5 points that have to be covered completely for a project to be considered of high quality in my opinion. They are (in no particular order):
- Feature Complete
- Secure
- Minimal Fingerprint
- Maintainable
- Recoverable
Feature Complete
All things being equal, this one’s easy and the one most people can achieve. Does the project do what it’s intended to do?
Now, I say this one’s easy because with a tool like ExpressionEngine (and to be fair, lots of other platforms too) its whole purpose of being is to make doing things trivial. And it does do it pretty well. Say what you will about the problems ExpressionEngine may or may not have but it does allow web developers to do some useful things with minimal effort.
That said, nothing can make a project good if the plan is poor. If the list of features isn’t compelling or interesting to users it doesn’t matter how well done the other parts are.
Where things fall apart for those projects with a good feature set is with the other 3 points though.
Secure
Things have changed dramatically in the last decade in terms of security and web development and ExpressionEngine does it’s part to make that easy for a lot of situations. (Lots of newbie devs will never appreciate the sheer terror in coming into the office and feeling the odd sense of shame and revulsion over what some script kiddie did to the network. It’s a shame…)
But all this is still at the platform level. Using extra tools like Securit:ee, VZ Bad Behavior, devot:ee Monitor, and all the other security minded add-ons at devot:ee you can improve ExpressionEngine’s security even further. But there’s nothing stopping devs from doing insecure things in the development of their project.
Just a couple base example questions to ask yourself:
- Is personal data secured? Can users change a URL parameter and view stuff they shouldn’t?
- Is sensitive data secured and encrypted before storage?
- Does the site rely on only JS for form validation?
- Are the embed templates hidden (dot/underscore)?
- Is the site still in debug mode in production?
- Are the templates setup for member access and lock out?
Obviously a lot of this stuff is dependent on the project but my point is that security needs to be taken seriously and as an actual “thing” before quality can be claimed.
Minimal Fingerprint
This one is obviously close to my heart at the moment with the EE Debug Toolbar reaching maturity. Minimal Fingerprint refers to performance and how hungry a site is for system resources.
This is basically the below points for most sites regardless of platform (my personal goals in parenthesis):
- Page execution time (0.5 seconds max)
- Combined SQL execution time (0.01 seconds max)
- Single query execution time (0.001 seconds max)
- Total query count (less than 100)
- Memory usage (10MB max)
- Page download time (3 seconds total for all assets)
Having a secure and kick ass feature set for a site means nothing if it takes 20 seconds for pages to load.
Another thing that gets over looked far too often is how well a site performs “under load”. It is two very different things for a site to work gangbusters with no visitors and no data, but another altogether when the site is under the expected load and expected data set. Knowing (and planning for) this before pushing live is critical for a quality project.
It should be noted that performance is one of the rare exceptions where you can just throw money at the problem. Hardware’s cheaper now than it’s ever been so if you don’t have the time, inclination, or skill, to actually improve on the actual product you can always spread the site out across a load balancer or dedicated database server (or whatever) to help with performance. Definitely an advanced strategy though and not to be taken into lightly and one that’s extremely dirty to go into except as a last resort.
Maintainable
For those of us who have been around the block a few times, this is the really important determination of quality. How difficult is it to make changes/updates to the project? A tool like ExpressionEngine offers much more than just CMS capabilities; it also adds in longevity so long as a little care is taken. There is no reason for a website to have to move platforms just to change the design.
Think of it like this: You got hit by a bus/quit your job/decide the client isn’t worth it. Whatever. Basically, you’re just gone. Now. Are all those clever hacks, nested embeds, template partials gone made, spaghetti code, dynamic variables ({{var1}_{var2}_thing} anyone?) and copy pasta going to make growth and change a problem? Is the developer who takes over once you’re gone going to want to find your grave, dance on it, find a shaman and resurrect you, only to torture you for eternity because of the assault against nature you’ve created? In my experience, more often than not, yup, we’re gonna do some grave dancing and cursing.
Knowing the history on this it makes sense why maintainability would be an issue.
Tools like ExpressionEngine and WordPress and all the other CMS systems out there (and PHP and ASP and Perl before them) make creating websites well within the reach of the average enthusiast and the early successes can lead to a great deal of confidence. Enough confidence to think it’s a good idea to put the old shingle out and be open for business. Unfortunately, it takes a while for these newly christened developers to run into maintenance as an actual issue so they never think about it until later in their career.
Creating a maintainable site, that can scale to change with ease and logic, is of the utmost importance for quality.
Recoverable
Clients never think about disasters and failures when it comes to their websites in my experience. In over eleven years of doing client driven web development I don’t think I’ve ever had a client bring it up except for a couple occasions. That’s why it’s imperative that we (the hired devs/agencies) keep this in mind and set the client up for success.
In a nutshell; what is the plan when things go wrong?
- How are backups of the files and db being done and where are they stored?
- In the event the host disappears, what is the secondary provider to port things to?
- How is DNS handled and where do you change it?
- Where are the extra server components (HDD, RAM, NIC Cards, etc) stored and accessed (for dedicated hosting)?
- Who are the points of contact internally for assistance and guidance?
Now, outside of complete website development, disaster recovery isn’t really something that needs to be considered as a constant todo. But, for those projects that are complete sites or those with maintenance contracts (at the least), disaster recovery is an absolute must in order to claim a project as high quality.
Some agencies/devs like to charge for this as an extra line item, and more power to them but, personally, I do not.
First, disaster recovery plans are incredibly rote and straightforward at this point. There’s very little mystery involved. Software wise, it can range from free (Backup Pro(ish), Safe Harbor Lite, and even shell scripts at the server level) to barely 0.004% of a small project budget for an automated backup solution.
Second, when something does go wrong I like to have the confidence I can fix things. Knowing what to do in the event of an emergency is just good sense.
Third, the client can say no. This is the big winner. It’s a tough sell to get a client to think about disaster recovery when they’ve likely never even heard of the possibilities. Worse, in my experience, some clients even get the idea in their head that you’re trying to “nickel and dime them”. It’s a very awkward thing, especially considering the absolutely minimal overhead involved in crafting a plan. No, best to just absorb that cost and look like a bad ass when something goes wrong and a solution isn’t a problem.
Conclusion
For me, it’s very important that all five items receive equal treatment wherever possible. I say wherever possible because when it comes to each of those items, it’s a rare thing when improving one doesn’t change the other. The key is to make your decisions with eyes open as to the full consequences.
For example, improving security on a website will, more often than not, increase the performance costs. Conversely, improving on performance can have negative effects on maintainability (especially with ExpressionEngine), while feature set takes away from maintainability, fingerprint, and security.
It’s a constant back and forth game of whack a mole but one that’s absolutely critical to play in order to build high quality websites.
Eric Lamb is the developer of professional and enterprise grade ExpressionEngine add-ons. Founded in 2009 Eric’s company mithra62 aims to be a leader in ExpressionEngine add-on development and has a reputation for stability, usefulness, and being highly configurable. Check out Eric’s popular ExpressionEngine add-on Backup Pro.
Blog Entry
In new installations of ExpressionEngine (from 2.6 forward), the Strict URLs setting will be enabled by default.
From the EllisLab blog post announcing the change:
With ExpressionEngine 2.6 and up, Strict URLs will be enabled by default in new installations. Using the same example, http://example.com/site/about-us is the only valid URL for that content. Visiting http://example.com/about-us/ with Strict URLs enabled will trigger ExpressionEngine’s defined 404 behavior.
If you are updating, don’t worry, ExpressionEngine will honor your current Strict URL preference. With this minor change in ExpressionEngine 2.6, we’re encouraging best-practice by default.
Most of you probably already turn it on when you’re setting up a new site but now this best practice is the default behavior instead of an option.
Now if only index.php was removed by default…
Add Your Comment
Share on Twitter
