http://www.globalize-rails.org/
Period.
uma pergunta meio tola, mas o Ruby dá suporte a transações distribuídas, replicação de sessão, e toda a parafernália que o Java com o RMI, JNDI, EJB, etc … oferece ?
Tem suporte a Web Services ? Tem alguma API pra programar pra Celular ?
Tem algum mecanismo de persistência fora a convenção dele ?
Hum, acho que não. Mas acho que você usou o termo errado:
[quote=michaelis]pa.ra.fer.ná.lia sf (lat med paraphernalia)
1 Objetos pessoais. 2 Equipamento necessário a uma atividade humana. 3 Pertences; tralha.[/quote]
E isso tudo não me parece nada necessário
Opa, ActionWebService @ http://api.rubyonrails.com/
[quote=Fabrício Cozer Martins]Tem alguma API pra programar pra
Celular?[/quote]
Não.
Como você pôde perceber existe um grupo de extremistas aqui no fórum preparados para ofender a todos que discordem de seus pontos de vista míopes.[/quote]
Bora deixar a brincadeira mais interessante. Cite os nomes dos extremistas aqui no fórum, dê os links para os tais post com opiniões extremas, explique por que é uma opinião alienada e dê o seu ponto de vista. Dizer “há um grupo de extremistas aqui no fórum” é bastante subjetivo, quero aprender a separar o joio do trigo também e é importante saber o que é “extremismo” e o que é a realidade.
Não precisa citar os seus posts.
Já que você não se vê como contra-exemplo pra essa afirmação, todo mundo aqui no GUJ trabalha com Java e você não para de dizer que nós ficamos irritadinhos quando alguém discorda dagente. Muita contraditório isso não acha?
[quote=Fabrício Cozer Martins]uma pergunta meio tola, mas o Ruby dá suporte a transações distribuídas, replicação de sessão, e toda a parafernália que o Java com o RMI, JNDI, EJB, etc … oferece ?
Tem suporte a Web Services ? Tem alguma API pra programar pra Celular ?
Tem algum mecanismo de persistência fora a convenção dele ?[/quote]
É por isso que agente espera que Java se torne cada vez menos plataforma de uma linguagem só e haja uma adoção do uso de outras linguagens (principalmente as de script) para a JVM.
Seria ótimo fazer uso da parafernália da J2EE usando uma linguagem com recursos mais avançados (blocks, closures, collections de verdade…) e de nível mais alto.
[quote=plentz]
[quote=Fabrício Cozer Martins]Tem alguma API pra programar pra
Celular?[/quote]
Não.[/quote]
Talvez seja uma questão de tempo… Tem até Python para celular…
[quote=Fabrício Cozer Martins]uma pergunta meio tola, mas o Ruby dá suporte a transações distribuídas, replicação de sessão, e toda a parafernália que o Java com o RMI, JNDI, EJB, etc … oferece ?
Tem suporte a Web Services ? Tem alguma API pra programar pra Celular ?
Tem algum mecanismo de persistência fora a convenção dele ?
[/quote]
Algumas dessas parafernálias não faz sentido Ruby ter, tais como JNDI, RMI e EJB, já que são técnologias específicas ao Java. JNDI é uma API muito genérica de diretórios, não possui equivalente direto em Ruby, mas coisas como acessar um servidor LDAP é sim possivel. Existe suporte a comunição remota em Ruby, que seria o moral equivalente ao RMI. Quanto a EJB, dado o enorme escopo dessa sigla, não existe resposta simples, quais partes do EJB vc gostaria de ver em Ruby?
Replicação de sessão é uma forma de gerenciar sessões em um cluster, RoR faz isso facilmente.
Transações distribuidas, bom, isso parece mais ser um argumento de vendedor que um argumento real. Sério, quantos aqui realmente precisaram usar XA e 2PC? Eu pessoalmente só usei quando o arquiteto do projeto achou que ia ficar bonito no currículo dele ter projetado algo que usasse isso. Uma transação distribuida possui mais estados bizantinos intrinsecos que normalmente um sistema teria ser usá-las.
Se teu sistema precisa de coisas que Ruby não suporta, use Java, se teu sistema possui requisitos simples e não tem muita coisa bizarra para ser resolvida, provavelmente Ruby é uma solução mais produtiva. Isso é ser pragmático, saber dizer que as duas técnologias são uteis e uma não se sobrepoe a outra integralmente.
[quote=louds]Isso é ser pragmático, saber dizer que as duas técnologias são uteis e uma não se sobrepoe a outra integralmente.
[/quote]
Se é para ser pragmático eu levaria em consideração vários outros fatores, até porque se um projeto usa determinada plataforma TODOS os programadores envolvidos são obrigados a conhecer aquilo.
Isso sem contar ferramentas, código já existente, perspectiva de evolução da plataforma e do negócio, etc.
Parece fácil “use o que for melhor”, agora imagine um desenvolvedor que resolve usar 5 diferentes coisas em 5 projetos diferentes e depois de alguns meses ele sai para ganhar mais em outro lugar, você acha que será fácil encontrar pessoas com experiência em 5 plataformas diferentes?
É necessário ter um plano estratégico em TI, o que a empresa pretende a curto, médio e longo prazo, e escolher aquilo que se adequa mais aos planos.
Acho que o “pragmatismo” vai além do código, o que as líderes de torcida do opensource parecem não entender. Acho que pensando dessa forma Ruby teria uma chance, mas infelizmente alguns só pensam em bits e bytes.
Será? Aqui é claro a distinção entre fanboys e profissionais com uma visão pragmática das coisas. “Pragmático”, essa palavra que alguns gostam de repetir, é justamente o que eles menos praticam.
Thiago, mas você vê nenhuma semelhança entre o seu pensamento e o do pessoal da época do Cobol não?
Pelo menos você tá parecendo admitir que se tratanto de bits e bytes o Ruby pode ser uma solução melhor que Java, mas gerencialmente ainda é complicado para uma equipe adotar a ferramenta.
Thiago, já trabalhei e tive contato a área de TI de algumas empresas grandes, que figuram na Fortune 500 até.
Elas usam Windows, Linux, AIX, Solaris, MainFrame, Tru65, HPUX - na maioria dos casos pelo menos 4 desses SOs. Muito, para uma boa visão de negocios…
Elas tem sistemas web em produção feitos em php, asp, .net, java, perl, ColdFusion e coisas de nicho como Ruby e C++. A maioria tem sistemas no ar feitos em pelo menos cinco dessas tecnologias, sistemas ativos e sofrendo manutenção evolutiva. Uma empresa com uma área de TI com mais 300 funcionários tranquilamente lida com essa diferença.
Eu acho falha essa idéia que desenvolvedores devem trabalhar com uma linguagem apenas. De fato, um desenvolvedor Java provavelmente deve saber também shell script, dezenas de dialétos de xml, perl, etc. Se ele já sabe isso, qual o problema de saber também C#, C++ e Ruby. E qual o problema de ele usar a mais adequada para cada situação?
Esquecendo Ruby por um segundo, ser fluente em várias linguagens de programação cada dia é mais util a medida que todos realizam que cada
uma tem um nicho no qual é melhor que as demais.
e os sintomas de Rails se espalhando [ http://www.theserverside.com/news/thread.tss?thread_id=41189 ]
Me dê mais um mês brincando com EJB 3 e o Entity Manager que eu garanto que ninguém mais vai dizer isso
É só eu ter tempo de escrever o maldito tutorial…[/quote]
Opa… contamos com isso
É praticamente impossível ter um ActiveRecord, assim como todo Active*, em Java. Seria necessário que o Java fosse uma linguagem dinámica para isso.
As coisas podem mudar, mas hoje é praticamente impossível. O melhor que se pode chegar é mesmo JPA ou Hibernate com annotations.
[]s
[quote=louds]Thiago, já trabalhei e tive contato a área de TI de algumas empresas grandes, que figuram na Fortune 500 até.
Elas usam Windows, Linux, AIX, Solaris, MainFrame, Tru65, HPUX - na maioria dos casos pelo menos 4 desses SOs. Muito, para uma boa visão de negocios…
Elas tem sistemas web em produção feitos em php, asp, .net, java, perl, ColdFusion e coisas de nicho como Ruby e C++. A maioria tem sistemas no ar feitos em pelo menos cinco dessas tecnologias, sistemas ativos e sofrendo manutenção evolutiva. Uma empresa com uma área de TI com mais 300 funcionários tranquilamente lida com essa diferença. [/quote]
Eu também, alias na maioria delas. E as poucas que conheci que tentavam padronizar uma única tecnologia. Acaba falhando ou gastando horrores em casos aonde aquele tecnologia não era a mais indicada e for teimosia usaram a padronizada.
[quote=juzepeleteiro][quote=saoj]
Alguém aqui manja de ActiveRecord ???
O quão difícil seria fazer um em Java ???
[/quote]
É praticamente impossível ter um ActiveRecord, assim como todo Active*, em Java. Seria necessário que o Java fosse uma linguagem dinámica para isso.
As coisas podem mudar, mas hoje é praticamente impossível. O melhor que se pode chegar é mesmo JPA ou Hibernate com annotations.
[]s[/quote]
Impossível não é. Daria para alcançar o mesmo efeito do ActiveRecord usando Dynamic Proxies e uma porrada de reflection. Mas o trabalho necessário talvez inviabilizasse.
De qualquer forma você teria que escreve uma interface com todos os gets e sets; E uma classe para os finds.
Não é a mesma coisa que o ActiveRecord.
Esses tópicos de versus sempre são muito interessantes, mas nunca chegam a lugar algum, hehehehe. Me lembra muito os eternos C x C++, C# x Java, Maçãs x Laranjas…
Mas isso é porque vocês não conhecem linguagens mais modernas e fáceis de usar, como Whitespace, Chef ou, a mais legal na minha opinião, COW! Depois de conhecer elas garanto que sua vida não será mais a mesma, ahhahaha
flw
Até então eu estou achado esse tópico bastante construtivo. Estamos conversando se é o não é possível ter ActiveRecord no Java; se o Ruby (que já é um realidade, assim como Java e .NET) vai crescer ou não no mercado enterprise, conversando sobre ser pragmatico e escolher a ferramenta certa para o projeto, se uma empresa deve ou não utilizar uma única tecnologia…
Não, esse não me parece um tópico Maças x Larajanjas… Me parece um tópico bem contrutivo… até então.
Dá ou não dá para ter ActiveRecord em Java ???
Alguém poderia postar um exemplo de como ActiveRecord funciona na prática ?
Talvez se fizéssemos isso não seria o pior dos mundos:
public class Person extends DBBean {
private int id;
private String username;
}
Person p = new Person(12);
p.load();
p.setUsername("sergio");
p.save();
p.delete();
Ok. Eu sei que o bean Person não é puro, pois está tendo que herdar de DBBean. Mas talvez isso não seja o fim do mundo e vai resolver o problema.
O problema é como pegar os campos de Person, sem ter que explicitamente defini-los no objeto, como eu fazia antes:
public class Person extends DBBean {
private DBField id = new DBField(this, "id", DBType.INTEGER);
private DBField username = new DBField(this, "username", DBType.STRING);
}
Assim vai funcionar bonito, mas tá longe de se parecer com ActiveRecord. Não é nem um pouco “puro” tb.
Alguém tem alguma idéia ou isso em Java vai ser complicado mesmo ?
[color=red]Deve ter alguma maneira de o DBBean se virar via reflection para descobrir os campos do Person, que está herdando DBBean. Nem que tenhamos que usar um marcador nesses campos.[/color]
private int _id;
private String _username;