Rails 4 está chegando e é interessante verificar se vai dar muita dor de cabeça para migrar sua aplicação atual.
Para isso, seguem alguns problemas comuns que podem acontecer no momento do deploy e as soluções para os mesmos. No Heroku, a stack a ser utilizada deve ser a stack Cedar. Caso sua aplicação esteja nas stacks anteriores, será necessário criar uma nova aplicação utilizando esta stack.

O primeiro ponto que vamos atacar é a configuração para guardar a session no Rails. Esta configuração serve para quem utiliza cookie como forma de armazenamento e quer continuar utilizando. Na versão 4.0.0.beta1 ela possibilitava que o armazenamento fosse feito de forma encriptada através de uma opção no arquivo config/initializers/session_store.rb cadastrada da seguinte maneira:

config.session_store :encrypted_cookie_store

Na versão 4.0.0.rc1 do Rails esta característica passa a ser um comportamento padrão, conforme descrito no changelog e a única opção mantida foi:

config.session_store :cookie_store

Caso o arquivo esteja com a opção antiga, no momento do startup do servidor o Rails já vai acusar um erro, como o abaixo:

/Users/joviane/.rvm/gems/ruby-1.9.3-p392/bundler/gems/rails-04d27153fcef/railties/lib/rails/application/configuration.rb:144:in `const_get': uninitialized constant ActionDispatch::Session::EncryptedCookieStore (NameError)

Esse é um ponto que se deve ter cuidado. Caso você venha do Rails 3 direto, basta fazer do último jeito caso venha da beta do Rails 4, lembre-se de alterar novamente.

Outra mudança que veio com o Rails 4 foi a localização dos comandos para subir o servidor, criar projetos novos, executar as tasks, etc… Agora todos eles ficam dentro da pasta bin/ do seu projeto Rails. Apenas essa alteração não impacta em nada na nossa vida, já que quando você fizer bundle install, e estiver usando o Rails 4, os arquivos já serão gerados no lugar certo.

O problema é que se você tiver utilizando o binstubs do Bundler, o conteúdo também será gerado dentro do diretório /bin e com isso vai sobrescrever alguns dos comandos, que passaram a funcionar de maneira errada pois o Rails verifica se o conteúdo do script/rails é o mesmo do bin/rails. Como o conteúdo é diferente, o Rails sempre mostrará o help do novo comando. Por exemplo, caso você tente fazer rails s vai aparecer o help do rails new.
Esta situação inclusive está comentado numa issue lá no próprio Bundler.

Além disso, dependendo da task que você quer executar, pode aparecer uma mensagem indicando que não foi encontrado o railties nas suas gems:

/app/vendor/ruby-1.9.3/lib/ruby/1.9.1/rubygems/dependency.rb:247:in `to_specs': Could not find railties amongst [...] (Gem::LoadError)

Para resolver estes problemas, basta que após a instalação do Rails 4 seja executado o comando bundle config --delete bin para que o Bundler deixe de gerar os stubs e o comando rake rails:update:bin para que o Rails atualize os arquivos e os deixe funcionando da maneira correta. A saída do console será parecida com:

exist  bin
identical  bin/bundle
conflict  bin/rails
Overwrite /Users/joviane/caelum/test/project/bin/rails? (enter "h" for help) [Ynaqdh] a
force  bin/rails
conflict  bin/rake
force  bin/rake

A nova versão do Rails, já mostra inclusive uma mensagem comentando que deve ser atualizado o bin:

Looks like your app's ./bin/rails is a stub that was generated by Bundler.

In Rails 4, your app's bin/ directory contains executables that are versioned
like any other source code, rather than stubs that are generated on demand.

Here's how to upgrade:

  bundle config --delete bin    # Turn off Bundler's stub generator
  rake rails:update:bin         # Use the new Rails 4 executables
  git add bin                   # Add bin/ to source control

You may need to remove bin/ from your .gitignore as well.

When you install a gem whose executable you want to use in your app,
generate it and add it to source control:

  bundle binstubs some-gem-name
  git add bin/new-executable

O diretório /bin atualizado deve ser commitado e somente depois deve ser feito o push para o Heroku. Com os comandos gerados, os comandos do Rails são executados normalmente.

Hora de fazer o deploy. Ao tentarmos efetuá-lo utilizando o Rails 4, o Bundler do Heroku irá acusar que existem erros na instalação como a mensagem abaixo:

remote:        Gem::InstallError: activesupport requires Ruby version >= 1.9.3.
remote:        An error occurred while installing activesupport (4.0.0.beta1), and Bundler
remote:        cannot continue.
remote:        Make sure that `gem install activesupport -v '4.0.0.beta1'` succeeds before
remote:        bundling.
remote:  !
remote:  !     Failed to install gems via Bundler.
remote:  !
remote:  !     Heroku push rejected, failed to compile Ruby/rails app

Isto acontece pois o Rails 4 requer pelo menos a versão 1.9.3 do Ruby, sendo a versão 2.0.0 a recomendada. Porém, atualmente o Heroku utiliza por padrão a versão 1.9.2 do Ruby. Para que o deploy consiga ser efetuado, é necessário especificar no Gemfile a versão do Ruby que deve ser utilizada, por exemplo:

ruby "1.9.3"

Agora o deploy funcionou, mas ao executarmos a aplicação, vemos que o css e o js não estão sendo carregados. Se olharmos no log do Heroku, vemos que os arquivos com os assets não estão sendo encontrados:

ActionController::RoutingError (No route matches [GET] "/assets/application-a802b6f76dc4b7e26213ed231e5c407d.css")
ActionController::RoutingError (No route matches [GET] "/assets/application-75a7854682675193d462515d38e028bc.js")

Este problema se deve ao fato de que no Rails 3, o Heroku injetava como plugin no momento do deploy as funcionalidades para servir assets estáticos e efetuar log da aplicação. Como no Rails 4 foi removido o sistema de plugins, o Heroku disponibilizou duas gems que devem ser inseridas no Gemfile para habilitar o comportamento antigo:

gem 'rails_log_stdout', github: 'heroku/rails_log_stdout'
gem 'rails3_serve_static_assets', github: 'heroku/rails3_serve_static_assets'

Pronto, depois de realizada essas alterações tudo deve funcionar normalmente. Boa parte desses problemas foram passados durante a migração do Agendatech para a nova versão do Rails. E você já está pensando em migrar sua aplicação? Passou por algum outro problema? Não deixe de comentar aqui no blog.

‘Aprender Java é muito difícil’! É uma exclamação frequente no fórum do GUJ.com.br e uma dúvida dos alunos da Caelum.

O Java é, junto com .NET, frontend, desenvolvimento mobile, php e ruby, uma das plataformas que mais interessam aos estudantes e iniciantes. Há vários motivos para isso. Você pode ter um primo mais velho que já trabalha com Java, sua faculdade pode estar cobrando exercícios e trabalhos nessa linguagem, quer programar para Android ou simplesmente gostou do logo da plataforma. Como começar?

Aqui na Caelum, aprimoramos nosso curso de Java e orientação a objetos durante anos, desde sua elaboração durante os cursos de verão da USP. Caso você não tenha disponibilidade de fazer nosso curso, não tem problema: a apostila está totalmente disponível na internet.

Vale lembrar que, para encarar essa apostila, você precisa ter um certo conhecimento de lógica de programação e de uma primeira linguagem, seja através de um curso ou de um bom livro.

Mas basta a leitura de uma apostila? Certamente não.

Pratique muito. No começo, evite ferramentas como Eclipse e Netbeans. Sofrer no prompt do DOS ou no shell do linux, com o javac, faz parte do processo de aprendizado. Não fique apenas nos exercícios que você vê nas apostilas ou na sua faculdade. É seu papel ir além, buscar implementar tudo aquilo que passa pela sua cabeça. Tente variações dos exercícios. Não se contente apenas com “agora deu certo”. Vá atrás de entender o que passa por debaixo dos panos. É uma característica importante de um programador.

E como vou ter meu primeiro emprego com Java?

Enviar currículos dizendo que está estudando Java básico pode não ser o suficiente. Apesar do mercado parecer eternamente bom para desenvolvedores de qualquer linguagem, as empresas buscam alguém que possa produzir desde o primeiro dia de trabalho, mesmo que o mínimo. Há dois caminhos de estudo que te possibilitarão mostrar um pouco de serviço, tanto na entrevista quando no início de trabalho: a Web e o Android.

A Web é repleta de sistemas que rodam Java. Há também a apostila do curso Java para Web da Caelum disponível. Servlets e JSP são a base desse desenvolvimento, apesar de, na maioria das vezes, trabalharmos com frameworks web MVC. Criar seu próprio pequeno sistema web, algo que resolva um problema que você mesmo tem, além de ajudar no seu aprendizado pode servir para mostrar no currículo e em uma entrevista.

Para o Android, o Java é a linguagem utilizada no desenvolvimento da maioria absoluta de suas aplicações. Apesar da máquina virtual não ser uma JVM, seu conhecimento de Java básico será utilizado o tempo todo, desde a sintaxe até as bibliotecas principais. Programar para Android é mais divertido do que você pode imaginar, e você pode rapidamente mostrar o resultado de seus estudos para amigos e parentes e para seu futuro chefe!

Seja qual for o caminho que você escolher, praticar e exercitar a linguagem são as principais forma de fixar seu conhecimento e demonstrá-lo! Conhecer profundamente as APIS básicas, como java.lang, java.util e java.io, além dos conceitos de orientação a objetos, é um grande diferencial que boas empresas saberão valorizar. É melhor focar seus estudos no coração da plataforma do que conhecer diversos frameworks e bibliotecas sem este embasamento.

Na plataforma Android, o uso de Fragments para flexibilizar o desenvolvimento é uma prática cada vez mais difundida, em especial para aplicações que precisam rodar em tablets. Através dos Fragments é possível isolar o comportamento de pequenos trechos da tela, ajudando a reduzir a quantidade de código nas activities e permitindo maior flexibilidade no momento de fazer a mesma aplicação rodar em Smartphones e Tablets.

Uma questão relevante nesse cenário é: O que devemos fazer quando um evento em um Fragment impacta em outros Fragments?

Suponha uma tela de um Tablet no qual existam 3 Fragments. À esquerda uma listagem de posts de um blog, no canto superior direito um Fragment que mostra os detalhes do post selecionado, no canto inferior direito para a criação de uma resposta para o post selecionado da listagem:

Tela da aplicação com 3 fragments

Quando clicamos em um item do ListView precisamos passar esse item para os demais Fragments, podemos fazer isso diretamente no Fragment que apresenta a listagem na tela:

getListView().setOnItemClickListener(new OnItemClickListener() {
	public void onItemClick(AdapterView<?> adapter, View view, int posicao,	long id) {
		BlogPost postSelecionado = 
			(BlogPost) adapter.getItemAtPosition(posicao);
		
		FragmentManager manager = getFragmentManager();
		PostSelecionadoFragment telaDetalhesPost = (PostSelecionadoFragment)
			manager.findFragmentById(R.id.direita_superior);
				
		telaDetalhesPost.lidaCom(postSelecionado);
		
		NovoPostFragment telaNovoPost = (NovoPostFragment) 
			manager.findFragmentById(R.id.direita_inferior);
				
		telaNovoPost.lidaCom(postSelecionado);
		
		PostsActivity activity = (PostsActivity) getActivity();
		activity.lidaComSelecao(postSelecionado);
	}
});

Mas será que é responsabilidade de um Fragment conhecer os demais? Podemos delegar a responsabilidade de lidar com a tela como um todo para a Activity que já a está gerenciando , isolando todo o código acima:

getListView().setOnItemClickListener(new OnItemClickListener() {
	public void onItemClick(AdapterView<?> adapter, View view, int posicao,	long id) {
		BlogPost postSelecionado = 
			(BlogPost) adapter.getItemAtPosition(posicao);
		
		PostsActivity activity = (PostsActivity) getActivity();
		activity.lidaComSelecao(postSelecionado);
	}
});

O problema é que acoplamos nosso Fragment de listagem com uma Activity em específico, dificultando seu reaproveitamento. Se resolvermos dar suporte a smartphones, inclusive de tamanho de tela pequena, precisaremos quebrar essa tela em duas ou até três, tornando o método da Activity que lida com a seleção cada vez mais complexo.

Uma maneira de reduzir o acoplamento é trabalhar com mensagens, de maneira semelhante à que os desenvolvedores no iOS fazem com o NSNotificationCenter.

Na seleção de um item, podemos usar o LocalBroadcastManager para disparar uma mensagem de broadcast que não sairá dos limites de nossa aplicação (ajudando nos quesitos segurança e performance).

getListView().setOnItemClickListener(new OnItemClickListener() {
	public void onItemClick(AdapterView<?> adapter, View view, int posicao,	long id) {
		BlogPost postSelecionado = 
			(BlogPost) adapter.getItemAtPosition(posicao);
		
		Intent intent = new Intent("post-foi-selecionado");

		intent.putExtra("blogpost", post);
		LocalBroadcastManager.getInstance(context).sendBroadcast(intent);
	}
});

Agora podemos registrar os Fragments interessados nesse evento:

public class BlogPostSelecionado extends BroadcastReceiver {
	private  FragmentObservador observador;

	public static BlogPostSelecionado registraParaLidarComASelecao(FragmentObservador o) {
		BlogPostSelecionado receiver = new BlogPostSelecionado();
		receiver.observador = o;
		
		LocalBroadcastManager.getInstance(o.getContext())
			.registerReceiver(receiver, new IntentFilter("post-foi-selecionado"));

		return receiver;
	}
}

Agora os Fragments interessados em nosso evento apenas precisam implementar a interface FragmentObservador:

public interface FragmentObservador {
	Context getContext();
	void lidaCom(Post post);
}

Dessa forma invertemos a responsabilidade de propagar o evento para a plataforma, reduzindo o acoplamento e facilitando a manutenção.

Querendo aprender desenvolvimento Android? Conheça o nosso curso!

Você já usa o básico do Git e quer dar um passo além: trabalhar com os temidos branches.

Uma das grandes vantagens do git ou de qualquer sistema de controle de versão distribuído é a possibilidade de trabalhar com branches localmente. Com isso, outras pessoas do projeto não precisam conhecer uma branch que foi criada apenas para facilitar o trabalho de um desenvolvedor. Mas quando desejamos distribuir o conteúdo de uma branch local para que outros desenvolvedores possam contribuir, precisamos que ela se torne remota.

Imaginem que uma das tarefas consiste em modificar o design de uma determinada página. Para isso, criaremos uma branch local chamada design, onde serão realizadas os commits com as alterações, e depois entramos nela:

git branch design
git checkout design

Agora você pode trabalhar normalmente, fazendo commits nesse branch, que ficará armazenado localmente. Dessa forma você não incomoda os outros desenvolvedores que estão trabalhando na branch master, nem precisará mandar todo o novo design pra lá num único commit!

Criando branches remotas

Contudo, você gostaria que uma outra pessoa também pudesse contribuir com as alterações nessa branch. No Git, para disponibilizar uma branch local remotamente basta rodar o seguinte comando:

git push origin design

Copiando uma branch remota localmente

Agora, outras pessoas que quiserem contribuir numa determinada branch remota, precisam copiá-la localmente. Isto é feito com o seguinte comando:

git checkout -t origin/design

Feito isso, você terá uma branch local chamanda design e pode trabalhar nela como qualquer outra branch local.

Depois do design pronto: ‘juntando’ os branches

Dentro do branch design, uma vez terminadas as modificações que queríamos fazer em paralelo, podemos jogar de volta as modificações para o branch master:

git checkout master
git merge design

Isso deixará o master atualizado com um novo commit, trazendo todas as modificações da branch design. Fica só faltando atualizar o master do remoto, com o simples git push.

Há também a opção de fazer um rebase, mas deve-se tomar cuidado, pois ele altera o histórico do master, tentando adicionar os commits do outro branch.

Removendo branches remotas

Uma vez a tarefa foi concluída e integrada na branch principal (master), a branch que criamos anteriormente não é mais necessária. Para não ficar poluindo o nosso repositório, uma boa prática é remover branches que não são mais necessárias. Para isso, basta rodar o seguinte comando:

git push origin :design

Perceba que a única diferença com o comando de disponibilizar reomotamente uma branch local é um dois pontos (:).

Aprenda mais no nosso curso de práticas ágeis e no curso online de Git!

Na última sexta-feira, dia 5 de Abril, aconteceu em São Paulo a primeira edição do MobileConf. Foi um dia completo com 500 participantes focados apenas em desenvolvimento mobile.

Palestras

Foram 3 tracks no evento, com um total de 19 palestras e 3 painéis de discussão no final. Vários dos slides e códigos foram disponibilizados pelos palestrantes:

Abertura do evento: Os caminhos de uma estratégia mobile, Sérgio Lopes

Track HTML5 e Web

• Mobile first, Horácio Soares
• Desenvolvendo para o novo Firefox OS, Andre Garzia
• PhoneGap e desenvolvimento multiplataforma, Loiane Groner
• AeroGear: Mobile Enterprise sem Complicação, Douglas Campos

Track Android

• Aplicações Android flexíveis e de facil manutenção, Erich Egert
• Construindo sua app para conquistar os usuários , André Silva
• Desenvolvimento de Jogos com Android, Anderson Leite
• Dicas Android, Alberto Souza
• Google Cloud Messaging, Ricardo Lecheta

Track iOS

• Customizando o elemento UITableView como gente grande, Diego Chohfi
• Do Zero à AppStore, Fernando Bass
• Primeiros passos com iOS e Objective-C, Osni Oliveira
• Desenvolvimento de games mobile, Andre Toyama

Novidades

Durante o evento, a Casa do Código lançou dois novos livros: A Web Mobile (meu, Sérgio Lopes) e Desenvolvimento de Jogos para Android (Anderson Leite).

E se você quer entrar em alguma dessas áreas de desenvolvimento mobile, a Caelum tem cursos de Web e HTML5, programação Android e programação iOS.

No final do ano passado, implementamos uma integração inicial do VRaptor com CDI. Durante o desenvolvimento tivemos que usar bastante funcionalidades dessa poderosa especificação.  O desafio que tivemos foi o de manter a compatibilidade em relação ao construtor com argumentos do VRaptor. O problema é que todo ponto de injeção para o CDI deve estar marcado com a anotação @Inject, diferente de como é no VRaptor. Abaixo segue um exemplo:

  @Component
  public class CDIComponent implements ComponentFactory {
   private final MyRequestComponent component;

   @Inject
   public CDIComponent(MyRequestComponent component) {
     this.component = component;
   }

   public ComponentToBeProduced getInstance() {
     return new ComponentToBeProduced();
   }
  }

Só que os usuários do VRaptor estão acostumados a apenas declarar um construtor, receber os argumentos e deixar que o framework se vire para realizar a injeção de dependências. Aí é que está justamente o ponto de customização. Precisamos pegar todas essas classes que possuem construtor com argumentos e avisar ao CDI que ele deve considerar esses construtores como se estivessem anotados com @Inject. Para fazer isso, a especificação fornece diversos pontos de extensão, onde podemos registrar classes novas que não foram previamente scaneadas, excluir classes que não precisamos além de poder alterar as configurações registradas para uma determinada classe.

Abaixo segue o exemplo da classe que já vamos criar! Para sermos notificados sobre o evento de configuração das classes, vamos utilizar a anotação @Observes, fazendo uso da implementação do Design Pattern Observer, que já é suportado nativamente por qualquer implementação do CDI.

  public class AddInjectToConstructorExtension {
    public void processAnnotatedType(@Observes final ProcessAnnotatedType pat) {
     //nossa mágica vai entrar aqui
    }
  }

O objeto do tipo ProcessAnnotatedType representa as configurações de uma determinada classe. Uma das coisas que podemos fazer com esse objeto é, por exemplo, saber quais anotações existem em cada elemento da classe. Podemos também adicionar novas informações, por exemplo que a classe tem a anotação @Inject no seu construtor. O primeiro passo é criar um novo objeto do tipo ProcessAnnotatedType, que vai ser o substituto do original. Para não gastarmos tempo implementando isso na mão, vamos usar um projeto da Apache chamado Delta Spike. Ele possui diversas extensões para ajudar em projetos que usam CDI.

  public class AddInjectToConstructorExtension {</pre>
    public void processAnnotatedType(@Observes final ProcessAnnotatedType pat) {
       AnnotatedTypeBuilder builder = new AnnotatedTypeBuilder();
       //lendo as configurações originais
       builder.readFromType(pat.getAnnotatedType());
    }
  }

Agora precisamos adicionar a anotação no construtor e informar ao container que ele deve usar essa nova configuração:

  public class AddInjectToConstructorExtension {
    public void processAnnotatedType(@Observes final ProcessAnnotatedType pat) {
       AnnotatedTypeBuilder builder = new AnnotatedTypeBuilder();
       builder.readFromType(pat.getAnnotatedType());
       List<Constructor> constructors = //pega os construtores com argumentos da classe
       if(hasArgsConstructorAndNoInjection) {
	  Constructor constructor = constructors.get(0);
	  builder.addToConstructor(constructor, new AnnotationLiteral<Inject>() {});
          // aqui efetivamente trocamos a configuração que o CDI vai usar ler a classe.
          pat.setAnnotatedType(builder.create());
       }
     }
   }

O código de verificação do construtor foi deixado de fora de maneira proposital, apenas para não perdermos o foco do post. Caso queira dar uma olhada no código completo, basta seguir este link.

Agora que já temos nossa extensão, vamos aos detalhes menores. Toda extensão no CDI deve implementar a interface de marcação chamada Extension. Basicamente segue a mesma ideia da interface Serializable:

  public class AddInjectToConstructorExtension implements Extension {
    public void processAnnotatedType(@Observes final ProcessAnnotatedType pat) {
       AnnotatedTypeBuilder builder = new AnnotatedTypeBuilder();
       builder.readFromType(pat.getAnnotatedType());
       List<Constructor> constructors = //pega os construtores com argumentos da classe
       if(hasArgsConstructorAndNoInjection){
	  Constructor constructor = constructors.get(0);
	  builder.addToConstructor(constructor, new AnnotationLiteral<Inject>() {});
          //aqui efetivamente trocamos a configuração que o CDI vai usar ler a classe.
          pat.setAnnotatedType(builder.create());
        }
    }
 }

Também precisamos avisar ao container que ele deve carregar essa nossa extensão, assim como avisamos a um container web que ele deve carregar nosso Listener. Para fazer isso, basta declarar um arquivo chamado javax.enterprise.inject.spi.Extension, dentro de uma pasta chamada services. Essa pasta deve ficar dentro da META-INF.  Agora basta que seja escrito o nome completo de cada classe que representa uma extensão:

  br.com.caelum.vraptor.ioc.cdi.extensions.AddInjectToConstructorExtension
  br.com.caelum.vraptor.ioc.cdi.extensions.ComponentExtension
  br.com.caelum.vraptor.ioc.cdi.extensions.ComponentFactoryExtension

Pronto! Nossa extensão vai ser carregada e todas as configurações de classes que tiverem construtor com argumentos, e não tiverem adicionado a anotação @Inject, vão ser alteradas. Tudo isso de maneira completamente transparente para quem está usando o VRaptor! Em breve, o CDI vai entrar como mais um provider de injeção no VRaptor, juntando-se ao Spring, Guice e Pico.

Métodos ágeis são hoje bastante conhecidas para os desenvolvedores de software, mas suas ideias podem ser aplicadas em diversas outras áreas. Aliás, muitas delas nasceram fora da área de desenvolvimento. Há algum tempo usamos um Kanban em nosso departamento comercial para otimizar e gerenciar a produção de tarefa de todos. O objetivo inicial era fazer com que toda a equipe soubesse quais eram as próximas atividades a serem cumpridas por cada um dos seus membros.

A quantidade de atividades a serem feitas semanalmente não é pouca: recontatar alunos, relatório de turmas a iniciar, geração de contratos, reservas de alunos, depoimentos, salas de aula, material de apoio ao curso, impressão de certificados, controle de presenças, e etc. Em nossa equipe de 7 pessoas, era comum que algumas dessas atividades passem despercebidas e não sejam feitas no prazo requerido.

Hoje nosso kanban é organizado da seguinte maneira: cada membro da equipe tem uma cor que representa suas atividades. Toda segunda-feira a equipe organiza o kanban com as tarefas, em ordem de prioridade, que devem ser desenvolvidas ao longo da semana. As etapas do nosso kanban são a fazer, em andamento e concluído. O nome das etapas já deixa bem claro o status daquela tarefa.

Dessa forma, é mais fácil supervisionar as tarefas estipuladas e a eventual cobrança do andamento delas. Nossa equipe é muito pró-ativa, e uma das diferenças que o Kanban nos trouxe, é que ao perceber que um dos membros não deu andamento em uma de suas tarefas ainda, um outro membro pode ajudar, tornando o processo mais ágil.

Há algum tempo atrás, optamos por abandonar o kanban, pois acreditávamos que todos os membros já estavam bem cientes de suas atividades. Hoje já voltamos a utilizá-lo novamente, devido a todas as vantagens relacionadas a visibilidade que já foram comentadas. Mas atualmente fazemos uso de um kanban virtual. O Trello foi a ferramenta escolhida, e todos temos acesso ao quadro das tarefas.

A utilização do Kanban fez com que nossa equipe se tornasse mais dinâmica, flexível. Além disso, ele deixou claro que para conseguirmos realizar as tarefas com excelência, é necessária a colaboração e supervisão de todos.

Você já utilizou Scrum ou algum outro método ágil fora de software? O que acha de implementar o Kanban em sua empresa? Em nosso curso de agilidade, discutimos metodologias ágeis dentro e fora de software. Otimizar processos não é algo útil somente nessa área.

Previsto para abril de 2013, a nova versão do JavaEE vem com atualizações para as principais especificações, além da adição de várias outras focadas em facilitar o desenvolvimento de aplicações para nuvem no modelo PAAS.

Vejamos as principais novidades:

JPA 2.1 (JSR-338)
Agora a JPA irá suportar chamadas a procedures de maneira transparente, sem a necessidade de usar código específico de nenhuma implementação:

  //prepara a procedure
  StoredProcedureQuery query = EntityManager.createStoredProcedureQuery("processaBoletos");
  //registra os parametros da procedure
  query.registerStoredProcedureParameter(1, String.class, ParameterMode.OUT); //saída
  query.registerStoredProcedureParameter(2, Integer.class, ParameterMode.IN); //entrada
  query.setParameter(2, 001); //seta o parametro
  query.execute();
  String resposta= query.getOutputParameterValue(1);

Podemos também invocar qualquer função que esteja disponível no banco de dados, através do novo comando FUNCTION da JPQL:

  SELECT c
  FROM Cliente c
  WHERE FUNCTION(‘EhClienteEspecial’, c.id)

Os EntityListeners da JPA agora também estão integrados com o CDI, permitindo receber por injeção qualquer dependência usando o @Inject:

  class PedidoListener{
    @Inject
    private GeredorDeNumero gerador;

    @PrePersist
    public void geraNumero (Object o){
      Pedido p = (Pedido) o;
      P.setNumero(gerador.novoNumero());
    }
  }

Também foi incluído o suporte a operações de update e delete em lote usando criteria, além de outras funcionalidades.

CDI 1.1 (JSR-346)

Apenas pequenas mudanças e melhorias serão incluídas nessa versão. Entre algumas das novidades esperadas estão permitir a ordenação de Interceptors e Decorators, uma API para criação de contextos personalizados, injeção de objetos estáticos e criação de eventos relacionados a API de Servlets, como inicio/fim de um HTTPServletRequest por exemplo.

EJB 3.2 (JSR-345)
Aqui o foco é continuar facilitando cada vez mais a configuração e o uso de EJBs. Agora teremos suporte a transações dentro de callbacks do ciclo de vida dos beans:

@Stateful
public class CarrinhoBean{
  @PersistenceContext
  private EntityManager em;

  @TransactionAttribute
  @PrePassivate
  public void armazenaNoBanco(){
     // algum código transacional
  }
     ...
}

As configurações sobre quais interfaces serão expostas nos beans também foram simplificadas:

  public interface Agendador{}
  public interface Executador{}
    //todas as interfaces são locais
    @Stateless
    public class AgendadorBean implements Executador, Agendador{
    ...
  }

  //todas as interfaces são remotas
  @Remote
  @Stateless
  public class AgendadorBean implements Executador, Agendador{
    ...
  }

Caso deseje que apenas uma das interfaces seja exposta, é só adicionar a anotação desejada:

  @Remote
  public interface Agendador{}

  //apenas a interface Agendador é exposta como remota
  @Stateless
  public class AgendadorBean implements Executador, Agendador{
    ...
  }

JSF 2.2 (JSR-344)

Algumas features que antes só estavam disponíveis através do Seam3 agora fazem parte da especificação. Isso acontece com a tag viewAction e a possibilidade de receber injeção de dependências via CDI em qualquer componente do JSF, como Validator, Converters e até mesmo em componentes customizados.

Uma nova annotation @ViewScoped foi criada em substituição a atual para permitir integração do CDI com ManagedBeans neste escopo. E falando em escopos, o @FlowScoped foi adicionado para ajudar na criação de fluxos pré-definidos, como wizards, sequências de passos em algum fluxo de negócio, etc.

Além destas, ainda há uma integração melhor com HTML5, suporte a configuração programática, um novo componente para upload de arquivos usando ajax, e muitas outras, como é possível ver na lista de novidades no JSF 2.2

JAX-RS 2.0 (JSR-339)

Agora com suporte a uma API de cliente, é possível implementar chamadas a um serviço rest de maneira portável entre os servidores sem a necessidade de bibliotecas externas:

  Client client = ClientFactory.newClient();

  //Dispara uma requisição GET para a url http://.../produtos?nome=Caneta
  Produto p = client.target("http://.../produtos")
                    .queryParam("nome", "Caneta")
                    .request().get(Produto.class);

Outras novidades são a integração com Bean Validation, suporte a requisições assíncronas tanto na API cliente quanto na servidor, filtros e interceptors.

JMS 2.0 (JSR-343)

JMS foi uma das especificações que mais sofreram alterações, removendo a maior parte do código desnecessário para enviar mensagens:

  @Stateless
  public class EnviadorDeMensagens
    @Resource(lookup = "jms/connectionFactory")
    ConnectionFactory connectionFactory;

    @Resource(lookup="jms/fila")
    Queue fila;

    public void sendMessageNew (String msg) {
      try (JMSContext context = connectionFactory.createContext();){
        context.send(fila,msg);
      }
    }
  }

Além de outras alterações e novas funcionalidades, como o suporte a Paas, melhorias nos Message Driven Beans e envio de mensagens com hora marcada.

Bean Validation 1.1 (JSR-349)

As anotações de validação agora podem ser utilizadas em parametros de métodos:

public void login (@NotNull String login, @NotNull String pass){
  ...
}

Componentes como ConstraintValidator agora são integrados ao CDI, além de outras pequenas mudanças.

Outras especificações foram adicionadas ao JavaEE, como JCACHE para gerenciamento de cache de objetos, Batch para execução de tarefas em lote, similar ao Spring Batch, JSON-P com as mesmas funcionalidades do JAX-B, mas para Json. Na lista completa de funcionalidades do JavaEE 7 você pode acompanhar todas as JSRs e conhecer mais sobre as novas especificações e evoluções da plataforma Java.

O que acha das novidades? O que você sente falta no desenvolvimento Java EE?

Você já conhece as apostilas abertas da Caelum. Disponíveis gratuitamente desde 2004 para download, elas são um diferencial nessa proposta pioneira da Caelum de difundir o conhecimento.

E as apostilas estão em constante evolução e inovação. Sempre atualizamos o conteúdo com novos exercícios e mais explicações – aliás, é por isso que você deve sermpre baixar a versão mais nova na página oficial. E sempre tentamos inovar na distribuição da apostila.

Na começo, publicamos PDFs pra você baixar e imprimir. Com a popularização dos ereaders, começamos a publicar versões de ebook em ePub e mobi (Kindle). Mas, às vezes, você quer apenas olhar um assunto rapidamente, ou mandar um link sobre algum tópico pra um amigo. Pra isso, lançamos 6 meses atrás as apostilas em HTML pra ler no navegador. Não precisa baixar nada, só clicar, ler, navegar, linkar.

A última inovação que acabamos de colocar no ar é suporte a leitura offline na versão HTML. Ou seja, você não precisa mais baixar o PDF ou os ebooks se quiser ler quando não estiver conectado a Internet. A versão HTML funciona em qualquer navegador moderno, incluindo tablets e smartphones, já que tem uma interface responsiva.

As novas apostilas HTML com suporte a offline juntam as vantagens das versões para download com as vantagens da Web. Para instalar, acesse o menu superior da apostila e vá na opção Leitura offline:

• Java e Orientação a Objetos
• Java para Desenvolvimento Web
• Laboratório Java com Testes, XML e Design Patterns
• Desenvolvimento Ágil para Web com Ruby on Rails 3
• Desenvolvimento Ágil para a Web 2.0 com VRaptor, Hibernate e AJAX
• Algoritmos e Estrutura de Dados em Java

E, claro, as outras opções para download (PDF, ePub, mobi) continuam disponíveis. Você escolhe a opção que for melhor pra você.

A implementação

O suporte a leitura offline é implementado usando a Application Cache API disponível no HTML 5. O suporte nos navegadores é muito bom: Chrome, Firefox, Opera, Internet Explorer (a partir da versão 10), iOS, Android e Blackberry.

A experiência na criação desse recurso gerou uma palestra sobre o HTML5 offline e Application Cache que você pode consultar para aprender mais. Se estiver curioso, dê uma espiada no arquivo de manifest da apostila FJ-11. É um arquivo texto bem simples de ler, e ele lista todos os componentes da apostila que serão baixados pelo navegador. A partir dele que é feita a instalação com a Application Cache API.

Essa novidade ainda está em beta, apesar dos testes extensivos que fizemos. Teste você também e deixe sua opinião nos comentários!

Quais versões de que browsers você deve suportar no seu website? Qual política deve ser adotada pela sua empresa?

Decisões difíceis, dado que tempo e verba são escassos. Muitos desistiam de suportar versões antigas do Internet Explorer, cortando uma fatia significativa de possíveis consumidores.

O fantasma do Internet Explorer assombrou a Web durante muito tempo. Navegadores ruins, não cumprimento dos padrões, problemas de segurança, péssima performance, e uma chatice pra testar os sites. Não mais. O mundo é outro hoje em dia e o tempo de fazer piada com o Internet Explorer está ficando pra trás.

O problema do IE está se resolvendo de várias maneiras:

• As versões mais novas são realmente muito boas – IE9 e IE10.
• A Microsoft fez um update automático para todos os usuários de IE levando à versão mais recente disponível. Isso fez IE6 e IE7 praticamente sumirem.
• Testar os sites no IE está muito fácil, inclusive no Mac e no Linux.
• Muita gente migrou para outros browsers – Chrome já é o browser mais usado no Brasil há bastante tempo!

Como testar no Internet Explorer no Windows, Mac e Linux?

Primeiro, só um serviço remoto de screenshots não resolve. Você precisa testar na sua máquina, usar o site. Pra isso, precisa instalar várias versões juntas. E o problema é que o IE vem embutido no Windows de tal forma que isso é impossível.

Existem algumas gambiarras que tentam fazer vários IEs rodarem ao mesmo tempo. Ou tem gente que só instala a versão mais nova e usa o modo de compatibilidade nas ferramentas pra emular os IEs velhos. Não faça isso, nada disso serve. Pra realmente testar o IE, você precisa de uma instalação limpa de cada um deles. Ou seja, você precisa de vários Windows.

Como fazer? Use máquinas virtuais, claro. Mas, até mês passado, isso significava comprar um Windows de cada versão (XP, Vista, 7 e 8). Não mais.

A Microsoft lançou máquinas virtuais oficiais com IE 6, 7, 8, 9, 10, no XP, Vista, Windows 7 e 8. Tudo legalizado, focado nos testes pra desenvolvedores Web. E mais: tem versões pra Windows, Mac e Linux, rodando em várias plataformas de virtualização: VMWare, VirtualBox e VirtualPC (Parallels a caminho). É só baixar e rodar.

Há o trabalho de abrir a VM, claro, toda vez que for testar. Mas, por favor, faça isso. Dica bônus: se você colocar 8GB de memória e um SSD na sua máquina, consegue rodar fácil 3 Windows ao mesmo tempo, além do seu sistema normal.

Quais versões do IE preciso testar?

Depende bastante do seu público. Mas já é meio consenso que IE6 e IE7 já eram. Claro, pode ser que seu público ainda use, então veja suas estatísticas.

O IE8 é um caso mais particular, já que é a última versão disponível no Windows XP, então muita gente ainda tem – 7,5% no Brasil em Janeiro/2013. Mesmo assim, muita gente já não suporta mais, como o Google.

Qual a política da Caelum?

Analisando os números do site da Caelum, vemos uma distribuição bem parecida com a população geral do Brasil: 60% de Chrome, 25% Firefox e 7,5% de todos os IEs.

Se observarmos as versões do IE então, vamos ver que IE9 e IE8 dominam, com o IE10 crescendo rápido. Mesmo assim, se calculasse com relação a total de usuários, teríamos: 4,3% de IE9, 2,4% de IE8, 0,5% de IE10, 0,24% de IE7 e 0,03% de IE6.

(E você pode comparar a evolução com esse post nosso de 2011, quando mostramos que 21% das pessoas usavam IE, sendo 16,8% só de IE8.)

Com isso, a política hoje da Caelum em 2013 é:

• Suportar IE8+ nos sites de audiência mais aberta (site principal, GUJ etc).
• Suportar IE9+ nos sites mais específicos (como plataforma Online)

Uma nota final sobre o IE10

O IE10 é um excelente navegador – até a Microsoft tá tirando sarro com isso, de tão inusitado, mas é verdade.

Um ponto importante: teste no IE10 também. Reparem nas estatísticas que IE10 já passou IE7+IE6 e já já passa IE8. A questão com o IE10 é que ele traz alguns desafios. Ele roda por enquanto só no Windows 8 e se integra de tal forma a ser o único browser disponível na versão tablet – e o “Metro Mode”. Quando sair a versão pra Windows 7 (esse semestre), deve passar todos os outros facilmente.

Hoje, pra testar o IE10, você precisa do Windows 8 (tem de graça lá no site da Microsoft de VMs). E existem 3 modos do IE10 que você precisa testar: Desktop-mode (IE normal), Metro mode, e Snap Mode. A boa notícia é que o IE10 é muito bom em padrões web, performance e usabilidade; não deve dar muito trabalho.

É isso. O cenário de testes e suporte ao IE tem melhorado a cada momento. As últimas versões são bastante boas, as versões antigas perdem market share rapidamente, e as novas VMs gratuitas disponibilizadas pela Microsoft facilitam muito o desenvolvimento. Por isso, considere fortemente incluir as versões antigas.

E qual é sua política de suporte a browsers? Alguma dica para facilitar esse trabalho? A gente discute esses e outros pontos sobre desenvolvimento Web no curso de front-end da Caelum.

No desenvolvimento mobile os testes podem ser ainda mais complicados e a variação de resolução, viewport e fabricantes deixa tudo desafiador. Participe do MobileConf Brasil, que acontecerá dia 5 de abril e conheça mais!