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.
In this article, we’ll demonstrate usage of the Bacon.js library, implementing a Node.js chat application in functional reactive programming style. We’ll use the Socket.IO chat application example as our baseline, adding on some additional asynchronous workflows, interaction with MongoDB, error handling, and logging.
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.
Try it out and feel free to send us your thoughts at firstname.lastname@example.org. We have a couple of big new features in the pipeline, but we’re excited to hear your thoughts as well.
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:
Madison Square Garden
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