Re: RES: [java-list] Re: to be EJB or not to be
Rapazeada onde eu consigo uns livros legais de java? Na livraria Cultura (www.livrariacultura.com.br), eles tem uma vasta seleção. Eu pessoalmente recomendo visitar eles na Paulista, os vendedores são atenciosos e competentes. Todos os livros lá são legais no sentido de legalidade e a maioria são legais no sentido de interessantes. Rafael -- LISTA SOUJAVA http://www.soujava.org.br - Sociedade de Usuários Java da Sucesu-SP dúvidas mais comuns: http://www.soujava.org.br/faq.htm regras da lista: http://www.soujava.org.br/regras.htm historico: http://www.mail-archive.com/java-list%40soujava.org.br para sair da lista: envie email para [EMAIL PROTECTED] -
Re: RES: [java-list] Re: to be EJB or not to be
Rapazeada onde eu consigo uns livros legais de java? sds, Thiago Antonio - Desenvolvedor Delphi/Oracle -- POP. Nem parece internet grátis. Seja POP você também! Acesse: http://www.pop.com.br/pop_discador.php e baixe o POPdiscador. -- LISTA SOUJAVA http://www.soujava.org.br - Sociedade de Usuários Java da Sucesu-SP dúvidas mais comuns: http://www.soujava.org.br/faq.htm regras da lista: http://www.soujava.org.br/regras.htm historico: http://www.mail-archive.com/java-list%40soujava.org.br para sair da lista: envie email para [EMAIL PROTECTED] -
Re: RES: [java-list] Re: to be EJB or not to be
Boa SILVIO, Só gostaria de ressaltar algumas coisas no comentário que você fez. Cada Tecnologia tem seus objetivos e seus problemas a solucionar. Por exemplo: O CVS não tem a intenção de proteger nada e sim manter um registro de versão. Se você for no CVS e baixar o manual logo nas primeiras página ele declara que o CVS não é para gerenciar com quem tah que arquivo e sim quem alterou tal arquivo e em que hora e tem tal versão, isso é controle de versão. Outro exemplo: A tecnologia J2EE tem o objetivo de separar as fazes de desenvolvimento e implantação de um sistema. Minimizar o esforço e preocupação do desenvolvedor com coisas de mais baixo nível (como meios de conexão entre cliente/servidor) e deixar ele se preocupar apenas com regras de negocio. Concordo com você quando diz que exageram na parte teorica e fazem você ler e encucar coisas como Desing Patterns, mas o que são Desing Patterns. São Padrões de Projeto, de uns caras que um dia tavam programando e viram que o jeito de comunicação X dava menos problema de manutenção. Você tem todo o poder de adotar um padão de projeto ou não. Mas lembre-se se você for fazer alguma coisa provavelmente vai usar alguns desse padrões, mesmo sem perceber, ou seja você reinventou a roda e nem sabe que se chama roda. O fato de ter alguns padrões enumerados ajuda no projeto do sistema. Sem mais. = /* Rafael José Peres Correia EMail: [EMAIL PROTECTED] AOLmsg: RafaelJPC ICQ#: 10193430 */ ___ Yahoo! Mail Mais espaço, mais segurança e gratuito: caixa postal de 6MB, antivírus, proteção contra spam. http://br.mail.yahoo.com/ -- LISTA SOUJAVA http://www.soujava.org.br - Sociedade de Usuários Java da Sucesu-SP dúvidas mais comuns: http://www.soujava.org.br/faq.htm regras da lista: http://www.soujava.org.br/regras.htm historico: http://www.mail-archive.com/java-list%40soujava.org.br para sair da lista: envie email para [EMAIL PROTECTED] -
RES: RES: [java-list] Re: to be EJB or not to be CVSxSS
Agradeço, pelo link...muito interessante. Mas ocorre que quando você esta trabalhando com manutenção e as tarefas são divididas, muitas vezes termos que fazer trabalhos conjuntos em cima do mesmo arquivo e/ou no mesmo ponto, principalmente quando você trabalha com integração de sistemas. E ai é que vem o diferencial do SS em relação ao CVS...é mais simples e seguro, simplismente fecha o acesso a terceiros. Abraços, Silvio. P.S.: O problema de desenvolver uma aplicação não esta no agora, mas no DEPOIS ! -Mensagem original- De: Felipe Leme [mailto:[EMAIL PROTECTED] Enviada em: Tuesday, June 24, 2003 10:46 AM Para: [EMAIL PROTECTED] Assunto: Re: RES: [java-list] Re: to be EJB or not to be On Monday 23 June 2003 08:31 am, SILVIO AMERICO GARCIA CICOTI wrote: Será que eu sou idiota, ou estou usando o CVS de forma errada Você está usando o CVS de forma errada. Porquê toda vez que vou usar um arquivo tal para dar manutenção tenho que avisar meu colega do lado: - olha cara, se você for mexer no arquivo tal...esta comigo viu !!! ISSO É HORRIVEL !!! CVS significa Concurrent Version System. Ou seja, é um sistema planejado para as pessoas acessarem os arquivos concorrentemente. Você pode ter um arquivo grande com 2 pessoas modificando o arquivo em partes diferentes que o CVS fará o merge automático das mudanças. Agora, se as 2 pessoas estão mexendo simultaneamente na mesma parte do arquivo, realmente dará conflito. Fica aí a pergunta: a falha é do CVS por fazer o merge ou do gerenciamento do projeto, onde 2 pessoas editaram o mesmo recurso ao mesmo tempo? Felipe PS: uma boa fonte de informação sobre o CVS é o CVS Book (http://cvsbook.red-bean.com/cvsbook.html). Por exemplo: To understand what this has to do with facilitating collaboration, we'll need to take a closer look at the mechanism that CVS provides to help numerous people work on the same project. But before we do that, let's take a look at a mechanism that CVS doesn't provide (or at least, doesn't encourage): file locking. If you've used other version control systems, you may be familiar with the lock-modify-unlock development model, wherein a developer first obtains exclusive write access (a lock) to the file to be edited, makes the changes, and then releases the lock to allow other developers access to the file. If someone else already has a lock on the file, they have to release it before you can lock it and start making changes (or, in some implementations, you may steal their lock, but that is often an unpleasant surprise for them and not good practice!). This system is workable if the developers know each other, know who's planning to do what at any given time, and can communicate with each other quickly if someone cannot work because of access contention. However, if the developer group becomes too large or too spread out, dealing with all the locking issues begins to chip away at coding time; it becomes a constant hassle that can discourage people from getting real work done. CVS takes a more mellow approach. Rather than requiring that developers coordinate with each other to avoid conflicts, CVS enables developers to edit simultaneously, assumes the burden of integrating all the changes, and keeps track of any conflicts. This process uses the copy-modify-merge model, which works as follows: 1. Developer A requests a working copy (a directory tree containing the files that make up the project) from CVS. This is also known as checking out a working copy, like checking a book out of the library. 2. Developer A edits freely in her working copy. At the same time, other developers may be busy in their own working copies. Because these are all separate copies, there is no interference - it is as though all of the developers have their own copy of the same library book, and they're all at work scribbling comments in the margins or rewriting certain pages independently. 3. Developer A finishes her changes and commits them into CVS along with a log message, which is a comment explaining the nature and purpose of the changes. This is like informing the library of what changes she made to the book and why. The library then incorporates these changes into a master copy, where they are recorded for all time. 4. Meanwhile, other developers can have CVS query the library to see if the master copy has changed recently. If it has, CVS automatically updates their working copies. (This part is magical and wonderful, and I hope you appreciate it. Imagine how different the world would be if real books worked this way!) As far as CVS is concerned, all developers on a project are equal. Deciding when to update or when to commit is largely a matter of personal preference or project policy. One common strategy for coding projects is to always update before commencing work on a major change and to commit only when
Re: RES: [java-list] Re: to be EJB or not to be
On Monday 23 June 2003 08:31 am, SILVIO AMERICO GARCIA CICOTI wrote: Será que eu sou idiota, ou estou usando o CVS de forma errada Você está usando o CVS de forma errada. Porquê toda vez que vou usar um arquivo tal para dar manutenção tenho que avisar meu colega do lado: - olha cara, se você for mexer no arquivo tal...esta comigo viu !!! ISSO É HORRIVEL !!! CVS significa Concurrent Version System. Ou seja, é um sistema planejado para as pessoas acessarem os arquivos concorrentemente. Você pode ter um arquivo grande com 2 pessoas modificando o arquivo em partes diferentes que o CVS fará o merge automático das mudanças. Agora, se as 2 pessoas estão mexendo simultaneamente na mesma parte do arquivo, realmente dará conflito. Fica aí a pergunta: a falha é do CVS por fazer o merge ou do gerenciamento do projeto, onde 2 pessoas editaram o mesmo recurso ao mesmo tempo? Felipe PS: uma boa fonte de informação sobre o CVS é o CVS Book (http://cvsbook.red-bean.com/cvsbook.html). Por exemplo: To understand what this has to do with facilitating collaboration, we'll need to take a closer look at the mechanism that CVS provides to help numerous people work on the same project. But before we do that, let's take a look at a mechanism that CVS doesn't provide (or at least, doesn't encourage): file locking. If you've used other version control systems, you may be familiar with the lock-modify-unlock development model, wherein a developer first obtains exclusive write access (a lock) to the file to be edited, makes the changes, and then releases the lock to allow other developers access to the file. If someone else already has a lock on the file, they have to release it before you can lock it and start making changes (or, in some implementations, you may steal their lock, but that is often an unpleasant surprise for them and not good practice!). This system is workable if the developers know each other, know who's planning to do what at any given time, and can communicate with each other quickly if someone cannot work because of access contention. However, if the developer group becomes too large or too spread out, dealing with all the locking issues begins to chip away at coding time; it becomes a constant hassle that can discourage people from getting real work done. CVS takes a more mellow approach. Rather than requiring that developers coordinate with each other to avoid conflicts, CVS enables developers to edit simultaneously, assumes the burden of integrating all the changes, and keeps track of any conflicts. This process uses the copy-modify-merge model, which works as follows: 1. Developer A requests a working copy (a directory tree containing the files that make up the project) from CVS. This is also known as checking out a working copy, like checking a book out of the library. 2. Developer A edits freely in her working copy. At the same time, other developers may be busy in their own working copies. Because these are all separate copies, there is no interference - it is as though all of the developers have their own copy of the same library book, and they're all at work scribbling comments in the margins or rewriting certain pages independently. 3. Developer A finishes her changes and commits them into CVS along with a log message, which is a comment explaining the nature and purpose of the changes. This is like informing the library of what changes she made to the book and why. The library then incorporates these changes into a master copy, where they are recorded for all time. 4. Meanwhile, other developers can have CVS query the library to see if the master copy has changed recently. If it has, CVS automatically updates their working copies. (This part is magical and wonderful, and I hope you appreciate it. Imagine how different the world would be if real books worked this way!) As far as CVS is concerned, all developers on a project are equal. Deciding when to update or when to commit is largely a matter of personal preference or project policy. One common strategy for coding projects is to always update before commencing work on a major change and to commit only when the changes are complete and tested so that the master copy is always in a runnable state. Perhaps you're wondering what happens when developers A and B, each in their own working copy, make different changes to the same area of text and then both commit their changes? This is called a conflict, and CVS notices it as soon as developer B tries to commit changes. Instead of allowing developer B to proceed, CVS announces that it has discovered a conflict and places conflict markers (easily recognizable textual flags) at the conflicting location in his copy. That location also shows both sets of changes, arranged for easy comparison. Developer B must sort it all out and commit a new revision with the conflict resolved. Perhaps the two developers will
RES: [java-list] Re: to be EJB or not to be
Gostaria expor meu ponto de vista, sobre alguns assuntos, e se possivel que fosse criticado por vocês. Vejo que todo projeto novo, o pessoal cria um monte de novos ejbs, e qual a necessidade disso ? Onde está a otimização e a reutilização dos ejbs criados em outros projetos ? Por que não se cultura uma biblioteca de ejbs, independente de projeto, onde estes estariam catalogados e muito bem mantidos, disponiveis para outros projetos atraves de façades. Talvez cada desenvolvedor queira implementar de sua maneira, mas acaba por fim repetindo a mesma solução de retornar os dados do cliente de diversas formas. Por causa dessa falta de organização, não me sinto confortavel de trabalhar com ejbs, sabendo que muito provavelmente já exista, escondido em algum lugar da empresa algum ejb que faça o que eu quero, mas não sei aonde ou em que instancia ele se encontra, e o pior quanto a sua manutenção, você esta usando um ejb de um projeto tal...um dia alguem vai la e muda tudo e você dança. Assim fica dificil criar um padrão de distribuição. Já que levantei com o pé esquerdo, vou abordar outro assunto... Será que eu sou idiota, ou estou usando o CVS de forma errada. Porquê toda vez que vou usar um arquivo tal para dar manutenção tenho que avisar meu colega do lado: - olha cara, se você for mexer no arquivo tal...esta comigo viu !!! ISSO É HORRIVEL !!! Estamos retrocendendo ou o quê, ou será uma questão de habito ? Será que niguem vai querer quebrar os padrões ? E falar...vamos usar o Source Safe, é mais prudente ! Estou ficando cançado de bitola, JAVA é legal mas não é perfeito. ...outro assunto. Ai você participa de um projeto e vê que a coisa esta ficando cada vez mais complexa...e para cada intervenção você leva meio dia para implementar uma nova funcionalidade. Qual o motivo disso ? Não que JAVA seja dificil, mas o pessoal vai construindo patterns sobre patterns e a coisa fica complicada de manter...sera que o glamur de ser dificil subiu na cabeça do pessoal. Ai vem neguinho (gerente) e fala: -Pô .NET é bem mais simples ! Eu concordoNET é bem mais simples. Por que as coisas são mais diretas ! Eu conheci um gerente usuário de um sistema que dizia o seguinte: - Eu analiso a funcionalidade do sistema pela quantidade de clicks que o operador tem que dar até chegar aonde se quer. Veja...é igual ao desenvolvimento de um projeto, quantas telas eu tenho que passar até conseguir dizer ao banco de dados que eu quero o nome de fulano de tal. É claro que devemos manter um minimo de organização...mas por que as coisas não são mais diretas. Usar struts é legal, MVC é correto...mas tudo deve ter um limite, uma adequação para cada tipo de projeto. Pronto...terminei ! Vejo que o problema não é java, muito longe disso. Mas o que as pessoas estão fazendo para torna-lo melhor ou pior. Temos que realmente pesar bem o que o usuario quer, e deixar nosso EGO de desenvolvedor não sufocar o projeto por tanta tecnologia. Um abraço a todos e até mais. Silvio. -Mensagem original- De: Carloshp Silva [mailto:[EMAIL PROTECTED] Enviada em: Friday, June 20, 2003 1:36 PM Para: [EMAIL PROTECTED] Assunto: [java-list] Re: to be EJB or not to be Jah participei de um grande projeto usando EJBs, e a impressao que ficou nao foi positiva. De qualquer forma, como foi usan- do a versao 1.0 da especificacao, nao seria justo eu tecer comentarios, entao sugiro esta leitura sobre o porque NAO adotar EJBs. Independente da especificacao, muitos fatos apon- tados neste artigo sao constatacoes tecnicas, muitas das quais eu vi na pratica e que tem a ver com a arquitetura da so lucao. http://www.softwarereality.com/programming/ejb/index.jsp []s, Carlos Em Wed, 18 Jun 2003 13:59:45 -0300, linux [EMAIL PROTECTED] disse: Caros Amigos, Em um projeto que estou envolvido estamos em um ponto de decisao sobre adotar ou nao EJBs. Como nosso projeto tem um publico pequeno menos de 100 pessoas, visa performance, utilizacao otimizada dos recuros de hardware (que sao poucos) devo apontar as vantagens e desvantagens de se utilizar EJBs. Entao gostaria de fazer uma pergunta, levando-se em conta que: 1) A performance eh fundamental, pois a massa de dados manipulada eh imensa. 2) Nao havera processamento distribuido pois temos apenas uma maquina HP-UX 32 proc. 3) O tempo de desenvolvimento do projeto eh muito curto. 4) O numero de usuarios eh bem pequeno. Quais vantagens e desvantagens voces vem em se utilizar EJBs? Gostaria imensamente de saber as opinioes e experiencias de voces. Muito obrigado Joao Pedro
