Fetch Issues from GitHub

We’ll want to organize our source code, write tests, and handle any dependencies. And we’ll want to follow Elixir conventions because that way, we’ll get support from the tools.

In this chapter, we’ll look at Mix (often mix in code), the Elixir build tool. We’ll investigate the directory structure it uses and see how to manage external dependencies. We’ll end up using ExUnit to write tests for our code and to validate the examples in our code’s documentation. To motivate this, we’ll write a tool that downloads and lists the n oldest issues from a GitHub project. Along the way, we’ll need to find some libraries and make some design decisions typical of an Elixir project. We’ll call our project issues.

Fetch issues

GitHub provides a nice web API for fetching issues. We simply issue a GET request to https://api.github.com/repos/user/project/issues and we get back a JSON list of issues. We’ll reformat this, sort it, and filter out the oldest n, presenting the result as a table:

#	created_at	title
889	2013-03-16T22:03:13Z	MIX_PATH environment variable (of sorts)
882	2013-03-20T19:22:07Z	Enhanced mix test --cover
893	2013-03-21T06:23:00Z	mix test time reports
898	2013-03-23T19:19:08Z	Add mix compile --warnings-as-errors

How will our code do it?

Our program will run from the command line. We’ll need to pass in a GitHub username, a project name, and an optional count. This means we’ll need some basic command-line parsing.

• We’ll need to access GitHub as an HTTP client, so we have to find a library that gives us the client side of HTTP.
• The response that comes back will be in JSON, so we’ll need a library that handles JSON too.
• We’ll need to be able to sort the resulting structure.
• Finally, we’ll need to lay out selected fields in a table.

We can think of this data transformation in terms of a production line. Raw data enters at one end and is transformed by each of the stations in turn.