Raphael Koh

In our last Domain-Driven Design discussion, we learned how to group similar business components into application Bounded Contexts, which were separated folders in our Rails apps. This segregated cohesive groups of application code into separate folder structures (bounded contexts), and gave us a jumping-off point to drawing more explicit boundaries between domains in our monolith. Now it’s time for us to re-think how to communicate from one context to another. Here’s how:

Continue reading …

As the popularity of Elixir and Phoenix continues to grow, we find ourselves spinning up more and more Phoenix apps for our clients and side projects. At Carbon Five, we have a pretty good consensus on our favorite practices and tools. With each new app, we find ourselves repeating the same steps to bring in many of the same resources and processes.

We created Razor, an opinionated app generator, to save ourselves this time and trouble. Razor isn’t the only one out there, but it captures our common needs and preferences at Carbon Five pretty comprehensively. It also provides a great platform for discussion; we hope to watch Razor evolve as the Elixir ecosystem grows and we continue to learn.

Continue reading …

Recently, designers and technologists from Cooper & Carbon Five sat down to brainstorm about the future of voice-driven user experiences, focusing initially on Alexa. It was a fun kickoff for what we hope turns into a series of prototypes and experiments exploring (and pushing) the boundaries of this exciting emerging technology. Here’s what we’ve discovered so far:

Continue reading …

As a consulting firm that’s been around for 17 years, Carbon Five has a unique perspective on trends in digital product development. In this post we look back on 2016 and reflect on what we’ve seen in the industry, and where we think it’s headed. Here are the the top five trends we saw in 2016.

Continue reading …

Working on an oldish Rails project, I came across some smelly ActiveRecord code that begged for some refactoring love. I also spent some time speeding up pages with slow/many database calls. Between those two experiences, I felt the inspiration to write-up some “Back to Basics” Rails Database Best Practices.

Rule #1: Let your Database do its Job

Databases are extremely feature rich and are really freakin fast when used properly. They’re great at filtering and sorting… and many other things. If the database can do it, it will do it way faster than doing the same thing in Ruby, or any other language for that matter.

You might have to learn a little bit about how DBs work, but honestly, you don’t have to go very deep to reap a majority of the benefits.

We generally use Postgres. What you choose is less important than getting to know it and using its features to make your product awesome. If you’re curious about Postgres, there are some good resources at the end of this post. We love it.

Our first, overarching rule: Let your database do what databases are good at, instead of doing it in Ruby.

Continue reading …

Check out the video of this talk from ElixirConf 2017 below

Monolithic applications are great when you start building your company, but as time progresses, they become difficult to maintain. These codebases, as they grow, easily become Big Balls of Mud.

When building large applications in frameworks like Rails, the very convention-over-configuration design principles that made Rails such a joy to use begin to get in the way when the application grows in scope. You may be experiencing the same pains as well if:

• Refactoring is difficult and tedious, because methods and classes depend on too many other classes
• You have an ever-growing list of business objects that are difficult to keep in your head. In fact, nobody seems to be able to understand the system as a cohesive whole
• Changing code in one area of the code leads to unexpected and unintended side effects in other areas of the code, because it’s easy to call out to global services and objects

Continue reading …

I want to discuss a topic near to my heart, a topic I believe to be the crux of effective software design. No, it’s not a new functional language, it’s not a fancy new framework, it’s not a how-to guide to do micro-services, nor a quantum leap in the field of machine learning.

It’s much simpler. It’s about names.

Names define us. They give life to abstract ideas and concepts and yet also stand in for real, physical objects. They’re language concepts, but more than that, they’re units of meaning. When used precisely, names enable shared understanding and smooth teamwork among people. Continue reading …

React Native is an emerging platform in the mobile space that allows developers to write native apps in Javascript without having to learn Java or Swift. It’s great conceptually, but developers end up having to write NativeModules (for iOS and Android) anyway because it lacks the tools that other frameworks generally provide. In this blog post, we’ll show you how to pass your build environment from the native environment to your javascript environment. In the process, you should get a better idea of how to build simple NativeModules.

Continue reading …

If you’ve spent anytime writing software, you’ve used an open source project. Open source projects save you time and energy by leveraging other people’s experience and hard work, leaving you free to focus on the core features of your project. Often people want to contribute to these projects, but don’t know where to start. They are afraid their contributions will be ignored or, worse yet, attacked. With tools like GitHub freely available for open source projects, anyone can become a contributor. If you follow a few simple steps, you can have a positive experience. Continue reading …

The tech scene (especially in the Bay Area) has reached a point where it’s expanded way past techies. It seems successful people from all different industries are drawn to the promise, reach, and money in tech. Doctors, bankers, artists, and even educators are launching startups and talking about MVPs. It’s definitely exciting and inspires me everyday. But, building a great product is sometimes more of an art than a science, and first time founders make common mistakes. From a company that has worked with more startups than it can count, and has seen its fair share of first time product mistakes, here are some of the most common ones to avoid.

Continue reading …