Produção

As estatísticas de servidores web liberadas mensalmente pela Netcraft mostram que o servidor livre Apache opera, agora, 1,2 milhões de sites a mais que há um mês.
Isso significa que o servidor web de código aberto está por trás de 176.748.506 dos websites pesquisados, quase metade de toda a amostra. Em segundo lugar na lista está o Microsoft IIS, com uma fatia de 35%, seguido do Google Web Server (GWS) com 6% e do Lighttpd, também de código aberto, com 3% (1,7 milhões de sites).
Segundo a Netcraft, uma nova promessa é o servidor Nginx, de autoria do programador russo Igor Sysoev. Em sua primeira aparição na lista, ele já alcançou o quinto lugar. As estatísticas estão disponíveis no site da Netcraft. O ranking de servidores de agosto está aqui.

==========
Fonte: Linuxnewmedia

Na oscon participei de duas palestras que falavam do uso de XMPP para criação de serviços web. O Etevaldo participou da primeira, e juntos organizamos este post.

As palestras foram “Open Source XMPP for Cloud Services” da Jive e “Beyond REST? Building data services with XMPP PubSub” do Flickr.

Ambas as apresentações estão online:
http://www.slideshare.net/mattjive/open-source-xmpp-for-cloud-services
http://www.slideshare.net/kellan/beyond-rest

Em ambas a indicação do uso de XMPP é para subistituir aplicações que façam HTTP Polling. HTTP Polling é o método que se baseia em requests periódicos a uma url para realizar o sincronismo entre duas aplicações, ou entre o cliente e o servidor. Segundo a apresentação do Flickr, isto seria equivalente a uma criança chata que fica perguntando ao pai de cinco em cinco minutos: “falta muito?” durante uma longa viagem de carro, e simplesmente não escala.

Nos casos em que o perído do polling é pequeno, ou seja, novos requests são gerados em poucos minutos ou segundos, é mais fácil enxegar a fonte de dados como um fluxo contínuo e ao invés de ficar abrindo e fechando conexões HTTP manter uma conexão persistente onde sejam trocadas mensagens. É assim que funciona o XMPP.

Bom ainda não estudei muito de XMPP, além de saber que é um protocolo aberto para “instant messaging” dei apenas uma lida no wikipedia . Acho que é o sufuciente por agora.

O problema encarado pelo Flickr era que o Friendster fazia HTTP Polling para sincronizar as fotos de seus usuários. Isso gerou uma grande volume de acesso no Flickr, que precisava de uma melhor alternativa. A solução do Flcikr foi criar um serviço via XMPP no padrão PubSub, ou seja, O Friendster abre uma conexão com o Flickr e a cada nova foto uma mensagem é enviada do Flickr para o Friendster.

Como se fazer um serviço web usando XMPP?
O que vc precisa fazer é criar um componente de acordo com o padrão XEP-0114 . Felizmente já existem APIs que implementam este protocolo em diferentes linguagens como a Whack API em Java e a gloox em C++ (deve existir para outras linguagens, mas não procurei).

Pelo que entendi do exemplo da Jive, vc vai criar um daemon que vai ficar rodando independente do servidor Jabber e que se conectará ao servidor Jabber, publicando algum tipo de serviço, como o que informa as condições do tempo.

Entre os servidores jabbers mais populares são o openfire (citado pela jive), o ejabberd, e o jabberd (citados no Flickr). Neste site tem um market share dos servidores jabbers, mas acho que não é mto confiável.

Acredito que em breve estaremos testando estes servidores jabber para entender melhor o funcionamento e saber como eles escalam aqui nas equipes de infra, pois provavelmente irão surgir aplicações que se utilizam deste protocolo.

Para o caso da Globo.com, precisamos pensar em como gerar clientes web para xmpp. Existe já uma API em javascript que faz a comunicação com Jabbers. Infelizemente, browsers não implementam o protocolo XMPP e este terá que ser encapsulado em HTTP. A técnica utilizada para isso é o BOSH (Bidirectional-streams Over Synchronous HTTP) da especificação XEP-0124 e com um post explicativo neste site.

Desta forma, as conexões persistentes teriam que ser feitas a um web-server que faria o papel de “proxy” com o servidor jabber???? Não necessariamente, o openfire e o ejabberd implementam bosh e saberiam lidar com “HTTP binding”.

Há também outras intefaces “não web”, por exemplo, que poderíamos utilizar, como a possibilidade de externar a funcionalidade de chat via XMPP, como está sendo feito pelo Facebook.

Antes que este post fique longo demais (já está), vou passar só mais uma referência que é este post interessante que discute pontos levantados na palestra do Flickr: http://redmonk.com/sogrady/2008/07/30/xmpp_rest/

Peço que sinalizem nos comentários caso exista interesse, para que eu possa tentar organizar um workshop para discutir idéias e implementações XMPPs.

Alguns dias atrás estive lendo relatos de pessoas que estavam utilizando o Opera 9.5 e dando suas opiniões a respeito. Todas, sem exceção, foram muito positivas. A maioria elogiava a rapidez e leveza do navegador em abrir páginas, sendo extremamente rápido se comparado ao Firefox 2. Como sempre é bom emitir opiniões a respeito de algo realmente conhecendo-o, me fez baixar o Opera 9.5 aqui no Linux.

Fazendo um ‘background’ sobre o navegador, ele entrou bem silenciosamente no mercado, em meados de 96. Eu lembro de ter ouvido falar dele quando estava já na 3.0, mas fiz o primeiro uso na versão 4, por causa do meu primo que utilizava um 486 na época. Entre Internet Explorer, Netscape e Opera, o Opera era mais leve para ele. O Opera prezava pela simplicidade e pelo menor consumo de memória e processamento, enquanto focava em ser um navegador com funcionalidades simples, porém eficientes. Entretanto, usar Opera naquela época era um desafio. Afinal, nem todas as homepages desenhavam bem neste navegador, já que estávamos entrando em quase 70% de aceitação mundial do Internet Explorer na Internet (e crescendo). No meu uso, fiquei bastante desconfortável. Afinal, você não fazia abertura de uma nova janela de navegação, como você fazia no Internet Explorer. Você abria uma janela interna quando fazia um “new window” e você gerenciava essas janelas dentro do Opera. Um sistema de usabilidade ultrapassado na minha opinião, que lembrava-me o estilo nostálgico de navegação do Windows 3.1. Finalmente, o browser era pago. Oras, porque eu pagaria por um software que não redesenha páginas como eu quero?

Bem, o tempo foi passando e conhecemos a guerra dos browsers, que era travada entre o “Mozilla” (incluem aqui Mozilla Suite, Firefox, SeaMonkey e etc) e o Internet Explorer. O Opera sempre foi um coadjunvante nessa guerra. Apesar disso, isso nunca foi intimidador para a Opera Software, que mudou um pouco mais o foco e procurou fazer um browser que fosse 100% compatível com os ‘web-standards’, algo que a Mozilla Foundation passou a também seguir. Uma coisa muito curiosa entre a Mozilla Foundation e a Opera Software, ao meu ver, é que ambos tinham os mesmos desejos: A simplicidade, a compatibilidade e a interoperalibidade (mais tarde a Opera pensou e assumiu também a gratuidade de seu software). As características que marcavam os softwares da Mozilla tinham no Opera e vice-versa. Pelo menos, sei que o Opera foi o primeiro navegador a utilizar abas de navegação (tabbed-browsing), se não me engano, na versão 6. Pelo menos nunca vi críticas de quem inventou o quê entre usuários, colunistas e das empresas. Aliás, isso pouco importava. Na verdade, o que importava era sempre o anseio de acabar com o império do Internet Explorer através do aperfeiçoamento e promovendo entre os site designers o uso correto de ‘web standards’.

Enfim, vamos falar do software atualmente. A começar, o ‘apt-get’ (instalador de pacotes Debian no Ubuntu) não possui o Opera como opção de download. Algo que pode ser frustrante para um usuário comum de linux. Fui então ao site oficial do produto e baixar a última versão (9.5.2042), baixei o install. um “gunzip -c opera-9.50.gcc4-shared-qt3.i386.tar.gz | tar xvf -” já expandia os arquivo sde instalação. “sudo ./install.sh” para instalar… apontou as recomendações de install e config, deixei default. Achei fabuloso que o Opera colocou seu ícone em “Applications / Internet” e também figura em “System / Preferences / Preferred Applications” como um “browser” selecionável para a abertura de links de internet.

Nos testes, realmente o Opera é extramente rápido. O desenho das páginas que são abertas por mim vem imediatamente. Ao meu ver, parece que ao baixar os elementos como a HTML do site, Js, CSS e os sub-elementos contidos no CSS o Opera decide desenhar a página, enquanto ao mesmo tempo está abrindo conexões extras ao servidor de web para baixar os outros conteúdos variáveis (como por exemplo, a foto de destaque de uma home, um banner em flash e etc). Além disso, o Opera procura e usa os plugins instalados no Firefox e adota-os também para uso, evitando de ter que baixar ou configurá-los na máquina. Infelizmente, o Opera não funciona bem com Gnash SWF, uma alternativa open source do plugin do flash. Isso nem é problema, afinal eu tenho em minha máquina a lib do flash da Adobe (9.0.124) em minha máquina e foi apenas questão de reapontar o plugin, algo extremamente fácil através do menu de preferences do navegador. Uma questão bastante elogiada no Opera é a execução de JavaScrips que eles declaram que é 2x mais rápido. Se é verdade ou não, acredito que é um pouco mais rápido mesmo para utilizar algumas funções JS em certas páginas em que pude testar.

Bem, para não dizer que TUDO funcionou perfeitamente, posso dizer que houveram sim alguns problemas de navegação. O principal problema é com o uso do Flash. Não sei exatamente se há um problema com o Opera ou com o plugin da Adobe, mas sei que em alguns raros momentos o ‘redraw’ de um banner em flash, um player de youtube pode sumir durante o scroll de uma página. Rodando o opera via command-line, eu vejo que o Opera fica cortando a excecução do plugin do flash em suas threads, declarando que o mesmo está ‘hanging’. Bem, posso dizer que no Firefox raramente ocorre do plugin do flash falhar. É mais fácil o navegador consumir mais memória do que cortar a execução do flash. Também tive problemas com o uso do plugin do Totem, aonde ele simplesmente não funcionou. Não tive paciência nem desejo de resolver essa questão. Afinal não curto mesmo ‘embeddar’ telas de video no navegador. Também vi que o Opera não funciona no formulário do WordPress. Simplesmente é impossível clicar na área de edição para escrever algo. Tive que redigir este post através do modo “code” do mesmo.

Finalmente, falando de recursos, achei legal o fato de abrir um ‘new tab’ ele abrir o ’speed dial’. O ’speed dial’ é uma página aonde você coloca suas páginas preferidas em thumbnails, aonde você pode clicá-las e acessá-las. Ele também faz o refresh dessas páginas periodicamente, então você pode ver as páginas e clicá-las para entrar. Possui também sistema de “mouse gestures”, que nem aproveitei porque nunca curti essa feature. O navegador também conta com um sistema de torrent internamente. Logo, se você baixar um torrent na internet o Opera estará usando seu sistema built-in para baixar o arquivo. Se isso é bom ou ruim, acho que fica a gosto. Pelo menos eu acredito que é uma boa feature. O navegador conta com “widgets”, que seria como os ‘extensions’ que existem no Firefox. Eu instalei um para ver a previsão do tempo e gostei. A página do Opera possui diversos widgets, mas como eu gosto de um ‘browser’ puro, preferi ficar com o que ele já me oferece. Ele também oferece sistema built-in de analizar erros de script bem completo. Pelo menos senti que fosse algo similar ao “Firebug”. Pelo menos não achei algo que se assemelhasse ao “Live HTTP Headers” built-in. É o recurso que mais uso para minhas investigações no dia a dia. =/

Acredito hoje que Opera tornou-se um navegador muito maduro, fácil e completo. Recomendo o uso dele, apesar de me apertar o coração. Afinal, ainda amo a Mozilla Foundation…

EDIT: Esqueci de informar aos leitores que o Opera foi um dos primeiros navegadores a passar do Acid Test 2, o famoso teste de compatibilidade dos browsers com padrões web de desenho de páginas. Ele fez isso antes mesmo do Firefox 3, que conseguiu essa marca neste ano, enquanto o Opera fazia isto desde 2006. Quanto ao Acid Test 3, o Opera consegue um satisfatório resultado de 83/100, três pontos a frente do Firefox 3. Os resultados da Microsoft com o Internet Explorer com Acid 2 e Acid 3? Praticamente um vexame.

EDIT2: Esqueci também de comentar dois fatos. O primeiro é que o recurso de widgets é poderoso. O que eu gostei de usar é o de weather. O segundo fato é que o Opera é o browser utilizado pelo videogame Nintendo Wii para navegar pela internet.

Jon Wiley, User Experience Designer do Google, relaciona alguns dos mais importantes princípios para o design de interfaces do Google. Em sua apresentação no WritersUA conference, Jon apresentou as seguintes linhas de ação:

1. Useful: focus on people - their lives, their work, their dreams.
2. Fast: every millisecond counts.
3. Simple: simplicity is powerful.
4. Engaging: engage beginners and attract experts.
5. Innovative: dare to be innovative.
6. Universal: design for the world.
7. Profitable: plan for today’s and tomorrow’s business.
8. Beautiful: delight the eye without distracting the mind.
9. Trustworthy: be worthy of people’s trust.
10. Personable: add a human touch.

Na informática, não existem competições entre empresas sobre um produto ou serviço. Existem guerras. Guerras porque, muitas vezes, não são competições honestas que ocorrem no mercado. E não há guerra tão bem acompanhada e ressurgida como a guerra dos browsers, aonde ela chega em sua terceira edição. Alguns vão dizer: “Terceira edição?! Pois eu acho que esta é a segunda!” Pois eu acho que não. Vamos recordar cada uma delas:

A primeira guerra dos browsers começou no início da internet, com o Netscape com o Navigator ou a suíte completa chamada Communicator; e a Microsoft vinha com o Internet Explorer com Internet Mail, quase que compulsóriamente aposentado com a entrada do Outlook Express. Todos nós sabemos o resultado do fim dessa guerra: A vitória foi da Microsoft, que já atingiu 95% de utilização deste browser no mundo inteiro. A empresa Netscape, cambaleada, foi comprada pela AOL que apenas sepultou a marca.

O segunda guerra de browsers começou com a ameaça fantasma de ex-desenvolvedores da Netscape, que criaram a Mozilla Foundation e começaram, do zero, a reprogramação do browser Netscape, rebatizado de Mozilla (devido ao nome-código que era dado ao Netscape). Incialmente com o Mozilla Suite, que procurava ser compatível com os padrões definidos pela W3C e outros tipos de padrões, ao invés de inventar padrões e redesenhar páginas ao seu modo, como ocorreu e muito com o Internet Explorer. Eu, que embarquei bem no início dessa nova geração ao utilizar o Mozilla Suite ainda na versão 0.4, era realmente difícil e desprazeroso utilizar a web usando um web-browser que não possuia compatibilidade nenhuma com site algum. Entretanto, com o maior amadurecimento do Gecko (o novo motor de redenrização que a Mozilla Foundation criou para seu browser), os sites passaram a ser melhor redenrizados, passou a ser mais compatível e, progressivamente, os sites passaram ser melhor formulados quanto a interoperabilidade. Ainda assim, o Mozilla Suite era apenas um patinho feio usado apenas por xiitas, masoquistas e/ou entusiastas de Netscape. Quem iria querer um programa que era lento para iniciar, feio para usar e que era apenas ligeiramente rápido para navegar do que o Internet Explorer? Talvez inspirado por esses e outros desejos é que a Mozilla soltou um novo browser com o nome de Firebird, nome que apenas durou quase 1 ano e teve que ser trocado, visto que causava conflito com um sistema de banco de dados. E, assim, nasceu Firefox. Um browser de interface amigável, mais rápido para iniciar, mais rápido e mais seguro. Essa guerra boa parte das pessoas de hoje conhecem e vivenciam. Não é raro mais encontrar alguém que realmente largou o Internet Explorer de suas vidas. O maior movimento para a Microsoft em combater o avanço do Firefox veio no Internet Explorer 7, quase que três anos depois do lançamento do Internet Explorer 6. Tão amigável quanto o Firefox, tão seguro quanto o Firefox e tão rápido quanto ele, que conseguiu aceitação pelo público.

Ok, então aonde está a terceira guerra? A terceira guerra está por vir, com Internet Explorer 8 e com Firefox 3. Ambas produtoras estão interessadas cada vez mais em ser compatíveis com qualquer tipo de site, ambas anseiam um objetivo comum: Ser 100% compatível com padrões web já estabelecidos e passar do famigerado teste do Acid2, hoje triunfo alcançado apenas por alguns navegadores, como o Safari da Apple e o Opera. Mas o que tem o Acid2 a ver Firefox e Internet Explorer? Porque cada vez mais está tendo uma revolução por parte de desenvolvedores de site a adotar desenvolvimento de site através de padrões de web para que qualquer navegador possa utilizá-lo, diferente de fazer algo que só funcione no Internet Explorer. Afinal, a adoção por diferentes navegadores de internet ocorrem, a adoção de outros sistemas operacionais crescem (como o Mac OS e o Linux) e é importante para os desenvolvedores de site procurarem ter seus sites funcionais para qualque um.

A terceira guerra dos browsers, que está ainda para estrear, tem sido bastante interessante, tendo tantos alvoçoros que parece até um pré-início de Big Brother Brasil, com participantes saindo e participantes entrando antes do programa começar. É o que tem sido nessa nova guerra. O que seria exatamente isso? Inicialmente, no lado da Microsoft, existem dois dilemas para ela: Esquecer o presente para um novo futuro ou tentar manter o presente e tentar encaixar o futuro? Do que conheço da Microsoft, ela pratica a segunda opção. Por isso, o novo IE conseguiria redesenhar sites criados para IE6 e IE7 mas também funcionaria no Acid2. Ela achou isso um pouco difícil. Qual foi a solução? Partir para a minha primeira opção, que é esquecer o presenter e pensar no futuro. Ela fez isso quando informou a intenção de criar um sistema de tags que os desenvolvedores precisavam criar em suas páginas para informar algo como “redenrize para Internet Explorer 8″. Assim, quando um usuário de browser de IE8 acessasse essa página, o IE8 automaticamente assumiria uma nova forma de redenrizar páginas, que seria no novo conceito de páginas usando padrões web. Um usuário de versões anteriores não sentiria diferença. A idéia, apesar de ser uma solução bastante interessante, foi altamente criticada por vários meios de notícias, blogs e empresas rivais, como a Google. Afinal, se existem algumas resistencias por parte de desenvolvedores em criar sites que funcione para todos, é criado um novo browser que ainda trabalhe de forma não-padrão, quem pensaria em gastar seu tempo redesenvolvendo tudo pensando em padrões de web? Nenhum.

A Fundação Mozilla, que toca o projeto do Firefox 3, está também alvejando a compatibilidade do Acid2. Apesar de não conseguir hoje passar do teste, é um dos browsers que mais chega-se perto disso se compararmos com o Internet Explorer atualmente. E como a cada versão da engine Gecko tem impressionado cada vez mais os desenvolvedores e usuários, é esperado que este seja um browser que ganhe mais espaço de market sharing, que hoje possui quase 20% de market-share.

Ok, apesar disso tudo, todos se perguntam: Qual a importância disso? O que isso muda no meu cotidiano? Talvez, para o seu não importa no momento. Afinal, muitas pessoas são conformadas em usar o Windows e o Internet Explorer. Entretanto, como cresce cada vez mais o uso da web em diversos tipos de dispositivos e sistemas operacionais, não seria interessante que eles funcionassem perfeitamente neles também? Por exemplo, não seria ótimo se através do iPhone acessar o G1 e visse da mesma forma que você vê no seu computador? Caso utilize um videogame como o Wii, usasse o browser Opera que existe nele e acessar o GloboEsporte, não gostaria que ele aparecesse certinho? Caso compre um MacBook, não acharia fantástico em poder acessar os Vídeos da Globo da mesma forma como você vê no PC? Pois é isso que a terceira guerra dos browsers veio proporcionar, além da antiga competição do market share. Nos próximos anos, teremos sites melhores desenvolvidos que funcionarão em qualquer plataforma, sem medos e sem desapontamentos. Será algo como preza a tecnologia Java, agora para sites: “Write once, run everywhere”.

ATUALIDADES: Hoje, lendo o Slashdot, vi um article aonde um camarada hospeda o arquivo de teste do Acid2 num webserver local e, usando o IE8 num server local, ele falha na redenrização do Acid Test 2. No Blog do time de desenvolvimento do IE8, já se prontificou a respeito e dando uma excelente explicação.

O hulu tenta ser mais um dos concorrente diretos do YouTube e estréia seus serviços hoje dia 12. São mais de 250 séries de TV (algumas completas) a disposição dos usuários, além de filmes. O site de vídeos é uma iniciativa conjunta da NBC Universal e da News Corp. , e deve incorporar a programação do canal de TV Time Warner, da Lions Gate Entertainment e de grupos de esporte, como a Associação Nacional de Basquete e a Liga Nacional de Hóquei. Meu primeiro contato com o site não poderia ser pior, pois nas 3 tentativas de assistir a algum vídeo, o primeiro um filme (Ice Age), o segundo a série Simpsons e o terceiro os 10 melhores lances da NBA, recebo a seguinte mensagem: Unfortunately this video is not currently available in your country or region. Nem perdi meu tempo em ler termos de uso do site e só Deus sabe quando eu voltarei a visitá-lo.

YouTube começa a testar vídeos em high definition. Abaixo screenshots do vídeo com a opção para “watch this video in higher quality.” Os screenshots são do mesmo frame de vídeo para melhor comparação.

Normal Quality

High Quality

Do Wikipedia:

“CAPTCHA é um acrônimo para “Completely Automated Public Turing test to tell Computers and Humans Apart” (teste de Turing público completamente automatizado para diferenciar entre computadores e humanos) desenvolvido pela universidade do Carnegie-Mellon.”

Ou seja, são estas imagens que utilizamos para evitar robôs nos sites. Li hoje um post sobre isso em um blog que entre outras coisas fala de outras alternativas de CAPTCHAs que estão em pesquisa com este elaborado pela Microsoft que trabalha com diferenciar gatos e cachorros e este da carnegie-mellon que propões a escolha e uma palavra que esteja relacionada as imagens.

Documento traduzido, indica as 10 vulnerabilidades mais críticas em aplicações WEB. Descreve as vulnerabilidades, o motivo da gravidade, coloca exemplos de ataque. Tudo de forma bem didática.

Leitura OBRIGATÓRIA para desenvolvedores web, e para quem trabalha com suporte/segurança das aplicações

Fonte:

http://www.owasp.org/images/4/42/OWASP_TOP_10_2007_PT-BR.pdf

O Pentaho é uma plataforma bastante completa de BI de código aberto. Sua arquitetura a primeira vista pode parecer um pouco complexa pela quantidade de recursos, mas sua estrutura modular facilita o entendimento. Vou tentar explicá-lo em poucas palavras aqui.

Outra grande qualidade do Pentaho é a grande quantidade de documentação disponível no site http://www.pentaho.com/index.php e também de uma comunidade razoável de usuários, inclusive no Brasil.

E para que isso serviria para a tecnologia da Globo.com???

Hoje temos uma grande quantidade de informações geradas em diferentes bases (webdesk, jira, sme, métricas, banners, etc). Estas informações precisam ser consolidadas, relacionadas e analisadas. Isso fica ainda mais importante com a introdução de métricas com o projeto QUATI. O Pentaho seria a ferramenta ideal para atender a estas necessidades.

Para explicar como isto funcionaria, vou pegar um exemplo simples e fazer um overview. Imagine que seja objetivo da Globo.com entender a influência dos incidentes na audiência e receita da Globo.com.

A primeira coisa a ser feita e integrar os dados. Isto é feito através de uma ferramenta do tipo ETL ( Extraction, Transformation and Loading) chamada Kettel. Nesta ferramenta é possível determinar as diferentes fontes de dados e métodos de transformação e carga. Ou seja, através delas configuraríamos como importar os dados do webdesk e do banco de métricas (não sei como isso seria possível).

Com as fontes de dados configuradas temos que definir como queremos enxergar estes dados. Este modelo é criado através de um cubo OLAP (On-line Analytical Processing) que representa os diversos “cortes” interessantes de uma análise. A ferramenta para isso no pentaho é o Mondrian. No exemplo poderíamos criar o cubo de análise com dimensões de dia da semana, produtos (g1, esporte, entretenimento) e duração e métricas de número de incidentes, duração média e audiência.

Por fim, podemos criar relatórios ou dashboard automáticos sobre todos estes dados gerados. Estes relatórios são na verdade páginas web com gráficos gerados automaticamente sobre os dados. Um exemplo a seguir: