Digital Media, Internet and Tech stuff

Algum tempo atrás foi divulgada a iniciativa do Cal Henderson do Flickr e do pessoal do Pownce para criar um padrão que permitisse obter informações de forma estruturada e rápida sobre algum conteúdo que possa ser “embedado” em uma página. Assim surgiu a iniciativa chamada oEmbed, que tem o objetivo de definir algumas regras para intercambio de informações de mídias.

O oEmbed é muito simples e a idéia é interessante, ao invés de vc ter de aprender as mil APIs dos diversos sites que existem na Internet para poder “embeddar” conteúdos destes sites, como Facebook, Orkut, Flickr, Picasa, etc. Vc pode usar a interface oEmbed dos seus providers favoritos, a promessa é que o oEmbed faça para as midias mais complexas (vídeo, áudio e fotos) o que o RSS fez para os conteúdos em texto.

Aqui segue um exemplo:

http://www.flickr.com/services/oembed/?url=http://www.flickr.com/photos/acarlos1000/2314303384/

A Resposta é:

{
"version": "1.0",
"type": "photo",
"width": 500,
"height": 281,
"title": "GloboVideos no MacBook e no Nokia N810",
"url": "http://farm4.static.flickr.com/3231/2314303384_c965ef5c96.jpg",
"author_name": "Acarlos1000",
"author_url": "http://www.flickr.com/photos/acarlos1000/",
"provider_name": "Flickr",
"provider_url": "http://www.flickr.com/"
}


Só acho que é meio nebulosa esta questão de ter a “oEmbed API”(API EndPoint) e uma URL para o Request, quando na verdade isso tudo vai gerar um request HTTP GET e poderiamos implementar isso com REST sem precisar passar por nenhuma “API”. Mas porque simplificar se podemos adicionar algumas camadas de burocracia.

De qq forma esta iniciativa esta apenas no início e com certeza vai evoluir bastante, alguns nomes de peso da Web estão implementando suas APIs oEmbed logo abaixo esta uma lista destes Providers:

Flickr (http://www.flickr.com/)

• URL scheme: http://*.flickr.com/*
• API endpoint: http://www.flickr.com/services/oembed/
• Example: http://flickr.com/services/oembed?url=http%3A//flickr.com/photos/bees/2362225867/

Viddler (http://www.viddler.com/)

• URL scheme: http://*.viddler.com/*
• API endpoint: http://lab.viddler.com/services/oembed/
• Documentation: http://wiki.developers.viddler.com/index.php/OEMBED
• Example: http://lab.viddler.com/services/oembed/?url=http%3A//www.viddler.com/explore/cdevroe/videos/424/

Qik (http://qik.com/)

• URL scheme (videos): http://qik.com/video/*
• URL scheme (user channels): http://qik.com/*
• API endpoint: http://qik.com/api/oembed.{format}
• Example: http://qik.com/api/oembed.xml?url=http%3A//qik.com/video/49565

Pownce (http://pownce.com/)

• URL scheme: http://*.pownce.com/*
• API endpoint: http://api.pownce.com/2.1/oembed.{format}
• Example: http://api.pownce.com/2.1/oembed.xml?url=http%3A//pownce.com/mmalone/notes/1756545/

Revision3 (http://revision3.com/)

• URL scheme: http://*.revision3.com/*
• API endpoint: http://revision3.com/api/oembed/
• Example: http://revision3.com/api/oembed/?url=http%3A//revision3.com/diggnation/2008-04-17xsanned/&format=xml

Hulu (http://www.hulu.com/)

• URL scheme: http://www.hulu.com/watch/*
• API endpoint: http://www.hulu.com/api/oembed.{format}
• Example: http://www.hulu.com/api/oembed.xml?url=http%3A//www.hulu.com/watch/20807/late-night-with-conan-obrien-wed-may-21-2008

Google lançou alguns dias atrás o Friend Connect, um recurso que permitirá uma forma mais fácil de integrar as suas ações online nas diversas aplicações sociais que estão por ai.

Mais uma vez o Google dá um passo a frente e se coloca como ferramenta e não necessariamente como um site de relacionamento social como é o Orkut.

O @nandop fez um post bem legal com as primeiras impressões sobre o este novo serviço do Google, vale a leitura.

Nos últimas semanas temos ouvido muito sobre a Microsoft não por causa do Vista e seus problemas mas, principalmente devido ao “Hostile Bid” de 44,6 Bilhões de dólares que a empresa fez para comprar o Yahoo.

Nesta semana a Microsoft “walked away” e desistiu da oferta de comprar o Y!, isso nos faz pensar o que a Microsoft fará para deter o Google na sua expansão online. IMHO o que esta acontecendo com a Microsoft é que ela demorou a entender as novas possibilidades que surgiram com a Internet, na verdade a Microsoft nunca gostou da Internet ela apenas aceitou que isso existe e usou todo o seu poder ($$$) para destruir a Netscape e colocar o seu browser como a “única” opção, mas o que estamos vendo agora é que essa estratégia da MS que funcionou tantas vezes não esta mais funcionando, a empresa é lenta e tem um mindset antiguado, um mindset de desktop.

Ela parece viver em ciclos de 4 em 4 anos, e neste interim abandona seus produtos totalmente, vejam o que aconteceu com o Internet Explorer e com o Windows Media, no primeiro caso é nítida a lentidão com relação ao Firefox, uma das provas é que até agora não li nada de relevante sobre o IE8 a não ser que eles estão tentando ser mais compliants com os padrões W3C, tentando ser copliant agora?? Em 2008?? Pelo amor de Deus!!! O FF3 vai trazer algumas novidades bem legais, promete arrumar os leeks (let’s hope) e vai continuar pequeno 5 ou 6 MB, já o IE7 precisa de uns 100MB, imagina o que será o IE8.

No caso do Windows Media foi muito pior, a Adobe tomou o mercado de supetão e agora vai ser muito difícil e vai custar uma boa grana para a Microsoft se equiparar. O Silverlight esta MUITO longe do ecosistema que existe em torno do Flash, e vejam que não necessariamente estamos falando de soluções de código aberto, a Adobe é a empresa que mais odeia Open Source depois da MS.

Eu lembro de falar com alguns executivos da MS alguns anos atrás e alertar que o Windows Media estava ficando pra trás e que nós na Globo.com não teriamos opção e iriamos usar cedo ou tarde o Flash, a resposta foi no mínimo triste. Toda a empresa na época estava focada em terminar o Vista e o novo Office, todo o resto foi colocado de lado, incluindo ai o IE e o Windows Media, este foi o preço a se pagar.

Você pode notar que a Microsoft esta tomando uma surra em quase todos os segmentos, Windows Mobile 6.1 não mudou quase nada em relação ao que era a 3 anos atrás, nem o Messenger mobile a Microsoft consegue fazer direito, existem milhões de opções de desenvolvedores terceiros que são melhores e não vou nem perder tempo com o IE mobile, este simplesmente não existe.

Alguns de vcs talvez não saibam, pois não se falou muito deste produto no Brasil mas a MS tentou criar um concorrente para o YouTube que se chamava Soapbox, ela errou em todos os passos, primeiro com a velha mentalidade de usar o Windows Media como formato de vídeo, depois trocou o player para Flash, mas aí era tarde demais, hoje o SoapBox não passa de uma aba no MSN Video.

A Microsoft também não tem nada relevante com relação a comunidades, o Orkut impera no Brasil e Facebook e MySpace dominam o mercado americano, o Google fez um lance de mestre e lançou o Open Social enquanto isso o Live Spaces é irrelevante e talvez tenha o mesmo destino do Soapbox, virando uma aba no Hotmail talvez :-). Claro que nesta área de comunidades tudo pode se “resolver” com alguma aquisição, Facebook e MySpace são compráveis e estão dentro do alcance da empresa de Bill. Aliás a News Corp já deu sinais de que pretende se livrar do MySpace em breve.

A Microsoft também tentou entrar no mercado de MP3 Players com seu aparelho Zune, que já deve ter vendido em torno de 2MM de unidades, o que representa 4% de marketshare contra 71% do iPod, mas o produto apesar de ter evoluido razoavelmente nos últimos meses (lançou suporte a uma loja de vídeos nesta semana), ainda esta longe de ter o appeal e facinio que o iPod conquistou. Mais um exemplo da mentalidade ultrapassada da MS é que ao comprar músicas no Zune Marketplace vc paga em Microsoft Points, WTF? Por exemplo, um vídeo custa 160 Microsoft Points que é o equivalente a $1,99, pra que facilitar se vc pode complicar.

O Vista vende bem apesar de tudo, mas ele esta sendo adotado mais porque as pessoas não tem opção, e ao comprar um micro novo elas não podem escolher ficar com o XP, se houvesse esta opção, não tenho dúvida que o XP venderia mais. No mundo corporativo a história é diferente, as empresas estão evitando com todas as força migrar para Vista. Até a Amazon surpreendeu o mercado com seu Amazon Web Services, e Google e a própria Microsoft estão correndo para oferecer soluções de “Infrastructure as a Service” ainda este ano, o Google já deu o primeiro passo com o AppEngine e a SUN esta repensando os serviços que já oferecia em um projeto chamado Hydrazine.

Dado este cenário vemos porque a empresa de Seattle estava disposta a pagar tanto pelo Yahoo!, era uma opcão de colocar sangue novo na empresa, apesar de o Yahoo não ser nenhuma Brastemp em tempos de Googleplex e computação nas nuvens :-), mas o Yahoo ainda é o maior site do mundo em audiência e tem algumas propriedades interessantes como o Flickr, Del.icio.us, UpComing, OneSearch, Right Media, entre outros que ajudariam a incrementar o portfolio do Live.com

Além disso, tem toda a disputa pelo mercado publicitário online (a atual galinha dos ovos de ouro), que esta cada vez mais sob o controle do Google e começa a gerar o efeito Tostines, onde se você não tem audiência suficiente não há quem anuncie no seu site. Com a compra do Yahoo, a Microsoft iria ganhar escala e um grande volume de tráfego para suas ferramentas de advertising (MS AdCenter, Yahoo Publisher Network, Right Media, Maven, Yahoo AMP e aQuantive) criando assim algum tipo de resistência ao crescimento do Google.

Enfim, a empresa de Bill Gates tem uma dura empreitada pela frente, só que agora o seu principal concorrente tb tem dinheiro pra brincar, por outro lado a MS ainda tem uma posição privilegiada no mundo dos desktops. A questão é, por quanto tempo o desktop será relevante para as pessoas?

Como era de se esperar a inovação não virá das empresas de TV, claro que as grandes redes de TV não estão interessadas em abrir suas redes e suas janelas de advertising para que seja possível a veiculação de um spot de propaganda que participou de um leilão online para definição de seu preço. E mais um agravante é o fato de que o anunciante não tenha comprado diretamente de seus departamentos comerciais, mas mais uma vez o Google veio mostrar o que se pode fazer para mudar os conceitos e os paradigmas.

Mesmo que a maioria das empresas de TV nunca fechem em parceria com o Google para mostrar os Google TV Ads (porque não fazer isso para os horários da madrugada, por exemplo, pelo menos para testar), a interface e a facilidade de criar uma campanha apenas acessando algumas páginas através de um Browser é fantástica e acho que toda empresa de TV deveria tomar isso como exemplo e pensar em modernizar seus sistemas de atendimento as agências e parceiros comerciais.

Por enquanto, os comerciais do Google estão sendo veiculados em mais de 125 canais via Dish Network, segunda maior broadcaster via satélite dos Estados Unidos. Entre os primeiros a anunciar através da nova plataforma estão nomes de peso como Intel, E*trade, Financial Corp e 1-800-flowers.com Inc

Se vc trabalha em uma empresa de TV este video abaixo é um MUST HAVE.

http://www.google.com/adwords/tvads/

Simplesmente fantástico, mas concordo totalmente Merrill Brown, que foi Editor Chefe do MSNBC.com, quando ele diz que as empresas de mídia tem uma grande barreira quando o assunto é inovação e quando se fala de advertising a barreira é MUITO grande, imagine então quando se fala de advertising na TV.

Merrill comenta o caso do fracasso da startup Backfence.com, site especializado em hyperlocal news:

One of the big reasons why the startup failed is that it did not offer “self service” advertising tools that made it super easy for local companies to create and deploy ads. Instead, Backfence had to rely on a pre-1999 business model of sending a sales force door-to-door in the local communities that it served.

Sem comentários.

Uma situação muito comum no dia a dia de diversas equipes de desenvolvimento de software e como não deveria deixar de ser também acontece aqui na Globo.com, é quando as equipes de marketing ou produto precisam de uma data garantida para o lançamento de um certo projeto, no entanto, estas mesmas equipes se sentem inseguras quando o ScrumMaster esclarece que o time é que vai estimar o que cabe em cada Sprint  e que cada time possui uma velocidade relativa contada em pontos de complexidade. Nessa hora elas entram em um estado de transe e voltam a pedir o que sempre pediram e a trabalhar da maneira como sempre trabalharam, Ken Schwaber chama este reflexo de “Muscle Memory.

Explicando melhor, quando as pessoas estão sobre pressão em um momento em que estão tentando alguma coisa nova (como por exemplo tocar um projeto usando SCRUM), na primeira dúvida que surge elas tendem a querer voltar a fazer as coisas como sempre fizeram, para muitas pessoas é realmente difícil aceitar que o Time é que define a velocidade de entregas, e neste momento elas requisitam alguma coisa que lhes dê uma segurança de que aquele software será entregue com certeza na data definida, é nessas horas que ouvimos o famigerado pedido “Poxa, não dá pra vcs fazerem um Project bonitinho com as datas e tal”, como se um project fosse o certificado de garantia de que o Time vai entregar alguma coisa em alguma data. Eu cada vez mais acredito que cronogramas não funcionam e não tem como garantir nada.

Em uma situação dessas, em que um produto precisa de um determinado set de funcionalidades e onde está se pedindo uma data formal de entrega, uma solução possível seria adicionar uma margem de segurança (ou buffer) nas estimativas para garantir que as estórias do projeto estarão prontas com certeza e, em seguida, verificar quantos Sprints são necessários para realizar esta entrega.

Este buffer é feito usando as estórias e suas estimativas de complexidade, durante o planejamento de um Sprint o Time evolui sua avaliação a respeito da complexidade de implementação das estórias com base no maior esclarecimento que vai acontecendo nas reuniões do Sprint.

Sendo assim podemos presumir que em um primeiro momento, quanto estamos lendo uma estória pela primeira vez, teremos um grau de precisão na avaliação da complexidade relativamente baixo, por exemplo 50%. Conforme as dúvidas e a arquitetura do sistema a ser utilizada são esclarecidos esta precisão aumenta até que no Sprint Planning 1  deve-se ter, idealmente, uma precisão sobre a estimativa de complexidade em torno de 90%. São estes dois dados que vamos utilizar a estimativa com precisão 50% e a estimativa com precisão 90% para calcular o buffer.

Vamos imaginar o seguinte Sprint Backlog com 4 estórias, e que estas foram estimadas pelo time nas reuniões de levantamento de estimativas(50% de precisão) e posteriormente no Sprint Planning 1(90% de precisão).

Com estes dados em mãos agora podemos calcular o tamanho do projeto adicionando o buffer:

 Complexidade do Projeto = Est. 50% + [(Delta)/2]

onde Delta/2 é o buffer.

Usando os números da tabela acima temos que a complexidade do projeto = 28 +(40/2) = 48 e o tamanho do buffer é de 20 pontos de complexidade, ou seja, quanto maior é a diferença entre a primeira estimativa e a estimativa mais precisa (90%), maior será o buffer.

OK, agora que calculamos o buffer podemos calcular quantos Sprints serão necessários para termos certeza de que o produto será entregue contendo estas 4 estórias. Supondo que a velocidade do time seja de 10 pontos de complexidade por Sprint, então vamos precisar de pelo menos 5 Sprints (48/10) para entregar estas 4 estórias com uma boa margem de segurança.

Como os Sprints possuem duração fixa, na Globo.com por exemplo giram em torno de 15 dias, então podemos garantir que em pelo menos 75 dias (15 dias x 5 Sprints) o produto estará entregue com todas as funcionalidades.