DEV Community: Ð̸aniel ₿elintani

Confie mais no seu instinto

Ð̸aniel ₿elintani — Sun, 29 May 2022 20:05:21 +0000

O ‘sentido-aranha’ adquirido por Peter Parker funciona quase como um sexto sentido, uma espécie de habilidade premonitória, tal como as aranhas, que possuem um dos sistemas sensoriais mais impressionantes da natureza.

Diferentemente do sr. Parker, aqueles sem poderes podem no máximo explorar melhor sua intuição, que é o resultado de vários processamentos que ocorrem no cérebro. Pesquisas sugerem que o cérebro é uma grande máquina de previsões, constantemente comparando a informação sensorial e as experiências atuais com o conhecimento depositado e as memórias de experiências passadas. Cientistas chamam isso de “estrutura de processamento preditivo”.

Já é fato que, organizações que tomam decisões baseadas em dados estão melhores, comparado às empresas cujas decisões são orientadas apenas por instinto.

Mas como citei neste texto, “dados são o novo petróleo”, porém, nada ultrapassará o bem mais valioso, o TEMPO. Isso quer dizer que, trabalhar “data driven” é incrível, desde que, isso esteja trazendo ganho de eficiência, e que estamos economizando tempo.

Enquanto os dados não trazem conclusões para todas as decisões, é possível explorar o máximo da intuição das pessoas mais experientes. Se é pra errar, que seja em algo inédito!

Por muitas vezes a solução é óbvia, mas não estamos neurologicamente condicionados a recomeçar, limpar o campo de visão, e procurar o que pode ser removido, nós insistimos apenas em adicionar mais e mais conteúdo. No artigo apresentado na capa da revista Nature em abril de 2021, pesquisadores da Universidade da Virgínia explicam por que as pessoas raramente olham para uma situação — em todos os tipos de contextos — e pensam em remover algo como solução. Em vez disso, quase sempre adicionamos algum elemento, ajudando ou não.

O simples ato de se comunicar verbalmente, por exemplo, é algo que consideramos “automático”. Porém, comunicar-se fluentemente não é simples, o excesso de domínio que temos em falar, faz parecer fácil. Isso ocorre em mais campos de estudo. Aquilo que mais temos certeza não requer grande esforço para tomada de decisão.

Analisar este comportamento é inclusive um dos fundamentos que classificam o polígrafo como uma “ultrapassada pseudociência”. Um bom mentiroso pode ter muito domínio em mentir, assim como um inocente pode ter pouco domínio em narrar numa situação de interrogatório.

No ambiente corporativo, se você tem afinidade em determinado tema, confiar naquilo que parece “óbvio” pode lhe trazer muito ganho de velocidade. Questionar-se todas a cada passo, e sempre procurar por referência em dados — por mais que traga uma resposta final mais fundamentada e assertiva — pode fazê-lo deixar de economizar tempo, que ainda é o verdadeiro valor almejado.

Por isso o mais sábio, na minha visão, é uma mescla, atuando empiricamente para itens de alto conhecimento, e deixando o campo de pesquisa para itens de baixo domínio.

Originally published at https://belintani.com on May 29, 2022.

CQRS, direto ao ponto

Ð̸aniel ₿elintani — Mon, 03 Jan 2022 11:48:38 +0000

Com todo o seu charme, essa é daquelas expressões em inglês que arrepia a espinha de qualquer iniciante, e que todo profissional quando compreende o conceito, repete com orgulhos nos olhos.(veja como é a pronúncia)

CQRS é a abreviação de Command and Query Responsibility Segregation.

O que isso quer dizer?

Não misture "leitura dos dados" com "gravação dos dados"!

Quando usar

Sempre que possível. O "papo" de over-engineering não se encaixa tão bem aqui, uma vez que não é tão complexo assim.
Claro, sem hipocrisia, numa distribuição orientada à microservices, existe chance de ser um trabalho chato e menos justificável.

Como implementar

Existem duas técnicas, no qual vi ser as mais comuns:

1 - Criando classes distintas, separando propriedades editáveis de dados disponíveis para consulta.

    public class CreatePlayer
    {
        public string Name { get; set; }
        public string Alias { get; set; }
        public string DefaultPassword { get; set; }
    }

    public class UpdatePlayer
    {
        public string Name { get; set; }
        public string Alias { get; set; }
        public string Password { get; set; }
    }

    public class FindPlayer
    {
        public Guid ID { get; set; }
        public string Name { get; set; }
        public string Alias { get; set; }
        public DateTime CreatedTime { get; set; }
    }

2 - Separando acessos distintos de leitura e escrita, de preferência com credenciais diferentes para acesso à base de dados.

Um método deve ser Command ou Query, nunca ambos.
Command se refere às funções de criação, alteração ou exclusão.
E por eliminação, Query são as consultas.

Benefícios

- Princípio da responsabilidade única

Ao separar os métodos, já encontrará o código quebrado para uma única responsabilidade, o que facilitará na implementação de cobertura de testes, e também na própria manutenção.

- Dimensionamento Independente

Caso tenha um software com mais requisições de leituras do que gravação, é ideal usar dois bancos de dados separados, podendo dimensionar os seus modelos de forma independente.

Além disso, podemos desnormalizar o banco de dados de leitura, o que resultará em consultas simples, junções menos complexas, e tempo de resposta rápido.

- Separação de preocupação

As regras de persistência e atualização dos dados não irão influenciar nas consultas, e entregar credenciais distintas trará menores preocupações no acesso aos dados.
Não basta estar blindado ao "sql-injection", mas também a atenção para erros humanos, o que acontece com frequência em projetos de objetos dinamicamente mapeados por um ORM.

CQRS é simples, mas que traz preocupações reais do mundo corporativo, e este conceito será referenciado em outros textos futuros, principalmente sobre tópicos relacionados à segurança da informação.

Originally published at https://belintani.com on January 2, 2022.

O plano é seu, assuma os riscos e colha os frutos

Ð̸aniel ₿elintani — Sun, 12 Dec 2021 23:44:23 +0000

A prática de trabalhar o solo para obter uma colheita é quase tão antiga quanto a própria humanidade. E independente de crença, nada me passa a mente como mais histórico do que os Provérbios das Escrituras Hebraicas, com ~1600 anos.

“O que semeia a injustiça segará males; e a vara da sua indignação falhará” (Provérbios 22:8).

“Portanto, comerão do fruto do seu procedimento e dos seus próprios conselhos se fartarão” (Provérbios 1:31)

A analogia aos provérbios vem do pressuposto de que um Plano de Desenvolvimento Individual (PDI) sempre será da própria pessoa, e de mais ninguém. Assim, inevitavelmente, colhemos aquilo que plantamos, e só irá evoluir na carreira aquele que efetivamente planejar (semear), e posteriormente se doar na execução.

Como vai o seu PDI?
Materializa-se um PDI pelo processo de organizar as ações que irão levar o indivíduo a atingir um objetivo e desenvolver-se. No ambiente corporativo, procuramos principalmente, mas não exclusivamente, focar na evolução profissional.

A partir de algumas pesquisas, descobri que comumente empresas tratam o PDI como um guia prático para desenvolver competências e habilidades, e acompanham tais evoluções para condicionar o crescimento na carreira do profissional em questão. Outros ainda, acreditam que apoiar o PDI significa reservar parte da verba da área em cursos, livros e certificações.

Discordo destas definições. Contrariando a maioria, em PDIs nos quais oriento, procuro dar ênfase aos pontos fortes e em como explorá-los em prol do destaque, ao invés de dar foco nas fragilidades e incompetências.

Não escolhemos quais são as pessoas ao nosso redor, mas influenciamos aqueles que estão próximos a nós. Tendencialmente, se trabalharmos nos pontos fracos das pessoas, criamos uma linha da mediocridade, e igualamos todos a ela, e deixamos de explorar a aptidão de cada pessoa.

Ao elaborar um PDI com foco na aptidão, revertemos e geramos os diferenciais no mercado, e buscamos extrapolar as possibilidades já conhecidas.

Desta forma, conseguimos quebrar limites e criar os grandes profissionais diferenciados, dedicando exponencialmente mais forças onde encontramos resultados. No exemplo acima, dos pontos fracos, não evoluímos nenhum ponto de “criatividade”, e investimos muito pouco em “comunicação”, apenas o suficiente para alavancar os pontos de “comprometimento” e “know-how técnico”, estes sim, dedicados e hoje considerados diferenciais desta pessoa em específico.

Todavia, ter um PDI bem elaborado não é tudo. É preciso disciplina para seguir o seu plano! Neste “novo mundo corporativo”, com “internet das coisas”, “metaverso”, e uma infinidade de distrações, vemos as pessoas fazendo aquilo que gostam, e não aquilo que precisam.

Uma ajuda para que se tenha disciplina, é a percepção do sucesso. O problema é que sucesso está atrelado ao que terminou, e não sobre o que se fez. Aposte nas entregas “parciais”. Esperar para ver uma evolução completa do seu PDI pode demorar muito, e consequentemente, a recompensa não virá de imediato, e este será o início do seu fracasso. Sucesso justifica o esforço. Reconheça o que se faz, trabalhe com pequenos marcos, e nunca esqueça de celebrar.

O próximo passo é buscar destaque, e isso está atrelado em fazer mais do que os outros, e agregar valor no seu trabalho. Um ponto de vantagem por aqui, é que a maioria das pessoas vão optar por decisões baseadas em “não quero”, “não gosto” e “não preciso”, e quando saírem da zona de conforto, logo no primeiro final de semana, já estarão nas redes sociais, postando, “pagando de diferentes” e esperando resultados diferenciados. Siga o seu PDI, e já estará em destaque perante a maioria.

--
Originally published at https://belintani.com on December 12, 2021.

Estude como se não houvesse amanhã

Ð̸aniel ₿elintani — Wed, 13 Oct 2021 01:36:00 +0000

Para o filósofo francês Montaigne, revolucionário no tema da educação, o ensino deveria estar atrelado com o empirismo, ou seja, através de experiências práticas. Ele também asserta na sua obra Ensaios (1580), que as ações de uma pessoa dependem das circunstâncias presentes no momento da ação, mais do que da sua personalidade e do seu raciocínio.

Conhecemos a frase de Gandhi, "Viva como se fosse morrer amanhã", que é reflexiva e vastamente utilizada para um defender um Carpe diem eterno. Todavia, a mensagem por completo é:

"Viva como se fosse morrer amanhã. APRENDA como se fosse viver para sempre."

Inspirado nestes dois históricos nomes, digo-lhes.

Estude como se não houvesse amanhã.

Correndo o risco de parecer redundante, reforço o primeiro ponto destacado no meu outro texto, "O caminho do sucesso" agora com um pouco mais de profundidade sobre fazer dos estudos um hobby. Isso levará-lhe, naturalmente, a se tornar um excelente profissional na área de desenvolvimento de software.

Fomos condicionados desde a infância à obrigatoriedade com o estudo. Frases como "estudar para a prova", ou "estudar para ser alguém na vida", geram uma pressão enorme, ainda quando crianças, em demonstrarmos capazes de decorar mais do que efetivamente aprender.

O que vejo com frequência, são iniciantes da área de tecnologia confundindo praticamente TUDO. Estudando conteúdos fora de ordem, lendo os livros "clichê", e pior, por muitas vezes, desperdiçando o seu próprio tempo.

Para simplificar a leitura, e garantir a absorção do conteúdo, apresento abaixo algumas "dicas de ouro" na qual adoraria que me tivessem passado.

Curta a jornada. Se desenvolver software não lhe dá prazer instantâneo, considere trabalhar em outra área, ou trocar de emprego, ou mudar de linguagem de programação. Digo tranquilamente que troquei várias vezes o video-game pela IDE de desenvolvimento. Codificar deve ser um prazer.
Não faça pelo dinheiro. A computação em geral sempre foi, e provavelmente sempre será, uma área sem desemprego. É melhor reduzir o seu padrão de vida (dividindo as contas com alguém, não troque de carro), mas não venda o seu tempo! Ele é escasso. Se você procurar tocar projetos em paralelo, vai achar quem contrate... Não faça isso! tire o seu tempo livre para estudar! No futuro, valerá mais financeiramente, pode confiar.
Estudar, não necessariamente, é ler livros. Se desafie a criar um algoritmo e medir resultados, mesmo que sozinho, isso já é estudar. Claro, grandes autores já transcreveram décadas de conhecimento no papel. Procure pelos "originais", Uncle Bob, Martin Fowler, Kent Beck, Donald Knuth, e evite autores que simplificam ou distorcem algumas mensagens.
Tenha um par ou trio de estudos. A maior satisfação em aprender algo, é compartilhar, e com o passar dos anos, a sintonia se tornará tão grande, que um complementará o raciocínio do outro, como um super-combo de street fighter em cada brainstorming.
Não seja uma pessoa iludida. Muitos profissionais juniores, começam a se desconsiderar iniciantes, uma vez que conseguiram "ir longe" com um projeto e ganhar melhores salários. O importante é ter consciência de que é possível criar algo grande, impactar a vida de milhares de pessoas, mesmo no início da sua carreira! Não importa o título que a "empresa A " atribuiu-lhe como cargo, não use isso para se iludir e deixar de estudar. Antes de investir, pelo menos 10.000 horas em algum tema, ninguém é especialista no assunto, e na engenharia de software e ciência da computação não é diferente.
O privilégio de ter um mentor, pode acelerar, e muito, os seus aprendizados. Na vida, vários mentores auxiliarão-lhe: professores, colegas, sócios, investidores. Um bom mentor não lhe dará nenhuma resposta pronta, mas promoverá a elasticidade mental necessária para questionar-lhe na devida intensidade sobre os seus métodos, as suas fontes de estudos, e as suas tomadas de decisão.

Não deixe para amanhã, o que pode-se estudar hoje. Bons estudos.

--
Originally published at https://belintani.com on October 12, 2021.

O que é uma Graph API

Ð̸aniel ₿elintani — Sun, 26 Sep 2021 01:09:31 +0000

Uma Graph API é uma REST API, porém, seguindo uma modelagem de dados entre nodes e edges, permitindo executar a chamada de várias entidades de forma encadeada, com um único request. Apesar de ser um pouco diferente, isso não significa que todas as especificações anotadas na OpenAPI devam ser ignoradas, pelo contrário, segue fielmente as especificações de cada verbo http, por exemplo.

Não é raro a confusão entre o conceito de uma GraphAPI com o uso de GraphQL, esta segunda sim, é bem diferente do convencional, e só disponibiliza um único acesso GET e outro POST, recebendo uma consulta na semântica da graphQL.

Na composição de uma Graph API temos:

nodes — basicamente objetos individuais, como um Usuário, Página Conta ou Comentário
edges — conexões entre uma coleção de objetos com outros objetos
fields — dados sobre um objeto.

Object ID's

Os nodes, por representarem objetos individuais, obrigatoriamente possuem, cada um, a referência para um ID único no sistema inteiro. Assim sendo, para obter informações de um objeto, basta consultar diretamente pelo seu ID. Não precisa especificar o seu tipo na chamada.

GET 'HOST/{node-id}'

Fields

Para obter outros dados do objeto além do ID, é necessário especificar explicitamente na consulta, pelo parâmetro chamado fields.

GET 'HOST/{node-id}?fields={var1},{var2}'

Edges

Os relacionamentos entre objetos são encontrados pelas edges. Por padrão, elas retornam apenas ID's, mas assim como é para os nodes, o parâmetro fields pode ser utilizado para retornar propriedades específicas em cada nível.

GET 'HOST/{node-id}/{edge}?fields={var1},{var2}...'

Exemplo → Facebook

Para exemplificar, apresento abaixo alguns exemplos de consultas reais do Facebook, que implementa em suas chamadas REST o conceito de Graph API.

Obter as contas de anúncio do usuário corrente, com nome da conta e o limite de gastos.

GET 'https://graph.facebook.com/v11.0/me/adaccounts?fields=id,name,spend_cap'

"me" é o node, "adaccounts" é a edge , e "id,name,spend_cap" são os fields.

Para cada conta de anúncio, é possível executar outra chamada para encontrar alguns dados das campanhas que estão dentro das contas de anúncio.

GET '.../v11.0/{adaccount-id}/campaigns?fields=id,name,objective,effective_status'

"{adaccount-id}" é o node, "campaigns" é a edge, e "id,name,objective,effective_status" são os fields.

No exemplo acima, se o usuário possuir 30 contas de anúncio, a chamada para buscar as campanhas deve ser invocada 30x.

Por isso, uma Graph API possui o grande trunfo: a busca encadeada.

GET '.../v11.0/me/adaccounts?fields=id,name,spend_cap,campaigns{id,name,objective,effective_status}'

Se você pensou "parece mágica", bem-vindo ao clube!

Esta mesma explosão ocorreu-me em 2013, quando comecei a trabalhar com as Graph API's do Facebook

--
Originally published at https://belintani.com on September 25, 2021.

SOLID, direto ao ponto

Ð̸aniel ₿elintani — Sun, 26 Sep 2021 01:06:52 +0000

Ao trabalhar efetivamente com Programação Orientada a Objetos (POO), provavelmente os 5 princípios SOLID já estão presentes no dia a dia, mesmo que de forma não intencional.

S — Single Responsiblity Principle

(Princípio da responsabilidade única)

Ao separar a arquitetura do projeto em camadas, provavelmente as suas classes já são quebradas, mantendo-as com uma responsabilidade única.

O — Open-Closed Principle.

(Princípio Aberto-Fechado)

As classes devem estar abertas para extensão, mas fechadas para modificação.
Uma forma simples de implementar, é definir as ações do sistema em interfaces e referencie-as nas funções ao invés de trabalhar com as classes originais.

Exemplificando, considere Enumerable uma interface para utilizar na função de Count() que avança para a função Next() até acabar a lista. Em nenhum momento um array de um objeto foi citado, e a função Count() trabalha exclusivamente com a interface.

public int Count(Enumerable e){
    int i = 0;
    do {
        i++;
    } while(e.Next());
}

L — Liskov Substitution Principle.

(Princípio da substituição de Liskov)

Quando uma classe estende outra, trabalhe a classe de mais alto nível nas funções. Assim sendo, se existir a classe Eletronico, e as classes filhas Televisão e Laptop, sempre dê preferência por trabalhar funções que manipulam Eletronico.

public class Eletronico {
    public void Ligar();
}

public class Televisao : Eletronico {
    public bool suportaHDTV;
}

public class Laptop : Eletronico {
    public byte portasUSB;
}

public class SistemaIntegrado {

    public void LigarSistemas(Eletronico[] es) {
        foreach(e in es) {
            e.Ligar();
        }
    }
}

I — Interface Segregation Principle.

(Princípio da Segregação da Interface)

Não obrigue uma classe importar uma interface, se a mesma não for implementar todo o contrato.

Considere duas classes, ContaCorrente e ContaPoupanca, onde ambas podem receber depósitos e recebem a implementação da interface Depositavel. Caso seja necessário rentabilizar o dinheiro da ContaPoupanca, não adicione a função CalcularLucro na mesma interface, afinal, a classe ContaCorrente não irá implementar tal calculo. Crie uma interface Rentavel e atribua apenas nos tipos de conta que terão rentabilidade.

public interface Depositavel {
    public function Depositar(int valor);
}

public interface Rentavel {
    public void CalcularLucro();
}

public class ContaCorrente : Depositavel {
    public void Depositar(int valor) {
        // depositar em conta corrente
    }
}

public class ContaPoupanca : Rentavel, Depositavel {

    public void CalcularLucro() {
        // calculo base da poupanca
    }

    public void Depositar(int valor) {
        // depositar em conta poupanca
    }
}

D — Dependency Inversion Principle.

(Princípio da Inversão de Dependência)

Encapsule qualquer classe externa dentro de uma classe própria, e passe este objeto para as classes que irão utilizar. Um injetor de dependência já garante a inversão de dependência.

Por exemplo, não deixe a função EnviarEmail responsável por decidir como obter o Remente, e em vez disso, já receba pronto as instâncias necessárias.

public bool EnviarEmail(Remetente r, Destinatario d, Formatador f, EmailManager em) {
    return em.Send(r.All(), d.All(), f.ToEmailEncode());
}

Por hoje é só pessoal!

Continue a acompanhar as próximas publicações para abordarmos mais temas de forma descomplicada e direto ao ponto.

Verdades difíceis de engolir programação de software

Ð̸aniel ₿elintani — Mon, 17 May 2021 01:57:55 +0000

Sócrates sempre fez perguntas difíceis de serem respondidas: Quem é o homem? Por que existo? O que é o belo? O que é o justo?

Mas convenhamos que atualmente as pessoas não gostam de quem faz perguntas. Na verdade, elas gostam mesmo é de respostas prontas, porém quando as têm, relutam pela dificuldade de digerir certas verdades.

Conto com seu bom senso em debatermos sobre algumas verdades, e saiba que, negá-las não as tornarão em inverdades.

1. É preciso estudar programação todos os dias.

Procure trabalhar com pessoas que procuram falar sobre inovação diariamente, ou encontre um par de estudos. Atuar em projetos da comunidade é um excelente meio de contribuir para o seu aprendizado de forma mais dinâmica. Leia mais sobre este tema neste meu texto: Quem não inova, morre.

2. Existe sim, uma linguagem de programação melhor do que outras.

Certamente esta é a mais polêmica, e atrai muita discussão, mas não acredite nas bobeiras do seu amigo, algumas linguagens são sim, melhores do que outras. Empresas insistem na falácia de que isto não é verdade, apenas para que haja interesse de alguém para trabalhar com uma linguagem de programação horrível e arcaica, afinal, reconstruir tudo é muito caro.

Agora, dizer qual é a melhor linguagem não é uma resposta simples, até porque altera constantemente. Minha recomendação é olhar para algumas características: Contexto (o que você quer construir); Frequência de atualização; tamanho da comunidade; contribuição de seu(s) criador(es); performance computacional; e simplicidade na sintaxe.

3. A grande maioria dos programadores não são bons programadores.

Vivemos em um mercado aquecido onde não existe desemprego para quem iniciou uma faculdade na área, e a maioria esmagadora (uns 95%?) parecem não ter aptidão para tal carreira. As empresas sabem disso, mas ficam acuadas: o recrutador tem meta de contratação, o gestor tem meta de crescimento do time, e a diretoria prefere fazer vista grossa e fingir que possuem um time forte.

Os poucos destaques são os profissionais incríveis, e recomendo a leitura do meu texto: O caminho do sucesso é ser incrível.

4. Não é necessário um PC gamer para trabalhar.

Nos anos 90, programação de software já era um trabalho reconhecido, e nada impediu que grandes programadores se desenvolvessem e criassem algoritmos incríveis e software que mudaram a humanidade. Um computador gamer só serve pra uma coisa: Jogar. Mas todo programador usa o trabalho como desculpa para montar um “setup” cheio de led RGB e placa de vídeo de 8GB. Mas, apesar de desnecessário, recomendo jogos como um excelente passatempo.

5. O seu código um dia será apagado.

Infelizmente existe ciclo para substituição de todo o código criado. Se esforce em adequá-lo aos padrões de longevidade, mas saiba que o fracasso é iminente. Leia mais sobre este tema neste meu texto: O seu código vai virar lixo.

6. Performance é melhor que elegibilidade.

Recentemente vi programadores medíocres defendendo ser uma boa estratégia alterar um código de 50ms de resposta para 250ms em prol de uma leitura “mais fácil”. Sinto muito ser o porta voz, mas isso não deve ser feito. Não deixe que as suas limitações no entendimento do código lhe permitam cometer tal crime. Se o código anterior entregava 5x mais rápido, com certeza absoluta ele é um código melhor, e deve utilizar corretamente as características da linguagem adotada. Aprenda com o código, melhore-o se puder, mas nunca, jamais, piore o desempenho do mesmo se não for realmente necessário.

7. Um verdadeiro bom programador só nasce depois de 10.000 horas programando.

O conceito é bem conhecido, onde diz que para se tornar expert em qualquer assunto, é necessário contato por dez mil horas. Como programador de carreira, impossível eu não concordar com isso. Programar não é LER sobre. É experimentar, codificar front-end, back-end, mobile. Ter habilidade em codificar requer lógica, algoritmo, metodologia de estudo, e claro, desenvolvimento de um software por completo. Sou a favor das especialidades, mas defendo que, um verdadeiro programador precisa ser capaz de criar um software inteiro, mesmo que o seu forte seja só em uma vertical, o básico das outras é obrigatório.

8. Trocar de emprego o tempo todo mancha sim o seu currículo.

O tempo médio de programadores em startups de tecnologia é de 18 meses. Hoje, com a alta demanda, é possível sim fazer “pula pula” a cada 6 meses no inicio da sua carreira. Mas saiba que, quando você tiver 10 anos de experiência, essa falta de foco em construir algo poderá diferenciar entre conseguir um salário baixo, ou o salário maior do que o diretor da empresa. Quando encontrar uma empresa que você goste do projeto e da equipe, abrace-a e não troque por 20% de aumento, tenha um foco a longo prazo.

9. O quanto antes você falar inglês, melhor.

Existe uma grande mentira, de que é possível codificar apenas sabendo o básico do básico de inglês. Porém, nomear variáveis, métodos, e qualquer anotação requer o uso de termos claros, e escrever nomes ruins/errados em inglês é pior do que escrevê-los em português.

Mas não se precipite, não escreva códigos em português, ou todos vão lhe odiar. Não queremos códigos limitados a brasileiros, e por este motivo, o seu código deve ser escrito em inglês. O que fazer então? Corra e aprenda logo, está perdendo tempo.

10. Bug é erro de desenvolvimento.

Tal como um cozinheiro errando no tempero, ou um escritor se perdendo na história de um personagem, bugs nos software é um reflexo direto de um erro no trabalho de construção do código fonte. Então sim, criar muitos bugs significa que algo está errado com o desenvolvedor, seja correria, falta de foco, ou simplesmente, desânimo com a tarefa assumida. Assim como a uma década atrás era inevitável o fim dos "analistas de sistemas" (criadores de diagramas que não sabiam programar), profissionais que apenas fazem "Quality Assurance (QA)" já estão desaparecendo, dando espaço, finalmente (e como antigamente), para programadores garantindo os seus entregáveis de forma estável.

Sei que não é fácil ler tais verdades, são difíceis de engolir mesmo.

O caminho do Sucesso é ser Incrível

Ð̸aniel ₿elintani — Sat, 21 Nov 2020 18:03:45 +0000

"Se você não sabe aonde ir, qualquer caminho serve."

Já disse o Gato de Cheshire, um animal fictício famoso através do livro Alice no País das Maravilhas de Lewis Carroll

Sou apaixonado por tecnologia, e trabalhar com desenvolvimento de software foi justamente um dos caminhos que escolhi para me aproximar ao máximo dos avanços computacionais.

A trajetória em desenvolvimento de software não é curta, e diria até, sem fim. Ao iniciar tal jornada, vários caminhos são ofertados como especialidade: frontend, backend, devops, dados, automação, robótica, mobile, web, segurança, entre incontáveis opções que surgem e morrem com o tempo.

A escolha da especialidade não garante ascensão na carreira. O sucesso é reservado para os que conseguem se destacar, e são estes os Visionários e os Incríveis.

Pessoas visionárias. O maior desafio de um visionário, é empreender com um time de pessoas incríveis. Gosto da frase que Joel Beasley escreveu logo no início de seu livro: "Não tem mágica para ser um visionário. Está mais para uma persistência ímpia. É uma habilidade aprendida por necessidade."

Pessoas incrivelmente esforçadas (ou podemos chamar apenas de 'incríveis'). O que define, para mim, um(a) profissional incrível na área da computação:

Muitos dizem que dados são o novo petróleo. Porém, nada ultrapassará o bem mais valioso, desde sempre, que é o TEMPO. Uma pessoa incrível estuda como um hobby, usando o seu tempo livre com estudos na área de computação, simplesmente porque ama o que está a aprender. Pessoas "não incríveis" vão reclamar e esperar que alguém lhes pague para sentar e aprender, e se a empresa não o fizer, se acomodam e não estudarão. É muito legal quando temos apoio corporativo para evoluções e estudos, mas depender disso não passa de desculpa esfarrapada para si mesmo.
Um pré-requisito para se tornar incrível é fluência em alguma linguagem de programação. Esta capacidade é atribuída quando o profissional consegue traduzir qualquer código com a mesma facilidade de ler um texto na sua língua materna.
Alguém de destaque não terá dois ou três empregos simultâneos. Foco é uma palavra-chave, e só há destaque ao dedicar-se 100% num objetivo. Pessoas incríveis vão ocupar o seu tempo livre com a família (ou outro lazer) e estudos. Pegar freelancer ou "rodar um projeto paralelo" é sempre um tiro no pé de quem quer se destacar. Procure manter-se dedicado integralmente até o término do caminho principal já escolhido.
Ao buscar debates na área é possível receber feedbacks dos seus estudos e trabalhos, além de sempre sair com algo novo para estudar. A única atenção é não cair na armadilha de acreditar que basta ir em eventos (seja pago ou "boca livre"), liderados por ~~papagaios~~ pessoas que apenas repetem algo, e encher o seu laptop de adesivos. Procure conversar com especialistas num assunto. O ideal é ter um ou dois mentores.
Uma pessoa arrogante nunca será incrível, no máximo, será iludida. Ambição e humildade precisam caminhar juntos. Como diz o ditado: "A gente aprende, aprende, aprende e morre burro". Eu já escrevi neste texto sobre o seu código não ser eterno. Assumir que outra pessoa pode ter pensado em algo antes/melhor que você, é um excelente caminho para aprender. Por outro lado, a arrogância afastará bons profissionais de perto de você.

Os incríveis irão longe, mesmo que não saibam aonde querem chegar. As suas características o guiarão ao sucesso, inevitavelmente. Já as pessoas "não incríveis" podem até saber onde querem chegar, mas sem os comportamentos adequados, o 'atalho' levará apenas até a metade do caminho e ali permanecerão, iludidas, reclamando da empresa, dos colegas, e da vida.

Metaforando, uma análise não-funcional

Ð̸aniel ₿elintani — Mon, 02 Nov 2020 12:51:17 +0000

Atenção: Todas as piadas são referências ao canal metaforando, do Vitor Santos.

Eu sou Daniel Belintani, perito não-profissional de micro expressões regulares.

“Código nunca mente. Já os comentários as vezes o fazem.”

Acredito que a primeira vez que eu vi esta frase foi em 2009, e naquele momento a minha cabeça explodiu! Desde então, nunca mais documentei um código "só por documentar". Ao procurar o texto original e atribuir corretamente os louros ao seu criado(a), só encontrei o famoso Ron Jeffries, quando divulgou a frase ao tweetar, em 2018.

Diagnosticando um cenário, na prática, sobre uma função que irá finalizar um carrinho de compras.

Até o momento, a análise realmente prova de que os comentários mostram descritivos congruentes. Apesar destes comentários serem completamente inúteis dado a sua redundância.

Seria aceitável que este código na sequência precise começar a verificar se o carrinho não está vazio:

Conforme o protocolo SPAMS, podemos observar que o descritivo da função "finaliza um carrinho, ou mostra mensagem de erro" já apresenta o seu primeiro comportamento incongruente. Fica evidente a inexistência de um comentário direto, onde função evita dizer: "eu retorno warning". Isso poder ser justificado por um simples esquecimento dos fatos pelo(a) programador(a).

Esta alteração no código também apresentou uma expressão de IDH (início de um histórico) na L9 seguido de um FDH (fim de histórico) na L14. O que de fato, não é um comentário bem-visto pela comunidade, sendo que há controladores de versão (ex: git) para exercer tal função.

Os comentários são então removidos no PR (pull request), mas alguns meses depois, um BUG traz uma nova pessoa para este código, e sem nenhum apego emocional, temos a alteração abaixo:

Vemos então um comentário desesperado, guiado pelo sentimento de vergonha ao fazer uma gambiarra desnecessária. É comum que pessoas culpadas deixem comentários como rastro dos seus crimes, na crença de que ganhou um "passe-livre da prisão" ao justificar-se com um comentário.

Outro comportamento de um comentário que tende a ser mentiroso, é o excesso de ~~tensão~~ textão, onde é adicionado um comentário longo para que ninguém leia. Este comentário, muito provavelmente não sofrerá a devida alteração quando algo mudar na regra de negócio.

Desconfie também de comentários que forçam a sua IDE (ferramenta de escrever código) a minimizar parte de códigos, isso pode ser considerado "afastamento e quebra de contato visual", muito utilizado por truques de mágicas.

Comentários podem ser mentirosos. Cuidado. Porém, existem comentários úteis:

Comentários em acessos públicos. Se o código for "fechado", seja num servidor, ou em uma SDK, quem desenvolveu tem o dever de documentar e manter atualizado a explicação de como utilizar e qual a sua função. Para APIs a solução mais comum é o swagger.
Comentários de TODO. Nunca deixe de anotar parte do código que ficou faltando algo ou que pode ser refatorado. Basta adicionar "TODO: o que fazer" nas linhas de referência.

Lembrando também que esse texto é um estudo, no qual venho na condição de perito dar uma visão, mas essa não é uma cartada final muito menos a verdade absoluta, é apenas uma análise.

O seu código vai virar lixo

Ð̸aniel ₿elintani — Wed, 28 Oct 2020 11:18:32 +0000

Este título não se trata apenas de um clickbait, mas sim um tema sensível, uma vez que pode atacar diretamente o ego de quem vem a construir software ao deparar com o fim trágico e eminente do seu trabalho.

Participei ativamente de pelo menos 250 contratações de devs nos últimos anos, e considerando uma média de 30 entrevistas presenciais para cada posição, estamos a falar de algo em torno de 7.500 reuniões de recrutamento. Acredite ou não, uma das frases que mais escuto dos participantes é:

"Eu não faço código para ir parar no lixo".

Algo interessante é que esta frase sempre traz o gatilho que preciso para compartilhar um pensamento que propago há alguns anos: "Todo o seu código, ou boa parte dele, vai virar lixo". A reação de espanto ou choque de realidade é instantânea para quem escuta pela primeira vez, e claro, ao mesmo tempo, já utilizo para avaliar comportamento ao ser confrontado(a) em algo que sempre repetiu a carreira toda.

A explicação é relativamente simples. Quem acompanhou o meu outro texto "quem não inova, morre" já sabe que trabalhei utilizando Adobe Flex Builder, para gerar websites em flash, e que sofri um pouco criando widgets J2ME (java micro edition). Também criei soluções web com applets (java), trabalhei em sistemas criando interfaces no Microsoft Access 95, e até em um ERP inteiro desenvolvido em Visual Basic 6.0, tudo isso há mais de 10 anos atrás. E se alguém julga que não poderia ser pior, desenvolvi um sistema inteiro em Microsoft Silverlight (competidor do flash), e até já utilizei uma "linguagem de programação própria" de uma empresa privada.

Isso quer dizer que, apenas do meu trabalho, milhares de horas de programação, e incontáveis linhas de código, foram parar no lixo.

Alguns fatores responsáveis por direcionar códigos para a lixeira:

Qualidade: Se o código não for legível, é mais fácil apagar e escrever novamente
Desempenho: Se o código não está devidamente desacoplado (independente) e preparado para escalar, outro virá para fazer o mesmo processo mais rápido
Tecnologia: O fator mais injusto de todos. Ao atualizar frameworks e linguagens, novas opções entram no mercado, até que um dia o código é depreciado por completo.

Uma das missões de todo bom profissional na área é justamente aumentar a longevidade do código o máximo possível, certo?

O primeiro passo que recomendo é justamente o reconhecimento. Saber que o código um dia será apagado, o que precisa ser feito para garantir que ele atenda o seu propósito pelo maior tempo possível.

Adicionar teste unitário no seu código é um excelente início. Sem ele, é quase certo que outra pessoa vai achar mais fácil apagar e reescrever a sua função. Todavia, se o código estiver com 100% de cobertura, com todos os casos mapeados, a probabilidade do código "sobreviver" a manutenção é exponencialmente maior. O ponto de atenção é que teste unitário mal elaborado/pensado, provavelmente vai parar no lixo a cada nova alteração.

Utilizar tecnologia de ponta é o mais óbvio. Se um ciclo de vida de 3-5 anos já é considerado longo para um software, o que acontece se for utilizado uma linguagem de programação ou framework com 2 anos já atrasado? O código vai parar no lixo 2 anos mais cedo, simples assim! Nunca inicie um projeto utilizando tecnologia antiga, por mais que "a curva de aprendizado vá tirar-lhe da zona de conforto", o compromisso em lutar contra a remoção do seu código tem que ser mais relevante. E se, o que lhe limita é a tecnologia já adotada na empresa, termine este texto, agende um compromisso de 1 hora na sua vida, PARE TUDO, e vá ler sobre microsserviços e virtualização com docker.

Além disso, mantenha um código elegante. Estude MUITO a tecnologia do momento, pois, sempre estará em aprimoramento, uma vez que concordou com tudo que escrevi até aqui, e logo, estará anualmente se atualizando com novas tecnologias. O trabalho árduo não trará uma visibilidade tão imediata da sua maturidade, mas posso afirmar-lhe que após 10 anos seus códigos serão naturalmente elegantes. Alguns materiais mais antigos podem ajudar no pontapé para quem está a iniciar, como o Clean Code, e o Clean Architecture, mas realmente o que mais recomendo, é a participação ativa na comunidade. Abrace um ou dois projetos open source grandes, tenho certeza que aprenderá muito só de observar outros códigos.

Para quem aguardou até aqui para discordar, sim, existem vários códigos que se mantém vivos por décadas, estes normalmente associados a código de baixo nível (alta performance), extremamente objetivos (elegante), e testáveis. Confie em mim, eles só estão preparados para longevidade, mas eles vão para a lixeira algum dia, é questão de tempo, nem que seja numa era da computação quântica.

Afinal, qual a longevidade buscar? A fórmula é bem simples. Custo x Benefício.

Reconhecendo o fracasso iminente do seu código, e o esforço em adequá-lo aos padrões da longevidade, coloque na balança.
Se em três horas for possível produzir um código que irá durar seis meses, logo, em doze horas deveria ser criado algo para permanecer por mais de dois anos. Caso contrário, não é tão vantajoso assim.

Contudo, isso depende. Em startups, a grande armadilha mora no over engineering. Muitas vezes devs com muita experiência de mercado insistem em dedicar 200 horas em criar uma funcionalidade que poderia ser desenvolvida em 40 horas (e durar apenas um ano). Para tirarmos vantagem (CxB), o código precisa durar cinco anos. E o mais bizarro é que normalmente são códigos preparados para tal longevidade. Mas nem tudo são flores e tão simples.

O que erroneamente acaba a ficar de fora da equação é o time to market. Uma startup precisa sempre estar de olho em aproveitar o momento. Não adianta negar, todos queremos o famoso unicórnio, e quando buscamos crescimento exponencial, é mais vantajoso ter um código que irá durar um ano, mas que é desenvolvido em uma semana, do que uma funcionalidade que vai permanecer imutável por cinco anos levando mais de um mês para ser construída. Afinal, é startup, a cada trimestre o foco ainda pode mudar, e uma funcionalidade nova poderá trazer "aquele cliente" que salvará as contas do mês.

Isso não é um passe livre para criar um monte de código lixo! Afinal, queremos um código que vai parar na lixeira, e não que já nasce lá.

Esteja preparado(a) para criar um código que irá durar muito, será útil algumas vezes.
Entenda a solução que está a construir e o momento de mercado. Não seja apenas um peão neste jogo de xadrez, entenda o projeto na totalidade.
Por fim, comunique a sua estratégia para os colegas, não faça um código rápido, e nem extenso, sem antes compartilhar a sua visão com os demais membros do projeto, e tomando a decisão no coletivo.

Quem não inova, morre

Ð̸aniel ₿elintani — Wed, 28 Oct 2020 11:16:49 +0000

Esta verdade inquestionável já deve ter passado por seus ouvidos em algum momento. Talvez a primeira vez em um caso de estudo da Yahoo, vendida a Verizon por 4% da sua maior valorização histórica; ou quem sabe em algum podcast falando da Nokia, quando insistiu em seu teclado qwerty até ser esmagado pelo atraso na adesão ao android após a revolução do touchscreen liderado por Steve jobs no iPhone;

Aproximando mais a nossa realidade, em inovação tecnológica, grandes nomes reforçam a importância da inovação, como Elon Musk, ao citar:

"O fracasso é uma opção. Se as coisas não estão a falhar, não está a inovar o suficiente."

ou Steve Jobs, quando defende que:

"Inovação é o que distingue um líder de um seguidor. As pessoas loucas o suficiente de pensar que podem mudar o mundo, são aquelas que o fazem."

Em analogia com o instinto de sobrevivência, seria natural a reflexão sobre "o que é inovação". Vejamos algumas definições.

Segundo Barack Obama:

“Inovação é a criação de algo que melhora a maneira como vivemos as nossas vidas".

Já para Peter Drucker, considerado como o pai da administração ou gestão moderna, e influenciador de um grande número de líderes e de organizações em todos os setores da sociedade:

"Inovação é a mudança que cria uma nova dimensão de desempenho".

Em termos práticos, de acordo com Schumpeter:

"Inovação refere-se a qualquer nova política para reduzir o custo total de produção ou aumentar a demanda por seus produtos".

Saindo da teoria e observando parte da minha vivência pessoal no mercado de tecnologia nacional, posso citar alguns exemplos que comprovam o quanto, cada dia a inovação é necessária para manter um produto ou empresa no mercado.

Dentre os mais marcantes, impossível não questionar as inovações no universo dos dispositivos móveis. Há apenas uma década (meados de 2010), ainda nos primórdios da IoT (internet das coisas), criar uma simples funcionalidade para rodar em celular não era fácil, tínhamos inúmeras limitações de memória, processamento, e bateria. Requeríamos no mínimo um estudo em J2ME (java micro edition). Já nos dias de hoje, após muita inovação na área, felizmente, temos a facilidade em certo nível de que até jovens já estão criando seus próprios aplicativos.

Outro exemplo bem ilustrativo é o universo dos bancos. Quando iniciei na área, estava claro que bancos "já faziam tudo que precisava", e empresas insistiam que aprender Cobol era uma grande oportunidade de se manter no mercado até a aposentaria, uma vez que era "impossível" os bancos desistirem dos seus mainframes. Porém, nos últimos anos vimos nascer Bancos 100% digitais, acompanhamos os bancos "tradicionais se reinventando / inovando, e temos pela frente o lançamento do PIX, novo ecossistema de pagamentos instantâneos (quase uma criptomoeda estatal, mas vamos guardar o tópico para outro papo).

Existem empresas fortes que se mantém em atualização, mas a grande parte de inovação hoje está descentralizado em milhares de startups pelo mundo. Os novos unicórnios somados trazem uma representatividade alta perante investimentos nas grandes companhias, o que torna a famosa "acqui-hiring" (processo de aquisição de uma empresa principalmente para recrutar os seus funcionários) cada vez mais valiosa. Confie em mim, se não estiver a inovar, não receberá uma proposta.

Na área de desenvolvimento de software, buscar inovação é algo corriqueiro, e fugir não é uma opção inteligente. Certamente você deve trabalhar com as linguagens de programação mais atualizadas, usar as últimas versões de software, e estar antenado(a) nas tecnologias emergentes.

Alguns colegas que não me escutaram em 2010 quando os alertei, seguiram teimosamente até a ruína de tecnologias como a Adobe Flex Builder , que utilizava Java para criar apps em flash.

Temos sim muito código legado e sistemas que funcionam bem com tecnologias arcaicas atualmente. Não caia na conversa fiada de que "é um sistema velho, mas nunca vai morrer". Tudo terá um fim, assim como o próprio código que acabou de escrever também terá um destino trágico (lixeira), seja por problemas de escalabilidade, desempenho ou limitações de integração.

A minha sugestão é que busque o conhecimento básico, e entenda como tecnologias anteriores contribuíram para o cenário atual, mas que principalmente, procure trabalhar em empresas que estão a procurar inovação.

Se por acaso inovação não faz parte do seu dia a dia corporativo, mude de emprego! Caso contrário estará limitado(a) e não poderá usar recursos computacionais mais atualizados, terá uma comunidade fraca para se relacionar, e ao longo prazo, perderá currículo e ganhará menos dinheiro. Um caminho conhecido é esquivar-se das propostas das grandes corporações engessadas e apostar nas startups, e tenha certeza que a experiência de 1 ano vale por 3 anos numa empresa que tem inovação como o seu diferencial.