Postagens

Mostrando postagens com o rótulo Programação

6 maneiras de fazer a mesma coisa, o que é considerado boas práticas?

As vezes tem tantas maneiras diferentes de fazer o mesmo código que nós ficamos na dúvida quanto a qual maneira usar. O que seria considerado "boa prática" pela comunidade e o que sua equipe entenderia melhor. Suponhamos que você esteja trabalhando dentro de um método de um Domain Service chamado UmDomainServiceChique(objetoDoDominio) que será chamado por uma API. Você tem uma regra de negócio chique para ser verificada que por enquanto chamarei de VerificaMinhaRegraChiqueComplexa(). Você chama UmDomainServiceChique(objetoDoDominio) e caso VerificaMinhaRegraChiqueComplexa() retorne true você vai querer que UmDomainServiceChique faça o que tem que fazer e a api retornar Ok 200, caso contrário você quer que a API responda um erro qualquer, tipo BadRequest, e retornar uma mensagem dizendo que VerificaMinhaRegraChiqueComplexa deu ruim. Eu vejo 6 maneiras de fazer isso, gostaria de saber a opinião de outrs devs sobre qual seria a maneira menos gambiarr...

Verdades sobre programação

Imagem
Esse blog , do @luisdalmolin, contém um excelente texto sobre verdades não tão conhecidas sobre programação. Não tão conhecidas talvez pelos nossos chefes / stakeholders, mas muito bem conhecidas por nós. O post foi traduzido desse aqui   em inglês. Basicamente, o texto fala sobre o que já sabemos: 1) Dez programadores não farão o programa em um décimo do tempo assim como nove mulheres não fazem um bebê em um mês. (apenas uma grande suruba lésbica). 2) Bons programadores passam muito mais tempo lendo, estudando, pensando, refatorando do que escrevendo, codificando e debugando. É fato! Scrum e XP pregam isso. O resto é XGH (eXtreme Go Horse). 3) Programadores (e hoje analistas de sistemas também) são tratados como peões, na rabeira do organograma da empresa, muitas vezes mesmo se destacando em sua área, possuindo graduação, pós graduação e certificações, o que significa que um programador é tratado como um operário mesmo tendo estudado tanto quanto (em alguns casos muito m...

Primeiro de Abril dos programadores

Quem é do ramo de TI sabe o que são as normas RFC . São conjuntos de convenções onde são estabelecidos padrões para que computadores possam se comunicar e trocar dados entre si, e para que esses dados sejam reconhecidos por todos. Se não fossem essas normas o mundo da TI seria um caos (e já não é). É insteressante o fato de que a norma RFC 2550 foi criada em 1° de abril de 1999, e tratava do bug y2k, o bug do milênio. Desde que a convenção de dadas expressa em 2 dígitos para o ano foi criada sabia-se que em 2000 isso ia dar merda parar de funcionar, mas mesmo assim a solução foi deixada para 1999, a véspera. Lendo a norma, é possível encontrar o seguinte texto, bem - humorado apesar da seriedade e sobriedade das normas RFC: " Nearly everyone now regrets the short-sightedness of the programmers of yore who wrote programs designed to fail in the year 2000. Unfortunately, the current fixes for Y2K lead inevitably to a crisis in the year 10,000 when the programs ...

Nunca confie no TIOBE

Em vários posts meus eu mencionei o índice TIOBE para relacionar a popularidade das linguagens. Mas eu não sabia como o índice TIOBE funcionava, achei que ele era sério, baseado em projetos, mas ele é mais furado que o IBOPE, muito mais. O TIOBE classifica popularidade como número de resultados nos buscadores. Ele parte de vários pressupostos errados. 1) Assume que popularidade é o número de resultados de buscas de uma linguagem em um mecanismo de busca. 2) Assume que todos os buscadores tem o mesmo peso, embora os resultados sejam muito diferentes e o algoritmo também. 3) Não elimina ruidos. Se você pesquisar por java programming encontrará resultados relacionados com uma programação qualquer na ilha de Java, por exemplo. Além do ruido ser problema, a pesquisa é sempre feita com os termos <linguagem> programming, mas termos diferentes relacionados a uma mesma linguagem podem trazer resultados várias ordens de grandeza maiores ou menores do que <linguagem> programm...

O glorioso retorno do bom senso

Bom, desde minha volda das férias esse é o meu primeiro post técnico, ou quase. Bom senso  está relacionado à razoabilidade. E vale para tudo, de saúde à tecnologia. Ando vendo por aí muitas pessoas preocupadas demais com o monte de buzzwords do mercado, são as metodologias e certificações de qualidade (ITIL, PMBOK, RUP, Open UP, XP, Scrum, laranja, abacaxi, batatinha) outras relacionadas a linguagens de programação (Java, Python, C#, Ruby) e cada linguagem de programação se desdobrando em infinitos frameworks para os mais diversos assuntos (Hibernate, Fluent, Linq, velocity, rails, django, makumba , spring). Para complicar há ainda diversos sistemas operacionais, de windows a bada. E por falar em bada, diversos tipos de mobile (android, symbian, windows 7, bada, iOS, McDonalds, China in Box ). E as ferramentas para documentação de código ou criação de diagramas? ArgoUML, Poseidon, Model Maker... Nós, que lidamos com tecnologia, somos curiosos por natureza. Mas a curiosid...

A alma do programador

Certa vez, no curso de pós graduação da FATEC-SP, um professor que eu admiro muito, ao ser interrogado sobre quando teria uma janela para reposição de uma aula, sacou seu smartphone para conferir sua agenda e disse: " - Deixe-me primeiro consultar minha prótese cognitiva." Interessante, ele considerava o seu celular como uma prótese cognitiva. Não sabia em que lugar ir ou quando ir se não fosse por ele, o celular. Isso não é de todo ruim se você levar em consideração a filosofia geral que permeava a classe dos Samurais (Saburau ou Bushi) no Japão Feudal dos anos 1200 aproximadamente até 18xx (aproximadamente). Eles tinham um extenso e complexo código de ética/conduta verbal. Era o Bushido, ou caminho do Servidor. Os Samurais eram, em sua maioria, militares de alta patente, guarda costas, juízes e executores. A maioria deles era muito bem versado nas artes marciais, mas também na poesia e na caligrafia. Todos eram guerreiros no sentido mais amplo da palavra, mas nem todos est...

Vida de Programador ... Estranho

Imagem
Cara, hoje eu sou programador, mas já trabalhei 2 anos com suporte e daí eu tirei as histórias mais hilárias da minha carreira. (e perdi 70% dos meus cabelos também). Mas você pensa que o único problema do pessoal do suporte são os usuários? Nada, os programadores são boa parte do problema. No blog Vida de Suporte  me identifiquei muito com o personagem Mauro que fala .... estranho. Eu falo igualzinho quando dá algum problema. A explicação é simples: se o programador desenvolve sem uma metodologia fixa (vamos desconsiderar aqui as pressões por preço e prazo) ele testa a aplicação num universo ou contexto familiar a ele. Quando ocorre algum problema ou é descoberto um bug, ou a maneira de reproduzir o bug é desconhecida do universo de testes do programador ou ele até já esqueceu que funcionalidade é esta que ele construiu, o que ela fazia, para que servia e como usá-la. Ele só sabe que não era para dar erro. Se der é no mínimo ..... estranho. Agora vai saber (ou imaginar) po...