Em sua apresentação, ele mostrou algumas técnicas para desacoplar o modelo de domínio da infra-estrutura da aplicação e ainda sim continuar usando recursos de frameworks em .NET.

A idéia é sempre deixar o domínio intacto, somente com o código do coração do software. Se você utilizar as famosas ferramentas de “arrastar e soltar”, vai poluir as entidades do domínio com código de infra-estrutura.

Quando falou a respeito do ADO.NET Entity Framework, o novo framework de mapeamento objeto-relacional da Microsoft, Tim se expressou indignado: “Oh, my God!”. Segundo ele, arrastar e soltar tabela por tabela do seu banco de dados, deixando o Visual Studio gerar um monte de código para você é algo não muito bom para se fazer.

Essas ferramentas de geração de código podem ser uma armadilha para desenvolvedores inexperientes. Para sistemas pequenos, sem grandes pretensões, isso pode ser uma solução rápida e que atende sua necessidade. Mas para grandes aplicações é preciso se concentrar no domínio e eliminar qualquer código que polua suas entidades de negócio.

Não é uma boa idéia criar um modelo de domínio fazendo a relação de uma entidade por tabela no banco de dados. As tabelas do banco de dados pertencem à infra-estrutura do sistema. O seu modelo de domínio deve ser rico e refletir seu negócio, o mais próximo da realidade possível. A partir do seu modelo de domínio é que você constrói uma infra-estrutura de persistência de dados.

A apresentação de Tim McCarthy foi repleta de exemplos reais (e rodando) de código. Num deles, mostrou uma classe de entidade do domínio onde havia uma referência using para o namespace Microsoft.SharePoint. Esse foi um tipico exemplo de entidade de negócio poluída.

Também tivemos um exemplo de utilização de repositórios (Repository), que segundo Tim, são um tipo de abstração da persistência, comparando-os como um tipo de coleção de dados, onde é possível listar, inserir, alterar e remover seus itens. Ele enfatizou que o classes do modelo de domínio podem usar repositórios, mas elas devem estar ligadas somente às interfaces dos repositórios, não acopladas às suas implementações.

Outra parte “prática” da apresentação foi a utilização de injeção de dependência (Dependency Injection) de repositórios nas classes de serviço e alteração do tipo de persistência via arquivo de configuração.

Tim também mostrou a implementação de uma unidade de trabalho (Unit of Work), onde a mesma não conversava diretamente com a base de dados.

A apresentação excedeu 10 minutos do tempo previsto, pois tinha muito código interessante a ser mostrado. Isso só acabou instigando a dar uma olhada no seu livro, que vem com o código fonte de todos os passos de construção de uma aplicação em .NET aplicando os padrões de DDD.

Só não esqueça que todo esse código somente vai poder lhe ajudar se você definir bem seu modelo de domínio, consistente e conciso com a realidade do seu negócio.
.

• Yehuda Katz - da Engine Yard, Mantenedor do Merb, nos explica sobre o novo framework Web Merb, a biblioteca de ORM DataMapper e as recentes discussões sobre frameworks Web em Ruby.
• Jan Lehnard e Chris Anderson - Core Committers do CouchDB, nos levam numa extensa jornada sobre o banco de dados orientado a documentos, CouchDB. Do que se trata, quais as principais características e onde ele se encaixa nesse novo cenário de bancos de dados não-relacionais.
• Nick Sieger - da Sun, Core Committer do JRuby, nos fala mais sobre o desenvolvimento do projeto JRuby, sobre como ele já é estável, rápido e compatível com o Ruby MRI (o oficial). Fala também sobre sua adição de Connection Pools no novo Rails 2.2.
• Francesco Cesarini - da Erlang Training and Consulting, com seus 15 anos de experiência com a linguagem Erlang, nos explica porque essa linguagem é tão poderosa e como a boa e velha programação funcional acidentalmente resolve os problemas modernos de computação paralela, concorrência e escalabilidade massiva.
• John Straw - da YellowPages.com, nos conta como sua equipe substituiu um antigo projeto legado Java de 150 mil linhas de código, por um sistema altamente escalável de apenas 13 mil linhas de código Ruby on Rails, onde metade são testes automatizados.
• Matt Aimonetti - Core Commiter e principal Evangelizador do projeto Merb, nos explica quais as diferenças com Ruby on Rails, em que cenários ele leva vantagem, suas principais características e aplicações.
• Ola Bini - da ThoughtWorks, num especial de quase 2 horas de duração, detalha diferentes estilos de programação que são ignorados pelo mercado de programação mas que agora voltam a ser altamente relevantes. Lambdas, High Order Functions, Prototypes, Condition System, Side-Effects, Message Passing e muito mais.

Dentre alguns dos keynotes do evento, tanto Kent Beck quanto Tim Bray discutiram sobre tendências. Foi muito interessante notar que ambos estão ohando para CouchDB com muito interesse. O fato de haver várias palestras sobre Ruby, Erlang e assuntos relacionados também me deixou muito interessado. Além disso, claro, tivemos grandes nomes como Martin Fowler, Eric Evans, Ralph Johnson falando sobre Agile, Domain Driven Design e outros assuntos relacionados ao mundo Ágil.

Todos que estão envolvidos no mundo de tecnologia - e realmente gostam de tecnologia - provavelmente já devem estar adorando a idéia de que finalmente programação funcional talvez encontre seu nicho num mercado maior, o de alta escalabilidade. Para isso linguagens como Erlang provavelmente serão mais usadas.

Aos não iniciados, vamos recapitular: o mercado ‘atual’ fala muito de Java, C#, PHP. A maioria das faculdades prepara as pessoas apenas para essas plataformas, paradigma Imperativo e Declarativo, derivados da era Fortran. Isso é pouco.

Se ainda não perceberam, chegamos ao fim da era do Gigahert, onde para um programa rodar mais rápido bastava esperar no ano que vem surgir um processador com mais Gigahertz. O mundo agora é de processamento paralelo. Qualquer notebook hoje já vem equipado com dois Cores.

Nesse sentido, programação monolítica é um problema grave. Programação com threads também não ajuda em nada e é recomendado somente se tudo que poderia ser feito antes já foi feito. Thread é algo tão ruim quanto os antigos GOTOs. O problema: estado compartilhado de memória. A solução: programação livre de efeitos colaterais.

Por acaso é exatamente isso que uma outra linhagem de linguagens vêm fazendo há décadas: as Linguagens Funcionais, derivadas de Lisp. Erlang é uma linguagem dessa categoria, criada pela Ericsson há 20 anos para criar sistemas de telecomunicação de altíssima-disponibilidade.

Linguagens orientadas a objeto como C# já flertaram com parte dessa idéia com construções como LINQ, que está na última versão do C#.

Erlang, por sua vez, foi usado para criar dois dos bancos de dados que estão para mudar o ambiente Relacional: o Amazon SimpleDB e o Apache CouchDB, o primeiro comercial e o segundo open source, ambos são bancos de dados não-relacionais, orientados a Documentos.

Esqueçam Joins, esqueçam chaves estrangeiras, triggers, stored procedures. Num mundo Web de crescimento massivo, esse tipo de recurso simplesmente não escala. Para ter uma idéia, existe hoje um projeto chamado Drizzle, que é uma versão do MySQL sendo modificado para não ter nenhum dos recursos que mencionei aqui. Sites enormes, como Facebook e Digg, simplesmente não usam mais esses recursos. Em cenários onde alta escalabilidade é um objetivo, a solução é escapar das limitações do mundo relacional e o CouchDB é um maiores proponentes a isso.

Finalmente, está claro que a filosofia Ágil já se provou com a única forma de desenvolver software de maneira sustentável, com qualidade e sucesso. Ainda há muito a se aprender, muitas pessoas e empresas ainda não entenderam como estão jogando dinheiro fora com metodologias tradicionais, mas num mundo em crise financeira, onde cada dólar gasto precisa ter valor, é uma boa hora para pensar de maneira séria em desenvolver software da maneira correta: com metodologias (e, principalmente, filosofia) Ágil e tecnologia Open Source.

O que eu vi na QCon está muito claro: a tendência é que os melhores programadores do mercado serão efetivamente os que dominarem não somente as tecnologias tradicionais (linguagens imperativas, bancos relacionais) mas também as que vão efetivamente solucionar os problemas de escalabilidade (linguagens funcionais, bancos não-relacionais) e, mais do que isso, as empresas de sucesso serão somente as que realmente entenderem a maneira Ágil de se pensar em software.

A idéia fundamental aqui é que com TDD você quer testar behaviour (comportamento) e constraint (restrição). Imagine um método que não pode receber argumentos nulos. Tipicamente você colocaria um bloco if e caso o argumento fosse nulo você lançaria algo como uma ArgumentNullException, mas antes deveria ter criado um teste para o caso do seu método receber o argumento nulo.

Agora imagine que você tenha, através da linguagem, um modo de estabelecer os contratos dos métodos. Neste caso você poderia escrever algo assim:

void SomeMethod(object someArgument)
    requires someArgument != null;
{
    // …
}

Esta palavra-chave requires é uma pré-condição (ou um guard). Ele estabelece um contrato que diz que o método SomeMethod não pode ser chamado caso o argumento someArgument seja nulo. Há vários outros tipos de contrato como invariantes e pós-condições, mas o importante de se entender aqui é que se o compilador for inteligente o suficiente para interpretar esta informação adicional, ele será capaz de fazer uma análise estática e determinar se o método SomeMethod é inválido ou pode ser inválido por causa do argumento que está recebendo de quem o está chamando.

Isto é especialmente poderoso, pois introduziria a “luz amarela” no seu ciclo de desenvolvimento TDD e eliminaria vários testes que com DbC são redundantes. Como se fala no mundo ágil que você deveria apenas testar o que possui business value, essas condições de contorno não precisariam ser testadas, pois seriam cobertas pelo DbC (a menos que as condições de contorno possuam, excepcionalmente, algum business value).

Ao longo de uma hora ele passou por diversos temas relacionados ao estado do HTTP hoje. Começou comentando sobre o grupo de trabalho Hypertext Transfer Protocol Bis, que visa revisar a RFC 2616 (que especifica o HTTP 1.1) para torná-la mais clara, evitando problemas de interpretação que costumam ocorrer em implementações. Deixou claro que o grupo não deve adicionar nada à especificação, apenas organizá-la melhor. O protocolo foi separado em sete partes, e cada uma delas possui um documento próprio, ainda em draft: URIs, Connections, and Message Parsing, Message Semantics, Message Payload and Content Negotiation, Conditional Requests, Range Requests and Partial Responses, Caching e Authentication. Em teoria os trabalhos acabam em seis meses.

Depois disso, Mark Nottingham falou sobre o estado atual e perspectivas de vários tópicos, como o estado de implementação atual de clientes, servidores e intermediários, e especificações e implementações relacionadas a URIs, headers, caching, etc.

Ainda falou sobre o draft para a especificação de PATCH, um novo método a ser adicionado no HTTP 1.1. Por sinal, com o uso cada vez mais disseminado de arquiteturas orientadas a recursos, esse método faz cada vez mais sentido, e foi comentado mais duas vezes na track de REST do evento. A questão é que um PUT implica em mandar todas as informações sobre o recurso novamente para o servidor, o que muitas vezes é pouco prático e ineficiente.

Ao final, fez alguns comentários sobre o que chamou de O2.0, que são os padrões abertos de segurança que surgiram nos últimos tempos, como OpenID e OAuth. A crítica que fez a eles foi a de que costumam se alinhar com o mínimo denominador comum de tecnologias existentes e que costumam simplificar excessivamente algumas questões de arquitetura, como ignorar a existência de intermediários, por exemplo.

Joseph Yoder, em sua apresentação “Software Patterns and Quality: Can Patterns Help Quality?” na QCon San Francisco 2008, distinguiu a qualidade de software em:

• Qualidade interna
• Qualidade externa

Com as seguintes perspectivas:

• Do desenvolvedor
• Do usuário final
• Do gerente (manager)
• Do CEO

Por exemplo, o valor da qualidade de um software para um usuário final (qualidade externa) é totalmente diferente da visão de qualidade do desenvolvedor (qualidade interna). A qualidade do código ou do design do software não faz sentindo para o usuário, se o software não atende suas expectativas ou suas necessidades.

Na grande maioria dos casos, o usuário final quer saber se o software funciona, não se foi feito utilizando as melhores práticas de desenvolvimento ou com um determinado tipo de arquitetura. Em muitas situações, o próprio CEO tem essa concepção de valor de qualidade do usuário final.

A qualidade interna nem sempre é alcançada facilmente. Pode haver dificuldades como algum custo adicional, prazo de entrega, investimentos na equipe, etc. Em cima dessas dificuldades, muitos pensam em qualidade de software de maneira quantitativa, tentando achar números para os tipos de qualidade: por exemplo, o quanto esse software é expansível, o quanto esse código e fácil de dar manutenção ou quão seguro é esse sistema.

Yoder usou o termo QWAN (Quality without a name), de Christopher Alexander para essas qualidades internas, as quais realmente não podem ser quantificadas. Os padrões de projeto (design patterns) ajudam a aumentar a qualidade interna do software, exatamente em cima das QWANs. Identificando o problema ou situação onde há necessidade de aumento de qualidade, escolhendo e aplicando o padrão adequado, a qualidade interna do software é afetada.

Algo que foi enfatizado na apresentação é a questão da definição dos padrões de projeto. Uma boa idéia de solução de um determinado problema de software não é um padrão. Essa idéia pode se tornar um padrão, depois de aplicada várias vezes. Os padrões vão de encontro com a experiência de utilização de soluções para problemas que se tornam comuns entre aplicações.

Padrões de projetos aplicados a uma determinada qualidade podem algumas vezes beneficiar outras qualidades do software. Um exemplo interessante mostrado foi a necessidade de aumentar a segurança em um sistema. Aplicando um padrão de segurança para essa necessidade, houve também um aumento de performance no sistema.

Existe uma série de padrões de projetos que vão muito além dos clássicos GoF. Em geral, todos os padrões de projeto no final das contas acabam se referindo ao aumento de qualidade de software. O livro Implementation Patterns de Kent Beck fala exatamente sobre padrões para criar código de qualidade.

Por outro lado, querer aumentar demais a qualidade, procurando a fórmula do código perfeito, pode gerar problemas. A perfeição no desenvolvimento do software acaba sendo inimiga da qualidade e, de fato é, inimiga da flexibilidade.

Em algumas situações é necessário usar a qualidade de “o bom o suficiente”, onde o software alcança os requisitos mínimos e atende as expectativas.

O que serve de lição é:
- Conheça sua necessidade de aumento de qualidade
- Estude os padrões
- Identifique os padrões que se adequam à situação em questão
- Aplique os padrões de forma concisa

Ah, e continue tendo boas idéias para aumentar a qualidade de seu código, mesmo que elas nunca se tornem padrão de projeto algum dia.

Logo no início deixou claro que a apresentação tratava do entendimento que ele têm sobre seu próprio processo de design. A idéia por trás de tudo é garantir um fluxo constante de implementação de funcionalidades, ou seja, adicionar uma funcionalidade após a outra sempre no mesmo ritmo. Para isso ser possível deve-se investir constantemente no design, de outra forma o que pode acontece é haver a necessidade de se parar de tempos em tempos para “ajeitar” o design para que ele possa suportar as próximas funcionalidades.

Depois disso, deu uma definição muito precisa para design: design são elementos relacionados beneficamente. Olhando por esse ponto de vista, design é livre de escala e não há diferença entre arquitetura e design, o que convencionou-se chamar de arquitetura é apenas design em um nível mais alto.

A partir daí falou sobre as coisas que compõem seu processo de design: valores, padrões, princípios, estratégias e refactoring, comentando mais sobre os três últimos.

Com relação a princípios, Kent Beck diferenciou os princípios universais dos específicos. Os primeiros são aqueles que se aplicam a qualquer software, como o DRY (”don’t repeat yourself”), por exemplo, enquanto os outros fazem parte da especificação de um software em particular (como “o sistema nunca deve deixar de escrever uma informação no banco de dados, mesmo em caso de falha”).

A parte mais tangível da apresentação foram as quatro estatégias para se evoluir o design:

- Leap: Sequência de pequenos passos na direção desejada. É importante que sejam pequenos para garantir que caso o código quebre no meio do caminho seja possível se voltar atrás. O tamanho dos passos depende de vários fatores - ferramentas, risco, experiência do programador, etc.

- Parallel: Manter dois designs diferentes que realizam a mesma coisa durante um certo período de tempo. Depois que o segundo design está estabelecido, pode-se começar a mover os clientes do design anterior para o novo.

- Stepping Stone: Quando o passo a ser dado para entender o problema é muito grande, adiciona-se uma etapa intermediária que ajude a chegar mais perto do destino final. Frameworks e APIs são exemplos dessa categoria. A diferença fundamental entre Leap e Stepping Stone é que o primeiro é o objetivo final, enquanto o segundo é o meio para se chegar ao objetivo.

- Simplification: Inserir ou retirar restrições no design para torná-lo mais fácil de ser trabalhado.

Por último falou sobre refactoring e de como vê o conceito ligeiramente diferente da forma como Martin Fowler o apresentou. Para ele todo refactoring é bi-direcional: se é possível criar um método novo a partir de um código existente, deve ser possível também subtituir as chamadas a um método pela sua implementação, por exemplo. Também comentou que achava que refactorings deveriam ser cidadãos de primeira classe nas linguagens, e não apenas modificações em arquivos texto, podendo inclusive ser incluídos com o código no controle de versão.

Para finalizar a apresentação Kent Beck reforçou que o princípio básico por trás disso tudo é garantir um fluxo constante de implementação de funcionalidades.

O problema seguinte é: qual sistema de versionamento? A maioria dos desenvolvedores hoje está acostumado com CVS, Subversion ou mesmo Microsoft SourceSafe. Eles ajudam, com certeza, mas felizmente hoje sabemos que é possível fazer muito melhor, na realidade, ordens de grandeza melhor.

Linus Torvalds, o pai da kernel Linux, tinha esse problema: como controlar as colaborações de código vindas de centenas de programadores ao redor do mundo? No começo o controle era essencialmente manual, com pedaços de código sendo inseridos e testados manualmente. É um sistema altamente trabalhoso e que com o tempo tende a ser impossível. Logo no começo ele decidiu que não usaria nem CVS, nem Subversion. Resolveu optar por BitKeeper, um sistema essencialmente diferente por ser DISTRIBUÍDO. Essa é a palavra-chave. Mas nem ele era perfeito (além de ser comercial, o que irritou muitos da comunidade). Por isso, Linus olhou novamente o mercado e, na opinião dele, não havia nenhuma opção aceitável, portanto ele mesmo resolveu desenvolver seu próprio sistema de versionamento distribuído, de onde nasceu o GIT.

Não perca nosso WebCast no dia 7 de novembro, onde pretendo dar um resumo sobre as funcionalidades do GIT.

Futuro: Sistemas Distribuídos

Sistemas de Versionamento Distribuídos (DVCS) sao muito diferentes de Sistemas Centralizados. Num fluxo de trabalho normal centralizado, cada desenvolvedor tem em sua máquina apenas a última revisão do projeto. Todo o resto, o histórico, fica armazenado num servidor central. Qualquer operação de atualização precisa necessariamente ocorrer via rede, portanto você só pode trabalhar se estiver conectado na sua rede local da empresa ou via internet. Ninguém pode gravar nada no servidor sem autorização, o que torna a colaboração em projetos open source muito mais complicada.

Com Sistemas Distribuídos, cada desenvolvedor tem em sua máquina local um clone completo do repositório original. No caso do Git, o repositório é extremamente otimizado. Por exemplo, a última revisão de código do Ruby on Rails tem cerca de 25Mb, já o repositório com todo o código, atualizações e modificações feita desde 2004, consome pouco mais de 20Mb.

Mais do que isso, como o repositório está todo local, o desenvolvedor não tem nenhum problema de permissão de escrita: está tudo local na máquina dele. Isso dá outra possibilidade: trabalhar totalmente offline, sem rede nem internet.

Como cada desenvolvedor tem o repositório inteiro em sua máquina, o que se chamaria de “servidor central” é apenas um dos clones que é elegido como “principal”, mas qualquer um pode preencher esse papel. Se eventualmente o “servidor” sofrer uma perda irreversível, não há problema: a natureza distribuída garante que qualquer um dos repositórios clonados possa ser eleita como “principal” e o fluxo nunca é quebrado.

Sobre colaboração, é inclusive possível que sub-equipes se formem para trabalhar numa determinada parte do projeto e só quando estiver pronto, mesclar as novidades com o repositório “principal”, de onde todos os outros podem puxar as atualizações. Isso flexibiliza muito a organização do trabalho.

No Git, trabalhar com “branches” é algo trivial e corriqueiro, sendo inclusive motivado. Isso facilita que os desenvolvedores trabalhem em partes diferentes do projeto, ao mesmo tempo. O desenvolvedor tem muito mais flexibilidade para organizar seu próprio trabalho.

Tudo isso se traduz em maior produtividade, maior segurança - já que não existe ponto único de falha, e uma consequência para equipes ágeis é também mais possibilidades de código de mais qualidade.

Aliás, é exatamente por ser descentralizada que a Internet pode existir: se fosse centralizada ela jamais escalaria até este ponto. Redes descentralizadas como a Internet são resistentes a falhas aleatórias e podem aumentar quase infinitamente.

Usando Git

Aprenda um pouco mais sobre Git no blog AkitaOnRails.

Os planos de Hospedagem Compartilhada Linux da Locaweb suportam GIT faz meses. Diferente de Subversion ou CVS, não é necessário instalar servidores à parte ou configurar nada extra, sequer um ambiente web. Tudo pode ser resolvido via SSH.

Para começar, vou assumir que você está usando Linux, Mac ou um ambiente Unix. Vamos criar uma chave SSH e exportá-la para sua conta. Se estiver no Windows, siga estas instruções.

ssh-keygen -t rsa

Esse comando perguntará sobre senha, passphrase, apenas dê Enter para deixar tudo vazio. Isso criará os arquivos ~/.ssh/id_rsa e ~/.ssh/id_rsa.pub

Agora precisamos transferir esse arquivo ao servidor:

scp ~/.ssh/id_rsa.pub seu_login@seu_servidor:~/.ssh/authorized_keys

Pronto, com isso você não precisa mais digitar a senha para fazer login na sua conta via SSH. Toda vez que estiver na sua máquina, o SSH usará o par de chaves criado para fazer a autenticação. Proteja bem sua chave privada em ~/.ssh/id_rsa.

Para criar um novo repositório GIT, faça o seguinte:

ssh seu_login@seu_servidor
mkdir -p repo/meu_projeto
cd repo/meu_projeto
git init

Digite ‘exit’ para voltar à sua máquina local. Agora crie um repositório local de GIT. Para isso escolha o projeto que quer versionar ou apenas crie um novo projeto, como no exemplo:

rails meu_projeto
cd meu_projeto
git init
git add .
git commit -a -m “Initial Commit”

Agora é só ligar as duas pontas. A partir do diretório do seu projeto, na máquina local, faça o seguinte:

git remote add origin ssh://seu_login@seu_servidor:repo/meu_projeto
git push origin master

Pronto. Agora seu servidor está com todo o seu código. Você pode usar “git push” toda vez que quiser atualizar o servidor.

Se quiser que outro usuário, em outra máquina, use seu repositório. Crie um novo par de chaves SSH como mostrado acima. Daí faça o seguinte:

scp ~/.ssh/id_rsa.pub seu_login@seu_servidor:~/.ssh
ssh seu_login@seu_servidor
cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys

Pronto, isso adicionará uma nova chave à sua conta e permitirá o outro usuário de acessar seu repositório. Para que ele possa começar a colaborar, ele pode fazer, da máquina dele:

git clone ssh://seu_login@seu_servidor:repo/meu_projeto

Isso criará um clone na máquina local dele. Como expliquei, será um clone completo, com todo o histórico desde o primeiro commit feito por você. Ele pode contribuir usando “git push” e ambos podem pegar as atualizações que o outro fez no servidor usando o comando “git pull”.

Usando Branches

O modelo que expliquei acima é apenas uma das formas de colaboração. Novamente, veja este link, para mais detalhes.

A partir do seu projeto, na máquina local, você pode usar o comando “git branch”. Ele mostrará algo assim:

>> git branch
* master

Ou seja, por padrão, o GIT sempre usa Branches e o primeiro branch criado automaticamente é o master. Inclusive é onde as atualizações vindas do seu repositório remoto vão residir. É uma boa prática sempre fazer seu desenvolvimento em outra branch separada, desta forma:

git checkout -b novo_branch

Feito isso você pode desenvolver normalmente no “novo_branch”. Toda vez que quiser puxar atualizações do servidor faça isto:

git checkout master
git pull
git checkout novo_branch
git rebase master

Isso fará o seguinte:

1. voltará o branch “master”
2. puxará as modificações que foram feitas no repositório remoto para dentro de “master”
3. muda de volta ao branch “novo_branch”
4. mescla as mudanças vindas do servidor no “novo_branch”

É possível que, de tempos em tempos, você tenha conflitos (dois desenvolvedores mexeram no mesmo arquivo, exatamente na mesma linha). Nesse caso o comando “git rebase master” acima vai falhar e dizer qual arquivo é o ofensor. Nesse caso você deve abrir esse arquivo e resolver o conflito manualmente, e feito isso faça o seguinte:

git add arquivo_corrigido
git rebase –continue

Daí o Git continuará o resto das mesclagens. Se ainda assim aparecer outra mensagem de erro sobre o mesmo arquivo, apenas faça “git rebase –skip”. O Git não faz mesclagens usando apenas as últimas revisões dos códigos: ele sabe usar a genealogia do conteúdo do arquivo. Por isso sua heurística de mesclagem é muito mais inteligente.

Toda vez que quiser gravar no seu repositório local alguma modificação para que não se perca, faça commit:

git commit -a -m “descricao deste commit”

Ao contrário do Subversion ou CVS, “commit” não manda nada ao servidor remoto, isso é tarefa do comando “git push”. O commit apenas empacota e grava as últimas modificações de código. É recomendado que se faça isso com bastante frequência para que você nunca perca nada e ainda possa mudar de idéia e voltar commits. Por exemplo, se quiser apagar os últimos 2 commits, por exemplo, faça assim:

git reset –soft HEAD^2

Isso irá desfazer os últimos 2 commits e suas modificações ainda estarão no lugar, daí você pode alterar o que precisar e fazer um novo commit.

Daí, digamos que você terminou o que estava desenvolvendo no “novo_branch”, e quer enviar tudo para o servidor. Sempre faça o processo de rebase como mostrado acima, para garantir que seu “novo_branch” está sincronizado com as últimas atualizações do servidor. Daí faça:

git checkout master
git merge master
git push
git branch -d novo_branch

Esses comandos farão o seguinte:

1. Volta ao branch “master”
2. Mescla todas as mudanças do branch “novo_branch” para o master
3. Envia os commits mesclados ao servidor
4. Apaga o branch “novo_branch”

Na realidade existe um processo ainda melhor:

git checkout master
git merge novo_branch –squash
git commit -a -m “descricao da nova funcionalidade”
git push
git branch -d novo_branch

A diferença é a opção “–squash”. Digamos que no “novo_branch” você tinha 50 commits. Mas você não quer que apareça 50 commits no servidor. Faz mais sentido que o que você fez no “novo_branch” suba como um único commit que engloba uma nova funcionalidade, uma correção de bug ou uma nova documentação, por exemplo, então você pode “esmagar” os 50 commits em apenas 1 para manter tudo limpo e organizado no repositório remoto central.

Feito isso, os outros desenvolvedores com acesso ao repositório central podem fazer “git pull” e receberão suas modificações.

Como podem ver, o Git oferece muitas ferramentas e opções. Aqui acabei de mostrar o topo do iceberg, muito mais pode ser feito. O repositório do Git é muito robusto (ainda nunca ouvi falar de repositórios git corrompidos), muito rápido (roda local e as ferramentas de linha de comando são feitas em C, pelo próprio Linus) e garante a produtividade que você precisa num ambiente ágil.

Instale o Git na sua máquina local (usuários Windows, instalem o msysGit) e aproveitem desde já o suporte a Git que a Locaweb já lhe fornece em suas contas Linux compartilhada. Outro detalhe: não, o Git ainda não tem nenhuma ferramenta visual competente. Por outro lado, o poder do Git só é liberado se o desenvolvedor tiver o conhecimento dos processos explicados acima. Escondê-los não ajudará em nada. Se seu desenvolvedor não conseguir aprender como usar o Git, o problema talvez seja reavaliar as capacidades desse desenvolvedor.

O uso do Git cresceu exponencialmente nos últimos meses. O website GitHub concentra a maioria dos projetos open source em repositórios Git. Ele nasceu há 1 ano e, começando do zero, hoje tem mais de 19 mil projetos em Git. O próprio Ruby on Rails, fora a kernel do Linux, estão em repositórios Git. Mais do que isso, graças à ferramenta git-svn é possível sincronizar (tanto leitura quanto escrita) com repositórios em Subversion, o que permite migração praticamente trivial de Subversion para Git.

Experimente e aprenda esta nova ferramenta. Alguns dos melhores desenvolvedores do mundo e projetos open source já estão migrando para Git. Aumente a produtividade na sua empresa adotando Git.

• Com mais de 20 anos de idade esta linguagem está mais do que consolidada no mercado, hoje é praticamente impossível ver um sistema operacional unix-like sem o seu interpretador, e mais, sem ter dezenas de scripts para as mais variadas funções, escritos em Perl;
• É o canivete-suíço das linguagens de programação pois, comprovadamente, é flexível e adaptável;
• Sua sintaxe é inspirada em linguagem C (ANSI), então, é simples, direta e prazerosa de escrever;
• Reúne as listas de Lisp, os Arrays Associativos do AWK e as Expressões Regulares do Sed, ou seja, o melhor destes mundos com inúmeras outras inovações;
• Também suporta estrutura de dados complexas, First Class Functions (construção de novas funções em tempo de execução), Closures, Orientação a Objetos, bem como a mistura de vários paradigmas, fica a critério do programador, e muito muito mais;
• Toda a liberdade ao desenvolvedor, possibilitando escrever instruções complexas em poucas linhas de código (quanto menos linhas de código menos bugs);
• É rápido e produtivo, pois provê ao programador todas as ferramentas necessárias para colocar os seus anseios em prática;
• “There is more than one way to do it”;
• CPAN, um repositório com milhares de módulos Perl, largamente utilizados, e conseqüentemente, testados pela comunidade;
• Liberdade. Não te prende à burocracia, e subentende de que o desenvolvedor tem consciência do que faz e quer liberdade para isso;

• São Paulo Perl Mongers: http://sao-paulo.pm.org/
• Perl Mongers: http://en.wikipedia.org/wiki/Perl_Mongers
• Perl 6: http://en.wikipedia.org/wiki/Perl_6
• Programming Perl: http://en.wikipedia.org/wiki/Programming_Perl
• Perl Foundation: http://en.wikipedia.org/wiki/The_Perl_Foundation
• Perl Monks: http://en.wikipedia.org/wiki/Perl_Monks

Este evento é marcado pelo fortalecimento da Marca SUN Microsystems no mercado e desta vez não foi diferente o foco deste foi no sistema operacional  Opensolaris .

Assisti algumas palestras  voltadas a administração do JAVA e novidades que futuramente podemos implantar :

GlassFish e o futuro do Java EE -  Estou acompanhando o crescimento deste server que tende a ser o substituto imediato do Tomcat , foi salientada a versão 3 que sairá em 2009  este server será o carro chefe da Sun para servidores Web.

(J)Ruby e Rails - Como no evento JUST JAVA a única linguagem mencionada no evento fora o JAVA foi o ruby on rails , está é a grande tendência para 2009 para quem quer saber mais acesse o curso grátis :www.javapassion.com

EJB 3, Spring e SEAM - Aplicações robustas desenvolvimento e injeção de dependências foi o forte dessa palestra que aguçou e muito meu interesse por estas tecnologias.

Conectando o mundo com REST, Melhorando a Performance em Java e  Desenvolvendo e administrando com segurança

Foram palestras voltadas para a administração do ambiente JAVA utilizando o OpenSolaris

Conclusões :

A Sun através deste evento anual fortalece sua marca e consequentemente os patrocinadores como a Locaweb e fornece um ambiente adequado e completo para o desenvolvedor oferecendo :

Sistema Operacional : Opensolaris

Linguagem de desenvolvimento : JAVA

Banco de dados : MYSQL (Adquirido pela Sun 2008)

IDE de desenvolvimento : Netbeans (Incorporado a Sun)

Server JAVA : Glassfish

Para que curte plataforma Linux , se atentem a estas ferramentas que serão padrões mais rápido do que a gente pensa.

Até mais .

Carlos Eugênio

Complementando as impressões do Eugênio, segue:

Virtualização: A Sun criou o VirtualBox (Sun xVM VirtualBox), ainda não testei, mas pelas demonstrações que tive, superou as expectativas.

Os interessados em ver as imagens dele em ação, basta acessar http://www.sun.com/software/products/virtualbox/ e clicar nas figuras contidas na seção xVM VirtualBox Gallery.

PHP e Java são amigos.

Com o Quercus, desenvolvido pela Caucho, é possível fazer o PHP rodar sob o Java e ter acesso aos seus recursos, dentre eles, JDBC e às suas demais classes. Detalhes podem ser obtidos em http://www.caucho.com/resin-3.0/quercus/

jMaki, Framework Ajax
O projeto jMaki faz parte da comunidade do Glassfish, e este framework pode ser utilizado tanto para Java quanto para Ruby, PHP e Phobos. O site deste projeto pode ser acessado através da URL https://ajax.dev.java.net/

Também fui na palestra sobre MySQL e a web 2.0. Kaj Arnö, palestrante, vice presidente de relações comunitárias da MySQL AB, citou com ética e carisma a questão do MySQL em relação aos demais sistemas de gerenciamento de banco de dados e sobre a importância do LAMP (Linux Apache MySQL P(PHP/Perl/Python)), onde podemos concluir que a Sun, assim como a Microsoft, também se preocupa e investe em recursos para o PHP. Para os desenvolvedores desta linguagem, é uma vasta variedade de opções para o desenvolvimento de soluções.

Glauco Furlaneto

Essa é uma excelente fonte de consulta, aproveite!

Acesse: CSS Properties Index