Um exemplo de chat com Ruby On Rails e Juggernaut (utilizando AJAX Push)

English Version here
Antes de iniciar a implementação do chat, nos precisamos instalar as dependências do juggernaut, ele precisa das gems json e eventmachine instaladas, para instalar ambas basta executar o seguinte comando:

  • gem install -y json eventmachine

Agora estamos prontos para começar a brincar …
Primeiro, vamos criar uma aplicação rails e instalar o plugin juggernaut com os seguitnes comandos:

  • rails -d sqlite3 chattest
  • cd chattest
  • script/plugin install svn://rubyforge.org//var/svn/juggernaut/trunk/juggernaut

O Juggernaut usa um servidor externo implementando Flash XML Push, e precisamos configurar este servidor, então vamos editar o arquivo: config/juggernaut.yml
Coloquei aqui no blog apenas as configurações que precisei alterar

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
PUSH_PORT: 8080
...
DEFAULT_CHANNELS: 
- "chat"
...
PUSH_HELPER_HOST: "localhost"
...
SECRET: "481516232342edededededed"
...
LOGIN_GET_URL: "http://localhost:3000/session/login"
LOGOUT_GET_URL: "http://localhost:3000/session/logout"
...
SESSION_ID: "_chattest_session_id"
...
BASE64: true

Precisei alterar PUSH_PORT Por que no linux apenas o root pode ouvir em portas inferiores a 1024, e mesmo assim eu não acho que a porta 443 padrão seja uma boa escolha, ja que esta é a porta padrão do protocolo HTTPS.
A linhe com PUSH_HELPER_HOST precisa ser alterada para o mesmo nome do servidor que for utilizado para a acessar a aplicação, em desenvolvimento, localhost deve resolver, mas não esqueça de alterar esta configuração quando for fazer o deploy do seu chat.
LOGIN_GET_URL e LOGOUT_GET_URL são utilizadas para notificar a aplicação quando um usuário conecta ou desconecta, apenas o desconectar é realmente importante para nós.
A SESSION_ID precisa ser igual ao nome do cookie utilizado como marcador de sessão da aplicação, no rails 1.2.x fica no application controller, no rails 2.0 esta configuração vai para o enviroment.rb
e BASE64 é a configuração mágica que habilita o uso dos helpers do rails para geração do Javascript que vai ser utilizado.

Agora vamos começar a criar o layout da aplicação.
Crie um arquivo de nome pubic/stylesheets/public.css com o seguinte conteúdo:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
body {
  background-color: white;
}
#users {
  float: left;
  width: 200px;
  height: 400px;
  border-style: inset;
  overflow: auto;
  color: white;
  background-color: gray;
}
#dasd {
  height: 400px;
  margin-left: 5px;
  border-style: inset;
  overflow: auto;
  color: white;
  background-color: gray;
}
#controls {
  clear: both;
  padding: 0 0 0 0;
  height: 55px;
  vertical-align: top;
  border-style: inset;
  overflow: auto;
  color: white;
  background-color: gray;
}

e o arquivo: app/views/layouts/application.rhtml com o seguinte conteúdo.

1
2
3
4
5
6
7
8
9
10
<html>
  <head>
    <title>Chat Test</title>
    <%= stylesheet_link_tag 'public' %>
    <%= javascript_include_tag :defaults %>
  </head>
  <body>
    <%= yield %>
  </body>
</html>

Com o layout pronto (sim, esta bem feio, mas eu não sou designer eu sou um desenvolvedor, então solicite ao designer da sua equipe a criação de um novo layout para este chat :D ) vamos criar o código fonte necessário e o banco de dados com estes 4 comandos:

  • script/generate model online_user username:string session_id:string last_seen:date online:boolean
  • script/generate controller session
  • script/generate controller chat index
  • rake db:migrate

Layout pronto, arquivos criados, agora só precisamos escrever o código da aplicação :D
Vamos começar editando o model OnlineUser (app/model/online_user.rb) para adicionar algumas validações, elas não são realmente necessárias, são resquícios da primeira tentativa de implementação do chat, mas mesmo assim mantive elas no código :D

1
2
3
4
class OnlineUser < ActiveRecord::Base
	validates_presence_of :username, :session_id, :last_seen
	validates_uniqueness_of :username, :if => Proc.new {|user| user.online }
end

Agora a view principal da aplicação no arquivo:app/views/chat/index.rhtml

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
<!-- Register with Juggernault -->
<%= listen_to_juggernaut_channels [:generic],session.session_id %>
<!-- The Users List -->
<div id="users">
  <ul id="users_list"></ul>
</div>
<!-- The messages pane -->
<div id="dasd"></div>
<!-- The controls pane (login and send messages) -->
<div id="controls"><%= render :partial => 'login' %></div>
<!-- An util javascript to scroll the messages window -->
<script type="text/javascript">
  function scrollMessages(){
    $('dasd').scrollTop = $('dasd').scrollHeight;
  }
</script>

Como podem ver é bem simples, apenas 3 DIVs, um javascript para fazer o scroll da tela de mensagens e um comando para inicializar o juggernaut no canal “generic” e utilizando o session_id como identificador individual do usuário.
A DIV de mensagens esta com o id dasd por que eu estava testando algumas possibilidades de conflito e esqueci de mudar o ID depois :D

Como pode ser visto na página index, precisaremos de um partial de nome “login” e vamos também precisar de um de nome “controls”, então vamos começar codificando o partial “controls”: app/views/chat/_controls.rhtml

1
2
3
4
5
6
<% form_remote_tag(
      :url => { :action => :say },
      :complete => "$('message').value = '';$('message').focus();" ) do %>
      <%= text_field_tag( 'message', '', { :size => 90, :id => 'message'} ) %>
      <%= submit_tag "Send" %>
  <% end %>

Bastante simples, possui apenas uma tag remote_form_tag que fara um post para a action “say”, um campo de texto para a mensagem e um botão de submit, quando o formulário é enviado o foco volta para o campo message para que o usuário possa digitar a próxima mensagem …

E o partial de login: app/views/chat/_login.rhtml

1
2
3
4
5
6
7
<%= "#{@message}<br/>" if @message %><% form_remote_tag(
      :url => { :action => :login },
      :complete => "$('username').value = ''",
      :after => "$('login').disabled = true" ) do %>
      <%= text_field_tag( 'username', '', { :size => 90, :id => 'username'} ) %>
      <%= submit_tag "Join", :id => 'login' %>
  <% end %>

Bastante parecido com o anterior, mas faz o post para uma action de nome “login”, e o javascript agora desabilita o botão quando o formulário é enviado, e também possui uma mensagem que deve aparecer para o usuário informando que o apelido ja esta sendo utilizado.

Agora todas as views ja estão prontas, podemos passar para a codificação da lógica da aplicação.
Como podemos ver nas views até agora, precisaremos de um controller de nome “chat” com dois métodos: login e say
vamos analisar um pouco o código do chat controller: app/controllers/chat_controller.rb

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
class ChatController < ApplicationController
  #this method does not need to exist, but I like to see it here, it only needs to render the index.rhtml view
  def index
  end
  def login
    #creates a new OnlineUser record, this is used to store who are the users that are online now
	@user = OnlineUser.new
	@user.username = Juggernaut.html_and_string_escape params[:username]
	@user.session_id = session.session_id
	@user.online = true
	@user.last_seen = Time.now
        #if we can save, it means that there is no other user with the same nick online, so this user can join the chat
	if @user.save
          #let's save the username in the session for future reference
	  session[:username] = @user.username
          #if there are online users, fill the users box for the new user know who is online
	  @users = OnlineUser.find(:all, :conditions => ["online = true and id != ?", @user.id]) 
          if @users.size >0 
            data = render_to_string(:update) do |page|
              @users.each {|u|
                page.insert_html :bottom, :users_list, %Q{<li id="user_#{u.username}">#{u.username}</li>}
              }
	    end
            #send the javascript only to the new user
            Juggernaut.send_to(@user.session_id, data)
          end
          #create a javascript call to add the new user to the end of the online users list
          data = render_to_string(:update) do |page|
            page.insert_html :bottom, :users_list, %Q{<li id="user_#{@user.username}">#{@user.username}</li>}
            page.insert_html :bottom, :dasd, "<b>user #{@user.username} just joined the chat</b><br/>"
          end
          #add the new user to the chat channel
          Juggernaut.add_channel(@user.session_id, 'chat')
          #send the javascript to all users in the chat channel
          Juggernaut.send_data(data, 'chat')
	  render(:update) do |page|
	    page.replace_html 'controls', :partial => "controls"
          end
	else
          @message = 'This nick name is already in use, please choose another'
	  render(:update) do |page|
	    page.replace_html 'controls', :partial => "login"
	  end
	end
  end
 
  def say
    #escape the message, that way the user can not harm others sending HTML ot JavaScript commands
    message = "#{session[:username]}: #{Juggernaut.html_and_string_escape(params[:message])}"
    #create a javascript to add the new message to the end of the messages screen and scroll the div to the bottom
    data = render_to_string(:update) do |page|
      page.insert_html :bottom, :dasd, "#{message}<br/>"
      page.call "scrollMessages"
    end
    #send the message to all users
    Juggernaut.send_data(data, 'chat')
    render :nothing => true
  end
end

O método say é bastante simples, então vamos começar analisando este:
Primeiro a mensagem é reconstruída adicionando o nome do usuário no inicio da mensagem enviada removendo todos os possíveis códigos HTML ou Javascript para garantir a segurança dos outros usuários.
Então é construido um Javascript utilizando o JavaScriptBuilder do rails e o método render_to_string para adicionar a nova mensagem no final da div “dasd” e fazer o scroll caso necessário.
Então este Javascript é enviado para todos os clientes que estão ouvindo o canal “chat”.

Agora um pouco sobre o método login:

  • nas linhas 7 a 11 apenas criamos e configuramos um model OnlineUser.
  • Se o novo usuário puder ser salvo no banco de dados então não existe nenhum outro usuário online com o mesmo apelido, e podemos continuar, caso contrário mostramos uma mensagem para o usuário para que este escolha outro apelido
  • nas linhas 17 a 23 é criado um javascript para popular a DIV users do novo usuário com a lista dos usuários que ja estavam online
  • E na linha 25 este código é enviado apenas para este usuário.
  • entre a linha 28 e 31 é criado um javascript que vai adicionar o novo usuário a div users de todos os usuários e enviar uma mensagem para todos dizendo que o chat possui um novo participante.
  • na linha 33 o novo usuário é adicionado ao canal “chat”
  • na linha 35 este script é enviado para todos os usuários
  • E entre as linhas 36 e 38 é utilizado o helper de ajax padrão do rails para substituir o conteúdo da DIV controls com a partial controls que possui o formulário que permite que o usuário envie mensagens para outros integrantes do chat.

Esta é quase toda a lógica que precisamos, a única parte que falta é remover um usuário da lista de usuários online de todos os participantes quando este fechar o browser ou deixar o chat por qualquer motivo, para isto vamos ao método logout do controller session: app/controllers/session_controller.rb

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
class SessionController < ApplicationController
  #Called when a user disconnect (a refresh in the browser causes this to be called too)
  def logout
    #search for the user record using the session_id
    @u = OnlineUser.find_by_session_id(session.session_id)
    reset_session
    #if a user was found
    if @u
      username = @u.username
      #remove it from the database
      @u.destroy
      #remove from the online users list from all users, and tell others this user left the chat
      data = render_to_string(:update) do |page|
        page.remove "user_#{username}"
        page.insert_html :bottom, :dasd, "<b>User #{username} left the chat</b><br/>"
      end
      Juggernaut.send_data(data,'chat')
    end                
    render :nothing => true
  end
 
  def login
    render :nothing => true
  end
end

O método login não faz nada, pois não precisamos desta notificação para o chat, então vamos a descrição do método logout …

  • Na linah 5 procuramos o usuário no banco de dados usando o id da sessão
  • se um usuário é encontrado
  • ele é removido do banco de dados na linha 8
  • e entre as linhas 13 e 17 é criado um javascript que remove o usuário da lista de usuários online e adiciona uma mensagem avisando que o usuário deixou o chat, e no final este script é enviado para todos os usuários ainda ativos

E isto é tudo pessoal! (isto só fica engraçado em ingles :( )
Agora só falta executar a aplicação.
Para executar esta aplicação, precisamos iniciar o servidor do Rails como padrão, e então iniciar o push_server, para fazer isto basta executar os seguintes dois comandos.

  • script/server
  • script/push_server

E acessar o seu chat novo em folha no endereço: http://localhost:3000/chat
Eu criei este exemplo emquanto estudava um pouco sobre o Juggernaut, é possível que existam maneiras mais fáceis de implementar isto, mas eu acredito que seja um bom ponto de partida.

Quaisquer dicas para melhorar o exemplo são muito bem vindas.

Se você gostou deste post, lembre-se de assinar o RSS feed do blog, para ser notificado de novos posts!

Recebi a camiseta do Eclipse :D

Recebi ontem a camiseta do Eclipse, por causa do review que escrevi sobre o Europa :D

Eu preferia a jaqueta, mas como o review foi publicado em portugues eu ja sabia que não ia ganhar ela mesmo :D

PS.: a camiseta polo é bem legal, com o logo do eclipse bordado :D

Se você gostou deste post, lembre-se de assinar o RSS feed do blog, para ser notificado de novos posts!

Integração contínua sincrona com Rails/Rake

English version here

Bom, integração contínua acho que todos concordam que é uma necessidade em qualquer projeto de software, mas a integração contínua assíncrona utilizada normalmente tem alguns problemas, como por exemplo:

  • O código mesmo não passando nos testes é comitado
  • Os testes só serão executados algum tempo depois pelo servidor de integração, e só no final disto é que o desenvolvedor ficara sabendo se ocorreu algum problema de integração com o código que ele ja não esta mais trabalhando
  • O desenvolvedor provavelmente ja esta no meio de outra tarefa quando receber o e-mail dizendo que ocorreu algum problema com a tarefa anterior

Eu não estou dizendo que não é interessante existir um servidor de integração, é interessante para que todos os envolvidos no projeto tenham sempre acesso aos relatórios e a última versão do sistema compilado, mas não acho que deva ser dele a tarefa de integrar o sistema.

Ou seja, o que antigamente era o servidor de integração, agora passa a ser apenas um servidor de builds, e gerador de relatórios sobre o código fonte e progresso do projeto.

O ideal é que o desenvolvedor, durante o processo de commit, seja obrigado a executar todos os testes, e este commit só ser realmente executado se todos os testes passarem.

Claro que isto pode ser melhorado, adicionando ainda algumas restrições, por exemplo, exigir uma cobertura de testes mínima, mas no meu caso, eu desenvolvi esta task do Rake para um projeto em que estou trabalhando sozinho, e estou utilizando o GIT para controle de versões (escreverei um post sobre o GIT ainda esta semana se der tempo), e estou utilizando integração sincrona também em alguns projetos com Java, em outra oportunidade escrevo sobre o processo com Java.

Estou adotando esta prática de integração sincrona para todos os novos projetos da minha empresa e dos clientes que aceitam a idéia.

Mas voltando ao assunto, é bastante fácil implementar isto em um projeto Rails, basta seguir estes passos:

1 - criar um arquivo de nome ‘git.rake’ dentro do diretório lib/tasks com o seguinte conteúdo:

namespace :git do
  desc "Update every thing before the tests"
  task :update do
    puts "Lets update it all, but we are using GIT so we already have the latest source for this repo"
  end
  desc "Run all tests, if all are OK, then commit every thing to the git local repository"
  task :commit => [:update, :test] do
    puts "No test failures, now we can commit it all"
    exec 'git commit -a'
  end
end

Como podem ver esta task do Rake é bem simples, e com certeza isto vai aumentar muito a qualidade do projeto!

2 - sempre ao final de uma tarefa, em vez de executar o comando “git commit -a”, executar o comando: “rake git:update”

Só isto, a partir de agora você esta utilizando integração continua sincrona :D

Claro que esta task do Rake pode ser melhorada ainda, pode ser configurado por exemplo um pull de um repositório central, ou um update de um subversion ou qualquer coisa do gênero, mas acho que ja serve como exemplo para quem quiser começar a utilizar integração sincrona.

Se todos os testes passarem, o GIT vai abrir o VIM para que o desenvolvedor edite a mensagem de commit, depois da mensagem editada o código alterado é comitado sem problemas e sem medo de quebrar o próximo build com tudo integrado.

E vocês, o qu acham deste processo de integração continua? preferem sincrona ou assincrona? por que?

Só para lembrar: Estão abertas as incrições para o curso de Java Server Faces da Tech Office

Se você gostou deste post, lembre-se de assinar o RSS feed do blog, para ser notificado de novos posts!

Mais uma turma aberta do Curso de JSF da Tech Office (Curso rápido, bom e barato :D )

Estão abertas as inscrições para mais uma turma aberta do excelente curso de Java Server Faces da Tech Office!

O curso vai acontecer dia 27/10/2007, ou seja daqui a duas semanas :D

Resumo do programa:

  • O que é JSF;
  • Escrevendo Managed Beans;
  • Criando páginas JSF;
  • Definindo a navegação entre páginas;
  • Modelo de componentes;
    • Validação
    • Conversão de dados
    • Eventos e Listeners
    • Componentes da implementação de referência
    • Criando um componente simples
  • Ciclo de vida de uma requisição JSF;
  • Localizando a aplicação;
  • Fluxo de processamento de uma requisição JSF;
  • O arquivo faces-config.xml;
  • Adicionando suporte a AJAX em uma aplicação JSF.
    • Ajax4JSF
    • ICE Faces

O material do curso foi totalmente reescrito e melhorado, isto considerando que o material do último curso já foi bastante elogiado e este esta ainda melhor.

O curso é 100% prático e vamos desenvolver uma loja de musicas durante o curso (exatamente em um curso de 8h), claro que não é um submarino da vida, mas serve como exemplo ou até mesmo como base para continuar o desenvolvimento depois …

Mais informações sobre o curso aqui.

Então o que você esta esperando? clique aqui para se inscrever :D

E se você procura um curso de Ruby On Rails, JPA + JSP/Servlets + EJB3 ou de Spring Framework, de uma olhada na agenda de treinamentos da Tech Office. (Sim isto mesmo, a data da próxima turma de Ruby On Rails já esta definida :D )

Se você gostou deste post, lembre-se de assinar o RSS feed do blog, para ser notificado de novos posts!

Blog em inglês

Faz tempo que to pensando em começar a escrever em inglês, mas acabava nunca montando o tal blog.

Sexta a noite resolvi começar a usar o dominio que eu comprei a algum tempo atraz o http://www.urubatan.info.

Os primeiros posts vão ser traduções do que eu postei por aqui, mas em pouco tempo vai ter conteúdo original por la também, a maior parte dos “how to” que eu escrever vou publicar por la, mas ainda não decidi qual vai ser a real diferença dos dois blogs, a principio a idéia é só atingir uma audiencia maior, ja que neste aqui a idéia é publicar coisas em portugues para quem não fala ingles ainda :D

Bom acho que era isto, espero ter tempo para manter os dois atualizados, mas este aqui é prioridade ja que ja tem muita gente que passa por aqui todos os dias :D

Pretendo ir trabalhar fora do brasil em uns 2 ou 3 anos, então o outro blog vai servir também (se tudo der certo) para que eu fique um pouco mais conhecido fora do brasil (se eu conseguir leitores para ele :D )

Uma das diferenças é que vou publicar alguns posts sobre mobilidade com symbian também por la, o que eu publicava antes no blogspot, só não migrei os posts ainda :D

Bom era isto, este post foi só para fazer um pouquinho de propaganda do blog novo.

http://www.urubatan.info

Se você gostou deste post, lembre-se de assinar o RSS feed do blog, para ser notificado de novos posts!

Frase do dia - politica

Acabei de ouvir isto no filme “Homem do ano”

Politicos são como fraldas, ambos devem ser trocados frequentemente e pelo mesmo motivo! 

Acho que se o povo começar a pensar assim é possível que as coisas melhores um pouco :D

Se você gostou deste post, lembre-se de assinar o RSS feed do blog, para ser notificado de novos posts!

Alteração dos permalinks do blog

Acabei de alterar os permalinks do blog, antes era /ano/mes/dia/nomedopost/ agora coloquei só /nomedopost/

Isto deve gerar URLs bem menores, e se tudo der certo, os links antigos não vão parar de funcionar :D

Espero não perder muitas posições no google por causa disto, caso contrário volto  a configuração anterior :D

Estou utilizando o plugin Permalinks Migration do wordpress para fazer a mágica :D

Se você gostou deste post, lembre-se de assinar o RSS feed do blog, para ser notificado de novos posts!

Ruby fora dos trilhos - Nitro and Og!

O Ruby começou a ganhar espaço nas empresas e na blogosfera principalmente por causa do Rails, mas o Rails não é o único framework para desenvolvimento Web em Ruby, um destes outros frameworks é o Nitro Framework ele tem mais ou menos a mesma idade do Rails, mas tem muito menos documentação, e que eu saiba bem menos usuários também.

Neste post vou falar um pouquinho dos meus primeiros 30 minutos com o Nitro …

Uma das coisas que eu mais gosto do Rails e que não é possível de se fazer com o Nitro é simplesmente alterar uma classe com o servidor rodando e as alterações se refletirem automagicamente no browser, mas vamos deixar isto de lado por enquanto …

O nitro diferente do Rails tem mais de uma abordagem para o desenvolvimento, é possível desenvolver aplicações utilizando MVC como o Rails, mas também é possível desenvolver aplicações direto em páginas como no ASP ou no PHP.

Para começar com o nitro basta seguir este passo a passo:

  • gem install -y nitro (isto vai instalar o nitro e as suas dependências)
  • gen app rocketpower (isto vai criar uma aplicação nitro)
  • cd rocketpower
  • ruby run.rb (eu precisei editar o arquivo e adicionar um require ‘rubygems’ na segunda linha)
  • acessar o endereço http://locahost:9000

Pronto, você esta executando a sua primeira aplicação Nitro!

Até o momento estou achando o Nitro muito confuso, provavelmente por causa da falta de documentação, ou dos exemplos toscos, mas seguem algumas coisinhas legais …

Para programar orientado a páginas, basta criar uma página no diretório public com a extensão .xhtml e quando quiser escrever código Ruby basta coloca-lo entre <?r e ?> ou então quando for para simplesmente imprimir texto usar diretamente #{…} como em qualquer string Ruby.

O nitro não possui uma estrutura de diretórios padrão como o Rails, os arquivos com o código da aplicação são declarados diretamente utilizando require no run.rb, acho que por isto não existe reload automático.

O nitro não obriga a extender uma classe para criar uma classe persistente (na verdade não é o Nitro que faz isto é o Og que é o framework de persistencia utilizado pelo Nitro), ele vai persistir qualquer coisa que tiver um método “serializable_attributes” que é criado automagicamente quando se utiliza os helpers para definição de campos do Og (setting).


Ele não tem nada parecido com migrations, pelo menos não que eu tenha encontrado até agora.

O código do Nitro e do Og eu achei muito mais simples de ler e entender o que esta acontecendo do que o código do Rails, já o código das aplicações escritas com o Nitro eu achei muito bagunçado, parece a grande maior parte dos códigos PHP que se encontra por ai (nada contra PHP apenas contra péssimos programadores PHP que infelizmente são a maioria).

Uma coisa que eu achei bem legal no nitro, é que os parametros para um método de um controller são recebidos como parâmetros do método mesmo e não no mapa “params”.

Bom, o exemplo que eu queria fazer para este post vai ficar para outra hora, pois vou precisar estudar um pouco mais o Nitro e o Og para poder fazer qualquer coisa que não me deixe envergonhado, achei os exemplos bagunçados demais, muitas classes por arquivo e coisas assim …

Por enquanto o Og parece muito verde ainda, ele havia passado um bom tempo com o desenvolvimento quase parado, mas voltou a se mexer agora com o “boom” do Rails.

Ele tem algumas coisas legais, mas por enquanto fico com o Rails :D

  1. Mais sobre Ruby e Rails
  2. Site oficial do Rails
  3. Mais sobre o Nitro
  4. Tutorial sobre Rails
  5. Curso de Ruby On Rails

Se você gostou deste post, lembre-se de assinar o RSS feed do blog, para ser notificado de novos posts!

Alguns bits de tecnologia :D

Segue mais uma daquelas grandes coletâneas de links que falam de tudo um pouco, tem Java, .NET, Ruby, Rails, Python, …

E este último merece um certo destaque, um post sobre a péssima postura da Aptana para com a comunidade, quando eles pegaram um monte de código que foi escrito pela comunidade, juntaram com o código do Eclipse e resolveram mudar a licensa de tudo, se alguem esquentar a cabeça com isto eles poderiam até mesmo ser processados, por que estão quebrando a licensa do eclipse e por conseqüência também do Radrail, e quem baixar os fontes hoje não pode mais criar uma distribuição diferente baseado nele.

Bom, acho que era isto, vou tentar escrever com mais frequencia para não acumular tanta coisa junto :D

Se você gostou deste post, lembre-se de assinar o RSS feed do blog, para ser notificado de novos posts!

Nova feature do .NET: processar você(framework) por todas as features que você tem

Brincadeiras a parte, saiu mais um dos comerciais do pessoal do RailsEnvy.com, desta vez é o Ruby on Rails X .NET …

Os comerciais não são a coisa mais engraçada da face da terra, mas alguns deles até que são legais …
Este último que não gostei muito, este outro com .NET também foi mais legal

Se você gostou deste post, lembre-se de assinar o RSS feed do blog, para ser notificado de novos posts!

O pessoal de sampa esta se mexendo, mas nos aqui do RS ja vamos começar também

Ruby On Rails LogoSe você mora em SP e programa em rails, acha interessante ou quer saber do que se trata, de uma passada no blog do Akita e participe do encontro que eles estão organizando.

Mas se você mora no RS não se desanime por que nos ja estamos começando a organizar algo parecido por aqui também :D

Por falar nisto ja temos uma data para a segunda turma do curso de Ruby on Rails da Tech Office, além de cursos de Spring Framework, JSF e um curso de JPA + Servlets/JSP + EJB 3 ja podem se inscrever para qualquer um deles :D

Se você gostou deste post, lembre-se de assinar o RSS feed do blog, para ser notificado de novos posts!

eSWT de bolso! Interfaces decentes para celulares Symbian

Um dos maiores problemas do Java ME (CLDC/MIDP) é a completa escassez  de componentes para UI, é simplesmente impossível desenvolver uma aplicação mais complexa com Java ME sem ter que re-inventar a roda  e recriar todos os componentes de alto nível utilizando Canvas, e isto é assim por que o maior objetivo do CLDC/MIDP é rodar em todo e qualquer celular, e para isto eles precisam alinhar os recursos por baixo, ou seja, suportar mesmo nos telefones mais poderosos (que não são mais a minoria) apenas os recursos gráficos dos celulares mais podrinhos.

A nokia sabendo disto, faz algum tempo que ja suporta eSWT nos celulares Series 80, mas isto não ajuda muito pois estes tem apenas uns 3 ou 4 modelos e ja suportavam CDC/Personal Profile, o que ja permitia até mesmo o uso de SWING, por tanto não sofriam tanto com este alinhamento por baixo (CDC/Personal Profile é a configuração para PDAs, e não PALM não suporta CDC palm é podre :D ).

Mas “Seus problemas acabaram” ou quase …

Faz bastante tempo que esta sendo prometida pela nokia uma implementação do eSWT para Series 60  (Todos os NSeries, ESeries e quase todos os modelos mais novos), e pelo que foi anunciado no Forum Nokia acabou de ser lançado o plugin de eSWT para o S60 3rd FP2 SDK, ou seja um plugin para desenvolvimento de interfaces eSWT para o kit de desenvolvimento para celulares Symbian 9 (ou Series 60 3rd edition), mas infelizmente apenas para o Feature Pack 2, ou seja, não existe ainda no mercado nenhum celular que implemente o Feature Pack 2 :(

Mas pelo menos  agora existe uma luz no final do túnel, poderemos em breve desenvolver aplicações com UI SWT sobre CLDC/MIDP para celulares Symbian, e com alguma sorte, vai sair também um .sis para adicionar este suporte aos celulares Symbian S60 3rd edition que ja estão no mercado (como o meu N80 por exemplo).

Se você gostou deste post, lembre-se de assinar o RSS feed do blog, para ser notificado de novos posts!

Rails 1.2.4 - release de manutenção liberada sexta feira passada

Ruby On Rails LogoAcabou de ser liberada uma release de manutenção do Rails.

Esta release tem poucas correções, algumas importantes de segurança, correção de encoding para JSON …

Mas o mais importante é que neste release serão gerados logs de deprecation para tudo o que não vai mais ser suportado no Rails 2.0.

Por tanto atualize a sua aplicação e preste atenção nos logs se pretende utilizar o Rails 2.0 em breve :D

Se você gostou deste post, lembre-se de assinar o RSS feed do blog, para ser notificado de novos posts!

SCEA 5 - Impressões sobre a prova e comentários sobre o conteúdo

Vou começar agradecendo ao todos os que me desejaram boa sorte no post anterior. E também lembrar que não posso escrever aqui quais questões cairam realmente na prova por causa do NDA que precisamos concordar antes do inicio de qualquer prova de certificação.

Mas vamos ao que interessa, dicas para quem ainda vai fazer a prova e comentários em geral (pelo menos eu acho que interessa :D )

  • A prova é cansativa, descansem bastante antes de ir fazer a prova, são 153 questões, e vocês tem 4:30h para responder todas, eu levei 3:30h.
  • Tem muitas questões com um texto bem grande descrevendo um problema qualquer, e a questão é: qual seria a melhor opção para este problema, ou quais duas tecnologias a baixo podem/não podem ser utilizadas para resolver este problema.
  • A SUN concorda que JSF tem problemas para ser indexado por search engines, e é bom que vocês lembrem disto.
  • Design Patterns, Design Patterns, Design Patterns, tem muitas questões sobre Design Patterns na prova
    • É preciso praticamente ter no sangue os patterns do GoF e conhecer bem os padrões do Java EE
  • É imrpescindivel conhecer toda a stack Java EE
    • Para que serve Servlet
    • Para que serve JSP
    • Para que serve JSF
    • Para que serve JMS
    • Para que serve JMX
    • Para que serve EJB
    • Quais tipos de EJB podem ou não ser transformados em web services
    • Como implementar e acessar web services
    • Segurança declarativa e programatica, quando utilizar cada uma
      • Ambiente Java EE (EJB3)
      • Servlets + JSP
      • Applets
      • JNLP
    • O que tem suporte a JTA, como é este suporte, excessões, …
    • O que é e para que serve JCA
  • Volto a dizer, é preciso conhecer muito bem Design Patterns.

Acho que foi mais ou menos isto, achei a prova muito cansativa, e a maioria das questões muito extensas.

Lembrei que eu odeio aquelas questões de arrastar quadrinhos.

Falando nisto, alguem sabe para que serve o pattern Mediator? e o pattern Strategy?

Bom, boa sorte para quem ainda vai fazer a prova, espero que este post ajude em alguma coisa :D

Se quiserem perguntar alguma coisa é só deixar um comentário.

PS.: O resultado da prova não sai na hora por ser uma prova beta, aparece só a mensagem dizendo que você vai receber o resultado entre 6 e 8 semanas, agora vou correr atraz de descobrir como vai funcionar o esquema para a segunda parte da prova :D

Se você gostou deste post, lembre-se de assinar o RSS feed do blog, para ser notificado de novos posts!

SCEA 5 - Sun Certified Enterprise Architect 5 - Saindo para a prova

Estou saindo agora para fazer a prova, espero ir bem, pois estudei muito pouco, marquei a prova sexta passada e a única data disponível era hoje :(

Queria ter marcado a prova mais para o final do mes para ter tempo de estudar …

Mas seguem os objetivos da prova, só pro cima o que eu estudei …

Application Design Concepts and Principles

1.1 Explain the main advantages of an object oriented approach to system design including the effect of encapsulation, inheritance, delegation, and the use of interfaces, on architectural characteristics.
1.2 Describe how the principle of “separation of concerns” has been applied to the main system tiers of a Java EE application. Tiers include client (both GUI and web), web (web container), business (EJB container), integration, and resource tiers.
1.3 Describe how the principle of “separation of concerns” has been applied to the layers of a Java EE application. Layers include application, virtual platform (component APIs), application infrastructure (containers), enterprise services (operating system and virtualization), compute and storage, and the networking infrastructure layers.

Estudei muito pouco aqui, espero que a experiência profissional me ajude nesta:D
Common Architectures

2.1 Explain the advantages and disadvantages of two tier architectures when examined under the following topics: scalability, maintainability, reliability, availability, extensibility, performance, manageability, and security.
2.2 Explain the advantages and disadvantages of three tier architectures when examined under the following topics: scalability, maintainability, reliability, availability, extensibility, performance, manageability, and security
2.3 Explain the advantages and disadvantages of multi-tier architectures when examined under the following topics: scalability, maintainability, reliability, availability, extensibility, performance, manageability, and security.
2.4 Explain the benefits and drawbacks of rich clients and browser-based clients as deployed in a typical Java EE application.
2.5 Explain appropriate and inappropriate uses for Web Services in the Java EE Platform

Integration and Messaging

3.1 Explain possible approaches for communicating with an external system from a Java EE-based system given an outline description of those systems and outline the benefits and drawbacks of each approach.
3.2 Explain typical uses of Web Services and XML over HTTP as mechanisms to integrate distinct software components.
3.3 Explain how Java Connector Architecture and JMS are used to integrate distinct software components as part of an overall Java EE application.

Business Tier Technologies

4.1 Explain and contrast uses for Entity Beans, Entity Classes, Stateful and Stateless Session Beans, and Message Driven Beans and understand the advantages and disadvantages of each type.
4.2 Explain and contrast the following persistence strategies: Container Managed Persistence (CMP) BMP, JDO, JPA, ORM and using DAOs (Data Access Objects) and direct JDBC-based persistence under the following headings: ease of development, performance, scalability, extensibility and security.
4.3 Explain how Java EE supports the deployment of server-side components implemented as Web Services and the advantages and disadvantages of adopting such an approach.
4.4 Explain the benefits of the EJB3 development model over previous EJB generations for ease of development including how the EJB container simplifies EJB development.

Web Tier Technologies

5.1 State the benefits and drawbacks of adopting a web framework in designing a Java EE application
5.2 Explain standard uses for JSP and Servlet technologies in a typical Java EE application.
5.3 Explain standard uses for JSF technology in a typical Java EE application.
5.4 Given a system requirements definition, explain and justify your rationale for choosing a web-centric or EJB-centric implementation to solve the requirements. Web-centric means that you are providing a solution that does not use EJBs. EJB-centric solution will require an application server that supports EJBs.

Basicamente JSF, JSP e Servlets, ja preparei bastante material para curso, e estudei bastante :D

Applicability of Java EE Technology

6.1 Given a specified business problem, design a modular solution implemented using Java EE which solves that business problem.
6.2 Explain how the Java EE platform enables service oriented architecture (SOA) -based applications.
6.3 Explain how you would design a Java EE application to repeatedly measure critical non-functional requirements and outline a standard process with specific strategies to refactor that application to improve on the results of the measurements.

Isto é basicamente esperiência profissional, Trabalho com isto o tempo todo :D

Patterns

7.1 From a list, select the most appropriate pattern for a given scenario. Patterns are limited to those documented in the book - Alur, Crupi and Malks (2003). Core J2EE Patterns: Best Practices and Design Strategies 2nd Edition and named using the names given in that book.
7.2 From a list, select the most appropriate pattern for a given scenario. Patterns are limited to those documented in the book - Gamma, Erich; Richard Helm, Ralph Johnson, and John Vlissides (1995). Design Patterns: Elements of Reusable Object-Oriented Software and are named using the names given in that book.
7.3 Select from a list the benefits and drawbacks of a pattern drawn from the book - Gamma, Erich; Richard Helm, Ralph Johnson, and John Vlissides (1995). Design Patterns: Elements of Reusable Object-Oriented Software.
7.4 Select from a list the benefits and drawbacks of a specified Core J2EE pattern drawn from the book – Alur, Crupi and Malks (2003). Core J2EE Patterns: Best Practices and Design Strategies 2nd Edition.

Aqui estudei bastante, li a descrição de vários patterns, espero não me confundir na hora …

Security

8.1 Explain the client-side security model for the Java SE environment, including the Web Start and applet deployment modes.
8.2 Given an architectural system specification, select appropriate locations for implementation of specified security features, and select suitable technologies for implementation of those features
8.3 Identify and classify potential threats to a system and describe how a given architecture will address the threats.
8.4 Describe the commonly used declarative and programmatic methods used to secure applications built on the Java EE platform, for example use of deployment descriptors and JAAS.

O único comentário que tenho sobre isto é: JAAS é um saco!

Bom, me desejem sorte :D

Se você gostou deste post, lembre-se de assinar o RSS feed do blog, para ser notificado de novos posts!