This Friday, November 19th, Centro is sponsoring the ITA Fall 2010 Challenge. This is the first year the Illinois Technology Association is putting on the contest and I think it’s a great idea. The ITA’s goal is to show local college students that there are plenty of tech jobs in the area, they don’t have to move to the coasts just to nerd it up professionally. Centro is a key sponsor, and as always, we’re looking to make a splash. We’ve decided to pass out some slightly unusual conference swag.

The TI LaunchPad is an extremely affordable entry into hardware development at only $4.30 a piece. The LaunchPad is very similar to the Arduino I’ve blogged about before. Unlike most Arduinos the MSP430 dev board doesn’t come completely assembled leaving the customer to solder on the pin headers. It’s a great way to save cost and make the units more customizable, but it’s definitely a barrier to entry for those new to hardware. Since we don’t know the students are that are getting these boards we decided we needed to do some assembly and, because electronics bought in bulk are so cheap we threw in some LEDs, resistors, wires and a breadboard.

What kind of fun would it be to just hand these students a box of parts and a random microcontroller development board? Sure they could find a diagram explaining how to wire up an LED with a breadboard, but then what? They could jump into some of the cool projects people have been sharing like this LED POV message writer, but in the spirit of the ITA Fall Challenge we wanted to give these kids both a starting point and a bit of an incentive. We’ve preprogrammed every board with our own little contest and have great prizes for the winners.

I can’t divulge much about our contest yet, we haven’t even passed out the boards. But as the contest progresses expect updates here, and eventually I’ll release all the code after the prizes are awarded. This is all for fun, and will hopefully be a nice, simple hardware introduction for people who might not have had the opportunity.

Seeing as this all came about in an effort to help us recruit more developers it would be foolish of me to not include a link to the Centro Job Board. If you have any questions or find yourself interested in one of the positions listed please email me: andrew [dot] bloom [at] centro [dot] net. I also owe a huge thank you to my teammates who helped me solder and pack all 100 of these boxes, especially Amy for picking up the beer!

My first month or so was spent hooking it up to LED’s and the Ethernet Shield. I wasted a bunch of time on a poorly thought out messaging system. I had LED’s hooked up to PWM outputs and was controlling their brightness independently from my computer. It was a great learning experience and the perfect way to remind me how to write C. Luckily for us all, that code has been scrapped (it can probably be found at the first revision on Github).

This week I got a package from Canada. “What comes from Canada?” you might ask. Not much, but there is a place that loves to ship NOS Russian Nixie tubes. Ogi Lumen has been a pleasure to deal with, and provides a top quality kit. Assembling the Nixie Driver kit took about an hour, and getting it up and running was smooth as can be. Ogi Lumen provides a concise and well written library with only a handful of functions for the developer to learn.

Tomorrow I’m giving a lightning talk at work about all this. I’ve spent the better part of the evening putting together some code to help with a demo. I’ve cleaned up the messaging protocol a bit (it still needs major refactoring, but I’ve opted to keep it simple). Now I have a few different kinds of messages, as well as minor error handling. I’ve set up a simple way to clear the Nixie tubes, a command to left justify some digits (and continuously shift them to the right) as well as right justify the display (with no shifting). But my ace in the hole is a demo command I’ve put together that will do some cool cycling of content across the tubes.

Ok, so it’s still not all that exciting, eventually I’ll buy more than two tubes. First though, I have plans to conquer this beast: Neon Bar Graph. I’ve placed an order from Digi-Key for a few discrete components to get myself started, eventually building a shift register/DAC driver similar to the Ogi Lumen Nixie Tube Driver kits (probably without the cool boards though).

Oh, you want a description? The description I wrote in the ticket wasn’t enough? Fine, I’ll expand a bit here. First, let me state that this issue was only uncovered due to our semi-unorthodox deployment strategy. I say semi-unorthodox because I’ve never read of anyone else using a similar style, but I don’t see an alternative.

Here at work we build apps for two sets of users: the public and our business team. These sets of users see totally different applications; in fact, they aren’t even running on the same boxes. Think of our internal tool as a CMS and Customer Service tool. Instead of writing two applications and making them share models, we have one larger application but can control how it reacts by changing the RAILS_ENV. Our basic configuration contains three environments: development, production and admin (this is a simplification: we also have multiple test environments, but they are unimportant for the sake of this discussion).

To limit what can take place on each environment we have segregated our routes.rb like you see below.

# back end services
if %w(admin development test).include?(RAILS_ENV)
    path_prefix = (RAILS_ENV == "development") ? "admin" : "")
    map.namespace(:admin, :path_prefix => path_prefix) do |admin|
      admin.connect "/applicants/:id", :controller => "applicants", :action => "show"
    end
end

# front end site
if %w(production development test).include?(RAILS_ENV)
    map.root :controller => "applicants", :action => "new"
end

Let’s go over this routing real quick. You’ll immediately notice two blocks, the first being for “back end services” (i.e.: internal business users), and the second for the “front end site” (i.e.: the public). If you look closely you’ll see the only difference between the conditionals for each block is that the first includes the “admin” environment while the second uses the “production” environment.

The issue I ran into stems from line #3. When path_prefix is blank, RouteBuilder generates improper URLs, therefore affecting everything inside the admin namespace.

• When path_prefix is set, the admin URLs look like: /admin/applicants/1
• When path_prefix is blank they look like: //applicants/1

That extra slash is a bit of a problem with the way we deploy our “admin” environment. We use some Apache fu to map http://admin/project to the root of the application, meaning our internal users need to go to http://admin/project//applicants/1. This URL is clearly incorrect and should never be generated.

Without the path_prefix we are severely limited in our ability to run the full project in development mode. With the path_prefix set in “development” mode we can view the public portion of the site at http://localhost:3000/applicants/1 and the private part at http://localhost:3000/admin/applicants/1. It should be noted that these two routes go to two completely different controllers, one being in the global namespace, and the other existing inside an Admin module.

Now I know if you payed attention you’re probably thinking: “Andrew, you can get around this with a simple refactor, maybe try this…”

path_prefix = (RAILS_ENV == "development") ? "admin" : nil)

Yes, you’re right, that would work: having the path_prefix set to nil is a simple solution. But, a bug is a bug, and adding an extra slash to a URL isn’t an appropriate thing to do. So please, if you made it this far and you don’t think I’m a raving loon then +1 my patch.

Luckily, Rails is nice enough to have a simple mechanism to do this. Open your environment.rb file and look for the lines that read:

  # Add additional load paths for your own custom dirs
  # config.load_paths += %W( #{RAILS_ROOT}/extras )

Simply un-comment the second line and replace it with something like this:

  # Add additional load paths for your own custom dirs
  config.load_paths += %W( #{RAILS_ROOT}/app/clients #{RAILS_ROOT}/app/observers #{RAILS_ROOT}/app/presenters #{RAILS_ROOT}/app/mailers )

Very similar to moving the Ruby files around, I have also taken to moving some of the views around, specifically, mailer views. I like to keep them near the mailer model, and not in the RAILS_ROOT/app/views path.

This change is also quite easy thanks to the extensibility of the Rails framework. Near the end of your environment.rb file add the following line:

  config.action_mailer.template_root = "#{RAILS_ROOT}/app/mailers"

class SupportControllerTest < ActionController::TestCase
  def test_applicant_activated_view
      Applicant.any_instance.expects(:activated?).returns(:true)

      post :create, :applicant => {:last_name => "Leapfrog", :email => "sos_platform@leapfrogqa.com"}
      assert_select "ul.activated"
  end
end

The first line in the above method mocks out the activated? method on any instance of the Applicant class. Isn’t that simple and clean? Without seeing the rest of the business logic I know it might be hard to accept why I need an entire library to help me with this simple boolean method, but trust me, activated? method is actually delegated to another model which is using an ActiveResource object to truly determine the result.

The Scroller object creates a simple news ticker that nicely rotates messages, stops when you mouse over, and continues when you mouse out. Yep, thats it. Check out my github project. View the comments in scroller.js for directions on how to use it.

Why the almost empty github project? The theory is I might one day write more Javascript and need a place to put it. So for now, only one file in that “project” but just you wait.

Check out the github repo. Let me know what you think, fork it, fix it and make it better.

note: I have only tested this (very briefly) with Capistrano 1.4.1. It might not work with 2.0. I will try to test it with 2.0 later