Sven, eu concordo com tudo isso que voc� falou, acho que realmente � o mais justo e mais interessante do ponto de vista tecnol�gico. O que eu quis dizer, � que talvez a propaga��o da tecnologia da MS seja feita de uma maneira menos traum�tica para pessoas/corpora��es que antes n�o tinham contato com essas novas tecnologias de alto n�vel. Vou te dar um relato pessoal do que est� ocorrendo comigo, talvez fique mais f�cil de eu me explicar. Sou um desenvolvedor com um belo curr�culo, domino PHP, Perl, ASP e afins. Estava num �timo n�vel na minha carreira, tanto financeira quanto profissional. A� minha ex-empresa(uma grande empresa) passou por maus bocados e demitiu uma galera, bem quando eu tinha chegado em um cargo de n�vel gerencial. A� comecei a ver o mercado e vi que nessas tecnologias que eu dominava quase n�o havia mais demanda para um analista de sistemas / coordenador. Ent�o resolvi investir em Java. Fiz cursos na FastTraining (paguei uma nota e a qualidade n�o foi das melhores), fui a todos os eventos poss�veis para me integrar e tal. Mas continuo com grandes dificuldades de ter confian�a para me arriscar no mercado Java, pois s�o tantas as siglas, especifica��es, e coisas do tipo. Hoje j� tenho um bom conhecimento em Java (core), estou tentando me ambientar com todo o resto que � a parte mais importante para entrar no mercado. Sintetizando: com tanta abrang�ncia da tecnologia Java, tantas siglas dif�ceis de se entender, a estrat�gia da MS tem conseguido levar uma quantidade grande de desenvolvedores pro seu lado, exatamente por eles terem um produto mais definido, que voc� consegue ter uma vis�o geral do produto deles mais facilmente. Isso � ruim, pois mesmo eu achando que a tecnologia Java � bem mais "power", te da mil possibilidades, mas na hora de algumas empresas e profissionais escolherem pra onde migrar, tenho ouvido relatos que a MS est� levando vantagem, e li alguns artigos em sites americanos que isso est� sendo mais evidente por l�. Posso estar bem enganado, s� estou relatando algo que est� acontecendo comigo, e estou com s�rias dificuldades de lidar com isso.
Grande abra�o a todos. Danilo Marcolin -----Mensagem original----- De: [EMAIL PROTECTED] [mailto:sven@;cilix.com.br] Enviada em: quarta-feira, 30 de outubro de 2002 10:03 Para: [EMAIL PROTECTED] Assunto: Re: RES: RES: [enterprise-list] CMP ou BMP Danilo Marcolin de Almeida C�sar <[EMAIL PROTECTED]> wrote on 30/10/2002 10:36:13: > Alias acho que essa � uma falha da SUN em rela��o a tecnologia Java, n�o > dar prioridade a nada, e na minha opini�o isto � o que vai fazer > tecnologia da MS ganhar espa�o sobre o Java, at� porque tenho conversado > com um pessoal e parece que est� sendo muito mais f�cil pra > profissionais que n�o tinham contato com nenhuma das tecnologias, > iniciar j� de um bom n�vel em .Net, do que em Java. Eu n�o acho uma falha, mas uma exelente qualidade. Java hoje em dia tem API para quase tudo e como Robson diz haja v�rias soluc�es para porblemas, basta escolher o melhor. O .net sempre ser� um produto e n�o um framework baseadas em technologias abertas, portanto n�o h� escolha e n�o temos influencia na dire��o da technologia, uma coisa que temos com Java, basta preencher o JSPA, assinar, mandar por fax para Santa Clara e vc manda(pelo menos um pouquinho) seu voto ter� o mesmo valor do voto do James Grosling. > > > -----Mensagem original----- > De: Robson Luis Ferreira [mailto:rlsferreira@;yahoo.com.br] > Enviada em: quarta-feira, 30 de outubro de 2002 10:07 > Para: [EMAIL PROTECTED] > Assunto: Re: RES: [enterprise-list] CMP ou BMP > > Pessoal > > T� pegando fogo essa thread !!! > > J� foram citadas v�rias op��es para a camada de > banco de dados - BMP, CMP, DAO, JDO -, cada qual com > suas vantagens e seus defeitos. Se existisse uma > f�rmula perfeita vcs n�o acham que todos n�s > usar�amos, a SUN daria prioridade total para ela, n�o > haveria discuss�es a esse respeito, estar�amos todos > felizes, a fome no mundo acabaria, etc., etc., etc. ?? > Acho que cada caso � um caso, e n�o h� como definirmos > um padr�o sem antes estudar as necessidades, infra e > padr�es do projeto e do cliente e nossa pr�pria > seguran�a em desenvolver com qualidade e prazos > satisfat�rios, e pessoalmente eu tenho minha opini�o > (DAO quase sempre) e cada um tem a sua. Algu�m duvida > disso ? > > Robson Luis Ferreira > [EMAIL PROTECTED] > > > --- Antonio Kantek <[EMAIL PROTECTED]> escreveu: > > > > ----- Original Message ----- > > From: <[EMAIL PROTECTED]> > > To: <[EMAIL PROTECTED]> > > Cc: <[EMAIL PROTECTED]> > > Sent: Wednesday, October 30, 2002 8:57 AM > > Subject: Re: RES: [enterprise-list] CMP ou BMP > > > > > > "Antonio Kantek" <[EMAIL PROTECTED]> wrote on > > 29/10/2002 14:21:04: > > > > > Essa thread CMP x BMP est� ficando interessante. > > > Eu vi que algum colega falou que os ger�nciadores > > de persist�ncia s�o > > feitos > > > por pessoas que entendem e por isso s�o bons. Bom, > > o que eu vejo, � que > > o > > > nosso colega realmente tem raz�o, as > > implementa��es s�o muito boas (ex > > > JBossCMP). Mas o grande problema � que a > > especifica��o � uma droga. > > > N�o � nem fraca... ou incompleta, � uma droga > > mesmo. > > > > > > Por exemplo: a EJB-QL s� pode ter sido > > especificada por autistas que > > > nunca escreveram um software cr�tico na vida. Como > > uma linguagem de > > > pesquisas n�o tem LIKE parametriz�vel ? > > > > Isso foi feito de proposto. Um finder no EJB n�o > > deveria devolver muitos > > objetos pois impacta muito no performance (uso de > > memoria etc). LIKE > > tipicamente devolve muitos registros do DB e por > > isso foi deixado fora da > > especifica��o. > > > > Sim, mas por isso que eu digo que as pessoas que > > fizeram a especifica��o s�o > > autistas. > > Se essa preocupa��o realmente fosse v�lida, a > > JBossQL com seu LIKE > > paramatriz�vel n�o > > faria tanto sucesso. > > > > > Quanto aos CMP 1.x s� pode ser piada aquilo. Eles > > n�o possuem os CMR, os > > > atributos de liga��o. Isso implica em termos um > > modelo de componentes > > que > > > mais > > > se parecem com as tabelas do que com qualquer > > outra coisa. Isso � > > ridiculo, > > > nenhum mecanismo de persist�ncia do passado era > > t�o ruim assim. > > > > CMR � bom e � ruim, como j� foi dito nesta > > discuss�o. O que pode ser feito > > com CMR en EJB 2.0 j� fiz tamb�m com CMP 1.1. Em > > termos de modelagem n�o � > > t�o complicado. > > > > Complicado n�o �. Mas tamb�m n�o � nada elegante. > > > > > > > > > > > --------------------------------------------------------------------- > > Para cancelar a subscri��o, envie mensagem para: > > [EMAIL PROTECTED] > > Para comandos adicionais, envie mensagem para: > > [EMAIL PROTECTED] > > > > > > > > > > > --------------------------------------------------------------------- > > Para cancelar a subscri��o, envie mensagem para: > > [EMAIL PROTECTED] > > Para comandos adicionais, envie mensagem para: > > [EMAIL PROTECTED] > > > > _______________________________________________________________________ > Yahoo! GeoCities > Tudo para criar o seu site: ferramentas f�ceis de usar, espa�o de sobra > e acess�rios. > http://br.geocities.yahoo.com/ > > --------------------------------------------------------------------- > Para cancelar a subscri��o, envie mensagem para: > [EMAIL PROTECTED] > Para comandos adicionais, envie mensagem para: > [EMAIL PROTECTED] > > > --------------------------------------------------------------------- > Para cancelar a subscri��o, envie mensagem para: enterprise-list- > [EMAIL PROTECTED] > Para comandos adicionais, envie mensagem para: enterprise-list- > [EMAIL PROTECTED] --------------------------------------------------------------------- Para cancelar a subscri��o, envie mensagem para: [EMAIL PROTECTED] Para comandos adicionais, envie mensagem para: [EMAIL PROTECTED] --------------------------------------------------------------------- Para cancelar a subscri��o, envie mensagem para: [EMAIL PROTECTED] Para comandos adicionais, envie mensagem para: [EMAIL PROTECTED]
