As much as I admire the elegant design of the iPhone, I find the auto-rotate feature infuriating on a daily basis.
Landscape mode is vital for many apps, especially Safari, and it needs to be easily discoverable. Yet the way it’s implemented in the iPhone removes the feeling of control from the user, violating a fundamental UI principle.
My favourite thing about starting to use another programming language is the new perspective it gives you on programming in general. Experiencing another language’s culture and how it solves problems is a great way to think about the underlying nature of your craft.
After years of avoiding Java, I’ve been writing quite a bit recently to take advantage of the libraries and infrastructure in the JVM. I’ve been pleasantly surprised: it’s like a better C++ with an emphasis on avoiding the treacherous details in the language and the C libraries. While its reputation for verbosity is well deserved, there are some nice features.
For instance, Java allows you to annotate methods and classes. If that was a feature of Ruby, it would be a neat solution to an problem I was trying to solve.
It starts so innocently. You create a new web application, and while developing it you run it on a non-privileged port. But over time the differences between development and production mount up, and one day, the system running in development looks nothing like production.
This means the application you’re developing is very different from the one which is running in production, and there’s the potential for things to become interesting when you deploy. I have come to realise that you must make a conscious effort to keep development mode as close to production as possible.
My project, ONEIS, was started using an early version of Ruby on Rails. Over two years of development, there’s been an ever growing mismatch between what I need and how Rails works, so I’ve been writing a replacement framework which does exactly what I need.
I’ve found Rails is great for smaller applications, but a bit painful when the code gets more complex. I think this is largely due to some of the underlying philosophy and the style of coding it promotes.
A little while ago, we spoke to a significant percentage of everyone who’d used ONEIS. Unexpectedly, over 80% commented on how fast ONEIS is when asked if they had any general comments on the service.
I consider this a shocking reflection of the current state of web development, rather than anything special about our service. There are very few speedy web sites out there, and it’s becoming an issue. Google have recently launched a drive for speed and Yahoo have some well known tools and guides.
Speed is most frustrating on a mobile device. If you’re browsing any of the many news sites which offer links to content over the web, reading an article downloads 100K or more, just to render a couple of K of text. This is very frustrating — almost enough to make me knock up a proxy which strips out the rubbish and just sends the text with readable mobile formatting, sort of Readability on the go.
The Yahoo guidelines are pretty good, but more aimed at large content sites such as Yahoo. If you’re developing a web application, then things are slightly different.
So here’s how I developed ONEIS with speed in mind:
- it’s often faster
- it offers easy integration with Java for access to vast amounts of useful Java libraries
- you get real threads, instead of C ruby’s green threads
It’s also a benefit to the Ruby community at large, even if you don’t run it. The various Ruby implementations are all working together on RubySpec, a large test suite which is effectively defining the Ruby language and verifying that all the implementations are compatible.