It remains a common practice in database systems today to refer to configurations where one database is a source of truth, and another database is a replica that follows the state of the source of truth database as a “master/slave” configuration.

Use of this term is problematic. It references slavery to convey meaning about the relationship between two entities. The term “slave” is used because one system is controlling the state of the other system.

Using these terms like this is cavalier. It downplays slavery and the massive human suffering it causes. By having an everyday use for the term “slave” we normalize the concept of having things called “slaves” and it desensitizes us to the seriousness of slavery. More importantly, the casual use of the term may be an unwelcome daily presence in the life of a person of color, for whom slavery has great personal significance. Continue reading …

Moving your code towards a more functional style can have a lot of benefits – it can be easier to reason about, easier to test, more declarative, and more. One thing that sometimes comes out worse in the move to FP, though, is organization. By comparison, Object Oriented Programming classes are a pretty useful unit of organization – methods have to be in the same class as the data they work on, so your code is pushed towards being organized in pretty logical ways.

Active Storage was introduced into Rails version 5.2. It is a highly anticipated addition to handle integrations with asset management such as AWS S3. For a long time, the field has been dominated by outside gems, including Paperclip, which has been around longer than many people have been Rails developers. Now that Active Storage has been released, Paperclip is being deprecated, creating even more incentive to migrate if you weren’t already considering it.

I recently performed the migration from Paperclip to Active Storage on production. It felt a bit like transferring trains without stopping at a station. You’re setting up Active Storage, replacing the code, and performing a data migration that relies on the code you’re refactoring out from under you. Continue reading …

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.

For a recent client engagement, we were tasked with implementing auto-save on a multi-field form: any time any of the field values changed, we’d save the form to the server. This is a common scenario where users are composing longer inputs, such as emails, word processing, and spreadsheets. Continue reading …

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 …

Preface

To quote Rúnar Bjarnason:

One of the great features of modern programming languages is structural pattern matching on algebraic data types. Once you’ve used this feature, you don’t ever want to program without it. You will find this in languages like Haskell and Scala.

I couldn’t agree more myself. That said, I spend most of my time writing programs with languages that don’t have first-class support for algebraic data types (ADTs). So what’s a programmer to do? 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.

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.