Week 4, Thursday

April 16, 2009 at 7:15 pm (Ruby, System Administration, Week 4) (, , , , )

Eric and I spent a good bit of time today trying to upgrade our app to Rails 2.3.2 (it’s currently 2.0.2), and we ran into several issues. One was that since we had Rails vendor’ed, our commit that upgraded the version caused our Subversion server some heartache on the commit side (but, strangely enough, not on the update side). Another was an error with the mysql gem that we solved on my machine and on another machine, but not on Eric’s machine, where we’ve been doing most of our work. Looong story short, we’ve reverted back to Rails 2.0.2 (which was a bit of a trial by itself), and next time we’ll most likely use Git and start right out using 2.3 (or higher!). <sarcasm>You have got to love debugging.</sarcasm>

I took a story, mostly alone, this afternoon and got it into a pretty good state, and meanwhile Eric worked on setting up a continuous integration server. I set up the exception_notification plugin and configured it for our project, which was pretty simple since I’d done it before. I just had to spend a bit of time figuring out how to get it under test (not the plugin itself, since that’s well-tested already: my implementation of it). I ended up getting some unit tests on the controller that I think are sufficient, but I don’t know how to get Cucumber cooperating yet for integration tests, so those are missing for now.

In case anyone else is struggling with how to write specs that test emails being sent when someone hits a bad url (like “/asgiuaguw”) in your application, here’s what I did (in a before block):


ActionMailer::Base.delivery_method = :test
ActionMailer::Base.perform_deliveries = true
ActionMailer::Base.deliveries = []
controller.use_rails_error_handling!

The first three lines just set up a fake mailing environment that you can query later with things like:

ActionMailer::Base.deliveries[0].to.should include("colin@8thlight.com")

Where ActionMailer::Base.deliveries[0] is a TMail::Mail object with all the information I can imagine you’d need to know about an email you’re sending.

The last line (controller.use_rails_error_handling!) ensures that RSpec isn’t going to rescue the exception for you (usually if there’s an exception during a test, the test fails with an error), and instead allows Rails to handle exceptions as it would during normal processing (with a rescue_action_in_public, for instance, as exception_notification uses). That way we can test that the behavior we want actually happens!

Advertisements

Permalink Leave a Comment

Week 2, Friday

April 3, 2009 at 8:09 pm (Java, System Administration, Week 2) (, , , , , , )

Time is flying a lot faster now. Today I looked at some new technologies (new to me, anyway): Ant and the KML API for Google Maps.

For Rubyists out there, Ant is analogous to Rake, but in the Java world (and Make for C/C++/others). It’s kind of an automated build tool, so that you can avoid duplicating labor each time you want to build a project and run the test suite (or any number of other things). Micah wanted me to build an Ant task that would run all of my tests. So I checked out the Ant manual, but it wasn’t much help at all to me until I’d seen and worked my way through a concrete example. It’s pretty nifty – until now, as far as I knew, I’d have to either let IntelliJ run the tests for me or go through each test class manually running the JUnit tests.

I also had to fix my directory structure to make it more idiomatic for a Java project. Previously I just had my src directory with all my *.java files under version control, but it turned out that what I really needed was to go up a directory and have the main project under version control (Git). This presented a problem for me in that if I just moved my .git directory up to the main project directory, it would appear to Git that I’d deleted and re-added a bunch of files, which would mean that every file’s history would begin again, and I’d lose the ability to see small changes from the previous commit to the next one (just for a certain commit, but still, I didn’t like it). Here’s the workflow I used to move Git’s notion of the structure up a directory, in case anybody else runs into the same issue:

  1. mkdir src/src
    because I knew I was going to need to see the current source files in an src directory, but it needed to be relative to the current Git location, src
  2. git mv src/*.java src/src
    here’s where I’m telling Git to rename the files – the key action that allowed me to preserve history on the same file
  3. mv src/src src_new
    moving the actual source files up to a new folder in the root (which is going to be src eventually, but since “src” is taken for now…
  4. mv src/.git .
    one of the many cool things about Git is that ALL of the versioning information is contained in a single directory – no .svn directories littering the project and making change like this difficult
  5. mv src src_old
    making way for the new src directory
  6. mv src_new src
    in place the way we need it
  7. git status
    checking to make sure things look good, with files being renamed instead of added and deleted)

Pretty simple, considering my initial worries. Thanks, Git!

My time with KML so far has been pretty educational, but I haven’t actually gotten anything done yet, I’ve just been investigating options. I’m working on a problem where I have points on a map with identical latitudes and longitudes, and I need to tell Google Maps to display them as separate points somehow. I’ve found a way to make Google Earth do it fine, but Google Maps is a different story.

Another task I’ve got before I get going on 3-D Tic-Tac-Toe is to split my 2-D version into packages. So I’m going to bone up on the package principles this weekend. I have a tentative separation already (there was some Git love that needed to happen there, too, when I moved files around), but I know have some Common Closure Principle violations I need to take care of before daring to show it to Micah.

Permalink 1 Comment

Week 2, Wednesday

April 1, 2009 at 10:10 pm (System Administration, Week 2) (, , , , )

Last things first: I had some delicious Chicago-style pizza this evening, my first since moving to Illinois. I won’t name names, but it was at a well-known place, highly recommended by some friends back in Georgia. I got some hot tips at work this afternoon about some other places that are supposed to be better, so I’ll be excited to try those once my wife and I finish all of our leftovers!

OK, on to the fun stuff. Eric and I worked on some more stories for the project we’re on. I actually had a decent amount to contribute today, because we did a lot of deployment-related stuff: SSL, payment gateways, Apache/Passenger configuration, and generally setting up a new Ubuntu slice to run Rails. My last job involved a lot of this kind of thing, so I was relatively comfortable, especially compared to yesterday’s mostly RSpec/Cucumber work. I had forgotten a lot of things, though, especially regarding Apache setup. We were both talking today about how we needed to go home and experiment with different Apache config commands to get more familiar. The big stumpers were VirtualHost, NameVirtualHost, and a lot of the mod_rewrite syntax (RewriteCond, RewriteRule, etc.) – nothing a few hours of thought and Q&A with Google couldn’t solve for us today, though.

It was nice having more to contribute, but at the same time it was frustrating when I couldn’t remember the syntax for things I know I’ve done before. It sure is a lot easier to copy a file from another project and replace a few lines than it is to recreate it one from scratch – but I’ve been interested in system administration stuff for awhile, so it’s good for me to know and practice.

My wife’s mother is in real estate – meaning she fixes up and sells or rents houses. For awhile starting out, there were certain things she didn’t know how to do, like laying bricks for a fireplace. So she hired some guys to come out and do the job, but she stood there with them and watched them do the job, asking questions and absorbing the information until she knew how to do it. When she needed a brick fence later on, she layed the bricks herself (and saved a lot of money, of course). This strikes me as a great model for software developers who work alone or on small teams with skill holes. Just hire somebody to come in and do the job, but learn from them. Chances are you won’t be as good as them at it when they leave, but you’ll be a heck of a lot better than you were before.

I know some companies can afford to have distinctions between/among system admins, database admins, and developers, but I think with software craftsmanship, and smaller teams in general, it’s important for the tech people to be able to get everything done, top to bottom. And for me personally, I love the idea of having the necessary knowledge and skill to produce a great product alone or with a pair.

I can see why people say that demonstrating a task or skill for someone is a great way to learn it, because I’m motivated to get more solid with my sysadmin knowledge, even though I felt like it was almost good enough today. It’s just a matter of prioritizing at this point. My stack of books to read is getting taller and taller, but I can only learn so much at once!

Permalink Leave a Comment