Como é programar em JavaScript em 2016

Esse artigo é uma tradução totalmente livre e adaptada de “How it feels to learn Javascript in 2016”, publicada na Hackernoon. Provavelmente nenhuma nova biblioteca foi criada enquanto esse artigo estava sendo escrito. Ou não.

Era uma terça-feira e chovia muito. Numa conversa entre dois amigos, um desenvolvedor frontend e um backend…

Man, seguinte, eu peguei um freela aí de um projetinho web pra dar uma ajuda nas finanças, sabe como é…

A crise tá foda, né?

Então… Mas como você sabe, faz um bom tempo que eu não mexo com web e ouvi muito sobre as mudanças que rolaram nos últimos tempos. Tô ligado que você manja muito do rolê de ser webdesigner, né?

O termo atual é “Engenheiro Front End” mas sim, é isso mesmo. Mudou bastante. Dá pra fazer tudo com JavaScript, acabei de voltar da BrazilJS e, cara, nunca me senti tão bem em conhecer o que há de mais novo na web. Dá pra fazer de players de música com aqueles visualizers foda e até controlar drones. A gente consegue fazer o que a gente quiser com JS, o céu é o limite.

Ler o post completo

O Ionic 2 RC saiu! Seu @App acabou de quebrar (de novo)!

Meu Webpack está MORTO, tens o que é necessário para esmagar o meu Rollup?

Nada como um Release Candidate para por um sorriso na cara de quem tá trabalhando com betas. Só quem viveu sabe as imagens de dor e sofrimento das últimas atualizações do Ionic 2. Mas tudo compensa pra ver um projeto como esse crescer.

Vamos falar um pouquinho das mudanças desse RC0, que olha, não foram poucas.

O Angular 2 final está entre nós

Se tá liberado, vamo usar valendo! A gente já usava sem liberar, agora só tá organizado: as APIs estão finalizadas. Além disso, veio de brinde o @NgModules pro Ionic, que permite a gente escrever apenas uma vez algumas coisas que a gente tinha que repetir pra cada @Component, como por exemplo os providers.

Ler o post completo

Regras de negócio no Firebase (ou quase)

Porque ele é mais do que um Banco de Dados que atualiza sozinho.

O Firebase é poderoso e acho que todo mundo hoje em dia está de acordo com isso. A versão 3.0 mostrou que não tá aí de brincadeira e já tem uma galera topster usando em produção.

Mas se tem uma coisa confusa sobre o Firebase é sobre como a sua segurança e regras funcionam. Quem tá acostumado com um CRUD clássico, onde ele escreve as regras e validações antes daquele conteúdo que o usuário criou ir pra o banco de dados.

Alguns acham que a validação e implementação de regras de segurança devem ser do lado do frontend. Mais absurdo que isso, apenas aqueles que acham que o Firebase não faz qualquer verificação, e qualquer um que conseguir o conjunto de chaves vai pintar e bordar com seu backend.

Trago boas novas. É compreensível a dúvida já que praticamente todo conteúdo que existe sobre Firebase é demonstrando como fazer get e set de variável, e mostrando como é fofinho mudando os valores em tempo real. Quantas vezes eu não ouvi que o Firebase é top pra fazer um Dashboardzinho, mas pra projeto “de verdade” precisa de banco de dados “de verdade”. Parece até um eleitor do Trump falando (ou talvez do Dória).

Vem conhecer o Firebase Rules.

Ler o post completo

Fira Code: a fonte perfeita pra você codar

Seu editor de código nunca mais vai ser o mesmo. Juro pra tu.

Quando eu não tô fazendo nada, vez por outra, eu gosto de procurar Fontes na internet. Cada fonte tem uma personalidade própria e única, tal qual o nosso próprio manuscrito. Além disso, elas são os “cartões de visita” de um texto ou marca, já que só de ver (sem precisar ler) já avaliamos o conforto e coerência de determinada palavra dependendo da Fonte a qual ela é escrita. Ver um texto ou logo em Comic Sans já te faz refletir sobre as escolhas vida, não faz?

Falar sobre fontes renderia assunto até não acabar mais. Porém, para desenvolvedores (especialmente os da Web) existe uma propriedade com a qual todos tratam — ou certamente já ouviram o termo — quando estão trabalhando com fontes: a serifa.

Certamente você já deve ter ouvido falar dos termos “sans-serif”, “serif” ou “monospace”, não? Os dois primeiros estão relacionados à serifa do texto, que nada mais é do que a “perninha” que prolonga as hastes de cada letra.

A Helvetica, por exemplo, é uma fonte não serifada, sans-serif. Ela não tem as perninhas.

A Times New Roman, por exemplo, é uma fonte serifada, serif. Ela tem perninhas.

Ao lado estão as perninhas destacadas em vermelho, para ficar mais claro.

Cada uma tem seu uso próprio e utilidade. Eu te desafio a citar 5 marcas que usam fontes com serifa no logo. Por outro lado, também te desafio a citar 5 jornais que usam fontes sem serifa para os textos das notícias.

Fontes sem serifa são notoriamente mais belas a nossos olhos, e mais marcantes. Por outro lado, fontes com serifa são mais confortáveis para uma longa leitura. Não é a toa que exatamente esse texto, que você está lendo agora, tem um título com fonte não-serifada e possui todo corpo com uma fonte serifada.

Mas para nós, desenvolvedores, ainda estamos acostumados a lidar diariamente com outro tipo de fonte: a mono-espaçada.

Fontes mono-espaçadas são auto-explicativas: todos os caracteres possuem o mesmo tamanho. Inventaram isso com a máquina de escrever: ela sabia que, a cada caractere digitado, tinha que mover o cabeçote sempre a mesma distância. Os computadores roubaram as fontes mono-espaçadas pela imensa limitação que os primeiros monitores tinham, então era muito mais fácil de programar sabendo quantos pixels cada fonte iria ocupar na tela.

E, pra programação, texto mono-espaçado tem uma vantagem a mais: como quando estamos desenvolvendo, estamos trabalhando com vários símbolos fora do padrão de nossa escrita tradicional, utilizar fontes que têm os caracteres de mesmo tamanho contribuem muito na legibilidade, mais do que qualquer outra fonte serifada.

Mas, porém, contudo, todavia, entretanto… Fontes mono-espaçadas não são as mais eficientes para a exibição de caracteres, principalmente quando a gente precisa combinar símbolos, se perde muito espaço de tela.

Pensando em resolver um problema que a gente não sabia que tinha, fizeram a Fira Code.

A Fira Code, como tudo que é bom, quebra algumas regras pra conseguir seu objetivo. Ela é uma fonte mono-espaçada, travestida de fonte sem-serifa, porém com uma propriedade muito interessante de fontes serifadas: a ligadura.

As ligaduras tipográficas nasceram no nosso manuscrito tradicional, pois somos preguiçosos: por que que eu vou usar mais de um caractere se eu posso fazer um só? O símbolo ‘&’ nada mais é do que a representação de et, porém sendo traçado com uma única reta (tenta fazer no papel, ‘Et’, com uma reta só). Nunca te contaram isso antes, né?

E justamente nos símbolos, a Fira Code usa essas ligaduras para transformar dois símbolos num terceiro. Pra entender melhor, veja esse print printoso de um código JavaScript:

Repare como !! ocupa seu espaço de maneira mais distribuída que a fonte que você tá usando agora no seu Editor ou IDE. Olha o ==, como tá show sendo um simbolo só? E como não amar o <=, também representado apenas por um caractere?

Se você curte drogas mais pesadas, se liga nesse print de Clojure:

Fica até mais claro, mesmo sendo Clojure!

O melhor de tudo é que a Fira Code é Open Source e completamente gratuita.

Ela é compatível com um monte de Terminais, Editores de Texto e IDEs, tá tudo lindamente documentado aqui no GitHub deles: https://github.com/tonsky/FiraCode

Tire 20 minutos do seu dia de hoje para baixar a Fira Code e configurá-la no seu terminal e no seu editor de texto. Garanto que sua experiência de programação vai melhorar. Se não melhorar, eu devolvo seu dinheiro.

Me agradeça depois.

Material Design no Ionic 2, na força bruta

Como definir o Material Design como padrão, mesmo no iOS, modificando Config do seu @App

O Ionic 2 é lindo. Sério. Principalmente nos seus componentes feitos usando os princípios do Material Design. Diferente do Ionic 1.x, onde teríamos que utilizar alguma biblioteca como o Ionic Material, tudo já vem prontinho de fábrica pra a gente aproveitar.

Claro que os temas para iOS e Windows também estão lá, nada mudou. Mas se você está fazendo toda sua identidade visual baseada no Material, provavelmente você irá querer manter essa consistência entre plataformas.

Fazer isso no Ionic 2 é bem simples, utilizando o Config do módulo ionicBootstrap, que está no pacote ionic-angular:

import { ionicBootstrap } from ‘ionic-angular’;

O ionicBootstrap é equivalende ao Bootstrap do Angular 2, que “avisa” qual componente será o root da nossa aplicação. Ele já está devidamente importado e chamado no app/app.ts do seu aplicativo.

Vá para a última linha, e lá estará ele:

ionicBootstrap(BitBar);
// Por sinal, você já baixou o BitBar?

O ionicBootstrap recebe (até) três parâmetros, o componente Root, os Custom Providers e o objeto Config. É deste último que iremos tratar no dia de hoje.

Config

O Config nada mais é do que um simples objeto onde definimos determinadas propriedades. A primeira coisa é adiciona-lo ao Bootstrap:

ionicBootstrap(BitBar, [], {});
// O Config é o terceiro parâmetro, então estamos passando um array vazio no parâmetro do Custom Providers. Trataremos dele em outro post.

Para implementarmos a ideia original do post, basta definirmos o mode como “md”:

ionicBootstrap(BitBar, [], {
  mode: 'md'
});

Prontinho! Estamos avisando ao Ionic que queremos que o modo sempre seja o Material, independente da plataforma real do dispositivo utilizado.

Esse é só um exemplo do que o Config é capaz. Podemos por exemplo, forçar com que as abas apareçam sempre no topo, é só fazer isso aqui:

ionicBootstrap(BitBar, [], {
  mode: 'md',
  tabsPlacement: 'top'
});

Quer usar o Material, mas acha os Ícones do iOS mais bonitinhos?

ionicBootstrap(BitBar, [], {
  mode: 'md',
  iconMode: 'ios'
});
// Atenção, não é porque você pode que você deve.

Na documentação oficial do Ionic 2 existem inúmeros exemplos de como podemos utilizar o Config para manipularmos nosso App. Mas lembrem sempre, crianças, com grandes poderes vem grandes responsabilidades.

Pin It on Pinterest