Chris Johnston

ioXtreme

Chris Johnston — Mon, 08 Jun 2009 04:13:48 +0000

I have got to get me one of these when they come out. Imagine having all of your programs starting up from scratch with the same speed as if you had maximized them. The ioXtreme is 80GB of high-performance, non-volatile storage in the form of a PCI Express card.

There are only two problems with it, one, it isn’t available yet and two, when it is available it will be $895USD.

Designing imperfection into websites

Chris Johnston — Tue, 05 May 2009 16:48:37 +0000

Here is an interesting article on the need to design imperfection into websites in order to make them more human and more accessible.

Elegant Web experiences walk a fine line separating simplicity (yawn) from chaos (huh?). And the rules that govern the quality of the attempt are derived from considerations of natural organization. This can still be elegant — as long as the chaos is modulated within a stable container, constrained by a well-designed illusion of natural order.

Great Web sites have feel — what Leonard Koren had called “heartfelt intelligence.”…Feel only comes about when you tear away the illusion of perfection.

Words are merely the leavings of our intellect, strung together into a story. The same goes for designed artifacts. The more imperfect the artifact, the more they tell of the passage of time, and the more human they become.

So a postulate I’d like to put forth is that when the proper amount of imperfection is present in a designed Web experience, it feels more human. A Web site that is more human becomes more useful, right? Here, we have to be careful. A web site is only more useful if it is elegant in its imperfection.

I don’t usually include this many quotes, but with this article, a precis does a much better job then I ever could.

HTML 4.01 or xHTML 1?

Chris Johnston — Tue, 28 Apr 2009 15:53:29 +0000

Dave Shea has decided to move away from implementing websites using xHTML and is using HTML 4.01. His main reason:

I made the switch more because of overall trends. Six years ago, many of us thought XHTML would be the future of the web and we’d be living in an XML world by now. But in the intervening time it’s become fairly apparent to myself and others that XHTML2 really isn’t going anywhere, at least not in the realm that we care about. For me, a guy who builds web sites and applications for clients that have to work in today’s browsers, XHTML2 is a non-issue. No browser support, no use to today’s web authors. End of story.

This is something I have not really thought about much over the last few years. I made the switch from HTML to xHTML and haven’t really looked back. Now, I am going to have to look into this. I don’t really see anything that xHTML offers over HTML 4.01. I do like the fact that xHTML is easier to parse using an XML parser, but this is a small point given libraries like Hpricot and Nokogiri.

What do others think? Is there any reason to use xHTML over HTML 4.01?

Time to move beyond 960?

Chris Johnston — Mon, 27 Apr 2009 21:05:44 +0000

A width of 960 pixels has become the de facto standard for creating fixed-width web sites. Cameron Moll is asking if it is time to move beyond this width, and if so, what do we move to? I personally really like 960 as a width. It makes for easy to read lines of text and helps to ensure that they don’t get too long.

He proposes widths of 1020, 1040, and 1080. I am not sure the extra 60 to 120 pixels will really make that big of a difference.

With most computer monitors now displaying 1280 or larger horizontal resolutions, it is definitely something to think about.

Multistage deployments with Capistrano

Chris Johnston — Fri, 24 Apr 2009 15:52:33 +0000

I have been trying to set up a Capistrano script for deploying to a staging and production server. I found this very well written tutorial showing how to set up the various cap scripts to work with mod_rails (Passenger).

One note, Capistrano does not copy over the database.yml file. You need to put this in yourself. This tripped me up for a while since I was assuming that it would somehow magically take the database.yml.template file I had and turn it into a database.yml file that I would then have to configure. The Ruby magic doesn’t extend that far .

Keep CSS layout in layouts not in view pages

Chris Johnston — Thu, 16 Apr 2009 01:11:43 +0000

When using layouts in Rails, I strongly suggest keeping as much of the container elements in the layout and using content_for to create sections in which content can be placed.

I am working on a site right now that has used the YUI Grids to layout the site (something I highly recommend for anyone designing a site from scratch). Most of the site uses a two column layout. The application.html.erb file looks like this:


  
    
      <%= render_partial "shared/header" %>
    

    
      <%= yield :content %>
    

    
      <%= render_partial "shared/footer" %>

What is missing is the part that divides the page into your content area and your, in this case, right-hand side area. This part was placed in the rest of the view files. Not only does this mean that it is repeated everywhere and a huge pain to change, it also means that it is much harder for coders, who may not know YUI CSS Grids, to properly lay out pages. In the case of the app that I am modifying, it has also meant that parts of the CSS layout are strewn careless between regular pages and partials.

Instead, this is how the layout page should look:


  
    
      <%= render_partial "shared/header" %>
    

    
      
        
          
            <%= yield :content %>
          
        
      
      
        <%= yield :side_content %>
      
    

    
      <%= render_partial "shared/footer" %>

This keeps everything clean and makes for view pages that look like the following.

<% content_for :content do %>
  put content here
<% end %>

<% content_for :side_content do %>
  put side content here
<% end %>

I think that makes it much easier to see what is happening within view pages. It also keeps all the layout code in one place.

Keep CSS clean

Chris Johnston — Tue, 14 Apr 2009 04:23:07 +0000

I have spent the last few days working with the CSS in an existing web application. It isn’t pretty. My biggest pet peeve with it is all the special cases that exist. If you find yourself doing a lot of the following you are in for a world of hurt when it comes time to redesign your site.

.homepage h3 {
  some style
}
.about h3 {
}
div.box h3 {
}

My advice is to create a style guide and stick to it throughout the entire site. That way, when you use h3 you will know exactly what it is going to look like and it will stay consistent throughout the entire web site.

Another side benefit of doing this is your CSS file will be greatly reduced in size and will be understandable. This will also save on download times for those visiting your site.

Filling browser with background colour using YUI Grids

Chris Johnston — Wed, 08 Apr 2009 03:07:14 +0000

I am not sure if anyone else has had this problem, but one thing I have never liked about using Yahoo! UI Grids library is that I could never get a background colour applied to to fill the entire background. It would only go to the bottom of the #doc div. So if that happened to be half way up your browser window you were left with half a window of white.

I finally figured out how to solve this. Grids, or Reset, adds a background CSS attribute to the html element. To get rid of this, and have your background fill the entire browser simply use

html {
  background: none;
}

Programatically adding tags to contacts in Highrise

Chris Johnston — Thu, 02 Apr 2009 22:53:02 +0000

I have been playing with adding tags to contacts in Highrise programatically. Unfortunately, 37Signals has not added this functionality to the API for Highrise so you have to hack it in. Based on a post on adding contacts, the following code will add a single tag to a contact.

require 'rubygems'
require 'net/http'

contact_id = 12345
connection = Net::HTTP.new("your_account.highrisehq.com")
req = Net::HTTP::Post.new("/parties/#{contact_id}/tags")
req["content-type"] = "application/xml"
req.basic_auth("your_api_token", 'X')
req.set_form_data({"name" => "new_or_existing_tag"}, ";")
response = connection.request(req)
puts response

This will return a bunch of JavaScript that you can ignore.

For comparison, here is the same code using HTTParty. A very nice, easy to use library for interacting with ReST services.

require 'rubygems'
require 'httparty'

class Tag
  include HTTParty
  base_uri "your_site.highrisehq.com"
  basic_auth 'your_api_token', 'X'

  def add_tag_to_contact(tag, contact_id)
    self.class.post("/parties/#{contact_id}/tags", :query => { :name => tag })
  end
end

puts Tag.new.add_tag_to_contact("tag_as_string", "1")

The goal of all this is to create a Highrise API wrapper that includes the ability to manipulate tags. Highrise is great, but the lack of Tags in the API really reduces what you can do with the tool since there is no facility for creating or manipulating lists.

Let people be masters of their time

Chris Johnston — Tue, 10 Mar 2009 17:16:58 +0000

…if you don’t keep your smartest people fully-informed, you’re going to wind up telling them what to do. And telling knowledge workers what to do is one of the biggest causes of mistakes, waste, and general low morale that I’ve ever seen.

I really like this quote from an article about letting employees take control of their time. The two points I got from the article were, one, that in order to make this work, you need to give your employees ownership of the success of the company and, two, that leadership needs to be completely open about everything and tell employees not only the what but the why.

These two points, plus the quote above, translate directly to development teams. One of the practices of an Agile project is group ownership of the code. So if one development pair sees a problem in the code, it is their responsibility to fix it and not ignore it because it is someone elses problem. If there are bugs in the code or a project fails, then responsibility for that is shared by the entire team, not just the developers that implemented it.

Transparency in business decisions can be seen in the use of story cards. I worked on one project were the “so that” part of story cards was missing. We were implementing bits of functionality and not adding business value. This lead to a lot of debates with business as to why we were implementing certain things.

As for telling people what to do, this one drives me crazy. One project I was on, story cards were placed on a wall and given out by the tech lead. Dev pairs were not able to sign up for stories. You could request a story, but it amounted to asking for permission to work on a particular story. You could not just pick up the next story without asking if it was okay to play it first.

People need to feel that they are trusted and once you give them that trust, they will surprise you. Trust them, give them ownership of the project they are working on and allow them to understand both the what and the why and you will amazed at what people create, because now they are not creating something for you they are creating something for themselves.