Fragmental

Já que começamos o tema vamos prosseguir para o GNU/Linux no desktop. Minha opinião? Linux no desktop é para quem tem pelo menos tempo (e interesse) de saber minimamente como um computador funciona. É simples: se você é um programador (ou se diz um) e não saber utilizar um GNU/Linux como desktop você está no caminho errado da carreira. Vamos lá, o GNU/Linux não tem nada de novo em termos de sistema operacional. Se você estudou SO em algum lugar (faculdade, livro, cadeia, etc.) você consegue saber como um UNIX funciona, se você acha que “perdeu tempo” estudando S.O. saia desta carreira e deixe os profissionais assumirem.

Mas… minha mãe não. Minha mãe trabalha com projetos, ela não tem tempo nem interesse em aprender como um computador funciona. Durante alguns anos ela usou GNU/Linux alegremente, quando eu morava com ela e dividíamos o computador. Ela já usou diversas distribuições e nunca reclamou. Por que? Porque eu configurava todo o computador, saia no tapa com winmodems e parâmetros bizarros e quando ela usava a máquina ela estava funcionando. Isso explica porque GNU/Linux para desktops corporativos funciona bem: quem toma conta não é o usuário. Agora minha mãe mora sozinha, eu deixaria um GNU/Linux instalado lá? Se eu não tenho tempo de a administrar (ainda que remotamente) não.

E não, não é mérito do Windows, é vergonha do GNU/Linux. Exemplo? Pegue um usuário leigo, deixe ele usando Mac OS X e depois pelo mesmo tempo seu sabor favorito de Linux. Sabe qual ele vai preferir? Eu já fiz essa experiência e te digo: o Mac. As interfaces GNU/Linux, por mais que KDE e Gnome sejam ótimos, não estão prontas para o usuário comum. Neste instante alguém diz: ah, é porque a documentação é para Windows.

Vamos lá, minha mãe não lê o manual do DVD player dela para saber o que o botão XYZ do controle remoto faz, você acha que ela procura na Internet como resolver um problema? A coisa tem que ser intuitiva e como eu disse acima um sistema UNIX é extremamente intuitivo para quem tem a mínima noção de como funciona um SO, mas não o contrário. Minha mãe não consegue diferenciar a rede local da Internet, como ela conseguiria conectar um modem ADSL para dois computadores? E estamos falando de uma pessoa que lida diariamente com computadores diversos há uns bons quinze anos, tanto no trabalho quanto em casa, e já passou por todos os sabores de Windows e antes dele o DOS e OS/2.

Eu não entendo como alguém pode aceitar as limitações de um sistema Windows enquanto desenvolve software (tanto que mesmo quando programo em .Net uso o Mono), mas realmente não consigo conceber um usuário doméstico, sem administrador, usando GNU/Linux.

Tem alguns meses que eu voltei apra o paraíso que é trabalhar apenas em GNU/Linux. No trabalho e em casa tenho um Kubuntu e para as aplicações que preciso de Windows (alguém disse MS Project?) eu rodo uma VM no qemu.

Ontem eu fiz a atualização periódica do meu sistema. É muito difícil, você precisa abrir um terminar e digitar:


$apt-get update
$apt-get upgrade


Sim, isso tudo.

Depois eu descobri que o Firefox não estava se entendendo com o kicker (a “barra do botão iniciar” do KDE). O kicker simplesmente travava. Pelo log do processo tinha algo errado na minha configuração do X misturada com a do Beryl. Depois de ler alguns históricos e fóruns eu descobri a solução adicionando uma linha nova na configuração para suportar um módulo novo qualquer, pronto. Tempo total: 45 minutos.

O que?!! 45 minutos para consertar um bug do sistema?! Sim. Mas pense bem: se isso acontece num sistema onde você não tem controle (nem digo um sistema de código fechado, esse não é o problema, o problema é não ter controle) você só ia ter uma opção: reinstalar o sistema. E sim, eu poderia reinstalar o sistema e ia demorar muito menos, já que eu talvez só precisasse reinstalar o KDE e não todo o SO como acontece com o Windows (acrescente duas linhas na sequência acima e pronto).

Aqui em casa temos um espaço com dois desktops, o da minha esposa e o meu. Ela roda Windows (mas está querendo migrar para Mac, não aguenta mais) e dia desses eu passei várias horas fazendo algumas manutenções no PC dela após uma sequência que começou com spyware e terminou com um computador sem som e que não reproduzia DVDs. Após a luta para salvar as fotos dela, arquivos, etc. eu formatei a máquina toda, depois tive que baixar aqueles programas que reconhecem o hardware para baixar de 3 sites diferentes os drivers de todos os periféricos, além da grana em anti-vírus.

Este não é um post do tipo “mude para Linux” porque eu já passei desta fase, mas é só uma demonstração de como os problemas que existem em ambas as plataformas são tratados.

Paul Graham e Martin Fowler decretaram o fim da MSFT. Não é a primeira vez que isso acontece mas desta vez são grandes nomes, um sempre escandaloso e um geralmente bem imparcial, na ordem. Como falamos aqui nos últimos meses, Redmond tem surpreendido a comunidade de desenvolvimento (como nota Fowler) com novidades realmente interessantes mas… Microso$oft é MSFT, não tem jeito. Após tantos anos jogando com as peças erradas vão ser necessários muitos milhões de dólares e neurônios para virar a mesa, e por mais que dólares não faltem neurônios ainda são muito caros para Redmond, já que seu preço varia com o freguês.

Enquanto Graham se atêm às perdas de mercado na computação de desktops Fowler fala sobre a perda de mercado da plataforma .Net. Vai ser necessária muita inovação, tanto em SO quanto em plataforma de desenvolvimento, para reverter o jogo. Em Plataforma temos visto aqui que realmente eles estão tentando, e muitas vezes conseguindo. A parte de SO é a antítese: cópias de recursos com mais de dez anos de existência.

Dado que a MSFT prende sua plataforma ao seu SO, o sucesso ou fracasso de um influencia o outro. Este risco sempre esteve presente para o programador .Net mas antes ele era tão irreal que era simplesmente desconsiderado. Agora ele está aí nas mãos dos milhares de MacBooks nas mãos de quem mora em países civilizados (do tipo que não faz um MacBook custar R$6.500,00) e dos sabores de GNU/Linux que alimentam os datacenters. Na lista do Graham sobre como salvar a MSFT eu incluiria abrir sua plataforma para externos. Por mais que o Windows continue caindo pelo menos uma parte da empresa estará a salvo.

Estava conversando com uns amigos e chegamos a uma dúvida bem interessante: por que as empresas acham normal gastar fortunas em infra-estrutura(CPUs, cores, memória, máquinas, RAC, cluster, cache, replicação) e não acham sequer razoável gastar esse investimento para migar para uma plataforma mais eficiente?.

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.

Continuando 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.

Ó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.

Lendo 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:

1. Cria-se uma estrutura fundamental baseada em boas tecnologias e plataformas, geralmente copiadas de casos clássicos de sucesso
2. Pessoas com nível técnico alto utilizam esta base para criar coisas muito interessantes
3. 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.

A Editora Mundo (que, aliás, precisa de um site) ataca novamente: Mundo .Net. Obviamente que eu tenho meus pontos contra a tecnologia .Net e com a Microsoft em específico mas é simplesmente burrice para qualquer arquiteto de software fechar os olhos para a penetração que a plataforma possui hoje em dia e as boas idéias -principalmente a aplicação de idéias antigas- que estão surgindo neste meio.

Eu sempre evitei comprar revistas (e até outro tipo de literatura, na verdade) sobre plataformas MSFT porque o conteúdo editorial nunca teve qualidade. Tem alguns meses que assino o Microsoft Architecture Journal e é um material de altíssima qualidade. O mesmo eu espero de uma revista que sai da mesma casa que a renomada Mundo Java e que tem como editor-chefe Rafael Steile Hamilton Veríssimo como colunista, ambos dispensam apresentações.

Ok, notícia velha, me critiquem por ser lerdo, mas não posso deixar de comentar esta excelente entrevista do Eric Evans no infoQ.

Com outro trecho mais adiante…

Combine that with the imperative to produce Web UIs mediated by http and html (which were not designed for that purpose) using quite primitive, first-generation tools. During that period, creating and maintaining a decent UI became so difficult that little attention was left for design of complex internal functionality. Ironically, at the very moment that object technology took over, sophisticated modeling and design took a heavy hit.

Sintetizam as desculpas (esfarrapadas) para se produzir aplicações baseadas em objetos burros nos últimos anos.

For example, SOA, when it is used well, provides us a very useful way of isolating the domain.

Este é outro ponto interessante. Muitas vezes vemos SOA sendo utilizado como desculpa para modelos de objetos burros e fracos, ou até mesmo para uma volta ao Dicionário de Dados. Serviços não trocam, ainda, objetos inteligentes e sim estruturas de dados mas dentro do serviço nós temos um sistema OO e, como tal, deve ser construído utilizando objetos!

E lembrem-se: objetos são dados e comportamento num mesmo conceito.

But back when the J2EE frameworks first came out, it utterly buried that basic expressiveness under mountains of framework code. Following the early conventions (such as EJB home, get/set prefixed accessors for all variables, etc.) produced terrible objects.

Isso eu comentei bastante no artigo sobre VO/BO.

Rails has generated a lot of excitement because it finally seems to make creation of Web UIs as easy as UIs were back in the early 1990s, before the Web. Right now, this capability has mostly been applied to building some of the vast number of Web applications which don’t have much domain richness behind them, since even these have been painfully difficult in the past. But my hope is that, as the UI implementation part of the problem is reduced, that people will see this as an opportunity to focus more of their attention on the domain. If Ruby usage ever starts going in that direction, I think it could provide an excellent platform for DDD. (A few infrastructure pieces would probably have to be filled in.)

Este trecho toca na minha crítica #1 com Rails: domínios fracos baseados em Bancos de Dados. A linguagem Ruby é tão cheia de vantagens que a limitação imposta pelo modelo CRUD do Rails me irrita profundamente. Ok, você não precisa ter um modelo fraco em Rails, mas você também não precisa ter um modelo fraco ao usar EJB 2.1, VB 6 ou Delphi e isso nunca evitou este problema.

More out on the cutting-edge are the efforts in the area of domain-specific languages (DSLs), which I have long believed could be the next big step for DDD. To date, we still don’t have a tool that really gives us what we need. But people are experimenting more than ever in this area, and that makes me hopeful.

Outro ponto muito bom. DSLs são iminentes mas as ferramentas simplesmente ainda não chegaram lá. O grande perigo é que o conceito está se tornando popular mas não existem ferramentas. Algo semelhante aconteceu com OOP, as linguagens eram procedurais mas todo mundo falava em OO, gerando a célebre consideração sobre C++ que eu traduzo mal e porcamente abaixo:

C++ é como sexo para adolescentes

Bom, não percam!

Quem acompanha o JavaPosse lembra de Tor Norbye falando sobre sua misteriosa apresentação no JavaOne… bem o mistério foi resolvido.

O projeto Semplice traz VB6 diretamente para a JVM através de ferramentas disponíveis na suíte da Sun (i.e. Netbeans). Chamads nativas á APi do Windows e controles OCX não são suportados mas o projeto parece bastante promissor.

Antes de xingar a Sun por colocar algo “tão dummy” quanto VB na JVM pense no mar de aplicações e profissionais VB6 que estão com dificuldades para migrar para .Net. Aliás, o legado VB6 é um dos fatos mais citados por Bruce Tate no Beyond Java, o livro que ninguém leu e todo mundo xinga. Ao lado da minha equipe existem uns 20 programadores VB tentando migrar para Java. Com algo assim eles poderiam ser produtivos enquanto aprendem a plataforma.

E temos mais uma linguagem quase-oficial para a JVM. Bom, se a Sun liberar a engine de conversão para ser utilziada por outras IDEs vai ser *muito* bom, mas mesmo por enquanto parabéns ao pessoal da Sun.