I’d argue Elixir has relatively few gotchas. It’s a simple and consistent language and when you first learn it there’s only a few things that are genuinely counter-intuitive and catch you by surprise. One of the examples could be the difference between binaries and charlists and why iex sometimes seems to do weird things to your lists: iex> l = [19, 7, 16, 119, 97, 116] [19, 7, 16, 119, 97, 116] iex> Enum.drop(l, 1) [7, 16, 119, 97, 116] iex> Enum.drop(l, 2) [16, 119, 97, 116] iex> Enum.drop(l, 3) 'wat' One of the other ones comes when you start working with atoms and get a little too trigger-happy with them. What you could hear from your more experienced teammates is something like this:

Earlier this year I presented my latest project - Hoplon - at the London Elixir meetup. I’m thinking of putting some more work into it over Christmas, so I figured I might gather the materials about it in one place: Hoplon is an Elixir developer tool that helps you validate your dependencies contain no hidden malicious code. Motivated by horror stories from the JavaScript community such as this hypothetical one and this very real one.

Towards the end of November I gave a flash talk at the London Elixir Meetup. This time I was talking about the journey from println debugging to proper tracing and bringing Erlang tools to Elixir programmers. You can watch the talk here: …and here are the slides: The resulting Rexbug project is ready to be used but there’s still some issues I could use some help on - some should even be suitable for Elixir beginners.

Last year, I saw José Valim give his keynote at the ElixirLive conference in Warsaw, where he talked about the motivation for his new Elixir libraries: GenStage and Flow. Even though I heard about those before, it was the keynote when I “got” what the libraries were good for and why they were neat - and I decided to play around with them.

July 2019 update: # I have since moved to neovim for all my Linux/OSX work, and I’m very happy with it. The information here is probably very outdated, but I’m leaving it here for posterity You can see my neovim configuration in my dotfiles Earlier this year I joined Mainframe as a backend engineer. I didn’t do any real development in elixir before and I wanted to become productive with it ASAP. When it comes to elixir there were some good books to help me understand it better, but I also needed an editor or and IDE that would give me the necessary tools without getting in my way.

I’ve been a semi-active board game nerd for quite a while now and I find myself playing a wide variety of games, ranging from Jungle Speed to Battlestar Galactica and go. Board games are a huge universe to explore, but there’s been one game that me and my friends have been playing for years now and it’s still a crowd favourite. It can accommodate virtually any number of players, it’s cheap (all you need is some dice), simple to explain, and - last but not least, drunk-people-friendly. If you can still count, you can still play and even if the table is all covered in beer, the dice couldn’t care less.

I spent the last three months in Dublin, on an internship with Microsoft. The experience was great and I could recommend it to anybody, but that’s not what I wanted to talk about this time. Whenever you move from one place to another there’s a certain amount of know-how that makes your new life easier/better/more predictable and that knowledge usually comes with time. By the end of my internship I felt at home in Dublin and now I’d like to share some tips with you.

In the last three months of the last year I had the pleasure of taking part in an online machine learning course, taught by prof. Andrew Ng of the Stanford University. The course is already over, so it might seem old news, but next edition should start any time now. If the topic of machine learning seems interesting to you in any way I can really recommend it.

For my classes I recorded screencasts about TDD, and, because lately I’m focused mostly on c++, I decided to dive into google test instead of the regular jMock and Mockito. Initially I wanted to make it a tutorial showcasing all the tools within the library, but it ended up being a TDD Kata solving example with a short introduction about how to set up the development environment.

This thursday, in the lecture hall of the Biology Departament of University of Warsaw, Google organized a meetup with their engineers, celebrating the official launch of their new office in Warsaw. The event started with Joshua Bloch’s, lecture, which was a treat for the attendees, most of whom were MIM UW students, almost filling the room. Joshua presented code snippets that don’t do what you might expect them to, by invoking constructs that may lead to unforseen behavior. Majority of those constructs weren’t Java-exclusive and could have been presented in C++ or even python. The well known issues were covered, e.g. String comparison, operator precedence, working with floating-point variables, implicit conversion. But there also were topics I haven’t ever thought about, like regular expressions that match same patterns but differ hugely in their efficiency.