#Elixir

Over the past week, I’ve created a couple custom validators for my Elixir projects which use Ecto. Since validators are just functions that take a changeset and return a changeset, they’re very easy to write.

I recently was playing around with Phoenix and Ecto, Elixir’s database library, and I wanted to test my validations. In the process, I wrote a little library along the lines of Shoulda from Ruby. However, when José Valim saw it, he suggested a much better approach which I think illustrates what makes Elixir great.

After a couple months of work, I’ve finally got the library I’ve been working toward for Twilio, and I’m calling it “Telephonist”. You can read all about it over on Github, but here’s a taste:

In my ongoing quest to make Elixir libraries that integrate with Twilio, I found that I needed a lookup table to store the state of ongoing calls in.

In Rails, this table would probably be a Postgres table or a list key in Redis. But before jumping to one of these familiar solutions, I thought, “What does Elixir/Erlang already have that would meet this need?”

In a previous post, I wrote about how to easily get a prebuilt PLT for your Elixir builds on Travis. But what if that doesn’t work for you? What if you have special requirements that my prebuilt PLTs don’t meet?

In my last post, I talked about Elixir’s typespec annotations and Erlang’s static analysis tool, Dialyzer. All that talk was great and all, but how do you actually use Dialyzer on Elixir projects?

Like many Rubyists who read popular coding news, I recently came across the Contracts gem. It caught my eye because it implements some of the features I like in Elixir, but for Ruby.

_This article was recently featured in Elixir Radar. Since it was written, I’ve found a simpler way to implement this kind of Stream. I’ll be writing an updated tutorial in the future, but if you’re interested, you should also check out the current state of ExTwilio.ResultStream._

This past week, as I worked on my new ExTwilio API library for Twilio, I ran into a snag dealing with Twilio’s API pagination.

Twilio paginates its “list” APIs, requiring multiple requests to fetch all of a given resource. However, users of my API library will expect to be able to fetch all of a resource and perform operations on it, like this:

calls = ExTwilio.Call.all
Enum.each calls, fn(call) ->
  # perform some operation
end

Users won’t want to mess with the details of pagination. They want to get a collection containing everything and then operate on it.

I find that there are two basic ways to achieve this, a blocking way and a non-blocking way.

I love how the Elixir build tool, Mix, has built-in support for configuration settings. It makes configuring packages much simpler by providing a standard interface for config settings.

I’m currently developing a Twilio API client for Elixir. While I develop and test it, I need to store an “Account SID” and “Auth token” to make requests. Naturally, I turned to Mix config.

At LeadSimple, we use Twilio to handle phone call routing. Twilio interacts with regular HTTP endpoints on your server to control calls and SMS messages, through a form of XML they call TwiML.

I’ve been toying recently ideas on how to bring next-generation Erlang (Elixir) and next-generation telephony (Twilio) together. Toward that end, I made a little library this week to make generating TwiML from Elixir easy.