Mark is a graph advocate and field engineer for Neo Technology, the company behind the Neo4j graph database. As a field engineer, Mark helps customers embrace graph data and Neo4j building sophisticated solutions to challenging data problems. When he's not with customers Mark is a developer on Neo4j and writes his experiences of being a graphista on a popular blog at http://markhneedham.com/blog. He tweets at @markhneedham. Mark is a DZone MVB and is not an employee of DZone and has posted 534 posts at DZone. You can read more from them at their website. View Full User Profile

Coding: Using a Library/Rolling Your Own

08.10.2010
| 3703 views |
  • submit to reddit

One of the things that I've noticed as we've started writing more client side code is that I'm much more likely to look for a library which solves a problem than I would be with server side code.

A requirement that we've had on at least the last 3 or 4 projects I've worked on is to do client side validation on the values entered into a form by the user.

The jQuery.validate plugin is quite a good fit for this problem and as long as the validation is just on a field by field basis then it works fine.

On the last project I worked on, however, we had validation rules which had field interdependencies and suddenly we ended up writing a lot of custom code to handle that on top of what jQuery.validate already did.

Eventually we got to the stage where the code had become a complete mess and we decided to rewrite the validation code server side and only fire the validation when the user submitted the form.

In this situation that was an acceptable trade off to make but in another we may have needed to write our own Javascript code to handle the various validation rules.

In that case we'd probably want to write our own code to handle the inter field dependencies but still use jQuery.validate to handle individual field validation.

While thinking about this I was reminded of a post written by Michael Feathers back in 2003 where he discusses 'stunting a framework':

[...]let's think about great frameworks… erm.. there aren't many are there? In fact, even the good ones are a pain in the ass, aren't they? There was that time when we downloaded framework X and it took quite a bit of time to learn how to use it, and that other time when we thought it would be useful if only it did that, but we spent the next week trying to force it and…"

Framework use is hard, yet we keep trying. Why do we do it? Mainly because we want to [...] leverage the work of others. If we use someone's else framework, we may save some time. Moreover, we've benefited from someone's "crystalized thought," thought in the form of working code. The code shows a proven way of doing things and if it's well-designed it can accommodate our thoughts and we can roll them back to the community.

Although the majority of the article is talking about frameworks from the angle of avoiding the temptation to create frameworks, I think it's interesting to consider whether we always need to use a framework.

One other area where I've noticed we instinctively turn to a framework is when we have to interact with a database. The instinct is to straight away use Hibernate/NHibernate/ActiveRecord when frequently the initial use case doesn't really require their use.

However, if we don't make that decision up front then we need to be quite vigilant about observing the point at which we're actually just reinventing the wheel rather than making a pragmatic decision not to use an ORM tool.

There are certainly other considerations to make when deciding whether to use a library or not such as our familiarity with it and its reputation/reliability in the community but it is still a decision point and one that I've frequently not recognised as being one and just gone straight for the library option.

From http://www.markhneedham.com/blog/2010/08/10/coding-using-a-libraryrolling-your-own

Published at DZone with permission of Mark Needham, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Tags:

Comments

Clure Rogre replied on Wed, 2010/08/11 - 6:12am

"let's think about great frameworks… erm.. there aren't many are there? In fact, even the good ones are a pain in the ass, aren't they?"

I totally disagree with this statement - (off the top of my head) frameworks like Wicket, Echo2, YodaTime, Hibernate, Spring are all bloody brilliant, easy to use (ish), and well documented.

I'd go as far as to say, using Wicket is a pleasure in every sense.

Andy Till replied on Wed, 2010/08/11 - 7:05am

I would never write my own ORM framework but I would seriously consider writing my own framework to validate several fields, even if solutions for either didn't exist.

The difference is the amount of flexibilty and features that need to be implemented for the software to become useful.  The return on a small framework with a single goal is much greater than writing your own ORM framework which is most likely to produce a net loss, even if initially it gives you greater productivity than learning Hibernate.

Mladen Girazovski replied on Wed, 2010/08/11 - 7:38am

One of the things that I've noticed as we've started writing more client side code is that I'm much more likely to look for a library which solves a problem than I would be with server side code.

 Interesting, this wasn't a Java project, right?

 

King Sam replied on Fri, 2012/02/24 - 10:43am

Part of the reason is that there's often just me and another developer working on something, and the time saved by using a library can be quite substantial, especially if I don't know everything there is to know about the problem I'm trying to solve with the library, as it then becomes a case of "Understand, at a very low level, how encryption works. Understand how to generate a cryptographic signature for an XML document" (Been doing Web Services Security lately).

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.