Olá galera, bom como vocês devem ter percebido fiquei um bom tempo sem alimentar esse blog, acredito que o motivo maior para que isso tenha acontecido foi perceber que não é tão simples como eu imaginei manter um blog atualizado.
Vários acontecimentos me levaram a deixar a atualização do Blog de lado mas ao mesmo tempo eu sempre tinha aquela vontade de compartilhar momentos e coisas que eu aprendia ao longo do tempo. “Tempo” esse sempre me tirava de cena quando a ideia era atualizar o blog.
E pensando nisso outro dia falando com um colega de trabalho, eu reclamei que não tinha tempo de atualizar meu Blog e que tinha deixado a atualização do Blog de lado e ele me disse – “Cara, sempre tem alguém com o mesmo problema que você, mas mesmo assim os blogs estão todos por aí atualizados.” isso me levou a entender que todos sofrem de falta de tempo, o jeito é reorganizar e priorizar algumas coisas.
Muita coisa mudou, desde última vez que postei, hoje eu não trabalho mais na CUT “Central Única dos Trabalhadores”, entidade qual eu tenho muito orgulho de ter feito parte da equipe de comunicação.
E até chegar onde estou atualmente, em umas das equipes do Apontador “O maior site brasileiro de anúncio de locais, estabelecimentos”. “Merchandising” [detected] 
Tive oportunidade de trabalhar com equipes onde pude aprender muito, como na WebPesados, e fazer parte dessa equipe foi de grande valor para mim, e é evidente que foi pelo nível técnico que tal equipe possuía, pois trabalhar com @lucashungaro, @shiota, @fabianoleittes, @fnando foi de grande avalia para mim.
Hoje, estou tocando um projeto no Apontador que eu ainda não posso revelar por motivos de contrato mas logo postarei coisas sobre este projeto.
Sinceramente, tempo não é algo que esteja sobrando mas eu farei o possível para deixar o Blog o mais atualizado, abraços e até o próximo post.
Olá Pessoal!!!!!
Esse post é apenas para explicar porque eu estou sumido.
Bom, como alguns já sabem, eu sou desenvolvedor full-time na CUT Nacional.
Continuo trabalhando com plataforma Ruby (Ruby on Rails,) e agora começando meus estudos com desenvolvimento iOS e Android.
Sobre o blog, estou com alguns posts escritos pela metade sobre Resque , Newsletter (E-mail Marketing ), que ainda faltam terminar. Mas com alguns novos projetos eu fiquei sem tempo pra dar continuidade.
O que eu tenho feito:
Em um mega resumo, tenho trabalhado em um sistema de Newsletter centralizado que já está em produção. Em um backend para uma App de rádio para iPhone e iPad e um cliente de Webservice em PHP.
Espero em breve voltar a postar e procurar aumentar a frequência dos posts.
Poucos dias atrás, o Google anunciou que estava abandonando o suporte para o codec de vídeo H.264 em seu popular navegador, o Chrome. Hoje vamos dar uma olhada nas ramificações atuais do vídeo na web.
Um pouco de história
Graças às conexões de internet rápida e os custos de banda larga caindo rapidamente transmitir vídeo através da Internet se tornou bastante popular. Diante disso, a reprodução de vídeos na web manteve-se como um caso extremamente confuso. Houve uma confusão de codecs e containers para lidar com o conteúdo. Esse vazio foi preenchido por três soluções: Windows Media, QuickTime e Real Media, que rapidamente tomaram conta de todo o mercado. Poucos esperavam que o trio seria destronado tão cedo. E, no entanto, foi o que aconteceu, por volta de 2005 o vídeo Flash dominou completamente o mercado de vídeo web e streaming, praticamente fazendo os outros players desaparecem. Os outros players ainda estão vivos , claro, mas por muito tempo Flash vídeo foi praticamente a única maneira, compatível e fácil de reproduzir o conteúdo de streaming em uma página web.
Apresentando o elemento de vídeo HTML 5
Sublime Player foi um dos pioneiros
Os desenvolvedores de todo o mundo reconheceram o buraco que o Flash expôs na especificação HTML e criaram o HTML5 spec para preencher esse vazio. A web precisava de um player de primeira classe para o vídeo, bem como para imagens que os navegadores pudessem desempenhar de forma nativa, sem ter de recorrer a um plugin, seja ele Flash, Silverlight, Quicktime, ou qualquer outra coisa. E assim, o elemento de vídeo nasceu. HTML5 define uma forma padrão para conteúdo de vídeo incorporar em seus sites: através da tag de vídeo. O suporte para este padrão, tanto entre os navegadores e distribuidores de conteúdos, como YouTube e Vimeo, vem aumentando a um ritmo acelerado Aqui é quando as coisas ficaram um bocado perigosas. A especificação HTML5 não determina quais os formatos de vídeo ou codecs que o navegador deve apoiar através da tag de <vídeo>. Cada fabricante de browser é livre para escolher e apoiar qualquer formato que considere adequado. Ogg Theora foi inicialmente o precursor para o formato de vídeo padrão, mas depois foi retirado a partir da especificação, substituído por especificações mais vagas. Atualmente, hoje existem três codecs que estão disputando sua atenção:
H.264
VP8
Theora
Vou falar sobre os codecs mais relevantes: H.264 e VP8. O Theora, não está realmente na corrida para a liderança, então vou ignorá-lo.
H.264
H.264, também popularmente conhecido como AVC, foi desenvolvido com colaboração e esforço de uma série de grupos, incluindo o famoso MPEG. É atualmente um dos codecs mais avançados tecnicamente disponíveis e oferece melhor qualidade de quadro em uma taxa de bits muito menor. Para os não técnicos, você tem qualidade superior em tamanhos de arquivo muito menor. Esta é a principal razão pela qual o H.264 é usado em um grande número de lugares, e sendo chefe entre eles. Além da qualidade, o H.264 tem uma série de outros benefícios. O conteúdo compactado com este codec pode ser reproduzido por uma série de dispositivos não PC. Roda em um iPhone? Sim, você pode assistir o conteúdo H.264. Roda no console de jogos (vídeo Game)? Claro que sim! Outro ponto a salientar é que muitos desses dispositivos têm hardware dedicado para decodificar este tipo de conteúdo.
O VP8
WebM
VP8, um codec relativamente novo, é uma ideia da On2 – os mesmos caras que estão por trás do Theora. O Google adquiriu On2, em 2010, e abriu todas as patentes de base do codec para o domínio público. WebM, o recipiente de escolha para a maioria dos navegadores atuais, utiliza VP8 para comprimir o conteúdo de vídeo e o Vorbis para o áudio. Produz conteúdo semelhante em qualidade ao H.264. E melhor, é completamente livre, agora e para o futuro. Em desvantagem, no entanto, tem a limitação para encontrar hardware dedicado para decodificação em dispositivos moveis.
Decisão do Google de remover o suporte ao H.264
Como mencionado no trecho, o Google removeu recentemente o suporte para H.264 a partir do navegador Chrome. Isso gera uma sinuca de bico, dado o crescimento do H.264 entre os vídeos na Internet e deixa o Internet Explorer e Safari como os únicos navegadores remanescentes apoiando o codec.
Declaração do Google abaixo:
Esperamos por uma inovação mais rápida na plataforma de mídia da web no próximo ano e então concentraremos nossos investimentos em tecnologias que são desenvolvidas e licenciadas com base nos princípios da web aberta. Estamos mudando o apoio da tag <video> do HTML5 no Chrome para torná-lo compatível com os codecs já apoiadas pelo projeto Chromium de código aberto. Especificamente, estamos apoiando a WebM (VP8) e codecs de vídeo Theora, e irá considerar a adição de suporte para outros codecs de alta qualidade e de códico aberto no futuro. Embora o H.264 tenha um papel importante , como nosso objetivo é permitir que a haja inovação no código aberto, o suporte para o codec serão removidos e os recursos serão dirigidos para tecnologias completamente aberta.
A decisão do Google:
Vamos dar uma rápida olhada em algumas perguntas que você pode potencialmente ter.
Por que a súbita mudança de codec agora ?
As questões de licenciamento e royalties. H.264 requer royalties para cenários específicos, enquanto VP8 e Theora estão completamente abertos.
Ouvi dizer que o H.264 é livre para um grande número de utilizações, existe mais do que isso?
Embora atualmente livre, se o conteúdo é distribuído gratuitamente, não é imutável. Lembre-se que MP3 também tinha licenças bastante liberais no início. Então, algo que é gratuito hoje pode não ser necessariamente assim amanhã. Não há problemas desse tipo com VP8.
Será esta uma forma do Google de tentar controlar o formato de vídeo que a web utiliza?
Na verdade, não. WebM já é suportado pelo Opera e Firefox [próximas versões]. Também é apoiada por uma boa parte da comunidade web. É muito mais uma questão de abertura do controle.
E se o Google torna-se subitamente mal e começa a cobrar royalties?
VP8 está sob uma licença BSD. É também sob uma licença de patente irrevogável livre. Este é o mais próximo que você pode obter gratuitamente.
Então eu posso usar plugins para assistir ao conteúdo H.264?
Absolutamente, através do Flash ou Silverflight ou qualquer navegador que você tenha.
O Google já encorpora pacote Flash, em sua plataforma fechada. Lógica ou fracasso?
O player, não necessita de royalties. Na verdade, você pode levar o caderno de encargos e criar seu próprio player. Chrome só vem com o Flash para uma logística mais fácil.
H.264 está em toda parte, goshdarnit!
Com certeza é. Mas eu acredito que um codec deve ser escolhido, com base no mérito e licenciamento.
Mas, mas, meus vídeos estão todos no formato H.264. Ter que codificá-lo com outro codec vai dar muito mais trabalho.
Você provavelmente já comprimiu antes de enviá-lo para o serviço de vídeo de sua escolha. Por que simplesmente não comprimi-lo com o formato VP8 agora?
Por que remover o suporte para H.264 agora?
Google pode dar ao luxo de fazer uma mudança aqui e evitar o monopólio H.264 no futuro.
O que isto significa para um usuário comum
Em seu ambiente nada muda. É apenas um bando de nerds falando de coisas que você não pode sequer vagamente compreender. Se você é um usuário móvel, no entanto, você está em um mundo de problemas. Com a maioria das plataformas móveis bloqueadas, a padronização dos navegadores móveis é algo quase impossivel de acontecer.
Como foi muito comentado e esperado, o Google liberou no dia 03 de Novembro 2010 o mod_pagespeed, um módulo para o Apache2 que promete aumentar a velocidade de páginas web.
E como eu já tinha falado em um post anterior sobre o livro de Steve Souders, em que ele mostra 14 boas praticas para otimização do FrontEnd também vou falar neste post sobre esse novo módulo que será uma mão na roda para quem quer seguir as 14 regrinhas básicas de boas práticas de desenvolvimento.
O Módulo lançado pelo Google faz exatamente todo o trabalho sujo sem muita dor de cabeça para o desenvolvedor. A grande sacada é utilizar o Apache do lado do servidor para executar todo esse trabalho.
O módulo ainda está em uma versão beta e já possui pacotes pré-compilados para Debian e Ubuntu.
Venho acompanhando em grupos de desenvolvimento muitas discussões sobre o consumo de carga que o módulo pode trazer ao servidor em produção. Em meus testes com Apache Benchmark, o mod_pagespeed se comportou de forma muito estável, e o consumo de processador e da memória foram satisfatórios para o meu ambiente.
Para os Rubistas de plantão posso dizer que como já era de se esperar a integração entre Passenger e mod_pagespeed foi perfeita não percebi problema algum em minhas aplicações mas é bom ficar ligado nos de testes de Javascript.
Vou descrever aqui em poucas linhas a simplicidade de instalação e integração do mod_pagespeed em um ambiente Debian/Linux.
Baixando o pacote:
wget https://dl-ssl.google.com/dl/linux/direct/mod-pagespeed-beta_current_i386.deb
Instalando:
dpkg -i mod-pagespeed-*.deb apt-get -f install
Habilitando o módulo:
a2enmod pagespeed
Restarte o Apache para que as novas configurações sejam aplicadas.
Agora só abrir o arquivo de configuração com seu editor preferido e adicionar o comportamento desejado.
vim /etc/apache2/mod-enabled/pagespeed.conf
Não vou adicionar todos recursos vou mostrar os que eu achei mais produtivos.
Veja a lista:
ModPagespeedEnableFilters add_head
Que adiciona um elemento “head” no documento se não existir . E vários outros filtros já ativam isso automaticamente, mesmo se não for especificado explicitamente.
ModPagespeedEnableFilters combine_css
Combina várias chamadas de css em um único arquivo reduzindo as requisição http.
ModPagespeedEnableFilters rewrite_css,rewrite_javascript
Reescreve arquivos CSS e Javascript removendo comentários e espaços em branco.
ModPagespeedEnableFilters rewrite_images
Otimiza imagens, removendo pixels em excessos que não serão exibidos.
#ModPagespeedEnableFilters remove_comments
Remove comentários no próprio html (Desligado na configuração padrão)
# ModPagespeedEnableFilters collapse_whitespace
Remove espaços desnecessários (Desligado na configuração padrão).
ModPagespeedEnableFilters elide_attributes
Remove os atributos que não são significativas de acordo com a especificação HTML. (Use com Cuidado)
ModPagespeedEnableFilters extend_cache
Encontra todas as imagens, css, javascript e outras que estão publicamente cacheadas há menos de um mês e estende sua vida útil para 1 ano.
Isto adiciona um conteúdo Hash na URL de modo que se o conteúdo muda a URL irá mudar,
e Vamos saber o comportamento de cache desejado.
A documentação do mod_pagespeed é de fácil intendimento, e pode ser lida aqui Documentação (em inglês).
Lá vai uma dica rápida e como o tempo está curto vou ser breve nesse Post. 
Algo sempre cheira mal quando eu abro o arquivo database.yml das minhas aplicações Ruby On Rails.
Uma certa duplicação de código deixa o código fonte um pouco fora do conceito de DRY — “Don’t repeat yourself” e pensando nisso fiz uma modificação no arquivo database.yml o deixando um pouco mais DRY.
Veja como o código ficou mais bonito.
Criando conexao de estrutura dinamica
login: &login
adapter: mysql
encoding: utf8
reconnect: false
database: blog_development
pool: 5
username: usuario
password: senhasecreta
socket: /tmp/mysql.sock
development:
<<: *login
database: blog_development
test:
<<: *login
database: blog_test
production:
<<: *login
database: blogproduction</pre>
Esse post é uma continuação do post Bit.ly função para encutar URL com PHP, cURL e Json que eu escrevi ontem no sentido que,
esse fonte faz a mesma coisa, encurtar Url’s dinamicamente.
A Pedido do meu grande amigo Rafinha reescrevi algumas linhas em outra linguagem e agora usei o Ruby.
O fonte é um pouco mais simples que o original em PHP mais a ideia é a mesma
Confira o Fonte:
# Criar URLs reduzidas
# @author Eder Eduardo <eder.esilva@gmail.com>
# @version 0.0.1
# @param string url parametro com a URL original
# @return string retorna a url reduzida pelo bit.ly
require 'rubygems'
require 'json'
require 'net/http'
require 'uri'
def BitUrl (url)
user = 'ederesilva' # Usuário do bit.ly
key = 'R_15280c78606271f4da96eef8523e63ef' # Code key
format = 'json' # Técnilogia usada
version = '2.0.1' # Versão do fonte
api = "http://api.bit.ly/shorten?version=#{version}&longUrl=#{URI.encode(url)}&login=#{user}&apiKey=#{key}&format=#{format}"
#Faz a requisição na variável api
response = Net::HTTP.get_response(URI.parse(api))
data = response.body
result = JSON.parse(data)
# Verifica se a conexão foi bem sucedida
status = result['statusCode']
if status == "OK" then
return result['results'][url]['shortUrl']
#Caso ocorra algum erro mostra a messagem de erro
else
print "Não foi possivel abrir o bit.ly verifique os dados de acesso."
end
end
# Exemplo de como usar a função. #
link = "http://edereduardo.wordpress.com"
urlshort = BitUrl(link)
puts urlshort
Surgiu um pedido muito interessante da Mariana Riccio @mricciof, responsável por cuidar de rede social aqui no trabalho.
A idéia é simples, usar um encurtador de URL (shortUrl) automatizado para facilitar a proliferação de conteúdo na rede.
Para quem não conhece encurtado de URL faz o serviço de converter URLs gigantescas em URLs menores, de 20~25 caracteres.
Com a demanda no colo seguimos a procura de uma solução rápida, eu já utilizo o bit.ly como encurtador de URL e por sorte a documentação do bit.ly é muito boa e de fácil intendimento, que pode ser lida aqui API (em inglês).
Para automatizar a criação de Url’s menores eu criei uma função em PHP bem simples.
E intuitivamente pensei em utilizar a biblioteca cURL do PHP5 mas na construção da código eu me lembrei que a biblioteca cURL precisa ser instalada e habilitada para funcionar e alem disso, pode acontecer do seu provedor não ter o cURL instalado.
E pensando nisso que surge a idéia de usar a função file_get_contents(); junto com a Biblioteca cURL.
Confira o fonte:
/**
* Criar URLs reduzidas
*
* @author Eder Eduardo eder.esilva@gmail.com
* @version 0.0.1
* @param string $url parametro com a URL original
* @return string retorna a url reduzida pelo bit.ly
*/
function BitUrl($url)
{
// Variaveis de acesso a Bit.ly
$user = 'ederesilva'; // Usuário do bit.ly
$key = 'R_15280c78606271f4da96eef8523e63ef'; // Código key
$format = 'json'; // Tecnologia usada
$version = '2.0.1'; // Versão do fonte
//Criando uma url
$api = 'http://api.bit.ly/shorten?version='.$version.'&longUrl='.urlencode($url).'&login='.$user.'&apiKey='.$key.'&format='.$format;
// Verifica se existe o cURL habilitado no servidor
$curl = (bool) function_exists('curl_init');
// Verifica se a biblioteca cURL existe e se está habilitada no php.ini
if ($curl ) {
// Caso exista, usa o cURL para fazer a requisição na variável $api
$ch = curl_init($api);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
$response = curl_exec($ch);
curl_close($ch);
//Converte a string para minusculas
if( strtolower($format) == 'json'){
// Decodifica o resultado Json
$json = @json_decode($response,true);
// Verifica se a conexão foi bem sucedida
$status = $json['statusCode'];
if($status =='OK'){
return $json['results'][$url]['shortUrl'];
// Caso ocorra algum erro mostra a messagem de erro
} else{
echo "Não foi possivel abrir o bit.ly verifique os dados de acesso.";
}
}
// Se a biblioteca cURL Falhou usa file_get_contents
} else if (!$curl) {
//faz a requisição na variável $api usando file_get_content
$response = file_get_contents($api);
//Converte a string para minusculas
if( strtolower($format) == 'json'){
$json = @json_decode($response,true);
// Verifica se a conexão foi bem sucedida
$status = $json['statusCode'];
if($status =='OK'){
return $json['results'][$url]['shortUrl'];
// Caso ocorra algum erro mostra a messagem de erro
} else{
echo "Não foi possivel abrir o bit.ly verifique os dados de acesso.";
}
}
}
}
/* Exemplo de como usar a função. */
$link = "http://edereduardo.wordpress.com" ;
$shorturl = BitUrl($link);
echo $shorturl ;
?>
Como podem perceber o fonte é bem simples e funcional lembrado que para usar a API do http://bit.ly é necessário criar uma conta no site.
