Category Archives: Software

Freezing the DOM while inspecting elements

Ever wasted a lot of time doing CSS and trying to fish for an element that disappears just when you click something on the browser inspector? Think styling autocompletes.

Well, after years and years and years suffering through that, I finally decided to Google how to freeze the page and be able to click around the inspector as much as I want without changing the DOM.

Stack Overflow shows 2 or 3 easy ways:
http://stackoverflow.com/questions/17931571/freeze-screen-in-chrome-debugger-devtools-panel-for-popover-inspection

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.

Colemak in iOS Simulator

For many months, the last place in my computer where I wasn’t using Colemak was the iOS Simulator.

Turns out it’s very easy to enable it.

In the simulator:

Settings->General->Keyboard->Hardware Keyboard

Colemak is the very last on the list.

Colemak: One Year In

February 15th 2016 marked my first anniversary using the Colemak keyboard layout. Colemak is a different arrangement of the computer’s keys, designed to be far more efficient than the traditional QWERTY layout.

I am glad I made the switch.

What made me try and switch to Colemak cold-turkey was Tim Ferris’s interview with Matt Mullenweg, in which he sings the praises of Dvorak, which he picked up many years ago, and mentions Colemak as being slightly more efficient.

I opened Mac OS’s keyboard settings and found Colemak right there. A Google search got me to Colemak’s website and a website with basic exercises, supposedly to be done in 9 days. I made Colemak my new keyboard, of course without changing the physical keyboard at all, and did the simple exercises for a few hours, maybe 3-4 over two days.

In the beginning I was extremely slow, and made many mistakes. However, I quickly realized my technique for typing numbers and capital letters had always been non-existent. I saw the new beginning as an opportunity to get those together too. I found a typing speed test and got my first performance measurement: 15 words per minute. Two days later I thought it would be a good idea to see how much I was doing with QWERTY, if only to have a term of comparison: even after the few days away from it, I did 74 wpm on the first try, and switched back to Colemak for ever.

I quickly learned that I could keep using qwerty on mobile keyboards — it’s a completely different context, and getting a Colemak keyboard for the iPhone was impossible with SwiftKey at the time.

I also learned that situations where I just have to use qwerty are rare: I don’t remember having to use someone else’s computer, but when using the iOS simulator or Windows/Linux VMs to test things, it’s just been easier to type on qwerty rather than install Colemak. My qwerty chops went down the drain pretty quick, and now I have to look at the keyboard to type. Again, I can go weeks without having to use qwerty, so to me it’s been all right.

Progress on Colemak was, or felt, very slow. One month into it, I was typing 46 wpm. Yes, that’s a 3× improvement, but try spending one month typing at about 40wpm. I didn’t care, I was measuring results every day in the beginning and knew it was a matter of staying the course.

Two months into it, I had improved to 50 wpm.

Six months into it, I did 62 wpm.

By then I was measuring my speed only rarely, and while I knew I had been far better on the qwerty before, the key configuration was clearly more efficient on Colemak and I knew I was bound to catch myself up. This was actually clear just by looking at the layout and envisioning key usage.

Today I measured my speed and it was my record: 73 wpm. Pretty hilarious to realize that, after a year, I still haven’t broken my late, unpracticed measurement on the qwerty, let alone my real speed which must have topped 85 wpm. I have no doubt I will get there and at the same time have a healthier typing setup for the rest of my life.

Another benefit of taking a hard look at my typing was developing tools for programming, which is really where most of my typing goes. I created Colemak Home Row Frenzy, which uses a totally insane set of dependencies but gives me a lot of efficiency typing typical programming symbols on a regular MacBook Pro keyboard. I have a hunch my move to Colemak rules out my ever becoming a Vim user, but I may be wrong.

In conclusion: for those of you who type a lot and see yourselves typing a lot 3 or more years into the future, I suggest you consider switching to Colemak. For terminal patients, luddites or people who are trying to quit computers altogether soon, don’t bother.

 

 

3 dicas para novos empreendedores digitais

Ao longo dos últimos 8 anos, conversei com muitos novos empreendedores digitais que procuram meus serviços, ou mesmo um bate-papo, para ajudá-los a dar o start em suas startups.

Acima de tudo, considero esse movimento muito saudável, e há mais de duas décadas essas pessoas vêm trazendo muitas novidades positivas para o mundo e para nosso país.

Nessas conversas noto 3 erros comuns e fáceis de explicar. Corrigi-los não é tão difícil, e vai dar mais eficiência ao trabalho de começar uma empresa digital.

1. Não revelar a ideia do negócio

É compreensível a relutância em contar para um quase desconhecido a sua ideia de startup. Eu mesmo assino diversos NDA (non-disclosure agreement) todos os anos, para que o empreendedor se sinta confortável em falar sobre seus planos.

Na prática, entretanto, essa proteção é contraproducente: a ameaça de alguém roubar sua ideia é praticamente nula. Todos nós temos diversas ideias, que por nascerem de experiências próprias, quase sempre são as que nos mobilizariam de verdade a começar um negócio. E, seja qual for a ideia, ela vai demandar um esforço enorme para ser implementada, sem contar prováveis mudanças de curso ao longo do processo.

Ao não falar abertamente para um grande número de pessoas sobre sua ideia, o empreendedor perde a chance de receber feedback de quem provavelmente conhece muitas ideias semelhantes, e às vezes idênticas. Já aconteceu comigo, por exemplo, de estar em uma reunião após ter assinado o NDA, ouvir a ideia, e perguntar para a empreendedora se ela conhecia as empresas X e Y, que me pareciam ser bem semelhantes à ideia que ela apresentava. A empreendedora não conhecia, e ao entender o que faziam aquelas empresas que já existiam, acabou encerrando a reunião, entendendo que precisaria aprofundar seu benchmarking.

2. Já tenho designer, marketing, e agora só falta programador

Por diversos motivos, a relação de oferta e demanda para encontrar designers e pessoas de marketing é muito mais favorável do que para encontrar bons programadores.

Todos esses papéis têm importância fundamental numa startup, mas o número de horas necessário para se programar um MVP típico é normalmente muitas vezes maior do que as horas necessárias para se desenhar um bom produto, ou para levar ao público um esforço de divulgação. Mais tarde no ciclo de vida de uma startup, com um produto lançado e funcionando, essa relação pode mudar bastante — no início, entretanto, é assim que tipicamente funciona. É bem mais difícil para um programador entrar apenas pelo equity se ele vai precisar se dedicar integralmente ao produto durante vários meses até que ele seja lançado.

3. Vou pegar um programador melhor, que já tem emprego, mas como freelancer à noite e fins-de-semana

A não ser que sua startup tenha um produto incrivelmente simples, o que nunca é o caso, a pessoa que for programar seu produto precisa estar nas melhores condições para trabalhar. Após passar 8 horas programando em um dia, mesmo o mais extraordinário developer vai ter seu rendimento reduzido a uma fração do normal. No fim-de-semana, após 5 dias trabalhando 8 horas, a mesma coisa acontece. Em termos de incentivo, esse arranjo também não ajuda muito a startup a sair do papel, porque o alinhamento de objetivos é, na melhor das hipóteses, apenas parcial.

Como fazer melhor

Considere a possibilidade de falar sobre sua ideia de startup com o máximo de pessoas interessadas, sem se preocupar tanto com possíveis consequências negativas.

Aceite que a energia dispendida para ter bons programadores, em tempo e dinheiro, vai ser considerável. Procure bastante, busque referências, veja projetos que os programadores já lançaram, pergunte em detalhes sobre o que fizeram nos projetos.

Ao encontrar alguém bom, faça um período de teste (uma semana, por exemplo, mesmo que seja part-time). Dando certo, garanta que ela vai trabalhar nas suas melhores horas e remunere-a para isso.

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à.

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] poe.ma :)))))

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.

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.