Twitter Bootstrap UI framework is proving to be a hit, well done to them

When it was initially made public, I thought Twitter Bootstrap could prove quite useful and I blogged in that direction. Many months later, I can now see that a lot of people adopted it. They’re recently released a version 2.0, which may well be a response to Zurb foundation. A glance at Github suggests that Twitter Bootstrap is one of the most popular project there.

I don’t have any affiliation with either organisations, but I do like to see something so useful in widespread use. This can only help users and developers, companies that build on such toolkits may be able to optimise their web application interface design costs too.

Twitter open sourced a really useful web front-ent toolkit, it’s called Bootstrap

Timing sometimes can be a strange thing, it can be nice when it works in your favour.

Just as I’ve started creating my own web UI toolkit, I get the news that Twitter open sourced their toolkit called Bootstrap. The timing couldn’t be any better for me, for the following reasons:

  • A few months ago I had come to the conclusion that 960 Grid System was a great choice for structuring web pages in a scalable manner
  • I’ve checked out lots of resources for creating nice looking page style elements, via Mashable, and I have yet to find the one “killer toolkit”. So, I’ve been reluctantly looking to make my own – with my non-existing front-end design skills, that was going to be exciting
  • Two of the projects that I am working on at the moment have now got embryonic style elements, it was time to dress them up a bit
So you can imagine the smile on my face as I went through Twitter’s blog this morning. Technical folks can’t design UI, and that’s good news for everybody. The trouble is though, technical people are often allowed to make UI design decisions, often for the lack of a better alternative (or awareness). With a toolkit like Twitter’s Bootstrap, I think those of us who can’t afford their own front-end design teams would hugely benefit by simply adopting it. The worse effect that this have may be to help reduce the amount of frankly “offending site designs” that hit the web regularly.

Ruby on Rails stack on Mac OSX keeps crashing while RVM looks ok (both 10.68 and 10.7). A fix.

I recently spent some time struggling with an annoying problem with a Ruby on Rails app that just kept crashing. My environment is(was) Mac OSX Snow 10.6.8.

How I fixed it

  • uninstall the entire stack: rails, bundler and all dependencies, gem and rvm itself,
  • change my system path settings (sudo vi “/etc/paths”, put “/usr/local/bin” on top)
  • restart the machine, verify that in my path “/usr/local/bin” comes before “/usr/bin”
  • re-install rvm, ruby 1.9.2, gem, bundler
  • verify “which ruby”, “which gem”, “which bundle”, they should all show the rubies path “~/.rvm/…rubies/…”
  • install rails, redo “bundle install” in the project folder

The problem

I was having troubles getting a ruby in rails application running. This same app had been running perfectly fine before, I didn’t touch the code and others didn’t seem to have any problems running it. So it had to be something with my environment. The main change that I did was to have migrated from Ruby 1.8.7 to Ruby 1.9.2. But everyone had done that too, the app had been nicely running on 1.8.7 for me too, but not on Ruby 1.9.2. Why was this happening? Why was I the only one experiencing this problem?

Clues that led to my approach

After some googling and reading up a few blog posts, I came across this post by Yehuda Katz. I followed Yehuda’s recommendations, but that didn’t fix my issue. He’d touched upon one thing that I was sure was going to be a good lead: some gems could have been compiled with the wrong version of Ruby or native libraries. That had to be it, but where, which gems? I thought if a quick reinstall didn’t do it, something must be seriously broken. As I started removing and reinstalling the gems one by one, I kept checking the search paths, that’s how I found out that it was consistently not what I was expecting, some gems were found on /usr/bin while others were found under /usr/local/bin or in the rubies (rvm).

The only way to stop this, for me, was to remove it all, force my system to search /usr/local/bin. So I cleaned my env, adjusted the file /etc/paths to search “/usr/local/bin” before other paths.

What I’ve learned here is, as Yehuda puts it, “check your assumptions first” is probably even stronger for the DRY Ruby on Rails like environments than say Java or .NET environments. Indeed it is too tempting to think that once you’ve installed rvm, the ruby on rails stack and some nifty little gems, all following some quickly assembled and even quicker read blog postings, that everything would be fine from there. And that’s the wrong assumption that one needs to challenge.

Installing rvm, instructing it to default to another ruby version is not all there is to it. One needs to ensure that the entire stack has a consistent chain of dependencies, it’s better to do it at install time when installing anything new, and running things (to check that no assumption was quietly falsified unbeknownst to you).

Cappuccino is for Objective-C developers what GWT is for Java developers

Every once in a while I come across a framework and wonder who on earth would want to learn this? Then time passes by and I would cross it again while exploring something else, then my curiosity is aroused a tad more. That’s how I’ve bumped into Cappuccino for the third time in perhaps an 18 months timespan. So this time I thought I’d look under the bonnet to see what it’s got to offer that I may learn something from.

My time budget was about 1 hr, which was enough to get the code, set it up and take it for a spin. Several times I thought I was reading Objective-C and nearly stopped, then I would carry on a little further.

This was a nice surprise, a topic for another blog posting in the coming weeks.