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.
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
2) More color, less shadows – for a brighter day
3) New background - behold the dots!
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.
Tests help me write better apps. Writing tests informs my interface designs, expresses some of my intentions, and guards against regressions. As applications grow so do the number of tests I’m running as a regular part of my development workflow. If I’m not careful those growing test suites can slow down, become inconsistent, and eventually lose the trust of the development team. Fortunately, test driving software design is not a new idea and we can look to other languages and frameworks with good testing practices for inspiration on how to avoid pitfalls we encounter when writing tests.
I ran into a couple of cases on recent projects where I wrote unreliable iOS XCTests. Let’s take a look at what went wrong, what a better test might look like, and what tools we, as iOS developers, might be missing.
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.
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.
Recently, we joined the CODE2040 community for a celebration of the 2014 Fellows. The evening started with a career fair where Marc, David and I had the chance to talk with the Fellows about what was next. A few of us had met some of the Fellows at previous events and we had briefly meet Estefania as she works with one of our clients, Good Eggs. But the career fair was a rare opportunity to speak with them one-on-one.
CODE2040 is addressing a real need to close the gap between the vast opportunities in the technology space and the lack of diversity in the workforce. Right now, the program is focusing its efforts on a Fellowship program for high achieving Continue reading
This Tuesday in Madison Square Garden, the National Pro Grid League will have its first regular season match. Three months ago, we started building the real-time scoring system that backs its events. Here’s how we did it:
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.
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
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.
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).