Java kicks Ruby in the what now? (49)

When I first read the Java Kicks Ruby on Rails in the Butt article by Javier Paniza, I brushed it aside as something from the time when Rails was just getting traction and people using related, established technologies started feeling threatened.

I then noticed the date - turns out the article is only a few days old! Color me confused, could that article really have been written in 2009? I thought we had left the FUD-spreading behind us.

In an effort to educate Javier - and hopefully others - I decided to rewrite the Rails part of his article the way he would have written it had he had more knowledge and experience with Rails.

Programming, Technology , Read the full entry

Launch: Lokalebasen (1)

It’s not like this has been a secret until now, but Lokalebasen, the most recent client work built by me (in collaboration with Casper Fabricius) has launched.

Lokalebasen allows realtors and other providers of offices, warehouses and production facilities to connect with companies looking for a location to buy or rent in Denmark. And so far, the site has been successful.

Projects , Read the full entry , 1 comments

Testing HTML emails with Rails and Litmus (1)

Every so often, a client wants their web application to send out emails that could benefit from a bit richer styling than what’s provided with your basic text emails. Occasionally, they’re right, and you find yourself walking down the path of HTML emails. But beware! That path is perilous and behind every corner lurks the big, all-consuming monsters of HTML emails; Email clients.

Thar be monsters in them woods

It quickly turns out that pretty much every email client renders HTML differently than the next. It’s sort of like cross-browser issues, but without the comfort of CSS hacks, conditional comments, UserAgent checking, and IE-specific stylesheets.

Instead, you find yourself facing more email clients than there are browsers, many used by enterprises that don’t mind running several year old versions of programs. Realistically speaking, it’s only feasible to have access to a fraction of those email clients.

Projects, Software, Webdesign , Read the full entry , 1 comments

Size still matters (0)

A couple of years ago (wow, has it been that long already?) I posted the results from my research into browser viewport widths, Size Does Matter.

Back then, I pointed out that basing your designs on the width of the screen was pointless. Far from every visitor would actually use the full width of their screen for their browser - only 66% on average. The wider your screen, the less likely you were to maximize your browser.

Even though massive flatscreen monitors regularly appear in cereal boxes and as Kinder surprises these days, the reality isn’t much different from what it was 2 years ago; Make your designs wider than 800 pixels and expect a good chunk of your visitors to get a horizontal scrollbar.

Choosing a design width

When determining what width to give your design the primary goal must be that as many visitors as possible should be able to view the entire design without getting a horizontal scrollbar (scrolling horizontally is bad, mmkay).

The following chart shows the percentage of visitors that will not get a horizontal scrollbar for specific pixel widths. It also shows the figures from my 2006 study:

It’s interesting to note, that the available width has clearly increased since 2006. Back then, if you were to make your design 800 pixels wide, roughly 10% of your visitors would get a horizontal scrollbar. Today, that number is around 5%. It’s getting easier to justify going above the 800 pixels mark.

Another interesting thing to note is the two steep drop-off points occuring in both graphs after 1000 and 1250 pixels. Both of those correspond pretty well to a maximized browser in the two most widespread screen widths; 1024 and 1280 pixels.

The remnants of a drop-off is also visible right before the 800 pixel mark, but it’s almost not visible indicating that 800 pixels wide screens are becoming a thing of the past.

What does a smart designer do?

The above numbers are based on my statistics gathered from mentalized.net. A smart designer will obviously measure this on the actual site in question before making a desicion.

Unfortunately, many statistics packages still only provide the useless screen size metric instead of the useful viewport width one. Mint is still the only one I know of that tracks viewport widths - and that’s through a plugin pepper.

What does a lazy designer do?

If you’re stuck with a statistics package that doesn’t provide you with the figures you need to make a decision, you’ll have to settle for my advice - just like I did when designing the Substance Lab website (a rare case of me doing what I say, I admit).

Back in 2006 I recommended that you “optimize your designs for a width of 770 pixels while making sure they scale […] to 960 pixels”. Now, more than 2 years later, that recommendation hasn’t changed much, unfortunately.

With a design width of 770 pixels only 2% of your visitors should encounter the dreaded horizontal scrollbar. At 960 pixels, the number has climbed to 7% - that’s 1 in every 14th visitor.

Personally, I don’t see the value in optimizing for 2% of my visitors. I wouldn’t, however, be happy knowing that 7% of my visitors were getting a less than optimal experience. You have to decide for yourself - and for your customers - where your accepted cut-off point is.

Webdesign , 0 comments

Side job versus dayjob (7)

I have been moonlighting as a freelance webdeveloper for the last couple of years. The first year, I was using my spare evenings and weekends until I began having trouble finding enough time to dedicate to new projects.

My reaction was to cut down on my dayjob, leaving me with more time to focus on my own clients (and less time to focus on BiQ, forcing us to hire another developer).

However, it was only a matter of time before I’d run into that luxury problem again. Once again, having to turn down cool new projects due to lack of time left me with the same choice I took roughly a year ago. And once again, I decided to cut down on my dayjob.

Half a dayjob minus half a day job equals…?

Do the math and you’ll notice that it leaves me no time to work for BiQ. And you’d be correct. Starting this December, I will be a full time independent web application developer. I am super excited (and slightly scared) about this change.

If you have a great idea for a website, why don’t you drop me a line and we’ll talk about it - I love giving good ideas the execution they deserve.

Business, Life, Programming, Projects, Software, Usability, Webdesign , 7 comments

Rails Camp DK 2008 (1)

Take 12 attendees (one from Italy, way to go, Fransesco!), 11 Apple laptops (and one Windows one, I believe), 1 wifi hotspot, mix it all together in a cottage in the middle of nowhere, sprinkle it with a tad of Ruby, Git, and *jour and let is stew for 2 days and 2 nights.

What you get is a Rails Camp, and the above recipe was cooked with great success last weekend. Thomas Watson has a bunch of pictures from the event.

Retrospect

Like Chopmo I enjoyed meeting members of the still growing Ruby community I hadn’t met before.

Looking back at the event, I might as well add a few observations - probably mostly echoing Chopmos post.

Internet access

My biggest pet peeve before the actual event was the notion that everyone seemed so worried about not having internet for the two days. To me, that was part of the fun. In the end, though, we did indeed have Internet access at the cottage.

Luckily, it wasn’t a terribly fast connection, but it was bearable, and I must admit I liked the infusion of emails and IMs from the outside world. That said, I think we could easily have come better prepared (like having the *jour stuff installed and working) and have managed without internet just fine.

Geeks are introverts, even the Rails-kind

I am not sure how much the presence of an Internet connection contributed to this, but as geeks go, we spend a lot of time staring into our own laptop screen. I realize I am as guilty of this as the next guys, but just doing something by yourself is the path of least resistance, and you can do that at home. Rails Camp should shake up the old patterns.

Improvements?

Demos/presentations

I like the idea of scheduling things. Make everyone give a demo or presentations of sorts. Thing is, it doesn’t have to be Steve Jobs keynote quality - as Laust clearly proved ;) Demos are best as it can often be done without any preparation.

The main benefit of this is to drag people away from the screen and focus attention on something shared between the group. Perhaps do this every other hour for like 15 minutes.

Games

Okay, so I am a gamer, which obviously biases me in this direction. I do, however, think that having Guitar Hero or a Wii or something else present to drag people away from their laptops would be a good idea. Again, break the existing molds.

Shared projects

I luckily managed to -sucker-convince another person into working on the Bottleships project with me (I’ll post more about that eventually), which was awesome. I would have loved to see more people contributing, though, but so be it.

One way to perhaps achieve this, would be to take a Barcamp style approach to projects. Everyone writes their project idea somewhere, perhaps pitches it to the group, and then people vote on what project they’d prefer to work on/help with, and only the top projects are picked.

People whose project didn’t get picked should be encouraged to go to one of the other projects so noone is left sitting around for one self.

Don’t get me wrong

I had lots of fun, and I’ll definitely attend the next camp if possible. Thanks a lot to all who attended, and especially thanks to Henrik for getting it all organized.

Life, Programming, Projects , 1 comments

Rails Rumble 2008 (0)

Rails Rumble 2008 is in full effect. Rails Rumble is a 48 hour Rails development contest, and I and two others from the Copenhagen Ruby Brigade have decided to enter the fray.

2 hours to go

The time is getting close to midnight and my eyelids are getting to close to the floor - or so it feels. We’re done, there’s no way we can manage any more improvements.

The last hour we’ve been doing bugfixes by deleting the stuff that’s not working. When something is buggy with no time (or energy) to fix it, and you refuse to deploy low quality stuff, that’s the way to go about it. Oh well.

Rails Rumble 2008 is over for us, looking forward to going through all the apps - some of them are looking really amazing.

3.5 hours to go

Fatigue is definitely setting in now. We’re doing stupid mistakes and things aren’t moving nearly as quickly as it has been. But, we’ve been able to check off some of the items on the “nice to have” list, which is… well… nice. Looks like my ability to blog doesn’t increase the more tired I get, either.

Anyways, the site has been deployed, and we don’t want to risk doing anything major to it for the remainder of the contest - we’re bound to break something if we do.

So without further ado I give you Quotagious - the most awesome way to store and find quotes.

7 hours to go

Uh oh, less than a regular day of work left. Actually, a lot less as it’s highly unlikely we’ll stay awake until the deadline, it being at 2AM our time and tomorrow being a work day.

Funny how tons of small things crop up as we get closer to the deadline. Luckily we have the features we aimed for done. And they would’ve been deployed had it not been for the fact that something took the server down. Oh well, with no staging environment stuff like that happens.

Thomas has been working on Twitter integration for the last few hours. We didn’t want to be the only Rails Rumble app not hooked up to Twitter somehow… Performance optimizations and even more usability improvements have been my focus for the last few hours - our beta testers are ruthless, thanks guys :)

In related news, we’re now down to 99% Ruby code, 1% Javascript :(

12 hours to go

75% through the competition. So far I have been focused on usability and making the site look nice. Thomas has started on one of the fancier features, and my wife has been doing beta-testing for us.

Having someone outside the team look over the application is invaluable, even if done remotely. We’ve already implemented some changes, primarily in relation to wording and program flow in order to make it clearer what the application is and how it works.

The application is pretty solid, and we’ve added a “stable” tag to it. So if we end up messing it totally up the last twelve hours, at least we’ll have something to deploy. We’ve also started working purely in feature branches (yay Git) to lessen the risk that we end up deploying something half-implemented and broken.

Day 2 - 17 hours to go

Good morning, time to dive back into the code after a short nights sleep. Unfortunately, the more interesting stuff will have to wait, as the nights beta-testing revealed a few serious issues that needs to be fixed; primarily usability-wise. I have a feeling that we won’t get many favourable votes if people cannot sign up or log in.

26 hours to go

Yawn, tiredness is definitely setting in, but we’ve come a long way by now. The core functionality is working and seems solid - although I am sure it’s all an illusion that shatters the moment a real user gets involved. We’ve even got around to adding the majority of the UI theme.

UI-wise we had originally decided on just buying a stock theme somewhere, but we ended up doing it ourselves. I had some visual ideas I wanted to try out, and most the themes we could find in the short time we’d put aside for it, didn’t feel right and/or would need too much modification after the fact. So we’re rolling our now - support for IE6? Yeah, right.

For the last couple of hours we’ve been mainly doing minor stuff, none of us really feel like tackling the bigger ToDo items. Looking at the bright side, this means we’ve got a fairly complete’ish application now not even halfways through the competion.

The plan for tomorrow is to dig into the more interesting stuff; the features that move the application away from “meh, this is just a script/generate scaffold job” and into Championship belt status - or at least, that’s the plan.

The plan for right now: Sleeping.

32 hours to go

The first long workday (and then some) has passed - and we’re still going strong. However fatigue is becoming noticeable and I suspect we’ll be heading away from the computers to do something different very soon.

The application is really shaping up. We’re dealing with a bunch of fairly intricate edge cases we discover as we learn more about data model, and Test Driven Development is really helping us out here.

Our To Do list for today is growing thin, and it looks like we might be able to start working on polish and cool stuff already today.

37 hours to go

5 hours in, and we’ve started questioning our data model. It’s not even that it’s that complex. We’ve got 5 models, but it should probably be just 4. Too bad we can’t figure out if it’ll make things easier or harder cutting the one model.

Another thing we’ve been running into is the desire to make things too good. When you’re facing a 48 hour deadline you have to settle for good enough. There’s simply no time to go “Hrm, that URL doesn’t like exactly like I’d like it to, let’s just tweak it a liiiiiiittle bit…” - before you know it, you look at the clock and it’s an hour later.

42 hours to go

Due to the competition starting at 1AM our time we figured we’d be wiser to start the competition by sleeping, so by now we’ve only been at it for roughly 3 hours. Progress so far: Breakfast has been eaten, and a basic application skeleton has been deployed to our server, running a very, very, very basic version of our core functionality.

We’ve used Bort (as I am sure a ton of other teams has as well) as the base for the application, and I am sure we’ve have saved some time doing just that.

Next time around I’ll probably take a look at the base application before actually basing an application on it, though. Not that there has been any issues, but we did waste some time figuring out some Bort details. Luckily, it’s time to dig into the meat of the application now.

Projects , 0 comments

ImmediateFeedbackFormatter - Better formatted RSpec output (0)

On one of my projects the specs are now taking a full 10 minutes to run on my machine. Needless to say, it’s mightily annoying seeing a spec failure in the output knowing you’ll have to wait for 10 minutes before you get the details of what’s failing and you can get to fixing it.

Luckily my co-worker, Laust Rud Jensen, had that same itch and decided to scratch it. Unfortunately he doesn’t have a website to post about these things, so I am posting it for him:

Laust speaks

Itch: specs are slow and RSpec progress feedback is either extremely verbose, or you have to wait for the full spec run to complete before you can see what failed.

Scratch: I’ve hacked together a new simple RSpec formatter called ImmediateFeedbackFormatter, with code based on the existing SpecdocFormatter.

My spec/spec.opts file now contains:
--require
spec/rspec_immediate_feedback_formatter.rb
--format
Spec::Runner::Formatter::ImmediateFeedbackFormatter
--colour
--loadby
mtime
--backtrace

The require and format options are needed to use the ImmediateFeedbackFormatter.

This new formatter will print full error details as soon as they are found. Successful or pending examples are written only as a dot in the output. Name of a spec group is only printed if errors occur within the group, so much less unnecessary output is generated.

Download it

For now, you can get the basic formatter here - hopefully it’ll sneak into RSpec proper or end up somewhere more accessible (and with tests and whatnot).

Install it by putting it somewhere in your project (spec/ for example), and require it in your spec.opts as shown above.

Programming, Projects, Technology , 0 comments

change:healthcare on CNN (0)

My longest running client, change:healthcare, has been featured on the CNN website and is scheduled to appear on air this weekend - what a great achievement.

I’ve worked with Christopher, one of the founders, and the rest of the team for the last few years, going from a static website with just 5 pages to an increasingly complex Ruby on Rails application helping people make sense of their medical bills and providers.

These guys (and gals) are the real deal. They are in this to change healthcare for the better - publishing a free PDF book and getting on CNN are just a few of the steps on the way.

Congratulations.

Projects , 0 comments

Things I learned from the Microsoft ads (0)

1. Windows is confusing and all about nothing - just like any episode of the Seinfeld show.
2. Microsoft needs to piggyback on Apples creativity.
3. Even though everyone and their brother use Windows, group pressure isn’t going to make me switch away from OS X.

Ah well, at least the Gates/Seinfeld episodes were somewhat amusing.

Software , 0 comments