Keep CSS layout in layouts not in view pages

April 16th, 2009 Comments off

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:

<body>
  <div id="doc" class="yui-t6">
    <div id="hd" role="banner">
      <%= render_partial "shared/header" %>
    </div>

    <div id="bd" role="main">
      <%= yield :content %>
    </div>

    <div id="ft" role="contentinfo">
      <%= render_partial "shared/footer" %>
    </div>
  </div>
</body>

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:

<body>
  <div id="doc" class="yui-t6">
    <div id="hd" role="banner">
      <%= render_partial "shared/header" %>
    </div>

    <div id="bd" role="main">
      <div id="yui-main">
        <div class="yui-b">
          <div class="yui-g">
            <%= yield :content %>
          </div>
        </div>
      </div>
      <div class="yui-b">
        <%= yield :side_content %>
      </div>
    </div>

    <div id="ft" role="contentinfo">
      <%= render_partial "shared/footer" %>
    </div>
  </div>
</body>

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.

Categories: Ruby on Rails, Web Development Tags:

Keep CSS clean

April 14th, 2009 3 comments

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.

Categories: Web Design Tags:

Filling browser with background colour using YUI Grids

April 8th, 2009 Comments off

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;
}
Categories: Web Design Tags:

Programatically adding tags to contacts in Highrise

April 3rd, 2009 2 comments

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.

Categories: Ruby Tags:

Let people be masters of their time

March 11th, 2009 Comments off

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

Categories: Agile, Thoughts Tags:

Manifesto for Software Craftmanship

March 10th, 2009 Comments off

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.

Categories: Application Development Tags:

Nokogiri works on Solaris 10

February 20th, 2009 Comments off

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.

Categories: Ruby Tags: