RubyURL was a project that I built about 2 1/2 years ago as a late night attempt to see what I could build and deploy with Ruby on Rails in a night. It’s nearing 50,000 unique website links, has a Ruby gem that you can use with it, and rbot plugins.

I’ve rewritten it about three times in the past six months, to try out some new approaches, but haven’t deployed with a new version as I’ve been waiting for someone to help me with a new design. Chris has offered to help out and once we integrate his new design with it, we’ll be launching it.

Everything is not great in RubyURL land though. It appears that it’s become an easy target for comment spammers to abuse the site to generate rubyurls and paste those links in their spam comments. Several pissed off bloggers, forum administrators, and system administrators have emailed me to complain that I’m spamming their site. Sadly, even with a basic disclaimer on the site, they still like to blame me for their spam. It’s gotten common enough, that I’ve written a template email that I respond with that explains how the site works and that I’m not accountable for people posting links to my URL redirect tool.

You can see that it’s popping up around the net via a google search.

So, I’ve been trying to think of ways to make it easier for people to flag URLs as being abusive of the site. I’ve not come up with any elegant solution that doesn’t force the good users of the site to have more steps in their process to create a basic RubyURL.

The ideal (and current) workflow:

• User navigates to http://rubyurl.com
• User pastes in long url into text box/area
• User submits form
• User is provided with new (shortened) rubyurl
• User copies the rubyurl and does what they want with it

(generally... pastes into IM, IRC, Email, etc.)
```yaml
Some people have suggested using a user system to do this, but I really
don't like that as a solution.

Another idea, which I built... and later removed from my new version,
involved having the original url load in a frame, and then provide a way
for users to flag it as 'spam', 'nsfw', or 'dead'. Then, we could
provide the user with a warning that the following URL was flagged
before, **are you sure you want to continue?** I didn't like this as a
solution in this way as it felt very obtrusive to have a rubyurl frame
at the top of the browser window.

One person suggested a captcha to try and verify that the user is human,
but there are problems with this.

-   I really dislike captchas. ;-)
-   This doesn't prevent spammers from using the ShortURL gem, which
```text
does everything via an API.

In regards to the API, this could be enhanced by requiring that everyone register an email address to get an API key, but only solves the API abusers.

I’m starting to brainstorm some solutions that specifically help the requests made through the web. I haven’t checked the logs enough yet to verify it, but I have a strong suspicion that much of the abuse is happening through a web-based bot, not through ShortURL… because Ruby developers are nicer than that. (I hope…)

So, I am curious… dear readers of my blog. How might you solve this problem without disrupting the user experience? Or, should I just stick with what I’ve got going and find a better way to respond to pissed off bloggers who think I’m spamming them?

Discuss…

It’s been a month since I posted, Audit Your Rails Development Team and now I find myself sitting in a hotel room in Mankato, Minnesota with Graeme after a long day of walking through the documents that we delivered to our client after conducting a Rails Code Audit and Review. Our client felt that it would be a great idea to have us visit with six of their employees and walk through the various topics that we brought up in our process. We’ve been doing several of these audits recently and are thought that it would be a good idea to begin sharing some problems that we’ve discovered across projects.

As much as we like to find lots things that we’d recommend improving in Rails applications, we also want to make sure that as many projects as possible avoid some of these common oversights. So, expect to see more posts related to things that we find through our Code Audit and Review process.

Today, I’d like to point out a potential security problem that is often overlooked by developers and system administrators.

Log files.

Does your application request any of the following information from your users?

• Social security number
• Credit card date (number, expiration date, etc..)
• Passwords

BY DEFAULT, all of this data is being written to your production log file. Even if you’re encrypting this data in your database, request parameters (get/post) are all written to your production logs without any encryption. Log files are also notorious for having insecure file permissions, so if you’re on a shared host, other accounts on the server might be able to view them. Regardless of how secure you think your server is, this isn’t data that you want sitting around.

Lucky for you, Ruby on Rails has an easy solution to this problem! All that you need to do is use the filter_parameter_logging method in your controller(s). We generally add something like the following to our application controller.

Earlier today, I was booking flights for Graeme and myself as we’re heading to Minnesota soon to visit one of our clients. While purchasing the tickets on Travelocity, I was glad to know that they remember that I’m a vegetarian. However, I almost made the mistake of submitting the form with the following meal preference for Graeme.

I found it amusing that this was the default in the drop down.

I finally decided to put my claimID to use today with the announcement that Basecamp now supports openID. This means that I can easily access all of my Basecamp project with a single login. Some of our clients have their own Basecamp projects and having everything spread around (different usernames, passwords…) made it difficult to manage. I just modified my accounts on a few Basecamp sites and now see them all listed for me to navigate between.

update: Minor annoyance. This caused all my RSS feeds to break because I subscribe to each project individually. I assumed that they’d allow me to now use my openid/password for all my RSS feeds/iCal subscriptions, but they provide you some unique hash for the password. Not sure why they decided to do that… instead of allowing me to use my openid/pass for the subscriptions.

If you’re working with Ruby on Rails and are looking for ways to improve your existing code base, I would encourage you all to read the following blog posts.

• [Skinny Controller, Fat

Model](http://weblog.jamisbuck.org/2006/10/18/skinny-controller-fat-model),
Jamis Buck
```text
-   [Find methods in
```text
controllers](http://blog.imperialdune.com/2007/4/19/find-methods-in-controllers),
by Graeme Nelson
```ruby
-   [RailsConf Recap: Skinny
```text
Controllers](http://www.therailsway.com/2007/6/1/railsconf-recap-skinny-controllers),
The Rails Way
```text
-   [Rspec notes from the trenches
```text
2](http://blog.caboo.se/articles/2007/6/19/rspec-notes-from-the-trenches-2),
by Courtenay

Hopefully… you’ve already read each of them and as a result… put your controllers on a diet.

It’s been just over a year since I posted the article, Install Ruby, Rails, and PostgreSQL on OSX and it still gets quite a bit of traffic. Unfortunately, there have been a few changes in the install process that have caught people.

Today, I am leaving my PowerBook G4. It’s being replaced with a MacBook because the logic board is on the fritz. So, guess what that means? I get to install Ruby, Ruby on Rails, PostgreSQL on OS X again! I figured that I would post a revised version of my previous article for those who may go through this same process in the near future.

::: warning [WARNING]{.caps}: This post contains some outdated instructions. Please read Installing Ruby on Rails and PostgreSQL on [OS X]{.caps}, Third Edition, which is focused on Installing Ruby on Rails on Leopard. :::

Author of The Art of Project Management, Scott Berkun, introduces Asshole Driven development.

“Asshole Driven development (ADD) - Any team where the biggest jerk makes all the big decisions is asshole driven development. All wisdom, logic or process goes out the window when Mr. Asshole is in the room, doing whatever idiotic, selfish thing he thinks is best. There may rules and processes, but Mr. A breaks them and people follow anyway.”

Read the rest…

In response to my article, Audit Your Rails Development Team, Tim Case writes,

“I think what you are doing has value and I’ve been anticipating that someone in the rails community would step up and do this, hence the question I posed because I’ve thought about that thorny issue too. I have a feeling Planet Argon is making the first step in a direction that has been building, Peer review has the potential to be positive for the entire community, provided that it’s shepherded properly and with care.”

It’s been just over a year since we first made a public announcement of our Rails Code Audit and Review service and we’ve had different types of clients inquire about it. We make sure to call it a code audit and review because we’re not aiming to only point out flaws. We see our service as a way to help stake holders gauge the capabilities of their developers while also providing developers with some more insight to how things could be done differently. There are a lot of developers using Ruby on Rails now and it’s safe to say that there are many that aren’t very good yet. Some may argue that the ease of getting started with Rails makes it easy for inexperienced developers to stay just good enough and never take the next step. We’ve seen some beautiful code and we’ve seen some horrific code. Some of our clients have made the tough decision to fire their existing freelancers after we’ve completed our analysis… but we’ve seen several situations where our clients were happier with their developers after.

For example, we recently completed a code audit and review for a client, which came to us with some concerns about their development team. Things seemed to be going slower than they thought it would and really wanted to have an outside opinion about the quality of their work. Overall, their application was being developed really well and the biggest problems that they had were related to a lack of testing. So, we’re now walking them through the process of integrating RSpec into their development process. Their development team admitted that they suffered from a lack of testing, but were very honest about the fact that they just didn’t know where to begin as it wasn’t something they had time to learn before. We’ve been able to provide them with some direction and now we’re available to answer questions and review their work from time to time. The outcome was good for everyone. The developers are better off because their manager has more confidence in them. The manager has more confidence in the product as a whole and knows exactly where his team should focus their attention on next. We’ve gained a new Rails consulting client and get to help them with their cool project.

While we love working on entire projects from start to finish, we also love working with other developers and development teams. This has been one of our favorite types of client relationships. We’re currently working with a handful of people as they work their way through the project life cycle and we’re always a phone call, Basecamp message, or email away from assisting them. I feel that these types of services are important to the Rails community, because we’ve witnessed situations where clients were unhappy with Rails because they weren’t happy with their developers. We’ve seen people drop Rails in favor of something else because of the poor quality of code that was being written in Rails. When bad perceptions spread, it’s bad for the community as a whole.

What we can do, is become the backup team for the client and/or development team. Should they run into any weird deployment issues at 2am on a Sunday morning or aren’t able to track down the cause of some performance issue, we’re another set of people that can help out. While we don’t know every nook and cranny of our consulting clients’ applications, we do have a good understanding of them. This allows us to dive in and help more quickly than we can for clients that call us for the first time a few hours after they had an emergency.

It’s my opinion that these types of services are very valuable and highly encourage other consultancies in the Rails community to offer them.

If you’re part of a development team and/or a freelance developer and looking for this sort of relationship, please contact us to see how we can assist you.

First of all, I’d like to welcome the more than fifty people that have joined the Rails Business group since my last post. Over the past week, there were less posts, but we did cover a few important topics, which may be of interest to you.

Subcontracting

Michael Breen asked a few questions about subcontracting for larger firms and how people set their rates when doing this. Several of the responses provided some personal experiences (good and bad) of being a subcontractor on large projects. Where some risks are and how to negotiate your rates, when applicable.

Read the discussion

Change Requests

Nick Coyne started a discussion on how to manage change requests in an Agile development process.

Dealing with large clients

There was also a discussion about how to go about responding to a 150 page RFP for a large client. A few of us offered our experiences of bidding on large projects. Read more

Join the Community

The list is about to pass 400 members and it’s already proving to be a valuable resource for all of you entrepreneurs out there. I encourage you all to introduce yourself.

• For more info: http://groups.google.com/group/rails-business

Several months ago, a few of your colleagues decided to join forces with you as you had come up with a concept for an innovative web application, shared the ideas with your friends and relatives, and began developing a business plan. After a few months of performing some initial market research, working on your pitch, and raising some initial funding, you decided to bootstrap the project and start designing and developing the product.

During your research phase, you came across several articles about this exciting new technology called, Ruby on Rails. You were impressed with many of the sites that were being developed on this new framework as well as the community that surrounded it. Your team decided that it would be a great idea to follow this trend and use Rails as the platform for your new product.

At this point, you began soliciting freelance developers and/or firms to hire for the design and implementation of your project. Eventually, you make a decision and break ground on building the product.

Let’s jump forward to the present day.

You’ve been in heavy development for quite some time. Your product has gone through a series of design changes and you’ve recently begun to allow other people to begin testing the application. You’re receiving a lot of bug reports as people use the system. Your development team quickly fixes them as they appear, but you’re noticing a trend in the development process.

The speed of implementing new features is drastically slowing down as your development team is spending most of their time fixing bugs. Along with that, they are becoming frustrated by the project because they can’t keep up with your new feature requests while trying to keep up with your growing number of bug reports. You’re becoming concerned about the stability of the product and are slightly suspicious that your developer(s) might not be as good as they suggested they were.

Did you hire a bad development team? Chances are, you may not be able to tell. You’re not a developer, so reviewing their code would almost be a waste of time. How would you know if they were doing a good or bad job? Your developers reassure you that things are going to work out in the end, but it’s going to take longer then originally planned. Along with this, your partners and investors are anxiously waiting for you to launch the product, but something feels wrong. You’re worried that launching it too soon could be the quick death of the entire project if it all comes to a screeching halt due to unforeseen bugs and problems with the application. This wasn’t how you pictured the launch of your exciting new product and you feel a lack of confidence in the entire process.

What can you do?

Before I get into that, let’s discuss some of the possible causes for this situation.

• Your development team may have grossly underestimated this project.
• You might have pushed too many features into the initial release of

the product and your development team might not have done a good job
of helping you [determine what you need, not just what you
want](http://www.robbyonrails.com/articles/2006/08/22/information-anxiety-and-solutions).
```text
-   Your development team might not emphasize testing enough in their
```text
process.
```text
-   Your development team may have begun to take a lot of short cuts in
```text
an effort to hit your launch date(s)
```text
-   Perhaps you asked for quick turnarounds on new features before an
```text
investor meeting... maybe this happened on several occasions.
```ruby
-   Your development team might not be very good with Ruby on Rails,
```text
maybe this was their first Rails project.

• …and so on.

At this point, the big question is… what’s the problem?

Can you answer this question yourself? Can your development team answer it? If not, what do you do? How can you get an accurate understanding of how stable the code base of your application is?

Answer: An independent code audit and review

Why is this a good idea? Well, when you have an independent team review your code, you get the benefit of having a fresh perspective.. and often times, an independent team can be much more critical and provide an honest assessment in a very short period of time. This is especially true if they have a lot of experience with the technology. For example, PLANET ARGON has been conducting code audits on existing projects for over two years. We’ve designed a process for checking existing code bases for mistakes that we’ve either made ourselves in the past or found in other projects that we’ve reviewed.

In fact, our process currently walks us through the following areas of your Rails application.

• Security of the application
• Privacy of users’ personal data
• Adherence to the conventions of the Ruby on Rails framework
• Scalability of the application
• Performance of the application and data model
• Testing framework and process
• User interaction (when applicable)
• Information Architecture
• Model-View-Controller (MVC) implementation and organization

Not only does this process provide you with our analysis, but we also provide you with our advice as to where your development team should focus their attention next. If your team is lacking experience in the areas that we recommend they focus on, we’re also here to help them through this with our consulting services. We’re currently assisting several Rails development teams with their testing process, refactoring, user interaction design, optimizing their site, improving their deployment strategy, and plan the implementation of new features.

In general, most freelancers and firms could/should provide you this service, but it should not be performed by your existing development team. They have a bias towards their process and this is your chance to get a second (or third) opinion on the work that you’ve been paying them for. If you’re spending several tens/hundreds of thousands of dollars into this product, an independent review of your investment should be something to seriously consider.

There are several different scenarios that could lead you to deciding to have an independent firm perform a code audit. In fact, I’d encourage you to always get an outside perspective of your team’s work.

You can learn more about our Ruby on Rails Code Audit service on our website or by giving us a call at +1 877 55 ARGON.

This past week (give or take a few days), the Rails Business group has covered a lot of topics, that might be of interest to you, should you be running a business and using Ruby on Rails. Many of the members of the new group are independent contractors and have been very open in sharing their experiences of working for themselves. I’d like to take a moment to highlight a few conversations and tips that were covered this past week.

Health Coverage

Mike Pence started a conversation about health coverage…

“Has anyone else found the medical insurance issue to be a show stopper for them? Are you one doctor visit and diagnosis away from financial ruin? I can tell you firsthand that wishful thinking won’t pay those bills…”

This started a discussion about how people are able to work on their own and maintain health coverage, which is definitely not something that should be considered lightly. Read more…

Client Expenses

Another great question was raised by Mike Breen.

“I’m going to start work on my first project that will require me to travel. How should I handle the expenses? Do I build the costs into the contract price or do I submit the expenses to the client for reimbursements? Or does this vary from client to client based on the company policy?”

The responses included links to IRS sites and sections of other peoples’ contracts. Read more.

Hosting Client Repositories

Where do you host your client’s source code repositories? Are you managing it all yourself on your own servers or using a service?

The discussion (so far) has lead us to evaluate our own solution for this at PLANET ARGON. It appears that everyone has different concerns about how they want to manage client code during the development cycle.

For example, do you allow your client access to trunk/ if they aren’t all paid up yet?

Also, it seems like there are a bunch of new commercial options coming out (and are built on Rails). Read more.

Naming Your Business

Jared Haworth writes,

“For those of you who are working as ‘independent developers,’ have you found that it makes more sense to simply do business under your own name, for example “Jared Haworth L.L.C.,” or to come up with a clever business name instead, such as “Code Fusion Studios”?”

This was a good conversation to follow and definitely raised a lot of great questions and things to consider in response to the original message. Read more.

Other Topics

• Magazines, what business magazines do you read?
• Where do you find gigs?

Join the Community!

The community is still only a few weeks old and we’re already approach 350 members! It’s been a great learning about other peoples’ experiences… as well as sharing what I’ve learned since I started PLANET ARGON (and how the name came to be).

If you hadn’t had a chance to join, stop by and introduce yourself!

So, I was trying to send AT&T wireless a support email through their online system and got stuck at the following screen.

{width=”500” height=”271”}

Come on guys… you can design a better form than this… and I’m now going to have to try and sneak in a question under a sub-topic that doesn’t apply to my question… just so I can send you an email?

Getting help shouldn’t be so hard[^1^](#fn1){#fnref1 .footnote-ref role=”doc-noteref”}.

1. ::: {#fn1}

At least I can **Print this page** and show all my
friends...[↩︎](#fnref1){.footnote-back role="doc-backlink"}
:::