Não consegue ver a utilidade de javaScript embutida no Java? Tiago Motta mostra pra você. Nada de ficar se preocupando se aquele seu javaScript tão Web 2.0 de 15 mil linhas está ok no próximo release, coloque o dito cujo no JUnit e tenha certeza do que funciona e o que você quebrou ;)
Archive for the ‘web’ Category
Test Infected
Wednesday, May 16th, 2007Performance x Pessoas: Compensando Perdas com Infra-Estrutura
Wednesday, May 16th, 2007Estava conversando com uns amigos e chegamos a uma dúvida bem interessante:
A empresa típica hoje tem na sua linha de frente programadores..uhm… “não-ótimos” para o serviço. Estes programadores geralmente são “adquiridos” por um valor baixo e possuem como característica básica o “trabalho não otimizado” e err… a “rápida depreciação e eventual substituição da mão de obra”.
Ok, sem mais eufemismos porque este blog não se gaba por ser enterprisey: contratam pessoas ruins que ficam pulando de empresa em empresa porque podem pagar pouco (comparado ao preço de um desenvolvedor de verdade) para elas.
E como isso dá certo? Bom, macacos digitando infinitamente não reproduzem a obra de Shakespeare, mas eu garanto que se eles martelarem um teclado por algum tempo eles escrevem boa parte das aplicações Java EE ou .Net criadas hoje em dia. Desenvolvedores ruins sempre existiram mas desde o advento de ferramentas como Visual Basic e Delphi, além de plataformas gerenciadas como Java e .Net se tornou viável contratar um bando deles de largá-los amrtelando teclados sendor egidos por gerentes de pojeto que se gabam de ter sua ‘arte’ surgida na Roma antiga e acabam aplicando práticas de gestão desta época.
Vamos e venhamos: as aplicações criadas na maioria das empresas são estupidamente simples, qualquer zé mané faz. E também na maioria das aplicações basta se comprar um servidor de R$2.000,00 e qualquer aplicação construída por uma menina de 3 anos roda bem que é uma beleza. Claro que a aplicação precisa escalar, ou precisamos ainda já começar pensando grande (pense numa empresa de telecomunicações), se nosso software foi construído por macacos de Shakespeare como podemos fazê-la escalar?
Com hardware.
Máquina. Memória. CPU. Banco de Dados replicado. Particionado. Cache. Quemt em aço e silício dispensa cérebros.
E porque é tão inpensável contratar bons profissionais (que, segundo estudos, podem substituir 10 ou mais code monkeys) e dar a eles uma ferramenta eficaz e eficiente como Ruby/Rails, JRuby/Jython/IronPython/Groovy, PHP, Seaside ou Python?
Por definição uma plataforma de mais alto nível é menos performática mas quase sempre podemos vencer isso na infra-estrutura.
Que tal parar de gastar numa aplicação ruim, que vai dar problema de manutenção frequente, numa plataforma complexa por algo que tem o mesmo custo total, foi feito por 1/10 das pessoas numa plataforma simples?
Update: Faltou a conclusão: por isso que uma empresa de centenas de pessoas e milhares de verdinhas se mata para imitar o que quatro garotos que vivemd e mesada criam nos fins de semana (e não conseguem nem chegar perto!).
Ok, não é por isso, mas é um dos motivos.
Ele Não Aguenta Mais Arroz Com Ovo
Monday, May 7th, 2007Continuando na nossa série de alertas (não, não era uma série mas acabo de inventar isso) chegamos a um excelente texto sobre o futuro de java x .Net no infoQ. Deste eu destaco:
When .NET was first released in 2000/2001, the Java community considered it a “clone” of Java, both language and standard library. Comparing simple code samples surely support this impression. However, MS profited from many years of experience with Java, and managed to solve some issues that Sun only now realizes as problems. The impression that the .NET and the CLR are evolving faster than Java is not lost on the Java community.
…
Other examples of this are modularization and versioning, which.NET solved by choosing the assembly, a collection of classes, as the basic deployment unit. Assemblies are equipped with metadata such as version information, unlike Java’s Jar file which lack versioning metadata. This is troublesome for increasingly large applications, which load many libraries. OSGi now provides a solution for this, Sun is busy adding something similar to Java 7.The Java language keeps on catching up with C#, adding features such as Generics and features such as AutoBoxing, Enumerated types or Annotations. C# now has anonymous expression support, which forms the underpinning of the LINQ technology. LINQ can be thought of a statically typed query language for many different types of data sources, such as XML, relational databases, but also arbitrary object graphs. The Java space, meanwhile, debates language minutiae such as language support for properties and which of four types of anonymous function to include in the language.
…
The Java space doesn’t really any of the mentioned items, except for the hosting interface, which was added in Java 6, under the name of JSR 223. This is basically just framework to add new language runtimes and initialize and access them in a standardized way.Jim Hugunin continues with a detailed explanation of how dynamic method dispatch is handled, which makes use of extension methods and other existing CLR systems. The only comparable initiative is JSR 292, which among other things wants to add a new bytecode invokedynamic .This effort was started by Gilad Bracha, who soon after the creation of the JSR, left Sun, and is now not convinced that this project will bring any short term solutions:
Exceto a bizarrice do LINQ, este texto só mostra algo que vem sendo visto diariamente. Provavelmente a JVM e a CLR vão disputar como VMs de linguagens dinâmicas e de DSLs, e tudo mostra uma vantagem técnica para a MSFT. Acordemos.
POX x REST: Interfaces Padronizadas
Monday, April 23rd, 2007Enquanto o GUJ tem sua massagem noturna eu respondo ao post do Maurício por aqui. O tema é REST x POX, mais especificamente: precisamos usar REST o tempo todo?
Pra você que estava hibernando há uns 12 meses, REST é um estilo arquitetural que se coloca como uma alternativa ao uso de SOAP e padrõesWS -* para criar WebServices. REST é interessante porque este estilo arquitetural é conhecido e utilizado há anos: é o estilo arquitetural que define a Web. Um sistema REST vai usar os métodos HTTP (GET, POST, PUT e DELETE), os content-types, os código de resposta e tudo mais que você ignora solenemente na maioria das aplicações web atuais mas que estão desenvolvidas e especificadas há mais de uma década.
Um possível problema seria de que as pessoas estão dizendo que usam REST quando na verdade apenas usam XML passando por HTTP, o chamadoPOX ( Plain Old XML, um primo do POJO). Este processo é exatamente a mesma coisa que utilizar SOAP com HTTP, exceto pelo fato de que o XML é personalizado (ao invés de 500 envelopes, um dentro do outro) e que não temos umWSDL (o que provavelmente é ruim).
Bom, a pergunta do Maurício é: isso é ruim? A resposta você já sabe: depende, mas depende do quê?
Quando se usa WebServices SOAP ou REST o que se quer é ter uma interface padronizada para um serviço. Há décadas nós temos serviços distribuídos sendoamplamente utilizados, o motivo de existir SOAP e outros é padronizar este ecossistema. Quando você padroniza algo como o protocolo de interface remota de todas as aplicações obviamente você vai pagar um preço em eficiência. Uma aplicação que segue um protocolo genérico como HTTP provavelmente não será tão eficiente em comunicação remota quanto um que segue um protocolo específico e especializado.
A partir do momento que você resolve utilizar uma interface genérica você assina um contrato. Se você me disser que seu sistema éRESTful eu tenho certeza que se eu fizer a requisição de um objeto inexistente seu sistema irá retornar um código de erro 404, e não um código 200 com um XML bonitinho e uma mensagem de erro. 200 pra mimsignifica uma só coisa: “Ok, o objeto existe e seu conteúdo segue no corpo da mensagem”.
Ao fazer POX você quebra esta regra. Pode ser que seu sistema seja simples e que definir um mini-protocolo baseado em POX seja uma ótima solução, mas você acaba de inventar seu próprio padrão, que é exatamente o que o uso de WebServices tenta evitar. Mesmo para sistemas legados com seus próprios padrões (coisinhas em COBOL, por exemplo), nós temos oESB como tecnologia que converte mensagens para um formato intermediário, de modo que não sejam criados seus próprios padrões. A idéia por trás de REST não é abolir padrões mas sim ter uma especificação simples e eficiente, com um mínimo de primitivas e máxima extensibilidade.
O Futuro na JAOO
Tuesday, March 20th, 2007Ótimo painel sobre o futuro da programação no JAOO. Especialmente o comentário do PragDave:
Dave: I’d like to predict that the current stacks of software by 10-15 years are going to be in a much worse legacy and more of a nightmare to maintain. You’re going to have employment forever maintaining this stuff. C++, Java code, C# code, this stuff is very complicated and very brittle with all these class libraries and frameworks. We’re digging ourselves in a really big hole and there will be a lifetime of opportunities for you people to maintain this stuff that you’re creating.
Prepare-se e pense nisso antes de comprar aquela ferramenta mágica ou criar mais um framework que faz a mesma coisa que todos os outros.
Palestras do ERECOMP-AL
Monday, March 19th, 2007Comento em breve o evento mas os slites já estão disponíveis:
Acorda, Maria Bonita…
Tuesday, March 13th, 2007Lendo a revista Mundo .Net deste mês pensei sobre o estado atual das duas maiores plataformas de desenvolvimento modernas, Java e Microsoft .Net. Infelizmente estou tendendo a creditar em uma coisa: A Microsoft aprendeu, a comunidade Java se acomodou. É impressionante como a MSFT tem investido em ferramentas e plataformas interessantes. A estratégia que pude perceber é mais ou menos assim:
- Cria-se uma estrutura fundamental baseada em boas tecnologias e plataformas, geralmente copiadas de casos clássicos de sucesso
- Pessoas com nível técnico alto utilizam esta base para criar coisas muito interessantes
- Pessoas com nível técnico baixo, grande maioria nas duas plataformas, podem utilizar ferramentas burrotizantes que criam apenas o básico que elas acham que precisam
Dado que as pessoas citadas no item (2) são raridade (eu conheço duas, todos vindos de Java/C++),a estratégia de marketing toda foca no povo do item (3). Para o item (2) (para utilizar um termo MSFT: os Elvis e Einsteins) o marketing é baseado em altos salários e oportunidades muito boas em um mercado saturado de arrastadores de componentes (Morts). Com Java foi exatamente o contrário: a linguagem atingiu o jet-set da computação mas logo se banalizou. Einsteins criaram uma plataforma altamente produtiva e de qualidade impressionante, mas logo Mort caíram em cima, fugindo de Delphi e VB 6.0.
Se o programador mediano Java não tivesse tantos problemas no passado com a Microsoft ele facilmente seria seduzido pela plataforma. Ali tem tudo que ele precisa para fazer seus CRUDs (ou seus grudes…). E se Elvis não tivessem tantos problemas com código proprietário e uma plataforma de um vendedor só eles certamente estariam esmagando cabeças dos programadores Java ao comentar como a plataforma .Net está ficando cada vez mais aberta, cada vez mais flexível, cada vez mais… parecida com sistemas em UNIX.
É sério. Não vou nem citar o MS PowerShell, basta olhar como é feito o deployment em .Net e comparar com um sistema UNIX. Ok, eu sei que é muito mais fácil alguém ter visto um deployment .Net que um UNIX então deixe-me tentar explicar com poucas palavras como geralmente é feito um sistema: cada módulo geralmente é implementado como um programa separado (programa mesmo, tipo uma classe com public static void main(String[])), estes programas conversam entre si utilizando diretivas de IPC. O SO (Linux, HP-UX, Solaris, etc.) controla estes programas (feitos em C/C++, PERL, Python, Ruby, Bash, TCL…).
Se você for esperto já fez uma analogia com um servidor de aplicações J2EE. SIM! Os servidores de aplicação vieram solucionar problemas deste modelo, trazendo um nível de padronização (e racionalidade…) para o processamento de transações distribuídas, segurança, persistência, etc. É para isso que Java EE foi criado, infelizmente as pessoas esqueceram ou não tiveram contato com um ambiente não padronizado e não entendem o que é, por exemplo, um EJB. Ok, mas o problema é que o servidor de aplicações é um mundo a parte, e um mundinho bem fechado.
Tem uns dois anos eu trabalhava para uma empresa líder mundial do setor de sistemas para redes de telefonia celular. Esta empresa possui até hoje uns 90% da base de código em C, rodando em Solaris e outros UNIXes. O sistema principal era exatamente como descrevi: um bando de processos em C que se comunicavam via pipes, filas de arquivos e memória compartilhada. parece uma zona, não? Nada de JMS para mensageria, nada de JAAS para segurança, nada de nada.
Pois a grande vantagem deste sistema não era a velocidade, como defendiam os xiitas locais. A vantagem era a flexibilidade. Quando uma correção era implementada o meu colega de baia enviava para o cliente um patch contendo apenas os processos modificados. Quando eu corrigia uma linha de código tinha que mandar um EAR de 10 megabytes. O primeiro nível de suporte era capaz de fazer scripts em PERL e Bash que corrigiam problemas quando aconteciam e automatizavam tarefas para o programa em C. para o programa em java só o próximo release implementaria a mais boba das tarefas, ou uma famosa dedada no banco de dados (um script SQL).
Claro que a culpa é dos programadores (não me excluo) que não se prepararam para sistemas abertos e extensíveis (anos depois eu consegui fazer alguns progressos nesta área e sumarizei em uma palestra), mas o maior problema é na forma que um Application Server é fechado, lacrado. Mesmo os servidores mais modernos ainda contam com abertura precária se comparados aos bons e velhos sistemas UNIX dos anos 70/80/90.
E neste ponto a Microsoft vai na frente, por incrível que pareça. Sua plataforma está baseada em Camadas que são unidas pelo SO, é como se a pessoa pudesse implementar um sistema UNIX utilizando um framework de workflow, persistência, apresentação, comunicação remota, transações e segurança unificado, não importa qual linguagem (e .Net é multilinguagem desde sempre).
Não, eu não estou falando para você migrar para .Net. O que eu estou dizendo é que Java está trilhando caminhos muito perigosos, como desenvolvedores nós temos que ficar de olho. Cuidado com ferramentas milagrosas e,principalmente, cuidado com caixas fechadas (ainda que sejam Open-Source).
E os Einsteins? Eles brincaram com Java mas voltaram para LISP.
RESTa Muito a Debater…
Thursday, February 22nd, 2007O DQO continua com a conversa sobre REST x WS-*.
Na argumetnação do porque-você-não-pode-simplesmente-ignorar-ws-* entram dois pontos centrais:
a) WSDL
b) REST é para HTTP apenas
Quanto a (a), eu também tinha a impressão que uma linguagem de definição de interfaces é fundamental mas mudei de idéia. Essas IDLs geralmente são muito complexas (desde CORBA) e isso está intrínseco ao fato de que devem definir tipos simples, tipos complexos, tipos do usuário, etc. de maneira auto-contida. Uma lignaugem de tipos genérica não tem como ser muito simples.
Quanto a ser editado manualmente, EJBs também foram criados apra serem editados apenas por ferramentas. Assim como eu tenho que editar EJB-Jar.XML todo santo dia eu tenho que editar WSDLs. temos um padrão aqui? Fora que os bindings SOAP para linguagens como PERL são…sofríveis. Na melhor das hipóteses. Enquanto isso qualquer coisa que faça HTTP e trate um formato como XMl está pronto para REST.
O ponto é que se eu tenho um conjunto de primitivas simples como PUT, GET, POST e DELETE eu não rpeciso de muito mais. parsers XML, YAML, JSON existem aos milhares e basta ser bem documentado para saber o que uma estrutura de dados representa.
Quanto ao ’ser HTTP-only’, sim, é uma limitação que pode não permitir o uso de REST out-of-the-box em alguns cenários. Mas SOAP, apesar de não ser dependente de transporte, não possui até onde eu sei especificações formais para o uso de JMS ou qualquer outra coisa que não seja HTTP. O que existe são implementações proprietárias destes transportes, e nada impede a criação de uma bridge JMS-HTTP, até via ESB.
Acho que o único motivo técnico real para o uso de SOAp é a abundância de ferramentas e suporte em diversos produtos. Em termos de integração, REST parece fazer muito mais sentido na maioria dos casos.
Eu Tentei!
Tuesday, February 20th, 2007Mudar para o Netvibes, seguindo recomendação do Marcelo Martins, mas não deu certo. É tudo muito bonitinho, muito Web 2.0, muito AJAX, mas basicamente são widgets para construir páginas personalizadas, não o que alguém que tem 15.892 feeds consegue utilizar.
O Bloglines pode não ser a melhor coisa do mundo mas ele é bom no que se propõe: leitura de artigos via RSS. Não tem widgets, não tem integração com qualquer-coisa-que-tenha-uma-porta-80-aberta, mas ele consegue me dar um mínimo de conforto ao selecionar o que presta ou não nos feeds.
Se pelo menos o NetVibes removesse da página os feeds já lidos eu poderia pensar no caso, mas quando você tem mais de cem blogs numa categoria (que vira uma página) e eles continuam aparecendo mesmo depois de lidos você tem um problema.
Mauricio Linhares no IMasters!
Sunday, February 18th, 2007Símbolo brasileiro da primeira bolha da Internet, o IMasters parece tentar retomar sua posição numa internet, ao contrário da anterior, soterrada de informações. Bom, os primeiros passos estão indo bem, pelo menos a publicação do artigo do Maurício Linhares foi sensacional: Ócio como combustível para a inovação.
| O texto toca no tema que Tom DeMarco aborda em Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency, que apesar de não ter o charme e importância de um Peopleware é uma excelente leitura. Parabéns, Maurício! |