Bash-pocalypse 2014!

By on in Everything Else

Hopefully by now everyone has heard about the Bash remote execution vulnerability, and is sufficiently terrified. We here at Carbon Five all use Macs, and so we are all by default vulnerable. Here are the steps we took to secure our computers. Maybe they can help you too.

Continue reading …


Junior Jump – Speaker Panel

By on in Everything Else, Mentorship

Here at Carbon Five, we have been making an increased effort to reach out to the growing junior developer community to provide guidance and mentorship. We piloted an event series dubbed Junior Jump, catered towards helping entry level developers prepare for their engineering careers. A few weeks ago, as a part of this event series, we brought in a group of junior developers and had an fishbowl-style open conversation about various topics concerning the current climate of junior developers including: the current difficulties of job searching, what kinds of expectations should be placed on a junior developer, and what the heck is a junior developer anyways. You can find the full video of this event below.

Continue reading …


Stickies.io Updated – More Color, Less Shadow

By on in Everything Else

We’ve heard lots of feedback from those of you using Stickies.io. Today, we launched a few small updates. Here’s what’s new:

1) New landing screen – with an easier way to give us feedback

Feedback

2) More color, less shadows – for a brighter day

Colors

3) New background – behold the dots!

Dot background

4) Most importantly – we dropped the name Boardroom. You might be thinking – what’s Boardroom? Exactly.

For those of you who don’t know, Stickies.io is Carbon Five’s free online, collaborative brainstorming and retrospective tool. The project started as a Node Knockout submission years ago (originally called Boardroom…well, originally-originally called Retroflection which was a mash-up of…nevermind). Anyhow, we’ve been slowly work on it – responding to Tweets and pull requests on Github ever since.

Try it out and feel free to send us your thoughts at stickies@carbonfive.com. We have a couple of big new features in the pipeline, but we’re excited to hear your thoughts as well.


Blocked by Design? Get Into a Design Flow with Story Triage

By on in Everything Else

In the years since we’ve been providing integrated design and development on agile teams, we’ve noticed something that seems to emerge naturally on projects that are going particularly well. While we always set out to design our products in small releases, refactoring along the way (i.e. “the smallest whole“), often designers find themselves quickly under a ton of pressure from the developers, who are looking for well-defined stories to work on, sometimes after only a week of product definition.

Needs Design

Even once the overall product design is in place, each week brings a handful of new features that developers are eager to start. In addition, sometimes a teammate will throw a story into the backlog that is just an idea, not even ready for a designer to elaborate. At times it can feel like our team is a fiery coal-burning engine (our product manager and developers) starving for fuel (the design).

Without time for a complete set of wireframes (let alone visual designs) designers sometimes have to get a little creative. Not every story can get the same level of definition, and a one-size-fits-all workflow (e.g. design, build, deploy) doesn’t really make sense for every feature. We’ve found a set of activities useful when the team feels “blocked by design.” I like to call it Story Triage.

Continue reading …


An Incremental Migration from Rails Monolithic to Microservices

By on in Everything Else, Microservices, Rails, Ruby, Web

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 …


New Hat Meets Old: Polyglot Distributed Systems with Barrister RPC

By on in Everything Else

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 …


The Junior Jump – A Retrospective

By on in Everything Else, Mentorship

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 …


A Lack of API Documentation Considered Harmful

By on in Everything Else

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 …


Micromessaging: Connecting Heroku Microservices w/Redis and RabbitMQ

By on in Everything Else

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 …


Spring Summit Diary

By on in Everything Else

Last week all of Carbon Five converged on Santa Monica for our bi-annual Summit to talk, eat, and play together. The theme for this season’s summit was Mobile, but as expected some of the most interesting conversations ranged far afield: from the challenges and opportunities of integrating design on Agile teams, to silly employee origin stories, and a thoughtful discussion about diversity.

IMG_0137

Following is a summary of the two-day event. If you’re curious about the presentation content, let us know and we’ll figure out a way to share the outcomes with you. More photos of the event can be found on our Facebook page.

Continue reading …