In other news, I am in the process of moving code samples over to Github, and embedding them here. It is a lot quicker and easier to do it this way than to use the Syntax Highlighter. Nothing against the highlighter, it’s just not the tool I need.

Turns out this was super simple to do. The following Ruby script takes care of resetting the build number. On Windows, I found the build numbers for projects under %USERPROFILE%\.BuildServer\config\.

To get it to run nightly, I simply set up a scheduled task using Windows’s built in Task Scheduler application. The task runs the following batch file:

That concludes my too-long-for-Twitter musings for now

So why would we make it a plugin? A JQuery plugin gives you the chance to encapsulate JQuery functionality into a single, pluggable module which can then be activated by calling a single method (with optional settings passed to it). If you’ve used things like the JQuery Validation library, you’ve seen a bit of the power of plugins. They are not hard to write, and the official documentation on the JQuery site gives you enough information to get started.

We will start off with the same basic HTML text box that we had in the previous post:

<input type="text" id="textBox1" />

And some simple CSS to go with it:

.watermark { color: #CCC; font-style: italic; }

So, just to recap what we want to do: when our focus is off of the textbox, and the textbox is empty, we want to display the default text, which is “type here…” in a light gray color. When the focus is on the textbox and the default text is displayed, we want to clear the box and the styling. If they type something in the box and then click elsewhere, we want to keep the new text and not reactivate the watermark style.

Using the previous JQuery code I posted as a base, here is the plugin code with comments to explain how it works:

(function($) {
	// Create a plugin with the name 'watermark'
	$.fn.watermark = function() {
		// Loop through the elements in the selector that we call the plug-in on
		this.each(function() {
			// Apply defaults to the box
			$(this).addClass("watermark").val("type here...");

			// Apply our focus and blur events
			// When we click on the field, we expect it to clear the field and remove the watermark
			$(this).focus(function() {
				$(this).filter(function() {
					// Check to see if we have a blank field or the default text
					return $(this).val() === "" || $(this).val() === "type here...";
				}).val("").removeClass("watermark");
			});

			// When we click off of the field, we expect it to replace the watermark,
			// unless we have entered text
			$(this).blur(function() {
				$(this).filter(function() {
					// Check to see if the field is blank
					return $(this).val() === "";
				}).addClass("watermark").val("type here...");
			});
		});
	};
})(jQuery);

To apply the plugin to our text box above we can now simply do this:

$(function() {
	$("#textBox1").watermark();
});

Making it better

What we’ve done so far is fine if you’re only concerned with a specific case, but what if we wanted to use this same plugin for different default text scenarios, or with different CSS classes? As it turns out, this is not hard to do.

We’re going to add two simple options to our plugin, but leave our defaults as they currently are:

(function($) {
	// Create a plugin with the name 'watermark'
	$.fn.watermark = function(settings) {
		// Defaults
		var config = {
			watermarkClass: 'watermark',
			defaultText: 'type here...'
		};

		// merge the passed in settings with our default config
		if(settings) $.extend(config, settings);

		// Loop through the elements in the selector that we call the plug-in on
		this.each(function() {
			// Apply defaults to the box
			$(this).addClass(config.watermarkClass).val(config.defaultText);

			// Apply our focus and blur events
			// When we click on the field, we expect it to clear the field and remove the watermark
			$(this).focus(function() {
				$(this).filter(function() {
					// Check to see if we have a blank field or the default text
					return $(this).val() === "" || $(this).val() === config.defaultText;
				}).val("").removeClass(config.watermarkClass);
			});

			// When we click off of the field, we expect it to replace the watermark,
			// unless we have entered text
			$(this).blur(function() {
				$(this).filter(function() {
					// Check to see if the field is blank
					return $(this).val() === "";
				}).addClass(config.watermarkClass).val(config.defaultText);
			});
		});
	};
})(jQuery);

Now, we can customize how we use the plugin:

$(function() {
	$("#textBox1").watermark({
		watermarkClass: 'grayText',
		defaultText: 'search'
	});
});

Files

• Sample (watermarks.zip)

Useful links

• Plugins/Authoring (jquery.com)

First, if you need help getting Mongoid setup, I recommend you take a look at the documentation on the Mongoid website. That will get you up and running. Before making any other changes, go ahead and run the rspec and cucumber generators for Rails to get the necessary files. Once that is done, make sure that if you’re not using Active Record (and since you’re using Mongoid and MongoDB I’m assuming you’re not unless you have a second database), you exclude it in your config/environment.rb:

config/environment.rb

RAILS_GEM_VERSION = '2.3.5' unless defined? RAILS_GEM_VERSION
require File.join(File.dirname(__FILE__), 'boot')

Rails::Initializer.run do |config|
  config.gem "cucumber"
  config.gem "mongoid"

  config.frameworks -= [ :active_record ]
end

Next we will configure RSpec to clean our database before each spec is run. We can do this by configuring RSpec as follows:

spec/spec_helper.rb

ENV["RAILS_ENV"] ||= 'test'
require File.expand_path(File.join(File.dirname(__FILE__),'..','config','environment'))
require 'spec/autorun'
require 'spec/rails'
require 'mongoid'

Dir[File.expand_path(File.join(File.dirname(__FILE__),'support','**','*.rb'))].each {|f| require f}

Spec::Runner.configure do |config|
  config.before(:each) do
    Mongoid.master.collections.each(&:drop)
  end
end

And, finally, we need to configure Cucumber. I will admit, I had to play around with this for a while to get the correct setup. At one point, I had a situation where my database was only being cleaned correctly every other run. This actually turned out to not be a problem with my configuration, but with my scenarios (I am still somewhat of a Cucumber noob). In a fashion similar to that of our RSpec configuration above, we will simply tell Cucumber to wipe out the collections before each scenario runs:

features/support/env.rb

ENV["RAILS_ENV"] ||= "cucumber"
require File.expand_path(File.dirname(__FILE__) + '/../../config/environment')

require 'cucumber/formatter/unicode'
require 'cucumber/rails/world'
require 'cucumber/web/tableish'
require 'webrat'
require 'webrat/core/matchers'
require 'spec/expectations'
require 'mongoid'

Webrat.configure do |config|
  config.mode = :rails
  config.open_error_files = false
end

Cucumber::Rails::World.use_transactional_fixtures = false

Before do
  Mongoid.master.collections.each(&:drop)
end

I am using “before” hooks on both RSpec and Cucumber. My reasoning behind this is to ensure that when something is running, it starts off with a clean slate. I could easily do an “after” and just have each one clean up after itself, but this way, if I just want to run a single spec or scenario and inspect the data in my test database afterwards, I have that option.

So far learning Cucumber and RSpec has been a great experience and both have really made Behavior Driven Development (BDD) click.

Useful links

• Mongoid website
• database_cleaner on Github
• Cucumber website
• RSpec website

When I started doing research on NHibernate in late 2007 after being discouraged with traditional data access and drag-and-drop designers, I never would have expected the adventure it led me on.

It all started when I began to look at a proprietary code generator and how it worked, and the massive amounts of code it spit out based on the database schema.  For a couple of weeks I made my best attempt to dig in and find out as much as I could without having access to the actual source code for the generator, to see how the data access was done.  After all, very little had to be done on the part of the developers using the tool – all that had to be done was make the modifications to the schema and run the tool.

Why did I feel like I needed to understand this data access?  Well, for one, just to make my life easier using the tool and understanding how it worked.  Secondly, I wanted to see if there was anything I could adapt and use for my own applications, just in the way of general data access strategy.  I became frustrated, and soon gave up on using anything that this application was generating because it seemed too complex for just data access.  I wanted something better.

I still remember the first blog posts I read about NHibernate.  titled “A Journey with Domain Driven Design (and NHibernate)” over on Ben Scheirman’s blog.  Many of the entries in the series were dated back in 2006, but they were still applicable enough for me to get my feet wet using NHibernate.  I printed out hard copies of the whole article series and read them several times, wrote many several applications, and started to get the hang of things.  The POCO (Plain-Old-CLR-Objects) and Persistence Ignorance approach to data access really resonated with me, and I wanted more.  After reading through the series, however, I got many more ideas in my head, and became very thirsty for knowledge.

Through the article I became exposed to Test Driven Development (TDD) and Domain Driven Design (DDD).  The more I read, the more I wanted to learn.  When I came across the ALT.NET groups, practices, and ideas, I found that there were many others out there who shared some of the same frustrations I had with the Microsoft-centric nature of .NET development.  I was able to learn things like Dependency Injection/Inversion of Control and the SOLID Principles.  I am not just plugging buzzwords for the sake of plugging, all of these things I have learned in the last almost two years have made me a much better software developer.

Even better is that there are a lot of really smart developers out there who have done lots of work in the public arena to get these ideas circulating, and are very much the developers who I admire.  They make me, as a software developer who is still early in my career, want to work harder to achieve the same excellence.  Some of them are listed in my Blogroll, although looking at it now I realize I still have more to add.

I really do feel that we never stop learning, regardless of what career path we choose.  I know I have not and never will.  I am happy to say that I have continued to venture outside my comfort zone, trying new languages and new platforms for software development.  My craft is to develop great software, and maybe learn a thing or two while doing it to make the next project that much better.

Code samples are just that: samples.  They are usually not representative of real world applications, and in many situations they are not intended to be in the first place.  Likewise, code snippets of different strategies or techniques in particular areas of the application are often not pulled out of a real world application either.  The point I’m trying to make here is, before you copy and paste code into a real application, make sure you understand what’s going on with that code. If something were to go wrong or not work the way you intended, you need to know how to fix it.

I saw this a lot when I was in school.  There were people in the Computer Science courses who could not see the programming language as just a tool used to write software.  To them, it seemed to carry some sort of mysticism, the likes of which was not to be disturbed.  So what did they do?  Copy code out of the book, and hope to tweak it until they got it working.

Most of my understanding of software and programming languages comes from taking a concept that I’ve read about and writing my own scenario with it.  When doing so, I am given the opportunity to explore the code, see what each piece does, and modify the behavior in ways to get different results.  I experiment.  When I experiment, I feel a greater sense of accomplishment than had I just read a book or blog post about a subject.  In fact, reading normally gives me the itch to write code these days.

During my reading, I often come across comments on blogs or messages in a mailing list of people asking the authors directly for code that addresses particular situations.  I never respond to these people, because it’s never my place; they’re not asking me directly.  I always think though that these developers who need code samples for every particular situation must not be learning how to apply what they are reading.  After all, the example that the author showed explains how to approach it, why not just take the example and learn from it?

Does learning to apply have any other benefits?  Well, I, for one, like to do most of my development without having to Google every time I see something unexpected.  If I can’t figure it out based on what I already know, or if the code just smells bad, then I will ultimately resort to this, as there is obviously something I do not know and need to learn.  Learning is an endless cycle, and I would not have it any other way.

In the past, I have been asked why I try to learn so many things in my time away from my day job, and why I don’t put all that extra time into what I do at my day job.  Here is the answer: that is the one way road to becoming burnt out or complacent.  The constant challenge of learning new technologies and practices keeps me on my toes, and also opens my eyes to what software developers outside my shop are doing.  This constant evolution of my skill set also makes me hold my code and the code of others to a higher standard.

I am a .NET developer now, but that does not necessarily mean that’s all I will ever be.  I am a Software Developer first, my focus in .NET is merely the current “tool for the job.”  If I was told tomorrow that everything was being converted to Ruby on Rails, I’d jump on it in a heartbeat.  I cannot, and will not, limit myself.  That being said, as a .NET developer, I do not limit myself to just what Microsoft says or what tools Microsoft releases.  I use the best tools for the job, when I have a choice in the matter.  If I were a Java developer, my perspective on this would not be any different: not all of the tools come from Sun, and the ones that do may not necessarily be the best for the task at hand.

I do a lot of work in my personal time, some evenings I come home from a day of programming to do more programming.  Some of it goes unfinished, but I still learn from it.  Some of them are not meant to be “finished,” as they are just conceptual projects to help me learn and understand something new.  To be perfectly honest, I would rather be doing some of my personal projects for clients, so there would actually be some sort of deployment strategy involved, and so my work would actually mean something.  As I am still a young developer, this is an area I’m not too terribly experienced with, but would like to be.

This year my focus is on networking, and getting out to participate in workshops, conferences, and the like as much as possible.  This has been my weak area so far, because I don’t live in one of the bigger cities and have access to a much smaller pool of developers (in fact, I hardly know more than those in my own office).  This is definitely something I’m looking to change, and learn all sorts of new things in the process.

One part I particularly liked is the talk about software craftsmanship with respect to a martial arts-style system, where you have masters, or black belts, who train their students, and when those students become black belts, they go off and some may further develop and create their own style, which then gets taught to more students.  The idea really resonates with me, but so does the idea of software craftsmanship in general, and I would very much like to see the industry move in that direction.

Presentation: Video – XP: After 10 years, why are we still talking about it?

Q&A: Video – Uncle Bob Q&A at Chicago ALT.NET

By adhering to the standards, you can get a website that is compatible for most situations.  There will likely be a few places where it is not, and more than likely the offending browser will be Internet Explorer.  There have been situations where I have spent hours just trying to work out a small kink in a design because of IE’s lack of full support for established standards.  Nevertheless, with some time and testing, all of this can be worked out if the design is good and the designer is familiar with browser quirks.  Not taking the time to test multiple browsers and versions is a sign of one or more of the following things: laziness, rushed to delivery, or poor quality assurance testing.

Laziness, or perhaps more appropriately, apathy about whether or not a site or application is cross-browser compatible, is probably the worst excuse for lack of cross-browser compatibility.  This is when the designer or developer of the application only tested it in, say, Internet Explorer, and didn’t care whether or not it worked in any other browser.  When people ask for support and are asked what browser they are using, if the answer is not Internet Explorer, they are met with the response “Oh, I’m sorry, we only support Internet Explorer.”  I don’t really find that to be acceptable today.  It is not difficult to install Mozilla Firefox or Google Chrome, at least the latest versions of them, and test the site.  At least know where the issues are!  And do not even get me started on the IT guys who will not let you install Firefox on a network computer because it is “insecure” (yes, I have actually encountered one).

There are some products that are rushed to delivery without the attention to testing that needs to happen.  Really, with these types of products and/or sites, the UI being cross-browser friendly is probably the least of their concerns, because there’s probably a lot more going wrong.  Tied together with this is the constant rush to get new features out the door and paying little attention to what’s happening with the UI.  As things are added, manipulated, or taken away, the chances of every little thing on the page working across different browsers decrease dramatically, especially if they were rushed, not tested, and thrown out into the world.  If the product is actually going so far as to throw errors in certain browsers, then you really have issues.  I have come across components from a certain vendor that would blow up when you viewed them in Google Chrome or Safari.  While this component vendor should have tested their product for cross-browser compatibility a bit better, so should the company using the component for their own product which produces the same error when viewed in those browsers.

Poor, or complete lack of, quality assurance testing means that any cross-browser issues that would have been caught will not be.  Even if there is not a QA “team” in place, some testing can be done by the designers and/or developers working on the project.  UI issues are generally pretty obvious, and testers with keen eyes can identify differences as small as one pixel.  In some respects, this is very similar to my explanation for laziness above, when it comes to the person designing or developing the project of checking their work in different browsers.  Having a team in place for testing means that additional eyes are looking over stuff that the designer or developer has been staring at for hours on end, which can be very beneficial.  Alas, not all companies can afford this luxury.

Cross-browser compatibility testing has become an important part of user experience testing, and it is not one that should be taken lightly.  The more popular the site or web application is, the more types of traffic it should be designed to accommodate.  One area I see this growing even more is in mobile web browsing, especially since mobile web browsers tend to have tighter restrictions as to what content they can actually display, and display correctly.  Many sites already have separate mobile versions, and it may be that this is the best way to address that particular issue.  All in all, the number of browsers that we need to support is not getting any smaller, so our workload is only growing.