Enquanto isso, a Microsoft desiste de comprar o Yahoo

maio 4, 2008

Atenção, este blog foi migrado para: http://brunopereira.org

Em uma nota divulgada publicamente ontem, a Microsoft anunciou que desistiu da idéia de comprar o Yahoo.

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.

Anúncios

Google também na TV, rádio, mídia impressa

maio 4, 2008

Atenção, este blog foi migrado para: http://brunopereira.org

Fiquei sabendo pelo post do Antônio Carlos que o Google lançou recentemente o TV Ads. Esta é uma ferramenta muito interessante e flexível de fazer propaganda na TV.

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??


Blogueiros “comuns” conseguem ganhar dinheiro com o Google Ads?

abril 14, 2008

Atenção, este blog foi migrado para: http://brunopereira.org

Isto é algo que eu gostaria de saber. Recentemente eu estava conversando com o Bruno Tonetto sobre o WordPress, e aí ele me perguntou se o WordPress permite usar o Google Ads.

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 🙂


Atom: one format to rule them all?

março 3, 2008

Atenção, este blog foi migrado para: http://brunopereira.org

Recently I’ve had several conversations regarding the Atom Syndication Format. This format is gaining more and more adopters and several big players in the industry are using it. Just to name the big boys, Google AND Microsoft are using it to implement RESTful APIs. When was the last time you heard Google and Microsoft agreed on something? 🙂 This should hint that Atom is indeed a nice thing happening in our field.

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 😉


Google Data API

fevereiro 21, 2008

Atenção, este blog foi migrado para: http://brunopereira.org

I’m currently using Google Data API at work. This API offers RESTful interfaces for several Google services, such as Calendar, Picasa, You Tube, Blogger, Google Documents, among others. There are also client libraries for Java, C# and Python, but these are actually tools to facilitate, rather than new interfaces. All client libraries access the RESTful interfaces, so by all acounts the API is RESTful.

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!


Microsoft faz oferta de compra do Yahoo! por US$44,6 bilhões

fevereiro 1, 2008

Atenção, este blog foi migrado para: http://brunopereira.org

Em um post anterior aqui no meu blog, eu havia mencionado que fazia todo sentido para as 2 empresas a compra do Yahoo! pela Microsoft.O Yahoo! é uma empresa bastante criativa e que sabe ganhar dinheiro com propaganda na internet, mas estava passando por problemas financeiros graves. A Microsoft tem mais dinheiro do que qualquer outra empresa de software, mas não conseguiu ainda estender os seus domínios ao espaço da internet. Além disso, a Microsoft tem sido sempre muito vagarosa em qualquer movimento tecnológico, e tem mantido sua posição confortável de faturamento basicamente com as vendas de Windows e Office.

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 😉


Atom feeds for enterprise application messaging

janeiro 27, 2008

Atenção, este blog foi migrado para: http://brunopereira.org

In the last months I have studied and worked a lot with web services in general, and more specifically the RESTful ones. I believe we are going through a fast maturation process in this area, and RESTful web services are becoming the preferred choice for many new implementations. Right in the thick of things in this field is the Atom Publishing Protocol. This is the blueprint solution for RESTful web services, and its adoption is growing fast, reaching much broader scope than just blog applications using the Atom Format.The Atom format and AtomPub protocol can both be used for many interesting purposes. This year I’m working on a big refactoring (actually a new implementation) of a widely used Globo.com application. This application (let’s call it Register) is responsible for the creation of new users and provisioning new services to them, among other features.

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!