Planeta Visie

É isso aí! Ano novo, nova jornada!

Antes do ano de 2009 acabar eu já observava indícios de que minha vida estava prestes a mudar. Fui Analista de Sistemas da Visie durante 2 anos. Sou de São José dos Campos e fui contratado pelo Elcio Ferreira no início de 2008 para trabalhar em São Paulo – Capital alocado em um cliente da Visie no centro de São Paulo.

Trabalhei quase 2 anos em um projeto para a ACSP (Associação Comercial de São Paulo) que iria substituir o atual sistema de proteção ao crédito da empresa (o famoso SPC). Neste período eu aprendi bastante. Tive a oportunidade de conhecer pessoas incríveis, que realmente mudaram minha vida diretamente e indiretamente.

Quando o projeto foi chegando ao fim o Elcio não achava mais necessário a minha presença no projeto e achou que eu seria mais útil na matriz da Visie em São Judas. Fui para lá e foi ótimo! conheci um novo modelo de trabalho, pessoas incríveis. Adoro trabalhar em um lugar onde as pessoas são apaixonadas pelo que fazem. A realmente sentirei falta de trabalhar para Visie.

O início de 2010 foi quente para mim. Recebi muitas propostas de emprego neste período, a maioria para sobrinhos faz tudo (#sick) e algumas interessantes. Uma delas foi a oportunidade de trabalhar no Virgula. Fui chamado para entrevista, gostei muito do lugar e pelo que conversamos a equipe também é promissora. Lá eu fiz um teste. Um simulado oficial da Zend (in english) para testar os conhecimentos. Três dias depois eu fui comunicado de que havia sido selecionado para a vaga.

Hoje, dia 16 de março de 2010. Eu encerro a minha jornada como membro da Visie e inicio uma brand new como parte da equipe do Virgula.

Que venha o Virgula, então!

Igor
[]’s

Antes de começar este post gostaria de contar uma história que ouvi em algum lugar que não me lembro mais (provavelmente li na internet numa busca qualquer).

Quanto um técnico ganha? Quanto você ganha? Pense nisso.

O sujeito comprou um equipamento caríssimo, que iria agilizar a produção em sua fábrica.

Após 1 mês de uso, o equipamento parou de funcionar.

Chamou todos os seus engenheiros, e nenhum deles conseguiu detectar o problema.

Desesperado, resolveu chamar um técnico de fora da empresa.

O técnico, examinando o equipamento, descobre o problema: um parafuso solto.

Apertou o parafuso, ligou a máquina e esta voltou a funcionar normalmente.

Apresentou a conta de Dez mil dólares.

O dono da empresa ficou espantado, alegou que não tinha como justificar esse preço absurdo, mas mesmo assim resolveu pagar, mediante descrição do serviço na nota fiscal.

O técnico então apresentou a nota fiscal com a seguinte descrição do serviço prestado:

Visita técnica: valor – cortesia

Apertar parafuso: US$ 10,00

Saber qual parafuso apertar: US$ 9.990,00

Recentemente meu apartamento tem passado por modificações, pintura, armário embutido, televisão acoplada e você sabe que quando tem mudança muitas coisas acabam quebrando. Bem, a hélice do meu ventilador de parede quebrou e eu tive que chamar a assistência técnica para arrumar outra hélice e colocá-la no lugar.

Como no meio do caminho estávamos pintando o quarto, decidi pedir para o técnico que veio em casa para colocar a hélice para passar o fio da tomada para o ventilador – menos de um metro, e fazer a instalação (passar o fio por dentro do tubo do ventilador. Não precisava nem fazer instalação elétrica, o ventilador já estava instalado, bastava apertar os parafusos na parede e passar o fio. Eis que ele me solta: “O custo desse serviço é de R$ 50,00 e eu precisarei voltar aqui outro dia para fazê-lo.” Claro que ele não falou com essas palavras, mas o resumo é esse. Respirei fundo e falei: “Não, ok! Pode deixar que eu faço.”

Bem, isso me fez refletir muito sobre o meu trabalho. E a pergunta inicial é “quanto devo cobrar sobre o meu trabalho“. Procurei, pesquisei, me informei com pessoas mais experientes e descobri o seguinte: não existe formula certa para o cálculo. Conversei com algumas pessoas e cheguei a um consenso de como fazer um orçamento sem ter prejuízos e o cliente ainda sair satisfeito pagando um valor justo.

Imagine a seguinte situação: A vizinha – dona de um restaurante, pergunta para você: “quanto custa fazer um site?” (isto já me aconteceu algumas vezes) e a pessoa não espera que você diga, “Passa na minha empresa depois para tomarmos um café e analisarmos sua situação, talvez cheguemos a um consenso comum em que você e eu sairemos satisfeitos com a proposta.” Muitas pessoas que recebem esse tipo de pergunta nem tem empresa para poder dar essa resposta – apesar de parecer a resposta mais sensata, então acabam soltando um numero aleatório qualquer, “sei lá… mil reais”. É aí que está a falha, você não sabe quanto trabalho vai levar, então quanto você deve cobrar? O que acontece é que depois de fechado o trabalho você se vê na condição de fazer tudo o que o cliente deseja: barba, cabelo e bigode. Tudo pelo preço já embutido. Oras, um site é um site, né?

Bom, não é uma fórmula nem a pura verdade. Cada um faz seus orçamentos como achar melhor, mas da forma como vou explicar talvez ajude você a não entrar em enrascadas ou a … Por incrível que pareça e mesmo parecendo chato, peça um tempo para orçar qualquer que seja o projeto. Analise o que será feito, o que deve ser implementado e comece a somar. Somar horas.

Encontre a solução que o cliente precisa e faça um projeto e leve menos de um dia para fazer isso, afinal você ainda não está sendo pago para trabalhar e mantenha uma boa aparência para o cliente, aparente ser ágil assim ele começa a pegar confiança em você. E estime por alto quanto você pode demorar a cada tarefa. Imaginemos a seguinte situação:

Quero implementar PagSeguro em minha loja. Minha loja só vende três produtos e não pretendo vender mais do que isso tão cedo.

Ok, uma implementação dessas não precisa de integração com o retorno automático nem implementação com uma linguagem server-side, podemos usar o PagSeguro com carrinho PagSeguro sem problemas. Quanto tempo para implementar? Um design de um botão, html simples para três produtos, jogar no ftp: trinta minutos. Coloquemos um nível de dificuldade que pode-se encontrar como o cliente não gostou do botão, o ftp que o cliente passou não funciona, mapear a URL de onde fica o botão, problemas de conexão… esta tarefa na verdade pode gerar um trabalho de uma hora. Então é isso, o trabalho terá o custo de uma hora.

Com as horas contadas, verifiquemos o valor que você deve cobrar, um valor justo, em cima do tempo que você vai gastar e não um chute de quanto você acha que o projeto inteiro leva.

Para gerar o valor de cada hora, precisamos saber, quanto você pretende ganhar em um mês? Digamos, R$ 5.000,00. Em um mês existem 26 dias úteis (30 menos 4 sábados menos 4 domingos) e cada dia possui 8 horas úteis o que totaliza em 208 horas. Peguemos esse valor de R$ 5.000,00 e dividimos pelos 208 horas, total de R$ 24,00.

Achamos um valor médio de trabalho, mas isso não é o valor ideal, ainda. Você não consegue pegar clientes todos os meses, existem meses em que você passa fome sem cliente algum, então você deve fazer uma média de tempo de vacas magras, digamos adicionar 10% no valor de cada hora. Também precisa adicionar os gastos que você terá durante o projeto, gastos que muitas vezes você não percebe que está tendo como por exemplo, energia elétrica ou desgaste de máquina, mais 10% dá conta do recado. E ainda temos o fato que você precisar de uma emergência como o fato de você adoecer e precisar contratar alguém para terminar o projeto no seu lugar, 20% deve resolver. Logo, os R$ 24,00 por hora ganham 50% de juros e temos o valor final de R$ 36,00 a cada hora de trabalho.

Imaginemos que você leve 4 dias para fazer aquele site da vizinha e você cobrou um valor de R$ 1.000,00 na lata. Para cada dia você trabalhou o equivalente a dez horas para conseguir manter o prazo, então você levou na verdade 40 horas de trabalho. Na ponta do lápis, você gastou R$ 1.440,00 e ganhou R$ 1.000,00 então você tomou um prejuízo de R$ 440,00. Quase 50% do projeto. Se você tivesse adoecido ou tivesse tido problemas com a familia você não conseguiria bancar as despesas e você ganhou apenas o que trabalhou, sem lucro algum. Isso quer dizer que você trabalhou de graça e não poderá tomar um sorvete por isso.

Na faculdade eu aprendi a ter ódio por “sobrinhos” porque eles cobravam o valor muito abaixo do que um projeto pode ter, por exemplo, minha vizinha conseguiu fazer um site para ela no valor de R$ 300,00. Impossível competir com meu valor de quase R$ 1.500,00. A diferença é estupidamente alta. Mas (!) mesmo não gostando desses pré-profissionais, depois que terminei a faculdade acabei cobrando o valor de um sobrinho para muitos projetos e em todos eles acabei tendo mais despesas do que lucros.

Coloque no orçamento que enviará ao cliente um descritivo de cada trabalho que você irá fazer, mostrando que cada pequeno pedaço do software dele tem um custo para você e quanto isso vale. Descreva bem, este documento poderá ser usado como base para que o cliente não te peça coisas a mais e você tenha um resaldo do que foi acordado. O fatorW tem escrito bastante coisa interessante sobre orçamentos e dicas para orçar seus projetos, vale a pena dar lida no que ele tem a dizer sobre o mercado na internet.

Hoje consigo montar um orçamento que me agrade um pouco mais e é justo – assim como o técnico, que eu consigo ficar satisfeito com o quanto estou trabalhando. E se o cliente dizer “você cobra muito caro”, na verdade ele não está querendo o meu serviço, que posso dizer que é de qualidade e vale o preço que cobro (ah, aprendi isso a duras penas) e nesse caso, é preferível que ele fique com o sobrinho e não comigo. Muitas vezes esses clientes depois de tentar abaixar o preço ao máximo se acham no direito de implicar com tudo e dizer que está pagando por isso, mas isso é outra conversa.

E você, como faz o orçamento para seus clientes?

HTML 5 ou CSS 3 já podem ser usados? Quando o HTML 5 será lançado?
Estou ouvindo demais essas perguntas. A resposta que darei, vai servir para as duas perguntas e para perguntas futuras sobre outras recomendações do W3C.

Para termos uma visão melhor, você precisa entender como o W3C funciona.

Padrões e Recomendações

O W3C é um órgão que regulamenta, cria e desenvolve linguagens para publicação de conteúdo na internet. Há uma diferença muito grande entre padrão e recomendação. O W3C não faz padrões, ele recomenda métodos e linguagens. Uma recomendação se torna padrão porque há a aderência da comunidade. Normalmente uma recomendação do W3C vira padrão, porque o W3C está lá para isso, eles trabalham para que seja assim. Entretanto, você pode criar uma linguagem como o HTML, e submeter para a aprovação do W3C ou fazer o “marketing” dela sozinho e torcer para que a comunidade de desenvolvedores e fabricantes de browsers o apóiem. Isso é difícil de fazer, mas não impossível. Aconteceu com o pessoal do WHATWG com o HTML 5. Um grupo de desenvolvedores estavam descontentes com o caminho que o W3C estava tomando em relação ao XHTML 2 e ao HTML. Então resolveram criar um grupo para escrever um novo padrão da linguagem HTML. O W3C se convenceu e adotou o padrão do HTML 5 que eles estavam escrevendo.
Claro que esse grupo foi inspirado por desenvolvedores da Apple, Mozilla e Opera, mas isso foi só um detalhe.

Processo de adoção

O W3C recomenda métodos e linguagens, o mercado acata e vira um padrão. Uma idéia do W3C, assim que nasce, não é já indicada para uso. Para que isso aconteça há um processo de aprovação e testes. Esse processo é dividido por passos:

1. Working Draft
2. Last Call
3. Candidate Recommendation (CR)
4. Proposed Recommendation (PR)
5. W3C Recommendation (REC)

No Working Draft o W3C publica um documento para a comunidade e grupos de membros do W3C. Trate isso como uma ideia rascunhada no papel, onde eles estão perguntando para todos os interessados se é interessante e vale a pena continuar.

No Last Call, o W3C publica os deadlines do projeto, e pede para que todos os grupos de trabalho que de alguma forma estão envolvidos naquele projeto, enviem seus reviews. Há uma fase dentro do Last Call onde o W3C pede para o público, que somos nós, enviar reviews e idéias sobre o assunto.

No Cadidate Recommendation, o W3C já acredita na tecnologia proposta. Ela foi largamente revista por técnicos de dentro e fora do W3C e por todos os grupos de trabalho envolvidos no processo. Nesse ponto, há o começo da experiência de implementação dessa nova tecnologia. Normalmente alguns browsers já implementam essa ideia para que possa ser utilizada por desenvolvedores mundo afora.

Depois dessa fase, entramos na Proposed Recommendation. Nessa fase a recomendação é enviada para o W3C Advisory Committee para que eles aprovem a adoção final que será um novo padrão no mercado. Entenda que nesse meio tempo, há um processo de testes, implementação e desenvolvimento muito criterioso. É o mundo inteiro testando e sugerindo revisões para que a tecnologia seja realmente interessante e inteligente o suficiente para suprir as expectativas.

Quando essa especificação é aprovada, chegamos ao último estágio, onde a idéia inicial vira uma Recomendação. Aí sim os fabricantes de browsers e desenvolvedores poderão utilizar em seus projetos.

Para ficar mais fácil imaginar, tente pensar em um calhamaço de papel. Nesse calhamaço contém um manual de instruções de uso, implementação e detalhes técnicos de como os browsers devem renderizar as instruções, instruções de como os desenvolvedores devem aplicar e escrever o código.
Engraçado que tudo isso gira em torno de ideias escritas, revisadas e reescritas. Claro que eles fazem testes reais em browsers reais durante todo o processo. Por isso há integrantes de todos os browsers nas equipes para representar cada um dos browsers do mercado. É um trabalho conjunto.

Mas e aí, podemos ou não usar?

Durante muito tempo o CSS foi lançado em versões. Hoje temos 2 versões completas (CSS 1 e 2) e uma revisão (CSS 2.1). O time de desenvolvimento do W3C lançavam atualizações fechadas, ou seja, para haver um lançamento oficial, a especificação do CSS teria de ser totalmente desenvolvida, testada e aprovada. O CSS e o HTML passavam inteiros por todos os processos acima. Por isso, os lançamentos de atualizações no HTML e no CSS eram tão demorados.
Hoje, a aprovação do CSS3 está sendo feito por módulos, assim como o HTML5. Há uma equipe para cada uma das principais propriedades do CSS. Por exemplo, há uma equipe que trabalha exclusivamente para o desenvolvimento do background no CSS3. Quando essa equipe acha que já fez um bom avanço, a propriedade de background, separada do resto da linguagem, passa por todo aquele processo que conhecemos no começo do artigo. Isso facilita a adoção dos browsers e dos desenvolvedores.

Por isso que hoje, mais do que nunca, é necessário que os desenvolvedores pratiquem o Graceful Degradation e do Progressive Enhancement. Pode ser que um browser não suporte uma determinada propriedade porque deu foco para outra propriedade. Isso faz com que a taxa de incompatibilidade de browsers aumente. Se levarmos em conta que os browsers estão mais espertos e suas atualizações estão sendo mais breves, isso não será grande problema. Nosso problema atual é exatamente browsers antigos que não recebem mais atualização. O IE6 está deixando de ser esse caso. A taxa de utilização do IE6 já está bem abaixo do IE7. Claro que em alguns casos isso não é motivador porque trata-se de público específico ou cliente interno. Mas a grande maioria do mercado já está sem essa sombra.

Querendo ou não, essa nova forma de o W3C lançar atualizações em módulos, mexe com a dinâmica do mercado. Não apenas os browsers precisam de atualizações rápidas, mas o desenvolvedor também. Cada uma das atualizações lançadas, minimizam o tempo de trabalho, melhoram o processo de desenvolvimento e priorizam a qualidade de código. Outro passo importante para o desenvolvedor é entender que o site que ele escreve, é portável para qualquer tipo de dispositivo. O desenvolvedor é uma espécie de mensageiro. O conteúdo precisa entregue em diversos meios, e é o desenvolvedor que possibilita isso.

Alguns links para que você conheça mais sobre o processo estão abaixo. Isso tudo pode ser encontrado no site do W3C. Basta ler.

• About W3C
• Níveis de aprovação
• Current Work do CSS

• Porque é a web que comanda
• Ah, o maravilhoso mundo real
• Sobre Internet Explorer para Mobile – Breve impressão
• Prepare-se para a Revolução
• Lançado Firefox 3.5

Navegando por aí, acabei esbarrando no blog do meu amigo Marcos Rossow (nossa, quanto tempo!)

E encontrei esse post: JavaScript UTF-8 Decode, com um código tirado daqui: JavaScript utf8_decode.

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))
}

Eu participo do Fórum iMasters onde de vez em quando publico algumas informações e dicas sobre PagSeguro. E também respondo alguns e-mail sobre dúvidas e perguntas sobre os meios de integração com a plataforma. Um desses e-mail foi sobre cálculo de frete. A resposta foi tão satisfatória que decidi escrevê-la no fórum do iMasters e publicá-la aqui.

Calculo de Frete usando o PagSeguro

As lojas normalmente tem um sistema de cálculo de frete próprio como FEDEX ou mesmo usando uma API própria que conecta nos correios. Daí você faz um carrinho de compras onde indica um frete para o cliente e você quer que o PagSeguro use esse valor de frete que você passou. (ao invés de usar o cálculo do PagSeguro)

Para resolver esse problema configure o frete no PagSeguro da seguinte forma: Frete adicional com valor fixo com valor fixo definido para zero. Passe o valor de frete com o valor que a loja calculou apenas para o primeiro item.

Para entender melhor ou simplesmente ver quais são as outras opções possíveis, veja a matéria original no fórum do iMasters.

Não é muito difícil ser produtivo. Em muitas palestras e aulas, me perguntam como o desenvolvedor client-side (ou qualquer outro) pode melhorar sua performance e desenvolver melhor, mais rápido e com qualidade. Além de muito treino, existem outros pontos que se utilizados da maneira correta, podem agilizar seu trabalho. Um destes pontos é o seu editor de código.
Você já parou para conhecer seu editor? Muitos desenvolvedores simplesmente ignoram a existência das features que seu editor carrega. Simplesmente instalam e digitam código. Desenvolvedor que é desenvolvedor, gasta tempo aprendendo seu editor.

Quando eu utilizava Windows, experimentei dezenas de editores. Foram muitos mesmo. Comecei pelo Notepad, passei pelo Homesite e CoffeeCup. Antes de migrar para Mac, eu estava utilizando EditPlus, mas estava tendo uma quedinha pelo NotePad++. Os dois são muito bons, embora faça um pouco de tempo que o EditPlus não tenha uma atualização.
Quando migrei para Mac, comecei utilizando o BlueFish. Gostei, mas não fui com a cara. A mesma coisa aconteceu com o BBEdit. Foi aí que encontrei o Textmate e depois o Coda. Gostei dos dois. Utilizei durante muito tempo o Coda por conta do seu FTP. Embora o Coda seja completíssimo, o TextMate me ganhou.

Toda essa migração de editores não foi da noite para o dia. Quando eu realmente gostava de um editor, eu o utilizava por muito tempo. Alguns desenvolvedores trocam de editor como trocam de roupa. Não é saudável. Você acaba não conhecendo suas especialidades e limitações. Você não tem tempo para se acostumar com a interface. E isso tudo prejudica sua produtividade. Eu recomendo que você tenha um editor predileto e fique apenas com ele.

Snippets

Eu gostava do Editplus por que ele era um dos únicos editores para Windows que tinham um configurador de Snippets decente (e olha que nem era muito bom). O Textmate tem um gerenciador de snippets invejável e foi por isso que fiquei com ele e não com o Coda.

Na maioria dos editores, os snippets te ajudam com código repetitivo. Eles autocompletam e inserem códigos que são repetitivos para que você não perca tempo redigindo. Mas pára por aí. Você sempre tem que digitar um bocado de código mesmo quando o snippet te ajuda no trabalho pesado. Claro que você tem a possibilidade de configurar e personalizar os seus snippets. Mas muitos dos desenvolvedores não querem parar para criar uma biblioteca de snippets que os ajudem realmente no trabalho pesado do código. É aí que entra o Zen Coding, uma biblioteca completa que lhe permite escrever pouco código e obter o máximo de resultado.

A sintaxe do Zen Coding é baseado em CSS. Você escreve “seletores” de CSS para obter código HTML.
O Zen Coding foi feito pelo Sergey Chikuyonok (em russo). Veja abaixo um vídeo demo de como funciona:

Pra quem não quiser ver o vídeo: a idéia é que uma linha como essa:

div#header > h1.logo > a {logo do site} < ul.menu > li.item-$*5 > a

Retorne este código:

<div id="header">
<h1 class="logo">
        <a></a></h1>
<ul class="menu">
	<li class="item-1">
            <a></a></li>
	<li class="item-2">
            <a></a></li>
	<li class="item-3">
            <a></a></li>
	<li class="item-4">
            <a></a></li>
	<li class="item-5">
            <a></a></li>
</ul>
</div>

Os programadores da Visie me mostraram estes dias um outro projeto criado pelo Rico Sta. Cruz chamado SparkUp. O Sparkup foi inspirado no Zen Coding. Mas tem uma coisa ou outra diferente. Abaixo veja um vídeo introdutório:

Se você é iniciante, entenda que você precisa aprender HTML primeiro. É interessante que você saiba o que cada tag faz, qual sua função e suas características. Aconselho o uso destes snippets apenas para desenvolvedores que já são fluentes em HTML. Não adianta você escrever em Sparkup, mas não saber do que se trata cada tag que foi jogada ali. Isso pode te transformar em um desenvolvedor analfabeto.

O Sparkup tem apenas suporte para Textmate e VIM, por enquanto. Já o Zen Coding tem suporte completo para Aptana, Coda, Espresso, Textmate, editArea, Visual Studio, Komodo Edit/IDE. Sem contar com suporte parcial para os editores TopStyle, Sublime Text, GEdit, Dreamweaver CS4, UltraEdit, BBEdit e Emacs.

Para baixar o Sparkup visite seu projeto no GitHug.
Para baixar o Zen Coding, visite seu projeto no Google Code.

• O que são Media Types do CSS?
• Ah, o maravilhoso mundo real
• Video tutorial – Implementando HTML
• Formulário Básico em 8 minutos – Tableless form
• Informação e Formatação; As duas camadas de desenvolvimento web

Trecho de código legado (ASP) que pegamos aqui:

if len(request("price")) = 3 then
    valorTotal = left(request("price"),1)
elseif len(request("price")) = 4 then
    valorTotal = left(request("price"),2)
elseif len(request("price")) = 5 then
    valorTotal = left(request("price"),3)
end if

Jênio.

No sábado passado realizei uma palestra na Impacta sobre como implementar uma loja virtual do nada com ajuda do PagSeguro da UOL. Esta palestra já está na terceira versão, eu já a apresentei no PHP-Minas e PHPConference no ano passado. Eu sempre dou um upgrade entre uma apresentação e outra ou corto coisas que não são importantes, mas o conteúdo é basicamente o mesmo.

Foram abordados os temas controle de versão, PDO, Frameworks, motivação, KISS (keep it simple, stupid!) e desenvolvimento ágil.

Eu gosto muito dessa palestra em particular porque demonstra como você pode (e deve) ter sistemas grandes implementados com poucas linhas de código, bastando usar a essência do PHP. Hoje o PHP pode ser considerado uma linguagem bem estável e com grandes recursos que em muitos casos usar um Framework completo é algumas vezes perda de tempo, valendo mais a pena usar a essência da linguagem.

Sala cheia (duas) na palestra sobre PagSeguro na Impacta

Também gosto pra caramba de implementar PagSeguro em palestras por ser simples. Em menos de vinte minutos explicativos é possível demonstrar como implementar PagSeguro com direito a retorno automático e dicas de segurança na hora de implementar. É muito satisfatório ver o quanto é rápido, simples e fácil implementar vários meios de pagamento de uma só vez. Com a segurança de “pishing”, fraude, reembolso e muitas outras vantagens que o PagSeguro disponibiliza.

A palestra esteve bem cheia, foram necessárias duas salas e uma conexão de áudio e vídeo para que todos possam ver a palestra. Dentre o pessoal consegui ver o @caferrari – dono do projeto vortice framework, e o @rodrideme – ex-funcionário da Visie e sua namorada @alazanscarol. Muito bom ver esse pessoal.

Enfim a palestra foi ótima e o código-fonte do projeto está no trac para qualquer um estudar. Para ver a palestra, basta vê-la no SlideShare. Espero que tenha mais palestras como esta pois acredite em mim, não é a mesma coisa assistir a palestra e vê-la no SlideShare, é completamente diferente.

Criei agora um pequeno script para resolver um problema meu, um exportador de base de dados MySQL para arquivos CSV. Resolvi compartilhar:

MySQL2CSV

Para baixar, você vai precisar do git. No Ubuntu, para instalar, faça:

$ sudo apt-get install git-core

Depois, para baixar:

$ git clone git@github.com:elcio/mysql2csv.git

Isso vai criar a pasta mysql2csv, com o script dentro. Você pode copiá-lo para a pasta /usr/local/bin/ e dar permissão de execução se for usar com muita freqüência:

$ cd mysql2csv
$ sudo cp mysql2csv.py /usr/local/bin/mysql2csv
$ sudo chmod +x /usr/local/bin/mysql2csv

Se fizer isso, vai poder chamar, em qualquer diretório:

$ mysql2csv host user passwd dbname

Recebi hoje um email do Google explicando que em 2010 eles irão deixar de suportar o IE6. Vitória!
Contar com o IE6 na cartilha de suporte é subutilizar o HTML5 e JavaScript. Aqui mesmo na Visie, temos projetos que o HTML5 e CSS3 seriam a resposta, mas ainda não podemos utilizar por causa do IE6, IE7 e em alguns casos o IE8.

Deixar de suportar o IE6 é questão de sobrevivência. E para matar o IE6, nós precisamos evoluir. Cabe a nós educar o usuário. Formar um mundo novo.

Abaixo segue o email recebido do Google.

Dear Google Apps admin,​

In order to continue to improve our products and deliver more sophisticated features and performance, we are harnessing some of the latest improvements in web browser technology. This includes faster JavaScript processing and new standards like HTML5. As a result, over the course of 2010, we will be phasing out support for Microsoft Internet Explorer 6.0 as well as other older browsers that are not supported by their own manufacturers.

We plan to begin phasing out support of these older browsers on the Google Docs suite and the Google Sites editor on March 1, 2010. After that point, certain functionality within these applications may have higher latency and may not work correctly in these older browsers. Later in 2010, we will start to phase out support for these browsers for Google Mail and Google Calendar.

Google Apps will continue to support Internet Explorer 7.0 and above, Firefox 3.0 and above, Google Chrome 4.0 and above, and Safari 3.0 and above.

Starting this week, users on these older browsers will see a message in Google Docs and the Google Sites editor explaining this change and asking them to upgrade their browser. We will also alert you again closer to March 1 to remind you of this change.

In 2009, the Google Apps team delivered more than 100 improvements to enhance your product experience. We are aiming to beat that in 2010 and continue to deliver the best and most innovative collaboration products for businesses.

Thank you for your continued support!

Sincerely,
The Google Apps team

Email preferences: You have received this mandatory email service announcement to update you about important changes to your Google Apps product or account.

Google Inc.
1600 Amphitheatre Parkway
Mountain View, CA 94043

• Porque é a web que comanda
• Simuladores de Browsers Mobiles
• Ah, o maravilhoso mundo real
• Aonde nos leva a morte do Internet Explorer 6?
• Web Standards Project – WaSP

Código simples, mas que pode ser útil para alguém não ter que escrevê-lo de novo (arquivo runcached.py):

import os,time
cachepath='cache'
timeout=360
 
def runcached(cmd):
  filename=os.path.join(cachepath,str(hash(cmd)))
  if os.path.isfile(filename):
    if time.time()-os.path.getmtime(filename)<timeout:
      return open(filename).read()
  t=os.popen(cmd).read()
  open(filename,'w').write(t)
  return t

A função runcached roda comandos do sistema operacional, e faz cache do resultado por 6 minutos. Para alterar o tempo do cache, basta mudar a variável timeout. Por exemplo, para cachear por 10 horas:

import runcached
runcached.timeout=36000
r=runcached('lynx --source http://www.tableless.com.br')

Estou fazendo uma nova aplicação aqui na empresa e teremos muitos formulários. Para não precisar criar um script de validação para cada formulário, fui atrás de um plugin que gerasse as validação JavaScript automáticamente, com base nas validações do modelo.

Sem maiores problemas, encontrei o plugin Live Validations. Ele faz tudo o que preciso, quer dizer, quase tudo.

Alguns dos formulários dessa aplicação são Nested Model Form e o Live Validations não suporta esse tipo de formulário.

Sendo assim, resolvi fazer meu próprio plugin, chamado Client Validations. O que ele faz é basicamente ler as validações definidas no Model e traduzi-las para JavaScript usando jQuery Validator.

Instalação

script/plugin install git://github.com/willian/client_validations.git

Como o Client Validations depende do plugin Validation Reflection, preciaremos instalar ele também:

script/plugin install git://github.com/redinger/validation_reflection.git

E por último basta instalar o jQuery e o jQuery Validator:

• http://code.jquery.com/jquery-latest.min.js
• http://ajax.microsoft.com/ajax/jquery.validate/1.6/jquery.validate.min.js

Não esqueça de carregar o jquery e o validator no seu HTML:

<%= javascript_include_tag 'jquery-latest.min.js', 'jquery.validate.min.js' %>

Supondo que temos o modelo abaixo:

class Task < ActiveRecord::Base
  validates_presence_of :name
end
 

E o formulário desse modelo:

<% form_for(@task) do |f| %>
  <%= f.error_messages %>
 
  <p>
    <%= f.label :name %><br />
    <%= f.text_field :name %>
  </p>
  <p>
    <%= f.submit 'Create' %>
  </p>
<% end %>

Tudo o que precisamos fazer para a validação client-side funcionar é adicionar o helper client_validations no formulário. Ficará assim:

<% form_for(@task) do |f| %>
  <%= f.error_messages %>
 
  <p>
    <%= f.label :name %><br />
    <%= f.text_field :name %>
  </p>
  <p>
    <%= f.submit 'Create' %>
  </p>
  <%= f.client_validations %>
<% end %>

Provavelmente você receberá a seguinte mensagem de validação:

translation missing: en, activerecord, attributes, task, name can't be blank

Para resolver esse problema, basta criar o arquivo de internacionalização em config/locales.

O plugin ainda está na versão 0.1.0 e muita coisa pode ser feita para melhorá-lo. Se tiver alguma sugestão, crie um comentário ou use a página do GitHub: http://github.com/willian/client_validations

A AppStore fez sucesso. Bastante. Por vários motivos: um deles foi por conta da remuneração do desenvolvedor. Teve gente que ganhou milhares de dólares sozinho vendendo aplicações por 99 centavos. Obviamente isso chamou a atenção de muita gente, que começou a fazer aplicações enlouquecidamente para ganhar alguns trocados. Consequentemente um grande números de aplicações que não precisam ser instaláveis no aparelho, apareceram. Vários desenvolvedores não perceberam que dependendo do seu sistema, ele não precisa ser desenvolvido exclusivamente para ser instalado na plataforma do iPhone.

Hoje, aparelhos como o iPhone, que tem um browser com um bom suporte a HTML 5 e CSS 3, possibilitam criar sistemas e aplicativos baseados em web, com características, designs e comportamentos idênticos aos de aplicações instaláveis nos aparelhos. E o melhor, podem ser utilizados de qualquer lugar, pela web. Outro ponto negativo é que desenvolver para iPhone/iPod Touch é um bocado burocrático. Você precisa ter o SDK que só funciona no OS X, e você precisa aprender Objective C para programar os Apps para Apple. Em contrapartida, para fazer um App baseado em Web, onde seus clientes acessarão o sistema diretamente pelo browser do aparelho, é preciso saber Javascript, HTML 5 e CSS 3. Se você já é desenvolvedor Web, você já sabe desenvolver para iPhone, iPod Touch, Android e qualquer outro dispositivo similar.

Se você gosta dos efeitos de transição dos aparelhos, você pode fazê-los sem problemas utilizando JQuery ou CSS 3. Há até um plugin de JQuery chamado JQTouch, que permite fazer efeitos idênticos ao do iPhone. Esse plugin foi pensado exatamente para funcionar em Mobile Safari e outros aparelhos com browsers avançados, como no Android.

Um caso sobre o que estamos falando é a aplicação do Itaú. Se você tem um iPhone, baixe o aplicativo pela AppStore. Ao abrir o aplicativo, perceba que o sistema não faz nada além de mostrar o site do Itaú. É muito mais interessante e barato ensinar o usuário a visitar o site em vez de procurar um aplicativo e instalar. Não é necessário nem divulgar um endereço mobile do site – esse aliás é outra discussão.

Obviamente, há exceções. A maioria dos jogos, se não todos, e alguns sistemas disponíveis funcionam melhor (ainda) se forem instalados no aparelho. Mas a grande maioria dos sistemas, principalmente aqueles que o usuário simplesmente insere ou verifca informações e dados, podem ser servidos diretamente pela web.

No caso do iPhone, os sistemas que utilizam recursos do aparelho, como por exemplo fazer o aparelho vibrar, bluetooth, bateria, GPS e etc, precisam ser instalados. Isso não se aplica a alguns mobiles da Nokia que são baseados na plataforma WRT.
A plataforma WRT permite que você desenvolva aplicativos utilizando Javascript, HTML e CSS. E por meio de Javascript, você pode ativar os recursos que ter utilizar no aparelho. Nesse caso, há uma vantagem em cima do iPhone: você não precisa aprender Objective C. Basta saber Javascript, CSS e HTML.

O cenário de hoje é interessante. Tudo o que o desenvolvedor sempre sonhou em utilizar de HTML 5 e CSS 3 pode ser aplicado no desenvolvimento para web mobile. Os browsers estão mais espertos e a cada dia trazem novidades interessantes para melhorar o desenvolvimento dos padrões e da web. Realmente, daqui pra frente, é um novo mundo que se forma. Um mundo tão ou mais complexo que o desenvolvimento web para desktops como conhecemos hoje. Pra mim, é mais apaixonante.

• Guidelines de User Experience da Apple.
• Forum Nokia – Web Runtime

• Ah, o maravilhoso mundo real
• O que é Tableless?
• Processos e Adoção de Padrões
• Versionamento inteligente para mobiles
• Porque só para o iPhone?

Alguém me perguntou no Formspring que dicas eu daria para aumentar a produtividade no desenvolvimento web. Minha resposta:

0. Paixão pelo que faz
1. Padrões web
2. Um bom framework (estou me divertindo com web2py)
3. Linguagens dinâmicas (uso Python)
4. Testes automatizados (TDD/BDD…)
5. Controle de versão
6. Scrum
7. Pair Programing
8. jQuery
9. Um bom editor de código (eu uso Vim)
10. Unix (facilita muita coisa)
11. Deploy automatizado
12. Investir em melhorar seus skills: medir tudo o que faz, participar de um coding dojo, testar novas ferramentas, ler, contribuir num projeto open source…

Espero que seja útil.

Você pode ler um pouco mais sobre boa parte desses assuntos em nosso PDF sobre produtividade.

Sem posts relacionados

• A respeito das vagas
• ClipDO: Projeto novo da Visie no ar
• CodeShow - Perguntas e Respostas
• CodeShow - Mais 20 Vagas! CORRA!
• Progredindo

O iPhone fez a festa dele. Todo mundo gostou do que viu e usou. Acontece que não só de iPhone vive o homem, e há pessoas por aí que não gostam do aparelho por motivos diversos. Há mercado para todos e por isso é natural que apareçam outros aparelhos com novos sistemas. Acontece que o lançamento do iPhone criou uma moda de criar versões dos sites específicas para ele. No começo isso foi ótimo. Mas agora, isso priva diversos celulares similares ao iPhone de terem uma boa experiência de navegação. É o caso de usuários de Android.

O Android é o novo sistema operacional para mobiles do Google. Até para um AppleBoy, como eu, o sistema é interessante. Tem a interface bem acabada, app’s amigáveis e etc. Ele faz muito bem o papel dele. O Engine de renderização do browser dele é WebKit. O mesmo engine que o Safari Mobile utiliza. E não estou falando de versões antigas do Webkit como alguns outros celulares utilizam. O Android utiliza as versões mais atuais do Webkit, com suporte extenso a CSS e HTML. Portanto, um site que teoricamente foi feito apenas para iPhone, pode ser visualizado da mesma maneira pelos usuários de Android.

Aí entra outra questão: provavelmente você deve ter pensado que seria apenas fazer um script de detecção de browser, capturando as visitas de Safari Mobile e Android e pronto. É aí que você se engana. Já há vários outros aparelhos que estão utilizando engines parecidas e que podem renderizar sua “versão de iphone”. Exatamente por isso, que você precisa fazer um filtro por características e não por browser. Fazemos isso utilizando Media Queries.

As Media Queries permitem fazer um pequeno filtro, onde definimos as características do dispositivo que acessará a página. Com isso, podemos definir um CSS específico para aquele grupo de dispositivos que se encaixaram no seu filtro. Veja um exemplo abaixo:

1
2

<link rel="stylesheet" href="style.css" type="text/css" media="screen and (min-width:481px)">
<link rel="stylesheet" href="mob.css" type="text/css" media="screen and (max-width:480px)">

A media que fiz é muito simples de ser entendida. A primeira linha engloba dispositivos que tem tela colorida, com uma resolução de largura mínima de 481px, isso inclui seu monitor, notebook e etc. A outra linha engloba dispositivos com uma largura máxima de 480px, ou seja, iPhones, Androids e dispositivos que seguem esse mesmo esquema de resolução e etc.

Dessa forma, você filtra os dispositivos e não os browsers dos aparelhos. Isso previne que algum celular, tão bom quanto o iPhone e o Android fiquem de fora de ter uma boa experiência de uso. Quer fazer um teste interessante? Se você estiver utilizando um browser que aceita media queries, redimensione a janela para uma largura menor que 480px. Você verá o Tableless chaveando os estilos automaticamente. Perceba que alguns elementos são reformatados e outros retirados do layout.

O filtro ainda não está completo porque não estamos contemplando os aparelhos que não aceitam meda queries, mas são mobiles. Para isso, usaríamos os Media Types, com valor de handheld. Embora celulares que aceitem os Media Types não tenham um bom suporte de CSS, podemos fazer pelo menos uma formatação de texto, cor e background. Celulares que utilizam Opera Mini, terão uma ótima experiência.

É sempre aquela mesma velha idéia: dar a melhor experiência para todos os meios de acesso. Sempre.

• Porque é a web que comanda
• Introdução sobre Media Queries
• Sites para Dispositivos Móveis – MediaType
• Sobre Internet Explorer para Mobile – Breve impressão
• O que são Media Types do CSS?

Antigamente não existiam simuladores dos pequenos celulares. Na verdade, não precisava. Você provavelmente usava WAP. Quando começamos a utilizar CSS e XHTML para fazer sites mais decentes para os mobiles, tudo ficou mais complicado, você precisava ter um aparelho para fazer testes. Em muitos casos era simples resolver utilizando o Opera no desktop mesmo, mas em forma de visualização mobile/handheld. Contudo, você estava desenvolvendo para apenas aparelhos com Opera. Não havia, por exemplo, um simulador de IE Mobile. Nem precisa, é horrível, e atualmente, a maioria utiliza Opera.

Para fazer sites para os iPhones e Androids da vida, não há segredo, já que eles aceitam tudo e mais um pouco de CSS e HTML. Você consegue ter homogeneidade ao desenvolver. Mesmo assim, para ter certeza, seria interessante você testar o site em um aparelho. Por isso, há simuladores que emulam o ambiente dos aparelhos. É o caso do iPhone e do Android.

Para aprender mais sobre o simulador do Android, visite a página oficial sobre o emulador deles. Assim você aprende como ele funciona, as funções, instalação e etc. O simulador pode ser instalado em Windows, Mac ou Linux.

O simulador para iPhone é só para quem tem Mac. Infelizmente a Apple ainda não liberou o SDK para outros sistemas. Uma pena, porque não só de mac vive o homem, e a maioria dos devs utilizam Windows ou Linux. Mesmo assim, você pode baixá-lo e utilizá-lo para testar qualquer site ou arquivos locais.

O pessoal da Nokia também disponibiliza vários emuladores. Contudo, aconselho que você utilize apenas o browser de S60, que é o melhor deles hoje em dia. Os browsers dos S60 suportam Webkit, mesmo não sendo a versão mais atualizada, é possível fazer muita coisa interessante, entretanto, há haver alguns erros de compatibilidade por conta do engine desatualizado.

• Simulador de Android
• Simulador de iPhone
• Simulador para Nokia

• Sobre Internet Explorer para Mobile – Breve impressão
• Mobilidade na cabeça
• Sites para Dispositivos Móveis – Breve introdução
• Browsers dos Dispositivos Móveis
• Sites para Dispositivos Móveis – MediaType

Pair Programming é, para mim, a melhor forma de trabalhar em equipe. Facilita a comunicações e impede que o conhecimento de uma funcionalidade/lógica fique somente com um desenvolvedor.

Trabalhando em Pair foi fácil perceber a evolução das pessoas como profissionais. Um profissional Jr. rapidamente ganhava experiência, adquiria habilidades e virava fluente na linguagem, ou seja, treinar a equipe usando Pair foi muito mais simples e barato para a empresa.

Mas, essa é minha opinião. Muita gente compartilha comigo esse mesmo sentimento, mas muita gente torce o nariz quando escuta as palavras Pair Programming juntas.

Mas como começar com Pair Programming?

Não adianta impor sua equipe a trabalhar assim. Mas antes de aceitar um não da equipe, é interessante testar e analisar a aceitação de todos.

Quando trabalhava na WebCo (Abril Dgital), resolvemos usar a Programação em Par. Foi fácil convencer todos, pois, no nosso caso, todos a maioria que torciam o nariz nunca tinham usado Pair, ou seja, não tinham argumentos.
No começo havia discussões, stress, mas com o tempo todos foram percebendo os ganhos que estávamos tendo com a adoção e virou regra da empresa utilizar Pair 100% do dia. Quando entrevistávamos alguém, um dos requisitos era a pessoa não ter nada contra ao trabalho em equipe, principalmente ao Pair.

Mas isso tudo poderia ter sido um tiro no pé. Por isso precisamos estudar caso à caso.
Hoje trabalho numa empresa que somente EU trabalhei com Pair Programming. Tive muitas barreiras para quebrar, principalmente dos gerente, mas felizmente consegui convencê-los e vou começar com Pair na minha equipe.

Como uso Pair Programming

Como uso Scrum para gerenciar o processo do desenvolvimento, ficou fácil dividir as duplas do Pair. No Daily Meeting, quando definimos o que faremos hoje, também definimos com quem faremos Pair. E durante o dia todo não trocamos de par, apenas revezamos, de tempos em tempos, o driver e o navigator. Esse revezamento pode ser feito marcando em um cronometro que avisará quando a troca ocorrerá, ou simplesmente quando a dupla julgar necessário (o que eu prefiro).

No dia seguinte, um das pessoas do par continua na história e a outra pessoa escolhe em qual história trabalhará e com quem fará par. O mesmo ocorre com os outros pares. Ou seja, assim conseguimos manter uma boa rotatividade. A idéia é que o maior número de pessoas possam trabalhar juntas durante o Sprint.

A dinamica


História 1: Juca - Pedro
História 2: Lucas - Thiago
História 3: Maria - Carla
1º Dia


História 1: Juca - Carla
História 2: Lucas - Pedro
História 3: Maria - Thiago
2º Dia


História 1: Carla - Thiago
História 2: Lucas - Juca
História 3: Maria - Pedro
3º Dia

E assim por diante…

Baby steps

Como disse, hoje estou começando com Pair na minha equipe, ela será uma cobaia dentro da empresa. Tendo bons resultados, poderemos expor para as outras equipes também dotarem o uso do Pair Programming.

Resumindo…

Não adianta impor, de cara, que toda a empresa adote o uso do Pair, escolha uma equipe madura, pense pequeno e, dando tudo certo, vá expandindo até que isso vire uma cultura dentro da empresa.

Respeite a opinião dos outros, aceite a derrota e mude de empresa se for o caso. Mas não faça inimigos tentando evangelizar algo. Acredite, não vale a pena. Se for necessário, peça ajuda. Tem muita gente na internet usando Pair.

Você, assim como eu, já deve ter se deparado com o problema de gerar uma cobrança para alguém através da internet e não queria entrar no painel de controle do PagSeguro e mandar aquele e-mail padrão que eles enviam quando fazem uma cobrança.

Ao invés disso você quer que ele acesse uma url única (bit.ly e tinyurl.com, por exemplo) para que ele possa fazer o pagamento via PagSeguro. Assim você pode fazer o e-mail formatado como você desejar. Talvez você considere essa mesma formula para mandar scraps via Orkut/FaceBook/Twitter/Skype/etc com cobranças ou pagamentos sem que você tenha a necessidade de escrever um formulário nos padrões do PagSeguro.

Existem inúmeras possibilidades para o PagSimples, use com moderação

Acontece que nem sempre você pode inserir HTML onde você gostaria que as pessoas lhe dessem dinheiro, como um link do youtube. Então faça uma cobrança no PagSimples e mande para quem você quiser.

Veja como é simples: http://pagsimples.dgmike.com.br/p/4b537c4bb8aed

O PagSimples é mais um projeto de uma madrugada (como diria o Marco Gomes) escrito com o Ice-Baby que foi desenvolvido a partir de uma conversa que tive com o Elcio dentro de um taxi.

Você já precisou ter o rodapé fixo no fim da página algum dia. Normalmente os clientes chatos acham feio aquele rodapé terminando no meio da página quando há pouco conteúdo. Há uma técnica no CSS que resolve isso. Não funciona no IE6, já aviso agora. Na verdade, tem um jeito de funcionar, mas não quero te acostumar mal.

Lembrando que você pode fazer isso facilmente com JQuery.

Suponha que você tenha o código HTML:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
	"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
 
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
	<meta http-equiv="Content-Type" content="text/html; charset=utf-8"/>
 
	<title>Tableless.com.br</title>
</head>
 
<body>
 
<div class="geral">
	<div class="header">
		HEADER
	</div>
	<div class="aside fleft">
		ESQUERDA
	</div>
	<div class="aside fright">
		DIREITA
	</div>
	<div class="content">
		<p>
		Lorem ipsum dolor sit amet, consectetur adipiscing elit. Proin augue erat, ullamcorper pulvinar malesuada ultricies, mollis non magna. Curabitur quis nisi ut ligula ultricies gravida. Suspendisse elit justo, vulputate in facilisis sed, tristique id nisi. Maecenas risus quam, suscipit eu vehicula ut, ultricies in neque. Donec gravida tristique turpis ut interdum. Donec lacinia nisi id enim lacinia sit amet facilisis est ullamcorper. Curabitur ipsum libero, sollicitudin nec rhoncus quis, congue non ipsum. Etiam at eros dolor. Mauris non erat vitae leo faucibus fermentum. In consectetur, diam eget faucibus dignissim, urna justo pretium dui, nec eleifend neque velit vitae odio. Nam et tristique turpis. In dictum commodo sem ut dignissim. In convallis quam non tortor posuere sed ornare nulla pulvinar. Suspendisse placerat turpis in tortor rutrum nec mollis nulla posuere. Integer tellus est, rhoncus ut sagittis eget, mattis a velit. Vestibulum ante ipsum primis in faucibus orci luctus et ultrices posuere cubilia Curae; Quisque gravida posuere orci nec ornare. Donec elit nulla, aliquam eget cursus a, commodo sed odio.
		</p>
		<p>
		Duis id metus enim, sed dignissim magna. Quisque dapibus pulvinar diam eget adipiscing. Ut aliquet ipsum quis lorem elementum lacinia. Vestibulum feugiat ultrices orci, vel sollicitudin nibh rutrum eu. In gravida tincidunt ornare. Aenean vestibulum leo eu orci egestas semper. Proin euismod dapibus tempor. Class aptent taciti sociosqu ad litora torquent per conubia nostra, per inceptos himenaeos. Suspendisse rutrum purus eget lectus ultricies a consectetur ante laoreet. Phasellus ullamcorper gravida risus vitae convallis. Curabitur ante lorem, faucibus in tincidunt quis, ullamcorper at lectus. Fusce fermentum blandit varius. Donec a quam id massa bibendum commodo sit amet vel felis. Sed magna nibh, convallis nec dignissim non, vestibulum adipiscing ipsum. Mauris cursus fringilla tortor eu feugiat. Vivamus vestibulum dapibus justo, porttitor luctus nisi posuere at. Nunc mi elit, suscipit id venenatis at, suscipit nec purus. Donec malesuada fringilla tempor. Pellentesque vehicula diam a magna commodo sagittis. Nulla facilisi. 
		</p>
	</div>
	<div class="footer">
		FOOTER
	</div>
</div>
 
</body>
</html>

E o seguinte CSS:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

*  {
	margin:0;
	padding:0;
}
 
html, body {height:100%;}
 
.geral {
	min-height:100%;
	position:relative;
	width:800px;
}
 
.footer {
	position:absolute;
	bottom:0;
	width:100%;
}
 
.content {overflow:hidden;}
.aside {width:200px;}
.fleft {float:left;}
.fright {float:right;}

Na linha 6, você faz com que as tags body e html tenham 100% de altura. Isso fará com que o rodapé entenda que o limite dos dois elementos seja o final da janela do navegador.

Na linha 8, defino que a largura mínima do div GERAL, que é o div que envolve todo o site, seja de 100%. E defino um position: relative; para que o footer seja referenciado por ele.

Na linha 14, eu defino um position: absolute; e bottom:0; para footer, forçando sempre para o final do div.
Se houver pouco conteúdo o Rodapé fica lá embaixo, se houver muito, o rodapé desce junto com o conteúdo.

Funciona em IE7+ e em bons browsers.

Link para o arquivo de exemplo: Footer fixo no Rodapé

• Tutorial Tableless Básico
• Introdução ao CSS Animation
• Formulário Básico em 8 minutos – Tableless form
• Image-Replacement x Imagens
• Centralizando um objeto na Horizontal e Vertical com CSS

Fazer menus com CSS é relativamente simples. Não precisamos de muitas linhas de código para fazer um menu totalmente personalizado. O Menu da Livraria Cultura é feito com Tabela. Na verdade, todo o site deles é feito com Tabelas, mas esse é outro assunto.

Você pode ver o menu deles aqui.

O Código HTML do menu deles é:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

 
<table border="0" cellpadding="0" cellspacing="0" width="100%">
<tbody><tr>
	<td><ul id="jsddm">
		<li id="mainmenu-livro" style="height: 22px; width: 79px;">
 
				<a href="/scripts/cultura/index.asp?sid=89120138612112390515516911&amp;k5=2FEC93B&amp;uid="><img src="imagem/_topo/abas/novo_livros.gif" alt="Livros" border="0"></a>
			<ul id="mainmenu-livro-sub" style="padding: 5px; background: rgb(11, 161, 176) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous; position: absolute; width: 69px; z-index: 350; margin-top: -2px; list-style-type: inherit; list-style-image: inherit; list-style-position: inherit; visibility: hidden;">
<li>
<a style="color: rgb(255, 255, 255);" href="/scripts/cultura/index.asp?lingua=POR&amp;sid=89120138612112390515516911&amp;k5=2FEC93B&amp;uid=">Português</a>
<a style="color: rgb(255, 255, 255);" href="/scripts/cultura/index.asp?lingua=ING&amp;sid=89120138612112390515516911&amp;k5=2FEC93B&amp;uid=">Inglês</a>
<a style="color: rgb(255, 255, 255);" href="/scripts/cultura/index.asp?lingua=ESP&amp;sid=89120138612112390515516911&amp;k5=2FEC93B&amp;uid=">Espanhol</a></li><li>
<a style="color: rgb(255, 255, 255);" href="/scripts/cultura/index.asp?lingua=FRA&amp;sid=89120138612112390515516911&amp;k5=2FEC93B&amp;uid=">Francês</a></li><li>
<a style="color: rgb(255, 255, 255);" href="/scripts/cultura/index.asp?lingua=ITA&amp;sid=89120138612112390515516911&amp;k5=2FEC93B&amp;uid=">Italiano</a></li><li>
<a style="color: rgb(255, 255, 255);" href="/scripts/cultura/index.asp?lingua=ALE&amp;sid=89120138612112390515516911&amp;k5=2FEC93B&amp;uid=">Alemão</a>
 
</li>
			</ul>
		</li>
	</ul>
		</td>
	<td><a href="/scripts/videos/index.asp?sid=89120138612112390515516911&amp;k5=2FEC93B&amp;uid="><img src="imagem/_topo/abas/b_dvds2.gif" alt="DVDs" border="0"></a></td>
	<td><a href="/scripts/musica/index.asp?sid=89120138612112390515516911&amp;k5=2FEC93B&amp;uid="><img src="imagem/_topo/abas/b_cds2.gif" alt="CDs" border="0"></a></td>
	<td><a href="/scripts/games/index.asp?sid=89120138612112390515516911&amp;k5=2FEC93B&amp;uid="><img src="imagem/_topo/abas/b_games2.gif" alt="Games" border="0"></a></td>
                               <td><a href="/scripts/hotsites/index.asp?sid=89120138612112390515516911&amp;k5=2FEC93B&amp;uid="><img src="imagem/_topo/abas/novo_sitesesp.gif" alt="Hotsites" border="0"></a></td>
 
	<td><a href="/scripts/eventos/index.asp?sid=89120138612112390515516911&amp;k5=2FEC93B&amp;uid="><img src="imagem/_topo/abas/novo_eventos.gif" alt="Eventos" border="0"></a></td>
	<td width="100%"></td>
</tr>
</tbody></table>

Eu não encontrei qual seria o pedaço do CSS referente ao menu, por isso eu não vou colar aqui.

O problema da versão do menu deles é que é todo feito com imagens e usa muita tabela. Há também código CSS inline. Isso prejudica leitores de tela, prejudica Google, e manutenção.
A versão que sugerimos é feita utilizando a técnica Image-Replacement. Segue abaixo o código HTML:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

<div class="nav">
	<ul>
		<li class="navlivros"><a href="#">Livros</a>
			<ul>
				<li><a href="#">Português</a></li>
				<li><a href="#">Inglês</a></li>
				<li><a href="#">Espanhol</a></li>
				<li><a href="#">Francês</a></li>
				<li><a href="#">Italiano</a></li>
				<li><a href="#">Alemão</a></li>
			</ul>
		</li>
		<li class="navdvd"><a href="#">DVDs</a></li>
		<li class="navcd"><a href="#">CDs</a></li>
		<li class="navgames"><a href="#">Games</a></li>
		<li class="navsitesesp"><a href="#">Sites especiais</a></li>
		<li class="naveventos"><a href="#">Eventos</a></li>
	</ul>
</div>

Abaixo o Código CSS:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50

* {
	margin:0;
	padding:0;
	list-style:none;
}
 
.nav {padding:10px;}
 
.nav ul li {float:left; position:relative;}
 
/* Define que todos os submenus aparecem quando passarmos o mouse no LI "pai" */
.nav ul li:hover ul {display:block;}
 
/* Define o estilo dos links */
.nav ul li a {
	float:left;
	height:22px;
	text-indent:-9999px;
	overflow:hidden;
	background-position:center center;
	background-repeat:no-repeat;
}
 
/* Adiciona o background e a largura nos elementos do menu */
.nav ul li.navlivros a {width:79px; background-image:url(imagem/_topo/abas/novo_livros.gif);}
.nav ul li.navdvd a {width:79px; background-image:url(imagem/_topo/abas/b_dvds2.gif);}
.nav ul li.navcd a {width:79px; background-image:url(imagem/_topo/abas/b_cds2.gif);}
.nav ul li.navgames a {width:79px; background-image:url(imagem/_topo/abas/b_games2.gif);}
.nav ul li.navsitesesp a {width:149px; background-image:url(imagem/_topo/abas/novo_sitesesp.gif);}
.nav ul li.naveventos a {width:109px; background-image:url(imagem/_topo/abas/novo_eventos.gif);}
 
/** Define que a UL do submenu está escondida por default. E define o visual do submenu */
.nav ul li ul {
	display:none;
	background:#00A2B0;
	width:70px;
	position:absolute; top:22px; left:0px;
	padding:4px;
}
 
/* Resetamos todo o estilo dos links do submenu. Isso poderia ser evitado se o IE7 conhecesse seletores complexos ou com JQuery */
.nav ul li ul li a {
	font:13px verdana, arial, tahoma, sans-serif;
	background-image:none !important;
	text-indent:0;
	float:none;
	color:white;
}
 
.nav ul li ul li a:hover {text-decoration:none;}

Veja o resultado do menu reconstruído aqui.

O Submenu na versão original, eu fiz utilizando apenas CSS. Testei em Firefox e IE7/8. Funciona que é uma beleza. Sem Javascript, sem JQuery, nem nada.
Se o IE7 já conhecesse seletores complexos, não precisaríamos resetar todos os links dos submenus como fizemos na linha 35.
O Código CSS, embora pareça longo, ele está organizado para ser fácil de adicionar outros elementos.

Sempre que escrever um CSS, pense sempre no futuro. Um CSS para resolver um problema imediato, normalmente tem menos código. Mas ele resolve apenas aquele problema específico. Se você fizer um CSS abrangente e pensando no futuro, seu código fatalmente vai ficar maior. Mas você terá menos retrabalho ao fazer as alterações futuras. Eu prefiro.

Pegue aqui os dois códigos para estudar: Reconstrução Menu Livraria Cultura

• Image-Replacement x Imagens
• O que são Media Types do CSS?
• Tutorial Tableless Básico
• Produtividade: editores e snippets
• Versionamento inteligente para mobiles

Quem conhece o começo do Tableless.com.br, lembra dos “Convertidos do Tableless”. Os convertidos era uma área no Tableless onde eu reimplementava as homes de grandes sites utilizando HTML e CSS. Era uma época onde ninguém fazia websites sem tabelas, ninguém usava CSS direito e o HTML era feito “nas coxas”. Era uma época também que os desenvolvedores duvidavam da possibilidade de fazer websites apenas com CSS, posicionando e diagramando os elementos sem tabela. Por isso, tive a idéia de criar um movimento onde o objetivo não era dar tapas na cara, mas apenas aprender e ensinar. Mostrar que até mesmo websites que foram pensados para tabela, podiam ser feitos com CSS, sem grandes problemas e o mais interessante, compatível com a maioria dos browsers.

Os convertidos do Tableless não existe mais. Algumas empresas que tiveram seus sites convertidos, acharam que o Tableless estava copiando seus layouts e etc. Mandaram uma cartinha extrajudicial, fazendo com que tirássemos seus sites (convertidos) do ar. Bem, fizemos isso e para evitar outros problemas, retiramos toda essa seção do ar.

Hoje, os Convertidos antigos não iriam fazer muito sentido, já que atualmente todos os sites são “Tableless”. Entretanto, o código de muitos sites são feitos de uma maneira, vamos dizer assim, não adequada. Por isso, levantarei a questão aqui novamente, mas farei o seguinte: durante algum tempo, pegarei partes de grandes sites conhecidos, recodificarei de uma maneira que eu acho que seria a ideal, e publicarei aqui os resultados.

Deixo bem claro que isso não passa de um estudo. Publicarei aqui os resultados para dividir com vocês o conhecimento adquirido e também ouvir as opiniões de vocês leitores.
Se houver algum desenvolvedor que trabalha nas empresas que citarei daqui pra frente, por favor, pode entrar em contato comigo se preferir. Vamos conversar em como a Visie pode ajudar você a resolver problemas.

Você já pode ver o primeiro Convertido: Convertido – Menu (Livraria Cultura).

• Navegando com a jQuery
• Produtividade: editores e snippets
• Convertido – Menu (Livraria Cultura)
• Ah, o maravilhoso mundo real
• Não “otimize” seu código

Fernando Sergio! posted a photo:

Passei a última semana no IPAE, aqui. É o colégio em que fiz o segundo grau (faz tempo!), um lugar fantástico, ao pé de uma montanha, região com paisagens inacreditáveis. Me hospedei no colégio com minha família, para matar saudades, e todos os dias saíamos para visitar algum lugar em Petrópolis ou Teresópolis.

Há catorze anos, quando estudei lá, telefonava para minha família uma vez por semana apenas, pois os interurbanos eram muito caros. Dessa vez, estava conectado via rede 3G o tempo todo. O mundo mudou muito rápido em catorze anos. Ponto para o 3G da Claro, que funcionou em todo lugar onde fui, inclusive em todo o trajeto paulista (Dutra, Carvalho Pinto, Ayrton Senna) e em boa parte do estado do Rio de Janeiro. Na região de Itatiaia virou 2G, mas continuou funcionando.

Antes de sair para viajar, usávamos o Google Maps e a Wikimapia para encontrar os pontos de interesse. O problema? Depois de encontrar o ponto de interesse, meu sobrinho tinha que digitar os endereços no GPS para obter a rota. E quando o ponto de interesse ficava no meio de uma estrada, o jeito era navegar à mão no GPS até o lugar, arrastando o mapa para cá e para lá.

Será que só eu sofri com isso? Vocês, meus bem informados leitores, conhecem algum aparelho de GPS que fale com a web, através de alguma integração maluca? O ideal seria GPRS. Seria muito interessante se, enquanto estou dirigindo, um passageiro pudesse pegar o GPS e ver a navegação acontecendo sobre a Wikimapia, por exemplo. Alguém já viu isso? Alguma idéia de como fazer?

O WRT é uma nova maneira de desenvolver aplicativos para celulares nokia.

Disponivel para as versões s60 (de forma mais estável), o WRT simplesmente transforma o seu aplicativo numa pagina web.

Para quem já esta acostumado a desenvolver para a WEB não vai sentir muita dificuldade com o WRT, o unico ponto chave é: “Tudo dentro de um único HTML”.

Isso mesmo que você leu, todas as suas páginas irão ficar dentro de um único HTML, e sua linguaguem de programação será o Javascript.

No Forum Nokia, você vai encontrar um material vasto sobre isso, mas a minha idéia é trazer um aplicativo exemplo, e como no post anterior eu falei de um projeto pessoal em WRT, eu tava pensando em trazer ele, mas eu ainda estou pensando.

Por isso, como inicio eu vou deixar o link do WRT no fórum da nokia.

E para aqueles que já estão familiarizados com isso, eu deixo o Guarana, biblioteca jQuery para WRT.

Eu passei um tempo escrevendo coisas legais nesse blog.

Mas eu passei por uma mega transformação, e o blog não me acompanhou.

Primeiro que eu tive que atualizar o blog, pois ele ainda estava na versão 2.7 (issu me deixou mal)

Segundo, porque eu não sou mais usuário de Ubuntu, podem me bater, hoje eu sou um usuário MAC OS.

Dae ficou a duvida, como deixar de falar de Ubuntu e falar de Mac, pois bem, isso é uma coisa que eu to pensando ainda.

Um dos projeto pessoais que eu to iniciando é um aplicativo em WRT. Quando ficar pronto eu falo mais, por enquanto, eu soh queria voltar a escrever um pouco.

Fernando Sergio! posted a photo:

Fernando Sergio! posted a photo:

Fernando Sergio! posted a photo:

Fernando Sergio! posted a photo:

Fernando Sergio! posted a photo:

Fernando Sergio! posted a photo:

Eu gostaria muito de fazer um artigo escrevendo uma retrospectiva do ano que passou. Mas isso é tão démodé, que resolvi deixar para lá. Mesmo assim, não há como falar do ano que vem, sem me alegrar dos avanços que o desenvolvimento web passou em 2009. Em 2009 foi o ano que os desenvolvedores se libertaram do IE6. Não que o IE6 seja uma coisa ruim, mas porque ele se tornou algo ruim, assim como os browsers de hoje podem se tornar um dia. Mas entenda, a saída do IE6, pelo menos para mim, foi um marco na história dos Padrões Web. É como se nós, desenvolvedores, tivessemos quebrado os grilhões que nos prendiam ao passado. Liberdade, entende? Isso prova que podemos mudar os paradigmas do mercado, quando quisermos.

2010 vai ser diferente. É o ano onde você começa um novo ciclo de desenvolvimento. Um ano onde você vai ser obrigado a mudar a sua forma de desenvolver. Melhor mudar sua cabeça se você acha que o HTML 5 é só uma sopa de novas tags. Melhor você rever seus conceitos, se você ainda acha Acessibilidade pode ser deixado para depois e que SEO é algo antigo e que ninguém acessa a internet via celular. E se você acha que a web vai continuar sendo a mesma para sempre. Leia:

“It’s been said today that, yes, this is a markup language for a Web page. But it’s a computing platform, too. The really big shift happening here is the shift to being a client-side computing platform,” Tim Berners-Lee

2010 é o ano onde você vai usar novas propriedades e seletores do CSS 3. Onde você vai fazer bordas arredondadas direto pelo CSS. Onde você vai abusar do Graceful Degradation e vai educar seu cliente a usar um browser mais novo. É o ano onde você dita as regras do mercado e não o contrário. Experimente mudar.

Se você ainda não percebeu, há um movimento grande a favor da evolução dos Padrões Web. 2010 não é 2004 onde você só começou a fazer tableless porque foi obrigado.

2010 é o ano para você mudar. Mudar seu método de trabalhar. Mudar seu browser padrão de navegação. Mudar a cabeça do seu cliente por mais que ele seja antiquado e retrógrado. Não importa o que você faça, mas mude.

Espero que 2010 seja realmente novo para você.

• Produtividade: editores e snippets
• Google Apps não suportará mais IE6
• Simuladores de Browsers Mobiles

Hoje li o post do Rafael Lima e me deu vontade de falar sobre o assunto.

Conheço muita gente, incluindo donos de empresas de desenvolvimento, que confudem Programador Rápido com Qualidade/Produtividade. Além disso, essas pessoas costumam achar que quanto mais “Programadores Rápidos” forem contratados, mais rápidos seus projetos serão entregues, mais felizes seus clientes ficarão e mais projetos poderão desenvolver.

Isto é mentira!

Essas pessoas se esquecem que quanto maior a equipe mais complicado fica o gerenciamento, que quanto mais rápido um programador for mais bug este código terá. Sim, sim, eu também conheço muita gente boa que programa rápido e entrega código com qualidade, mas vamos concordar que infelizmente essa não é a realidade da grande maioria.

Como o Rafael Lima disse, antes de julgar e comparar um programador rápido com um lento, vamos ver se estão fazendo testes, se estão se preocupando com a qualidade antes de entregar o produto. Prefiro entregar um produto bom com alguns dias de atraso do que entregar na data e falhar quando o cliente for usar.

E por falar em testes, essas mesmas pessoas insistem em deixar “5 horas” no final do projeto para a equipe de QA. Pensam, ou fingem pensar, que isso é o bastante para garantir a qualidade do produto e o sucesso do projeto.

Vejo isso todos os dias e só lamento.

Essas pessoas precisam ler mais sobre Getting Real, Gerenciamento de Projetos Ágeis e Gestão de Pessoas.

Concordo com o Rafael quando ele diz que prefere um programador lento do que o “rapidão da turma”.

A Zend anúnciou ontem no seu perfil do facebook que irá criar uma área no portal zend.com com o intuito de divulgar os grupos de usuários PHP. Não importa de que país e localidade seja o seu grupo de usuários php. Se você quiser divulgar o seu grupo no site oficial da Zend. Envie um e-mail para localphp[arroba]zend.com com as seguintes informações:

Nome do Grupo
Localização do Grupo (Pais e Estado)
Informações para contato
Site
Uma Logo
Curta descrição do grupo.

É uma boa notícia. Ter o seu grupo reconhecido pela empresa responsável pelo desenvolvimento da linguagem PHP é um ótimo empurrãozinho para o seu grupo crescer. Boa Sorte!

[]’s
Igor.

Hoje irei compartilhar com você uma questão que me perguntaram em uma entrevista de emprego há uns 5 anos atrás. Essa questão realmente me inspirou e mudou minha perspectiva na maneira pelas quais busco resolver problemas.

Questão: Você está está dirigindo um carro em uma noite de tempestade e está chovendo pesado quando, de repente, ao passar por uma parada de ônibus, você vê três pessoas esperando por um ônibus:

1. Uma senhora de idade que parece que está a beira da morte;
2. Um amigo das antigas que já salvou sua vida uma vez;
3. O(a) parceiro(a) perfeito(a) que você sempre sonhou em passar o resto da vida;

Qual deles você ofereceria uma carona se coubesse apenas um passageiro em seu carro?

Esse é um dilema ético e moral, então veremos as opções que apareceram na minha cabeça no momento:

- Você poderia pegar a senhora de idade, porque se ela fosse morrer, você podeira salvá-la primeiro;
- Ou você pode pegar seu velho amigo que uma vez salvou sua vida, e essa seria a chance perfeita de retribuir o favor.
- No entanto, você pode nunca mais encontrar seu par perfeito;

Não direi a resposta que eu dei, mas nem preciso, eu não fiquei com o emprego. Entretanto, fiquei intrigado, e liguei uma semana depois para perguntar qual era a resposta certa…

E foi isso que eles me responderam:

O candidato que foi contratado nos deu essa resposta:
“Eu daria a chave do carro para meu velho amigo que levaria a senhora da idade para o hospital. Eu ficaria para trás… e aguardaria o próximo ônibus com a parceira dos meus sonhos”.

Algumas vezes, nós ganharíamos mais de fossemos capazes de ultrapassar nossas limitações. Nunca se esqueça de pensar fora da caixa ou além do óbvio.

Vi este texto aqui.

Uma coisa que sempre me espantou é a ineficiência dos servidores de DNS dos provedores de hospedagem brasileiros. Já testei ADSL, cabo coaxial, 3G e, aqui em São Paulo, de maneira geral as conexões são boas. Mas como o servidor de DNS dos provedores é ruim, a navegação é muito lenta.

Eu vinha usando OpenDNS, cuja performance é muito boa. Mas hoje resolvi testar o Google Public DNS. Deixa o OpenDNS no chinelo!

Como o Google conseguiu isso? Um mega sistema de cache, com cobertura global, e um inovador sistema de prefetching. Se você não está usando ainda, vale a pena testar.

Para facilitar a vida dos usuários de Linux, segue meu /etc/resolv.conf:

nameserver 8.8.8.8
nameserver 8.8.4.4

Sim, são esses IPs mesmo Não é fantástico?

Recentemente atualizei meu Mac para o Snow Leopard e fui logo configurar meu ambiente de desenvolvimento.

Como alguns já sabem, programo em Python, mas atualmente estou afastado da linguagem, utilizando 100% Rails.

Uma das coisas que aproveitei quando resolvi instalar o Snow Leopard foi formatar todo o HD. Com o tempo fui acumulando alguns lixos, então juntei o útil com o agradável e fiz uma bela faxina.

Outra coisa: meu Vim estava todo bagunçado. Fiz uma cagada nele e estava difícil trabalhar com ele, então estava usando somente o TextMate. Adoro o TextMate, é um baita editor, mas não é meu Vim. Com o Vim me sinto mais em casa e não sofro quando preciso programar em uma máquina que não seja meu Mac, afinal, o Vim é free e roda até no Windows (eca!).

Bom, vamos lá!

O Vim

Para facilitar sua vida, criei um repositório do meu Vim, todo configurado, pronto para uso.

Para instalá-lo, basta fazer o clone:

$ git clone git://github.com/willian/willvim.git

Entre no diretório criado pelo comando acima e execute o comando abaixo:

$ chmod +x install.sh
$ ./install.sh

Os comandos acima baixam os repositórios dos plugins e faz a instalação dos arquivos no seu diretório $HOME/.vim.

ATENÇÃO: Esses comandos não funcionarão no Windows. Em breve configurarei isso.

MacVim

Gosto de usar o MacVim (ou o gVim quando estou no Linux), pois tem uma aparência melhor do que o Vim no terminal.

Entre na página de download do MacVim e baixe a versão mais nova. A versão "stable" até a data deste post é a MacVim-7_2-stable-1_2.tbz.

Se você está no Linux e usa Ubuntu, basta rodar o comando abaixo:

$ sudo apt-get install vim vim-gnome vim-full vim-python vim-rails vim-ruby

Agora basta rodar o comando mvim ou gvim (caso você esteja no Linux) no terminal para abrir o Vim no modo gráfico.

Ruby on Rails

Tanto a linguagem quando o framework já estão instalados no seu Mac, mas precisamos atualizá-los. Na verdade, você pode apenas atualizar o Rails, e é exatamente isso que vou mostrar aqui.

Atualizando o RubyGems

$ sudo gem install rubygems-update

Esse comando instala a nova versão do RubyGems. Para verificar a versão instalada, rode o comando abaixo:

$ gem -v
1.3.5

Até a data deste post a versão mais nova é a 1.3.5.

Atualizando suas gems

$ sudo gem update

Atualizando o Ruby on Rails

Nesse ponto a versão do Rails já deve estar atualizada, mas caso não esteja, rode o comando abaixo:

$ sudo gem install rails

MySQL

Apesar de poder rodar o Rails com o SQLite, gosto de usar o MySQL no ambiente de desenvolvimento. Para isso, acesso a página de download do MySQL e busque a versão mais nova. Na data de criação deste post a versão mais nova é a MySQL 5.1.

ATENÇÃO: Só fique atento à arquitetura escolhida. O Snow Leopard roda com 64bits, então baixe a versão x86_64.

Feito isso, hora de instalar a gem do MySQL:

$ sudo env ARCHFLAGS="-arch x86_64" gem install mysql -- --with-mysql-config=/usr/local/mysql/bin/mysql_config

Testando tudo

Vamos criar um aplicação de teste para verificar se o Rails está rodando corretamente, incluindo o MySQL:

$ rails blog -d mysql
$ cd blog/
$ script/generate scaffold Post title:string body:string
$ rake db:create
$ rake db:migrate

Se não aparecer nenhuma mensagem de erro, os procedimentos acima foram executados corretamente e você agora tem um ambiente completo para desenvolver seus aplicativos com Rails.

Ontem aconteceu a Conferência da W3C Brasil. Infelizmente não pude ir, mas acompanhei tudo pelo twitter através da hash tag #webbr2009.

Diversos assuntos foram discutidos neste dia, dentre eles o que mais me chamou a atenção foi a quantidade de opniões divergentes com relação ao ter ou não ter certificações para os profissionais que lidam com o desenvolvimento front-end todos os dias.

De todas as opniões que foram expressadas neste dia, se juntar tudo e fazer uma categorização das opiniões, vocês vão ver que tudo gira em torno da desilusão dos profissionais quanto a este assunto.

Vi muitas pessoas sendo contra a certificação, pelo fato de muitos ja terem comprovado e sentido na pele o grande interesse de algumas instituições – que prefiro não citar – em vender somente o papel e não o conhecimento.

Depois da discussão que tive com alguns amigos que trabalham na área pude ver que as pessoas não são desiludidas com A CERTIFICAÇÃO em si. Os profissionais estão desiludidos na maneira como ela é vendida e mantida pelas instituições e a forma como as empresas fazem a utilização desta certificação.

A certificação é vendida como se fosse um curso qualquer. Onde o candidato à certificação entra em uma salinha, responde umas perguntas e sai certificado. O que é uma demonstração CLARA de que as instituições não estão nem um pouco interessadas no nível do profissional que sai dali com este papel de baixo do braço e sim pelo dinheiro dos que acreditam que este papel vai mudar o seu mundo – o que tem uma pitada de verdade.

Vi também que muitos estavam “indignados” pelo fato das empresas utilizar tais certificações como filtro em um processo de seleção. Veja bem, eu também acho isso uma sacanagem mas não acho isso, o fim do mundo. A empresa tem um senso equivocado as vezes pensando que se eles ignorarem todos os que não tem certificação e entrevistar somente o que tem estarão fazendo um bom negócio pois os que não tem é lixo – na visão deles.

Mas por outro lado em grandes corporações este filtro serve puramente para agilizar o processo. Imagina uma empresa com uma fila de 3 mil candidatos a uma vaga. Eles iriam demorar 5 anos para entrevistar todo mundo da forma mais humana e minuciosa possível, mas infelizmente, eles acreditam que mesmo ignorando 2 mil sem certificações eles acreditam que pelo menos 10% destes mil que sobraram sejam bons profissionais.  Se pensarmos por este lado, é totalmente aceitável o filtro quando aplicado em uma situação como esta – mesmo sabendo que eles podem ter perdido os steve jobs pessoal deles. Steve Jobs não tem nível superior, imagina ele procurando emprego? milhares de empresas aplicando seus filtros em cima de uma mente brilhante, cool.

A minha opinião sobre estas certificações é: Devemos sim ter certificações. Quanto mais o nosso ramo amadurecer neste sentido e ter instituições que comprovem e testem os profissionais que atuam neste meio é mais um passo que damos rumo a extinção dos sobrinhos. Quanto mais formal tornarmos o nosso ramo de trabalho, mais dificulta o acesso das empresas sérias a profissionais sem compromisso e consideração com o ramo e as pessoas que atuam nele. Tevemos sim ter certificações, talvez tenhamos que amadurecer melhor esta idéia e talvez não oferecermos uma certificação de HTML ou CSS mas sim de Padrões Web, quem sabe…

Se a forma como tudo é “vendido” mudar, estas certificações servirão como uma forma de valorizar o profissional que possui esta certificação. Tudo tende a agregar valor.

Este é um ótimo assunto e que diferente de só fornecer a certificação, devemos GARANTIR que o profissional que porta este selo é um profissional que no mínimo se importa com a gente, com a nossa luta e principalmente, com o cliente.

Meu amigo Chris também falou e apontou suas consideração sobre o debate, vale a pena dar uma lida também.

[]’s
Igor.

Fernando Sergio! posted a photo:

Fernando Sergio! posted a photo:

Fernando Sergio! posted a photo:

Fernando Sergio! posted a photo:

Fernando Sergio! posted a photo:

Fernando Sergio! posted a photo:

Fernando Sergio! posted a photo:

Fernando Sergio! posted a photo:

Fernando Sergio! posted a photo:

Fernando Sergio! posted a photo:

Fernando Sergio! posted a photo:

Fernando Sergio! posted a photo:

Fernando Sergio! posted a photo:

Fernando Sergio! posted a photo:

Fernando Sergio! posted a photo:

Cansado de ler sobre este manifesto no Twitter. Resolvi dar uma googada para sumir com a minha wtf-face.

O que é o Manifesto Slow?

O Manifesto Slow é um manifesto criado por não sei quem cujo este criou um site chamado (claro): Manifesto Slow. Se você se der o trabalho de acessar verá de cara um resumo curto e grosso sobre o que é este manifesto.

“Esse manifesto não contém nada. Porquê? Fazer um consumiria tempo. E tudo se resume em ganhar tempo. Tempo para que? Para não fazer nada.”

E nisto se resumi o Manifesto. Todas as dicas e pensamentos são escritos no blog do manifesto slow com o único objetivo: Poupar tempo. Todas as dicas são totalmente e unicamente em prol de não fazer nada ou fazer menos.

Se você ainda não entendeu nada, no blog do manifesto eles já publicaram alguns exemplos de como você deve fazer para se unir ao Manifesto Slow.

Na minha humilde opnião, você deve tomar muito cuidado na hora de escolher o que vai ouvir e o que vai jogar fora. Nesta lista que eles divulgaram tem apenas 7 exemplos sobre o que se trata o manifesto slow e duas delas eu discordo e uma eu diria que há controversa. Quando temos o dom da palavra é melhor tomarmos cuidado com o que dizemos pois isso pode se virar contra você ou não.

A grande questão é: Tudo isso é uma grande piada ou eles querem mesmo de alguma forma mudar o mundo? rs.

O Twitter é o serviço de microblogging mais famoso do sistema solar, porém, muitas pessoas ainda não fazem a menor idéia para o que serve e qual a sua real utilidade.

Acompanhando as atualizações do meu Twitter acabei me deparando com este vídeo onde o William Bonner fala sobre o Twitter, conta como ele faz o uso do Twitter e o que mudou na vida dele após a sua utilização.

Para quem ainda não entendeu o seu uso e não faz a mínima idéia para que serve, o video da uma clareada na cabeça de vocês.

Twitter do Willian Bonner: @realwbonner

William Bonner fala sobre o Twitter

[]’s
Igor.

Sei, o projeto está um pouco deixado de lado, mas este ano tem sido muita correria e nos momentos de desespero o CodeIgniter tem sido o meu framework padrão. Acontece que fiz uma busca na internet e encontrei um projeto chamado Internet Communications Engine – ICE, que faz parte da familia ZeroC e suporta PHP. Para não haver confusão, decidi trocar o meu humilde projeto de framework. Agora ele deixa de se chamar Ice e passa a se chamar Ice-Baby, em homenagem a uma música que gosto pra caramba do Vanilla Ice.

http://www.youtube.com/watch?v=h4v5MeJ5fVg

Na minha última palestra (PHP Minas) eu apresentei um microframework e ele me serviu de rascunho para o novo Ice-Baby. Talvez mantenha alguma coisa do Banco de dados do antigo Ice, mas provavelmente tudo irá mudar.

Alguns conceitos de MVC devem ser abstraidos quando você for usar o framework já que ele não exige uma estrutura lógica como a maioria dos frameworks por aí. Ao invés de você ter que pensar URL com arquivo, com classe e com método e assim por diante você deve pensar em mapear uma ou mais URLs e direcioná-las para a classe desejada. O método que ele irá usar é o método no qual o usuário chegou na página (get/post). Simples, né?! E os parâmetros, você decide o que é parâmetro também Veja um exemplo de código de como sua aplicação pode ficar:

1
2
3
4
5
6
7
8
9
10

<?php
require_once('appropriate/app.php');
 
app(array('^.*$' => 'Welcome'));
 
class Welcome {
  function get() {
    print 'Hello from Bahamas!';
  }
}

Sim! Você consegue escrever uma aplicação com apenas dez linhas de código.

No momento estou me concentrando a escrever a parte do Framework que conversa com o banco de dados (Models e seus resultados). Quem quiser acompanhar o desenvolvimento da ferramenta, pode acompanhar no github, dessa vez vai!

Quem quiser, pode usar outro framework enquanto o Ice-Baby não sai do Beta. Recomendo o Vórtice, Spaghetti e CodeIgniter. Os motivos pelos quais eu escolhi estes frameworks para indicar e não outros? Liberdade! Eu gosto de escrever código da forma que eu quiser sem ter que aprender muito para começar a usar uma ferramenta.

Só para deixar registrado: instalei o novo Ubuntu 9.10, Karmic Koala. Tenho um LG R405. Funcionou tudo de primeira, sem configurações esotéricas em arquivos texto misteriosos.

Boota rápido. Boota muito rápido. Estou feliz

[update 1] Olha que legal: qual o boot mais rápido - vídeo comparativo de boot entre o Karmic, o Jaunty, o Vista e o Seven. [/update 1]

Recentemente alguns site e blogs vem divulgando listas de dicas para se codificar em javascript. Apresentando melhores práticas de desenvolvimento e muitas dicas bacanas, Pensei que este seria um bom tópico para se extender e compartilhar com vocês. Neste post estou reunindo as minhas top 10 dicas e boas práticas para codificação javascript.

Espero que gostem.

1. Use o atributo defer para indicar o uso scripts externos no IE

O propósito do defer é avisar o script que está sendo requisitado externamente para esperar  até que a página seja carregada ou o DOM esteja preparado. O mesmo pode ser realizado através de bons métodos não-obstrutivos via javascript, que usualmente inclui códigos que previne a execução de scripts antes que o DOM seja carregado por completo.

A vantagem do defer ocorre quando utilizamos o Internet Explorer, tendo em vista que é único browser que suporta o atributo defer. Então, se você precisa de um rápido script que rode únicamente e exclusivamente no Internet Explorer, e você não quer que ele execute antes que o DOM esteja preparado, então simplesmente adicione defer="defer" no sua tag <script> e ela irá rapidamente tratar o seu problema. Corrigir a transparência de arquivos PNG no IE6 é uma das possibilídades práticas do uso do defer.

(Edit: O atributo defer deve ser usado quando escondemos um script de outros browsers com o uso dos comentários condicionais  – conditional comment – que afete somente os navegadores da Microsoft – de outra maneira o script vai rodar normalmente em outros browsers.)

2. Use o CData Section para previnir erros de validação XHTML Strict

Muitas vezes seus scripts vão residir em arquivos externos e chamados dentro da tag <script> dentro do  <head> do documento, ou então antes do fechamento da tag </body>.

Mas este documento pode estar eventualmente usado em um local que junto dele existem marcações HTML, como abaixo:

<div>
<p>
<script type="text/javascript">
var my_variable = 100;
if (my_variable < 50) {
// alguma coisa aqui...
}
</script>
</p>
</div>

Você pode notar que no código acima, dentro do if, existe o símbolo <  que representa “menos”, que é parte da sintax, corréto? Este símbolo causa um erro de validação. O validador interpreta ele como um inicio de uma marcação ou uma tag HTML que não foi fechada, a não ser que você encapsule o seu código com o CData, assim:

<div>
<p>
<script type="text/javascript">
//<![CDATA[
var my_variable = 100;
if (my_variable < 50) {
// alguma coisa aqui...
}
//]]>
</script>
</p>
</div>

3. Evite palavras-chaves reservadas do JavaScript quando estiver criando funções e identificadores

Muitas palavras são reservadas no javascript, então você deve evitá-las quando forem criar variáveis ou outros idenficadores. A lista completa de palavras-chaves do javascript segue abaixo:

break
case
catch
continue
default
delete
do
else
finally
for
function
if
in
instanceof
new
return
switch
this
throw
try
typeof
var
void
while
with

4. Evite palavras reservadas do JavaScript quando estiver criando funções e identificadores

Que estão também algumas palavras reservadas, que não estão necessariamente sendo usadas pela linguagem mas são reservadas para o uso futuro. São estas:

abstract
boolean
byte
char
class
const
debugger
double
enum
export
extends
final
float
goto
implements
import
int
interface
long
native
package
private
protected
public
short
static
super
synchronized
throws
transient
volatile

5. Não mude o tipo das variaveis depois da declaração inicial.

No javascript, tecnicamente, isso é perfeitamente legal:

var my_variable = "Esta é uma string";
my_variable = 50;

Depois que a variável é inicialmente declarada como string na linha 1, na linha 2 o seu valor é mudado e o seu tipo também. Esta não é uma boa prática e deve ser evitada.

6. Não use variáveis globais.

Para previnir possíveis conflitos, em 99% dos casos, use o “var” no início quando estivermos declarando uma variável e seu valor. Isso faz com que a sua variável exista somente no escopo da função e não fora dela, ou seja, toda variável criada pelo var, só poderá ser acessível dentro do escopo no qual ela foi declarada e não mais fora dele. Então, se acontecer de você utilizar duas variáveis com o mesmo valor em lugares diferentes do seu script, nenhum conflito ocorrerá.

7. Javascript é Case-Sensitive.

Lembre-se do que vem a seguir: No código que segue temos duas variáveis que estão armazenando seus valores em 2 lugares diferentes na memória, e não um só, como alguns podem pensar. São duas variáveis completamente diferentes alocadas em lugares diferentes na memória:

var myVariable = "data";
var myvariable = "more data";

8. Use o switch para lidar com multiplas condições

Não faça isso:

if (example_variable == "cyan") {
// faça algo aqui...
} else if (example_variable == "magenta") {
// faça algo aqui...
} else if (example_variable == "yellow") {
// faça algo aqui...
} else if (example_variable == "black") {
// faça algo aqui...
} else {
// faça algo aqui...
}

Faça isso:

switch (example_variable) {
case "cyan":
// faça algo aqui...
break;
case "magenta":
// faça algo aqui...
break;
case "yellow":
// faça algo aqui...
break;
case "black":
// faça algo aqui...
break;
default:
// faça algo aqui...
break;
}

O segundo bloco de código faz exatamente a mesma coisa que o primeiro – mas o segundo é limpo, fácil de ler, fácil de dar manutenção e modificar.

9. Use o try-catch para previnir que erros sejam expostos para os usuários

Encapsulando todo o seu código no try-catch, você pode evitar que o usuário final nunca veja um feio erro de javascript exposto na tela. Assim:

try {
funcaoQueNaoExiste();
} catch (error) {
document.write("Um erro ocorreu.")
}

No código acima, eu tentei chamar uma função que não existe, para forçar um erro. O navegador não vai exibir o típico erro “not an object” ou “object expected”, mas ao invés disso, vai exibir um erro mais customizável que eu incluí dentro do meu “catch”. Você pode também deixar o catch vázio para nada ser mostrado para o usuário, ou você pode criar uma função que seja chamada dentro do catch que faça o tratamento deste erro para propósitos de debug etc.

Mantenha na sua cabeça que isso pode esconder erros do desenvolvedor também, então uma boa decumentação do código e comentários podem ser úteis neste ponto.

10. Faça comentários multi-linhas legíveis, mas simples

Em javascript, você pode comentar uma linha de código colocando um // no início da linha. Você também pode criar um comentário em bloco como mostra a seguir: /* [comentário aqui ] */. Algumas vezes você precisa incluir um comentário longo, um comentário de mais de uma linha. Um bom método para se utilizar que não tenha uma visual esmagador, mas é fácil de identificar o código é esse a seguir:

/*
* Este é um comentário multi-linha...
* bla bla bla...
* bla bla bla...
* bla bla bla...
* bla bla bla...
*/

E é isso

Este artigo é uma adaptação e tradução do texto: 10 JavaScript Quick Tips and Best Practices

Nesta sexta-feira, dia 30 de outubro, o PagSeguro mudou a sua homepage e com ela muitas coisas novas aconteceram. Inclusive rolou uma palestra para 70 pessoas do twitter que acompanharam as mudanças do Twitter. A palestra foi ministrada pelo Dennis Ferreira e pela Valéria Santos. Pessoas que tive a oportunidade de conhecer de perto e eles são pessoas responsáveis e estão conscientes das mudanças e do impacto que esta mudança causa.

PagSeguro - Uma empresa UOL

Tem bastante gente falando sobre as novidades do novo site do PagSeguro por aí, então se quiser saber o que exatamente, recomendo os slides da palestra e uma busca no oráculo.

Mas, e na parte de códigos? O que muda? Você precisa atualizar seus códigos para essa nova plataforma? A resposta é simples e óbvia: NADA. Sim você não precisa atualizar seu código correndo achando que sua URL mudou. O PagSeguro deixou de ser implementado em ASP e passou a ser implementado em JAVA, o que deixou a aplicação muito mais robusta e segura, com isso a URL do retorno automático mudou. No site do PagSeguro eles indicam uma nova URL para o retorno automático ( https://pagseguro.uol.com.br/pagseguro-ws/checkout/NPI.jhtml ) mas a URL anterior continua funcionando normalmente e continuará por um longo tempo.

O pessoal do PagSeguro fez todas as alterações no seu sistema e antes de por no ar fez uma longa bateria de testes e só foi para o ar após verificar se todas as bibliotecas oficiais continuavam funcionando normalmente. Então, as URL de retorno automático continuará funcionando normalmente. Com o passar do tempo, é óbvio que a URL anterior morra, mas isso acontecerá muito tempo depois, até perceberem que ninguém mais utiliza a URL antiga.

A mudança vai ser longa e sutil, com o tempo iremos alterar todos os scripts para a nova URL, mas você não precisa sair desesperado para trocar suas URLs. O PagSeguro pensou bem nisso quando alterou a url de retorno automático. Eu mesmo fiz testes hoje de tarde para comprovar isso, já que recebi algumas dúvidas de alguns clientes e algumas pessoas reclamaram disso no twitter. Portanto, não se preocupe, você não precisa alterar nada no seu script de retorno automático do PagSeguro.

Antes de mais nada, Benchmarking é o nome pomposo dado às práticas adotadas na indústria (não importa qual) que visam alcançar um desempenho/qualidade superior. Ou seja, Benchmarking é todo tipo de prática cujo objetivo é melhorar/maximizar/amplificar os resultados.

No artigo de hoje vamos abordar benchmarking focado em código, desempenho especificamente. Não é meu objetivo neste artigo aprofundar sobre profiling etc. Existem muitas práticas de benchmarking que podem ser utilizadas para poder alcançar algum tipo de amplificação na sua área, porém não daria para falarmos detalhadamente de todas em um único artigo.

Quando desenvolvemos aplicações para Internet e o stress da aplicação será muito grande (como um todo), temos que ter cuidado, muito cuidado. Conhecer mais de uma forma de se implementar uma única solução pode ser o que vai salvar o seu pescoço.

Benchmarking de código – na prática

Muitas vezes, quando estamos meditando para solucionar um problema, precisamos saber se aquela implementação é rápida. Mas, como assim, rápida? Como eu vou saber se uma determinada implementação de código/função é rápida o suficiente de forma que supra as necessidades sem comprometer a qualidade de modo geral do sistema?

Vale lembrar que o método que vou mostrar aqui faz com que os resultados variem de máquina para máquina, pois é tudo uma questão de processamento. Os resultados aqui apresentados são apenas para ILUSTRAR e SIMULAR para atingirmos resultados significantes.

Este é o seu momento “MythBusters”.

Descobrir qual é a forma mais rápida de se resolver um problema é uma tarefa simples (nem sempre), em determinados casos, não temos um parâmetro para saber se devemos seguir pelo caminho A ou B, tudo o que nos resta é saber várias formas de se codificar/implementar uma determinada solução e medir o desempenho de todas elas, cada trecho, para assim, resolver o problema.

Vou dar um exemplo de como se medir o desempenho de uma implementação de código, levando em conta um problema que tivemos aqui no trabalho.

Tivemos que desenvolver um framework adhoc (free style) onde nós conseguíssemos obter resultados semelhantes a alguns frameworks bem comuns na Internet como Code Igniter, Cake PHP etc. MVC, Inflector, ActiveRecord, Rotas de Urls etc.

Agora vem a pergunta na cabeça de vocês:
- Por que re-inventar a roda?

A empresa que pediu para que a gente re-inventasse a roda, alegou que estes são frameworks não “oficiais”, e são feitos/mantidos por pessoas em que eles não confiam (untrusted or non certified application).

Resumindo? Eles queriam ver como a “coisa” era implementada, para poder, assim, atingir o melhor desempenho e retirando tudo o que eles não precisam da aplicação, tornando-a mais leve.

A grande questão?

O aquivo ActiveRecord.class.php está demorando muito para terminar o seu serviço, quando você instanciava uma nova classe, a dita cuja tinha um modelo, que, por sua vez, também possuía um controle onde possuía todas as regras do negócio.

Sempre que executássemos uma método da classe por ex ->find, findFirst ou findAll ele retornava um array de objetos, ou seja, era um array e todas as suas posições eram compostas por objetos e suas respectivas propriedades (atributos).

Exemplo

Array
(
    [0] => Usuarios Object
        (
            [nome] => Igor Escobar 1
            [email] => blog@igorescobar.com
        )

    [1] => Usuarios Object
        (
            [nome] => Igor Escobar 2
            [email] => blog@igorescobar.com
        )

    [2] => Usuarios Object
        (
            [nome] => Igor Escobar 3
            [email] => blog@igorescobar.com
        )

)

Era mais ou menos assim que ele retornava os usuários de uma determinada tabela. Este é um array de objetos com apenas 3 elementos, mas para você ter um resultado para que possamos simular um resultado no benchmarking mais expressivo, você precisa de um array de objetos com mais elementos, pois iria exigir mais do processador, etc. No nosso experimento vou aumentar este array de objetos para 10.000 elementos e veremos quanto tempo ele demora para fazer o trabalho.

Medindo o desempenho (do trecho)

Criei uma class de exemplo, apenas para conseguirmos a estrutura vista acima:

<?php
public class Usuarios {
	var $nome;
	var $email;
}
?>

Agora, eu crio a implementação para atingir o resultado esperado:

$arraUsuarios = array();
for($i = 1 ; $i <= 10000; $i++):
	$obUsuarios = new Usuarios();
	$obUsuarios->nome = "Igor Escobar {$i}";
	$obUsuarios->email = "blog@igorescobar.com";
	$arraUsuarios[] = $obUsuarios;
endfor;

Para medir o desempenho exatamente no trecho que queremos, eu utilizo a função microtime() do php.

$time_start = microtime(true);
$arraUsuarios = array();
for($i = 1 ; $i <= 10000; $i++):
	$obUsuarios = new Usuarios();
	$obUsuarios->nome = "Igor Escobar {$i}";
	$obUsuarios->email = "blog@igorescobar.com";
	$arraUsuarios[] = $obUsuarios;
endfor;
$time_end = microtime(true);
$Benchmarking1 = ($time_end - $time_start);
echo "Array de Objetos levou: " . $Benchmarking1 . " microsecondos<br />\n";
//Output: Array de Objetos levou: 0.04233980178833 microsecondos

Agora vamos criar uma outra implantação, ao invés de retornarmos uma array de objetos, vamos retornar um array de arrays, ou seja, seria uma array com n posições e todas as suas propriedades seriam INDICES do array e não mais atributos do objeto.

Exemplo

Array
(
    [0] => Array
        (
            [nome] => Igor Escobar 1
            [email] => blog@igorescobar.com
        )

    [1] => Array
        (
            [nome] => Igor Escobar 2
            [email] => blog@igorescobar.com
        )

    [2] => Array
        (
            [nome] => Igor Escobar 3
            [email] => blog@igorescobar.com
        )

)

O mesmo script, apenas montando de maneira diferente (array de arrays), ficou assim:

$time_start = microtime(true);
$arraUsuarios = array();
for($i = 1 ; $i <= 10000; $i++):
	$arraUsuarios[] = array (
			'nome' => "Igor Escobar {$i}",
			'email' => 'blog@igorescobar.com'
		);
endfor;
$time_end = microtime(true);
$Benchmarking2 = ($time_end - $time_start);
echo "Array de Arrays levou: " . ($Benchmarking2) . " microsecondos<br />\n";
//Output: Array de Arrays levou: 0.036391973495483 microsecondos

Qual método é mais rápido?

// Se resultado for negativo: Método 1 é mais rápido
// Se resultado for positivo: Método 2 é mais rápido
echo "Resultado: " . ($Benchmarking1 - $Benchmarking2);
//Output: Resultado: 0.007580041885376

Viram? Duas formas de fazer a mesma coisa e a segunda forma é 0.007580041885376 microsegundos mais rápida.

Conclusão

Neste simples teste, podemos tirar a seguinte conclusão: neste caso, utilizar a minha estrutura de retorno como um array de objetos é mais lento do que trabalhar com um array de arrays. Este é um teste fora da realidade, quanto mais próximo da realidade a complexidade do dia-a-dia, este número aumenta, tende a ser cada vez maior.

Veja que este exemplo não envolve conexão com banco de dados, acrescente todo o stress que envolve validação de regras de negócio, segurança, consistência e etc., e veja este número crescer MUITO mais.

Vale lembrar que eu não estou dizendo para vocês não, nunca mais, utilizarem objetos, porque não é isso, estou apenas ilustrando que NESTE CASO, foi mais rápido, e mais interessante para o projeto que o retorno desta função fosse um array de arrays, é tudo uma questão de escolher entre mysql_fetch_assoc, mysql_fetch_array, mysql_fetch_object ou mysql_fetch_row, cada uma tem suas características e são válidas dependendo da sua necessidade em questão.

Você pode aplicar isso em “tudo” na sua aplicação, até para saber quanto tempo uma determinada função demora para terminar seu trabalho basta utilizar o microtime() no começo e no final da função e subtrair os valores do maior para o menor.

$time_start = microtime(true);
//nome da função
$time_end = microtime(true);

E é isso, pessoal, espero que tenham gostado. Certamente, se vocês utilizarem este recurso para o seu crescimento profissional, será de muita valia para vocês.

Fonte Completo

<?php
class Usuarios {
	var $nome;
	var $email;
}

$time_start = microtime(true);
$arraUsuarios = array();
for($i = 1 ; $i <= 10000; $i++):
	$obUsuarios = new Usuarios();
	$obUsuarios->nome = "Igor Escobar {$i}";
	$obUsuarios->email = "blog@igorescobar.com";
	$arraUsuarios[] = $obUsuarios;
endfor;
$time_end = microtime(true);
$Benchmarking1 = ($time_end - $time_start);
echo "Array de Objetos levou: " . $Benchmarking1 . " microsecondos<br />\n";

$time_start = microtime(true);
$arraUsuarios = array();
for($i = 1 ; $i <= 10000; $i++):
	$arraUsuarios[] = array (
			'nome' => "Igor Escobar {$i}",
			'email' => 'blog@igorescobar.com'
		);
endfor;
$time_end = microtime(true);
$Benchmarking2 = ($time_end - $time_start);
echo "Array de Arrays levou: " . ($Benchmarking2) . " microsecondos<br />\n";

// Se resultado for negativo: Método 1 é mais rápido
// Se resultado for positivo: Método 2 é mais rápido
echo "Resultado: " . ($Benchmarking1 - $Benchmarking2);

?>

[]’s
Igor.

UPDADE: Este artigo foi reformulado devido a muitas dúvidas e questionamentos referentes a este meu método. Obrigado a todos que ajudaram no amadurecimento do conteúdo.