I've used a number of pure JavaScript libraries and jQuery plugins to handle client-side validation over the years but I never really liked any of them.  As I often do when I can't find exactly what I want, I built a new one.  

There are certainly libraries out there that cover a broader set of features, but my goal here was to make it dirt simple.  So simple in fact that anyone should be able to read the source and in a few minutes figure out how to make it conform to novel requirements.  The entire framework is shown here in the following gist:

As you can see it takes up just over 100 lines and offers out-of-the-box support for a number of standard validation patterns.  However, additional validator methods can be added via the options object.  Below is a usage sample that will make things more clear:

In the above example you can see that adding validation to any input element is as simple as defining a "data-validators" attribute to the element.  The value of this attribute is essentially a JSON string with some syntactic sugar to make it easier on the eyes.  For example, you don't have to surround the whole string with curly braces and if you are defining a validator such as "required" but have no additional options to specify you don't have to do "required:{}" for the JSON to be valid.  If you look at the "expandValidatorString" method in the source you can see that these elements are added dynamically before the JSON is evaluated.

At some point I'll put this up as a repository with more complete documentation but I wanted to get it out there for some feedback before that.  Let me know what you think.

I've had the occasion recently to work on some projects in very small teams, just 2 or 3 others at most.  This experience has rekindled in me a joy for this kind of working environment and atmosphere.  There's just something about not being lost in a sea of teammates or (even worse, leading a giant team) that really appeals to me.

As I thought through this more, I began to realize that this isn't simply something that I enjoy, but something that has that "right" feeling about it - it just clicks.  The following is a list of things that I believe are beneficial about operating in small teams and some of the things that flat out cannot be duplicated within a large team structure.

Note: Most of this will be obvious to people and I'm sure it's all been said before, but let me have my fun and blog about it...golf claps at the end would be appreciated.

Low Tolerance for the Silo Effect
When teams are small it's almost impossible for silos to develop.  Even in the face of explicit attempts to make silos, in a small team they just don't materialize.  Whether this is a result of a smaller domain or the low communications barrier, the benefit is clear.  Smaller teams have a much easier time cross training because they hardly have to do it at all, it's a natural phenomena that occurs when living so close to someone else's code.

Nobody Hides Behind the Wall
On large software teams I use the phrase "throw it over the wall" to describe the interaction that often occurs between one part of the team and another.  They don't really care who's on the other side of that wall nor what they're throwing for that matter.  Status just needs to be reported as: We made something, and we threw it over that wall.  The wall could be the one between development and QA, between the business and the BA team, or between the BAs and the developers...point is, it's a wall, and stuff get's chucked.

Clearly this is a terrible way to work and it reduces overall quality because people rely on the shleps on the other side of the wall to complain before they'll deal with their mistakes.  This cannot occur in a small team because the walls are too short for you to throw something over it and still retain the comfortable anonymity that a higher wall would provide.

Sorry: Took that analogy a bit far!

We Don't Need No Stinking Managers
While this is not strictly true all the time, my point is that with small teams the oversight tax is quite minimal.  As a team grows in size the amount of overhead incurred by management rises logarithmically.  By the time you have a team of 20-25 developers you have so many tech leads, architects, and project managers installed that your 2 for 1 pizza coupons are no longer valid.

Management and oversight is important but not at the expense of agility and direct (peer) accountability.  Small teams rarely have this problem and often a single manager can provide adequate oversight for more than one semi-self-governing project.

We Built [more of] That
This one is just my opinion, but when a large team builds an enormous software product the "I made that" quotient per individual is very low.  When a small team builds a substantial software product for their size that same metric goes through the roof.  It is profoundly more satisfying (for me anyway) to be part of a 4 person team who accomplishes the work of 7 over being part of a 23 person team who comes in over budget and delivering less scope.  Again, just my opinion.

Craftsmanship and Apprenticeship <3 Small Teams
This one may be a bit controversial but I believe it's more difficult for mentorship to occur on big teams.  It can happen of course, but the ratio of highly skilled craftsman to more junior developers forces those highly skilled individuals to be spread too thin on large teams.  On a team with one seasoned journeyman and two apprentices the two junior team members will learn a lot more simply because they have more concentrated contact with their mentor...and visa versa.

That's it...I'm sure there are loads more benefits (and joys) that people can identify from working in small teams but these are the ones that came to mind at 1:30 in the morning.  I'm very much looking forward to continuing the trend of working in smaller groups and delivering better software for it.

In an effort to increase my personal effectiveness I've recently been experimenting with different productivity techniques.  Over the past couple weeks I've attempted to use the Pomodoro approach to task execution.  I've modified the "official" pattern but tried to stay true to it's intent.  My spin on it consists of the following steps:

Set Up

1. Create a catalog of like sized tasks I want to complete.  These tasks don't have to be related but usually are smaller bits of a larger project.  The catalog is prioritize and ordered.  The tasks don't all have to be the same size but it helps to keep the Pomodoros same duration.

2. Arrange a distraction free environment for the duration of the upcoming Pomodoro.  This means shutting down email, IM, TweetDeck, and closing all potentially distracting browser tabs.  If I'm working in a common area I'll either move to somewhere more secluded or put my headphones in to avoid potential interruption.

3. Make sure the stage is set, meaning, make sure all the necessary software is running and projects are open.  No sense wasting the first two minutes of the cycle opening text editors and spinning up servers, etc.

Execute

4. Set a timer.  For me I'm using the simple Pomodoro Timer app for my iPhone.  This works well for me although it seems some people prefer a physical kitchen timer for this.  I find that 20 or 25 minutes work best, more than that you lose the drive to get to the finish and with less time you don't accomplish enough.

5. Do work!

6. Take a 5 minute break and GOTO step 4 until task catalog is complete.  Obviously you'll want to keep the list manageable.  I would suggest not putting more items in the catalog than you can actually accomplish in a set of sequential Pomodoros as this leads to chronic spillage on to the next task list.  You get a nice mental kick when you throw away a completed list.

It sounds like a lot of setup for just 20 or 25 minutes of heads-down time but the ritual really does put me in the mental space to knock something out.  I'm finding that I can run three Pomodoros with 5 minute breaks before I need a longer break or inevitably get pulled into a meeting or something more distracting.  

Although I haven't yet experienced it, I hear people say good things about employing this technique while pairing as it keeps a virtual carrot in front of the pair and relieves the pressure valve every 20/25 minutes or so.

It's been out on the Githubs for a few weeks now, but I wanted to do a quick writeup on NoRMatic.  If you're using MongoDB with .NET or Mono, it's pretty likely that you've come across NoRM, the great driver and LINQ provider for MongoDB.  While NoRM is awesome, it can be a little low-level at times and for Crew we needed a library to abstract a few common bits.

Some of the features that NoRMatic provides:

• ActiveRecord style interface (Save, Delete, GetById methods, etc)
• SoftDelete
• Versioning
• Validation (via DataAnnotations attributes)
• Save and Delete Callbacks (Before/After)
• Global Query Filters
• Basic Auditing (DateUpdated, UpdatedBy)
• Simple Log Listener
• Connection String Provider (to connect models to different databases)

Check out the documentation at the Github page for more information.