DEV Community: Marcos Felipe

Faculdade não é sobre escrever bons códigos

Marcos Felipe — Thu, 17 Feb 2022 23:14:12 +0000

Quando falamos especificamente da carreira de uma pessoa que irá escrever códigos, é comum pensarmos que ao sairmos da faculdade iremos ter aprendido a escrever os melhores códigos possíveis e estaremos prontos para o mercado de trabalho, mas isso é falso. E isso não é culpa da faculdade.

Se fizermos uma pesquisa simples "para que a faculdade serve" no Google, iremos encontrar vários posts de faculdade em seus blogs dizendo basicamente que tem o objetivo de aumentar as oportunidades profissionais, seja possibilitando ser um diferencial no mercado de trabalho ou trazendo experiências enriquecedoras. É totalmente esperado em nossa área uma pessoa que ainda está na faculdade ou acabou de terminar ainda esteja apenas no começo de sua caminhada, afinal tem bastantes coisas que elas precisam aprender sobre o mundo "real" que provavelmente não foram ensinadas na faculdade, e que talvez nem deveriam ser.

Recentemente temos visto cada vez mais essa discussão de "faculdade compensa?" aparecer na bolha dos programadores. O problema está quando pessoas que são ouvidas por quem está começando na área diz simplesmente "não compensa" ou começa a colocar em cheque todos os ensinamentos das faculdades com questões que deveriam ser bem mais complexas.

O código ruim da faculdade

Conforme a faculdade vai nos ensinando como programar, vamos tendo contato com vários trechos de códigos que podem fugir um pouco da realidade do mundo "real". Dificilmente veremos as melhores abordagens para aqueles ensinamentos.
Já em outra perspectiva, se pegarmos vários cursos disponíveis na internet (seja de graça no YouTube, ou na Udemy) para quem está começando, é bem provável que teremos um tópico só para boas práticas ou simplesmente ouviremos mais cedo termos como: SOLID, Clean Code, etc.
Essas duas perspectivas parecem demonstrar muito bem o mundo real, certo? Na verdade, as coisas são um pouco mais complexas que isso.

O primeiro ponto é que é possível sim ter contatos com esses termos na faculdade, mas provavelmente em momentos diferentes, e mesmo que não tenhamos, isso não deveria ser um ponto que desmerecesse a faculdade (falaremos disso melhor depois).

O segundo ponto é que muitas vezes quando pegamos esses códigos que seguiriam más práticas e tentamos comparar com o que seria o ideal, excluímos o contexto de onde aquele código foi usado.

Por exemplo, se formos apresentados a um código em Java que conecta no banco de dados, porém está suscetível à SQL Injection, e simplesmente compararmos com o que o mercado espera, com certeza podemos ser induzido a acreditar que aquele código não prepara o profissional para o mercado. Mas fazer isto é bastante desonesto, porque sem o contexto daquele código fica difícil saber onde foi utilizado, afinal ele pode ter sido utilizado para introduzir programação com banco de dados, ou em uma prova falando para não fazer desta maneira, ou como exemplo de más práticas.

Quando eu fazia faculdade eu já trabalhava na área, e isso me ocasionou um evento que me lembro até hoje que consegue exemplificar muito bem esta cultura do reduzimento da faculdade. Eu estava em uma aula de Banco de Dados e o professor estava ensinando a criar funções, durante um exercício eu usei a abordagem de early return, quando o professor viu aquilo ele me questionou dizendo que não era o ideal fazer desta maneira. Mesmo eu não concordando com seus argumentos até hoje, o ponto foi que eu lembro de me sentir superior por saber mais boas práticas que ele, e com isso eu questionava todos seus conhecimentos sobre isto, afinal se ele não sabia uma coisa tão simples assim, então provavelmente eu saiba mais que ele.

Agora pegando este professor como exemplo, por ele não saber essa boa prática, ele está ensinando errado? Não. Com toda certeza ele tem mais conhecimentos abrangentes na área do que eu. Ele sabe qual o caminho deve ser traçado para os alunos terem um conhecimento base para lidar com Banco de Dados. Várias pessoas aprenderam a criar funções naquele dia, mesmo sem o early return.

Simplesmente não faz sentido esperarmos que veremos sempre boas práticas (mesmo que de segurança) a todo momento, afinal o caminho do aprendizado é tão importante quanto a chegada. Existe uma estrada bem grande entre ensinar Java e conexão com banco de dados até a introdução à SQL Injection. E mesmo que a faculdade não te ensine que aquele código em Java é ruim (ou o que é early return), é bem provável que você esteja mais preparado a entender os problemas do que se tivesse pulado para o final (onde o código já segue todas essas abordagens).

Referência é importante para se ter qualidade. Um código que segue boas práticas só existe porque sabemos quais são às más práticas.

Não é só código

Até o momento só falamos especificamente sobre código e boas práticas. Mesmo explicando que até neste pilar, as coisas podem ser mais complexas, existem outros pontos esquecidos quando criamos estas comparações.

A grade curricular de uma faculdade geralmente abrange muitos outros tópicos que os cursos não cobrem, como: Algoritmos, Estrutura de Dados, Matemática Discreta, Cálculo, entre outros. Obviamente conseguimos encontrar cursos onlines sobre esses mesmos assuntos, entretanto essa decisão do que é necessário estudar é muito mais difícil para quem está começando na área e na maioria das vezes a pessoa só se dá conta que precisa aprender algo assim depois de uma boa caminhada.

Sempre vão existir pontos contra esses assuntos, como utilizar linguagens mais acessíveis para se ensinar estrutura de dados, ou o que poderíamos fazer preparar melhor o profissional, e para todas elas eu não tenho uma resposta, o que eu tenho apenas é a demonstração que o cenário é muito maior do que simplesmente pegar uma experiência sem contexto e utilizá-la para influenciar pessoas ou gerar tretas.
Isso comparando em um cenário onde estas duas situações são possíveis, entretanto muitas vezes nem todos tem a oportunidade ou o tempo livre para estudar por conta própria, pois isso pode necessitar de uma internet de qualidade, conhecimento prévio do que é necessário, ou meramente de um notebook.

Outro pilar importante é o do mercado de trabalho. Como já entendemos muito bem, às vezes a faculdade não nos prepara 100% para o mundo corporativo, porém podem existir situações onde a mesma pode ser um fator decisivo entre uma vaga. É bem provável que em uma concorrência entre pessoas da mesma qualidade técnica a faculdade possa ser um diferencial para um.

O preço é diferente

Ao começarmos a percorrer nossa caminhada nesta área de desenvolvimento de software, é regular esquecermos dos caminhos já percorridos. Podemos concluir que certas abordagens em nossa área são ruins porque conseguimos compará-las com experiências passadas. Conseguimos entender melhor certas situações devido a referências passadas. Porém, é muito difícil conseguir visualizar este caminho de referências, e muitas vezes não conseguiremos, mas considero um exercício muito importante para quem está no processo de mentorar pessoas.

É preciso ter cuidado para não aceitar conselhos de quem não vai pagar o mesmo preço que você.

Cada decisão tem um peso diferente para cada pessoa, para algumas pessoas não fazer ou não uma faculdade não faz diferença, para outras pode ser um desejo pessoal ou da família (como é o meu caso), então decidir ou não uma coisa desta tem muito mais a ver com você, afinal o preço a pagar de suas decisões não são o mesmo de quem aconselha.

Então eu devo fazer?

Se você chegou até aqui decidido a fazer faculdade devido aos pontos levantados aqui e acredita que os cursos são ruins, então creio que não consegui explicar muito bem a minha ideia.

Primeiramente, os cursos são muito importante, pois na maioria das vezes, complementam aquilo que não é ensinado na faculdade e podem ser uma maneira muito rápida de se aprender algo de maneira correta. Além disso, em certas situações o investimento para se realizar vários cursos é bem menor que o de terminar uma faculdade.

Também existem cursos para quem realmente está dando os primeiros passos e não sabe por onde começar e podem entregar um resultado muito mais rápido, este resultado pode ser um emprego, um conhecimento necessário para o que você realiza hoje, entre outras coisas.

Fazer ou não fazer faculdade é algo que envolve muitas variáveis.

Pode ser que ter uma faculdade concluída para você seja uma realização pessoal muito importante. Ou pode ser que você não consiga investir o tempo e dinheiro necessário para isto. Você também pode estar precisando de um emprego muito rápido e talvez os cursos consigam te entregar este resultado mais rápido.

E qual seria o meu conselho? Se você puder, faça tudo. É sempre bom ouvir conselhos e ter mentorias com pessoas mais experientes, mas saiba que a única verdade que temos nessa área é que não existe bala de prata (nem para seus estudos, nem para suas escolhas de carreiras, nem para as tecnologias que você deve trabalhar).

Espero que isso te ajude de alguma forma.

Twitter: https://twitter.com/omarkdev
Github: https://github.com/omarkdev

Design Patterns: Null Object

Marcos Felipe — Tue, 14 Apr 2020 14:49:48 +0000

Nada resultará em nada

Copo vazio — Matthew Bowden

É muito comum criarmos métodos que possam retornar valores nulos em determinadas situações onde a informação requisitada não está presente ou algumas condições não são atendidas para executar determinada lógica de negocio. Ao utilizar essa abordagem, pode ser necessário criar verificações do código para garantir que eles não sejam nulos antes de chamar algum método ou obter algum estado, pois normalmente não é possível chamar métodos em referências nulas. Muitas pessoas chamam isso de “programação defensiva” e como consequência acabam criando verificações quando intuitivamente não fazem sentido, mas isso demonstra que na verdade o que acontece é que o controle do código foi perdido.

Os problemas de se essa abordagem não é algo novo em nossa área, tanto que Tony Hoare em sua apresentação na QCon Lodon 2009 chamou isso de “erro de bilhões de dólares” e pediu desculpas por inventar a referência nula.

I call it my billion-dollar mistake. It was the invention of the null reference in 1965. At that time, I was designing the first comprehensive type system for references in an object oriented language (ALGOL W). My goal was to ensure that all use of references should be absolutely safe, with checking performed automatically by the compiler. But I couldn’t resist the temptation to put in a null reference, simply because it was so easy to implement. This has led to innumerable errors, vulnerabilities, and system crashes, which have probably caused a billion dollars of pain and damage in the last forty years.

— Tony Hoare

Quando falamos especificamente sobre orientação a objetos, trabalhar com referência nula pode ser um problema um pouco mais complexo quando analisamos o design do nosso código. Steve Smith (entre alguns outros programadores) defende no artigoNulls Break Polymorphism em seu blog que ao utilizar referência nula nós quebramos o polimorfismo e violamos o princípio da substituição de Liskovdo SOLID.

Mas não pense que esse problema de referência nula é uma particularidade apenas de linguagens orientada a objetos. No artigo Top 10 JavaScript errors from 1000+ projects (and how to avoid them) que está no blog da empresa Rollbar, podemos ver que 8 dos 10 erros são problemas de nulos e indefinidos.

São várias as possibilidades que tentam ajudar resolver esse tipo de problema, uma delas é o design pattern Null Object.

A ideia básica

O Null Object é um design pattern que utiliza herança para criar representações válidas de um dado de valor null. A intenção desse padrão é fornecer uma alternativa ao objeto original, oferecendo uma assinatura igual sem estado e comportamento.

Utilizando esse padrão ao invés de a todo momento termos que escrever verificações do código antes de realizar uma operação, podemos criar uma representação não funcional do objeto esperado. Essa representação tem a mesma assinatura do objeto esperado, em linguagens orientada a objetos isso é possível implementando a mesma interface ou estendendo a mesma classe (muitas vezes abstrata) e já em linguagens que seguem outro paradigma, basta ele ter a mesma assinatura.

Esta forma ajuda a evitar alguns efeitos colaterais e facilita um pouco a codificação pois não precisa tratar casos que são exceção à regra. Além disso essa forma tende a seguir um pouco mais a orientação a objetos, pois fornece abstrações em cenários desconhecidos.

Agora vamos imaginar uma situação onde o nosso cliente precisa fazer log de algumas informações, porém cada ambiente deverá ter um alvo de log diferente, sendo que o ambiente de produção não terá log nenhum e o ambiente de desenvolvimento utilizará o log por console. Quem será responsável por decidir qual log será utilizado é uma factory. Seguindo a abordagem inicial, quando o ambiente for de produção onde não deverá existir log, basta retornar null. Teríamos algo mais ou menos assim:

No exemplo, temos a interface Logger que representará todos os tipos de logs, temos também a factory LoggerFactory responsável por decidir qual mecanismo de log criar baseado no ambiente e que pode retornar null e por último a classe Client que utiliza a factory e faz uma verificação para ver se é null.

Com esse exemplo extremamente simples podemos notar algumas coisas:

Todo lugar que for utilizar a factory terá que criar uma verificação se o resultado é de valor nulo;
Não é de responsabilidade do cliente saber se é nulo ou não, ele apenas quer logar suas informações;
Ao escrever alguns testes para a classe Client teremos alguns casos a mais para tratar essa exceção.

Podemos ver que para a nossa necessidade a possibilidade de se obter nulo é um efeito colateral desnecessário e problemático. Para solucionar isso podemos ter a seguinte solução:

Analisando o nosso exemplo, deduzimos e comparamos com o exemplo anterior o seguinte:

O Client utiliza o LoggerFactory para criar a instancia do mecanismo de log, assim como no exemplo anterior;
A factory LoggerFactory é capaz de criar apenas instâncias de Logger , diferente do exemplo anterior que poderia criar Logger e null;
A interface Logger define o contrato que o cliente utilizará, assim como no exemplo anterior;
A classe ConsoleLogger implementa a interface Logger e provém um comportamento funcional, assim como no exemplo anterior;
A classe NullLogger implementa a classe Logger e provém um comportamento neutro, diferente do exemplo anterior onde não existia essa classe.

Analisando o diagrama, podemos ver que pouca coisa realmente mudou, mas ao escrevermos logo de cara é visível as mudanças.

Vendo o resultado, conseguimos compreender que agora para o Client pouco importa se realmente a informação será logada ou não, ele apenas confia que a factory retornou o que é necessário para aquela ação naquele contexto e agora quem for utilizar a factory apenas terá a mesma confiança, além disso vemos também que diminuímos os casos de testes pois não tem mais uma exceção lógica. Resumidamente, resolvemos os 3 problemas descritos anteriormente.

Quando usar

Assim como qualquer abordagem que utilizamos em nossa área, cada uma tem seus casos de uso para determinar quando usar, afinal cada uma tenta resolver problemas específico. Saber quando usar algo é um ponto fundamental na carreira da pessoa programadora, pois é isso que determina o caminho para se solucionar o problema proposto.

Deveríamos usar o padrão Null Object, apenas quando o cliente verificaria nulo apenas para pular a exceção ou executar uma ação padrão, dizKrzysztof Woyke em seu artigo Introduction to the Null Object Pattern.

Como todos os padrões, o padrão Null Object também tem suas vantagens e desvantagens, pois assim conseguimos definir se as vantagens valem o preço das desvantagens no nosso caso de uso, ajudando a definir quando usar o padrão.

Vantagens

O cliente consegue lidar de forma mais simples e de maneira uniforme com os respectivos objetos;
Reduz a chance de exceções de ponteiro nulo (NullPointerException);
Com menos condicionais, menos casos de teste;
Esse padrão segue os princípios gerais do Tell-Don’t-Ask.
Evita quebrar o polimorfismo e violar o LSP do SOLID causado pelos valores nulos.

Desvantagens

Pode esconder problemas que seriam pegos ao utilizar valores null;
Se não bem explicito para os responsáveis pela manutenção, pode ser que acabem criando desnecessariamente os null check’s mesmo com essa abordagem;
Pode ser necessário criar vários NullObject’s aninhados devido a abstração que o NullObject representa.

Um ponto importante que também deve ser levado em consideração na hora de decidir se vale a pena usar o design pattern Null Object é saber que na maioria das vezes ele será utilizado com outro padrão, seja uma factory, builder ou outro. Isso determina saber quando usar o outro padrão também e saber se a utilização de ambos faz sentido para o caso de uso apresentado.

Antes de sair colocando esse padrão em todos os seus projetos e alimentando seu ego, analise com carinho se isso que você está fazendo é algo realmente benéfico ou é algo que vai te tirar algumas noites de sono.

Espero que isso te ajude de alguma forma.

Twitter : https://twitter.com/omarkdev

Github : https://github.com/omarkdev

Indo além do console.log

Marcos Felipe — Tue, 07 Apr 2020 11:57:06 +0000

O mundo além do simples .log do console

Toda pessoa que já passou pela necessidade de debugar algum código em JavaScript com certeza em algum momento teve que usar o famoso console.log(). Muitos de nós ainda utiliza esse método até os dias de hoje, mesmo que alguns não gostem de admitir.

Uma pesquisa feita pelo site Rising Stack em 2016 que tinha o objetivo entender como os desenvolvedores utilizam node, concluiu que cerca de ¾ das pessoas utilizam o método console.log() para encontrar erros. Mesmo que exista ferramentas que são muito melhores para debugar, é inevitável o reconhecimento da facilidade e da quantidade de pessoas que ainda utilizam.

Sabemos que é muito fácil utilizar o console.log() em nossos códigos, porém em alguns casos é necessário realizar algumas adaptações no debug para que seja possível fazer a analise corretamente, isso devido a nossa necessidade ser diferente do propósito do método. O que muitos talvez não saibam é que a própriaAPI do console oferece uma variedade de outros métodos que podem ajudar de forma mais eficiente a resolver os problemas que estamos enfrentando.

Log simples

Sabemos que o que o método console.log() mais resolve são logs simples, mas até mesmo os logs simples podem ter algumas pequenas particularidades. Imagine uma situação onde você precise mostrar mensagens de alerta e erro. Claramente as mensagens de alerta são mais criteriosas que mensagens comuns e mensagens de erros mais criteriosas que a de alerta. Devido a criticidade desses tipos de mensagens, precisamos de um destaque maior para elas. Para ajudar nessa situação temos 2 métodos: console.warn() e console.error() .

Podemos ver no exemplo que o método warn() produz uma mensagem com o estilo de alerta e já o error() uma mensagem com estilo de erro. O exemplo também nos apresenta um método novo console.info(), esse método no Chrome tem exatamente o mesmo resultado que o nosso já conhecido console.log().

Mas você não precisa necessariamente ficar preso apenas no estilo já proposto pela plataforma utilizada. Os métodos de log simples seguem o formato de estilo printf, caso a primeira string siga esse formato. Dessa maneira é possível fazer algumas mudanças em como nossa mensagem é apresentada, seja em sua cor ou como chamamos o método.

Caso o primeiro argumento contenha %c o segundo argumento aceita propriedades CSS. Com essa possibilidade até mesmo o nosso queridíssimo console.log() pode se tornar mais elegante, se necessário.

Listar valores de listas ou objetos

É impossível programar em JavaScript e não utilizar listas ou objetos. Debugar essas estruturas de dados pode ser um pouco desagradável, dependendo do que é necessário. Em estruturas grandes, você encontrar valores utilizando o console.log() pode ser um pouco trabalhoso, isso quando não precisa ordená-los para facilitar a visualização. Na maioria dos casos, será necessário uma adaptação no código para facilitar o debug.

Para tornar a visualização desses dados mais fácil a API do console nos oferece um método chamado console.table() que tem como objetivo montar uma tabela com os dados apresentados. O primeiro parâmetro é a estrutura de dados que você quer apresentar. Essa estrutura não precisa ser necessariamente um array.

No exemplo foi utilizado a biblioteca Faker.js para criar uma estrutura com dados falsos. Podemos ver que essa estrutura fica visivelmente muito mais simples. Neste caso, a estrutura é um array de objetos, mas qualquer tipo de estrutura de dados é permitido.

O método sempre tentará encontrar um index que represente cada item da estrutura. No caso de um array é o index do item dentro da lista, já em objetos é o nome da propriedade, formando assim uma tabela de chave valor.

Contagem

Fazer a contagem de algum trecho do código pode ser extremamente necessário, seja de uma iteração, resultado de evento ou invocação de método. É bem provável que você opte por incrementar uma variável e ficar fazendo log dela a cada momento necessário, porém pode ser necessário fazer alguma adaptação no código para que isso seja possível no momento em que você está desenvolvendo. Mas por que não utilizar algo nativo que facilite esse debug?

O método console.count() nos auxilia a realizar essas contagens de forma muito mais simples. O primeiro argumento do método (que é opcional) é uma descrição que identifica o que está sendo contado, caso o método seja chamado com a mesma descrição, sua contagem é incrementada e apresentada na tela.

Também pode ser necessário reiniciar essa contagem em algum momento do nosso debug e para esse problema também temos uma solução. O método console.countReset() realiza essa reinicialização na contagem. Para identificar a contagem a ser reinicializada basta informar a descrição no primeiro parâmetro, da mesma maneira que o console.count() funciona.

Agrupamento de log’s

Em métodos muito grandes pode ser um pouco complexo debugar utilizando o console caso seja necessário demonstrar várias informações diferentes. Muitas vezes optamos por colocar prefixos que nos ajudem a identificar o grupo em que a informação pertence. De qualquer maneira o nosso objetivo é tornar õ processo de debug mais simples e apresentar a informação de uma forma mais agradável.

Para nos ajudar, a API do console oferece o método console.group() que tem como objetivo agrupar os logs. Esse método deve ser usado em conjunto com o nosso já conhecido console.log(). Para se utilizar, primeiro chamamos o método console.group() que recebe como parâmetro a descrição do grupo, que seria como uma identificação e todos os logs que vierem após isso, entrarão nesse grupo. O mais interessante é que você pode ter mais grupos dentro de grupos, bastando apenas defini-los sequencialmente. Após fazer o log de todas informações necessárias daquele grupo, é preciso chamar o método console.groupEnd() para informar que o último grupo foi finalizado, dessa maneira todos os logs posteriores não vão mais pertencer à aquele grupo.

No exemplo, foi utilizado novamente a biblioteca Faker.js para poder ilustrar melhor as informações. É possível ver no resultado o agrupamento das informações além de ser possível esconder ou mostrar o conteúdo do grupo. Caso você queira que o log de um grupo comece com seu conteúdo escondido, basta utilizar o método console.groupCollapsed().

Tempo de execução

Quando estamos com problemas de performance em nossa aplicação a primeira coisa que fazemos é tentar descobrir qual trecho está causando problemas. Para isso, precisamos descobrir quanto tempo nossos trechos de código estão levando para serem executados. Obviamente esse não é o único caso em que é necessário descobrir o tempo de execução de um trecho, mas com certeza é um dos mais frequentes. Como todas as outras necessidades já apresentadas, essa também tem muitas maneiras de solucionar. Você pode comparar datas ou até mesmo analisar visualmente os log’s simples e ver quanto tempo cada um demora para aparecer. Para tentar facilitar a nossa vida e evitar adaptações malucas em nossos códigos a API do console também oferece alguns métodos que podem nos ajudar.

Os métodos necessários para se medir o tempo de execução de um trecho de código são console.time() e console.timeEnd(). Ambos os métodos recebem como primeiro parâmetro a descrição do que está sendo medido, essa descrição serve como um identificador, dessa maneira é possível fazer várias medições em vários trechos de código junto. O método console.time() deve ser chamado no início do trecho a ser analisado e o console.timeEnd() no final. O tempo de execução será apresentado apenas após o método console.timeEnd() for invocado.

Mas dependendo da situação pode ser necessário saber durante o trecho do código quanto tempo já se passou e isso também é possível com a fantástica API do console. O método console.timeLog() faz um log simples durante a execução do código, diferente do console.timeEnd() que faz apenas no final. Igual aos outros métodos, esse método espera no primeiro parâmetro a descrição do que está sendo medido.

Nem só de console vive o homem

Mesmo não tendo apresentado todos os métodos presentes na API do console, é possível concluir que ainda sim é uma API fantástica e nos oferece muitos métodos que podem facilitar nossas vidas em determinadas situações, porém isso não quer dizer que ela irá resolver todos os seus problemas sempre ou que substitui uma boa ferramenta de debug. Cada caso é um caso, mas é inevitável a necessidade de se conhecer novas ferramentas, pois só assim você irá descobrir qual facilita mais a sua vida e te ajuda a resolver os problemas mais facilmente.

Espero que isso te ajude de alguma forma.

Twitter : https://twitter.com/omarkdev

Github: https://github.com/omarkdev

A questão não é a receita do software e sim os ingredientes

Marcos Felipe — Thu, 02 Apr 2020 12:13:40 +0000

Photo by Kara Eads on Unsplash

Programar não é escrever uma receita de bolo?

É bem provável que quando você começou a estudar programação, seja em uma faculdade, curso online ou pedindo ajuda para alguém, a pessoa responsável por ensinar provavelmente te disse “Programar é como uma receita de bolo, instruções contidas em uma receita”. Se pegarmos a definição de Dasgupta, Papadimitriou e Vazirani, sobre algoritmos, onde diz “algoritmos são procedimentos precisos, não ambíguos, mecânicos, eficientes e corretos”, reforçamos ainda mais essa ideia de estarmos criando sempre receitas.

Vamos imaginar que passamos o dia todo criando CRUD’s em nossa API, basta seguirmos a nossa receita, não é? Afinal, fazer a operação de atualização de um valor é a mesma, certo?

Crie a rota para que irá atualizar os dados;
Adicione a verificação de usuário está autenticado;
Valide os dados recebidos na requisição;
Busque o registro baseado no valor recebido;
Dispare uma exceção caso não encontre nenhum registro;
Atualize os valores no banco;
Retorne para o usuário que a operação foi concluída com sucesso.

Graças a receita de 7 passos, podemos construir quase qualquer operação de atualização de um CRUD. Isso não é necessariamente um problema, pois mesmo que você procure outras maneiras de fazer isso, no final sempre irá parecer uma receita. Mesmo este processo sendo o mesmo para a maioria dos casos de CRUD, muitos podem se frustar por sempre estarem seguindo a mesma receita, outros podem até dizer “eu não estou aprendendo nada com isso”.

A questão nunca foi seguir os passos a passos da nossa receita e sim saber o porquê cada ingrediente está lá. Um grande chefe de cozinha entende o motivo daqueles ingredientes estarem naquela receita.

Um chefe de cozinha ao se chegar no resultado de uma receita de um prato, provavelmente ele já teve muitas experiências com aqueles ingredientes, pois apenas desta maneira é possível concluir que aquela combinação é algo saboroso. Essa experiência que te da a capacidade de montar uma receita só acontece depois de muito teste, pois imagine quantas vezes não foi necessário testar para se chegar as combinações de páprica, alho e cebola em pó, pimenta-do-reino, salga e tomilho e alecrim, para se ter um tempero seco para churrasco?

Escrever uma receita é diferente de cozinhar.

No início de nossa carreiras é comum começarmos com atividades simples que seguem um passo a passo. Depois de um tempo fazendo coisas parecidas, começamos a associar o tipo do problema com as possíveis soluções, mas o aprendizado não deve parar ai.

Se você utiliza um framework para gerenciar sua API, provavelmente ele tem um ORM que você usa para salvar seus dados no banco de dados, nenhum problema nisso, mas você sabe se seu ORM segue o padrão Active Record ou Data Mapper? Como seria essa receita com outros ORM’s que seguem um padrão diferente do que o seu ORM segue? Se minha aplicação é basicamente um monte de CRUD, faz sentido eu continuar utilizando meu ORM que é um Data Mapper? São esses questionamentos que importam.

Conforme você for tentando resolver os problemas baseado na sua experiência já associada, você deve ir tentando adicionar novos ingredientes, ou trocar a dosagem, trocar a ordem ou remover um ingrediente. Muitas vezes começamos fritando ovo, mas você já comeu um frango à parmegiana? Então por que não tentar fazer um ovo à parmegiana?

A familiaridade com o resultado é algo extremamente vantajoso, pois você sabe qual deve ser o resultado, então se você mudar algumas coisas, você tem como comparar. Se você cria as query do banco de dados na mão, você pode testar um framework e comparar os quesitos que você já sabe que são importantes, e mesmo que você tenha que refazer, você aprendeu algo novo que pode te ajudar no futuro.

Entender e saber utilizar uma ferramenta vai muito além de ler a documentação, é entender que ela serve para aquele caso e que os benefícios que ela está trazendo valem a pena o preço que você vai pagar. Se você resolve começar a utilizar outra biblioteca que faz gerenciamento de rotas, você pode acreditar que ela é melhor para aquele caso seu, mas você sabe se é melhor para o seu time? Ela resolveu um problema, mas o preço que você pode ter que pegar (ensinando o time, dando manutenções diferentes, migrando outras rotas) pode não valer tanto a pena. Conhecer ferramentas é diferente de se ter um resultado over engineering.

Basicamente nossa profissão é resolver problemas com tecnologia, então quando você entende o porque e como utilizar aquele ingrediente para aquele problema, você começa a se tornar um profissional melhor e pronto para resolver mais problemas.

Espero que isso te ajude de alguma forma.

Twitter : https://twitter.com/omarkdev

Github : https://github.com/omarkdev

Novas funcionalidade do JavaScript em ES2019 (ES10)

Marcos Felipe — Tue, 31 Mar 2020 12:07:08 +0000

Photo by Nijwam Swargiary on Unsplash

Faz um certo tempo que o ECMAScript 2019 foi lançado, mas pouco se vê falar ou utilizar as funcionalidades trazidas pela edição. Várias das novas funcionalidades podem ajudar muito no seu dia-a-dia em coisas que antes você precisava “implementar na mão”. Mesmo que já tenha passado algum tempo, é extremamente necessário sempre reforçamos os aprendizados e analisarmos se deixamos de passar algo.

É importante saber que para rodar os exemplos que serão apresentados, você precisará do NodeJS a partir da versão 12, ou com o Chrome na versão 72.

Array#{flat,flatMap}

O método flat cria um novo array concatenando todos os elementos que são sub-arrays.

O parâmetro que esse método pode receber representa o nível de profundidade que será concatenado os sub-arrays, por ser um parâmetro opcional, caso não seja informado nenhum valor o seu valor padrão será 1. Caso você queira todos os níveis, basta informar o valor Infinity.

É importante sabermos também que o método exclui intervalos ou elementos vazios no array.

Entendendo como o método flat funciona, fica mais fácil entendermos qual o objetivo do método flatMap. Resumidamente, o método tem o mesmo efeito usando o map seguido de um flat , dessa maneira se o seu flatMap retornar um array, ele será concatenado.

É importante saber que o flatMap por padrão é definido com profundidade 1, que seria como chamar o flat sem parâmetros ou informando o valor 1.

Object.fromEntries()

A função cria um novo objeto a partir de um iterable que tenha pares chave-valor.

String#{trimStart,trimEnd}

Os métodos trimStart e trimEnd tem quase a mesma finalidade, ambos removem os espaços em branco de algum lado de uma string, a diferença é que o trimEnd remove os espaços em branco que estão apenas no final da string e o trimStart apenas os que estão no começo.

Symbol#description

Antigamente caso precisássemos saber qual a descrição do nosso Symbol era necessário chamar o método toString, que retornava a descrição dentro de Symbol().

Dessa maneira antiga, caso fosse necessário obter apenas a descrição, era necessário fazer algum tipo de formatação. Para resolver isso, foi adicionado a propriedade de apenas leitura description que contém apenas a descrição do Symbol, caso o Symbol foi criado sem nenhuma descrição, a propriedade terá o valor undefined.

Parâmetros opcionais no catch

Agora o ES10 nos permite criar blocos de try/catch sem que seja necessário fornecer o parâmetro de erro no bloco de catch.

Esse tipo de abordagem é muito útil para quando você sabe que não vai utilizar o objeto de erro.

Revisão de Function#toString

Nas versões anteriores do ECMAScript, você pode imprimir o código-fonte de uma função usando o método toString, porém todos os espaços em branco e comentários eram removidos. Agora com o ES10, esses trechos são mantidos.

Estabilidade no Array#sort

Anteriormente, o V8 (Motor do JavaScript) usava um método de ordenação chamado QuickSort para arrays que tinham mais de 10 elementos, apesar de ser um método extremamente rápido, era bem instável.

A partir do V8 7.0 / Chrome 70, o V8 passou a utilizar o algoritmo TimSort.

Caso você queira saber mais sobre o assunto, você pode ver a demo do Mathias Bynens.

Melhor formatação no JSON.stringify

Foi adicionado uma melhoria para impedir que o JSON.stringify retorne caracteres Unicode mal formatados.

Melhorias no JSON

A Sintaxe do JSON é definido pelo ECMA-404 e permanentemente corrigida pela RFC-7159, permitindo que o separador de linha (\u2028) e o separador de parágrafo (\u2029) possam ser exibidos corretamente sem disparar um erro.

Espero que isso te ajude de alguma forma.

Twitter : https://twitter.com/omarkdev

Github : https://github.com/omarkdev

Lidando com valores booleanos no JavaScript

Marcos Felipe — Thu, 26 Mar 2020 14:42:45 +0000

Photo by George Bosela from FreeImages.

Sabemos o quão importante são os valores booleanos na maioria das linguagens para se desenvolver software, mas outra coisa que sabemos também é que o JavaScript sempre está nos aguardando com novas surpresas. Lidar com booleanos no JavaScript para muitos é algo extremamente simples que não tem nada de diferente, mas para outros em alguns casos podem existir algumas particularidades não conhecidas, que são bem importante conhecermos para não nos surpreendermos no futuro.

Atualmente, “acreditamos” ter 3 maneiras de se converter valores para booleanos: !!, Boolean e new Boolean.

Analisando o exemplo extremamente simples, podemos ver que as 3 maneiras funcionaram ao verificarmos se os valores são iguais a true. Mesmo ambos funcionando, temos uma particularidade ao usar o new Boolean.

Ao verificarmos os tipos das abordagens, vemos que o new Boolean é um objeto de uma instância do booleano ao invés de um tipo primitivo. É importante sempre preferirmos tipos primitivos porque são imutáveis possibilitando compartilhar apenas referências e não ter que manter nenhum estado na instância, consequentemente são mais “baratos”. Além disso, também podemos ter problemas quando lidamos com outro tipo de comparação.

Por se tratar de um objeto quando usamos o new Boolean, ao se utilizar o comparador idêntico (onde é verificado se o valor e o tipo são iguais) passamos a ter o resultado false.

Os valores a serem convertidos

A abordagem escolhida não é a unica coisa importante a se considerar ao se trabalhar com booleanos, os valores a serem convertidos também são, afinal são eles que ditam o resultado. Independente da abordagem que você escolha, o resultado de ambas será o mesmo (obviamente com a particularidade do objeto ao se utilizar new Boolean).

Quando temos uma string com valores e um número diferente de 0, sempre resultará em true, porém esses não são os únicos valores que podemos lidar no dia-a-dia. Existe também os falsy values , que são 6 valores que se convertidos em booleano, resultarão em false.

Conhecendo os falsy values possíveis, podemos ver que strings vazias e número 0 sempre resultarão em false.

Qual abordagem escolher?

Cada projeto terá uma ou mais abordagens em seu código e isso é extremamente normal, pois como já vimos cada uma pode ter uma particularidade escondida. Mas se você está se perguntando quando você deve utilizar cada uma, existem algumas idéias que podem te ajudar a refletir sobre isso.

Sabemos que ao utilizar o new Boolean teremos um objeto como resultado, e como também já sabemos, podemos adicionar propriedades aos objetos no JavaScript. Então, se você por algum motivo precisa de mais informações no seu “booleano”, talvez faça sentido seguir com essa abordagem.

Talvez para você utilizar a abordagem Boolean pode ser mais interessante caso você tenha abordagens mais verbosas. Porém a abordagem Boolean não serve apenas para converter valores, por se tratar um construtor, podemos utilizá-lo em alguns trechos onde temos que verificar os nossos falsy values.

E para muitos o quesito performance é extremamente importante, mesmo que ela seja miníma, para tirar essa dúvida temos um teste de performance que utiliza as 3 abordagens. Aparentemente o !! é o mais rápido.

Espero que isso te ajude de alguma forma.

Twitter : https://twitter.com/omarkdev

Github : https://github.com/omarkdev

Uma introdução prática à Reflection no PHP

Marcos Felipe — Tue, 24 Mar 2020 11:58:20 +0000

Analisando ou modificando estruturas no PHP com PHP

São inúmeras linguagens de programação que disponibiliza mecanismos para se fazer reflexão em estruturas de dados, no PHP isso também não seria diferente. Mas antes precisamos entender, o que é reflexão?

Em ciência da computação, reflexão computacional (ou somente reflexão ) é a capacidade de um programa observar ou até mesmo modificar sua estrutura ou comportamento. — Wikipedia.

Se você tem uma pequena vivência com o PHP, provavelmente já deve ter encontrado algum código “mágico” que resolve algum problema. Um exemplo um pouco comum é a injeção de dependência do Laravel (que não é exclusividade da ferramenta), vamos ver um exemplo (caso você não tenha vivência com o Laravel, não tem problema):

Se analisarmos o exemplo, vemos que o construtor da nossa classe UserController espera uma instância de UserRepository, certo? Até aqui, sem problemas, apenas PHP. A “mágica” do Laravel acontece quando o próprio framework cria a instância de UserRepository e passa automaticamente para o nosso controller. Para isso, o framework utiliza um padrão chamado service container que por outro lado utiliza uma técnica chamada injeção de dependência. Basicamente, o service container analisa que a classe UserController precisa de um UserRepository para ser instanciado e cria essa instância, mas como ele sabe que ele precisa dessa instância? Com reflexão.

Trabalhar com reflexão no PHP é possível graças as classes mágicas de Reflection do PHP. Essas classes estão disponíveis no core da linguagem desde a versão 5, então não é necessário fazer nenhuma instalação. Existem algumas classes de Reflection no PHP, sendo que cada uma depende de onde você vai aplicar:

ReflectionClass —_ _Utilizar em classes;
ReflectionExtension — Utilizar em extensões;
ReflectionFunction — Utilizar em funções;
ReflectionFunctionAbstract — Utilizar em funções abstratas;
ReflectionMethod — Utilizar em métodos;
ReflectionObject — Utilizar em objetos;
ReflectionParameter — Utilizar em parâmetros (de métodos ou funções);
ReflectionProperty — Utilizar em propriedades de classes;
ReflectionType — _Utilizar para saber sobre tipos de retorno;_
ReflectionGenerator — Utilizar em geradores.

Vamos seguir com a ideia do exemplo em Laravel, mas agora fora do framework. Imagine que precisamos instanciar a classe UserController que espera uma instância de UserRepository, tudo isso fora do framework.

Analisando o nosso pequeno exemplo podemos ver que precisamos descobrir o que o construtor necessita para que possamos instanciar, tudo isso de forma “mágica”, utilizando reflexão. Se olharmos a lista das classes disponíveis, podemos notar que existem 2 tipos de classes que chamam a nossa atenção para esse caso, são as ReflectionParameter e ReflectionMethod, porem olhando a assinatura é possível notar que ReflectionParameter não serve diretamente para o nosso caso, pois o primeiro argumento é um callable e não é o caso do nosso __construct, então sobra o ReflectionMethod. Então, basta instanciar a classe ReflectionMethod passando o nosso controller junto com o nome do nosso método que é __construct.

Criamos a nossa reflexão do método __construct utilizando a classe ReflectionMethod. O interessante de se analisar é que o método getParameters() da classe de reflexão retorna uma lista de ReflectionParameter que representa cada parâmetro, ou seja, mesmo que não utilizando o ReflectionParameter diretamente acabamos chegando na ideia do mesmo resultado, tudo isso graças à uma ótima API das classes. Isso não é particularidade apenas da ReflectionMethod, podemos fazer o mesmo utilizando a classe ReflectionClass, criando uma reflexão para o nosso controller e analisando o construtor do alvo.

Dessa maneira, conseguimos começar do nível de cima e ir acessando às nossas necessidades até o último nível. Com esses pequenos exemplos, conseguimos começar a entender como utilizar a API de reflexão do PHP e o básico (bem básico) de como um service container funciona.

Os exemplos podem ter ficado um pouco longos mas são bem simples, pois são apenas um começo de como a reflexão do PHP funciona, de qualquer maneira aconselho você a começar a testar cada uma das classes e entender suas particularidades e funcionalidades.

Espero que isso te ajude de alguma forma.

Twitter : https://twitter.com/omarkdev

Github : https://github.com/omarkdev

Uma introdução prática à Decorators no TypeScript

Marcos Felipe — Thu, 19 Mar 2020 12:22:30 +0000

Photo by Ferenc Almasi on Unsplash

Os decorators são um dos recursos mais poderosos oferecido pelo TypeScript, tendo como um dos principais objetivos ampliar funcionalidades de classes e métodos de forma simples e limpa. Atualmente, os decorators são uma proposta de estágio 2 para JavaScript e estão disponíveis como um recurso experimental no TypeScript. Mesmo sendo um recurso experimental, eles já estão presentes em grandes projetos de código aberto, como o Angular e Inversify.

Por ser um recurso experimental, para ser possível utilizar no TypeScript, é necessário habilitar no tsconfig.json:



{
    "compilerOptions": {
        "target": "ES5",
        "experimentalDecorators": true
    }
}

Ou pela linha de comando:



tsc --target ES5 --experimentalDecorators

Mesmo que inicialmente os decorators possam parecer mágicos, eles são simples de se entender e fáceis de se criar.

Mas afinal, o que é um decorator?

O site do TypeScript descreve como:

“Um Decorator é um tipo especial de declaração que pode ser anexada a uma declaração de classe, método, acessador, propriedade ou parâmetro.”

Essa definição pode não explicar muito o que um decorator realmente representa. Eu prefiro definir como “uma declaração especial para adicionar funcionalidades extras a uma declaração de classe, método, acessador, propriedade ou parâmetro”.

Você pode ter visto em algum projeto a utilização de decorators, eles utilizam o formato @expression, onde o valor expression representa uma função que fará as modificações as classes, métodos, acessadores, propriedades ou parâmetros.

Para se criar um decorator é bem simples. Como já previamente explicado, os decorators são apenas funções, essas funções são chamadas em tempo de execução. Um exemplo bem simples é criarmos uma função log que irá realizar um console.log no alvo em que ele for utilizado, ficando desta maneira:

Pode ser que em certas situações pode ser necessário você customizar como um decorator é aplicado à uma declaração. Para isso, é necessário criar um Decorator Factory , que é uma função que retorna a expressão que será executada. Seguindo o mesmo exemplo, imagine que agora você queira adicionar um prefixo estático nos logs, o resultado seria algo assim:

Como é possível analisar, agora ao invés de recebermos o alvo como parâmetro, recebemos o parâmetro que informamos e temos que retornar uma função, que será executada.

Tipos de decorators

Ao se desenvolver decorators é importante saber que existem vários tipos, esses tipos são determinados pelo alvo em que está sendo aplicado, sendo que cada tipo tem suas particularidades e assinaturas diferentes. Atualmente os tipos existentes são:

Class Decorator.
Property Decorator.
Method Decorator.
Accessor Decorator.
Parameter Decorator.

Class Decorator

A maneira mais simples de se começar a entender os decorators é começar desenvolvendo para classes. Um decorator para classe deve ser declarado antes da declaração da classe. Esse decorator recebe um único parâmetro que é o construtor da classe alvo.

Caso o decorator retorne um valor, ele substituirá a declaração de classe pelo valor fornecido, que deve ser um construtor. Dessa maneira, diferente do exemplo acima, podemos aplicar mudanças diretas à classe, ao invés de apenas no protótipo da classe.

É importante ressaltar que caso você decida retornar um construtor, você deve manter a mesma assinatura do alvo.

Você perceberá no decorrer do aprendizado, que esse tipo de decorator é o mais generalista, pois nele você pode ter acesso à classe inteira, ao invés de pequenas partes do objeto.

Property Decorator

Um decorator de propriedade deve ser declarado antes da declaração da propriedade. Dessa vez, o decorator, recebe 2 parâmetros, target e key. O parâmetro target é o protótipo da classe em que está sendo aplicado o decorator, já o parâmetro key é o nome da propriedade da classe em que está sendo aplicado o decorator.

Com esse pequeno exemplo, foi mostrado na tela Task {} 'title', que representa o protótipo da classe e o nome da propriedade.

Um ponto interessante e importante de se analisar, como já foi dito, recebemos como parâmetro o protótipo da classe e não sua instância, sabendo disso é possível ver no exemplo que o decorator foi executado mesmo sem instanciarmos a classe, isso por que o decorator é chamado no tempo de execução do arquivo. Isso deve ser levado em consideração na hora de se criar seus decorators já que você não terá uma chamada no decorator a cada vez que instanciar a classe.

O interessante desse tipo de decorator é a possibilidade de aplicar mudanças de comportamento nas propriedades.

No exemplo, criamos um decorator chamado logProperty que tem como objetivo fazer um console.log toda vez que a propriedade tiver seu valor alterado ou for acessada. Para saber o que acontece na propriedade, utilizamos os getters e setters do próprio JavaScript.

Method Decorator

Para muitos esse é o tipo de decorator mais útil oferecido pelo TypeScript. Um decorator para métodos deve ser declarado antes da declaração do método. Ao se utilizar um method decorator recebemos 3 parâmetros. O primeiro parâmetro é o target que é protótipo da classe, igual ao que vimos no property decorator. O segundo parâmetro é o propertyKey que é o nome do método em que estamos aplicando. Já o último é o propertyDescriptor, que é um conjunto de propriedades que definem uma propriedade de um objeto em JavaScript, neste objeto podemos ter acesso a propriedades como: configurable, enumerable, value e writable, além de get e set. Tendo acesso nesses 3 parâmetros, somos capazes de realizar quase qualquer operação em cima de nossos métodos.

Vamos imaginar um cenário onde temos um método changePassword em uma classe User e queremos alterar o enumerable deste método através de um decorator para que esse método não apareça na hora de percorrer as propriedades existentes na classe.

Neste simples exemplo, será mostrado na tela name e changePassword. Como queremos alterar o enumerable para o valor false deste método para não mostrar na tela, basta alteramos a propriedade dentro do nosso propertyDescriptor.

Agora será mostrado na tela apenas name.

Esse tipo de decorator é extremamente útil quando queremos aplicar mudanças no comportamento dos nossos métodos e como temos acesso a quase tudo que representa o método, se torna muito simples aplicarmos as mudanças que queremos.

Accessor Decorator

Os accessor decoratos são os mesmos que os method decorators, mas são aplicados aos métodos setter ou getter.

É importante entender que o TypeScript não permite aplicar um decorator a ambos os acessadores de um único membro. Em vez disso, deve ser aplicado o decorator ao primeiro acessador especificado na ordem do objeto.

Parameter Decorator

Por último, mas não menos importante, temos os parameter decorators. Um parameter decorator deve ser declarado antes da declaração de um parâmetro. Esse decorator recebe 3 parâmetros. O primeiro, como na maioria dos decorators que já vimos é o target que é o protótipo da classe. O segundo é o propertyKey que é o nome do método que contém o parâmetro estamos trabalhando, bem semelhante ao que ja vimos no method decorator. Já o último parâmetro, é o parameterIndex que é o número da posição do parâmetro na função, lembrando que começa a partir do 0.

Dessa maneira como estamos construindo os nossos decorators, só é possível analisar o objeto e o método, qualquer alteração necessária no comportamento requer o uso do reflect-metadata (que é um assunto para outro post).

Quando usar

É comum quando estamos aprendendo algo novo entendermos como algo funciona mas dificilmente conseguiremos enxergar cenários para aquele aprendizado. Para alguns, não é diferente ao começar a aprender a trabalhar com os decorators.

Os decorators são extremamente úteis quando devemos adicionar ou alterar comportamento de nossos alvos através de meta-programação. Quando temos algo que pode ser considerado genérico, mas que pode ser reutilizado em vários lugares no objetivo de facilitar alguma mudança em cima do alvo, talvez seja uma ótima situação para se utilizar.

Ao se começar a pensar na criação de nossos próprios decorators podemos ver que um grande benefício é a reutilização, porém mesmo que isso seja uma verdade, devemos tomar muito cuidado para não acabar criando coisas extremamente complexas com várias responsabilidades e efeitos colaterais.

Espero que isso te ajude de alguma forma.

Twitter : https://twitter.com/omarkdev

Github : https://github.com/omarkdev

Do presencial ao remoto

Marcos Felipe — Tue, 17 Mar 2020 16:04:05 +0000

Photo by Patrick Perkins on Unsplash

O modelo de trabalho remoto vem crescendo cada vez mais, seja por empresas que tenha apenas esse modelo, ou empresas que oferecem os 2 modelos de trabalho. Além disso, devido aos acontecimentos recentes, muitas empresas que tinham um modelo de trabalho presencial estão migrando para o remoto, mesmo que seja experimental ou temporário.

Se você está passando por essa mudança, mesmo que seja temporário ou trocando de emprego, é importante saber que cada pessoa reage de uma maneira diferente. Tem pessoas que na mudança vão se sentir produtivas, confiantes e satisfeitas e outras já podem se sentir improdutivas, aterrorizadas ou insatisfeitas.

A ideia deste artigo é apresentar algumas dicas baseado na minha experiência e aprendizado que podem ser interessantes para você nessa migração. Caso você esteja se sentindo perdido, esteja com um pouco de medo do novo modelo de trabalho ou está apenas procurando outros pontos de vista, talvez eu possa te ajudar. Mesmo com essas dicas é importante ressaltar que não existe um caminho único e mágico a ser seguido, cada pessoa se comporta de uma maneira, cada empresa tem processos de trabalho diferentes, por isso analisar a situação é mais importante do que procurar soluções de ouro.

Quando falo em analisar a situação, quero dizer especificamente em você analisar a si mesmo e entender como você trabalha. Observe como você trabalhava presencial, quais eram suas maiores dores e felicidades e tente imaginar quais características você deve se importar (tanto para evitar quanto para manter). Essa analise pessoal pode ser um pouco difícil no começo, mas é para isso que esse artigo foi escrito, para mostrar alguns pontos interessantes que devemos levar em conta.

Rotina

A maioria dos artigos que você encontra quando pesquisa “dicas para trabalho remoto”, dizem que você deve definir uma rotina. Bom isso pode ser um pouco de verdade, mas esses tipos de soluções prontas muitas vezes não explicam a razão para se utilizar essa abordagem, e se não tem o motivo, como você sabe se isso serve para você?

Ter uma rotina na grande maioria dos casos será algo extremamente necessário, pois o seu horário de trabalho não influencia apenas na empresa mas também nas suas atividades pessoais. Essa definição de horário de trabalho pode te ajudar a definir como será a sua manhã, ou te ajudar a evitar trabalhar excessivamente. Definir o quão restrito será essa rotina também vai depender muito da sua empresa e de você. Tem empresas que funcionam em vários fuso-horários e conseguem manter uma comunicação assíncrona onde permite que cada funcionário se auto-gerencie, outras já oferecem um horário um pouco flexível e outras já determinam o horário a ser cumprido. Pode ser que mesmo com a empresa um pouco flexível ela exija que você informe uma faixa de horário que você vai estar disponível para comunicação, e mesmo que a empresa seja totalmente flexível, talvez você funcione melhor com rotinas bem definidas.

Se você está começando em uma empresa nova, primeiro tente entender como ela já funciona, mas se é uma empresa que está apenas migrando do presencial para o remoto, é bem provável que a rotina seja bem parecida, pois quanto menor o impacto mais fácil é a adaptação dos funcionários e da empresa.

Quando falamos em rotina, queremos dizer aquilo acontece sempre, então faz mais sentido começarmos definindo a nossa rotina com aquilo que se repete. Se a sua empresa já tem os horários definidos, seja de reuniões, rituais de scrum ou horários a ser cumprido, é bem provável que a sua rotina se adapte aos horários já definidos.

Como já sabemos, precisamos entender as dores e as felicidades que existiam no modelo presencial. Para muitos ao começar com o trabalho remoto a primeira coisa que pensam é “vou acordar 5 minutos antes de começar a trabalhar”, mas você sabe o que isso impacta em você? Se você é uma pessoa que precisa de um tempo para acordar para poder começar a produzir algo, pode ser que você se sinta menos produtivo pela manhã ao seguir essa ideia. Isso não quer dizer que você precisa ser radical e seguir exatamente a mesma rotina, afinal de contas um dos pontos mais positivos do trabalho remoto é a qualidade de vida. Se com o modelo presencial você levava 3 horas para chegar no trabalho, isso não quer dizer que você precisa acordar 3 horas antes no modelo de trabalho remoto, talvez acordar meia-hora antes tenha o efeito que você precisa.

Durante essa caminhada do trabalho remoto, é quase inevitável que você irá encontrar dicas ou alguém irá te dizer coisas como: “tenha um local de trabalho específico” ou “troque de roupa para começar a trabalhar”. Essas dicas são importantes pois podem te ajudar a evitar dores de cabeça que outras pessoas já tiveram, porém como já falamos, escondem o real motivo delas existirem.

Para algumas pessoas trocar de roupa para começar a trabalhar pode ser necessário, pois pode passar o sentimento de estar em um escritório, mas para outros isso é extremamente desnecessário. Se você não precisa estar com uma roupa específica durante uma video-conferência (ou não tem uma video-conferência) e não tem essa necessidade de experiência de escritório, por que seguir essa dica? Trabalhar remoto está ligado mais ao seu profissionalismo do que com a roupa que você utiliza.

Ter um escritório (entenda escritório como local específico de trabalho), pode ser útil para quem precisa se sentir “desligado” ao sair do ambiente, ou precisa de privacidade. Quando trabalhamos no modelo presencial, na maioria dos casos a empresa já definiu onde você irá trabalhar, qual cadeira você vai utilizar, a sala já pode estar equipada com tudo que você precisa (ar condicionado, álcool em gel, etc.), porém quando você vai para o modelo remoto, todas essas questões tem que ser decididas por você, seja diretamente ou indiretamente. Você pode optar por trabalhar em co-workings, mas ainda sim é uma escolha sua baseado nesses pontos (e em outros também). É preciso saber quais são as necessidades que você tem para poder trabalhar sem incômodos. Quase todo mundo no início começa trabalhando da mesa da cozinha, no sofá na sala ou na cama no quarto, se dessa maneira você não tem dores nas costas, interrupções e consegue desempenhar um bom trabalho, sem problemas.

Por isso o auto-conhecimento é extramente importante, e se essas respostas ainda não estão respondidas por você, o único jeito é ir tentando aos poucos, mas sempre se observando.

Produtividade

Acredito que produtividade seja o ponto mais impactante quando trabalhamos com essa migração. A maioria das notícias que lemos sobre trabalho remoto são voltadas em como os profissionais se tornam produtivos em trabalho remoto. Sabendo desse detalhe muitas empresas podem acreditar que terão mais entregas ao adotar esse modelo, ou até mesmo você pode se assustar quando perceber que no começo não está produtivo igual antes.

No começo é totalmente normal se sentir menos produtivo. A migração entre esses modelos é algo muito impactante, agora a comunicação com o seu time é diferente, você não consegue mais chegar na mesa do lado e chamar pelo colega para te ajudar em um problema, ter um auto-gerenciamento agora é mais necessário, as interrupções agora são outras e obviamente tudo isso impacta na sua produtividade (ou na sua percepção de produtividade).

Distrações, na maioria dos casos, são inevitáveis, tanto no modelo presencial quanto no remoto. A questão é entender como esses pontos que impactam na sua produtividade podem ser reduzidos. Se você é muito interrompido pela sua família enquanto trabalha em casa, um acordo é extremamente necessário. Se os elementos que estão no seu ambiente de trabalho chamam a sua atenção constantemente, tente mudar o local de trabalho.

Por mais que a queda de produtividade seja uma constante, ela não vai se resolver magicamente. É necessário enfrentar os problemas que impactam essa queda de produtividade. Quando falo em enfrentar os problemas é tentar evitar que eles aconteçam e não tentar ser produtivo mesmo com os problemas ainda existindo. O artigo “10 lições que aprendi sobre trabalho remoto em 4 anos com um time distribuído” escrito pela Victoria Haidamus, diz que “Horas trabalhadas não são métricas de sucesso”. Não é porque você foi interrompido muito pela sua família e atrasou a entrega de uma atividade importante que você deve trabalhar 12 horas por dia, desse jeito você está apenas evitando o problema, ao invés de resolve-lo. É preciso muito cuidado no começo para não cair no falso dilema de que é preciso trabalhar mais que o horário definido para ser produtivo no remoto.

Comunicação

Até mesmo empresas que sempre trabalharam remotas em algum momento enfrentaram (ou ainda enfrentam) o problema de comunicação. A comunicação no modelo remoto é totalmente assíncrona, diferente de estar presencial com o time onde você pode interromper (e atrapalhar) o colega de trabalho para tirar uma dúvida. Aprender a lidar com esse tipo de comunicação é algo extremamente difícil. Tem pessoas que precisam de um contato mais próximo e tem outras pessoas que já conseguem trabalhar mais sozinhas. Cada tipo de pessoa vai ser impactada de uma maneira.

Por ser uma comunicação assíncrona, muitas vezes ela acontece por texto, o que pode dificultar a explicação em certos casos. Tem pessoas que tem facilidade em se comunicar com texto (seja escrevendo ou lendo), outras já não, e tudo bem também. Se você é uma pessoa que tem dificuldades em se comunicar com texto, ou entende que a outra pessoa com quem precisa se comunicar vai entender melhor de outra forma, talvez seja inevitável chama-lá para uma chamada. Por mais que na maioria das vezes fazer as chamadas podem facilitar essa barreira da comunicação assíncrona, ainda sim é necessário respeitar essa característica. Não é chegar ligando já para a pessoa e esperar que ela atenda. Cada pessoa tem uma rotina diferente, pode ser que ela esteja online mas está na cozinha bebendo água. Por isso é necessário respeitar a rotina de cada um.

Ao lidar com esse modelo de comunicação, o nosso trabalho também deve se adaptar. Caso aconteça muito da equipe ficar “bloqueada” esperando a resposta de alguém, talvez isso seja mais um problema de processo do que de comunicação. Você pode simplesmente pegar outra atividade enquanto espera a resposta para poder continuar a sua. São nessas situações que o auto-gerenciamento são necessário, você precisa saber se gerenciar para poder lidar com essas características que são inevitáveis.

A falta de comunicação no dia-a-dia também pode ser um impacto para você. Se você saiu de um modelo presencial para ir trabalhar em casa e é uma pessoa que precisa de um contato mais próximo com as pessoas (seja para jogar conversa fora ou tirar dúvidas), pode ser que você seja bastante impactado. Sentir falta de se comunicar com pessoas durante o dia devido a uma mudança tão rápida pode ser algo bem comum. Um estudo feito pela A.T. Kearney diz que o número de trabalhadores remotos cresceu 115% entre 2008 e 2018, e que são justamente esses colaboradores os mais propensos a desistir do trabalho por causa da solidão. A sua adaptação da rotina pode mudar conforme esses sentimentos vão vindo, pode ser que agora você comece a fazer mais atividades com seus amigos fora do horário de trabalho para começar a ver pessoas.

Os impactos vão acontecer, seja de comunicação, produtividade ou alteração de rotina, mas cabe você à lidar com eles e entender se esse modelo faz sentido para você. Quando comecei a trabalhar remoto eu me senti muito improdutivo e solitário pois sentia falta da comunicação diária com as pessoas, com o passar do tempo fui aprendendo que a improdutividade minha estava ligada mais a falta de percepção das coisas que eu estava fazendo, já a solidão era um pensamento limitado que quando começado a questionar foi possível concluir que eu continuava mantendo contato com algumas pessoas, ele era menor com certeza, mas ainda sim existia. Mesmo com esses problemas apontados não quer dizer que o trabalho remoto é ruim, muito pelo contrário, hoje eu acredito que dificilmente eu trocaria esse modelo de trabalho. Com remoto também temos muitas vantagens como: qualidade de vida, redução de custo, liberdade de local de trabalho (não que isso ocorra sempre comigo), flexibilidade, entre outras coisas. Por isso cabe a você ter o autoconhecimento e colocar na sua balança para entender qual o lado que vale mais a pena para você.

Espero que isso te ajude de alguma forma.

Twitter : https://twitter.com/omarkdev

Github : https://github.com/omarkdev

O código perfeito

Marcos Felipe — Thu, 12 Mar 2020 12:18:26 +0000

Inevitavelmente um caminho que será encontrado por quem escreve códigos, em algum momento na carreira, é o da necessidade de escrever códigos melhores, pois afinal, queremos sempre resolver os problemas de formas mais simples e eficiente. Após esse caminho ser encontrado, aprendemos o quanto antes a necessidade de sempre nos questionarmos se o que está sendo entregue está dentro do que sabemos e consideramos de boa qualidade.

Com o tempo e com mais aprendizados, acreditamos que fica mais fácil distinguir um código bom do ruim, mas até mesmo o código bom aparenta não estar ideal, ainda não chegou no estado da perfeição idealizado por nós.

O ser humano se defronta com essa ideia de perfeição há muito tempo, isso por um lado pode ter trazido muita angústia, decepção ou esforço inútil, mas por outro lado pode ter trazido grandes avanços. Já analisando isso de uma forma mais próxima de nossa área, a busca pelo código perfeito trouxe para várias pessoas, muitos aprendizados, seja de novos padrões, linguagens ou outras maneiras de solucionar o mesmo problema, porém trouxe também muitas angústias ou decepções, afinal pode ser muito decepcionante quando seu código com toda sua bagagem de pesquisa se torna mais um problema do que uma solução.

Há cerca de 25 séculos atrás, Platão criou sua versão sobre a perfeição que está diretamente ligada a nossa percepção da realidade. O filosofo defendia que a percepção da realidade é dividida em dois mundos, o mundo das ideias e o mundo dos sentidos.

O mundo das ideias seria o mundo das formas perfeitas, onde se tem todas as ideias primordiais, sendo que essas ideias são eternas e perfeitas e só podem ser alcançadas pela razão. Basicamente nesse mundo é onde estão todas as “formas” que nos ajudam a definir que algo é algo. Somente com a percepção desse mundo somos capazes de saber que uma cadeira sempre será um objeto para sentar, não importa seu tamanho ou modelo.

Já o mundo dos sentidos seria o mundo em que vivemos, em outras palavras o mundo material, que só pode ser percebido porque todos temos a ideia de um mundo idealizado (as formas existentes no mundo das ideias). Esse mundo é defendido como uma cópia do mundo das ideias e por se tratar uma cópia está sujeito a erros e não é eterno.

Somos capazes de imaginar um código perfeito, pois essa forma está no mundo das ideias, mas jamais desenvolveremos um assim, pois o desenvolvimento pertence ao mundo dos sentidos. Qualquer código terá bugs, pontos a melhorar ou problemas de performance. Já a ideia do nosso código perfeito não, essa ideia é perfeita.

O paradigma da perfeição

Vivemos em mundo imperfeito, sujeito a vários erros. Usamos os aprendizados para tentarmos chegar a perfeição e nos livrarmos dos erros, pois acreditamos que o modelo idealizado por nós do código perfeito é um objetivo factível.

Infelizmente, é preciso te dizer que o código perfeito que foi idealizado por você, é impossível de ser alcançado, é uma utopia. Esse modelo que você idealiza como a perfeição, é incapaz de ser alcançado. Você não sabe exatamente o que falta para seu código ficar perfeito, mas você sabe que não está bom. O código respondeu a todas as necessidades com maestria, mas você ainda idealiza que ele não está bom.

Essa busca pela perfeição gera frustração naquele que tenta trazer para a realidade sua ideia imaginária de perfeição. A frustração muitas vezes impede o executor de continuar sua tarefa, pois o que foi executado não importa mais, importa apenas é a aproximação do mundo real com o imaginário. Parece que a cereja do bolo é mais importante que o próprio bolo.

Entender que a perfeição é algo inatingível, não é motivo para entregar resultados ruins. Não é por que é uma utopia que devemos fazer as coisas de qualquer maneira. Não se engane, até mesmo a perfeição, que é inatingível, é extramente útil como modelo de aperfeiçoamento.

Outro filosofo, que inclusive foi aluno de Platão, chamado Aristóteles, defendia uma outra linha de raciocínio que pode ser o caminho de saída da angústia da busca pela perfeição: a excelência. Enquanto a perfeição é uma impossibilidade, algo inatingível, a excelência é factível, pois significa “o melhor possível”, algo atingível ao ser humano.

Ser escravo da perfeição é aceitar um caminho de angústia, em contrapartida abandonar a perfeição pode nos tornar pessoas medíocres. A resposta está no meio termo. Precisamos reconhecer os limites e também de utopias para nos aperfeiçoarmos.

Sabemos que não atingiremos a perfeição, mas podemos ter compromisso com a excelência e colocar o nosso melhor naquilo que fazemos.

Espero que isso te ajude de alguma forma.

Twitter : https://twitter.com/omarkdev

Github: https://github.com/omarkdev

Usando o operador de coalescência nula do ES2020 no JavaScript

Marcos Felipe — Tue, 10 Mar 2020 12:30:51 +0000

Entendendo e utilizando o operador de coalescência nula que foi introduzido no ES2020

Photo by hossein khosravi from FreeImages

Foi introduzido um novo operador para gerenciar valores indefinidos ou nulos no ECMAScript 2020. A sintaxe do novo operador são dois pontos de interrogação seguidos “??”. O operador irá retornar o valor do lado direito quando o valor do lado esquerdo for nulo ou indefinido.

Atualmente a proposta de adicionar este operador está no estágio 4, que significa que está pronto para ser incluído. Você pode testar essa funcionalidade nas versões mais recentes do Chrome e Firefox.

A utilização é bem simples:

Bem parecido como antigamente

A similaridade com os outros operador && e || é bem grande, mas por que não utilizar os operadores antigos? Esses operadores são utilizados para manipular valores truthy e falsy. Os valores falsy são: null, undefined, false, número 0, NaN e string vazia. Já os valores truthy, são todos os outros valores não falsy.

A particularidade dos operadores && e || algumas vezes pode nos induzir a alguns erros. Imagine que um valor null ou undefined para você é algo que você tenha que se preocupar, mas o número 0 não, se você optar por utilizar esses operadores pode ser que você seja induzido ao erro.

Com o operador ||, o valor da direita é retornado pois o valor da esquerda é um valor falsy, na qual no nosso caso é um problema. Utilizando o novo operador de coalescência nula, fica mais simples essa abordagem.

E como já foi dito, o valor se preocupa apenas com undefined e null, todos os outros valores falsy são considerados como “verdadeiro”.

Esse operador é algo extremamente simples e útil, com a evolução da especificação estamos cada vez mais prontos para lidar com essas divergências de valores.

Espero que isso te ajude de alguma forma.

Twitter: https://twitter.com/omarkdev

Github: https://github.com/omarkdev

Community owners, stop being stupid!

Marcos Felipe — Sat, 02 Mar 2019 16:34:26 +0000

How problematic is it that an influential person starts talking stupid things and people start taking it as law?

I recently read an article that talked about a comparison of Fabien Potencier’s benchmarks (creator of Symfony) and Taylor Otwell (creator of Laravel). You can check the article:

Is Taylor Otwell Right About Fabien’s Statement on Symfony’s Benchmark?

Reading this article, I thought, how a PHP community is disunited, compared with other communities (mainly like the frontend) and that is due to the fault of the owners themselves.

It’s incredible how as only in our area we see specialized communities in just one area, like it would be strange a screw fan club organized by cabinetmakers. On the one hand, this is very cool because it promotes the evolution of a specific area, but this becomes a big problem when these areas begin to compete with each other and forget the purpose, which is to make the language more accessible for everyone.

Is Benchmark really the priority?

If Benchmark really were the priority, we would be talking about frameworks written in C in this article.

Surely benchmark can influence our choices, but I believe for a majority of developers, it is not the priority. There are thousands of other factors influencing choice, for example: Learning curve, labor market, agility, design patterns, documentation, design, community, among other things. Why do not we just talk about these points? Or do not they talk about these points?

The environment where the application is running influences more in the benchmark than the own technology.

“But there is a market in which they fight”

I agree, no matter how miraculously they leave stupidity aside and do things together, you still have comparisons, because they are different products. But if they really need to fight in the market and the benchmark is their top priority, why are not they competing with Code Igniter?

Basically, when that happens, everything community always says “Technologies are a means and not an end,” they ignore and try to prove that their grass is greener than the other. The worst of it all is when your followers start adopting it as truth, and things look more or less like this:

Your framework should provide for language evolution, not the other way round.

So Taylor Otwell and Fabien Potencier (and other community owners), stop the stupid fight and promote more things for the communities, so that we will have more people using their tools and consequently evolving them.

Twitter : https://twitter.com/omarkdev

Github: https://github.com/omarkdev