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.

I didn’t start unit-testing for a long time because I didn’t really know where to begin. Especially with an existing codebase. I’ve been working on a project and part of the project includes a file upload that needs to be parsed. I couldn’t stomach the thought of clicking, browsing, submitting and waiting each time just to test a few changes.

Problem

Testing uploaded file parsing in a manual fashion is very time consuming and takes a long time. If the parsing breaks, we won’t know unless we upload each test file after every change. We can do better than this.

We need to utilize the testing framework in Django to help us automate this process a bit more.

Solution

The first thing we want to do is make an example file that a user may upload in our fixtures directory. Keeping the test upload files in our fixtures has a number of advantages. It allows us to keep them in our version control and lets all of our testing be portable.

For the example let’s pretend we are parsing an excel file of some kind.

The next step is to prepare our test. While we are only testing a single file upload, you may want to add in corrupted files or perhaps expand to different versions. So, lets setup our test with a single test “runner” test that will run the tests.

Also note that by keeping the import statements using a localized path instead of a full package sitename.app.file, we can further improve portability.

from django.test import TestCase
from utils import parse_excel_upload
import os

class ExcelParseTest(TestCase):
    
    test_upload_path = 'fixtures/test_upload.xls'
    
    def test_parse(self):
      self.parse(self.test_upload_path)

The above is straight forward, we have our excel test parse class, and a method named test_parse that will call a method named parse that takes a filename and will run all the actual tests.

Next, let’s setup our actual parse method:

 def parse(self,file_location):
        """
        Tests that we can parse our excel files
        """
        
        #setup
        path = os.path.join(os.path.split(__file__)[0],file_location)

        elements = parse_excel_upload(path)
        
        #Assert that we have something returned as expected
        self.assertNotEqual(elements,None)
        # continue doing more specific tests here

Note that I am using self.assertNotEqual. If you are running Python 2.7 or later, you can use self.assertNotNone(elements) for the same functionality. Using assertNotEqual simply allows us to run a older versions of python as well.

If we wanted to test our method with more files, perhaps some corrupted files, we simply need to add another test file in our fixture and then modify our runner to include parse the new file.

Conclusion

Testing requires a small initial time investment to get started. If it’s your first time testing, there are a few mental gymnastics to get used to for writing code that is testable.

After the initial investment, which becomes less and less each time do it, we can vastly improve the reliability of our code and catch subtle bugs that may crop up during development or future releases.

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;

He open his first restaurant in Japan in Shichirigahama, off of the Enoden-line. I hadn’t ridden the Eno-den yet, but was rather excited as it’s quite old, having been around since 1900.

photo courtsy of hamapenguin on Flickr

When I think of a celebrity chef, I usually think of a stiff atmosphere, and prices so high I swear I’m paying for white on the plate, not food. Bill’s is quite the opposite. While the prices are a tad higher than usual, it’s nothing out of the ordinary in Japan.

I ordered the Ricotta Pancakes with Honey Butter and Banana. It was incredible. At first thought, one would expect a cheesy flavour, but as ricotta does not have much taste by itself, this is was not the case. They were incredibly filling (as pancakes usually are for me) and highly recommend them.

In hindsight, I should have ordered coffee or something bitter to go with my pancakes, but how does one see an Orange Juice, Banana, Yogurt, and Berry drink? You can’t. Given the price of ¥700, I was a little disappointed in the amount received, but it encouraged me to savor the flavour that much more.

Conclusion

Bill’s in Shichirigahama comes highly recommended. The food was delicious and not overly expensive. The view of the ocean makes it the perfect place to enjoy a quiet Sunday morning.