FIAT + FIORI – UMA PARCERIA DE BABACAS FOREVER ALONE

Standard

A concessionária Fiori, revendedora da linha Fiat em João Pessoa, comercializou em dezembro de 2011 um veículo ‘Novo Palio’, modelo 2012, de placas OFB-7139-PB, com falhas ao cliente José Fernando Santos de Carvalho.

De acordo com o comprador, dois dias após a aquisição do veículo, começaram os intermináveis problemas. Inicialmente, o veículo não deu partida, ou seja, quando a chave de ignição era acionada, o painel não acendia e o carro não ligava o motor.

Indignação
“Procurei a Fiori para solucionar o problema e ‘eles’ (Fiori) não detectaram nenhuma anomalia, informando que o carro estava em perfeitas condições de uso. No entanto, o problema persistiu e eu retornei diversas vezes na concessionária para relatar a mesma anomalia, além de outros tantos, como um alarme de velocidade excedida sem que o veículo estivesse em tal condição. Houve travamento de porta-malas, ponteiro pulando, computador de bordo todo sem regulagem, entre outros problemas”, disse José Fernando.

Medo
O consumidor prejudicado teme pela sua vida e da sua família. Ele revelou que por conta de sua vida profissional, necessita  viajar constantemente. “Eu não posso nem me arriscar, pois não confio mais no Palio que adquiri na Fiori. Vou procurar meus direitos e tenho fé que tudo será resolvido”, desabafou José Fernando.

O outro lado

A reportagem do Paraíba Já entrou em contato com a Fiori, pelo 3208-1512, porém, a ligação passou por diversos ramais e acabou sendo desligada.

Paraíba Já

 

 

=============

 

http://paraibaja.com.br/?p=noticia_int&id=19509

 

Defeito de fábrica em Novo Palio 2012 e o descaso da FIAT

Nos ultimos 3 meses e meio, tenho retornado à Concessionária Fiat varias vezes. O fato é que comprei um carro(NOVO PALIO 2012) com anomalias, que eles nao conseguem resolver. Eles alegam: “O carro está em perfeitas condicoes de uso”.

Pasmem, ja experimentei porta-malas eletrico travado(no dia que ia viajar para ser padrinho de casamento), computador de bordo informando problemas no motor, dificuldades pra ligar o carro, ponteiro do velocimetro “PULANDO”, cortes na ingestão de combustível enquanto em movimento, controle das portas não respondendo e outras falhas na entrega do produto(direção desalinhada, risco no painel, peças alteradas).

Eu ja não aguento mais relatar o problema a empresa ou ficar vários dias à pés, por deixar o carro na Concessionária. Passo por diversos transtornos e incovenientes.

Tenho um filho de 1 ano. Todo pai sabe que “é lei”, chegar em casa e dar uma voltar na rua com o bebe pra ele nao chorar.Ficar se o unico carro da familia é MUITO PROBLEMATICO.

Faço viagems constantes à refice-PE, devido ao meu mestrado na UFPE e tenho MEDO DA INTEGRIDADE FISICA DA MINHA FAMILIA.

Sugiro que NÃO COMPREM VEICULOS FIAT, É JOGAR DADOS COM A SORTE. se o carro sair bem, ok, senão, vc ESTARÁ NO PREJUIZO (FATO).

 

How to ou Tutorial Full do Subversion (SVN) Fácil e prático (e ripado)

Standard

Este é um pequeno artigo que tem a intenção de resumir , para iniciantes no assunto, como eu, as principais funcionalidades e conceitos por trás do controle de versão (versionamento) feito através do Subversion ou SVN.

Atenção! Este artigo foi todo baseado no UBUNTU, mas pode ser facilmente modificado para se aplicar em qualquer S.O, como o windows.

Como o título pode sugerir, não pretendo aqui abordar as inúmeras funcionalidades ou mesmo mostrar todo o poder do subversion. Sou um programador PHP que, a maioria do tempo, trabalho sozinho nos meus projetos, apenas sendo ajudado no que tange ao projeto gráfico dos sites pelos meus amigos.

A idéia é mostrar como usar, de forma prática, o controle de versão, por pessoas como eu, que não obrigatoriamente estão trabalhando em grandes equipes. Deixando claro que, os conceitos aqui apresentados, poderão ser extendidos.

Começemos pelo começo !

Para que serve este negócio de controle de versão ?! A finalidade é dar um controle maior sobre tudo que você altera no seu projeto!

Pausa para explicação! 

Projeto: Nome que inventamos de dar a um monte de arquivo e diretório junto! Ou seja, para o Subversion é tudo arquivo e diretório! Problema seu se você quis chamar isso de projeto!

Digamos que ele permite você ter um histórico de tudo que você fizer. Se você modificou aquela rotina para otimizar uma
montagem_pensamento_inicial.jpgconsulta, se você inseriu uma nova função e retirou outra, se você modificou a imagem que era exibida em determinada página html, tudo fica lá guardado! Pra que isso ? Para o caso de sua alteração causar algum problema! Se deu você nem precisa se preocupar em relembrar o que foi que tinha alterado, se fez tudo correto, basta um simples comando e você recupera o estado anterior.

O Melhor de tudo, na minha opinião, é que você fica livre para mexer como quiser no seu projeto sem precisar ficar fazendo backups !

Vai me dizer que você nunca pegou um arquivo fonte para alterar aquela função vital e só por via das dúvidas fez um backup e deixou lá : arquivoFonte.bkp. Ai depois precisou fazer outra alteração, e lá foi você fazer um outro backup : arquivoFonte-20070507.bkp ?! Ou ainda resolveu fazer uma alteração substancial em várias partes do site e ai resolveu, por via das dúvidas, copiar todo o diretório e criar um outro: projetoBackup ! Nunca fez isso ? Sorte sua amigo, pois muita gente faz isso e fica com aquele monnnte de arquivos no diretório.

Vamos só explicar, antes de mais nada, alguns conceitos.

<conceitos>

Repositório!

Segundo o Houaiss, lugar onde se guarda, arquiva, coleciona alguma coisa. Traduzindo. Nada mais é do que o local onde você vai guardar o seu projeto. Na prática, é um diretório, uma pasta qualquer guardada ou no seu computador, ou no seu pendrive, ou em um server na china.

Repositório = Diretório = Pasta

A única diferença entre um repositório e um diretório qualquer do seu disco, é que o repositório é uma pasta que é controlada pelo Subversion, ou seja, ele vai colocar um bocado de coisa lá dentro e vai controlar tudo. Logo, não se preocupe se você não entender o que tem lá dentro. Simplesmente saiba que ele vai controlar tudo direitinho.

Cópia de Trabalho (Working Copy)

Novamente, nada mais é que um Diretório, pasta, qualquer.

Comece a perceber que,para o subversion, tudo se resume a diretórios (pastas) e arquivos. Este negócio de repositório, Cópia de Trabalho, Projeto, é tudo criação da sua cabeça.

A única diferença deste diretório para o Repositório, é que é neste que você trabalha, ou seja, faz as modificações, cria, apaga as coisas. O outro (repositório), é o seu Backup, para onde você manda, por segurança, tudo que você alterou, criou, apagou.

Se tudo é Diretório, qual a diferença entre um diretório qualquer do meu HD, para o Repositório e para a Cópia de Trabalho ? A única diferença é que o Subversion tem controle sobre estas duas últimas, não fazendo a mínima idéia do que fazer sobre todas as outras!

</conceitos>

Resumão!

Tudo se resume a pegar os arquivos do repositório (como quem tira os cadernos da gaveta), fazer as alterações necessárias, enviar de volta para o repositório (guardar os cadernos novamente). E assim sucessivamente.

Vamos Detalhar um pouquinho melhor!

Lembre-se: Você vai trabalhar em um diretório, que chamamos de Cópia de Trabalho (Working Copy) !

O funcionamento básico do controle de versão, resumidamente, consiste em:

 

Criou o Supusitório? Opa, é repositório rapá!
(SVNADMIN CREATE)

Caso ainda não exista uma pasta no seu computador, no seu pendrive, em um servidor qualquer da china, é hora de criar o repositório. Claro, você só vai criar se você tiver este poder né mesmo! A Idéia deste artigo é mostrar como isso é feito localmente, na sua máquina mesmo. Caso necessite, existem servidores pagos e gratuitos , como o projeto OpenSVN (https://opensvn.csie.org/) que permite que você tenha um repositório  longe do seu computador.

 

Para criar um repositório, você vai utilizar o comando svn create. Como a idéia aqui é mostrar como utlizar o subversion, do ponto de vista , de um programador que trabalha sozinho, este passo será necessário. A não ser que se escolha utilizar um servidor externo.

O processo é simples. Basta digitar :

$svnadmin  create  <CaminhoDoDiretorio>

Este comando irá criar o Diretório que será considerado o repositório do seu projeto.

Eu tou começando a usar o meu pendrive como repositório. Isso mesmo. Crio o meu repositório no meu pendrive, e ele vai comigo para onde eu quiser. Quando eu chego em outro micro, plugo o pendrive, faço um checkout (explicado mais abaixo), trabalho do jeito que eu quero, e no final, basta desplugar o mesmo, clocar no bolso e ir pra casa. Qual a vantagem disso em relação a um servidor externo ? Boa pergunta! Velocidade, e acesso aos meus projetos, mesmo emmicros sem acesso a internet. Qual a desvantagem ? A inicial é que só eu posso usar isso, ou seja, se quiser um repositório compartilhado com mais pessoas, não dá.

Exemplo Prático:

$mkdir /home/diego/repositorio
$svnadmin create  /home/diego/repositorio/sitePessoal

 

Vai começá ? Coloque as coisa sob o chicote do seu Subversion! 
(SVN IMPORT)

Uma vez que o repositório esteja criado, ou tenha sido escolhido, deve-se pegar os arquivos do seu projeto, que deverão estar em uma pasta qualquer, e colocar no mesmo, para que o subversion possa começar a controlar as alterações que você fizer! Imagine isso como um Backup inicial de tudo que você já tem ou não tem.

Pausa para alguns conceitos! 

O pessoal que trabalha com Controle de Versão, adora definir algumas coisas como “boa prática” ou mesmo como “regras”, mas nada disso que vou falar abaixo, é obrigatório de ser utilizado.

Como já vimos anteriormente a única coisa que o subversion entende são arquivos e diretórios, logo pouco importa o nome que damos a eles, ok ?

O “Povo”, que utiliza o subversion, defende duas correntes. Uma diz que você deve criar um repositório (Diretório) para cada projeto. Assim:

RepositorioAplicacao1

RepositorioAplicacao2

E outra que você deve ter um único repositório (diretório), guardando vários projetos. Assim:

 

Repositorio

    +——- Aplicacao1

     ‘——– Aplicacao2

E ai, qual usar ? Bem, pra mim, tanto faz. O Subversion só entende diretórios mesmo. Claro, isso no entendimento básico. Como não sou nenhum expert, me parece que tem sim diferença quando você começa a usar permissionamento de quem pode mexer em que.

Outra é que, independente de como você escolheu acima, deve, ao criar o seu repositório ,estruturá-lo através de 3 diretórios, assim:

RepositorioAplicacao

     +——— trunk

     +——— branchs

      ‘———- tags

Pra que isso ? E eu sei lá! Brincadeira! Explico.

Bem, isso é muito utilizado quando você tem uma aplicação de médio/grande porte onde você tem vários desenvolvedores ou mesmo naquelas que você tem previsão de muitos versões. A idéia aqui é dividir para facilitar.

No diretório trunk deve-se colocar o projeto inicial. Seria o que o pessoal chama de linha de desenvolvimento padrão. Você começa por ai e desenvolve tudo ai dentro.

Se por um acaso você (ou outro desenvolvedor) decide, de repente, adicionar uma funcionalidade revolucionária que não estava prevista no projeto como por exemplo, a implementação de uma comunicação audio/visual em tempo real para habitantes de outros planetas, a idéia é que você faça isso em uma branch! Ou seja, você copia o estado atual da sua aplicação, ou seja, copia os arquivos todos, que estão no diretório trunk para um subdiretório dentro de branch, por exemplo, vers_comunicador_marte. Por que isso ? Porque imagine que você decida fazer isso na linha principal de desenvolvimento, ou seja, no diretório trunk. O que pode acontcer ? Pode acontecer de, por isto tudo ser um teste, quebrar a aplicação. Se você separa em um outro diretório, neste caso, um subdiretório dentro de Branch, você pode testar a vontade, sem pertubar os outros, concorda ?! Então é isso! 😀

Quer ver outra explicação porquê você deve fazer uma cópia dentro do branch ? Imagine que você esteja desenvolvendo a sua aplicação, digamos versão 1.0, e ai decide que vai começar a versão 2.0, que terá umas funcionalidades malucas, mas não quer deixar de dar suporte na versão 1.0, que é a que todo mundo usa. O que você faz ? Você continua com o desenvolvimento normal, da versão 1.0, dentro do trunk, e cópia tudo para um subdiretório, por exemplo, versao2, dentro do branch, e começa a trabalhar nesta nova versão lá. Sacou ?

Beleza! E o diretório tags ?! Bem, este diretório é utilizado para criar um snapshot, um instantâneo da sua aplicação. Como assim ? Quando o pessoal vai desenvolvendo uma aplicação e vem corrigindo bugs, adicionando funcionalidades extras, etc, geralmente o que fazem é dar nomes ou números a estas versões , correto ?  Por exemplo: aplicacao_ver_1.0, aplicacao_ver_1.1, etc.

A questão é, como será que você faria para distribuir esta aplicação ? Bem, você faria uma cópia da sua aplicação naquele exato momento que você definiu como uma nova versão, empacotaria e pronto! Estaria feito a versão 1.XX.YY, ok ? E se daqui a duas semanas, resolvesse que deveria lancar uma outra versão que corrigisse uns bugs, faria a mesma coisa, correto ? Bem, a idéia aqui é a mesma. Só que você vai deixar o subversion controlar isso pra você.

O que o pessoal faz, e você vai fazer, se quiser claro, é, quando decidir que uma aplicação deve ter uma nova versão lançada, você vai e copia tudo, todos os seus arquivos, diretórios, etc, para um subdiretório dentro de Tags, como por exemplo, versao1.1. E se daqui a duas semanas decide que vai lançar outra versão, cópia tudo de novo para um outro diretório, dentro de Tags, chamado versao1.2, ok ?

A questão é que, quando você acessar o diretório trunk, você terá o desenvovimento principal da sua aplicação, ou seja, o que você vem mexendo no dia a dia.

Quando você acessar um subdiretório dentro de branch, você estará acessando uma versão que você ainda está desenvolvendo e testando. É uma outra linha de desenvolvimento.

E dentro de tags, você terá instantâneos da sua aplicação em momentos que você definiu, sacou ?

E ai você pode perguntar. Beleza, tudo bem, fica tudo muito organizado, mas já imaginou a quantidade de arquivos que eu vou ter na minha máquina ? Um bocado, repetido em tudo que é canto !  Ai que está. O Subversion controla tudo isso de maneira magistral, só copiando o que deve ser copiado e fazendo links simbólicos internos ,etc, etc, etc. Ou seja, você terá o mínimo de arquivos duplicados.

Resumo da história. Tudo isso é apenas convensão para sua organização. Se você não quiser. Não precisa criar diretório trunk ou  branch ou  tag ou qualquer outro. Como falei antes, o Subversion entende apenas diretórios e arquivos, ou seja, para ele, trunk, branchs, tags são apenas diretórios, você ou quem utiliza que convenciona como vai utilizá-los. Isso é tão verdade, que se você quiser, nem precisa criá-los ou pode até criá-los com outros nomes, por exemplo: Em vez de trunk, colocar LinhaPrincipal, em vez de Branchs, LInhasDeTestes e em vez de Tags, VersoesLancadas.

E isso se aplica a desenvolvimento de sites ? Bem, ai é com vocês! Se achar que se aplica, utilize para organizar melhor as coisas, se não, esqueça e pronto. Só Lembre-se: TUDO É DIRETÒRIO e OPERAÇÕES DE BACKUP.

E depois de tudo isso, o que eu devo fazer, pelo amor de Deus ?

Bem, se você quiser utilizar o que falei acima, ou seja, utilizar estas convenções, crie os diretórios trunk, branchs, tags, coloque toda a sua aplicação (arquivos fontes, diretórios, etc) dentro do trunk, e importe tudo para o repositório. Este ato de importar, está indicando para o subversion que ele deve copiar tudo que está na sua pasta para o seu repositório e deve começar a controlar as coisas.

Continuando o Exemplo Prático:

Continuando o exemplo anterior

$cd /home/diego/temp
$mkdir MinhaAplicacao
$mkdir MinhaAplicacao/trunk
$mkdir MinhaAplicacao/branchs
$mkdir MinhaAplicacao/tags
$cd MinhaAplicacao

Observação: Caso você já tenha algo desenvolvido do seu projeto, conforme a convenção explicada acima, coloque tudo dentro do diretório trunk.

$svn import   .   file:///home/diego/repositorio/sitePessoal/trunk/ 

Observação2: Estou utilizando, nos exemplos, um repositório local, que fica na mesma máquina. Como dito anteriormente, o mesmo pode estar em um servidor remoto, e ai o acesso pode se dar pelo protocolo http. Neste caso você utilizaria, no lugar de file://, http://<servidor>/<Repositorio>

Atente para o fato de que, mesmo estando na mesma máquina, o acesso ao repositório, feito pelo svn, é através de uma URL, neste caso file://.

 

E esse tar de Uorqui Copí ?!
(SVN CHECKOUT)

Como explicado anteriormente, o subversion só controla dois diretórios: O repositório e a Cópia de Trabalho. É necessário, caso você ainda não possua, criar uma cópia de trabalho. Isso nada mais é do que pegar o que tem no seu repositório, ou seja, seu backup, e colocar em uma pasta qualquer. A partir deste momento, você terá uma cópia de trabalho do seu projeto, onde deverá efetuar todas as alterações.

Atenção! Atenção! LEIA RAPÁ ! 

Quando você faz o IMPORT do seu projeto para o repositório, como explicado no item anterior, o diretório não fica automaticamente controlado pelo Subversion! Por isso ele pode ser descartado, apagado, jogado fora, esquecido, deletado. Entendeu ?

Logo, para começar a trabalhar no seu projeto, depois de importá-lo para o repositório, é obrigatório que você faça um checkout, ou seja, copie tuuuuudo de volta, do repositório para algum diretório (work copy).

 

Este processo de checkout é sempre utilizado quando se vai começar a trabalhar no projeto, caso você não possua uma cópia de trabalho (work copy), em sua máquina ou em uma máquina nova. Caso já possua, geralmente se faz um update apenas, que tratará de atualizar a sua versão da cópia de trabalho de acordo com a que está no repositório.

Também é utilizado, quando você quer pegar uma versão qualquer do seu projeto, que não a última, ou mesmo, uma versão que está em algum branch.

Continuando o exemplo prático

$mkdir /home/diego/projetos/CopiaTrabalhoSitePessoal
$cd /home/diego/projetos/CopiaTrabalhoSitePessoal
$svn checkout  file:///home/diego/repositorio/sitePessoal/trunk/

Caso você queira trabalhar em um branch específico, por exemplo, uma versão 2 que você está desenvolvendo, em vez da linha de desenvolvimento principal:

$svn checkout file:///home/diego/repositorio/sitePessoal/branchs/ver2

Não sei se vocês notaram, mas até agora, tudo se resumiu a copiar de um diretório para outro, só que ao invés de usar comandos do sistema operacional, estamos usando o subversion.

Alterô os Arquivo ?! Ouxe, Diz pro Seu Subversion cuidá dêles.
(SVN COMMIT)

Toda e qualquer alteração na sua cópia de trabalho não é automaticamente controlada pelo subversion! Não? Não! Uma vez que você tenha alterado um arquivo, você precisa dizer para o subversion que você alterou e que ele deve ser enviado para o repositório!

Opa! Perai! Mas se o repositório é um backup, ele vai apagar meu backup anterior! Naaada disso! Ai é onde está o pulo do gato. O Subversion, não apagar nunca seus arquivos, apenas ele vai criar uma nova versão do seu arquivo lá! Ou seja, vai existir a cópia anterior e a nova cópia! 😀 Isso é o que se chama de revisão. Toda vez que você altera algo e manda para o repositório, você está criando uma nova revisão.

Continuando o exemplo prático
$cd /home/diego/projetos/CopiaTrabalhoSitePessoal
$svn commit file:///home/diego/repositorio/sitePessoal/trunk/ 

 

Criô ? Apagô ? Tá bulindo nas coisa né ? Vô dizê pro Seu Subversion! 
(SVN ADD, DELETE, MKDIR, etc)

Assim como as alterações nos arquivos, quando você cria um novo diretório dentro do seu projeto, apaga, mude de lugar, ou seja, mexe na estrutura do seu projeto, você precisa informar isso para o Subversion.

Tudo isso é feito através dos comandos ADD, DELETE, MKDIR, etc. Veja abaixo, no Exemplo Prático da Vida Real, como trabalhar com estes comandos.

 

E se eu já tô cum minha Uorqui Copi, como qui eu dexo ela atualizadinha ?
(SVN UPDATE)

 

Isso é feito através do comando UPDATE, que tem a finalidade de atualizar a sua cópia de trabalho.  

E como é que se mexe nestes tar de BRUNCH, TAG ?

Quer saber mesmo ? Então veja o Exemplo Prático da Vida Real abaixo. É facim facim. 

Exemplo Prático da Vida Real

1. Criando o Repositório em uma pasta qualquer

 

 

/tmp# mkdir repositorios 
/tmp# cd repositorios/ 
/tmp/repositorios# svnadmin create HelloWord 
/tmp/repositorios# ls -lh 

    total 4,0K 
    drwxr-xr-x 7 root root 4,0K 2007-05-29 09:31 HelloWord 

/tmp/repositorios# ls -lh HelloWord/ 

    total 28K 
    drwxr-xr-x 2 root root 4,0K 2007-05-29 09:31 conf 
    drwxr-xr-x 2 root root 4,0K 2007-05-29 09:31 dav 
    drwxr-sr-x 5 root root 4,0K 2007-05-29 09:31 db 
    -r–r–r– 1 root root    2 2007-05-29 09:31 format 
    drwxr-xr-x 2 root root 4,0K 2007-05-29 09:31 hooks 
    drwxr-xr-x 2 root root 4,0K 2007-05-29 09:31 locks 
    -rw-r–r– 1 root root  229 2007-05-29 09:31 README.txt

2. Criando o diretório e estrutura da nossa futura aplicação.

/tmp/repositorios# cd .. 
/tmp# mkdir HelloWord 
/tmp# cd HelloWord 
/tmp/HelloWord# mkdir trunk 
/tmp/HelloWord# mkdir branchs 
/tmp/HelloWord# mkdir tags 
/tmp/HelloWord# ls -lh 

    total 12K 
    drwxr-xr-x 2 root root 4,0K 2007-05-29 09:38 branchs 
    drwxr-xr-x 2 root root 4,0K 2007-05-29 09:38 tags 
    drwxr-xr-x 2 root root 4,0K 2007-05-29 09:38 trunk 

/tmp/HelloWord# cd trunk 
/tmp/HelloWord/trunk# echo “<?php echo ‘pagina inicial’; ?>”  > index.php 
/tmp/HelloWord/trunk# cat index.php 

    <?php echo ‘pagina inicial’; ?> 

/tmp/HelloWord/trunk# ls -lh 

    total 4,0K 
    -rw-r–r– 1 root root 32 2007-05-29 09:41 index.php

3. Importando (enviando) a aplicação para o repositório.

/tmp/HelloWord/trunk# cd ..
/tmp/HelloWord# svn import . file:///tmp/repositorios/HelloWord/  \
                        -m “Importacao Inicial”

    Adicionando    branchs
    Adicionando    trunk
    Adicionando    trunk/index.php
    Adicionando    tags

    Commit da revisão 1.
/tmp/HelloWord# ls -lh /tmp/repositorios/HelloWord/ 

    total 28K 
    drwxr-xr-x 2 root root 4,0K 2007-05-29 10:09 conf 
    drwxr-xr-x 2 root root 4,0K 2007-05-29 10:09 dav 
    drwxr-sr-x 5 root root 4,0K 2007-05-29 10:09 db 
    -r–r–r– 1 root root    2 2007-05-29 10:09 format 
    drwxr-xr-x 2 root root 4,0K 2007-05-29 10:09 hooks 
    drwxr-xr-x 2 root root 4,0K 2007-05-29 10:09 locks 
    -rw-r–r– 1 root root  229 2007-05-29 10:09 README.txt

 

    Observe que a estrutura de diretórios do repositório, apesar da importação(cópia), não mudou em nada, pois o subversion trata de controlar tudo isso internamente. Era de se esperar que aparecessem as pasta s trunk, branchs, tags dentro de /tmp/repositorios/HelloWord,  já que a importação nada mais é do que uma cópia não é mesmo ? ;D

    Observe também que todas as operações com o subversion, de importação, de update, de checkout, etc, devem ser realizadas na raiz do projeto, neste caso o diretório /tmp/HelloWord.


4. Apagando o conteúdo do diretório, que já não é mais necessário, e que não é controlado pelo subversion, e fazendo o primeiro checkout.

/tmp/HelloWord# rm * -r 
/tmp/HelloWord# svn  checkout  file:///tmp/repositorios/HelloWord/trunk   . 

    A    index.php 
    Gerado cópia de trabalho para revisão 1. 

/tmp/HelloWord# ls -lh 

    total 4,0K 
    -rw-r–r– 1 root root 32 2007-05-29 10:19 index.php

 

    Observe que, como pedimos para fazer o checkout do trunk, veio apenas o arquivo index.php. Lembre-se, não ficaremos fazendo checkout de toda a estrutura que importamos, mas apenas do que nos interessa, ou seja, o que estiver dentro do trunk, ou de branchs ou mesmo de tags.

5. Alterando o conteúdo do arquivo e dando commit para forçar a atualização do Repositório.

/tmp/HelloWord# echo “<?php echo ‘linha2′; ?>” >> index.php
/tmp/HelloWord# cat index.php
   
    <?php echo ‘pagina inicial’; ?>
    <?php echo ‘linha2′; ?>

/tmp/HelloWord# svn status
   
    M      index.php

/tmp/HelloWord# svn commit -m “index.php modificado”

    Enviando       index.php
    Transmitindo dados do arquivo .
    Commit da revisão 2.

    Observe que, após a edição do arquivo, ao se executar o comando svn status, o mesmo retorna indicando que o index.php foi Modificado.

    Quanto se executa o commit o arquivo Modificado é enviado para o repositório e o prrojeto fica na revisão 2.

 

6. Alterando a estrutura (diretórios e arquivos) do projeto.

/tmp/HelloWord# mkdir cpanel
/tmp/HelloWord# cd cpanel
/tmp/HelloWord/cpanel# echo “<?php echo ‘PainelDeControle’; ?>”  >   \
                                 cpanel.php

/tmp/HelloWord/cpanel# cd ..
/tmp/HelloWord# svn status
   
    ?      cpanel

    Observe que o subversion mostra uma interrogação ao lado do diretório que acabamos de criar. Isso indica que este diretório ainda não é controlado pelo subversion, ou seja, ainda não está no repositório. Precisamos adicioná-lo ao repositório.

 

/tmp/HelloWord# svn add cpanel/ 
    A         cpanel
    A         cpanel/cpanel.php

    Observe que ele automaticamente adiciona tudo que está dentro do diretório cpanel. Vale lembrar que, apesar do comando ter sido bem sucedido, o mesmo ainda não foi definitivamente concretizado. Para isso, precisamos chamar novamente o commit.

/tmp/HelloWord# svn commit -m “+ Diretorio cpanel”
    Adicionando    cpanel
    Adicionando    cpanel/cpanel.php
    Transmitindo dados do arquivo .
    Commit da revisão 3.

    Veja que automaticamente todo o conteúdo do diretório foi enviado ao repositório e agora o nosso projeto se encontra na revisão 3.

    vamos adicionar mais um arquivo no nosso cpanel e ver o que acontece.

/tmp/HelloWord# echo “<?php echo ‘moduloUsuario’; ?>” >  \
                        cpanel/user.php

/tmp/HelloWord# svn status

    ?      cpanel/user.php

    Como esperado, o status retorna informando que o arquivo user.php ainda não está sobre controle do subversion. Logo vamos adicioná-lo.

/tmp/HelloWord# svn add cpanel/user.php

    A         cpanel/user.php

/tmp/HelloWord# svn commit -m “+ modulo usuario”

    Adicionando    cpanel/user.php
    Transmitindo dados do arquivo .
    Commit da revisão 4.

    Agora nosso projeto se encontra na revisão 4. Acho que você já deve ter notado que a cada commit o número da revisão é incrementado.  Deve ter notado também que a cada arquivo criado, deve-se adicioná-lo ao repositório correto ? Correto! E deve estar pensando natrabalheira que é, se eu adcionar um monte de arquivos ou se eu tiver que ficar dando add e commit a cada arquivo criado. Pois é ! Mas hoje já existem aplicativos, como o rapidSVN, o TortoiseSVN(para windows), scripts que se integram ao nautilus, etc, que fazem tudo isso na interface gráfica. Ou seja, o que estamso fazendo aqui, manualmente é para que você entenda o conceito, já que o modo de usar os softwares pode variar de um para outro.

    Vamos imaginar agora que por um descuido você removeu o arquivo user.php, do diretório cpanel, quando era para ter removido outro.

/tmp/HelloWord# rm cpanel/user.php 
/tmp/HelloWord# svn status

    !      cpanel/user.php

    Observe que o subversion retorna com o nome do arquivo removido com uam exclamação, como quem diz : Meu Deus, cadê o arquivo que eu estava controlando ?! Como isso foi um engano, e como você anteriormente já tinha colocado este arquivo no repositório, você pode atualizar a sua cópia de trabalho com o comando updatde.

/tmp/HelloWord# svn update

    Restaurado ‘cpanel/user.php’
    Na revisão 4.

    O arquivo foi restaurado. Começaram a perceber o poder deste negócio de controle de versão ?

    Com isso fica o que falamos acima. Quando quiser realmente adicionar um diretório, remover um arquivo, criar um novo arquivo, você deve fazer isso com os comandos do subversion. Na verdade, adicionar arquivo e diretórios nem é tão crítico, já que podemos utilizar o comando add posteriormente a criação dos mesmos, mas a remoção de arquivos e diretórios ou mesmo a movimentação deles para outros lugares, isto sim, deve ser feito com o subversion. Logo a remoção do arquivo, se você quiser realmente removê-lo, deve ser feita da seguinte maneira :

 

/tmp/HelloWord# svn delete cpanel/user.php

    D         cpanel/user.php

/tmp/HelloWord# ls cpanel -lh

    total 4,0K
    -rw-r–r– 1 root root 34 2007-05-29 12:23 cpanel.php


/tmp/HelloWord# svn commit -m “- user.php”

    Apagando       cpanel/user.php
    Commit da revisão 5.

    E se, mesmo depois de ter apagado propositadamente, você descobre que aquele arquivo continha um trecho que você poderia necessitar ? Ou mesmo, que aquele arquivo era essencial e você não deveria ter apagado ? Será que tem como recuperar o arquivo ? Tem sim, claro. Basta você dizer para o subversion que quer que ele atualize a sua cópia de trabalho para a revisão anterior, no caso a 4.

/tmp/HelloWord# svn update -r4

    A    cpanel/user.php
    Atualizado para revisão 4.

/tmp/HelloWord# ls cpanel -lh

    total 8,0K
    -rw-r–r– 1 root root 34 2007-05-29 12:23 cpanel.php
    -rw-r–r– 1 root root 31 2007-05-29 12:59 user.php

    Observe que agora estamos trabalhando da revisão 4. A revisão 5 ainda existe, só que ela não possui o arquivo user.php. O interessante é notar que, a qualquer momento, podemos trabalhar nas revisões que quisermos, nos movimentando entre os nossos “backups”. Só que isso gerou um impasse, concordam ? Eu tenho um arquivo , que acabei apagando de propósito, mas que não era para ter apagado, na revisão 4mas não tenho ele na revisão 5.  Se eu continuar a trabalhar na revisão 4, eu perco todas as outras alterações (se houverem), que eu tenha feito até o commit para a revisão 5. Se eu vou para a revisão 5, eu tenho todas as alterações, mas não tenho o arquivo user.php. E agora ? Quem poderá nos ajudar ? 😀

    A questão é que o subversion dá nó em pingo d’água. E o que estamos escrevendo aqui é apenas uma pontinha de todo o seu poder. Como tudo para o subversion é diretório e arquivo, pensemos assim. Se eu não utiliza-se controle de versão e fizesse as coisas na mão, provavelmente eu teria  dois diretórios assim :

    HelloWordRevisao4

    HelloWordRevisao5

    Logo, ficaria muito fácil eu recuperar o arquivo, fazendo uma simples cópia entre diretórios, concorda ? Então o mesmo se aplica ao subversion, ele tem um comando chamado copy, onde você pode especificar a origem, o destino e a revisão. Então observe:

Voltemos para a revisão 5.

/tmp/HelloWord# svn update

    D    cpanel/user.php
    Atualizado para revisão 5.

/tmp/HelloWord# ls cpanel/ -lh

    total 4,0K
    -rw-r–r– 1 root root 34 2007-05-29 12:23 cpanel.php

    Agora vamos copiar o arquivo user.php, que está na revisão 4, para a nossa cópia de trabalho atual.

 

 

/tmp/HelloWord# svn copy -r4   \ 
             file:///tmp/repositorios/HelloWord/trunk/cpanel/user.php   \ 
             cpanel/

    A         cpanel/user.php

/tmp/HelloWord# ls cpanel/ -lh

    total 8,0K
    -rw-r–r– 1 root root 34 2007-05-29 12:23 cpanel.php
    -rw-r–r– 1 root root 31 2007-05-29 13:13 user.php

/tmp/HelloWord# svn status

    A  +   cpanel/user.php

    Como podemos notar, o arquivo foi copiado do repositório para a pasta, e aparece com um A, indicando que foi adicionado a sua cópia de trabalho. Finalmente, vamos dar um commit para gravar tudo no repositório.

/tmp/HelloWord# svn commit -m “user.php recuperado”

    Adicionando    cpanel/user.php
    Commit da revisão 6.

    Imagine que chegamos ao final do dia e decidimos que esta versão final (revisão 6)  deveria sser chamada de HelloWord Versao 1.0. Podemos decorar que a revisão 6, é a versão 1.0, ou podemos dar este nome específico para esta revisão. de modo que quando fizermos referência a versao 1.0 o subversion nos traga automaticamente a revisão 6. Este processo consiste em “TAGGEAR” o projeto. Este é o motivo, já explicado acima, de termos criado o diretório tags.

 

    Este processo nada mais é do que uma cópia entre diretórios, utilizando o subversion.

    Antes de mais nada, vamos listar quais são as tags (versões já lançadas, digamos assim), que nós temos. Ou seja, vamos dar um ls (comando dir, para o DOS), no repositório.

/tmp/HelloWord# svn list file:///tmp/repositorios/HelloWord/tags/

    Observe que nada foi retornado, como esperado.

    Para testar um pouco mais do comando list, vamos listar o trunk.

/tmp/HelloWord# svn list file:///tmp/repositorios/HelloWord/trunk/

    cpanel/
    index.php

    Ele retornou com os nossos arquivos. Claro, porque estamos trabalhando sempre no trunk, lembram ? Ou seja, o comando list seria como um ls, láááá no repositório.

    Mas vamos lançar nossa versão 1.0 do nosso incrível projeto Hello Word.

tmp/HelloWord# svn copy file:///tmp/repositorios/HelloWord/trunk/  \
                       file:///tmp/repositorios/HelloWord/tags/versao1.0   \
                       -m “Lancando a versao 1.0″

    Commit da revisão 7.

    Antes de mais nada, o comando acima deve ser digitado em uma única linha. Pronto, nossa versão foi lançada. O que fizemos foi apenas copiar o que tinha no nosso Trunk para o diretório versao1.0 dentro de tags. Isso láááá no nosso repositório ok ? Ah, uma coisa. Isso não vai duplicar os milhares de arquivos que temos em nosso projeto, ele vai apenas criar links simbólicos, ok ? 😀

    Vamos listar agora, quais as tags (versôes) que nós temos.

/tmp/HelloWord# svn list file:///tmp/repositorios/HelloWord/tags/

    versao1.0/

    Pronto! Final do Dia. tudo correu bem. Lançamos uma versão e vamos para casa.

    Agora imagine que você chegou em casa, e lembrou que esqueceu de coloca uma pequena coisa no index.php, e gostaria de trabalhar no seu projeto. Claro, que estamos trabalhando com um repositório local, mas como dito anteriormente, o mesmo pode estar em um servidor em qualquer lugar do mundo, ou mesmo, pode estar no seu pendrive. Vamos fazer de conta, que o repositório está acessível para a gente da mesma forma que estava na outra máquina, lá no trabalho ok ?

    E agora, como eu faço para trabalhar no meu projeto ? Basta você voltar a fita e ir lááááá para o passo número 4, onde falamos em checkout. É isso mesmo. Como não temos uma Cópia de Trabalho, ainda, precisamos fazer um checkout, ou seja, copiar a revisão lá do repositório para um diretório qualquer.  Então você pode fazer, imaginando que vamos trabalhar no diretório /home/diego/temp :

/home/diego/temp# mkdir HelloWord
/home/diego/temp# cd HelloWord/
/home/diego/temp/HelloWord# svn checkout  \  
                                         file:///tmp/repositorios/HelloWord/trunk .

    A    cpanel
    A    cpanel/user.php
    A    cpanel/cpanel.php
    A    index.php

    Gerado cópia de trabalho para revisão 7.

    Pronto, agora é só meter a mão na massa e continur com os commits, updates, etc etc etc.

    Ah, como estamos trabalhando sozinhos, os updates não se tornam tão importantes. Mas se estivermos trabalhando em dupla de dois, por exemplo, vale a pena sempre dar update para garantir que sua cópia de trabalho esteja sempre atualizada, caso seu amigo tenha feito alguma modificação.

 

    Espero que este pequeno grande artigo sirva para abrir os horizontes dos iniciantes no mundo do controle de versão.

Fonte: http://www.ultimolog.com/2007/05/29/controle-de-versao-com-subversion-svn-rapido-e-pratico/

Vai navegar? Vai de Google Chrome!

Standard

A monstruosa Google nem perdeu tempo e já disponibilizou seu navegador Ultraleve e UltraFuncional. Vale a pena ressaltar que há pouco tempo ela estava apoiando o firefox (projeto mozilla) que por sua vez está na versão 3. Não iremos comentar, iremos disponibilizar (liberado há poucos minutos) o link para download, por isso “voe”:

http://www.google.com/chrome

A notícia foi retirada de -> www.tinews.info

POG: O que é?

Standard

A Programação Orientada a Gambiarras (POG ou WOP – Workaround-oriented programming) é um paradigma de programação de sistemas de software que integra-se perfeitamente a qualquer grande Paradigma de Programação atual.

Por definição, Gambiarra é aquilo que é de difícil concepção, de inesperada execução para tornar fácil o uso de algo que sequer deveria existir.

A Programação Orientada a Gambiarras foi uma evolução natural do uso do Programa Bacalhau, também conhecido como ATND – Artifício Técnico Não Documentado, dos anos 1.960–80, e vem de uma antiga expressão sileira, “Para quem é, bacalhau basta” (época em que o peixe seco ainda era barato). Programadores e analistas mais preocupados em usar buzzwords costumam utilizar o termo workaround para impor respeito.

Para que um programador possa exercer a Programação Orientada a Gambiarras, são necessários alguns fatores específicos, facilmente encontrados em ambientes de desenvolvimento:

  • Sistemas originalmente mal projetados;
  • Clientes chatos;
  • Usuários chatos;
  • Falta de vontade;
  • Falta de tempo;
  • Criatividade;
  • Gente que pensa que é DBA (normalmente são pessoas chatas, gordas, feias, sem certificação nenhuma e no que fizeram um curso de SQL Básico);
  • Arquiteto de software achando que é o máximo(normalmente pessoas, altas, loiras, chatas, arrogantes e metidos a sabe tudo);
  • Término do estoque de café/chá;
  • Aproximação do final da tarde;
  • Véspera de feriado/fim-de-semana;
  • Ter o Jackie Chan como chefe;
  • Ter o MacGyver como coordenador de projeto (ver Método MacGyver);
  • Governo defecando regras ou MP’s que entrem em vigor imediatamente sem dar tempo de atualizar sistemas;
  • Requisitos dinâmicos e/ou instáveis;
  • Área comercial vendendo ou pré-vendendo produtos imaginários ou inacabados com “entrega garantida em 30 minutos ou seu dinheiro de volta!”.

Reunidos, todos estes fatores transformam o programador em um gambiarrizador, espécie mais evoluída de programador, que possui curva de aprendizado e produtividade muito mais altas. Os códigos dos gambiarrizdores podem ser chamados de CACA (Código Avançado Complexo e Adaptável).

Lembre-se que a Microsoft – idealizade direitos, por isso, cuidado para você não precisar pagar royalties á Microsoft. Na próxima versão do Visual Studio, todas as POGs documentadas terão wizards personalizados. Por ser dotado de Inteligência Artificial (já que os programadores VB não possuem inteligência alguma) ele irá tornar o uso transparente ao POGramador.

Estudos realizados neste segmento, mostram que os programadores que evoluem para gambiarrizadores vivem melhor, saem as 18:00h, tem cabelos mais bonitos e esvoaçantes. Tudo pelo fato de que, em gambiarrizadores, eles entram em um estado alfa, onde tudo na vida funciona. Tudo que é impossível torna-se possível, de maneira totalmente obscura, mas possível.

Há correntes de programadores que discriminam a Programação Orientada a Gambiarras, alegando ser uma má técnica, que faz com que os sistemas fiquem lentos e ganhem bugs. Também ficou claro nas pesquisas que estes programadores só dizem isto por nunca terem evoluído para gambiarrizadores (e por isso nunca pegam mulher nenhuma). Com apenas uma evolução (ao contrário de ‘ como o Charmander, que necessitam de duas para atingir o ápice de seu desenvolvimento), 100% dos programadores admitem que a Programação Orientada a Gambiarras, definitivamente, é o melhor paradigma de todos.

Além disso, a Programação Orientada a Gambiarras, assim como outros paradigmas, deu origem a outros movimentos de pesquisa científica como Modelagem Orientada a Gambiarras (MOG ou WOM – Workaround-oriented modeling), Desenvolvimento de Sistemas Orientado a Gambiarras (DSOG ou WOSD – Workaround-oriented software development).

PPOG (Princípios da programação orientada a gambiarras) comentados:

  • Se funciona, então tá certo – Acoplado ou não, txt ou sql, mil funções ou 10, design patterns… Nada disso tem valor para o usuário, que só precisa de um software funcional. O termo “escalável” é falacioso;
  • My Way – Programador esperto, se é esperto mesmo é adepto do My Way. Se você está com dúvidas, faça do seu jeito pois se der merda é você quem vai se foder (e como);
  • Murphy ou Lei de Murphy ou Lady Murphy – Para lidar com Murphy e seu exército só com POG. Murphy é sagaz e ligeiro, tá só esperando você dar mole. Nada mais rápido do que uma gambiarrazinha pra acertar o que Murphy destrói;
  • Deixe o amanhã para amanhã – Muitos programadores atrasam projetos alegando que a demora de uma implementação para seguirem regras de design patterns ou comentários que ajudarão a outros entender melhor o código. Deixe o amanhã para o otário programador seguinte;
  • Comentários são para amadores – Um desenvolvedor deve ser treinado para ser fluente na linguagem de programação usada sem precisar de comentários, independente da consequente ruína de sua vida social. Isso também é conhecido como sétimo sentido;
  • Eficiência primeiro – Evite escrever em várias linhas o que pode ser feito em uma;
  • Fé em Deus – A informática é levianamente definida como ciência exata, quando esta é na verdade uma ciência holística. Vários casos reais de divina Providência foram testemunhados em ambiente fiéis aos princípios ruins foram exorcizados, e a paz instalou-se graças a fé dos gambiarrizadores;
  • 1337 h4x0r5 dud3 lol – Quanto mais ilegível, mais respeitado o código é. Consequentemente menos alterado ele é, e mais estável o sistema fica, garantindo a empregabilidade do gambiarrizador;
  • A ocasião faz o ladrão – Em determinados momentos não conseguimos escapar dela;
  • Capacidade de Abstração – Este conceito se baseia em focar-se no problema e desconsiderar conceitos e dados deios para atingir o objetivo, ou seja, o Programador deve abstrair tudo que lhe faça perder tempo como regras de negócio desnecessárias ou tratamentos de erros;
  • Conclusão Hipotética Universal Técnica Explicativa – Quando nenhum dos outros conceitos se aplica, utiliza-se este até funcionar ou desistir (C.H.U.T.E);
  • Criatividade acima de tudo – Uma pessoa criativa não é aquela que consegue chegar a diversos lugares, mas sim, aquela que chega no mesmo lugar por diversas maneiras.. Portanto, o POGer não é nada mais do que um programador criativo, que faz a mesma coisa que outros, adotando técnicas não convencionais…

Chavões POG:

“A principio isso nao tem nada a ver com o erro, mas pode ser que tenha…. algo a ver” Programador POG, sobre o erro no programa que nao sabe da onde veio.

“Deu certo? Deixa! Funcionou? Não mexa!” Bill Gates, durante o desenvolvimento do Windows ME.

“Sem comentários…” Monkey Coder sobre POG.

“Ninguém mandou pagar pouco…” Estagiário sobre POG.

“Muito cuidado ao mexer em um POG, siga o velho ditado: Bosta seca não se mexe!” Careca sobre POG.

“O que importa são os resultados” Programadores do Google Adwords.

“Os fins justificam os meios!” Nicolau Maquiavel sobre POG.

“Travou? Tenta dar Ctrl+Alt+Del. Se não funcionar, desliga e liga de novo a máquina…” Resposta de um POG a outro sobre a execução de um LOOP do manual da POG.

“Abre no Internet Explorer que funciona” Resposta padrão do suporte sobre POG.

“Na minha máquina funcionou” Programador sobre POG.

“O importante é fazer funcionar” Programador 100% pragmático sobre POG.

“O ótimo é inimigo do bom” Gerente POG Master sobre POG.

“Ontem tava funcionando!” MPOG sobre POG.

“Assim fica mais eficiente” Satanás sobre POG.

“É só colocar um DIV ali!” WebDesigner sobre POG.

“/* só testei até aki! */” Comentário de um programador Mancebo em um arquivo.

“Não se preocupe… quando você for implementar vai descobrir a melhor maneira!” Gerente sem-noção.

“Não me interessa se é restrição da ferramenta, dá um jeito e coloca isso funcionando até amanhã!” Gerente de Projeto falando ao programador.

“Simplesmente comentei e funcionou!” MPOG.

“É facil, não vejo dificuldade em fazer isso!” Gerente sem-noção definindo prazo junto com o programador.

“Tive que arrumar direto no banco – daí funcionou! Se o problema “voltar”, nos ligue novamente” POGger sobre O Poder da Fé.

“Como não faz?! Tem que implementar, acabamos de vender o produto com isto” Gerente de vendas de uma empresa qualquer.

“O código tá certo, deve ser problema na massa de dados” Programador Experiente, com várias certificações em POG.

“Terminei, só falta testar” Programador POG as 18h00 com a mochila nas costas falando pro chefe.

“É só reiniciar que funciona!” Programador POG logo de manhã com copo de café na mão.

“Dá um Build All que funciona!” Programador VB desesperado por não saber a procedência do erro.

“Bom, deixa estourar a bomba lá, aí quando vierem me pentelhar aqui eu vejo o que faço…” Programador para outro programador só esperando o problema voltar.

“A função ficou com 3000 linhas porque é impossível deixar ela menor” Programador POG tentando se passar por expert.

“Como não funciona? Eu compilei e não deu nenhum erro!!!” Estagiário, ainda falta muito para ser um programador POG.

“Se compila, funciona!” Programador POG, usando a técnica No_Exception.

“Eu fiz somente o que foi especificado!” Analista, usando a técnica In-Diana.

“Dear Aunt, let’s set so double the killer delete select all” Software de Reconhecimento de Voz, implementado em POG.

“Hum… Que estranho… Não era para acontecer isso…” Programador iniciante na empresa.

“Que lixo que fizeram!!! Olha isso!!!” Programador POG falando sobre outro Programador POG.

“Quando eu cheguei já tava assim!!!” Gambizeiro querendo tirar o seu da reta.

“… É que 1GB de RAM é pouco! Tem que colocar mais memória!!!” POGramador sobre estouro de pilha.

“… Ah!!! Isto é um erro comum do Windows!” POGramador tentando ganhar tempo para corrigir seu código.

“Reza e cruza os dedos que vai funcionar!” POG Pai de Santo falando para um POGramador menos experimente…

“Quando eu testei, funcionou!” POGramador demonstrando as gambiarras para seu Gerente Sem Noçao.

“Se funcionou contra os aliens no Independency Day, vai funcionar com você!” Will Smith sobre POG.

“Eu modelei em POG o vírus para o PC dos Aliens em Independency Day!” Chuck Norris sobre POG.

“Meu Precioso…” Gollum sobre POG.

“O ótimo é inimigo do bom” Sauron – Master PWNER SUPREMUS sobre POG.

“POG é POG e vice-versa…” Jardel – Ex-jogador de futebol sobre POG.

“O importante são os três pontos conquistados independente de como se joga” Antônio Lopes – Treinador de Futebol sobre POG.

“Existem 3 jeitos de se fazer as coisas: o jeito certo, o errado e o jeito Maximo Poder” Homer Simpson sobre POG.

“Se não funcionar leva um Roundhouse Kick! Olha só, funcionou!” Chuck Norris, conversando com o sistema quando o mesmo travou durante apresentação ao cliente.

“O Titanic afundou por que o código do GPS dele não era POG” Leornardo Di Caprio sobre POG.

“O Transponder dos aviões não funcionou pelo mesmo motivo” Piloto sobre POG.

“Service Pack – POG compilado” Anônimo sobre POG.

“Deu certo? Deixa! Funcionou? Não mexa!” Bill Gates.

“O sistema só dá problema quando tem gente usando” Programador POG, às 18h00, indo embora, já fechando a porta e falando pro chefe.

“Porra! Quem foi o filho da puta que fez este programa?” Dercy Gonçalves ao ler um programa POG.

“Fechei todos os bugs. Estão abertos apenas os que não foram resolvidos” Programador POG, vangloriando-se por ser eficiente.

“A Informática é uma ciência exata que nunca é exata né, genti” Chefinha nada gostosa de um CPD em reunião com os programadores POG, Justificando o uso de POG e relembrando a todos que ela é a Gerente de Sistemas Internos do Interior do CPD.

“Claro que conheço POG! Acabei com toda a “lentideza” dos sistemas usando POG puro com Access” Chefinha nada gostosa do CPD antes de ser chefe, na entrevista de emprego para começar como programdora de POG no CPD.

“É hora da pamonha!” Freakzoid sobre POG.

Agradecimentos a:

Sandro J. S. Souza


Crônica: O Maior Software já Escrito em Todos os Tempos.

Standard
Crônica: O Maior Software já Escrito em Todos os Tempos.


Image

Até a lua e de volta, graças a rotina de software.

Charles Babcock um dos principais redatores da revista eletrônica sobre tecnologia da informação, Information Week disserta em uma crônica onde analisa algumas das principais tecnologias criadas pelo homem para tentar classificar: O Maior Software Escrito.

Babcock considera softwares pouco lembrados, como o Sabre da American Airlines, ou programas que sequer eram softwares, como o Colossus. Remete-se a clássicos como IBM 360 e Deep Blue, para finalmente concluir qual o maior programa de computador já escrito em todos os tempos. O autor define critérios claros para suas conclusões:

“Desenvolvimento de fato superior só pode ser julgado dentro de um contexto histórico. Deve representar uma inovação, brilhantismo técnico, algo difícil que antes de tal software, não poderia ser conseguido. E deve ter plena adoção no mundo real. O Colossus transformou um processo mecânico de grafia em eletrônica — foi uma espécie de computador pioneiro — e ofereceu um serviço útil ao acelerar a tradução do telégrafo codificado. O Colossus mais que fez história, ajudou a história a tomar forma.”

Ao revisar as maiores e mais impactantes criações tecnológicas da história, o autor repassa pela criação dos sistemas operacionais, da interface gráfica com o usuário, planilhas eletrônicas, da Internet, do Unix, TCP/IP, DNS, correio eletrônico, editores de texto e conclui:

“O Maior Software de Todos os Tempos, com o mais amplo impacto no mundo todo foi o BSD 4.3. Outros Unix tornaram-se sucesso comercial mais bem sucedido, mas as conquistas cumulativas conseguidas nos sistemas BSD, especialmente versão 4.3, representaram picos incomparáveis de inovação. O BSD 4.3, representa sozinho, a maior revolução da Internet. Mais que isso, a paixão que envolve o Linux e código aberto é apenas uma ramificação direta dos ideais criados no BSD: amor pelo poder computacional e a crença que este deve ser uma extensão do poder intelectual humano, disponível sob todos os preceitos de liberdade — poder de intelecto, este que coloca o homem em seu devido lugar no universo.”

A tradução dessa crônica foi republicada internamente na FreeBSD Brasil LTDA, e essa tradução você acompanha na íntegra agora, aqui na FUG-BR.


O Maior Software já Escrito em Todos os Tempos

Por Charles Babcock, 14 de Agosto de 2006

Sem exceção, todo profissional de tecnologia pode opinar de forma rápida sobre qual o maior software já produzido, mas quando reserva-se um tempo para avaliar o que torna um software realmente brilhante, as escolhas não são tão óbvias.

Uma das mais significantes criações da programação que conheço, não era sequer um software. Antes dos britânicos construirem a máquina Colossus, que traduziam os códigos de telégrafo dos alemães durante a Segunda Guerra Mundial, os aliados demandavam seis horas para decodificar uma mensagem, e mais de um dia para interpretar essas informações junto à inteligência, chegar a conclusões e finalmente repassar essas informações ao comando militar. Depois da Colossus, os aliados conseguiram decodificar essas informações imediatamente ao interceptá-las, e assim, ter um panorama visual de todas as atividades militares alemãs na Inglaterra — informações usadas pelo General Dwight Eisenhower para, com segurança, lançar o ataque do Dia D.

Image

IBM 360

Colossus foi construída em 1944 para realizar operações Booleanas em formulário contínuo gerado na máquina na grandeza de 30 milhas de papel por hora. Sua lógica era literalmente integrada e dependente da máquina. É, talvez, o maior software que nunca foi escrito.

Mas então, a que conclusão isso nos leva? Primeiro, vamos definir critérios para avaliar o que torna um software grandioso. Desenvolvimento de fato superior só pode ser julgado dentro de um contexto histórico. Deve representar uma inovação, brilhantismo técnico, algo difícil que antes de tal software não poderia ser conseguido. E deve ter plena adoção no mundo real. A Colossus transformou um processo mecânico de grafia em eletrônica — foi uma espécie de computador pioneiro — e ofereceu um serviço últil ao acelerar a tradução de telégrafo codificado. Colossus mais que fez história, ajudou a história a tomar forma.

Outro exemplo de grande programação foi o sistema 360 da IBM. O software foi escrito como o primeiro sistema operacional de propósito geral, em 1964. Muitas das verdades que conhecemos hoje sobre software — por exemplo, que projetos simples são melhores que os complicados, que poucos programadores habilidosos conseguirão melhores resultados do que pelotões de programadores igualmente habilidosos — são originados do livro de Frederick Brooks sobre o projeto do 360, The Mythical Man-Month, da editora Addison-Wesley Professional de 1995. Brooks já sabia a quantidade de problemas que poderiam ocorrer com grandes projetos de software, antes que o projeto 360 tivesse início. De fato, ele era um crítico sobre como a IBM deveria gerir o projeto; ele considerava que os potenciais de falha eram muitos. Suponho que seja por isso que a IBM o tornou responsável pelo projeto.

Muito esperto. O resultado foi o primeiro sistema computacional capaz de executar aplicações distintas ao mesmo tempo. Originou a linha de mainframes da IBM, que posteriormente evoluiu até a Série 370 e atualmente na zSeries. Até hoje, esses sistemas são compatíveis com o sistema operacional IBM 360 de Brooks. O que me faz lembrar de outro atributo de um grande software: tornar-se tradicional. Ficou e está há tanto tempo no mercado, que não pode ser fácilmente substituído.

Reconhecemos sua grandeza

Todos concordam que o IBM 360 foi um dos maiores softwares ja escritos. Sua grandiosidade é facilmente avaliada dadas suas longas perspectivas históricas. Contudo, quanto mais perto ficamos do presente, mais difícil fica classificar os grandes softwares.

Bem, ainda temos torpedos. Com grande inspiração o coloquei em minha lista de grandes softwares ja escritos, partindo da Colossus até o presente. Consultei os gurus James Rumbaugh; Stuard Feldman, o presidente da Associação de Maquinários Computacionais, a investidora Ann Winblad e Gary Morgenthaler; os criadores da linguagem de scripting PHP 3.0, Zeev Suraski e Andi Gutmans; e meu pequeno irmão, Wally. Essa lista todavia, continua bastante pessoal. Os que a considerarem sábia e com escolhas inspiradas, me envie uma mensagem de correio eletrônico no endereço ao final dessa crônica. Aos que considerarem de mal gosto, sem fundamentos ou horrivelmente ignorante, enviem sua mensagem ai Wally, ex estrela profissional de basketball de aproximadamente 2,10 metros de altura.

Sempre fiquei impressionado com a nave espacial Apollo e seu sistema de orientação, criado pelo Laboratório de Instrumentação do MIT. Em 1969 esse software levou a Apollo 11 para a lua, desconectou o módulo lunar, pousou-a na superfície da lua e trouxe três astronautas de volta para casa. Tinha que funcionar na pequena quantidade de memória disponível no computador Raytheon que estava onboard na nave. O software tinha 8 Kbytes, menos que um driver de impressora hoje em dia. E não poderia haver a menor hipótese de reboot em caso de falha no sistema, quando a nave estivesse fazendo a re-entrada em atmosfera terrestre. Felizmente o Windows não estava realizando o serviço.

O sistema de orientação da Apollo hoje pode parecer software de rotina, do ponto de vista da sofisticação tecnológica. Sistemas de navegação muito mais complexos são operados hoje em dia. A essência do sistema era um conjunto de algorítimos conhecidos baseados em lógica comprovada. Mas para mim, ainda é Ciência Espacial. Grandes softwares nos impressionam pela segurança com que desempenham corretamente tarefas que tem tudo para dar errado.

Image

Colossus, o maior software jamais escrito.

Aos que não se impressionam pela relativa simplicidade do sistema espacial da Apollo, pergunto: Você colocaria sua vida sob dependência de um sistema mais complexo? Por exemplo, o Sistema de Automatização BAE, software que supostamente deveria manusear as bagagens no Aeroporto Internacional de Denver, projetado em dois supercomputadores de processamento paralelo. Em sua data de lançamento, outubro de 1993, direcionou tanta bagagem para os aviões errados que a cidade teve que adiar a inauguração do aeroporto em 16 meses. O prejuízo consequente para a cidade foi equivalente a 1.1 milhão de dólares por dia.

Apenas para ilustrar, nossas vidas já estão nas mãos desse tipo de software. A Administração da Aviação Federal nos EUA gastou centenas de milhões de dólares, não apenas uma, mas três vezes tentando construir um sistema efetivo de tráfego aéreo. Jogou fora cerca da metade do que criou, tecnologia avaliada em 144 milhões de dólares, enquanto a outra metade desse montante, a metade que se tornou o sistema em uso, frequentemente falha ou para completamente. Grande software? Dou preferência para o sistema de orientação da Apollo. Para que um software seja considerado um sucesso, o mínimo que se espera é que ele consiga realizar as tarefas à que foi criado.

Certamente tal axioma se aplica ao VisiCalc, o primeiro software de planilha eletrônica. Ele é grande, pois demonstrou o potencial da computação pessoal. O software colocou nas mãos de cada empresa a possibilidade de analisar e manipular enormes quantias de dados matemáticos. Mas o VisiCalc em si, apesar de representar um conceito inovador, não era um grande software. Era falho e limitado, não podia desempenhar muitas das tarefas que os usuários desejavam. A grande implementação da planilha de cálculos não foi VisiCalc, e nem mesmo o Lotus 1-2-3, mas sim o Microsoft Excel, que extendeu o poder das planilhas eletrônicas e dispôs às empresas uma grande variedade de ferramentas de cálculo. A Microsoft afirma que faz software brilhante, sem dúvida é uma afirmação no mínimo contestável, mas a planilha eletrônica Excel veio para ficarl. É unânime para todos que usam profissionalmente esse tipo de ferramenta.

Em Busca de Inteligência

Há muitos exemplos de grandes softwares no campo da inteligência artificial. Cada um ao seu tempo. Al por exemplo, produziria inteligência similar à humana, podendo inclusive conversar conosco, nos ensinar algo que não entendemos e combinar grande poder e racionalidade com comandos e dados sem um limite. Mas afinal, como acabou o Al? Muitos artifícios e inteligência insuficiente.

Redes neurais, conceito criado na pesquisa de desenvolvimento do Al, produziu sistemas de identificação de impressões digitais usados plenamente no mundo todo. É sem dúvida um grande sistema de combinação de padrões, mas isso é inteligência? Minha lógica diz que não.

Image

Deep Blue tinha uma vantagem artificial: o pensamento humano.

A aplicação Al que produziu a primeira inovação foi a máquina de inferência, sistema dotado de base de conhecimento e regras de condições. Esse sistema computacional é capaz de combinar condições que identificam precisamente um paciente com febre antes mesmo dele atingir o grau de calor corporal necessário para ser considerado febre, simplesmente fazendo uso de uma regra, o fato de infecções bacteriais causar grandes febres. Uma das melhores variantes desse software o sistema de diagnóstico médico Mycin, pode corretamente identificar infecções bacteriais em uma pessoa baseado em seus sintomas com precisão de 65%. Pouco? É melhor que a maioria dos profissionais recém graduados na mesma área. Mas esse tipo de software nunca saiu do laboratório e tampouco tornou-se popular. Ninguém poderia identificar o culpado quando seu resultado não fosse preciso.

Meu pacote favorito do Al foi o Deep Blue da IBM, que derrotou o grande campeão Mundial de xadrez Garry Kasparov em um jogo de seis partidas. Kasparov alegou que por trás da parafernália eletrônica haviam humanos. E ele estava certo. Os programadores da IBM estavam furiosamente revisando as decisões do Deep Blue entre cada jogada e ajustando o computador de acordo com o estilo de jogo de Kasparov. Isso retira completamente o Deep Blue da minha lista de candidatos à grande software. As atividades da IBM condisseram com as regras da disputa, mas não deveria ter sido assim. Como Kasparov poderia competir? Readaptando seus circuítos mentais?

Os softwares no estilo Al podem impressionar, mas todos os meus melhores exemplos ficam longe de ser considerados grandiosos.

Eventualmente descrevo meu navegador de Internet como um terminal burro emocionalmente dotado. Meu irmão, Wally, pesquisador literário convenceu-me que o Mosaic foi o primeiro navegador gráfico, “tirou a Web da terra dos técnicos e a colocou no mundo dos humanos comuns”. Um de seus predecessores, o Gopher, é um exemplo de quase sucesso, e depois veio o ViolaWWW, o primeiro navegador com os botões de páginas anteriores e próximas.

Mas a combinação de linha de endereço para a URL, interface de apontar e clicar baseada em mouse, apresentação de arquivos multimídia e hyperlink na janela, significava que os clientes finalmente haviam encontrado uma parceria perfeita para acessar as informações que proliferavam nos servidores da Internet. A combinação de elementos de fácil uso do Mosaic com um conjunto de menus deslocáveis, criaram um formato que mais tarde seria sempre reproduzido pelo Netscape Navigator, pelo Internet Explorer e pelo Firefox (na janela do Explorer experiente clicar no menu Ajuda e depois no Sobre ou About, e você verá os créditos ao Mosaic). Brilhantismo técnico? Não exatamente, mas uma necessidade solene e síntese de novidade técnica. Em outras palavras, um grande software que abriu diversas portas.

O mesmo pode ser dito da própria World Wide Web? Tim Berners-Lee produziu a síntese da linkagem de hypertextos, do localizador de recursos universal (URL), e as páginas HTML impactaram nosso mundo monstruosamente. Mas a Web copiou idéias que já existiam, e todas são dependentes dos protocolos de rede TCP/IP e do servidor de nomes BIND (Berkeley Internet Domain), aquela camada de software próxima do metal que faz por exemplo, roteadores funcionar. Não, a Web não é um grande software, mas certamente é um dos líderes de escala quando consideramos a popularidade de seu impacto.

Satisfação do Usuário

Continuando a análise contemporânea, Google, em ao menos um aspecto, representa um grande software. Os sistemas de busca precediram o Google na forma do Lycos do AltaVista da DEC e outros engines. Mas o Google incorporou um sistema de ranking de páginas estruturadas em seus resultados de busca, associando as milhares de páginas resultantes de uma pesquisa em um sistema hierárquico que representa a frequência de seu uso ou de referências cruzadas em outras páginas. “O valor de um documento acadêmico é medido de acordo com o número de vezes que esse documento é mencionado em outros documentos ou em suas notas de rodapé”. O Google adaptou essa convenção para a Web, segundo Morgenthaler Ventures. Além disso, colocou na mão de milhões de novos usuários uma grande e valiosa ferramenta de informação estruturada. Taí um grande software.

Image

Sabre da American Airlines

Pensei também no Java da Sun, como linguagem derivativa, membro da família C que redefiniu convenções que já existiam. Depois de refletir, concluí que estava errado. Java implementa o conceito de máquina virtual em clientes, permitindo que o código fosse transportado pelas redes e executado no PC de destino sem que este código tenha muitas informações dessa máquina. Java instituiu o uso de byte code intermediário, uma espécie de código fonte previamente compilado, que permite sua tradução para código de máquina assim que chega na plataforma cliente. Isso equaciona portabilidade e performance. Java restringiu o código copiado para uma espécie de sandbox ou um conjunto de limites — o disco rígido do cliente por exemplo, fica estritamente nesses limites. A sandbox em teoria protege os usuários de se expor à problemas de segurança, como os problemas encontrados com sistemas irrestritos como o ActiveX da Microsoft.

Com esses recursos orientados à rede, Java deslizou no mundo dos negócios e na era da Internet. A Microsoft copiou todas as melhores idéias por trás do Java ao criar o Visual Studio .Net. Java se destacou sobre essa cópia, se extendeu e tornou-se mais rico em termos de recursos, e isso certamente é sinal de grandiosidade.

E se pensarmos em software mais focado em usuários finais, como publicação baseada em Desktop? Esse tipo de adoção foi possível com o PostScript da Adobe Systems, que digitalmente pode formatar imagens e textos dentro de um computador ou em uma impressora laser. Adobe simplificou as definições tipográficas profissionais que surgiram nos laboratórios de pesquisa da Xerox em Palo Alto no Vale do Silício, conseguindo uma combinação coerente de simplicidade e poder operacional no formato PostScript. Tornou a publicação baseada em estações de trabalho convencionais totalmente comum. Muito bem feito, mas não o suficiente para ser considerado inovação técnica e chamado de grande software.

Falando na Xerox, o Macintosh da Apple foi baseado no sistema denominado Alto, criado na Xerox. Alto incluiu a primeira interface gráfica baseada em janelas, o primeiro mouse e a primeira interface unificada para o usuário. Mas nunca chegou no mercado. Foi necessário completo redesign do projeto pela Apple para gerar o impacto. Posso ainda me lembrar da primeira vez que sentei na frente de um Macintosh, na vitrine de uma loja de computadores em Endicott, N.Y. Eu tive aquela sensação de “Ciência Espacial”: podia ver o que o sistema fazia, mas não conseguia acreditar no que via. O Mac incorporou o poder da computação orientada a objetos na interface com o usuário, e a maioria dos usuários nunca mais quiseram saber de outra coisa. O primeiro sistema operacional Mac foi um grande software.

É Chegado o Momento das Pestes

Tecnologia que se infiltra em nosso dia-a-dia e modifica completamente nossa vida se qualifica como grande software. De tal forma, meu próximo candidato consegue alcançar esse critério, mesmo sendo um pedaço desprezível de software. Em 1988 a peste Morris (um worm de rede) se proliferou pela Internet, infiltrando-se em servidores de grandes universidades e fechando grandes escritórios de negócios. O estudante de Cornell, Robert Morris, afirma hoje em dia que fez o work para que pudesse mensurar o tamanho da Internet apropriadamente.

Como a maioria dos software, o worm teoricamente poderia rodar em apenas um ou dois ambientes alvo, mas acabou demonstrando algo novo sobre a grande rede de computadores. A peste em questão se espalhou de servidor em servidor explorando uma vulnerabilidade de estouro de pilha no Sendmail. Não podíamos imaginar quantos backdoor ou aberturas defensivas puderam atordoar o Unix, Sendmail, Finger e outros sistemas. A peste contínuamente definia novos servidores como alvo e, aleatoreamente, se replicava. Morris afirma ter adicionado esse recurso para garantir que seu worm pudesse se espalhar. Ele conseguiu.

Como software, esse intruso foi uma inovação, uma demonstração capaz de abrir os olhos dos mais céticos sobre como um software brilhante poderia explorar um lado anti-social até então não conhecido nessa proporção na Internet. Estávamos todos começando a ficar interconectados e dependentes disso. Precisávamos de um puxão de orelha, algo para nos acordar. Parabéns, Senhor Morris. A Grande Peste se provou um incontestável e preciso alarme. Era um grande software.

O sistema Sabre da American Airlines também era grande. Demonstrou como software poderia ser usado além das necessidades táticas de um negócio, mas também como recurso estratégico. Sabre tinha a habilidade de calcular e combinar as necessidades de viajens de um cliente com os vôos disponíveis, em um escritório de um agente de viagens. Sua listagem incluia também vôos dos competidores da compania aérea em questão. O sistema garantiu economia de tempo e dinheiro junto à American Airlines e também seus para seus agentes de viagens. Mas a empresa depois abusou e colocou seus próprios vôos com maior prioridade na tela de resultados das pesquisas. Assim sendo, eram escolhidos com maior frequência, interferindo no mecanismo de busca do Sabre. A empresa chamou isso de “Ciência Informativa”.  O Governo Norte Americano chamou de “Informação Polarizada e Deturpada” e baniu essa prática do mercado.

Sabre foi um exemplo de duas vias: estratégia comercial e abuso comercial. Com o advento da Internet, busca por vôos reapareceriam como o serviço Travelocity e sistemas de busca de propósito geral implementariam pagamento de quotas para apresentar posições privilegiadas como resultados de busca.

Os Três Primeiros

Então como fica meu ranking de candidatos em uma lista de 1-12? Em ordem decrescente, os maiores software já escritos são:

12 – A Peste (Worm) Morris
11 – Sistema de Ranking de Busca do Google
10 – Sistema de  Orientação Espacial da Apollo 11
9 – Planilha Eletrônica Excel
8 – Sistema Operacional Macintosh
7 – Sistema Sabre
6 – Navegador Mosaic
5 – Linguagem Java
4 – Sistema Operacional 360 da IBM

Isso significa que a minha terceira, segunda e primeiríssima escolhas ainda estão faltando.

Então vamos lá:

O número três é o software de sequenciamento genético do Instituto de Pesquisa do Genoma. Não é um sistema cujos resultados são inexatos, e sim “uma guinada de brilhantismo técnico que consegue precisão de 10 em cada 10 sequências analisadas”, comenta Morgenthaler. O sistema de sequenciamento do Instituto ajudou subdividir e propiciar análises sequenciais, acrescido de sua habilidade de recombinar subunidades de análises como parte da análise integral, “acelerou a ciência genética em no mínimo uma década”. Agora temos as ferramentas para traçar padrões da migração humana para a África; o genoma humano relevou com minúcias como a genética se diferencia entre grupos étnicos, exatamente em um momento onde essa informação é solenemente necessária. Ele concede base científica sobre como os humanos podem se olhar mútuamente como irmãos em um momento da história onde vivenciamos o risco de destruirmos uns aos outros. O sistema vem sendo utilizado para realizar diversos sequenciamentos genéticos adicionais, mapeamento da raiz de várias doenças e montagem do quebra-cabeças da hereditáriedade que sempre assolou a Biologia. Pode pela primeira vez ser resolvido. Raras ocasiões aconteceram onde grandes pesquisas e grandes sofwares estiveram tão ligados.

Minha escolha número dois é o System R da IBM, um projeto de pesquisa da IBM no Laboratório Almaden em São Jose, Califórnia, que fez os bancos de dados relacionais ter seu rumo à ascensão. Na década de 70, Edgar Codd considerou a matemática teórica conjunta e concebeu uma maneira de aplicar essa estratégia no armazenamento de dados e obtenção desses dados de volta, usando a teoria dos conjuntos, que mantém elementos relacionados sem armanzená-los em um compartimento identificado. Conjuntos são elementos relacionados que juntos desempenham um papel abstrato. O conjunto de cores azul, branco e vermelho por exemplo, são elementos relacionados que combinados dão origem às cores da bandeira da França, e que portanto dada a essa combinação geram um quarto elemento que pode posteriormente ser combinado à outros. É ainda possível encontrar todos os elementos de um único conjunto de forma improvisada, sabendo seguramente apenas um único elemento identificador desse conjunto.

O System R e todos os que originaram-se desse princípio — DB2, Oracle, Microsoft SQL Server, Sybase, PostgreSQL, MySQL, e tantos outros — terão um impacto que nós apenas começamos a vislumbrar. Bancos de dados relacionais podem armazenar conjuntos de dados sobre clientes, e pesquisar outros conjuntos de dados para traçar o perfil de como um cliente faz compras. Os dados são adicionados na base na proporção com que são conseguidos, e o banco encontra relacionamentos escondidos nessas informações. As bases de dados relacionais e sua linguagem de acesso, a SQL, nos permite fazer algo que a mente humana quase considera impossível: encontrar uma quantia enorme de dados que se relacionam sem precisar saber muito do conteúdo desses dados, quando foi armazenado ou como se relacionava à outras informações. Tudo que é preciso é uma trecho adicional de informação apenas, a chave primária, que nos permite acessar o conjunto dos elementos. Gosto do System R por sua incrível suavidade operacional, sua escalabilidade e sua incrível utilidade para todos que trabalham com dados massivos. É um software com uma rara noção de verdade matemática por trás.

E agora, O Maior Software Já Escrito pelo Homem — Unix

Os Laboratórios Bell frequentemente levam o crédito pela criação do sistema operacional Unix, mas Bell nunca financiou seu desenvolvimento. De fato, a gerência da instituição em questão não sabia nada sobre o assunto. Os Laboratórios Bell como parte da AT&T, tinham desenvolvedores comprometidos em um projeto de multiplos fabricantes, chamado Multics, que fazia uso de muitas idéias novas para um sistema operacional. Mas o projeto sucumbiu, e um desses desenvolvedores da Bell Labs, Ken Thompson, decidiu fazer uma versão pessoal do Multics, de forma que pudesse concluir seus jogos de guerra nas estrelas, diz Feldman (que a propósito, foi o sétimo desenvolvedor do Unix da AT&T, e agora é presidente da Associação de Maquinários Computacionais).

Na melhor das tradições de software, Unix foi um esforço individual que criou vida própria. Thompson projetou o Unix diante da rejeição dos Laboratórios Bell em dar continuidade ao projeto em uma estação PDP7 da DEC com 16 ou 32 Kbytes de memória — Feldman não se lembra ao certo da capacidade de memória. “Unix foi escrito sob grandes limitações”, comenta Feldman. “Não havia memória nem poder de processamento. Você se envergonharia hoje, se seu relógio de pulso por exemplo, não tivesse mais memória ou CPU do que o Unix dispunha naquele tempo”.

Thompson projetou seu pequeno sistema operacional de forma a mover dados em blocos ou em páginas, de um sistema de acesso aleatório de memória para um sistema de armazenamento secundário em disco, liberando mais espaço em memória principal. Quando essa memória fosse necessária novamente, o sistema operacional saberia acessar esses dados no disco e carregar de volta em memória aleatória. Desta forma, um grande sistema operacional pode rodar em um pequeno computador com pouca memória. Seu sistema operacional era ainda multiusuário. Até os mainframes daquela época eram limitados a usuários únicos, tornando o tempo computacional relativamente caro. O Sistema Operacional de Informações Uniplexadas (Unics) de Thompson, permitiria que duas pessoas utilizassem o computador ao mesmo tempo.

O Grupo de Pesquisas de Ciências Computacionais dos Laboratórios Bell, ficaram sabendo do Unics e quiseram uma cópia. Sob requisição do grupo, Thompson e seu parceiro Dennis Ritchie concordaram em adicionar um sistema de formatação de texto no ambiente operacional, com tanto que uma máquina maior, PDP 11/20 fosse fornecida. Então, o processamento de texto em Unix nasceu. Unics tornou-se Unix, foi reescrito em um sistema mais poderoso, mais portável, em código de alto nível – em linguagem C – e foi anunciado mercadológicamente como o Unix System III da AT&T.

Então o Unix System III foi o maior software já criado — ou quase? Acompanhem comigo.

Uma Filosofia GNU

System III representou um avanço, mas esqueceu de muitas coisas como interface mais amigável com o usuário e um método de tratar sistemas distribuídos. Em uma tentativa de expandir a adoção do Unix, a AT&T o tornou disponível para instituições acadêmicas e de pesquisa sob uma pequena taxa. Algumas pessoas pensam que o Open Source apareceu quando os códigos tornaram-se livremente disponíveis pela Internet. Estão errados. De fato, o Código Aberto tem suas raizes na primeira distribuição do Unix. Uma dessas distribuições originou-se do trabalho noturno para melhorar o Unix na Universidade da Califórnia em Berkeley. Uma série de outros pesquisadores ouviram falar dessas melhorias, e pediram à pessoas como Bill Joy uma cópia desse Unix de Berkeley. Assim sendo, o primeiro código aberto não era um arquivo digital. Foi de fato, um rolo de fita magnética que Joy colocou no correio em uma dessas noites após terminar seu dia de trabalho, de acordo com Eric Allman, graduando da Universidade da Califórnia em Berkeley, criador do Sendmail, que estudou com Bill Joy. Em 1977, uma coleção das adições e melhorias de Joy e diversos outros alunos de graduação foi disposta em conjunto, e tornou-se conhecida como a Berkeley Software Distribution of the Unix Operating System, ou apenas a Distribuição de Software Unix de Berkeley — o BSD.

Unix foi projetado como módulos discretos de código, cada qual relacionado a um trecho específico do equipamento. Isso o tornava mais simples de ser analisado do que os sistemas operacionais da IBM. Os estudantes de Berkeley fizeram rápidas mudanças. Adicionaram um sistema de arquivos mais limpo e rápido e um subsistema de redes confiável, além do poderoso editor de textos e de códigos, o vi. Adicionaram a API de sockets de Berkeley, tornando a transmissão de dados para um destino remoto na rede tão simples quanto para um disco local.

O Departamento de Defesa e Pesquisa Norte Americano havia contratado a consultoria Bolt Beranek & Newman para implementar um protocolo de rede para o governo. No BSD 4.1, os estudantes de Berkeley revisaram os conceitos por trás desse protocolo, modificaram e o aprimoraram, criando uma versão apropriada para atender suas próprias demandas. Em 1986, no BSD versão 4.3, o DARPA (Departamento de Defesa) testou esse protocolo, o TCP/IP, e decidiram adotá-lo ao invés da versão projetada por BBN.

Bill Joy saiu da Universidade de Berkeley em 1982 para co-fundar a Sun Microsystems, usando Berkeley Software Distribution como base para o SunOS e Solaris. Sun e AT&T colaboraram mutuamente na melhoria do System V, produzindo o consolidado o Unix System V Release 4. Concordaram que esse seria o Unix padrão para o futuro. A AT&T, objetivando o retorno de seus investimentos no Unix, aumentou as taxas cobradas pelo software.

Mas os estudantes de Berkeley não sairiam dos trilhos. Reescreveram o BSD Unix, livrando-o dos arquivos originais do Unix da AT&T e criando uma nova variante do sistema que poderia rodar em sistemas de baixo custo — os computadores pessoais. Com mais uma versão do Unix, AT&T considerou que o impacto em seus lucros poderia ser comprometido, e sua nova subsidiária, a USL – Unix System Laboratories – processou a BSDI, empresa que distribuia uma versão do Unix de Berkeley destinada a computadores pessoais de linhagem Intel. A USL manteve tal processo por anos, atrasando a evolução do BSD Unix em ambiente computacional de linhagem Intel.

Enquanto isso, as altas taxas cobradas pela licença do Unix da AT&T ofendiam Richard Stallman, aluno de graduação que utilizava o sistema no laboratório de inteligência artificial do MIT. Software, decidiu Stallman, deveria ser considerado recurso intelectual e ser livre, como o trabalho publicado de seus companheiros pesquisadores. Ele decidiu criar um conjunto de ferramentas com objetivo de substituir as ferramentas existentes no Unix, e que também fossem usadas por programadores para dar origem a outras ferramentas igualmente livres, e chamou-as de GNU.

Essas ferramentas chegaram a Linus Torvalds, um estudante de 21 anos em uma universidade em Helsinki na Finlândia, exatamente quando este estava considerando uma versão do Unix que pudesse ser rodado em seu computador pessoal. Estas ferramentas foram decisivas na criação de um kernel de sistema operacional, que batizou com o nome Linux. O resto da história é conhecida. Linux tornou-se tão popular que ofuscou a Distribuição do Software de Berkeley em computadores pessoais. Hoje, Linux se esforça para assumir também a posição de mercado final. Mas Linux é meramente um clone de um sistema GNU incompleto e de seus predecessores BSD. BSD gerou todos os conceitos chave implementados no Linux; exatamente por isso todos os principais pilares da Internet como BIND, Sendmail e o TCP/IP foram desenvolvidos sob o Unix de Berkeley, e não no System V. É por isso que a Microsoft, ao precisar de uma implementação melhor do TCP/IP para Windows, utilizou a implementação BSD Unix. Quando a DARPA quis construir a rede ARPANET – hoje a Internet – em 1983, descartou seu protocolo existente e confiou o serviço no TCP/IP do BSD Unix.

Então ai está: O Maior Software de Todos os Tempos, com o mais amplo impacto no mundo todo foi o BSD 4.3. Outros Unix tornaram-se sucesso comercial mais bem sucedido, mas as conquistas cumulativas conseguidas nos sistemas BSD, especialmente versão 4.3 representaram picos incomparáveis de inovação. BSD 4.3 representa sozinho a maior revolução da Internet. Mais que isso, a paixão que envolve o Linux e código aberto é apenas uma ramificação direta dos ideais criados no BSD: amor pelo poder computacional e a crença que isto deve ser uma extensão do poder intelectual humano, disponível sob todos os preceitos de liberdade — poder de intelecto este que coloca o homem em seu devido lugar no universo.

TEXTO ENCONTRADO EM:

http://www.fug.com.br/content/view/138/77/