DEV Community: Patricio Cano

AlloyCI - A year since release

Patricio Cano — Fri, 14 Sep 2018 02:15:09 +0000

It has been over a year since I started working on AlloyCI, but today is the one year anniversary from its first public release, and a lot has happened since then.

I would like to tell you more about the project, what motivated me to start it, and what has kept me going since. I would have hoped to release version 1.0 by now, but alas life had other plans. Keep on reading for more...

How everything started

I know I mentioned this on other posts about AlloyCI, but I want to state it again. I started the project as a learning exercise and as a challenge to myself. I heard so many good things about Elixir, but I was happy with Ruby, so I saw no real incentive for me to learn it. That was a mistake. Once you stop learning, you start going backwards as a developer.

The tipping point for me was when I left GitLab. I found myself with a lot of time on my hands while looking for a new job. It was the perfect time to learn something new. I picked up a few books on Elixir, and Phoenix, and started dipping my toes in the water.

After so many years working on just Ruby, Elixir felt familiar, but at the same time it felt like a breath of fresh air, something I hadn't felt since I started learning Ruby back in 2012. The feeling wasn't quite the same, though. Before Ruby I was using Java at university, and only Java, as classes were very much enterprise and industry focused. At that time, Ruby liberated me from the clutches of "enterprise grade" programming. It helped me see that actual joy could be had while developing software, that code could be beautiful, and it showed me a great and welcoming community.

So when I started learning Elixir, it wasn't like being in a dark tunnel for ages and finally seeing the light, like it was when going from Java to Ruby. It felt like going from watching a movie on a regular cinema to watching it in an IMAX theater with digital projection and Dolby Atmos surround sound. Both high quality experiences, but once you experience the latter, going to the former feels like going back to the stone age.

Once I started learning all the great things that Elixir, and the Erlang ecosystem have to offer, and not only that but the incredibly amazing, kind, and helpful community, I knew I had found something special, and that I made a mistake not diving into Elixir the minute I heard about it.

The project idea

If you've read AlloyCI's dev diaries (which I have neglected since the last one I wrote, I know) you know how the idea got started, but if you haven't, here is the gist of it. I wanted to build something bigger than the tutorial projects, and I wanted to see if I could create a worthwhile and hopefully long lasting open source project.

AlloyCI came out of that. I wanted to work on something a bit more complex, but also a bit familiar, so I chose a continuous integration system.

First couple of months

Initial development went pretty quickly and I was able to get a working prototype in a couple of weeks, but it took me almost 6 months to release the first public version, since that was the first MVP, where the basic CI system worked and it looked kind of nice.

Since then, new versions where released pretty often, around once a month for the next 9 months, until v0.7.0 which was released almost 3 months ago.

My motivation was high during that time, which meant coding was easy, even on times where I hit a snag, or things got difficult, that motivation kept me going. Even while I started to get frustrated with my day to day work, my drive to continue working on AlloyCI did not wither.

But motivation can be hard to maintain, and that is the situation in which I found myself at the beginning of the summer. My frustration grew larger, to the point where it started sucking all my will to write software. I needed a break.

Last couple of months

I needed a break from a lot of things, so I took the time. It is important to take care of oneself, so I decided to not pressure myself, distance myself from the project, and only do something if I really felt like it. This approach helped a lot.

In the time since the last release, and until a couple of weeks ago, I barely touched the code, and it was mostly to update dependencies, or Elixir versions.

I regained my motivation at the beginning of the month and started working on a new feature that was on the roadmap. It took me a while to get back in the rhythm, but it was awesome to be back.

I picked up the rhythm again, and noticed a lot of chores that needed to be done, in order to make developing AlloyCI easier, so I did them 😊

Things like adding typespecs to public functions, refactoring modules, improving the way the build traces are saved, etc. I started having fun again.

Present

Interest in CI/CD tools has picked up, specially now that Microsoft announced their entry with Azure Pipelines, so I think it's time to take AlloyCI more seriously, and not just as a hobby project. I would like to make it a worthwhile open source option for CI/CD, and for that I need v1.0 to be out sooner rather than later.

Which is why, with this post, I'd also like to announce the release of AlloyCI v0.8.0. A proper announcement post is coming later today or tomorrow with a detailed description of the changes, but you can already see what changed here: CHANGELOG.md

The next year

Getting to 1.0 is going to be a lot of work. There are a lot of features that are missing, specially surrounding administration, user management, permissions, etc., in short, almost everything that an organization will need to run AlloyCI as a serious development tool. It will take me the better part of the next year to get there, but I am hoping that someone awesome (maybe you) would jump in and help the project grow.

A long time has gone by since the last time I posted a dev diary. I have wanted to document most of the development process, so I will be writing these posts again. I have learned a lot this past year, and I want to share my knowledge with as much people as I can.

These are my goals for the second year of AlloyCI, I really hope I can meet them, and we will be reviewing them soon enough.

For me this year has been full of ups and downs, a couple of more downs than ups actually, but I know it will get better. I am setting goals for my personal and professional lives and also setting a very ambitious goal for this project. To me AlloyCI feels like my baby sometimes, and I know we both will grow stronger this year!

Bonus trivia

AlloyCI was released on September 13th because that is also my birthday. I released it as a present to myself, to show to myself that I could create something great, and to put myself out there. So happy birthday to AlloyCI 🎉 Thank you for this year! 🎉🎊

AlloyCI v0.7.0 released!

Patricio Cano — Tue, 26 Jun 2018 23:02:37 +0000

AlloyCI v0.7.0 has been released! This version includes some major changes. Keep reading for a better description, or go here to checkout the code.

Deprecations

The biggest change for this release is the fact that JSON configuration files have been deprecated. You will no longer be able to use them to configure your AlloyCI builds. From now on you will need a YAML configuration file.

The main reason behind this decision is that YAML is much more flexible than JSON. It allows us to use aliases in oder to avoid duplication, to add comments to make the config file more understandable, and it is the de facto standard configuration file for almost all CI systems in the market.

When I first started writing AlloyCI, my initial intention was to use YAML for the configuration files, but at that time, the YamlElixir library did not support all modern YAML features. A couple of months ago these features were added to the library, but it still lacked proper support for aliases. I decided to see how difficult it would be to add that functionality. Luckily it was quite simple, so now AlloyCI uses its own fork of the YamlEixir library with proper support for aliases.

Furthermore, YAML makes the configuration file easier to write and easier to read. As an example, here is the config file used for AlloyCI in JSON format:

{
  "image": "elixir:latest",
  "services": [
    "postgres:9.6"
  ],
  "cache": {
    "paths": [
      "_build/",
      "deps/"
    ]
  },
  "variables": {
    "MIX_ENV": "test",
    "GITHUB_CLIENT_ID": "fake-id",
    "GITHUB_CLIENT_SECRET": "fake-secret",
    "GITHUB_SECRET_TOKEN": "fake-token",
    "SECRET_KEY_BASE": "NULr4xlNDNzEwE77UHdId7cQU+vuaPJ+Q5x3l+7dppQngBsL5EkjEaMu0S9cCGbk",
    "DATABASE_URL": "postgres://postgres@postgres:5432/alloy_ci_test"
  },
  "before_script": [
    "mix local.hex --force",
    "mix local.rebar --force",
    "mix deps.get",
    "mix ecto.setup"
  ],
  "mix + coveralls": {
    "stage": "test",
    "tags": [
      "elixir",
      "postgres"
    ],
    "script": [
      "mix coveralls.post --branch \"$CI_COMMIT_REF_SLUG\" --name \"$CI_SERVER_NAME\" --sha \"$CI_COMMIT_SHA\" --committer \"$CI_COMMIT_PUSHER\" --message \"$CI_COMMIT_MESSAGE\""
    ]
  },
  "credo + formatter": {
    "stage": "test",
    "tags": [
      "elixir"
    ],
    "script": [
      "mix credo",
      "mix format --check-formatted"
    ]
  }
}

And here is the exact same config in YAML:

image: elixir:latest

services:
- postgres:9.6

cache:
  paths:
  - _build/
  - deps/

variables:
  MIX_ENV: test
  GITHUB_CLIENT_ID: fake-id
  GITHUB_CLIENT_SECRET: fake-secret
  GITHUB_SECRET_TOKEN: fake-token
  SECRET_KEY_BASE: NULr4xlNDNzEwE77UHdId7cQU+vuaPJ+Q5x3l+7dppQngBsL5EkjEaMu0S9cCGbk
  DATABASE_URL: postgres://postgres@postgres:5432/alloy_ci_test

before_script:
- mix local.hex --force
- mix local.rebar --force
- mix deps.get
- mix ecto.setup

mix + coveralls:
  stage: test
  tags:
  - elixir
  - postgres
  script:
  - mix coveralls.post --branch "$CI_COMMIT_REF_SLUG" --name "$CI_SERVER_NAME" --sha
    "$CI_COMMIT_SHA" --committer "$CI_COMMIT_PUSHER" --message "$CI_COMMIT_MESSAGE"

credo + formatter:
  stage: test
  tags:
  - elixir
  script:
  - mix credo
  - mix format --check-formatted

Much cleaner, right?

Also, YAML allows you to use comments in your file, which means that if you have a particularly complex setup, you can leave comments in them to make it easier to understand for people new to the project.

In addition to that, YAML allows you to declare aliases in your file, like a generic part, that can be reused in other declarations in order to avoid extra typing, e.g.:

image: elixir:latest

# This is the generic part we want to reuse.
.docker: &docker
  image: elixir:1.5
  entrypoint:
  - "/bin/bash"

mix:
  # In here he use that generic part, so everything declared there, will be added here
  <<: *docker
  services:
  - postgres:9.6
  stage: test
  tags:
  - elixir
  - postgres
  script:
  - mix test

credo:
  # Same goes for here
  <<: *docker
  services:
  - postgres:latest
  - redis:latest
  stage: test
  tags:
  - elixir
  script:
  - mix credo

# This one does not use the generic part, so it will use the `image` declared in the first line
distillery:
  tags:
  - elixir
  - postgres
  variables:
    MIX_ENV: prod
  script:
  - mix docker.build --tag latest
  artifacts:
    paths:
    - alloy_ci.tar.gz
    - _build/prod/lib/alloy_ci

And AlloyCI is smart enough not to treat elements starting with a . as a build directive, so no build named .docker will be created.

I'm sure using YAML will make AlloyCI a lot friendlier and easier to use.

New Features

This release does not include many new features. The most notorious one is that the status of pipelines and builds will be automatically updated via websockets in their own respective page.

This means that whenever you are in the project view (to see a list of pipelines) or on the pipeline view (to see a list of build jobs) the status of each one will be automatically updated whenever their status changes on the backend. This is accomplished via Phoenix Channels. You can see the changes necessary for this to work here.

Bug fixes

Fixed redirect loop that would happen when an authentication token expires.
Reverted back to Kerosene v0.7.0, as the updated v0.8.0 had pagination bugs.

Thank you for your interest on AlloyCI, and I hope you find this update useful. As always don't hesitate to ask any question, or report any bugs via the issue tracker on GitHub.

Check out AlloyCI v0.7.0! https://github.com/AlloyCI/alloy_ci/releases/tag/v0.7.0

🎉🐣

AlloyCI v0.6.0 released!

Patricio Cano — Mon, 07 May 2018 21:56:39 +0000

AlloyCI v0.6.0 has been released. The biggest change since last release is that it now supports any S3 compatible storage service, in order to store the build artifacts that might have been generated by your project.

This also means that now you can make full use of this feature even in you are running AlloyCI on Heroku.

Check it out! https://github.com/AlloyCI/alloy_ci/releases/tag/v0.6.0

🎉🐣

AlloyCI v0.5 released!

Patricio Cano — Fri, 30 Mar 2018 22:51:24 +0000

Major changes ahead

Photo by Kristopher Roller on Unsplash

This week marks the first year anniversary since the first commit of AlloyCI, and to celebrate it, we are releasing the v0.5 version. With it we get closer to the much coveted v1.0 release, when AlloyCI will be fully ready (and fully supported) for production environments.

This version of AlloyCI comes with a wide variety of changes. The most noticeable being the new and improved design, and support for GitHub Enterprise.

Design Changes

For the past year we have been using CoreUI as the basis of the design. At the beginning, it seemed like a good “admin” template that offered a lot of functionality. Unfortunately it started to feel dated, and bloated pretty quickly. The way it was used with AlloyCI was not ideal and it was not nice to look at.

We decided it was time for a change. The new design feels clean, modern, and is easy to look at.

Some elements remained, like the use of cards to represent the projects, and the use of panels to separate related information:

New projects view

The use of colors to represent statuses also stayed, but with a new pantone:

New pipelines view (single project)

The builds view was completely reworked to better illustrate the different stages of a pipeline, and to give a quick overview of the status of each build within that pipeline:

New builds view (single pipeline)

The single build view also suffered major changes. Now each build has its own page, with dedicated, always visible information about the build on an aside to the left, and the entire build output (which will automatically update if the build is running) to the the right.

New build view

The project settings view did not change that much, but it still looks cleaner and now groups related information more tightly:

Project settings view

New features

GitHub Enterprise

This new version of AlloyCI also comes with a host of new features. The biggest one for this release is support for GitHub Enterprise. GitHub released version 2.13 a few days ago with support for GitHub Apps. This meant that AlloyCI would finally be compatible with GHE. After a few changes to the way the system communicates with GitHub, mainly making endpoints configurable, full compatibility was achieved.

Builds

Builds can now be restarted individually, without having to restart the entire pipeline. The old build data will be kept, and a new job will be created for the new build.

Build Artifacts

The other major new features revolve around build artifacts. With this release we added:

Artifacts can be managed and downloaded from the build view
Expired artifacts will be pruned once a day (or at any configurable interval)
Artifacts can be kept forever, if the user chooses to

Bug fixes

A couple of bugs have also been fixed with this release:

When cancelling a pipeline, all builds were marked as cancelled, now only builds that are either created, running, or pending are updated.
After the upgrade to Guardian 1.0, it became impossible to add another authentication method to an existing user. This has been fixed.

This is pretty much it for this release. The roadmap ahead includes adding S3 bucket support for build artifacts, so that they can be uploaded to services like AmazonS3, or Digital Ocean Spaces. With this support implemented, it will become possible for AlloyCI installations that are hosted on Heroku to also make use of build artifacts, something that is not possible right now.

Until next time! ❤️

AlloyCI Dev Diary — Part 3

Patricio Cano — Mon, 26 Mar 2018 17:17:18 +0000

Project management with GitHub Issues & Boards

Photo by Todd Quackenbush on Unsplash

This blog post is part of a series of posts detailing the development process of AlloyCI. The previous entries have been:

Now that we have started a new project, we most certainly have a lot on our minds about what needs to be done. We might already know where to start, what comes next, and how to get there, or we might not.

If we already know what we want, it makes perfect sense to write it down, give it form, and expand on the ideas and use cases we want to tackle.

If we don’t, then writing down the goals we want to accomplish will most likely light the way. Once we have written the main goal, the next step would be to break it down into smaller goals, and the those goals into smaller tasks that we can accomplish easily.

In both cases, we need a way to keep track of what we need to work on. For a software project, GitHub issues are a great tool for this.

Organization

You can create an issue for every task that needs to be tackled, keep them, organized using labels, e.g. have a label for User related, or front-end related tasks, and to keep a record of your progress.

AlloyCI’s Issue Labels

I have been using them for AlloyCI since early on. The project has different labels to organize different issues, and filter them. Even though, for now, it’s only me working on AlloyCI, having all the tasks that need tackling, and also a history of what has already been done, will really help anyone wanting to get started with the project.

It might seem tedious if it’s only you working on a project to devote so much time to issues, but it will really help. You will most likely be the one that benefits the most once you come back after a few months of not working on the project and see the list of thing to be done. If you hadn’t written them down, you would have most likely forgotten about this tiny feature you wanted to add, that seems unimportant but greatly increases user’s happiness.

Planning

If you want to go a step further and keep track of what issues are being worked on, what their statuses are, and what the next steps are, you can use GitHub’s Issue Boards. The Boards allow you to create columns that represent stages of the development process, like “In Progress”, “Waiting Review”, “To Be Deployed”, etc. They give you an instant visual overview of how the project is progressing.

AlloyCI’s Issue Board

Setting goals

To keep myself motivated I also added milestones to the issues. The first milestone was v0.1, in other words, the minimum amount of functionality needed in order for AlloyCI to actually be a CI coordinator. I set a date for it, as a tentative goal for when I wanted to be done with the first part. I wasn’t able to keep it (I pushed it back at least 2 times and by more than 2 months), but it gave me something to aim for.

AlloyCI’s current milestones

For v1.0 I haven’t set a date, it is an open milestone, because there are some pretty complex issues assigned to it, but I still look at it as a goal. That is where I want the to project to be. It can be in a few months, in can be next year, but I know I’m going to get there.

There are many tools to help you with project management, but for a small team (or a team of one) the tools GitHub gives you for free are more than enough to get you where you need to be.

AlloyCI Dev Diary — Part 2

Patricio Cano — Thu, 22 Mar 2018 23:20:58 +0000

Structuring a new Phoenix Project

This blog post is part of a series of posts detailing the development process of AlloyCI. The previous entries have been:

Part 1: Starting a new Project

If you are coming from a Rails background, you might find the folder structure of a Phoenix project a bit weird, specially after the changes in 1.3. But don’t be put off by this, the structure actually makes a lot of sense, specially the new 1.3 structure.

Unlike Rails, there is no app/ folder where most of your code will live. Phoenix 1.3 projects follow the structure of pretty much any regular Elixir project, this means that most of your code will live inside the lib/my_app folder.

As you might now, Phoenix 1.3 changed the way projects are structured. Before this change most of your code would be under web/, with little to no further organizations. You would have a models directory, where you would put all your business logic, without much consideration as to how they interact together. This folder would get pretty large, pretty fast. Also the name model seems to imply an object, but in Elixir, there are no objects, so storing your data access layer under a folder named "models" makes little contextual sense.

Data & Contexts

Phoenix 1.3, by default, guides you towards a better way of organizing your code. Controllers, Views, Templates go under lib/my_app_web, database migrations and related files go under priv/repo, and the rest of your Elixir code will live under lib/my_app. This is the basic setup, and you can tweak it, and change it as much as you like. You have complete liberty as to how to organize your code.

Since I started writing AlloyCI before Phoenix 1.3 was fully released, some of the folder structure is different than the one the latest 1.3 generators create. I prefer the way AlloyCI is structured right now, because I really don’t like the way they renamed the web/ folder to alloy_ci_web/ and everything inside it from AlloyCi.Web.XXX to AlloyCiWeb.XXX. I really prefer the separation in the module name, and the fact that the app name is not repeated in the web folder name. Thanks to the flexibility Phoenix provides, I don’t need to follow the conventions, though.

Anyways, the most important part about the structure changes, is that Phoenix now guides you towards using contexts for structuring your data access layer.

Using AlloyCI as an example, we have the Accounts context (which is under lib/alloy_ci/accounts folder), where the User, Authentication, and Installation schemas live. These 3 schemas are closely related, and belong to the same business logic, namely the handling of Accounts.

If you look closely at the files under the accounts folder, you will see that there are no functions in the schema files, other than the changeset function. This means that I would need to either go straight through Ecto to manipulate the database data (not recommended) or that I need an API boundary that will let me perform actions on the accounts related schemas.

This is where the AlloyCi.Accounts module comes into play. This module is the boundary with which AlloyCI will interact if it needs to perform an action on any of the schemas related to an Account. All public functions of this module provide an easy way to manipulate the data, while providing security through a layer of indirection.

This is the purpose of contexts. They provide a boundary between your data layer and your business logic, and allow you to have an explicit contract that tells you how you can manipulate your data. It also allows you to stay independent from Ecto.
Let’s say, in the future, you’d like to switch from Ecto to the “latest, coolestDB driver”. If you didn’t use an abstraction layer, like the contexts, you would have to refactor every function across the codebase that used Ecto to communicate to the data layer. But since we are using contexts, we would only need to refactor the code inside the context itself.

Data Presentation

The code that will actually present your data to the user can live under the lib/my_app/web or lib/my_app_web folders, depending on how you want to structure it (the automatic generator will default to lib/my_app_web but I prefer the former).

In here you will find the folders where your controllers, views, templates and channels will live. Let’s start with the presentation layer.

Views & Templates

If you come from a Rails background, you might wonder why there are two components to presenting the data, when in Rails all you need is the views folder. In Phoenix, the “views” are not composed of templated HTML files, but rather they are regular Elixir modules. These modules are there to help you share code with the template, and fulfill a similar purpose as the Rails “View Helpers”, but are, by default, specific to a single controller (other views are not loaded, unlike Rails that loads all view helpers, regardless of the controller being called).

This separation makes it easier to use the same signature on similar helper functions needed to present data (without really overloading them), depending on which controller is being called, thus simplifying your code.

The templates are, then, where your HTML code lives. The template files are saved as *.html.eex files (meaning embedded Elixir), and are very similar to erb files. The syntax is exactly the same, but instead of Ruby code inside, you write Elixir code 😄

A very important distinction between Phoenix and Rails is how you share information between the controller and the template. In Rails, it is enough to declare an instance variable with @something and it will be available to the template/view.
Given the functional nature of Elixir, in Phoenix you need to explicitly pass the information you wish to be available to the views in the render function. These are called assigns. As an example, here is the show action of the PipelineController:

def show(conn, %{"id" => id, "project_id" => project_id}, current_user, _claims) do
  with %Pipeline{} = pipeline <- Pipelines.show_pipeline(id, project_id, current_user) do
    builds = Builds.by_stage(pipeline)
    render(conn, "show.html", builds: builds, pipeline: pipeline, current_user: current_user)
  else
    _ ->
      conn
      |> put_flash(:info, "Project not found")
      |> redirect(to: project_path(conn, :index))
  end
end

Everything that comes after "show.html" are the assigns, so the variables available to the templates related to the show action are builds, pipeline, and current_user. We can see an example of how to use them in this snippet from the pipeline info header:

<div class="page-head">
  <h2 class="page-head-title">
    <%= @pipeline.project.owner %>/<%= @pipeline.project.name %>
  </h2>
  <nav aria-label="breadcrumb" role="navigation">
    <!-- Breadcrumb -->
    <ol class="breadcrumb page-head-nav">
      <li class="breadcrumb-item">
        <%= ref_icon(@pipeline.ref) %>
        <%= clean_ref(@pipeline.ref) %>
      </li>
      <li class="breadcrumb-item">
        <%= icon("github") %>
        <%= sha_link(@pipeline) %>
      </li>
      <li class="breadcrumb-item">
        <%= icon("book") %>
        <%= pretty_commit(@pipeline.commit["message"]) %>
      </li>
      <%= if @pipeline.commit["pr_commit_message"] do %>
        <li class="breadcrumb-item">
          <%= icon("code-fork") %>
          <%= @pipeline.commit["pr_commit_message"] %>
        </li>
      <% end %>
      <li class="breadcrumb-item">
        <%= icon("tasks") %>
        <%= String.capitalize(@pipeline.status) %>
        <%= status_icon(@pipeline.status) %>
      </li>
    </ol>
  </nav>
</div>

Once a variable has been assigned, it is available to the template via @var_name, just like with Rails. Functions defined in the view file of the same name as the controller (in this example pipeline_view.ex) are immediately available to the template. In the above example, sha_link/1 creates an HTML link to the specific commit on GitHub.

Controllers

In structure, Phoenix Controllers are very similar to Rails Controllers, with the main difference being described above. When generated by the helper tools, they will have the same index, show, edit, update, and delete actions as their Rails counterparts. And just as with Rails Controllers, you can define any action you desire by defining a function, and connecting a route to it.

Channels

Phoenix Channels are used to communicate with the web client via Web Sockets. They are similar to ActionCable in Rails, but in my opinion, much more powerful, and performant. In AlloyCI, they are used to push the output of the build logs in real time, and to render a pre formatted piece of HTML code to show the user’s repositories (more on how AlloyCI uses Channels will be discussed in another post).

Routes

Routes in Phoenix are defined in a somewhat similar way as Rails Routes. Some of the syntax is different, but it is immediately recognizable and feels familiar. Have a look at how the project routes are defined on AlloyCI:

scope "/", AlloyCi.Web do
...
  resources "/projects", ProjectController do
    resources("/pipelines", PipelineController, only: [:create, :delete, :show])

    resources("/builds", BuildController, only: [:show, :create]) do
      get("/artifact", BuildController, :artifact, as: :artifact)
      post("/artifact/keep", BuildController, :keep_artifact, as: :keep_artifact)
    end

    resources("/badge/:ref", BadgeController, only: [:index])
  end
...
end

The real difference when it comes to routes, between Phoenix and Rails, is the power that you get when using plugs. We will discuss them in detail in a future post.

And there you have it. That is the basic structure of a Phoenix project. There are other components that we haven’t covered here, like Plugs, or Background Jobs. We will discuss these advanced topics in a future blog post.

On résumés and applying to jobs

Patricio Cano — Fri, 02 Mar 2018 22:29:29 +0000

I’ve been thinking about writing this post for a while, specially after my short stint as a hiring manager for the Service Engineer position at GitLab. What finally notched me was this tweet by Stephanie Hurlburt where she asked her followers if they wanted their résumés reviewed. I realized it made sense to write some advice around this topic, and not just for résumés, but for applying to a job in general. So, let’s begin…

Keep it short

While looking through resumes for the Service Engineer position at GitLab, I came across a high number of résumés that where more than 4 pages long.
It is not necessary to list every single thing you have done in your résumé. List your most proud achievement first (if it’s relevant to the position), and follow up with the most recent positions you have held. Try to keep it single page, 2 pages at most. The people reviewing your résumé have a whole pile of them to go through. It helps if it’s short. I have seen profiles being discarded just because the résumé was too long, and they didn’t even give a glance to it.

Tailor your résumé to each position

It is highly encouraged to tailor your résumé to the company and the position to which you are applying. This way you can showcase the particular skills you already have that match perfectly with the open position. List them first, or close to the top, and add information about projects on which you have worked that are relevant to the requirements.

Personal information should be at the top

Your personal information should be highly visible, preferably at the top of the document, and it should stand out. Use colors to highlight and contrast this information.

Education should be further down

Unless highly relevant to the position, education can go further down. It usually suffices to say the highest degree you have attained, no need to list specific courses and grades, unless, again, it’s highly relevant to the position. In this section you can also list the languages you speak, certificates you have attained, etc.

Add something interesting about yourself

At the very end, add something interesting about yourself. Something that might let the hiring manager relate a bit to you.

Use LaTeX, or InDesign for the layout

Make your résumé shine! There are amazing résumé templates available that you can easily tailor to your needs, so you really outshine the competition. Word has gotten better in later versions, but it still cannot hold a candle to what you can do with LaTeX, or InDesign.

Always submit your résumé as a PDF

PDF, PDF, PDF! It is called Portable Document File for something. It renders pretty much the same way on any machine. A Word, or other word processing document has its own weird way of rendering a document. It will most likely look different in my computer than it does on yours. I might not have the proper fonts, and the layout will get really screwed. This is a no-go. Always submit your résumé as a PDF.

Your GitHub profile is not a résumé

Having a lot of toy projects or tutorial projects on your GitHub profile and submitting that instead of a proper résumé will be detrimental to your application. These types of projects do not showcase your ability to work with other developers, or to grasp complex code, or that you actually have vast knowledge of the framework in which your toy projects are written.

On the other hand, if you contribute to open source projects, in whatever form (documentation, issue triaging, helping people out on the issues or other forums, etc.) now this does showcase your ability to work with other developers, or to communicate complex subjects, or to prioritize. This kind of contributions can be more appealing to potential employers.

Now I know there are great developers that are not able to contribute to open source. If that is the case for you, have some code samples of work that highlights your abilities, so that you can send to the technical interviewers upon request.

Use LinkedIn

A lot of people seem to hate on LinkedIn, but it is a tool that is used by a lot of recruiters. Keep your profile updated, with your latest skills, your latest projects, your education, etc., and you might get job leads just for having a profile. A lot of recruiting software also allows you to pre-fill information on the application form from your LinkedIn profile, so it will save you some time.

Keep it updated!

After you have the perfect résumé, it is time to apply to the job opening, which it’s actually the most important part. No point on having the best résumé ever, if no one will see it.

Write a cover letter

Nowadays most openings require you to write a cover letter, but even if they don’t, you should always submit one. This is your moment to shine! It is a freeform letter in which you get to tell them who you are in your own words. Put some thought into it, and take your time. A great cover letter can be more valuable that a résumé.
Write about what makes you you, what inspires you, what excites you, and tailor it to each specific position. Showcase what you’ve done in a way that is relevant to the open position and makes you stand out.

If possible, have a personal blog

Having a personal blog can only benefit you. It can show your ability explain complex topics in understandable ways, your communication skills, etc. It is also a great indicator that you will most likely be able to write good documentation.

This is feedback that I have gather over the past 4 years of applying to different jobs, from my short stint as a hiring manager, and from watching other hiring managers at companies I’ve worked at. This is just my humble opinion, and should not be construed as professional advice, though. And with that I bid you good luck on the job hunt! 👍

AlloyCI Dev Diary - Part 1

Patricio Cano — Thu, 01 Mar 2018 17:11:03 +0000

Starting a new project

Going by AlloyCI’s introduction post, you would think that the idea to write a CI coordinator came pretty naturally for me, but it actually took me quite some time to find the perfect idea for a new project.

Since the main purpose of starting this new project was to cement my newly acquired Elixir knowledge, I could have chosen something simpler, or even just gone along with the tutorial projects found in all language learning books. Something like a blog management system, a GitHub issue API client, a very simple CMS, etc. But I knew that if I went that route, I would stop adding features to the project as soon as I was done with the book. I did not want that to happen.

I really think that a longer lived, more useful project, will have a more positive effect, than a one-off tutorial project, specially if you try to make something other people might find useful. But here’s the catch: Coming up with something other people might find useful is really hard!

A good starting point is finding a problem that you might have that isn’t quite solved by current offerings. Chances are that more than one person out there has the same problem as you. Now, I’m not going to lie, it is going to take you a lot of time to come up with something usable, but that is part of the fun!

I took me around 3 months until the CI coordinator idea creeped into my head. Before that I thought about re-implementing the omniauth-saml Ruby library in Elixir, but that idea quickly died when I realized that SAML support is almost non-existing in Erlang, let alone Elixir, at least nothing that can compare with ruby-saml and it’s power. Once that idea died, I continued with the re-implementing something idea for a while. I eventually gave up when I noticed that every idea I had to re-implement something, already had a corresponding Elixir project. In hindsight this might not have been the best idea. Even if there is already a library out there, you can always learn a lot by re-implementing it. Your own particular views and opinions can lead you to a better implementation of an existing solution. At the very least you will learn a lot.

The idea to create the CI coordinator came to me, as many ideas often do, while I was in the shower. Clearing your mind and not thinking about a problem is often the best way to find a solution, I have experienced this multiple times in my life. Once the idea “presented itself”, I knew it had great potential. By re-implementing the GitLab CI API in Elixir I would be decoupling its system and liberating the GitLab Runner, making it compatible with other SCM systems. It would give new possibilities to an already great, but locked down project (the CI Runner). The last part was what really got me excited to get started. I could leverage an existing project to build something new, and simplify some of my approach, which would give me a head start, and make it possible to release an Alpha version quicker.

The next day I got started with the basic project layout and did not go to bed until 4 am of the next day 😬

And that is the squick story about how I got started with AlloyCI. Part 2 of the Dev Diary will be about project structure for a new Phoenix project, and the transition between 1.2 and 1.3 that AlloyCI went through before its public release.