DEV Community: Kevin Oliveira

Deixe seu frontend mais consistente com componentes positionless

Kevin Oliveira — Thu, 24 Aug 2023 19:17:45 +0000

Por mais que muita gente diga por aí que front-end é fácil, não é. E só nós pessoas de front-end sabemos disso, pois pode até parecer simples posicionar elementos com CSS numa tela, mas será que está sendo feito da melhor forma?

E são essas boas práticas que levam muito tempo para entrar na cabeça de uma pessoa iniciante, ter o conhecimento de como posicionar, alinhar ou separar elementos numa tela. E vou deixar meus cinco centavos sobre isso neste post.

Mas de onde surgiu o termo "positionless"?

Confesso que esse termo surgiu na minha cabeça (até pesquisei mas não encontrei nada) muito inspirado pelo termo "tableless" que foi uma revolução no desenvolvimento web há uns 15/20 anos quando devs largaram a mão de montar sites com tabelas e também pelo termo "stateless" que é basicamente ter componentes agnósticos livres de manipulação de estado.

E com isso o termo "positionless" veio justamente por pensar na boa prática de deixar componentes de um layout livres de qualquer regra CSS que manipule seu próprio posicionamento na viewport.

Como é uma tela sem componentes "positionless"?

Eu tenho certeza que em projetos pessoais no início de carreira ou até em projetos legados de alguma empresa que tenha trabalhado você já viu um código dessa forma com elementos posicionados hardcoded:

Exemplo de botão no header

<div class="header">
  <img src="logo.png">
  <a href="" class="button">Fale conosco</a>
</div>

.header {
  position: relative;
}

.button {
  position: absolute;
  top: 15px;
  right: 15px;
}

Ou até, também, numa lista de posts de um blog:

Exemplo de lista de posts

<div class="list">
  <div class="card">
    <img src="card-thumb.png">
    <h2 class="card-title">Título do post</h2>
  </div>
  ...
</div>

.card {
  margin: 10px;
}

Isso tudo se ainda não estiver com o estilo inline que deixaria tudo muito pior, né?

Repare nesses trechos de código que o posicionamento/separação dos elementos .button e .card estão cuidando do próprio posicionamento, seja com position ou com margin.

Mas agora pensa comigo, provavelmente esse button e esse card está sendo ou poderá ser utilizado em outras partes do site, certo? E se o posicionamento ou separação for diferente em outro lugar? Você vai sobrescrever esse código de que forma? Vai criar outra folha de estilo se for em outra página? Vai usar !important se for na mesma página?

Por que não deixar os componentes da sua aplicação agnósticos de posicionamento? Porque o problema não é usar position/margin/etc, isso são recursos que são feitos para serem usados em determinados casos, o problema é usá-los de forma errada que pode prejudicar todo o prosseguimento do seu desenvolvimento de layout.

Então que tal deixar a responsabilidade do posicionamento para o pai daquele componente específico? No exemplo do botão do header, aproveitando o HTML, podemos ao invés de usar position para jogar o botão para o lado direito do header alinhado ao logo, podemos fazer com flexbox dessa forma:

.header {
  display: flex;
  align-items: center;
  justify-content: space-between;
}

Ficando ainda melhor não só na questão de deixar a responsabilidade de posicionamento para o pai, mas também por não criar uma nova camada deixando o layout mais complexo para ser renderizado e manutenido.

E no exemplo da listagem de posts, deixando a responsabilidade de separação de cards para o pai podemos usar gap na lista ao invés do margin diretamente nos cards que estava afetando todos os cards da aplicação, dessa forma:

.list {
  display: grid;
  grid-template-columns: 1fr 1fr 1fr;
  gap: 10px;
}

"Mas e se eu precisar estilizar um elemento específico?"

Certo, pode ser que você realmente precise editar o posicionamento de algum elemento específico, mas pense uma forma que aquilo não afete as outras partes de seu layout e também que force tanto a especificidade, deixando tudo muito complexo.

Pense que uma vez que seu componente é agnóstico, ele pode ser incluído em qualquer lugar de seu layout e o pai/container dele que ficará responsável por isso, logo podemos fazer algo no sentido lá do primeiro exemplo:

.header .button {
  position: absolute;
  top: 15px;
  right: 15px;
}

MAS CALMA LÁ! É aí que você precisa repensar se essa é a melhor forma de se fazer isso, pois mesmo não afetando outras partes do site pode ter uma forma melhor e nesse exemplo específico, vimos que não, pois conseguimos posicionar o botão da forma que gostaríamos sem criar um segundo nível de especificidade, pois zero especificidade é melhor que uma especificidade.

Conclusão

Com tudo isso podemos ver o quão consistente nosso layout fica e também o tanto de recurso que economizados não tendo que sobrescrever estilos usando o horroroso !important ou criando especificidades desnecessárias que poderiam ser evitadas deixando a responsabilidade ao pai do seu componente.

Antes de começar a criar suas divs e seus style.css ou de começar a manutenção do site de qualquer forma, pense bem em como aquele elemento será reutilizado e no que outros lugares de sua aplicação poderá ser afetada com aquela nova edição ou adição.

Eu quero ouvir a opinião de vocês sobre isso nos comentários. That's all folks!

Referências para estudo

Como melhorar a nota no Google Pagespeed em sites WordPress

Kevin Oliveira — Sun, 28 May 2023 04:12:21 +0000

Fazer projetos no WordPress sempre dá muito trabalho para chegar numa nota legal no Google Pagespeed Insights, né? Se liga nessas dicas que vou passar.

Diversos fatores são necessários para que o Google Pagespeed Insights dê uma nota boa para seu site, várias destas métricas são atualizadas em alguns momentos e mesmo com essas dicas é sempre bom estar testando seu site na ferramenta da Google de tempos em tempos.

É bom ressaltar também que, além de nota no Google Pagespeed Insights, o mais importante mesmo é a experiência do usuário. E é o que a Google leva em consideração na hora de rankear seu site.

Claro que boa parte dessa nota é levando em consideração boas práticas de UX (User Experience), mas é bom pensar que não adianta seu site ter nota 100 se o seu usuário não conseguir utilizar seu site.

Dizendo isso, neste post vou explicar diversas dicas que utilizo diariamente em projetos WordPress para melhorar a performance e consequentemente a nota no Google Pagespeed Insights.

Introdução

Antes de tudo, é importante notar que o WordPress é uma ferramenta completa mas que também dá muito espaço para fazer coisas erradas, pois é muito fácil instalar vários plugins para fazer coisas simples que no final carregam diversos assets desnecessários.

Então a primeira dica é evite usar muitos plugins e quando for usar, pesquise bem o que esse plugin adiciona na raiz do seu site pois pode acabar prejudicando muito a performance.

Plugin de cache

Cachear e minificar seus assets é importantíssimo para uma melhor performance em seu site WordPress.

O plugin que mais dá resultado nos projetos que faço é o WP Fastest Cache.

Prefira font-face, estilos e scripts locais ao invés de CDNs

A facilidade de só adicionar um <link> do CDN é tentadora, mas é uma requisição e quanto mais requisições mais lento seu site fica. Pensando nisso, prefira sempre:

Baixar as fontes do Google Fonts e usar o transfonter.org para criar os estilos
Baixar os scripts e estilos por NPM e criar um bundle de vendors com Gulp ou Webpack

Dessa forma você evita requisições externas e deixa tudo a disposição do servidor, pronto para ser usado.

Faça preload dos arquivos de fontes

Importante para evitar quebras de textos no carregamento, o que gera uma piora na nota do CLS (Cumulative Layout Shift).

<link
  rel="preload"
  href="Roboto-Regular.woff2"
  as="font"
  crossorigin="anonymous"
/>

Lazy loading nas imagens

Carregue suas imagens por demanda com o atributo loading="lazy" em suas imagens

<img src="foto.png" loading="lazy" />

Adicione `width` e `height` nas imagens

Para evitar pioras notas no CLS é importantíssimo falar para o navegador qual o tamanho da imagem para que aquele espaço seja reservado na renderização antes da requisição da imagem.

<img src="foto.png" loading="lazy" width="800" height="600" />

Dessa forma o navegador já reservará os 800x600px da imagem e não ficará empurrando o conteúdo quando a imagem for requisitada.

Utilize imagens otimizadas e no formato webp

O formato webp é importantíssimo para um melhor carregamento de sua página em navegadores que já tem suporte para este formato.

Há alguns plugins que facilitam a conversão e otimização, os que eu mais tive resultado foram o WebP Express e EWWW Image Optimizer, este último conta com diversas possibilidades de integração com CDNs o que facilita na hora de utilizar outro servidor para hospedar suas imagens.

Reduza as queries

Muitas das funções WordPress geram queries, pois essas funções fazem buscas no banco de dados e nos retornam resultados.

Para ter uma performance melhor, ao invés de por exemplo, chamar várias vezes o título de um post com o get_the_title() prefira criar uma variável $title = get_the_title() e reutilize. Da mesma forma, invés de puxar várias vezes uma thumbnail com get_the_post_thumbnail_url(), crie uma variável $thumbnail_url = get_the_post_thumbnail_url() e reutilize. E assim com diversas outras funções, dessa forma você evita chamadas desnecessárias e além disso, código repetido.

Conclusão

Mas estas são apenas alguns dos pontos que deixam seu site WordPress mais leve e consequentemente com a nota melhor no Google Pagespeed Insights e para fechar saiba que cada caso é um caso, pois cada tema WordPress foi feito de um jeito, com muitos plugins ou com poucos plugins, temas comprados ou temas feitos, servidores bons e ruins.

Antes de procurar uma bala de prata verifique toda a condição daquele site e procure melhorar ponto por ponto. Melhorar a performance e a nota no Google Pagespeed Insights é um trabalho de formiguinha e tire da cabeça que você fará isso em um dia, é um trabalho recorrente, por isso tenha calma e vá refatorando aos poucos.

E, claro, salve este post nos favoritos pois sempre que eu descobrir coisas novas sobre performance no WordPress atualizarei este post.

That's all folks!

Evite conflitos em seus repositórios GIT

Kevin Oliveira — Sun, 28 May 2023 04:08:10 +0000

Você trabalha com mais de duas branchs nos repositórios GIT e sempre acaba com conflitos quando vai fazer merge de uma nova funcionalidade/ajuste?

Em projetos que possuem branchs para produção (geralmente "master" ou "prod) e homologação ("dev" ou "staging"), alguns cuidados devem ser tomados para criar uma funcionalidade, ou fazer um ajuste no código.

Crie sua nova branch a partir de master

A primeira dica é criar a sua nova branch (por exemplo "fix-button") sempre a partir da branch de produção, que é sua branch aprovada, que está no ar e atualizada:

$ git checkout master
$ git checkout -b fix-button

Agora sua nova branch foi criada a partir de master.

A partir disso, na sua branch "fix-button" faça os ajustes necessários e comite.

Suba sua nova branch para homologação

Estando tudo ok, é hora de subir esse ajuste na branch de homologação para aprovação do cliente:

$ git checkout dev
$ git merge fix-button

Agora seus novos ajustes estão na branch dev.

Dica de ouro para evitar conflitos

E é agora que vem a dica:

Uma vez que seus ajustes foram aprovados e podem ir para o ar, iremos fazer o merge da nossa branch "fix-button" diretamente para nossa branch "master".

Mas por quê?

Imagine que antes dos ajustes da branch "fix-button" tivemos outros ajustes ("fix-header", "fix-footer", etc) e todos estes ajustes estão no ambiente de homologação MAS: NÃO FORAM APROVADOS.

Não podemos fazer merge de "dev" diretamente para "master".

Se "dev" for para "master" diversos outros ajustes, que ainda podem estar sendo desenvolvidos ou que ainda não fora aprovados, podem acabar quebrando nosso ambiente de produção.

Por isso é perigosíssimo fazer merge da branch "dev" para "master".

Um breve resumo

Resumindo, prefira seguir o fluxo:

master <- fix-button
Faça os ajustes necessários em "fix-button"
fix-button -> dev
Aprove os ajustes em homologação
fix-button -> master
Delete a branch "fix-button"

Assim seu repositório ficará limpo e livre de conflitos.

Conclusão

Claro que esse fluxo de branch não vai te livrar definitivamente de todos os conflitos que podem acontecer em seus projetos.

Mas ter um fluxo claro de branchs em seu repositório deixa o desenvolvimento mais organizado e consequentemente teremos um processo com menos conflitos.

That's all folks!

Pedir ajuda é diferente de pedir para resolverem seu problema

Kevin Oliveira — Sun, 28 May 2023 04:03:42 +0000

Este artigo foi migrado de um post que fiz no grupo Front-End Brasil lá no Facebook{:target="_blank"}{:rel="noopener"}

Participo da comunidade front-end há alguns anos, antes mesmo de entrar na área, e não há nada que me deixa mais triste do que ver grupos — onde a galera deveria estar disseminando conteúdo de altíssima qualidade, ensinando e aprendendo — sujos com posts de pedidos que dizem, basicamente, “faz isso aqui pra mim”.

Antes que eu arranje mais treta que eu já tenho e vocês venham pra cima de mim igual esse ser aí em cima, quero passar um pano quente aqui dizendo que não é errado ser iniciante, aliás todos já foram e sempre serão em algo na vida — Sempre haverá aquele dia que tomaremos um banho de água fria quando acharmos que somos bons o suficiente em algo — mas deve haver o bom senso entre saber o que difere o “me ajuda” com o “faz pra mim”.

Copiar e colar código não fará você aprender

É triste pensar que muita gente cola um trecho de código no grupo, depois que alguém resolve, copia e cola na sua aplicação. Mas sinto-lhe dizer, a verdade dói e copiar e colar código não fará você aprender a programar.

E o que me deixa mais cabisbaixo (aqui toca a música do Chaves sozinho quando todo mundo foi pra Acapulco) é perceber que muitos não tentam entender o porquê daquele código pronto funcionar para não ter que pedir ajuda novamente num caso parecido, apenas comemoram e partem para a próxima.

Ou pior do que isso, antes de pedir ajuda não consegue dar uma googleada ver do que se trata o erro, como fazer aquela funcionalidade ou como ou porque aquilo funciona daquela forma.

Tenho certeza que, com o básico de lógica de programação ou bom-senso, você, formulando uma pergunta realmente construtiva (que pode, depois, ajudar o seu colega que tiver o mesmo problema), teria a luz da resposta antes de perguntar:

“Oi, galera! Eu queria saber como eu posso ativar uma classe só SE eu clicasse no bot…” — “se”? Eu acho que já ouvi falar disso…

Você realmente gosta de escrever códigos?

A primeira coisa que imagino quando vejo alguém jogando um bloco de código imenso num grupo (Não façam isso! Usem o Codepen), é que a pessoa não gosta de programar ou não tem paciência para exercer aquela função que exige paciência e capacidade lógica de resolver problemas.

Não sei vocês, mas a sensação orgasmática de resolver um problema sozinho sem copiar nenhuma linha de código é incrível. Pode ser a coisa mais besta, mas quem nunca resolveu algum problema sozinho e gritou “Aê p%R\$@, consegui resolver!”. Eu recomendo a vocês sentirem esse prazer pelo menos uma vez por dia.

“Ok, Kevin, ok. Você trouxe o problema mas e a solução?”

É claro que eu não poderia só trazer a polêmica e sair correndo (mas até que eu poderia…), por isso trago alguns links clichês para vocês consultarem antes de encherem os grupos, que deveriam ser de qualidade, de chorume e pedidos de esmola.

Coma a MDN (Mozilla Developer Network) com farinha: https://developer.mozilla.org/pt-BR/{:target="_blank"}{:rel="noopener"}
Use o Codepen e não cole mais código direto nos grupos, pelo amor de Deus: https://codepen.io{:target="_blank"}{:rel="noopener"}
Estude no apaixonante e mágico Codecademy: https://www.codecademy.com{:target="_blank"}{:rel="noopener"}
Estude com o Gustavo Guanabara e divirta-se aprendendo a programar: http://cursoemvideo.com.br/{:target="_blank"}{:rel="noopener"}

Acompanhe a tradução do Felipe Fialho{:target="_blank"}{:rel="noopener"} sobre: Como se tornar um herói Front-end{:target="_blank"}{:rel="noopener"}

Enfim, compartilhe sua opinião sobre o assunto nos comentários e vamos lutar por uma internet com menos chorume e mais conteúdo de qualidade.

That’s all folks!

Como NÃO ser um bom front-end

Kevin Oliveira — Sun, 28 May 2023 04:01:44 +0000

Quer ser um péssimo front-end? Neste post eu elenquei diversos pontos que farão você alcançar esta desgraça na sua carreira.

Nós, desenvolvedores, que estamos cercados por conteúdo sobre tecnologia todos os dias vemos diversas boas dicas de como nós tornarmos melhoras desenvolvedores, boas práticas e como conquistar a atenção da empresa dos sonhos. Não é mesmo?

O que ninguém fala (pelo menos eu nunca vi) é como não ser um bom desenvolvedor front-end, dicas do que te torna ruim nesta profissão e tantas outras coisas.

1. Não use GIT

Obviamente não usar GIT deveria estar aqui na primeira dica, por que em 2017, com tantas ferramentas cloud (leia-se Dropbox, Google Drive e One Drive), nós deveríamos utilizar um linha de comando rápida e leve que versiona nosso código com apenas três comandos? Ao invés de criar pacotes zipados e fazer o backup disso tudo na internet…

Não aceite quando seu colega disser para você clonar o repositório, onde já se viu ter que ficar baixando as coisas em CDNs de alta velocidade sendo que podemos armazenar tudo em simples pendrives?

E mais do que isso, nada de rodar *git pull origin <branch> antes de editar o projeto, faça o seu trabalho e o próximo que se vire com os conflitos.

2. Acessibilidade? O que é isso!?

Ter um site acessível a todos? Isso é coisa de comunista!

Não se preocupar com os cegos, surdos e deficientes motores é comum, ninguém faz isso para que gastar algumas horas antes de iniciar o projeto pensando em acessibilidade? E se for necessário mesmo, vemos isso depois, não é prioridade agora…

Vamos fazendo testes e se alguém reclamar, implementamos.

3. Fique no seu mundinho

Participar de eventos e ver gente que se acha o rockstar palestrando por quase/mais de uma hora te enche o saco, você está no caminho certo.

Conversar com outros devs, aprender nas conversas e socializar tomando uma cerveja realmente não deve ser legal. Até porque, na maioria das vezes, as pessoas falam muito e ficar no silêncio do quarto escuro com o shell aberto é bem melhor.

4. Não fale sobre o que você sabe

O que mais assusta você é que alguém faça você ensinar ela a fazer alguma coisa, certo? Realmente é complicado ter tantos anos de estudo e, de graça, ensinar as pessoas a saberem sobre certa tecnologia também.

Até porque o conhecimento foi feito para ser guardado e não queremos correr o risco de perder nosso emprego para alguém que pode vir a saber mais do que nós, certo? Pois é, é perigoso…

5. Não aceite novas tecnologias

Todo dia um novo framework JavaScript, por que esses caras não fazem outra coisa, não é?

Não aceitar novidades do mercado faz você estar muito bem posicionado nessa lista, até porque a linguagem não deve evoluir, ela tem que servir apenas para resolver o seu problema e deixar você na sua zona de conforto do conhecimento.

6. Ser intolerante é engraçado

Programação é coisa de homem, né? Como é que pode uma mulher sair do lugar dela e vir querer roubar nossos trabalhos. Pensar assim te dá uns belos pontos nesse lista. É isso aí, você está chegando ao topo!

Pessoas que não sabem tanto quanto você são inferiores, mas talvez elas consigam tomar seu emprego. Por isso é importante ter cuidado, né?

Você acha que a minoria quer muitos privilégios e tratamentos especiais? Opa, chefe! Boa, ganhou uns pontos.

7. Reinvente a roda sempre, custe o que custar!

Soluções criativas já foram inventadas, mas já que eu sei para que vou colocar o script de outra pessoa no meu código se eu posso fazer isso?

Esse meu projeto não é open source, mas vou me basear em outros para fazer um e utilizar só em projetos próprios.

8. Nunca programe de graça

Programar de graça é um absurdo, não é mesmo? Tantos anos investindo na minha carreira com estudos e noites mal dormidas para programar algo open source?

Tudo bem que eu utilizo Linux, faço back-end com PHP e uso Atom que são programas open source, mas eu não programo de graça!

E mesmo que meu projeto open source possa me trazer visibilidade no mercado e entrar numa grande empresa, open source é só para otários.

9. Foque nos frameworks, saber o básico é para os fracos

Seguindo a dica, muito bem observada, do amigo Daniel Tapias, o negócio hoje em dia para estar bem rankeado como um front-end ruim é manjar de todos os novos frameworks mas não conseguir resolver um problema simples de CSS, até porque saber o básico é para os fracos.

Como não é programação, CSS é coisa para quem é júnior, um bom front-end precisa saber de React com flux, redux, mastrux…

10. Não ajude a comunidade a crescer

Sabe aquele seu amigo/amiga que está começando a desenvolver, dando os primeiros passos como dev? Então, para que ajudar eles? Ele só vai ser um concorrente seu, não é mesmo? Até porque quando você começou ninguém te ajudou, você é autodidata demais, nunca entrou num StackOverflow, nunca abriu um tópico num fórum com dúvidas, nunca olhou a documentação de algo na MDN (até porque a MDN se escreve sozinha). Logo, se ninguém nunca te ajudou, não tem por que ajudar os outros, né?

Se quer destruir sua carreira como front-end é uma ótima dica também, complementando a dica #4, não apontar o caminho das pedras, não indicar livros nos quais você teve facilidade em aprender, não indicar vídeos nos quais as dificuldades da profissão cairam por terra, não indicar cursos que você teve outro pensamento e descobriu novas formas de fazer as coisas.

Acho que esse é o caminho certo, faça isso mesmo.

E está constatado: seguindo duas ou três itens dessa lista você já será considerado um developer ruim, por isso persista e não desista!

São bastantes os pontos que tornam você um desenvolvedor front-end ruim. E essa lista pode, e irá, aumentar!

Inspirado no post 15 Dicas Infalíveis para Destruir Implacavelmente sua Carreira do Daniel Orlean, usarei a frase:

O seu "Insucesso" só depende de você!!!

Como contribuir em projetos open source sem codar?

Kevin Oliveira — Sun, 28 May 2023 03:57:12 +0000

Não é só de código que vive o dev, mas também de toda ajuda de bom coração

Muitas vezes, principalmente quando estamos começando, é difícil conceber ideias ou contribuir com projetos open source já existentes na internet, não é mesmo? Mas saiba que não é só de código que vive o dev.

Eu já passei por dilemas, e ainda passo — e acho que alguns de vocês também, onde chego em um projeto top e penso:

Eu poderia contribuir com isso, né? Seria massa… Mas não tenho conhecimento com essa tecnologia.

O GitHub é o antro de projetos que podem mudar o mundo e não contribuir com isso, de alguma forma, pode vir a ser um desserviço à comunidade open source. Por isso, se você não tem conhecimento técnico de programação, para contribuir com esses projetos vou dar algumas dicas do que você pode fazer para ajudar:

Contribua com as documentações

Sabe aquele mesmo projeto sensacional que você achou? Dê uma lida no readme.md e repare se o conteúdo está escrito da melhor forma, se o documento está condizente com as funcionalidades, faça revisões de gramática, melhorias na descrição dos links, crie um sumário e veja se o mesmo não necessita de uma tradução.

No caso da tradução, é fato que saber inglês é fundamental para qualquer ser humano, mas isso não quer dizer que não devemos ter conteúdos em português em projetos open source, temos que manter nosso idioma ativo e vivo.

Ache bugs e abra issues

Sou do tipo que “me venha com o problema, mas traga também a solução” e acho que muitos também pensam assim.

Por isso, caso você não saiba como resolver aquele bug que achou testando o app, é extremamente importante relatar isso através das issues do projeto detalhando onde e como achou aquele problema e, talvez, como aquilo poderia ser resolvido.

Abra discussões de como o projeto poderia evoluir

Através das issues você também pode iniciar discussões, como num fórum (veja o fórum da Open School Brasil), de como o projeto evoluir, quais os próximos passos poderiam ser tomados, ideias de novas features, design etc. Isso daria bastante pano para mangas e, a comunidade envolvida no projeto, a possibilidade e inviabilidade de implementar tais coisas.

No caso do design do projeto tenho dois exemplos meus, onde inciei através das issues, discussões para a nova identidade visual da comunidade Front-end Brasil e a discussão para a definição da marca Open School Brasil. Essas discussões geraram amizades e bons frutos.

“Não é só de código que vive o dev”

Escreva artigos para a comunidade

Da mesma forma que não é só de código que vive o dev, também podemos contribuir fora do GitHub e não viver só de commits, escrevendo artigos para a comunidade.

E a iniciativa Poste mais! da comunidade Front-end Brasil gera muitos frutos e conteúdos para a comunidade, como este artigo que estou escrevendo com base na issue #46 do Danilo Vaz.

Por isso, contribua com a comunidade, escreva artigos. Siga estes passos e faça o open source crescer.

That's all folks!

DEV Community: Kevin Oliveira

Deixe seu frontend mais consistente com componentes positionless

Mas de onde surgiu o termo "positionless"?

Como é uma tela sem componentes "positionless"?

"Mas e se eu precisar estilizar um elemento específico?"

Conclusão

Referências para estudo

Como melhorar a nota no Google Pagespeed em sites WordPress

Fazer projetos no WordPress sempre dá muito trabalho para chegar numa nota legal no Google Pagespeed Insights, né? Se liga nessas dicas que vou passar.

Introdução

Plugin de cache

Prefira font-face, estilos e scripts locais ao invés de CDNs

Faça preload dos arquivos de fontes

Lazy loading nas imagens

Adicione width e height nas imagens

Utilize imagens otimizadas e no formato webp

Reduza as queries

Conclusão

Evite conflitos em seus repositórios GIT

Você trabalha com mais de duas branchs nos repositórios GIT e sempre acaba com conflitos quando vai fazer merge de uma nova funcionalidade/ajuste?

Crie sua nova branch a partir de master

Suba sua nova branch para homologação

Dica de ouro para evitar conflitos

Mas por quê?

Um breve resumo

Conclusão

Pedir ajuda é diferente de pedir para resolverem seu problema

Copiar e colar código não fará você aprender

Você realmente gosta de escrever códigos?

“Ok, Kevin, ok. Você trouxe o problema mas e a solução?”

Como NÃO ser um bom front-end

Quer ser um péssimo front-end? Neste post eu elenquei diversos pontos que farão você alcançar esta desgraça na sua carreira.

1. Não use GIT

2. Acessibilidade? O que é isso!?

3. Fique no seu mundinho

4. Não fale sobre o que você sabe

5. Não aceite novas tecnologias

6. Ser intolerante é engraçado

7. Reinvente a roda sempre, custe o que custar!

8. Nunca programe de graça

9. Foque nos frameworks, saber o básico é para os fracos

10. Não ajude a comunidade a crescer

Como contribuir em projetos open source sem codar?

Não é só de código que vive o dev, mas também de toda ajuda de bom coração

Contribua com as documentações

Ache bugs e abra issues

Abra discussões de como o projeto poderia evoluir

Escreva artigos para a comunidade

Adicione `width` e `height` nas imagens