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.