Há um certo tempo refatoramos o sistema que trabalhamos. Migramos de uma arquitetura definida pelo Fowler como Transaction Script (explicada nesse edição da MundoJ) para uma arquitetura essencialmente O.O Domain Model. Por incrível que pareça, o que mais nos chamou a atenção nesse processo não foi o fato de transferir a lógica de negócios para as entidades responsáveis, visto que delegar responsabilidades é complicado e é isso que faz do O.O tão desafiante, mas sim a qualidade na expressividade do código que atingimos.

Alguns sinais de que seu código não esteja expressivo são os comentários. A lógica é que, se você está explicando com comentários algo que o próprio código deveria dizer, é um smell, neste caso um forte sinal da falta de expressividade (não para a linguagem, mas não está se expressando bem para outro programador).

Sabemos que programador odeia ver código de outro programador, e nos tempos atuais onde a agilidade e ideia de código coletivo estão cada vez mais em alta, código expressivo passa a ser uma exigência, quase que um requisito não funcional. Vamos considerar o código abaixo, tente lê-lo você mesmo:

public void imprimirEstatisticasDeVenda(Vendedor vendedor) {
	BigDecimal total = BigDecimal.ZERO;
	BigDecimal comissao = BigDecimal.ZERO;
	for (Venda venda : vendedor.getVendas()) {
		total = total.add(venda.getQuantidade().multiply(venda.getPreco()));
		if(venda.getQuantidade().doubleValue() >= 5) {
			if(venda.getPreco().doubleValue() >= 5) {
				comissao = comissao.add(venda.getQuantidade().
					multiply(venda.getPreco()).multiply(new BigDecimal(0.05)));
				venda.priorizarDespache();
			}
		}
	}
	System.out.println(vendedor.getNome() + " - Total arrecadado: "
		+ df.format(total) + " - Comissao: " + df.format(comissao));
}

Se analisarmos linha a linha, veremos que este código calcula o total arrecadado a partir das vendas, o total de comissão que deve ser pago ao vendedor que efetuou as vendas, e finalmente prioriza aquelas vendas que tiveram quantidade e preço maior que cinco.

Ele poderia ser melhorado? Sim, de diversas formas: poderíamos ter extraído varias partes desse código para métodos menores e com nomes significativos para torná-lo mais limpo. Outra opção é buscar por bibliotecas ou criar suas próprias DSL’s.

Para não esperar as closures do Java 8, conseguimos um pouco de programação funcional utilizando a biblioteca LambdaJ, dando um toque de cálculo de lambda ao Java. Ao reesrever o código utilizando essa biblioteca, temos algo mais enxuto:

public void imprimirEstatisticasDeVenda(Vendedor vendedor) {
	List<Venda> vendas = vendedor.getVendas();
	BigDecimal totalArrecadado = sumFrom(vendas).getValorDaVenda();

	List<Venda> vendasComissionaveis = select(vendas,
		comQuantidadeMaiorOuIgualA(5).and(comPrecoMaiorOuIgualA(5)));
	forEach(vendasComissionaveis).priorizarDespache();

	BigDecimal comissao = sumFrom(vendasComissionaveis)
	        .getValorDaVenda().multiply(new BigDecimal(0.05));

	System.out.println(vendedor.getNome() + " - Total arrecadado: "
		+ df.format(totalArrecadado) + " - Comissao: " + df.format(comissao));
}

Seria esse um código mais expressivo? Consideramos que sim, mas alguns vão criticar que estamos escondendo uma certa complexidade do sistema, que deveria estar a vista dos programadores. E a performance? O LambdaJ tem suas inicializações e objetos temporários, sendo um pouco mais lento que a versão anterior, podendo trazer problemas em laços. Há também o problema de ser uma biblioteca de fora da API padrão, e os desenvolvedores precisam de um tempo, mesmo que curto, para se adaptar às novas ideias trazidas por ela. Se você já cursou o FJ-16, pode conferir a modelagem em Scala, mais funcional. 

Expressividade de código derruba alguns conceitos que aprendemos, principalmente sobre Design Patterns. Afinal, o que o seu cliente entende: Usar um BO para alterar o VO e persistir usando o DAO no MYSQL ou “salvar cliente  no repositório de cadastros“?

Desenvolver para Android não é uma tarefa fácil. Hoje existem cerca de 700 dispositivos que rodam Android. Além de rodarem diversas versões do android, eles possuem hardwares, telas e tamanhos diferentes. Uma grande dor de cabeça para o desenvolvedor Android, a conhecida fragmentação da plataforma.

Para facilitar o desenvolvimento e  aliviar a dor de cabeça do desenvolvedor, a plataforma Android desenvolveu uma ferramenta fantástica: o Application Resources.

O Application Resources é muito útil no desenvolvimento de aplicativos que serão usados por diversos dispositivos, principalmente se for no caso para smartphones e tablets.

Fonte: http://developer.android.com/images/resources/resource_devices_diagram2.png

Para se utilizar do Application Resources, basta colocar qualifiers nas pastas de Resources (res/). Quando criamos um projeto Android ele já tem a pasta layout. Se, por exemplo, formos criar layouts diferentes (mais adequados) para dispositivos de telas pequenas, criaremos a pasta layout-small. Nesse caso, small é seu qualifier.

Quando sua aplicação é executada, ela carregará os resources de acordo com os qualifiers do seu dispositivo. Se você não utilizar nenhum qualifier, a aplicação utilizará os resources defaults (sem qualifiers. Ex: layout, values, etc.). Aplicações podem possuir diferentes diretórios para diferentes qualifiers, como a figura mostra:

Se você vai desenvolver sua aplicação para uma grande quantidade de dispositivos, é praticamente obrigatório o uso do Application Resources. Ele vai evitar que você faça arquivos de layouts desnecessários, ou seja, ao invés de ter um arquivo XML dentro da pasta layout para cada tipo de tela, você terá o arquivo com o mesmo nome em uma pasta layout e outro com o conteúdo diferente em layout-small. Com isso você pode aproveitar as capacidades (processamento, qualidade e tamanho de telas) dos dispositivos.

Uma curta aplicação de exemplo está disponível no github. Nela exibimos um texto diferente para cada tipo de dispositivo: dispositivo com telas pequenas, telas médias, telas médias em landscape, telas grandes e telas grandes com versão 14. O Application Resources não serve só para internacionalização, no exemplo a ideia é exibir qual o tipo de tela que o dispositivo tem alterando apenas o conteúdo do arquivo strings.xml de acordo com os qualifiers. Seguindo esta ideia, também podemos utilizar o Application resources principalmente no styles.xml, facilitando trabalhar com os diferentes tipos e orientações de telas.

Uma aplicação que tem muitos detalhes diferentes em dispositivos diferentes pode aparecer com diversos qualifiers grandes, como values-pt-large-v14-land.

Mas tome cuidado, não saia colocando qualifiers em tudo. Antes disso, procure usar o que realmente você vai precisar. Esperamos te encontrar aqui no curso de desenvolvimento para Android!

Um dos mais badalados frameworks de ORM no mundo Java (e popular também no .NET), o Hibernate recentemente ganhou sua versão 4.0 Final, que chega para arrebentar de novidades. O framework surgiu em 2001, por iniciativa de Gavin King, e logo se tornou amplamente utilizado devido a uma grande diversidade de recursos para mapeamento objeto relacional. Com a especificação da JPA (Java Persistence API), solidificou-se como  a implementação mais utilizada. Diversos projetos também passaram a ser desenvolvidos pela equipe do Hibernate a fim de aprimorar os recursos existentes no framework. Muitos deles, em vez de serem anexados ao projeto Core, tornaram-se plugins, tais como Hibernate Search, o Hibernate OGM e o Hibernate Validator. Este último, inclusive, teve fortes influências para a criação de uma nova especificação, a Bean Validation (JSR 303).

A partir da versão 3.5, o Hibernate tornou-se uma implementação certificada para a JPA2 (JSR 317), lançada oficialmente no final de 2009. Várias annotations surgiram e muitos recursos foram aprimorados. Em dezembro de 2011, a versão 4.0 Final veio à tona, trazendo algumas importantes novidades que gostaríamos de destacar:

Redesign da SessionFactory

Possivelmente essa é uma das grandes mudanças no Hibernate 4. Estávamos habituados a obter uma SessionFactory da seguinte forma:

private static final SessionFactory sessionFactory =
    new Configuration().configure().buildSessionFactory();

Entretanto, agora o método buildSessionFactory() está listado como deprecated, bem como as classes de Configuration: org.hibernate.cfg.Configuration e AnnotationConfiguration. A nova forma de se obter uma SessionFactory é através do ServiceRegistry, que explicaremos adiante, lançado para esta versão 4:

ServiceRegistry serviceRegistry = new ServiceRegistryBuilder()
    .configure().buildServiceRegistry();
MetadataSources metadataSources = new MetadataSources(serviceRegistry);
metadataSources.addResource("algum.hbm.xml")
    .addAnnotatedClass(SuaEntidade.class);
Metadata metadata = metadataSources.buildMetadata();
SessionFactory sessionFactory = metadata.buildSessionFactory();

Para que possamos obter uma SessionFactory, precisamos de um ServiceRegistry, seguido de um MetadataSources (eventualmente podemos adicionar recursos, classes anotadas, entre outros, de forma similar ao Configuration); a partir deste obtemos um Metadata e então finalmente conseguimos uma SessionFactory.

Para obter uma EntityManagerFactory nada muda, podemos usufruir da classe javax.persistence.Persistence.

ServiceRegistry

Uma nova forma foi implementada para que o Hibernate gerencie seus serviços. Services são classes que fornecem ao Hibernate diversos tipos de funcionalidades, tais como ClassLoader, conexão com o banco (ConnectionProvider), descoberta de dialetos apropriados, entre outros. Você deve estar se perguntando por que isso é um ponto interessante. O fato chave é que agora todos os serviços possuem uma interface. Caso queira, você pode mudar a forma com que o Hibernate realiza algumas funcionalidades de uma maneira muito simples, apenas fazendo com que suas classes implementem a interface de serviço do Hibernate. É uma forma de desacoplar seu código interno e se tornar mais maleável.

Suporte a Multi-Tenancy

Para que não conhece o termo, aí vai um pequeno resumo – em um modelo multi-tenant, é possível compartilhar os mesmos recursos físicos para clientes/empresas diferentes, mas ao mesmo tempo permite-se que fiquem logicamente isolados. A frase anterior pode parecer abstrata, então imagine diversas aplicações de e-commerce. Muitas delas possuem um core muito similar e diferem apenas em questões de layout e UI. Imagine então que fosse criada uma base de código igual para todas essas lógicas de e-commerce e apenas o design de cada loja diferente fosse mudado; cada uma delas teria seu próprio namespace e um endereço na web; contudo a base de código seria a mesma. Esses websites de lojas de e-commerce seriam cada um, um tenant.

Podemos implementar o Multi-Tenancy de algumas formas: Instâncias de bancos separadas (cada tenant possui sua prórpia instância de banco); Schema separados (os tenants compartilham o mesmo banco físico, entretanto cada um deles possui um schema); e também podemos implementar o Multi-Tenancy através de Particionamento (usamos o mesmo banco físico e o mesmo Schema), onde os tenants são particionados de acordo com algum discriminator value (uma chave que apareceria em toda as tabelas) e uma única tabela guarda os dados de cada um deles. O Hibernate 4 dá suporte a esta última opção de maneira fácil. Para este caso, tomemos como exemplo uma tabela no banco denominada Cliente:

CLIENTE (
  ID BIGINT,
  NOME VARCHAR,
  ...
  TENANT_ID VARCHAR (ou uma chave estrangeira)
)

Note que precisamos do campo TENANT_ID, pois ele define a qual tenant nos referimos. Em um exemplo real, esse ID vai dizer a qual loja pertence determinado produto, por exemplo. Essa abordagem via Particionamento ainda dá suporte a cache de segundo nível.

Mas será que sempre precisaremos nos lembrar de criar um TENANT_ID em nossas tabelas? Como poderíamos ter algo como:

CLIENTE (
  ID BIGINT,
  NOME VARCHAR,
  ...
)

sem termos um TENANT_ID? Poderíamos ter schemas separados e criarmos uma SessionFactory para cada tenant. Entretanto, isso seria inviável se tivéssemos muitos tenants, pois muitas SessionFactories podem ser extremamente custosas para a memória. Uma outra ideia seria utilizarmos uma abordagem conhecida como application-supplied connections, onde abrimos uma Session em cada SessionFactory através de uma Connection específica que fornecemos. Podemos dizer ao Hibernate qual Connection utilizar em cada contexto. Lembra-se de quando explicamos o ServiceRegistry? Um dos Services, é o ConnectionProvider. Separando os schemas evitamos a necessidade de um TENANT_ID em cada tabela, mas perdemos a possibilidade de usar o cache de segundo nível de maneira fácil, além de ser mais trabalhoso realizar relatórios e estatísticas com mais de um cliente.

O Hibernate 4 fornece essas alternativas básicas para o cenário multi-tenant, de forma quase transparente.

Usando o Hibernate 4

Quer ver o Hibernate 4 em ação? A maneira mais fácil de colocá-lo em seu projeto é através do Maven:

  <dependency>
    <groupId>org.hibernate</groupId>
    <artifactId>hibernate-core</artifactId>
    <version>4.0.1.Final</version>
  </dependency>
  <dependency>
    <groupId>org.hibernate</groupId>
    <artifactId>hibernate-entitymanager</artifactId>
    <version>4.0.1.Final</version>
  </dependency>
  <dependency>
    <groupId>org.hibernate</groupId>
    <artifactId>hibernate-annotations</artifactId>
    <version>3.5.6-Final</version>
  </dependency>

Se você utiliza alguma outra ferramenta de build, aqui você encontra todas as dependências necessárias declaradas para Ivy, Gradle, SBT, entre outros.

Você também pode baixar os jars necessários para usá-los diretamente. Caso você use o JBoss AS 7 (conheça mais sobre essa nova versão do servidor), a versão 7.1 (ainda em Beta) já vem com o Hibernate 4 Final. Se você preferir o cloud, pode experimentar o Hibernate 4 no Openshift (aqui há um tutorial no blog da Caelum).

Gostou? Há muito mais nos links abaixo:

Webinar de Hibernate 4 – link
Hibernate 4 – post oficial do in.relation.to
Multi-Tenancy – mais informações (tutorial introdutório)
Multi-Tenancy e Hibernate 4 – Perguntas e Respostas

Também não deixe de visitar os vários posts da Caelum sobre Hibernate, inclusive o conhecido 7 hábitos dos desenvolvedores Hibernate e JPA altamente eficazes. Esperamos você no nosso curso de Hibernate e JPA!

Desenvolver um aplicativo Android com uma boa interface com o usuário não é fácil: os diferentes tamanhos de tela podem dar trabalho para chegar a um resultado satisfatório em múltiplos dispositivos. Quando levamos em conta os tablets surge um problema ainda maior: como criar uma aplicação para smartphone que, ao rodar em um tablet, aproveite o espaço extra que o dispositivo oferece? Mais ainda: como fazer isso de maneira fácil?

A partir da versão 3 do Android, através da a API de Fragments, podemos dividir nossa tela e dar comportamento a cada pedaço (fragmento) de uma view com um Fragment.

Como exemplo vamos usar uma aplicação que contém uma listagem de nomes de arquivos de fotos em um ListView. Queremos que o evento de clique em um item da lista nos mostre a imagem selecionada.

Caso nosso Tablet esteja na horizontal gostaríamos que a listagem e a imagem escolhida apareçam na mesma tela, conforme ilustrado na imagem abaixo:

Comportamento da seleção de uma imagem no Tablet na horizontal

No caso do tablet estar na vertical gostaríamos de ver apenas a listagem ou a imagem na tela:

Comportamento da seleção da imagem em um Tablet na vertical

Para que isso seja possível precisamos ter layouts diferenciados para o tablet em landscape. Podemos fazer isso colocando qualifiers nas pastas de layout. Em nosso caso telas grandes em landscape.

Na view em landscape podemos usar a tag fragment:

<LinearLayout ...>
  <fragment android:id="@+id/fragment1"
     android:name="br.com.caelum.hubbletablet.ListaImagensFragment" .../>

  <fragment android:id="@+id/fragment2"
     android:name="br.com.caelum.hubbletablet.ImagemFragment" .../>
</LinearLayout>

Enquanto a outra será apenas um framelayout para inflar:

<LinearLayout ...>
     <FrameLayout android:id="@+id/ambos_fragments" .../>
</LinearLayout>

Para criarmos um Fragment basta herdarmos da classe e implementar o método onCreateView, onde receberemos um inflater o qual podemos usar para inflar uma view que queremos associar ao Fragment.

public class ListaImagensFragment extends Fragment {
   public View onCreateView(LayoutInflater inflater, ViewGroup container,
			Bundle savedInstanceState) {

       View viewLista = inflater.inflate(R.layout.lista, null);

       ListView listaImagens = (ListView) viewLista
           .findViewById(R.id.listaImagens);

       colocaDadosNoListView(listaImagens);
   }
   // ...
}

O controle da tela ainda é feito pela Activity e através dela manipularemos os Fragments. Caso o tablet esteja na horizontal, a Activity estará associada à versão do main.xml que usa a tag fragment, que informa ao Android as classes dos Fragments que desejamos usar, então o próprio Android se encarregará de instanciá-los. Caso o tablet esteja na vertical, a Activity estará associada à versão do main.xml que contem apenas uma tag FrameLayout, nesse caso precisaremos criar o fragment que trará a lista e associá-lo ao FrameLayout. Fazemos isso no onCreate da Activity:

getFragmentManager().beginTransaction()
    .add(R.id.ambos_fragments, new ListaImagensFragment())
.commit();

Para termos a funcionalidade de apertar o botao de back no Android e o mesmo empilhar e desempilhar os fragments, podemos fazer:

getFragmentManager().beginTransaction()
    .replace(R.id.ambos_fragments, new ListaImagensFragment())
    .addToBackStack(null)
.commit();

O código acima só deve ser executado se o tablet estiver na horizontal, portanto precisamos fazer essa verificação, uma maneira de fazer isso é através do Activity.getResources().getConfiguration().orientation.

No onCreateView do ListaImagensFragment podemos guardar em um atributo o endereço da imagem selecionada quando houver um clique em um item na lista. Como fazemos agora para passar essa informação para o ImagemFragment para que ele possa mostrar a imagem?

Quando estamos trabalhando apenas com Activities temos que usar o putExtra em Intents para enviar dados de uma Activity para outra. O envio de informações de um Fragment para o outro pode ser feito na Activity de uma forma menos orientada a Strings e maps, tornando nosso código mais orientado a objetos.

Se o tablet estiver na horizontal:

ListaImagensFragment listaFragment = (ListaImagensFragment)
	getFragmentManager().findFragmentById(R.id.fragment1);

ImagemFragment imagemFragment = (ImagemFragment)
	getFragmentManager().findFragmentById(R.id.fragment2);

imagemFragment.setImagem(listaFragment.getImagemSelecionada());
imagemFragment.atualizaImagem();

Se estiver na vertical:

ListaImagensFragment listaFragment = (ListaImagensFragment)
	getFragmentManager().findFragmentById(R.id.ambos_fragments);

ImagemFragment imagemFragment = new ImagemFragment();
imagemFragment.setImagem(listaFragment.getImagemSelecionada());

getFragmentManager().beginTransaction()
	.replace(R.id.ambos_fragments, imagemFragment)
	.addToBackStack(null)
.commit();

Essa solução ficou tão interessante que os desenvolvedores da plataforma resolveram criar um pacote de compatibilidade para poder usar praticamente as mesmas ideias nos dispositivos antigos, sem precisar de um dispositivo moderno com versão 3.x ou 4.x, de maneira bem simples.

Um grande cuidado que devemos ter com o uso de Fragments é evitar espalhar por toda aplicação if’s que verificam se a tela é grande ou o aparelho está na horizontal, etc. Podemos criar diferentes classes que implementam o comportamento em aparelhos grandes e em pequenos e então fazê-las implementar uma interface java. Assim podemos utilizar o polimorfismo e chegar a uma solução mais elegante.

Quando iniciamos com desenvolvimento profissional, uma das primeiras perguntas que surge é: “onde os arquivos desse projeto ficarão armazenados?”. É necessário, principalmente quando trabalhamos em conjunto com outros desenvolvedores, que o projeto esteja armazenado em um local acessível a todos os membros da equipe, com as respectivas permissões para que os mesmos sejam alterados, para que novos arquivos sejam criados e que arquivos existentes possam ser modificados e excluídos.

Tendo em vista esse cenário, podemos definir que qualquer computador, numa rede onde todos os membros da equipe tenham acesso, é candidato a “local de armazenamento do projeto”. Mas e se ocorrer algum problema com esse computador?

Então podemos pensar em armazenar os arquivos do projeto em um servidor, com redundância de dispositivos de armazenamento e backups constantes. Uma pasta compartilhada na rede em uma máquina mais segura do que uma estação de trabalho torna-se uma opção melhor. Já podemos chamar esse local de repositório de código?

Apesar dessa segurança adicional, ficamos um pouco restritos quanto a recuperar arquivos excluídos, não temos como desfazer alterações no nosso projeto seletivamente e também não temos informações suficientes sobre o projeto para saber “qual versão desse arquivo eu devo recuperar do backup?”. Podemos criar um histórico (log) textual e adicioná-lo como parte do projeto. Agora perceba que ficamos com um ambiente com requisitos demais para um simples “local de armazenamento de projeto”?

Pensando nesse problema foram criadas ferramentas de controle de versão, e nosso novo curso online apresentará uma das mais utilizadas hoje em dia, o Git, que ainda possui a vantagem de ser distribuído, em relação ao CVS e SVN. O Git é utilizado por muitos projetos de código aberto, podemos citar o kernel do Linux, o Rails e o Hibernate como exemplos. É possível, porém, utilizá-lo para projetos privados com restrições e permissões de acesso.

Uma grande vantagem do Git é a existência de ferramentas comerciais de hospedagem de código na Web. A maior provedora de hospedagem de repositórios Git, abertos ou privados, é o Github. Para projetos aberto, ele é gratuito. A Caelum hospeda seus projetos dentro do github, que por sua vez hospeda toda sua aplicação no cloud. Dessa forma, para você começar a utilizar o git, não é necessário instalar o seu servidor. Vamos então instalar o cliente.

O Git é uma ferramenta baseada em linha de comando, ou seja, realizamos as operações de controle dos arquivos pelo prompt de comando. Se você é adepto de ferramentas gráficas não se preocupe, existem algumas opções para facilitar seu trabalho e plugins para o Eclipse.

Durante o curso de repositórios remotos e Git aprenderemos outros comandos que o Git nos fornece para solucionar diversos problemas desde o trabalho básico de criação de um repositório, commits, branches, conflitos, como trabalhar no repositório sem conexão com a internet, trabalhar em diferentes implementações simultaneamente num mesmo projeto, modificação de um arquivo por mais de uma pessoa simultaneamente no projeto e tratar os conflitos, entre outros.

Download e instalação do Git

A instalação do Git é diferente para cada sistema operacional. A seguir, mostraremos como todo o
processo é feito em cada um deles, para depois iniciarmos com os comandos básicos.

Windows

Você pode acompanhar o processo de instalação do Git no Windows no vídeo acima ou os passos a seguir.

Para instalar o Git, iniciaremos acessando a página http://code.google.com/p/msysgit/ e baixando o instalador do msysgit. O instalador da versão mais recente, no momento, é o Git-1.5.6.1-preview20080701.exe. Uma vez baixado, basta executar o programa e seguir as instruções.

Na primeira tela de boas vindas, apenas clique em Next e, na próxima tela, indique o diretório onde deseja instalar o Git em seu computador.

Em seguida, indique quais utilitários serão instalados junto do Git. Marque todas as opções, exceto git-cheetah shell extension. A seguir, defina o nome do menu do Git para o menu Iniciar do Windows, podendo deixar o valor padrão.

O msysgit instala por padrão em seu computador um programa próprio chamado Git Bash, onde é possível manipular os repositórios de arquivos que trabalharemos no futuro. Caso você prefira, é possível usar o próprio prompt do Windows. Basta na próxima janela marcar a opção Run Git from the Windows Command Prompt, como indicado na imagem a seguir:

Na janela a seguir, indique que queremos que as quebras de linha sejam consideradas da mesma maneira, independente do sistema operacional trabalhado. Para isso, marque a primeira opção:

Nesse instante, a cópia dos arquivos será feita para o computador, e em seguida a mensagem de que a instalação foi finalizada aparecerá.

MacOS

Você pode acompanhar o processo de instalação do Git no Mac OS/X no vídeo acima ou os passos a seguir.

Para instalar o Git no Mac OS X (Snow Leopard ou superior), há um instalador pronto, basta baixá-lo em http://code.google.com/p/git-osx-installer/downloads/list?can=3. Na listagem, selecione o arquivo git-1.7.7.3-intel-universal-snow-leopard.dmg.

Após baixá-lo clique duas vezes para ter acesso ao pacote de instalação. Agora é só clicar duas vezes no arquivo .pkg de dentro do .dmg para iniciar o processo de instalação.

Na tela seguinte, selecione a opção “Instalar para todos os usuários desse computador” para continuar. Depois é só prosseguir com a instalação padrão.

Para testar a instalação, abra a aplicação “Terminal” e digite o comando “git”. A saída deve ser similar à imagem:

Opcionalmente, é possível configurar o Terminal para completar os comandos do Git ao pressionarmos a tecla “tab”, além de mostrar na linha de comando se a pasta atual está sendo rastreada pelo Git. Para isso é necessário adicionar as seguintes linhas ao arquivo de perfil do usuário para o prompt de comando, habitualmente encontrado na pasta home do usuário com o nome de .bash_profile. Adicione as seguintes linhas ao fim do arquivo:

if [ -f /usr/local/git/contrib/completion/git-completion.bash ]; then
	. /usr/local/git/contrib/completion/git-completion.bash
fi
GIT_PS1_SHOWDIRTYSTATE=true

PS1='\u@\h:\w $(__git_ps1 "(%s)")\$ '

Ao iniciar uma nova janela ou aba do Terminal, as alterações estarão aplicadas. Caso queira aplicar as alterações imediatamente no Terminal digite source ~/.bash_profile.

Linux

Você pode acompanhar o processo de instalação do Git no Linux no vídeo acima ou os passos a seguir.

Em qualquer sistema Linux, podemos utilizar o gerenciador de pacotes da respectiva distribuição para instalar o Git. No Ubuntu e no Debian, por exemplo, basta instalar o pacote git-core para ter o Git instalado. No Fedora, o pacote git. E no Gentoo, o pacote dev-util/git.

Portanto, por exemplo, para fazer a instalação do Git no Ubuntu, basta executar o comando:

sudo apt-get install openssl git-core

Siga as instruções do prompt de comando, primeiro confirmando a instalação dos pacotes e suas dependências, depois confirmando a instalação do pacote git-core, como demonstrado na imagem:

É possível testar se o Git foi corretamente instalado rodando o comando git no prompt de comando. A saída deve ser uma mensagem de ajuda, similar à demonstrada na imagem:

Ao instalar o Git, um script de ajuda que completa os comandos do Git no terminal é instalado, juntamente com um script que demonstra na linha de comando se estamos em um diretório que é um projeto rastreado pelo Git. Para ativá-los é necessário modificar o arquivo de perfil do prompt de comando, normalmente esse arquivo encontra-se na pasta “home” do usuário e chama-se “.bash_profile” (em alguns casos “.bashrc” ou “.zshrc”).

Caso nenhum dos arquivos citados exista, crie-o, caso exista, adicione as seguintes linhas ao final dele:

if [ -f /etc/bash_completion.d/git ]; then
	. /etc/bash_completion.d/git
fi
GIT_PS1_SHOWDIRTYSTATE=true

PS1='\u@\h:\w $(__git_ps1 "(%s)")\$ '

Salve o arquivo, a partir de agora, caso estivermos em uma pasta rastreada pelo Git no prompt de comando, seremos informados. Para ativar as alterações imediatamente, execute o comando source informando o arquivo de perfil que alteramos:

source ~/.bash_profile

Clonando um repositório

Para testar, faça agora um clone do repositório do vraptor:

git clone git@github.com:caelum/vraptor.git

Repare que, diferente de muitos outros sistemas de controle de versão, você possui agora todo o repositório do VRaptor, inclusive todo o histórico de modificações, possibilitando trabalhar de maneira offline e concorrente a outros desenvolvedores. Mais detalhes no novo curso de Git online.

Quem nunca reclamou de uma API não tão bem amigável? Um bom caso é o uso do Calendar enquanto estamos programando em Java. Para fazer uma simples soma de dia num Calendar acabamos com o seguinte código:

   Calendar data = Calendar.getInstance();
   data.add(Calendar.DAY_OF_MONTH,1);

O que seria mais interessante, pelo menos nesse caso, seria ter algum método mais propício que fizesse a lógica de adição. Lá dentro poderia até ser implementada de uma maneira complicada, mas é para isso que serve encapsulamento. Já que trabalhar com Calendar é muito comum, muitos programadores acabam criando classes utilitárias justamente para encapsular este tipo de código. Abaixo segue um exemplo:

  CalendarUtil calendarWrapper = new CalendarUtil(Calendar.getInstance());
  calendarWrapper.plusDays(1);

Existe inclusive o bem conhecido Joda Time, exatamente com esse propósito. O problema aqui é que nem sempre temos uma lib como essa para tentar minimizar problema de APIs verborrágicas e, além disso, temos que trabalhar com objetos de classes diferentes, talvez modificar assinaturas de métodos que já existem, algumas vezes impossível. Pensando nisso, a Scala tem umas de suas mais conhecidas features, para simular novos métodos em classes que não temos controle. Imagine que queremos ter um novo método no Calendar chamado plusDays. O código seria como o abaixo:

   Calendar data = Calendar.getInstance();
   data.plusDays(1);

Só que esse método não existe. É justamente aqui que criaríamosnosso próprio Wrapper, adicionando esses novos métodos e delegando os antigos, podendo implementar um decorator. No Scala, podemos indicar ao compilador para que procure métodos não existentes em determinadas classes em outro lugar. Preste atenção no código a seguir, que define um método convertCalendarToImprovedCalendar que recebe um Calendar e devolve uma instância de classe anônima (filha de Calendar) com o método adicional plusDays:

  object Converters {
   implicit def convertCalendarToImprovedCalendar(calendar:Calendar) = new {
      def plusDays(number:Int) = calendar.add(Calendar.DAY_OF_MONTH,number)
   }
  }

O nosso plusDays poderia ser implementado inclusive com o Joda Time por debaixo dos panos, e os outros desenvolvedores continuariam a trabalhar com o velho conhecido Calendar.

A mágica aqui acontece com o uso da palavra implicit. Podemos agora pedir para que esse conversor seja utilizado sempre quando um método não existente em Calendar for invocado. Basta importarmos o Converters, como no exemplo abaixo:

  import Converters._
  class TesteCalendarComMetodosNovos {
    def main(args:Array[String]) {
      val data = Calendar.getInstance();
      data.plusDays(1);
    }
   }

Repare que os métodos da classe Converters são importados estaticamente para o escopo de execução, a linha import Converters._ funciona muito parecido ao import estático do Java.

Essa técnica para adicionar novos comportamentos em classes que não estão disponíveis para serem alteradas foi chamado de Pimp my Library por Martin Odersky, num post que ele escreveu há bastante tempo. Outras linguagens possuem features similares, como as Open Classes do Ruby. Uma diferença bastante grande entre os implicits e as Open Classes é que como o Scala é uma linguagem estaticamente tipada, a resolução das chamadas a esses métodos são todas resolvidas em tempos de compilação. Nada é adicionado em tempo de execução.

Implicit method é uma das features que mais utilizamos da linguagem (e precisamos tomar cuidado para não abusar). Adicionar esses novos comportamentos, criação de DSLs e outros usos que discutiremos em novos posts são alguns dos exemplos de uso.

Para quem quiser ver um pouco mais, existe um projeto chamado hibernate-dsl que utilizamos aqui na Caelum para conseguirmos trabalhar com a session do Hibernate de maneira mais interessante.

Assim como nos anos anteriores, o de 2011 foi mais um de conquistas. Gostaríamos de compartilhar algumas delas com vocês, sucintamente.

- O Caelum Online foi lançado há apenas 3 meses e já se prova eficiente no ensino de tecnologia, oferecendo aprendizado colaborativo, além de comunicação pessoal com os instrutores para a correção dos exercícios. Em breve, teremos novos cursos, além de funcionalidades, que são adicionadas a cada semana.

- Livro de introdução à arquitetura e design lançado. Depois de uma longa espera, o livro foi publicado e o primeiro carregamento da Saraiva se esgotou em menos de 1 semana! O estoque está sendo reposto e agradecemos a todos os alunos do curso de design e arquitetura da Caelum pelo apoio e ajuda.

- Muitos grupos de usuário fizeram suas reuniões por aqui. O Grupo de Usuários de Tecnologia Google, o .NET Architects, o GUJ através do Café com Java, o Grupo de Usuários Ruby e muito mais, com novidades para esse ano, como o grupo de usuários iOS. Além disso, o QCon deixou sua marca novamente, em sua segunda edição no Brasil.

- E certamente comemoramos em grande estilo, com as festas de fim de ano nas 3 unidades:

- Qual o resultado final? Esse ano nós viajamos para 20 cidades diferentes por todo o Brasil. Agradecemos as empresas dessas cidades, que confiaram a nós o trabalho de atualização e aprendizado:

Mas nosso trabalho atingiu muito mais. Apenas em 2011, tivemos alunos vindos de 285 diferentes cidades. Fica um grande agradecimento a todos os que se deslocaram, viajando para as nossas unidades de São Paulo, Rio de Janeiro e Brasília, dormindo por aqui e que não investiram só dinheiro, mas em especial muito do seu tempo e estudo.

E nesses quase 8 anos de treinamentos estamos prestes a atingir 600 cidades diferentes. Com um crescimento ordenado, unidades próprias e a confiança do mercado, conseguimos não só manter como também melhorar nossa qualidade de ensino. Outra prova disso são as mensagens que recebemos de vocês:

Quer ler mais do que estão falando da Caelum? Veja aqui uma lista com mais tweets. E que em 2012 trabalhemos para conseguir mais dessas mensagens!

Desde o início de nosso trabalho com o cloud em 2009 temos investido tempo e pesquisa na utilização do cloud como plataforma para diminuir custos (e trabalho!) e potencializar produtos, através de diversos vendors.

Com a Amazon não é diferente: nosso sistema de ensino online está deployado lá. Com o lançamento de grande parte da sua plataforma no Brasil, a Amazon se torna uma opção ainda mais interessante de onde ter sua aplicação. Vamos ver passo a passo como fazer um deploy e aproveitar das novas vantagens da Amazon por aqui.

Primeiro nos logamos no painel AWS Manager, e escolhemos a região da América do Sul:

Depois escolhemos a imagem que usaremos para a máquina, no nosso caso uma instalação linux limpa, mantida pela própria Amazon. Existem centenas de instalações possíveis (de linux e windows) que podem ser buscadas no market da amazon.

Escolhemos então a potência da máquina e em qual availability zone ela ficará. Comecemos com “sa-east-1a“, que indica América do Sul:

Vale lembrar que uma aplicação realmente com alta disponibilidade precisaria ser deploiada em duas ou mais avaliability zones, mesmo sendo pequena a chance de uma zona cair.

Nas duas próximas telas escolhemos detalhes do Kernel e do RAM, além de possíveis tags que queremos dar para a máquina (em geral para trabalhar através dos web services). No nosso caso deixaremos os defaults.

Quando uma nova máquina é criada, precisamos nos logar nela e, para isso, precisamos de uma chave privada de acesso. A amazon pergunta qual o nome que devemos dar a chave, criando e permitindo que baixemos o arquivo. Note que a chave contida nesse arquivo é importantíssima e qualquer um de sua posse poderá ter acesso a máquina.

Por fim, escolhemos quais portas desejamos deixar abertas. No caso de uma aplicação Java com Jetty ou Tomcat, adicionamos a porta padrão 8080:

Isso mesmo, nada de complicados usuários e senhas. Nada de gerenciá-los através de ferramentas de webadmin desatualizadas. Nada de complicadas regras e configuração de firewalls. A Amazon então permite confirmar todas as opções, e o resultado é a máquina rodando:

A máquina possui um IP interno (para ser acessado de dentro da Amazon) e um DNS público, através do qual acessaremos a mesma de fora da Amazon. O DNS público pode ser visto ao clicar no nome da máquina:

Vamos acessar a máquina via ssh:

chmod 700 caelum-exemplo.pem
ssh -i caelum-exemplo.pem ec2-user@ec2-177-71-153-49.sa-east-1.compute.amazonaws.com

Resultando em:

The authenticity of host 'ec2-177-71-153-49.sa-east-1.compute.amazonaws.com (177.71.153.49)' can't be established.
RSA key fingerprint is 34:a6:de:34:88:fd:a1:73:ae:c5:03:f1:ed:8e:2f:96.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'ec2-177-71-153-49.sa-east-1.compute.amazonaws.com,177.71.153.49' (RSA) to the list of known hosts.

       __|  __|_  )
       _|  (     /   Amazon Linux AMI
      ___|\___|___|

See /usr/share/doc/system-release/ for latest release notes.
There are 16 security update(s) out of 24 total update(s) available

Agora fazemos download do jetty, descompactamos e rodamos o servidor (se preferir, utilize o Tomcat):

wget http://download.eclipse.org/jetty/8.1.0.RC1/dist/jetty-distribution-8.1.0.RC1.tar.gz
tar zxf jetty-distribution-8.1.0.RC1.tar.gz
jetty-distribution-8.1.0.RC1/bin/jetty.sh start

O servidor irá inicializar e você logo receberá a mensagem de que ele está ouvindo a porta 8080.

2011-12-15 17:54:27.682:INFO:oejs.AbstractConnector:Started SelectChannelConnector@0.0.0.0:8080 STARTING

Pronto, acesse seu jetty:

E se desejarmos atualizar a imagem da máquina, com atualizações de seguranca? Se sua máquina não armazena o banco, mas sim somente arquivos voláteis (de fácil reinstalação), basta terminá-la e criar uma nova. Sistema operacional atualizado! Para manter dados voláteis, você pode usar o RDS da Amazon para seu banco Mysql ou Oracle (ou outras máquinas para bancos não relacionais) e manter um script de configuração (usar técnicas de configuration management).

Mais: com apenas alguns cliques é muito fácil de adicionar um load balancer através de sticky sessions, configurar ips fixos, etc.

O que você está esperando para fazer seu primeiro deploy por lá?