O que marcenaria me ensinou de front-end

Fazia tempo que eu queria aprender e praticar algumas coisas a fim de mudar um pouco meu modo de pensar, escolhi meditação, marcenaria e bonsai. Arrumei tempo para estudar e praticar os três. Tentar aprender um pouco mais sobre marcenaria/construção foi um dos fatores que me levou a voluntariar no TETO.

Acho que foi no ZOFE sobre carreira em front-end que o Zeno e o Daniel (recomendo que você ouça todos os podcasts destes caras) fizeram uma comparação entre o trabalho de artesãos e dos desenvolvedores front-end: desenvolver um trabalho único e dedicar-se a entregar o melhor de si em uma “peça”, ou no nosso caso, a uma interface. 

Eu e a marcenaria

Apesar de ainda não saber praticamente nada de marcenaria ela já me ensinou bastante. Sei pregar, sei serrar, sei lixar. Tudo isso mais ou menos, e bem mais para menos.

Comecei a praticar faz pouco tempo e para começar resolvi reciclar, restaurar e pintar um caixote de feira para a Bia transformar em um criado mudo ou em um caixote para guardar coisas. Ela (ou o pai dela) já haviam arrumado o caixote e em um final de semana comprei lixas e resolvi começar.

Caixote de madeira

Quem sabe um dia?

Lixei uma vez e o caixote ficou bem mais bonito do que estava antes. Foi uma hora de calma, café e o cheiro de madeira. E neste ponto comecei a refletir sobre minha ansiedade (este era um dos motivos de eu procurar atividades offline) e fazer comparação com o desenvolvimento web e a marcenaria.

Depois de pouco mais de quase três horas de trabalho e muita lixa gasta, eu poderia considerar o caixote pronto. As partes internas lisas como nunca estiveram, os cantos arredondados (não é piada com front-end) e minhas mãos secas da lixa e pó. O resultado depois disso foi que o caixote ganhou outra cor, quase sem nenhuma “sujeira” externa visível e pronto para receber uma camada de verniz e se tornar parte da decoração de casa.

Já estava tarde, eu estava cansado, fui dormir e retomei o trabalho no dia seguinte.

Não comecei pela pintura, peguei novamente a lixa e vi detalhes que passaram despercebidos no dia anterior. Não hesitei em recomeçar a lixar, a melhorar o acabamento de algumas pontas e deixar tudo mais simétrico. Mais lixa, mais pó e o resultado melhor do que o anterior, repeti o ciclo algumas vezes, desta vez de forma mais rápida. 

Pintura e ferramentas

Satisfeito com o estado do caixote, fui verificar o que precisava para fazer a pintura. Desisti de passar apenas verniz e resolvi pintar a caixa.

Como eu não tinha a base correta para madeira usei uma outra base que, em teoria, deveria funcionar pois era bem parecida com a base para madeira (dizem…). 

Ficou horrível. Estraguei o caixote. 

A madeira “chupou” toda a tinta que eu passava, a cada passada o rolo secava e a madeira adquiria um esbranquiçado apático, bem pior do que quando estava apenas lixada.

O caixote esta lá, esperando para receber a finalização.

O que marcenaria me ensinou sobre front-end

Desde que comecei a trabalhar com o caixote fiquei pensando em escrever este texto e pensando em como paciência é uma virtude importante para um desenvolvedor, seja front-end ou back-end. 

Eu sei que posso entregar um projeto em cinco horas ou este mesmo projeto em quinze horas, e apesar dos resultados aparentarem ser “bem parecidos”, não é bem assim. 

Em meus projetos eu costumo sofrer de uma síndrome chamada “ansiedade de colocar no ar”, principalmente se tratando do And After. Por razões de negócio sou muito mais cuidadoso com o Eu Compraria, mas mesmo assim a ansiedade é uma complicada de lidar e acaba atrapalhando na qualidade e produtividade enquanto estou programando.

Se algo está “quase pronto” era comum três coisas acontecerem por aqui:

  1. Trabalhar mais que 10 horas diárias
  2. Não conseguir focar em outra coisa senão o projeto que quero lançar
  3. Preciso lançar hoje

Identificar o problema é o primeiro passo para lidar com ele, e lixar, lixar e lixar me ajudou a controlar um pouco a ansiedade (provavelmente meditação e estar cultivando bonsais também ajudaram).

Aprendi a ser um desenvolvedor com uma qualidade de entrega melhor do que a que eu estava acostumado, controlo um pouco melhor a ansiedade que sinto em publicar um projeto (text, código, etc.).

Em uma construção de moradia emergencial no TETO
A construção é de um final de semana. 

Que tal participar do TETO?

Quando o objetivo é fazer bem feito não devemos ter pressa, hoje eu foco em fazer o melhor possível no tempo que eu acho necessário, e não no tempo que eu acho mínimo para uma entrega. 

No TETO o primeiro dia é basicamente dedicado a fundação da casa, e temos apenas 2 dias para construir. Antes de começar a codar seu projeto pense em cada detalhe, estruture ele na sua cabeça ou no papel. Trabalhar em um projeto com uma estrutura sólida é muito mais tranquilo e rápido.

Buscar atividades fora do digital podem ajudar bastante a melhorar nossa qualidade de vida e qualidade de trabalho quando tentamos fazer uma relação e aprender sobre a vida, não sobre uma profissão ou atividade específica.

E você, tem alguma experiência parecida com atividades que refletiram na melhora do seu trabalho? Compartilhe nos comentários ou me escreva. 🙂

Javascript Rock

O  Dmitry Baranovskiy's escreveu um RAP do Javascript e John Fawcett fez esta maravilhosa obra de transformar a letra em rock!

Tomei a liberdade de traduzir a letra para o português, fiquem a vontade para sugerir melhorias na tradução.

Letra – Javasript Rock

You code in JS, but you mixing the types
And always forget the syntax for "splice".
To type "double equal" is like rolling the dice
And you scared to death … of prototypes

Você programa em JS mas você mistura os tipos
E você sempre esquece a sintaxe do splice
Escrever "igual igual" é como jogar dados
E você morre de medo de usar prototype


It's time to stand up and get some respect,
Just go to ECMA and start reading spec.
Unpuzzle, unlock it, uncode and decrypt
And gain yourself power of true JavaScript

É hora e levantar e ganhar algum respeito
Vá para o ECMA e comece a ler as especificações
Desembaralhe, desbloqueie, uncode e decodifique
E ganhe você mesmo o poder do verdadeiro Javascript

You add number to string and string to array
Divide it by object (you know it's ok)
The prototype chain you can see through the code…
It was a great journey from Netscape to Node.

Você adiciona número a string e string ao array
Divide por um objeto (você sabe que está ok)
Com o prototype você pode ver todo o código
Foi uma grande jornada do Netscape ao Node

 

O vídeo foi dica do grande Clécio no Facebook.

Se você gosta de músicas falando de tecnologia precisa conhecer o SEO RAP.

Zen Coding agora é Emmet

Emmet é uma ferramenta que substitui o Zen Coding, uma série de snippets de código que tornam o desenvolvimento mais ágil.

 

Nunca fui um adepto fervoroso do Zen Coding, tinha ele instalado mas não aproveitava muito o que ele tinha para oferecer. Agora, trabalhando apenas como freelancer, resolvi apostar mais no Emmet para ver se me ajuda a produzir mais.

Para mais informação, leia também:

BrainJS – Rede Neural com Javascript

Recentemente conheci o BrainJS, uma biblioteca de Rede Neural Artificial toda desenvolvida em Javascript disponível para instalação com npm no NodeJS (veja como instalar o NodeJS + npm).

 

Como funciona uma rede neural?

A resposta curta é: com magia negra.

Esta é uma rede neural não artificial: um cérebro de chipanzé.

A reposta um pouco mais longa, é que a rede neural recebe uma série de dados (inputs) e a resposta esperada para cada caso de conjunto de inputs. 

Depois de coletar alguns inputs com respostas que você já saiba você pode executar o "treinamento" desta rede neural, e o resultado deste treinamento será um algoritmo. Este algoritmo calculará uma  probabilidade de resposta para os próximos inputs que você colocar neste rede neural.

A rede neural é utilizada para sistemas de inteligência artificial, com o constante treinamento da rede (e input de informações) suas respostas ficam mais acertadas com o tempo.

Leia mais sobre redes neurais artificiais na Wikipedia.

 

BrainJS

Agora que você já tem uma idéia de como uma rede neural artificial funciona, pode fazer como eu e ficar impressionado por isso funcionar em javascript (server-side com NodeJS) ou client side, utilizando a artimanha do browserify

Eu fiz uma série de experimentos com o BrainJS, quase todos relacionados a seletores de cores – sabem como é difícil a vida de um daltônico? Pensei em uma ferramenta para me auxiliar na identificação de cores e está dando certo…

Treinando uma rede neural com BrainJS

// instanciamos nossa rede neural, spongebob
var spongebob = new NeuralNetwork();
 

Agora vamos inputar dados de altura (h) e largura (w) e os resultados esperados: se o objeto é vertical ou horizontal.

spongebob.train([
  {input: {w:200,h:100}, output: {horizontal: 1}},
  {input: {w:500,h:400}, output: {horizontal: 1}},
  {input: {w:100,h:110}, output: {vertical: 1}},
  {input: {w:5,h:7}, output: {vertical: 1}},
]);

O resultado do treinamento da rede é um objeto que traz informações do sucesso (ou não) do treinamento e do número de iterações feitas para treinar sua rede neural. O treinamento pode levar um tempo pois é aqui que o algoritmo da sua rede neural é calculado.

 

Fazendo a rede neural trabalhar

Agora vamos fazer a rede neural trabalhar! Depois de inputar informações que você sabia a resposta você pode colocar dados que você não saiba a resposta e deixar a rede fazer o trabalho dela.

var resultado = spongebob.run({w:50,h:400});

Cada run vai resulta um objeto com as prováveis respostas, no exemplo acima:

horizontal: 0.45137855383391234
vertical: 0.5486215106258696

 

É ou não magia negra?

Veja um demo do  BrainJS

3 Dicas de performance de CSS

O primeiro passo para se discutir a performance da renderização das páginas no navegador é entender como o navegador funciona.

Antes de continuar você deve entender os conceitos de browser reflow e browser repaint, pois nosso objetivo para ter uma página renderizada mais rapidamente é a redução dos reflows e repaints da página.

Como o navegador interpreta o CSS?

O navegador começa a leitura do CSS da direita para a esquerda, do nosso último elemento para o primeiro. Ele pega o seletor bem da direita, percorre todos os elementos do DOM que casem com este seletor e passar para o próximo seletor a esquerda, verificando os parents do seletor que ele verificou anteriormente (o bem da direita na sua linha de seletores).

Parece confuso mas na prática é simples. Para o código abaixo, por exemplo:

#content #menu ul li a

O navegador vai varrer todos os elementos "a" da sua página, depois ele vai verificar quais destes elementos estão dentro de um elemento li e assim por diante até encontrar o elemento #content.

Agora que você já sabe como o navegador trabalha vamos as dicas de CSS para páginas rápidas!

 

1. Escreva seletores curtos

Agora que você já sabe como o navegador percorre o seu seletor, já sabe quanto mais curto ele for menos será o caminho percorrido e consequentemente mais rápida a renderização da sua página.

Evite

#content nav#menu ul li a

 

Melhor performance CSS

.menu-item

 

Outro exemplo, em uma página com bastante conteúdo tabular:

Evite

table thead tr td

 

Melhor performance CSS

.header-table

 

2. Prefira classes e ids do que seletor por elemento

Quanto mais preciso seu seletor for menos elementos do DOM serão percorridos pelo browser, o seletor de tag tende a ser mais abrangente do que seletor de classe.

Evite 

h2.product-title

Melhor performance CSS

.product-title

 

Evite

nav#menu

Melhor performance

#menu

O navegador não precisa fazer 2 verificações para estilizar os elementos casados com a classe.

 

3. Evite seletor universal, por atributo e pseudo-selectors

Principalmente no IE evite os pseudo seletores como :hover, :nth-child e outros. O seletor universal percorre todos os elementos do DOM (por isso a baixa performance) e os pseudo seletores tem uma performance bem inferior do que qualquer seletor por classe ou id, então sempre que for possível evite seu uso.

Evite:

input[type="text"]

Não tão ruim:

input.texto

Melhor performance CSS:

.input-texto

 

Dica bônus: não enlouqueça

Não seja um paranóico, não deixe que as preocupações com performance de CSS prejudiquem (muito) a organização e leitura do seu código.

Se você trabalha em projetos com uma equipe grande em que todos estão acostumados a escrever seletores descritivos (e compridos) para facilitar o entendimento do código pode ser um pouco complicado fazer esta mudança, uma boa dica é estimular comentários no CSS – qualquer processo de minify arrancará os comentários e manterá o código enxuto.

 

Para saber mais sobre performance no front-end veja este post sobre performance de javascript e o recente post do Chris sobre manipulação do DOM de forma mais performática.

Se está na dúvida (ou não acredita no que escrevi), utiliza esta ferramenta para testar a performance de seletores CSS.

 

Referências:

Melhorando a performance do CSS

Escrevendo CSS eficiente

Google best pratices rendering

Mozilla – Writting effective CSS

Simplifying CSS selectors