inaka

Latest blog entries

/
The Art of Writing a Blogpost

The Art of Writing a Blogpost

Apr 11 2017 : Matias Vera

/
SpellingCI: No more spelling mistakes in your markdown flies!

Feb 14 2017 : Felipe Ripoll

/
Fast reverse geocoding with offline-geocoder

Do you need a blazing fast reverse geocoder? Enter offline-geocoder!

Jan 18 2017 : Roberto Romero

/
Using Jayme to connect to the new MongooseIM REST services

MongooseIM has RESTful services!! Here I show how you can use them in an iOS application.

Dec 13 2016 : Sergio Abraham

/
20 Questions, or Maybe a Few More

20 Questions, or Maybe a Few More

Nov 16 2016 : Stephanie Goldner

/
The Power of Meeting People

Because conferences and meetups are not just about the technical stuff.

Nov 01 2016 : Pablo Villar

/
Finding the right partner for your app build

Sharing some light on how it is to partner with us.

Oct 27 2016 : Inaka

/
Just Play my Sound

How to easily play a sound in Android

Oct 25 2016 : Giaquinta Emiliano

/
Opening our Guidelines to the World

We're publishing our work guidelines for the world to see.

Oct 13 2016 : Brujo Benavides

/
Using NIFs: the easy way

Using niffy to simplify working with NIFs on Erlang

Oct 05 2016 : Hernan Rivas Acosta

/
Function Naming In Swift 3

How to write clear function signatures, yet expressive, while following Swift 3 API design guidelines.

Sep 16 2016 : Pablo Villar

/
Jenkins automated tests for Rails

How to automatically trigger rails tests with a Jenkins job

Sep 14 2016 : Demian Sciessere

/
Erlang REST Server Stack

A description of our usual stack for building REST servers in Erlang

Sep 06 2016 : Brujo Benavides

/
Replacing JSON when talking to Erlang

Using Erlang's External Term Format

Aug 17 2016 : Hernan Rivas Acosta

/
Gadget + Lewis = Android Lint CI

Integrating our Android linter with Github's pull requests

Aug 04 2016 : Fernando Ramirez and Euen Lopez

/
Passwordless login with phoenix

Introducing how to implement passwordless login with phoenix framework

Jul 27 2016 : Thiago Borges

/
Beam Olympics

Our newest game to test your Beam Skills

Jul 14 2016 : Brujo Benavides

/
Otec

Three Open Source Projects, one App

Jun 28 2016 : Andrés Gerace

/
CredoCI

Running credo checks for elixir code on your github pull requests

Jun 16 2016 : Alejandro Mataloni

/
Thoughts on rebar3

Thoughts on rebar3

Jun 08 2016 : Hernán Rivas Acosta

/
See all Inaka's blog posts >>

/
The King of Code Style

Iñaki Garay wrote this on September 05, 2014 under elvis, erlang, inaka .

At Inaka, we self-select to be people who love what we do. When you love something, you want to do it right. For the programming team, that means that the code you write and work with should be the best possible, within time constraints and team member ability.

We won't discuss the meaning of pure art, the origin of aesthetics, or John Dewey's Pragmatism, but for us, we think code is 'beautiful' when it not only activates the part of your brain that smiles when you look at the Mona Lisa, but also the part that thinks how much technical debt you have to deal with on your next sprint.

That part, the one that knows when an expression, object or module API is "right" because of the far-reaching effects it will have on code maintainability, is born out of experience (and a wee bit of borderline pseudo-OCD). You stop writing god modules after you've had to maintain one. You know when you have one case expression too many when your eyes glaze over looking for the place that variable was bound to its value.

The erlang community is growing, but it's still small. It's sometimes hard to find people that share our viewpoint and can sling erlang code from the hip, so we try and train new hires. This means that sometimes, some of our team members don't have the benefit of 20 years of erlang experience, and make decisions regarding code without even knowing they are doing so.

For these reasons, we've put together a document with the rules and guidelines we follow at Inaka: Erlang Standards (https://github.com/inaka/erlang_standards). We know they are not universal, but we share everything in the hope that it will be useful for somebody. We try to justify the guidelines, so they are more readily accepted without the experience behind the justification.

Buuuuuuuut...

You can't keep a hundred rules in your head when writing code, especially if you're thinking about how to match that record field in this function header. So we wrote a tool similar to Ruby's Hound, and named him Elvis (https://github.com/inaka/elvis), 'cause he ain't nothin' but a hound dog. Elvis comments our github pull requests, pointing out when we stray from our own rules. Not all of them are checked, as some are, ahem, more vague than others. But writing him was really fun, and as he is configurable, we hope he is useful to you too.

Compile it, test it, fix it, rebase it, build it, ship it, mass-deploy it. Code on!