The Fiber dream

When my wife, Jesyka, told me she got a job at IBM in Austin, TX my first thought was: CONGRATUALTIONS! My second thought was: My friends are going to be super jealous when I tell them I’m getting Google Fiber.

The Fiber reality

After scouring apartment listings in Austin, and doing a bit of research, it became clear that there were a few problems with my Google Fiber dream:

• Roll-out was only scheduled for specific areas of Austin
• None of the areas were a reasonable commute distance from Jesyka’s work
• New areas were being added slowly

Google provides an excellent map of Fiber listings in Austin but there was no way to actually tell how often the listings were updated, if at all. Not to be deterred, I decided to write a webapp to track new Fiber listings, as they were added.

Reverse engineering Google Fiber listings

Using Chrome Developer Tools, I was able to check network traffic on the Google Fiber map and discovered that the data for all Fiber enabled apartments was being stored in a JSON file. This JSON file was used by Google to build the apartment map on page load.

Rather than use inline linking for my webapp, I wrote a Go tool to fetch, parse, and store apartment data in a separate database on Heroku. This prevents page loads from my app causing additional traffic on Google servers. Heroku’s background job scheduler runs the tool a few times a day, to avoid the server stress mentioned earlier.

For the front end of the webapp, I used AngularJS. The front end uses an AJAX request to query the Heroku back end for JSON apartment data. The apartment data is then loaded into a table, which lists important information such as the name of the apartment complex, address of the apartment, and time the listing was added. Using AngularJS’ built-in data filtering, users can search for listings by apartment name or address.

Check it out

The Austin Fiber site is still up here. The code is also available on Github.

From restaurant to manufacturer

I’ve worked with Marie Antoinette’s Gluten-Free Bake Shoppe, as their Lead Developer, since the company was founded. In late 2014, the company decided to shift their business strategy. The owners closed their restaurant and chose to focus and grow their manufacturing and distribution business by selling directly to vendors instead.

Requirements

After working with the business owners, a designer, and speaking to product vendors, the following list of requirements for the new website was created:

• display information about the bakery (contact, hours, etc)
• allow customers to browse and search the bakery menu
• allow customers to place online orders, which could be shipped or picked up
• create a separate menu and order placement system for vendors
• admin ability to edit menu items, create vendor invoices, and approve new vendor accounts
• quick development is preferable as the current site lacks functionality

Roll your own or use a prebuilt solution?

First I considered using an off the shelf solution. Creating a content management system and ordering system from the ground up is quite a bit of work. I did research into existing “shopping cart solutions” such as Shopify or Magneto. Unfortunately, none of the existing systems I could find were able to satisfy all of the requirements. To use an off the shelf solution, I would need to extend the code base with a plugin in the language “chosen solution” was written in. Rather than go down a rabbit hole of foreign application architecture, undocumented features, and learning a new language, I decided to rebuild the Marie’s site from scratch.

Front end structure

The front end was built using AngularJS and Bootstrap 3. AngularJS’s strength lies in its two-way data binding as well as its large selection of third party libraries. Functionality, such as filtering a list of menu items based on a search, is fairly trivial to do in AngularJS. Coupling AngularJS with Bootstrap allowed me to rapidly set up, try out, and iterate different layouts with the designer. Bootstrap is designed to be customizable out of the box, so changing how everything looked was no problem.

Why Go?

For the back end I chose to use the Go programming language. I had been using Go in my side projects for a while and I wanted to leverage Go’s strengths of:

• a robust standard library
• easy to deploy to a variety of platforms (I chose Heroku)
• excellent performance
• built in concurrency
• official library support for Stripe (our payment processor)

I chose to use the Martini web framework after hearing about in on the Changelog Podcast. Martini has several upgrades the from the built-in Go web framework that the Marie’s site would rely on. These include:

• middleware support for simple HTTP request/response modifications
• improved routing controls, making REST API endpoints easy to write
• dependency injection make sure that you always have access to the correct objects

I also chose to use GORM to connect to the database. GORM allows you to declare normal Go structs that map directly to database tables. When you make a database query with GORM, it’s a series of methods that return an easy to use Go struct. Using an ORM library, over manual SQL queries, made sense for the Maries site as development speed was more important than raw performance.

Still going strong

The Marie’s website is still up and running today with both vendors and regular customers making online orders! You can check it out here.

Teacher-centric lesson planning

Common Ground, a companion webapp to Inscribe, enabled teachers with Inscribe accounts to create lesson plans for their current courses. Teachers could also export lesson plans and collaborate with other teachers on shared lesson plans. Common Ground had the following requirements:

• share login and user data with Inscribe
• allow teachers to create lesson plans for Inscribe courses
• populate lesson plans on a calendar
• ability to easily export lesson plans to a variety of formats
• enable sharing of lesson plans and editing by multiple teachers

Talking to Inscribe

Although the back end for Common Ground was written in a different language than Inscribe (Go and Python, respectively) it was pretty easy to communicate over HTTPS between the two. When a user would login to Common Ground, the following process took place:

• login request sent to Common Ground
• Common Ground forwarded the login request to Inscribe over HTTPS
• Inscribe checked the user’s credentials and returned a JSON Web Token(JWT)
• Common Ground sent the JWT back to the user to be stored client side

Common Ground and Inscribe shared the same JWT secret key, which is used to determine the validity of JWT claims. Sharing the JWT secret key between the two back ends made it so Common Ground could validate claims for Inscribe JWTs, instead of checking with the Inscribe back end every time the user tried to do something.

Front end lessons from Inscribe

After the lessons I learned from Inscribe, I immediately chose to use AngularJS for Common Ground’s front end. Using the same front end framework across both Inscribe and Common Ground had the added benefit of allowing me to reuse code across the two projects. This enabled the team to quickly get Common Ground up and running.

Iterate early, iterate often

Today Common Ground is no longer in use. After extensive user testing, Pomegranate Lab determined that a different approach was needed to help teachers better connect with their students. This project later iterated into The Playbook.

When it was around, Common Ground looked like this: