blog do chester

Lose It! – perca peso controlando o que você come

chester — Wed, 04 Jan 2012 02:53:35 +0000

Não sou nenhum caso de obesidade mórbida, mas desde uma ocasião em 2007 (na qual achei que ia morrer durante uma partida de DDR), comecei a cuidar melhor da alimentação e da saúde no geral. É possível fazer isso de várias formas, mas monitorar o peso é uma das mais objetivas. E é fácil de acompanhar: basta ter uma balança em casa (e por menos de 50 mangos dá pra comprar uma digital), e registrar todo dia em uma planilha.

Com isso dá pra gerar um gráfico e pisar no freio da comida/acelerador da atividade física sempre que a curva sobe demais. Esta diligência não me impediu de fechar 2011 com uns oito a dez quilos acima do peso ideal, mas tenho certeza que estaria bem pior sem ela. E para matar esse peso extra nos próximos meses, me convenci de que, além de registrar o peso, era importante ter noção do que eu comia.

Novamente eu precisava de uma medida numérica, e para comida, estamos falando de calorias. Mas se já é complicado anotar/planilhar tudo o que se come (mesmo com celular e computador), saber o valor nutricional de cada coisa é ainda mais difícil. Não é à toa que vários websites e aplicativos surgiram para dar conta dessa missão, e o Lose It! foi o meu escolhido.

Ele começou como um (fantástico) aplicativo para iOS, e evoluiu para um site igualmente bacana: o banco de dados de alimentos é bem completo, mas é bem fácil cadastrar comidas novas ou pratos de restaurantes. A interface é excelente, tanto no site quanto no aplicativo (que se sincronizam), e a tudo isso se acrescenta uma rede social bem configurável, que permite compartilhar (ou esconder) qualquer aspecto da sua dieta.

Eu achava que seria impossível cadastrar tudo o que eu como (mesmo restringindo a comidas que, de fato, tenham calorias), mas uma vez que as comidas mais comuns já estejam lá, a busca dinâmica permite acrescentar refeições completas em poucos segundos. O sistema divide o dia em quatro blocos (café da manhã, almoço, jantar e lanches), facilitando a visualização.

Acabei abandonando a planilha e usando ele também para registrar o peso. Isso permite determinar objetivos e estabelecer um “orçamento” de calorias diárias. O site vai acompanhando a perda de peso, e estima a data em que você vai chegar ao objetivo. E à medida em que você vai alimentando o sistema, mais e mais gráficos e relatórios interessantes aparecem. Para arrematar, é possível cadastrar exercícios, considerando o impacto deles sobre a evolução do peso.

Um ponto negativo é ele não suportar o sistema métrico. Mas isso é um problema menor, já que quase sempre a gente lança o consumo em copos, xícaras, doses e outras medidas desse tipo. O mais chato é entrar o peso, mas aí o Google Calculator resolve: uma busca como “80 kg to lbs” dá o valor correto na hora, aí é só copiar e colar.

Algumas pessoas também podem ter dificuldade com os alimentos em inglês – mas o cadastro é tão rápido (basta obter a quantidade de calorias na embalagem ou no Google) que dá pra se virar cadastrando por conta. O que mais me chateou, no entanto, é que o aplicativo Android não pode ser baixado no Market do Brasil.

Críticas à parte, é um sistema gratuito que me atendeu muito bem. Estou realmente confiante em conseguir resultados – se isso vai acontecer mesmo, só o tempo e a balança dirão. Quem quiser conferir pode se cadastrar e acompanhar o meu perfil. Afinal, a minha vida é sempre um livro aberto – mesmo que eventualmente se trate de um livro de culinária…

Exposição Game On no Museu da Imagem e do Som (MIS)

chester — Sun, 04 Dec 2011 23:42:00 +0000

A Game On é uma exposição de origem inglesa sobre a história dos jogos eletrônicos, que visitei no último sábado e gostei bastante. É muito completa e detalhada, apresentando desde os primeiros protótipos até jogos da atualidade, mas o diferencial é a interatividade: a idéia é que os participantes joguem de verdade, sempre que possível no hardware real, proporcionando uma imersão que remakes e emuladores não permitem alcançar.

Na abertura você já se depara com uma máquina de Spacewar e uma de Pong. Deu uma pequena frustração porque nenhuma estava funcionando (apesar de haver um emulador do último projetando na parede), mas só de tocar os controles e ficar em frente a elas já deu para reproduzir a sensação de época como nenhum texto ou documentário permitiria.

Dali pra frente, no entanto, é interatividade total: na primeira área (dedicada aos primeiros arcades) foi obrigatório jogar Asteroids (que controla diretamente o canhão do tubo de TV ao invés de seguir o padrão de scanlines, o que resulta em um visual ímpar), Puck-Man (o original japonês do Pac-Man, ainda que a maior diferença esteja na decoração do arcade, com o Pac-Man narigudão) e vários outros.

As outras áreas são bem diversificadas em termos de épocas, estilos e lugares. Os formatos também variam: tem consoles, computadores pessoais, portáteis, brinquedos eletrônicos, mini-games, enfim, todo o tipo de parafernália, rodando jogos dos mais diversos gêneros. É bem bacana poder brincar com tudo o que a idade, local de nascimento, escolha de plataforma ou grana não permitiram, o que deve tornar a exposição única para cada participante.

Não vou negar que eu e a Bani olhamos metodicamente cada um dos brinquedos, e paramos em todos que tinham algum significado (e vaga). Foi divertido jogar a dois toda a carreira “pré-Super” do Mário (Donkey Kong no arcade e Mario Bros. em um Famicom), além de tirar a curiosidade que eu tinha sobre o Speak & Spell, brincar com o Lemmings num Amiga, ver quão pequenininho é um ZX81 original, digitar alguns comandos no adventure do Guia do Mochileiro das Galáxias rodando em um IBM-PC, e até modernidades como o Child of Eden. E claro, joguei DDR em mais um lugar! :-)

Alguns poucos equipamentos estavam em manutenção, mas a maior parte estava em pleno funcionamento. Uma dica: se o jogo precisa de interação com o console (ex.: apertar o GAME SELECT ou GAME RESET num Atari), procure por fendas nas laterais dos paineis disponibilizando estes botões – a gente deixou de jogar um ou dois até perceber este detalhe.

Como fomos no sábado, estava um pouquinho cheio, mas nada que impedisse de jogar – por mais que os pais trintões e quarentões tentassem mostrar para os filhos o que eles curtiam na época, a molecada focava mesmo nos jogos “modernos”, liberando os clássicos que nos interessavam. Pelo preço da entrada (inteira a R$ 10) vale a pena conferir os dias e horários e voltar quando estiver mais vazio, já que a exposição vai até Janeiro. Sai mais barato que qualquer fliperama e, mimimi de velho à parte, pode ser bem mais divertido.

O que eu quero MESMO ganhar no Natal

chester — Sat, 12 Nov 2011 20:36:01 +0000

Amigos e familiares que eventualmente estejam pensando em me presentear no Natal que se aproxima: eu fico muito feliz com isso, juro. Mas ficarei ainda mais feliz se eu não ganhar um presente. Existe uma explicação científica para isso, mas vocês merecem uma satisfação mais pessoal.

Fato: é complicado presentear, por mais que a gente ache que conheça a pessoa. Você perde um tempão, gasta um dinheirão, e muitas vezes não atinge o resultado esperado. Que tal, ao invés disso, usar esse tempo e dinheiro para ajudar alguém que esteja precisando muito mais do que eu ou vocês?

Não pensem que estou sendo mal-agradecido (ou que vou ficar triste com quem optar por me presentear). O fato é que eu acredito que a redução do sofrimento (pessoal ou alheio) está intimamente ligada à iluminação e à busca pela felicidade. E nada me deixaria mais agradecido do que um esforço no sentido de reduzir – um pouquinho que seja – do sofrimento neste mundo. E eu seria injusto se não deixasse isso claro para todos.

Se vocês acham que é mais fácil comprar um presente, tudo bem. Mas eu duvido: o que não falta é gente precisando de ajuda. A escolha fica a seu critério, mas eu optaria por ajudar uma entidade que promova o bem-estar social (mais do que oferecer assistencialismo não-sustentável) e que não tenha conexão com qualquer religião (durmo melhor sabendo que meu dinheiro está sendo empregado em ações concretas, e não para promover este ou aquele dogma).

Organizações que eu já ajudei incluem a EFF (que defende direitos civis em um mundo cada vez mais digital) e a Kiva (que faz microcrédito, ou seja, empresta dinheiro para gente simples, que trabalha por conta e precisa investir pequenas quantias nisso). Não sei de organizações no Brasil que façam esse tipo de coisa – se alguém souber, por favor me diga!

Se preferirem fazer uma coisa mais “hands-on”, mais com cara de natal, uma opção é ajudar o Papai Noel dos Correios: vocês escolhem uma carta, providenciam o presente/resposta, e os Correios cuidam da entrega. Esta atitude, embora não seja tão eficiente quanto o que uma instituição faria, leva um pouco de alegria para uma família que provavelmente estava precisando bastante.

Outra idéia é ajudar a manter produções culturais e artísticas que você consome gratuitamente ao longo do ano. A Wikipedia é um deles (e explica bem por que é razoável contribuir), e basta prestar atenção quando você navega que vai encontrar outros. Devo atualizar este post com outros sites que me vierem à cabeça, mas convido o leitor a dar sugestões no campo de comentários abaixo.

Qualquer que seja a sua escolha, eu agradeço de verdade. Se tem alguma coisa muito melhor do que desejar um “Feliz Natal”, sem dúvida é ajudar a construir um!

sorteio2600

chester — Mon, 07 Nov 2011 02:08:56 +0000

O sorteio2600 é um programa que eu fiz para o Dev In Vale, por sugestão do Willian Fernandes, um dos organizadores do evento. Já que eu já ia demonstrar o Hello World em um Atari de verdade (graças ao Harmony), e a minha palestra era a última, a idéia era aproveitar o setup e fazer o sorteio dos brindes no próprio Atari.

Pensei que seria uma tarefa fácil, mesmo numa plataforma tão limitada, mas levei umas vinte horas ou mais quebrando a cabeça para que o programa saísse! Este post comenta o processo de desenvolvimento e no final mostra um vídeo do software rodando no Atari. É recomendável ver os slides ou assistir à palestra para entender melhor, mas talvez dê pra acompanhar sem isso.

Dígitos na tela ⇒ Python ao resgate

O ponto de partida foi o Hello World da palestra (que escreve uma frase na tela usando o playfield, isto é, os 20 “pixels largos” que ocupam a parte esquerda da tela do Atari, repetidos no lado direito). Usando o score mode, é possível esconder um dos lados (colocando nele a mesma cor do fundo), e usando 6 pixels por dígito seria possível representar os três dígitos necessários para escrever um número entre 000 e 999.

O problema com essa idéia é que dígitos não se alinham com os registradores do playfield (PF0, PF1 e PF2). Veja na ilustração como eles precisam ser posicionados:

Seria necessário fazer vários shifts para combinar os dígitos nos registradores, e, além disso, temos o fato de que o PF0 e o PF2 são lidos “ao contrário” (com o bit menos significativo à esquerda). Era muita manipulação pra fazer on-the-fly, então resolvi que, ao invés de uma única tabela de bitmaps dos dígitos, eu teria duas tabelas para o dígito das centenas (uma para o PF0 e outra para o PF1), duas para o das dezenas (uma para o PF1 e outra para o PF2) e uma para a unidade (que fica inteira no PF2).

As tabelas já teriam as inversões e shifts pré-executados, tornando a operação de escrever o PF1 e o PF2 tão “simples” quanto ler um valor, combiná-lo com outro (via operação OR ou soma) e armazenar. O PF0 teria só uma leitura e armazenamento, e isso tudo poderia ser feito na scanline enquanto o canhão está do lado esquerdo da tela (que não seria usado de qualquer forma, já que eu queria os dígitos no lado direito).

Calcular essas tabelas de bits manualmente seria um porre, mas eu não precisaria fazer isso, já que tenho um computador: fiz um script Python que lê os bimaps dos caracteres “0″ a “9″ e gera o .asm com as tabelas descritas acima (recorrendo novamente à fonte do ZX Spectrum, que já tinha transcrita em hexadecimal no tilewriter).

Score Mode

Teria sido um plano perfeito, não fosse por um detalhe: o score mode foi feito para desenhar placares, não para dividir perfeitamente a tela. No emulador tudo funcionava bem, mas no Atari de verdade o TIA muda a cor um pouco antes do esperado, fazendo com que um pedaço do playfield esquerdo apareça onde não deveria.

Se eu soubesse disso antes, teria usado menos bits, mas com o programa já escrevendo os caracteres na tela, apelei: estiquei o missile 0 (que já tinha a mesma cor que o fundo da tela) e posicionei de forma a cobrir a parte da tela onde aparece o lixo. Não é a solução mais limpinha do mundo, mas funcionou bem.

Etapas do sorteio

Com tudo isso eu já tinha um programa que escrevia dígitos arbitrariamente na tela. A partir daí, se eu incrementasse o número a cada scanline não utilizada, eu teria eles mudando na tela em alta velocidade, dando um efeito de sorteio. Incrementando a cada frame (ou a cada n frames) eu podia reduzir a velocidade, o que me levou a dividr o programa em quatro “modos”:

Modo select: Mostra os dígitos correspondentes ao limite máximo do sorteio. Pressionar GAME SELECT em qualquer outro modo muda para este, e pressionar novamente GAME SELECT incrementa o limite máximo (de 100 em 100).
Modo rodando: Acionado pelo GAME RESET, este modo incrementa o número a cada scanline, conforme descrito acima. Aqui surgiu um dos bugs mais difíceis de encontrar: eventualmente eu usava duas scanlines (por conta do “vai um”) sem contabilizar, gerando uma tela com scanlines a mais. Isso fazia o vídeo tremer, por perder a sincronia.
Modo parando: Passsa a valer se o jogo estiver no modo rodando e o usuário apertar o botão do joystick. Ele incrementa o número a cada n frames, começando em 2 e aumentando aos poucos. Com isso, os números vão avançando cada vez mais devagar por uns poucos segundos, simulando o efeito de uma roleta parando (confesso: a minha inspiração foi a memória do Roletrando nos anos 80!)
Modo parado: Quando o atraso de frames do modo parando chega a um limite, é hora de parar e declarar um número vencedor. Para isso o programa muda para este modo, permanecendo nele até um novo GAME RESET.

Números (pseudo-)aleatórios

Mesmo implementando todos esses modos, ainda havia um problema: a pseudo-aleatoriedade seria garantida pelo fato de um tempo indeterminado se passar entre o GAME RESET e o botão do joystick ser pressionado, e neste tempo incrementarmos o número sorteado a cada scanline fora do desenho. Isso tem um problema: se temos k scanlines livres na tela, o sorteio avança de k em k números, e dependendo dos divisores comuns entre este número e o limite superior do sorteio, o mesmo ficaria limitado a um subconjunto de números.

Como o limite superior varia, o melhor jeito de evitar o problema era inicializar o contador com um número pseudo-aleatório “de verdade”. Para isso, a solução foi introduzir um contador de um byte na RAM, incrementado a cada frame enquanto o console estiver ligado, e usá-lo para inicializar a dezena e unidade do número sorteado. Um truque bacana foi fazer este incremento usando o modo decimal, ou modo BCD do 6502. Com isso, cada nibble do contador contém um dígito de 0 a 9, e pode ser usado diretamente para inicializar a dezena ou a unidade.

Som

Com isso, faltava adicionar um efeito sonoro que complementasse o sentimento de “roleta”. Não falei sobre som na palestra, mas a teoria é simples: o TIA tem dois circuitos de som independentes, e pra cada um você pode escolher o volume, a frequência e o tipo de som, escrevendo nos registradores apropriados.

É preciso usar alguns dos minguados ciclos para gerenciar isso, e a produção de músicas é dificultada pelo fato de as frequências não baterem com uma oitava musical “tradicional”. Mas para esse programa não foi um problema: fiz um tom curto e grave ser acionado a cada frame em que ocorre uma mudança de dígitos. O resultado é um ronco de motor meio Endurozento no modo rodando e um tuc-tuc-tuc no modo parando, o que serviu bem ao propósito.

Cores e o resultado final

O toque final foi acrescentar cores: deixei uma diferenciada para o modo select, e no modo parado eu reutilizei o contador de frames para mudar as cores constantemente (se não fosse o BCD, creio que ficaria parecido com o cálice do Adventure). Isso deixou o programa pronto para usar, e o pessoal do evento curtiu o sorteio feito de forma tão inusitada. Veja ele em ação:

Normalmente eu programo com um pouco mais de planejamento, mas no Atari as limitações do hardware fazem com que qualquer coisa além de uma idéia inicial viável tenha que ser decidida conforme os recursos vão permitindo. Foi assim que David Crane criou o Pitfall! – ele tinha um esquema pra fazer um homenzinho correndo, e queria bolar um jogo usando isso:

Eu sentei com uma folha de papel em branco e desenhei um homenzinho no meio. E disse, “Ok, eu tenho um homenzinho que corre, vamos colocá-lo em um caminho [mais duas linhas desenhadas no papel]. Onde fica esse caminho? Vamos colocá-lo em uma selva [desenho umas árvores]. Por que ele está correndo [desenho tesouros a coletar, inimigos a evitar, etc.]?” E o Pitfall! nasceu. Todo esse processo levou uns dez minutos. Cerca de 1000 horas de programação depois, o jogo estava pronto.

David Crane, em entrevista de 2003

Harmony: rodando jogos (e testando programas) num Atari de verdade

chester — Sat, 05 Nov 2011 02:30:07 +0000

A programação para Atari 2600 é uma curiosidade que já me levou a escrever artigo e minstrar palestras sobre o assunto. Vira e mexe estou lendo e experimentando, e até acredito que um dia alguma dessas brincadeiras pode se tornar um jogo de verdade.

Um bom emulador é necessário para programar para qualquer dispositivo, seja ele um celular ou um console. O Atari tem o excelente Stella (cujo debugger é bom até para quem só quer entender como algum jogo funciona). Mas é igualmente importante testar o programa no console “de verdade”, pois só lá os detalhes vão aparecer.

Foi com esse objetivo que eu encomendei o Harmony. Em termos simplificados, é um cartucho com slot para cartão SD, que disponibiliza os jogos (ROMs) gravados no cartão através de um menu no console. Comparando com aqueles cartuchos com 2 ou 4 jogos selecionáveis através de chaves, é uma evolução incrível.

Como tudo que é simples, tem uma engenharia sofisticada por trás. As especificações mostram que, só em termos de clock, a CPU do cartucho é 70 vezes mais rápida que o do videogame (na prática a diferença é ainda maior, afinal, é uma arquitetura ARM de 32 bits contra um 6502 de 8 bits). Talvez não precisasse de tudo isso, mas um hardware mais generoso pode embarcar um software que reconhece dezenas de formatos de ROMs, e que pode ser atualizado com faclidade.

Para mim foi útil logo de cara, porque o “Hello, World” que eu apresentei no Dev In Sampa nunca tinha rodado em um console de verdade, e eu não acreditava que acertaria de primeira. Dito e feito: eu não zerei os registradores do TIA (chip de vídeo) correspondentes aos objetos visuais que não estava usando, e eles apareciam como “lixo” na tela. Este problema não acontecia no emulador, porque ele zera a memória emulada ao inicializar. Felizmente a correção foi fácil, e já foi aplicada nos slides e no código-fonte.

Ele também foi útil para viabilizar o sorteio2600, um programinha que sorteia números entre 0 e uma centena qualquer (100, 200, 300, etc.), feito especialmente para o Dev In Vale. Novamente, entre o emulador e a vida real havia uma diferença: o score mode, que divide o fundo (playfield) monocromático em duas cores (uma à esquerda e outra à direita) não faz essa divisão de forma 100% precisa (a cor muda um tiquinho antes da hora).

Como os projetistas de jogos já sabiam disso (dificilmente usariam emuladores naquela época), eles não usavam o playfield todo quando habilitavam o score mode. Mas o meu código já tinha sido pensado para sumir com metade dele (e usar toda a outra metade), então eu “roubei”, usando um dos missiles para cobrir a parte do playfield que não deveria aparecer. Isso está documentado no código, e fica como mais um exemplo dos truques que eram necessários para fazer o hardware limitado do Atari 2600 atender às necessidades de cada jogo.

Se interessar, veja mais fotos do Harmony em ação.

(esse post pede um agradecimento especial ao Alexandre Oliveira, que me cedeu vários cartuchos de Atari para testar o console “novo”, evitando que eu procurasse problemas onde eles não existiam)

Micro Men – o “Pirates of Silicon Valley inglês”

chester — Tue, 01 Nov 2011 08:30:12 +0000

Durante a explosão da microinformática nos anos 80, a Inglaterra era um dos poucos países (o Japão seria outro) nos quais os computadores eram projetados de forma independente dos EUA. Ali, Sir Clive Sinclair se destacou ao criar os primeiros computadores pessoais realmente acessíveis, o que lhe rendeu o título.

A disputa entre a Sinclair Research e a Acorn (ou, especificamente, entre Clive e Chris Curry, ex-funcionário do primeiro e um dos fundadores da Acorn) para decidir quem iria fabricar o computador que levaria a marca da BBC é o mote central de Micro Men, um documentário dramático que começa nas primeiras inovações de Sinclair (calculadoras de bolso e relógios de pulso digitais) e vai até os finalmentes das duas empresas, retratando o “estouro da bolha” que viria nos anos seguintes.

Embora a relevância da disputa possa parecer um pouco exagerada (ainda mais ao considerar que o filme é produzido pela própria BBC), o fato é que o vencedor teria não apenas um contrato gigante para colocar micros em todas as escolas britânicas, mas também ganharia a chance de educar uma geração inteira usando seus produtos. A importância disso fica evidente quando se observa quão bem esta mesma oportunidade foi aproveitada nos Estados Unidos por ninguém menos que a Apple.

Outro ponto que poderia ser questionado é a colocação da Acorn no mesmo nível de destaque que a a Sinclair, considerando que seus micros pouco apareceram fora da Inglaterra. Mas vale lembrar que eles foram os criadores do que viria a se tornar o processador ARM (que muito provavelmente está no seu bolso neste instante, já que sua arquitetura é uma das mais populares em smartphones).

O começo do filme é um pouco confuso (e parado), mas o contexto vai ficando mais claro, e o ritmo também melhora muito. Ele inclui momentos clássicos, como a famosa briga no Baron Of Beef, e no final é uma experiência muito divertida para quem curte a microinformática “raiz” e quer saber mais sobre as pessoas por trás dos micros – em particular quem teve um TK ou equivalente nos anos 80.

Chester em Hollywood (e no set do The Big Bang Theory)

chester — Sat, 01 Oct 2011 21:30:12 +0000

Não sei bem como introduzir o assunto, então vou direto ao ponto: ganhei um concurso do Warner Channel, que levou eu e a Bani até Hollywood para, entre outras coisas, assistir à gravação do The Big Bang Theory. E o melhor: pudemos tirar várias fotos, bater na porta da Penny e até sentar no sagrado lugar do Sheldon!

O concurso pedia para responder à pergunta: “Por que você acha que a série The Big Band Theory merece ganhar um Emmy?”, e eu não lembro das palavras exatas da minha resposta – mas foi na linha de “porque ainda não inventaram um Prêmio Nobel de Comédia”. Além da frase, era preciso responder a um questionário nada trivial sobre o Emmy, mas com esmero e a ajuda do IMDB, eu e a Bani concluimos a tarefa e esquecemos o assunto.

O aviso da vitória veio em um momento crítico: eu entraria em cirurgia no dia seguinte – nada muito sério, mas o passeio dependia de um OK do médico, e este de uma recuperação sem complicações. Ambos vieram e zarpamos para a cidade das estrelas.

Hollywood, Beverly Hills, etc.

Ficamos hospedados no Reinassance Hollywood, que além de confortável é bem localizado: fica no mesmo complexo que o Kodak Theatre – o lugar onde é feita a entrega do Oscar. A Bani aproveitou e comprou ingressos antecipadamente para o Iris, o recém-inaugurado espetáculo do Cirque du Soleil cuja temática é justamente o cinema. Estava uma bela bagunça na Hollywood Boulevard por conta da estréia, mas isso não impediu a gente de encontrar um protesto do Anonymous.

A visita a Hollywood pedia um tour em Beverly Hills para ver as mansões dos famosos (por menor que seja minha identificação com esse mundo), além de inúmeras locações de filmes e pontos relacionados a cinema e televisão. Juntado isso com uma passeadinha pela calçada da fama (que era bem próxima), deu para preencher bem o “lado Hollywood” da visita. Só lamento ter trocado uma visita ao Madame Toussauds (museu de cera) por uma ao Acredite Se Quiser, que se revelou bem fraquinho.

Como eu estava em pós-operatório, limitamos os passeios a pé a uma tarde no downtown. Começou muito bem no Little Japan, onde comemos e compramos, mas ficou desagradável no Toy District. O nome e os guias sugeriam uma espécie de Fao Schwartz a céu aberto, mas a vizinhança se revelou qualquer coisa entre uma 25 de Março e a Boca do Lixo paulistanas. Sério.

Recuperamos o entusiasmo no Universal Studios CityWalk, que conta com excelentes opções de compras, balada e comida. Jantaríamos fácil ali, mas a falta de supervisão adulta inviabilizou o plano em algum ponto entre a loja especializada em pipoca e o frozen yogurt da Hello Kitty. É um passeio de fácil acesso – basta pegar o shuttle gratuito em frente ao metrô (sim, a cidade das estrelas tem transporte público).

E por falar em comida, a limitação de mobilidade foi compensada pela proximidade de boas opções a preços quase que baratos (comparando com bons restaurantes paulistanos, por exemplo) como o restaurante da revista Rolling Stone e o The Grill (dica: Fish and Chips).

Gravação do TBBT

O último dia abriu com pompa e circusntância: nós e os outros ganhadores fomos levados de limusine até os estúdios da Warner, onde fizemos o passeio que mostra coisas como a caixa d’água onde os Animaniacs moram, a casa da Lorelai Gilmore, um General Lee e uma infinidade de outros artefatos que até então pertenciam ao reino da ficção. Um dos depósitos tinha a mobília do Central Perk guardada, e a gente conseguiu uma foto no sofá da abertura do Friends.

Mas o melhor ainda estaria por vir: no final do dia fomos assistir à gravação do TBBT. As gravações geralmente são à noite para que os atores possam memorizar falas durante o dia, e a presença da platéia tem duas funções: gravar as risadas e dar aos atores a oportunidade de sentir o timing das piadas. Naquela noite eles gravaram um episódio inteiro (exceto por uma cena externa) e ainda deu tempo de assistir ao vídeo do episódio anterior – possivelmente para gravar risos adicionais.

Eles gravam tudo na ordem da história, e não é picadinho: a tentativa no geral é fazer a cena toda de cada locação de uma vez só. Para isso usam quatro câmeras, sendo pelo menos uma móvel, e quando erravam (a Kaley Cuoco engasgou uma hora, tadinha) voltavam um pouquinho, com raros cortes do diretor. Tudo é filmado pelo menos duas vezes (com ajustes e improvisos eventuais de uma para outra), e a gente dava risada em ambas – porque ao vivo é ainda mais engraçado.

Após a gravação o público se engalfinhou para conseguir autógrafos de um elenco visivelmente cansado. Nem encanamos, até porque o que viria em seguida seria bem mais legal: apesar da proibição de fotografia nos estúdios, como convidados nós pudemos fotografar o cenário à vontade.

Os atores já tinham ido embora, mas conseguimos foto com o físico do seriado: o Prof. David Saltzberg, PhD em Física e consultor que cuida da qualidade científica das piadas e até faz as fórmulas nas lousas! Ele mantém um blog muito bacana, que entra nos detalhes da ciência por trás de cada episódio da série.

No final foi uma experiência ímpar, e só posso deixar meus sinceros agradecimentos ao pessoal da Warner que nos premiou e acompanhou. Sentar no lugar do Sheldon definitivamente não tem preço, e lembre-se: quando assistir ao quinto e ~~sexto~~ sétimo episódios da quinta temporada, você estará ouvindo, entre outras, as nossas risadas!

O Dia da Boa Notícia

chester — Mon, 12 Sep 2011 04:14:31 +0000

Esta época sempre me lembra uma história trágicômica dos primeiros anos do iG. Quando ela aconteceu eu era programador na equipe que cuidava, entre outras coisas, do sistema de publicação do Último Segundo, jornal online no qual se deu o “causo”.

Uma experiência que se tornou recorrente no portal foi a criação de campanhas temáticas que, durante um período de tempo, customizavam a cara e o conteúdo de um ou mais sites. No embalo de um sucesso anterior (creio que ligado a animais de estimação, não lembro ao certo), surgiu a idéia de criar uma data comemorativa: o Dia da Boa Notícia.

O mote: a imprensa só publica assassinatos, guerras, aumentos de impostos e coisas assim, e um dia em que se lesse apenas boas notícias seria uma mudança de ares. Além disso, o Último Segundo contaria com matérias especiais, que falariam de ONGs ou qualquer outra coisa “do bem” e seriam marcadas no publicador para aparecer com um destaque BOA NOTÍCIA bem chamativo.

Vários jornalistas foram contra – uma notícia é uma notícia, e não achavam certo deixar de noticiá-la, ainda que por uma boa causa. Mas a determinação foi mantida, e preparamos o sistema para operacionalizá-la. O teste de fogo do plano veio na madrugada, com o assassinato de um político, mas a direção do portal foi firme e resolveu manter a diretriz, não veiculando a notícia. A crise da madrugada foi superada, e o plano parecia infalível.

A alegria durou pouco: logo pela manhã aconteceu outra notícia nada boa: um avião se chocava contra uma das torres do World Trade Center, em Nova York. Isso mesmo, era o dia 11 de Setembro de 2001! A CNN reduziu sua pagina a uma foto e uma manchete, e os portais (incluindo a gente) lutavam para atender à enxurrada de pessoas que procuravam notícias em tempo real.

Os editores estavam a mil por hora, e pediram o ligamento e desligamento do “modo boa notícia” tantas vezes que o sistema mal tinha tempo de atualizar os caches entre uma ação e outra. Eventualmente decretou-se o fim da data comemorativa e o assunto permaneceu como tabu durante um bom tempo, mas sua sombra nos manteve cautelosos. Afinal, sempre existe o risco de se escolher justo o dia em que quase começa a terceira guerra mundial para não dar más notícias…

DISCLAIMER: Este relato não pretende qualquer desrespeito àqueles que perderam entes queridos nesta tragédia, tampouco aos profissionais de jornalismo do iG, muitos dos quais me ensinaram bastante sobre o assunto, só aumentando o orgulho de ter feito parte da “família do cachorrinho”. É só uma história que eu não quis deixar passar em branco.

Palestra sobre Programação para Atari 2600 no Dev in Sampa 2011

chester — Sun, 28 Aug 2011 05:21:44 +0000

O Dev in Sampa é um evento bacana, por conta do blend muito equilibrado entre aprendizado e networking. A edição deste ano foi, a meu ver, ainda melhor que a do ano passado – os organizadores (@tinogomes, @nuxlli e @lfcipriani) e o pessoal de apoio da Abril estão de parabéns. Gostei da decisão de reverter ao formato de trilha única de palestras, que limita a quantidade de vagas mas mantém o nível alto e ajuda a galera a se manter na mesma estação.

Das palestras que eu vi, destaco o @shiota despertando o lado designer dos programadores, o convite do @klauswuestefeld a repensar o compartilhamento de informações e o @qmx destrinchando a JVM. E dessa vez eu também palestrei, falando sobre Programação para Atari 2600:

Foi uma palestra bastante difícil de encaixar no tempo, porque a proposta era habilitar o público a compreender a totalidade de um programa “Hello, World!” para Atari, e para isso foi preciso mostrar os elementos básicos do chip de vídeo TIA (usando jogos clássicos para mostrar como eram aplicados) e também dar uma visão rápida do Assembly 6502/6507. Mas o pessoal curtiu, o que me deixou MUITO feliz. :-)

UPDATE: Saiu o vídeo da palestra – obrigado, @agaelebe pela edição! Confira abaixo ou no blip.tv:

Recomendo um passeio nos links do finalzinho (slide 138) para quem quiser se aprofundar mais no assunto (alguns já foram comentados neste blog, como o livro Racing the Beam)~~, e creio que em breve os vídeos das palestras devem ser disponibilizados~~. Reitero os parabéns e agradecimentos à organização do evento, e espero ver esse povo todo lá no ano que vem!

Clean Code (Código Limpo), por Robert “Uncle Bob” Martin

chester — Sun, 14 Aug 2011 21:39:51 +0000

Já observei que a maior parte dos programadores com algum tempo de estrada tende a se acomodar, acreditando que o que quer que fosse estado da arte (ou apenas popular) quando a pessoa era ultra-jovem é a verdade absoluta e inenarrável. Não sei se por preguiça, insegurança, ou cansaço, mas muita gente, depois de um tempo, se recusa a a aprender qualquer tecnologia, paradigma ou modo de trabalho novo, em muitos casos se afastando da programação porque já “aprendeu tudo”.

Robert C. Martin é tiozão, assim como eu. Talvez um tiquinho mais: ele até adotou o nick “Uncle Bob”, me fazendo pensar se eu não vou virar o “Tio Chester” logo, logo. Mas, tabmém como eu, ele não é acomodado. Muito pelo contrário: entre seu tempo de consultor, desenvolvedor e autor, ele foi um dos criadores do Manifesto Ágil, e, mais recentemente, ajudou a consolidar o termo “Artesanato de Software” (Software Craftsmanship).

Artesanato, de fato, descreve o dia-a-dia da imensa maioria dos programadores profissionais de forma muito mais completa do que as metáforas tradicionais que giram em torno de engenharia ou administração, reaproximando o ofício das suas raízes na computação, mas levando em conta o aspecto de criação, qualidade e atenção ao ser humano que está na “outra ponta”. Uncle Bob postula com muita propriedade que a adoção de uma política de aprendizado constante e qualidade total é fundamental para um profissional digno do nome – em um bate-papo com o Fábio Akita ele compara o desenvolvimento de software com a medicina, ilustrando muito bem a questão.

O Clean Code é um guia sobre um aspecto fundamental da atividade: a criação de código limpo. Mesmo tendo bastante experiência e escrevendo código que eu julgava muito limpo e bem documentado, o livro me mostrou diversas maneiras de escrever código que seja mais fácil de ler e manter. O autor adverte: você pode não concordar com todas as sugestões dele, e provavelmente vai discordar de forma veemente de uma ou duas (no meu caso: deixe meus parâmetros booleanos em paz :-P). Mas o espírito é que conta.

Ele vai a fundo em uma série de aspectos – quase todos são possivlemente pequenos detalhes, mas a atenção ao conjunto cria programas que dão orgulho para quem faz e alívio para quem mantém. Os exemplos todos são baseados em Java, mas compreensíveis para qualquer um que tenha conhecimentos básicos de orientação a objeto, e quase todos são aplicáveis a qualquer linguagem.

Comportamentos enraizados no Java (ex.: JavaDoc, encapsulamento via getters/setters) são analisados com a mente limpa, na tentativa de separar o mito da realidade no que diz respeito aos benefícios reais (e possíveis malefícios) de cada um deles. Eu certamente revi meus conceitos quanto à maneira de nomear e dividir os artefatos dentro do meu software, e recomendo o livro para qualquer um que leve a programação a sério, independente da experiência ou área de atuação.

Li a versão Kindle que, apesar de não usar formatação monoespaçada para o código, foi bem confortável de ler, até mesmo no iPod Touch (meu companheiro do ônibus/metrô). Existe uma versão nacional (“Código Limpo”), mas não sei quão boa é a tradução. Qualquer que seja o formato ou idioma, só não recomendo a leitura se para você programação é só um day job, ou se você acha que o seu jeito é o jeito certo, e todo o resto é modinha. Neste caso, eu torço muito para que a gente se encontre na rua ou na balada, mas jamais em um projeto de software.