Hein? Hein?
Eu também não falei que ele disse que Java á mau. Só disse que achei, e continuo achando, que o texto é voltado para o mercado/cultura Micro$oft.
Hein? Hein?
Eu também não falei que ele disse que Java á mau. Só disse que achei, e continuo achando, que o texto é voltado para o mercado/cultura Micro$oft.
Hein? Hein?
Eu também não falei que ele disse que Java á mau. Só disse que achei, e continuo achando, que o texto é voltado para o mercado/cultura Micro$oft.[/quote]
Então cara, por quê? O que ele escreveu que é cultura M$, o que ele escreveu de INADEQUADO?
É a cultura do vender acima de tudo, acima da qualidade da cominidade de desenvolvedores? Se é, tá, não reparei coisas assim no texto.
Desculpem, estive fora o dia todo e não deu tempo de acompanhar essa discussão, bem interessante por sinal.
Vamos por partes:
1.1-Marcio Tavares, quanto aos problemas que você citou, sou capaz de apostar que todos têm solução. A sessão que expira pode ser configuração incorreta do webgardening ou estouro de sessões, ambas têm como serem solucionadas. Posso te mostrar um monte de sites (até o site onde eu invisto em ações que comentei com o luka e o internet banking que eu e uso) que são feitos em asp.net e ficam de pé (diferente do Orkut). Anos dando suporte nessas coisas e a gente vai “pegando as manhas”
1.2-A compatibilidade com W3C do ASP.Net é perfeitamente possível, também tem configurações para isso.
1.3-Os scripts de validação gerados por ele fazem o básico, a idéia é ir extendendo com os seus ou com os de terceiros. Tenho uns que eu fiz e uso uma biblioteca que gosto muito, chamanda Infragistics, toda em .Net, ela também ajuda. Também muita coisa vai mudar nessa parte agora com o VS 2005.
1.4-Também não uso o WebMatrix, dei só um exemplo de uma ferramenta de 4 mega feita em C#, se o tamanho for algo que importa Também pode usar o notepad e compilar em linha de comando, tem gosto pra tudo.
1.5-Vamos pegar o Excel. Eu uso 5% do que o Excel oferece. Meu colega usa outros 5%. Conheço outro cara que usa 20%. Minha mãe usa 0.5%. Se você quer fazer um produto que atenda milhões de pessoas, com certeza ele SEMPRE vai ter mais recursos do que cada uma delas individualmente usa. Você usa tudo o que o J2EE te oferece? Já vi cara da IBM na frente do Websphere mudando entre as milhares de páginas de configuração e não conseguindo dizer exatamente como configurar WS-Security lá, enquanto no Visual Studio você faz isso em minutos… As ferramentas estão ficando complexas mesmo, bom pra nós que somos bons e vamos ter muito mercado para ensinar a usa-las.
2-Gostei dos 4 mandamentos! Só não entendi por que quando eu falo que o negócio é mais importante, sou taxado de defender software mal feito, mas quando vocês falam que o negócio vem em primeiro lugar, a coisa muda de figura… não estamos falando da mesma coisa? Também vi muita gente dizer que os meus tópicos estavam corretos, mas com argumentos errados. Queria mesmo ver os argumentos adequados.
3-Não lembro quem me perguntou sobre o que eu falei dos Design Patterns e a tecnologia. Pois bem, um exempo super polêmico: Existe uma discussão no mundo Microsoft sobre o que usar na camada de persistência. Alguns defendem o nHibernate (irmão do Hibernate em .Net), outros o Gentle.Net, e por aí vai… O .Net traz built-in os DataSets, que são mapeamentos de XSD Schemas para classes, propriedades e coleções. Daí como não existia nenhum Design Pattern que falasse de DataSets (agora até estão aparecendo), muita gente preferia não usa-los, mesmo em projetos mais simples onde eles resolviam 100% a necessidade. Agora na versão nova viriam os ObjectSpaces numa abordagem mais inteligente e performática que o nHibernate, mas adiaram isso mais pra frente.
Outro exemplo foi num curso de .Net que eu dei para uma turma de analistas que trabalhavam com java (isso mesmo, já treinei uns 150 profissionais java em .Net, e acredito que nenhum saiu decepcionado com essa tecnologia, mas aí é outro papo), e eles questionavam muito os Delegates do .Net. Diziam que esse não é um recurso 100% O.O. Eu defendia que na prática era exatamente a mesma coisa que vocês fazem com Interfaces, só que simplificado, e que nada impede que se use Interfaces do jeito tradicional também…
Entende a questão? É aquela velha discussão entre purismo x produtividade. E nenhum dos lados tem 100% de razão o tempo todo.
4-Obrigado aos que me defenderam!
Vixe, falei demais…
Mudando rapidamente de assunto, amanhã deve sair outro artigo meu, também polêmico. Só que dessa vez eu acho que vou apanhar da turma do VB, hehehe.
É sempre bom polemizar um pouquinho: gera reflexão. Só não vale soco na cara, nem xingar a mãe. =]
[size=12][quote=mateusvelloso]1.1…[/quote]
Mateus, como eu falei antes, nós tivemos que resolver o problema de outra forma na época (tem mais de um ano isso) e não pudemos esperar por outra solução. Se os consultores contradados foram incompetentes, aí eu não sei… pelo menos eles e a empresa contratada eram “certificados” pela M$.
Eu mantive contato com o pessoal dessa empresa que eu trabalhei e pelo que me disseram parece que o problema com as sessões já não existe mais, desde algumas versões atrás do .Net. Mas de qualquer forma, preferiram não usar sessões, para não terem um re-re-trabalho, e porque a confiança da tecnologia nesse ponto ficou abalada.
Pena que eu só vou estar de volta ao trabalho na segunda-feira, senão eu iria te mandar um link da MSDN falando sobre alguns objetos HTML que não existem no Asp.Net sem motivos muito claros. Tentei procurar agora mas não consegui achar, porque o sistema de busca do MSDN realmente acaba com a minha paciência… retorna coisas que não têm nada a ver com o que eu perguntei…
Vc tem algum link que tenha texto falando sobre isso?
Quando tivemos os problemas com validação que eu citei, nós chegamos ao ponto de ter que fazer manipulações diretamente no código javascript gerado em runtime pelo Asp.Net. Foi muito ruim fazer isso, porque o código gerado, até hoje, tem uma aparência muito “porca”. Me desculpe falar dessa forma, mas essa é a minha opinião pessoal. Vou fazer um comentário a respeito do que envolve isso, no final.
Existe também um produto similar mas pra C#, se eu não me engano o nome é SharpDeveloper, que tem um acabamento bem melhor que o WebMatrix, mas não é da M$. Acho que o WebMatrix poderia ter uma atenção maior, porque ele tem alguns problemas muito básicos.
Entendo o que vc quis dizer, mas eu acho que a comparação não é totalmente válida. O uso do Excel é um milhão de vezes mais genérico e amplo do que o do VS.Net, talvez isso justifique as porcentagens que vc colocou, mas não vamos entrar no mérito dos detalhes. Eu concordo com o que vc falou, mas eu continuo achando que o VS.Net tem opções demais pro que se propõe. Realmente, nesse ponto entraríamos em outro assunto porque eu acho que isso acontece pelo perfil da M$ querer criar coisas extremamente fáceis pra qualquer tipo de usuário. Dependendo do âmbito de aplicação dessas facilidades a coisa pode se tornar boa ou ruim. Pro Excel pode-se dizer que foi bom, mas pro VS.Net foi ruim, na minha opinião.
Eu tenho uma opinião a respeito disso. Talvez até me crucifiquem por causa disso, mas vamos lá:
Eu trabalho no mercado M$ desde 1998. Desde então já trabalhei com desenvolvimento, teste de software, engenharia de localização de software, um pouco de infra-estrutura, entre outras coisas. Com isso, eu fui criando uma opinião sobre qual é a diferença entre profissionais M$ e não-M$. Falando de uma forma curta, o perfil que eu sempre vi de quem trabalha com M$ geralmente é daquele tipo de profissional que não se importa nem um pouco com o que está fazendo e da forma como está fazendo. O que importa na verdade é o resultado final, a satisfação do cliente e o dindin no bolso o mais rápido possível. Por outro lado, os profissionais não-M$, e mais especificamente Java, têm um perfil, digamos assim, “romântico” de trabalho. É o cara que está preocupado não só com a lógica de negócios, mas em como o produto está sendo criado, está sempre com um olho no futuro pra não criar potenciais problemas para um eventual crescimento do produto e se interessa em saber como as coisas funcionam por trás dos panos, tentando sempre ficar minimamente dependente de outras coisas pra resolver seus problemas.
Qual é o perfil certo? Quem está certo, quem está errado? Existem muitos poréns nisso. Muitos acham que o que importa é a satisfação do cliente e ponto. Outros acham que tem que haver o meio termo entre os dois… enfim, é um assunto imenso.
Vejam bem: esses tipos de perfil que eu falei são de pessoas que trabalharam comigo até hoje. Principalmente de profissionais M$, e não foram poucos. Lógico que no mercado M$ existem ótimos profissionais e no mercado não-M$ também existem péssimos profissionais. Mas até hoje o que eu vi na prática foi o que eu citei.
Um exemplo: uma vez eu fui contratado para fazer manutenção e desenvolvimento de módulos num grande sistema que tinha partes em Asp tradicional e partes em Asp.Net. No dia que eu fui entrevistado eu fui almoçar com o dono da empresa e, papo vai, papo vem, eu perguntei pra ele se usavam alguma metodologia, modelagem etc e qual. Ele me olhou com uma cara de “tá maluco?” e falou “Nada disso! Aqui é pensou, escreveu. Rodou, entrega pro cliente!”. Durante os meses seguintes eu sofri por causa disso, porque basicamente a parte em Asp.Net era apenas uma imensa classe de ± 10mil linhas que fazia tudo. Fazer manutenção era uma gracinha…
Nessa mesma empresa eu ainda passei por uma outra situação onde um dos funcionários questionou de forma rude o planejamento que eu estava tendo com outro rapaz a respeito de uma nova funcionalidade. Resultado: esse funcionário acabou assumindo essa parte. Terminou em uma semana, beleza. No mês seguinte precisou fazer uma grande alteração e levou mais um mês e meio, porque teve que reescrever praticamente tudo, pois foi fazendo de qualquer jeito no começo. No final, eu e o outro rapaz provamos por A+B que do jeito que estávamos planejando isso não teria acontecido. Levaríamos uma semana no máximo, os dois, pra terminar, e menos de uma semana pras alterações necessárias. Por pouco o funcionário não foi demitido.
Isso sem falar que um dos bancos de dados dessa empresa tinha mais ou menos 50 tabelas sem nenhum relacionamento entre elas. A justificativa: “os relacionamentos estão dando muitos problemas, então decididos remover todos e tentar fazer a integridade via código.”
Outro bom exemplo que eu tenho foi quando eu trabalhei com Localização de Software. Nessa época eu tive contato direto com pessoas de dentro da M$. Fiz os projetos de localização do Office, Office Online, Windows, entre dezenas de outros produtos. Acho que foi nessa época que a ficha caiu de fato: a M$ não é nada mais que uma empresa como outra qualquer, mas em proporções maiores. Tem gente tapada como qualquer outro lugar, comete erros bisonhos como qualquer outra, não tem metodologia nenhuma etc…
Também trabalhei com um rapaz de redes que odiava Linux, porque dizia que “tinha que configurar muita coisa. No Windows eu dou 3 cliques e pronto”.
Na própria MSDN Magazine saiu uma entrevista com um desenvolvedor .Net radicado nos EUA, dizendo em um ponto porque tinha desistido do Linux: “é muita coisa pra estudar. No Windows é tudo mais fácil”.
Até hoje todos os sistemas feitos com tecnologia M$ que eu dei manutenção eram muito mal construídos. Sem planejamento nenhum e com pseudo-arquiteturas próprias no estilo bacalhau com batatas. Foi azar meu pegar só projetos assim? Ou a maioria É assim? Não sei.
Então, durante esse tempo todo eu percebi que, na maioria esmagadora das vezes, o profissional M$ tem uma base teórica mínima, muitas vezes nenhuma, enquanto que profissionais não-M$ ocorre totalmente o contrário.
Por que isso acontece? Na minha opinião por causa da filosofia da M$ de tornar tudo mais fácil pra todo mundo, inclusive suas tecnologias de desenvolvimento. Com isso, pessoas com preparo zero podem se aventurar em VBs e ASPs da vida, e fazer coisas que chamam de sistemas. Muitas dessas coisas torturaram a minha cabeça muitas vezes. Por esse motivo também, a remuneração pra profissionais M$ geralmente é bem menor.
Pra concluir esse ponto (ufa…) eu digo que a minha opinião a respeito do que vc falou sobre “falar sobre o negócio” é justamente a falta de preocupação do profissional M$ com o que acontece por trás dos panos em um sistema.
PS.: Estou generalizando mesmo. Senão, teria que triplicar o tamanho do texto. Mas eu tenho consciência das exceções dentro do que eu estou falando.
PS2.: Renato, acho que respondi à sua pergunta com isso, confere?
PS3.: Falei a palavra profissional(is) 10 vezes!
Esse é outro ponto que me irrita na M$: a cada momento surge uma solução pro mesmo problema, mas sem padronização nenhuma, isso quando não é cópia, como o Hibernate. Aí, esqueça o que vc aprendeu antes e aprenda outra coisa totalmente nova, do zero. Isso aconteceu do VS 2002 pro 2003, vai acontecer com o 2005 de novo e também quando o LongHorn sair.
Às vezes quando eu navego no MSDN eu fico assustado com a quantidade de funcionalidades novas que são criadas em pouquíssimo tempo. Muita coisa de segurança, muita coisa de configurações específicas, atualizações de funcionalidades incompatíveis com as anteriores… Menos 1 pra credibilidade.
Sim, Java também tem muito produto pra mesma coisa, mas pelo menos a maioria segue a mesma teoria. Isso sem falar na imagem totalmente voltada pro lado profissional da coisa, ao contrário da M$, que só quer saber de marketing. Muito ruim.
M$ e padrões: eu não entendo até hoje porque a M$ reluta tanto em adotar padrões, metodologias etc consagradas no mercado. Sempre quer criar uma tecnologia própria. Pra quem é profissional “híbrido”, isso é péssimo!
Eu vejo muito isso nos artigos do Mauro Santana. Ele adora alfinetar os outros… vive dizendo que o padrão SQL é vergonhoso, que o W3C não sabe o que faz com os seus padrões, entre outras baboseiras. Gostaria de ver ele falando a respeito do padrão próprio de *HTML que o IE tenta impor ao mercado há anos, antes de ele criticar o W3C.
Há algum tempo atrás eu vi um artigo de gente da própria M$ criticando a UML, e dizendo que iria criar uma linguagem de modelagem própria… prontamente, James Rumbaugh respondeu às críticas de forma bem firme. Pra que isso? Só pra ser “diferente”? Lógico que a UML tem os seus problemas mas acho que isso não justifica criar uma coisa totalmente nova pra só pra ser diferente. Odeio essa postura…
Eu acho que muitos dos problemas que acontecem com as tecnologias da M$ são mostras de uma certa “imaturidade” por parte da empresa. Tudo bem, muitos dos problemas já foram solucionados, mas eles não deveriam sequer ter existido nas versões públicas, como o problema das sessões por exemplo. Nesse caso, como eu falei, a confiança na tecnologia cai.
Bom, não concluí o texto do jeito que eu queria, mas eu dei a essência do que eu penso a respeito disso tudo. Tô tonto de sono já e não aguento escrever mais… :S[/size]
Sim, estamos falando da mesma coisa - o que talvez nao tenha ficado claro no seu artigo (e, peco desculpas, nao tive tempo de ler!) seja o foco em se manter pragmatico ao tentar elevar a qualidade do software desenvolvido, mesmo que pra isso se jogue um pouco do purismo de lado.
Aaaaaaaaah
Cade a diversao, entao? :mrgreen:
Olá
Aconteceu do Fortran 4.1 para o Fortran PowerStation, do C 3 para o C 5, do C 5.x para o C6.0, do VB 1 para o VB 3, do VB 3 para o VB4, do VB 4 para o VB 6, do Access 1 para o Access 2, do FoxPro anterior para o FoxPro3, do 3 para o seguinte, etc…
Realmente a falta de compromisso ou de respeito da Microsoft com a base instalada vem desde o início da empresa. Eles acham que rodar um programinha de migração resolve tudo.
[]s
Luca
Achei: http://www.ddj.com/documents/s=9211/ddj050201dnn/
Esse é o tragicômico: A Petition to Microsoft
Marcio, voce ta falando do Joel Spolsky?
Não, tô falando desses aí que eu coloquei em cima.
Mas vou dar uma lida nesse que vc mandou. :mrgreen: :thumbup:
Olá
Observações sobre os links que passaram em relação ao que disse no meu post anterior:
:arrow: Quando falei que os Fortrans eram incompatíveis não estava falanda da mudança do 77 para o 90 que na verdade são linguagens quase diferentes e sim de incompatibilidade de 2 implementações M$ da mesma linguagem.
:arrow: Não acredito que alguém possa ter migrado do Apple para o basic do PC mudando apenas 2 linhas de código em cada módulo a menos que seu programinha não usasse IO.
:arrow: Quando o Sr Joel Spolsky diz: [color=darkblue]“This was literally the first time in living memory that when you bought an upgrade to a Microsoft product, your old data (i.e. the code you had written in VB6) could not be imported perfectly and silently. It was the first time a Microsoft upgrade did not respect the work that users did using the previous version of a product.”[/color] ele está exatamente corroborando o que eu disse, isto é, que sempre a cada nova versão é necessário fazer migração (silenciosa ou não)
Com o Java também já passei por algumas dificuldades na mudança de versão. A mais sofrida foi a passagem do jsdk1.1.6 para o chamado Java 2 (j2sdk 1.2). Uma outra bem dificil foi passar do j2sdk 1.3 para j2sdk 1.4 por causa das mudanças na API de foco no swing. Agora com o Java 5 há a questão dos warnings que incomodam alguns. Mas com tudo isto as mudanças ainda são menores do que a prática de incompatibilidades da Microsoft.
[]s
Luca
Marcio, esse artigo é muito interessante! Também gostei dos seus argumentos, são bem consistentes.
Em algumas coisas eu concordo bastante com o artigo, principalmente nas críticas em relação ao VB. Quem me conhece sabe que eu sempre fico meio de nariz torcido em relação a uma linguagem onde você pode dizer: “Não quero ter que declarar variáveis” ou “Não quero ter que fazer conversão explícita de tipos”. Bom, mas o VB tem seu público…
Já em relação a outros pontos que ele coloca, aí da pra fazer um simpósio para discutir o assunto, tem muitas visões aí.
Essa questão da continuidade realmente é difícil. Mas temos que considerar que uma coisa era evoluir as tecnologias de desenvolvimento quando você nem tinha uma biblioteca central de classes (pré-.Net) e outra é disso em diante. Do Framework 1.0 para o 1.1, não se perdeu praticamente nada de compatibilidade, assim como no 1.1 para o 2. Os objectSpaces, como eu disse, nem vão ser lançados por enquanto (exatamente o caso do WinFS que ele comenta no artigo, ele depende disso). E mesmo sendo lançados, não irão matar os DataSets.
Na verdade, do VB4 para o 5 e depois o 6, praticamente nada mudou de significativo, tirando uma bobagem ou outra (como RDO virar ADO) a maioria das coisas ficaram iguais. ESSE era o problema! Uma mudança radical TINHA que acontecer. Precisávamos de um ambiente OO, de um “Framework” central, de liberdade de escolha de linguagens… Daí veio o .Net. Daí pra frente (aí eu corro o risco de me queimar no futuro) eu acho difícil grandes quebras de compatibilidade. Por outro lado, coisas ainda precisam ser definidas, como os WS-*.
Justamente porque você tem que atender muita gente, é difícil às vezes simplesmente falar: “Minha tecnologia de persistência é essa aqui e apenas ela, se vire se não gostar”. Às vezes você tem que oferecer mais de uma opção…
Quando ao W3C, posso procurar por algum artigo, mas te explico aqui basicamente porque já tive que apanhar disso:
Por default, o VS trabalha tudo com estilos dinâmicos (aqueles style= nas tags). Aí ele define posicionamento, cor, tamanho de campos, etc tudo por style. Se você usar desse jeito, aí só o IE vai entender (O Firefox também entende, mas aí você tem que abrir os arquivos de configuração do .Net e dizer a ele que se vier o FireFox, ele não deve filtrar os styles).
Mas você pode não concordar e fazer os posicionamentos via Tables, tamanhos via as devidas propriedades e etc. E mesmo que em algum momento você diga: “Ei, mas tal tag HTML não existe aqui!” (não me lembro de nenhum caso assim) você pode também montar seus custom controls e mandar gerar HTML do jeito que quiser.
Ou seja, não vejo aí nenhum impedimento de trabalhar com 100% puro W3C, certo?
Quanto aos scripts que ele gera, não sei se você já viu mas essa biblioteca é aberta. O que eu fiz foi criar meu próprio textBox com meus próprios Validators com scripts que eu escolhi. Aí ele ja entra com validação de CPF, CGC, CEP, máscaras e coisas que o .Net não traz pronto.
Quanto a você ter conhecido empresas sem nenhuma metodologia… Bem… Também conheci uma centena delas. Tem empresa ai concorrendo no mercado cobrando 14 reais/hora de desenvolvimento (inclusos impostos, análise, gerência de projeto…). Faça as contas e me diga se da pra esperar muita coisa de uma emrpesa dessas.
Infelizmente isso ainda existe. Mas como eu disse, isso está mudando. Aliás, a Microsoft acabou de lançar uma campanha de financiamento e apoio para os parceiros tirarem CMMI nível 3. (minha empresa está em processo de tirar o CMMI já tem 1 ano).
Conheci alguns caras na MS Brasil e de fora responsáveis única e exclusivamente por arquitetura e patterns (o cara do patterns foi um dos criadores do COM+ hehe). Como eu disse, eventos que antes eu nunca imaginaria a Microsoft promovendo estão ocorrendo. Muitos desses sujeitos têm doutorado, trabalharam muito com java, e às vezes até me irritam um pouco quando são muito puristas, hehe. Então podemos sim olhar para o passado, mas como diz meu banco: “Valores passados não são garantia de rentabilidade futura”.
No mais (aqui eu posso até apanhar de novo) quanto mais eu olho para o C# e para o Java, menos diferenças encontro. Vocês têm httpModule, nós temos httpModule, vocês têm stringBuffer, nós temos stringBuilder. Aliás, vocês agora têm stringBuilder também, né?
Outra coisa muito interessante no artigo é o XAML. O autor coloca isso como uma tática da Microsoft para vender Windows. Pode ser? Pode. Por outro lado, tem o myXaml que é uma iniciativa open source feita para rodar em outros lugares, e tem o Flex da Macromedia (agora adobe) também com a mesma linha.
Isso mostra que o HTML, um dia (nem que leve 20 anos) vai ter que dar lugar a algo mais consistente, com mais recursos, e se Deus quiser, mais padronizado. Vejo o XAML como uma dessas iniciativas. E sinceramente, falando tecnicamente, eu ADOREI o XAML. Simples, eficiente, organizado… E se a MS não se preocupar em fazer XAML pra linux, pode ter certeza que outros vão fazer, não se preocupe.
Mais um último argumento: Lembre que a interface do VS pode ser toda customizada. Então se você acha que tem botão demais atrapalhando, menu demais, tela demais, se as cores não estiverem boas… pode mudar!
PS. Esse tópico está rendendo boas conversas, tô gostando!
Cultura UNIX Clássica: Faça o mais performático e mais configurável, se não tiver algo que precise na libc, crie baseado naquele livro d ealgoritmos na estante em vez de procurar um pronto na Internet. Você é macho ou não é?
Cultura Java Romântica: Você já leu o paper do Japoneis A. King no TSS que fala sobre um padrão inverso em IoC para usar com containers JTA integrados à JMS?
Cultura Programadores java Migrando do VB/Delphi: Eu tenho uma JSP que usa um JavaBean apra conectar ao banco e traz um DTO…como faço pra fazer meu link piscar? tem algum framework pra isso?
Cultura Programadores microsoft VB e borland delphi: Click. Click. Click. Hey, it compiles, let’s ship it!!
O programador Microsoft/Borland padrão (e excluo dessa lista muitos programadores Visual C++ que conheço) é treinado em ferramentas, não em programação. Falando em C++, muitas vezes quando fazia seleção recebia curriculums com:
(o cara para começar nem imagina que ASP clássico não é linguagem de programação)
Eu acho que ferramentas de produtividade são ótimas, o problema é quando você faz seus programadores aprenderem a usar ferramentas e nada mais. Um exemplo clássico é o Delphi (infelizmente VB não é exemplo útil aqui) que tem uma senhora infra estrutura, mas a Borland sempre preferiu investir em fazer programadores quin’n’ndirty do que ensinar a linguagem e plataforma em si. Essa é a cultura Microsoft, ou melhor aidna: Cultura Programador Windows.
Como falei outro dia, java está no lugar certo e na hora certa, Delphi e VB estiveram taaaanto tempo nesse lugar e…nada.
Dê uma olhada em termos de componentes prontos. Quase todos os componentes Java são frameworks ou classes em um jar que você isntancia e usa no seu código. Os componentes visuais só estão chegando agora com JSF e essas porcarias de outras JSR para JavaBeans.
Produzir rápido, todo mundo quer, atender ao negócio, todo mundo quer, a diferença é que alémd a fronteira da cultura Microsoft geralmente se quer também entender o que se está fazendo, não confiar num wizard.
SharpDeveloper (eu acho legalzinho, principalmente o editor que é muito show)
[quote=mateusvelloso]3-Não lembro quem me perguntou sobre o que eu falei dos Design Patterns e a tecnologia. Pois bem, um exempo super polêmico: Existe uma discussão no mundo Microsoft sobre o que usar na camada de persistência. Alguns defendem o nHibernate (irmão do Hibernate em .Net), outros o Gentle.Net, e por aí vai… O .Net traz built-in os DataSets, que são mapeamentos de XSD Schemas para classes, propriedades e coleções. Daí como não existia nenhum Design Pattern que falasse de DataSets (agora até estão aparecendo), muita gente preferia não usa-los, mesmo em projetos mais simples onde eles resolviam 100% a necessidade. Agora na versão nova viriam os ObjectSpaces numa abordagem mais inteligente e performática que o nHibernate, mas adiaram isso mais pra frente.
Outro exemplo foi num curso de .Net que eu dei para uma turma de analistas que trabalhavam com java (isso mesmo, já treinei uns 150 profissionais java em .Net, e acredito que nenhum saiu decepcionado com essa tecnologia, mas aí é outro papo), e eles questionavam muito os Delegates do .Net. Diziam que esse não é um recurso 100% O.O. Eu defendia que na prática era exatamente a mesma coisa que vocês fazem com Interfaces, só que simplificado, e que nada impede que se use Interfaces do jeito tradicional também…
Entende a questão? É aquela velha discussão entre purismo x produtividade. E nenhum dos lados tem 100% de razão o tempo todo.[/quote]
Acho que entendi agora. Acho que não é questão nem de ser purista cara, mas de gente que quer seguir a modinha OO, Design Patterns. Os cara num deve ser assim do jeito que tu ta falando, pelo motivo que realmente verificaram que se usarem nHibernate, Delegates, DataSets etc. vão estragar seus projetos, mas sim por mania de estar na moda, de se cool, de ser elegante. Agora se realmente tu ve que a coisa eh um lixo que vai te detonar, reinvente a roda, uma roda melhor!!!
hehehe, se eu disser que já entrevistei mais de um que me jurava que sabia programar em XML… Pelo menos a gente se diverte. =]
Também já vi um professor de MBA dizer: “Essas Advanced Server Pages não prestam!”
Realmente não deve prestar porque nunca ouvi falar desse negócio, hehe
Perai! Calma lá! Antes de confundir o povo, java.lang.StringBuffer e java.lang.StringBuilder podem fazer exatamente a mesma coisa, mas suas implementações são bastante diferentes. Diferentemente do java.lang.StringBuffer, o java.lang.StringBuilder não é thread-safe (igual ao System.Text.StringBuilder do .NOT, cuja documentação diz que “any instance members are not guaranteed to be thread safe”), logo, várias threads podem alterar o conteúdo de um StringBuilder simultaneamente.
Mas, enfim, isso não adiciona nada à discussão. Voltamos à nossa programação normal.
Cara se não tormarmos cuidado está acontecendo o mesmo com os frameworks.
O pessoal está usando pela inércia não pela necessidade real.
A mesma coisa são com os patterns…
Joãoziho diz:
“Vamos usar DTO, EJB, DAO, Hibernate, Factory, Struts, Swing, Servlet porque esse é o padrão certo”
Sim, Daniel, desculpe a piadinha infame, foi só para brincar com os termos parecidos.
Realmente o .Net trata como regra que em qualquer instance member, o controle da thread é problema de quem desenvolve, ao contrário do que for static.
[quote] Cara se não tormarmos cuidado está acontecendo o mesmo com os frameworks.
O pessoal está usando pela inércia não pela necessidade real.
A mesma coisa são com os patterns…
Joãoziho diz:
“Vamos usar DTO, EJB, DAO, Hibernate, Factory, Struts, Swing, Servlet porque esse é o padrão certo” [/quote]
Bem, se você consegue fazer alguma coisa com a mesma produtividade e o mesmo nível de controle sobre a aplicação sem usar nada disso, parabéns.
Frameworks são aplicações semi-prontas que servem pra serem estendidas e utilizadas conforme as nossas necessidades. Se não fosse assim, agente ia programar em assebly, que é o único jeito de não usar (quase) nada, montar tudo na mão.
Tem uma empresa de desenvolvimento de sites em Java que está passando por um problema sério, por que as suas páginas não estão abrindo no Firefox (exemplo: http://www.wscom.com.br/ ), eles não usaram MVC, fizeram tudo “dentro” do JSP. Agora imagine o milagre que eles vão fazer pra mudar tudo isso, simplesmente porque ninguém pensou nisso. Se alguém tivesse se preocupado em dividir essas coisas em camadas, montar uma arquitetura bonitinha, o trabalho ia ser bem menor.
Usar frameworks, padrões de projeto, orientação a objetos, orientação a aspectos e todos esses buzzwords da informática, não serve de nada pro cliente, serve é pra nós, os trabalhadores braçais, que vão ter que debugar, limpar, corrigir e mudar aquele resultado. Montar uma arquitetura bem definida só serve pra facilitar o nosso trabalho, não deixar a ferramenta melhor pro usuário final.
Eu, pessoalmente, acho que o clicar e arrastar, os wizards e essas coisas comuns de ferramenta RAD estão a um abismo de distância dos frameworks que nós estamos acostumados a trabalhar em Java.
Teve até um caso interessante na lista Java-BR, um cara tava perguntando como é que ele instalava o Hibernate no PC dele. Disse que foi no site e não achou nada na documentação que falasse sobre a instalação dele no computador. Ele queria wizard até pra dezipar o arquivo?
Concordo plenamente.
Usar frameworks e patterns com certeza é fundamental.
O que eu quiz colocar é que devem ser usados com bom senso.
Usá-los por moda não é muito proveitoso.