IT talks

"Recent case studies (the Internet) provide very dramatic evidence ... that commercial quality can be achieved / exceeded by OSS projects."

"OSS is long-term credible"

"Linux and other OSS advocates are making a progressively more credible argument that OSS software is at least as robust -- if not more -- than commercial alternatives. The Internet provides an ideal, high-visibility showcase for the OSS world"

"Linux has been deployed in mission critical, commercial environments with an excellent pool of public testimonials. ... Linux outperforms many other UNIXes ... Linux is on track to eventually own the x86 UNIX market ..."

"The ability of the OSS process to collect and harness the collective IQ of thousands of individuals across the Internet is simply amazing"

Quem será que tem tanta admiração assim por OSS e Linux?

Resposta em breve.

"Internet Explorer, like Outlook, has finally become [...] a permanent security hole"

"Millions of you may have every bit of your browser-driven online financial security information stolen."

Estes são trechos do artigo Internet Explorer Is Too Dangerous to Keep Using, de Steven J. Vaughan-Nichols, publicado após a descoberta do recente "buraco" (ou cratera!) de segurança no Internet Explorer.

A recomendação do autor? É a mesma deste humilde escriba: livre-se do IE e corra para o Mozilla.

Vamos imaginar: você encomendou a construção de uma casa para morar. Decidir pelo número de quartos e banheiros não foi muito difícil, mas agora você quer ter certeza que a casa vai ter a ver com você, coisas devem fluir de um ambiente para o outro, deve haver um certo tipo de harmonia entre os elementos...

Então você chama o arquiteto e diz para ele: "Eu quero uma casa que tenha a ver comigo". E fica olhando para ele.

O arquiteto, por sua vez, tranquilamente leva você até uma folha de papel e começa a conversar enquanto lhe mostra alguns rabiscos. Ele continua conversando com você e também lhe mostra fotografias de algumas casas. Ao longo da conversa - que vai durar muitos dias - várias maquetes, desenhos, montagens são criadas. Muitas delas vão simplesmente para o lixo. Mas ao final do processo você e o arquiteto descobrem juntos uma casa que serve para você.

Agora, roda a fita para trás: o cliente não está pedindo uma casa - ele quer é um novo relatório e você é o Analista de Systemas. O cliente lhe diz: "Eu quero um relatório que me mostre o total de vendas por produto." Como um tradicional Analista de Sistemas, você pensa imediatamente: "lá vem este camarada com especificações genéricas e vagas que não me servem de nada para montar relatório algum". Você respira fundo, olha com piedade para o cliente e diz: "OK. Mas quais são exatamente os requisitos?". Seu cliente olha sem entender para você, e ao longo de um processo vagaroso e complexo onde você o tortura com perguntas sobre tabelas, ordem de classificação, diagramação visual, critérios de seleção, periodicidade de emissão, método de distribuição e outras muitas questões que ele não tem a menor idéia de como responder ele acaba assinando embaixo de um documento que ele não entende.

Você sai contente com a sua Especificação de Requisitos de Software debaixo do braço e diz para o cliente antes de desaparecer pela porta: "Esta versão vai ser baselined em nosso Software Configuration Management System. Se você desejar alterar a especificação você terá de acionar o Processo de Mudança de Software corporativo e submeter uma requisição para mudança de requisito ao Board de controle de mudança. Um abraço."

Qual a diferença básica entre a abordagem daquele Arquiteto e deste Analista de Sistemas? O Arquiteto entende e assume como natural que o cliente não sabe em detalhes o que quer no momento em que está solicitando seus serviços. Também, o Arquiteto reconhece que mesmo quando o cliente sabe o que quer ele terá dificuldades de expressar estes desejo em um conjunto de especificações escritas que tenham real validade como input para o trabalho de arquitetura. Então ele guia o cliente através de modelos, protótipos, maquetes, fotografias , desenhos, etc. O trabalho de prototipação começa assim que o Arquiteto tem uma idéia mínima do desejo do cliente. A medida que possibilidades vão sendo avaliadas - e muitas delas descartadas - os novos desenhos têm mais detalhes mas é assumido como natural que leverá tempo até a proposta final ser aceita pelo cliente.

Em especial, há o entendimento de que os requistos não estão nativamente dormindo dentro do cliente esperando que alguém apareça com uma varinha mágica e os faça despertar. Assume-se, na verdade, que este conjunto detalhado e complexo de requisitos simplesmente não existe no início do trabalho: isto vai ser construído em um trabalho conjunto desenvolvido pelo cliente e pelo Arquiteto.

É por isto que, portando o exemplo para TI, alguns analistas afirmam que requisitos de software - como são tradicionalmente referidos pela Engenharia de Software - não existem. Não que a Engenharia de Software não tenha validade, mas que ela é produtiva em certos aspectos e em certa medida.

A noção de inexistência prévia dos requisitos de software é bem expressa pelas palavras usadas por Karl Wieger para descrever esta atividade: "requirements development". Outros falarão em "requirements nurturing".

Independente da expressão a noção é a mesma. É fútil, improdutivo e frustrante insistir no velho modelo de análise de sistema. Se você ainda está lecionando por esta cartilha corra já para a livraria mais próxima e compre qualquer livro que achar sobre qualquer Agile method.

Depois que você descobrir os benefícios trazidos por métodos interativos de desenvolvimento de software você vai ver que esta é uma viagem sem volta.

Felizmente, é uma viagem que leva a impressionantes ganhos em termos de comunicação com o cliente, qualidade no produto final e redução de custos.

(este artigo foi livremente inspirado no artigo "Nurturing Requirements" (pdf), publicado no site da Pragmatic Programmers)

O internauta tem duas opções básicas:

1. ficar baixando patches, montar um altarzinho em casa para seu santo preferido, ficar rezando para que os patches cheguem antes dos vírus e depois comprar várias caixas de lenço de papel para a hora da choradeira

2. aposentar de vez o defasado IE e instalar um browser alternativo, menos popular, mais moderno e mais user-friendly. Estou falando, é claro do Mozilla, que é um produto redondinho, gratuito, open source e superior ao IE. Como todo software, tem bugs, mas como tem uma base instalada muito menor, poucas vezes é alvo de hackers.

Mozilla é um produto vivo, em contínuo aperfeiçoamento, com uma ríquissima comunidade de desenvolvedores oferecendo suporte. Por seu lado, o IE, como o amigo leitor já sabe, há tempos foi congelado em sua versão atual. Não haverão atualizações até que a Microsoft bote na rua o hiper-alardeado Longhorn. Pode demorar...

Estas coisas não acontecem por acaso. Alguns analistas entendem que o ritmo de inovação do IE diminuiu na mesma medida em que crescia o entendimento da MS de que o mercado de browsers já estava cativo. Por isto, se diz que ao invés do proclamado "direito de inovar" alardeado pela MS parece mais que ela esta lutando pelo "direito de estagnar"...

Ah, tem sempre aquela "coisinha especial" que o IE faz e que a gente nao pode viver sem ela... Pessoalmente, prefiro me livrar desta coisinha e diminuir drasticamente a chance de ter meu HD destruído ou meu cartão de crédito roubado. Mas, concordo e aceito: tem gosto para tudo.

Nathan Lee propõe em seu blog o "A to Z" do desenvolvedor J2EE.

Nas palavras do autor:

"Expect this to be out of date within 0.2 seconds of posting, and to have missed huge numbers of cool technology, and expect some of the comments on things to disagree with lots of people.. but hey.. that's life :o)"

Para DBAs oracle, tem uma série de Pocket Guides em www.solutionbeacon.com/tools_guides.htm. O formato é bem conveniente.

Então você vai querer saber o quanto você está valendo na terra do Tio Sam.

A Infoworld publicou sua pesquisa salarial de 2004, que pode ser lida aqui (pdf).

Além dos dados brutos vem uma interpretação suscinta dos mesmos. Alguns pontos a destacar neste artigo:

- gasto com TI deve estabilizar (parar de cair) ou mesmo aumentar no próximo ano
- diminuiu o número de empresas que planejam demissões ou "congelamento" de admissões
- o salário médio parou de diminuir
- aumentou a distância entre os salários do top management e "o pessoal de baixo"
- o fantasma do offshore outsourcing parece ter pouca influência real sobre o nível de compensação

Dados coletados sugerem também que depois de anos de contínua pressão por maior produtividade o profissional de TI já está no seu limite. Conjugada com o sentimento de que recém agora a economia americana está dando sinais de que vai realmente começar a reagir, há uma esperança de que as empresas vão finalmente tirar da gaveta os planos de renovação da infraestrutura e projetos de tecnologia.

Em relação aos dados brutos, uma nota pessoal sobre o mesmo: o significado real do salário médio de um IT / IS / Tech Manager (US$ 72 mil) depende de onde a pessoa vive. O custo de vida varia dramaticamente nos diversos estados norte-americanos.

Em especial, certa feita assisti uma preleção de uma pessoa que viveu durante muito tempo no Vale do Silício e o cidadão demonstrava com números e planilhas que 70 mil dólares naquela região mal dá para pagar as contas.

Estou brincando, é claro. Mas o fato é que enquanto Web Services e Service Oriented Architectures (SOA) recem começaram a brigar por um lugar ao sol já tem tecnologista propondo que "the next big thing" é uma nova combinação de letrinhas: EDA, ou Event-Driven Architectures.

Para os ansiosos por novidade, a Basiline tem um primer sobre o assunto.

Um artigo de um dos diretores da Neon Systems - que está desenvolvendo produtos para a área - pode ser encontrado aqui, onde o leitor será introduzido também à Event-Driven Enterprise (olha o buzzword aí, gente...)

Artigo da Application Development Trends apresenta mais um caso de um projeto de TI que parece fadado ao fracasso. Neste caso, o projeto de renovação tecnológica do famoso, secreto e todo poderoso órgão de segurança norte-americano - FBI.

Os culpados - surpresa! - parecem ser os mesmos de sempre:

- mudança da visão do projeto depois que ele ja estava em andamento
- pressão política para ver os produtos implementados "o quanto antes"
- encolhimento do prazo sem enxugamento/revisão dos requisitos
- falta de efetivo suporte executivo

Quem tem um background em projeto de banco de dados vai achar até engraçado ler que um clássico erro parece ter acontecido aqui: ao projeto que tinha foco operacional antes do 11/9 adicionou-se também a ênfase para a geração de serviços de análise de dados.

Um bombom para quem enxerga aqui monstruosas bases de dados sendo usadas para datawarehouse e aplicações transacionais ao mesmo tempo...

Este relatório (pdf), produzido pelo Computer Science and Telecommunications Board (CSTB) explica com detalhes os problemas enfrentados até então pelo projeto.

Ferramentas e frameworks para persistência de objetos são atualmente alguns dos tópicos mais importantes para quem tem um background e interesse na área de projeto de banco de dados e aplicações transacionais.

Este artigo, publicado no The Server Side, compara brevemente dois dos mais conhecidos projetos open-source nesta área: Hibernate e Cayenne.

EJB, JDO, Hibernate, Cayenne, ORB, Toplink, ...

Hoje em dia não faltam opções para arquitetos Java desenharem suas camadas de persistência. Na verdade, talvez existam opções demais e ao invés de fragmentar esforços em diferentes e concorrentes projetos a comunidade Java poderia abordar o assunto com outra estratégia.

Quem sabe, embutir um modelo de persistência na próxima versão do J2EE?

Esta é a proposta dos autores do artigo 'Persisting Problems', reproduzido hoje pelo The Server Side (TSS).

Leia o artigo e acompanhe a subsequente discussão aqui.

Estudo afirma que 80% do spam origina-se em PCs zumbis, previamente infectados por Trojans. Ou seja: o meu e o seu PC.

Portanto, não seja negligente: se está cada vez mais difícil ter certeza que o micro não está contaminado pelo menos não custa nada instalar um firewall para ao menos "anestesiar o zumbi".

Pegue um software firewall de graça em
http://www.zonelabs.com/

Para quem acredita em pesquisa de mercado, a internet.com publicou recentemente um estudo do mercado de banco de dados da IDC.

Alguns dados do mesmo:

- o mercado gerou $ 13.6 bilhões em 2003
- por volta de 75% do mercado é dominado por Oracle, Microsoft e IBM
- Oracle tem uma fatia de 39.8%, IBM 31.2% e Microsoft 12.1%
- um aquecimento do mercado é esperado para 2006, devendo atingir $20 bilhões em 2008
- com 0.1% do mercado, open source databases ainda não fazem nem cosquinhas nos líderes

Leia a reportagem original na íntegra: Oracle Still King of Database Market

Nesta entrevista para The Server Side (TSS) O autor de Agile Database Techniques expõe alguns de seus pontos de vista sobre Agile Modeling e Agile Development Process.

Li esta obra e o autor parece ter real experiência na complexa tarefa de construir a ponte entre aplicações basedas em tecnologia de objetos e bancos de dados relacionais. Os fundamentos e as boas práticas estão todas lá.

Nesta obra não ficou muito claro para mim o quão realísticas são as propostas de metodologia. Mas o assunto é quente e vale a pena conferir.

http://www.theserverside.com/talks/index.tss

Há outros papos técnicos no mesmo link.

Uma atualização de software "de rotina" realizada na segunda-feira, 31 de Maio, no Royal Bank - que é o maior banco do Canadá - acabou resultando no que provavelmente é o maior desastre gerado por software em uma intituição financeira daqui.

O problema ainda não foi explicado em detalhes mas aparentemente devido a este bug uma série monstruosa de transações bancárias nunca se efetivou nos bancos de dados da companhia. Em consequência, ontem, 4 de junho, 5 dias depois, 10 milhões de clientes ainda não sabiam o saldo de suas contas.

Como era final de mês, o salário ficou (e ainda estava ontem) indisponível para centenas de milhares de pessoas. Contas de toda a sorte não foram pagas e proavelmente milhões em multas e taxas vão ser gerados.

Este problema está em todos os jornais do Canadá, incluindo o Globe and Mail.

Claro que é cedo para julgar o que realmente aconteceu. Mas apenas como um exercício intelectual de revisão das boas práticas de desenvolvimento e gerenciamento, eu fico a me perguntar onde foi a falha:

(a) A existência de risco associado a este procedimento foi identificada?

(b) Se a resposta é sim, a abrangência do potencial problema associado a este risco foi identificada?

(c) Se as respostas são sim e sim, alguma iniciativa específica foi desenvolvida para tentar eliminar o risco?

(d) Ou, alguma iniciativa foi desenvolvida para reduzir o impacto do potencial problema?

(e) Ou, existia algum procedimento de contingência para problemas como este?

Passada a tempestade, o que tende a acontecer é o Banco sair atrás do programador que gerou a rotina com bug (se é que ele já não perdeu o emprego). Mas isto em pouco ajudará a empresa. Quando problemas desta magnitude acontecem são normalmente frutos de processos precários postos em prática para construir software de qualidade. Ou mesmo inexistência de tais processos.

Então você assumiu a gerência de projetos de software de sua empresa e no primeiro pronunciamento ao time você fez questão de enfatizar como qualidade é importante em sua equipe. Boniiiiito! Mas... o que isto quer dizer mesmo?

O artigo abaixo é uma livre tradução de uma das edições da Clarrus Compendium, e foca exatamente sobre esta pergunta.

É comum anunciar que qualidade é importante para o seu projeto de software. Afinal, estão aí todas as matérias negativas no jornal sobre a indústria de software e, francamente, quem não costuma ter um pouco de gosto em falar mal daquele terrível software que se estava usando ontem mesmo? Mas o que realmente significa focar em qualidade como uma prioridade?



Primeiro – e mais importante – para verdadeiramente ter qualidade como foco de seu projeto você precisa ser detalhado sobre o que isto significa. Se você não tem uma clara descrição de qualidade que possa ser independentemente verificada ao final do projeto então esta ênfase em qualidade é pouco mais que vapor.

Usualmente, qualidade significa diferentes coisas para diferentes pessoas em diferentes tempos. Enquanto eu digito em meu laptop o que é importante para mim são coisas como confiabilidade e usabilidade. Em outras situações, eu posso estar mais interessado em interoperabilidade. E quando submerso em código o foco se volta para o objetivo de se produzir algo que possa ser testado, modificado ou reusado.

Tome cuidado com o que você pede em termos de qualidade – como muitas coisas na vida, seu produto não pode ser “todas as coisas” para “todas as pessoas”. Existem negociações entre as diversas facetas da qualidade e satisfazer alguns aspectos de qualidade só é possível a um alto preço. Configurar um sistema para máxima eficiência pode significar que a facilidade de manutenção do código será sacrificada, por exemplo.

Se você está interessado na alta disponibilidade que é construída em sistemas de missão crítica você automaticamente estará reduzindo suas opções de sistemas operacionais, aumentando o custo da plataforma de hardware e a complexidade da arquitetura. O simples requisito de que um sistema não pode estar indisponível mais de 5 minutos ao ano pode mais que duplicar o custo global do sistema!

Se você quer integridade de dados então sua melhor opção é planejar as checagens e análises que ajudam assegurar que integridade de dados vai ser mantida (e que problemas nesta área vão ser interceptados tão cedo quanto possível). Você precisa pro-ativamente levar esta qualidade para todos os níveis de contrução e teste, sempre guiado por um design e arquitetura que vão fornecer a requerida infraestrutura. Este esforço toma tempo e recursos e requer planejamento. Por outro lado, tentativas de embutir esta qualidade em sistemas existentes pode ser ainda mais custosa.

Pode haver um custo extremo associado com a construção de qualidade em um sistema. Mas este custo pode ser quase nada se comparado com os custos que você pode acabar gerando se você negligencia qualidade. Você não pode exigir qualidade e ao mesmo tempo impor restrições de prazo ou custo que impedem que as pessoas façam o seu trabalho. Permanecer no mundo do gerar-código-e-consertar pode dramaticamente aumentar os prazos para muito além do antecipado. Atrasos e insatisfacão dos clientes acabam por se revelar ainda mais custosas uma vez que elas são geralmente inesperados. Do ponto de vista da qualidade, você literalmente recebe o que você pagou.

Por outro lado, trabalhar com claros objetivos de qualidade pode ser um incrível fator de economia de custos. A maioria dos projetos que põem ênfase em prazo em detrimento de qualidade acabam terminando com atraso e entregando software de discutível qualidade. Ao balizar-se por prazo, acabam falhando nos dois lados. No entanto, quando a ênfase é em qualidade o projeto se torna monitorável e pode ser acompanhado em sua evolução, normalmente resultando em maior capacidade de ser entregue em tempo.

Tenha cuidado com o que você pede em termos de qualidade. Mas não se esqueça de pedir por qualidade e ser claro em relação ao que isto significa.

Leia o artigo original em inglês no site da Clarrus.