jpreardon.com

When armed guards need to be stationed at the Human Resources office, it may be an indication that something has gone terribly wrong with your project. This is precisely what happened at Arizona State University after they rolled out a new Oracle application to manage their payroll (requires wsj.com subscription, sorry). According to the article, this was the result of ASU’s new approach to managing technology projects. Part of this new approach includes admitting that there will be problems up front, then working through them with some help from the people using the problem software. In other words, release early and often.

In many cases, that isn’t a bad approach, but a line needs to be drawn somewhere. When people don’t get paid, they get upset–rightfully so. In the end, one could label this project a success since they are now cutting paychecks at a lower error rate than they had with the old system. But, over the course of several botched pay cycles, enough animosity has been created towards the IT department that it will be difficult to overcome. Asking one of those who had difficulty paying their bills how successful the project was is unlikely to produce a positive response. This won’t make rolling out the next project any easier.

So, if armed guards may be a necessity, think twice before applying the beta tag to a project that should really be more rigorously tested.

This Nested resource CRUD tutorial does a great job of quickly explaining how to get a nested resource working in a RESTful Rails application. If you want some more detail, this RESTful Rails Development PDF covers more while still remaining succinct. It is worth a read, even for non-rails developers, since it explains more about how REST works. Especially helpful is the explanation of how the HTTP verbs are used to call different actions in the controller.

Learn from my mistake and don’t forget to modify the nested controller’s create action. This is noted in the PDF but not the post. Left unmodified, the create action will insert the nested records (in this case, “comments”) with NULL foreign keys in the database.

There are a couple ways to fix this. I’ll keep with the posts/comments example in the code snippets below. The method used in the PDF simply adds one line of code to explicitly set the parent id as shown in bold below:

def create
	@comment = Comment.new(params[:comment])
	@comment.post_id = @post.id
	. . . .
end

The other way, which I prefer, is to replace the call to the comment’s new method with a call to the build method as shown in the following code:

def create
	@comment = @post.comments.build(params[:comment])
	. . . .
end

This accomplishes the same thing in one line rather than two, therefore, I like it. Thanks to Ryan for pointing this out on railsforum.

This Ruby on Rails security guide pulls together several excellent sources on securing Rails applications. It is broken down by category (authentication, model, controller etc.) so it makes for a great reference.

via Ruby Inside

Those wishing to remember their nights spent at Siberia Bar will soon get their chance. A documentary about the shuttered Hell’s Kitchen hang is currently in post-production. If a film just isn’t enough to sooth your Siberia withdrawals, help might be on the way. The Radar article also mentions that Tracy Westmoreland, former Siberia owner, is looking to open a new spot downtown.

via City Room

Those traveling on the back roads between New York City and Montreal generally fall into two groups: bicyclists and motorcyclists. I’m a fan of both two-wheel forms of transport but a motorcycle was the vehicle of choice for this trip. If you have a few days to spare and a motorcycle at hand, this is a great way to see some of the rural areas of New York and Quebec while passing through some gorgeous mountain ranges and tiny hamlets. What follows is a brief account of a trip I took a couple weeks ago with my friend Jeff. If you are interested in the details, keep reading. If you are really interested in the details of the routes, you will find Google Maps of each day’s travels at the end of this post.

(more…)

Writing code without using version control is the equivalent of swinging on a trapeze without a net. Sure, if you execute each move flawlessly, you’ll be fine. But, one wrong move and you’ll fall to your death. Okay, coding mistakes rarely lead to injury or death–of the programmer anyway–but I think you see my point.

There are loads of version control systems out there. Subversion, however, is the weapon of choice for most people working with Ruby on Rails. If you are unfamiliar with Subversion, the Subversion book is a good place to start (print version available on Amazon). The first part of this book gives a good overview of what version control is all about, so those totally unfamiliar with the concept can jump right in.

As for Ruby on Rails applications, they can just be checked into version control like anything else. But, there some files and directories that don’t really need to be under version control. There is an easy, step-by-step guide on using Subversion with Rails at the Rails wiki. Following these instructions takes less than five minutes and will keep your repository free of extraneous files (e.g. log and temp files).

With your Rails application under version control, you can rest easy knowing that you have some recourse when your latest code update breaks everything. Just don’t forget to commit your changes on a regular basis or this is all for naught. Also, remember that the Rails generator scripts accept an --svn option which will automatically add generated files to your repository. This will save you the step of adding these files manually later on.

In addition to giving you a sort of coder’s safety net, using Subversion gives you the ability to automate application deployment with Capistrano if you wish. So, now you have two excellent reasons to get your application into Subversion. By the way, if you are looking for a place to store your repository, check out CVSDude. They offer several monthly plans, including a free one.

Dealing with a group of people’s time off can be a headache. Spread that group across several locations and that headache quickly turns into a migraine. There are hundreds of applications to help with this which range from the very rudimentary to the overly sophisticated. WhosOff, a free web application, looks to have hit the sweet spot here. It is easy to use, but also includes more advanced features like time off approvals. Since it is web based, it is simple to deploy and has the added benefit of allowing the whole team to see who’s out of the office at any given time. Sharing this information with the team becomes more important as the team grows and is difficult to do if the information lives only on the manager’s computer–or, even worse, in their head. WhosOff will get this information in front of the team where it belongs without burdening the team members or mangers with unneeded overhead.

via lifehacker