Following up Jonathan's post on the design decisions
that went into Verify
, here is some of the thinking on the engineering decisions we made. Think of it as tips on going from *zero* to *one point oh* taken from our experience building Verify:
Never let engineering drive design
Don't get me wrong, engineering gets a hell of a lot of say in what gets implemented, but it should never
be driving what gets created. It's a conflict of interest really; as an engineer your primary objective is to maximize the efficiency, readability, and speed at which your code is developed. This is always at odds with the best interests of the people using your application. They want features that are easy to use, through a simple interface, that often requires complex logic behind the scenes.
using prototypical inheritance
ZURB has some pretty savvy designers. They may be a little crazy
, but they are certainty knowledgable as to what you can do on the web, and what's just bat shit crazy
. I can't stress how critical this is to a good engineer-designer relationship.
Alright, enough touchy-feely stuff, it's about to get real
Inheritance is your friend
Using inheritance and polymorphism isn't just for uber-geeks
. Sure, there are a lot of letters in those two words, but really it's just about code reuse. If you're using a framework that does not provide support for inheritance or some equivalent form of code reuse, you may have chosen poorly.
Verify has a lot of different tests, that all share a lot of similar functionality. So it was pretty much a slam dunk that all the tests would inherit from a generic test that includes all the shared functionality. This way when you want to create a new test, you just inherit from the generic test and already have most of what you will need. Simple right?
If you are using Ruby on Rails
(or a similar MVC framework), then you can also use inheritance in your views and controllers. For Rails specifically, the inheritance support in controllers and views is a very powerful, but seldom discussed. The details are beyond the scope of this post, but one thing we make extensive use of in Verify is removing the helper :all
line from application_controller.rb. This loads the view helpers in the same order as your inheritance tree, as opposed to just loading everything in alphabetical order.
You know, backend code is not the only place you can use inheritance.
. Sure, it has great doc, huge adoption, and solid performance, but mostly it's the CSS selector based selection and traversal that makes it accessible to everyone on the team.
, and a lot of message passing using custom events.
Don't event your entire app if you don't have to
When I say event
does this and can deliver some very cool interactions, however it's a very heavy framework to learn that may be overkill for what you are trying to accomplish.
(#raw) so that the back and forward buttons, bookmarking, and copy pasting still works as they would with a regular url.
- Don't think about implementation until you know what you are building
- Learn how to properly use inheritance on your platform of choice
- Only event what you need to
Like what we did here? Think you can do better? We're hiring a full time Rails Engineer and looking for engineering interns
, hit us with your best shot.