Well, on Monday we managed to deploy the beta to beta.playlouder.com and of course as we were going live our payment gateway and access circuit wholesale partner both discovered that we did not have the correct product codes and were not set up with the correct authorities on their systems. So we have had a few days of testing and fixing, but we can now sell lines and take monthly payments.
It is starting to come together. The beta is about delivering a really impressive service and getting a feel for how far we can take the idea of properly integrating broadband with music. And we are open to all ideas, from outside our beta community as well as from inside. If you want to join you need to get an invite from a member, and invites will be strictly limited. Members don’t need to order an ISP line once they’ve joined, but non-members can’t order lines at all. The ADSL service is currently UK only.
We have one week to close off the incredibly fast development we have been doing for the beta launch. There’s never enough time when you need to hit deadlines to get everything done, but it’s important to give everyone involved a powerful message about what the new Playlouder site will look like, and how the MSP broadband music services will operate.
Development doesn’t stop when the beta launches - we have a long way to go before we’ll be ready for full commercial launch, but we will shift emphasis towards stability and being more incremental than radical.
And here is a challenge, because our mission is to do new things with broadband but with paying customers even on a beta it’s bad form to break the servers. Anyway, here are some of the things we are thinking about beyond the beta…
We will blur the boundary between business and consumer. In DSL consumers get low upstream bitrates and high contention, which is bad news if you have something to share with the world. We’re going to find some ways to make home and small business broadband more of a publishing platform.
We’re going to make a playground for geeks. In the early ’90s computer science students got accounts on university servers with almost no restrictions and big internet bandwidth. That’s an environment which encourages people to experiment, so we will see what we can do to create the same conditions on our ISP.
We will make sure that whatever is better local, is local. Too much effort and resources are wasted making multiple indentical datastreams go in and out of ISP networks because the local provider either can’t or won’t get involved. We can make sure that content and services are localised as much as possible which gives both uploader and downloader a better experience.
I’m still getting ‘wow’ moments about what people are doing with computers and the internet. Penumbra was one such recently. And for Playlouder MSP I ask the same question with everything - ‘what’s a smart way to get music into that?’
Much as I love Rails, and ubiquitous as its use is amongst the current crop of agile ‘Web 2.0′ start-ups, I feel its approach to Javascript and client-side code leaves a lot of room for improvement.
As the new Playlouder app does some quite clever things with Javascript, improve it is what we’ve done. So I thought I’d write a little about our approach and some of the issues we’ve had. Before this though, I’m going to outline some of my issues with the now-standard Rails approach, RJS templates. For the un-initiated, these consist of a domain-specific language embedded in Ruby which allows one to generate a range javascript expressions. Expressions which, when evalled in response to an AJAX request, are rather handy for updating the DOM and running some of the neat range of effects available through the Scriptaculous library.
At first glance, these are wonderfully magical and clever, but on a deeper inspection they leave rather a bad taste in my mouth. Why?
- The magic makes it look, at a first glance, as though one can genuinely compile Ruby to Javascript in a similar way to, say, Google’s Web Toolkit and its compilation of Java, or HaXe (an interesting platform which I’m keeping an eye on). This is not infact the case, and the magic is limited to a fairly restrictive set of possibilities. I would prefer something a little more transparent, to a clever Ruby DSL whose magic boasts more than it can realistically deliver.
- They’re geared very much towards a server-centric model where client-side code is kept to a minimum, DOM updates and effects are generally only pushed to the client in response to an AJAX request. If yours is just a matter of adding the now-requisite ’sprinkle of AJAX’ to a traditionally-structured web application then this is fine - ideal even - but if you need to push things even a little beyond this then you’ll start to find it a real pain:
- When you’re maintaining a library of ‘real’ client-side javascript code alongside the magically-generated kind, it can lead to duplication in two different languages (RJS and Javascript), and to confusing spaghetti code. Some code will be found in standalone little snippets of RJS in your view folders and controllers, whereas other code that runs alongside it will be in proper javascript classes - often the two will get out of sync, and bugs will arise from updating the one without remembering about the other.
- While it’s true that one can make one’s own RJS helpers, the little snippets of RJS can be rather brittle and don’t exactly lead effortlessly into good object-oriented design and code re-use practices for the client-side code.
- RJS encourages requests to the server (what should I do next? give me more javascript to run!) when they’re not really needed, when more sophisticated client-side code could easily cache results or figure out what to do without additional data from the server. I suspect this may be part of the reason some AJAX-heavy Rails-based apps have gotten a bad rep for performance.
- Whatever happened to the MVC design pattern so beloved to Rails on the client-side? It’s nice to have the client run its own controller code, and to have a little model/view/controller separation on the client side as well. It’s also nice to have structure in place for re-usable UI widgets - with their own controller code, views and data binding. RJS doesn’t really address this need or provide structure for it - although the helpers we have for some of the Scriptaculous controls are a step in the right direction, they too leave a lot of room for improvement.
In case this sounds overly critical, I have absolutely no beef with using RJS in applications which don’t require a significant client-side component, but which benefit from a little special AJAX sauce on some of their forms. Use the right tools for the right job and so on. But I would definitely warn against it to those setting out to write a moderately complex web application with significant client-side interactivity.
Next entry, find out which alternatives we chose, and some suggested best practises for structuring client-side code within a Rails application.