Bill Burke (EJB) X Rod Johnson (Spring)

Assuntos Gerais Notícias
#61

Quando o assunto não é mais um simples CRUD, e há necessidade de transacionar operações entre diferentes aplicativos distribuídos em uma mesma rede, sendo, contudo, executandos em servidores de aplicações diferentes, EJB3 é uma boa solução.

Atualmente estou envolvido em um projeto desses (e no passado estive em outros), assim como já estive em projetos em que Spring era uma boa opção (e foi a escolhida).

Pensar que algo não serve absolutamente pra nada me parece um pensamento muito minimalista. Como o CV bem disse no último CJ, isso é coisa de Arquiteto de uma nota só!

Usar Spring apenas pra IoC? Usar EJB pra CRUD? Fugir de application server como o diabo foge da cruz? Hummm… Prefiro pensar um pouquinho mais.

Cada tem seus requerimentos particulares, bem como cada tecnologia a sua aplicabilidade…

IMHO

#62

[quote]
Tem “cap deploy” no Grails? Que implanta tudo em infinitos servidores sem você mexer mais do que dois dedos? [/quote]

Maurício, no Grails você pode optar por deployar num WebLogic a vida, que ele faz automaticamente o deploy em todas as instancias que estão no cluster.

Não estou defendendo, somente dando uma solução para o problema.

#63

[quote=saoj][quote=Maurício Linhares]
Aiaiai, o cara programa em PHP e é um incompetente? Tipo, o Wordpress é em PHP, o YouTube é em PHP… preconceito faz mal rapaz, muito mal :lol:
[/quote]

O Facebook é feito todo em PHP. E vale 15 bilhões de dólars. 2% foi vendido para a Microsoft por quase 300 milhões de dólares.

[/quote]

Não significa que seja bem implementado ( Não estou dizendo que não seja) . Mas o valor da companhia é muito mais inerente ao modelo de negócios, marketshare do que tecnologia propriamente dita.

#64

Só pra deixar claro.

Nada tenho contra o PHP. Eu mesmo tenho diversos projetos feitos em PHP, mas convém mencionar a existência dos “programadores”. No meu dia a dia, quando tenho de contratar alguém, é extremamente comum me deparar com gente que diz que desenvolve em web com PHP e, no final das contas, não faz práticamente nada.

Óbvio que PHP não é uma linguagem de merda, mas é nítida a imensa legião de “programadores/desenvolvedores/ou o nome que você quiser” que, usando o fato de fazer scripts bestas em PHP, queimam o filme de toda a nossa categoria. Este é um fato de mercado. Não há dúvidas com relação a isto.

Que há projetos feitos em PHP de incrível qualidade, não há dúvidas também. Basta ver que a popularidade do PHP é muito maior do que JSP/JSF/Grails/RoR ou qualquer outra linguagem para desenvolvimento web. É uma plataforma interessante para se trabalhar, não resta dúvidas. Mas, HÁ este lado negativo também.

Assim como ocorreu com o desenvolvimento em Delphi e VB, o mesmo ocorreu com o PHP, não há muito como negar. Pessoas que não sabem o básico (e são muitas, acredito que a maioria) de arquitetura de sistemas estão aí desenvolvendo “sistemas” em PHP que, quando você pega trabalhar, são um desastre.

Sugiro que vocês comparem os artigos escritos aqui no Brasil a respeito de PHP e outra linguagem mais OO como Java por exemplo. Vão ver nítidamente que o nível técnico É inferior na maior parte das vezes. Basta olhar o nível de discussão que temos aqui no GUJ e o nível de discussão que você vai encontrar em uma comunidade sobre PHP. O mesmo digo com relação tanto ao Delphi e VB (detalhe: trabalho tanto com Delphi quanto VB também. não é preconceito CONTRA a plataforma, mas sim CONTRA um certo tipo de profissional que prolifera na mesma, e acaba DESTRUINDO a credibilidade da mesma).

#65

Maurício, YouTube é escrito em Python. :wink:

#66

** somente pra aqueles que mencionaram que RoR pode “roubar” a cena do java…

vejam aqui

acho que eu não estarei mais por aqui quando isso acontecer… :shock:

#67

[quote=Kenobi]Maurício, no Grails você pode optar por deployar num WebLogic a vida, que ele faz automaticamente o deploy em todas as instancias que estão no cluster.

Não estou defendendo, somente dando uma solução para o problema. [/quote]

Considerando que o custo de licença pelo Capistrano, um servidor unix com shell, apache e alguns mongrels é zero, acho que é mais fácil pegar Ruby e Rails né :slight_smile:

#68

Mas é exatamente esse o ponto, a tecnologia hoje é o mínimo dos seus problemas (na verdade, faz muito tempo isso já, uma lidinha em Peopleware ou The Mythical Man Month já mostram isso). As tecnologias só afundam projetos de quem realmente não sabe nada ou não tem direcionamento nenhum (ou realmente não sabia nem escolher o que deveria usar).

#69

[quote=Maurício Linhares]
Considerando que o custo de licença pelo Capistrano, um servidor unix com shell, apache e alguns mongrels é zero, acho que é mais fácil pegar Ruby e Rails né :)[/quote]

Aí que tá, o mesmo você pode dizer do Tomcat ou o JBoss por exemplo. Dá na mesma.
Custo financeiro aqui não conta mais.

#70

[quote=Javabuntu]** somente pra aqueles que mencionaram que RoR pode “roubar” a cena do java…

vejam aqui

acho que eu não estarei mais por aqui quando isso acontecer… :shock: [/quote]

Eu não acho que Ruby o Rails vá ‘roubar a cena do java’, apesar de achar que ‘a cena do Java’ tem dias contados, mas só um exercício: você se lembra quando java chegou ao topo dessa lista? Ou quando comemoramos que Java tinha mais projetos que C+ no SourceForge? Lembra quando tudo o Brasil era Delphi, ASp e PHP e Java era ‘muito lenta, não tem boa ferramenta’, etc.?

Sinceramente, eu não sei se as pessoas esquecem ou simplesmente não viveram isso.

#71

[quote=pcalcado][quote=Javabuntu]** somente pra aqueles que mencionaram que RoR pode “roubar” a cena do java…

vejam aqui

acho que eu não estarei mais por aqui quando isso acontecer… :shock: [/quote]

Eu não acho que Ruby o Rails vá ‘roubar a cena do java’, apesar de achar que ‘a cena do Java’ tem dias contados, mas só um exercício: você se lembra quando java chegou ao topo dessa lista? Ou quando comemoramos que Java tinha mais projetos que C+ no SourceForge? Lembra quando tudo o Brasil era Delphi, ASp e PHP e Java era ‘muito lenta, não tem boa ferramenta’, etc.?

Sinceramente, eu não sei se as pessoas esquecem ou simplesmente não viveram isso.[/quote]

Na sua opinião, o que virá a substituir o lugar do Java (linguagem) atualmente?

Pessoalmente, acredito que daqui pra frente Java passará a ser a ser visto cada vez menos como linguagem e mais como plataforma de execução (o que de fato sempre foi desde o início), pois estão surgindo diversas novas linguagens para a plataforma (Groovy, JRuby, Scala, Grails, etc.), ao passo que a linguagem Java, em si, já está chegando ao fim de sua própria evolução (não que a linguagem Java vá morrer, mas sim vai dar uma “estacionada”).

#72

Sim, por aí. Não vai ter uma coisa que vai substituir Java, simplesmente as pessoas vão voltar para o ponto onde se escolhia a ferramenta certa para o problema. A JVM tende a ser apenas uma entre diversas outras plataformas que dao suporte à essas liguagens.

#73

O futuro de Java é como plataforma. Esse é um lance que a Microsoft atacou com .Net desde o início, e que a Sun também tem despertado e investido. Alguns exemplos disso? JRuby, Groovy, Projeto Da Vinci Machine…

Falei um poucou sobre isso recentemente em meu blog:

Isso é muito louco. A veia da idéia é: Seja livre pra escolher a linguagem que melhor atenda às suas necessidades, que melhor resolva seus problemas computacionais, sob todos os aspectos.

Agora, o maior obstáculo que eu vejo nisso são os prograadores que acham que Java é a melhor linguagem de programação do Universo. Java não foi concebida para resolver todos os problemas computacionais do Universo, basta ver a sua história.

Eu acho um absurdo esse tipo de pensamento. Porque, não é porque Java tem API e framework [bizarro] pra tudo, que ela seja a melhor opção também em tudo.

Na boa? Não acho que a “linguagem” Java vá morrer não, porque ela tem os seus méritos e a sua aplicabilidade - todos nós aqui programamos em Java e sabemos disso. Mas também não acho vá continuar por cima da carne seca por mais muitos anos.

O que eu penso? Penso que ela vai ser só mais uma (ainda que boa) opção como linguagem de programação para a JVM. Não acho que vá ser a melhor, nem a pior. Acho que vai ser apenas mais uma opção. Lembrando, claro, que opção se faz com parametros, senão não é opção, é “goela abaixo”, “lavagem cerebral”, qualquer coisa, menos opção.

Tal como acontece na plataforma .Net você pode resolver problemas computacionais com C#, VB, IronPython, ou sei lá mais o que, dependendo do problema em questão, creio que na plataforma Java acontecerá. (Nesse ponto temos que tirar o chapel pra Microsoft, porque eles “se inspiraram” em Java e fizeram aquilo que Java deveria ter feito desde o início).

E viva a liberdade de escolha!

#74

melhor crítica à Ruby ever:

#75

Como viver sem o “Open Call Hierarchy” ???

Isso me assusta um pouco. As facilidades do Eclipse para o Java, tais como auto-complete, refactoring, auto-compile, show call hierarchy, etc. agilizam muito o desenvolvimento e a manutenção de um projeto grande, cheio de classes.

E a característica do Ruby de ser Dynamic Typing, parece que vai de encontro a isso.

Fonte: http://www.javaworld.com/javaworld/jw-07-2006/jw-0717-ruby.html

#76

[quote=kicolobo]Aí que tá, o mesmo você pode dizer do Tomcat ou o JBoss por exemplo. Dá na mesma.
Custo financeiro aqui não conta mais.[/quote]

Aí é que tá, você primeiro descobre o que o Capistrano faz -> http://www.capify.org/getting-started (leia esse getting started, basics e rails)

Aí então você vem aqui e diz a ferramenta que faz isso com Tomcat e JBoss (não vale dizer que o Capistrano faz também :P)

:wink:

#77

[quote=kicolobo]Na sua opinião, o que virá a substituir o lugar do Java (linguagem) atualmente?

Pessoalmente, acredito que daqui pra frente Java passará a ser a ser visto cada vez menos como linguagem e mais como plataforma de execução (o que de fato sempre foi desde o início), pois estão surgindo diversas novas linguagens para a plataforma (Groovy, JRuby, Scala, Grails, etc.), ao passo que a linguagem Java, em si, já está chegando ao fim de sua própria evolução (não que a linguagem Java vá morrer, mas sim vai dar uma “estacionada”).[/quote]

Pois é, o negócio é não se amarrar em nada, o Mono tá aí, correndo por fora mas do jeito que a VM deles vai e os projetos de linguagens dinâmicas na CLR comecem a dar resultados mais concretos, a concorrência vai aumentar e muito.

A questão hoje é não ficar se matando ou defendendo isso ou aquilo com unhas e dentes, mas estar preparado e de olho no futuro (e no passado também :] ) pra não perder tempo querendo apertar um parafuso a martelada.

#78

[quote=saoj]Como viver sem o “Open Call Hierarchy” ???

Isso me assusta um pouco. As facilidades do Eclipse para o Java, tais como auto-complete, refactoring, auto-compile, show call hierarchy, etc. agilizam muito o desenvolvimento e a manutenção de um projeto grande, cheio de classes.[/quote]

Aí agente volta pra velha história do ovo e da galinha. A primeira ferramenta de refactoring refatorava o que? Smalltalk!

Bingo!

De qualquer forma, uma boa cobertura de testes sempre ajuda a simplificar esses trabalhos.

#79

[quote=pcalcado][quote=Javabuntu]** somente pra aqueles que mencionaram que RoR pode “roubar” a cena do java…

vejam aqui

acho que eu não estarei mais por aqui quando isso acontecer… :shock: [/quote]

Eu não acho que Ruby o Rails vá ‘roubar a cena do java’, apesar de achar que ‘a cena do Java’ tem dias contados, mas só um exercício: você se lembra quando java chegou ao topo dessa lista? Ou quando comemoramos que Java tinha mais projetos que C+ no SourceForge? Lembra quando tudo o Brasil era Delphi, ASp e PHP e Java era ‘muito lenta, não tem boa ferramenta’, etc.?

Sinceramente, eu não sei se as pessoas esquecem ou simplesmente não viveram isso.[/quote]

concerteza o java não vá durar pra sempre, assim como na área de TI nada é sustentável infinitamente… (pra comentários que houve sobre isso) só alertei pelo ponto de vista de que dificilmente o RoR vai ultrapassar o java, com as possibilidades de mercado e as metodologias ágeis de desenvolvimento cada dia ganhando mais e mais força…e o java ser muito amarrado, framework pra tudo… concerteza pouco tempo ai teremos algo tomando essa fatia de mercado…

#80

JAVA AINDA É MAIS MERCADO, EM FAVOR DE SEU CÓDIGO ABERTO GERAR DEMANDA DE OUTRAS TENDÊNCIAS TECNOLOGICAS ATÉ ENTÃO NÃO EXPLORADA, É CERTO QUE SE HOUVER MUNDANÇAS AINDA ASSIM SERÁ SUTIL

[color=blue] O que a Sun tem feito?[/color][size=18] [/size]
No JavaOne Conference em 2006, a Sun se comprometeu em abrir o código de toda a sua plataforma Java. No dia 13 de novembro, a Sun fez a liberação inicial dos componentes de suas principais implementações:

* Java Standard Edition (tradicionalmente executado em desktops)
* Java Micro Edition (geralmente encontrado em telefones e outros dispositivos embutidos)
* Java Enterprise Edition (tipicamente a base de uma infra-estrutura corporativa)

Cada uma dessas liberações ocorreu sob o GNU General Public License (GPLv2). Especificamente, a Sun abriu o código de importantes aspectos de seu Java SE (incluindo máquina virtual HotSpot, compilador javac e sistema de documentação JavaHelp) e Java ME (incluindo o código CLDC e CDL otimizado da Sun). Além disso, a empresa reiterou sua promessa de liberar todo o Java JDK em licenciamento de código aberto até o primeiro semestre de 2007.

A escolha do modelo de licenciamento para a liberação dessas implementações foi um dos aspectos mais especulados da decisão. O código do Java SE JDK foi aberto usando o GPLv2 com a exceção Classpath, e o Java ME foi liberado sob GPLv2 direto. Ao escolher o esquema de licenciamento no cerne da comunidade GNU/Linux, a Sun está buscando os desenvolvedores que, no passado, talvez não tivessem escolhido imediatamente o Java como solução. A escolha de GPL também deverá maximizar os benefícios para quem já usa código aberto, especialmente os membros da comunidade Linux.

A Sun é atualmente quem mais contribui para as comunidades de software livre e GPL.

Admite-se que a decisão da Sun de abrir o código da tecnologia Java cria potencial para implementações conflitantes da plataforma. Mas a Sun traz um valor único ao cenário do Java de código aberto, e ainda possui as implementações Java SE e Java ME padrão gold. A Sun ? como principal arquiteta da tecnologia Java e do JDK ? oferece muitos recursos para desenvolvedores e anos de experiência no equilíbrio das necessidades de um ecossistema Java complexo. Ambos contribuirão para que a Sun preserve sua função de orientar a compatibilidade da plataforma Java.

Que oportunidades o Java de código aberto cria?
Bem, agora que sabemos o que a Sun fez e por quê, vamos examinar algumas das implicações para clientes, desenvolvedores e para a própria Sun. É desnecessário dizer que as ramificações da tecnologia Java de código aberto estão se espalhando.

Para os clientes, a tecnologia Java de código aberto promete muitas recompensas. Com a abertura do código da principal plataforma para Web, os clientes adotam a tecnologia Java com plena confiança de que não ficarão presos à tecnologia ou a uma implementação. E com a tecnologia Java disponível livremente, ela estará sujeita às forças do mercado que ajudam a promover a concorrência e reduzir os preços. Além disso, com a capacidade da Sun e as comunidades Java Community Process (JCP) e Java Specification Request (JSR) para ajudar a direcionar o desenvolvimento, os custos para mudar de uma implementação Java para outra serão baixos.

A tecnologia Java de código aberto se traduz em inovação mais rápida. No mundo do código aberto, existe mais concorrência de desenvolvedores que buscam criar aplicativos de melhor desempenho e mais recursos. Isso resultará em melhores produtos, preços mais baixos e redução do custo total de propriedade. Além disso, essas mudanças serão mais tangíveis no data center ? onde a prioridade é fornecer os serviços de melhor qualidade pelo custo mais baixo ?, porque ao usar uma implementação de código aberto da tecnologia Java, os desenvolvedores terão condições de criar grandes aplicativos empresariais compostos por um custo muito menor.

Para os desenvolvedores, a tecnologia Java de código aberto oferece maior flexibilidade e a possibilidade de explorar a tecnologia Sun de maneiras novas e inesperadas. [color=black]Por exemplo, em ambientes da Web 2.0, existem muitas linguagens novas e dinâmicas (vem à mente o Ruby on Rails) que estão sendo desenvolvidas fora da Sun[/color]. A maior parte dessas linguagens é executada em seus próprios intérpretes ou máquinas virtuais.

[color=blue]Com uma máquina virtual Java de código aberto, e com a Sun e a comunidade trabalhando para acrescentar suporte a essas linguagens dinâmicas, é possível, se não provável, que a linguagem Java não seja mais a única beneficiária da máquina virtual Java. Em outras palavras, a máquina virtual Java pode se tornar uma tecnologia reutilizável que pode ser explorada em muitas linguagens diferentes. Os desenvolvedores terão a estabilidade e desempenho da máquina virtual Java, bem como a possibilidade de usá-la em seus próprios aplicativos que não são com Java.
[/color]
Por fim, o código aberto promete trazer mais desenvolvedores à comunidade de tecnologia Java, o que resultará em aumento da concorrência, mais inovação e custos mais baixos para os clientes. Vale repetir ? [size=24]O volume gera oportunidade e benefícios.[/size]

Bob Brewin
Diretor de tecnologia da Sun Software e Engenheiro Emérito Sun
Sun Microsystems, Inc.