So Far So Good

We're pushing pretty hard on the development of GlowDay and we expect to make an announcement on release dates shortly.

Apart from the product development what else has been keeping us busy? Registering the business name, registering for taxes, company formation, banking, market research, dealing with potential customers and investors… All good and necessary stuff, individually, they don’t take up that much time but they just have to be done. We are also doing some custom work, which adds to the variety to our workday.

One challenge we have is ensuring the code is consistent with the product vision and business model. We have a pretty good operational cost model worked out and we’re constantly referring back to this model when refining the feature set. We still have the same issues that every software development project has but it’s interesting to be also dealing with operational costs at the software design and coding stage of the project. In most other developments I’ve been involved in, this has not been the case, commercial and technical decisions are often made by different groups within a company… I’ll follow up with a blog post about this later on..

There’s plenty of great writing out there on entrepreneurship and start upping, Here’s some of my favorites. Since we started GlowDay, I’ve found that I read a lot more and read more carefully than before, theres nothing like having some skin in the game to improve your concentration.

Entrepreneurial Proverbs is one I tend to read every so often to remind me why I'm doing this.
Guy Kawasaki's Blog is always worth a read.
www.startupping.com
Wil Schroters Blog provides a nice counterpoint to the 50 page and 5 year business plan startup approach.

If you have your own favorites, let us know in the comments

Ultimately, every startup is different, you can only read so much.. One of the great things about working in a start-up environment is that you get to make plenty of decisions; priorities, features, technical and product direction... Of course, the problem with this is that you gotta make the decisions and live with your decisions, which can sometimes mean changing them quickly!!

The last month has really flown by. Were approaching the point of having our first release and our first customers, which is when the fun really starts!

Garry

The GlowDay Logo

I was recently asked by a friend (whose also in the process of starting a business) where the logo had come from and I agreed to write up a short post on it's story.

Shortly after I had decide to give up my old job at Vision we decided we need to start building a web presence. A pressing reason for this was that I was going to FOWA in London in February and I felt it was important to have business cards on the off chance I would meet people whom I would want to keep in touch with. The @TODO stack looked like this:

1. Find a Domain Name that's available
   
2. Get a Logo Designed
3. Create a Guest Book
   
4. Print Business Cards

I'll post another day about the name, suffice to say it was a major headache. I had been working on a homepage and guest book and had a rough idea of what I wanted...



I though it was pretty cool. Getting DIV elements to sit well in a spiral was not easy. I was slightly inspired by www.fleck.com. Garry was diplomatic and wanted to see alternate designs.
Since the GlowDay team were all still employed it made sense to outsource the work, preferably to somebody with a little more flair for this. We'd had good success with Elance/Rent A Coder style out sourcing in VISION so it was the obvious way to go.

I logged on to Elance and posted a project. We awarded the project to LatinSolutions based on their portfolio, there were others to choose from all at about the same price, $250. I filled in their questionnaire, sent them the design above and they got to work. The plan was to design the logo first and then design the homepage around it, the first four concepts arrived promptly:




















These were all clearly based on the design I had supplied. I said like to see a few more concepts. At this point we decided we liked the Camel Case. We asked LatinSolutions to suggest some more color schemes too. 10 days latter we got the next batch of samples:









We selected the logo that's now on the top of our blog. It's one of the oldest elements of GlowDay. Most visitors seem to like it but please leave a comment if you have an opinion on it.

Tech Review: Google Web Toolkit

I’ve been working with the Google Web Toolkit for a while now, and thought it would be good to share my impressions of GWT so far.

Just getting my thoughts together on this, I was struck by some similarities between current AJAX development techniques and software development at the start of my programming career. It’s funny that almost 20 years later, AJAX developers are still struggling with the same problems that we had developing DOS TSR’s in assembly language.

• Threading. The browsers JavaScript code execution model is single threaded and largely event driven. (A user clicks on something, your code handles that event etc) So, if you need to do continuous background processing, you will need to set timers and execute your code periodically in response to these events. The browser does provide some support for multithreading, e.g. a video or sound clip can be playing while javascript events are being processed, but from a JS developers perspective its single threaded.
  
• Code Size. OK, unlike the old 640k limit which existed for DOS systems, there is no real technical limit on your AJAX application’s code size. The real limit is that excessive code size means the site takes longer to load which can mean your users going somewhere else. It is also more expensive to host.
• Collections. With Java/.NET the platform provides great support for Lists, Hash Maps for storing and retrieving objects, it doesn’t come out of the box in the AJAX world.
• Language choice. Server side developers have plenty of choices, including JEE, JSP, ASP, .NET, PHP, Ruby etc. Client/Browser UI developers really only have one choice. On the browser, you really only have JavaScript if you want to support all browsers.
• Debugging support is very poor compared to developing traditional applications in C#, Java, C++ etc. Full source level debugging, ability to set conditional breakpoints etc have been standard for years when developing traditional applications.

These problems have been solved many times before for Windows, Linux and Mac application programmers.

On the plus side, the browser provides great features for programs like garbage collection, page layout, image rendering, multimedia support, CSS syling, http/s communications etc. But I thought that before looking at GWT, its worth mentioning that, from a developers perspective, there are limitations with the browser as an application platform.

Essentially, it’s user demand that any new application must be accessible via a single click on their browser that makes the browser the leading application platform today.

Aside over…

With GWT, you code in Java and GWT converts this code to JavaScript to execute on the browser. GWT also provides a set of base classes for creation of common UI elements, such as Radio Buttons, Images, Labels, Tables, PopupPanels etc. The base classes are a very thin abstraction layer over the browsers DOM. And also a set of classes which wrap the XMLHttpRequest object to simplify server interaction.

Learning Curve. There are a number of GWT books published which should help get started. But if you are a Java programmer who enjoys experimenting with different technology, the learning curve isn’t that tough. Once you get your project running in Eclipse and can run your code in hosted mode, then you are well on your way. The code base for the UI classes is small enough understand within a few days. The programming model is like Java Swing, but it also maps closely enough to AJAX programming. Not too surprising, as both are very much event driven. A good understanding of DHTML and CSS would help but isn’t essential to get started.

Productivity. I like to be able to stay away from browser quirks if at all possible. With GWT I find that I don’t have to test browser compatibility as much as if I was doing pure JavaScript. The other major productivity boost is in refactoring. With web development, often you start out with a basic prototype for the page layout, user interface and choices. The pages usually goes through a few iterations as trial user feedback is incorporated. The strong type checking inherent in the Java language and the refactoring tools in the Eclipse IDE make it much more easier to refactor the code to suit the new interface. The compiler will pick up most of the errors whereas when refactoring JavaScript the errors will only on execution.

Code size. The GWT java to JavaScript code converter minimizes download code size by minimizing white space, mapping function and variable names to their shortest possible values, and by producing browser specific versions of the code, which are downloaded after the start-up script figures out the browser type. I’ve found that the converter is quite smart in that it wont include java classes that are in the same package but are not referenced by the application code. As you start to add java code, download sizes increase but in a predictable manner. One thing I would advise is to double-check that your application is complex enough to warrant GWT if file download size is a serious concern. If, for example, you have a simple GWT app which creates an single image element and does something simple when the user clicks, the download will be almost as big an application that does a lot more. This is because classes like com.google.gwt.user.client.ui.ClickListenerCollection extend java.util.Vector and so the code for this class must also be converted and downloaded to the browser.

Production Ready. GWT is certainly ready for production use and for complex applications.

Application Updates. Your application is going to change over time, which will mean changes to server side code, Javascript, CSS etc. This should be easy, right? But browser bugs and user caching settings may result in cases where some old versions of your DHTML/Javascript is active on some browsers after your servers have been updated. GWT provides clever support to ensure this doesn’t happen by first tagging a parameter at the end of the main module include file and ensuring the filename of each included script is different for each version, to ensure its not cached. Simple but it works, and nice to see it’s taken care of automatically.

Services/Server Communication. GWT provides out of the box support for developing Java services that can be invoked by your GWT client code. One of the strengths of the toolkit is the simplicity of doing this.

Styling and CSS support. Its an area where I think the GWT team needs to rethink their approach. Basically, each ‘widget’ type (table, horizontal panel, vertical panel etc) is automatically set up with their own style name e.g. gwt-html for a HTML element. This Nub Games blog entry provides more information. At this stage I think the library would be better off not having default style names for elements, as unless the application is very simple, the same elements will require different styles anyways. I have found that IE 7, although its much better than IE 6, it still not 100% CSS compliant as regards selection of the correct style descriptor where style elements are inherited from many different parent elements. My feeling is that it will take a while for best practice to emerge in this area with GWT.

Appearance. GWT isn’t a simple way to add complex graphic effects to an existing web application; there are other better libraries out there if your main effort is going to be creating impressive visual effects on your pages but the overall essence of your application is each click should load a new page. GWT provides a standard set of UI widgets, which are functional, can be customized by CSS. Its not that suprising as Google’s applications are deceptively simple from a users perspective. GWT shines where you have a requirement for lots of business logic to be deployed and invoked within the browser in response to these simple standard controls.

JavaScript integration. I have used this if there’s a JavaScript library or widget that I want to include in my application, mainly for visual effects.

Code Reuse. There is support for inheriting code from third party libraries and indeed there are plenty of third party libraries already out there. If your server side uses Java, the same validation classes could be re-used to do client side checking for instant user feedback, and also reused on the server side for security. I don’t want to oversell GWT for code reuse, where your UI elements could inherit from some third party elements. Its certainly possible but I think it will take a while for quality third party components to emerge. One third party component i have used and recommend is this Simple XML Parser.

Debugging. ‘Hosted mode’ provides some support for hot code swapping but the logging support is worth it by itself. GWT.log output is displayed on the hosted mode container. The com.google.gwt.core.client.GWT class is treated specially by the java to javascript code convertor, which removes GWT.log calls when generating ‘production’ code.

Cross Browser. If you stick to the provided GWT UI elements, it just works!

Tip: Think twice before using a logging framework around calls to GWT.log. If you must do this ensure that the compiler/javascript code generator is optimizing these calls out to minimize your deployed code size and increase the responsiveness of your application.

Heres a simple example. The java code fragment contains an inline call to GWT.log plus a call to a method that wraps the logging call and logs. One would expect both calls to be removed by an optimizing compiler, hey the variables defining the logging behaviours are declared as final...

myWidget = new NewPagePrompt();
GWT.log("A call to the GWT log, note how it has been removed from Javascript", null);
log(msInfoLog, "Some Log message for Page number =["+pageNum"]");
}
private static void log(int level, String s) {
if (msLoggingLevel>=level)
GWT.log(s, null);
}
private static final int msInfoLog = 3;
private static final int msWarningLog = 2;
private static final int msErrorLog = 1;
private static final int msLoggingLevel = 0; // Set logging to off

But here’s the generated javascript for this java code fragment.

dH = bH(new cH());eH(fH,'Some Log message for Page number =[' + tG + ']);}

function eH(gH,hH){oG();if(iH >= gH);}

First, you can see how GWT minimized code size by minimizing function names...

myWidget = new NewPagePrompt(); is converted to dH = bH(new cH());

You can see the inline call to GWT.log has been removed. However the second call to the log method that wraps GWT.log is still there. eH(fH,'Some Log message for Page number =[' + tG + ']); and is concatenating 3 strings as part of the call statement. The java method private static void log(int level, String s){...} has been replaced by function eH(gH,hH){oG();if(iH >= gH);} Note the call to GWT.log has been removed so the function does nothing.

So the production code still suffers by having the debug messages in there but adding no value, just increasing code size and slowing performance.

So if you are wrapping the GWT class, be careful and check the effect on the generated javascript.

Going forward, the GWT team have some major decisions to make. First Java as a language has changed significantly since 1.4. It’s a lot more complex and getting every further away from Javascript. Keeping GWT current with the latest language spec is a big task, is it worth the effort? Also, there are a lot of requests for more Java-like features to be added to the platform. Some of these e.g. support for Reflection would have major implications on deployed code size.

One feature, I would like is the ability to have non UI java code converted to javascript, and have some way to use it in my non GWT UI apps, where the generated javascript exposes a predictable interface.

GWT 1.4 is out this month, there’s a pre-release already. The feature list looks exciting; a lot of core optimizations and some new UI widgets, in particular the rich text editor is a great addition. It’s taken a while to get GWT 1.4 released, but it looks like it is worth the wait.

GWT is a clever technology and its great to see new approaches being taken in this area. After working with GWT for a couple of months, I can say that while we are still waiting for the perfect AJAX development environment, GWT is a strong contender particularly if your application requires lots of bespoke client side logic with server calls.

Pacman meets XML/SWF Charts

I came across this image on an backwater Slashdot thread and it gave me a chuckle. (Note: I can't find who owns the copyright on this, it's widely published around the net though.)
...meanwhile we've been experimenting extensively with this XML/SWF Charts Library. It's a pretty neat simple to use Library with a huge range of very impressive charts. It's not perfect but it nearly is and it's extremely competitively priced. It consists of an embeddable SWF object that you pass a XML feed to. The rendering is then done on the client side. The appeal of this is that the load on the server can be reduced with out sacrificing the visual effect. I've used it to produce a GlowDay version of the Pacman Pie Chart. You might want to refresh to see the animation it all it's naff.

My main complaint is it mixes presentation and data together in one XML feed.
Aside from the fact that this is a violation of separation of concerns process, it has a major practical consequence, every time you update the data you have to republish the presentation layer too. This means more bandwidth consumed. In the example above the data feed is about 3K of which 309 bytes is the data portion. This means 90% of the bytes downloaded might never change. What's especially annoying about this is that the chart library caches the data file so you have to resort to appending a unique number to the data file URL to stop this happening, more bandwidth consumed unnecessarily, and if you not careful with your server side implementation more server horsepower consumed re-generating your data file.

My other complaint is that there doesn't appear to be a schema available for the XML feeds. This is poor, in my book XML with out a DTD or an XSD is not XML it's a proprietary format. While the documentation for the libary is excellent there are ambiguities in places and an XSD with eliminate them. I'm using JAXB at the back end to generate the chart data for publishing so a schema was really a necessity.

The website had lot's of sample documents so I thought, Trang to the rescue! Trang is a sort of XML Swiss Army Knife written by James Clark the XML Guru. (Incidentally this is my preferred Swiss army knife at the moment ) . Trang allows you convert to and from these XML languages:

• RELAX NG (XML syntax)
• RELAX NG compact syntax
• XML 1.0 DTDs
• W3C XML Schema

More importantly for my purpose it allows you to infer a schema from a collection of samples. The command line documentation is a little vague on how to do this but eventually I got it to work. Hey Presto! one XSD here for all to use. It does a pretty good job, It's not perfect but it seems close enough so far.

Despite these gripes we're going to be using XML/SWF charts for a while anyway.

Daniel