Jake Gordon

Welcome, I'm Jake Gordon, a startup software engineer - a full stack developer who builds web and mobile applications for SaaS companies, and occasionally makes games on the side.


SaaS Shopping List(January 22, 2015)

In my last post I delved into a big list of things you probably have to think about if you’re starting a SaaS company.

I wanted to also take a moment to recognize the growing number of 3rd party SaaS vendors we depend on in order to build out our own platform, and the increasing amount of time we must spend on evaluating and integrating all of these pieces into a (hopefully) cohesive whole.

Generally speaking, for a lean startup we should be spending our resources on the core product features that are central to solving our particular business problem. I should not be spending time on peripheral concerns that would be best outsourced to a company that has already solved those particular issues.

I want to Build only if it’s core to the problem at hand, and Buy if it is secondary scaffolding that I just happen to need in order to support my core feature set.

What this means is that a large part of a tech co-founders role is making lists like this one…

Continued...

Software Startup Roles(December 26, 2014)

In 2015 I plan to (co)-found a new software startup company.

While I am confident about the technical aspects, I am less sure about the business, sales, and marketing components. So it will be critical to have co-founders with complementary skills in those areas.

Of course, having great co-founders doesn’t divest me of the responsibility to understand those areas. So recently I started to make a list of all of the things that a software startup must think about, make decisions upon, and act on, in order to succeed.

Naturally, being a developer, my list started with the technology - the services we would need, the platform we would choose, the development process we would implement, the infrastructure we would put in place…

My list grew long

Then I started to think outside of my area of expertise, and consider the bigger picture, customer validation, market research, competitive analysis, branding, funding, legal, accounting…

My list grew much longer

I am a natural organizer, so once I have a long list I want to categorize and organize it, and the obvious starting point was to break it down into the classic startup co-founder roles…

Continued...

Yesterday, I sent out a survey to developers asking if they still own and purchase technical books, along with a number of questions related to lending and borrowing books.

Huge THANKYOU to all who responded, and to the various tech groups that allowed me to post my request.

I’m considering resurrecting an old side-project of mine that would provide a local community book lending/exchange/selling platform - not a business, just a side-project, but I thought it important to find out if developers still used physical books, or if we had all switched to e-readers, or simply abandoned books for the quick fix from StackExchange (I hope not).

The survey was rough, biased, and not scientific, but I found the results interesting and wanted to share.

The nuances of human decisions can never really be summed up in a simple yes/no question so the open ended comments at the end are particularly interesting.

Here are the survey results from the first 100 respondents:

Continued...

I love books, especially technical books, and while there is no substitute for getting your hands dirty and to learn by doing, it can be refreshing to step back out of the weeds to get a holistic overview of a topic from a well written technical book.

But am I alone?

The audience for technical books seems like a shrinking market. There are very few technical bookstores left, and the computer section in Powell’s seems to shrink every time I visit.

Perhaps…

  • we’re all using e-readers?
  • we’re all ordering online?
  • tech books are too expensive?
  • and get stale too quickly?

Perhaps… we’ve simply lost our attention span and now look for quick answers from StackExchange and Twitter.

Well, I’d like to find out, so if you can…

Please complete this brief survey


It’s only 10 questions, it’s anonymous, and should take less than 2 minutes.


Cheers!


Ruby Shoes Tetris(November 07, 2014)

I was inspired by a talk from @jasonrclark at this weeks @pdxruby that reminded us that the Shoes project is still alive and well. I had a little free time so I thought I’d make a tiny contribution and take a day to port over one of my simpler javascript games to Shoes.

Shoes was is a cross-platform Ruby desktop GUI framework aimed at beginners wanting to get into programming. For those of us who have been in the Ruby community for a while we might have assumed that Shoes died when _why left the community. However, from the shoesrb.com history…

“Way way back in the day, there was a guy named _why. He created a project known as Hackety Hack to teach programming to everyone. In order to reach all corners of the earth, _why decided to make Hackety Hack work on Windows, Mac OS X, and Linux. This was a lot of work, and so _why decided to share his toolkit with the world. Thus, Shoes was born. Everybody loved Shoes. Many apps were made, and put into The Shoebox, which no longer exists. But, one day, _why left. In his memory, Team Shoes assembled, and carried on making Shoes. They released Shoes 3 in late summer 2010.”

… and they are actively working on Shoes4.

So here’s a version of Tetris you can run with Ruby Shoes:

Continued...

Daemonizing Ruby Processes(September 15, 2014)

Your application might need a long running process in order to:

  • Listen on a socket (e.g. a web server)
  • Subscribe to a queue (e.g. a resque worker)
  • Poll a DB job table (e.g. a DelayedJob)

Much of the time you will use an appropriate 3rd party server such as Unicorn, Resque, or RackRabbit, but sometimes you just want to write some Ruby code and make it daemonizable. To achieve this you might reach for gems such as Dante or Daemon-kit, and these are good options, but with a little work you can avoid the additional gem dependency and get a deeper appreciation for the underlying Unix process mechanisms along the way.

As part of my work on the RackRabbit server I had to learn a little more about daemonizing and forking unix processes, and so I wrote up a little how-to for those of you who might want to daemonize your own Ruby code without adding any new dependencies.

Continued...

SOA - Introducing RackRabbit(September 04, 2014)

In this series we have discussed:

We talked about why we might implement a Service Oriented Architecture in order to scale to meet…

  • the demands of our users
  • the demands of our dev team

We also talked a little bit of theory on what an SOA looks like, how to define the boundaries for our services, the practical implications of building a distributed system, and the 3 main communication patterns of a distributed system:

  • Synchronous Request/Response
  • Asynchronous Worker Queue
  • Asynchronous Publish/Subscribe

When implementing SOA using HTTP, we discovered that we have access to a robust set of technical options such as Rack, Unicorn, HTTParty, Faraday, Redis, Resque, or Beanstalkd, but no single technology can provide for all 3 communication patterns.

When implementing SOA using AMQP, we discovered that we can implement all 3 patterns using a single technology, but the implementation details are a little more tricky, programming directly to the AMQP interface, and the infrastructure and community support for hosting production-ready consumers are lacking (e.g. there is no easy-to-program-to Rack interface, or Unicorn style server for easily load balancing RabbitMQ consumer processes).

Just like everything in our profession, there are trade-offs.

Continued...

SOA - using AMQP(September 03, 2014)

Service Oriented Design with Ruby and Rails - Paul Dix

In the introductory article we talked about why we might implement a Service Oriented architecture in order to:

  • scale to meet the demands of our users
  • scale to meet the demands of our dev team

We also talked a little bit of theory on what an SOA looks like, how to define the boundaries for our services, and the practical implications of building a distributed system.

In the previous article we showed how to build an SOA using HTTP that implements the 3 main communication patterns of a distributed system:

  • Synchronous Request/Response
        using Faraday, Unicorn, and Sinatra.
  • Asynchronous Worker Queue
        using Redis and Resque.
  • Asynchronous Publish/Subscribe
       using Redis.

This article will show how to implement the same 3 communication patterns using a single technology, an AMQP message broker such as RabbitMQ.

Continued...

SOA - using HTTP(September 02, 2014)

Service Oriented Design with Ruby and Rails - Paul Dix

In the introductory article we talked about why we might implement a Service Oriented architecture in order to:

  • scale to meet the demands of our users
  • scale to meet the demands of our dev team

We also talked a little bit of theory on what an SOA looks like, how to define the boundaries for our services, the practical implications of building a distributed system, and the 3 typical communication patterns we might need:

  • Synchronous Request/Response
  • Asynchronous Worker Queue
  • Asynchronous Publish/Subscribe

There are many ways to approach an SOA infrastructure, but within the Ruby and Rails community we tend to see the following two choices being considered:

  • SOA using HTTP - making an HTTP call to a rack-based server is bread-and-butter for the RoR community and so this is the natural technology we reach for when thinking about the synchronous request/response communication pattern. However we need to reach for additional technologies, such as Redis and Resque if we want to implement the additional asynchronous communication patterns.

  • SOA using AMQP - using a message broker such as RabbitMQ is not as common in our community as using direct HTTP calls, but this is a great option for providing a common transport for all three of our desired communication patterns (and more), as well as providing a robust, managed broker to act as the hub for all internal communication.

This article shows how to implement an SOA using HTTP.

Continued...

SOA - Overview(September 01, 2014)

Service Oriented Design with Ruby and Rails - Paul Dix

Table of Contents

Introduction

Regular readers of my (irregular) posts will know that I enjoy making fun little javascript games on the side, however my day-to-day work is generally spent building SaaS-style web applications, primarily within the Ruby on Rails eco-system.

For the last 7+ years I worked on a single RoR application that grew from an experimental prototype, into a beta product, through those first paying customers, via many, many short iterative releases, up to a large, robust, and feature rich application with thousands of users, supported by a company rapidly growing towards 100 employees.

Rails is a fantastic framework to get through those early years. It’s certainly not without it’s faults, but in terms of productivity and getting features to market it is hard to beat.

However, if we follow the vanilla Rails path we can easily end up with a large, monolithic application, and after a while begin to feel the creaks and groans of the framework and start to think a lot about the issue of scaling.

How are we going to…

Continued...

All Articles