Dev Crítico 🦀

Vou começar a criar conteúdo lá, em breve. Começo a postar agora em Maio, não vai ser apenas sobre tech, vai ter meu dia a dia: Tech, games, treinos, outfits, cartinha de Pokémon, role eletrônico, etc. Quem quiser colar, prometo opinião polêmica semanalmente.

Agora é com você Claude

Acabaram as discussões, vai ser só um post e já era.

Nessa treta aí eu tô torcendo pra treta mesmo.

@vevereiro @_menneck Concordo!

@_menneck @DevCritico Usar primitivo sempre que da pra evitar essas merda ai

Algo que não entra na minha cabeça, é que o Java não tem um null safety como Kotlin. Pra mim é um absurdo essa parada, e não, Optional<> não é null safety. Sempre que vejo alguém falando de NPE, fico indignado como ainda lidamos com essa parada no dia a dia.

São coisas diferentes. O cliente da API pode passar o que ele quiser no payload, e o servidor pode aceitar e tentar fazer o parse ou não, a depender das validações (se existirem) no conteúdo. No caso do Kotlin, se um tipo Boolean é declarado, se você estivermos trabalhando com Spring + Jackson, se não estou enganado, naturalmente o Jackson vai lançar um MissingKotlinParameterException em uma request com campo Boolean sendo passado como null, bem mais elegante que um NPE. Mas além disso, e que é o principal ponto que estou batendo no tweet, é o fato de termos certeza que em qualquer ponto do código que tentarmos acessar um tipo Boolean no Kotlin, saberemos que o valor está ali.

@DevCritico Null safety do Kotlin não faz diferença para apis. Ela não impede null. A api vai quebrar da mesma forma que a versão em Java caso o campo seja nulo . Só muda o tipo de excessão

@vhmolinar NPE no Kotlin ocorre explicitamente ou com interoperabilidade com Java.

@DevCritico Null safety do kotlin nao previne o erro da postagem em questão. Vai acontecer uma runtime exception da mesma forma equivalente a NPE.

Boolean no Kotlin não pode ser null, Boolean? pode ser, mas você é obrigado a tratar a condição. NPE no Kotlin acontece por escolha explícita ou interoperabilidade com Java, isso é do design da lang, sacou? O que eu reclamo no Java, é que uma stack que até hoje não se preocupou com isso.

@DevCritico Pior que esse erro aí no Kotlin rolaria tbm.

Se você não consegue escrever e desenhar a solução que está planejando, você ainda não tem um plano.

Tema comum em mentoria: Todo mundo quer evoluir skill de Arquitetura de Software Uma das coisas que mais escutei enquanto mentor de outros Devs, é o desejo de evoluir conhecimentos sobre Arquitetura de Software. O problema desse objetivo, é que ele é extremamente vago: o que é arquitetura? Por exemplo, se você evoluir seus conhecimentos em k8s, e amanhã você se deparar com um problema que pode ser resolvido com service mesh, você evoluiu seus conhecimentos de arquitetura? Se você estudar AWS e seus serviços mais a fundo, e começar a propor soluções usando esses serviços, você evoluiu seus conhecimentos em arquitetura? Se você aprender mais sobre ferramental de dados, e começar a enxergar soluções que podem resolver melhor certos problemas com essas ferramentas, você evoluiu seus conhecimentos em arquitetura?

É basicamente a estratégia que estou seguindo nesse momento. SDD com escopo fechado e deploy incremental e Pair Review: Chamo a pessoa, e a gente faz um review juntos, já mexe na hora, commit, merge, deploy.

@eivey_namoral Eu diria que é indiferente, mas com o ponto de atenção para que se você for ter um portfólio, que seja aderente a sua posição.

@DevCritico Mas você diria que "atrapalha" a contratação de um Sr? Ou é indiferente?

Portfólio é algo que ajuda mais quem está em começo de carreira, não é tão determinante para posições Sr+.

É sério que tem gente tomando detergente? Mano…

se vc tem que fazer curso pra td, sugiro voltar umas casas e rever seu método: pesquisar -> experimentar (construir) -> reavaliar esteja confortável em não saber, e em errar pra descobrir. aprender não é acertar um alvo, é disparar e analisar até saber como o disparo funciona.

Databases are simultaneously the most interesting pieces of software in the world and the thing people want most to be "boring" tech. Availability, reliability, and performance are the big-three asks of a database. Postgres is > 1 million lines of C MySQL is > 4 million lines of C/CPP Incredible engineering effort goes into making boring tech.

Tudo é Full Stack! Sua especialidade até pode ser de back ou front, mas cada vez mais será cobrado para colocar a mão onde for necessário: back, front, infra, dados. Essa é a verdade.

FAAAALA DO CLAUDE!!!

build in public no LinkedIn e vocês aí falando de fonte por 75 reais.