Celso Martinho - Portuguese

No more lazyweb

nospam@example.com (Celso Martinho) — Mon, 14 Jul 2008 22:15:42 +0100

PS: Eu não subscrevo o firefox_answers
PS2: O twit teve ainda como consequência a passagem de um fã de Slayer pela minha secretária.

No cameras or lights, just data.

nospam@example.com (Celso Martinho) — Mon, 14 Jul 2008 21:01:37 +0100

"In Radiohead's new video for "House of Cards" from the album "In Rainbows", no cameras or lights were used. Just data."

http://code.google.com/creative/radiohead/viewer.html

Sem palavras.

TODAY

nospam@example.com (Celso Martinho) — Mon, 14 Jul 2008 00:16:53 +0100

Mais talento emergente Português.

"A CADA é uma associação cultural empenhada no desenvolvimento de uma cultura artística inspirada em estruturas tecnológicas. Interessa-nos explorar as relações criativas entre a arte, ciência e tecnologia." (mais)

A CADA acaba de lançar o TODAY, uma aplicação para telemóveis Symbian que capta os eventos do aparelho, traça um perfil pessoal da utilização do mesmo e transforma esses dados numa interessante visualização, uma espécie de DNA do comportamento do utilizador. Ou, como lhe chamam, "TODAY is a piece of generative design for mobile phones. ". O projecto foi aparentemente financiado pela Direcção-Geral das Artes e pelo Ministério da Cultura.

Não experimentei porque não tenho nenhum Symbian mas gostei de ver os resultados.

3 curtas

nospam@example.com (Celso Martinho) — Thu, 10 Jul 2008 00:32:57 +0100

Não tem sido fácil arranjar tempo aqui para o folhetim. Esta vida sem vida própria, mais um mês inacreditável para o melhor e para o pior, e mais o vício inacreditável do microblogging resultaram num vazio de mais de 1mês. Sorry about that.

Para compensar ficam aqui 3 rapidinhas relacionadas com o SAPO, só para os mais desatentos:

1. Lançámos finalmente o nosso site para programadores http://developers.sapo.pt/. Para além da documentação e exemplos das APIs públicas que temos, esta iniciativa pretende acima de tudo ser um repositório de conteúdos e uma ferramenta de consulta e de comunicação e de colaboração do SAPO com a comunidade e vice-versa.

Por lá aparecerão apresentações, vídeos, exemplos práticos de código e grandes temas. É também um espaço de notícias e lazer. Um exemplo disso é o cartoon de Os Especialistas cujo desafio de recuperar lançámos ao Pedro e ao Nelson (obrigado por terem aceite).

2. SAPO Summerbits. "O SAPO Summerbits é um programa que oferece a alunos uma bolsa para escrever código para vários projectos de software livre existentes ou para desenvolver os seus próprios projectos de raíz. O SAPO irá trabalhar com vários grupos relacionados com software livre e tecnologia para identificar e financiar vários projectos ao longo de um período de três meses. A Associação Ensino Livre colabora activamente com a SAPO na organização deste programa.".

3. SAPO Codebits. Está confirmado e aprovado, vai ser no Factory LX nos dias 13, 14 e 15 de Novembro, marquem nas agendas. O organização já começou há umas semanas mas o ritmo agora vai acelerar, mais sobre isto assim que possível. Fiquem atentos ao blog.

Fazer uma máquina de Arcade

nospam@example.com (Celso Martinho) — Tue, 27 May 2008 02:20:45 +0100

A pedido de muitas famílias, aqui vai.

Quem roçar na minha geração sabe o que é um salão de máquinas de arcade. Sabe, se for uma pessoa normal e dentro do target deste blog, certamente, como é passar intervalos ou uma tarde livre de aulas (ou não) fechado num salão agarrado a um Bubble Bobble, Shinobi, New Zealand Story ou Rainbow Islands, só para mencionar alguns. Sabe o que é ser expulso dos salões por ainda não ter idade para os frequentar, sabe o que é poupar no lanche para gastar na jogatana, sabe jogar snooker e setas, sabe truques e maroscas e enganar o responsável do salão de jogos e sabe, acima de tudo, escrever o nome completo com apenas 3 letras e com orgulho.

A minha adolescência ficou profundamente marcada pelos salões de jogos e pelos clássicos de arcade. Mesmo depois com o computador pessoal e mais tarde com as consolas, a tendência foi sempre procurar as versões e as adaptações dos jogos de arcade, infelizmente na sua maioria muito pouco fieis aos originais. Esta minha vivência explica também em parte porque é que o 3D ou os jogos com estratégia nunca me fascinaram particularmente, acho que fiquei viciado na satisfação imediata que só um jogo de máquina (cujo principal objectivo é maximizar o investimento por quantidade de tempo) pode dar. Ainda hoje, e percebo que isto seja uma autêntico sacrilégio para os mais novos, posso dizer que me dá mais gozo jogar uma boa partida de Outrun em 15 minutos do que aprender a jogar, ou jogar, GTA, e que o Spore me fascina muito mais pelos aspectos técnicos e científicos da obra do que pelo jogo em si (provavelmente nunca o vou jogar). E com isto choquei uma boa percentagem dos meus leitores, imagino.

Quando deixei de ser um garoto (para aí por volta dos 30) tornou-se óbvio que eu um dia tinha que ter uma genuína máquina de jogos de arcade em casa, a todo o custo. Só que ter um trambolho destes em casa tem requisitos muito altos em termos de espaço e devidas autorizações à alta autoridade para a harmonia da estética caseira, vulgo AHEC. E foi portanto, e vejam a elegância com que faço a ligação deste post com o post anterior, com a mudança para a casa nova que concretizei a promessa.

O que se segue é uma espécie de making-of para o leitor curioso ou para potencial interessado. Divirtam-se.

Preparação

A primeira coisa que fiz quando decidi que era desta foi comprar um livro da especialidade. Encomendei o Project Arcade à Amazon UK porque me lembrava de uma review sobre o mesmo no Slashdot. O livro revelou-se completamente inútil, devia pertencer à colecção dos for dummies. Apesar de o achar objectivo e de boa leitura, tem 3 grandes defeitos: é tudo muito básico para uma pessoa com a minha formação (electrónica e novas tecnologias), está completamente desactualizado, parou nos 90s, e é muito win32 centric. A melhor fonte de informação para quem quer construir uma Arcade Machine é a Internet, de longe.

A segunda coisa que fiz foi arranjar um "sócio" para a empreitada. Apesar de me considerar desenvencilhado no que diz respeito a bricolage e afins, fazer uma besta destas requere bons conhecimentos sobre a arte da carpintaria e eu não queria arriscar e ficar com uma obra imperfeita. Foi aqui que o meu amigo Fernando Afonso entrou em acção. Quem melhor do que o 'panhol para me ajudar com a escolha dos materiais, das ferramentas e com a carpintaria? Fizemos um acordo, ele ajudava-me nesta e eu ajudava-o na construção da dele, mais tarde. E vou ajudar.

Terceiro, convencer a mulher a hipotecar a varanda da casa nova por pelo menos 1 mês, com toda a sujidade, incómodo e barulho associados.

Modelo do gabinete

Há muitos modelos de máquinas de Arcade e muitos planos para cada uma delas, pagos ou gratuitos. O livro Project Arcade traz alguns no CD. Mas eu queria o modelos mais clássico de todos, aquele que mais se via nos salões em Portugal, o armário vertical com o ecrã ligeiramente na diagonal, consola ao nível do banco, com dois joysticks, botões de lado (para o Pinball Action, claro), moedeiro em baixo a bater nos joelhos, e mostrador luminoso com o tema do jogo em cima. Não foi fácil mas consegui encontrar exactamente o que queria aqui no Mameroom por $29 USD.

Os planos são bastante completos com instruções detalhadas passo a passo. Mas para ser honesto, o que mais aproveitei dos planos foram as medidas exactas das peças do "cabinet" porque acabámos por usar outras técnicas de montagem e colagem, na minha opinião mais robustas do que as propostas. Mas isto, mais uma vez, depende das habilitações de cada um para a carpintaria. Se seguirem estes planos à risca também ficam bem servidos.

Materiais

Eu perdi a conta e memória à quantidade de material e ferramentas que comprei para fazer a caixa da Arcade, mas foi muita tralha, e comprei tudo no AKI. Ele foram madeira (duas tábuas grandes e pesadas, de MDF de 16mm, que o AKI teve de levar a casa), massa reparadora para as imperfeições e buracos, tinta preta para madeira, lâmpada fluorescente para o mostrador, dobradiças, parafusos, cola para madeira, tacos, madeira adicional (ripas) para os suportes internos, lixa, vidro, acrílico, máscaras, óculos e proteções, pincéis, rolos, eu sei lá.

Ferramentas, assim de cabeça, berbequim (de preferência com controle electrónico de velocidade), coroa para fazer buracos grandes, brocas, serra eléctrica de recorte, aparafusadora eléctrica, um esquadro grande, fica métrica, e uma tupia que dá jeito para os buracos pequenos e que requerem precisão.

Aconselho também a terem uma boa mesa de carpinteiro ou cavaletes. No meu caso usei (com muito cuidado) a mesa de comer da varanda e acabei por lhe fazer um lenho com a serra eléctrica. "Muito profissional sim senhor", disse a patroa quando viu o desastre.

Quanto ao televisor tinha duas opções. Ou ia para o state of the art e escolhia um TFT grande e barato de 4:3 e não tinha que me preocupar com ligações ao PC nem com lesões nos olhos, ou optava pelo genuíno ecrã de tubo catódico, vulgo CRT, a bombar com varrimentos de 15k/50Hz em que se notam claramente os espaços entre as linhas de pixels dos jogos. Optei, claro, pelo último. Eu queria a experiência orignal em toda a sua glória. Comprei um televisor Mitsai de 70cm na Worten por menos de 150 Euros com 2 entradas SCART (e RGB activo, isto é muito importante como verão mais abaixo).

Construindo a caixa

Construir o gabinete é trabalho puro de carpintaria e aqui têm duas opções: ou percebem da coisa e dão o vosso melhor aproveitando as medidas dos planos ou seguem religiosamente cada um dos passos dos planos e rezam para que corra tudo bem. Eu optei pela primeira, graças à ajuda do carpinteiro Afonso, claro.

A inovação no nosso caso foi a união das tábuas. Os planos sugerem apenas umas dobradiças mas nós para além disso colámos as tábuas com cola de madeira e com tacos e pequenos furos (do tipo mobilia do Ikea, só que melhor). Colocámos ainda umas ripas em pontos estratégicos, por dentro. Ficou sólida (e pesada) que nem um rochedo, posso-vos dizer.

Inovámos também na parte de trás ao fazer uma porta de abrir para ter acesso facilitado ao interior no futuro. As arestas das tábuas foram trabalhadas com lixa e não com máquina (o MDF é fácil de trabalhar, não é muito duro) e também ignorámos a sugestão de ter uma gaveta para teclado na parte frontal, achei que isso seria pouco fiel ao original (embora seja cómodo para efeitos de manutenção, admito).

Antes de terminar o trabalho, encastramos a televisão dentro da estrutura. Este passo é complicado e por isso aqui ficam algumas dicas:

1. Comprem uma televisão com as medidas correctas. No meu caso comprei uma Mitsai de 70cm (medidas do cinescópio) que encaixou que nem uma luva. Não se esqueçam, mais uma vez, que deve ter entradas SCART com os pinos de RGB activos (a maioria dos chipsets modernos têm).

2. Ao retirarem o cinescópio e a "board" da televisão tenham muito cuidado. Certifiquem-se que a televisão nunca foi ligada, ou pelo menos que não foi ligada recentemente, e mesmo assim tenham cuidado. Uma descarga nas vossas mãos do condensador de alta tensão que as televisões CRT têm para estabilizar a alimentação dos tubo catódicos pode-vos fulminar, literalmente. Foram avisados.

3. O cinescópio é muito pesado, especialmente um destas dimensões. Quando pegarem nele façam-no com ajuda e 3.1 certifiquem que a estrutura da caixa está bem feita para o encaixar e o suportar 3.2 prendam-no muito bem, com parafusos.

4. O plano B, que é muito mais seguro, é não esventrarem a televisão e colocarem-na dentro caixa inteira. A parte má é que normalmente há imenso plástico à volta do cinescópio propriamente dito e não só vai ficar mais inestético e pouco realista como possivelmente terão que lá meter um televisor com uma área visível de imagem substancialmente inferior para caber tudo.

No fim fizemos uma maratona de lixa na mão, arredondámos as arestas, as imperfeições foram todas corrigidas com a ajuda de massa branca, a madeira ficou tão limpa e tão suave como a pele de um bébé.

E terminámos com a pintura. Duas de mão ou mais, tinta boa, preta, rolos (não usem pincéis para as grandes superfícies), já sabem uma de mão na vertical, outra na horizontal, não ajavardem. Se não sabem pintar, peçam ajuda a quem saiba porque uma má pintura estraga o projecto. E não se esqueçam, não pintem nada sem lixar e limpar muito bem a madeira primeiro.

Painel de comandos

Esta é uma das partes mais críticas da máquina e eu queria que ficasse perfeito e ia investir em qualidade. Queria aqueles joysticks industriais feitos com micro-switchs em que podemos mandar-lhes uns bons murros sem constrangimentos, idem para os botões.

Encomendei um sortido de comandos à Ultimarc em UK, uma casa especializada em material para Arcades.

2 Mag-Stik pretos.

8 botões de cores várias e 2 botões com 1UP e 2UP.

Da Ultimarc veio também uma interface I-PAC, aonde liguei os comandos todos. Esta interface transforma os interruptores dos comandos em teclas normais de um teclado PS/2 ou USB. Parece simples mas não é bem assim porque para além disto o interface tem uma série de features cruciais para gaming: pouco delay de resposta, não tem problemas de ghosting (várias teclas premidas ao mesmo tempo em secções diferentes) nem stuck keys, etc, etc. É muito bom. O plano B aqui, que não recomendo pelos motivos enumerados, é usar o controlador de um teclado velho desmontado.

E veio também, e este é o toque de requinte da máquina para verem o meu empenho, um moedeiro electrónico "COIN mech" que liguei correctamente ao I-PAC e que viria a desempenhar as suas funções em pleno, ou seja, meter moeda para ter créditos. O moedeiro é uma obra de arte, é programável e funciona por comparação de moedas (peso e dimensões). Basicamente basta-me meter uma moeda exemplo no mecanismo e ele compara-a com as outras que caiem pelo buraco.

O painel e o moedeiro ficaram um mimo como podem ver nesta foto. Wiring aqui. Ligação ao I-PAC aqui. Foto do moedeiro pela parte de dentro.

Acabamentos

Acabou a poeirada. Entramos nos detalhes e no interior da caixa.

Altifalantes: dois, por cima dos comandos. Aproveitei os da televisão. Mais tarde arranjei as tampas pretas com redes em esponja que coloquei da parte de fora.

Luz fluorescente, comprei uma daquelas baratas no AKI com muito pouca potência e aparafusei-a no compartimento dos altifalantes. Mais tarde mandei fazer um painel em "Black light" (aqueles que se usam nos mostradores de comida luminosos do Mc Donalds) com um tema do meu jogo favorito de todos os tempos, o Bubble Bobble. Encontrei a "marquee" em formato vectorial e enviei para a Tutitex que me devolveu o painel uns dias depois. Afixei-o à caixa com uma proteção em acrílico. Ficou catita.

"Board" da televisão, coloquei-a por trás do cinescópio em cima de uma prateleira estratégicamente montada à altura certa. Mais um vez, cuidado com o maldito condensador. Deixei o LED receptor de infravermelhos com linha de vista para o acrílico do painel para poder usar o controle remoto da televisão do lado de fora, se for preciso.

Vidro protector do ecrã. Tirei as medidas e mandei cortar um quadrado de vidro no AKI. O Afonso pintou as bordas do vidro com um spray de tinta preta para delinear as medidas exactas do cinescópio. Ficou 5 estrelas.

Comprei um PC de linha branca Pentium IV 3Ghz com disco de 250 Gigs a preços da chuva no Intermarché, junto às pastilhas elásticas e aos rebuçados. Na realidade aqui, para correr Mame exclusivamente, qualquer chasso reciclado deve dar. Eu simplesmente por um lado não tinha chasso nenhum na garagem e por outro queria algum poder de processamento para fazer outras brincadeiras. A parte muito má deste PC é que a ventoinha faz uma barulheira inacreditável, é algo que ainda vou ter que resolver com alguma imaginação. Sugestões para sistemas de arrefecimento silenciosas?

A caixa do PC foi toda desmontada, fiquei só com a motherboard, disco e fonte de alimentação. Acomodei tudo dentro da Arcade em cima de prateleiras montadas para o efeito.

Conselhos sobre PCs:

1. Linha branca ou material reciclado funciona bem, não é preciso nada de muito sofisticado. Verifiquem só se não é muito barulhento porque uma caixa de madeira deste tamanho faz sempre alguma ressonância.

2. De preferência, mas não necessariamente, comprem uma board que suporte ACPI com sensores de temperatura e velocidade variável da ventoinha para poderem ter um controle dinâmico por software. O Linux suporta bem isto.

3. A placa gráfica é importante mas pode ser externa. Leiam o ponto sobre a placa gráfica mais abaixo.

Software

A escolha do software para a máquina de Arcade é determinante para termos uma réplica fidedigna. Este é o meu setup mas há muitos outros possíveis, tudo depende da vossa experiência e do vosso conforto com cada uma das opções.

Eu queria usar Linux por isso instalei a distribuição Debian, versão "unstable" (que em Debian, como todos sabem, quer dizer estável e com as últimas versões das libs todas) com kernel 2.6.17-2.

Quanto ao emulador, depois de muita pesquisa, optei pelo Advance Mame que é simplesmente soberbo. É um port do mame especialmente desenhado precisamente para máquinas de Arcade e para CRTs, televisões e monitores com frequências fixas. Funciona em Linux, Mac e Windows e tem uma série de características que fazem deste software a escolha mais profissional possível. Algumas:

1. Suporta uma porrada de placas gráficas/frameworks e modos de vídeo, mesmo as mais bizarras, como vão ver.

2. Tem built-in uma série de efeitos gráficos, resizing, streching.

3. Suporta scripting e invocação de scripts externos, por evento.

4. Os ficheiros de configuração são ficheiros de XML facilmente editáveis.

5. Permite mudar grande parte dos parâmetros em run-time, durante os jogos, através de menu especiais.

6. É orientado para a máquina de jogos, arranca em full-screen com um ambiente gráfico (AdvanceMenu) que pode ser personalizado (e muito flexível) que nos permite escolher o jogo. Semelhante aquelas máquinas mais modernas, multi-game, só que melhor.

Lista completa de "features" do AdvanceMame aqui e do AdvanceMenu aqui e snapshots também.

A configuração inicial do AdvanceMame não é pera doce no entanto. Vamos começar pela compilação.

Para suportar bem a minha placa gráfica tive que usar a svgalib (versão 1.4.3, pacote libsvga1 do Debian). A outra opção era Frame Buffer mas tentei até à exaustão e não consegui por aquilo a funcionar direito. Também experimentei SDL mas sem sucesso. Atenção que este trial and error depende muito da placa gráfica que tiverem (ver mais abaixo). Para o som usei o framework alsa, claro. A svgalib controla o teclado e a placa gráfica.

Opções do configure do advmenu:

$./configure --prefix=/servers/mame/ --enable-svgalib

Eis as opções do configure do advmame:

$ ./configure --prefix=/servers/mame --enable-svgalib --enable-alsa

Placa gráfica e VGA

A escolha da placa gráfica é importante quando decimos usar uma televisão em vez de um monitor. Precisam de uma placa que tenha modos gráficos compatíveis com 50 a 60Hz de varrimento vertical e 15.6Khz de varrimento horizontal, que é como quem diz PAL e NTSC. A minha escolha foi uma GeForce4 MX 440 AGP 8x que é completamente overkill para jogar mame mas que se dane, funciona com TVs.

Para esta placa e para o setup descrito svgalib+mameadvance, vão-me agradecer estes 3 ficheiros:

1. Ficheiro de configuração da libsvga: /etc/vga/libvga.config

2. Ficheiro de configuração do advmenu: /servers/mame/config/advmenu.rc (o mais valioso neste são as linhas device_video_modeline que definem com precisão uma porrada de modos gráficos para televisões CRT).

3. Ficheiro de configuração do advmame: /servers/mame/config/advmame.rc (mesma conversa)

Agora a parte complicada. Uma placa gráfica tem normalmente saídas VGA (e eventualmente uma saída de S-Video que não vão querer usar, confiem em mim). Ora do outro lado (na televisão) está uma entrada SCART. Embora o pinout VGA seja decomposta em sinais de RGB e as frequências de varrimento já estejam correctas, não é possível fazer uma ligação directa ao pinout da SCART. Isto porque há algumas diferenças nas normas que têm que ser corrigidas primeiro.

Sem medo. O grande Tim Worthington fez um guia à medida para resolver o problema: "How to use a SCART TV as a Monitor for MAME". Eu optei pela versão com o 74HC86 com as portas XOR porque é mais seguro do que a versão simples com diodos. Comprei os componentes na Dimofel e uma placa de circuito impresso daquelas já perfuradas com pistas paralelas para fazer pequenos protótipos e em 30 minutos fiz o circuito, funcionou à primeira. Aqui está uma foto dele em acção. A alimentação do IC fui busca-la ao PC, a um daqueles conectores para os discos rígidos.

A nitidez e o contraste da televisão ficaram impressionantes. Notam-se os pixels bem definidos, só visto. Nem pensem em usar vídeo composto ou daqueles adaptadores baratos de VGA para SCART, vai ficar um ranho.

ROMs

Para jogar jogos de Arcade num emulador, é preciso ter as ROMs desses jogos e é preciso serem donos dos mesmos, caso contrário podem estar a cometer alguma ilegalidade. Eu poderia dizer que há torrents em barda com a coleção completa de ROMs ou sites com arquivos online mas não seria correcto. Afinal de contas ainda há muitas máquinas das décadas de 80 e 90 a fazerem dinheiro por aí.

Há também uma série de ROMs que foram cedidas sem direitos de autor pelos seus creadores. E são fantásticas (not).

Artwork

Há uma série de icons, screenshots, snapshots e afins que dão suporte ao Advance Menu para ficar tudo bonitinho nos menus de selecção. Aqui está uma boa coleção de artwork para o Mame. Coloquem os Snaps em /servers/mame/config/snap.

O Advance Mame permite ainda, em run-time durante os jogos tirar snapshots ou até excertos de vídeo e som com um simples premir de tecla, erhm, botão, e que podem depois ser incorporados no Advance Menu.

Startup

Os scripts de arranque da máquina também foram um desafio, por um motivo, porque para o teclado (leia-se painel de controles) funcionar com a svgalib esta necessita de apoderar-se de um tty, como se estivéssemos feito login numa consola e corrido o advmenu manualmente. Isto coloca de parte qualquer abordagem pela iniittab, daemontools ou /etc/init.d/ porque sem o login efectivo de um utilizador na consola e de um shell, não há tty para ninguém e o advmenu vai-se queixar (via svgalib) que não consegue ter controlo do teclado. Na realidade, vim a descobrir agora mesmo enquanto escrevo este post, este problema é mencionado na FAQ do Advance Mame aqui (ainda bem que eu perdi horas a bater com a cabeça na parede há uns meses atrás).

A solução que acabei por escolher foi: instalei o mingetty e configurei-o na inittab para fazer autologin (que é uma das suas features). Assim:

1:2345:respawn:/sbin/mingetty --autologin root tty1

Desta forma, quando o PC arranca é feito um login automático de root em cima do tty1. Depois basta meter isto no ~root/.bashrc:

export PATH=$PATH:/servers/mame/bin
export ADVANCE=/servers/mame/config
export TERM=linux
tty | grep tty1 && ( while [ 1 ]; do
cd /servers/mame/logs
/servers/mame/bin/advmenu --log
if [ -f /tmp/quitloop ]
then
sleep 3600
fi
done; )

O ficheiro /tmp/quitloop dá jeito se quisermos parar o advmenu completamente.

Custo total

Entre material, ferramentas que não tinha, televisor, computador, placa, botões e outros, devo ter gasto uns 1500 a 2000 Euros, estimo. Mas tendo as ferramentas, o PC e eventualmente a televisão é possível realizar o projecto por muito menos dinheiro.

Resumo

Este projecto foi um dos mais interessantes que já fiz, deu-me um gozo brutal montar isto, desde a primeira tábua, aos acabamentos, à electrónica e ao software. E a obra ficou impecável, diga-se de passagem. Quase ninguém acredita, quando vem cá a casa, que isto feito de raíz.

Só me falta fazer uma coisa, montar o último circuito do Tim para me ligar a televisão automaticamente sob as ordens do PC.

Depois de escrever isto tive esta ideia. E que tal, no Codebits deste ano 2008, fazer uma maratona a montar uma (ou mais) destas? Já a estou a ver depois junto aos elevadores, no SAPO.

Este post está carregado de fotos mas aqui fica um slideshow com as fotos todas, para o impaciente:

Espero que tenham gostado. Dúvidas, perguntas, etc, coloquem-nas nos comentários, eu tentarei responder.

Secção de classificados: Um belo T2

nospam@example.com (Celso Martinho) — Sat, 17 May 2008 18:02:04 +0100

A audiência geek deste blog que me desculpe o off-topic.

Estou a vender um T2 em Lisboa na Rua Lúcio de Azevedo (perpendicular à estrada da Luz) no Lote 10. Os atributos são:

10º andar. Dois quartos, 1WC, hall, cozinha e marquise, sala grande, lareira.
Vista sobre Monsanto e linha de vista aberta para o Cristo Rei. Solarengo.
Lugar de garagem e arrecadação.
O prédio é relativamente novo, o condomínio não é caro.

O local é IMHO óptimo porque tem boas acessibilidades quer para o centro quer para fora (2ª circular e eixo norte-sul à porta), mas ao mesmo tempo é um local sossegado. É ver o mapa.

Razão da venda? Simples, 2 filhotas, troquei de casa. Preço, à volta de 225k.

Interessados, contactem-me.

Fotos aqui.

Unplugged '08

nospam@example.com (Celso Martinho) — Tue, 13 May 2008 12:42:28 +0100

No próximo dia 21 de Maio vai decorrer a inauguração do laboratório SAPO na Universidade de Aveiro, um espaço dedicado a alunos e docentes para realizar projectos no âmbito do protocolo de colaboração que as duas instituições fizeram. É um marco histórico por vários motivos, pelas origens, pela mudança, pelo potencial que representa esta aproximação ao meio académico e ao talento emergente, e também porque é o culminar e a formalização de uma relação que tem vindo a ser muito trabalhada nos últimos meses.

Para acompanhar a ocasião decidimos organizar uma conferência da parte da tarde sobre um tema que para nós é neste momento absolutamente prioritário: Usabilidade.

O programa conta com vários oradores com experiência e reconhecimento nesta área ao nível nacional, privado e académico, e ao nível internacional com a presença da autoridade máxima nesta matéria, a Adaptive Path.

Apareçam. A entrada é livre.

A presença já não é o que era

nospam@example.com (Celso Martinho) — Sun, 04 May 2008 00:03:03 +0100

Update 1: Por coincidência o TechCrunch tem hoje um artigo precisamente sobre a oportunidade de usar uma infra-estrutura como o XMPP para suportar um Twitter "bem feito".

Update 2: Um bom artigo do Mickaël Rémond da Process-one sobre a utilização do XMPP e do pubsub num serviço do tipo Twitter/micro-blogging.

Update 3: A malta do Psi também anda a fazer umas brincadeiras com estes conceitos (via Melo).

Durante anos, na relação que tenho com certos e determinados operadores móveis (o plural é só para confundir, faz de conta que os MVNOs também contam vá), defendi que o Instant Messaging não tem interesse absolutamente nenhum num telefone móvel. Não tem interesse porque todas as pessoas neste País têm um telemóvel (ou vários) e estão permanentemente ligados, a maior parte durante a noite inclusive. Os portugueses estão permanentemente disponíveis com o telemóvel, é seguro dizer. E portanto colocar uma aplicação de IM no telefone acrescenta o quê em relação ao SMS que é praticamente gratuito e que possivelmente funciona na mais bem trabalhada aplicação nativa que qualquer aparelho pode trazer? Informação de presença não é. Nada, não há absolutamente nada de relevante no IM no telemóvel a não ser uma ligeira sensação efémere de que estamos na crista da onda a falar com os amigos do PC num teclado de 9 teclas. E então quando me falavam de tarifários a cobrar à mensagem...

Mas estas coisas já se sabe, se o vizinho do lado dá um pontapé numa pedra nós temos que um pontapé num calhau, mesmo que arrisquemos partir o dedo grande. E imagino que seja assim em todo lado, aliás, sei que é. E durante anos isto fez-me muita confusão. Mais tarde percebi que estes e outros produtos que os operadores móveis querem replicar da Internet do PC (da qual só percebem a popularidade, mas não a mecânica) são apenas uma fachada para comunicar aquilo que realmente interessa no mundo móvel (por enquanto): o tarifário de voz, SMS e dados. Adiante.

No outro dia, com amigos, divagava sobre o que é que torna o twitter tão inútil e tão viciante ao mesmo tempo. Não são certamente as notificações gratuitas por SMS, já desliguei isso tudo, não sobrevive ao teste da vida real. Não é também pelo social networking, já estamos no período post-web2.0 certo? Nem o facto de ser micro-blogging e de nos exigir uma grande capacidade de síntese, leia-se só permitir 140 caracteres por mensagem provavelmente por causa da história dos SMSes (para mim isto é uma limitação). E também não deve ser por causa dos inúmeros problemas de performance e de disponibilidade que o serviço tem sofrido ultimamente. Mas há algo, porque aquilo agarra-nos. O que é? Eu diria que é isto:

1. Ranking. A nossa eterna e involuntária necessidade de nos superarmos e de nos pavonearmos junto dos nossos mais próximos que nos está cravada no DNA, e não se armem em insensíveis a isto. Ele é meter um número ao lado da fotografia do utilizador e é vê-lo matar-se por fazer cresce-lo. Neste caso o "game score" é o número de "followers" de cada um tem. Não é um grande número e até o metem ali disfarçado de "stats" mas é um número. Ver "How Game Mechanics Can Make Your App More Fun".

2. Social Networking, se calhar afinal até é. Qual é o detalhe? A grande diferença para o Instant Messaging é que as relações individuais são públicas para todos. Qualquer um pode ver no meu perfil quem são as pessoas que eu sigo. Há aqui uma pirâmide de reputação quase perversa mas que funciona muito bem. A primeira coisa que eu fiz quando revisitei o twitter e o comecei a usar mais regularmente foi vasculhar os perfis das pessoas por quem eu mais reconheço interesse, e aí encontrar umas outras tantas que subscrevi pela reputação herdada dos anteriores.

3. Não é push (ver ponto 4 sobre o melhor do E-Mail). As mensagens são lidas on-demand, com a periodicidade que eu bem entender ou à distância de uma short-key dependendo do client que usar (twitterrific no meu caso), não sou incomodado com popups de janelas e notificações de growl. Isto lembra-me que usar o Twitter através do bot de XMPP é adulterar esta característica, nunca o faria.

4. A mais importante e voltando à introdução do post, é instant messaging mas sem presença. Agrega as principais vantagens do IM, do IRC e do E-Mail: É instantâneo e é social, mas não tem informação de presença. Eu já disse mais do que uma vez que a presença está em desuso. Porquê? Porque nós, com o advento da mobilidade e com os saltos qualitativos que os dados móveis, o acesso aos portáteis, os "smart-phones", as redes wifi e o acesso à Internet em geral deram nos últimos anos (e vão continuar a dar), estamos-nos a tornar todos deuses do online. Nós estamos a ficar progressivamente omnipresentes na Internet, quer gostemos quer não.

O meu ponto, para não desviar muito, é: até que ponto a presença vista como informação de disponibilidade, um dos bastiões das plataformas emergentes de messaging dos últimos anos (IMS, SIP e SIMPLE, XMPP, etc.), continua a ser importante?

Do meu ponto de vista continua a ser importante mas talvez não nos moldes em que inicialmente foi pensada, não apenas para transportar a disponibilidade dos meus correspondentes. A funcionalidade da presença pode ser muito interessante se puder ser extendida e se puder transportar outro tipo de meta-informação associada à minha pessoa e que nos dias que correm é muito mais importante do que a minha conhecida omnipresença na Internet, nomeadamente: Geo-localização, avatars, estado de espírito, a música que está a tocar no iTunes, etc, etc, etc.

E é talvez aqui que o XMPP, como plataforma extensível de messaging e de presença, pode marcar a diferença em relação a outras. Isto sim, faz sentido. Já dei o toque à malta da Process-One para fazerem uma proposta ao Twitter, agora que eles estão a ponderar mudar de plataforma. (smile).

Video do PTMail

nospam@example.com (Celso Martinho) — Sun, 20 Apr 2008 15:44:28 +0100

Ok, alguém me vai matar por isto amanhã. Mas estive a ponderar e sinto que há legitimidade para tornar este vídeo público: Primeiro porque tenho créditos, muitos créditos, no que diz respeito a expor situações embaraçosas dos meus queridos colegas e amigos de trabalho. Segundo porque já lá vão mais de 4 anos, e todos sabem que na Internet 4 anos são na realidade 12, é muito tempo.

Este vídeo representa um marco na cultura interna do SAPO. Foi o nosso primeiro mega-projecto, que envolveu tempo, recursos e custos consideráveis para essa altura. Tratou-se de construir a nova plataforma toda baseada em produtos Opensouce (ie: Qmail, Horde, Debian Linux, etc, etc.) e que viria a suportar o E-Mail da Telepac e do próprio SAPO, e que ainda hoje existe.

Foram 18 meses de projecto e de trabalho árduo em que não faltaram muitas discussões, muita pressão também do status-quo da época (e dos fabricantes e fornecedores do legacy), mas também muito trabalho em equipa, profissionalismo e diversão. Enfim, vejam.

versão com fullscreen no player

Takeoff 2008

nospam@example.com (Celso Martinho) — Sun, 20 Apr 2008 01:02:32 +0100

Hoje estive na Takeoff 2008. Boa iniciativa sobre empreendedorismo, que sem fanfarras nem mega-produções conseguiu reunir um bom painel e uma audiência jovem e francamente interessada pelo tema. Muitas caras conhecidas também (entre sapos, ex-sapos e colaboradores do sapo, quase parecia uma reunião de direcção). A repetir.

Fiquei sensibilizado com o convite para ser orador. Afinal de contas eu já não me considero empreendedor, pelo menos não no sentido de começar startups, há uns anos valentes desde que ajudei a fundar o SAPO e o mail.pt. Mas enfim, a minha vivência e o facto de lidar no meu dia a dia com pessoas brilhantes e novos empreendedores de alguma forma me dá formação e me permitirá passar uma mão cheia de conselhos.

Fica aqui a minha apresentação, a quem interessar, essencialmente sobre a história do SAPO e a sua criação. O vídeo do PTMail segue num post a seguir.

Booting up sapo.cv

nospam@example.com (Celso Martinho) — Thu, 17 Apr 2008 01:13:33 +0100

update: Apparently this post had some unexpected echo all over the blogs. Thanks all for your feedback, we're proud. My friend Pedro was crazy and kind enough to translate the post to english.

Ontem lançámos o SAPO Cabo Verde. A sensação de ter um SAPO fora de Portugal é no mínimo estranha, é um misto de orgulho e de medo, em que a segunda das sensações advém certamente do facto de nunca termos pensado muito nisto, na hipótese de actuarmos fora do rectângulo. É o tal síndroma que nos persegue, aos Portugueses em geral, para aí desde o tempo em que deixámos de pensar que somos grandes.

O projecto já cozinhava há uns largos meses. Não vou aqui discutir nem as razões nem os objectivos, alguém o fará por mim, vou só falar de tecnologia. Tecnologicamente falando, instanciar o SAPO fora de Picoas foi um desafio muito interessante. Uma coisa é escalarmos dentro do mesmo Datacenter mas outra coisa é sair do útero, distribuir conteúdos em pontos do globo distintos e distantes e reutilizar a mesma tecnologia mas em contextos diferentes e com características diferentes da nossa realidade mantendo ao mesmo tempo uma arquitectura global.

Ainda é cedo para falar. Posso estar a mandar foguetes antes do tempo e sair-me o tiro pela culatra, mas de qualquer forma achei relevante fazer este post e partilhar convosco a nossa experiência:

SOA

Nos últimos 2-3 anos andámos a queimar pestanas e a limpar a casa para conseguir montar uma arquitectura de sistemas baseada em serviços, vulgo SOA. E conseguimos. O nosso BUS de serviços está de pé e com uma vasta oferta de conteúdos que usamos e reutilizamos quer internamente quer com parceiros ou público em geral. Mas o BUS é mais do que um HUB de APIs, faz mais do que isso. Faz transformações de um formato para outro de qualquer método (ie: RSS para JSON), logging, controle de acessos, proxying, caching, gera documentação e código para todas as linguagens com base nos contratos dos serviços, é um mundo. E é só por causa deste valor todo que suportamos o fundamentalismo do seu incansável e convicto mentor em relação às guerras de SOAP vs REST. Em 2008 vamos colocar o nosso BUS em Opensource, está decidido.

E foi quando deixámos de apregoar SOA para efectivamente o praticar que conseguimos realizar projectos como o SAPO Mobile, que não é mais do que um "cliente" rico do portfolio do BUS (ok, é mais do que isso, mas é para perceberem). O services.sapo.pt é hoje uma peça fulcral na forma como concebemos e montamos os nossos projectos e permitiu-nos não só baixar drasticamente a complexidade dos desenvolvimentos bem somo os tempos de produção dos mesmos. Cabo Verde não existiria nos moldes actuais se não fosse estes esforço silencioso e quase inglório (porque durante muito tempo não representou output para a empresa) que a tecnologia do SAPO teve durante os últimos anos.

Broker

O Broker é outro dos "building-blocks" do SAPO. Foi escrito e re-escrito de raíz por nós (embora a primeira versão tenha sido baseada no Mantaray) e é um dos nossos projectos Opensource. Basicamente e sem entrar em muitos detalhes é uma nuvem gigante de agentes que está presente no Backend de todos os servidores do SAPO, distribuida, e que permite a qualquer aplicação a troca de mensagens e eventos, de forma completamente assíncrona (fire and forget) e em tempo real. Cada evento viaja dentro de um tópico (ou namespace). Os "clients" podem ser produtores ou consumidores de eventos (think pubsub, think uma rádio a emitir numa determinada frequência e um sem número de ouvintes que a sintonizam).

A Homepage do SAPO é completamente dependente do Broker. Cada um dos frontends da Homepage tem um agente que o gestor de conteúdos notifica (através do Broker) cada vez uma zona da Homepage precisa de ser queimada. A Homepage também produz eventos de Broker no browser, com chamadas da AJAX (ie: cada click que se faz numa notícia).

A beleza do Broker é aquilo que eu chamo de "decoupling". Imaginem mashups de eventos em vez de feeds. Imaginem que alguém no SAPO quer montar um serviço que incrementa um contador por cada vez que alguém pesquisa por "Cabo Verde" na Pesquisa do SAPO e que cada vez que um JID do SAPO Messenger, que é colaborador da empresa, faz login dispara-lhe uma mensagem de IM com o número de pesquisa feita por esse termos até à data. O exemplo é estúpido, é da hora, mas o ponto é: Qualquer pessoa no SAPO pode fazer este serviço, não depende de ninguém, não depende da malta da Pesquisa, nem do SAPO Messenger. Basta-lhe consumir os tópicos apropriados que já estão na nuvem e que estão documentados e cujos eventos está a ser gerados, em tempo real, pelas plataformas do SAPO.

Neste momento já temos mais de 100 tópicos a gerarem notificações e com um tráfego agregado na nuvem de mais de 1000 eventos por segundo. A regra de ouro é, qualquer serviço novo que realize uma acção relevante (ie: Alguém faz o upload de um vídeo no SAPO Vídeos, alguém faz login no SAPO Mail) deve produzir uma mensagem e publicar num tópico no Broker.

O Broker é crucial para a nossa escalabilidade e fiabilidade (o decoupling permite-nos na prática reduzir o número de dependências das aplicações e as característica de assincronismo e fire-and-forget reduzem o risco de falta de recursos e performance).

Este é daqueles produtos que temos de advogar mais. O tempo é escasso e é-nos difícil passar a mensagem para fora mas não hajam dúvidas: se procuram um framework de messaging entre aplicações, espreitem isto.

Cabo Verde tem uma nuvem própria de eventos a correr "lá" e partilha uma série de tópicos com Portugal (ie: O gestor de conteúdos reside cá).

CDNs

Durante anos tive a Akamai à perna a tentar vender-me soluções de CDN. Mas por muito que se goste da Akamai (e gosto) a solução nunca fez grande sentido. Na realidade não há muitos problemas de descentralização da entrega de conteúdos quando as maiores redes de acesso ADSL, Cabo e Móvel são da mesma empresa.

Mas entretanto a realidade alterou-se. Não só a rede de acesso cresceu muito e tornou-se complexa sendo necessário encontrar formas de estarmos mais próximos da last-mile, como o Cabo se separou, como entretanto o SAPO se internacionalizou e passou a ter mais do que um Datacenter em mais do que um País. O próprio perfil de conteúdo alterou-se drasticamente. Há 5 anos atrás não havia vídeo na Internet, só para dar um exemplo.

O SAPO Vídeos é o nosso serviço mais exigente no que diz respeito a entrega de conteúdos. Neste momento está a gerar quase 2Gbit/s de largura de banda em média durante todo o dia. Quando construímos a plataforma pensámos muito sobre a melhor forma de resolver o problema dos altos débitos e do futuro crescimento do serviço. E acabámos por construir uma solução de CDN caseira baseada em arquitectura de rede, NAS, DNS e Squids invertidos.

Esta mesma solução permitiu-nos levar o SAPO Vídeos para Cabo Verde, optimizando a entrega local dos vídeos (através da nossa CDN) mas mantendo o "core" do serviço (gestão, master dos vídeos, webUI) em Portugal, Picoas. Isto quer dizer que, com alguma magia de DNS (ver mais abaixo) em Cabo Verde os mesmos vídeos de http://videos.sapo.pt/ são servidos a partir do Datacenter da CV Multimédia por forma a não abusar de um muito limitado link internacional que o País tem.

Bricolage, gestão de conteúdos

O Bricolage é um gestor de conteúdos (enterprise-class for all you suits) Opensource e nesta tecnologia estão assentes alguns dos nossos Websites mais importantes, incluindo as Homepages de Portugal e Cabo Verde, o DN e o JN, entre outros. Workflow, autorizações, versioning e XML é com o Bric. Poucos sites precisarão de um canhão destes, a curva de aprendizagem não é pequena. É impróprio para cardíacos.

Mas depois de feito o deployment e de uma boa formação das equipas editoriais, esta besta é poderosa e de confiança.

A Homepage do SAPO em Cabo Verde é editorialmente gerida a partir do Backoffice alojado em Picoas, numa infra-estrutura partilhada com a Homepage de .pt. Os frontends em Cabo Verde são notificados (via broker) quando há conteúdo novo e isso despoleta um processo de actualização e re-processamento das páginas.

Imagens, CSS e conteúdo estático

As nossas farms de Imagens e de conteúdo estático (ie: http://h.s.sapo.pt/ http://js.sapo.pt/) possuem réplicas exactas e locais em Cabo Verde (http://h.sapo.cv http://js.sapo.cv). A replicação é feita com rsync. As farms estáticas são processos de lighttpd (dois por máquina para aproveitar os Xeon) em Linux e com epoll e cabeçalhos de Expires gigantes. Em testes conseguimos esgotar as interfaces de Gigabit de um destes servidores. A carga? 2. Uptime do nosso static1 (de 3):

root@static1:/servers/lighthttpd/etc# uptime
 01:08:13 up 553 days, 11:36,  1 user,  load average: 0.01, 0.01, 0.00
root@static1:/servers/lighthttpd/etc# ps ax |grep lightt
 2019 ?  S 429:53 /sbin/lighttpd -D -f /servers/lighthttpd/etc/httpd1.conf
 2039 ?  S 370:24 /sbin/lighttpd -D -f /servers/lighthttpd/etc/httpd2.conf

Rsync

O rsync é um dos nossos canivetes suíços dentro do SAPO. É usado para replicar árvores inteiras de conteúdos, para fazer a passagem de projectos para produção que estejam distribuídos por vários servidores, para gerir repositórios de pacotes Debian, para replicar a nossa farm de Web thumbnails, etc, etc. É muito eficiente porque faz cópias incrementais e comparativas e porque prima pela simplicidade e pela performance. Comporta-se muito bem também em cenários de conectividade remota. Só para terem uma ideia, há pessoas corajosas o suficiente para fazerem backups de servidores e dos seus computadores pessoais com rsync.

Cabo Verde depende muito dos nossos processos integrados de passagem para produção e replicação de conteúdos, que passam necessariamente pelo rsync.

Monitorização e Métricas, Nagios e Cacti

Desde sempre que usamos o Nagios para monitorização e alarmes e o Cacti para métricas de sistemas, mais dois produtos Opensource de qualidade. Em Cabo Verde usámos a mesma aproximação e estamos activamente a tentar ligar as duas instâncias (quatro) para termos uma visão integrada de tudo, do SAPO como um todo. Em teoria é bem possível, não só porque o software é Opensource mas porque é baseado em sondas, scripts e SNMP.

DNS patch

Os nossos DNS primário e secundário correm em cima de djbdns. Adicionámos-lhe um patch (com contribuições poderosas do nosso Über Sysadmin japc) que basicamente nos permitem dar respostas diferentes para ponto geográficos diferentes. Como base de dados de georeferenciação usa a GeoIP. Very nice.

Já estão a adivinhar não? Se alguém em Cabo Verde pedir um ficheiro de .js a http://js.sapo.pt/ o DNS encarrega-se de lhe resolver o nome para um IP dos nossos servidores em .cv (que também respondem a js.sapo.pt) e o conteúdo é servido localmente. Se alguém fizer o mesmo noutra parte qualquer do mundo, o DNS resolve para o IP de Picoas. Este conceito é aplicado em inúmeros cenários do projecto.

Instanciação e Templating

Outra mudança de mindset para nós foi a de passarmos a pensar nas plataformas dos projectos como sendo sistemas capazes de correr em contextos diferentes com comportamento diferentes mas sempre com uma base comum, um chapéu. E capazes também de se instanciarem, total ou parcialmente, fora do seu habitat natural, neste caso Picoas.

Isto na prática exigiu de nós um cumprimento mais rigoroso de um conjunto de boa práticas que nem sempre foram a regra: Usar sempre templating (ie: smarty, mason, template-toolkit) e CSS, prepararmos-nos para o multilingue, configurações dinâmicas dos serviços (por contexto, ie: bases de dados, memcacheds, etc), modularização e reutilização de componentes web (ie: mashups), repensar os procedimentos de passagem de desenvolvimento a produção (a contar os cenário de multi-hosting, multi-site).

libsapojs & Widgets

Outro projecto que fizemos em 2007 e que nos ajudou em Cabo Verde foi a nossa library de Javascript. No fundo estamos a falar do mesmo, reutilização de componentes e distribuição. Os Widgets que desenvolvemos em Portugal ficam, através dos procedimentos de passagem a produção e replicação, automagicamente disponíveis em todo o universo SAPO, tal como um mapa do Google num blog se auto-actualiza sob o comando do seu dono.

Em suma:

Estes são só alguns exemplos do tipo de preocupações que tivemos quando começámos a pensar no Internacional. Conselhos? Sim, alguns:

1. Uma boa arquitectura de sistemas é crucial para a evolução de qualquer projecto de TI. Nós, por questões históricas e heranças (legacy de mergers and stuff), aprendemos isto a bater com a cabeça na parede. Custou-nos mais. Não facilitem. Facilitem em tudo mas uma má arquitectura num projecto que quer crescer é um tiro no pé no médio-longo prazo.

2. Especifiquem por excesso, raciocinem top-down. Pensem à frente do tempo. É preferível perder 2 dias a colocar gettext nos templates, mesmo que não se use ainda, do que depois perder 1 mês a fazer refactoring de tudo para acomodar os novos requisitos. Definam um conjunto de boas práticas e cumpram-nas religiosamente. As áreas de negócio vão ficar irritadas por causa do famigerado time-to-market mas arranjem uma firewall e percam tempo no início, não durante. Eu sei que isto é uma lapalissada mas tem que ser dito.

3. APIs são ouro, são a cola da Internet. Estruturem e façam interfaces para tudo, e anunciem-nos, mesmo que não usem. Seja RSS, XML, JSON, SOAP, Microformatos, o que for. Desde que seja um formato estruturado, até sou capaz de suportar WSDL. HTML scrapping ou logins para aceder a uma schema mutante de Mysql é que não, por favor. Produzam matéria prima, mesmo que seja inútil, e publiquem-na, de preferência de forma assíncrona para o caso dos eventos. Alguém algures, dentro ou fora da organização pode reutilizar esse material para construir um novo serviço, "decoupled" dos plataformas e dos autores das fontes, como deve ser.

5. Simplifiquem, não compliquem. O ser humano é complicado por natureza, temos uma tendência natural para nos metermos em alhadas e depois racionalizar tudo com explicações estapafúrdias. Para quê usar um SQL se o schema não é relacional? O filesystem é das bases de dados mais robusta e testadas do planeta, funciona impecável para queries do tipo chave/valor. Para quê um "full blown Apache Webserver" quando na realidade o que nos interessa é performance HTTP? Talvez um lighty seja mais adequado. Balanceamento Layer4, não será um simples perlbal mais eficaz e robusto do que um dispendioso e obscuro equipamento de rede? Etc.

Para fechar, fica aqui o testemunho de que é possível construir uma arquitectura de um Portal Web completamente distribuída, modular, reutilizável e flexível com produtos Opensource e prata da casa. Não se assustem nem se deixem levar à primeira pelos discursos dramáticos dos consultores e dos fabricantes (so called carrier-grade). A nós deu-nos muito gozo montar isto, agora é deixar amadurecer, aprender um pouco mais, e lançarmos-nos a maiores vôos.

Software Livre: AMA e ESOP assinam protocolo

nospam@example.com (Celso Martinho) — Tue, 15 Apr 2008 18:19:39 +0100

Plano Tecnológico ++

Vídeo, Protocolo.

Modelo3 2008 .app

nospam@example.com (Celso Martinho) — Sat, 29 Mar 2008 22:32:40 +0000

A minha cara metade hoje azucrinou-me o juízo, no bom sentido, para tratar do IRS e não deixar para a véspera do última dia, como é habitual. E lá me convenceu.

Tentei sacar a versão offline da aplicação java da DGCI porque sempre corre fora do browser e posso usar o real estate todo do ecrã. O problema é que o instalador para Mac OSX do .dmg que está na página do e-financas está marado. Testado num iBook G4/PPC e num MacBookPro Intel, nos dois sistemas fez asneira, criou uma directoria a mais, cheira-me que por causa de um "/" mal escapado.

De qualquer maneira nem sei para que raio é o instalador uma vez que aquilo é totalmente self-contained. Vê-se mesmo que foi feito num framework qualquer, install4j a julgar pelo nome da excepção que estava a dar, e que nem sequer foi testado de facto num Mac.

Mesmo correndo o risco de não poder fazer isto, aqui fica o Modelo3.app para download, já composto à mão, pronto a arrastar para /Applications e a funcionar, a quem der jeito.

Qual opt-in

nospam@example.com (Celso Martinho) — Mon, 24 Mar 2008 20:59:43 +0000

Na Keynote da WWDC de 2007 o Steve Jobs disse com um ar matreiro, e cito, "... and we know how to push software, trust me" (or something, mas disse). Quer-me parecer que a Apple aprendeu da pior forma que fazer push de um quicktime que ninguém usa em Windows é diferente de impingir um browser.

Isto é quase tão mau como instalar o Java e levar com uma barra do Google que não pedi. Neste último caso ainda fiquei a pensar uns minutos como é que o trambolho lá foi parar, nem queria acreditar, afinal de contas estamos a falar da mais pura e non-evil das empresas. Ou esperem lá, será que foi quando instalei o player de Flash? Nevermind.

O FSJ ainda não comentou, espero ansiosamente.

GP2X

nospam@example.com (Celso Martinho) — Sat, 22 Mar 2008 00:07:43 +0000

Tenho-me andado a aguentar. Dêem-me bons motivos para não encomendar este delicioso gadget por favor. O raças do brinquedo e mais os seus 2 CPUs corre MAME "full speed" em toda a sua glória (a PSP não consegue, nem de longe). Plus é baseado em Linux em tem o código todo, incluindo o firmware em Opensource. Com todo este poder, não preciso de "yet another encoding profile" para trazer os filmes das crianças para a Arrifana, basta copiar os ficheiros da AppleTV directamente. E então, que argumentos vão arranjar?