Olá
Eu vou!
Informações em:
E você ainda ficará aguardando o EJB 4.0?
[]s
Luca
Eu ia, mas surgiu um imprevisto hoje. 
Opa Luca, vou tentar ir sim, quase certeza 
Vamos tentar nos encontrar lá para nos conhecermos
Nossa, quanta gente vai! Vai lotar hein!
Olá
Meu resumo do evento:
-
Número de inscritos: mais ou menos 150
-
Compareceram uns 130, sendo que veio gente do Rio, Brasília, interior de SP e até um do Piauí. Achei interessante que tinha alguns outros coroas além de mim.
Minha impressão sobre a tecnogia depois da exposição de hoje
-
Reamente para aplicações novas e que não precisem de two phase commit, objetos distribuídos, processamentos concorrentes em larga escala, isto é, para a maioria das aplicações novas, RoR é fantástico. Melhor do que eu pensava. Não sabia que era tão fácil fazer balanceamento de carga e nem das facilidades com as sessões. Quem a deixar de lado pode perder muitos clientes.
-
Ruby como linguagem parece interessante pelo fato de exigir muito menos linhas de código do que Java para fazer as mesmas coisas. Mas se não existisse o Rails, Ruby iria não teria destaque.
-
Depois das palestras que vi hoje, não entendo os que dizem que não há IDEs para RoR. Pode até alguém prefira o vim mas para quem está acostumado com o eclipse é muito bom continuar usando a mesma coisa.
-
Para não dizer que tudo são flores, duas restrições ainda a confirmar:
a) o processo de deployment das aplicações que é aparente fácil, para meu espanto parece que precisa ser repetido quando a aplicação vai para um outro servidor como o de homologação ou de produção.
b) O Kenobi levantou uma dúvida que não foi bem respondida. Onde colocar as validações das regras puramente relativas ao negócio (core business). Como o framework adota uma série de procedimentos padronizados, restou esta dúvida.
c) Ficou uma certa impresssão de que apesar de no Ruby tudo ser objeto, as aplicações feitas com RoR ainta tem um certo ranço procedural que o progamador nem sempre consegue evitar facilmente.
GUJeiros que encontrei por lá: Kenobi, Anderson Leite (que já conhece RoR), Proteus Alcebidiano, Paulo e Guilherme.
Muito bom o evento. O local é bom com um auditório bem amplo. Valeu cada centavo dos R$ 35,00 que paguei.
Parabéns Ronie Uliana, Adriano Dadário, TAQ (Eustáquio Rangel de Oliveira Jr), Bill Coutinho, Fernando Gomes e André Wolf (Tempo Real).
[]s
Luca
Posso não ter entendido a dúvida, mas não seria no model?
Olá…
Estive lá.
Particularmente, achei o Rails é especificamente bom para aplicações cujo mapeamento Tabela x Classe seja sempre direto. Aplicações mais complexas, envolvendo mapeamentos de tabelas mais complexos, aparentemente não são tão facilmente criadas ou mesmo não suportadas.
Já a parte de criação da estrutura do projeto, bem como a auto geração de CRUD são bem legais.
Espero que o Rails se desenvolva mais. E concordo com o Luca de que se não existisse o Rails, o Ruby ficaria meio de lado…
Mas a liguagem parece bem legal e, considerando que o Rails ainda deve se desenvolver muito, talvez no futuro haja muito mais flexibilidade para ferramentas que o utilizem e para o próprio Framework.
PS.: Gostei do “Eclipse Customizado para Rails” que os caras usaram.
Abraços
Carlos Eduardo
[quote=ceduardo.roque]Particularmente, achei o Rails é especificamente bom para aplicações cujo mapeamento Tabela x Classe seja sempre direto. Aplicações mais complexas, envolvendo mapeamentos de tabelas mais complexos, aparentemente não são tão facilmente criadas ou mesmo não suportadas.
[/quote]
com active record voce consegue fazer qualquer mapeamento, mesmo que seja complexo 
O nome do pluguin é google:radrails :mrgreen:
fmeyer,
Sim dá para fazer tudo pelo Active Record… Porém para montar um esquema de Class Table Inheritance, uma tabela por classe, precisei de acordo com um artigo que encontrei na internet montar um esquema de views e rules no banco para que o ActiveRecord trabalhasse neste formato. Existe alguma maneira de fazer isso no código ao invés de mexer no BD?
abs.,
Flávio
Ah, foi muito legal o evento, foi bem legal conhecer o pessoal do GUJ, muito joia mesmo, valeu a pena comparecer ao evento pela qualidade das palestras…só queria um coffe break melhor hehehehehe
ah sim, eu fiquei de passar a Meta-heuristica GRASP para Anderson, mas nem peguei o contato dele, vou colocar por aqui que fica mais facil (se nao tiver problema, claro hehe)
Mais informacoes aqui
E Luca, o blog que te falei é esse aqui
t+
Editado: Coloquei o artigo aqui porque eu nao conheco o nick do Anderson aqui no GUJ, mal minha =S
T+
Outra questão que não ficou clara foi da programação com interfaces, já que não é obrigatório definirmos retornos nos métodos, ou seja, como ficariam as abstrações.
Proteu, valeu pelo arquivo. Fechei soh agora o programinha.
Luca, não o conhecia pessoalmente até o evento, uma enciclopédia em pessoa. Aguardo o próximo evento pra conversarmos mais.
A questão levantada pelo Kenobi eh que não podemos criar packages distintos para por exemplo a camada business, isso torna mais difícil inclusive a reutilização de código.
Abraços!
Respondendo algumas das perguntas:
Class table inheritance e mapeamentos esquisitos: a ideia do Rails eh que essas coisas sao dificeis de fazer e/ou parecem ser gambiarras pq, se vc parar pra pensar bem, elas sao. Entao, o truque que eles arrumaram foi desencorajar usuarios a fazer esse tipo de coisa ao torna-las “feias”. Mas, querendo, tudo eh possivel
Validacoes automaticas: o model deveria tomar conta de todas essas coisas (e escrever novas validacoes, que funcionam do mesmo jeito que as do Rails), eh baba.
Programacao com interfaces: nao tem, mas muitos vao concordar que duck typing da conta do recado.
Criar packages: huh?
Deployment: tem o Capistrano, que automatiza boa parte da bagunca. A gente usa ate mesmo em alguns projetos Java por aqui.
cv,
Qual é a melhor maneira de trabalhar com heranças? STI?
abs.,
Flávio Suguimoto
[quote=cv]Respondendo algumas das perguntas:
Class table inheritance e mapeamentos esquisitos: a ideia do Rails eh que essas coisas sao dificeis de fazer e/ou parecem ser gambiarras pq, se vc parar pra pensar bem, elas sao. Entao, o truque que eles arrumaram foi desencorajar usuarios a fazer esse tipo de coisa ao torna-las “feias”. Mas, querendo, tudo eh possivel
Validacoes automaticas: o model deveria tomar conta de todas essas coisas (e escrever novas validacoes, que funcionam do mesmo jeito que as do Rails), eh baba.
Programacao com interfaces: nao tem, mas muitos vao concordar que duck typing da conta do recado.
Criar packages: huh?
Deployment: tem o Capistrano, que automatiza boa parte da bagunca. A gente usa ate mesmo em alguns projetos Java por aqui.[/quote]
Pera duck typing não resolve o problema de “contrato”. Isso é muito útil quando temos projetos relativamente grandes, sendo desenvolvidos por equipes Heterogêneas.
Também não sei como fica o Polimorfismo … assunto, que gostaria de saber mais à respeito.
Quanto aos packages, já vi que existem os namespaces para Ruby, que cumprem tal papel.
PS: Particularmente gosto de organizar meu código, principalmente em projetos enterprise…
Bom, sobre o evento o coffee estava terrível, mancada feia !! hehe …
As palestras ficaram muito repetitivas, com um conteúdo inicial similar, fiquei bastante decepcionado com o evento. Parecia uma introdução para estudantes e não um seminário voltado à profissionais.
Aqui somente uma consideração: Não fiquei até o final, então não vi a última palestra, pois já estava com o saco na lua …sabadão neh ?!
Quanto aos gujeiros, show de bola o Anderson, Luca entre outros… Não vi o Paulo por lá … acho q estava distraído
Pra findar, achei o Rails interessante para aplicações pequenas e rápidas, voltadas à tecnologia da informação, como websites, cms entre outras do tipo.
Para aplicações mais densas, preciso ainda estudar à fundo, antes de emitir uma opinião. Ao menos comprei um livro sobre o assunto,após minha leitura e brincadeiras, volto com base para argumentações.
Hoje sou meio cético, e da forma que eu vi o pessoal programando, me pareceu um retrocesso no quesito design - orientação a objetos.