Quando você está escrevendo código, pense sempre em quem vai ter que lê-lo no futuro. Pode ser você mesmo. Pode ser você mesmo, daqui a cinco, às duas da manhã, correndo para consertar um bug.
É por isso que padrões e convenções são uma ideia tão boa.
Quanto tempo você já passou olhando o código de alguma aplicação, tentando descobrir onde estão as coisas? No web2py, um dos meus frameworks favoritos, quando você cria uma nova aplicação, a pasta de código se parece com isso:
Aplicação nova em web2py, ainda sem nenhum código.
Web2py é um framework MVC, que, você sabe, é a sigla para model, view e controller. Para acessar o banco de dados você escreve um model. E como se chama a pasta onde estão seus models? Ok, models. E as regras de negócio devem ir num controller. E onde estão seus controllers? Na pasta controllers, claro. E as views na pasta views.
Zero esforço para entender, zero esforço para decorar.
Eu sei que é bem pouco esforço decorar que, no seu novo framework da moda, as views estão dentro de /presentation/templates/html, os controllers em /app/core/controllers e os modelos em /persistence/rdbs. Mas pouco é infinitamente mais do que zero. E, acredite, esses pequenos esforços, somados, fazem um bocado de diferença.
Apresentei hoje cedo uma palestra no GAiN, um encontro de profissionais de comunicação e internet da minha igreja. Há um tempo que venho falando às pessoas que trabalham com internet na igreja sobre os padrões do W3C. Mas hoje tive a oportunidade de falar para gente que trabalha com isso de toda a América do Sul, de uma vez.
Muito obrigado aos organizadores pelo convite. Quem quiser conferir minha palestra no GAiN, sobre as tendências para o futuro próximo da web, pode encontrar a apresentação aqui: aqui.
Não sei se minha palestra foi gravada. Se eles publicarem lá, aviso por aqui.
SVG é suportado em tudo quanto é navegador hoje, incluindo o Internet Explorer 9. Isso significa que, num futuro próximo, você vai poder usar SVG sem medo. Enquanto isso, para boa parte das necessidades, você pode usar SVG com uma biblioteca de compatibilidade com IEs antigos, como a Raphaël e a svgweb.
Dá uma olhada nesse exemplo. Exibe o código fonte e você vai ver que isso aí foi feito com umas 300 linhas de javascript.
Qual o segredo?
SVG é um formato de XML para a descrição de gráficos vetoriais. O que significa que, diferente do que acontece com canvas, com SVG os objetos que você exibe na tela são de fato objetos, nós do DOM, na árvore do seu documento. Então dá uma olhada nesse outro exemplo. A animação do logo em cima e o gráfico interativo em baixo, tudo isso tem umas 35 linhas de Javascript apenas.
Então fica a dica: estude SVG. Tenho certeza que vai ser útil.
É impressionante a facilidade com que certas discussões técnicas ficam parecendo discussões sobre moral, ética ou futebol. Parece que é difícil entender o fato de que fazer uma escolha técnica diferente da sua não vai condenar ninguém ao inferno.
Veja, por exemplo, a questão da validação do W3C. Algumas páginas do site da Visie não passam na validação do W3C. E a gente não está nem aí para isso. Entenda bem, nós acreditamos na importância dos padrões web. A empresa se chama “Visie Padrões Web”. Mas acreditamos que padrões web são importantes porque tornam seu site acessível, compatível, rápido e indexável. Também são importantes porque formam um excelente conjunto de tecnologias para o desenvolvimento. Desenvolver direito com padrões web é a melhor relação custo X benefício.
Nada disso tem a ver com estar “certo”, politicamente correto, ou com conseguir ganhar um selinho. Tem a ver apenas com encontrar a melhor maneira de deixar meus usuários satisfeitos. Ponto.
O validador é uma ferramenta e tanto. Principalmente para quem está aprendendo HTML ou precisa corrigir um problema misterioso num site. Eu uso muito o validador em treinamentos. Mas ele não é um juiz, um crivo obrigatório sem o qual seu site não deveria nem ser publicado.
Javascript
Javascript é uma linguagem muito flexível, que permite muitas escolhas diferentes de modelagem, de técnica de codificação e até de estilo do código. E isso é um terreno muito fértil para os inventores de regras. Existem mil maneiras de preparar Neston. Nenhuma é mais “certa” do que a outra, o que define o que é certo são seus objetivos.
Não, não estou falando sobre a polêmica dos ponto-e-vírgula no código. Embora esse seja um assunto interessante, não é tão importante. Estou falando de algo mais.
Leia, por exemplo, o excelente artigo do Willian Bruno sobre orientação a objetos. Antes de criticá-lo, preciso dizer que o Willian usou uma abordagem muito didática, e escreveu código impecável. Vale a pena a leitura. A única coisa que eu recomendo ao leitor é que entenda que a abordagem usada não é a única correta.
Começando com o estilo de código para orientação a objetos. Tem gente que escreve construtores de objetos literais, como o Willian fez. Tem gente que escreve funções construtoras, para ser chamadas com new, e atribuem propriedades e valores dentro do construtor. Tem gente que escreve funções construtoras e atribui propriedades e métodos ao seu prototype. Há grandes diferenças de sintaxe e ligeiras diferenças nos resultados obtidos ao usar cada técnica. O ponto é: não escolha as regras de alguém como as suas sem entender primeiro os porquês.
Outro ponto tem mais a ver com a modelagem do que com estilo de código. O Willian usa um pattern bastante popular hoje em Javascript, o Module. E faz com ele controle de visibilidade, fazendo com que apenas um método seja visível fora do módulo. Esse estilo de modelagem, embora bastante popular, está longe de ser o único correto. Embora programadores Java e C sejam incentivados a se preocupar muito com isso, a maioria dos programadores Ruby usa com muita parcimônia o controle de visibilidade e a comunidade Python tem vivido muito bem sem esse recurso. Você pode escrever módulos com excelente nível de encapsulamento sem controle de visibilidade.
A mesma coisa se aplica a quase qualquer escolha em tecnologia. NoSQL não é a bala de prata que vai salvar a próxima geração de ERPs, mas vale a pena conhecer. Os novos recursos do HTML5 não vão tornar a jQuery desnecessária, mas você precisa conhecê-los. O Sublime Text não me fez largar o Vim, mas valeu muito a pena gastar um tempinho para ter uma segunda opção.
Moderação. Não é futebol. Não é religião. É só técnica.
Boa parte das APIs do HTML5 já estão disponíveis hoje para a maioria dos navegadores e, com um pouco de conhecimento e uma pitada de javascript, é possível desenvolver hoje aplicações com geoposicionamento, funcionamento offline, conexão em tempo real com o servidor, gráficos vetoriais e todo um novo conjunto de recursos de interface.
Por que esperar?
O HTML5 foi construído de maneira modular. Não é preciso esperar que toda a documentação esteja escrita para começar a trabalhar com ele. Você pode usar agora mesmo o que já está pronto.
Pensando nisso, preparamos este Workshop sobre as APIs do HTML5 e como construir a nova geração de aplicações web. Veja o programa.
Para iniciar este post, é preciso deixar algo claro: diferente da minha postura com os polêmicos ponto-e-vírgula, em que sei que sou “promíscuo e relaxado”, eu sou muito reticente quanto ao uso de eval() em javascript. O principal motivo é que eval() me cheira a gambiarra. Mas tenho muita dificuldade em dizer porquê. Na verdade, acho mesmo que é só uma questão de elegância.
Já li muita coisa sobre o assunto, mas nenhum argumento me convenceu. Os dois principais argumentos são performance e segurança. Em minha opinião nem um dos dois argumentos procede.
Performance
Em primeiro lugar, é preciso dizer que o argumento de que JSON tem pior performance raramente é verdade. Há alguns anos, código executado via eval não poderia ser cacheado ou pré-otimizado. Isso não é mais verdade hoje em dia. A V8 (Chrome), a Nitro (Safari) e a SpiderMonkey (Firefox) já trabalham com caching do código passado a eval em diversas circunstâncias. Além disso, pense nas situações em que eval seria útil. Não consigo imaginar uma em que performance seja um problema. Por exemplo, uso eval como um fallback para navegadores que não tem suporte nativo a JSON. Sinceramente, depois de um delay de dois segundos esperando por uma requisição Ajax, não faz absolutamente nenhuma diferença se interpretar esse retorno vai levar dez milissegundos a mais.
Alguém pode dizer que seria melhor nessa situação usar uma biblioteca JSON com validações, como a do Douglas Crockford. Mas isso acrescentaria 17Kb de código em troca de absolutamente nada. Alguém pode então argumentar que o que se ganha usando uma biblioteca dessas não é exatamente nada, mas pelo menos um validador do código antes da execução. Respondo a isso no final.
Segurança
O segundo argumento mais usado contra o uso de eval() é segurança. O fato de executar uma string, gerada dinamicamente, e não código escrito diretamente por você, pode dar calafrios. Puxa, mas não dá para ter a menor ideia do que será executado! Um agressor não poderia usar isso para executar código arbitrário? Isso não abre as portas para ataques XSS ou man-in-the-middle?
Aqui também, ninguém nunca conseguiu me demonstrar um único caso em que isso fosse uma preocupação real. Imagine o caso de uso que citei acima, por exemplo, de fazer parsing de dados JSON vindos via Ajax. Embora o código que vá passar por eval() não esteja no seu javascript, ele efetivamente foi escrito por você, no servidor. Se alguém consegue acesso a sua aplicação server afim de enviar dados maliciosos para suas requisições Ajax, por que ele se daria ao trabalho de fazer isso se ele poderia simplesmente gerar Javascript malicioso ou HTML malicioso? Se alguém teve esse nível de acesso a seu servidor, XSS é a menor de suas preocupações.
Outra variação do argumento da segurança diz que se você usa eval() a partir de uma entrada de dados do usuário, isso sim poderia abrir as portas para a execução de código malicioso. É preciso lembrar aqui que código javascript roda no client. Assim, o fato de eu poder digitar um script malicioso num campo de formulário, por exemplo, não significa nada exceto o fato de que posso “invadir minha própria máquina”.
Claro, se você recebe os dados gerados por esse eval() no servidor sem validá-los, isso pode causar problemas. Mas, nesse caso, o problema não está no eval() mas em sua validação porca no servidor. Se não houvesse eval() no código, a mesma coisa poderia ser feita na Firebug ou no console do Chrome.
Há ainda a preocupação com buscar dados de um servidor externo e executá-los, o que faria com que seu site possa executar código malicioso. Bom, se você inclui javascript em sua página gerado pelo Google Analytics, e pelo Twitter, Facebook, AddThis e outros geradores de widgets, porque não confiaria em executar código dessas mesmas fontes via eval()? Qual é exatamente a diferença?
Em suma, se as fontes de dados para o eval() não são confiáveis, não use-as de jeito nenhum. O problema não está no eval().
Qualidade de código
Um último argumento, menos usado mas em minha opinião mais relevante, tem a ver com a qualidade de código. O principal motivo que me faz evitar o uso de eval() é o fato de, se houver algum erro no código avaliado, será bem mais difícil debugar. O navegador vai acusar o número da linha do eval(). Esse é um forte argumento, mas não para todas as situações. Geralmente eu gero JSON no servidor com uma biblioteca ou módulo bastante confiáveis, tanto em PHP quanto em Python. Quais são sinceramente as chances de meu software falhar porque há um problema na biblioteca padrão de JSON do PHP?
Por isso, eu não costumo trocar um simples eval() pelo uso de uma biblioteca de JSON, por exemplo.
Fazendo errado
Não importa quão útil e boa seja uma ferramenta, sempre há uma infinidade de maneiras erradas de usá-la. Vi esses dias código assim:
eval('document.'+obj).className='selected'
Esse código é muito ruim, demonstrando um desconhecimento básico dos recursos da linguagem. Pode facilmente ser substituído por isso:
document[obj].className='selected'
Entenda que este artigo questionando os argumentos comuns contra o uso de eval() não é uma defesa de seu uso, principalmente de seu uso indiscrimado.
Seu argumento
Perdi alguma coisa? Há algo mais que precise ser dito? Por favor, fique à vontade para deixar seus comentários.
A recomendação desse mês é o TidBits. O Danilo tem feito interessantíssimos experimentos com HTML5 e CSS3, sempre postando o código e explicando. Além disso, tem dicas, notícias e outros assuntos interessantes, principalmente para quem trabalha com front-end.
Acesse o HTML5 Please. Clique em use e dê uma olhada na lista. Agora clique em use with caution e confira a lista. Viu quanta coisa?
Por que a maioria dos exemplos de site em HTML5 brasileiros, dois anos depois de começarmos a usar esse treco, ainda são um mark-up levemente vitaminado e canvas?
Onde estão nossas aplicações offline? Web sockets? Drag-and-drop? Geolocation? Micro-data? Device orientation? Novos campos de formulário? SVG? History API?
Mas não tem demanda…
Você pode se desculpar por estar usando os mesmos velhos recursos de sempre, dizendo que os clientes da agência ou produtora onde você trabalha não querem os recursos novos, que seu chefe não quer saber dessas coisas, que tem trabalho pra caramba pra simplesmente recortar os layouts que recebe e não quer arrumar sarna pra se coçar…
Você vai mesmo querer passar o resto da vida recortando layouts? O mundo vai mudar, e você vai ser extinto, dinossauro. Se não tem demanda, crie a demanda. Comece a desenvolver projetos pessoais com o que você acha que seus clientes deveriam estar usando. Em seguida, mostre para todo mundo. Você vai ver se a demanda não aparece.
Todo mundo tem celular conectado. Todos os navegadores (até o IE) estão se esforçando para funcionar direito. É um momento mágico. É uma oportunidade que você não quer deixar passar. Um pouquinho de esforço aí, galera.
Em meu último post sobre esse assunto, expliquei porque prefiro, na maioria dos casos, usar um formato de descrição de dados como JSON ao invés de XML. Infelizmente, parece que nem todo mundo concorda comigo, e há uma porção de dados úteis disponíveis apenas em XML. O que não é um problema, certo? Do que eu estou reclamando? Os dados estão lá, disponíveis publicamente, muitos de graça, e eu aqui reclamando do formato?
Vamos dar um jeito e ler XML!
A maneira óbvia parece ser usar um parser de XML, e é o que eu faço na maioria dos casos. Toda linguagem e ambiente de desenvolvimento hoje possuem bons parsers de XML para você escolher. Mas nem sempre o parser de XML é a melhor solução.
A resposta é um RSS com uma tag content:encoded, contendo uma seção CDATA com um trecho de HTML. Você vai ter que fazer duplo parsing se quiser as informações de dentro desse HTML. Ou pode adotar uma solução assim:
Cinco linhas de código. Dê uma olhada no retorno disso:
>>> data
{'Barometer': '1028 mb', 'Wind Speed': '10 KMH', 'Dewpoint': '15\xc2\xb0C', 'Wind Direction': 'SSE (160\xc2\xb0)', 'Visibility': '6 km', 'Humidity': '93%', 'Wind Chill': '15\xc2\xb0C', 'Heat Index': '16\xc2\xb0C'}
>>> for i in data.iteritems(): print '%s => %s' % i
...
Barometer => 1028 mb
Wind Speed => 10 KMH
Dewpoint => 15°C
Wind Direction => SSE (160°)
Visibility => 6 km
Humidity => 93%
Wind Chill => 15°C
Heat Index => 16°C
É importante entender os riscos que estamos assumindo ao adotar essa solução. Se o formato desse HTML for ligeiramente modificado, nosso código pode parar de funcionar. Neste caso, como os dados estão em HTML dentro do XML, isso não é uma desvantagem, porque você teria o mesmo tipo de problema usando um parser SGML.
Será que conseguimos a mesma simplicidade lendo HTML?
Não me entenda mal, XML é uma idéia interessantíssima, pela qual sou apaixonado. Tenho dado aula de XML, escrito HTML como XML válido, publicado e consumido dados em XML, acompanhado as iniciativas de Open Data e RDF no W3C.
O problema é que, enquanto alguns mercados subutilizam XML, tornando o intercâmbio de dados muito complexo, outros exageram no uso. XML não é a panaceia da troca de dados.
Há, por exemplo, uma porção de sistemas que usam XML como arquivos de configuração. Isso torna complicado o trabalho de editar esses XML, e na maioria dos casos torna complicado o parsing disso para rodar o sistema.
Veja um breve exemplo: a busca do Twitter está disponível em três formatos, HTML, ATOM e JSON. Teste a busca a seguir nesses três formatos (veja a diferença nas URLs):
A maneira como o Twitter publica suas buscas é inspiradoras. O formato ATOM servirá para leitores de feeds e para aqueles programadores que adoram escrever parsers XML. E para o resto do mundo, temos JSON. Veja como consumir a URL JSON e obter dados nativos no Python:
A dica então é se perguntar se XML é necessário e, se não tiver um bom motivo para usá-lo, trabalhar com JSON, YAML ou, quem sabe, um arquivo de configuração declarando variáveis em sua própria linguagem.
Semana passada participei de um curso sobre HTML5 ministrado pela w3c Brasil. Nesse curso o Elcio Ferreira foi o instrutor, eu fiquei com uma duvida e fiz uma pergunta para ele sobre a necessidade de incluir a extensão do arquivo na tag <video> para que o mesmo funcione no firefox. Ele me mostrou uma forma utilizando PHP mas infelizmente não consegui obter o codigo.
Os servidores web, quando servem um arquivo, enviam ao navegador a informação de tipo de conteúdo. O header enviado do servidor, para um arquivo Ogg Vorbis, deve ser:
Content-type: application/ogg
Se o servidor não enviar esse header, o vídeo não vai tocar no Firefox. O Apache sabe fazer sozinho, basta que esteja configurado para isso. No Ubuntu, por exemplo, ele já vem configurado para servir ogg.
A saída de scripts PHP é servida com outro tipo de conteúdo. Geralmente “text/html”. Se você serve seu vídeo do PHP, precisa enviar um header no início do script avisando o navegador que esse conteúdo é vídeo. Você pode fazer:
<?php
header('Content-type: application/ogg');
?>
Já se você serve os vídeos como arquivos estáticos, não deve usar PHP para processá-los só para que sejam servidor com o tipo correto. O jeito certo é configurar corretamente o servidor. Se for um hosting compartilhado, eu tentaria um chamado ao suporte pedindo para que configurem isso corretamente antes de fazer com PHP. Ou estudaria mudar de hosting 😉
Durante esta semana estive no escritório do W3C Brasil, ministrando um treinamento de HTML5. Para encerrar o treinamento, o W3C organizou uma edição do Café com Browser.
Nós e o pessoal da Agência Click vamos mostrar um pouco do que já estamos fazendo com HTML5, e você pode assistir ao streaming ao vivo, cujo link será disponibilizado na hora.
O jogo é simples, e o objetivo é apenas apagar todas as luzes. Por curiosidade, fiz também o algoritmo que resolve o jogo:
O desafio está lançado. O primeiro que colocar nos comentários a URL de uma página com um botão “solve” como o meu ganha uma entrada para o Codeshow. Importante:
Vale o primeiro comentário. Mesmo que você comente de madrugada e eu demore a moderar, ganha quem comentar primeiro.
O solucionador tem que ser escrito em Javascript. Você pode copiar minha versão do jogo e desenvolver em cima dela.
Não pode resolver na base da tentativa e erro. Tem que ser uma boa solução, que resolva qualquer estado do tabuleiro em 20 passos ou menos.
Divirtam-se!
(O pessoal da Visie, se quiser participar, pode. Só não vai ganhar nada ;-))
Tem duas coisas que me incomodam nessa abordagem. A primeira é essa mania que muita gente tem, particularmente programadores PHP, de tratar UTF-8 como um “código alienígena” e ISO-8859-1 como normal e padrão. Alô, ISO-8859-1 é usado por parte do mundo. Não dá para escrever hebraico, mandarim, japonês, árabe ou russo com isso. ISO-8859-1 é uma das diversas tabelas de caracteres que existem mundo afora. E Unicode é a única maneira sensata de escrever um sistema que possa ser usado aqui e na China.
A segunda coisa que me incomoda é a quantidade de código. Não testei profundamente, mas tenho a impressão de que o código abaixo resolve o problema:
function utf8_decode(t){
return decodeURIComponent(escape(t))
}
Discussões sobre o melhor sistema operacional, o melhor navegador ou a melhor linguagem de programação tendem a entrar em loop infinito. Cada um dos lados parece achar o outro um completo idiota por não se convencer de suas opiniões.
Semana passada troquei algumas mensagens com o René de Paula que me fizeram pensar bastante sobre o assunto. O René provavelmente não me conhece, mas eu tenho aprendido muito com ele nos últimos anos, principalmente em seu podcast, o Roda e Avisa. E esse post não é um desabafo “estou chateadinho”. Estou citando o nome do René porque a conversa se deu no Twitter, ou seja, em público, e realmente me fez pensar.
O René recomendou esse artigo da ZDNet, analisando um estudo de segurança dos navegadores web. O artigo começa apresentando os resultados do estudo, em que o Internet Explorer ganha de lavada, e segue explicando porque, na opinião do autor, o estudo patrocinado pela Microsoft é tendencioso e irrelevante.
Respondi ao René dizendo que concordava com o artigo que ele havia indicado, que realmente o estudo era tendencioso. E usei a frase “o rei está nu.” Para mim, a crônica da roupa nova do rei é uma excelente metáfora para a situação. Ele me respondeu que havia visto meu blog e que achava que havia um “viés oculto” em tudo o que eu dizia. Em seguida twittou sobre o fato de as pessoas tratarem essas discussões como se fossem sobre times de futebol. Isso me fez pensar um bocado.
Eu gosto de, numa discussão, ouvir o outro lado. Também gosto muito de lógica. Se tem uma coisa que eu vou defender numa discussão, mais do que meu time de futebol, é o bom uso da lógica. Tento nunca ser irrazoável. Sei que todos somos tendenciosos, mas sempre tento ser mais imparcial que a média.
Talvez seja o fato de a discussão ter acontecido no Twitter, meio pouco propício, mas confesso que fiquei muito preocupado com a impressão que o René teve. Quem me conhece, sabe, trabalho com Linux, Windows ou Mac, sem rabo preso, escolhendo sempre o jeito mais simples de resolver cada problema.
Cada cabeça, uma sentença
Em primeiro lugar, não há um sistema operacional “melhor” e outro “pior”. Há um “melhor para você”. O fato de aquele seu amigo usuário de Windows não ter enxergado ainda que o Linux é o melhor sistema operacional do mundo talvez seja porque, para o perfil de uso dele, o Windows seja realmente o melhor sistema operacional.
Dificilmente eu tento convencer alguém a usar exclusivamente Linux. Sempre tento convencer as pessoas a experimentar. Se o sujeito me diz que é um heavy gamer, por exemplo, recomendo o uso de Windows. Sei, o Wine está muito evoluído e tal, mas se ele tem dinheiro para pagar as licenças e pode rodar a versão mais nova de cada jogo no ambiente em que ele foi feito para rodar, por que complicar?
Sim, não me esqueci, para certos perfis de uso, Mac OS X também é um sistema fantástico. Estou quase comprando um para minha mulher.
Existem, porém, padrões absolutos
O fato de não existir uma solução “bala de prata” e a paixão que costuma cercar essas discussões têm levado muita gente, principalmente programadores, a uma posição morna tão irrazoável quanto os extremos. É comum ouvir frases como “a melhor linguagem é aquele com a qual você sabe trabalhar” ou “a melhor ferramenta é a que resolve seu problema.”
Acredito sim que há casos de uso os mais variados. Mas, dentro de determinado caso de uso, há métricas objetivas que você pode usar para dizer o que é melhor. Falando em linguagem de programação, por exemplo, a melhor não é aquela que faz você se “sentir bem”. A não ser que programar para você seja só um hobby, a melhor é aquela que vai te permitir resolver mais rápido o problema do cliente, com a qualidade e a performance necessárias.
Dado um determinado problema do cliente, e uma determinada métrica de performance, deve ser possível apontar a melhor linguagem para essa situação.
Que problema seu software se propõe a resolver?
Se você é desenvolvedor de software, é importante entender isso. Você dificilmente vai encontrar uma oportunidade de desenvolver um produto que é o melhor para todo mundo. Não há unanimidades.
Você pode desenvolver algo que é o melhor para a maioria, pode achar uma minoria endinheirada, ou pode desenvolver algo legal para você mesmo e torcer para que haja gente parecido com você lá fora.
Mas, se você tentar ouvir todas as sugestões que receber e superar os concorrentes em absolutamente todos os perfis de uso, nunca vai terminar de desenvolver.
Mente aberta
Na Visie hoje temos 7 máquinas Windows, 6 Linux e 3 Macs. Sem contar as VMs, o ambiente de testes, e os servidores onde estão hospedadas as aplicações. Desenvolvedor, abra sua mente. Aprenda uma linguagem de programação nova, experimente outro sistema operacional, teste outra solução. Você vai aprender muito.
Aprenda Python, Ruby, Haskell ou Scala. Isso vai tornar você um melhor programador PHP, Java ou .Net. Desenvolva um projeto com uma banco de dados não relacional (estou usando MongoDB em um projeto.) Se você ama WordPress, faça alguma coisa com Joomla, e vice-versa. Tente outro framework, outro editor, outro jeito.
Sobre navegadores
No dia seguinte a essa conversa estive no escritório do W3C Brasil, assistindo ao Café com Browser com o pessoal do Internet Explorer.
Eles passaram boa parte do tempo falando sobre os recursos do navegador para o usuário final. Coisas como abas (oh!) e favoritos mais legais, webclips, processos independentes em cada aba, melhorias de performance e segurança. Tudo muito interessante mas, eu acho, apresentado para o público errado. Estávamos dentro do W3C, afinal de contas. Queríamos saber sobre as melhorias para o desenvolvedor.
Ao final, a palestra sobre melhorias para o desenvolvedor foi, para mim, parte surpreendente, parte decepcionante. Me surpreendi principalmente pela reação dos desenvolvedores no Twitter. Muita gente não conhecia as developer tools do IE8, ou os modos de compatibilidade, por exemplo. Quando foi apresentado o querySelector, muita gente twittou revoltada, porque a Microsoft estava “inventando um novo jeito proprietário de fazer as coisas”. Gente, o querySelector é uma recomendação do W3C (está em Working Draft, mas está lá.)
A parte decepcionante, expressei em minha pergunta:
Em suma, não tenho ódio da Microsoft ou de quem quer que seja. Não quero que o Internet Explorer suma do mapa. Ainda tenho projetos em ASP, VB e .Net, e sou feliz com isso. Só quero poder desenvolver uma vez só minhas aplicações. Quero não ter que cobrar do cliente pelo custo de fazê-la funcionar no Internet Explorer. Quero entregar mais rápido aplicações melhores, mais estáveis, com menos código.
A convite do Dulcetti, resolvi aderir à campanha “morte ao IE6”. Incluí o script do iMasters neste blog, e estou indicando quatro desenvolvedores para participar da brincadeira, convidando mais quatro cada um e assim por diante:
Resolvi experimentar um pouco a Twitter API. É linda, do jeito que toda API deveria ser. É REST, muito fácil de entender e colocar para funcionar, e devolve dados em XML, JSON, RSS e ATOM.
Essa simplicidade permite interagir com a API usando ferramentas simples da linha de comando do Unix, como o wget e a cURL. Para nossos exemplos, vamos usar cURL. Se você usa Ubuntu, antes de começar faça:
sudo apt-get install curl
Para fazer um simples post, por exemplo, você pode digitar, em seu terminal:
curl -u seu_username:sua_senha -d status="Twittando do terminal. Aprendi com o Elcio: http://blog.elcio.com.br/brincando-com-a-api-do-twitter/" http://twitter.com/statuses/update.json
É isso mesmo, meninos e meninas, é só um post com autenticação, mais nada. RESTful, simples e elegante, deixar qualquer SOAP no chinelo. Inspirador para qualquer um que precise projetar uma API. Isso retorna dados em JSON. Se você quiser os mesmos dados em XML, ATOM ou RSS, basta mudar a extensão na url.
Agora vamos automatizar isso. Eu criei um arquivo /usr/local/bin/twitter com o seguinte conteúdo:
Naturalmente, criei o arquivo como root e dei permissão de execução para todos os usuários. Agora, no diretório de cada usuário, basta criar um arquivo .twitter com o seguinte conteúdo:
user=seu_username
password=sua_senha
Pronto, tendo feito isso, qualquer usuário que tenha o arquivo .twitter em seu home pode twittar do terminal com:
twitter "Twittando do terminal, aprendi com o Elcio: http://blog.elcio.com.br/brincando-com-a-api-do-twitter/"
Simples e indolor, agora você pode automatizar suas twittadas com shell script. Pode, por exemplo, twittar toda vez que seu servidor baleiar, ou agendar twits com cron.
Search API
A Search API também é espetacularmente simples, dê uma olhada. Fiz a UPBox usando a Twitter Search API, por exemplo, com 22 linhas de código.
Olha que legal, o Thiago vai dar presentes às pessoas que participarem de sua promoção, e para o primeiro colocado ele escolheu dar como presente um curso online de acessibilidade da Visie. Lisonjeado.
Parabéns Thiago pelo primeiro aniversário do Profissão Web.
É um site para falar sobre Javascript, Ajax, CSS, XHTML. Mas não é um site para opinião e recomendações, é um lugar para você ler sobre código, ler código, e colaborar. O site é aberto ao cadastro e colaboração dos usuários, embora todos os artigos devam ser aprovados pelos editores. Entenda a política do site.
Se você já possui um blog ou site sobre o assunto, pode publicar seus artigos em seu próprio site e apenas um link com um breve comentário no ClientSide. Só não faça isso com cada um dos seus posts, apenas com os melhores. Não é um agregador. Se fosse, eu teria feito para funcionar sozinho. É um site onde você vai ler conteúdo especial, focado no assunto, que foi selecionado por seres humanos de um jeito que as máquinas (ainda) não sabem fazer.
