Dealing with tiny bugs in software seems trivial. The problem is that Developers don’t want to work on them and Customers and Managers don’t want to waste time on them. But, these tiny issues can really bring a product down.

Canonical, the company behind the Linux distribution Ubuntu, has coined the term “paper cut” for these issues and is starting a new initiative called “One Hundred Paper Cuts.” The idea is that they want to find 100 small bugs or issues that users have to deal with, and fix them. And they mean really small. For example, a bug that fits the qualifications for the initiative would be a button in the user interface that might be just a little too small. You may not notice that you have trouble clicking on those buttons, but it’s going to subtly impact your experience with the software. Imagine hundreds of these tiny issues scattered throughout the system. Now, the software feels broken.

It’s hard to justify fixing the smaller bugs, they take time and don’t seem to be valuable. Nobody seems to want to fix them because they don’t really affect getting new customers. But, they will affect keeping them around.

Keep in mind that one paper cut may be annoying, but one hundred is fatal.

Example: Tables v. Design

Most people who work with or around websites or web applications are aware of the mantra “Tables shouldn’t be used in design,” but I don’t think all of them understand why. To explain, I’d point you to a practical example: http://www.csszengarden.com/

The css Zen Garden is a great way to look at the power of separating content from design. Every page in the collection uses the same simple HTML page but achieves very different organization and style using simple CSS.

This wouldn’t be possible if you didn’t separate your design from your content. Using tables for layout exactly breaks this rule. A giant table that wraps your content to achieve three columns commits your page to a life of three columns with no hope of changing. (It should go without saying that tables have their place and their use…for building tables.)

Definitions: Markup, Style and Layout

It’s important to have clear definitions about the three components of web design. Some others may vary slightly, but I like to think of them this way.

Read the rest of this entry »

Background

Dojo.data is a fantastic abstraction layer for data stores such as JSON and XML. Dojo.data provides a fetch method which works like a SQL select statement except that it’s asynchronous. Fetch is used by providing your query, a success callback, and a error callback. Once the query is completed the proper callback is called with the returned items. This asynchronous system works great in web applications, allowing the query to be run over the network in the background while not disrupting the user’s experience. This behavior is consistent with the fundamental principles of AJAX.

We, however, are not currently working on a web application. One of our projects has a desktop app component and we’re using Adobe Air and dojo to fulfill this requirement. An asynchronous fetch just doesn’t make sense while we’re doing our data processing. The first thing we tried was a Google search for “dojo.data fetch synchronous”. None of the results gave us information on how to make fetch synchronous, but the third link on that page does give some good information. In that post Nathan Toone explains why fetch is asynchronous and has this to say:

One of the more common questions that I’ve seen is “How can I make this call synchronous?” If you find yourself asking that, you should reexamine what you are trying to accomplish, and change your approach to be more asynchronous. You’ll gain a lot of performance benefits in the long run. Remember, dojo is an Ajax library – not an Sjax library.

But, as the Dalai Lama said, “Learn the rules so you know how to break them properly.” See how to make fetch synchronous after the jump.

Read the rest of this entry »

Web application and desktop application development varies in a few ways. One of these ways is product release cycles. Adobe Photoshop, which has been around since 1988, has shipped only 14 times in the last 20 years. In contrast we’ve “shipped” or pushed code onto the web 15 times in the last 20 weeks.

This is due partly to the fact that we are a much smaller company and are much more agile in our development. But, this is also due to the fact that traditional development cycles emphasize phases. First there is design, then development, then bug fixes and finally the product is prepared for release, printed on discs, and shipped out to retailers. This last step is not a trivial one, once a product is shipped to retailers it isn’t feasible to add a new feature or bug fix and give it to all customers without shipping again.

With a web application it is possible to develop continuously. The traditional development cycles still exist, but on a per feature basis instead of per product. We don’t have to worry about shipping our product to retailers, we can give it directly to the customer through the web, and we can constantly update it.

There is one major drawback to continuous development however, the lack of parties, specifically release parties. I imagine it is not difficult to drum up excitement for a release when the last year of your life was dedicated to it. But how do you get people excited for version 3.0 when you just pushed version 2.99?

Answer: You have cake. And so, as we internally wrap up version 3.0 of SAGrader we celebrate with cake.

Dojo is our Javascript toolkit of choice and we’ve recently upgraded to Dojo 1.1.1. We’re going to try to pass on some of the knowledge we’ve accrued, starting with how to create your own custom widgets.

Step 1. Determining Inheritance – Typically you’re going to be subclassing an existing widget, so naturally you’ll need to inherit from that widget. But there are several other widgets you may chose to inherit from.

• dijit._Widget: Pretty basic, if you follow each widget’s inheritence you’ll eventually get here, so you probably won’t need to inherit from this unless you’re starting from scratch.
• dijit._Templated: If you want your widget to pull in and use an HTML template
• dijit.layout.ContentPane: Includes some AJAX, as well as layout methods
• dijit._Contained / dijit._Container: To establish parent child relationships between two widgets, the child and parent will need to inherit from each respective widget

Step 2. Writing the Code – Each widget has some pretty basic methods you’ll want to override or add to, check out the widget life cycle to learn about all of them.

Code examples are after the jump.
Read the rest of this entry »

Training a new employee is exciting and stressful. You are responsible for the success of a new coworker, but you have to stay on top of your own game simultaneously. You can be confident the days will be shorter, the frustration levels higher, and the bugs more plentiful. This two-part article will give you some tips on how to keep your new employee and your hair from leaving, including tips on teamwork, explaining things, making mistakes, and navigating The Big Picture.

Start with The Big Picture. You should begin training by giving an overview of the company and its projects and later climb down to specifics. Even though your employee will not vividly recall all the general information you give them about the vast array of tools and procedures you use, it’s still important to expose them early on. It is the foundation of their learning, and you can revisit The Big Picture before going into each new tool or area of information to be learned. It takes a lot of sleep to assimilate vast amounts of information to the point where it can be usefully applied.

You’re a team. If you are pointing out a mistake your trainee made, it is often better to say something like “It looks like we forgot to…” or “We accidentally put this in wrong…” This lowers both stress and anxiety and lets you share responsibility for their learning. Share credit for tasks completed with your trainee, even if you did most of the work. They are doing a lot of work by learning. Using these methods, confrontations are minimized, more issues are openly resolved, and enthusiasm and morale are maintained.

It’s OK to make plenty of mistakes. You’re going to mess up, type in the wrong thing, be lost for an example, or explain things in such a way to incite laughter from your coworkers. Don’t worry about it. They would be doing the same thing. It’s more important to admit that you are wrong as soon as you realize it, and work towards finding the correct solution. That’s the essence of your work–problem solving. You’re an expert at making mistakes and finding solutions, not perfectly reciting facts and procedures you already know. Plus, making mistakes in front of new employees will create an atmosphere for them where it’s okay to make mistakes as a part of creative problem solving.

Explain the same things over again and again. You should expect to do this and not get frustrated too easily. Be very patient. Make sure your employee knows it is OK to ask for an explanation of anything you are doing, even twice, thrice, or the umpteenth time. Having them take notes is good, but you can’t expect every piece of information to make it into the notebook, or be easily found and applied to the current situation.

Take a break. Have someone else take over training for a day or two so you can catch up on other pressing issues and recuperate. In part II of this article, we’ll explore some topics to help you along after those first few critical days of training. You will learn about increasing efficiency, preventing burnout, and transitioning your trainee into being a productive employee.

Here at Idea Works our primary development platform consists of Perl and MySQL on Linux. In addition to that, over time we’ve established specific tools we use in development. This leads to about ten software tools that are used daily which our developers must be comfortable with to be productive.

But, in our experience it’s always better to hire someone smart, not simply someone who is familiar or skilled with the tools used. Programming languages and environments are just syntax. Understanding computer science concepts is the hard part.

You can teach almost anything to someone who’s willing to learn, and companies should be wary of requiring candidates to know specific language sets or tools. If you hire the right people they’ll learn, and you’ll be better off in the end.

We practice what we preach: We’ve recently hired two interns for this summer. One has beginner Perl experience and the other has none. But, we have confidence that they’ll learn, and that they’ll learn fast enough that we won’t be impacted negatively.