Notes from Andrew Hao

Lightweight dependency injection in Elixir (without the tears)

By on in Development, Elixir

In our last Elixir blog post, “Functional Mocks with Mox in Elixir”, we discussed how testing across module boundaries could be made easier by creating a Behaviour for a collaborating module, then utilizing the wonderful framework Mox to substitute a lightweight mock module in tests.

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.

Continue reading …

Comparing Dynamic Supervision Strategies in Elixir 1.5 and 1.6

By on in Development, Elixir


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.

Continue reading …

Taking Elm for a Test Drive

By on in Development, JavaScript

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”.

Elm prides itself on having a low barrier of entry – it can be introduced as a component into an existing web app, so long as your app can provide it a self-contained div. In fact, the creators of Elm strongly advocate taking an incremental approach to introducing Elm into your systems.

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.

Continue reading …

Evented Rails: Decoupling complex domains in Rails with Domain Events

By on in Development, Microservices, Rails, Ruby

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 …

Bring clarity to your monolith with Bounded Contexts

By on in Development, Microservices, Rails

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.

Indiana Jones Rock

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 …

Ubiquitous Language & the joy of naming

By on in Development

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.

I Declare Thee the RideCommerce Service...

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 …

Rails, meet Phoenix: add Phoenix to your Rails ecosystem with session sharing

By on in Elixir, Microservices, Rails

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!

Continue reading …

The 10 Practices of Healthy Engineering Teams – Part 2

By on in Culture, Development, Process, Startups

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).

Continue reading …