Uma curiosidade que um amigo me falou hoje que nunca havia me dado conta… Os apelidos das versões do Debian são baseados nos personagens do desenho Toy Story:

Buzz, Rex, Bo, Hamm, Slink, Potato, Woddy, Sarge, Etch e Lenny.

Segue um breve resumo sobre as versões:

A Debian 1.0 nunca foi lançada: Acidentalmente, Infomagic, uma empresa vendedora de CD, lançou a versão em desenvolvimento do Debian e a chamou de 1.0. Em 11 de Dezembro de 1995, Debian e Infomagic juntamente anunciaram que este lançamento foi indevido. Bruce Perens explicou que os dados colocados no conjunto de 5 CDs, “Fonte para Desenvolvedores Linux”, de novembro de 1995, com “Debian 1.0″ não era a versão 1.0 do Debian, mas uma versão em desenvolvimento que estava parcialmente no formato ELF, que provavelmente não iniciaria ou seria executada corretamente, e não apresentaria a qualidade de uma versão Debian. Para evitar confusões entre o CD prematuro e a atual versão do Debian, o projeto Debian renomeou sua próxima versão para “Debian 1.1″. A Debian 1.0 prematura, incluída no CD, é desaprovada e não deveria ser usada.

Debian 1.1 Buzz (Junho de 1996): Esta foi a primeira versão Debian com um codinome. Este foi retirado, como todos os outros, de uma personagem do filme Toy Story… nesse caso, Buzz Lightyear. Neste momento, Bruce Perens tomava a liderança do Projeto de Ian Murdock e Bruce trabalhava na Pixar, a companhia que produziu o filme. Esta versão era toda em ELF, usada pelo kernel Linux 2.0 e continha 474 pacotes.

Debian 1.2 Rex (12 de Dezembro de 1996): Apelidada com o nome do dinossauro de plástico do filme. Esta versão consistia em 848 pacotes mantidos por 120 desenvolvedores.

Debian 1.3 Bo (5 de Julho de 1997): Apelidada de Bo Peep, a pastora. Esta versão consistia em 974 pacotes mantidas por 200 desenvolvedores.

Debian 2.0 Hamm (24 de Julho de 1998): Nomeada com o nome do porquinho do filme. Esta foi a primeira versão do Debian para múltiplas arquiteturas, adicionando o suporte para as arquiteturas da série Motorola 68000. Com Ian Jackson como líder do Projeto, esta versão fez a transição para a libc6 e consistia em torno de 1500 pacotes mantidos por 400 desenvolvedores.

Debian 2.1 Slink (09 de Março de 1999): Nomeada com o nome do cachorro-mola do filme. Mais duas arquiteturas foram adicionadas, Alpha e SPARC. Com Wichert Akkerman como líder do projeto, esta versão consistia em cerca de 2250 pacotes e requeria 2 CDs no conjunto oficial. A inovação técnica foi a inclusão do apt, uma nova interface de gerenciamento de pacotes. Mundialmente copiado, apt é o grande responsável pelo crescimento contínuo do Debian e estabeleceu um novo paradigma para a aquisição e instalação de pacotes em sistemas operacionais de fonte aberta.

Debian 2.2 Potato (15 de Agosto de 2000): Apelidada com o nome do personagem “Sr Cabeça de Batata” do filme. Esta versão adicionou o suporte para as arquiteturas PowerPC e ARM. Com Wichert ainda atuando como líder do projeto, esta versão consistia em mais de 3900 pacotes derivados de 2600 pacotes fontes mantidos por mais de 450 desenvolvedores Debian.

Debian 3.0 woody (19 de Julho de 2002): Nomeada com o nome da personagem principal do filme: “woody”, o cowboy. Mais arquiteturas foram adicionadas a esta versão: Ia-64, HP PA-RISC, MIPS (big endian), MIPS (little endian) e S/390. Esta também foi a primeira versão a incluir software com criptografia devido as restrições de exportação que foram iniciadas nos EUA e a primeira a incluir o KDE, agora que os problemas com a licença da QT foram resolvidas. Com Bdale Garbee recentemente eleito Líder do Projeto e mais de 900 desenvolvedores Debian, esta versão continha 8900 pacotes e 7 CDs binários no conjunto oficial.

Debian 3.1 Sarge (06 de junho de 2005).

Debian 4.0 Etch (15 de Agosto de 2007) .

O codinome para a próxima grande versão do Debian após o etch é o lenny. Ainda sem previsão de lançamento.

Fonte: http://debian.org

Um website teve a algum tempo a iniciativa de economizar enegia substituindo a página de pesquisas do google por uma página preta.

A idéia é economizar MegaWatts/h ao exibir uma página negra, que gera menos luz e consome menos energia que uma página branca.

“Em Janeiro de 2007 um artigo num blogue com o titulo Um Google Negro Salvaria 750 MegaWatts/hora Por Ano, propunha a teoria de que uma versão negra do motor de busca Google iria salvar muita energia devido á popularidade do motor de busca.”

A proposta do Blackle.com é utilizar-lo como alternativa ao google para efetuar pesquisas web enquanto se economiza energia. Ele também mostra ums estatística de quantos Watts/h já foram economizados pela página desde sua criação.

Um outro website com a mesma iniciativa é o http://www.pretog.com:

Para exibir uma tela inteira branca, seu computador usa cerca de 74 watts, enquanto para mostrar uma preta o consumo é de 59 watts.
O excesso de luminosidade produzida por um fundo totalmente branco é muito mais prejudicial aos olhos que um fundo totalmente preto.

Ambos se basearam no post deste blog: Um Google Negro Salvaria 750 MegaWatts/hora Por Ano (em inglês).

Na última sexta-feira meu professor de DSI (Desenvolvimento em Sistemas de Informação) apresentou uma nova abordagem em desenvolvimento de software com a aula mais dinâmica que já tive. Trata-se da Extreme Programming (XP) .

Esta é uma nova metodologia de desenvolvimento de software (com cerca de 8 anos), voltada a interatividade com o cliente, ao trabalho em grupo e a dinâmica. Recomendada para desenvolvimento de softwares com requisitos vagos e que necessitem de constantes mudanças.

É baseada nas seguintes regras e práticas:

• Planejamento
  • Problemas do usuário
    • São escritos pelos clientes especificando o que o sistema deve fazer por eles;
    • Estes Problemas assemelham-se ao uso de cenários, mas não limitados a descrever uma interface e são expressados em cerca de três sentenças escritas pelo cliente;
  • Plano de Lançamento
    • Após os Problemas serem escritos, encontros são realizados para para criar o Plano de Lançamento;
    • Este Plano de Lançamento especifica que cartões serão implementados para cada lançamento e as datas destes lançamentos;
  • Lançamentos Periódicos
    • O Time de desenvolvimento deve liberar pequenas versões interativas aos clientes periodicamente;
    • No próximo encontro os clientes expõe suas opiniões e satisfações sobre o projeto (Teste de Aceitação), o que permite ao time melhorar este de acordo com as necessidades do cliente;
  • Velocidade do Projeto
    • A Velocidade do Projeto é medida conforme quanto trabalho é realizado no projeto;
    • Para medí-la, simplesmente adicione as estimativas de cada Problema resolvido durante a iteração;
  • O projeto é dividido em Iterações
    • Desenvolvimento iterativo adiciona agilidade ao processo de desenvolvimento;
    • Divida o projeto em cerca de uma dúzia de iterações com uma a três semanas de duração;
    • Mantenha essa duração constante durante o projeto, é esta constante que torna a medida de progresso e o planejamento simples e confiável na XP;
  • Plano de Iteração
    • Uma reunião é feita no início de cada Iteração para criar o plano daquela Iteração, os trabalhos de programação a serem realizados;
    • Problemas são escolhidos pelo cliente para esta Iteração, a partir do Plano de Lançamento, na ordem do mais importante para cliente primeiro;
    • O total de problemas é estimado de acordo com a velocidade do Projeto da última Iteração;
    • Testes de Aceitação falhos e que precisem de reparos também são selecionados;
    • Estes Problemas do Cliente e Testes de Aceitação são divididos em tarefas e anotados em Cartões;
    • Enquanto os Problemas são descritos na linguagem do Cliente, os Cartões são escritos na Linguagem doProgramador;
    • Programadores responsabilizam-se por estes Cartões e estimam quanto tempo suas tarefas levarão para serem completadas (geralmente 1 a 3 dias);
  • Mude os Papéis
    • Os papéis de cada membro do time de programação devem ser trocados constantemente para evitar desperdício de conhecimento e “codificação viciada” destes;
    • Se apenas um membro é capaz de trabalhar em certa área, será um problema se esta pessoa sair do projeto ou você pode acabar com acumulo de tarefas para este;
  • Reuniões em pé
    • Uma reunião em pé é realizada diariamente;
    • Comunicação entre o time de projeto é a intenção desta reunião;
    • O conhecimento de cada um é dispersado e compartilhado, assim como uma visão geral do andamento do projeto;
    • Reuniões em pé tentem a ser rápidas e dinâmicas, e impede que o time distraia-se com futilidades;
  • “Conserte a XP quando ela quebrar”
    • Nào dizemos ’se’ porque obviamente serão necessárias modificações e adaptações para cada projeto;
    • Não exite em descartar as opções que não funcionarem e adicionar novas.

Estas são as práticas da fase de planejamento, não pretendo me extender aqui a ponto de descrever todas as fases, mas vou ressaltar alguns outros pontos importantes:

• Simplicidade
  • Um projeto simples leva menos tempo para ser desenvolvido que um complexo;
  • Sempre faça o mais simples possível que funcione;
• O Cliente está sempre disponível
  • Um dos principais requerimentos das Programação XP é comunicação constante com o cliente, preferencialmente face a face;
  • Não apenas para ajudar a equipe de projeto, mas sim como parte da própria equipe;
• Programação em duplas
  • Toda a programação a ser incluída no projeto deve ser realizada por duas pessoas trabalhando juntas no mesmo computador;
  • Programação em duplas aumenta a qualidade do software sem impacto no prazo de entrega.

É notavel na programação XP que suas práticas são voltadas muito mais para a programação do que para a documentação e planejamento do projeto. Isto pode causar um grande impacto sobre os tabus de que a documentação é até mais importantes que a programação em si. Obviamente a documentação não deve ser descartada, mas também pode ser realizada dinamicamente durante os encontros/reuniões, desde anotações simples até gravação das sessões.

O suporte também não fica prejudicado pela falta de documentação apropriada. Uma vez que o conhecimento sobre o projeto é difundido sobre a equipe, fica relativamente fácil realizar modificações e aprimoramentos.

A imagem a baixo é um diagrama interativo da metodologia de programação XP. Hospedado em http://www.extremeprogramming.org/, que também foi minha maior fonte para este artigo. Leitura recomendada…

Fontes: http://www.extremeprogramming.org, http://en.wikipedia.org/wiki/Extreme_programming, http://pt.wikipedia.org/wiki/Extreme_programming

Meu professor de DSI (Desenvolvimento em Sistemas de Informação) nos apresentou um artigo (na verdade ele contou a historinha) sobre mudanças e novidades na Engenharia de Software, o qual eu apresento abaixo:

O Porco Assado

Certo dia um caçador voltava da floresta com um porco vistoso e gordo o qual seu povo costumava comer cru. Ao perceber que a floresta estava pegando fogo, largou o animal e fugiu. Após o fogo passar, voltou e percebeu que o porco havia queimado. Como estava com muita fome, resolveu comer o porco queimado mesmo, e surpreendeu-se com o sabor agradável, muito melhor que porco cru.

Logo difundiu a idéia para seu povo. Assim, cada vez que queriam comer um porco, largavam-no em uma floresta e colocam fogo na mesma. Após passar o fogo, iam saborear a carne de porco. Com o passar do tempo, surgiram inúmeras empresas de consultoria de como atear fogo em florestas, como fazer o porco ficar próximo a regiões que queimavam mais (porco bem passado) ou menos (porco mal passado), e até certificações em queimar porco em florestas.

Certo dia um estagiário de uma das empresas sugeriu que o porco fosse posto sob uma fogueira, pois queimaria de forma proporcional, e quem fizesse poderia controlar o fogo melhor. Foi demitido, pois ousou desafiar uma metodologia que estava dando certo, pois porco assado no floresta era um sucesso!

Mas o que essa estória tem a ver com engenharia de software?

Ora, assim como o estagiário propôs uma nova metodologia para assar o porco (diga-se de passagem muito melhor), porque não podemos propor uma nova forma de desenvolver software?

O texto acima foi extraído do blog zetoniazzo.wordpress.com, quem quiser ler o conteúdo original, assim como as opiniões do colega e baixar o podcast que continha a palestra com a história acima, pode acessar o link aqui.

A história retrata um problema que vemos em muitas empresas, que temem mudanças bruscas em sua metodologia, justificando com o bem-andamento da metodologia atual, o que acaba estagnando a empresa e impedindo-a de evoluir (o que é essencial no mercado de Sistemas de Informação).

Para uma empresa de tecnologia, por mais que seja custoso fazer grandes mudanças, cada caso deve ser estudado para trazer as melhores vantagens para esta. Mesmo que adotar uma nova tecnologia ou metodologia de trabalho consuma recursos demasiados, isto pode trazer grandes benefícios num futuro próximo, retornando a empresa todos os recursos gastos.