Serviços Digitais da Americanas

June 25th, 2005 § 2 comments § permalink

Eu devo ser o último a saber, mas as Americanas lançaram serviços digitais muito interessantes: um serviço de relevação de fotos digitais, um serviço de músicas (nos moldes do iTunes e Yahoo! Music) e um serviço de ring tones para celulares. Por si só, nenhum desses serviços é novidade, mas o site da Americanas é bem popular e conta muito em termos de popularização. Obviamente, as músicas tem DRM e duvido que isso vá mudar logo, mas já é um começo.

Tao

June 24th, 2005 § Comments Off on Tao § permalink

Já faz um bom tempo que eu estou mexendo com sistemas Unix ou baseados no mesmo e eu ainda me espanto com a filosofia diferente dos mesmos, que propicia um modo de pensar e agir tão distintos de outros sistemas operacionais.

Eu estava fazendo a migração de um sistema de um servidor para outro e, por razões diversas, praticamente todas as páginas do sistema precisavam ser modificadas. O que, em um sistema Windows, seria uma questão de usar vários programas completos, se resumiu a dois comandos no shell do Debian. Um wget recursivo para baixar o sistema de um servidor para outro e um rpl igualmente recursivo para alterar as páginas. Direto no servidor, sem intermediação. O uso do wget vem do fato de que eu não tinha acesso ssh ao outro servidor do momento, somente FTP.

Imagine-se fazendo a tarefa acima no Windows. Se você tivesse acesso remoto ao servidor, ainda assim seria obrigado a ter um programa FTP instalado que lhe permitisse fazer o download completo do sistema no outro servidor. Seria necessário então usar um editor de texto qualquer com suporte a pesquisa e substituição recursiva em diretório. Não que seja difícil encontrar ou instalar tais programas. O problema é ter que instalá-los. Sem acesso remoto seria ainda mais trabalhoso considerando que o Windows não tem nada equivalente a um simples ssh.

É claro, você pode simular um ambiente Unix no Windows. Mas a trindade poder-flexibilidade-facilidade que eu valorizo extremamente em qualquer ambiente computacional não é inerente ao Windows como o é para o Unix.

Código aberto e o Brasil

June 23rd, 2005 § 3 comments § permalink

Toda essa discussão sobre o uso de aplicações de código aberto por parte do governo brasileiro me parece uma grande bobeira algumas horas. Por mais que os zelotes defensores do código aberto digam que sim, o governo não entende nem de longe a questão em si — com ou sem Gilberto Gil. Eu sou um defensor do código aberto, mas acredito que a postura do governo é equivocada e, a longo prazo, até prejudicial ao Brasil.

Existem dois tipos básicos de aplicações de código aberto: as que foram criadas porque uma necessidade qualquer chegou ao ponto de superar a inércia da formação de uma comunidade de desenvolvimento — caso do Gaim, JBoss, Apache e por aí vai — e os que foram criados simplesmente para acabar com um coceira qualquer.

A diferença fundamental entre os dois é que o primeiro consegue se manter de pé sozinho, formando um ecossistema ao seu redor, com parasitas e forks em igual medida, mas mantendo a visão original dentro dos parâmetros de continuação do projeto. O segundo, ao contrário, move-se fortemente no começo, de uma maneira geral, mas depois começa a soltar só fumaça e no final cai em um ritmo ocasional de atualizações que não fazem nem muita diferença no produto final.

O primeiro tipo de projeto, onde pode se encaixar nas necessidades do governo, é muito interessante. Como qualquer negócio, o governo está mais interessado em estabilidade e manutenção. O segundo tipo de projeto, nesse sentido, é até prejudicial para a estrutura tecnológica do governo, incluindo a possibilidade de reinvenções seguidas da roda — algo que já é, por si só, muito comum nos meandros tortuosos da burocracia.

Assim, a escolha do código aberto apenas pelo aspecto aberto (e, possivelmente, pelo grande interesse no aspecto gratuito da vasta maioria desses projetos) pode, a longo prazo, se converter em um problema para o Brasil. O governo sente muitas coceiras, mas coceiras não são a melhor área de atuação do código aberto.

Eu sei de pelo menos um exemplo em que o governo adotou uma base de código aberto e tentou torná-la uma aplicação decente. O resultado foi uma massa de código difícil de manter e ler — e isso só depois que a metade do código foi reescrita.

Além disso, existe outra questão fundamental, a do mercado interno. Não há como esperar que todas as empresas se transformem em filantropias, decidindo liberar todo e qualquer projeto — mesmo os altamente customizados — como código aberto. Existem tipos de sistemas para os quais o código aberto não é aconselhável. Sistemas especializados, de uso restrito, não ganham nada sendo código aberto.

Uma decisão unilateral em favor do código aberto pode eventualmente prejudicar o desenvolvimento de tais sistemas com conseqüente aumento de custos e diminuição de qualidade. Um WordPress pode funcionar como um sistema de gerência de conteúdo, com workflow embutido? Pode, de maneira simplificada. Pode, então, ser customizado para a tarefa? Sim, mas tornando-se mais frágil, levando a dependências que podem não interessar ao projeto principal e que tornam futuras manutenções mais complicadas, efetivamente criando um produto diferente.

Nessas situações — e, principalmente, aquelas que envolvem integração com sistemas legados — eu não vejo problema algum em fomentar uma indústria nacional que não se sinta na obrigação de usar ou desenvolver código aberto meramente porque parece ideologicamente mais saudável ou porque o custo parece a princípio menor.

É claro, eu imagino que existam pessoas no governo que estão pensando seriamente nesses aspectos. Eu duvido que um Sérgio Amadeu seria tão descuidado a esse ponto. Mas como os zelotes estão sempre à solta, não custa falar um pouco mais sobre o assunto.

Neverwhere

June 22nd, 2005 § Comments Off on Neverwhere § permalink

Como eu tinha mencionado em uma entrada anterior, não demorei muito e comprei o Neverwhere, do Neil Gaiman. Como eu tinha previsto também, gostei mais do American Gods do que dele.

O motivo não é nem tanto que American Gods é melhor construído, ou coisa assim. Tem mais a ver com o fato de que Neverwhere parece uma introdução, ou uma primeira tentativa do que mais tarde seria o American Gods. As estórias têm tanto em comum que ler as duas com um intervalo tão pequeno entre as mesmas tirou um pouco da diversão.

Dito isso, Neil Gaiman continua a mostrar o seu talento como autor de contos-de-fadas modernos, cuja mágica está explícita em cada página. É impossível não ficar surpreendido, não se fascinar com os personagens e situações. Mesmo sendo um livro bem menor do que American Gods, Neverwhere consegue atingir a mesma verossimilhança do primeiro em termos da construção de um mundo imaginário completo.

Em Neverwhere, nós temos a estória de Richard Mayhew, um inglês to interior que se mudou para Londres procurando um trabalho melhor e cuja vida pacata e comum parece estar se encaminhando na direção ideal. Seu trabalho é bom, sua noiva é perfeita e tudo está dando certa para ele. Até que, em uma noite, ele topa com uma jovem caída no passeio perto de sua casa. Ele ajuda a jovem, que está ferida e amedrontada, e sua vida se transforma completamente. De repente, ninguém mais o conhece e ele parece não mais existir, exceto para os misteriosos habitantes de uma outra Londres, a Londres Abaixo. Recrutado para uma causa em que ele não acredita, Richard Mayhew precisa aprender a lidar com o perigoso mundo em que se encontra se espera sobreviver por mais do que algumas horas.

Em sua Londres Abaixo, Gaiman cria uma versão convincente do subsolo da cidade, um lugar extraordinário, povoada de criaturas míticas cujas vidas se passam completamente às margens da Londres Acima. A exemplo de outras cidades famosas na literatura, Londres Abaixo é complexa e multifacetada, com surpresas que espreitam em cada canto. Obviamente, para um leitor londrino, as referências são bem mais óbvias, mas Gaiman tomou o cuidado de criar versões diferentes do livro para outros públicos, com mais explicações e passagens mais explícitas.

A vontade que me deu depois de ler o livro foi ver a séria de TV da qual o mesmo derivou. Mesmo sendo bem mais condensada, uma representação visual depois do livro certamente teria seus méritos.

Com mais um livro do Gaiman na coleção, é hora de comprar Coraline. Julgando-se pelos outros três, não há chances de que eu fique desapontado.

Alguém tem mais?

June 22nd, 2005 § 2 comments § permalink

Durante os últimos dez anos, eu fui acumulando contas de e-mail a torto e a direito. Algumas grátis, outras pagas — aliás, quem é que paga para ter conta de e-mail hoje? — e dessas, quatorze permaneciam ativas por razões diversas.

Depois da Grande Reformatação Inadvertida do Sistema, eu decidi reduzir as contas ao ver o trabalho que dava para configurar tudo. Além disso, verificar e filtrar todas essas contas está ficando trabalhoso demais, sem contar que algumas delas servem basicamente para ensinar o filtro sobre o que é spam, de tanto lixo que eu recebo.

Só para começar, eliminei oito delas, que eram perfeitamente inúteis. Algumas delas, que estão no meu servidor mesmo, foram criadas para alguma necessidade específica que nem existe mais e não faz sentido mantê-las apenas porque uma ou duas pessoas podem eventualmente usá-las.

O resultado é que agora eu só preciso verificar duas contas pessoas, que servem propósitos bem definidos. Também troquei todas as contas POP3 por IMAP4. IMAP4 tem suas falhas, mas elas são compensadas pela centralização dos dados e por evitar perdas de backups locais.

Bom. Agora eu só preciso achar um cliente IMAP decente. O Evolution é bom com POP3, mas não gostei para IMAP4. O Thunderbird é interessante, mas a interface precisa melhor um pouco. Não que eu me importe em testar novos programas, de qualquer forma.

Perigos em gerar HTML

June 21st, 2005 § 9 comments § permalink

Em dez anos de trabalho com a Web, uma coisa eu aprendi: nunca confie em uma biblioteca para escrever HTML para você. Quando mais eu mexo nessa área, mais me convenço de que essa é uma boa regra. Qualquer biblioteca que esconda a geração da camada de apresentação por trás de funções ou componentes mais complexos tende a limitar as escolhas e tornar a otimização uma tarefa inglória — em muitos casos, impossível.

O problema com esse tipo de abstração é que ele tende a vazar mais facilmente, deixando o desenvolvedor em uma situação em que ele é obrigado a usar a abstração e intencionalmente quebrá-la toda vez que precisa de alguma coisa ligeiramente diferente.

O .NET, por exemplo, é especialmente doloroso nessa área. Criado com a intenção de eliminar completamente a necessidade de escrever HTML na mão, ele acaba complicando a vida dos programadores que precisam lidar com duas interfaces diferentes para atingir o objetivo de uma delas somente. O resultado é uma solução pela metade, de difícil manutenção e legibilidade, e com resultados imprevisíveis dependendo da plataforma em que está rodando.

Efetivamente, o que tais bibliotecas geralmente fazem é ignorar as decisões do programador, gerando código que pode ser comportar do jeito que o programador tencionava, mas que geralmente possui efeitos colaterais escondidos que podem causar problemas no futuro.

Isso é fatal quando os padrões Web entram na questão. Voltando ao .NET, um exemplo simples. O mesmo possui um objeto que replica a funcionalidade de uma painel da página. No Internet Explorer, o elemento é corretamente exibido como uma <div>. No Mozilla, o elemento sai como uma <table>, o que altera completamente a semântica da página, influenciando também folhas de estilo e scripts.

O que eu tenho buscado atualmente é um meio termo.

Quando eu estava começando a programar para a Web, o tedioso trabalho de criar os widgets necessários em uma página sempre me levava a criar o tipo de função nociva citado acima. Com o tempo, aprendendo que as mesmas mais atrapalhavam do que ajudavam, eu fui ao lado extremo, para mecanismos de template que simplesmente procuravam expor dados para a página, deixando toda a construção da mesma para o programador com algumas poucas funções para enumerar itens ou selecionar entre dois valores.

Com minhas recentes experiências no Rails, eu estou vendo esse meio termo em ação. O Rails oferece funções para gerar HTML, mas geralmente essas funções são tão simples e transparentes que não formam mais do que uma fina camada sobre a apresentação. Essa fina camada é flexível e não impede a fácil customização do resultado, gerando somente o que precisam gerar. Efetivamente, elas se convertem em uma ferramenta que economiza tempo nas tarefas simples sem impedir que tarefas mais complexas sejam realizadas.

O Rails, é claro, possui a sua fatia de erro, com algumas funções que só podem ser customizadas se substituídas por completo (errormessagesfor é uma que me vem à mente agora). Mas, em geral, ele faz a coisa certa.

O PHP mistura demais lógica e apresentação. O .NET presume separar, mas a ligação entre os dois é tão forte que é como se não houvesse separação. As várias bibliotecas para Java cometem os dois tipos de erro: misturam tudo ou unem tudo. O Rails atingiu um bom balanço dessa área, principalmente por causa do uso de MVC, mas precisa tomar cuidado agora com a introdução de Ajax nas bibliotecas primárias.

De qualquer forma, parece que as coisas estão começando a melhorar nessa área com mais e mais pessoas pensando em soluções para esse tipo de problema. Eu acredito que as novas safras de bibliotecas para a Web vão ser cada vez mais práticas nesse aspecto, sem perder a produtividade.

Vai escrever assim lá longe…

June 20th, 2005 § 8 comments § permalink

Um tempo atrás, eu disse que eu estava espantado com o tanto de blogs que o Scoble lia — na época, mais de 1400.

Atualmente, eu estou ficando espantando é com a quantidade de entradas que alguns blogueiros conseguem produzir no espaço de uns poucos dias. Eu deixei o Bloglines meio de lado por alguns dias para retornar e encontrar alguns dos blogs que eu leio com o limite de armazenamento de entradas (200) no mesmo excedido. E não estou falando de blogs coletivos ou feeds de jornais e fóruns, mas de blogs individuais.

Aparentemente, há pessoas gastando a maior parte dos seus dias lendo e comentando outros blogs. :-)

Preguiça

June 19th, 2005 § 8 comments § permalink

Preguiça é uma das virtudes fundamentais da programação, junto com impaciência e hubris. Preguiça para nunca resolver manualmente o que pode ser resolvido de forma automática. Como se pode ver, nada tão ruim assim.

Infelizmente, nem sempre dá para aplicar. Esses dias, eu estou às voltas com um problema que exige editar quase que 2000 arquivos (PHP e HTML) manualmente, limpando o lixo que se acumulou nos mesmos com implementações anteriores por vários programadores. Não dá para automatizar porque virtualmente cada arquivo é único, tendo sido modificado várias vezes em ferramentas diferentes ao longo de mais de quatro anos. Existem áreas de conteúdo que aparecem de maneira idêntica na tela, mas cujo código é bem diferente em termos de formatação, caso e aninhamento de elementos.

O jeito é pagar para alguém fazer. Dureza.

Chefões finais

June 15th, 2005 § 5 comments § permalink

Se há uma coisa que eu nunca achei graça é derrotar os chefões finais de um jogo. Tem coisa mais ridícula do que passar sessenta horas em um jogo, resolvendo problemas, derrotando inúmeros inimigos, para chegar no final e enfrentar um personagem que é dez vezes mais poderoso que você e que você vai só derrotar na base de muita munição e corridas? Tenha dó.

Internet Móvel

June 14th, 2005 § 2 comments § permalink

Navegar na chamada Internet móvel me deu uma visão nova de como a Web ainda tem um longo caminho a percorrer nessa direção. Com exceção de uns poucos sites desenhados especificamente para as telas pequenas e limitadas de handhelds e celulares, a maioria não oferece suporte direto para dispositivos móveis.

As telas do meu celular (176×208) e do Palm (320×320) são razoavelmente grandes para esses tipos de dispositivos. É possível navegar pela maioria dos sites, mas há horas em que dá desespero. Não tanto pelo fato de que os sites não renderizam bem (embora muitos tenha uma aparência sofrível, resultado, geralmente, de medidas fixas no layout) mas pelas complexidades adicionais de entrada de dados e navegação.

Uns poucos sites, como o Bloglines e Google Search, possuem versões bem reduzidas e apropriadas para dispositivos móveis. Mas, mesmo esses sites pecam em tentar manter as versões móveis próximas demais das versões comuns.

O Google Search, por exemplo, mantém o mesmo formato de resultados, com todas as informações adicionais que são pouco usadas. Eu preferia ter mais contexto e menos links.

No caso do Bloglines, a versão é muito boa, mas peca por manter uma imagem grande em todas as páginas e pelo tamanho de algumas páginas de resposta. Considerando que algumas operadoras cobram pela quantidade de dados transferidos, o custo de acesso pode escalar rapidamente.

Outros sites, como o Fictionwise, que eu uso bastante, são praticamente impossíveis de navegar em um dispositivo móvel — o que é bastante irônico considerando que o público deles é justamente esse. A página principal do Fictionwise ultrapassa 100Kb mesmo sem que as imagens sejam carregadas. Se a página deles oferecesse fácil navegação — como a página da Mobipocket oferece — seria possível comprar e baixar livros diretamente do celular e lê-los no mesmo ou enviá-los para o Palm via IrDA ou Bluetooth sem precisar recorrer a um PC como intermediário de instalação.

Ironicamente, muitos blogs são bem fáceis de serem lidos em um dispositivo móvel graças à disseminação de templates padrão do Blogger e MovableType que, por serem baseados em um uso extensivo de CSS e XHTML, tendem a degradar bem.

Um dos problemas que eu vejo agora com o avanço da Internet móvel é o uso indiscriminado de tecnologias Ajax. Os dois navegadores móveis que uso suportam JavaScript de uma maneira bem completa, mas a velocidade e renderização dinâmica de estilos são bem mais limitadas do que em um navegador comum, sem contar que a maior parte da interação é feita pelo teclado.

Além disso, a degradação na ausência de JavaScript ou imagens deve ser considerada também. A versão comum do Bloglines, por exemplo, falha silenciosamente na ausência de JavaScript e o usuário fica olhando para uma tela em branco sem conseguir imaginar porque os feeds aos quais está subscrito desapareceram. Na ausência de um mecanismo de degradação, alguns sites podem se tornar frustrantes.

Essa foi minha experiência até o momento. A conclusão é que é perfeitamente possível navegar, mas que a experiência está longe da facilidade e velocidade de uso experimentadas em um ambiente desktop.

Where am I?

You are currently viewing the archives for June, 2005 at Superfície Reflexiva.