My Year in: Investing

The year of 2015 was the very first full year I spent invested in securities. Rather than imitate the pros by starting to write publicly about my performance when I get good, I decided it would be more productive to begin right away.

Since these are personal figures, instead of revealing actual money figures I chose a more important measure of the worth of money to me (and I suppose to most non-rich people): months of life in current regular living conditions.

Expressed in months of living expenses, my total savings at the end of 2015 are at about 3 to 4.

Performance in securities was -41% for the year.

Overall savings variation was -2.2% for the year. The only redeeming in overall performance when compared to securities was brought by operating profits (as they call it: working, getting paid and not spending it all).

I adhere to my ever improving version of Ben Graham’s investment philosophy, with added knowledge from numerous other people, namely Buffett, Munger, Klarman, Marks and Parisotto. Therefore it may not be surprising to learn that total number of transactions this year was three. All of the three were purchases, going long 2 different companies. No leverage was employed.

It’s hard to look at a dip of 41% and not think you’ve made mistakes. So let’s get to them: the first one was buying into a company with high debt-to-equity (0.71 at the time), Petrobras. Prudence says don’t touch anything above 0.5, even though it’s easy to spot companies at 3 and greater. I actually built the position in Petrobras in late ’14. As an unprecedented sequence of bad things was uncovered in and around the company, and the Real lost a lot of value, Petrobras’ debt-to-equity more than doubled to 1.57. Talk about ignoring a margin of safety. The price of the stock didn’t fall quite as much this year, 11%.

All the other companies in the portfolio, which also dropped in value, belong to mining or steel. None seemed too burdened by debt, and I believed I had purchased them at a low enough valuation, but their usually long cycle still had a far deeper bottom awaiting them — and that’s assuming we touched bottom at all.

When there are so many companies costing one tenth to one fifth of what they did just two years earlier, as is the case now in Brazil, opportunities are likely to arise. While staying cognizant of the opportunity cost incurred, and my limitations in selecting and analyzing stocks (working on it), I continue to see things in at least a 3-to-5-year perspective, and remain quite optimistic about the current portfolio and possible new additions next year.

Notes on deploying Webpack in a Phoenix application on Heroku

As of today, there’s no Heroku buildpack specifically built for deploying Phoenix and Webpack. Having found no consolidated place to learn how to do it, here’s what I did.

First, make webpack run in your local environment. This link explains it well.

Make sure to comment out /priv/static in your .gitignore file.

If you haven’t, add the following buildpacks to your heroku deploy.

# Set the buildpack for your Heroku app
heroku buildpacks:set

# Add this buildpack after the Elixir buildpack
heroku buildpacks:add --index 1

Add a file called compileto the root folder of your app, and add the call to webpack:

ENV=production node_modules/.bin/webpack

Note that ENV=production is optional and should relate to your webpack configuration.


My Year in: Books

In a sense, my year of reading turned out surprisingly well. On January 11th my first daughter was born. I thought I wouldn’t read anything at all for a long time. That did not turn out to be true.

I only started jotting down what books I read two years ago. And I did it only because I was reading them on a computer, right by some note-taking app. This is the third year I do it. In the previous two years, my average had been 35 books read per year. At my current pace, by the end of this year I’ll have read 25 books. This is not counting, on any year, children’s books. Last year I spent a weekend at the home of Brazil’s most prolific children’s writer, Ziraldo (he rents out his beach home in Ilha Grande), and must have read at least 40 of his books in half an hour. I also exclude programming books from my personal stats.

Looking at the broad subjects in the list, it’s pretty clear I was interested in the human mind — a third of the total. Straight psychology accounts for 5 books, or about 20% of the total.

I read Lacan’s first seminar, which is largely about Freud’s writings on psychoanalytical technique, and it was one of my favorites this year. It’s a transcription of his seminars, so it’s apparently disjointed, which mimics the analytic speech so perfectly. What stayed with me is a clear message of being open to human contradiction, which is usually immense – and much of other people’s contradictions are nothing but our own lack of capability to understand their coherence.

Lacan’s book made me very curious about Freud’s Papers on Technique, which I read some time later. There’s a lot to learn in those 60 or so pages. One long-standing question of mine which they answered: what happens right after the analytical act? Is there synthesis? What is the role of the analyst in that moment? He explains that the analyst is largely incapable of interfering, at least with any guarantee of a positive influence, and that the mind reorganizes itself immediately, according to its own previous experiences and predispositions. This is mid-career writing for him, so he may have revised that later. I mentioned all that to my own analyst and she, characteristically, didn’t answer anything.

Another towering highlight of my reading year was Making the Modern World: Materials and Dematerialization, by Vaclav Smil. The book is an extensive compendium of the historic use of all kinds of materials, from all kinds of metals to sand and gravel, to hydrocarbons and polymers. That work is where you’ll find the first reference to the fact that China used more concrete in the first decade of this century than the U.S. in the entire 20th century. Also, I learned that the world market for sand, something you pretty much just find, bag and sell, is larger that the world market for fine art, a field in which I spend many of my finest but least financially rewarding hours.

I don’t count the books I start and don’t finish, but it’s possible to estimate the books I finished and won’t remember or already forgot I ever read. My guess for those is 5, or about 20% of the total. Yes, I did read a book by Alain de Botton, and I regret that.

All things considered, an understandably below-the-average year for my reading, more than offset by my becoming a father.

Another way I keep track of my reading is via Goodreads. Do friend me there if you’d like.

My Year in: Software Development

Just like those lists of best albums and books of the year, I’m writing this almost a month before 2015 ends, this time with a compelling reason: I just took time off from writing software until the end of December. And this may be the fact of the year in my life as a software developer, if you consider I hadn’t taken time off in about 3 years and about 25 days of vacation, total, this decade.

But let’s start from the beginning: in January this year I was deep into a startup project that I had started from scratch 14 months earlier. To give you an idea of the difficulty in launching a startup, I am informed that the startup in question has not been launched yet, even with some very competent people working on it.

I had helped specify the product from day one, focus the scope, personally drew wireframes, recommended and was working with the design team, had picked the technology for the backend (Ruby on Rails), had helped hire and was working together with 4 programmers developing the web, iOS and Android apps for the MVP.

The MVP was and is quite ambitious in scope. Fortunately, the founder and funder is a patient, experienced businessman (although this is his first digital venture) able to keep at it for over 2 years.

At the beginning of the year it was getting clearer to me I had to be working on a subject which I felt more natural affinity for. I was learning a lot about programming, but I envisioned the future, and imagining success for the company, I couldn’t see myself happy over the long run in the company’s problem space, even though it’s a legitimate one.

When that feeling became clear, I spoke with the founder and we looked at alternatives for a transition. Finding good programmers available was very hard, as it always is. I suggested we hire Code Miner 42, a respected Rails firm in Brazil, and so we did.

The transition had to be well done and smooth, so I stayed and worked with two Code Miner programmers besides the mobile guys in our team for 5 months. They had a lot to teach me, which I already wrote about in another post. Despite the fact that we had only 2 programmers allocated from them, it was fun to witness how everybody at Code Miner would go into our repo at any time and throw in suggestions, and that’s dozens of people. Code Miner’s lead developer, Fábio Akita, is a very experienced programmer, and worked on our code base for two days in which he gave excellent contributions.

In my free time I was studying both Angular and React. One of my biggest mistakes in that long project was not using any javascript framework from the beginning, only Coffeescript and a lot of jQuery. It would have been fine for a prototype but the interface grew very sophisticated, completely ajaxy, and progress was slower than it could have been. Getting other coders to embrace the frontend code base was hard – by this year, they expected Ember to be there since it was part of Code Miner’s stack.

It became increasingly clear that React was gaining traction over Angular 1, and Angular 2 was taking longer than expected to go public. Gradually, I focused more of my attention on React and by June was studying only React in my free time. Boy did I hate JSX, and still do, but the overall architecture feels much better than Angular. The JavaScript world is a mess at this point, but a happy one with lots of great invention including stuff that isn’t JavaScript like Elm.

In July I accepted a shorter project helping out Moccato launch its coffeepod subscription service, which needed work on the frontend urgently. It was very gratifying to be able to help quickly and effectively, and I was so in tune with the Rails stack by then that everything flowed very quickly for an application of their size.

Earlier I had had a conversation with a friend who was working on a peer-to-peer food distribution service, Comida da Gente, and wanted to have me on board. He mentioned he was building the backend in Clojure, and sang the praises of functional languages. I was aware of the rising popularity of FP, and started looking more seriously. I already had played with Clojure itself, but couldn’t bear all the parens everywhere – I’m certainly a Ruby guy when it comes to not using weird, non-alphanumeric characters in my programs unless I’m pretty much forced to. I had been hearing more and more about Elixir, and finally ended up at their website. I installed the language in about one line in the terminal, played around for an hour, and felt like coming back to do more the next day. And the next. And the next. I thought pattern matching was strange but fun and a valid way to organize code, and knew I couldn’t at all see the big picture yet. But I was having a good time, and Elixir’s website, as well as the language itself, are organized with such a generous learning curve it’s totally captivating. Of course over time I learned that the whole ecosystem José Valim and many people are creating is getting to be totally amazing.

I had an old idea in mind that, upon learning a bit of Phoenix (Elixir’s framework), I decided to mess around with right away. I called it Look in Tens, and you can read more about it here. As a matter of fact, my time off this December may become time on this project. Phoenix is crazy fast in case you haven’t heard.

In September I started work with Comida da Gente. It was time to use React for something real. Look: it was hard. Javascript was at such a transition state (which it still is to a very large extent) picking anything was gruesome: build system (Grunt, Gulp, Brunch, Fly? Went with Gulp after many comparisons, only to bump into Webpack a little later), JS version itself (go with ES6 right away or wait a little longer? Went with it right away. Babel? Yeah.), talking to data (flux? Reflux? This new kid Redux? Went with Reflux, saw it was a mess, moved to Redux two months later, it’s much better). Midway you see Cycle.js, RxJS and you’re simply not sure you’re making the best choice. It’s truly stressing.

The design for Comida da Gente’s MVP wasn’t finished so I did a few days of that too. For that I learned Sketch. Sketch is all right, I expected more from seeing people going nuts about it, but it felt slow and the symbol system was still pretty naive. However, I liked the ease of exporting bitmaps and the libraries of vectors like the iOS stuff and material design. Very neat indeed, and I see new versions of Sketch coming out – I’ll check it again soon.

It took me a really long time to develop what I did at Comida da Gente. Just a basic authentication system with a sign-up form after Facebook authentication took a couple of months. Facebook has no integration of its APIs with React, such as in the login button or anything, so it was just tough. I did implement a beautiful geosuggest with Google Maps and the interface has some nice easy ways to do stuff, but I was almost ashamed about how long it took me to do that. Oh well…now I know much more about React, Redux and that ecosystem, and as it always happens, at this point can implement that stuff with a few copies and pastes. Many people were very generous towards me, and I thank Dan Abramov and Andrew Nguyen among others for showing me the way.

Finally, again it became clearer I needed to actively look for a project whose actual subject I deeply cared about. Nothing was falling on my lap which I loved, as much as I did my best to fall in love with what I was doing — and it had nothing to do with code. So I decided to finally stop and actively look for projects in areas which I simply care about, related to stuff I read in my free time. Those are finance, value investing, education, design and books. By the way, if you know of something interesting in those areas, please let me know: gustavo [at] :)))))

I think next year will be great in software. Who knows what will happen to the Unicorn valuations? Maybe they will collapse and anybody with some money will be able to hire the most amazing engineers to build new stuff. Maybe they will grow to trillions and make no sense. And who gives a damn? I actually do. It’s a great spectator sport.

I thank every one whom I worked with this year, every one with whom I exchanged ideas, inspiration and knowledge, and wish you all a great 2016.

On Sigmund Freud

I’ve been a beneficiary of psychoanalysis in two different periods of my life. The first, short and fundamental in helping me completely change my profession at the age of 27. The second, longer and still ongoing, helps me in a myriad of ways and led me to read a fair amount of psychology books.

In the title I make sure to specify which Freud I’m writing about because my life has been affected by at least three members of his family: himself and his grandsons Clement and Lucian. Clement wrote a children’s book called Grimble which taught me self-reliance. And Lucian, a great painter, taught me what looking can really mean.

Sigmund has seen times in which he was more fashionable than today. And it wouldn’t be surprising if Lucian becomes the name most associated with the family in a couple of centuries, given how great a painter he was and the fact that ideas flow and are co-opted much more easily than works of art.

Reading Sigmund’s works has no substitute in terms of getting in touch with what a truly transformative mind is able to do. One immediately forgets all the pop-culture clichês about him and is struck by his intellectual honesty: a writer who continuously hyperlinks the ideas he uses to their sources, weaving the web that was his place and time, and which he came to symbolize. At the same time, he is very diligent when it comes to laying out the limits of his knowledge, and often wonders in print how long it will be before his ideas will be superseded by better ones. Many have been, and many have not.

Even after over a century and the tremendous influence he exerted on western culture, it’s fascinating to learn about the interaction between the unconscious and our lives, and also about the many modules in our brain, which can only be dealt with in their own terms. Contemporary neurology confirms and expands on those themes, opening avenues of improvement for individuals and society.

If only by helping people give their mental lives a framework for self-understanding, Sigmund Freud is a worthy read. His masterful writing ensures it all feels like a vacation, if a scary one at times. His writings on technique can be helpful to any field, with much that is counterintuitive and he dealt with and incorporated into his practice. I still think, however, that The Interpretation of Dreams is a good starter, if only because he explains why we dream so often that we are still in school.

React.js, Facebook JS SDK and a costly little mistake

Last week I spent much more time than I ever wanted implementing Facebook login in React.js.

As it often turns out to be, one mistake cost me about 10 hours net of investigation, and if you don’t have time to read further, here’s what was wrong: I had added all my <script> tags inside <body> in the html, and then used <body> as the element to replace when rendering my main React component.

That was it. But what about that mistake is making me stop and write about it?

First: my app worked perfectly for a long time just as it was. Weeks. In the beginning of the project I was switching back and forth between two different build systems, and when I decided on one I must have copied the main React component and nothing pointed out an error.

Second: Facebook login kind of worked perfectly in localhost. The only strange thing I noticed was that, as I loaded the js sdk into the html, the most important sdk method, FB.init, was never found.

Since I am no React master at this point and Facebook provides no documentation on how to integrate FB login to React, even though they’re all made by FB, I had many possibilities to investigate. And lo and behold, by moving the FB.init call to the React component inside componentDidMount, everything about the login worked in localhost.

When it came to the staging environment, however, things got weird. My app would not get the login status on load, but on clicking the login button, the modal dialog would open. Sometimes the window would come up blank, sometimes it would prompt for login and then never close, and many other different outcomes.

Since most recent blog posts on Facebook login deal with difficulties with OAuth settings, my investigation went that way, and there it stayed for a long time. No warning or error message ever gave me the slightest clue as to what I was doing wrong.

Thus a mistake that arguably should have made my app break on the very first run ended up taking many hundreds of runs before the bug was caught.


Follow up:
React 0.14 warns against this.


In July and August 2015, I spent about 140 hours working on Moccato.

They are a subscription service for Nespresso pods. Apparently Nestle’s patent or rights for exclusivity recently expired, and Fabrizio Serra, formerly from ChefsClub, took up on the opportunity to have high-grade Brazilian coffees delivered to people’s doors.

They had run into difficulties with the frontend, even though they had been able to launch the website in some fashion. When I took up the work, they had a solid backend engineer, Dimas Cyriaco, a mostly complete and excellent visual identity developed by my brother’s Plau (who evidently were the ones to recommend me for the work), and were ready to begin packaging and shipping coffee all over Brazil.

Moccato is built on Ruby on Rails. Earlier, they had attempted to do an API-only backend in Go, but it was not successful. They decided to go with Rails, and what was initially an independent API client was integrated into the new Rails app.

They managed to make it work somehow, but the code base was highly impractical to iterate upon. The home page was linked to static css and js files, as were about 4 or 5 other pages, all to their own assets which were not at all using Rails’ asset pipeline. Thus, changing a mere style would involve finding it in any of up to 5 redundant stylesheets, and then making sure that style wasn’t used anywhere else.

Once I had that diagnosis, it was clear we had to move everything into the Rails asset pipeline, remove all duplicity, and only then look into giving the frontend conceptual coherence. Classes were named completely different from one file to another, and the DOM structure had 3 or 4 different versions.

The reorganization was not particularly difficult to do, but it’s remarkable how laborious it always is after something is in place. It’s impossible to stress enough how much more economic it is to have a very good programmer from the get-go. Also, of course, how it’s never very easy to get one.

I converted all .erb templates to .slim. Yes, Slim is much better in my opinion. If one is a Ruby programmer, Slim is the most Ruby-like templating system there is. It’s concise in the same way Ruby is.

I also converted most Javascript to Coffeescript. Same idea here: it’s a Ruby project, so it’s great to use a similar mental model for everything.

The pleasure of working with Slim and Coffeescript is like night and day when compared to xml-based templates and curly-brace-semi-colon-purgatory JS 5. Also they’re far more productive and, performance-wise, pretty identical.

I was able to introduce a few things which I learned from working with guys at Code Miner, such as using Pivotal Tracker (better than Asana, which I had been using prior, and possibly not as good as, which I want to use soon) and certain Github project management procedures ranging from using pull requests even if working alone on a repo (pretty extreme, I know) to subtle commenting etiquette and markdown styles.

Perhaps most importantly, I learned and used Airbrake for the first time. It’s an integration that notifies you of exceptions via email, Slack or other channels. It has a ton of possibilities, and it’s one of those things you just can’t live without after you experience it. Another one I was not able to delve much into, but seemed pretty powerful, was RD Station, as far as I know a Brazilian digital marketing engine that seems really well done and which I will definitely look into with more detail.

The end result was a desktop website that is free of extreme layout breakages, much more consistent visually, and much closer to being considered responsive. Also, I was able to build a mobile version, which really should be everyone’s first consideration from now on — instead of desktop —, as much as I personally prefer to use and develop software for larger screens.

I wish I had more time to fine-tune the designs and work on user admin pages, but that was not to be. It may, however, happen in the future, and I will write about it if so. Many thanks to my brother Rodrigo, to Dimas for being such a great work partner, to Fabrizio for the trust and to the whole team at Moccato. I wish you much success.

Deploying to Dreampress – note to self

If you setup a Dreampress installation with a * temp site.
And when you deploy the final domain the links get stuck to the old, including the admin area which becomes unreachable.

Make sure wp-config database credentials are directly reachable (or they evaluate correctly for a command line script).

SSH into the host and clear Varnish and Memcached caches:
curl -X PURGE “*” ; wp cache flush

Also, you may want to temporarily rename wp-content/object-cache.php, flush, and revert to the correct name.

Monitoring Phoenix

For the past month or so, I’ve looked at Elixir and Phoenix with interest. Phoenix is a young framework, still in beta, so tools are only starting to appear.

Michael Schäfermeyer has posted on Medium about monitoring in Phoenix, a welcome addition.

Here’s wishing for a quick port of Slim or Jade into Elixir.