Category Archives: Javascript

TDD with Firestore functions emulator

Having spent time running tests inside and outside Firestore’s emulator, I learned that using the emulator is more than 50% faster.

Here is the latest flow we are using at Circuit. If you know of a simpler way, please let me know at gus [at] getcircuit [dot] com.

Basic version

firebase emulators:exec --only firestore 'jest'

You can replace jest with the runner of your choice.

Abstract the emulator call

Install scripty:

yarn add scripty

Add an entry to package.json:

{
  …
  "scripts": {
    …
    "test": "scripty"
  }
  …
}

Create a directory called scripts in the root of your project.

Create a file with path and name scripts/test:

#!/usr/bin/env sh

str="$*"
firebase emulators:exec --only firestore "yarn jest $str"

Allow computer to run this file:

chmod 644 scripts/test

Now you can run yarn test and add anything you would add to the command, like yarn test --watch, yarn test /path/to/test.file.

Enable connecting with a browser’s debugger

Add an entry to package.json:

{
  …
  "scripts": {
    …
    "debug": "scripty"
  }
  …
}

Create a file with path and name script/debug:

#!/usr/bin/env sh

str="$*"
firebase emulators:exec --only firestore "node --inspect node_modules/.bin/jest --watch --runInBand $str"

Allow computer to run this file:

chmod 644 scripts/debug

Add debugger to any line of your Firestore code.

Run yarn debug — you can also pass a filename to focus on it right away.

Open your browers’s developer tools.

Click on the green cube (Node’s logo):

This will open the debugger and you’re ready to step debug your code.

My Year in: Tech

I started the year of 2019 as a front-end developer at Toptal’s core team. Just a few days later, I was invited to be Team Lead for a brand new team.

My emphasis turned, again, to working with people. That was a delight and I fully embraced the opportunity to help build a team. We had a few company veterans enlisted to start the new team, all of whom I had not worked with before, and we needed to hire two more front-end engineers.

The first recruitment process was for an excellent React engineer. It was done very deliberately and unhurriedly, to make sure we raised the overall level of the team on the React stack. It took us a little over 2 months until we found a great guy, who has contributed a lot this year.

The second engineer was a gift to us, as he was initially hired for another team. Happy to say he’s also doing tremendously well.

We quickly became a real team. It seems we did a few things that helped: communicating a lot, admitting mistakes and ignorance openly and quickly, and being real human beings.

One teammate brought along the Personal Questions call from his previous team. This call has a simple structure: one team member asks one or two questions, personal as the name says, to everyone on the team.

The questions are as simple as “What was the best trip you ever took?”, or “What is your favorite dish?”. It’s up to the team to let this call become just a little window on who they are, or a huge gateway to people’s souls. Yes, it’s possible to cry while listening to someone tell you about their favorite food once they tell you the story behind it. The bond I felt with the team was immense.

Dedicating at least one or two hours per week of each team member’s time to building rapport makes a big difference, particularly in new teams. Next year I will work to learn more ways of doing that.

I made my share of mistakes. The one that comes strongest to mind is about having patience before giving feedback to people you may like personally but don’t think are doing a good job — especially when they are not reporting to you. Convincing people to change is hard enough as it is, doing it without mutual trust and knowing their motivations is likely to backfire.

Another lesson I was reminded of by a mistake of mine is the “no surprises rule”. It’s often hard to know, in advance, how sensitive some task or decision may turn out to be. Next time something I do starts to deviate too much from what was agreed-upon, I should remember to share that early on, and avoid surprises, because the surprise itself may make people react negatively to something fundamentally desirable, or I may have the wrong assumptions or decisions and other points of view will help me see that.

I stayed with the team for a total of 9 months, we launched a good chunk of the new application we were developing, and then I was enlisted to start a new team from scratch: to recruit every single engineer, and help recruit designer and product manager.

It was painful to say goodbye to a team I loved so much.

Soon it was back to recruiting, this time a few weeks of full-time effort, and we are still at it. We seem to be close to hiring two people, and have one more front-end and one more QA person to bring onboard on the engineering side.

This recent team switch gave me time to study programming after a several-month hiatus. I am focusing on new React APIs, from Hooks to Context and Suspense, as well as testing, TypeScript and, soon, Apollo.

I did continue to study the Elixir language source, something I’ve done for maybe 3 years now. This year I did relatively little of it. I love Elixir just as much as always, and am thankful for having learned so much from its community.

I plan to go multi-team as soon as I have a chance, be it in an Engineering Manager or CTO role. Thus I dedicated more time than ever to reading about leadership, management and communication, often with a big emphasis on tech. Especially for people who are new to management, I recommend The Making of a Manager by Julie Zhou.

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.

Live gut reactions to learning Ember.js

I am starting on a new project that uses Ember.js.

I started learning it from scratch a few days ago. Thought it would be a good opportunity to log my gut reactions while I find out how it works.

My main term of comparison will be React.js, which I started learning in about February 2015. I have spent a decent amount of time working with it. Far less than on jQuery-based projects in the past, but still. I also know a bit of Angular 1, so that may come up too.

I will go for free-associative, bullet-list, initial reactions for this post.

  • Official website is organized and pretty enough.
  • Really easy to download and have a local server running with a blank app.
  • No webpack. I like that.
  • ES6. Great.
  • Official tutorial does tests. Awesome.
  • Tutorial is very clearly written. Can’t compare to what I came across when I started with React.
  • Handlebar templates. I don’t know about that. Better than jsx perhaps? I miss jade, slim, wonder if it can work with something like that.
  • Bower? Not happy to see that.
  • All package names seem to start with ember-cli. Welcome and scary at the same time.
  • What’s the difference between a controller and the other entities, helpers etc? Still pretty foggy at this point.
  • Easy to install Stylus for CSS. Heard about “ember pods”. Will investigate.
  • Extremely easy to deploy something crude to Heroku, even without doing anything about the env.
  • Oh gosh, there’s an ember package to load Google Fonts.

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 https://github.com/gjaldon/phoenix-static-buildpack

# Add this buildpack after the Elixir buildpack
heroku buildpacks:add --index 1 https://github.com/HashNuke/heroku-buildpack-elixir

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.

Voilà.

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.

Moccato

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 Sprint.ly, 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.

React.js and software workarounds

The amount of conceptual compromises React.js either addresses or introduces is very high. That, however, is typical, especially in a browser environment.

This introductory talk explains the basic design decisions that led to React.js.

Although the video is a bit old, it’s also surprising to hear, at the very end of the video, that the presenter has no idea whether React will be used for Facebook mobile on browsers. Reminds us of Microsoft.