T* About

trivelop

{:ok, "Let's ship it ..."}

Looking back at 2017

I think it’s save to say that 2017 has been the most eventful year of my adult life.

Leaving Neopoly after 16 years of being with the company was one of the biggest decisions I ever made. It’s always hard to move on, but this has been a very special goodbye. On January 2nd, I started working at 5Minds.

In February, I finally handed in my dissertation. After 2 years of preparation and 4 years of researching and writing, this was a very special moment, parting with 400 pages that changed my life.

I’ve always been more interested in the practical side of things, both with computer science and economics. But being more interested meant a 60/40 split, where I am still very much an academic at heart. Being able to go to university next to my day-job and, over the course of 7 years, get a degree has always been a privilege to me (I got my Diploma in 2011). I feel blessed that I subsequently got the chance to work on a research project of my choosing to get a PhD as well.

ElixirConf.EU was a blast this year. It’s been a great experience, rekindling old Elixir friendships and forming new ones. As always, it’s been great to meet people from the community.

It made me tremendously happy to see how the community embraces the same principles and I am still proud to contribute something back by maintaining Credo, ElixirStatus and ElixirWeekly

In June, I had the honour to marry my partner-in-crime, Julia ❤️

In July, I took the final oral exam for completing my PhD. As I am writing this, I still haven’t fully proccessed the fact that my formal higher education, a journey I started when I was 20 years old, has come to a close.

In October, got the opportunity to represent 5Minds at this year’s RuhrJS.

The year came to a close in December with a very special request from Argentina: I became a SpawnFest judge.

I am with 5Minds for a whole year now, getting used to my new role as a software architect and teamlead. Leading teams of developers, instead of writing code full-time myself, is a great challenge. And I mean “great” both in terms of size and feeling of accomplishment.

Do I miss writing code? Sure. But working with people next to bits and bytes is a new and exciting task. This job finally combines my previous engagements - being a programmer, designer, part-time student, later part-time teacher, public speaker and author - all into one.

Also, I am going from speaking to organising: My colleague Marc and I are organising a .NET Core user group, .NET Developers Ruhr, which will meet in February for the first time.

In conclusion: What a year. I am exited for the next one! 👏

ElixirStatus is 2 years old!

ElixirStatus is two years old now. 🎁 🎉

This was my first “complete” Phoenix project, and while it is a trivial app, I am still amazed how it keeps running, humming away like an old diesel engine, doing its job for those who find it useful.

When ElixirWeekly celebrated its first birthday a couple of weeks ago, I wrote:

The Elixir community is growing and, while some would like to see an explosion in popularity akin to JavaScript, I really like to watch the steady but unstoppable progress we are achieving together.

All the tools are maturing, getting better, gaining focus and, while all the numbers are growing, the community is staying healthy and solving real problems in the real world using our favorite programming language.

Wow. It’s been a whole year. Time has flown.

It’d like to emphazise the same for ElixirStatus and give some numbers as well:

  • Twitter followers have grown to > 4,000 Elixir programmers
  • There have been 700 postings to the site in 2016/17 (vs. 600 last season)
  • With 100 new first time authors of posts

Another observation: Lots of people are subscribing on Twitter and then unsubscribe a week later. The dense information flow ElixirStatus has to offer is special in that you get a raw feed of new projects and ideas from the community. It is understandable that this kind of tweet stream can be overwhelming, annoying even.

ElixirStatus is not for everyone and that is ay-okay! But despite this quirkiness, the community still managed to double its reach. This is great, because this means the interest in Elixir is growing.

Not with the kind of stratospheric JavaScript-like growth some had hoped for, but rather a healthy, sustainable rate to grow the Elixir community around the right ideas and problems.

I’m proud to be a part of this.

Wow. It’s been two years already. Time has flown indeed.

Credo: How Config Comments work

As of v1.4 of Elixir the compiler will warn you when you declare an unused module attribute. Unfortunately, this is also the case for @lint attributes.

# BEFORE: using @lint attribute to disable Credo
#         for an entire function

@lint false
defp do_stuff() do
  # ...
end

With the release of Credo v0.8, there is a new comment-based syntax. This will get rid of the compiler warnings. Also, you will be able to disable specific lines or entire files for all or only specific checks with this syntax.

# AFTER: use config comment to disable Credo
#        for the exact issue you want to ignore

defp do_stuff() do
  # credo:disable-for-next-line
  IO.inspect {:we_want_this_inspect_in_production!}
end

There are four config comments available:

  • credo:disable-for-this-file - disables Credo for the entire file, no matter where the comment is put (so you can put it somewhere it doesn’t bother you too much)
  • credo:disable-for-next-line - disables Credo for the next line
  • credo:disable-for-previous-line - disables Credo for the previous line
  • credo:disable-for-lines:<count> - disables Credo for the given number of lines (can be negative to disable previous lines)

Disabling specific checks

Each of these can also take the name of the check you want to disable:

defp do_stuff() do
  # credo:disable-for-next-line Credo.Check.Warning.IoInspect
  IO.inspect {:we_want_this_inspect_in_production!}
end

Lastly, you can put a regular expression (/.+/) instead of a check name to disable multiple checks (or if you do not want to type out the checks):

defp do_stuff() do
  # credo:disable-for-next-line /\.Warning\./
  IO.inspect {:we_want_this_inspect_in_production!}
end

Some Batteries NOT included …

There are two features which are not supported with this new syntax:

  • Let you put config comment at the end of a code line
  • Let you disable Credo at a specific line and re-enable it later

The reason for the first is that comments should be on their own line (except for things like defstruct, see Credo’s Style Guide).

The reason for the second is that people should not get used to regularly disabling Credo for large parts of their code (with the obvious exception of excluding entire files like third-party code).

Credo has always been good at rethinking seemingly tried-and-true mechanics. But: It can only get better at this through feedback. We have to reflect both the raised issues and the status quo.

While disabling Credo for a specific range of your code might seem useful, we have to ask ourselves if that is really what we want. Instead of giving people the means to silence these issues, we have to encourage them to “complain” and file a bug report with the Credo project on GitHub.

One more thing …

I would really like to thank all the contributors who make these releases possibly. Credo is very much a community effort and I applaud each and every one of you for being an active part of the Elixir community.