Programando Pedro

Recentemente, o Fabiano Vasconcelos abriu uma discussão no Grupo de Usuários de C e C++: De cara eu vi algo aqui um pouco estranho, se que o amigo Márcio me permite comentar: que muitos programadores, inclusive eu (se que posso ser rotulado como programador) foram instruídos com o princípio de NUNCA usar o goto, por ser considerado um mau estilo de programação. Durante a discussão, o Eduardo Vieira puxou um artigo da KernelTrap sobre uma discussão similar ocorrida no grupo de desenvolvimento do Linux, onde Robert Wilken disse o seguinte: In general, if you can structure your code properly, you should never need a goto, and if you don't need a goto you shouldn't use it. It's just "common sense" as I've always been taught. Unless you're intentionally trying to write code that's harder for others to read. É preciso colocar a máxima "goto considered harmful" na perspectiva histórica adequada. Acredito que praticamente todo programador trein...

afe! Enquanto não rola um estudo retrospectivo maneiro, aqui vão minhas primeiras impressões. por mais que pareça andar de ré, tenha um porting para o sistema do desenvolvedor, onde a compilação não é cruzada; não exija frameworks xUnit e faça bilhões de programecos se necessário; guarde no coração que não é preciso reflection nem mesmo shared objects para aplicar dependency injection; não despreze a tediosa tarefa de testar parte a parte, pequena parte a pequena parte; não tenha escrúpulos para satisfazer dependências aleatórias com stubs. A maior revelação para mim nesse processo foram os pontos 2, 3 e 5 acima. Após um longo tempo digerindo o problema, e após diversas discussões sobre que framework de testes usar, por fim completei a tarefa da forma mais tosca possível: cada teste é um programa executável individual.  O projeto usa cmake para configurar a construção, e o ctest funciona legal com essa lista de programas de teste. O maior esforço nesse processo foi refat...

Eu diria que a ruptura entre Análise e o Projeto acontece quando acabam as considerações sobre o problema e começam as considerações sobre a solução. Em outras palavras, o papel do Analista é considerar o problema, enquanto o papel do Projetista é o de considerar a solução. Assim, o Analista aparece quando um problema aparece, e dá lugar ao Projetista quando o problema foi devidamente analisado, restando produzir para ele uma solução. E diria que a ruptura entre a Especificação e a Implementação acontece quando acabam os artefatos para consumo por humanos e começam os artefatos para consumo por máquinas. Em outras palavras, o papel do Especificador é produzir artefatos para consumo por humanos, enquanto o papel do Implementador é produzir artefatos para consumo por máquinas. Assim, o Especificador aparece quando a atividade é produzir efeitos sobre humanos, e dá lugar ao Implementador quando os humanos estão devidamente satisfeitos e a atividade prossegue para produzir efeito...

Independência de plataforma é uma mentira. O seu sistema Java não é independente de plataforma. Ele é dependente da plataforma Java versão 4. Ou 5. Ou 6. Você não pode rodá-lo na plataforma Java versão 1. Ou na plataforma Micro Edition. Seu sistema C++ também não é independente de plataforma. Ele pode rodar em todos os Windows, mas não roda no Linux. Ele pode rodar no Windows e no Linux, mas não roda no Mac. Ele pode rodar no Windows, no Linux e no Mac, mas não roda no BeOS. Ele pode rodar no Windows, no Linux, no Mac e no BeOS, mas não roda no Symbian. Mesmo que o seu sistema seja puro C -- ISO C89! -- então esta é a sua plataforma, e o seu sistema não roda onde não há implementação para C, como chips experimentais que executam Java bytecode. Não existe código independente de plataforma. Todo requisito de portabilidade deve expressar explicitamente para quais plataformas o sistema deve ser portável.

A discussão sobre a proposta de regulamentação da profissão de Analista de Sistemas que está circulando no Senado provoca o debate sobre o verdadeiro valor da graduação. Sobre esse assunto eu tenho uma coisa para dizer com firmeza. O mercado não ensina você a ser um Analista de Sistemas. O mercado ensina você a ser um Horse . O mercado não tem nem a capacidade nem o interesse em transformar você em um Analista de Sistemas. A formação desse especialista é custosa e demorada. O fato de um diploma de graduação não ser suficiente para caracterizar um Analista de Sistemas não contradiz esse fato; ele o reforça . A empresa capaz de transformar incompetência em competência é Mecca para todos nós. Essa empresa não está contratando. Se você acha que não precisa estudar em uma escola porque já sabe tudo o que precisa, ela não o contrataria, de qualquer modo.

Está irritante ler o Java EE 6 Tutorial sobre RESTful web services. A interpretação que o texto dá para REST é um amontoado de lixo sobre o conceito original. O texto constrói uma distinção artificial entre REST e SOAP no que me parece uma tentativa de distinguir os mercados para JAX-WS e JAX-RS. É claro que isso é uma tolice, porque SOAP é um protocolo e uma representação de dados, enquanto REST é um princípio de arquitetura e design . Um design REST reproduz o design da Web: transferência de representações de recursos a.k.a. download. Um tal design não possui sessão e portanto o relacionamento entre cliente e servidor não mantém estado. Isso não tem nada a ver com usar ou não usar SOAP, usar ou não usar WSDL, estabelecer vínculos complexos ou simples com a aplicação cliente. Ninguém merece.

Todo esse papo sobre as vantagens e maravilhas do SOAP sempre pareceram um pouco suspeito, e agora finalmente eu percebi o porquê. De algum modo, me parece que o discurso de benefícios o SOAP é uma versão travestida do seguinte argumento: o melhor é reusar o HTTP porque o melhor é reusar os servidores HTTP pré-existentes ou, ao menos, porque o problema de implementação de um servidor HTTP tem solução conhecida. Uma crítica fundamental ao SOAP sobre HTTP é o fato de o HTTP não ter sido projetado como protocolo de transporte para outros protocolos; na prática, esse fato é simplesmente desconsiderado. Creio que isso evidencia as razões histórias para esse esquema: o valor não está tanto nas capacidades do HTTP como protocolo de transporte, mas nas capacidades das implementações do HTTP de suportar esta forma de reuso. Entendendo as coisas por esse ângulo, faz perfeito sentido que ao inventar uma plataforma de web services um sujeito reusasse, digamos, o Apache HTTP Server, ou o Mic...