Software Development, Paragliding, Rock Climbing, and more.

Prototyping RESTful Services With Sinatra

| Comments

Working on a new project at work recently, we’re developinf a RESTful web service to be accessed by a WPF client. Since we have existing infrastructure to access OpenVista Server using Java (via OVID), the final solution will be a Java one.

However, before one of our primarily Java developers would have a chance to put something together, I needed to make progress on the WPF client.

Sinatra swaggers in to save the day!

Looking at my options, I decided to go with Sinatra to prototype something quickly. I know that Sinatra is far more than a prototyping tool, but it still seemed a perfect fit. Here’s a sample resource for the project:

  • URI: /chief_complaints
  • HTTP Verb: GET
  • Content-Type: application/json

This is a sample of the expected output:

  { "name": "Dizziness" },
  { "name": "Chest Pain" }

Implementing this is trivial with Sinatra:

The code is relatively straight forward. First, we add the necessary modules we’ll use:

require 'json'
require 'sinatra'

Next, we define a variable to hold our chief complaints. In order to achieve the desired JSON format, we use a array of one-entry hashes (I’m using the Ruby 1.9 key-value syntax, this won’t work on older Ruby releases):

chief_complaints = [
  { name: "Dizziness" },
  { name: "Chest Pain" },

Next, we add a simple before filter that specifies the content type for responses. We match all routes with the filter, in order to avoid having to specify the format for every route.

before /.*/ do
  content_type :json

Finally, the definition of our route is a simple one liner:

get '/chief_complaints' do

After running the service, this is the result of sending a request to the resource at http://localhost:4567/chief_complaints:

[{"name":"Dizziness"},{"name":"Chest Pain"}]

Next post I’ll discuss how we’re using RestSharp in the client to access the RESTful service.

Continuous Integration and OpenWrap

| Comments

Today at work I had a need to extract some code that we had been “sharing” between a few projects via manual C&P in the projects. Obviously this wasn’t feasible in the long term. I’d been reading a lot about OpenWrap recently, so I decided to try to bundle the reusable code into a wrap that could be referenced by the consuming projects.

To set the stage, we have the following environment:

  • Hudson is our continuous integration software, running on a Windows server. Hudson is hosted by Tomcat running as a local user named tomcat on port 8080, and we have Apache Web Server doing reverse proxying of http://server/hudson to http://server:8080/hudson.
  • Bazaar is used for DVCS.


My goal is to end up with Foo.Shared as a reusable wrap referenced from FooA and FooB.

Highlevel Steps

Here are the highlevel steps I took:

  • Installed OpenWrap locally.
  • Created a new shared project.
  • Initialized the shared project with OpenWrap.
  • Installed OpenWrap on the continuous integration server.
  • Configured CI so successful CI builds of the shared project publish the wrap to a local repository on the CI server.
  • Configured Apache Web Server to serve up the files from the local repository as an http repository.
  • Added the CI server as an OpenWrap repository on my local machine.
  • Referenced the new shared wrap from consuming projects.

Installing OpenWrap

First, I downloaded o.exe. Upon successful download, I openned a cmd prompt and ran o.exe. When prompted, I typed i to install o.exe into my PATH.

Shared Project

Creating the project

In VS 2010, I created a new project, Foo.Shared, saved it, and then exited. OpenWrap is fairly opinionated about how projects should be structured, which fortunately matches my usual way of organizing things, so I next created a src\ folder at the top level of my project, and moved the Foo.Shared folder into there. This results in the following structure:

  • Foo.Shared
    • Foo.Shared.wrapdesc
    • src
      • Foo.Shared
        • Foo.Shared.csproj
    • wraps
    • version

I then edited Foo.Shared.sln to fix the path to Foo.Shared.csproj accordingly. I confirmed the build still worked as expected by building in a command prompt:

C:\Users\pete.johanson\repo\Foo.Shared> msbuild /t:Clean;Build Foo.Shared.sln

Adding OpenWrap to the project

To initialize the OpenWrap information, I returned to my cmd and prompt and performed the following:

C:\Users\pete.johanson\repo\Foo.Shared> o init-wrap -NoSymlinks true -IgnoreFileName .bzrignore -All true

The -NoSymlinks portion is key to keep version control systems like Bazaar happy (without it, OpenWrap creates a “JUNCTION” in the wraps\ folder that confuses Bazaar). I specified the -IgnoreFileName explicitly because otherwise OpenWrap places the .bzrignore file in the wraps\ folder which Bazaar seems to ignore. This produces the following Foo.Shared.wrapdesc:

name: Foo.Shared
depends: openwrap anchored content
use-symlinks: false

I again confirmed that rebuilding the project worked fine after OpenWrap updated the all the .csproj files. Next, I confirmed the OpenWrap configuration worked as expected:

C:\Users\pete.johanson\repo\Foo.Shared> o build-wrap

After that, I added the usual culprits to .bzrignore to prevent adding things I didn’t want to Bazaar, and committed. I think pushed to our central repository location.

Setting up the build server

Installing OpenWrap on the server

I logged into the Hudson server as the local tomcat user. Again, I downloaded o.exe, ran it in a command prompt, and when prompted typed i to install OpenWrap into the PATH on the server.

Creating the server repository

I then created a directory on the server that will serve as the repository:


From a command prompt, I think configured the local OpenWrap repository:

C:\wraps> o add-remote local file://C:\wraps\

Exposing the server repository over http

In the httpd.conf in C:\Program Files\Apache Software Foundation\Apache2.2\conf\ I added:

Alias "/wraps" "C:/wraps"
<Directory C:/wraps>
    Options FollowSymLinks
    AllowOverride None
    Order allow,deny
    Allow from all

Publishing the shared project on build

In Hudson, the shared project build consists of three build steps. The first uses the MSBuild plugin for hudson, and is of type “Build a Visual Studio project or solution using MSBuild” and uses the Foo.Shared.sln solution file. The remaining two steps are both of type “Execute Windows batch command”. The first simply creates the wrap:

o build-wrap

And the second publishes it:

o publish-wrap local -Name Foo.Shared

Doing a “Build Now” in Hudson causes the shared library to build built, packaged into a new OpenWrap wrap, and then published to the shared repository.

Consuming the new repository

To consume the new repository on the continuous integration server, we add a new repository:

C:\Users\pete.johanson> o add-remote continuous http://server/wraps/

After adding the repository, we can now list the repository:

C:\Users\pete.johanson> o list-wrap -Remote continuous
# OpenWrap v1.0.0.0 ['C:\Users\pete.johanson\Foo.Shared\wraps\_cache\openwrap-\bin-net35\OpenWrap.dll']
 - Foo.Shared (available:

Success! We can now properly add Foo.Shared to any other projects.


| Comments

At work recently, we had code looking a little something like this:

When refactoring the code, I thought about the recent blog post about A Less Ugly Switch Statement and thought I might do something similar with IComparer (and IComparable, but I’ll leave that as an excercise for the reader). The envisioned invocation is:

I ended up with this implementation:

Is this better? I’m not really sure. It is functionally equivalent. Is it more readable, or less?

Whitewater Rafting on the Kern!

| Comments

This weekend, Heather and I went whitewater rafting on the Kern River in the Sequoia National Forest. It was amazing..I manage to look even goofier than usual when wearing a helmet and holding a kayaking paddle:

On Saturday night, we actually did a “Night Run” at around 10PM, by moonlight. Man, it was the cooliest, eeriest thing I’ve done in a long time. Very fun. Sadly, my glasses didn’t quite survive the last run of the day:

It was definitely worth it though. Looking forward to doing it again next year!


| Comments

Google Earth Rendering

Second time launching Crestline. Not the most graceful launch as I was a tad nervous about Crestline winds, combined with wanting to spend the extra 15 seconds to double check the replacement brake line I put in after my last flight. (The sheething of one of my upper cascade brake line had caught on a rock on launch a while back and gotten torn, finally got it replaced). Worked the ridge at Crestline only briefly, then bailed to head out and get over regionals. Made regionals with about 200’ to spare, still not 100% comfortable with Crestline, need to get there so I can actually try to work the ridge there on good days.

After getting to Regionals, worked that a little bit, the air was pretty punchy, with thermals that seemed pretty broken up. Only really properly cored a few of them, the rest of the time was mostly boating around, hitting lift, then sink, then lift, with nothing really coreable. Fun none the less!

The KML File.

Billboard, B*tches!

| Comments

Ignoring my crappy day yesterday (I got some uber-sport sunscreen in my eye at launch, and couldn’t see right for the next 3 hours, so didn’t get to fly), this weekend was great for paragliding. In particular, Saturday was “epic” (quoth Dusty).While sitting on launch waiting for the conditions to get good, I was chatting with Brian, and we got the idea of maybe shooting for hitting Pine (the mountain + ridges just to the west of Marshall) if the day suited it. I was excited at the idea, but wary. I was definitely trying my hardest to make sure I didn’t get too set on the idea, lest that lead me to pushing to hard for it when I shouldn’t. Little did I know what was in store!I launched right at 5PM, steady wind with no complications. Worked the ridge a bit right at Marshall, and then decided to shoot out to Regionals, where folks seemed to be doing well.

Got over regionals a little low, and scraped around until I caught one or two thermals that got me to about 4300. Brian was no where to be seen, but I figured I’d give Pine a shot. I now know that I definitely need more than 4300 if I want to try for Pine straight from Regionals! I got about 2/3 of the way to the lower Pine ridge and tucked tail, turning around and heading back for Regionals before I got stuck and had to hit the backup LZ. I made it back to the lower ridges of Regionals (what are these called? anyone?) with little altitude to spare, and back to hunting I went. Things were looking pretty bleak, until I found a nice wide thermal that I managed to ride back up to 4100, directly above Cloud Peak. Regionals was now happening a little bit more, and several pilots were now getting up to about 4500 at times.

Suddenly, I noticed Dusty’s wing heading over towards where Rob was circling, and I thought to myself, “If I want to follow anyone to look for good thermals, it’s them!” so off I went. Lo and behold, after searching a bit with Dusty, he and I latched onto a rocket of a thermal. It wasn’t necessarily pretty, and we both had to work to keep with it, but we both managed to ride it to 5100.At that point, Dusty started heading “back.” I’d only ever even launched from Crestline once, and certainly never gotten high and flown back there. I had a moment of doubt, but then decided that since I had about 50-100 feet on Dusty, I could keep my eye on him the whole time, follow him, and worst case scenario bail and head out again. The glide was smooth, with not a single beep out of my vario the whole time we were headed back. We crossed the ridge leading down from The Billboard (Yes! I’d made it there!) at about 4600, and there were those lovely beeps of the vario again! We circled in the bowl there, and I got to have my first pass flying over the billboard! (for those that don’t know, the billboard is an old radio antenna that looks like a green billboard, thus the name).

Did a few passes there, before Dusty stared heading for Pine. Why not? Off I went. On the way there though, I hit some pretty big sink, and I’d fairly well used up my reserve of boldness in the glide back to Crestline, so I decided to play it safe, and aborted the glide to Pine to head back to Regionals. Made it back there with altitude to spare, but not a lot, and started working things there again. Folks were working the area by the 750, so I headed that way, and managed to hook a nice one that drifted me back towards Marshall and up to 4300. I noticed Brian over by Marshall, so headed that direction. Made a couple passes over the peak, and managed to nail my first top landing there! Brian later managed to scrape his way up enough to have a side hill landing, and we took a nice breather before both launching again and enjoying sled rides to the LZ.

An eventful 1:30h flight, followed by a victory lap flight of 14 minutes! What a day!

And here is the KML file.

Soboba Flying!

| Comments

Had a great weekend at a work party/fly-in at Soboba, a flying site near San Jacinto, California. Talk about a fun time! We worked all saturday morning widening a leg of the trail used to hike up to launch to 6’ wide, to make hiking easier, and to hopefully allow quads and hardy golf carts to help bring equipment, gear, and pilots up the hill. We all got dusty as hell from the upslope wind, but it was definitely worth it. Got some lunch at McDonald’s/Taco Bell and made complete messes of their bathrooms trying to wash off the layers of dirt and dust.Got back to the LZ, and headed up the hill! The hike wasn’t so bad, a little bit of good exercise before getting to fly. Did some para-waiting for a while, and finally most folks got off the hill around 5 PM, give or take.

It was a classic glass off, with butter smooth lift anywhere you went looking for it. Had a nice hour and a half flight, and managed not to screw up my first landing in a foreign LZ. Here’s a screenshot:

And here’s the IGC and (since they’re in high demand) KML files. The KML file could use some work, I haven’t yet figured out how to:

  1. actually see the individual track points, or
  2. see a path that includes the elevation so you can actually see the 3D path like the one rendered by GPLIGC.

Camped out that night, enjoyed a nice BBQ with everyone, then crashed in the shipping container at the bottom of the hill. Spent the next day hanging out, working a bit on some stuff by the shipping container, then headed home since we were grounded by rain. Altogether, an awesome weekend, and a lot of fun flying for the first time at a new site. Big thanks to Darrel, Bob, Alan, Elvis (and his awesome dog Leeloo Dallas Multipass Lopez), Roger, Mike, Regina, and everyone else that was there and made it such a great time flying there!

EDIT: Thanks to some examples from my brother, 3ric, The KML file now has a path that includes all the altitude information. You can right click the path, click properties, go to the altitude tab, and click “Extend path to ground” if you want to help visualize the path that way. Here’s a screen grab of the path in google earth:

GPS Tracks of My Paraglider Flights

| Comments

So a while ago I took advantage of my REI dividends and bought myself a Garmin Foretrex 101 to take with me on my paraglider flights. Three weekends ago I managed to sneak a flight in, and recorded my first track on the thing. I found GPLIGC a while ago, which is a utility for viewing the statistics of flights, as well as doing 3D models of IGC files (which you can create from the Garmin format easily). I managed to get the elevation data installed/configured, but I haven’t yet figured out how to get the giant 6000x6000 pixel GeoTIFF images from here into a format GPLIGC can digest, so no orpho map backgrounds for my stuff just yet. Anyways, here’s a rendering of my flight:

It was a nice hour long flight, beautiful conditions, etc. I actually only landed because I was starting to feel a bit queasy after the previous night’s festivities (if you look closely at the flight, you can see a spiral or two in there that I pulled to try to get down faster (and for practice as well).You can grab the IGC file here. Fun stuff, I wish GPLIGC were anything other than Perl/Tk, but until I magically find time to hack on something myself (maybe leverage Turtle? Do something new myself?), it will definitely do. Fun stuff!

Medsphere Is Hiring!

| Comments

Medsphere is hiring! We are on the lookout for sharp software/UI developers right now to work in Orange County, California. We have a full job description up, but I’ll attempt to summarize from a “in the trenches” perspective:The R&D team is busy implementing all sorts of GUI components of the healthcare experience. We recently open sourced OpenVista CIS, which is the project I’ve been working on the past year and half, and we will be doing continued development on that, as well as working on several other components needed to flesh out the healthcare experience. The perks include:- Working on a project that can have a huge impact on the health and welfare of thousands of individuals. - Working in a fun, flexible environment using open source technologies. The UIs are written in gtk#, but we’re looking for anyone with UI design experience. You can pick up gtk+/gtk# easily if you’ve done UI development before. - Enjoying beautiful, sunny southern California. If you need convincing, it’s a gorgeous 75F out right now. If you’re not out here already, we can certainly try to work something out to get you out here. If you’re at all interested, please mail your resume to me at pete.johanson@medsphere.com