Todos os post de mbelo

A Engenharia de Software está uma bagunça?

Essa questão está sendo levantada por nomes de grande importância na área da ciência da computação. Nomes como Ivar Jacobson, Bertrand Meyer e Richard Soley.

Num artigo escrito por Ivar Jacobson e Bertrand Meyer, Methods Need Theory, eles expõem uma vergonhosa realidade que a engenharia de software, ao contrário das outras engenharias, sofre na sua evolução: influência exagerada de marketing. Cada novo método vende-se como a nova revolução do momento. Tudo é um novo paradigma, como se nada que existisse antes valesse a pena ser estudado. Afinal, como se venderiam tantos livros? Alguma das outras engenharias são tão voláteis quanto a de software? O perigo citado no artigo é a banalização da nossa ciência. Para muitas pessoas, segundo os autores, torna-se mais importante usar a última moda em método de engenharia de software do que propriamente desenvolver software de boa qualidade.

Eles defendem que usemos na engenharia de software os mesmos princípios adotados pelas outras engenharias: um maior formalismo teórico e menos sensacionalismo, unindo o mundo profissional com o acadêmico. Em outro artigo, intitulado “Why we need a Theory for Software Engineering“, Ivar Jacobson e Ian Spence procuram enfatizar essa importância da fundamentação teórica da ciência.

Um professor da PUC (Prof.Rubens Nascimento) uma vez proferiu numa palestra que assisti: “de tudo que surge como “novo” na computação, 95% é puro marketing. 5%, talvez, possa ter alguma inovação.”. Ao longo desses anos trabalhando na área pude constatar o quanto ele estava certo.

Com interesse de organizar a “nossa” engenharia, as importantes figuras da área de computação acima citadas iniciam uma força tarefa, conhecida pela sigla de SEMAT (Software Engineering Method And Theory), com o objetivo de organizar os fundamentos da engenharia de software, sem modismos, sem termos marketeiros, sem firulas. Coloco muito fé nesta iniciativa, tanto que a subscrevi na página organizada pelos proponentes.

Vale a pena acompanhar a iniciativa. Acesse o link aqui.

Methods Need Theory

Sun Tech Days 2009

Nos dias 8 e 9 de dezembro de 2009 participei do Sun Tech Days 2009 como conferencista. Um dos mais ilustres palestrantes foi o James Gosling que, para quem não sabe, é considerado o “Pai” da plataforma Java. Tive o privilégio em tirar uma foto com ele.Eu e o James Gosling

Clique aqui para acessar os links para as apresentações.

Participei integralmente dos dois dias do evento, apesar da complicada chegada ao local no evento no dia 8, quando uma forte chuva complicou ainda mais o já complicado trânsito de São Paulo.

Uma boa fonte para saber mais sobre a Plataforma Java EE 6 é um seminário via WEB da Sun. Acesse aqui.

Desculpas esfarrapadas de Analistas

Acabo de ler um artigo muito interessante na revista Dr.Doobs. Numa tradução grosseira seu título seria “Desculpas esfarrapadas: Os administradores não sabem o que eles querem”. Os administradores, no caso, são os usuários que nos contratam para desenvolvimento de sistemas.

Achei o artigo com um visão muito verdadeira que reflete os problemas típicos de engenharia de software. Em essência, o artigo critica a visão individualista dos analistas de sistemas, que não se preocupam em entender o negócio dos seus clientes.

Leia o artigo aqui.

Depender do Google

Era o início do ano de 2005, estava em fase final de preparação para encarar a defesa da minha dissertação de mestrado. Naquele momento, aguardava ansiosamente um e-mail, que seria enviado pelo meu orientador, o saudoso Prof. Orlando Loques. Passaram-se uma, duas semanas…. e nada do e-mail chegar. Por diversas vezes entrei em contato com meu orientador, oborrecendo-o com a mesma pergunta: quando será a fatídica data? A resposta era sempre a mesma: aguarde meu e-mail. Cansado de insistir, fiquei eternas duas semanas sem entrar em contato. No momento que entrei, recebi a seguinte resposta: “Márcio, mandei a mensagem duas semanas atrás. Sua defesa será amanhã.”. Dei-me conta que meu e-mail gratuito, num provedor local, tinha me deixado na mão… novamente.

Irritado, e seguindo dica de um colega, crei minha conta no Gmail. O serviço era de primeira: alta qualidade e disponibilidade. Desde então venho sendo testemunha dessa verdade. Afinal, para um serviço gratuito, os recursos oferecidos são sensacionais. Deixei de imediato a conta no meu antigo provedor de lado, e passei a usar minha nova e confiável conta.

Terça passada, dia 1/9/2009, enquanto fazia minha diária viagem para a faculdade onde leciono, recebo pelo rádio a notícia que o Gmail estava fora do ar. Ao chegar na faculdade, deparei-me com o serviço já no ar novamente. Foram menos de duas horas de indisponibilidade, pelo que tive notícia, mas o suficiente para trazer a seguinte pergunta à mente:  até onde podemos confiar em um serviço gratuito? Ocorrendo um problema, a quem reclamar? Não tenho nenhum contrato de nível de serviço com a Google. Como todos os usuários do Gmail, cedo um pouco da minha privacidade pela gratuidade, e autorizo que paraceram na minha tela anúncios direcionados.

O fato é:  acredito do modelo de negócio da Google para o Gmail. A indisponibilidade ocorrida na última terça é normal em qualquer operação de TI, embora não desejável, mas em nada abala minha confiança no serviço do Gmail.

Programação x Programação Paralela

Deve-se separar o ensino de programação do ensino de programação paralela?

Foi levantando essa questão que James Reinders escreve seu artigo sobre o ensino de programação paralela. No artigo, Reinders cita o fato de que a maioria dos sistemas atuais, até o chamados entry-level (baixo custo), estão vindo com mais de um núcleo (leia-se CPU). São os chamados multicore. Nesse contexto, deve-se continuar priorizando o ensino de programação separado do ensino de programação paralela, como fazem a maioria das instituições de ensino? Geralmente, programação paralela aparece, quando muito, em disciplinas avançadas dos cursos de graduação. Uma boa reflexão para instituições de ensino que desejam manter-se na vanguarda do ensino tecnológico.

O interessante escrito de James Reinders pode ser acessado neste link.

O desafio de se achar algo no JavaDocs

Quem desenvolve em Java sabe o quanto é difícil encontrar uma classe, dentro da biblioteca de classes nativas, que soluciona aquele problema específicio que desejamos resolver. Não é àtoa. A Java API tem mais de trinta mil e quinhentos métodos, distribuídos por mais de quatro mil classes. Mesmo usando os buscadores da internet, que facilitam encontrar no Javadocs classes que realizam determinado tipo de tarefa, acabamos encontrando dezenas de opções, que nos desafiam com suas sutis diferenças.

Pensando nisso, pesquisadores da Carnegie Mellon desenvolveram duas ferramentas que adicionam, entre outras facilidades, a pesquisa classificada das classes baseada em relevância, mecanismo semelhante ao que o Google utiliza. Por exemplo, ao fazer a pesquisa por uma classe de impressão, o desenvolvedor poderia pesquisar no JavaDocs por ‘Printer’. Usando as classificações por relevância, o motor de pesquisa dará destaque à classe PrintWriter, colocando-a em letras com corpo maior do que a PrintEvent, posto que a primeira é usada e referenciada com maior frequência do que a segunda.

Maiores informações, consultar os sites dos projetos ou o artigo na Dr.Dobb’s que fala das ferramentas:

Finding Java API Methods and Classes

Dicas para a certificação SCJP 6

No dia 23/6/2009 passei na prova de certificação Sun Certified Java Programmer, versão 6, com 91% de acertos (errei 6 de 27 questões). Como dica para aqueles que pretendem passar nessa certificação, recomendo:

1. Ler o livro “SCJP Sun Certified Programmer for Java 6 Study Guide Exam (310-065)”, de Kathy Sierra e Bert Bates. O livro é excelente, e vale também como fonte de consulta para qualquer desenvolvedor Java. Ler do capítulo 1 ao capítulo 10. A cada capítulo, fazer as questões simuladas. Não se assuste se errar muito no começo.

2. Fazer os dois simulados do CD que acompanham o livro. Nele, existem dois grupos de simulados, cada um com 75 questões. Recomendo fazer esses dois primeiros simulados no formato Quiz-OpenBook, mas monitorando o tempo total.

3. Fazer o simulado adicional que pode ser baixado do site da MasterExam, cujo link está no próprio CD. Neste, faça no formato de simulado.

Fazendo mais do que 75% de acertos (em questões não repetidas), pode ir com segurança para prova.

Boa sorte!