Pete Corey Writing Work Contact

User Authentication Kata with Elixir and Phoenix

Written by Pete Corey on Oct 2, 2017.

It’s no secret that’s I’m a fan of code katas. Over the years I’ve spent quite a bit of time on CodeWars and other kata platforms, and I’ve written a large handful of Literate Commit style articles outlining kata solutions:

Delete Occurrences of an Element

Point in Polygon

Molecule to Atoms

Nesting Structure Comparison

The Captain’s Distance Request

Not Quite Lisp

I’m a huge fan of the idea behind code katas, and I believe they provide valuable exercise for your programming muscles.

We Should be Training

That being said, the common form of code kata is just that: exercise. Something to get your heart pumping and your muscles moving, but devoid of any real goal.

Exercise is physical activity for its own sake, a workout done for the effect it produces today, during the workout or right after you’re through.

Does my career benefit from reimplementing search algorithms? Probably not. How much do my clients benefit from my skill at coming up with clever solutions to contrived puzzles? Resoundingly little. What’s the objective value of being able to write a non-recursive fibonacci sequence generator? Zero dollars.

Instead of exercising, we should be training.

Our focused practice time should be structured around and focused towards a particular goal. To make the most of our time, this goal should be practical and valuable.

Training is physical activity done with a longer-term goal in mind, the constituent workouts of which are specifically designed to produce that goal.

We should be working towards mastery of skills that bring value to ourselves and those around us.

Practical Code Katas

Lately I’ve been working on what I call “practical code katas”; katas designed to objectively improve my skills as a working, professional web developer.

The first kata I’ve been practicing is fairly simple. Here it is:

Build a web application that lets new users register using a username and a password, and that lets existing users log in and log out. Protect at least one route in the application from unauthenticated users.

The rules for practicing this kata are simple: you can do whatever you want.

You can use any languages you want. You can use any frameworks you want. You can use any tools you want. Nothing is off limits, as long as you correctly, securely, and honestly complete the kata as described.

I encourage you to go try the kata!

How long did it take you? Are you satisfied with the result? Are you satisfied with your process? Where did you get stuck? What did you have to look up? Where can you improve?

When I first completed this practical code kata, I was following along with the first several chapters in the excellent Programming Phoenix book (affiliate link) by Chris McCord, Bruce Tate, and José Valim. Copying nearly every example verbatim (and trying to convert to a Phoenix 1.3 style) as I read and followed along, it took me roughly four hours to first complete the kata.

Later, I tried practicing the kata again. This time, I had a rough lay of the land, and I knew vaguely how to accomplish the task. Two hours and many references back to Programming Phoenix later, I finished the kata.

And then I did it again. This time it only took me forty five minutes. I found myself stumbling on a few pieces of trivia (“Where does assign live? Oh right, Plug.Conn…”), but the process went much more smoothly than before.

And I did it again. Now I was down to thirty minutes. I still found myself forgetting small details (remember: *_path helpers live in <YourProjectWeb>.Router.Helpers).

So I did it again, and again, and again…

The Benefits of Training

As I continue intentionally practicing with this kata and others like it, I continue to find more and more benefits. Some benefits are obvious, while others are more subtle.

An obvious benefit of this type of routine, intentional practice of a small set of common tasks is that implementing those tasks in a real-world project becomes as natural as breathing. Even better, if I ever need to implement a task similar to any of my katas, I’ll immediately know where to start and what to change.

Repetition breeds familiarity.
Familiarity breeds confidence.
Confidence breeds success.

Practicing this type of kata has not only improved my ability to know what code I need to write, but also my ability to write it.

As I repeatedly find myself writing and rewriting identical sections of code time after time, I start looking for shortcuts. I start to notice places where I can use new Vim tricks I’ve been trying to learn. I build up my snippet library with generic, repeated blocks of code. I get more comfortable with the nuts and bolts of what I do for a living: writing code.

Final Thoughts

If it wasn’t obvious before, it’s probably obvious now. I love code katas.

That being said, I think we haven’t been using code katas up to their full potential. Intentional, repeated practice of a set of practical, real-world problems can help us greatly improve our skills as professional web developers.

Stop exercising, and start training!

Using GraphQL Schema Types with Apollo Server

Written by Pete Corey on Sep 25, 2017.

Apollo is a beautifully cohesive set of tools for quickly and efficiently building out a GraphQL-powered project. Unfortunately, that cohesiveness can cause problems when you try to do something a little out of the norm.

Recently, I ran into a problem with trying to use traditional GraphQL schema types (like GraphQLObjectType) together with an Apollo-generated schema.

Straight out of the box, these two approaches don’t play nicely together. However, I managed to put together a working, but less than ideal, solution.

Read on!

The Problem

Recently, I’ve been working on an Apollo-powered client project. Apollo schema strings are used to define types and schemas throughout the project.

While working on a new feature for the project, I began using Mongoose to model data living in a MongoDB database. Using Mongoose and GraphQL together meant I had to define two nearly identical schemas.

One schema for Mongoose:

export default new Schema({
    _id: Number,
    name: String,
    roomId: Number

And another for GraphQL:

export default `
    type Bed {
        _id: Int
        name: String
        roomId: Int
        room: Room

From past experience, I knew that having to maintain both schemas would be a nightmare. They would inevitably diverge, either through laziness, forgetfulness, or ignorance, and that divergence would lead to problems down the road.

The solution to this problem, in my mind, was to generate the GraphQL schema from the Mongoose model.

Mongoose Schema to GraphQL

Thankfully, after a quick search I found a Node.js package to do exactly that: Sarkis Arutiunian’s mongoose-schema-to-graphql.

As you would expect, the createType function in the mongoose-schema-to-graphql package accepts a Mongoose schema as an argument and returns a corresponding GraphQLObjectType object as a result.

Armed with this tool, I could replace the Bed GraphQL type definition with a call to createType:

export default () => [
        extend type Bed {
            room: Room

At least that was the dream…

Unfortunately, trying to pass the generated GraphQLObjectType into Apollo’s makeExecutableSchema fails. The typeDefs option in makeExecutableSchema only accepts an array of GraphQL schema strings, or a function that returns an array of GraphQL schema strings.

Trying to pass in a GraphQLObjectType causes makeExecutableSchema to blow up.

A (Less Than Ideal) Solution

Our mongoose-schema-to-graphql package only returns raw GraphQL types, and makeExecutableSchema only accepts schema strings.

Short of forking and extending Apollo’s graphql-tools, it seems like our only option is to convert the GraphQLObjectType returned by createType into a string before handing it off to makeExecutableSchema.

But how do we convert a GraphQLObjectType into a corresponding GraphQL schema string?

export default () => [
        extend type Bed {
            room: Room

The printType utility function in Facebook’s graphql package saves the day!

We can use the printType function to convert the GraphQLObjectType generated from our Mongoose model into a GraphQL schema string which we can then drop into makeExecutableSchema.

Unfortunately, makeExecutableSchema immediately undoes all of that work we just did and converts the GraphQL schema strings it was passed into raw GraphQL types.

Oh well, at least it works.

Coming to Terms

While the createType/printType conversion process works, I wasn’t happy with the solution.

In my throes of desperation, I opened an issue on the graphql-tools project asking for either a better approach to this problem, or support for raw GraphQL types within makeExecutableSchema.

Sashko confirmed my suspicions that there currently isn’t a better way of dealing with this situation. He mentioned that the ability to intermingle these two styles of schema creation within makeExecutableSchema has been requested in the past, and pull requests are welcome.

Maybe I’ll build up the courage to dive deeper into graphql-tools and look for a better solution.

Exploring the Bitcoin Blockchain with Elixir and Phoenix

Written by Pete Corey on Sep 18, 2017.

Earlier this month we dove into the brave new world of Bitcoin development by writing an Elixir module that could communicate with a Bitcoin full node. At this end of the day, we had a small handful of Elixir functions that could retrieve some basic information about the Bitcoin blockchain.

Let’s expand on that idea a bit.

In this article we’re going to use the Phoenix framework to build a bare-bones blockchain viewer. Let’s get to it!

Project Scaffolding

First things first, let’s create our new Phoenix project. We’ll be using Phoenix 1.3 and the new phx generators that shipped with it:

mix hello_blockchain --no-ecto

Once we’ve gone ahead and set up our new project, let’s add two new routes to our application. One for viewing block headers, and another for viewing full blocks:

mix phx.gen.html Blockchain Header headers --no-schema

mix phx.gen.html Blockchain Blocks blocks --no-schema

Notice that we specified --no-ecto when generating our new project, and --no-schema when generating our block and header resources. We don’t be needing Ecto in our blockchain viewer. All of the data we’re rendering lives in our full node!

Our Blockchain Context

When we generated our header and block resources, we also generated a Blockchain context module. Our context will be our interfacing with our Bitcoin full node.

Sound familiar?

That’s because we implemented the Blockchain context module in our last article! Let’s remove the auto-generated contents of Blockchain and copy over the bitcoin_rpc function.

def bitcoin_rpc(method, params \\ []) do
  with url <- Application.get_env(:hello_bitcoin, :bitcoin_url),
       command <- %{jsonrpc: "1.0", method: method, params: params},
       {:ok, body} <- Poison.encode(command),
       {:ok, response} <-, body),
       {:ok, metadata} <- Poison.decode(response.body),
       %{"error" => nil, "result" => result} <- metadata do
    {:ok, result}
    %{"error" => reason} -> {:error, reason}
    error -> error

Be sure to add dependencies on :httpoison and :poison, and set up your :bitcoin_url in your configuration file.

Once we’ve finished that, we’ll add four helper functions to our Blockchain module. we’ll use these functions to fetch the data we want to render with our blockchain viewer:

def getbestblockhash, do: bitcoin_rpc("getbestblockhash")

def getblockhash(height), do: bitcoin_rpc("getblockhash", [height])

def getblock(hash), do: bitcoin_rpc("getblock", [hash])

def getblockheader(hash), do: bitcoin_rpc("getblockheader", [hash])

Now that we have a functional context module, we can start wiring it up to our routes.


Armed with our newly generated block and header resources, let’s add their new routes to our router:

scope "/", HelloBlockchainWeb do
  pipe_through :browser
  resources "/", PageController, only: [:index]
  resources "/blocks", BlockController, only: [:index, :show]
  resources "/headers", HeaderController, only: [:index, :show]

For now, we’re only going to be handling the :index and :show routes for our blocks and headers.

Now that our routes are established, let’s move on to refactoring our controller modules. We’ll start with the BlockController.

We’re going to remove all of our controller functions except the index and show functions, which we’ll heavily modify.

When we hit the /blocks/ route, we’ll fall into the index controller function. We want this function to redirect us to the most recent block in the blockchain:

def index(conn, _params) do
  with {:ok, hash} <- Blockchain.getbestblockhash() do
    redirect(conn, to: block_path(conn, :show, hash))

We use getbestblockhash to get the hash of the most recently validated Bitcoin block, and we redirect the user to the :show route, providing the resulting hash.

Our show controller function accepts the provided hash as an argument, fetches more information about the block from our full node, and finally renders the block using the show.html template:

def show(conn, %{"id" => hash}) do
  with {:ok, block} <- Blockchain.getblock(hash) do
    render(conn, "show.html", block: block)

Similarly, the index function in the HeaderController redirects the user to the :show route of the most recently verified block:

def index(conn, _params) do
  with {:ok, hash} <- Blockchain.getbestblockhash() do
    redirect(conn, to: header_path(conn, :show, hash))

While the show function fetches the relevant information using Blockchain.getblockheader and passes it into its show.html template:

def show(conn, %{"id" => hash}) do
  with {:ok, block} <- Blockchain.getblockheader(hash) do
    render(conn, "show.html", block: block)

There’s one final route we need to implement. When a user hits our application for the first time, they’ll land on the Phoenix landing page. Instead, let’s show them the most recent block header:

def index(conn, _params) do
  with {:ok, hash} <- Blockchain.getbestblockhash() do
    redirect(conn, to: header_path(conn, :show, hash))

Once again, we use Blockchain.getbestblockhash to fetch the most recently verified block hash from our Bitcoin full node. We use that hash to redirect the user to the header’s :show route.

With our routes properly configured, we can fetch data about any full block or block header just by knowings its hash.

Let’s more on to the final piece of the puzzle: rendering that data.


Our blockchain viewer now correctly routes the user to the appropriate :show route for either the block or block header they’re trying to view, and passes all relevant data to the corresponding template to render.

Now all we need to do is build out our templates!

To keep the scope of this article manageable, we’ll keep our user interface as minimal as possible. The more bare-bones way to render our blocks and headers, while still being meaningful to our users, is to render the data received from our controllers as JSON code blocks.

The simplest way to do this would be to dump the output of Poison.encode! into the DOM:

<code><%= Poison.encode!(@block, pretty: true) %></code>

The pretty: true option passed into Poison.encode! ensures that the resulting JSON string is nicely formatted. In our app.css file, we should set the white-space rule on <code> blocks to preserve this formatting:

code {
  white-space: pre !important;


A basic block header.

A bit minimal, but beautiful none-the-less.

While dumping raw JSON into the DOM is informative, it’s not especially user-friendly. Let’s add an extra layer of interactivity to our blockchain viewer.

The blocks and block headers we receive from our Bitcoin full node come with previousblockhash field and (usually) a nextblockhash field. These hashes, as we would expect, point to the previous and next blocks in the blockchain, respectively. Let’s transform these hashes into links so users can easily navigate through the blockchain.

The first thing we’ll do is write a function in the corresponding view file that converts hashes into links. In our HeaderView module, our hash_link function would look like this:

defp hash_link(hash), do: "<a href='/headers/#{hash}'>#{hash}</a>"

Using this function, we can write a function that modifies our block header. It replaces the hashes in previousblockhash and nextblockhash with links to those blocks, and JSON encodes the resulting object:

def mark_up_block(block) do
  |> Map.replace("previousblockhash", hash_link(block["previousblockhash"]))
  |> Map.replace("nextblockhash", hash_link(block["nextblockhash"]))
  |> Poison.encode!(pretty: true)

In our HTML template, we can replace the contents of our <code> block with the result of mark_up_block:

<code><%= raw(mark_up_block(@block)) %></code>

Notice that we’re wrapping mark_up_block with raw. We want to HTML being injected into our JSON to be interpreted as raw HTML, and not encoded as special characters.

After carrying out the same changes in our BlockView and our block HTMl template, cleaning up our layout template, and adding a few final styling touches, we have our result.

A decorated full block.

Behold, the most basic of blockchain explorers!

Final Thoughts

Obviously, this is just the tip of the iceberg when it comes to building a Bitcoin blockchain explorer.

I’m super excited about Bitcoin and development projects related to Bitcoin. If you’ve made it this far, I assume you are as well! If you’re looking for a deep dive into Bitcoin development, I recommend you check out the fantastic Mastering Bitcoin (affiliate link) book by Andreas Antonopoulos.

Expect more updates to this blockchain explorer in the future, and more Bitcoin focused projects. In the meantime, check out this project on Github.