To be wrong, even when you’re not

There’s a time when we must assume that we are wrong – even when we are doing the right thing. At my last job, I realized that it was happening with me.

After Nubank, I began to work on a company that, in a way, was a bet in my career – most of the systems in this new company were written in C# (a language that I had never written a single line), there was a huge codebase without a single line of test, the systems did not run on the developer’s machines, and one of the reasons that I was interested in working with then was to organize this codebase, in Clojure, with microservices. Also, to coach the development team, so we would migrate away from monolithic systems to a better architecture, with tests, microservices, and multiple programming languages.

In other words, to apply what I learned at Nubank in this company.

It was a long journey, first to be able to make the code, at least partially, compile on my Linux machine (the default configuration of our development machines was Windows with Visual Studio). And no, there wasn’t simply a matter of swimming against the flow that made me want to work on Linux: it was simply because the mandatory configuration of our Windows workstations was a very slow machine with a very slow antivirus and monitoring systems (to see if anyone was installing pirate software). Also, we had no access to USB, could not download external software, and our antivirus sometimes identified our git blobs as “suspicious software”, effectively corrupting our code every git commit. My machine booted in 10 minutes, and I had to wait another 20 for Visual Studio to be responding (and I’m not faking these numbers).

Then, the migration to Clojure. It wasn’t really that difficult to write the code. The problem was to publish it – the company did not want to use docker, nor containers, nor continuous integration/delivery. We migrated our code from TFS to Bitbucket to GitLab, then to a self hosted GitLab, then back to Bitbucket. Also, we had to fight – a lot – to be able to access our Q/A docker environment, as we had no access to production, staging, or homologation environments. We caught lots of bugs only in production, because we simply had no idea on how the calls for external APIs worked (there was not a single mocked/stubbed external system, and the very few external services that did offer sandboxed environments were so misconfigured that even API versions were different).

Then, after a long fight, more than a year later, we lost.
Continue reading

Posted in Work and Jobs | Tagged , , , , , , , , | Leave a comment

Don’t be a Copperfield

After a year and a half working in other languages, I’m back to Ruby. And, one of the things that I was amazed at Clojure is how simple things were.

Back to Ruby, I’m really surprised on how people overcomplicate things.

There’s no perfect language, nor perfect community of languages. In Clojure, there are fewer abstractions, which is not exactly a good thing – if you, let’s say, just want to create a simple page to show data from a database, you’ll find it extremely tedious to do it in Clojure, where in Ruby/Rails it’s just a few lines of code away. Ruby’s moto is “programmer happiness”, and this reflects in every library that they write.

But this kind of higher abstraction pays off with time. At least where I live, working with Ruby means working with Rails almost all the time. There are no “big competitions” for Rails or ActiveRecord (Sequel is a close one, but at the time of this post, AR have 10 times more downloads than Sequel), and other web frameworks are mostly “Rails-like”. But what bugs me most is “magic”.
Continue reading

Posted in Ruby | Tagged , , , , | Leave a comment

Two new libraries in Clojure

Last week, I was looking to some old code I wrote in my last job and my spare time. Then, I’ve decided to publish two new libraries for Clojure and ClojureScript.

One is Paprika, available in Clojars at version 0.1.0-SNAPSHOT.

The other is Check, also available in Clojars (but at version 0.0.1-SNAPSHOT).

The reason for the early publishing is to push forward some simple libraries to fix a simple problem that I had while working with Clojure: the absence of abstractions.
Continue reading

Posted in Clojure | Tagged , , , , , , , , , | Leave a comment

My frustration with ClojureScript

Last time I worked with Clojure, I was working in a multi-language team, and somebody wanted to do microservices with Node.JS. We already had a library for microservices with Clojure, and I wanted to help then. We did a simple proof of concept where we migrated parts of our libraries to use ClojureScript too, and we did rewrite some tests so things would work correctly in both platforms (even in Node.JS, when we made a “translation layer” for it to work).

Then, I’ve found out how difficult is to test ClojureScript code, and made a bunch of macros to help me test async code, with timeouts and other tweaks. Now, I’m trying to extract this library to be usable for multi platforms.

And then, the headache began:

The Stack

We can use ClojureScript to generate JS for the browser, or for Node.JS. Unfortunately, when we’re trying to generate code for Node.JS, some options need to be added, some removed, and we have a bunch of problems with ClojureScript libraries being exported as Google Closure Compiler libs, in place of Node.JS’ require statement. Also, it’s not really clear how to expose ClojureScript code to JavaScript, as every specific optimization configuration uses some strange code to call functions.

In our experience, :optimizations :simple worked best for Node.JS. :advanced broke our code in ways that we did not understand why, :whitespace doesn’t work with Node.JS output, and other bizarre issues I found. Also, to avoid leaking goog global variable, I used :output-wrapper true, one simple flag for cljsbuild that it’s incredibly difficult to see at documentation.

Then, one of the things I wanted to do is to use the same API for both Clojure and ClojureScript. This means, mostly, that I wanted to re-utilize all code that I could using .cljc files.

And there’s the catch: ClojureScript works really well with .cljc files… unless, of course, you skip the part where macros must be written in Clojure, requires are incredibly different between each platform, and different levels of optimizations give us different results when we’re using cljc and reader conditionals… so, let’s start with the first:

The Macro Problems

Let’s say that I want to write a macro for, let’s say, an arrow for assertion, much like Midje, using some external library. So, instead of saying (is (= "foo" my-str)), I want to be able to say (check my-str => foo). For more information, check my library check (where I used the wonderful expectations library to make my asserts):

; In check/core.cljc
(ns check.core)

#?(:cljs (require '[some-cljs-assert :as assert-cljs])
   :clj (require '[some-clj-assert :as assert-clj]))

(defmacro check [actual arrow expected]
  (assert (= arrow '=>))
     `(is (assert-cljs/assert ~expected ~actual))
     `(is (assert-clj/assert ~expected ~actual))))

Except that this doesn’t work. When we’re compiling for ClojureScript code, this will interpret the file as a Clojure file, so our reader conditionals will try to require different code, and will use the clj version of our macro.

There is a way to tell ClojureScript, when requiring macros, that it’s supposed to use ClojureScript version, but is hacky.

The “Hacky” Version

This would create a macro that, at macro-expansion time, will use the correct version for Clojure or ClojureScript. Except that it doesn’t work correctly too: ClojureScript is very strict about their requires, and while I was programming check, I found that in development mode (no optimizations, figwheel running, etc) it worked correctly. But I also want to be able to run this code on a CI, so I’ve created a cljsbuild profile for test, and that didn’t work: it gave me an error saying SEVERE: : ERROR – required namespace never provided.

The odd thing is that this namespace changed over time: sometimes, it was “cljs.core.async” (that I also use on my library), other times were “expectations”, etc. And the really odd thing is that it only occured when I tried to use :simple optimization, so when I was using, :none, things were working fine.

The really ugly

Sometimes, there’s simply no way to work around these limitations. In my project, I’ve tried multiple possibilities to allow the namespace check.async for both Clojure and ClojureScript. Unfortunately, there wasn’t a single option that I was aware of that made this possible: when I tried to use a cljc file, I had to use the horrible if-cljs macro, and that made Closure Compiler crazy with errors. I had to require specific namespaces for Clojure and ClojureScript, alias then with different names, and even then things didn’t work-I was still getting errors. Then, I’ve just gave up and created a new namespace: check.async-cljs, so that the macros would live in a different clj file.

And yet, that didn’t work either!

Somehow, I was still getting required namespace never provided. To solve it, I needed to create a check/async_cljs.cljs file, and put the following trivial code:

(ns check.async-cljs
  (:require [clojure.string :as str]
            [cljs.core.async :as async]))

Why? Because it informs to ClojureScript that I want to require these namespaces in my ClojureScript file, when I’m using the macros from check/async_cljs.clj. It simply doesn’t matter that I already required these same namespaces, with these same aliases, in my .clj-it’s a Clojure file, and it’s ignored by cljsbuild.

Also, another problem is that when I’m using my check library, there’s no easy way to “require” things in a way that works for both platforms. Again, if I try to (require ' with reader conditionals, depending on optimization level, Closure Compiler will not understand that it needs to add that library to the final JS file.


Although the idea that Clojure and ClojureScript, in a single project, it’s amazing, I simply wouldn’t recommend when there’s a time box to make your project work. Seriously, it’s a lot of work with lots of issues that I simply don’t know why they exist.

Althrough slow, I would probably still prefer a experimental flag on cljsbuild to be able to write macros in ClojureScript. This would probably slow a lot the compilation process, but it’s would make things easier to program. Also, figwheel is an amazing technology, but we need to be aware that it allows invalid ClojureScript code to be compiled and tested, so it’s essential that we always have a cljsbuild profile for testing.

Posted in Clojure | Tagged , , , | 3 Comments

There’s a little Haskell in your Javascript

This may seem a little strange, but althrough Javascript is a dynamic language, with very loose typing (automatic convertions, equals signs that only works on arrays/numbers/undefined/nil), lots of things that are “falsy” by default, with the new promise-based approach of Javascript, the language is borrowing some very interesting concepts from Haskell.

And yes, this is a great thing. And yes, this will probably change the way we program.

Let’s begin by talking about Javascript, and its new features. Old async-javascript code was probably like this:

some_io_function(function(result) {
  find_name_in_db(result.person_id, function(name) {

Now, it’s like this:

  .then((result) => find_name_in_db(result.person_id))

And, with new ES6 features:

async () => {
  var result = await some_io_function();
  var name = await find_name_in_db(result.person_id);

Now, what does this have to do with Haskell? Multiple things, but the most important: Functors!
Continue reading

Posted in Haskell, Javascript | Tagged , , , , , , , | Leave a comment

Stop disrespecting my job!

This will be a bit of a rant-sorry.

I work as a software developer. This means lots of things – the most obvious is that I create and develop softwares. I can’t think of myself as an “IT Analyst”, because I don’t just “analyze” software, and I don’t think of myself as a “Programmer” because I do more things than only program. Also, I don’t like my last two job titles “Software Engineer”, mostly because I associate Computer Engineering with calculus and digital signal processing and neural networks and such. Also, I think that here, at Brazil, people like the “Engineer” status, and I’m don’t care for titles and such – I’m interested with knowledge and abilities more than anything.

That being said… when I search internet to find a job, most of the time we find: “We’re searching for computer Jedis/Ninjas”; “If you’re a master of the computer arts, please apply for…”; or the innocent looking “we’re not looking for someone to work, we’re looking to someone to have fun with us while we create a great product”.

Okay, let’s start by the beginning: I am a professional Software Developer looking for a job. This needs to be clear, and it’s nothing better or worse than that. I’m not a Jedi – sorry to be the one with the bad news, but Jedi doesn’t exist (sorry UK). Ninjas do exist, but their primary concern is not softwares… and yes, I studied a little of Ninjutsu (Bujinkan school) as a martial arts, but I’m no ninja (I did not graduate a single time).

We spent years trying to get rid of the title computer boy. Why do we, now, allow ourselves to be called of something we are not? Just because it’s cool to be a Jedi or a Ninja?
Continue reading

Posted in Divagações | Tagged , , , | Leave a comment

Clojure, reflection, and performance/memory issues

Right now, I’m working in a game project in Clojure. I don’t really know how it will turn out, but for now I’m just trying to learn a better way of making games.

While working in this project, I found out that my game was consuming a lot of memory. I’m using play-clj library, and I know that it creates a lot of small objects for each render cycle, so that was my first guess.

So, I plugged in a VisualVM in my running game to understand what was happening. In the beginning, nothing seemed to make sense: the heap grew, then was released, the correct and normal cycle of any Java application. Then, I tried a memory profiling and a memory dump. Then, things became interesting.

There were a lot of float[] objects popping up, as I would expect – play-clj uses floats to position elements on the screen, and all the time I found myself trying to coerce doubles to floats. But there was something even stranger there was consuming a lot of memory: instances of java.lang.Method.

For those who don’t know, Clojure interoperability with Java relies on reflection when it can’t resolve a type. To resolve a type means that Clojure can be certain that, at run time, that a specific identifier will be a specific type. So, for the following code:

(ns example.core)

(defn sum-abs [a b]
  (Math/abs (/ a (float b))))

(defn only-abs [a]
  (Math/abs a))

The first method call will use reflection because it knows that the result of a sum will always be a float. The second one has no idea if it will be called with a number or not, so it relies on reflection. It may seem strange, as we’re calling Math/abs, but remember that in Java we can have different methods with the same name, differing only on type signature.

So, to resolve the type, we’ll need type hints. But first, we can test if our code is using reflection using lein check.
Continue reading

Posted in Clojure | Tagged , , , , , | Leave a comment

We need a better way to write SQL

For some time now, we’ve been working with SQL to communicate with database systems. What we learned in these years is that SQL is not a good way to query data, and I’m going to explain why.

SQL should be a standard way of querying data, but most programmers have learned (probably the hard way) that most of databases implement SQL in a different way. What is means in practice is that any time we need to change databases we will face lots of incompatibilities and queries that simply won’t work as we expect. But this is only the beginning of our problems…

We tried lots of ways to solve this kind of problem, one of them migrating to ORMs. But, ORMs in fact solve a different problem – the one that relational databases work with row-column structures, and our programming languages use objects, hash-maps, records, and other richer ways of representing data. Ruby’s ActiveRecord was a huge step forward, promising us to deliver value simplifying our relational-object mapping, but in the end we faced the same problems – incompatible queries, SQL fragments being thrown in the code, and in the end, we ended up with another huge kind of problems – performance, complexity, and separation of concerns problems (a single ActiveRecord mapping is responsible for validation, for queries, and to define business logic). Even worse, the Arel promise (a complete library to abstract every possible SQL query) was underused – it’s now an internal library to ActiveRecord, it doesn’t really have a stable public API, and in every minor version, something changes in a bizarre and incompatible way.

So, I’ve started a simple project named relational. In the beginning, it was just a playground to learn Scala. But, right now, and faced with modern problems (I’m working with Clojure, and it doesn’t really have a good way to query relational databases – Korma is incomplete in multiple ways, HoneySQL doesn’t really delivers what I want, and other libs are just wrappers around string queries), I’m implementing a version of Relational in Clojure, and the reason I’ve started working on it is kinda simple…

SQL isn’t a standard.

Okay, if we just want to query all data from a single database, inner-joining with other, just listing the fields, it’s completely fine. Add SQL functions and pagination, and we’re in a pinch – for instance, the standard way of limiting the result to just 100 rows is:


I don’t know a single person who wrote this kind of query, simply because almost no database supports the standard – in PostgreSQL, MySQL and Sqlite, it’s written as:


In Oracle, it is

SELECT * FROM table WHERE rownum < 100

In Microsoft SQL Server, it is

SELECT TOP 100 * FROM table

And don't even start with GROUP_CONCAT or other strange SQL functions…
Continue reading

Posted in Banco de Dados | Tagged , , , , , | Leave a comment

Atom Packages with ClojureScript

One of the best things in Clojure (and ClojureScript) is that you can design your code connected in a live environment – so, your auto-complete abilities reflect exactly what’s running right now. Then, you can evaluate code with real data, to catch bugs or just test things. Then comes Atom, an editor that, in my opinion, is one of the easiest editors to create plugins (packages), using technologies we already know – mostly, HTML, CSS, and JavaScript. To program with Clojure, you can use proto-repl – an awesome package that, combined with ink, allows us to run clojure code and display right on the editor, Light Table style.

But then I became greedy and wanted more. I created clojure-plus, a package that extends proto-repl to be able to work with multiple projects, specially when these projects are not configured to be “refresh-friendly” or something. Most of the things I have in clojure-plus are simple helpers that I found missing in proto-repl, at least in the beginning.

But, after that, I began to work professionally with Clojure. And then, most of the projects had some kind of “strangeness”, mostly because everyone was using InteliJ with Cursive – a lot of people I knew didn’t even run the code, with exception of midje tests. So, I changed my package to work around these “strangeness”, and after a while, I saw that I was creating a big mess of code. Then, came ClojureScript support, and things became even more complicated… so, came the idea to port my package to ClojureScript, and after trying several things (Figwheel, Ajom, and other packages) I discovered that they could not solve my problems. The only one that worked, with restrictions, was Weasel, but then with some hacks things worked fine. So, here are the steps to make things work:
Continue reading

Posted in Clojure | Tagged , , , , , , | Leave a comment

Mudanças no Blog

Esse será um post rápido sobre pensamentos aleatórios e alguns desabafos.

Nos anos que tenho esse blog, percebi que as coisas não são fáceis para quem quer trabalhar seriamente com desenvolvimento de software. Primeiramente, o mercado brasileiro ainda é muito atrasado e engessado nos antigos paradigmas – analista, desenvolvedor, e testador são papeis diferentes nesse cenário. Além disso, é difícil achar uma empresa que pense seriamente na idéia de usar linguagens não tradicionais. Hoje em dia, eu trabalho com Clojure. Sou uma minoria. E por um tempo, eu achei que uma boa parte dos programadores era como eu – queria programar em linguagens diferentes e divertidas, tipo Haskell, LISP, etc – mas não conseguia.

Hoje em dia, percebo que sou uma minoria que quer estudar. Na verdade, a maioria dos programadores está, literalmente, pouco se lixando pra tecnologia. A percepção disso me assustou um pouco, e confirmou como estavam sendo infrutíferas as coisas que eu estava fazendo – vídeo-aulas que enviei para pessoas e não tive feedback nenhum, plug-ins de Atom, estudos de Clojure, etc. Até uma boa parte das postagens aqui no blog acabaram caindo nisso. Somado ao fato de que o Brasil está um lixo – e não vou “açucarar” as palavras agora, pois sofremos com assaltos diariamente, as pessoas estão também pouco ligando pro que acontece no dia-a-dia, todo mundo está vivendo sua vida sem se importar com os outros, e a hipocrisia cada vez mais crescente das pessoas que pedem o fim da violencia mas a defendem quando podem – acho que é hora de cortar alguns laços com esse país, e um deles é esse blog.

Eu não vou acabar com ele. Mas, a partir de agora, as próximas postagens (e possivelmente algumas antigas) serão em inglês. Não vou deixar o blog multi-idioma – isso daria trabalho demais e, sendo sincero, já deu pra perceber que o Brasil está simplesmente desistindo de ser uma nação. Isso só aumentou ainda mais minha vontade de morar fora do país, e um blog em inglês possivelmente me tornaria mais conhecido também.

Então, esse é o último post em português. Possivelmente, terei um domínio próprio também, mas isso ainda não está decidido. Então, so long and thank you for all the fish.

It’s time to grow up, people! This country can’t live in its infancy for all eternity.

Posted in Divagações, Quick Post | Tagged , , | 4 Comments