Recentemente o SANS Institute divulgou um artigo interessantíssimo listando os 25 erros mais perigosos - e comuns! - cometidos por desenvolvedores de software. São erros críticos, que podem comprometer todo um sistema e expor este a ataques de pessoas mal-intencionadas ou mesmo de usuários curiosos

Sem delongas, segue a lista dos erros.

1) Má (ou inexistente) validação de dados do usuário

Um dos “mandamentos” de todo programador: “Nunca confie nos dados do usuário!“. Sempre, sempre faça validação. Como fazer isso irá variar conforme a sua aplicação. Por exemplo, se o seu sistema perguntar a idade do usuário, confira se o valor digitado é um inteiro.

2) Uso de encoding errado no output. (ou falta de “escape characteres”)

Encoding - ou codificação - é a nossa segunda fonte de erros.

Digamos que você tenha um componente A no seu sistema, que se comunica com o componente B através de comandos. Pois bem, digamos que um dos comandos seja IMPRIMIR palavra o que acontece se o componente A quiser imprimir a string IMPRIMIR? Se ele enviar IMPRIMIR IMPRIMIR o componente B pode achar que são dois comandos, e então desencadear uma falha substancial no sistema.

3) Falha em preservar a estrutura de uma query SQL (SQL injection)

SQL Injection é uma das técnicas hacker mais simples e, ao mesmo tempo, mais eficientes.

Sem me alongar nesta falha, eu apenas pergunto: O que acontece nas suas aplicações se o usuário entrar com o valor ‘; DROP TABLE users;’# ?

Nada? Afortunado ou prevenido és, caro leitor…

4) Falha ao preservar a estrutura do seu documento HTML (Cross-site scripting).

Digamos que você tenha um site onde os usuários podem criar um perfil, com uma breve descrição.

Então, um usuário mal-intencionado insere um pedaço de código HTML nessa descrição, que explora uma falha em um browser conhecido (o IE, por exemplo. )

Se o seu site nao retirar este pedaço do código da descrição do usuário, outros usuários podem acessar o perfil e sofrer as consequências da execução do código malicioso. E o culpado, pasme, é você.

Vou continuar com as outras falhas no próximo post, para este post não ficar muito grande - e ninguém ler.

Ok, não é em apenas 1 post que eu vou conseguir ensinar uma coisa dessas - coisa, aliás, que eu mesmo ainda não descobri

Mas um exercício interessante é analisar as carreiras de grandes personalidades do meio, e quem sabe, através da estatística, descobrir um fórmula de sucesso. (Nada mais nerd do que isso)

É exatamente isso que é feito no post
“Famous Programmers From Adleman to Zimmermann”

Vale a pena ler.

A Universidade de Stanford - uma das melhores do mundo na área - anunciou que vai disponibilizar gratuitamente o material completo de vários cursos de tecnologia, como engenharia, ciência da computação e inteligência artificial.

A página do projeto pode ser acessada aqui -> Stanford Engineering Everywhere

A iniciativa, parecida com o “MIT Open Course Ware” do MIT, reforça uma nova tendência no meio acadêmico de computação - que particularmente aprecio muito - de disseminar conhecimento para a comunidade.

Para quem conseguir um tempinho na agenda, é uma ótima oportunidade de ter um curso de Stanford ou do MIT no currículo.

Estava eu no hall do café da empresa que trabalho, esperando a máquina terminar meu expresso, quando ouço o seguinte diálogo:

- C++ é muito melhor do que Java, cara.

- De jeito nenhum!

- Claro que é! Para te provar isso, você sabia que a máquina virtual do Java foi escrita em C++?

Agora eu te pergunto, amigo leitor: O que tem a ver uma coisa com outra?

Isso me levou a pensar sobre o comportamento de alguns colegas de profissão - e, algumas vezes, o meu próprio comportamento.

Linguagens de programação são apenas ferramentas, e devem ser tratadas como tal, e não como uma ideologia. Aliás, a primeira qualidade de um bom profissional é saber escolher corretamente suas ferramentas, deixando de lado emoções e gostos pessoais.

Ora, por acaso você já viu um mecânico de automóveis tentando tirar um parafuso com um martelo, simplesmente porque ele acha que o martelo tem uma usabilidade melhor? Pois é exatamente isso que as vezes fazemos, por não dar voz à razão.

Hoje trabalho com desenvolvimento de software embarcado nativo, em C. E nem seria louco de propor o uso de Perl, por exemplo. Java? talvez um dia.. mas não hoje - e nem nas camadas que “falam” diretamente com o hardware. Seria loucura.

Durante a minha carreira, já programei em PHP, Perl, Java, C, C++, JavaScript… qual é a melhor? nenhuma delas. Todas são ferramentas importantes guardadas na minha modesta caixinha, prontas para serem usadas quando eu julgar conveniente.

Muito se discute sobre metodologias de software e hoje estou convencido de que não é possível o desenvolvimento de software sem uma metodologia eficiente. E toda metodologia traz consigo uma série de processos a serem seguidos. E,  este eh um ponto importante que diferencia as diferentes metodologias presentes no mercado: a quantidade de processo que cada uma traz consigo.

Mas… qual é o limite ideal da relação programação/processo?

Os desenvolvedores irao brigar pelo desenvolvimento, e o pessoal dos times de qualidade, pelo processo

Mas que tal olhar sob o ponto de vista do usuario? sera que ele se importa realmente se o software que esta usando eh proveniente de uma empresa com certificacao CMMI? Eu, como usuario, nao me importo.

Sob este ponto de vista, acredito que a quantidade ideal de processo eh a minima possivel, para que seja possivel o gerenciamento do projeto, mas que nao leve o desenvolvedor a passar mais da metade de seu tempo preenchendo formularios. (quem trabalha em empresas de porte medio a grande sabe do que estou falando… )

PS: me perdoem a falta de acentuacao, estou postando de um PC desconfigurado..