Warehouse is a Subversion browser that “doesn’t suck.” You can find Corkboard’s at http://warehouse.corkboardinc.com. There are currently four projects available: ActiveBudget, Food Lab, Wiffled, and the secure associations plugin. Previously ActiveBudget and secure associations were available on Google code. I’ve dumped the repository from Google into the Corkboard repository and that’s where future development will happen.

The big news is you can now see the source code of Food Lab and Wiffled. To me, opening up the source for our internal projects is a no brainer. It’s a great way to showcase the code we write and also benefits the community by providing examples of real world applications.

If you’d like more technical information about the Corkboard repository, check out my post on the Grinding Rails blog.

BarCamp Manchester was yesterday and it was a lot of fun. I kicked off the day with a presentation called Semantic CSS. I tried to give an overview of the CSS best practices we use. The slides don’t have tons of content, but they do feature both the Highlander and tribbles.

One month after announcing ActiveBudget, it’s time for a refresh. We think it’s important to give products a tune up a few weeks after launch. We did a similar tune up for Daily Sales.

The 2.0 I speak of isn’t really version 2.0. Version numbers don’t really make sense for web applications. I’m talking about that other 2.0, Web 2.0. Yes, you are free to roll your eyes - I will join you.

Tagging - Each transaction in ActiveBudget used to belong to one category. At first I liked the simplicity, but I missed the flexibility of tagging. So now each transactions can effectively belong to any number of categories. This is implemented through the Web 2.0 standard of tagging.

On the application side, all the categories were converted to tags and attached to transactions. Just about every site has their own tagging format. Delicious is space delimited, 43Folders is comma delimited, and Flickr is space delimited with quotes for multiple word tags. I decided to go with the simplest solution - comma delimited tags.

Analytics - I’ve begun experimenting with new techniques to visually represent spending. Representing expenses as a pie chart doesn’t working with tagging. That graph has become a ‘bubble’ chart. Each tag is represented by a bubble who’s size is determined by the number of uses. As the total spending for that tag increases, the bubble floats higher.

I think this graph has a lot of potential. It currently only uses two dimensions to represent data. There are still two dimensions unused - the X axis and color. I’d like to implement some sort of clustering - either grouping similar tags on the X axis or by color of the bubble.

The second new graphs shows income and and expenses over time. It sums each and present it as an area. This way you can easily see when you are spending more money then you have.

Design - I recently put a new design on Wiffled, and thought it would look nice on ActiveBudget as well. It gives the page a little more structure and is easier to navigate. Since ActiveBudget is a teaching app, I’m putting a lot more emphasis on the HTML and CSS rather than the actual look of the design. The new design makes great use of semantic markup and its goal is sustainability.

The 2.0 edition of ActiveBudget is far from complete. A lot of the design still makes me cringe, but it’s stilly my everyday app for tracking spending. Expect new changes to come as I get time to work on it.

If you’re not familiar with the idea of baseline rhythms or grid layouts, check out A List Apart’s great overview. The best tip I picked up from that article is Khoi Vinh’s background image trick.

Without further ado, the results. Here’s what the site used to look like:

You’ll have to check out the full size version to really appreciate what’s going on. Frankly, I’m surprised it started out as good as it did. But behold the improvement:

You’ll notice all the text, no matter what size or type, all line up the same grid. Without the illustrative grid, it’s probably not something most people could pick up. However, on such a heavy text site, it has a huge effect on usability.

Next up, I will get this blog going with the same rhythm.

ActiveBudget is the software I use every day to track my spending, income, and hours worked. It works so well for me, I wanted to share it with the world.

Everyone has their own way of handling a budget. I’ve put together a quick screencast to show how ActiveBudget works for me. I’ve tried my best to make ActiveBudget applicable to everyone.

However, even if ActiveBudget isn’t for you, I’ve decided to release it as open source under the MIT License. If you’re a new Rails developer and would like to see how to make a production app, ActiveBudget has a lot to offer.

General Concepts

• REST design with integrated API
• Test Driven Development
• Using Flash to create graphs
• Deploying with Capistrano

Technical Pain Points

• Handling time zones
• User authentication with an API
• Securing ActiveRecord associations
• ActiveRecord migrations
• Using the Redbox lightbox
• Rendering calendars

So check it out and let me know what you think. I have a hosted version up at http://activebudget.org or you can get it from the Google Code project. The easiest way to get the source is through Subversion:

svn checkout http://activebudget.googlecode.com/svn/trunk/ activebudget

I’m not a designer, so it could certainly use a nice CSS treatment. It’s also far from feature complete. I plan to add SMS text messaging and more reporting in the future, so stay tuned.

Using classes like “float_left” (.float_left { float: left; }) breaks the separation of markup from presentation and makes it difficult to change layouts / looks just by switching stylesheets.

It’s an excellent point. In a follow up email, Jonny pointed me to this W3C tip. The essential point is that CSS class names should answer the question why and not how. A class named red says how something should look. A class named warning would answer why.

After listening to Hampton Catlin speak about Haml on the Ruby on Rails Podcast it really got me thinking about website documents as a DOM rather than a random string. Semantically meaningful CSS is an important element of a well constructed DOM.

Since I’m not a designer by trade, I approach UI work like programming. I do a lot of iterations and continuously distill XHTML to its most terse form. As an agile developer, I want to see results as quickly as possible. Early on this leads to very scary looking views. For example, a snippet from Wiffled:

<% for comment in @player.comments -%>
  <div style="border-bottom: 1px solid #ddd;">
    <p style="margin-top: 1em;">
    <% unless comment.sender.picture.nil? %>
      <%= image_tag comment.sender.picture.public_filename(:thumb), :style=>'float:left;margin-right: 1em' %>
    <% end -%>
  </div>
<% end -%>

Yuck! However, this is exactly how I work. I didn’t plan what I wanted the page to look like, I just wanted it to work. The best way to do this is to utilize the style attribute directly. This gives you the freedom to play around and try new things easily. Some might call it Rapid Development. I just call it GSD.

Of course if I left code in the above state, I wouldn’t be very good at my job. I believe it’s the next step that really separates web developers. Writing good models and controllers will get you straight up developer cred. But writing great views? That’s the specific domain of web developers.

Rails is really great at the M and C of MVC. ERB is nice, but it’s not a leap on par with the rest of Rails. The next big web app innovation will almost have to come in the View space. I highly suspect it will come from the Ruby community because a great view framework will require a lot of opinions. Semantic CSS and rapid development are some of the things I care about, but I’m sure you’ve got lots of concerns of your own.

Since then, Hot or Not has been an unqualified success. The founders got rich and the community grew. Hot or Not could probably continue the status quo indefinitely. However, the company has decided to shake up their business model drastically.

Hot or Not’s revenue is based on premium subscriptions, which allows users to contact each other directly. Founder James Hong claimed conversion rates at 15% - which is ridiculously high. It accounted for the lion’s share of their revenue.

But in a really surprising move, Hot or Not has decided to move towards a free model. Users won’t have to pay for a subscription to meet each other. In the short term, this lead to a dramatic decline in revenue. However, their page views have sky rocketed. This of course will lead to significantly more ad revenue. Hot or Not should have no problem remaining profitable in the future.

Initially I was very impressed with this move. I believe community sites should try their hardest to provide as much free content as possible. Unfortunately free content is usually support by ads. I wish more communities could follow the model of Rocketboom and NPR. They understand people don’t like ads and keep them at a minimum.

Mingle is an interesting departure for ThoughtWorks. Derek Walsh outlines the evolution of ThoughtWorks Studios in this blog post. Mingle is the first product from the Studio. It’s a project management web app tailored for agile development. It’s an interesting idea, and the agile flavor gives it a powerful differentiator in the crowded project management space.

But I’m not concerned with the quality of the project at the moment. ThoughtWorks and ThoughtWorks Studio exemplify the division between the Rails and Enterprise communities. ThoughtWorks clients are slow moving and cautious. ThoughtWorks Studio makes products for agile companies. So how do you bridge the gap?

ThoughtWorks decided to invest heavily in JRuby. While Java and Ruby are about the same age, Java has spent most of its life settling into the enterprise market. It’s accepted. It’s safe. Ruby on the other hand is still seen as new and unreliable. It’s untested. It’s not safe.

ThoughtWorks has taken an ‘unsafe’ technology and wrapped it in a safe one. It’s like sugar coating a pill. At the core, Mingle is Rails. Will clients feel better they can just download a .war and deploy it? Probably. Should they? Definitely not.

What ThoughtWorks should have done is leverage their authority to make Ruby and Rails more accepted. Rather than wasting time with JRuby, which I feel has no long term value, they could have made the world’s greatest Rails deployment system. There’s nothing preventing someone from creating a one click Rails server installation.

To most Rails developers, the enterprise is still anathema. However at this point, there’s no question that Ruby and Rails are headed toward the enterprise. The technology is just too good. This is where ThoughtWorks has really excelled - using great technology to solve big problems. I just wish they would represent Rails fairly rather than hiding it behind boring old Java.

Microsoft® Silverlight™ is a cross-browser, cross-platform plug-in for delivering the next generation of .NET based media experiences and rich interactive applications for the Web.

Lots of flashy buzzwords, but nothing that really says what it can do for a developer like me. During a podcast on TalkCrunch, Silverlight product manager Brian Goldfarb mentioned dynamic languages like Ruby about every other sentence, so I felt compelled to check it out.

Microsoft doesn’t have much open source credibility, but I was willing to give them the benefit of the doubt on Silverlight. If it’s truly going to be successful, it really does have to be “cross-browser, cross-platform.” So I was a little surprised to find the beta download for a Mac running Firefox was a .exe file. Thanks guys!

Eventually I got the proper .dmg (gotta use Safari some times) and installed Silverlight. Now it was time to check out the demos. When you distill down all the hype, the current state of Silverlight is one thing: movies. The most prominent demo on the Silverlight site is the Fox Movies trailer for Fantastic Four 2. After waiting to buffer the file three times, I was able to watch the trailer. Of course I’ve been able to do the same thing, in true high definition, in Quicktime for months. Color me unimpressed.

The final nail in the Silverlight coffin was this page. Please click that and let it soak in for a minute. I’m really not sure what it’s trying to accomplish. There’s a navigation widget-y type thing on the side, but that’s something easily accomplished in pure CSS. The insane part is the rest of the site. Seriously.

That’s right, it’s a huge jpg. What? I don’t even understand what they are trying to demonstrate. Personally I like my websites with text.

Alphabetized Stylesheets - There’s nothing more annoying than scrolling over a huge .css file to find one class definition. Alphabetizing the file makes any entry instantly findable.

Group Related Definitions - All the styles related to the header should be right next to each other. This works well with alphabetizing because each definition should begin with #Header. In general we prefer one big stylesheet, but if you begin to have an overwhelming number of header attributes, they could be moved to header.css.

Avoid Overloading Definitions - Just because 3 different types of text need to be bold, don’t define them all at the same time. It’s better for your stylesheet to be more verbose, but more easily searchable. Also, decoupled definitions makes things easier to change in the future.

Use id and class Semantically - ids should only be defined once on a page. They are a perfect fit for things like headers and footers.

Differentiate id and class Stylistically - They have different meanings, so they should look different too. Use UpperCamelCase for ids and lower_case_underscored for classes.

Use classes as Building Blocks - Define some commonly used classes with a single style element. For example:

.float_left    { float: left; }
.margin_center { margin: 0 auto; }
.text_center   { text-align: center;  }

Since you can define multiple classes on an element, just include the building blocks you need. This works really well during the design phase since things will inevitably change around.

Good style is a requirement for a sustainable web site. If you use a consistent and reliable style, your future self will thank you.

Update: Jonny’s comment about the example classes is exactly correct. Those are really bad example to use. I’ve posted more about this in a recent entry.