These days Atomic Object has me working on CircleBuilder, a social networking application for faith-based organizations. Each organization gets to set up its own social network. Think Ning for churches.

We do this by giving each organization their own subdomain off circlebuilder.com. The most important consideration is that data belonging to one organization must not be displayed in other organizations. We knew going in that this would be very easy to overlook while under pressure to get tasks done. We also knew that the customer would simply expect it to work, and would not mention the constraint when defining stories. To prevent embarrassing bugs, we nailed down a consistent approach that could guarantee we filtered data correctly.

• Pages Written , from c_bass, Germany
• Pop Expenses , from ryanfogle, Michigan, USA
• Glasses of Water, from DugaldWilson, North Carolina, USA
• Windows XP Reboots , from catenate, Iran
• Coughs (I'm Sick) , from trentcarlyle, Colorado, USA
• Tweeple Following Me, from sarach, Washington, USA

Loading javascript at the top or middle of a page can prevent it from loading smoothly. This can make the page appear to freeze halfway through the rendering. You can significantly improve the perceived performance of your application by moving the javascript to the bottom of the page, below all the content it would have blocked. In a complicated web application, this can be a lot of work, but a simple trick can make it a lot easier.

With margin: 0 auto; it’s pretty easy to center content horizontally, but it’s a pain without tables to center content vertically inside either a container or the window. Here’s a pretty simple CSS method I found. In this example, we’ll be centering in the browser window, but this can be applied inside a container as well.

Over the past few months I have been involved with the development of uladoo.com. Uladoo is a small, in-house, collaborative web project between Atomic Object and David Christiansen. Uladoo provides a simple means of creating, updating and sharing charts for people who desire to track their daily activity. Uladoo uses Twitter for creating and updating charts.

David had the idea for Uladoo in the midst of a weight loss effort. He was already an active Twitter user and thought it would be convenient to be able to tweet his weight and have those tweets tracked.

I thought David's idea was interesting because he identified that Twitter could be used as an application's data source. At the time, most of the applications related to Twitter were on the surface of the Twittersphere, facing inward. Twitter clients, tweet management tools, and tweet analysis were all hot. These kind of applications were aimed at enhancing and organizing a user's Twitter experience. David realized that we could think of Twitter as a communication protocol to power Uladoo. Users could input their chart data through a multitude of Twitter clients and we could use the Twitter API to pull our application data.

Because this project was in-house, we had the luxury of being able to exercise our product design and development practices as we saw fit. We viewed the idea as experimental and decided to forgo user research. We decided to release a minimal product that was easy to learn, account free, and simple to use. If the idea took off, we'd develop it further.

Being account free was a curse and a blessing. During our discovery and design phase we kept identifying all kinds of complexities. What happens if a user tweets to the same chart twice in a day? What happens when they skip a day? What level of granularity should we display the data? We kept getting bogged down into the details and started to think that a user would have to provide preferences. We didn't want users setting preferences via Twitter because we thought that violated our principles of Uladoo being simple and easy to learn. Our principles forced us to make judgment calls and design the behaviour in accordance with our idea of the general case. Our self imposed constraints allowed us to move forward and not sputter out during the design phase.

We were able launch Uladoo within five weeks. We spent about a week in design and discovery and four weeks in construction. It was a great experience participating in a small, focused project. We're continuing to add features to Uladoo. After we had about 100 people using Uladoo, we decided to provide a 10, 30 and 60 day view of user charts. We just added a feature allowing users to embed a chart in their blog or web page. Check out the Uladoo Blog for updates on new development.

The question of whether or not to use a CSS Framework has come up of late. There are a few names that are big in the field, particularly Blueprint and 960 Grid System. At the behest of a developer here in the office, I began to research these two frameworks and determine the pros and cons of using an existing framework. Here’s what I found…

Sometimes it's nice to keep a page's footer stuck to the bottom of the browser window until the content pushes it down. It seems simple enough, but it can be a pain to implement with CSS. Here is a very simple example of to do it. This works in Safari, Firefox, IE6, and IE7.

We are using Joyent to host a Ruby on Rails application. We noticed that our application seemed be running slower on our Joyent slice than our personal laptops. Out of curiosity we decided to run a simple benchmark test using irb on both our Joyent slice and our development machine. The following is the script that we ran.

require 'benchmark'; puts Benchmark.measure { 5000000.times {  1 + 1 } }

We were shocked to see a huge difference between our development machines, and our Joyent slice that was running ruby version ruby 1.8.6 (2007-09-24 patchlevel 111) [i386-solaris2].

Development machine time:

1
2

>> require 'benchmark'; puts Benchmark.measure { 5000000.times {  1 + 1 } }
  1.070000   0.000000   1.070000 (  1.079934)

Joyent Slice time:

1
2

irb(main):001:0> require 'benchmark'; puts Benchmark.measure { 5000000.times {  1 + 1 } }
  2.070000   2.650000   4.720000 (  4.723583)

In order to correct the problem on our Joyent slice we compiled ruby 1.8.7 from source. After making this update we saw a huge improvement in the processing time.

Joyent Slice time after ruby update:

1
2

irb(main):001:0> require 'benchmark'; puts Benchmark.measure { 5000000.times {  1 + 1 } }
  0.890000   0.000000   0.890000 (  0.891699)

An incredible improvement! Really makes us wonder what kind of ruby install Joyent does out of the box.

The following walk through describes how we went about updating our Joyent slice. We found that this approach was much easier than trying to remove the old install of ruby.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

# Download, compile and install ruby 1.8.7 in /opt/ruby187
curl -O ftp://ftp.ruby-lang.org/pub/ruby/1.8/ruby-1.8.7.tar.gz
tar zxf ruby-1.8.7.tar.gz
cd ruby-1.8.7
./configure --with-openssl-dir=/opt/local --with-readline-dir=/opt/local --with-iconv-dir=/opt/local --prefix=/opt/ruby187
make
sudo make install

# Download and install rubygems
wget http://rubyforge.org/frs/download.php/45905/rubygems-1.3.1.tgz
tar zxf rubygems-1.3.1.tgz
cd rubygems-1.3.1
export GEM_HOME=/opt/ruby187/lib/gems
sudo /opt/ruby187/bin/ruby setup.rb

# Install gems needed to run the application
sudo /opt/ruby187/bin/gem install rake mongrel_cluster mysql

Edit .profile and put /opt/ruby187/bin at the beginning of the path.

This article on the Joyent wiki provided most of the steps we needed to take.

If a developer mentions using tables in his design, the chic thing to do is to raise your nose in the air, wonder how they created a time-machine from the ancient 90s, and say ‘I would’ve used divs’. That being said, I think we may go too far in our aversion to tables. Obviously, modern CSS dislikes the archaic idea of the table layout, but we must remember that tables still serve a great purpose.

Recently, on a job, I noticed how rusty I had become with tables, and it made me do some thinking. The task had information which was obviously tabular, and I broke down and used an old-school table. While doing this work, I found some very useful updates to tables that help with styling, so I thought I’d pass ‘em along.

If you’ve spent any time doing HTML and CSS development, you know that Internet Explorer is frustrating. “Seriously?” “Yep.” One of the largest frustrations is that each version of IE has different bugs from the next.

But I have some good news. When you’ve tried everything, and you simply cannot make a site look consistent between browsers, there’s a pretty easy fix. In the header, you can put this text below your main stylesheet link. It should look something like this…

Ever create a page that works fabulously in Firefox, and then you try testing in IE 6 or 7, and there’s a chunk of text that has simply disappeared? “Where is it?” you ask the computer. The computer doesn’t respond. I’d imagine that it too must be sick of all the IE questions. So then you try to highlight the content on the page, or maybe you scroll down to see if it has decided to take a vacation by the footer and…

VOILA! It appears!

When debugging a webpage for multiple browser use, it’s easy to overlook the DOCTYPE. Just the other day, I was racking my brain on a particular bug, and it didn’t dawn on me until much later that it was because the page had no DOCTYPE.

It’s an easy thing to forget about, and though we all know a DOCTYPE needs to be present, I believe it’s important to know exactly why its vacancy causes problems.