Keep CSS clean

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

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 <body> 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

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

…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.

Manifesto for Software Craftmanship

A few days ago, some software developers got together at 8th Light and created the Manifesto for Software Craftsmanship. If you are a professional software developer who cares about the code you are creating, then you have a responsibility to sign and adhere by the principles laid out in the manifesto.

As aspiring Software Craftsmen we are raising the bar of professional software development by practicing it and helping others learn the craft. Through this work we have come to value:

Not only working software, but also well-crafted software
Not only responding to change, but also steadily adding value
Not only individuals and interactions, but also a community of professionals
Not only customer collaboration, but also productive partnerships

That is, in pursuit of the items on the left we have found the items on the right to be indispensable.

For a better understanding of what this means, check out this video of a presentation that Robert Martin did on Craftmanship and Ethics.

Nokogiri works on Solaris 10

As a quick follow up to my previous post, Nokogiri works fine on Solaris 10 as long as you link to the most current version of Libxml2 (2.6.31). Our problem was that, although I had installed the newest binaries, Nokogiri was linking to a previous version (2.6.10). Once we updated the link, by changing the LD_LOAD_PATH environment variable, everything worked great.

Weird behaviour from Nokogiri on Solaris

At work I have been playing around with Webrat to see if it can speed up our acceptance tests. We have been using Selenium, but the tests are taking far too long to run (somewhere around 40 minutes or so, rough guess). And the majority of the tests are not testing JavaScript or AJAX.

In the tests that I did, Webrat worked amazing with a huge speed increase. One test went from 134 seconds down to 2.5 seconds. The glitch is that Webrat is designed to be used with a Ruby web app–Rails, Merb, Sinatra, etc–and we want it to test a Java app running in Tomcat. Thankfully, this is fairly easy to do. You just need to set the mode to Mechanize and add a few lines to include Webrat::Methods and Webrat::Matchers into RSpec.

The problem we ran into was when we tried to run the tests on our Solaris box. Nokogiri is only returning the doctype and comment parts of the fetched HTML. Running the following in IRB only returns the doctype:

>> require 'mechanize'
>> require nokogiri'
>> a = WWW::Mechanize.new
>> r = a.get("http://www.google.com")
>> s = Nokogiri::HTML(r.content.to_s)
>> puts s
=> <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" "http://www.w3.org/TR/REC-html40/loose.dtd">

On Ubuntu and my MacBook Pro, this prints out the entire HTML, under Solaris, it only prints out the Doctype. I have raised a ticket with Nokogiri, but am wondering if anyone else has experienced this? The only difference between Solaris and our Ubuntu dev boxes is the version of Ruby, 1.8.6 p0 and 1.8.6 p111 respectively.

« Previous PageNext Page »