Xucros

Fiz meu primeiro (e único) jogo em 2005, como TCC. Apresentei o meu jogo de truco para celulares feito em Java. Me formei, pensei seriamente em fazer um site e por o jogo à venda, mas deixei pra lá, por que teria muitos problemas com pirataria e afins.

Fiquei sabendo da existência do iPhone pelo blog da Kathy Sierra (volta Kathy!), mais especificamente por este post. Tinha acabado de comprar o meu primeiro produto Apple, um iPod nano, e estava maravilhado com a Apple em si. Mesmo assim me mantive cético em relação a comprar um.

O principal motivo que me convenceu a comprar um iPhone não foi o iOS, o fato de poder tuitar do banheiro ou qualquer coisa do tipo: Simplesmente acordei um dia e falei: vou programar pra essa p*. Neste dia tinha percebido que o mercado de desenvolvimento para iOS era bom. Bom no sentido de que uma pessoa pode desenvolver uma aplicação, por pra vender em um canal de vendas acessível a todos os donos de iPhone e receber bem mais pela sua criação do que receberia em qualquer outro meio.

Me entupi de sites, blog posts e tutoriais de Objective-C, fui até a TIM e voltei com um iPhone 3G em mãos. A empresa onde eu trabalhava na época comprou um livro de programação para iPhone, que eu peguei e (pra variar) não terminei de ler. Na época tínhamos interesse e liberdade para desenvolver algo se uma ideia boa aparecesse.

Uma piada interna que acabei tomando como verdade é a seguinte:

O iPhone não é seu. Ele é do titio Steve. Só passa a ser seu depois do jailbreak.

Eu nunca tive sérios problemas com as coisas que a Apple impõe para os donos de iWhatever. Até atualizar o meu iPhone 3G para o iOS 4. Para os que estudaram, vejam o vídeo abaixo:

Eu sempre fui contra updates de software imporem updates de hardware. Desde antes ter o meu primeiro computador. E sempre admirei a Apple pelo fato de você atualizar as versões de seus softwares para eles ficarem mais rápidos ou ocuparem menos espaço no seu HD.

Só que o iPhone não é meu. Eu não posso, nas CNTP, voltar ao iOS 3.1.3, por que o iOS 4.0 leva 20 segundos pra abrir qualquer app, ou pq eu tenho um tocador de mp3 que leva mais tempo que o Foston pra trocar de música depois que eu clico no “next”. Eu não posso plugar o iPhone dos meus amigos no meu computador e passar uma app que eu tenha feito, como fazia com o meu jogo mequetrefe de truco em 2005.

Eu me virei, voltei para o 3.1.3. Sô ráquer. Um conhecido meu, que é desenvolvedor de iPhone, disse que o preview do iOS 4.1 para desenvolvedores já resolveu o problema de performance no 3G, mas é tarde demais. A questão é que você poderia resolver o problema em minutos, mas não pode. Por que o telefone não é seu.

Existe um bug de segurança relacionado a PDF que a Apple resolveu agora, no iOS 4.0.2. Só que o bugfix não foi feito para iPhone 2G, ou iPod Touch 1G. Tem um desses dois gadgets e quer a atualização? Você não pode, por que o telefone não é seu.

Enfim, vou para o Android, o Galaxy S e o HTC Desire me parecem ótimos aparelhos. Mas essa decisão é pra ser feita na hora de comprar, o que no meu caso poderá levar semanas ou meses.

Existe o Android Market, o qual eu ando meio por fora, mas se não é, logo será uma alternativa viável para as pessoas que pagam as contas desenvolvendo software mobile. O hardware chegou ao nível do iPhone e o software está inevitavelmente chegando perto.

Pra quem decidir começar a programar mobile hoje, recomendo aprender tanto iOS quanto Android.

Verdade seja dita: A Apple dividiu a história da telefonia celular em antes-iPhone e depois-iPhone. Você terá um iPhone. Eu falei mal de quem comprou e comprei. As pessoas que falaram mal de mim por ter comprado acabaram comprando. E você vai comprar um. Acontece, é a melhor interface. A gente acaba pagando a língua.

Mas ele não será seu.

Eu ainda pretendo fazer alguns aplicativos para iOS. Eu ainda tenho a Apple como referência para qualidade. Eu não quero cuspir para cima e falar que nunca mais usarei um iPhone. Sim, pode ser que eu tenha mais iPhones durante a minha vida.

Mas eles não serão meus.

Tradução para o post do Steve Jobs no site da Apple, com as suas considerações sobre Flash e o relacionamento da Apple com a Adobe:

Texto original aqui.

A Apple tem um relacionamento de longa data com a Adobe. Na verdade, nós conhecemos os seus fundadores desde quando eles estavam naquela lendária garagem. A Apple foi o primeiro cliente grande, adotamos a linguagem Postscript para a nosssa impressora nova, a Laserwriter. A Apple investiu na Adobe e por muitos anos foi dona de 20% da Adobe. As duas empresas trabalharam bem de perto e foram pioneiras no mercado de publicação, e houveram muitos momentos bons. As empresas seguiram seus próprios rumos desde aquela era de ouro. A Apple passou pela experiência de quase morrer, e a Adobe foi levada para o mercado corporativo com a sua linha de produtos Acrobat. Hoje ambas as empresas trabalham juntas para servir o mercado de criação – Metade dos produtos da suíte de criação da Adobe são vendidos para usuários de Mac – mas além disso, existem outras áreas de interesse comum.

Eu queria anotar alguns pensamentos nossos sobre os produtos Flash, para que os nossos clientes e críticos entendam melhor por que nós barramos Flash nos iPhones, iPods e iPads. A Adobe definiu a nossa decisão como pura estratégia de negócios – eles dizem que queremos proteger a nossa App Store – quando na verdade a decisão é baseada em critérios tecnológicos. A Adobe diz que somos um sistema fechado, e que o Flash é aberto, quando na verdade é o contrário. Permita-me explicar:

Primeiro, há o “Aberto”.

O Adobe Flash é um produto 100% proprietário. Só é disponibilizado pela Adobe, a qual possui toda autoridade sobre seu desenvolvimento, preço, etc. Embora Flash seja amplamente disponível, isso não significa que seja um produto aberto, já que é controlado e disponibilizado exclusivamente pela Adobe. Baseando-se em praticamente toda e qualquer definição, Flash é um produto fechado.

A Apple possui mutos produtos proprietários também. Embora o sistema operacional do iPhone, iPod e iPad ser proprietário, acreditamos fortemente que os padrões relacionados a Web devem ser abertos. Ao invés do Flash, a Apple adotou HTML5, CSS e JavaScript – todos padrões abertos. Todo dispositivo móvel da Apple sai de fábrica com esses padrões abertos implementados de maneira que tenham alta performance e baixo consumo de energia. HTML5, o novo padrão da Web que está sendo adotado por Apple, Google e muitos outros, permite aos desenvolvedores criarem gráficos, tipografias, animações e transições sem fazer com que eles dependam de plugins de terceiros (como Flash, por exemplo). HTML5 é completamente aberto e é controlado por um comitê, do qual a Apple é membro.

A Apple até cria padrões abertos para a Web. Por exemplo, a Apple começou com um projeto open-source pequeno e criou o WebKit, um motor de renderização HTML5 open-source, que é o coração do navegador web Safari, browser usado em todos os nossos produtos. WebKit está sendo adotado bastante. Google o usa no navegador do Android, Palm o usa, Nokia o usa, e a RIM (Blackberry) anunciou que usará também. Quase todo smartphone que não é Microsoft usa WebKit. Ao abrir a tecnologia do WebKit, a Apple definiu o padrão para navegadores web mobile.

Segundo, há o conceito de “toda a web”.

Adobe tem insistido em dizer que os dispositivos móveis da Apple não podem acessar “toda a web” por que 75% dos vídeos na rede estão em Flash. O que eles não dizem é que quase todos esses vídeos estão disponíveis também em um formato mais moderno, o H.264, e está disponível para iPhones, iPods e iPads. O Youtube, que de acordo com estimativas possui 40% de todos os vídeos na internet, tem um aplicativo que vem em todos os dispositivos da Apple, sendo que o iPad talvez seja hoje quem oferece a melhor experiência para o usuário que existe. Adiciona e esta lista os vídeos do Vimeo, Netflix, Facebook, ABC, CBS, CNN, MSNBC, Fox News, ESPN, NPR, Time, The New York Times, The Wall Street Journal, Sports Illustrated, People, National Geographic e muitos, muitos outros. Os usuários de iPhone, iPod and iPad não estão perdendo muita coisa.

Outra reclamação da Adobe é de que os dispositivos da Apple não rodam jogos em Flash. Isso é verdade. Felizmente, existem mais de 50 mil jogos e títulos de entretenimento na App Store, e muitos deles são gratuítos. Existem mais jogos e títulos de entretenimento disponíveis para iPhone, iPod e iPad do que para qualquer outra plataforma no mundo.

Terceiro, há a confiabilidade, segurança e performance.

A Symantec destacou recentemente que Flash possui um dos piores históricos de segurança de 2009. Nós também sabemos de antemão que Flash é o motivo número 1 de travamentos nos Macs. Nós estamos trabalhando com a Adobe para resolver este problema, mas eles estão resistindo por muitos anos. Nós não queremos reduzir a confiabilidade e a segurança dos iPhones, iPods e iPads só para adicionarmos suporte à Flash.

Além disso, Flash não funciona bem nos dispositivos móveis. Nós andamos pedindo com frequencia para a Adobe nos mostrar Flash rodando bem em um dispositivo móvel, qualquer um, durante alguns anos. Nós nunca vimos. A Adobe disse publicamente que Flash sairia para smartphones no começo de 2009, depois disse que sairia no segundo semestre de 2009, depois no primeiro semestre de 2010, e agora disse que sairá no segundo semestre de 2010. Nós achamos que uma hora vai ser lançado, mas estamos felizes por não termos esperado por eles. Quem sabe como ele vai funcionar?

Quarto, há a bateria.

Para a bateria ter uma duração longa reproduzindo vídeo, os dispositivos móveis devem decodificar o vídeo via hardware; fazê-lo via software consome muita energia. Muitos dos chips usados em dispositivos móveis contém um decodificador chamado H.264 – um padrão da indústria que é usado em qualquer Blu-Ray DVD player e foi adotado por Apple, Google (YouTube), Vimeo, Netflix e muitas outras empresas.

Embora Flash tenha recebido recentemente suporte para H.264, os vídeos em quase todos os sites Flash precisam de um decodificador antigo, que não está implementado nos chips atuais, portanto é rodado via software. A diferença é impactante: em um iPhone, por exemplo, vídeos H.264 podem ser reproduzidos por até 10 horas, enquanto que vídeos decodificados via software são reproduzidos por não mais do que 5 horas até que a energia seja toda consumida.

Quando os websites re-codificam os vídeos para H.264, eles podem fornecer os vídeos sem usar Flash. Eles são reproduzidos com perfeição em navegadores como Apple Safari e Google Chrome sem usar plugin algum, e ficam ótimos em iPhones, iPods e iPads.

Quinto, há o “Touch”

Flash foi desenvolvido para PCs com mouse, e não para touch screen que usam os dedos. Por exemplo, muitos site em Flash dependem de “rollovers”, que mostram menus pop-up ou outras coisas quando o mouse passa por cima de um ponto específico. A interface multi-touch revolucionária da Apple não usa mouse, e não um conceito de “rollover”. A maioria dos websites em Flash precisará ser re-escrita para suportar dispositivos com interface touch. Se os desenvolvedores precisam refazer seus sites Flash, por que não já usar tecnologias modernas como HTML5, CSS e JavaScript?

Mesmo que iPhones, iPods and iPads rodassem Flash, isso não mudaria o fato de que sites em Flash teriam que ser re-escritos para suportar interface touch.

Sexto, o motivo mais importante de todos.

Além do fato de que Flash é fechado e proprietário, possui muitas desvantagens técnicas, e não suporta interfaces touch, existe uma razão ainda maior para não darmos suporta à Flash nos iPhones, iPods e iPads. Nós discutimos os contras de se usar Flash para reprodução de vídeos e conteúdo interativo nos sites, mas a Adobe quer também que os desenvolvedores adotem Flash como ferramenta de desenvolvimento para os nossos aplicativos móveis.

Nós aprendemos da pior maneira que deixar uma camada de software de terceiros entre a plataforma e os desenvolvedores resultará no final das contas em aplicativos com qualidade abaixo do esperado e no impedimento do progresso e da evolução da plataforma como um todo. Se os desenvolvedores ficarem dependentes das ferramentas e bibliotecas de terceiros, eles só tirarão proveito das melhorias da plataforma quando e se os terceiros resolverem adotá-las. Nós não podemos ficar a mercê de decisões de terceiros de quando e se as nossas melhorias e progressos ficarão disponíveis para os desenvolvedores.

Isso piora ainda mais quando os terceiros estão disponibilizando uma plataforma de desenvolvimento. O terceiro pode não adotar as melhorias até que todas elas sejam disponíveis em todas as suas próprias plataformas. Com isso, os desenvolvedores sempre só terão acesso ao menor denominador comum de funções. Novamente, não podemos aceitar um ambiente onde os desenvolvedores são impedidos de usar as nossas inovações e melhorias por que elas ainda não estão disponíveis na plataforma dos terceiros.

Flash é uma ferramenta de desenvolvimento para múltiplas plataformas. O objetivo da Adobe não é fazer o melhor aplicativo possível para iPhone, iPod and iPad. Seu objetivo é ajudar o desenvolvedor a fazer aplicações que rodem em múltiplas plataformas. E a Adobe tem sido dolorosamente lenta para adotar as melhorias das plataformas Apple. Por exemplo, embora Mac OS X tenha sido lançado há quase 10 anos, a Adobe só o adotou por completo (Cocoa) dois anos atrás, quando eles lançaram o CS5. A Adobe foi o último grande terceiro a adotar completamente o Mac OS X.

Nossa motivação é simples – nós queremos fornecer a mais avançada e mais inovadora plataforma possível para os nossos desenvolvedores, e nós queremos que eles estejam diretamente sobre os ombros dessa plataforma, e criem os melhores aplicativos que o mundo já viu. Nós queremos melhorar a plataforma continuamente para que os desenvolvedores possam  criar aplicações ainda mais surpreendentes, poderosas, divertidas e úteis. Todos ganham – nós vendemos mais dispositivos por que nós temos as melhores aplicações, os desenvolvedores alcançam uma base de clientes cada vez maior e os clientes são continuamente agradados com as melhores e maiores seleções de aplicativos de qualquer plataforma.

Conclusões.

Flash foi criado durante a era do PC – para PCs e mouses. Flash é um negócio de sucesso para a Adobe, e nós podemos entender por que eles querem levá-la para além dos PCs. Mas a era mobile é sobre dispositivos limitados, interfaces touch, e padrões abertos para a web – todas áreas nas quais o Flash é aquém.

A avalanche de sites e mídias que oferecem seus conteúdos para os dispositivos da Apple demonstra que Flash não é mais necessário para se assistir vídeos ou consumir qualquer tipo de conteúdo na web. E os mais de 200 mil aplicativos na App Store da Apple provam que Flash não é necessário para as dezenas de milhares de desenvolvedores criarem aplicativos com interfaces gráficas ricas, incluindo jogos.

Novos padrões abertos criados na era mobile, como HTML5, vão vencer em dispositivos móveis ( e no PC também ). Talvez a Adobe deveria focar mais em criar ferramentas boas para HTML5 para o futuro, e focar menos em criticar a Apple por ela ter deixado o passado para trás.

Steve Jobs

Abril, 2010

Texto original aqui.

Tradução deste excelente artigo do Daring Fireball:

Robert Scoble tem uma analogia boa:

Voltemos alguns anos para a época em que o Firefox estava acabando de chegar. Vocês se lembram? Eu me lembro que não funcionava com um monte de websites. Bancos, e-commerces, entre outros. Porque? Porque na época esses sites foram escritos explicitamente para o Internet Explorer.

Algumas pessoas acharam que o Firefox ia fracassar por causa desses sites quebrados. Do mesmo jeito que a Abobe está tentando dizer que o iPad vai fracassar por causa dos seus sites quebrados.

Só se passaram alguns poucos anos e você vê site que não funciona no Firefox? Eu não vejo.

O que houve? O Firefox FORÇOU os desenvolvedores a usarem os padrões web.

A mesma coisa está acontecendo agora, baseando nas minhas conversas com os desenvolvedores: eles não estão incluindo Flash nos seus planos para o futuro.

No que diz respeito àquelas peças azuis de lego indicarem conteúdo Flash no MobileSafari, pense dessa forma: Quem tem o poder de dar sumiço nelas?

1. A Adobe não pode. Ela não pode enfiar um player Flash goela abaixo do iPhone OS.
2. A Apple pode, mas não vai.
3. Os usuários poderiam convencer a Apple se recusando a comprar iPhones, iPod Touches e iPads pelo fato deles não suportarem Flash. Não parece ser o que está acontecendo. Na verdade, as vendas de iPhone estão aumentando.
4. Os desenvolvedores podem arrancar os legos azuis, trocando Flash por uma outra tecnologia.

A reação inicial da Abode em relação ao iPad parece ter mais a ver com o item 3 – enfatizar publicamente que os dispositivos com iPhone OS não tem capacidade de renderizar os sites com Flash. Boa sorte para vocês.

Com certeza, o medo da Adobe é de que o item 4 aconteça. E não é pra menos, uma vez que já estamos vendo isso ocorrer. O evangelista de Flash Lee Brimelow fez um poster mostrando como os sites com Flash ficam sem Flash sem nem olhar antes como eles ficam no MobileSafari. No final um monte deles, incluindo o pornô, já possuem versões específicas para o iPhone, sem os legos azuis e vídeos H.264 que são reproduzidos bem o bastante. Usuários de iPhone que visitam esses sites não tem ideia do que estão perdendo por que, bem, não estão perdendo nada. Para os demais sites, existem apps nativas de iPhone para elas.

Kendall Helmstetter Gelner fez uma versão do poster usando screenshots reais, tirados direto do MobileSafari, direto da App Store, e das aplicações nativas. Os únicos sites com legos azuis que sobraram: FarmVille e Hulu.

A explicação é simples: Produtores de sites tendem a ser práticos. Os que usam Flash não o fazem por que são adeptos, mas sim por que Flash é fácil e ubíquo. Poucas tecnologias tem 100% de penetração de mercado. Flash chegou notoriamente perto desta marca. A alguns anos atrás você poderia dizer que, na prática, Flash estava em todo lugar. Para sites como Hulu e YouTube, fez todo o sentido usar Flash.

Flash não é mais ubíquo. Há uma grande diferença entre “em todo lugar” e “em quase todo lugar”. As próprias estatísticas da Adobe colocam o Flash com 99% de mercado no mês passado. Isso por que, de acordo com a sua metodologia de pesquisa eles só contam “PCs” – o que ignora toda a gama de dispositivos e gadgets que trouxeram essa discussão à tona. O argumento da Adobe é de que Flash é suportado em 99% dos browsers que suportam Flash, não de 99% de todos os browsers.

Você pode até argumentar que Flash, independente dos méritos, foi quem entregou o conteúdo para a sua audiência. Isso não é mais verdade, e a penetração do Flash está encolhendo a cada gadget movido à iPhone OS que a Apple vende.

O que a Hulu vai fazer? Sentar e esperar? Reclamar dos legos azuis? Ou fazer a coisa prática e escrever software que entrega vídeos para o iPhone OS? A resposta é óbvia. Hulu não está nem aí pra Adobe. Eles estão aí pra Hulu. Hulu não é um site de flash, é um site de vídeos. Desenvolvedores vão aonde os usuário estão.

P.S.: Negritos por mina conta.

Tradução desse artigo aqui:

(Essas são informações baseadas em uma experiência real, conduzida no Reino Unido)

Oito macacos foram postos em uma sala. No centro da sala há uma escada, que leva a uma penca de bananas penduradas em um gancho no teto.

Cada vez que um macaco tenta subir a escada, todos são atingidos por um jato de água gelada, o que os humilha. Não demora muito, sempre que um dos macacos tenta subir a escada, os demais o derrubam e o espancam, com medo do jato de água. Logo nenhum dos oito macacos tenta mais subir a escada.

Um dos macacos é substituído. Vendo a escada e as bananas, ele se pergunta porque nenhum dos demais está fazendo o óbvio. Eis que, destemido, ele começa de imediato a subir a escada.

Todos os outros macacos caem de pau em cima dele e o espancam. E ele não faz idéia do porque.

Entretanto, ele para de tentar subir a escada.

Um segundo macaco do grupo inicial é substituído. Novamente, o recém-chegado tenta subir a escada, mas todos os outros macacos enchem ele de porrada.

Isso inclui o macaco anterior, o qual grato por não ser o alvo da surra, participa do espancamento porque todos os outros macacos estão participando também. Entretanto, ele não faz idéia do porque está batendo no macaco novo.

Um a um, todos os macacos que estavam no começo da experiência são substituídos. Oito macacos novos estão na sala. Nenhum deles foi atingido pelo jato de água uma vez sequer. Nenhum deles tenta subir a escada. E todos vão prontamente espancar qualquer um que o tente, sem ter a menor idéia de saber o porque.

E é assim que a grande maioria das políticas corporativas são criadas.

Uma coisa que sempre me encacucou a mente foi o fato de muitas pessoas, em todas as áreas profissionais, mudarem de personalidade quando ingressam em uma profissão, ou quando atingem (ou pensam que atingem) proficiência na mesma. Boa parte dessa gente faz pior que isso, indo e voltando entre as aparências conforme bem lhes interessa.

E eis que esbarro nesse texto escrito por C. G. Jung, discípulo de Freud, que diz o seguinte:

… .Um exemplo comum é o da identidade destituída de humor, que muitos homens estabelecem com sua ocupação ou seus títulos. O cargo que ocupo certamente representa minha atividade particular; mas é também um fator coletivo, historicamente condicionado pela cooperação de muitos e cuja dignidade depende da aprovação coletiva. Portanto, se identificar-me com meu cargo ou título, comportar-me-ei como se fosse o conjunto complexo de fatores sociais que tal cargo representa, ou como se eu não fosse apenas o detentor do cargo, mas também, simultaneamente, a aprovação da sociedade. Dessa forma me expando exageradamente, usurpando qualidades que não são minhas, mas estão fora de mim. “L’état, c’est moi”, é o lema de tais pessoas.

Recentemente meu chefe disse que todo mundo devia fazer terapia. Cada dia que passa concordo mais com ele.

Participamos!

Sobre o Dash: É um campeonato de Django, onde o seu time tem que construir uma aplicação Django funcional em 48 horas. Ele aconteceu das 2 da manhã de sábado 30/maio até as 2 da manhã de segunda 1/junho.

Porque entrei nessa? Simplesmente por que venho estudando Python desde algum tempo atrás. Não pretendo abandonar o Ruby e o Rails, só acho perfeitamente possível trabalhar com as duas linguagens e os dois frameworks. Chamei o povo pelo Twitter e o @lpirola me procurou uns dias depois. Alguns minutos de conversa depois, eu, ele, o @wilerson e o @ottohenrique estávamos cadastrados.

Resolvemos fazer uma aplicação similar ao orangotag. Resolvemos homenageá-lo, chamando de gorillatag. Diferente do orangotag, o gorilla é um tracker de filmes. O esquema é bem simples: você se cadastra, adiciona seus amigos, e marca os filmes como assistidos. Daí, nos feeds rss dos seus amigos aparece um item avisando que você viu o filme em questão. Você também pode comentar filmes e deixar mensagens para os usuários.

Pra deixar as coisas mais interessantes, eu nunca tinha usado Django. Ninguém tinha. E acho que alguns deles nunca tinham usado Python também. Mas tudo isso acabou sendo um fator positivo.

Nós entregamos a aplicação. O que já é um ponto positivo. Mas perto da concorrência, fomos mal. Muito mal. Agora temos o que olhar e comparar.

Depois de 48 horas usando Django, posso fazer uma comparação simplista de alguns pontos bons e não tão bons, em comparação ao Rails:

• Schema: O Django não mantém histórico das mudanças no banco. Tirando operações básicas como criar tabelas, ele não faz muita coisa. Se você adiciona um atributo a um model, tem rodar um comando do django que imprime o schema na tela. Daí você pega esse esquema e atualiza no seu banco de dados. Bem diferente das migrations do Rails.
• Models: No Django os atributos reconhecidos por ele tem que ser declarados no model. Isso é bom em relação aos models do Rails porque você tem tudo num lugar só, não depende de plugins que olham o schema e colocam os campos em comentário, por exemplo.
• Performance: Sejamos sinceros: Python está num nível de maturidade bem maior do que o Ruby. A performance dele chega a assustar depois que você passa um ano e alguns meses usando Ruby. Ele “compila” os seus scripts em arquivos .pyc. Os arquivos “compilados” são carregados mais rapidamente pela virtual machine, mas não alteram a velocidade de execução. Mesmo assim é uma ajuda tremenda.
• Django “environment”: Uma das coisas que difere bastante o Django do Rails é a forma como eles tratam o “ambiente”. No Rails, pondo as coisas nos lugares certos, você sempre tem tudo à disposição, carregados certinho. No Django você precisa importar tudo. Vai usar um model numa view? Precisa importar. Vai usar coisas simples como datetime? import. Posso estar falando besteira, mas não carregar as coisas pode ser um motivo para a velocidade do shell do django e outras coisas ser tão mais rápido do que o equivalente no Rails.
• Plugins: O Django vem com uma engine de autenticação out-of-the-box, que te deixa plugar um model de “profile” nela. Vem também com um models de comentários, sendo que as instâncias desse model podem ser associadas a qualquer outro model do Django. E ainda tem mais: implementar feeds rss é simples ao ponto de criar uma classe, implementar os métodos de título, link, descrição e items e pronto. Creio que isso tudo aconteceu pelo fato do Django ter nascido dentro de um jornal.

Vamos esperar umas duas semanas até sair os resultados do campeonato. Estamos pensando em continuar com o projeto e lançar um beta. Aguardem.

Paranóia. Você não está livre dela.

Eu sou um cara paranóico. Só a idéia de ter que cuidar de servidores em um final de semana me deixa meio apavorado. Embora isso faça com que eu fique apavorado um final de semana sim, um não, há um motivo para isso.

Existe a possibilidade de que eu não tenha feito algo direito. De que eu não tenha coberto todas as possibilidades. De que o meu código não é perfeito.

A gente sabe que não é necessário (nem possível) fazer código perfeito. Apenas código que funciona. Mas aí que a coisa fica engraçada. Eu, como desenvolvedor nunca tive certeza de que o que eu fiz não iria parar de funcionar de uma hora para outra. Isso até eu descobrir TDD, BDD e afins.

A entrada dos testes na minha vida foi (assim como tudo que entra pra ficar) dramática. De repente, lá estava eu escrevendo código pra ter certeza de que um puts “Hello World” imprimiria “Hello World” na tela. Lá estava eu falando (e/ou achando) pra todo mundo que não fazia que a vida deles era miserável, que eles eram desenvolvedores inferiores. Lá estava eu evangelizando. Justo eu que critico evangelizadores bem mais do que devo.

O meu site, que está em pré-alpha (e vai sair do alpha em breve) está sendo feito com TDD bunitinhu. RSpec e o caraio a quatro. Daí eu resolvi fazer uma tela sem o maledeto. Consegui! E foi mais rápido, porque eu não precisei escrever os testes e specs! E nisso eu fiz mais uma, e outra, e outra. Nisso se passou uma semana, e tinha uma meia dúzia de 9 specs falhando. Ah, 9 de mais de 100? Depois eu arrumo.

Até que eu faço um commit fatal. Alguma merda fez com que, no lugar do browser interpretar a página e mostrar o site, te entregasse as páginas como se fossem downloads. Erro bobo, arrumado em segundos e atualizado pro site em minutos.

Me senti como o Jim Carrey no filme “Yes Man!”. O tempo todo, desde a hora que virei um evangelizador/publicitário gratuíto, até a hora que imaginei estar magicamente preso à filosofia.

No man! No man! No man!

Na verdade, a ansiedade e a felicidade por isso ter resolvido boa parte dos meus problemas, fez com que eu achasse que todo mundo também precisaria dessa solução. Assim como penicilina. Só que ninguém precisa nem tem saco pra saber que isso mudou a minha vida de desenvolvedor.

Quem sabe passem a querer depois que o site ficar famoso. Ou depois que fique menos chato.

No site que eu estou fazendo agora, que está em pré-alpha (se é que isso existe) , uma requisição simples, sem nada no cache demorava horrores. E isso porque só tem uma imagem no leiaute até agora.

Eu tinha que fazer alguma coisa. E uma regra importante sobre otimização é medir a performance antes de sequer relar no código, para ver o que (e se) você precisa fazer.

Resolvi dar um pouco de atenção para o YSlow, e ao rodar ele, ele me mostrou algo um tanto quanto vergonhoso:

- 12 http requests (9 JavaScript files, 3 StyleSheets)
- Load time: 13.23s (server in other country)
- 262KB to load

E uma bela de uma nota F no YSlow.

Se, por um lado, o Rails vem com tudo pronto e fácil para você, por outro ele pode ser um tanto quanto lerdo se você não souber tunar a aplicação. Prototype, script.aculo.us e afins estão a um include de distância, mas eles vem preparados para você desenvolvedor, e não para você usuário.

Ganha-se muito tempo, tanto de desenvolvimento quanto em performance, resolvendo primeiro os problemas de carregamento da página, e depois a sua lógica. Isso significa que: quanto menos arquivos externos, e quanto mais comprimidos eles estiverem, melhor.

O legal é que o Rails tem uma solução simples para isso: passar o parâmetro :cache => true para os métodos javascript_include_tag e stylesheet_include_tag. Ele faz com que todos os arquivos sejam fundidos em um só, all.js, ou all.css. Isso deu o seguinte resultado:

- 3 http requests (2 Javascript files (um é o widget do uservoice), 1 StyleSheet)
- Load time: 4.04ms (server in other country)
- 143KB to load

Bem melhor! Mas ainda dá pra melhorar. Se você configurar o seu servidor da maneira certa, ele usa gzip para mandar uma versão compactada da página e dos arquivos externos. Eu já tinha instalado o módulo no Nginx, mas mudei o servidor para Apache 2, e acabei esquecendo.

A dica aqui é que se você procurar na internet sobre como configurar o Apache para usar gzip, você vai dar de cara com um monte de links para o mod_gzip, módulo externo ao Apache. Mas você não precisa dele: basta ativar o mod_deflate, que é nativo e vem instalado em praticamente todo Apache. É só procurar por ele em /etc/apache2/mods-available/. Edite o arquivo /etc/apache2/apache2.conf, adicionando:

<IfModule mod_deflate.c>
    AddOutputFilterByType DEFLATE text/html text/plain text/xml application/xml application/xhtml+xml text/javascript text/css application/x-javascript
    BrowserMatch ^Mozilla/4 gzip-only-text/html
    BrowserMatch ^Mozilla/4\.0[678] no-gzip
    BrowserMatch \bMSIE !no-gzip !gzip-only-text/html
    DeflateCompressionLevel 9
    SetEnvIf User-Agent ".*MSIE.*" nokeepalive ssl-unclean-shutdown downgrade-1.0 force-response-1.0
</IfModule>

Rode:

sudo a2enmod deflate
sudo /etc/init.d/apache2 stop
sudo /etc/init.d/apache2 start

e pronto! Os resultados para mim foram:

- 3 http requests (não mudou em relação ao teste anterior)
- Load time: 2.99s (server in other country)
- 42.2KB to load

E ainda tem mais! Se você for um dos 20 primeiros a comentar, receberá… Você pode ativar outro módulo do Apache, o mod_expires, e configurar imagens e arquivos externos para expirarem daqui a muito tempo. Assim o browser nem tenta pegar os arquivos que já tem. Abra novamente o arquivo /etc/apache2/apache2.conf,e coloque:

<IfModule mod_expires.c>
    <FilesMatch "\.(ico|pdf|flv|jpg|jpeg|png|gif|js|css|swf)$">
        ExpiresActive On
        ExpiresDefault "access plus 1 year"
    </FilesMatch>
</IfModule>

Rode:

sudo a2enmod deflate
sudo /etc/init.d/apache2 stop
sudo /etc/init.d/apache2 start

Isso fez com que as requisições seguintes carreguem em 0,7 segundos, ou até menos! E agora a aplicação recebe nota B no YSlow!

A lição de tudo isso: Otimização prematura é a raiz de todo mal. Ainda há espaço para mais: Colocar as versões minimizadas do Prototype & afins, mas para um único post já está de bom tamanho.

Eu comecei a usar Dvorak. 30% por preocupações com a saúde e 70% por originalidade

O único problema ao usar o leiaute ¨Dvorak¨ nativo do Mac OS é com os acentos, ou Dead keys. Para se fazer a letra ´a´ com acento agudo, por exemplo, você precisa digitar alt+e, depois ¨a¨.

O Tarmann me indicou o Ukelele, que te ajuda a fazer o seu leiaute, daí eu arregacei as mangas e fiz um leiaute Dvorak com as Dead keys iguais às do U.S. International.

O arquivo está aqui. Só recapitulando: Salvem como arquivo no diretório (HOME)/Library/Keyboard Layouts

Aproveitem!