As a consulting firm that’s been around for 17 years, Carbon Five has a unique perspective on trends in digital product development. In this post we look back on 2016 and reflect on what we’ve seen in the industry, and where we think it’s headed. Here are the the top five trends we saw in 2016.
The micro-services push is on with developers writing simpler applications that interact with each other. But how do you deploy these services? Manage versions and discoverability? Learn two approaches from our August 17th Talk Night speakers as they cover using Docker or going completely server-less with Amazon Web Services’ Lambda!
First we’ll have Samuel Chow, Head of Mobile at Farmers Insurance, give an “Intro to Docker”:
Docker has become one of the hottest technologies in the industry. But what is Docker? Why do developers love it and why might you want to use it? We will cover how it works and introduce the Docker terminology and toolset.
Then Grindr’s Principal Applications Engineer Tom Bray walks us through “Going Serverless with AWS Lambda”:
Microservices got you down? Come learn how to implement Serverless architectures with AWS Lambda and API Gateway from someone who has done it in the real world. Get a glimpse of life beyond the operational overhead that Microservices require and discover the benefits of Serverless. Decrease time to market, reduce operational cost, and let AWS Lambda handle scaling for you automatically while you only pay for the compute you use.
Our doors will open at 6pm with pizza, drinks (including non-alcoholic options), and of course wi-fi provided. The talks will kick-off at 7pm, with Q&A interspersed throughout.
So sign up on Meetup and get ready to get some macro-knowledge on building micro-services!
Among many of the new features of ES6, aka ECMAScript 2015, is the arrow function expression, also known as the fat arrow function. For those that have been programming in CoffeeScript, the syntax will look quite at home.
Essentially, it’s just a different way of specifying a function (of which there are a ton of different ways in ES6), but it’s not a direct replacement for function — you can’t do a ‘replace all’ in your code. Several important differences beyond syntactic sugar exist, including: 1) it creates a lexical this, 2) it implicitly returns an expression, and 3) it’s always an anonymous function. And that is where it gets interesting. To understand the problem the standards committee was trying solve, you first have to delve into context and the lexical this.
If you’ve practiced Test-Driven Development, you know that fast-to-execute tests are more than just a nice-to-have. As suites get slow, developers run them less often locally. Failures start to crop up in the CI environment, and the length of time between a breaking change and its detection increases.
The problem gets worse with acceptance tests. Since they execute in a browser, they’re slower to begin with and significantly more brittle. But with these negatives come a huge benefit: since they interact with your application in the same way a user does, they give you much more confidence that your system is working than isolated unit tests.
Running tests in parallel can sometimes help speed up tests, but doing so comes with its own set of issues. As with any concurrent code execution, global state can cause intermittent failures. In particular, very often tests rely on making changes to a database. These changes can easily leak from one test to another, causing havoc.
The upcoming release of ecto has a interesting new solution to this problem. It offers a connection pool built on the db_connection library, which provides a module named DBConnection.Ownership.
Higher Order Components (HoC) in React can be simple to use and test. If you haven’t read about HoC’s and how and why they’ve replaced mixins, check out this great Medium post by Dan Abramov.
Most of the resources and examples that I found online about higher order components are complex, and don’t include a testing solution. This is a super simple example designed to demonstrate how we can generalize React components using Higher Order Components and unit test them. We will be using ES6 syntax and Enzyme to test.
The video of the talk is available above (thanks to the EmpireJS crew for it and being incredible hosts) and the slide deck is available below. Try out demos on our VR demo site c5vr.com with all the code being available through the site’s repository.
Finally, we’re holding a workshop in our Santa Monica office walking through the same concepts for the Android platform, using Google Cardboard and Unity on Wednesday May 20th at 7:00pm PDT. For $15 you get one of the limited spots and your own take-home headset so if you’re interested, please register here!
Directives man! While the they’re literally the entry point into Angular development (every application contains a call to ng-app), many people starting out with Angular are hesitant to write their own because of the complexity associated with them. And directives are complex. Even a simple directive requires understanding complicated concepts like restrict, scope and link. But when you figure it out, the value of a directive as a reusable component becomes indispensable.
But what about when a directive isn’t self contained? What if a complicated component comes along that is naturally modeled by multiple directives? This group of directives, as a whole, form a single self contained component. None of directives in the group can stand alone because they only make sense when used together; they collaborate; they are aware of each other and need to communicate with each other.
This post will discuss best practices for managing communication among collaborating directives and illustrate these practices with an example.
We’ve been trialing the usage of Docker and Docker Compose (previously known as fig) on a Rails project here at Carbon Five. In the past, my personal experience with Docker had been that the promise of portable containerized apps was within reach, but the tooling and development workflow were still awkward – commands were complex, configuration and linking steps were complicated, and the overall learning curve was high.
My team decided to take a peek at the current landscape of Docker tools (primarily boot2docker and Docker Compose) and see how easily we could spin up a new app and integrate it into our development workflow on Mac OS X.
In the end, I’ve found my experience with Docker tools to be surprisingly pleasant; the tooling easily integrates with existing Rails development workflows with only a minor amount of performance overhead. Docker Compose offers a seamless way to build containers and orchestrate their dependencies, and helps lower the learning curve to build Dockerized applications. Read on to find out how we built ours. Continue reading …
Our example application implements a function createEmployee that is used to create an employee from a personId.
To create an employee, our system loads some data from our database, validates that data, and then performs an insert. Some of our functions are written in continuation-passing style (they accept a callback) and some are written in a direct style (they return values and/or throw exceptions). We’d like to compose these functions in such a way that they succeed or fail as a single unit – that any error in any segment of the sequence will cause subsequent steps to be skipped with a failure – but with some of our validations happening synchronously and some asynchronously, this can be difficult to do.
Carbon Five is a full service software consultancy that helps startups and established organizations design, build, and ship awesome products. If you have a project you’d like us to take a look at, or are interested in joining our team, please let us know.