New Gaming Site!

My good friend paka has a site up where's posting his unity games. He's an absolutely amazing 3d guy and the site is worth keeping an eye on.

Ten ways to make rapid site development run smoother

Note: This post was written by Rich Lowenberg.  When I migrated this site from Wordpress to Blogger, it assigned them all to me, but he deserves the credit.

For the last five years I've been working for ad agencies doing rapid flash site development. Most of the sites I've worked on have had to be translated for multiple regions (sometimes more than fifty!) and plugged into various different forms of content management system. They have often had rotating casts of developers working on them, and usually those developers don't have the opportunity to pass knowledge to the next person.

After leading a lot of teams and working with developers from a lot of different technical backgrounds, I've started seeing the same pitfalls over and over again, and I've come up with a few things that I think make flash coding in a team run smoother.

It's important to note that these strategies are for sites on a very tight deadline. There are recommendations in here that would be a bad idea if you had the resources you need. But if you don't, then you have to make compromises. These are the compromises to make:

1)    There is a big difference between doing what's right, and doing what's best.
The problem I often come across with developers who have come from another technical background, particularly in software, is they get a lot of enjoyment from figuring out the perfect solution and implementing it. The trouble is, there usually simply isn't time for a perfectly architected solution. If it works, move on to something that doesn't work, and only tackle poor architecture if it starts causing serious problems in other areas.

2)    Think about what it IS.
Often in rapid site development it's hard to plan for every circumstance. The spec changes multiple times in mid project and suddenly the developers have to mould their work into something new.

If you can't anticipate everything, what can you do to make the code as flexible as possible? The most important thing is to keep dependencies between site elements to a minimum. This is standard OOP stuff, but in the flash world it's still often poorly executed. A common problem is using the same instances of a class to create site elements that look the same, but that are actually semantically different. An example might be a subheader that happens to have the same visual treatment as a photo caption. But to build a class to handle that text and use it for both the photo caption and subheader creates a dependency between those two elements that shouldn't be there.

3)    Use constructors as much as you can.
The great thing about a constructor function is that it allows you to force an instantiator to pass the class everything it needs. Take advantage of this, and avoid having to use setter functions during instantiation. 

I know I know, getters and setters are standard practice. But bear with me - the point here is that if you define a constructor that builds everything you can be sure you have all the data you need. If you use properties and setters for instantiation you don't know that, and it can be a real headache for a developer taking over who doesn't know in what order properties need to be set, and what data the class needs to run properly. Constructors tell other developers clearly what data is needed to use a class, and they help avoid the need to write both constructor and modifying code, which takes more time and is more prone to bugs.

4)     Make new instances, don't modify old ones
There are plenty of exceptions to this rule. But what I see often, particularly with simple components such as tooltips or notifications, popup panels etc, is developers instantiating a single instance of the class and then just changing the content of that instance when a new tooltip / panel is shown. The problem with this is that it forces you to build modifiers into a class instead of being able to just use a constructor, so that's double the code and double the potential for bugs. Secondly, by using the same instance for two elements you're often creating a dependency between two site elements that doesn't need to be there, and can reduce flexibility and cause interference with mixed up variables, conflicting tweens etc.

5)    When taking over another developer's work, take the time to understand it.
Code is difficult to read, especially when you didn't write it, and modifying someone else's code just isn't as much fun as writing your own. Because of this, developers are often too quick to dismiss someone else's code and rewrite from scratch. This is sometimes necessary, but often it's just because the developer isn't willing to take the time to figure out what the first dev did. Make sure you have a reason to rewrite someone else's code other than not understanding it. If you must rewrite, try to rewrite only the parts that are aren't up to par, don't try and get it perfect (see 1).

6)    COMMENT!
Commenting doesn't only help the next person to work on your code, it also helps you think clearly as you build. There's no need to comment the simple, obvious stuff, but as soon as something isn't intuitive there should be a short explanation in there. It often doesn't feel like there's time to do this, but it's absolutely crucial and helps prevent situations like number 4 happening.

7)    Name things properly
Take the time to name your variables properly, and for God's sake don't use acronyms and short forms unless it's really obvious what they stand for. If you're using almost anything outside of the flash IDE these days then you'll probably have auto-complete for your variables and functions anyway. So use full, descriptive names that leave no ambiguity about what that variable or method is. This will help you think clearer and it'll be a godsend to the developer who takes over your work.

8)    Be realistic about changesIf a change to spec comes in, be clear about how it will affect timelines, and make sure you give yourself breathing room in your estimates.
 A lot of developers, especially as they get good, tend to be optimistic with their time estimates. They decide something is easy without taking the time to fully think it through, or they just want to look in control and competent. Don't let your ego get involved when you're setting other people's expectations, be careful and realistic.

9)    Prioritize
Sometimes there are things that can be worked on after client delivery. Often there are things that need to happen outside development before the site can launch. Typical post-delivery work might be plugging everything into the CMS, making sure components work with all possible content not just the test data, or fixing bugs that are harder to reproduce. Keep track of them and keep the rest of the team aware that the work needs to be done, but leave them until the end if you want the best chance of meeting your deadline.

10)    Find compromises outside of the development If something looks like it will be tricky to build, talk with the creatives about implementations that will be easier to develop and achieve the same goal. Sometimes the tiniest little components can cause big delays, and if there's a faster way to implement them then it's worth having a ten minute conversation to determine that.

 Don't assume the creative is inflexible.

Thanks for reading, and I hope this helps! If you have any comments I'd be happy to hear them.

New Writers for Unl33t

I've invited some of my friends and former colleagues to post here, in order to offer different perspectives on a wider subject matter. All of them are extremely well versed and highly experienced in varying areas of software development, and I'm looking forward to reading their posts.

The first is Rich Lowenberg. Rich has been a big presence in the professional Flash and Flex world for some time. He's done a lot of work leading teams to bring together many very slick flash and flex based sites. He's done some very cool stuff with Papervision3d as well. He's also very well versed in web standards development and some server side technologies. He's also a musician and writer, loves to travel, and recently moved to Amsterdam.

Enjoy!

Grails: Java's Saviour?

Grails is a RAD framework that runs on the JVM. The project, formerly called Groovy on Rails before the RoR folks complained, is essentially just what their initial name describes. It's meant to bring Rails-like productivity to the JVM world, while maintaining integration with all the lovely java-based API's available. To many, what exists in the Rails world will be sufficient, but in some areas, Rails just isn't there. Domain specific APIs (medical, banking, insurance, etc...) as well as some of the more beefy packages that would appeal to enterprise (security, workflow, rules, etc...) tend to come in Java or Java and .Net. Hence, the ability to get at these while gaining the velocity of Rails is very attractive.

Before we go too much further, though, a few points about what Grails is. Grails uses Spring and Hibernate, and can leverage the usual set of JS libraries (scriptaculous, prototype, jquery, etc...).

Code is written in Groovy, a dynamically typed language modeled to some extent on Java, but making heavy use of reduced syntax for common operations, and closures. Closures are a new beast in the java world, but should be familiar to those who write a lot of JS. Enclosing code in braces creates an implicit object which wraps that functionality and can be passed around. While this can take a bit of time for us Java guys to grok, it can be very useful.

Many dev actions are performed from the command line, using the "grails" command. This will be familiar to anyone who's used Rails. For example, grails create-domain-class Book will create a domain class named "Book". Subsequently running grails generate-all Book will generate scaffolding (a controller and various views) that can act as either a basis for code to use that object, or an out-of-the-box admin interface for that object. If you want to learn more about the details of using Grails, their Quick Start Guide is a good place to start.

While Grails has a lot of pieces of the puzzle, it still leaves a lot to be desired. The Eclipse plugins for Grails and Groovy have been in a dismal state for some time. SpringSource recently released a package for these which is a big improvement, yet problems persist. The dynamic typing nature of Groovy means method insight is rarely available, and the eclipse plugins appear to have huge memory consumption and some leaks. While a gc cleans up most of the memory (but not all), the frequency of gc'ing required really impinges on the dev velocity.

There continue to be bugs with complex relationships. Abstract domain classes cannot have many-to-many relationships or the app will fail to start. A given domain class can only reference itself once. This can prove challenging if one wants to build graph structures, for example. This is especially troublesome, since Hibernate supports these. Hence, something that translates Grails mapping syntax into Hibernate has serious flaws.

Grails also adds classes to the default imports, and these will have bizarre conflicts should any of your domain classes be named the same. The framework, and the tooling in the eclipse plugin, give no warning of potential problems.

I had the misfortune of having a domain class named PropertyValue. It lead to some very weird behaviour. The app would start fine and run fine, but a change to any class (controller, service, etc...) and the app would fail to run. I figured out later that something done in reloading the class would trigger the default import to take precedence, resulting in methods I was calling on my domain object not being present. When the app was assembled into a war for promotion, the app would fail to start entirely, for the same reason.

While Grails has a great many advantages, it is cumbersome to get into, and the failure in handling complex mapping situations will trouble many who are trying to build more advanced apps. I'm anxious to check out Spring's new ROO framework, which looks to circumvent the problems posed by the new abstraction layers between the user code and the underlying frameworks in Grails by generating modifiable "glue code", rather than the grails approach of implicit glue code. Anyone have any experience with Roo?

My Employer Decloaked: Brightsquid

As some of you may know, startups need to spend a lot of their ramp up time off the radar, in order to allow their product(s) to mature. That phase just ended for my employer who has officially revealed themselves.

Brightsquid is a company who's goal is enable online collaboration for healthcare professionals. We have great product, and some phenomenal to be announced partnerships. We have a bright future (no pun intended).

When I was approached with the option to work at Brightsquid I jumped at it. The idea of helping those who cure the sick and save the dying is appealing to me. To be offered the opportunity to contribute to the staggering efforts put forward by healthcare practitioners is inspiring in no small way. Further, the more I learned about Brightsquid, the more I could see what game changer it is. I hate to use marketing-jargon, but this is a paradigm shift if ever there was one.

One of our founders, Rahul Sood, has a blog post more insightful than anything I could ever hope to muster, so I'll simply link to his post, and encourage everyone to read it.

Site update

I went back over some of my old posts and realised the code readability was horrible. I've added in syntax highlighting, should make things a little cleaner.

Enjoy!

Tapestry and Restlet Part 2

In my previous writeup on Tapestry and Restlet, I missed something, which fortunately our integration tests turned up.

Since Tapestry is ignoring calls to our REST api, we aren't hooked into their plumbing.  The problem here is that Tapestry stores a lot of stuff in ThreadLocal and removes it based on a Tapestry Filter.

Thus, while the result of my previous post will work in simple scenarios, one ends up with things like long running Hibernate sessions, and since Tapestry's transaction management is a bit wonky, long running transactions as well.

To fix this problem, we need to create a Restlet Filter that will handle triggering Tapestry's cleanup, and hook it onto our Router.  The cleanup filter:

package firstSteps.filter;

import org.apache.log4j.Logger;
import org.apache.tapestry5.ioc.services.PerthreadManager;
import org.restlet.Context;
import org.restlet.Request;
import org.restlet.Response;
import org.restlet.data.Status;
import org.restlet.routing.Filter;

public class CleanupFilter extends Filter {
    private PerthreadManager perthreadManager;

    public CleanupFilter(Context ctx, PerthreadManager perthreadManager) {
        super(ctx);
        this.perthreadManager = perthreadManager;
    }

    @Override
    protected void afterHandle(Request request, Response response) {
        perthreadManager.cleanup();
    }
}

To hook this onto the router would be something like the following at the end of your Restlet Application's createRoot method.

    CleanupFilter cleanupFilter = new CleanupFilter( getContext(),
        getService(PerthreadManager.class) );
    cleanupFilter.setNext( router );
    return cleanupFilter;