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!
This month we welcome J.J. Arnold to the Carbon Five blog. J.J. recently joined us as the office and events coordinator in the San Francisco office. Her first week coincided with one of our semi-annual retreats, and she graciously agreed to write up a diary of her experience.
April 21st marked the start of Carbon Five’s 2015 Spring Summit! Team members from San Francisco, Chattanooga, and New York converged on our new office in Santa Monica. The days that followed included informative presentations, exploration, experimentation and a whole lot of team bonding.
Note: If you’re looking for information on Houdini or Toggle, you’re in the right spot. After changing the project name from Toggle to Houdini (for SEO reasons), we’ve switched again (there was another Houdini already). If you know of another language called “Presto” please let us know, we’ve got more names.
Over the years we’ve noticed that it seems like every day, all day, all our fancy code boils down one basic thing: showing and hiding DIVs. That’s it. Send a bunch of DOM to the browser, then toggle those DIVs on and off. Logged in? Show a DIV. Logged out? Hide a DIV. Click a tab? Yup, another DIV.
So, we’ve gone and done it. We wrote our own language, Presto. And Presto is all about showing and hiding DIVs. Fast. How? Read on. It’s like magic.
You’ve got a software project—you just need the resources to do it.
So you start writing an RFP (Request for proposal). You put down the budget, timeline and deliverables in an effort to properly scope the initiative. After all, you need to find the best qualified team which means you need to be as specific as possible.
Then, you sit back and read what you’ve outlined.
After your brain gets back to its normal speed, you realize that if you can’t keep yourself awake, you have little hope of keeping potential teams engaged long enough to gain interest in your project.Continue reading …
Steve McConnell wrote a book called “After the Gold Rush” that was published back in 1999. He wrote about how the software development industry would benefit by maturing and becoming a professional industry that had learned from the mistakes made during the tech bubble of the late 90s (Steve is actually better known as the author of “Code Complete,” a great book that influenced very many developers). We, as an industry, have learned a lot since then and there are far fewer colossal failures, but we still have plenty to learn about building successful software products. This is especially important when you’re considering your next gig.
The (tech) Gold Rush is still going strong, having dipped only a bit in the mid-naughts. If you’re an experienced designer, developer, or product person… you have more opportunity than most people out there. That’s a great position to be in and we should all be thankful.
All that opportunity makes deciding where to exercise your talents harder. There are many factors at play when you’re looking for a job, some of which may be obvious (e.g. size and location) and others which require looking inwards (e.g. culture, work style, and hierarchy). If you’re looking for a new gig, here are some tips that will help with the process.
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.
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.
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.
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.
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.