Blog

About an year ago, I started a new project in a stealth startup. Aside from the fact that it would provide currency that could then be exchanged for goods and services, including food for me and my family, one of the biggest reasons I took the job was that I was going to get to learn a lot of new things.

Now, over a year later I can say that learn I did. And I caught myself thinking of what I wish I knew back in the beginning. The following list is probably not exaustive but it’s a good example of what I’ve learned. These are mostly things I’ve dealt with on rewrites, redesigns, or are things that I still struggle with.

JavaScript is magical and that’s not good

I already had a general idea of the issues with JavaScript, but I really failed to grasp how magical JavaScript is. And when I say magical, I don’t mean the good kind that conjures fluffy rabbits inside hats. I mean evil dark magic that would make Voldermort cry. I mean magic in the sense of a language that never seems to behave just the way you think it should.

I wish I knew back then how much work I would need to spend to do what seemed at first to be basic, simple stuff. I often caught myself fighting JavaScript instead of working with it.

AngularJS is awesome but the web works on jQuery

I think AngularJS is fantastic. Really I do. I am not at all sorry for having picked it for the project. I think it’s well-designed and logical and yes, it is magical sometimes, but often in a good way.

But…

I wish I knew back then how much work I would have to do making AngularJS and jQuery work together, and you have to make them work together because honestly, unless you want to reinvent the wheel for every little thing, you will end up using jQuery components. We will revisit that later.

So yeah, AngularJS is great but for it to work properly, you have to do things the Angular way and that means turning a lot of jQuery components into AngularJS directives. Once you get the hang of it, it gets much easier and faster but there’s a bit of a learning curve there.

asynchronously have You think undefined

You have to think asynchronously to work with JavaScript. For a while, it was painful and it surely added to my perception of JavaScript being magical. JavaScript is entirely asynchronous and works like a turn-based game. This can be annoying at first and I caught myself working around this in all kinds of wrong ways. I wish I knew back then what I know now so I’d embrace the async’ness from the get-go. Things would be so much easier.

Large single-page web applications rock but…

Picking AngularJS as my framework of choice, I designed the web client for the project to be almost purely implemented inside the browser in JavaScript as a single-page app. This has some very good consequences, chief among them responsiveness. The application feels fast. Sure it has to download a lot of JavaScript up front, but (1) this is not nearly as bad as I expected it to be and (2) with caching this is done once and that’s it. Switching from a “page” to the other is essentially instantaneous as it’s all pre-loaded AJAX parts of the page. The server actually has to do very little.

But now, if I could start all over again, I would not do it like one big single-page app. It’s just too much JavaScript code and I’ve already established how I feel about that. I never have the feel that things are stable, even though there are integration tests passing all the time. I can’t explain it but it all feels like a big house of cards, like it’s all going to come tumbling down all of a sudden. I simply don’t trust the code. I would much rather use JavaScript sparingly, to do some things but surely not all. I have been fixing this slowly by isolating some parts of the application as separate, but to do it for everything would require a rewrite that I don’t have the time for right now.

Trust the Go standard lib

As an alternative title, “don’t go too fancy with Go.” It’s not that I didn’t trust it, but I sure did try things that honestly didn’t make sense. I am looking right at you, Martini, I had to do a lot of work to get rid of you.

As it turns out, the standard library is really good. And for the things that are not in the standard lib, there are packages that are really well done and work with the standard lib, not against it. I love you, Gorilla Toolkit.

Never assume jQuery components will do what you need

The current state of JavaScript is such that there is literally—in the figurative sense—an infinite number of components out there ready for you to use. As far as I can tell, anything I could ever possibly conceive of has already done and hosted on Github. There are time pickers, calendars, and even a business hours widget display ready for you.

And yet.

I am yet to find one single component that is flexible enough to work for my needs without extensive modifications. And it’s not like I have especially unique needs. I am talking about things that are to the best of my knowledge pretty basic. But no, they never do that one tiny thing you need them to and I spend a lot of time implementing features I need.

Bootstrap responsiveness

For a long time I misunderstood how Bootstrap deals with responsive design. Trusting Bootstrap’s system is a must. It works very well. I wish I understood it better back then. It would have saved me a lot of time. And related:

Don’t use an existing Bootstrap theme

It’s just not worth it. Back then, we didn’t have a designer and we wanted to have our minimum viable product as quickly as possible so we went after something ready. We chose a premium theme that is very popular. It was good looking and seemed really nice. Boy do I wish I had a time machine now.

We are now stuck with it. Switching to something else is something we will have to do eventually and let me tell you: it will be painful. These themes change everything and not in a way that we could simply switch themes painlessly. It permeates everything.

Think of touchscreens from the beginning

Oh boy. You do a lot of nice stuff and then one day you try it on a tablet and nothing works just as your co-founder tells you that your first customer will use the app exclusively on tablets. Then you start panicking and sobbing and crying and running for help. You then find out about the hack that is jQueryUI Touch Punch and although it fixes some of the problems it creates new ones and then there’s jQuery Mobile which is OMG fantastic except lo and behold it doesn’t play well together with AngularJS. And then you find some projects on Github trying to get jQuery Mobile to work alongside with AngularJS but they’re no longer maintained and won’t really work that well and…

Well, it would be best to think about touch support from the get go.

Stop worrying about the size of your JavaScript

Or actually, do worry, but for the right reasons. One of the things I learned is that the web is full of outdated and/or otherwise uninformed advice.

Stop laughing.

Yes, it’s obvious, but still. With little experience with web frontend programming, I used to worry about the size of my JavaScript code. And the web doesn’t really help. Search a bit and you will find people telling you how horrendous it would be to download 100Kb of JavaScript and how the only way to save your customers is to access files from popular CDNs.

It turns out that’s kind of like cargo cult programming. It’s just a bunch of people repeating something they heard somewhere. Things change. We measured them.

Concatenating and minifying our files and serving them gzip’d and with aggressive caching is actually faster. Even concatenation is about to become irrelevant now that SPDY is becoming more common (IE11 now supports SPDY3 and the upcoming versions of Safari for OSX and iOS will as well.)

The first access to our app downloads almost 1MB of JavaScript code and CSS files. It sounds horrible but it’s really fast, even on bad 3G with with defer and async. Speaking of which.

Most of the advice repeated as a mantra on the web is from before browser support for <script defer> and <script async> was widespread.

I think that’s about it. Now all I need is a time machine.

A few days ago I posted about a new Go package called validator that we initially developed for our own internal use at project7.io but what fun is internal stuff, right? So we opensourced it.

Then Matthew Holt pointed me to an ongoing discussion
on validation happening on martini-contrib’s github. By the way, if you don’t know martini yet, go rectify that right now.

And today I learned about check, which takes a completely different
approach to data validation than the one we took, which by the way is totally fine and you should check it out.

Good to know we were not the only ones with the problem. Although I’m happy with how our package turned out, I kind of wish
I had found these other guys earlier. Could have shared some code or just ideas.

The thing about working in a startup under stealth mode is you can’t often talk about what you’re doing. Thankfully, from time to time, an opportunity appears that lets us at least share something tangential.

A large part of our project at project7.io involves receiving data from a client (generally in JSON) for processing. This involves unmarshaling the JSON into a struct, something that Go does very well. But then comes the boring part: checking that the information sent from the client is correct and complete before doing anything with it.

1

<span class='line'><span class="k">if</span> <span class="nx">t</span><span class="p">.</span><span class="nx">Username</span> <span class="o">!=</span> <span class="s">""</span> <span class="o">&&</span> <span class="nx">t</span><span class="p">.</span><span class="nx">Age</span> <span class="p">></span> <span class="mi">18</span> <span class="o">&&</span> <span class="nx">t</span><span class="p">.</span><span class="nx">Foo</span> <span class="o">!=</span> <span class="kc">nil</span> <span class="o">&&</span> <span class="nb">len</span><span class="p">(</span><span class="nx">t</span><span class="p">.</span><span class="nx">Bar</span><span class="p">.</span><span class="nx">Baz</span><span class="p">)</span> <span class="p">></span> <span class="mi">8</span> <span class="o">&&</span> <span class="o">...</span>
</span>

We had to do this often and for a large number of different structs and sometimes a struct gained a new field and we had to go back and see that it was being properly validated everywhere. It was so boring that we ended up writing something to make it easier for us. We’ve been using this for a while and now we decided to open source it in the hopes that it might be useful for others.

Package validator implements validation of variables. Initially we had implemented JSONschema but we don’t always deal with JSON, we also get data as XML and sometimes as form-encoded. So we changed our approach and went right to the struct definitions.

1
2
3
4
5
6
7
8

<span class='line'><span class="kd">type</span> <span class="nx">T</span> <span class="kd">struct</span> <span class="p">{</span>
</span><span class='line'>  <span class="nx">A</span> <span class="kt">int</span>    <span class="s">`validate:"nonzero"`</span>
</span><span class='line'>  <span class="nx">B</span> <span class="kt">string</span> <span class="s">`validate:"nonzero,max=10"`</span>
</span><span class='line'>  <span class="nx">C</span> <span class="kd">struct</span> <span class="p">{</span>
</span><span class='line'>      <span class="nx">Ca</span> <span class="kt">int</span>    <span class="s">`validate:"min=5,max=10"`</span>
</span><span class='line'>      <span class="nx">Cb</span> <span class="kt">string</span> <span class="s">`validate:"min=8, regexp:^[a-zA-Z]+"`</span>
</span><span class='line'>  <span class="p">}</span>
</span><span class='line'><span class="p">}</span>
</span>

This allowed us to attach validation rules right to the data structure definitions. Then instead of large, boring list of if statements, we were able to validate in single function call.

1
2
3

<span class='line'><span class="k">if</span> <span class="nx">valid</span><span class="p">,</span> <span class="nx">_</span> <span class="o">:=</span> <span class="nx">validator</span><span class="p">.</span><span class="nx">Validate</span><span class="p">(</span><span class="nx">t</span><span class="p">);</span> <span class="p">!</span><span class="nx">valid</span> <span class="p">{</span>
</span><span class='line'>  <span class="c1">// not valid, so return an http.StatusBadRequest of something</span>
</span><span class='line'><span class="p">}</span>
</span>

Multiple rules for different situations

We often use the same struct to deal with different data coming from the client. Sometimes we only care about one or two of the fields in one scenario, so we also supported multiple rules like, say

1
2
3
4

<span class='line'><span class="kd">type</span> <span class="nx">T</span> <span class="kd">struct</span> <span class="p">{</span>
</span><span class='line'>  <span class="nx">A</span> <span class="kt">int</span>    <span class="s">`foo:"nonzero" bar:"min=5,max=10"`</span>
</span><span class='line'>  <span class="nx">B</span> <span class="kt">string</span> <span class="s">`bar:"nonzero"`</span>
</span><span class='line'><span class="p">}</span>
</span>

In scenario foo, we need A to be non-zero, but we don’t care for what is in B. In the bar scenario, however, we need B to be non-zero and the value of A to be between 5 and 10, inclusive. To validate, we then make validator use a different tag name for each case

1
2
3

<span class='line'><span class="nx">t</span> <span class="o">:=</span> <span class="nx">T</span><span class="p">{</span><span class="nx">A</span><span class="p">:</span> <span class="mi">3</span><span class="p">}</span>
</span><span class='line'><span class="nx">validator</span><span class="p">.</span><span class="nx">WithTag</span><span class="p">(</span><span class="s">"foo"</span><span class="p">).</span><span class="nx">Validate</span><span class="p">(</span><span class="nx">t</span><span class="p">)</span> <span class="c1">// valid</span>
</span><span class='line'><span class="nx">validator</span><span class="p">.</span><span class="nx">WithTag</span><span class="p">(</span><span class="s">"bar"</span><span class="p">).</span><span class="nx">Validate</span><span class="p">(</span><span class="nx">t</span><span class="p">)</span> <span class="c1">// invalid</span>
</span>

We can also change the tag by using SetTag with will then make the tag name persistent until changed again by another call to SetTag.

Please refer to http://godoc.org/gopkg.in/validator.v1 for a lot more documentation, use cases, and how to access the individual validation errors found for each field.

On the way to the Moon, the Apollo crew and ground control needed precise information about the position, speed, and acceleration of the stack. Getting that information was a feat of engineering involving very clever solutions that deserve a post of their own, but the easiest piece of the puzzle was the position.

To figure out where exactly the Apollo was at any given moment, the crew used a guidance computer designed by the MIT along with a sextant, not much unlike the ones used for centuries by sea captains.

The CM pilot would pick a specific star (or planet sometimes) that could be placed within view of the sextant optics, he’d then align the sextant viewport with the chosen star, and then tell the guidance computer to calculate the position by telling it which star he had just pointed the sextant to.

The astronauts had a table of stars they could use, each accompanied by an octal code that could be fed to the computer. In this list, along with well-known stars—such as Sirius (15), Rigel (12), and the Sun (46)—were three oddly named stars.

While helping with the development of this system, the crew of Apollo I decided to have a little fun and added references to themselves by changing the names of some stars to parts of their own names spelled backwards:

• Navi (03) for Gus Grisson’s middle name (Ivan)
• Regor (17) for Roger Chaffee
• Dnoces (20) for Edward White II.

In reality, Navi was γ Cassiopeiae, Regor was γ Velorum, and Dnoces was ι Ursae Majoris.

After the crew lost their lives in a tragic fire—the first fallen in the American space manned program—the people at NASA kept those names in all their documentation and literature.

Um amigo publicou um texto no Facebook hoje que me lembrou do MBA. Vou deixar o texto aqui, como exemplo do tipo de texto comum em escolas de negócio e deixar o julgamento ao leitor:

ASSALTO MUITO INTERESSANTE.

Durante um assalto, em Guangzhou, China, o assaltante de bancos gritou para todos no banco: “Não se mova O dinheiro pertence ao Estado Sua vida pertence a você…”

Todo mundo no banco deitou-se calmamente no chão. Isso é chamado de “Mudando o conceito mental” Mudar a forma convencional de pensar.

Quando uma senhora apresentou-se sobre a mesa provocativamente, em que o ladrão gritou para ela: “Por favor, seja civilizada isto é um assalto e não um estupro!”

Isso é chamado de “ser profissional” Concentre-se apenas no que você está treinado para fazer!

Quando os assaltantes voltaram para casa, o ladrão mais jovem (MBA treinee), disse ao ladrão mais velho (que só completou seis anos na escola primária): “Big brother, vamos contar o quanto nós temos.”

O assaltante mais velho rebateu e disse: “Você é muito estúpido. Há tanto dinheiro que vai nos levar muito tempo para contar. Hoje à noite, o noticiário da TV vai nos dizer o quanto nós roubamos do banco…!”

Isso é chamado de “experiência”. Hoje em dia, a experiência é mais importante do que as qualificações do papel!

Depois que os ladrões saíram, o gerente do banco disse ao supervisor bancário para chamar a polícia rapidamente. Mas o supervisor lhe disse: “Espere, vamos retirar U$ 10 milhões do banco para nós mesmos e adicioná-lo aos 70 milhões dólares que já foram desviados do banco”.

Isso é chamado de “nadar à favor da maré.” Convertendo uma situação desfavorável para a sua vantagem!

O supervisor diz: “Vai ser bom para nós se houver um assalto a cada mês.”

Isso é chamado de “morte do tédio”. Felicidade pessoal é mais importante do que o seu trabalho.

No dia seguinte, o noticiário da TV informou que U$ 100 milhões, foram retirados do banco. Os ladrões contaram e contaram e contaram, mas eles só podiam contar o montante de U$20 milhões. Os ladrões estavam muito irritados e reclamaram: “Nós arriscamos nossas vidas e só levamos 20 milhões de dólares. O gerente do banco levou 80 milhões de dólares com apenas um estalar de seus dedos. Parece que é melhor ser educado do que ser um ladrão..!”

Isso é chamado de “Conhecimento que vale tanto quanto ouro!”

O gerente do banco estava sorrindo feliz porque suas perdas no mercado de ações foram agora cobertas por este roubo.

Isso é chamado de “Aproveitando a oportunidade.” Ousadia para assumir riscos!

Então, quem são os ladrões reais aqui?

Conde de Kakflour