This approach is well and good when you have very concrete module boundaries that are well-defined and coarse enough to warrant the ceremony of wiring up a behavior for a module boundary. But what if we aren’t necessarily interested in all the work in creating a mock, and we need something simpler and more lightweight?

Join us as we discuss some alternative ways to write lightweight tests across function or module boundaries.

Let’s say you’re managing complex process state in your Elixir application and you need a way to spin up and down new processes as your app runs. This requirement is known as dynamic supervision, the ability for a supervisor to add processes to its supervision tree at runtime.

This post will explain how to implement a process under dynamic supervision with Elixir 1.5, and discuss how Elixir 1.6’s new DynamicSupervisor is easier to configure and is more flexible.

If you’re like me, you came over to Elixir from Ruby and quickly found that certain development assumptions so common to Ruby (and object-oriented programming) require some adjustment in this new functional language. Continue reading …

Elm emerged on the scene in early 2012 as a strongly-typed, functional language that compiles down to Javascript. With its architecture and type system, it claims to provide bulletproof guardrails to help developers build systems that are highly reliable, with “no runtime exceptions in practice”.

Lately, a few Carbon Fivers and I have been taking the language out for a spin and discovering what it means to write software systems in Elm. In this post, we’ll walk through what it looks like to take a small form widget written in vanilla jQuery and convert it to Elm, picking up language basics and learning to write apps the Elm way. We’ll also discuss the unique feature set that makes Elm apps so reliable.

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:

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

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 …

In Part 1 and Part 2 of this series, we introduced the engineering team at SuperStartupCorp. They had built a reputation for delivering quality software, fostering a culture of trust, and developing healthy learning practices. Read up on the first two parts, then join us to discover the final secrets to their success.

You’ve resolved to build your company’s Next Big Thing in Phoenix and Elixir. That’s great! You’re facing a problem though – all user authentication and access concerns are performed on your Rails system, and the work to reimplement this in Phoenix is significant.

Fortunately for you, there is a great Phoenix plug to share session data between Rails and Phoenix. If you pull this off, you’ll be able to build your new API on your Phoenix app, all while letting Rails handle user authentication and session management. Let’s get started!

In Part 1 of this series, we introduced a high-performing engineering team at SuperStartupCorp that had automated repetitive tasks, codified its engineering practices, and adopted a learning mindset, resulting in happy engineers and happy stakeholders. Read on to learn more traits and practices that make this team so successful, and how they keep their bus factor high. (If you’re feeling extra adventurous, you can head on over to Part 3).

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.