Mister Bleigh

My company, Intridea are avid users of Unfuddle as it’s by far the most feature-filled-while-remaining-simple solution out there for software project management. Unfuddle comes with Subversion hosting, but it’s harder and harder to ignore the strengths of Git as a SCM solution. Not one to sit idly by when there’s hackery to be done, I put together a rough tool for anyone who has a GitHub account that provides a webhook to automatically create Unfuddle changesets.

All you need to do is grab the bridge code from It’s GitHub Home like so:

git clone git://github.com/mbleigh/github-unfuddle.git

And follow the setup instructions in the README. The webhook is running off of Sinatra and is very lightweight. Once it’s running you can start seeing changesets just by pointing your post-receive URL to the webhook, and you’ll soon start seeing updates in Unfuddle like so:

This is still in its beginning stages so there’s bound to be a kink or two, but that’s the beauty of GitHub! Just fork, fix, and pull.

Like so many other Rails developers, I have started to see the advantages of Git as a version control system. I’m not totally there yet as far as understanding, but when one of my friends got me a GitHub I figured it was time to make the great migration. I have moved all of my plugins into GitHub and will be doing all further commits etc. to these versions of the projects instead of the old SVN.

Here are direct links to all of the GitHub repositories for reference:

• Acts as Readable
• Acts as Taggable On
• Browserized Styles
• Needy Controllers
• Princely

GitHub seems awesome and I think that it is generally going to be great for the open source Rails community to have such a powerful repository for plugins and other hacks.

For those of you who aren’t on Git yet, sorry! I don’t know of any simple-to-setup Git/SVN sync tools, but if anyone else does I’d be happy to keep the SVN and Git repositories in sync.

The other day when Zoho People was announced I came to the realization that even though I had heard about Zoho in 20 different blog posts over the last year or so, I had never taken a moment to go check out what they were all about. With a full online office suite, it’s definitely something I’m interested in and could use. So why didn’t I take 5 minutes to explore further?

Their Logo. It had been attached to all of the posts about them, and when I see it I just instantly lose interest in the company and their products. This is not the logo of a company that wants to be taken seriously for a productivity suite, it’s the logo of some company that sells teddy bears online that you can customize…or something. It is such a stark disconnect from the target demographic that I really just can’t understand the thought process that went into it.

Now I may be shallow in writing off this company solely because I didn’t like the look of their logo (though I would argue that’s a perfectly reasonable thing to do), but the point is that it doesn’t matter at all what features, awesome back-end programming, and next-generation online collaboration Zoho offers. I never found out more about them because the image I was presented was not one that appealed to me.

The design of a company’s logo, its products, its website, everything, are not throwaway concerns. In a split-second, a person might look at your corporate website and decide “This company doesn’t look professional enough.” There is a critical period in the very first moments a potential customer sees your product that may well inform the rest of your relationship with that customer. Without an appealing aesthetic front, you will never make it to the meat of your pitch, because they have already written it off mentally.

This, I feel, was the largest gap between my college Computer Science education and the real world. I’ve always been a designer as well as a developer, but when there was absolutely no emphasis placed on the user experience or the aesthetics of the software that we were building for classes, I got frustrated. Not everyone has an eye for design, and that’s not a problem. But if a product is to be taken seriously, someone along the line has to take it and make it look good, because behind-the-scenes magic will always be just that: behind the scenes.

In an effort to practice what I preach, I am going to start including more images and visual components to these posts. Looking at my blog, it’s an enormous river of text with very little visual attention. Images break up the monotony of the posts and are generally helpful to convey the message of the post. So it’s time to start using them!

I saw a post on 9rules the other day entitled from psd to code my way and thought that sounded like a good idea for a post. Every designer seems to have their own process to go from the image in front of them to the final code, and I think there is something to be learned from hearing about others processes. This is how it works for me.

Step One: Write the Markup

I’m not sure how many designers do this, but I don’t create a single image or style or implement a single piece of the design until I have my (near) final XHTML document. My first step is to open up the PSD, open up a TextMate window next to it, and start writing the code. I write out every last piece of the design in completely semantic XHTML using standard classes and ids that I use on almost all sites I code.

By making the XHTML before I do anything else, I make sure that the markup is as semantic as possible: I’m not sacrificing anything at this point to ‘make the design work’ and so the code that comes out is clean, simple, and well-formed. As I go along I validate the XHTML to make sure I’m not doing anything like forgetting to close meta tags or the like.

The only thing I always do that isn’t strictly semantically necessary at this stage is put a #wrapper div around the whole thing since I know I’m going to need it to fix my width and stick my footer (see Exploring Footers on A List Apart). There are also a number of tricks that I use over and over (a text-indented out h1#logo for the logo, etc.) that I write into the code that make semantic sense and help with the styling later.

Step Two (Optional): Reset that CSS

At this stage, I’m ready to start styling with CSS. My first act is to include Eric Meyer’s Reset Reloaded CSS to get me to a completely blank slate from which I can build my style rules. This isn’t strictly necessary, but helps level out the browser defaults difference.

Step Three: Setup and Repeating Parts

I actually don’t have a separate “slice up the PSD into images” and “code the CSS for the site” stage. I find it goes much more quickly and I create much cleaner styling when I code a section at a time and generate the images as necessary by hiding, slicing, and selectively saving when I need a part of the image. The first thing I do in this stage is to set up my general page dimensions, fonts, etc. I make my link and heading styles, get the font sized the way I want it in general, and fix the width of the content.

The next thing I usually do is tackle the header. It is finally at this point that I will actually do something in Photoshop: first I slice out the logo and save it as such, making a note of the dimensions. Then I will take any menu styling and convert the corresponding layer into a Smart Object. I do this so that I can open it in its own document to make its images using the Sliding Doors Technique. I use sliding doors for almost every menu system I have ever coded, and its usefulness is not restricted to tab-based navigation.

I usually put my CSS in a <style> tag in the document itself while I’m writing it from scratch. This allows me to keep a single document open to make all the changes I need, and it’s a simple matter to cut and paste it into a separate file when I’m finished. This also helps with using TextMate’s live preview. I do all of my initial style checking in Firefox/Safari, and relegate compatibility to a later step.

Once I’ve finished the header, I move on to any other pieces that will be replicated throughout all pages of the site. I usually slice up one or two images at a time as I’m writing the styles, giving me a chance to look at the dimensions as I’m doing so and keeping it all to a “only what’s necessary” point. I also make it a point to name my images for the elements they will be backgrounding, as it makes it extremely easy to write the style rules (oh, I’m setting the background image for #footer? It must be footer_bg.png that I need).

Step Four: Styling Each Page

Once I’ve pulled out all of my repeatable parts and styled them, I will cut and paste that code block into my stylesheets directory and start a new style block on the page to style the page-specific elements. Once I finish that, I will pull it out into a stylesheet named for the page, and do so for as many pages as have designs and need styling.

Step Five: Browser Compatibility

This whole time I’ve been working in the Web Preview in TextMate (which runs on WebKit like Safari), so now it’s time to test in other browsers. I pull up Firefox and expect it to look more or less the same with maybe a tweak here and there. I then fire up my VMWare Fusion image to run Internet Explorer 6. This step can be anything from a slight headache to a major catastrophe, depending on how complex the style of the page had to be. If it’s the former, I will usually try to just use a few CSS hacks (html > body is a personal favorite of mine for targeting IE6) to get the style into line. If it’s more serious than that, I will use a heavier solution.

So now I’ve coded up my page into valid XHTML, extracted the CSS and images that I need to make it work, and I’m ready to ship it off! The process can get a bit tedious, but this is what I’ve settled into after coding countless sites and works the most quickly for me.

When writing an application there’s a number of times where it can be very useful to know whether or not a user has seen or accessed a piece of information. I recently had to write a solution to such a need and have wrapped up the result in a plugin for your enjoyment.

ActsAsReadable allows you to create a generic relationship of items which can be marked as ‘read’ by users. This is useful for forums or any other kind of situation where you might need to know whether or not a user has seen a particular model.

Installation

To install the plugin just install from the GitHub repository:

git clone git://github.com/mbleigh/acts-as-readable.git vendor/plugins/acts_as_readable

You will need the readings table to use this plugin. A generator has been included, simply type

script/generate acts_as_readable_migration

to get the standard migration created for you.

Example

class Post < ActiveRecord::Base
  acts_as_readable
end

bob = User.find_by_name("bob")

bob.readings                      # => []

Post.find_unread_by(bob)          # => [<Post 1>,<Post 2>,<Post 3>...]
Post.find_read_by(bob)            # => []

Post.find(1).read_by?(bob)        # => false
Post.find(1).read_by!(bob)        # => <Reading 1>
Post.find(1).read_by?(bob)        # => true
Post.find(1).users_who_read       # => [<User bob>]

Post.find_unread_by(bob)          # => [<Post 2>,<Post 3>...]
Post.find_read_by(bob)            # => [<Post 1>]

bob.readings                      # => [<Reading 1>]

And that’s all there is to it! It’s not an incredibly complex set of features, but I find it to be a pretty useful one. If you have any questions or issues, please feel free to post them on the public Trac