As I mentioned in my last review, I wouldn’t be updating on a weekly basis, which is a shame because there are so many fascinating discussions going on that might benefit you if you’re running a business that uses and/or relies on the Ruby on Rails framework. I’d like to highlight some of the discussions that have been taking place over the past month or so.

First off… wow! As of this morning, there are *650 members!

Some Recent Discussions

Obtaining Ruby Gigs

Johan Pretorius started a discussion with the following…

“I’ve been lurking on the group for a while now, the time has come to participate … What strategy would you recommend for somebody that wants to break into the Ruby (on Rails) market?”

On a related topic, Jose Hurtado started a discussion asking for tips on how to get a reputation in the Ruby on Rails community for you business.

Some of the responses included:

• Start a portfolio
• Contribute to Open Source projects
• Contribute to Rails through Documentation
• Subcontract through well-known developers
• Start a blog
• Write a book

Read the entire thread and please share any other ideas that you have on this topic with Johan, Jose, and rest of the list. :-)

Taking a full-time job, what about your freelance clients?

Oren writes, “I got a full-time job offer as employee (and not on as a contractor). My current client might need some help on the weekends in the next month, so I might still do contract work. Can I keep my corporation (corp S) while working full time?”

Read the responses

Reality Check!

Starting your own business might sound like an amazing thing to do, but it often comes with a lot of consequences and struggles, which I’m definitely not been immune to.

Michael M. writes, “…added to having to create a company, perform customer support, continue to grow the features, marketing, and the loads of other things I haven’t thought of yet…is there any hope that one person can pull this off while still working at my current job ( with hopes of going it alone when I’m sure it can fly ), and giving time to my family, with very little up front costs. I’ve been reading quite a bit about bootstrapping lately, but to really make the time has been very difficult.”

There were several thoughtful responses where well-known members of the Ruby on Rails community, such as Joe O’Brien Ben Curtis shared through personal experiences.

Joe O’Brien wrote, “I wanted to mainly chime in on the family part. Something that has taken a year for me to figure out how to balance. I would not have been able to do any of it, had it not been for my wife’s full support. I have three kids, all of whom I love spending time with, so figuring out a way to balance it all has been very tricky. Up front though, my wife and I knew this would not be your typical job. It helped that I used to travel and now do not, but it has still been an
adjustment.”

If you’ve been running your own Rails business, please consider responding to this thread and sharing your experience.

Join the Community

As mentioned, this is just a small sample of some of the great discussions taking place on the Rails Business mailing list. If you’re an aspiring Rails freelancer or business owner, be sure to join the community and share your experiences and learn from other members of the community that are willing to share theirs.

As always, have fun!

We’ve been quietly rolling out our new Rails hosting solution over the past month, each week… inviting more people to ask questions and place orders. Initially, we invited some of our business hosting customers, and then sent out invites to those who signed up on the Rails Boxcar announcement list. We’ve been taking orders for the past few weeks and have had sites running on Boxcar for over a month now.

You’ll also notice that we’ve begun to phase out all of our older shared hosting solutions for new customers and are focusing solely on our Business and Boxcar accounts (aside from custom managed/dedicated solutions that we’ve been offering upon request).

To learn more about Rails Boxcar, read the announcement on the PLANET ARGON blog.

In other news, Daniel Johnson, our Lead Systems Administrator broke his arm while riding his bike while participating in Zoo Bomb (and cracked his helmet in the process). He’s at home today on pain medicine and we hope that he has a swift recovery.

If you’re using the bookmarklet for RubyURL, you will want to update it with the latest version as there was apparently a bug in the JavaScript and some URLs would fail to redirect properly. Thanks to the help of Jerome, this is now fixed.

So, head over to RubyURL and update your bookmarket. Not sure what I’m talking about? Watch the video.

When you’re running a Rails application in development mode, you might notice that it takes a little longer for requests to get processed and this is somewhat intentional as the framework is was designed to allow you to run the application and make live changes to it. This way you can do some basic functional tests from your web browser, work on HTML/CSS changes, or anything else that might need to be done in development mode.

Anyhow, this can be slow from time to time and if you’ve done much Ajax work, you might be familiar with how slow this can feel when performing some basic tasks. Well, thanks to Josh Goebel, we can speed up things with a new plugin he just released.

To install via piston:

Like many… I’ve been using del.icio.us for several years and so have some of my closest colleagues. A few of us at PLANET ARGON have been using the for:username tag to send each other links, which has been a great productivity hack as we don’t need to copy URLs and paste them into emails, IMs, or IRC channel windows anymore. One of the things that del.icio.us doesn’t have a totally perfect implementation is sending to a group. There are people in your network, but to my knowledge, there isn’t a way to send everyone in a network the same link without selecting everyone individually. This was adding more time to the process of saving a link for ourselves and our fellow team members. So, we came up with a clever hack… a new delicious user account.

Over the past four months, our team has bookmarked almost four hundred links on topics ranging from Rails plugins, Interaction Design, Business processes, cool new web applications, to any variety of things that we find relevant to our team.

So, all of the links are being sent to a fake user. How do we see the links for that user without having to logout of our current user and into the planetargon account? Well, what we’ve done is take the delicious RSS feed and pipe it through feedburner and given everyone the URL that feedburner provides. Now, we’re all able to subscribe to the same feed and check out links when each of us has time for it.

…and this is what I get to see show up in my RSS reader. :-)

How is your team managing bookmarks? :-)

Yesterday afternoon, we were helping our newest employee, Paige Saez, get setup with new accounts across all of our applications. She uses Google Reader and couldn’t understand why her Basecamp RSS wasn’t working in it. We explained that Google doesn’t provide any way to subscribe to authenticated feeds (yet)… so it wasn’t something she could do. (I still use NetNewsWire because of this problem…)

During the discussion, I said that it probably wouldn’t take much effort to build a proxy for an authenticated feed… and Andy said he’d give it a shot.

10 minutes later… he had an initial version of a RSS proxy application, written in Ruby.

15 minutes after that, we had it up and running on a private server for all of us at PLANET ARGON to begin using.

…and here is the proof!

Wee! Authenticated Basecamp RSS feeds in Google reader. It even works with the openid authentication.

You can grab the code from Andy’s blog post and finally make the switch off of desktop RSS readers to Google Reader, because you know you want to. ;-)

Thanks Andy!

I wanted to give Jing a try… so here goes my first screencast with it.

Enjoy!

Yesterday evening, I deployed the new version of RubyURL. This was a collaborative effort between Chris Griffin and I, which we’re happy to finally push live.

There are a few things that we’re going to push out in near future, such as an API and a new RubyGem.

{width=”500” height=”458”}

Chris volunteered to work on the new design and I did most of the programming in Ruby on Rails. When we worked on this, we really wanted to keep the process as simple as possible, despite some of the problems that the site has been having.

In the end, we have a Rails application that is only 85 lines of code and has a 1:2.3 code-to-spec ratio. I wanted to keep it under 100 lines of code. This means that there is some breathing room for further development.

We also tried out a beta account that I was given for RoundHaus for Subversion hosting. We had a really good experience using their service and were impressed by the plethora of useful features that came with the repository, such as continuous integration, rcov/code coverage stats, and twitter integration!.

If you find a bug, be sure to submit a ticket on the RubyURL bug tracker.

On a side note, we deployed this on a brand new Rails Boxcar, our new hosting solution that will be launched in the very near future. ;-)

It’s been about six weeks since the last Rails Business “Weekly” Review on here, so perhaps it’s worth changing the name to cut me some slack on not being consistent. ;-)

Since the last post, we’ve gone from around 400 members to 555 as of this morning. We’ve had 562 messages as well, so there hasn’t been a shortage of discussions taking place. I’d like to take a few moments to highlight some of the discussions that have taken place and encourage you all to consider participating, if you’re not already.

Licensing and Client Agreements

Tim Case writes,

“My client sent me this agreement drawn up from their lawyer that
included the following:



© the Contractor shall not bundle with or incorporate into any Work
Product any third-party products, ideas, processes, software, codes,
data, techniques, names, images, or other items or properties without
the express, written prior approval of the Company;”

Tim then goes on to ask how his applies to using Ruby on Rails, which as a MIT license and how other consultancies are handling these types of situations. Follow the discussion…

Escrow

Gustin writes, “Does anyone have any escrow experience, legal and cost? I am dealing with a client that got burned bad and we are reducing their fear with escrow on the first two iterations.”

Follow the discussion…

Project Planning tools

Mike Pence writes, “So, I used to use MS Project for the composition of those dreaded Gantt charts, but it has been a few years since I had to be so formal. Anything new and exciting - and more robust than Basecamp - happening in the world of project planning software?”

Follow the discussion…

Not long after, Jim Mulholland started a new thread on the same topic and brought up the open source application, redMine. Follow this discussion…

Ruby on Rails versus .NET

Michael Breen asked a big question on the list, which has sparked an going discussion about the benefits of using Rails versus .NET (and other platforms).

“A couple of months ago I decided to stop actively pursuing .NET gigs to focus on Rails. Several of my existing .NET clients have learned of this through the grapevine and have contacted me to discuss.”

Follow the discussion…

Three things Tim’s learned from Freelancing Rails

Tim Case shared his experience of freelancing with Ruby on Rails and highlights three things that he’s learned.

• The non-code business aspect of Freelancing is demanding.
• It takes 10 hours to bill 6 to 8.
• Figuring out your rate is hard.

Read the rest of Tim’s observations and the discussion the followed.

Client issue tracking and documentation

Jeff Judge writes, “Hello all! I was curious to here how people are handling client issue tracking and documentation.”

Several applications were mentioned for handling issue tracking and the general consensus was that there was still a lot to be desired that current options didn’t provide. Be sure to follow the discussions…

Join the Community

These were just a small handfull of the discussions that have taken place over the past several weeks. If you’re an aspiring Rails freelancer or business owner, be sure to join the community and share your experiences and learn from other members of the community that are willing to share theirs.

Until next time, have fun!

While engaging in another one of our deep philosophical conversations in #caboose, the topic of remembering that great idea that we had before we fell asleep or at any point during the evening.

Manfred Stienstra writes, “I always think of stuff right before I fall asleep and can’t remember them when I wake up.”

This happens to me as well, just not as much as it used to. I keep a small moleskin notebook and a pen on my bed side table and try to get everything in there as it comes up. When I open it, I see notes that don’t make any sense, which were probably after waking up from some bizarre dream. There are many business and development ideas that come up, but it’s often hard to record everything.

I’m sure that there are others who’ve faced this problem. Have you come up with a working solution? If so, would you mind sharing it?

I meant to work on this post… oh about 7 months ago.

Way back in January (7 months ago), Jamis Buck posted an article titled, Testing your views, which gave a few tips on using Test::Unit to, as the title suggests, test your views.

While, I’m not going to rewrite everything that Jamis wrote, I’d like to show you how to test these views with RSpec. (you might take a moment to quickly read his post…)

In this example, I’m going to show you how we’re able to write specs for the following RHTML, which you’ll notice matches the code that he wrote tests for.

Our team is lucky enough to be in a position where we have both designers AND developers working on the same code base in parallel.

Since Ruby on Rails adopts the Model-View-Control pattern for separating business logic from the presentation layer, we’re able to give our designers a lot of breathing room to to design the interface, whether it’s for interaction or aesthetic reasons. However, sometimes this breathing room has resulted in small bugs slipping into the application interface. In general, nothing disastrous, but each bug that slips into the queue, slows down the project and we want to avoid as much of that as possible.

I’d like to share a few issues that we’ve seen occur on various occasions, and then show you what we’ve done to avoid them happening again.

Scenario #1: The case of the changed div id, (victim: designer)

• Designer adds a few HTML elements to the page, defines an id on a

`<div>` tag and styles it with CSS.
```text
-   A few days later, a developer needs to make some changes, tests it
```text
in their favorite browser and commits.
```text
-   Later, the designer doesn't understand why the styling is all messed
```text
up. "It *was* working fine."
```text
-   ...minutes, hours... go by where the designer tries to track down
```html
the issue. "Oh! Someone renamed the `id` in this `<div>` tag. Sigh."
```text
-   Developer apologies, but explains that he needed to do it because he
```text
needed to make it work with his new RJS code.
```ruby
**Scenario #2:** The case of the changed `div` id, (victim: developer)

-   Developer is implementing this cool new Ajax feature into the web
```bash
application
-   The code relies on there being one or many HTML elements in the
    DOM with specific `id` values defined.
```ruby
Example: `<div id="notification_message">`

-   A few days later, a designer is making some changes to the layout
```html
and needs to restyle some of the view that this `<div>` tag is
defined. Designer decides to change the id to a different value for
any variety of reasons. (or perhaps they changed it to use a class
instead of styling it by the id). Often times, we don't know who set
the id or class... and many times the developers aren't savvy enough
with HTML and designers end up cleaning things up a bit.
```text
-   Later, code is checked in and designer didn't notice that the Ajax
```text
was now breaking as they weren't focusing on just the layout.
```text
-   Day or two later, developer sees bug, "Feature X isn't working,
```text
throwing JavaScript error..."
```yaml
-   Developer is confused, "Hey, that was working! What happened?"
-   Developer tracks down the problem, discusses with designer, they
```text
figure out a solution. Problem solved.
```ruby
I could outline a few other examples, but I really wanted to highlight
these two types of situations, as our team has seen this happen on
several occasions. Luckily, we've learned through these experiences and
have taken some measures to try and avoid them in the future.

## Moving forward (together)

Both of the examples above, were essentially the same problem, but
resulted in problems for a different role in the design and development
cycle. While, I've definitely been the victim of #2 several times
myself, I know that I've also been the guilty of #1. So, what can we do
as designers and developers to work with each other without causing
these little problems from occurring? (remember: many little problems
can add up to a lot of wasted time spent resolving them)

Several months ago, I had a meeting with
[Chris](http://chriszgriffin.com/) (User Interface Designer) and
[Graeme](http://blog.imperialdune.com/) (Lead Architect/Developer) to
discuss this very problem. At the time, we were implementing a lot of
Ajax into an application and were occasionally running into Scenario #2.
We discussed a few possible ways of communicating that, "yes, this div
id should NOT be changed (without talking to a developer first)!"

### Idea 1: Comment our "special" HTML elements

We discussed using ERb comments in our views to do something like the
following.
```html
```html
<% # no seriously, please don't change this id, it's needed for some Ajax stuff %>
  <div id="notification_message">
    ...

We all agreed that, while effective, it was going to clutter up our
RHTML code more than any of us desired.

**Team Response:** *Meh.*

### Idea 2: Reserve id's for developers

Another idea that came up, was to ask that designers only use classes
and ids wold be used by the developers when they needed it.
```html
```html
<div id="developer_terriroty" class="designer_territory">
    ...

Chris pointed out that this wasn't an ideal solution as there is a
distinct case for when to use ids versus classes.. and he is very strict
about adhering to the HTML/CSS standards.

**Team Response**: *Not hot about it...*

### Idea 3: Naming convention for Ajax-dependent elements

The third idea that was discussed, was specifying a naming convention
for any elements that were needed by our Ajax code. We played around on
the whiteboard with some ideas and settled on the idea that we'd prefix
our id's with something easy to remember for both designers and
developers.

We agreed on... `x_` (x underscore), which would make an element id look
something like this:
```html
```html
<div id="x_notification_message">
    ...

**x == ajax**... get it?

While this adds the strain of typing two more characters to much of our
RJS code, we don't run into Scenario #2 very often anymore.
````ruby
```ruby
render :update do |page|
    page[:x_notification_message] = 'Something exciting happened... and this is your notification!'
    page[:x_notification_message].visual_effect :highlight
  end

or in client-side JavaScript (where we also use this)...
```bash
```javascript
$('x_notification_message').do_something

```

I find that this helps our team keep a clear distinction between what can and shouldn’t be changed in the views by our designers. Sometimes they have a good reason to do so, but they know that if there is x_, then they should ask one of the developers on the team for assistance in renaming it without causing any problems in the application. It also allows our designers to add classes to these elements, or style the id that we’ve defined.

Team Response: Wow, was that all we needed to agree on? Hooray!

This leads me to some other problems that have/may come up, but I’ll discuss that in my next post on this topic, when I’ll show you how we can use RSpec to avoid these sorts of designer versus developer problems.

If you’re working in a similar environment, how are your designers and developers working, together, in perfect harmony?

Until next time, remember to hug your designer. …and if you’re still having developer design your applications, consider hiring a designer. ;-)

UPDATE: changed examples after a few comments about using div_for as another solution. (see comments for details)