Client – Developing Units of Sound online

continued on from Developing Units of Sound Online

Client side choices are some of the hardest for any prospective Web Application, there are a myriad of browsers, versions of browsers, networking infrastructures etc etc that can affect your client and therefor your end user experience. Javascript engines are all slightly different from Firefox to Chrome to Opera and arguably worst Internet explorer, so how can I as a developer cope with all these differences? Especially i wont be able to commit even 20% of my time to this project  (its on top of a normal 9-5 remember).

 Standardization

the only way to deal with this problem is to use some tool which will iron out all of these idiosyncrasies with each browser and give me a level playing field. There are a few Javascript libraries written for this purpose but the winner in this for a long time has been flash. Flash is actually its own run-time environment but is very well supported by all the major browsers and for my purposes will level the playing field perfectly. This does throw some spanners in the works for later on, especially with mobile development.

Framework

Before being opensourced Adobe was push Flex as a flexable framework which would compile down to AS3 and run inside the flash run time environment. So without too much thought and investigation this is what i started to develop in and so far all my experiences have been great. Nine times out of Ten when i start to tackle a problem which is complex and not breaking into smaller sections very well i find that with a bit of reading the functionality is already implemented or partially implemented but under a different ‘name’.

Advertisements

Developing Units of Sound online

To begin with, some background Units of Sound is a online port of an existing windows native program, and currently has an install base of around 5000 users all in the UK. To allow expansion to other countries and other platforms as well as to out run limitations with the old program (written in a non longer supported language) I am helping move this program to a Flex application which will be capable of running entirely in browser.

 

Architecture in my mind is what drives the majority of high level decisions including ‘do we even need our own server?’ this sounds like an obvious question but after some thought about the operation of the program i found that 95% of it was statically served and run entirely in the client.

The KISS principle is something I think about a lot when undertaking tasks of this nature. The UOS team is made up of two developers and in all likelihood will never be made up of any more, once written the program will change very little, there will be the bare minimum of documentation and the scale will most  likely never top 30-40K users. Bearing this in mind its more important that bugs can be found easily, code can be stopped and stepped through and that what each function and section is trying to achieve is obvious.

My latest conundrum comes the previously mentioned question ‘Do we even need our own server?’  Flex is a very powerful language, it allows us to make http calls and use other third party SaaS type API’s E.G Amazon Web Services S3 or Rackspace Cloudfiles, why not just use these to do the small amount of storing required? we could even find a company to host our database, server our static content from storage providers and we are 100% ‘serverless’ (serverless as in we dont have to write any server side code).  But this architectural decision does have downsides, first and most obviously is we loose control of that area of our program and therefore User Experience. With a realitively small number of users its important to provide an excellent user experience. We would loose a few other things:

  •  custom request hooks
  • analytics becomes harder
  • unforseen functionality might be limited
  • caching not under out control
  • easy of access to our ‘own’ data

My decision was not a light one, the simple approach of no server to deal with is very aluring, but in the end the unknows and out-of-our-control’s are too many so we will stick with a traditional approach and run our own server. Next post, Technology