Estudar para que se eu já sei o que fazer

{ November 1st, 2007 }

Autor: cmilfont

Tenho severas críticas ao modelo educacional, principalmente o superior. Vou e volto para a faculdade de tempos em tempos, minha escola real está nos livros, a faculdade é pelo diploma porque a falta dele as vezes fecha portas que não tem como serem abertas e em determinados momentos precisam serem ultrapassadas.

Minhas críticas derivam principalmente da falácia e do sofismo, as pessoas acreditam que possuir um nível superior as credita para a qualificação necessária a uma determinada tarefa simplesmente. Quantos alunos estão se formando esse ano em Ciência da Computação sem a necessária qualificação? A maioria? Todos? Nenhum? Como saber se não existe um mecanismo eficiente de provar isso?

Na ausência de um mecanismo eficiente, o mercado sempre adota pontos factuais para basear suas contratações, e uma delas é o porte de um diploma de curso superior.

Fiz quase todas as cadeiras que envolvem desenvolvimento de software: Estrutura de dados, laboratório 1 e 2, técnicas de programação 1 e 2, lógica matemática, teoria da computação, entre outras que não lembro no momento. Em todas essas cadeiras nunca ouvi o professor(a) sequer mencionar coisas como: Closure, Currying, Continuation, Design By Contract, Actor model, Lazy evaluation, Tail recursion, Quine, Engine, Liskov substitution principle, … mais algumas coisas que não lembrei no momento …

O básico de orientação a objetos é ensinado, o aluno consegue até responder o que é herança e encapsulamento, mas eu nunca vi sequer mencionarem Orientação a Objetos Prototype-based, aí tenho que me deparar com gente dizendo que Javascript ou Lua fede porque simplesmente não entende como funciona os conceitos e acha estranho a sintaxe das linguagens.

Eu mesmo passei a faculdade inteira sem discutir design patterns, com exceção de DAO, que eventualmente pula na frente dos alunos em alguma cadeira obscura de "desenvolvimento web" (sic). Hoje um amigo estava impressionado com as recomendações que o pessoal da SUN passou sobre o GoF na caravana de ontem, e eu falei para ele que isso é naftalina, sério, se em 2007, o GoF é novidade para você, algo de muito sério aconteceu com sua formação.

Tive um professor muito bom, Hélio Moura, que usava na época a primeira edição do livro "Applying UML and Patterns"(que é de 1997 e faz portanto 10 anos) do Craig Larman, referência na época para RUP, e passou alguns princípios legais como GRASP, Law of Demeter, Open/closed principle, entre mais algumas coisas legais que não lembro agora. Mas isso foi uma exceção, e esse professor não ministra mais aulas na faculdade onde estudo. Isso era coisa de 99 ou 2000, início do milênio, vi que os professores de lá ainda usam a mesma versão do livro do Craig. Detalhe, já estamos na terceira edição e com mudanças significativas.

Agora PoEAA do Martin Fowler que é bom, voce vai passar batido, nem tenha esperança de discutir isso em sala de aula.

Domain Model? isso é anos-luz da academia brasiliana, vá estudar que é melhor. Domain Driven Design também é assunto inexistente, procure outra freguesia.

Metodologias ágeis, enquanto a academia está descobrindo XP (timidamente claro), o mercado já discute a fusão entre XP, Scrum, FDD, Crystal, DSDM. Até a Microsoft tem métodos ágeis enquanto a academia consolida UPs como novidade.

A maioria sai da faculdade monoglota, com apenas o conhecimento específico de uma linguagem de programação, enquanto deveriam estudar princípios, estão estudando linguagem. Programação funcional até pode ser vista, talves raramente em uma cadeira de calculo, ou IA (com LISP) se der tempo, alguns confundem sentenças com paradigmas, tinha um professor que falava que por a linguagem ter sentença condicional como um "IF", ela não poderia ser considerada 100% Orientada a objetos, entre outras sandices bizarras. DSL? bah!

Conversando com um amigo dia desses lá na faculdade, entramos no assunto banco de dados, sem querer surgiu no meio da discussão sobre formas normais, para minha surpresa ele disse que não sabia do que eu estava falando, achei estranho porque o professor de banco de dados 1, cadeira responsável por esse conteúdo, é um excelente professor, Fernando Siqueira, e conhecendo ele eu sabia que não passaria ninguém sem ensinar formas normais. Depois esse meu amigo voltou e falou que deu uma "olhada" no livro e "lembrou". Ora, isso me causa apreensão, mesmo eu sabendo que o professor tem a competência sobre uma matéria e tenho certeza que a aplicou, porque um aluno simplesmente esquece o principal conteúdo de uma determinada matéria?

São mistérios, mas mistério mesmo é uma menina que se forma esse ano e não sabe ainda para que serve um banco de dados, mesmo evidentemente ter cursado todas as cadeiras de banco de dados. Isso sim merece estudo, tese, trabalhos científicos e tudo que nós pudessemos descobrir.

Livros

A minha escola real são os livros, tive e tenho alguns bons professores, uns poucos excelentes, mas os autores clássicos são os mestres dos meus mestres. Não procure livro específico, procure autor, e toda a cultura por volta desse autor.

Posso indicar alguns que são a base da carreira de qualquer desenvolvedor que se preze: Alan S. Koch, Alistair Cockburn, Bertrand Meyer, Craig Larman, Eric Evans, Joshua Kerievsky, Kent Beck, Martin Fowler, Rod Johnson, Ron Jeffries, Steve McConnell, Robert C. Martin, … isso só dando uma olhadela aqui na minha "biblioteca". Sei que esqueci nomes importantes, mas se você seguir essa lista, vai acabar caindo neles.

O pior disso tudo é que o pessoal fica empolgado com título aqui, o cara virou doutor já se acha semi-deus, são praticamente inacessíveis, é muito mais facil você falar com Martin Fowler do que falar com um Doutor brasileiro.

Então voce tem duas alternativas, estudar ou frequentar a faculdade, dá para conciliar as duas, mas a preferência será sempre para o estudo, ele que pagará o leite de cada dia, aliás… leite não que esse está matando ultimamente, e ei que pensei que era a cerveja

Posted in Design Patterns, Engenharia de Software, Metodologia, Orientação a Objetos ~ 16 Comments

Mais história em slides -XP

{ October 31st, 2007 }

Autor: cmilfont

Essa palestra apesar de ter o foco em eXtreme Programming, foi um momento especial, se observarem, havia slides sobre domain model e outras coisas não relacionadas diretamente com métodos ágeis, porque o material foi preparado para combater o famoso anti-pattern BOLOVO (termo criado pelo Shoes) que misturado ao RUP e dosado com muita incompetência, estava no auge nessa época e representava toda a cultura de atraso que passávamos.

Nessa época passavamos pelo treinamento da Evolução com uma figura que ministrava tudo que havia de mais insano nesse campo, BOLOVO na vêia, e com essa palestra consegui abrir muitos olhos. Essa talves foi a palestra mais importante da minha vida em termos de eficiência na mensagem passada e nos objetivos alcançados.

Posted in Design Patterns, Engenharia de Software, Melhores práticas, Metodologia, Métodos Ágeis, Scrum, Test Driven, XP, palestras ~ 1 Comment

Bridge para encapsular o Cross Browser

{ October 5th, 2007 }

Autor: cmilfont

No rastro do meu último post, aproveitando a deixa de detecção otimizada trabalhando junto com o Design Pattern Bridge, aproveitaremos esse conceito para encapsularmos a complexidade de se trabalhar com códigos que tenham que rodar em múltiplos Browsers.

O padrão Bridge define o desacoplamento da abstração (interface) com suas implementações e cada implementação possa variar independentemente.

No código passado vimos isso implementado na função addEvent como segue:

var addEvent = function(el, type, fn) {
    el['on'+type] = fn;
};
if(document.addEventListener) {
    addEvent = function(el, type, fn) {
        el.addEventListener(type, fn, false);
    };
} else if(document.attachEvent) {
    addEvent = function(el, type, fn) {
        el.attachEvent('on'+type, fn);
    };
}

Nesse código o método addEvent é uma forma genérica de adicionar eventos a um elemento DOM na página e encapsula o comportamento implementado pelos Browsers. Essa estratégia pode e deve ser adotada em todo o código que necessite de implementação diferente dependendo do navegador, o chamado Cross Browser.

Cross Browser é a técnica de implementar uma construção que rode em múltiplos navegadores sem diferença perceptível ao usuário. O custo de aplicar essa técnica é diminuir a performance da aplicação como um todo, aumentar a complexidade do código mantido, propiciar um ambiente mais sujeito a falhas de implementação e cair em bugs do próprio navegador (como o Memory-Leak no IE).

Instanciar o objeto XMLHttpRequest é outra situação que possui diferença entre o líder de mercado e os demais navegadores. Aplicando essa técnica, faríamos o seguinte código:

var getXHR = function() {
	this.http = new XMLHttpRequest;
	return this.http;
}
var isIE = !!document.attachEvent;
if(isIE) {
      var msxml = [
        'MSXML2.XMLHTTP.3.0',
        'MSXML2.XMLHTTP',
        'Microsoft.XMLHTTP'
      ];
      for (var i=0, len = msxml.length; i < len; ++i) {
        try {
          http = new ActiveXObject(msxml[i]);
          //cria nova implementação
          getXHR = function() {
            return new ActiveXObject(msxml[i]);
          };
          break;
        }
        catch(e) {}
      }
};

Dei a dica no artigo passado de criar um arquivo para cada implementação de navegador diferente e aplicar o conceito de Lazy Loading para carregar sob demanda.

Posted in Ajax, Design Patterns, JavaScript, Melhores práticas ~ 7 Comments