Anunciado no GUJ a criação do RubyOnBr, portal nacional sobre Ruby e Rails.
Muito boa a iniciativa. pelo visto o site usa o javaFree CMS, o que mantêm a velha tradição de sites sobre uma tecnologia feita em outra :D
Já estou no fórum.
Archive for the ‘rails’ Category
Nova Comunidade Brasileira de Ruby
Monday, July 3rd, 2006Dave Matters!
Thursday, June 22nd, 2006A revista Business 2.0 divulga no seu portal as 50 pessoas que são importantes neste momento para os negócios. Adivinha quem é o numero 34 numa lista que inclui Hugo Chavez.
Avante JRuby!
Tuesday, May 16th, 2006Se você acompanhou minha palestra no Rio Java Summit 2006 pôde ver um pouquinho do que linguagens dinâmicas podem fazer na sua aplicação. Um dos projetos mais interessantes nesta área, o JRuby, anuncia novidades. Basicamente teremos Rails na JVM em breve.
SAP Developer Network: Rails de Novo
Friday, April 21st, 2006Mais um artigo na SDN sobre Rails, desta vez o tema é RadRails.
Mas, claro, a SAP é só mais uma daquelas empresinhas pequenas que fazem sitezinhos bobos. Não é?
2006: O Início da Arquitetura Heterogênea Java EE (ou: “Qual o melhor Framework web?”)
Sunday, April 2nd, 2006Eu não te responderia isso sem avaliar o problema, mas um laboratório na NASA acaba de divulgar um videozinho com uma comparação. O vídeo do Sean Kelly é bem engraçado mas traz muito das tendências modernas no desenvolvimento de aplicações, web ou não.
Na atualidade, o laboratório em questão usa Java EE para tudo e avaliou se era a melhor solução para interfaces e aplicações completas web.
O autor começa falando de sua experiência com um sistema em C++ e como qualquer alteração resultava na recompilação de todo o sistema. A solução foi manter partes que são alteradas com mais frequência, no caso interface, em uma linguagem de script, no caso TCL/TK. Este trecho casou muito bem com algo sobre o qual queria escrever faz tempo e que certamente vai guiar minha linha de estudos neste ano.
Aplicações web pequenas geralmente são muito dinâmicas. O layout muda, o esquema muda, tudo muda o tempo todo. Algumas aplicações são temporárias então não vale gastar muito tempo, elas devem se pagar rapidamente. Outras ficam como portais e nossos adoráveis aplicativos online, mas geralmente você também vão precisar de muito dinamismo para enfrentar o mercado atual.
Para estes dois tipos de aplicação eu hoje sugiro fortemente Rails. Eu trabalhei na área de agências web, nestes lugares o trabalho é quase sempre criar um portal e integrar com um backoffice. Antes essa integração era quase sempre feita direto no banco de dados, não que não houvessem opções menos dolorosas, mas era o padrão. Hoje temos o tal do SOA que ninguém sabe direito o que é mas faz com que todas as aplicações acabem com alguma espécie de API para serem utilizadas por outras aplicações.
As aplicações construídas nos tempos mais recentes geralmente têm interfaces REST ou SOAP, as mais antigas e/ou que não tenham estas interfaces podem (e devem, quase sempre) ter um adaptador que permita a outras aplicações utilizá-las sem duplicar o que aquele sistema já faz no novo.
Neste cenário podemos facilmente integrar uma aplicação destinada ao usuário final em, por exemplo, Rails com todo o zoológico de aplicações coorporativas em JEE, .Net, COBOL, C++, Delphi e todas aquelas tecnologias bizarras que parece que só a sua empresa usa no mundo todo. Batsa você colocar a aplicação Rails para conversar com as outras, assim você pode utilizar na sua interface web o que há de melhor enquanto mantêm seus sistemas escritos em Java, C++, .Net ou o que quer que seja.
Mas e quando o que você está construindo são as tais aplicações ‘coorporativas’, as peças que prestam serviços para a interface web?
A maioria dos desenvolvedores quando ouve falar de Ruby on Rails (que eu conheço, anda contra as outras) pensa: “bah! minha aplicação faz muito mais que ser apenas um sitezinho!”
Bom, antes de mais nada:
- Em geral o que é feito hoje nas consultorias são variações de sitezinhos
- Ruby on Rails, por exemplo, traz muito mais produtividade para este tipo de aplicação
- Mesmo que não fossem, Rails serve para muito mais que sitezinhos
Mas vamos partir do ponto que estamos criando uma aplicação que não é apenas um site, não apenas um cadastro que aplica regras de negócio simples em cima de dados.
Eu trabalhei algum tempo em aplicações cuja interface é geralmente um socket aberto falando um protocolo proprietário de um lado e uma interface SOAP no outro. Nada de GUI além de algo muito básico para administração, apenas receber requisições SOAP, processar, mandar mensagens via socket para outro sistema e dar uma resposta SOAP a quem te chamou. O que estes anos me ensinaram é que mesmo neste tipo de sistema existem partes na aplicação que mudam bastante e outras que não mudam quase nunca.
A arquitetura de uma aplicação geralmente não muda. Se você criou seu sistema baseado em EJBs, Servlets e Hibernate, dificilmente isso vai ser alterado no meio do caminho. Mesmo que seja, as pessoas têm alguma noção do custo disso e criam projetos completos para esta migração, ou fazem tudo de forma tão gradativa que viram aqueles famosos projetos eternos que têm data de início mas do fim ninuém sabe.
Já regra de negócio, por exemplo, vive tendo mudanças. Uma promoção que a empresa vai fazer que altera o modo como clientes são cobrados por um mês, uma regulamentação nova ou a reinvenção de algum processo (você sabe, reengenharia de processos está na moda novamente) e lá vamos, como Sean no vídeo, ter que alterar, compilar tudo de novo, empacotar… isso tudo para mostrar ao cliente ver se era realmente o que ele queria. Ah, não é? Repita o ciclo.
Mudanças são parte da vida. O que podemos fazer para evitar que mudanças constantes afetem a produtividade? Que tal adotar uma arquitetura amigável à mudanças?
Java é uma linguagem robusta e segura, muito interessante para construir infra-estrutura, por exemplo, mas não é lá muito dinâmica. Escrever código que está sempre mudando em Java é complicado, envolve mudar arquivos de configuração, recompilação e deployment muitas vezes.
Um grande problema que enfrentei por algum tempo é o modelo monolítico de artefatos em Java EE. Imagine que você gera um grande EAR com toda a sua aplicação. Um EAR geralmente possui uma aplicação web, um conjunto de EJBs ou um JAR de POJOs se você utilizar Spring, por exemplo, e outros recursos.
Imagine que um destes componentes possui um bug (acredite, vão haver bugs) que precise ser corrigido imediatamente. Geralmente nestes casos se implementa um chamado hotfix (ou, em bom português: gambiarra/bacalhau) que vai corrigir de uma forma não-ideal enquanto não se entrega uma versão onde o problema foi realmente sanado.
Ok, você implementa o hotfix e… tem que recompilar, gerar o EAR e mandar pro cliente instalar tudo de novo. Pára servidor de aplicações, instala, sobe tudo de novo…péssimo! Por uma mudança em um componente você teve que parar tudo por talvez algumas horas.
Numa arquitetura C/C++ em UNIX, por exemplo, você possui diversos programas que cooperam através de IPC (comunicação entre processos) para compôr o sistema. Se um destes componentes precisa ser corrigido, o cliente precisa instalar apenas este e não todo o sistema novamente.
A parte do seu sistema que pode mudar é provávelmente a que vai possuir mais bugs no decorrer do tempo, afinal cada mudança pode inserir novos bugs e trazer de volta antigos. Mas e se esta parte da aplicação fosse construída de maneira que qualquer mudança fosse simples e rápida? Este é um tema que pretendo abordar este ano em palestras e artigos.
Como tornar seu sistema mais flexível e mantendo a confiabilidade? Qual o impacto da nova realidade onde Java não é a linguagem única e soberana mas apenas uma ferramenta na caixa do profissional?
Imagine construir uma aplicação com a arquitetura central em Java mas com a Camada Web em Groovy ou quem sabe até Rails num futuro próximo? Que tal escrever suas regras de negócio numa linguagem que seu usuário final entenda e possa ele próprio alterar?
Em breve podem esperar material sobre estes temas com frequência aqui no Fragmental.
–
Voltando á comparação original, os competidores eram variações de Java EE (Servlets, JSP, Hibernate, JBoss em combinações variadas), Ruby on Rails, Django, Zope e TurboGears. As conclusões eu deixo para você ver pessoalmente, eu acho que foram exemplos muito simples para qualquer conclusão maior.
De qualquer modo, faltou um produto interessante: O Seam. Se você quer conhecer este modelo de aplicação que mistura JSF com EJB3, não perca mês que vem a chance de conhecer a paltaforma diretamente da boca de seu inventor, que por um acaso é também inventor do Hibernate(!) e principal colaborador do EJB 3.0 (!!): Gavin King. King vai estar novamente no Rio de Janeiro mês que vem, e não vai estar sozinho! Mais informações em breve.
Google e Seu Marketing
Saturday, March 11th, 2006O Signal vs. Noise discute porque o Google teria comprado o Writely e eu pergunto a você: quanto tempo por dia você passa usando produtos do Google (Orkut, GMail, GoogleTalk, Search, Maps, Froogle, Blogger, Analytics, Video, Picasa, AdWords…) e quanto passa usando produtos Microsoft (tirando o Windows)?
A Microsoft vence fácil, não é? Então pense quanto tampo você passava utilizando produtos de cada um destes há apenas um ano atrás.
Considerando este crescimento absurdo, o quanto do seu tempo o Google vai ter tirado da Microsoft em mais um ano?
É engraçado isso. Enquanto o Google distrai com coisas sobre um possível Google OS ou o tão aguardado GoogleCalendar ou ainda a suíte de Office inteiramente web a emrpesa está, na verdade, tomando a web aos poucos e quase que despercebidamente.
Tate te Faz Atravessar Fronteiras
Wednesday, March 8th, 2006Bruce Tate, autor do comentadíssimo livro Beyond Java, acaba de lançar no developerWorks da IBM uma série chamada Crossing Borders.
Na série o também autor de Better, Faster, Lighter Java (ótimo livro) fala sobre os motivos que um programador (programador Java no caso mas se aplica a qualquer um) teria para aprender novas linguagens e teconologias. Ele cita:
- Java não é a linguagem perfeita para qualquer problema.
- Você pode utilizar as idéias que aprender em Java.
- Outras tecnologias estão mudando o modo como as próprias tecnologias Java são criadas.
E eu concordo completamente.
No primeiro artigo ele fala de ActiveRecord do Rails, boa leitura.
Ruby + Spring
Wednesday, February 1st, 2006Interessante esta entrada do Phil Bogle.
Os caras usam jRuby, Spring e Hibernate apra produzir aplicações web rapidamente. Apesar da semelhança com o Rails nada impede que você faça algo parecido com Jython, Groovy ou qualquer outra coisa.
Eu estava fazendo algo aprecido usando jRuby, Spring e EJB 3, mas no final parti rpo bom e velho Rails. De qualquer forma se você não pode abrir mão da JVM nem de simplicidade… pode ser uma alternativa bem legal.
Programar em Ruby te faz odiar linguagens estáticas
Thursday, January 26th, 2006Papo interessante que estava tendo com o Fabrício ainda agora…
fabrício diz:
hehehhe
vc tb ta estudando ruby ?
Phillip Calçado - All that’s sacred..comes from youth! diz:
simfabrício diz:
pq ?Phillip Calçado - All that’s sacred..comes from youth! diz:
por que eh uma linguagem *muito* boa
produtiva e de qualidadefabrício diz:
rapaz..
hehe
sacanagem, mas eu quero saber o q eh q vcs acharam tao extraordinario nessa linguagem
eu vi aquele videozinhoPhillip Calçado - All that’s sacred..comes from youth! diz:
closures, dinamismo, DSLsfabrício diz:
realmente me surprendiPhillip Calçado - All that’s sacred..comes from youth! diz:
hoje eu estava com um problema interessante em javafabrício diz:
qual ?Phillip Calçado - All that’s sacred..comes from youth! diz:
tem uma classe qualquer que cria um objeto que pode ser considerado uma sessão com o banco de dados
só que numa jvm só podem existir duas sessões ao mesmo tempo, em threads diferentes
e me foi pedido para toda vez que se tenta abrir uma dessas, logar num arquivo antes quantas existem em memoria
para saber se estavamos tendo muito problema com isso ou se quase nunca duas sessoes ficam abertas
o jeito mais simples seria colocar uma variavel de classes (estatica) na classe que cria a conexão para saber quantas ela criou, certo?fabrício diz:
é, a principio sim
e aii ?Phillip Calçado - All that’s sacred..comes from youth! diz:
mas o problema eh que a classe que pede para essa outra criar uma sessão é quem fecha a sessão
então nós poderíamos saber quantas ssessões foram criadas, mas não quando uma for fechada
e essa classe sessão é do fornecedor do banco de dados, ou seja não pode ser alterada
como resolver isso em java?fabrício diz:
unh … sem alterar a classe do fornecedor do bd, acho q tem q queimar um pouco os neuronios hehe
pq essa classe na pior das solucoes poderia notificar a todos que tem um comunicacao com ela, de que a sessao foi finalizada
sim, e ai?
vc fez o q?Phillip Calçado - All that’s sacred..comes from youth! diz:
basicamente o que eu fiz rpa contornar a situação foi pegar todas as threads do sistema, ver quais delas possuem sessões abertas e logar, e como isso é bem lento deve ser melhor usar um adapter nesta classe
mas se fosse em uma linguagem como ruby, ao criar a instancia de sessao eu poderia alterar o metodo commit() desta instancia, fazendo ele avisar a classe fabrica que foi fechada antes de chamar o metodo original
Não entendeu a solução? Em Ruby uma classe é dinâmica, você pode alterá-la em runtime. Vamos a um exemplo (você pode testá-lo neste site) . Então supomos que nossa classe Session seja assim:
class Session
def commit
puts ‘COMMITED’
end
end
E que quem crie sessions seja esta fabrica:
class Factory
def create
return Session.new
end
end
Agora vamos modificar a fabrica para que guarde o numero de Sessions abertas e altere o método Session#commit
class Factory
#vamos guardar a quantidade de sessoes aqui
@count
#cria um ‘getter’ para o count
attr_reader :count
#construtor
def initialize
@count=0
end
#metodo usado para informar que uma sessao foi finalizada
def session_ended
@count=@count-1
end
def create
s=Session.new
#muda o metodo do objeto criado e cria variavel de instancia para localizar a factory
class <<s
#onde vamos guardar uma referencia para nossa factory
@factory
#cria um ’setter’ para factory
attr_writer :factory
#Muda o nome do metodo commit real
alias original_commit commit
def commit
@factory.session_ended
#chama o metodo antigo
return original_commit
end
end
#diz à sessao modificada que esta eh sua factory
s.factory=self
@count=@count+1
return s
end
end
Ficou bem maior que o método original, mas muito do que foi adicionado são getters, setters e construtores. No fim do post está o texto do teste completo, basta salvar num arquivo e rodar no interpretador ruby.
Note que o código não é thread-safe, teríamos que colocar uns monitores ali. Também é bom notar que não são todas as instâncias de Session que são afetadas mas apenas aquelas criadas pela Factory. Caso fosse necessário, poderíamos fazer com que todas as instâncias d Session fossem alteradas.
É assim que coisas como o Rails são implementadas e por isso é tão complexo criar ‘um Rails em Java’.
Se pudesse fazer isso em Java não estaria quebrando minha cabeça amanhã para otimizar uma ferramenta de diagnóstico… Minhas opções são: (a) empacotar a classe Session num Adapter ou (b) continuar buscando todas as threads e vendo se elas possuem sessões abertas
Provavelmente vou criar um adapter ou se não puder uma subclasse. WrappedSession implements Session e implemento o método commit() fazendo o necessário antes de delegar à Session real. O fato de criar uma classe nova na hierarquia apenas para adicionar um conceito ortognal (ou um cross cutting concern, algo importante para o sistema mas não importante do ponto de vista do usuário) não me faz muito bem. E se eu tiver que acrescentar esta funcionalidade a uma outra subclasse de Session criada por alguma das outras factories? Com wrapper tudo bem, mas se não usar subclasse eu crio outra com a mesma finalidade? E se eu quiser que todas as Sessions, não importa onde foram criadas, tenham esta funcionalidade? Find “Session”/Replace with “WrapperSession”?
Ps: estou tendo problemas com o WYSIWYG do WrodPress, a formatação tem ficado meio bagunçada devido a isso - Com ajuda do Diego isso foi meio que resolvido :P
Exemplo completo:
class Session
def commit
puts 'COMMITED'
end
end
class Factory
#vamos guardar a quantidade de sessoes aqui
@count
#cria um ‘getter’ para o count
attr_reader :count
#construtor
def initialize
@count=0
end
#metodo usado para informar que uma sessao foi finalizada
def session_ended
@count=@count-1
end
def create
s=Session.new
#muda o metodo dentro do objeto criado e cria variavel de instancia para localizar a factory
class <<s
#onde vamos guardar uma referencia para nossa factory
@factory
#cria um ’setter’ para factory
attr_writer :factory
#Muda o nome do metodo commit real
alias original_commit commit
def commit
@factory.session_ended
#chama o metodo antigo
return original_commit
end
end
#diz à sessao modificada que esta eh sua factory
s.factory=self
@count=@count+1
return s
end
end
f = Factory.new
s = f.create
puts f.count
s.commit
puts f.count
UPDATE: O taq deu uma limpada no código, ficou menor mas se for sua primeira vez vendo algo em Ruby pode ser mais confuso::
class Session
def commit
puts "COMMITED"
end
end
class Factory
attr_reader :count # pode usar o attr_reader direto que ele cria a @count
def initialize
@count = 0 # aqui tem que 'setar' o valor default né, inclusive se você não
end # tivesse usado o attr_reader, a @count poderia ser criada aqui sem problemas
def session_ended
@count -= 1 # olha o -= ao invés do @count = @count - 1
end
def create
s = Session.new
class << s
attr_writer :factory # mesmo esquema acima - não precisa explicitar @factory
alias original_commit commit
def commit
@factory.session_ended
original_commit
end
end
s.factory = self
@count += 1 # olha o += ao invés do @count = @count + 1
s # não precisa do return, apesar de ficar mais legível com ele
end
end
f = Factory.new
s = f.create
puts f.count
s.commit
puts f.count
Bruce Eckel: Visão estreita!
Tuesday, December 20th, 2005Sobre o artigo de Bruce Eckel 9que é um cara que eu gosto abstante aliás no Artima falando um monte de bobeira sobre Ruby e (o livro) Beyond Java, vou deixar para vocês o comentário do cadafalso: Visão estreita!