Using Objection with UIViewControllers and Storyboards

I have used Objection in several iOS projects as a lightweight Dependency Injection framework.  If you’re not familiar with it, take a look.  One pain point has been how to inject dependencies for UIViewControllers that are in storyboards.  Your controllers are likely instantiated through segues or by calling instantiateViewControllerWithIdentifier on a storyboard instance.  Wouldn’t it be nice to have Objection inject the declared dependencies from its context on these controllers?  There is a simple way to accomplish this – subclass UIStoryboard and override instantiateViewControllerWithIdentifier.  This technique is based on a stackoverflow post for how another DI framework, Typhoon, can be integrated with storyboards.

Continue reading

Posted in Mobile | Tagged , , , | Leave a comment

Node.js in Production

When running a node application in production, you need to keep stability, performance, security, and maintainability in mind. Outlined here is what I think are the best practices for putting node.js into production.

By the end of this guide, this setup will include 3 servers: a load balancer (lb) and 2 app servers (app1 and app2). The load balancer will health check and balance traffic between the servers. The app servers will be using a combination of systemd and node cluster to load balance and route traffic around multiple node processes on the server. Deploys will be a one-line command from the developer’s laptop and cause zero downtime or request failures.

It will look roughly like this:

Photo credit: Digital Ocean

Continue reading

Posted in Ops, Web | 24 Comments

An Incremental Migration from Rails Monolithic to Microservices

Your Rails application has become a monolith. Your test suite takes 30 minutes to run, your models grow to several hundred (or thousand!) lines, and feature development slows to a crawl. New members of your team must read through massive amounts of code before they can feel confident making changes. You’ve watched Uncle Bob’s Architecture the Lost Years, Matt Wynne’s Hexagonal Rails and read Martin Fowler’s Microservices and are convinced that the time has come to start breaking things up into smaller, simpler, faster components – but you’re unsure of where to begin.

In this article, I will demonstrate an approach to breaking a monolithic-style Rails application apart into microservices using plain Ruby classes and a simple RPC framework – all deployed to Heroku. I’ll show you how to work through this migration incrementally; you’ll be able to decompose things down as far as makes sense for your codebase. As a special bonus, I’ll show you how you can use Barrister RPC to alleviate much of the pain associated with documenting and creating API clients for the components of your now-distributed system. I’m skipping the advocacy; if you’re here it’s because you already love yourself some microservices but don’t know how to implement them yourself.

Continue reading

Posted in Everything Else, Microservices, rails, ruby, Web | 12 Comments

New Hat Meets Old: Polyglot Distributed Systems with Barrister RPC

Connecting the components of a distributed systems is no easy feat. Should I use REST? An RPC system like Apache Thrift? Protocol Buffers? SOAP? How do I document these components’ APIs? What’s the best way to write client bindings? The Internet offers a wide array of possible solutions, all of which I’ve found to be either incompatible with my needs (to, at minimum, work in a web browser) or heavy (XML sucks).

For the last few years, I’ve enjoyed great success using a an RPC framework called Barrister. Barrister RPC provides a variety of language bindings (Python, Ruby, browser-based JavaScript, Node.js, Go, Java, and PHP), which means that I have no problems connecting my Backbone application to a Ruby web service, or Node.js image processor to Spring MVC. Barrister separates API design from transport – so I can experiment with HTTP or SMTP or Redis queues… all without changing my API. Remote calls are encoded as JSON, so I can debug using Firefox and all the other tools I’m already familiar with. Imagine SOAP, redesigned for developers who build modern, dynamic, cloud-deployed web apps, don’t work at banks and have no stomach for enterprise service busses or XML. Continue reading

Posted in Everything Else | 1 Comment

The Junior Jump – A Retrospective

One of our goals here at Carbon Five is to play a bigger part in mentoring the growing community of junior developers. Last week, we took a big step toward that goal by hosting our first ‘Junior Jump’ event in our Santa Monica office. The event, a follow up to this blog post, was centered around helping junior developers learn more about working in a professional process, and giving them tools that they would be using on day one of a real product team.

image1

Continue reading

Posted in Everything Else, Mentorship | 1 Comment

A Lack of API Documentation Considered Harmful

As someone who consumes many web service APIs – both internal and external – the recent trend in the web development community to forgo writing API documentation has got me worried. While I do understand that publishing and maintaining documentation can be a hassle, APIs with no documentation can quickly become a bottleneck in a team’s workflow, inhibiting the team’s ability to scale, outsource, or distribute themselves geographically. In this article, I’ll walk you through a partially-fictionalized version of a disastrous experience I had working on distributed system whose APIs were largely undocumented.

Continue reading

Posted in Everything Else | 5 Comments

Roll Your Own Asset Pipeline with Gulp

I’ve found myself using Gulp for just about everything involving HTML/CSS/JS these days. It’s super fast, quick to write scripts for and flexible. I’m at a point now where I have a ton of projects I can just cd into, run gulp and be up and running. It’s the best solution I’ve found for delivering static assets whether for local development or production.

If you haven’t used a tool like this before, you might be thinking that your cobbled together scripts (or Asset Pipeline) work just fine. The value of using Gulp is not within its ability to concatenate files, minify files or any of that. Gulp’s true value lies in its ability to compose these things well. Using disparate components might make it easy to concatenate JS, but mixing that in with Rev will immediately compound the complexity of your home-grown scripts. It’s value compared to Asset Pipeline is that it is still flexible.

If you’ve been on Rails’ Asset Pipeline, or on a totally different stack, Gulp should offer you a great solution to static asset compilation. Here’s how:

Continue reading

Posted in Web | Tagged , , , , , , | 20 Comments

Micromessaging: Connecting Heroku Microservices w/Redis and RabbitMQ

While attempting to deploy a system of interconnected microservices to Heroku recently, I discovered that processes running in dynos in the same application cannot talk to each other via HTTP. I had originally planned on each microservice implementing a “REST” API – but this wasn’t going to be an option if I wanted to stick with Heroku. Much head-scratching ensued.

The solution, it turns out, is to communicate between microservices through a centralized message broker – in my case, a Redis database (but I’ll show you how do it with RabbitMQ as well, free of charge). The design of each microservice API has been decoupled from HTTP entirely: Client/server communication is achieved by enqueueing JSON-RPC 2.0-encoded messages in a list, with BRPOP and return-queues used to emulate HTTP request/response semantics. The Redis database serves as a load balancer of sorts, enabling easy horizontal scaling of each microservice (in Heroku dyno) on an as-needed basis. Redis will ensure that a message is dequeued by only a single consumer, so you can spin up a lot of dynos without worrying that they’ll clobber each other’s work. It’s pretty sa-weet.

So how’d I do it, you ask? Read on!

Continue reading

Posted in Everything Else | 25 Comments

Tinderbox: Continuous Deployment and Better Code Reviews

A couple of months ago, we committed to hosting Tinderbox talks every 8 weeks. We’re excited to announce the second event in the new series, which is scheduled for Wednesday April 30th. This is what we have on the docket:

Paul Biggar, founder of CircleCI, is joining us to discuss the Many Ways of Continuous Deployment:

So… Continuous Deployment. You hear that you should be practicing continuous deployment, but nobody every pointed out that there are many different ways to do it!

This talk compares and contrasts different kinds of continuous deployment strategies. Implementation, requirements, tradeoffs will be covered. Case-studies, examining different strategies practiced at companies such as Facebook, GitHub, IMVU, Heroku and CircleCI.

We use CircleCI on many of our projects these days and think it’s pretty wonderful.

Doc Ritezel, from the Ministry of Velocity, is joining us to share some wisdom on the subject of Better Code Reviews:

Do your team’s technical discussions devolve into tense confrontations? Are you frequently confused by other people’s code changes? Is there someone who you just can’t seem to get along with? Software peer review on a modern development team is essential to healthy code and a happy team. But it’s riddled with human-sized pitfalls. Learn why talking about code in person is important, how to talk about code without burning bridges, and most importantly, how to take dread out of your workplace.

We shoot for an intimate atmosphere, great talks and insightful Q & A. We’re pretty proud of our previous events not only because the content has been good, but the questions and interactions have been high-quality. We hope you can join us.

Doors open at 6:30 and the talks begin at 7. Please RSVP at the Tinderbox meetup.

Posted in Events | Tagged , , , | Leave a comment

Extracting Service Objects From Workers

Background jobs processed by asynchronous workers, are a staple of most production Rails applications I work with. Inevitably there is some time consuming process that you want to handle in the background, either because you want to keep user requests snappy or because you need to process things outside of the context of a user’s request. Unfortunately, these worker classes frequently become a rat’s nest of business logic and responsibilities and rarely do they get refactored. In this post, I’m going to give an example of one such worker and explain how to refactor your code to be better organized, more easily read, and better tested. Usually a worker starts out fairly simple.

Continue reading

Posted in Web | 11 Comments