 Your package depends on other packages, and their updates can break your package without you realizing it. We published 

, an elixir package to make testing against multiple versions of dependencies fast and simple. Check out 

 showing exactly how to integrate it into your package.

If you create or maintain an Elixir package, chances are it's built on top of other open-source libraries. You can see this clearly in your 

Surface has extensive tests to catch regressions and ensure features work correctly. But what version of 

, your tests uses the dependencies as exactly defined in in 

So, as Surface evolves, new features, bug fixes and refactors are implemented in surface source code, how do you know it still works with 

A great package stays great by multiple reasons but avoiding regressions or having as few bugs as possible is one of them. The sooner you catch issues, the better, the feedback loop is crucial.

Both potentially could have been avoided.

How to test against multiple versions of dependencies

 to make it as easy as possible to test against multiple dependency versions without manual 

 juggling. Blend is a development-only tool, meaning it won’t bloat your production release.

 (an Nx backend), we realized that testing against different versions of 

 was a real pain. We started building a solution to simplify this process, and then we realized this was a problem the broader community could benefit from.

At first, we wondered whether this wasn’t a common practice because it didn’t feel like a real problem or if the problem was real but we were just missing the right tools to solve it easily.

We believe it’s the latter, so we decided to extract 

, you can define a test matrix covering different versions of 

https://github.com/surface-ui/surface_catalogue

https://github.com/surface-ui/surface_form_helpers

https://github.com/dbernheisel/phoenix_seo

https://github.com/Flo0807/flagpack_elixir

https://github.com/mimiquate/slack_request

https://github.com/mimiquate/tower_rollbar

 to demonstrate how easy is to integrate blend into an existing package. Check out these two different approaches PRs:

 - Add Blend with BLEND env var configuration

Test Your Elixir Package Against Different Versions of Its Dependencies

: We built and open sourced a new Elixir package called 

 that provides Elixir Exception Tracking with many pre-built reporting options available, including E-mail, Slack, local ErrorTracker and popular 3rd party services.

The Elixir programming language is well known for it's easy way of building applications that, almost naturally, can deal with and tolerate faults.

 programs (and in turn Erlang and Elixir programs), by design, run as a collection of small and isolated processes supervised by other special processes called supervisors that act when their supervised processes (children) exit abnormally (mostly restarting them based on different strategies).

However, that doesn't mean that one would want to completely ignore any exception in processes running as part of an Elixir application.

Something goes wrong for one or some amount of processes, they terminate their execution abnormally, and a supervisor takes care of re-starting these with clean state. It is truly great that this mechanism makes your application tolerant to the exception, the fact that it contained, isolated, and that it doesn't bring your whole executing application down.

But you still want to be informed about whatever went wrong, so that you can try at a later point in time, understand, troubleshoot and fix whatever needs fixing, to prevent it from happening again if possible or prevent worse consequences.

So, exception tracking and reporting, I think is still very important for Elixir applications as it is for other programming languages.

When it comes to writing code to listen and be aware of all exceptions occurring in a running Elixir application, it's not as trivial as it can be with other programming languages that are naturally single-process. Writing a simple "try-rescue" wrapper in an application "entry point" won't work, because there is no such thing as a main entry or main function.

Any Elixir application is highly concurrent. Several processes will be started concurrently at boot time by the BEAM VM. Not only the main application supervisor's children defined in the 

 file will run concurrently, but potentially also a several of the dependencies listed in 

, may have defined their own "application" that Elixir will also run concurrently along yours.

 behavior can be enough to handle all exceptions happening in processes executing plug calls, i.e. executing the source code that is responding to web requests, like a Phoenix controller action function. However, it won't be aware of exceptions happening elsewhere, in backgrounds processes like Oban jobs, or any concurrent processes part of your supervision tree or dependencies supervision trees, or even unlinked tasks (with 

) started in a controller function itself.

Whether these omissions are a deal-breaker might depend on each one.

They are for me in most use cases if not all. I won't feel comfortable running an Elixir application in production for which I won't be informed of all exceptions, except the ones I intentionally silenced. I think I'd rather be informed by an error tracker first than by a customer.

A second and more general-purpose approach is implementing a logger handler.

For quite some time, in Elixir, there wasn't a well generalized and solid solution for this, until a substantial change landed in Elixir 1.15 with the 

Details probably deserve their own separate article but in summary it means that one can easily define what is called a 

 and listen to all, or a filtered subset of, logged events in the running applications, which include, among other events, exceptions in processes.

This will listen to any exception "crashing" any running Elixir process.

Raised exceptions that are manually handled (via rescue or catch) by application code or your dependencies code, that aren't re-raised won't actually "crash", so it won't land on the logger, unless the handling code manually sends a log message to the logger including the 

An example of these "silent" exceptions are those occurring inside 

 job execution. For those particular situations, hopefully the library emits 

 events with the exception information, which is the case for Oban. That means that in addition to a logger handler you may need a few additional Telemetry event handlers as add-ons for special cases.

Cool. We found a way to listen to any exception occurring in any concurrent process in the whole running application.

All of the above work to listen to exceptions is, in a nutshell, what 

 does, a package we build for ourselves at Mimiquate and open sourced.

At its core it is a universal Elixir exception tracker, that wraps the exception data into a well-defined Elixir struct called a 

 and passes these along to any number of reporters. So we also say is agnostic to reporting destination, meaning it's not coupled with Exception Monitoring Services, E-mail or Slack or any other.

In order to report to one any number of destinations you can depend on separate Elixir packages that we also wrote and published, or write your own.

Set a few Sentry-specific config settings.

Automatic reporting of exceptions will “just work”.

 anywhere you like in your application code, like so:

You need or want to switch service from Sentry to Honeybadger.

config :tower, reporters: [TowerHoneybadger]

Add Honeybadger-specific config, like setting API Key.

Automatic reporting of exceptions continues to “just work” without any changes.

 throughout your application code unchanged.

You are reporting to Sentry and you want to test ErrorTracker while continuing to report to Sentry.

Follow a few ErrorTracker specific configs.

config :tower, reporters: [TowerSentry, TowerErrorTracker]

Automatic reporting of exceptions continue to “just work” without any changes.

Now you will have exceptions reported to both Sentry and ErrorTracker.

Tower: Universal and Agnostic Elixir Exception Tracker

After eight years of growth and evolution, we’re thrilled to unveil a fresh look for our brand, along with an updated website and a brand-new blog. This rebranding marks a key milestone in Mimiquate’s journey, helping us better communicate who we are today and share more about what excites us—especially the projects and events we’re involved in.

When Marcelo and I first founded Mimiquate, it was just the two of us. Our goal back then was simple: create a brand that looked great online and could be easily shown to potential clients as we traveled to conferences. It was essential that the brand reflected our commitment to adapting to our clients’ needs—something we still prioritize today.

One of the things we loved most was our original mascot, the chameleon. It wasn’t just a fun symbol; it represented our core value—adaptability to our clients. Just like a chameleon changes its colors to fit its environment, we prided ourselves on being flexible and responsive to the challenges and requirements our clients presented. However, as time passed, we realized that while the mascot worked well digitally, it became tricky to use in other formats like print. Logos were more complex back then, but the industry has since shifted towards simplicity.

We took a practical approach to our first website, too. Using a $20 template from an online gallery, we customized it to fit our needs. At the time, it was the perfect solution: affordable, quick, and functional, with a fantastic return on investment for our young company.

As Mimiquate grew, balancing branding with the demands of the business became more difficult. Both Marcelo and I were coding full-time, so naturally, marketing efforts took a back seat. Now, eight years later, with a team of 30, we finally have the opportunity to focus more strategically on enhancing the company’s image.

Our original brand started to feel outdated, especially with the industry trend toward cleaner, more modern designs. What once symbolized our adaptability began to feel too complex. So, we knew it was time for a refresh.

For this redesign, we chose to work with the creators of our original brand, Barbudo Estudio, because of the great experience we had with them before. This time, we wanted a more modern, approachable look that reflects our growth while staying true to our core values.

A key difference with this rebrand is that we involved our entire team in the process. As Mimiquate has expanded, we felt it was important for the brand to represent all of us, not just the founders. The result is a fresh, unified look that we’re all proud to share.

Our rebranding didn’t stop at just the logo. We also set out to completely redesign our website to better showcase who we are today and the work we do. To bring this vision to life, we teamed up with our friends at Purple Bunny, who handled everything from design to copy and implementation.

One of the most exciting aspects of the new website is the launch of our blog. We’ll use this space to dive into technical content, share updates on the events we organize and sponsor—including the Elixir Montevideo meetup—and talk about other company-related initiatives. We’re excited to connect with our community in a more personal way through these posts.

Mimiquate's New Look and Blog

At Mimiquate, we are strong believers in the power of in-person community events. There's something unique about being physically present that fosters unity, collaboration, and shared enthusiasm. Over the years, we have seen how events like ElixirConf serve as the heart of the Elixir community, connecting developers, companies, and enthusiasts alike. That’s why, for several years now, we’ve proudly sponsored ElixirConf—and 2024 was no different.

ElixirConf 2024 – More Like LivebookConf!

This year’s conference had us joking that it felt like "LivebookConf," with so much focus on livebooks and their ever-growing influence in the Elixir ecosystem. But in all seriousness, the event was packed with inspiring talks, groundbreaking projects, and fascinating use cases that show the continued evolution of Elixir and its community.

The keynotes were, as always, the heartbeat of the conference, offering deep insights and new perspectives. Here are a few standouts:

: These two titans showcased how to spin up 

 machines to perform parallel machine learning tasks, leveraging Elixir for a seamless experience. This method, coupled with the power of Livebook, opens up exciting possibilities for data scientists experimenting with new models. The prospect of bringing Elixir closer to the world of data science is an exciting development!

: Theo’s talk brought a fresh breeze to the ElixirConf stage. Coming from the JavaScript community, Theo’s presence was a nice reminder of how valuable cross-community dialogue can be. His talk was personal, yet relatable to developers from all backgrounds, and his insights bridged the gap between Elixir and the wider programming world.

: José never disappoints. This year, he reflected on 20 years of web development history while also looking ahead at what's to come. One of the most intriguing parts of his talk was an experimental project (now archived) that explored syncing frontend and backend changes through database replication, offering an alternative to LiveView that collapses layers in a new way. It was thought-provoking, even if the project was just an experiment.

: Closing the conference with an inspiring talk, Justin Schneck explored the potential of household technology and how we can leverage it to enhance mental health. His message was not only technically impressive but also a reminder of the broader, positive impact technology can have on our daily lives.

Beyond the keynotes, there were plenty of other excellent talks to check out, especially if you missed the event:

: These talks demonstrated the growing versatility of Livebook in experimentation, teaching, and more.

: Guillaume took us through a live demonstration of building out Elixir’s type system. It was fascinating to watch such an intricate process unfold live on stage.

: Chris’s deep dive into working with Materialized Views in Ecto brought some exciting database concepts to the forefront of the conference.

: Their talk on how Elixir developers can engineer their career progression and promotions was both practical and motivating—great for anyone looking to level up their career.

: Wojtek’s session on rapid prototyping in Elixir was packed with useful takeaways for developers looking to get the most out of their projects quickly.

As always, we’re already looking forward to next year’s ElixirConf. It’s such an important event for us, and we plan on continuing to sponsor and support it. I’ll be there with my instant camera again, capturing memories and making new friends.

One thing we hope to see more of in the future is a more welcoming atmosphere for people outside the Elixir community. Bringing fresh perspectives, like Theo’s, is invaluable, and we’d love to see even more diverse voices at these events.

Mimiquate Blog

Tower: Universal and Agnostic Elixir Exception Tracker

Test Your Elixir Package Against Different Versions of Its Dependencies

Tower: Universal and Agnostic Elixir Exception Tracker

Mimiquate's New Look and Blog

Recap ElixirConf 2024