Chris Egy Rose and Patty Chang came to Carbon Five in spring of 2012 with an exciting new concept around facilitating human interaction and connected learning. The idea was to allow young people to connect with their friends, classmates and families through face-to-face interactions and a shared canvas. The interactive canvas overlay allows participants to use simple tools to create and draw with one another. The initial ten-week engagement happily turned into a rewarding long term partnership that shepherded the product and team through many iterations over many months, resulting in an outstanding, feature rich set of products.
Scoot & Doodle’s Scoodle Jam is featured in the Education section of the app store.
I am writing this to explore the following line of thought:
- We can increase the value we generate without expanding our talent pool
- Improving quality creates the most value
- Inflexibility keeps us from improving
- Ignoring queues is the primary cause of our inflexibility
- Kanban is the method for managing our queues
- Once flexibility exists, we can use it to add value by increasing quality
I will be exploring this in two major sections. The first will describe why flexibility matters. The second will prescribe a possible solution: Kanban. Get comfortable, this post is a little long.
On a recent project, my client set the ambitious goal of launching their MVP (minimum viable product) with just four weeks of development time. The entire project was budgeted for just two months, and we needed to launch midway so that we could gather data and user feedback, then iterate on those learnings. (At the time of this writing, the site is live but the client is still under the radar using a temporary brand name, so unfortunately I can’t disclose their identity just yet. But we’ll post an addendum when they launch to the public!)
- Responsive, mobile-first design
- Streaming video
- Shopping cart with credit card payments over SSL
- Embedded discussion forums
- Account creation and login via Facebook
- A/B testing for pricing
- Transactional emails
- Helpdesk chat
- Content management system
An additional challenge was that the team included just one developer and one designer. How would we meet our goal?
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.
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.
I love playing around with the LeapMotion. It is a wonderful little piece of technology, has great documentation, and is way ahead of its time.
More specifically, I’m interested in its potential to communicate with MIDI, the protocol which allows software to translate musical data.
A quick aside: My background is in music, having played drums since I was a small fry. Naturally, my instinct was to make air-drumming a reality with the LeapMotion.
I checked out the available options for LeapMotion “drumsets” and found current apps pretty difficult to use. There is a nice air-drumming example built in Python called AirDrum , but I wanted to be able to use more than just a few sounds for my drumset. So, I sought to build my own.
At Carbon Five we install and use many different database engines. Document-oriented databases are proving to be a good fit for more and more of our projects. MongoDB is the most popular of these and provides a powerful set of tools to store and query data, but it’s been plagued by performance problems when used with very large databases or large cluster sizes. Riak is another interesting option that is built from the ground up to perform at scale. But Riak is difficult to set up and has a minimal API that requires a lot more work to manage the data. RethinkDB is a relative newcomer that wants to fill the gap between these.
The trade-off between developer friendliness and high performance is unavoidable, but I’ve been looking for something in the middle. RethinkDB claims to solve the 1-15 problem, which is a database that is reasonable to use as a single node, but can scale up to around 15 nodes with minimal configuration and no changes to the application. Whether or not this claim holds up remains to be seen. In this post I take it for a test drive and provide a qualitative assessment (i.e. no benchmarks) of its ease of use and effectiveness for application development. The question is, what do developers have to give up for the peace of mind of knowing they won’t have to rip out the persistence layer when the app gains popularity (tldr; not much).
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.