Inovação se escreve com C. O caso Oracle.
Nunca tive grande simpatia pela Oracle, mesmo assim nunca deixei de reconhecer as qualidades do seu carro chefe, o Oracle Database.
Apesar de gozar da liderança do mercado há décadas com sua solução de banco de dados, como qualquer grande empresa, a Oracle não pode se contentar em ser cantor de uma música só. Através de dezenas de aquisições a empresa entrou em diversos outros setores, mas sempre com foco Entreprise. Com a aquisição da Sun em 2009, a Oracle entrou de cabeça no mercado de Hardware.
As duras penas a Oracle está descobrindo que as margens em hardware são bem menores que no mercado de software, além disso a tendência de Cloud e SAAS (Software as a Service) está fazendo que o mercado de Data Centers (seus principais clientes) fique cada vez mais encolhido e centralizado. Esses fatores evidentemente estão afetando o bottom-line da Oracle.
Após o anúncio de seu decepcionante resultado nesta semana, as ações da Oracle despencaram. 14% em um só dia. Não creio que essa tendência de queda seja passageira. A Oracle é uma empresa que nunca conseguiu se reinventar e continua apoiada apenas em seu único produto de grande sucesso. Inovação para a Oracle é colocar a primeira letra da buzzword do momento ao lado da versão de seu banco de dados, foi assim com o Oracle 8i (i de internet) e Oracle 10g (g de grid). O que fazer? Considerando sua história, o jeito que tem vai ser lançar uma nova versão para seu banco de dados, o Oracle 12c (c de cloud).
Assuntos aleatórios que podem mudar sua vida
Semana passada fiz uma apresentação aqui no CESAR para despertar o interesse nas pessoas em se informar mais. É muito importante ficar antenado em tudo que está acontecendo a sua volta. Além disso, é muito mais rico aprender em grupo do que aprender sozinho. Além de ler mais e acompanhar mais o que está acontecendo a sua volta, é importante envolver outras pessoas na discussão. Estou muito feliz porque estou vendo que a mensagem atingiu algumas pessoas que estão sendo catalizadores de uma grande mudança. Para registrar, aqui estão os slides:
Todas as coisas que todo programador não pode deixar de saber
Fiz essa apresentação com o objetivo de resumir e simplificar as coisas mais básicas que todo profissional de desenvolvimento de software simplesmente não pode deixar de saber. Acho que ficou bem legal e funcionou bem em 2 níveis: para os iniciantes se prepararem para o mercado de trabalho e para os experientes lembrarem de coisas que muitas vezes são esquecidas. Foi apresentado no C.E.S.A.R e em várias universidades daqui de Recife. A primeira apresentação foi gravada e você pode ver e ouvir clicando aqui (é o webseminar 15).
O Browser Morreu?
Finalmente entrei de cabeça no mundo móvel, agora sou proprietário de um iPad e um celular Android (Samsung Galaxy S). Mesmo usando meus novos brinquedinhos por poucos dias, reforcei uma visão que já estava percebendo: A era de ouro dos browsers web está acabando.
Já faz tempo que a popularização dos celulares pressionou a indústria de software a criar soluções específicas, que atendessem as características particulares dos celulares (telas menores, teclado numérico, limitações de memória, etc). De uma forma geral, especialmente quando falamos de aplicações web, essas limitações poderiam ser identificadas como um subconjunto das características de um computador completo. Sendo assim, as soluções técnicas na web seguiram a linha da simplificação. WML e HTML atendiam perfeitamente a demanda da web no celular, e todos os sites relevantes fizeram versões de suas páginas para celulares utilizando essas tecnologias. Mas aí, a Apple criou o iPhone.
Com o iPhone tudo mudou. Novas características como touch screen e o acelerômetro tornaram inviável a criação de uma interação rica com usuário na web utilizando as tecnologias disponíveis. Era preciso criar aplicações específicas para o iPhone. A última peça do quebra-cabeça foi o App Store, com ele o problema da busca e distribuição das aplicações estava também resolvido. O sucesso de vendas forçou imediatamente a todos os distribuidores de conteúdo a criar suas aplicações iPhone. Este modelo deu tão certo que todos os fabricantes acabaram o seguindo. E depois surge o iPad.
Com a criação do iPad, se popularizou um novo segmento de dispositivos móveis, os tablets. O sucesso do iPhone se repetiu aqui, e como esperado o resto da indústria seguiu o modelo. Só que, mais uma vez, características específicas do iPad, especialmente relacionada ao tamanho fez com que as aplicações criadas para o iPhone não sejam suficientes. É preciso criar versões das suas aplicações para o iPad, e isto está acontecendo. Mas é necessário ter tantos dispositivos diferentes?
Eu acho que sim. Uso prioritariamente o meu notebook para produzir conteúdo (estou escrevendo este post nele), o iPad para consumir conteúdo e o celular para comunicação (através da telefonia celular ou internet). Não abro mão de nenhum. E também não acredito que vá aparecer um dispositivo único capaz de ser tão adequado para todas as essas atividades. Acho que a situação só deve piorar no futuro. Acho que vai aparecer cada vez mais dispositivos com características diferentes (e nem falamos sobre tv digital) que vão exigir softwares específicos para acesso a conteúdo da rede. Acredito que toda essa diversidade vai impedir que exista uma tecnologia única que abrace todos esses conceitos e seja tão universal como o HTML é hoje. Sendo assim, o que é que vai ser da minha vida?
Agora o desafio está lançado. Temos que criar soluções que englobem interfaces para Android, iPads, iPhones, Google TV, Apple TV, HTML, Flex e o diabo a quatro... Temos que nos preparar e investir cada vez mais em qualidade nos softwares que produzimos. Separação da lógica de negócio da apresentação é vital. Investimento em criação de ferramentas que facilite a criação de interfaces tão diferentes é importante. De qualquer forma, isso representa mais trabalho e mais dinheiro. Mas como ficam os browsers web nesse contexto?
Bem, os browsers ainda vão ser muito importantes, especialmente para uso nos computadores. Mas não deve ser a única ferramenta dominante para acesso a conteúdo. E a web como infraestrutura?
MAIS FORTE DO QUE NUNCA!
Tum tum tum tum tum tum tum
Cloud Computing, REST, JSon, Web Services, SOA, Azure, Web como plataforma, oAuth, NoSql, Cassandra, Redis, Memcached, MySql, PostgreSql, MongoDB, CouchDB, RDBMS, Data Warehouse, BI, Twitter, Microblog, Blog, Facebook, Orkut, Redes Sociais, Scala, Haskell, C#, Java, Groovy, Ruby, Ruby on Rails, Python, Javascript, Smalltalk, F#, Clojure, JRuby, JVM, Polyglot Programming, Agile, Scrum, XP, TDD, BDD, Design Evolutivo, DDD, DSLs, Grasp, OOAD, iPhone, iPad, iTunes, IOS, App Store, Android, Bada, Symbian, Dalvik, Windows 7, OS X, Linux, Unix, VPN, Html 5, Flex, GWT, RIA, Actors, Múltiplos Cores, ESB, Camel, MP3, DivX, H234, Amazon, Google, Apple, Microsoft, Adobe, Oracle, Intel, Ubuntu, Samsung, Subversion, Mercurial, Git, Chrome, Firefox, IE, KVM, Virtualização, e por aí vai...
overloaded... e o pulso ainda pulsa...
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.