Vinícius Knob

Quem nunca ouviu uma frase semelhante a essa: "Faz aí uma correção que resolve esse problema rapidamente, pois precisamos entregar isso para o cliente e tem que funcionar. Outra hora revisamos esse código com mais calma".

E assim iniciou-se um ciclo viciante (sim, viciante, essa é realmente a palavra) de pequenas inserções de código que visam boas intenções, obviamente, porém com consequências destrutivas no longo prazo. Se você já passou por isso sabe do que estou falando. São essas pequenas atitudes que fazem com que um projeto comece a ter pequenas amostras de código que poderão futuramente nunca ser substituídas.

Afinal, para que serve um paliativo?

Você já se perguntou? Bom eu vou lhe explicar. Um paliativo segue a ideia de um MVP praticamente, desenvolver o mínimo de valor entregável que gere um retorno e que atenda às expectativas do cliente. Só que um paliativo não pode ser chamado de MVP, ele apenas segue a ideia, aí você adiciona um pouco mais de velocidade ao processo (nesse momento você já deve estar no meio do fogo), e também algumas palavras mágicas devem ser proferidas: "Isso será temporário!".

Ei pera aí! Temporário? Eu acho que tem algo errado aí. Algo que deveria ser temporário acaba permanecendo por muito tempo no sistema. Na maioria das vezes esse paliativo recebe correções e até melhorias. Nesse ponto, significa praticamente dar uma armadura a um monstro que já existia. Você agora está fortalecendo esse monstro.

"O cliente não se importa com o código", muito se ouve falar isso. A única pessoa que se importa com ele é você, pois nem o seu gestor está interessado se aquilo é um paliativo, se é de fato uma implementação permanente, se é a melhor aplicação dos padrões de projeto que existe, ninguém se importa, somente você e agora você tem um monstro com uma armadura em seu sistema. Sabe por quanto tempo ele vai viver?

Por que paliativos são um problema?

Simples, pois eles funcionam. E somente por esse atrativo é que são tão requisitados e aceitos. E então esquecidos. Mas então qual é o problema com eles? Especificamente, o problema não está no paliativo. Se um sistema fosse apenas um paliativo, ele em si seria o sistema, logo não seria um paliativo, nem poderia ser chamado disso. O que estou tentando dizer é que nesse contexto o "paliativo" não é um problema, ele é um sistema. 

Quando o problema é o paliativo, você tem um problema no sistema. Um pequenino e indefeso código lá nos confins daquele bolo de classes e arquivos de configuração, no futuro pode resultar em um comportamento que precise de correção ou melhoria. Nesse contexto, nós temos um problema, mas o que é o problema: o paliativo inocente ou a situação do futuro que precisa mexer nesse paliativo? Perceba que aqui estamos falando de questões como planejamento e segurança: quanto estou disposto a me defender de possíveis anomalias conhecidas do meu sistema?

Bom, você tem um problema quando esse paliativo está em um local incomum, não rastreável, nem por olhos humanos, durante a rotina do dia-a-dia, e nem por sistemas de versionamento. Você também tem um problema com paliativos quando eles não seguem boas práticas como escalabilidade, legibilidade, manutenibilidade, responsabilidade, baixo acomplamento, e tantas outras mais. Aliás, um paliativo que segue essas práticas não pode ser chamado de paliativo.

Não sei se ficou claro, mas o fato de um sistema ser algo dinâmico faz com que você tenha que pensar no futuro. Já falei sobre o futuro logo acima. O paliativo somente será um problema se existir um futuro, e ele existe para a maioria dos sistemas. Partindo dessa premissa, talvez o problema realmente não seja o paliativo, mas sim você que chegou ao ponto de precisar de um paliativo.

Algumas táticas para contornar isso

Fugir dos paliativos é um pouco difícil. Você precisa deles e isso é inevitável por diversas razões: um paliativo de curto prazo é a melhor solução para que um projeto seja entregue, uma demanda seja finalizada ou uma correção em ambiente produtivo mantenha o sistema online. Então nesse caso o que fazer? 

Regra nº 1: Rastreabilidade

Primeiro passo é tornar esse paliativo rastreável, ou seja, você quer que esse paliativo dentro de algum tempo vire algo que seja revisado, e feito de forma correta e permanente. Estamos falando agora de código limpo, performático e fácil de entender. Um código que siga os padrões do Projeto e de Projeto (perceba a diferença entre "de projeto" e "do projeto", um papo para outro post). 

Se a sua empresa utiliza algum controle de issue, o melhor é neste exato momento que você está criando o paliativo também criar uma issue explicando como encontrar o paliativo e o que deve ser feito para que posteriormente alguém atenda a esta solicitação, ou mesmo você, e a correção deste paliativo resulte em uma implementação correta do mesmo. Se um Kanban é utilizado em seu projeto, essa é a hora de fazer um ticket ou story aparecer nele, provavelmente em backlog, o local não importa, mas alguma coisa deve aparecer.

Regra nº 2: Código Sujo

Sim, sujo, é isso mesmo que você leu, uma denominação que indica o oposto de código limpo. Uma importante atitude é não fazer com que esse paliativo seja algo excepcionalmente bom, ou seja, se você é um expert em código não utilize das melhores práticas, o palitivo não pode ser considerado um código fantástico que alguém vai olhar e pensar "Meu Deus, eu não vou conseguir fazer melhor que isso". Se esse código envolve telas faça uma tela com HTML puro as pessoas não devem gostar disto, a própria implementação deve ser um alerta para que as coisas sejam melhoradas.

Outra motivação para que esse paliativo seja sujo, é que fazer um código limpo geralmente demanda mais tempo, pois atender as boas práticas na maioria das vezes requer tempo, análise, uma relembrada dos padrões de código, conduta e convenções utilizadas. Se você está utilizando um paliativo, muito provavelmente esteja em um mal momento, algo está pegando fogo, então por que perder tempo com coisas bonitas?

Se você não tem saída e este paliativo deve ser uma implementação muito boa tanto em front quanto em back, performática e fácil de ler, então você ainda deve lembrar que tem a possibilidade de criar uma issue no sistema para rastreamento futuro. Se tempo não for o problema para você, por que está chamado sua implementação de paliativo?

Regra nº 3: Conhecimento

Eu não poderia deixar de falar sobre isso, pois esse com certeza é o assunto-chave para reduzir drasticamente a capacidade de você gerar um paliativo no sistema. Deixei ele por último, pois quero que esse seja o foco. As regras 1 e 2 são contingências, mas a regra 3 é o que realmente fará a diferença na sua vida.

Você já se perguntou por que chegou ao ponto de precisar de um paliativo? Bom, vou tentar listar alguns pensamentos, ou mesmo afirmações, que podem estar passando pela sua cabeça agora:

A plataforma/framework/lib que estou utilizando possui um bug, e agora preciso de um paliativo. Bom, você identificou um bug, será que consegue documentar esse bug e passar para a equipe de suporte desse recurso de terceiro que você precisa? Esse recurso está encapsulado e é acessível através de uma interface do seu sistema, e pode facilmente ser implementado um novo encapsulamento oferencendo a possibilidade de troca ou alternância de recurso? O ideal aqui é reportar o bug, mas também ter o sistema muito bem protegido para que uma troca de lib, por exemplo, não seja um problema. O acoplamento dessa lib no sistema deveria ser uma interface ou classe do sistema, e só. O nome desse padrão de projeto é Facade, mas nada impede você de utilizar o padrão Adapter, também conhecido como Wrapper, caso o recurso seja minúsculo e precise de adaptações para conexão com o seu sistema.

Outra pessoa da minha equipe gerou esse problema, e agora preciso de um paliativo. Ótimo, você identificou um problema no sistema, identificou o gerador, fez o paliativo. Hora de respirar? Não. Tente entender os motivos que levaram essa pessoa do seu time a criar esse problema para você. Muito provavelmente será falta de conhecimento, e agora você tem uma missão em suas mão: melhorar o processo de desenvolvimento do seu time. Você tem o conhecimento necessário para propagar de maneira controlada a informação de ações ou boas práticas para evitar problemas que geram paliativos no sistema. Um time é tão forte quanto seu integrante mais fraco.

Eu gerei esse problema, e agora preciso de um paliativo. Perfeito, você tem nas mãos um feedback perfeito para tomar uma atitude de mudança em sua vida. Melhore suas práticas de desenvolvimento de software, utilize testes unitários, crie anotações para não esquecer de configurações complexas de plataformas mal documentadas, utilize testes automatizados, explore mais as lógicas do seu código, teste em múltiplos ambientes, converse com outras pessoas do time, peça para alguém mais validar o seu código, peça por sugestões de melhorias, peça por sugestões de testes que podem ser feitos, explore mais as plataformas online como StackOverflow, teste como se sua vida dependesse desse código, teste, Teste, TESTE.

Para você desenvolvedor...

Se você leu até aqui acredito que seja alguém como eu, que deseja insamente melhorar, que seja curioso, que seja inquieto com o código fonte. Espero que meu objetivo tenha sido alcançado com você. Minha visão sobre o paliativo, o motivo de eu considerar isso um problema, como atacar o problema, mas principalmente o que fazer pró-ativamente para que um paliativo nunca seja necessário em seu sistema. 

Resolvi por curiosidade estudar o método estático RqlStatement.parseRqlStatement. No Javadoc da classe, pude observar que existem duas formas de utilizar o método com passagem de String para representar o RQL, algo muito comum quando estamos no mundo ATG e seus infindáveis properties de configuração. As duas formas podem ser vistas abaixo:

RqlStatement.parseRqlStatement(rql);

e

RqlStatement.parseRqlStatement(rql, cacheRqlStatement);

Quero focar meus esforços em apresentar a diferença entre esses dois métodos. Quando utilizado RqlStatement.parseRqlStatement(rql), o que realmente acontece é a execução do parse sem manter o objeto convertido em cache. Para deixar claro, esse cache é interno a classe.

Já no segundo método, o Javadoc descreve o processo da seguinte maneira:

"Parses an RqlStatement from the given String. If pCacheRqlStatement is true, then the RqlStatement that is created from this operation will be saved in an internal cache with the String pStatement as the key. The next time this same string is passed to parseRqlStatement, the cached RqlStatement will be returned, so we don't have to re-parse the same string over and over again. Only use this method for statements that you'll definitely be re-using over again, and if the code you're using does NOT cache the statement already".

Isso quer dizer que ao utilizar o segundo método ganha-se a possibilidade de armazenar no cache interno do RqlStatement uma referência do objeto convertido, não sendo necessário efetuar novamente a conversão do mesmo pela própria classe.

Para se ter uma ideia do impacto disso, montei 2 testes com JUnit: 1 sem cache e 1 com cache (informando o segundo parâmetro como true). Na imagem abaixo, pode-se ver como é alarmante a diferença entre ambos os processos quando temos 1 milhão de iterações. Sem cache o processo leva 62 segundos, mas com cache leva apenas 0,843 segundos.

Sendo assim, o melhor caminho seria utilizar RqlStatement.parseRqlStatement(rql, true), favorecendo a performance dos processos, otimizando o tempo em novas chamadas ao parse que possuam o mesmo parâmetro de RQL, não sendo necessário armazenar referências convertidas em atributos de classe, pois a classe RqlStatement faz isso.

Talvez você se sinta inclinado a querer a possibilidade de limpar esse cache quando quizer. Esse geralmente é um controle que Desenvolvedores do mundo ATG gostam de ter. Entretanto, lhe afirmo que esse não é um cache perigoso, daqueles que você realmente precisa limpar, pois algo foi atualizado em banco e agora a aplicação precisa refletir. Não! Esse é um cache interno a classe RqlStatement. Se o RQL for alterado por um properties dinâmico, tudo que a classe irá fazer na próxima iteração é armazenar o novo RQL convertido, sendo que o anterior não será mais utilizado.

Gostou? Compartilhe esse post =)

A API de Notificações permite que páginas web controlem a apresentação de notificações do sistema para o usuário final. Essas notificações estão em um nível acima da janela atual da página web, isso permite que elas sejam apresentadas mesmo que a guia não esteja selecionada, ou que você esteja utilizando um programa/aplicativo diferente. A API foi projetada para possui total compatibilidade com sistemas de notificação existentes nas diferentes plataformas.

Em plataformas compatíveis, existem dois passos muito simples para lançar notificações:

Solicitando permissão ao usuário

A solicitação de permissão para envio de notificações é um passo muito interessante. Que mundo seria esse se as notificações estivessem livres para uso desenfrado por todos os sites? Seria o carnaval eterno na web (acho que de qualquer forma isso já está acontecendo com alguns sites). Para evitar o problema clássico do uso sem limites, a API foi criada com uma premissa básica: notificações precisam ser ativadas pelo usuário final.

O seguinte código lança a solicitação de permissão, que nada mais é do que um popup, parecido com um tooptip ou popover, onde existe uma pergunta e as opções de resposta: permitir ou bloquear.

Notification.requestPermission();

Quando solicitar?

Depende. Gosto de pensar que essa decisão tem a ver com "se colocar no lugar do usuário". A maioria dos sistemas solicita a permissão ao carregar a página, mas tudo vai depender do tipo de conteúdo e do público alvo. Pense comigo, o conteúdo pode chamar mais atenção do usuário que a solicitação e ela acabar sendo ignorada. Quando uma solicitação é ignorada ela mantém o status default, ou seja, notificações não serão lançadas. O público alvo pode resultar no mesmo problema, pois se o seu sistema atinge pessoas que tem pouco ou nenhum conhecimento do que seria uma notificação elas podem simplesmente ignorar ou até bloquear (status "denied") a solicitação. Por padrão, os browsers não efetuam múltiplas solicitações de permissão se o usuário já bloqueou a primeira.

Lançando notificações

Após obter a permissão do usuário, seu sistema está apto a lançar notificações. O status da API está "granted" e criar uma notificação é muito simples:

new Notification(title, options);

title: Na notificação, o title fica na parte superior, com mais destaque;
options: Existem diversas opções de configuração, porém as que você realmente precisa conhecer são body e icon. O body recebe um texto mais descritivo, mais longo que o title, e que será apresentado no centro da notificação. Já o icon é uma url de uma imagem para ser apresentada na esquerda da notificação.




Isso é o suficiente para sua notificação ser apresentada ao usuário =)

Na imagem demonstrada acima você pode observar um exemplo de notificação existente no Queiroz.js. Já falei do Queiroz.js aqui no blog. No Queiroz.js, utilizo as notificações para avisar aos usuários de que alguns determinados horários do dia estão próximos de chegar. Isso ajuda consideravelmente o usuário que pode estar efetuando atividades em outras janelas, mas mesmo assim verá a notificação. Esse é um exemplo real, e foi utilizado exatamente da mesma forma que explico acima.

Você deseja que o usuário aceite a permissão, pois ele entende aquilo e sabe do que se trata, ou você simplesmente quer que ele aceite e viva com uma notificação que pode se tornar algo muito estressante e gerar críticas ruins? A maioria dos sites não se importa com a resposta para essa pergunta. Não seja mais um nesse grupo.

Encerro hoje meu primeiro curso na Udemy que teve como foco "Cloud Computing com AWS" e gostaria de compartilhar esse conhecimento com você. Dentre os assuntos abordados estavam: AWS com ECS, RDS, Elastic IP e Security Groups. Instalação e configuração de Apache, PHP e Wordpress em uma instância Linux. Google Cloud, Azure, Digital Ocean e Linode.

O curso realmente te mostra como iniciar no AWS com ECS, RDS, Elastic IP e Security Groups, de quebra ainda te ensina a instalar Apache, PHP e Wordpress. No ECS configurei uma instância Linux. No RDS uma instância MySQL. Acontece que aquele console da Amazon em questão de produtos, serviços e opções é algo para meses, não apenas 3,5 horas, em compensação as configurações para subir uma instância Linux, configurar um Banco de Dados, instalar um servidor Web, Wordpress e sair rodando é bem rápido.

Durante o curso tive a infelicidade de ser cobrado em $1 dólar, além daquele $1 dólar que a verificação do cartão de crédito me cobrou, por algum motivo que até o momento não sei, pois segui exatamente o que o curso apresentou, porém isso é uma questão de atenção. Se você é aluno como eu aconselho fortemente a ler além do que o curso te oferece antes de colocar a mão na massa mesmo durante o FREE TIER (período de 12 meses).

Estou feliz com o resultado, e sei que boa parte do aprendizado também depende de mim. Ao final, falar sobre Google Cloud, Azure, Digital Ocean e Linode fecharam com chave de ouro o super portifólio de conhecimento. No fim tudo é estímulo para levantar no próximo dia e correr atrás de mais e mais.

Cloud Computing já está aí há muito tempo, tenho certeza que estou atrasado e prometo recuperar esse tempo perdido. Quem sabe alguns posts?

Link para Curso

https://www.udemy.com/wordpress-na-amazon-aws-gratis-por-1-ano

Se você utiliza o sistema Dimep Kairos assim como eu, então você precisa conhecer o Projeto Queiroz.js.

Nesse post quero explicar o que é o Projeto Queiroz.js, motivação, finalidade, tecnologias envolvidas, enfim, quero apresentá-lo de uma maneira melhor da que foi feita no README do GitHub, e demonstrar como uma simples extensão para navegador pode facilitar a vida de muita gente.

Queiroz.js é uma extensão JavaScript para o serviço online de ponto chamado Dimep Kairos. Basicamente, a extensão fornece cálculos para facilitar a tomada de decisão no dia-a-dia. Se você tem curiosidade em conhecer o código, ou mesmo participar da criação do mesmo, pode conferí-lo aqui.

Como muitas coisas na área da programação, Queiroz.js nasceu da união de dois ingredientes: problema e conhecimento. Eu me perguntava "por que esse programa não mostra cálculo algum?", depois pensei "vou criar algo em JavaScript para rodar nesse console e logar o que preciso".

Como já foi dito, tudo começou no console de um navegador. Entre um console.log e outro, fui debbugando a interface de ponto, catando elementos, classes, tentando observar os padrões existentes até conseguir trazer para variáveis JavaScript os checkpoints contidos na tela.

Depois do console, foi para um arquivo onde cresceu até atingir a marca de quase 900 linhas de código. Eis a versão 1.0. O formato userscript ganhou lugar e as extensões Tampermonkey no Chrome e Grancemonkey no Firefox começaram a serem utilizadas como gerenciadores para guardar e executar o script. Nesse ponto o arquivo já estava rolando em conversas de Skype e e-mails.

A versão 2.0 foi marcada pela completa reescrita da estrutura do código. Com Gulp, consegui modularizar. Já estava sendo utilizado o Revealing Module Pattern, então não foi tão difícil separar em arquivos, e colocar o Gulp para automatizar diversas tarefas como concatenação e minificação.

A versão 3.0 teve uma grande reescrita do módulo core. Esse módulo é responsável por ordenar a chamada de cada um dos outros módulos fazendo com que todas as operações aconteçam em ordem, desde a coleta dos dados até a apresentação dos resultados. Essa versão também disponibilizou a primeira possibilidade de interação com o usuário: a funcionalidade DayOff, que permite "desligar" dias da semana que são feriados, ou coisas do tipo. Alguns commits depois, surgiu o TimeOn que permite informar folgas em horas. Recentemente, foi incluído a integração com Notifications API.

Não existe mistério. O código literalmente lê a view, coleta os valores de ponto, efetua as conversões para objetos Date e String, efetua cálculos em milisegundos e renderiza novos componentes em tela apresentando todos cálculos em formato humano. Tudo com JavaScript.

A montagem dos componentes HTML também é feita em JavaScript. Entretanto, antes da versão 3.0, foi feita uma propaganda sobre a mesma utilizando um modal. Esse modal foi feito em HTML puro, Gulp fazia a minificação, injetava em uma variável String utilizando replacement, depois renderizava em tela utilizando innerHTML.

Tudo na extensão é JavaScript. A estrutura que não é. O projeto hoje possui HTML, CSS, Strings e JavaScript. A união de tudo isso ocorre graças ao Gulp. Se você olhar no GitHub verá que existem arquivos separados para cada coisa, mas o que realmente é utilizado encontra-se na pasta dist, arquivo queiroz.min.js, que é um compilado de todos os módulos/arquivos.

Bom, em primeiro lugar: Conhecimento e Experiência. Queiroz.js me possibilitou conhecer inúmeras tecnologias, tanto novas como aprofundar as já conhecidas. Git e GitHub, por exemplo, mesmo utilizando no trabalho, hoje posso dizer que tenho muito mais conhecimento em Git Distribuído do que tinha antes. Padrões de Projeto com JavaScript também é algo muito bom e fácil de ser utilizado: Revealing Module Pattern, Observer Pattern e Module Pattern dão vida e organização ao Queiroz.js. Gulp.js é algo que realmente me deixou feliz: um automatizador de tarefas extremamente fácil de utilizar e graças ao Gulp.js a versão minificada e distribuída é tão simples de ser criada.

Em segundo lugar: Networking. Você realmente percebe que nada pode ser criado sozinho e considerado algo suficiente a todos. Receber constantemente opiniões de inúmeros colegas de profissão é algo incrível. Por diversas vezes eu respondo: "Como eu não pensei nisso?!". E imediatamente eu anoto para incluir.

Queiroz.js tem muito que evoluir ainda, que tal fazer parte disso também?