Uma questão muito importante no mercado de software é o lock-in de fornecedores, no qual os clientes às vezes se vêem obrigados a manter um fornecedor de software mesmo sem estarem satisfeitos com o serviço/produto oferecido. Discussões em torno disso são muito freqüentes quando comparamos o modelo de desenvolvimento customizado com o trabalho em torno de produtos.

Além destas duas opções já antigas, há uma terceira na moda: Cloud Computing.

Embora eu tenha certas preferências pessoais em alguns cenários, não aponto nenhum desses modelos como o mais indicado de uma maneira geral.

Quando você compra serviços de software customizado, teoricamente o seu investimento inicial será mais baixo do que comprando um produto, mas deve-se avaliar o quão produtivo é o produto, o quanto de esforço você terá para desenvolver de forma customizada, qual é o “time-to-market” desejado, ROI, entre outros fatores. Isso varia demais de um tipo de projeto para o outro, e depende do grau de commoditização dos produtos e do conhecimento do domínio.

Além destes fatores, o lock-in é uma característica importantíssima que deve estar sempre na cabeça das pessoas. Existe uma tendência a achar que o fato de você comprar software proprietário vai necessariamente te prender a um fornecedor. Dependendo do cenário realmente existe uma dificuldade enorme em trocar, mas em outros casos isso é bem mais tranqüilo.

A questão é que com software customizado isso também ocorre muito. Software customizado pode amarrar o cliente até mais do que um produto comercial, dependendo de como for construído, e da participação do cliente no processo.

Sobre Cloud Computing, existe uma enorme febre nesse momento. Todo mundo falando em colocar aplicações “na nuvem”, nos ganhos de custo-benefício, na escalabilidade, e muitas outras “ilidades”. A proposta realmente é tentadora. Você rodar suas aplicações numa infra-estrutura gerenciada por experts do Google, da Amazon ou da Sun parece um sonho realizado. Se você pensar que eles compram hardware muito mais barato que a gente e já têm enormes parques tecnológicos com capacidade ociosa, praticamente fica impossível argumentar contra isso.

Para muitas empresas isso pode realmente fazer sentido. Colocar “na nuvem” serviços que não sejam muito críticos, para empresas de porte limitado. Agora, vamos pensar em empresas que já têm uma enorme gama de aplicações em produção, em datacenters existentes, com políticas de segurança, privacidade, etc.

Será que seria fácil e conveniente ligar a sua empresa “na nuvem”, expondo vários dados críticos e sigilosos, e trazendo riscos de segurança para seu ambiente? Pensem num cliente que já tem um site, uma intranet, ERP, e várias outras aplicações em produção atendendo a fins distintos.

Será que um diretor de tecnologia se sente seguro em abrir sua infra-estrutura para se integrar com redes, computadores e pessoas que ninguém sabe afirmar ao certo onde estão? Você teria certeza de que aqueles dcumentos valiosíssimos da sua proposta comercial não estariam acessíveis pelos concorrentes? Pense em quantas VPNs e configurações complexas de segurança seriam necessárias para adequação a esta nova topologia. Já não é tão sexy, não é mesmo?

Além deste aspecto, o hype em torno de Cloud Computing é tão grande que já estão sendo discutidas possibilidades de interoperabilidades entre Clouds. O mercado ainda está longe de amadurecer, e já vemos discussões comuns em mercados consolidados. Do meu ponto de vista, Cloud Computing pode ser muito interessante, mas é necessário um grau de confiança no fornecedor em níveis que eu raras vezes vi entre pessoas, e muito menos entre empresas.

Depois de tantos anos, comprar software continua muito difícil, e exige um conhecimento cada vez mais sofisticado. O segredo dos projetos melhor sucedidos que eu já vi é a parceria verdadeira entre os fornecedores e os clientes. Projetos de software que dão certo são os que têm pessoas competentes, bem intencionadas e ambiciosas em ambos os lados.

Os melhores fornecedores de software aproveitam cada projeto para trazer o máximo ROI para o cliente, e então conquistar sua confiança e parceria para mais projetos no futuro. E os melhores clientes são os que agem como donos do negócio de suas empresas. Eles buscam todas as oportunidades de melhorar os resultados das empresas, e com isso alavancar suas próprias carreiras.

A Concrete, modéstia à parte, é um baita fornecedor de software. E eu estou tendo a chance de atuar em projetos diferenciados e não há nada mais contagiante para um profissional de software. Estou tendo a chance e a responsabilidade de trazer resultados expressivos para a empresa, e se eu for realmente competente isso trará muitas vitórias para a empresa e para mim (bom, pelo menos eu espero.. ).

Faca nos dentes, sempre em frente

Foi anunciado recentemente o Microsoft Office Web. Embora não seja nada inovador, pois o Google Docs já existe há algum tempo, eu gostei dessa novidade. O serviço ainda não está disponível, mas um FAQ sobre ele já foi publicado.

Achei interessante que o Office Web suportará o Firefox e o Safari além do IE. Além disso, usuários de qualquer sistema operacional poderão usar o serviço, contanto que tenham um dos browsers suportados. Quando eu soube que lançariam o Office Web, a primeira coisa que veio à minha cabeça foi que só funcionaria com o IE e que seria necessário instalar algum add-on que só funcionasse no Windows. Saber que isso não é verdade foi uma ótima surpresa.

Eu utilizo com freqüência o Google Docs, e gosto muito da praticidade do serviço. A facilidade de compartilhar documentos e editá-los de forma simultânea é ótima. Desde que comecei a usar o Google Docs, eu raramente uso o Open Office ou Word. Praticamente só uso um dos 2 quando eu tenho que escrever alguma coisa com preocupações em relação a estilos e formatação. O Google Docs é bem limitado neste sentido, infelizmente.

Com o Office Web, provavelmente o suporte a estilos e formatação será melhor que no Google Docs, e isto pode me estimular bastante a usá-lo e aposentar o OpenOffice e Word, e viver ainda mais na Web.

Algumas conseqüências bacanas podem surgir deste novo serviço. A competição entre o Office Web e o Google Docs provavelmente trará muitos benefícios aos usuários finais, que deverão ter serviços web gratuitos e de ótima qualidade.

Além disso, o Office Web fará a Microsoft sofrer um pouco com as incompatibilidades entre os browsers. Suportar as mesmas funcionalidades no IE, Firefox e Safari dará um certo trabalho. Talvez isso desperte uma iniciativa da Microsoft de consertar o IE, e fazer com que os desenvolvedores web em geral tenham menos trabalho com essas incompatibilidades.

Se o Office Web trouxer essas 2 mudanças, terá sido uma das melhores iniciativas que a Microsoft já teve. Torço para que esse projeto ganhe força e que todos possamos usufruir dos benefícios

Por enquanto o conteúdo desse blog é apenas o conteúdo importado do blog anterior. Entretanto, aos poucos farei uso dos recursos que disponho nesta hospedagem e colocarei algumas coisas interessantes aqui.

Uma das coisas que mais me agradava na hospedagem gratuita do Wordpress era que o SEO deles é excelente. Meus posts apareciam muito bem em várias buscas do Google, e isso é um ponto importante para o sucesso de qualquer blog. Eu instalei um plugin que gera o sitemap para as engines de busca e espero que isso tenha resultados semelhantes ao Wordpress gratuito.

Bom, se você já conhecia o meu blog antigo, continue acompanhando ele por aqui, pois pretendo continuar melhorando o conteúdo por aqui.

Buenas noches!

As duas empresas não chegaram a um consenso financeiro, mesmo após a Microsoft aumentar sua oferta inicial em cerca de US$ 5 bi. Aparentemente a diferença de cultura entre as empresas é tão grande que o Yahoo exigiu um valor muito alto pela compra, para recompensar seus acionistas.

O Yahoo chegou até mesmo a flertar com uma possível parceria com o Google para serviços de busca, na qual o Yahoo retornaria links patrocinados pelo Google em uma parcela pequena de resultados. Isto valeria apenas nos Estados Unidos e seria um teste para ver o quão interessante isso poderia ser para as duas empresas.

Fazendo parceria ou não com o Google, o fato é que o Yahoo recusou as propostas da Microsoft. Os acionistas certamente temiam pela perda da identidade da companhia, e preferiram arriscar e continuar tendo competir de forma individual.

Depois dessa decisão, ficará muito difícil para a gigante de Redmond a disputa com o Google, considerando a enorme penetração que este está conquistando. A briga por receitas de propaganda ficará muito difícil para a gigante de Redmond, e acredito que a única forma de lutar contra isso seja a oferta de serviços web mais interessantes, para conquistar audiência. O ponto positivo para nós é que certamente esta competição trará mais e mais novidades interessantes para usarmos na internet.

Eles disponibilizam uma aplicação no “self-service” que permite que pessoas interessadas em veicular propaganda na TV façam isso de forma ágil e prática. Você consegue criar uma campanha, definir seu público-alvo, especificar canais e programas e horários durante os quais a campanha será exibida e dizer o quanto você pretende gastar com isso. A aplicação trará várias sugestões e permitirá que você envie a mídia da propaganda para iniciar a veiculação rapidamente nestes vários canais.

Esta é uma iniciativa inovadora e potencialmente muito poderosa para o Google. Além disso, eles também lançaram o Google Audio Ads e o Print Ads. É isso mesmo: eles já dominam a propaganda na internet, e agora lançam ferramentas inovadoras para tentar ganhar espaço na propaganda feita na TV, rádio e na mídia impressa. Fiquei curioso e fui ver a lista de canais e jornais que já participam disso. A maioria dos canais de TV americanos já permite propaganda através do Google TV Ads e a maioria dos jornais também. Entre os jornais estão por exemplo o New York Times, Los Angeles Times, Washington Post e muitos outros. Além disso, inúmeros jornais pequenos (porém com público muito mais específico, direcionado) já fazem parte do programa também. Muito interessante isso.

Já sabíamos previamente da iniciativa do Google de entrar firme no mercado de dispositivos móveis. Agora eles aumentam drasticamente o alcance das ferramentas de propaganda deles. Para completar, também está nos planos do Google a entrada nos set-top boxes de TV digital. Se essas iniciativas forem bem-sucedidas (e certamente tem boas chances), o Google conseguirá uma impressionante penetração no mercado. Será mais poder do que a Microsoft já teve um dia. E tudo isso com um modelo de negócios que traz muito mais simpatia do que a Microsoft.

Difícil saber qual (e se existirá) o limite para eles. Realmente impressionante. Quando será que isso chegará ao Brasil??

Atualmente o Wordpress hospedado no wordpress.com não permite este recurso, mas eles dizem que futuramente isto pode ser liberado. Como eu não sou nenhum superstar e meu blog não é nenhum fenômeno de audiência, eu nunca tinha ligado muito pro Google Ads no que diz respeito ao meu blog.

Entretanto, o Bruno me passou um link bem interessante que me despertou a curiosidade sobre o assunto. Neste link o dono do site comenta que colocou o Google Ads em Fevereiro de 2005, quando seu site tinha 86000 acessos. Neste mês ele ganhou US$ 53, o que não é lá grande coisa. Já em Janeiro de 2006 os acessos do site tinham subido para 715000, e a receita dele com o Adsense subiria para US$ 4700, o que já é bem interessante.

Considerando que estes números são do começo de 2006 e este mercado evolui bem rapidamente, eu gostaria de ter uma idéia de quão interessante é o Google Ads para blogueiros “comuns”. Blogs de pessoas que não sejam superstars, e portanto tenham uma quantidade de acessos bem mais humilde que este site do link.

Eu recentemente tenho pensado em utilizar o wordpress em uma hospedagem própria, para poder mexer um pouco na estrutura do blog e poder colocar mais conteúdos também. Eu uso uma hospedagem bem interessante para projetos freelance, e ela me dá vários serviços como hospedagem php (pro Wordpress e phpPgAdmin), servidores Tomcat ou JBoss, SVN/CVS, Postgresql/MySql e mais uma porção de coisas.

Utilizando o wordpress em uma hospedagem separada eu teria uma liberdade maior para mexer no que quisesse, e também poderia usar o Google Ads, se fosse o caso.

Depois de ver que com 715000 acessos em 2006 um cara ganhava US$ 4700 por mês, eu não consigo entender como o Matt Raible não usa o Google Ads no site dele, que tem cerca de 2 milhões e meio de acessos mensais.

O meu blog é bem mais humilde. Este mês ele deve fechar com pouco mais de 4000 acessos. Eu o criei em novembro do ano passado, e ele vem crescendo progressivamente, num ritmo constante, mas não muito rápido. Eu tenho a curiosidade de saber se daria para ganhar alguns trocados tendo uns 10000 acessos mensais. Acho que este é um valor normal para um blog pessoal. Claro que alguns blogs têm muito mais acessos do que isso, mas já é bem mais difícil.

Se alguém utilizar o Google Ads e souber responder a esta pergunta, por favor responda por aqui ou diretamente por e-mail, se preferir. Eu não criei meu blog pensando nisso, e definitivamente este não é um dos fatores mais importantes pra mim. Mas é legal ter uma idéia do nível que estamos em termos de propaganda na internet, e claro que se for interessante para mim eu farei uso deste recurso

Web services using the Atom format for data exchange encapsulate information using Atom’s standard elements and also define some extension points where needed. Some very useful elements are present in the specification. There are standard ways of publishing individual entries and collections, pagination support, links between resources, among other things useful for RESTful web services.

Depending on your domain model, the amount of data you would put in Atom extension points varies a lot. Some domains such as Google Apps can produce a RESTful model that uses a lot of Atom’s standard elements without needing to define too much extension points. However, if you use Atom to exchange billing information between ISP applications, you’ll probably have to define a lot of extension points. I’m saying this to show that some domains match much better to Atom structures than others.

While talking to Silvano (a very clever working mate of mine) a couple of weeks ago, he asked me if encapsulating everything inside Atom elements was not the same as encapsulating everything inside SOAP. This is a very very good question.

When you’re choosing a format for you data exchange in web services, it’s very important to analyse what you gain and what you lose by picking any given format.

For example, a good rule of thumb about SOAP services is: “WS-* is just overhead unless you have something meaningful in your SOAP Headers” (quoting Sanjiva Weerawarana at ApacheCon 2007).

Atom was designed in a RESTful manner by a very talented group of professionals. Many applications are making use of it to exchange data, and the adoption is growing fast. Could it be a silver bullet then?

That’s where I shall leave my observations. If you consider my example of billing information, you’ll see that most of the data there doesn’t mesh well with Atom’s standard elements. Thus, we’d need to define a lot of extension points, and wouldn’t make much use of Atom’s resources. Putting billing data inside Atom entries would represent an overhead without giving us much in return. In this case, I’d rather use my own XMLs directly over HTTP.

Am I saying that Google and Microsoft made a bad decision choosing Atom? No, absolutely not! Their decision was very good. Microsoft is using Atom for Windows Live API and Google’s using it for most of their applications. What do these have in common? They all manipulate web content. They have a domain where many things are accessible on the web, with lots of URIs, different media types, pagination, categories, tags, etc. Atom makes a lot of sense with web content.

I don’t think Atom is a Silver Bullet for RESTful web services in general. Of course you can choose to always use it, and benefit from the standards and the avaiable tools. But isn’t this true for SOAP as well?

What I do think is that Atom is very close to a Silver Bullet when you’re dealing with web content. Whenever you’re developing web services, choosing the right format for your data exchange is one of the most important decisions. To know well the avaiable options is very helpful, and certainly the Atom format brings a lot to the table when your domain meshes well with it. As long as you don’t think it’s the best choice for every application, go ahead and use it wisely

What I’d like to comment is how easy it was for me the to get up to speed with the API. There are several pages explaining the API’s features, the URIs, their use of HTTP method, return types, etc. Their design is pretty much compliant to all REST best practices (although they do use some query string parameters ocasionally). Being very familiar with this kind of web services, most of what I did was looking and saying: “Ok , this is how i expected it to be”. And after less than one hour I was ready to begin using the API properly.

Worth noting is that there were no “Interface Document” to look at. Not anything similar to WSDL or any other IDL. What was there was just a simple and RESTful API that was pretty easy to use after you knew what the resources were and which operations they support. Several pages describing their protocol and the XML entities they use were enough for me to know how I was supposed to integrate with a reasonable amount of their services.

I don’t even want of to think of how would it be if they had WS-*. Just to read the WSDL documents would take me more time than to read all their RESTful documentation. There would be a lot of operations and messages described in their WSDLs, and it’d be a massive reading to get the grasp of the API.

Fortunately Google (the most powerful web company) is embracing a RESTful design and it should probably take many other companies with it. They’re also supporting the use of Atom and Atom Publishing Protocol, so many nice things should keep coming. Apache Abdera is already integrating Google Feed Server code, and hopefully we’ll be able to use Abdera for most of Google’s services.

Very very nice! By the way, I took a good look in the source code of Google Data API and it’s very well implemented. They have a very interesting approach to manipulate feeds and entries. It makes it very easy to model a lot of stuff using just feeds and entries. It was an inspiring code inspection and I’m thankful Google also embraces open source These guys are good!

A junção das 2 empresas trará dinheiro para investimentos tecnológicos do Yahoo! e trará para a Microsoft a expertise do Yahoo! em propaganda na internet. Esta compra tem obviamente uma grande relevância no mercado, e será interessante ver como se sairá o Google nesta disputa.

Eu particularmente acredito que o Google está tão bem servido de profissionais e de finanças que será muito difícil a Microsoft alcançá-lo em termos tecnológicos. É claro que com o enorme faturamento que a Microsoft terá, ela continuará numa posição muito confortável financeiramente. Mas em termos de vanguarda de software, a Microsoft tende a ficar cada vez mais para trás.

Vamos esperar o desenrolar de todas essas aquisições recentes para ver como o mercado ficará, mas bem que o Google podia comprar o Ubuntu e dar uma canseira na Microsoft na briga por sistemas operacionais também

A nice concept present in the original development is the use of Application Connectors. Through these connectors, other applications get notified of events that happened in the Register application. An example is: when a new subscriber (a paying user) is created, a connector sends the notification to another application in order to create the subscriber’s mailbox in the company’s external mail provider. Another example is: when a user gets provisioned in the blogging service, another connector sends a notification to the blogger application, that does what it needs in order to create the user’s directory and quota on the file server.

Although i like this concept, it currently has some problems. This connector’s invocation is done explicitly by the Register application. The Register application knows that a new subscriber must receive a new mailbox, and it needs to call a given connector to do this. This is my biggest concern with the current implementation. I strongly believe that an application that creates users must not know anything about mailboxes. In the current structure, when a new application ABC must be notified of events in application XYZ, application XYZ must be modified to invoke a new connector. This doesn’t please me at all. Let me explain a solution that pleases me more

To explain my idea, I’ll propose some examples involving Google and its services. As we all know, Google offers several different services, all of which can be accessed using the same Google account. When you register at Google, you receive a mail account. Let’s suppose that Google Register application sends a new entry to an Atom feed every time a new user is created. This way, every user creation is present on the Atom Feed. If an application (for example Google Mail) needs to be notified of the creation of new users, it just needs to subscribe to the Register’s Atom feed.

Let me propose a richer example now. Let’s say Google starts to offer some super cool software development services. If you’re a developer, you can ask them to give you a “development account”. This development account would give you access to a Subversion repository, a Bugzilla project and a MySql database. Each of these would be an independent service offered by them, subject to change at any given time. The activation of “development accounts” could also populate an Atom feed.

This way the Subversion, Bugzilla and MySql services could be subscribers of the feed, doing everything they need when a new development account is activated, in asynchronous manner. The application that activates the development account has no knowledge of any other services. If Google wants to offer new services such as a Maven repository or a Continuous Integration environment, no problem. The new services would just subscribe to the Atom feed and do whatever they need when a new account is activated.

If Google wants to offer a free development account and a non-free account with better features, there could be another Atom feed for the activation of the paying accounts or maybe updates to the same existing feed. The Register application would know only about registrations, and other components could be easily plugged and unplugged from this process, without modifications on the Register application. Ah, and worth mentioning… totally decoupled from any specific platform. I don’t know how to implement any kind of messaging more decoupled than that.

This is much much better than the way our Register application sends notifications currently. And I’ll be pretty happy once we manage to do this, it’ll be so cool!

By the way, these Google’s software development services would be awesome. My friend Bairos kindly provides me Subversion and Trac services, but he doesn’t have Google’s bandwidth Let’s hope Google gets to know about this and starts offering these services. It’d be amazing!