My Year in: Software Development

2017 ends for me, at least in terms of software development, on a much higher note than it started.

From January till October I worked on a financial startup through Toptal. I was part of a team of between 5 and 15 people over the period, and my duties were far more restricted than what I’m used to: mostly markup and styling.

I did the work inside Ember but never warmed to the framework. I’m sure it was not because of technical matters per se, rather mostly because I perceived the framework as not picking up traction, therefore not deserving of much investment. It was hard to flow with it since auto-reloads were quite slow and the style of getting and setting values always felt strange to me.

There’s a lot I learned in this project in terms of organizing teams and the main lesson was: if you hire remote team members, embrace that fact full-heartedly. This is not to say that you either do it remotely or locally, but if you have even one team member that is working remotely, you should do everything as if the whole team was remote, otherwise the interactions will break down fast. I’d go further and say that dev teams should work as if remotely even if the team is local, persisting all relevant decisions in writing, avoiding one-to-one communication in favor of groups to save on recommunication and following the basic protocols of remote collaboration.

All the while, I kept spending some time on Elixir, and was always happy doing so even though the language has all but become hugely popular thus far.

Another significant change in my process was my move from Atom to Vim. Yes, the entry barrier is significant, and a bit more so since I use the Colemak keyboard layout, but I am very glad I did it. After a while you’re much more productive in Vim, and it’s a more direct connection between thought and writing. It took about 3 months for me to feel as productive in Vim as I had been in Atom.

Sometime in the middle of the year, a couple of fellows got in touch about starting a company in the real estate sector. After much talk we decided to join forces and we started EmCasa.com.

At EmCasa.com I was free to choose the stack for a greenfield project, and so I chose Postgres, Elixir/Phoenix and React for the web client. Postgres is the dependable relational database, with (I trust) more native support for geolocation, so I didn’t hesitate there. Elixir and Phoenix wasn’t much more of a difficult decision either: I trusted the language entirely, felt the tools are at a very reasonable point, enjoy using it a lot, and thought we could attract good developers to use it. So far it’s worked out that way, and as I get ready to hand over most of the Elixir side to a new team member, we talked to a number of pretty great developers that are fond of the language and excellent at it.

Finally, the React decision was a bit more difficult, and even though I consider myself a frontend developer, has been more fraught with difficulties. It’s hard to say I’d choose React again. I probably would, but I really don’t know if we’d been doing better with Vue.js or maybe even Elm.

EmCasa needs a lot of good SEO, so it needs server-side-rendering and very controllable html headers. It took me a while to sift through a few of the available possibilities, that being the main con of polylyths. Finally I made progress using Next.js, which has been a pleasure to use. I ended up throwing out Redux and I haven’t regretted it. I think Next.js has a good path ahead of itself.

We have a long list of ideas to implement at EmCasa, our backlog is public, and so are our backend and our frontend. If you’re reading this and would like to chat with us about joining the team, check out www.emcasa.com/jobs or write me at gustavo.saiani [at] emcasa.com.

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.