Pathfinder Development
Author Archive: Jason Sendelbach

Automated Deployments Rock

I have been a developer for many moons, and have taken many systems to production. I must say that production deployments were never on my list of things that make me warm and fuzzy. This was due to the fact that they weren't automated, or the automation was poor. On a recent java project, we had a series of simple sh scripts that did the work of deployment. We deployed war files to 12 application servers and to about 60 JBoss nodes. Before the automated scripts, a developer who typed wicked fast did all of the deployments. Without him, deployments would have been a nightmare.

I learned Ruby on Rails last year, and was delighted when I found Capistarno. I wanted to share the things I love and hate about capistrano.
Continue reading »

Review of fixture_replacement2 plugin

We have been using fixture_replacement2 on some of our Ruby on Rails projects. I am writing an internal application and finally switched over from using fixtures. It took a bit of time to get the tests that I had written modified to stop using the fixture data, but now I am completely fixture free. The tests are a lot easier to write, and I created a few helper methods that setup common datasets. This way, I can call a setup method to configure my data, and then - it's all good. At first I called the method test_data_blah, and was wondering why I was getting an error running any test, so now it's called data_blah.  Doh!

At first I didn't like the fact that I needed to explicitly create the data for what I was working on, but then I realized that (especially for unit tests)  you don't need much dependent data; usually it's one or two records. For functional tests, I found that the data setup methods rocked, as I could quickly get the data set up that I needed.I could quickly assert the content of the response, based on the data in my setup. I missed fixtures at first, but now realize that over time, they are a pain.

Continue reading »

Testing various roles in ruby on rails

On pretty much every project I've ever been on, there have always been various roles in the system that experience different behavior. Admins can generally do everything, end users get the least functionality, and there are always a few in between that vary based on requirements. Unfortunately, all too often all possible scenarios aren't tested, or they test only positive cases for each role.

In my current Ruby on Rails project, I am checking all roles and ensuring those who should be able to do certain things are able to, and those that shouldn't are unable to. What I have found, is that usually, the Admin and one other role can usually do a set of things, and every other role can't. So, I find that I set up my tests the following manner:

['root','hr'].each do |role_name|
    context "logged in as #{role_name}" do
      setup do
        login_as_user(role_name)
      end
 
      should 'index' do
         get :index
         assert_response :success
         # other assertions
      end
  end
end

Continue reading »

What makes a good requirement document for an agile project

As a developer, I start from requirements. I have worn project management and business analyst 'hats' on many projects (but I am a geek, as I really enjoy the developer hat the most). My coworker, Alice Toth, has come up with a pretty awesome template and style of writing requirements that seems to be perfect for the agile development methodology. Too often, I see struggling projects struggle, because their requirements suck. I look at their "requirements" and they are nothing more than a picture with a bunch of notes. The developers have so many questions, and in general, all people involved (client, developers, BAs, IAs and testers) don't have a good understanding of the system as a whole, and what are the various personas that use the system.

I have worked on projects that have used Use Cases and Functional Specifications, but these never seem to convey all the necessary information for all involved. They tend to be very verbose, and they are really not fun to write, read or manage. A good requirement should tell each audience member exactly what the expected functionality is, and never generate a myriad of questions from all involved. It's often difficult to solicit information from a client, but documenting for developers should never be that hard. Here is a recap of what a good requirement is:

Continue reading »

Topics: ,

A Java Programmer’s transition to Ruby on Rails

There is much out there on the topic of migrating to Ruby on Rails for an experienced Java programmer. I figured I'd add my two cents, as I have finally drunk the Kool-Aid. I switched to Ruby on Rails late last year, and developed a subscription and content management system in Ruby on Rails, went back to a Java project, and then back to Ruby on Rails. The switch back to Java gave me an interesting insight into the things I love and hate about both development platforms.

Continue reading »

Who is Pathfinder?

Topics

Search

WordPress

Comments about this site: info@pathf.com