Twin Cities Code Camp 19 – Recap

Hey all,

This past weekend I made the 5 hour drive up to Minneapolis, MN for the 19th edition of Twin Cities Code camp.  I had the opportunity to speak there with a long time friend.  We demonstrated how to build an app using the Phoenix web framework and then adding Angular on top of it. We did a screencast style recording of the presentation which is linked below.

I also went to a couple sessions while I was there, one on developing apps for the Apple TV and another on managing technical debt.

The Apple TV session was interesting as it was the first time I had heard about TVMLKit from Apple.  The TL;DR is you can now write Apple TV apps using remotely hosted JavaScript.

The session on managing technical debt was interesting in that I heard a large amount of horror stories that made me really appreciate working at Getty along with specifically all the things we have done in the Madison office to continue to work on paying our technical debt off.

Then I got to enjoy this tasty beverage at the speaker dinner: https://instagram.com/p/9PWAgokOem69BkMZRvI-RhY_FSzZznosMaF6A0/

Cheers,
-CJ

Find and replace in directory with grep and sed

Recently I needed to find an replace a method name in a project as part of a re-organization. So rather than just using an editor to do it for me I figured I would spend some time with a small science project on the command line.

What I was able to come up with is a combination of using grep to find all the files that had the method name in them and pipe that list to set to do the global substitution.

grep -lr -e 'bad_method_name' * | xargs -n1 sed -i '' 's/bad_method_name/new_method_name/g'

As you we see in the code above we have our command starting with grep, looking for ‘bad_method_name’ in * and are piping that to sed.  With sed the only issue I had was with the -i flag.  At first I didn’t specify anything for that flag and had errors in OS X about a malformed sed command.  Passing a blank string to it fixed that.

An open letter to Frontier Communications

Dear Frontier,

I am writing this open letter as a way to communicate my recent experiences with Frontier Communications.

On the 9th of September, my wife received a call from a regional manager that our service could be upgraded. She told the manager that I was not home and would call back later to find out more.

I called on the 10th of September and talked to a CSR that made my dreams come true, I was able upgrade from 3 megs down to 7 megs down. I was excited after being a Frontier/Verizon customer for almost 5 years I was finally going to get a speed increase!

I was told that I could see my new speed with in 1-2 business days and would receive a new DSL modem in the mail around there also. On the 12th of September, I wasn’t seeing any speed increase so I called tech support. They told me that everything looked good and I was provisioned for 7 meg service, but I should wait for the new modem to get there and install that to see if that would help.

The new modem came on the 13th of September, I installed it and only hooked up one computer. I ran a speed test and again was only seeing a little over 3 megs down. I work in IT (consultant, and software developer) so I understand that I will not get the full 7 megs down, but expected to get a consistent 6. So on the 20th I cleared some time and again called the tech support group and was assured that I was provisioned for 7 megs and there must be an issue on Frontier’s end. He told me that he had filed a ticket and the issue should be resolved by the evening of the 23rd.

On the 23rd a field support tech came to my house and spoke with my wife, everything was good on their end and told us that we were not eligible for 7 meg service. He instructed her to have me call back to customer support.

Shortly after the tech left, I called customer support and was then told that there really isn’t anything I can do, my old plan is no longer valid (it was a grandfathered Verizon plan) and I was stuck. They then told me they did take the 2 year agreement off of my account but that there is nothing else I can do.

So now I’m stuck paying $5 a month more for no more speed. I work from home from time to time and also am part of an On Call rotation. My work cell phone works over VOIP and I regularly lose either the phone call or my VPN connection when I am troubleshooting an issue in the middle of the night.

I was given the option of adding a second phone line and dsl line for $23 plus taxes and 911 fees which based on my current bill total about $16. The down side of this is I would need to purchase a WAN balancer or managed switch in order to allow my devices to talk to each other and use both internet connections. I was hoping that you could provide a WAN load balance solution but it sounds like I am on my own.

From here I do not know where to go. The only consolation I was given today was a one time $15 credit which will cover my increased bill cost for 3 months while I try to figure out what to do.

I had looked forward to the day when I could publicly thank Frontier for upgrading the service in my area, however after 5 years of the same speed I’m sure it will be much longer before I can do that.

Sincerely,
– One disappointed customer

Rails 3, SOAP and Testing, Oh My!

This past week at work I have had the “pleasure” of building out a SOAP endpoint for an internal system. This has caused me to find a wonderful new gem Wash Out (https://github.com/inossidabile/wash_out). With a feature comes with new test and with my first SOAP endpoint comes, how to test SOAP endpoints.

Testing a Wash Out controller wasn’t something that was blaintiantly obvious to me and took some experimenting and discussions with Boris Staal (@_inossidabile). Below is an example of how we settled on testing. This may not be the end all perfect solution but hopefully it will help you get started.

Let’s start with a sample controller, this will give us a base to refer to with our tests.

class API::GasPrices < ApplicationController
  include WashOut::SOAP
  soap_action "GetGasPrices", 
              :args   => {:postal_code => :integer}, 
              :return => :string
  def GetGasPrices
    render :soap => GasPrices.find_all_by_postal_code(params[:postal_code]).to_xml.to_s
  end
end

This controller is a fairly standard example, it has one method GetGasPrices and takes a postal_code as an argument. It returns a string of gas prices.

One of the things that we got caught on was how to actually hit the Wash Out gem and execute the HTTP request. To do that we’ll need to mount our app as a rack app.

We’ll need to make sure that we are using a version of the HTTPI gem that can use a Rack adapter. Right now we need to point our HTTPI gem at the GitHub repo. For the actual testing of making SOAP calls we can use Savon.

gem 'httpi', :git => 'https://github.com/savonrb/httpi.git'
gem 'savon'

Next we’ll need to create a spec file for our tests. For this example let’s use a request spec, even though this is a controller we actually want to make a request with SOAP to make sure our methods are recieving information correctly.

|~spec/
| |+requests/
| | |+API/
| | | |-gas_prices_controller_spec.rb

Let’s setup our spec file now, we’ll need to require Savon and the spec_helper.
Then create a describe block like below.

require 'spec_helper'
require 'savon'

describe API::GasPrices do
  HTTPI.adapter = :rack
  HTTPI::Adapter::Rack.mount 'application', MyGasPriceChecker::Application

  it 'can get gas prices for a postal code' do
    application_base = "http://application"
    client = Savon::Client.new({:wsdl => application_base + api_gas_prices_path })
      result = client.call(:get_gas_prices, :message =&gt; { :postal_code => 54703 })
    result.body[:get_gas_prices_response][:value].should_not be_nil
  end

Inside of our describe block we are using the HTTPI rack adapter, and then configuring that adapter to mount our MyGasPriceChecker as application. This will give us the ability to use the url http://application. In our test we’ll create a new Savon client, this client will need to access our WSDL so it can find the operations it has access too.

Once we have a client created our code can now actually call the GetGasPrices SOAP method. Our test then verifies that the value of our response is not nil, this is really just a starting point and we can iterate going forward to test actual return values.

Using Virtualbox for development VMs

If you’re like me sometimes I just find it easier to use a Virtual Machine for doing development work, especially when it is a complex system with many moving parts.  Recently I started to work on a project that I had inherited from another developer.  The project was partially setup on a remote development server.  I wanted to under stand how the pieces went together and be able to pass it along to other co-workers, so I decided to build a VM.

I have been a heavy VMware Fusion user for many years yet not everyone in my office has the luxury of a license for it.  I decided to give Virtualbox a go for this project.

At first I was really happy with it, I got my machine up and running in no time and was working away until I came to setting up the server and realized for the sake of sane hostfile management I wanted it to have a static ip.  I decided to switch the network adapter over to NAT which is where the pain began.

I enjoy just shelling into my machines and working that way, once I switched to NAT I could not just shell to the ip address of the vm.  This seemed odd to me, VMware creates a virtual network for you which apparently Virtualbox does not.  So I went diving and here is what I found:

You’ll need to enable port forwarding to the vm’s NIC. To start open up the network configuration section of your vm.

The Virtualbox network interface menu

After opening the network tab, click on the “Port Forwarding” button under the “Advanced” section.

Then fill out the sections with the relative information.  I found that if you try and put in a Host IP the setup doesn’t work quite right.  Here I’m forwarding my localhost port 2222 to port 22 on the guest vm along with port 8080 to port 80.

Now from my host machine I can use the following shell command to ssh in $ ssh aip@localhost -p 2222 which will use the port-forwarding and let me access my machine.

The same logic applies to trying to view the site running on the vm, in my browser I just have to access http://localhost:8080.

Now this is a bit of work but it is the trade off for a free tool for virtualizing your environments.  It’s working for me right now but your mileage may very.

Pairing on a Severity 1 issue

Recently at work I had to help respond to a Severity 1 issue.  This is our worst case scenario, something major is broke in production and is costing the company money.  In the presentation I gave at Twin Cities Code Camp about pair programming I said that often troubleshooting bugs and fixing production issues weren’t the easiest to pair on.  Reflecting on the past couple days I noticed that while trying to fix the issue at hand we were pairing the whole time.  I don’t think we could have accomplished the fix without the entire team using some of the techniques I had outlined in my presentation.

We used two of my local pairing techniques along with two remote pairing tools. Locally we used a mixture of traditional paring and “Divide and Conquer” pairing.

Traditional

With traditional pairing one person is “driving” while the other person “navigates”. As I sat in the driver seat with vim open and tailing a log on production my manager sat next to me helping navigate through the code as we figured out what needed to be modified. I used to think that I liked to work on these high stress issues alone and troubleshoot things with my own process, but now have a different opinion.  Having someone there to limit the amount of thrashing was a major help.

Divide and Conquer

With a major issue there are lots of logs to check, experiments to try, and pieces of a system to update.  This is where we brought another developer so we could divide up the work and conquer the problem.  While I updated configs, he updated our applet code.  By the time I was done getting the configs ready he had the applet built and ready to be pushed out.  We were in constant contact sitting next to each other but were able to work in parallel to finish the one task.

Remote Tools

Working with a team distributed around the world makes troubleshooting major issues difficult.  I was able to keep everyone on the same page by using a combination of a screen sharing tool http://join.me and tmux.  I used Join.me to share a remote desktop session from London.  From the remote desktop I was able to use putty to connect to a tmux session on my own machine.  This way I could show code and logs to the entire team.  Using tmux allowed me to reboot the machine and pick up and start running very quickly.

Using pairing techniques and tools helped us diagnose the problem and solve it.

TCCC12 – Pair Programming recap

I recently I had the opportunity to share a passion of mine at Twin Cities Code Camp 12.  I gave a presentation, “Pair Programming Techniques”, where I shared my experiences of pair programing including things I found to great and things that are not so grate. This presentation was one of my favorites as it had a great amount of audience participation. I will attempt to share this information in a series of blog posts.

Pair programming is the act of working on a focused task with someone.  I’ve seen it be a productivity booster, we’ve all had times where we just hit the preverbal wall while working on something.  I always found that explaining my situation to someone else would help me get over this block and get back to work.  Imagine having that person right there working on the task with you. Sure I’ve been in situations where both of us in a pair got stuck but that is a rarity.

While pairing I tend to notice that I am getting a real time review of the code I am writing.  I like being able to discuss code while it is written, giving me a chance to learn and teach all while getting things done.

Pair programming is not the silver bullet, it’s not going to solve all your problems or make your team’s velocity jump a hundred and twenty percent.  It’s not just for twenty something hot shot developers, working at the latest startup.  Even though you have two eyes working on the codebase doesn’t mean bugs are going to get through. Pair programming is like the old saying “measure twice and cut once”, which doesn’t mean you are going to cut every board perfect but it it limits your possibility of a defect.

In todays work place it is common to have people in the office along with remote employees.  Just because someone works remotely doesn’t mean that they can’t pair and have to work alone.  There are advantages and disadvantages to both situations.

Pairing locally has many advantages, most of which have to do with being in a physical environment. When you are working locally you have the ability to better read your pairs body language, you can grab some paper and sketch out some ideas.

Sometimes pairing locally can have some distinct disadvantages too.  There are big things like sickness, working in a very close environment makes it easy to pass things to each other.

Working remotely solves the sickness issue and allows both people to pair and not worry when they have a simple cold.  I have found myself enjoying remote pairing in this situation.  While you don’t have some of the physical amenities that you would in a normal office setting, video chat and screen sharing comes pretty close. I have spent time working remotely at previous jobs and have found that human interaction is something that I need. Pairing remotely gives you someone to talk with, share your ideas and get feedback from.

While pairing remotely is great during the height of flu season, and with video chat and screen sharing you can almost see everything there is still a great deal of communication that needs to take place for the pair to be effective. Bandwidth is a major downfall of remote pairing, I live in a location with a slower DSL connection and I have to prioritize the tools I use when remote pairing.

Look for follow up blog posts about different styles and tools for paring locally and remotely.  I’ll cover some of the techniques I have learned and developed since I started pairing.

Ruby Koans

Recently after doing a Code Retreat with Cory Haines I found myself really wanting to work on my Ruby fu.  I was inspired by the idea of practicing my trade everyday in some simple exercises that  allow me to focus on parts of the language to really learn it well.

So I decided to pick up the Ruby Koans which I was introduced to a year or so ago but never thought I needed that.  I always figured I could just keep learning by using Ruby for my projects, but then I realized that I was just using the same few parts of the language to build my apps.

Following the craftsman analogy, I was using the same saw and hammer because they are comfortable.  I didn’t take the time to learn about the pneumatic framing nailer because I already had a way to pound in nails, but boy does it make building things easier.

So if you are new to Ruby or have been using it for awhile I really recommend you find some exercises to keep your skills sharp and explore new parts of the language. I really think the Ruby Koans are perfect for this, I see them being easy to get started and with enough substance that even seasoned developers will pick up new things.

Web Development Recipes

Today marks a new accomplishment in my career.  I am a published, professional author.  Today we released the beta of Web Development Recipes a book for anyone interested in expanding their knowledge of Web Development.

I worked on this book with several very intelligent and amazing co-authors: Brian Hogan, Chris Warren and Aaron Godin.

So head over to http://pragprog.com/book/wbdev/web-development-recipes and pick up a copy, or two, or three!

Web Development Recipes Cover