Vejamos como tocar o nosso jazz.mp3

<audio id="mp3" src="jazz.mp3" type="audio/mpeg" controls/>

Apenas esta tag vai gerar um pequeno player com controles customizados pelo browser. E como saber que a musica parou? Basta escutar pelo evento ended

var mp3 = document.getElementById('mp3');
 
mp3.addEventListener('ended', function(){ 
	alert("fim"); 
});

Para customizar os controles basta omitir o atributo controls na tag audio e usar os métodos play e pause, por exemplo.

Um bom exemplo pode ser encontrado aqui:
http://ajaxian.com/archives/html5-media-support-video-and-audio-tags-and-scriptability

E documentação sobre html 5 vc encontra aqui:
http://www.w3schools.com/html5/html5_reference.asp

A tag video segue a mesma idéia, mas será assunto para um próximo post.

Porém como saber que a musica acabou? A classe sound possui um listener para o evento COMPLETE porém isto é para completar o donwload da musica, não o final da mesma. E ai, comofas/

Simples: o método play retorna uma instância SoundChannel que, por sua vez, possui um listener para o evento SOUND_COMPLETE, logo bastaria fazer

var snd:Sound = new Sound();
snd.load(new URLRequest("jazz.mp3"));
var channel:SoundChannel = snd.play();
channel.addEventListener(Event.SOUND_COMPLETE, 
      soundCompleteHandler);
 
private function soundCompleteHandler(e:Event):void{
  /* insira aqui o que deve fazer quando a musica acabar */
}

If you are interested in how the segmenter works you can find out more on how to use libavformat at the following resources: an older libavformat tutorial, some sample libavformat code, How to Write a Video Player in Less Than 1000 Lines, and more sample libavformat code.

Ora… não pensei duas vezes e cliquei no link sobre escrever um video player, curioso que sou. É um tutorial bem proveitoso,
que ja dá frutos na primeira lição. Deixo aqui um pequeno exemplo que analisa arquivos de video e informa dados do codec de cada stream (audio, video e o que mais tiver la dentro).

#include <libavcodec/avcodec.h>
#include <libavformat/avformat.h>
 
int main(int argc, char **argv){
   int i;
   char buf[256];
   AVFormatContext *pFormatCtx;
 
   av_register_all();
 
   while(*(++argv)){
     printf("analisando arquivo '%s'\n",*argv);
     if(av_open_input_file(&pFormatCtx, *argv, NULL, 0, NULL)!=0 || 
	av_find_stream_info(pFormatCtx)<0){ 
		puts("nao foi possivel analisar este arquivo!");
		continue;
	}
     for(i=0;i<pFormatCtx->nb_streams;i++){
	avcodec_string(buf, sizeof(buf), pFormatCtx->streams[i]->codec, 0);
	printf("\tstream[%d]=%s\n",i,buf);
     }
   }
 
   return 0;
}

Para compilar basta adicionar a libavcodec e a libavformat (apt-get nelas).

gcc -lavformat -lavcodec -Wall a.c

A execução é simples:

$ ./a.out *
analisando arquivo 'teste.bin'
	stream[0]=Video: wmv2, yuv420p, 320x240
	stream[1]=Audio: mp3, 48000 Hz, stereo, s16, 128 kb/s

Não apenas voltei a programar em C (que é uma delícia) como produzi um executavel bem enxuto (12 k) e util para determinar os codecs presentes em dado arquivo. Divertido. Vamos ver o que é possivel fazer agora.

Olhando no CHANGELOG na versão que estavamos acostumados a usar o correto era fazer :string => “mensagem que veio no ‘body’” ,entretanto nas versões mais atuais isso foi substituido por :body => ‘tcharam’ … e é este exemplo que esta no site. Como isso quebra o backward compatibility, foi documentado no changelog mas passou despercebido. É claro que a versão mais antiga não vai funcionar que nem a nova.

Se tentassem executar os testes antigos no fakeweb 1.2.4 receberia
esta exception:

Deprecation warning: FakeWeb’s :string option has been renamed to :body.
Just replace :string with :body in your FakeWeb.register_uri calls.

Este é um exemplo onde mudar a forma como utilizamos uma biblioteca ou qualquer software causam todo o tipo de problemas quando não prestamos atenção a todos os detalhes.

irb(main):001:0> require 'rubygems'
=> true
irb(main):002:0> require 'fakeweb'
=> true
irb(main):003:0> FakeWeb.register_uri(:get, 'http://google.com', :body
=> 'google')
=> [#<FakeWeb::Responder:0xb78290a8 @uri="http://google.com",
@options={:body=>"google"}, @method=:get, @times=1>]
irb(main):004:0> HTTParty.get('http://google.com')
=> nil
irb(main):005:0> x = HTTParty.get('http://google.com')
=> nil
irb(main):006:0> x.code
=> 200
irb(main):007:0> x.body  # deveria vir 'google'
=> ""
irb(main):008:0> Net::HTTP.get(URI.parse("http://google.com"))
=> ""  # mesma coisa... :/

Atualizando para versões mais recentes (como a 1.2.4) o problema acaba. Alguem mais passou por isso?

O FakeWeb é uma excelente ferramenta para testes reais onde dependemos da resposta de outros servidores. Ao inves de estabelecer uma comunicação real, que pode trazer outros tipos de problema de dificil detecção, simulamos a resposta para ver se o sistema se comporta de acordo com o esperado.

Sabe quando vc tem que testar se de 1, N, 0 elementos ou 404, essas coisas, e nem sempre vc pode forçar estas situações por ser complicado demais? Nesse ponto o FakeWeb é A ferramenta certa.

o número 3025 possui a seguinte caracteristica: 30+25=55 e 55*55=3025. Escreva um programa que escreva todas os números com quatro algarismos que possuem a citada características.

Veja que solução elegante temos com ruby:

>> (1000..9999).find_all{|x| (x/100+x%100)**2 == x}
=> [2025, 3025, 9801]

Entretanto tive a apelar para uma sujeira (alguem percebe?) na versão em haskell:

Prelude> import List
Prelude List> findIndices(\x -> ((x `div` 100)+(x `mod` 100))^2 == x && x > 1000)[0..9999]
[2025,3025,9801]

Por fim, um simples ‘one liner’ usando gawk

$ seq 1000 9900 | gawk '(int($1/100) + $1%100) == sqrt($1){print}'
2025
3025
9801

É claro que a solução esperada é algo como

#include <math.h>
#include  <stdio.h>
int main(){
	int i;
 
	for(i=1000;i<=9999;i++){
		if(((i/100)+(i%100))==sqrt(i))
			printf("%d\n",i);
	}	
 
	return 0;
}

Até ANSI C é mais elegante – sem flamewars por favor, afinal todos sabem o que são programadores de verdade

   require 'base64'
   data = "Now is the time for all good coders\nto learn Ruby"
   Base64.b64encode(data)

Entretanto se vc quer processar o conteudo de um arquivo, vale um cuidado extra: definir a forma de abertura dos arquivos.

Por exemplo, eu posso fazer isso

   require 'base64'
   data = File.open('imagem.jpg').read
   Base64.b64encode(data)

Se eu estou desenvolvendo no linux, para mim o resultado é coerente. Eu ficaria feliz (sem sacanagem) se fosse o caso de desenvolver um software que rodasse exclusivamente nesse sistema operacional. As vezes não é bem assim…

Ruby é um bom exemplo de uma linguagem que permite desenvolver software multi-plataforma, entretanto é muito facil atrapalhar o interpretador (afinal, quem nunca teve problema com uma referência a um arquivo “C:\xxx”?). No exemplo real que eu passei, bastaria informar o modo ‘rb’ (r de read, b de binary) para o comando open que eu teria o mesmo comportamento em todas as plataformas.

   require 'base64'
   data = File.open('imagem.jpg','rb').read
   Base64.b64encode(data)

É claro que este tipo de comportamento pode ser verificado através de uma suite de testes em todas as plataformas-alvo, entretanto vale de alerta para estudarmos um pouco as caracteristicas das apis e bibliotecas nas diferentes plataformas (não adianta, desenvolver software signfica estudar constantemente).

Para terminar, vejamos esta thread:

Summary: open should default to binary mode on windows

Initial Comment:
On windows the open() function defaults to reading
files in text mode. To get a binary mode file I need
to append a “b” to the mode string. I think this is an
unnessary platform inconsistency. Twice now I’ve had
hard to track down bugs because I was reading a file in
text mode and should have been using binary. This is a
wart, IMO.

Ou seja, muita gente, em diferentes linguagens, vai enfrentar o mesmo problema de achar que o open, pode padrão, vai abrir o arquivo em modo binario. A origem disso é antiga e não vai desaparecer de uma hora para outra.

Por fim, vale lembrar que o conceito de ‘nova linha’ é diferente de acordo com o sistema operacional, no unix é \n enquanto no windows é \r\n. Também é antigo e remonta a epoca de impressoras matriciais, DOS e por ai vai. É o tipo da coisa que, pela lei de murphy, vai sacanear a gente quando menos esperamos.

Obrigado ao Rafael por ter visto este detalhe comigo tarde da noite.

Quando eu faço, em Ruby, algo como

i = 1 + 2

estou fazendo, na verdade,

i = 1.+( 2 )

Pois o 1 é um objeto da classe FixNum, que responde ao método + (simbolo de adição).

E no Python, sera que isso funciona? Na verdade a coisa é ligeiramente diferente!

i = 1 + 2

é equivalente à

i = (1).__add__(2)

É claro que vão falar: puxa, eu tenho que colocar os parentesis ao redor do 1 para invocar um método (que não tem o mesmo nome do operador + e sim algo bizarro como __XPTO__). Isso se deve à como o interpretador funciona, que vê o primeiro ‘.’ apos um numero como o delimitador da parte inteira da parte não-inteira.

É possivel, então, fazer a mesma coisa que eu faço com Ruby de duas formas:

i = int(1).__add__(2) # ou 
i = 1.0.__add__(2)

Percebam o 1.0.metodo tinhoso ali: eu estou invocando um método do objeto 1.0 – da mesma forma que o Ruby ou outras linguagens totalmente OO – apenas a sintaxe difere um pouco.

Decidi não postar nenhuma pegadinha. De fato existe uma proposta de ter algo como os blocos unsafe do C# em java ( veja aqui) mas nada confirmado.

Bom primeiro de abril para todos!