isotope|eleven

This is a fantastic article about how to use vim textwidth like a pro.

The takeaway I needed from it was: To reflow a paragraph that you've modified that no longer respects the textwidth boundaries, go inside it and issue the command vipgq

Since I did make this post about using environment variables more often, it occurs to me that I needed a follow-up post.

If you're deploying an application that depends on environment variables, and you use Apache as your web server, then you want to add this to your vhost:

SetEnv QUOTE_APP_XRONO_URL http://xrono.org
SetEnv QUOTE_APP_XRONO_USER api@xrono.org
SetEnv QUOTE_APP_XRONO_TOKEN this_is_a_token

Then your app will get the environment variables it depends upon, and life will be skippy.

So while I was at SpreeConf I met up with Daniel Doubrovkine from art.sy and he showed me around General Assemb.ly which was a really cool space.

While I was meeting with him, I sort of got a demo that gave me the kick in the tail I needed to put together an API with grape. I built the backbone.js wine cellar demo, converted it to coffeescript along the way, and wrote a backend for it in grape. Along the way I ran into a few interesting problems that others might run into when doing something similar, and I figured I'd share the code. Let me know if it's helpful! :)

TL;DR - This is an application for bidding software projects.

We at Isotope11 built a project to use when creating estimates for our customers. It allows us to rapidly develop quotes for our customers, as well as use post-mortems to make future quotes better. We can export the quotes to PDF, which we send to the customers.

Before we built this app, we were developing quotes in Google Docs. It worked alright, but the display always left something to be desired. We would either give ugly quotes to customers, or we would spend insane amounts of time making them look good. This tool allows us to easily generate good-looking estimates, quickly.

Features

• Estimate time required to build a software project with line items supporting min and max estimates.
• Export your quotes to PDF.
• Clone a quote.
• Store common line items in Item Templates, to help you easily add them to future quotes as well as to gradually perfect your min/max estimates on those items over time.
• Sections in a quote can have subsections, and you can add line items to the quote at any nesting level.
• Sections and subsections sum up their childrens' min/max hours.
• Export a quote to xrono, and create the project and all subtickets via the xrono API.

This project is on github.. We welcome forks and pull requests. We would love to hear from you if you have suggestions as well - just use github issues.

I found this article today and thought I'd share. I figured it to be the best description of how I learned RoR. It describes some of the pitfalls a beginner can fall into when first learning.

http://rob.yurkowski.net/post/17610425880/rails-is-definitely-not-for-beginners

Although I must say I disagree with what some of this article says because the great thing about Rails and how far the community has come, is how much easier things are these days with all the gems we have and how extensive most of the documentation is. Just some things to think about.

Now, I'm getting verklempt! Talk amongst yourselves. I'll give you a topic. The Prince of Tides was about neither a prince nor tides.

Today I am going to walk through our recent continuous integration Traffic light notifier project that we just finished at the office. This project stemmed from my company's desire to immediately know if a developer has broken a software project, and what better way to do that than to have a huge red light flashing in your face. We connected an old salvaged traffic light fixture to our Jenkins CI-server that monitors the testing status of all of our current software projects. If all our tests are passing, the light stays green, if any test fails the light turns red to provide a visual notification of a problem. While Jenkins is running a test suite on any project, the yellow light will flash to let us know of the activity.

So how does one connect a 48" tall traffic light to a continuous integration server? With a Ruby script, an Arduino, and a few relays of course.

The Ruby code will create a serial connection with the Arduino to send data, then create a web connection with the CI server to request the build status data via our CI server's built in API. A quick look through the returned data will give us a chance to see if there are any problems – if so, we'll send a signal to the Arduino to change the light status, otherwise it stays green. The Ruby script requires 3 gem dependencies to run: faraday, json, and serialport – all available from rubygems.org (eg. gem install faraday).

# Isotope11 continous integration server Traffic-light
# Ruby script to monitor json output from Jenkins CI-server, and output the status of projects to a Traffic-light. 
# If all builds are passing, the light is green. 
# If a job is currently building, the yellow light flashes. 
# If any job is failing, the red light is turned on and green turned off.
require "serialport"
require "json"
require "faraday"
require "net/http"

# create a new Serial port for the Arduino Uno which uses port /dev/ttyACM0. Older Arduinos should use /dev/ttyUSB0
sp = SerialPort.new("/dev/ttyACM0", 9600)

# wait for connection
sleep(1)

# create a new Faraday connection with the Jenkins server to read the status of each job
conn = Faraday.new('http://your_Jenkins_server_address.com')
puts 'go to loop'

loop do
  begin
    # grab the json from the jenkins api
    response = conn.get('/api/json')
    # parse the response into a list of jobs that are being monitored
    jobs = JSON.parse(response.body)["jobs"]

    # search each job to see if it contains either "anime" (building) or "red" (failing)
    should_blink = jobs.detect{|j| j["color"] =~ /anime/ }
    should_red   = jobs.detect{|j| j["color"] =~ /red/ }
  rescue
    # if no response, assume server is down – turn on Red and Yellow lights solid
    server_down = true
  end

  # check results of job colors
  if should_blink
    # something is building... flash yellow light!
    puts "Something is building... flash yellow light!"
    sp.write("1")
  else
    # nothing is building... turn yellow light Off.
    #sp.write("2")
  end

  if should_red
    # something is red... turn On red light!
    puts "Something is broken... turn On red light!"
    sp.write("3")
  else
    # nothing is red... turn On green light.
    sp.write("4")
  end

  if server_down
    sp.write("5")
  end

  # wait 5 seconds
  sleep(5)
end

# close serial data line
sp.close

The Arduino board is fitted inside of the traffic light housing, and mounts to a perforated prototyping board from Radio Shack using some male-pin headers. Above the Arduino, are two small PC mount relays capable of switching up to 1 amp at 120vac – perfect for some low wattage light bulbs. The relay coils are controlled using a 5v signal, and only consume about 90mA at that voltage level, so we can use the Arduino's onboard 5v regulator to power the relay coils. Unfortunately, we cannot simply drive the relays directly from an Arduino pin because it can only supply around 40mA per pin and the inductive switching properties present in a relay might cause damage to the Arduino. Instead, we can use 2 small N-type signal transistors (either bjt or mosfet) to interface between each relay and the Arduino output pin. Building the relay board might require some hands-on tinkering, but is a rewarding task when complete (circuit schematic file included).

The Arduino code is simple, basically listening on the serial port for 1 of about 5 signals. If the Arduino detects a recognized serial byte, it will carry out a function to control the Traffic lights - there is no extra fluff, just what is needed. If you are having trouble locating an old Traffic light, or would like to build a smaller desktop version of the notifier, you can do so with only an Arduino and a few LEDs (red, yellow, and green) - you don't even have to solder anything!

// Isotope11 CI-server traffic light
// Arduino Uno with 2 relays (SPDT) attached to pins 4 and 7
// isotope11.com 2-9-12

// declare variables and output pins:
int inByte; // create a variable to hold the serial input byte
long lastTx = 0; // create a “long” variable type to hold the millisecond timer value
int yellow_light = 4; // create an output variable attached to pin 4
int red_green_light = 7; // create an output variable attached to pin 7

void setup() {
  Serial.begin(9600);   // start Arduino serial monitor at 9600bps
  pinMode(yellow_light, OUTPUT); // set up pin 4 as an output
  pinMode(red_green_light, OUTPUT); // set up pin 7 as an output
}

void loop() {
  // check serial buffer
  if (Serial.available() > 0){
    inByte = Serial.read();    // read serial byte
    Serial.println(inByte);     // print serial byte
    lastTx = millis(); // set the lastTx time-stamp variable equal to the current system timer value

    // the serial bits “49” - “53” are detected when the numeric buttons “1” – “5” are pressed on the keyboard.
    switch(inByte){
    case 49:  // if serial value received is "49" (number 1), blink yellow light
      digitalWrite(yellow_light, HIGH);
      delay(1000);
      digitalWrite(yellow_light, LOW);
      break;
    case 50:  // if serial value is "50" (number 2), turn yellow light off
      digitalWrite(yellow_light, LOW);
      break;
    case 51:  // if serial value is "51" (number 3), turn red light on (green off)
      digitalWrite(red_green_light, HIGH);
      break;
    case 52:  // if serial value is "52" (number 4), turn green light on (red off)
      digitalWrite(red_green_light, LOW);
      break;
    case 53:  // if serial value is "53" (number 5), turn green and yellow lights on solid (api error)
      digitalWrite(red_green_light, LOW);
      digitalWrite(yellow_light, HIGH);  
    }    
  }
  else {
    if ((millis() - lastTx) > 10000) {
       // it has been more than 10 seconds (10000 milliseconds) since any serial information has been received
       // assume there is a break in the PC connection, and turn red and yellow lights on solid.
      digitalWrite(red_green_light, HIGH);
      digitalWrite(yellow_light, HIGH);
    }
  }
}

Repo

The github repository is here.

Parts list:

1. an old Traffic light
2. Arduino Uno, Radio Shack part # 276-128 - $34.99
3. PC prototyping board, Radio Shack part #276-168 - $3.19
4. (2) PC pin relays, Radio Shack part #275-240 - $4.69 ea
5. (2) NPN transistors or mosfets, Radio Shack part #276-2016 - $1.19 ea
6. (2) 10kohm resistors, Radio Shack part #271-1335 - $1.19 pk
7. (2) 100kohm resistors, Radio Shack part #271-1347 - $1.19 pk
8. (20) male-pin breakaway headers, Sparkfun part#PRT-00116 - $1.50
9. (4) 8mm bolts, 1” long (with nuts) - $1.00

Tools needed:

1. wire/wire snips
2. solder/soldering iron
3. drill/drill bit

Just pushed a small update to bootstrap-will_paginate that fixed this issue.

Big thanks to Michael Hartl for submitting the issue. If you're looking for a great starting Rails tutorial, you can't go wrong with his Ruby on Rails Tutorial.

Git Bisect is awesome

So I was attempting to debug a weird bug that cropped up in a release branch that hadn't existed before all the original feature branches were merged. There were quite a few feature branches and changes so I was scratching my head trying to figure out what broke it.

Enter Scene: Ben Holley (Isotope11 Developer)

"You should try git bisect! I've never done it but I heard it will help you here"

Turns out its awesome. It will step between a known good commit/branch and a known bad commit/branch and allow you to test your code in between and mark them as good or bad. Eventually, and fairly quickly you will narrow down what commit caused your particular problem. Here is how:

$ git bisect start
$ git bisect good some_good_branch
$ git bisect bad master
> Bisecting: 60 revisions left to test after this (roughly 6 steps)

You will now be in a "bisect" branch that is somewhere between the known good point and the known bad point. At this point you run whatever test you need to and verify if your code works at this point or not.

Lets assume it does not

$ git bisect bad
> Bisecting: 29 revisions left to test after this (roughly 5 steps)

Git has stepped us to a different point in the tree to test here. Notice that it says that there are only 29 revisions left to test. It doesn't just step back one by one it figured out what branches definitely can't have caused the problem based on the tree. So you don't have to step through every single commit. In this case git estimates I'll have roughly 5 steps left.

Basically you will continue through the git bisect good or bad routine until eventually git returns this

> db791e5031d72dea6a6cfb761d349c53277c1a4f is the first bad commit

You now know exactly which commit broke your code.

To return to the branch you were in when you started the git bisect type:

$ git bisect reset

Now use git show to figure out what was in that commit that was so horrible and you're done!

$ git show db791e5031d72dea6a6cfb761d349c53277c1a4f

This saved me hours of debugging time, hopefully it will help someone out there too

So we just launched our new site. I figured this was as good a time as any to finally get our ducks in a row vis-a-vis continous deployment. Since this is the sort of thing that a lot of people have to deal with, I figured I'd publish a blog post explaining how we took care of it.

Continuous Integration

isotope|eleven uses Jenkins for our continous integration server. We have it configured to run the relevant tests anytime a commit is pushed to our git repositories, as well as once daily for each job. We keep the Jenkins Wallboard running on our main conference room TV at all times, so we can see at a glance if any builds are failing. These are all fairly standard practices.

Continuous Deployment

Jenkins is pretty flexible, and so when it came time to do continous deployment I decided to use Jenkins to handle it. In Jenkins, it's very easy to make a job that just executes some shell script (in fact, most of our jobs are precisely this sort). This is perfect, because of course we just have a shell script we use to deploy our projects - capistrano!

Setting up the deploy job

To get started, I built a new job in Jenkins. The repository our site lives in is called isotope-rails3, as is the main CI job for our site, so the new job is called isotope-rails3-deploy. I set its git repository URL to our repo. I then added a single build step, an "Execute Shell" step whose command is cap deploy:migrations

Finally, I set it to notify me in the event of a failure.

Setting up deploy without intervention

At this point, I can click the 'Build Now' button to kick off the deploy, but it's going to complain about passwords. I also had to set up the jenkins user on the jenkins server to be able to deploy our site passwordless. If you don't know how to do this, this is a pretty good tutorial on setting up your SSH authorized keys.

So now the button works and it will deploy without intervention, but I want to kick off this job after a successful run of our tests so that it will deploy each time we push new code to the deploy branch. To manage this, I just went into our main CI job for the repo and set it to 'Build other projects' in the Post-build Actions, and I told it to build the 'isotope-rails3-deploy' job only if the build succeeded.

Done! Get your Continous Deploy on.

With those simple steps, you've got a robust Continuous Deployment server that can be modified in a host of useful ways, as it's just a standard Jenkins job. Let me know if you try this and have any problems. Thanks!

If you're writing Rails engines and you aren't namespacing your models, you might as well write in your README one of the two following things:

1. You cannot be comfortable using this engine in your app because there might be collisions, either in model names or database tables.
2. There will be a Great Upheaval in the future and all code written around this engine will require change, because I will eventually namespace it.

Repeat after me: I will always namespace my models in my engines. If you want an example of how to do it, check out isotope_contacts

Oh yeah, and I pushed a new version

Also, now's a good time to mention that I pushed the isotope_contacts gem out as version 0.1.0. If you're not sure what it is, isotope_contacts is a Rails 3 engine for managing contacts. It's also a clean codebase that you could look at if you're unfamiliar with building a Rails engine.