As a former Dev Bootcamp (DBC) student, I get a lot of inquiries from recent grads asking for tips on landing a job. I was lucky to get into the DBC early, graduating from the second cohort a year and a half ago, and the job market was quick to pick us up. However, after going through the growing pains of learning how to code in a production environment, I don’t find it too surprising that bootcamp grads now are having a harder time landing jobs.
Node.js has more than proven itself capable of handling
multiple events concurrently such as server connections, and all without
exposing us to the complexities of threading. Still, this locks
our apps down to a single process with a single thread of execution
consuming a single event queue. On a machine with a single processor, this
is no big loss; there is only one active process in any case.
But we live in a multi-core world now and out of the box Node does not take advantage of this,
though it certainly has the ability to. Continue reading
It was about a year ago that we first announced Raygun, our Rails applications generator. Since then, many apps have been zapped into existence, both internally at Carbon Five and in the wild. Raygun evolved over the year; it does more of some things and less of others. Let’s see what Raygun does and what has changed…
Raygun is a command-line tool, installed as a gem, that generates new Rails apps with a bunch of tweaks, settings, and other time-saving enhancements. It bakes in the libraries and recipes we find useful when building Rails apps. Rather than including everything we might need, it provides a foundation that, by and large, is applicable to most projects.
Raygun also serves as living documentation of our conventions at Carbon Five. Changes are made via pull requests, where people propose ideas and others chime in with their thoughts. It evolves in small ways all the time, as our preferences and the available tools change.
At Carbon Five, we build quite a few AngularJS projects. It’s a fun, powerful framework that gets you up and running quickly, but once you’ve got your feet wet, you run into its infamous learning curve. AngularJS has a fair share of deep concepts; taking some time to understand them can get you back on track.
One of these important concepts is scopes. In an AngularJS application, the controller and view share an object called a scope; this object is at the core of its amazing two-way data binding. The controller sets properties on the scope, and the view binds to those properties. AngularJS takes responsibility for keeping the two in sync.
Greetings, programs! Meet vimtronner, a multiplayer command-line game that teaches you the core vim keys. Be the last player alive by either controlling your bike safely around obstacles or building your own walls for your opponents to crash into. Just remember: you can’t do both at the same time!
You can learn how to install and play
vimtronner on its Github page as well as check out its codebase. In this post we’ll walk through it’s origins and lessons learned about terminal graphics, handling input for games, efficiently routing events to interested parties and more. Continue reading
All the programmers around me seem to have very strong opinions about functional programming. The Internet certainly loves to talk about it. Some of the concepts are interesting – but many of them (at first) don’t seem to apply for those of us writing database-fronting web applications. What can we apply from a world in which side effects are shunned if the majority of what our application is doing is getting stuff out of a database for display on a web page?
In this article, I’ll share some of the lessons I’ve learned writing programs in a functional style using other languages and how these lessons apply to problems of testability, predictability, and parallelism in the regular ‘ole web application code we’re writing today. I’ll show you how you can increase the quality of your existing application by introducing stateless functions that interact with the state-manipulating stuff you’re already familiar with (and have already written). This article is geared towards web application development in the real world; don’t fret, the word “monad” does not appear anywhere on this page. Continue reading
Here at Carbon Five, we consider testing the software we write to be crucial to the long term stability and velocity of our projects. We also value developer productivity. The iOS simulator is a very valuable tool for testing and development. Recently a major upgrade of a library prevented an iOS project from running and testing in the iOS simulator. We had a problem. A little bit of refactoring and a new CocoaPods podspec got things moving again.
As websocket communication makes large real-time web experiences more common, we are increasingly faced with the problem of how to build apps that work just as well with many concurrent users as they do with a few. The problem touches both the technical limits of the server infrastructure and the design of the user experience. This post argues that imposing an artificial constraint on concurrent users and then designing around that constraint will lead to better real-time apps. It then describes a scalable waiting list implementation (with a working demonstration project) built around Redis sorted sets.
Rails offers an easy way to render objects in a view that are automatically associated with their
own partials. With ActiveModel::Conversion, you can quickly build widgets out of classes (models or presenters or other).
In a recent project, we had several little status/info blocks that we wanted to render on a page. Each block required different model data. In the controller, as we started writing code to fetch all the right data and put it together, we quickly realized that things were going to get ugly. We started with something like this:
You can see that as we added more items to put on the page, both the controller and view got bigger and more complex.
Posted in Web