Estou postando o comando com o aptitude, primeiramente, e as respostas no terminal. Aumentando a verbose (-v,-vv, [...]) a saída muda:

$ aptitude moo
Não existem Ovos de Páscoa neste programa.
$ aptitude -v moo
Realmente não existem Ovos de Páscoa neste programa.
$ aptitude -vv moo
Eu já não lhe disse que não existem Ovos de Páscoa neste programa?
$ aptitude -vvv moo
Pare com isso!
$ aptitude -vvvv moo
Ok, ok, se eu lhe der um Ovo de Páscoa você irá embora?
$ aptitude -vvvvv moo
Tudo bem, você ganhou.

                               /----\
                       -------/      \
                      /               \
                     /                |
   -----------------/                  --------\
   ----------------------------------------------
$ aptitude -vvvvvv moo
O que é isso? Isso é um elefante sendo comido por uma cobra,
é claro.

Com o apt-get nós recebemos a vaquinha :P

$ apt-get moo
         (__)
         (oo)
   /------\/
  / |    ||
 *  /\---/\
    ~~   ~~
...."Have you mooed today?"...

Também, se falarmos ‘moo’ para o bot no canal #Debian no IRC (irc.freenode.net ou irc.debian.org) ele no responde com um versinho:

samuraidio: moo
dpkg: mooooooo! I am cow, hear me moo, I weigh twice as much as you. I’m a cow, eating grass, methane gas comes out my ass. I’m a cow, you could be too; join us all! type apt-get moo. aplay /usr/lib/openoffice/share/gallery/sounds/cow.wav

Apesar de inúteis, estes comandos são, no mínimo, engraçados. É o tipo de coisa que os programadores fazem nas horas vagas…

Eles me lembram também de um comando no M$ Word, onde, se você digitar =rand (20,10) e pressionar Enter ele imprime diversas vezes (pra ser exato, o primeiro número é a quantidade de frases por parágrafo e o segundo a de parágrafos) a seguinte frase:

“A ligeira raposa marrom ataca o cão preguiçoso.”

Porém esta tem uma razão, a frase acima, no original, em inglês, contém todas as letras do alfabeto, é era utilizada para testar máquinas de escrever (Fonte: Wikipédia).

“The quick brown fox jumps over the lazy dog.”

Agora, sabe-se lá porque foi adicionado no M$ Word…

Estudos de rastro visual exibem que usuários geralmente lêem páginas web em um formato padrão em ‘F’: Duas linhas horizontais, seguidas de uma linha vertical.

“‘F’, de Fast. É como usuários comumente lêem o conteúdo de nossas páginas e blogs. Movendo os olhos velozmente em um padrão bem diferente do que aprendemos na escola.”

Estudos do Grupo Nielsen Norman, comprovam que a maioria das leituras de páginas web concidem no padrão de leitura utilizado:

• Primeiramente, o usuário lê uma primeira linha horizontal superior à página.
• Em seguida o usuário desce um pouco e lê mais rapidamente uma segunda linha horizontal ou parte desta.
• Por último, o usuário escaneia rapidamente as linhas abaixo, formando uma linha vertical na página, correspondente aos inícios dos parágrafos subseqüentes.

O estudo deste padrão de leitura foi feito com o uso de uma tecnologia de escaneamento de rastro visual. A tecnologia destaca, como zonas de calor, os locais onde o usuário mantém seus olhos fixos por mais tempo. Veja os exemplos abaixo:

As áreas mais próximas do vermelho são as em que o usuário gastou mais tempo com seus olhos fixos, enquanto as em azul são as que foram vagamente visualizadas. As zonas de calor desenham um formato que lembra, na maioria dos casos, a letra ‘F’.

Este estudo é um tanto útil para designers e redatores de páginas, uma vez que exibe quais áreas em geral recebem mais atenção do usuário. Assim, seguem algumas dicas para dar uma boa leitura aos visitantes de seu blog ou site:

• Escreva um título chamativo e atraente, que dê uma boa idéia do tema que será abordado na página. Este será a linha superior do ‘F’ e, conseqüentemente, a que receberá mais atenção.
• Presenteie o usuário com um breve resumo so material apresentado no parágrafo logo abaixo do título. Este resumo pode ser uma rápida conclusão do assunto, ou um breve comentário sobre os principais pontos desde. Este será a segunda linha horizontal do ‘F’ e, possivelmente, muitos leitores terminarão por ler apenas até aqui, caso não se interessem mais pelo assunto. Em resumo, os dois primeiros parágrafos devem apresentar a parte mais importante da informação.
• Destaque cada início de parágrafo do texto principal com um objetivo bem definido. Não enrole o texto com citações ou comentários desnecessários, comece diretamente no assunto, e lembre de separar cada tópico em um novo parágrafo. Estes inícios de parágrafos formarão a linha vertical do ‘F’. O desafio é incentivar o leitor a não parar nas primeiras duas ou três palavras do parágrafo.

Obviamente, este padrão não se aplica a páginas com estruturas diferentes de um artigo em comum. Como páginas de FAQ e separadas em tópicos, mas é predominante na maioria.

Uma vez que é a nossa missão como designers web, redatores e/ou blogueiros, dispor informações para rápido e fácil acesso aos nossos queridos leitores, não custa nada seguir esta pequenas regrinhas. Certamente elas trarão mais e mais leitores para nossas páginas, atraídos pelos textos bem elaborados e objetivos.

Fonte: www.useit.com

Acontece que a Mozilla não libera binários para sistemas 64 bits (os 32 bits do ff3b4 podem ser obtidos aqui), então, enquanto não saem os binários para o Debian, o jeito é baixar o código fonte e compilar eu mesmo.

Os fontes podem ser obtidos aqui, mas não vou explicar o processo de instalação agora, isso fica pra um próximo post (quem sabe amanhã).

Pois é… Então que eu baixei os fontes, compilei, e após iniciar o bichinho, me aparece uma janelinha animada me parabenizando por ter compilado e instaladocom sucesso o Minefield 3.0 beta 4… Huh!? Instalado o que?? :|

Bem, apesar da estranheza do logo e nome do programa, ele é, obviamente, o nosso querido Mozilla Firefox.

A diferença no nome e logo tem, segundo comentários em #developers@irc.mozilla.org, dois motivos: 1. Os direitos autorais do nome e logo do Firefox, pertencentes à Mozilla, e 2.Como ainda é uma versão beta, ele pode apresentar vários bugs, e sendo compilado por usuários, pode apresentar ainda mais, então não seria saudável, para o nome Firefox, ter tantos bugs. Ou seja, algo como: “Use-me e abuse-me a vontade, e se eu apresentar algum bug, lembre-se, eu não sou o Firefox, sou o Minefield que você mesmo compilou”.

Hehe… Brincadeiras a parte. Logo vou postar um tutorial detalhado resumido de como compilar e instalar corretamenta o Mozila Firefox Minefield em seu Debian GNU/Linux, e também como utilizar perfis diversos, para não precisar compartilhar as extensões e configurações entre as versões 2.0 e 3.0 (o que causaria problemas de compatibilidade).

Trata-se de uma adição, pelo menos interessante, contendo alguns vídeos bem-humorados, como este a seguir:

[There is a video that cannot be displayed in this feed. Visit the blog entry to see the video.]

Fontes: http://www.lintube.com, http://br-linux.org/2008/lintube-site-agrega-videos-sobre-codigo-aberto-do-youtube/

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

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

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.

ATENÇÃO: Este é um procedimento perigoso, não recomendado para menores de idade, pessoas com problemas mentai, ou que não saibam contar

1. Pegue aquele CD de pagode ou funk de sua irmã que você não aguenta mais ouvir;
2. Retire da capinha;
3. Coloque dentro de seu microondas, com a face metálica (a que toca) voltada para cima;
4. Ajuste o tempo para 3 segundos e ligue.

Vale lembrar que o CD não vai mais tocar depois do procedimento.
Caso esteja sem um microondas no momento apenas dê uma olhada no vídeo abaixo.

[There is a video that cannot be displayed in this feed. Visit the blog entry to see the video.]

Especificamente, o relatório compara o número de brechas de segurança registradas nos seis primeiros meses de vida no Vista, Windows XP, Red Hat Enterprise Linux 4 Workstation, Ubuntu 6.06, Novell SUSE Linux Enterprise Desktop 10.8, Mac OS X 10.4 e outros.

A conclusão, sempre segundo a Microsoft, é de que o Vista teve 12 brechas corrigidas. Em comparação, o Red Hat Workstation teve 281, sendo 86 de “alta severidade”. O Ubuntu teve 145 vulnerabilidades, 47 graves; o SUSE, 159, 50 severas; e o Mac OS X, 60, com 18 de alta severidade.

O relatório é apresentado por Jeff Jones, diretor de estratégia de segurança da Microsoft. Seus números e conclusões já estão sendo postos em dúvida. Uma das críticas feitas a ele refere-se à relação entre falhas conhecidas e corrigidas. Aponta-se, por exemplo, que o Red Hat teve mais brechas, mas resolveu 81% das falhas conhecidas, enquanto a taxa de correção no Vista é de apenas 48%.

O relatório original de Jones, em formato PDF, está neste endereço.

Fonte: http://info.abril.com.br/aberto/infonews/062007/25062007-19.shl