Windows 8: A nova corrida do ouro
Em junho deste ano a Microsoft exibiu pela primeira vez um preview da mais nova versão do seu sistema operacional para PCs, o Windows 8. Nesta nova versão, a Microsoft introduziu o Metro Style Apps, um novo paradigma para criação de aplicações.
As Metro Apps representam uma mudança que vai muito além da cosmética. É uma forma realmente reimaginada para construção de aplicações tanto para o desktop quanto para tablets. Apesar do fato que o Windows 8 rodando em plataforma Intel manter a compatibilidade com o legado, certamente as novidades irão forçar desenvolvedores a reescrever suas aplicações para o novo modelo.
Além disso tudo, o modelo de distribuição de aplicações será o da moda: App Store. No final de fevereiro a Microsoft promete abrir a loja, e nos meses seguintes começarão a aparecer os primeiros dispositivos com o novo sistema.
Agora, é só juntar as peças. Dona de um mercado imenso (alguém duvida que o Windows 8 vai vender horrores?), gerando a demanda pela reescrita de todas as aplicações e abrindo uma App Store do ZERO, a Microsoft está criando uma imensa oportunidade de negócios para desenvolvedores. Ouso a dizer que é uma oportunidade sem precedentes na história de nosssa indústria.
Que tal arregaçar as mangas e se aventurar neste mercado?
Arquitetura Pragmática
Fui convocado por Silvio Meira para dar uma aula sobre Arquitetura de Software para a turma de engenharia de software na pós-graduação da UFPE. Minha intenção foi fugir do óbvio e mostrar uma nova visão sobre arquitetura, fortemente influenciada pelas metodologias ágeis e pela evolução das tecnologias web. A aula foi bem proveitosa e estou satisfeito por mostrar algo que vai além das abordagens tradicionais. Este trabalho é marcante porque contém pela primeira vez os enunciados das primeira e segunda lei de Arquitetura de Software de Borba 
))))))
Será o Java o novo COBOL?
O projeto Green foi iniciado em 1991 pela Sun com a intenção de criar uma plataforma para desenvolver sistemas embarcados, em especial para set-top boxes da indústria de tv a cabo. Nesta época a internet era menor que uma ameba se compararmos com hoje. A web já existia (foi criada em 91), mas ainda não era notada. Apenas em 94, quando o browser Mosaic foi criado é que a world wide web começou a ser popularizada. O pessoal da Sun não esteve alheio a esse movimento e ainda em 94 redirecionou o projeto para web. Finalmente em 1995 a plataforma Java (rebatizada) foi lançada, já contando com o suporte do principal browser da época, o Netscape.
O Java trouxe uma quantidade imensa de inovações para a indústria de desenvolvimento de software na época: máquina virtual, multi-plataforma ("write once, run everywhere"), garbage collector e em especial a integração com a web através dos applets. Foi como juntar a fome com a vontade de comer. A web começando a bombar no mundo todo e uma plataforma de desenvolvimento inovadora e integrada com essa nova tecnologia.
Identificado como inovação o Java aglutinou o interesse de inúmeros desenvolvedores open source, que com suas criações e o poder de difusão da web, alavancaram em tempo recorde o Java para ser a principal plataforma de desenvolvimento de software do planeta. As grandes empresas não ficaram de fora e com mais alguns investimentos tornaram Java também a principal solução para o mundo enterprise. Curiosamente os applets que foram a ponta de lança para a divulgação da plataforma acabou não tendo sucesso.
A característica multi-plataforma do Java prejudicava diretamente a estratégia da Microsoft, que dependia de máquinas Intel com o sistema operacional Windows. A Microsoft não deixou barato e em 2002 lançou o .NET Framework, que era conceitualmente uma cópia do Java, mas que só rodava no Windows. A partir deste momento, as duas plataformas começaram a disputar uma corrida de inovações para conquistar mais mercado. A cada nova versão, cada plataforma trazia inovações que superavam a outra. Neste processo, a Microsoft acabou por conquistar uma boa fatia do mercado, porém sem desbancar a liderança do Java.
Essa tendência se manteve ao longo dos anos, mas desde 2006 a Sun não lançou mais nenhuma nova versão do Java. Como Java parou no tempo e a a Microsoft com sua política fechada de preservação do Windows não atrai os desenvolvedores open source, a inovação começa a aparecer em outras plataformas como o Ruby (on Rails), Python, Scala, Groovy, Closure, Erlang, etc. Todas essas novidades, são absorvidas rapidamente pelas startups, mas não pelas empresas tradicionais, e portanto o cenário de liderança de Java nesse setor ainda não mudou.
No início do ano passado a Oracle concluiu a aquisição da Sun, e no final de setembro divulgou o roadmap do desenvolvimento do Java dos próximos 2 anos. O resultado foi esperado, o Java vai levar 2 anos para incorporar as novidades apresentadas por essas linguagens. Para quem procura inovação, é um balde de água fria, porém é uma estratégia conservadora e segura para as empresas tradicionais (que são típicos clientes Oracle).
O COBOL durante muitos anos também foi a principal plataforma para desenvolvimento de Enterprise software, mas não conseguiu acompanhar a evolução tecnológica. Hoje COBOL existe apenas no legado. Mas o que aconteceu com COBOL? O que fez ele perder a liderança?
A partir de meados da década de 70, começam a surgir e se popularizar os computadores pessoais. Durante a década de 80 esse fenômeno começa a atingir as empresas, em especial as que não tinham condições de ter um mainframe. COBOL é uma solução forjada para o mainframe, e os microcomputadores demandavam plataformas de desenvolvimento novas, mais adaptadas as suas características. Neste cenário, soluções como o Clipper eram cada vez mais usadas especialmente para pequenas empresas, que não tinham dinheiro para comprar um mainframe. Nenhuma dessas plataformas (como Clipper, Delphi, VB, SQLWindows, etc) conseguiram substituir em larga escala o COBOL nas grandes empresas. Essa substituição maciça em só acontece com a adoção do Java, combinada com o aparecimento do Linux e a evolução do Windows.
O cenário atual parece criar um momento semelhante ao que foi vivido pela revolução da microinformática, mas com algumas diferenças significativas.
A revolução atual é o cloud computing. Java, diferentemente do COBOL na época dos micros, ainda é adequada para soluções cloud, além disso, falta surgir uma plataforma tão disruptiva e confiável quanto foi o Java em seu tempo. A estratégia da Oracle compromete a liderança de Java como uma plataforma inovadora, mas não sua posição para soluções Enterprise. COBOL foi criada no final da década de 50 e levou uns 40 anos para ser desbancada. O domínio de Java não deve durar tanto, mas ainda será uma aposta confiável para sua empresa por vários anos. De quebra, ainda não sabemos quem será seu sucessor. Java é sim o novo COBOL, mas essa é a pergunta errada. A pergunta correta é quem será o novo Java?
Nota do autor: Nunca programei em COBOL, não sou tão velho assim.
TDD mais importante que tudo
No dia 18/09/2010 apresentei a palestra "TDD direto das trincheiras" em João Pessoa, no evento "Agilidade Paraíba" promovido pelo grupo Scrum-PB. O público era bastante jovem e poucos conheciam ou usavam TDD. Espero ter conseguido despertar a curiosidade de várias pessoas, mas na verdade eu ainda fico bastante chocado como tão poucas pessoas/empresas adotam TDD. Como eu coloco no último slide da minha apresentação, "TDD é mais importante que tudo".
A prática do TDD viabiliza economicamente o design evolutivo e em última instância o próprio desenvolvimento iterativo incremental. Através principalmente do TDD é que a curva de custo da mudança pode ser suavizada.
Usando TDD as pessoas perdem o medo de fazer refactoring para remover código duplicado ou para evoluir funcionalidades existentes. O uso do TDD induz ao programador ter um melhor entendimento do negócio. Além disso, usamos menos o debug (que toma um baita tempo), localizamos mais rapidamente os bugs e enfim, escrevemos um código de melhor qualidade.
Se você não usa TDD, sugiro que avalie melhor esta prática. Não é fácil fazer a transição. Leva tempo e esforço, mas quando a ficha cai, você não vai querer trabalhar de outra forma. Estude, se prepare bem. Se precisar de ajudar é só chamar
Como brinde, deixo aqui um link com uma introdução ao TDD bastante legal. Boa Sorte!
Curado da IDE-dependência
No post "Jogue Fora sua IDE" eu falava sobre a IDE-dependência, de como ficamos dependente de IDEs e de como isso é ruim especialmente quando estamos aprendendo uma nova tecnologia. Pois bem, eu estou CURADO! Já faz um tempo que estou usando (aprendendo) Scala, e sem usar nenhuma sofisticada IDE.
Configurei um ambiente para programar em Scala utilizando apenas o gEdit (linux). O máximo que me permiti foi um syntax highlight, mas nada de code assist. De quebra, estou usando o sbt em um terminal integrado ao editor. Veja só:
Cuidado com a IDE-dependência. IDEs são ótimas ferramentas de produtividade, mas só funciona para quem domina o que está fazendo.
Codificação é Commodity?
Ouvi uma coisa no início dessa semana que não saiu da minha cabeça: "codificação é commodity". E aí? Será que é mesmo?
Quando usamos o termo commodity para serviços deve ser necessário que as empresas tenham uma certa uniformidade em relação a prestação deste serviço. Por exemplo, enviando uma especificação para duas "fábricas" de software espera-se que ambas entreguem o mesmo produto (com poucas diferenças) e mais ou menos no mesmo prazo. Em um cenário assim, a escolha do fornecedor vai depender primordialmente do preço. Vamos escolher a "fábrica" que cobrar mais barato. Para fortalecer ainda mais este conceito, temos certificações como o MPS.BR e CMMI que servem para classificar os fornecedores. Imagina-se então que duas empresas que são CMMI nível 5 devem produzir mais ou menos a mesma coisa no mesmo prazo e portanto, posso escolher a que me cobrar mais barato. Você realmente acredita nisso?
Diferentemente de como muita gente pensa, codificação não é uma atividade mecânica. Não existe nenhuma máquina em que você coloque as especificações em um buraco e saia o software pronto do outro lado. Arquiteturas, especificações, designs são modelos meramente teóricos. Nenhum arquiteto ou projetista pode garantir que aqueles esquemas irão funcionar. Para saber se vai funcionar o sistema tem estar codificado e rodando. Na prática esses modelos teóricos ajudam a estruturar o problema e definir as soluções em um nível mais abstrato, mas durante a implementação é que os detalhes emergem e as decisões finais são tomadas. Não sendo uma atividade mecânica que dizer então que não pode se considerar uma commodity? Acho que não, outros fatores devem ser analisados como por exemplo o desempenho dessa "indústria".
E como está o desempenho dessa "indústria"? Basta dar uma olhada no resultado do CHAOS Report (relatório anual do desempenho dos projetos de desenvolvimento de software feito pelo Standish Group). Em 2009 apenas 32% dos projetos de software foram considerados plenamente bem sucedidos. Como uma "indústria" com desempenho tão ridículo pode oferecer um serviço considerado commodity?
Cuidado, se você vai contratar uma empresa de desenvolvimento de software não olhe apenas para o preço. Fazer software é muito difícil e muito pouca gente sabe. Procure uma empresa que tenha um portfólio de sucessos. Não acredite apenas nessa bobagem de certificações, isso não vale nada. Tratar desenvolvimento de software como commodity só vai trazer dor de cabeça e prejuízo.
Por que você precisa (re)aprender linguagens funcionais?
Continuo investindo neste tema. Essa apresentação fiz em maio aqui no CESAR.
Jogue fora sua IDE
Há algum tempo atrás, um amigo meu (Samuel) me disse que quando estava aprendendo algo novo (um framework ou uma nova linguagem) ele preferia usar o notepad ao invés de uma IDE. Naquele momento eu não dei muita importância, e ainda disse que era frescura, que usar uma IDE era bem melhor. Na hora eu não me dei conta, mas hoje vejo que eu já estava com IDE-dependência aguda.
Estou estudando Scala, e a primeira coisa que procurei para começar o estudo foi uma IDE para começar a dar meus primeiros passos. O problema é que não existe ainda nenhuma IDE que seja boa o suficiente para Scala. Primeiro tentei o Eclipse, mas o plugin está incrivelmente instável, não deveria ser nem disponibilizado para download. O Netbeans não está muito a frente e o IDEA é o melhorzinho, porém com muitos bugs também. Resultado, fiquei com o IDEA e comecei a trabalhar. Por conta dos problemas e dificuldades em pouco tempo eu travei. Perdi a paciência por usar uma ferramenta com tantos problemas e parei os meus estudos práticos.
E agora? Vou ter que esperar meses (ou anos) para que alguém desenvolva uma IDE boa o suficiente? E quando não existia ferramentas com esse nível de recursos? Como a gente se virava?
Quando eu comecei a trabalhar, usava Turbo C 2.0. Alguém se lembra? Não tinha syntax highlight, abria apenas um arquivo por vez e code assist nem pensar. Tinha copy and paste e lamba os beiços. E que saber? Era uma ferramenta muito boa. Era boa e produtiva pela simples razão que EU SABIA O QUE ESTAVA FAZENDO.
As ferramentas de hoje em dia são tão sofisticadas, tem tantos recursos e facilidades, que criaram uma geração de programadores que são absolutamente dependentes delas. Programadores que não são capazes de saber que método de uma determinada classe ele precisa chamar. Se não tiver um code assist eles simplesmente não sabem o que fazer (muitos não sabem nem com o uso do code assist).
Precisamos abandonar um pouco nossas IDEs. Precisamos (re)aprender as linguagens e frameworks sem o uso dessas facilidades. Só quando finalmente estivermos seguros sobre o nosso conhecimento é que estamos autorizados a usar as IDEs. Bye bye IDEA, seja bem vindo o Notepad. Agora finalmente vou APRENDER Scala. Depois de um momento de negação estou finalmente me curando da IDE-dependência. Samuel, você estava CERTO!
Porque linguagens funcionais são importantes
Dos 3 principais paradigmas de programação (funcional, imperativo e orientado a objetos), o funcional é o mais antigo. A primeira linguagem de programação funcional foi criada em 1955 (IPL) e a mais popular LISP foi criada em 1958. Apesar de surgirem um pouco depois (Fortran e COBOL foram criadas respectivamentes em 1956 e 1959), as linguagens imperativas tiveram maior popularidade. Mesmo sem ter alcançado o mainstream, o paradigma funcional continou recebendo investimentos ano após ano até meados dos anos 90, quando a turma das linguagens imperativas se fundiu definitivamente com o pessoal de orientação a objetos (C++ e principalmente Java são exemplos) enterrando as linguagens funcionais no lixo da história. Acabaram as esperanças desse paradigma se tornar parte do mainstream. Será?
O tempo passou e nos últimos anos alguns sinais começaram a aparecer. Erlang (linguagem funcional proprietária criada pela Ericsson) que foi banida e distribuida de forma open-source em 98, volta a ser utilizada pela Ericsson (e por muitos outros) em 2004. A Microsoft lança o F# (linguagem funcional para a plataforma .NET). O pessoal do Twitter reescreve seu back-end em Scala (linguagem funcional e OO para a plataforma Java). C# incorpora conceitos funcionais na sua linguagem para dar suporte ao LINQ. A Google publica artigos mostrando como utiliza o paradigma funcional para armazenar e recuperar dados. Porque esse interesse no paradigma funcional foi renovado? Qual o pulo do gato?
Devido a proximidade de limites técnicos e preocupação com consumo de energia, o pessoal de hardware está focando no desenvolvimento de novos processadores em soluções de múltiplos cores. Em breve teremos processadores com centenas de cores. Para se beneficiar deste panorama, temos que escrever softwares que executem de forma paralela. A boa notícia é que é muito mais fácil escrever código concorrente em liguagens funcionais do que em linguagens imperativas.
Não existe um único paradigma que seja indicado para resolver todos os tipos de problemas. Precisamos aprender (ou reaprender) o paradigma funcional, que foi abandonado por muito tempo. Precisamos de linguagens que incluam de forma coerente vários paradigmas, para que a gente possa escolher a melhor forma de resolver um determinado problema. Por fim, precisamos aprender Scala, que me parece a mais promissora nas novas linguagens multi-paradigma.
SQL ou NoSQL? Essa é a questão
Banco de dados relacionais fazem parte da nossa vida há muito tempo. SQL e abstrações (HQL por exemplo) fazem parte da rotina de qualquer desenvolvedor de sistemas de informação. Agora, será que o domínio dessa tecnologia vai continuar prevalecendo na era da Internet?
Gigantes da Internet como Google, Amazon, Facebook, entre outros, descobriram há um bom tempo que os bancos de dados relacionais não atendem suas necessidades, especialmente as relacionadas com escalabilidade. Essas empresas investiram em outro tipo de tecnologia para armazenamento e recuperação de dados. Hoje essas soluções são conhecida coletivamente como NoSQL.
Agora vem a grande questão, para onde eu vou: SQL ou NoSQL?
Cada opção tem sua aplicabilidade, não seja dogmático (muitos nas duas comunidades são) e aproveite o que cada tecnologia tem de melhor. A única coisa que quero alertar é que a opção por NoSQL é uma realidade viável. Claro que as soluções NoSQL ainda tem que comer muita farinha para chegar a maturidade, mas podemos enxergar nisso uma oportunidade de pioneirismo. Como desenvolvedores de software temos que estar preparados, então arregace as mangas e vá ESTUDAR!