Below I will outline some techniques that I use when developing websites that help keep my Javascript to a minimum and prevent me from repeating myself.

Create a convention, and stick to it

Create your naming scheme for your DOM ids and CSS classes and stick to it. This will make it a lot easier to write your javascript in a generic fashion and then process requests on the server.

For IDs, I usually combine at minimum the action and a unique identifier ( record id or primary key ) sandwiching a hyphen. If I am doing work with multiple forms on a page, I might also include the form prefix in the identifier as well.

Create css class conventions for basic actions, and use them consistently. The main 2 that I use are a class named “link” and “ajaxAction”.

Render responses server side

You should never embed html templates into your javascript. Ever. As stated above this creates a fragile mess that is difficult to maintain. Instead take advantage of your web framework’s template rendering system ( you are using some kind of framework, right? ). Make sure it’s the same template that you also use to originally generate the page in the first place. I use Django for most of my web development, so if I am rendering a table that is ajax’ified my table template might look something like this:

<!-- table.html -->
<table>
	{% for row in data %}
		{% if forloop.first %}
			<tr>
				<th>Date</th>
				<th>Message</th>
			</tr>
		{% endif %}
		{% include 'message_row.html' %}
	{% endfor %}
</table>
 
<!-- message_row.html -->
<tr>
	<td>{{row.data}}</td>
	<td>{{row.message}}</td>
</tr>

My ajax response would then simply render message_row.html as part of its response. This insures that by ajax response and my original rendering are always the same.

Use Delegates Instead of Bindings

When first learning how to use jQuery, we usually bind our dom objects either directly via identifiers or by css classes. This works fine, until you try to add a new element after initial binding. You can click all that new element all you want, but it won’t respond until you rebind it. Again, unsustainable.

Learn to use delegates instead. The effectively automatically binds all elements on the page, no matter when they are added, by doing lazy processing of the request.

	$('.ajaxAction').bind('click', function() { } );
	//BAD
 
	$('body').delegate('.ajaxAction','click', function() { } );
	//GOOD

Conclusion

Javascript doesn’t have to be ugly and repetitive, although it is often introduced in manners that encourage this. Writing clean and concise Javascript is not difficult, but it does take some discipline and planning. Following the 3 above techniques alone will not guarantee your code is perfect, but it will greatly enhance maintainability and reduce errors in common functions on your site.

At the time, having a full, professional grade IDE available for free was mostly unheard of. Compared with Visual Studio, who’s minimum entrance fee was in the range of $1000. Students, of course, got a discount. Since then having a free IDE on your platform has become the norm. If this is because of Xcode or not, I am not sure.

Suddenly, for the first time, Xcode has a price for non-paid developers: $4.99. There has been an uproar as to what open source developers and people who are interested in learning to program will do. That Apple is somehow taking away a lot from developers by adding this barrier to entry. I would argue, they aren’t.

Open source developers often list Xcode as a dependency for those that wanted to compile from source, not because the project required Xcode, but because it installed the requisite compilers. If having Xcode as a dependency is not something that developers want, then the community is going to need to pick up the slack as per keeping the toolchain current and packaged. As these tools are open source, it shouldn’t be that difficult to do (although we do know what happens when we say shouldn’t….)

Ignoring the argument that if you can afford a Mac, and you’re interested in learning to program, you can afford $5 dollars for tools to develop with. More than likely, the book you pick up to learn Objective-C will cost a heck of a lot more than that.

At the end of the day, any serious mac developer is going to have the $99 dollar subscription to the Mac developer program. If you’re looking to learn to program for the Mac, 5 dollars is a minimal investment for access to a world class development tools. If you’re just looking to program on your Mac but don’t want to spend the $5 for Xcode or $99 for the developer subscription, learn a language different than Objective-C. There are many build in programming languages in OSX, including Python and Ruby.

As for me? I will keep my paid developer accounts ignore the rest of the uproar.

Problem

Traditionally, web developers have had to create graphics for every non-standard button they used on their site. This is expensive in terms of time, money, and usability. It takes extra work for our buttons to be assessable, increases load times, and if we ever want to change the wording of our button, we have to start all over again.

Using various features afforded in css3, we can remove the need for images altogether, lower load times (and save bandwidth) while gaining scalability of our user interface, full accessibility, and never have something that is completely reusable throughout our site without any extra work.

We are going to go from the one on the left to the one on the right.

Solution

First, we need to begin with our basic markup.

<a href="#">My Button</a>

Because we want to style it and reuse said styles more than once on a page (potentially), we’re going to want to add a css class name.

<a href="#" class="gradient_button">My Button</a>

That’s all the html markup we will use. From here on out, we will just be adding styles to our stylesheet. The first thing we need to do is decide which color our button needs to be. We need a minimum of 2 colors: one lighter color for the top of the button and one darker color (of the same shade) for the button of the button.

I used the CSS3 Gradient Generator to select my colors and generate the rules. I’ve picked a grey color for this tutorial. Feel free to pick anything you like. Let’s set it as the background for our button. Let’s create our gradient_button selector and add our gradient background

a.gradient_button {
	background-image: -webkit-gradient(linear,left top,left bottom,color-stop(0.43, rgb(237,234,237)),color-stop(0.72, rgb(176,176,176)));
	background-image: -moz-linear-gradient(center top,rgb(237,234,237) 43%,rgb(176,176,176) 72%);
}

It’s ugly, but we’re getting closer. Next, let’s add some padding around our button, create a border, and give it rounded corners. Add the following to the gradient_button selector.

border:solid 1px #111;
-webkit-border-radius:3px;
-moz-border-radius:3px;
padding:5px;

Already we are looking much better and more realistic. However, the text completely throws the button off. It looks like it’s just pasted on there. We want our text to be a part of the button. We can do that by insetting the text with a shadow. So, next, let’s remove the text decoration, change the color, and inset that text.

color:#111;
font-weight: bold;
text-shadow:#ffe 0px 1px 0, #333 0 -1px 0;
text-decoration: none;

Already, you can see our button finally looks like a button. We could stop there, but we should go the extra mile for that last bit of polish. Especially considering how much time we can save because we never have to visit photoshop to make a button again.

First, we need to recognize that objects are never flat. Everything casts a shadow. Our buttons are no different. Remember to try and keep a consistent light source when implementing shadows on your website, my light source is directly above, so I only want to cast a shadow below my button. Add the following to the selector:

-moz-box-shadow:  0px 2px 5px #999;
-webkit-box-shadow:  0px 2px 5px #999;
box-shadow: 0px 2px 5px #999;

Our button now looks great. Try clicking on it. Notice that? It maybe look like a button, but it surely doesn’t behave like a button. We can fix that by adding one more selector. We need to style the :active state of the link, which is displayed when a button is pressed.

When picturing a physical button pressed, what sort of changes we see? I imagine that the shadow would disappear, as the button is now becoming flat with the surface from which it protrudes. Also, I imagine that the shine of our gradient would change. I think that it would become almost a solid color, but not quite. Let’s one last style to make our button behave a lot more naturally when clicked.

a:active.gradient_button {
	-webkit-box-shadow: none;
	-moz-box-shadow: none;
	box-shadow:none;
	background-image: -webkit-gradient(linear,left bottom,left top,color-stop(0.18, rgb(237,234,237)),color-stop(0.59, rgb(176,176,176)),color-stop(0.8, rgb(237,234,237)));
	background-image: -moz-linear-gradient(center bottom, rgb(237,234,237) 18%,rgb(176,176,176) 59%,rgb(237,234,237) 80%);
	}

There we have it. A completely realistic button using nothing but CSS3 and a hyperlink.

Conclusion

CSS3 buttons allows us to save time (and therefore money) when developing a modern web application. Moreover, we get fringe benefits such as being able to make our website more accessible and fully scalable for free.

View Realistic CSS3 Button

Update:

This doesn’t work in IE. If you’d like to use a similar effect for the gradient, you can use the IE filter styles. The major caveat is that IE only seems to render these with a div wrapper or an absolute position. The div wrapper really kills the elegance of being able to have any link suddenly look and behave like a regular button with a single style. I recommend a graceful-degradation in IE, and just set the background color to a be solid.

The css for getting the same gradient effect in IE is as follows:

	/* For Internet Explorer 5.5 - 7 */
	filter: progid:DXImageTransform.Microsoft.gradient(startColorstr=#EDEAED, endColorstr=#B0B0B0);
	/* For Internet Explorer 8 */
	-ms-filter: "progid:DXImageTransform.Microsoft.gradient(startColorstr=#EDEAED, endColorstr=#B0B0B0)";
	/* graceful-degradation when the filter doesn't work */
	background:#EDEAED;

After a scrapped interface and a few delays, I forced myself stop adding new features and move the “nice to haves” into a future release. Jisho 4.0 was shipped in December 2009.

Soon after the 4.0 release I began work on Jisho 4.1 to take care of these issues. Jisho 4.1 was released in January 2011. The development time was quite long, but most of it was not spent writing code. Below are some lessons I learned while developing Jisho 4.1.

Define the scope of the release

Define features or fixes in a given release and stick to it. With a proper scope written there will be no second guessing if your program is ready to ship. Have you implemented the planned changes? Yes? Ship.

Keep it limited

If it sounds like it could be broken into multiple releases, it probably should be. Try to keep releases small. I made the mistake of trying to refactor the backend to improve search and add in some new UI features for a single release. The end result was looking 3 major undertakings directly after a major release was paralyzing.

Fully plan an interface before committing to development of a feature

Fully plan how a feature is going to work and integrate with the rest of the application before committing to develop it for a particular release.

With Jisho 4.1, I wanted to refine the interface so the user could see kanji in a larger view. I hadn’t planned the interaction properly and a clean design was not forth coming.

I spent the majority of development time trying various interactions that inevitably felt unnatural. Simply planning this refinement more completely would have told me it’s enough for it’s own release.

Push features to if it means you can release

If you have a feature that is sapping development time and holding up bug fixes or already completed features, push it. There’s no shame in pushing a feature to a future release so your users can get better software today.

Users tend to get upset if you promise a feature for a given release and then pull it. So, this lesson is most applicable if you don’t promise particular features while they are still in development or even before they are released.

Git (or your scm of choice) is a good thing

Creating a branch for development of a new feature is a great way to make it easy to revert to a prior version so you can release. If you only merge branches once the fix or feature is stable and complete, you will always have a stable version ready.

I just started using Git before the development of 4.0. Before that I was coding dangerously with random zip archives of the code, usually at each point release, and a changelog that only mentioned the changes the end-user would see.

Lower the barrier

The more steps required when releasing a piece of software has the same effect as adding steps during checkout. You’re going to lose a lot of people (or in our case inertia) towards making an actual release. Simply your release process as much as possible.

Until 4.1, Jisho was distributed as a dmg for new users. This dmg had a custom background, readme, shortcut to the applications folder. Each release was built by hand. I would spend a good hour crafting this dmg for each release.

Now Jisho 4.1 is simply distributed as a zip file of the application. I still have to zip / upload it manually at this point, which takes 2 minutes, but that’s still an extra step. Future plans include automating the entire process from within Xcode.

Release something

Releasing is like software food. Software lives by releasing new versions. The quickest way to kill a software project is to get weighed down by a single non-critical feature of fix.

The guilt associated with keeping fixes out of the hands of your users in the name of an unannounced feature will only grow with time. Assuming you haven’t pre-announced the feature, users won’t know what they’re missing. If you have, they might complain a bit, but most users would rather have something new rather than nothing.

It’s not too late

If you find yourself agreeing with any of this, stop reading this and figure out the fastest way to get a release out the door. It’s not to late to release something.

Jisho was well on it’s way to death by starvation. By reverting to the latest stable version and cutting the features that were holding up release I was able to breath life back into Jisho.

Was the release technically what one would consider a release worthy of a new sub-number version release? By itself – probably not*. However, the principal still stands – if your software looks like it’s starving, cut whatever you need to and feed it now. Failing to do so may inadvertently cause the death of your project.

* There were other factors at play with the version number, which I written about on the Sugoi Software blog.

Paypal is perhaps the easiest way to send/receive money online and WordPress is perhaps the most popular blogging platform out there. Wouldn’t it be great if there was a way we could integrate them together?

There are currently a number of plugins available that allow you use WordPress with paypal for invoicing customers and such. However if you want to do anything custom you are going to need to process IPNs (Instant Payment Notifications) yourself.

Problem

One could easily just put a php file on their server to process the IPN independently of WordPress. However if you want to interact with your database at all you have three basic options:

1. Hardcode your database settings in your IPN processor.
2. include your wp-config.php and pull the database settings from that manually.
3. Integrate with WordPress so you can use the $wpdb object in your plugin ( I assume that you are developing your own larger plugin and paypal support is part of that).

Hardcoding your settings is fine for one off scripts, but if you change servers you could easily forget to update your settings breaking your website or worse: stopping people from giving you money!

Including your wp-config.php has a number of drawbacks. It makes certain assumptions that break your software. Namely it assumes that wp-config.php is a directory or two up in ../../wp-config.php or something of that nature. As WordPress allows you to have you config file in other locations e.g. not ../../wp-config.php this is very risky business.

Integrating with WordPress allows the user to use the plugin without any extra configuration to access their database. If WordPress can access the database so can we. We also get access to some wordpress convenience methods – always a plus.

To be able to access the $wpdb object requires WordPress initialize and for the IPN somehow call our plugin. Obviously telling Paypal to send its requests to /wp-content/plugins/my_plugin/ipn_listener.php is a bad idea ( and I don’t think it would even work).

Solution

Let’s ponder for a moment how WordPress processes our requests. Usually we see the exact details of the request and they look pretty thanks to mod_rewrite. A typical request would look something like

http://example.com?/2009/08/01/delicious-cheese

Or as WordPress sees it:

http://example.com?year=2009&month=08&day=01&name=delicious-cheese.

Understanding this, my solution was to build upon this and direct the IPN to index.php with some extra variables set.

 http://www.example.com?my_plugin=paypal.

Now that we’ve got that far. Next we need to tell WordPress to be on the look out and accept more variable names from the request. We do this by adding a filter to query_vars. We have to do this because WordPress ignores them if we don’t in an effort to prevent processing unknown and possibly malicious inputs.1

function my_plugin_query_vars($vars) {
	// add my_plugin to the valid list of variables
	$new_vars = array('my_plugin');
	$vars = $new_vars + vars;
    return $vars;
}
add_filter('query_vars', 'my_plugin_query_vars');

Now that WordPress accepts GET variables with the name my_plugin it’s time to do something with that. We add an action on parse_request which gives us first change to parse given request before WordPress does.

Notice that we check to make sure that our specified variable exists and is the value we are expecting. If we do not do this we end up processing all requests. 2 Once we have confirmed that both our GET variable and is the name we expect we call the function in our plugin that processes the IPN.

function muy_plugin_parse_request($wp) {
    // only process requests with "my_plugin=paypal"
    if (array_key_exists('my_plugin', $wp->query_vars) 
            && $wp->query_vars['my_plugin'] == 'paypal') {
        my_plugin_proccess_paypal_ipn($wp);
    }
}
add_action('parse_request', 'my_plugin_parse_request');

As per processing the IPN you can start by simply copy/pasting the Paypal sample code in the function. You then access your database using the $wpdb object. Don’t forget that it’s global so you must first

global $wpdb;

before you can access it.

Update

I thought we were finished but we aren’t. The above works fine with Paypal’s Tester IPN as it doesn’t check URLs. Paypal does not allow you to active your IPN in Paypal if a given URL has GET arguments.

We can fix this with just a little more code and the magic of mod_rewrite. First you will need to enable mod_rewrite in WordPress (Options -> Permalinks) by selecting one that is non-default e.g. Day and name.

Then we need to add a hook in WordPress rewrite system and then create a rule that tell WordPress to forward all requests to

http://example.com/my_plugin/paypal

to

http://example.com/?my_plugin=paypal

The code to do this is as follows:

add_action('generate_rewrite_rules', 'my_plugin_rewrite_rules');
 
function my_plugin_rewrite_rules( $wp_rewrite ) {
  $new_rules = array('my_plugin/paypal' => 'index.php?my_plugin=paypal');
  $wp_rewrite->rules = $new_rules + $wp_rewrite->rules;
}

Notes

1 If you wish to access the paypal and other variables (both GET and POST) via $wp->query_vars you must declare them in your query_vars filter as well. Since there are loads of them with paypal this may or may not be worth the effort.

2 It might not hurt to make the value a bit more obscure e.g. ei190A0F (random gibberish). Another side bonus is you could also add support for other services quite easily.