Quem desenvolve sites e aplicações web sabe: a coisa mais pentelha que existe é conseguir fazer com que as telas tenham exatamente a mesma aparência em qualquer browser (não, eu não faço parte daqueles que acham que um site deva ser desenvolvido para funcionar bem apenas no navegador que domina o mercado e o resto que se dane, a menos que seja para uma intranet homogênea..call center por exemplo). E para resolver isso, não tem muito segredo: é preciso testar, testar e testar.

Hoje em dia existem vários sites que geram screenshots de um site gerados a partir de vários navegadores e são uma mão na roda. No meu caso, que uso Mac para desenvolvimento de projetos pessoais (como o Job4Dev), eu sinto falta de ver o resultado gerado pelo IE. Por isso, o site http://ipinfo.info/netrenderer/index.php é uma ótima pedida: gera screenshots gerados por várias versões do IE e ainda por cima é extremamente rápido.

Existe no Google Code o projeto svnbook-pt-br para a tradução do livro oficial do SVN, Version Control with Subversion (http://svnbook.red-bean.com/). Existem versões parciais disponíveis para download e o projeto aceita colaboradores.

Isso não pretende ser um post. Na verdade será uma pergunta aberta à comunidade leitora deste blog.

Frameworks já deram muito o que falar por aqui. Basta dar uma olhada no artigo Sobre Frameworks… escrito pelo Raphael há algum tempo atrás. Eu, ao contrário de muitos de meus colegas, não tenho opinião fechada sobre este tema. Existem frameworks que eu odeio (Hibernate), outros que eu não vejo maiores problemas no uso apesar das críticas (Struts) e alguns poucos que eu gosto muito (no momento, Django).

Fato é que frameworks, por princípio, oferecem um quadro de trabalho dentro da qual temos que nos acomodar. Estava assistindo agora a uma palestra interna da empresa sobre este tema, e o palestrante levantou uma vantagem e uma desvantagem no uso de frameworks que me chamaram a atenção.

A vantagem apresentada foi que frameworks ajudam a desenvolver 80% do trabalho repetitivo de uma aplicação (CRUD por exemplo). Basicamente, eliminando a repetição. A desvantagem é que ele engessa um pouco a criatividade e pode tornar difícil os 20% não previstos nos casos comuns. Alguém na sala acrescentou que o problema é que em muitos casos, para resolver os casos não previstos temos que contornar o framework.

Eu concordo com estes dois pontos. As porcentagens não são nenhum pouco científicas, mas pela minha pouca experiência eu diria que elas são bem aceitáveis. E pareceu ser consenso na sala de que estes 80% justificam a existência do framework. De certa forma eu também concordo com isso.

A minha pergunta, provocativa, é a seguinte: supondo que os 80% que o framework resolve são os problemas genéricos que todos os projetos têm, não seriam os 20% restantes (que frameworks tornam difícil) o que realmente agrega valor e diferencia o produto? Ou seja: no final das contas, os frameworks não atrapalhariam o desenvolvimento daquilo que é a razão de um sistema existir?

A bruxa estava solta no final de semana. Passou pelo Job4Dev e apertou o botão FODA-SE SISTEMA (uma variante do botão FODA-SE Rubinho, muito usado pela Ferrari).

Na sexta, o sistema de markdown parou de funcionar. Sem mais nem menos. Nada foi mexido no sistema. Ele funcionava, e depois deixou de funcionar. Foi resolvido: era uma simples questão de path. Mas mesmo assim eu pergunto: como alguém ainda pode dizer que a computação é uma ciência exata?

Tá bom, provavelmente este vai ser mais um daqueles bugs misteriosos cujo computador é o primeiro a levar a culpa (”eu tenho certeza que funciona, não tem como não funcionar, a culpa é deste micro lazarento que não sabe nem processar um if decentemente”), e que depois a gente percebe que a culpa é do desenvolvedor. Esta constatação em geral é seguida por um “Ahhhhhhhh..”

Logo em seguida, um erro de operação (famosa problema de interface cadeira-teclado) fez com que a base de dados fosse pro beleléu. E obviamente, em casa de ferreiro espeto de pau: isto aconteceu logo depois de eu escrever um post sobre a importância do backup. E obviamente eu não tinha um backup local configurado. OBVIAMENTE.

Não querendo esperar o pessoal do webfaction encontrar o backup no meio de toneladas de arquivos, tomei duas decisões:

1. Restaurar os anúncios mais importantes/mais recentes na mão e aproveitar pra fazer uma limpeza geral no sistema.
2. Montar um sistema de backup local. Os mais astutos perceberão que o post sobre o pgpass foi fruto desta tarefa.

Estamos no ar novamente, e agora com um sistema muito mais rápido, estável, confiável e a prova de manipulações desastrosas.

Estou configurando um sistema simples de backup da base de dados do Job4Dev, usando as ferramentas crontab do linux e pg_dump do Postgres. Clássico.

Mas me deparei com um probleminha: a base de dados é criada com um usuário diferente do meu usuário no servidor. E o comportamento padrão do pg_dump (e de qualquer ferramenta relacionada ao Postgres)
é de pedir a senha em um prompt, o que é obviamente problemático em uma tarefa automatizada.

A solução é criar um arquivo chamado .pgpass, armazenado na raiz do home dir do usuário que irá executar o comando com a permissão 600 (qualquer outra permissão fará com que o arquivo seja ignorado) e contendo a seguinte informação:

hostname:port:database:username:password

Pronto, agora qualquer comando que envolva a tupla (host, port, database, username) descrita no arquivo tem acesso direto à base. Mais informações podem ser encontradas aqui.

Jogo rápido: caso seu ambiente de desenvolvimento inclua o Eclipse e SVN, aconselho fortemente o uso do plugin Subversive para gerenciamento de repositórios dentro da IDE. A experiência aqui no projeto onde eu trabalho foi que este plugin se mostrou muito mais estável e prático de trabalhar do que o Subclipe.

Atendendo ao clamor popular, coloquei no ar ontem um sistema de tag cloud no Job4Dev.

A primeira versão está bem simples: lista de tags ordenada por nome, com o número de anúncios em que a tag aparece do lado. A próxima versão, que deve sair em breve, será del.icio.us like, diferenciando as mais populares das menos populares pelo tamanho da fonte.

De grão em grão…

Por Odracir Antunes Júnior

Creio que boa parte dos desenvolvedores sabe da importância dos testes automatizados como ferramenta indispensável no desenvolvimento de software. Mesmo assim, para deixar as coisas ainda mais claras, gostaria de compartilhar uma experiência que tive com meus amigos em um projeto recente.

Estavamos trabalhando em um projeto de produto genérico, que serviria para várias empresas. Conseguimos um primeiro cliente que, obviamente, solicitou várias adequações para que o produto pudesse se utilizado por ele. Algum tempo depois tínhamos mais dois clientes além daquele inicial. Um deles pretendia utilizar apenas um sub-conjunto do produto original, e outro precisava de mudanças que eram incompatíveis com os outros dois.

A gestão da configuração do projeto se tornava cada vez mais complexa. Precisávamos atuar em frentes diferentes, para atender às necessidades dos clientes. Tínhamos que implementar as novas funcionalidades, porém sem quebrar o que já existia. Pra variar, acabamos atrasando. E os novos prazos estavam ficando cada vez mais apertados. Algumas vezes nós chegamos à entregar versões preliminares para homologação, com bugs em funcionalidades que já tinham sido testadas e aprovadas em versões anteriores. Isto nos causava um grande desgaste perante o cliente, e era preciso garantir a qualidade do que estava sendo entregue.

Tínhamos uma equipe de testes que também estava sobrecarregada, pois quanto mais complexos se tornavam os produtos, maiores eram as dificuldades na simulação dos cenários diferentes para os testes. Foi definido um “Smoke Test“, com as funcionalidades essenciais do produto que eram comuns entre os clientes. No meio da correria, depois de um refactoring crítico na infraestrutura do projeto, eu tive que testar manualmente a aplicação. Fiquei 4 dias testando e mal passei de 40% da cobertura básica!

Passada aquela correria, começamos a automatizar o processo de “Smoke Test” tanto quanto possível. Já sabíamos que muitas outras correria ainda nos esperavem num futuro não muito distante!

Boa parte das aplicações desenvolvidas últimamente são aplicações WEB, e portanto também é fundamental poder fazer testes através do browser, como se fosse um usuário comum operando o sistema. Obviamente isto não exime o desenvolvedor de implementar os testes unitários. Os testes através da camada web devem ser um complemento aos testes mais básicos.

O Selenium é uma ferramenta de para testes de aplicações WEB, distribuído sob a “Apache License, Version 2.0“. Temos os seguintes produtos, e modos de uso do Selenium.

Selenium Core - (Modo direto)

Os testes são efetuados diretamente através do browser. As páginas de teste devem estar hospedadas no mesmo servidor que o programa/site a ser testado. Esta restrição/característica é função da segurança relativa à mesma origem requerida pelo javascript.

Vantagens:

• Suporte para todos os browsers

Desvantagens:

• É necessário a instalação remota no servidor.
• Possui algumas limitações para testes mais complexos.
• Pode ter um comportamento irregular quando se testam páginas com ajax, onde é necessário um controle maior do tempo, e/ou seqüencia de eventos. Este comportamento é altamente dependente do “engine” java script do browser. Dependendo do caso, às vezes pode apresentar falsos erros em função da priorização das atividades, já que tando “quem testa” quanto “quem é testado” estão sendo executados sob o mesmo “engine” java script, e comportamentos concorrentes podem não ser tão previsíveis assim …

Selenium IDE - (Modo indireto - Plugin no browser)

Os testes são efetuados através de um plugin instalado no FireFox. Este plugin é um ambiente integrado de desenvolvimento. Permite gravar a navegação do usuário, e depois repeti-la à titulo de teste. Também permite exportar os testes gravados em outros formatos. (Maiores explicações adiante…)

Vantagens:

• A instalação é local e simples.
• É muito fácil de usar.
• Permite gravar sessões de teste para uso posterior.
• Permite exportar as sessões de teste como arquivos fonte Java, C#, Perl, PHP, Python e Ruby, que podem ser usados pelo Selenium RC.
• Excelente para quem inicia o uso do Selenium.
• Não é preciso saber programar.

Desvantagens:

• Funciona como plugin apenas no FireFox.
• Possui algumas limitações para testes mais complexos.
• Pode apresentar o mesmo comportamento irregular relatado no item Selenuim Core. (colocar link local para #L1)

Selenium RC - (Modo indireto - Programa de teste + Proxy)

Os testes são efetuados através de um programa, que comanda o browser através de um proxy. Este programa pode ser escrito em Java, C#, Perl, PHP, Python e Ruby.

Vantagens:

• Permite o uso de verdadeiras linguagens de programação.
• Permite um controle muito mais apurado do tempo, seqüencia de eventos, etc. …
• É possível importar os testes gerados pelo Selenium IDE.
• Muito mais flexível e poderoso. Pode evoluir até para grandes suítes de testes, integração contínua, geração de relatórios . Como o programa está nas suas mãos você pode fazer o que quiser!

Desvantagens:

• A instalação e configuração do ambiente é um pouco mais trabalhosa.
• É necessário saber programar.
• Pode ser mais complicado escrever os testes à partir do “zero”.

Qual ferramenta/modo eu devo usar ?

Além das informações listadas aqui, gostaríamos de sugerir a seguinte abordagem híbrida:

• Instale o Selenium IDE e crie os seus testes básicos.
• Exporte esses testes como programas (java, por exemplo).
• Crie um projeto com as suítes de teste para uso com o jUnit.
• Faça um refactoring nas classes geradas pelo Selenium IDE, pois o código gerado tem muita redundância.
• Melhor ainda seria arrumar o código para ficar simples como uma mini “DSL” (Links #9 e #10), mais adequada para a sua aplicação, com chamadas de mais alto nível.

Depois de que automatizamos uma parte dos testes, aquilo que eu levei 4 dias era feito em apenas 20 minutos! Uma cobertura mais abrangente e confiável! A tranquilidade e a segurança que temos depois que os testes passam após um “refactoring”, ou mesmo antes de uma entrega do sistema para o cliente, é algo que não tem preço!

Moral da história: O tempo utilizado na elaboração de testes automatizados não é um tempo “gasto”. Na verdade é um tempo “investido”!

[Odracir Antunes Júnior é Analista de Sistemas com mais de 20 anos de experiência de desenvolvimento de sistemas em C, C++ e Java]

Acabou de sair do forno!

O formulário de cadastro de novas vagas do Job4Dev agora aceita o uso de markdown para formatação de texto. Para quem não sabe, markdown é um padrão de codificação simples de texto para geração de HTML. É muito usado por wikis e afins.

Exemplos de marcação markdown:

• *texto em itálico*
• **texto em negrito**
  

O parser do texto e geração do HTML ficou a cargo da lib Python Markdown.

Um professor da Unicamp com quem fiz 3 cursos sempre dizia que cada desenvolvedor deve possuir a sua caixinha de maldades. E por maldades, entenda ferramentas aplicáveis no dia a dia. Eu tenho algumas que considero indispensáveis para qualquer desenvolvedor. Expressão regular é uma delas. Aprender a sintaxe e usar corretamente regexp podeser complicado no início, mas o esforço vale a pena.

Descobri um site bem legal para testar suas habilidades nesta área, o RegexPal. A interface é das mais simples possíveis: escreva a sua expressão regular na caixa de texto superior, e o texto na caixa inferior. O site usa a mágica do Javascript para analisar e exibir em tempo real quais pedaços do texto são capturados pela expressão.

E ainda a este respeito…

Via XKCD

Conhece a anedota? Conta que um programador estava tentando resolver um problema: ele tinha um sistema que precisava manipular e enviar informação estruturada para outros clientes. Num instante de pura sagacidade, ele pensou “Já sei. Vou usar XML!”. No instante seguinte, de pura decepção, ele constatou: “Agora eu tenho dois problemas. Não bastasse meu problema original, eu vou usar XML.”

De todos os alfabetos gastos em tecnologias que construiam “em cima” do XML (XQuery, XPath, XSL, XML-RPC, X-Men, Xuxa, sei lá) não consigo lembrar de nenhum que traga algo novo. Parece que é o tipo de coisa que cai na categoria “problemas inventados pelos vendors de software para que eu possa continuar justificando lucros trimestrais de US$4 bilhões.”

Tudo que eu e o programador da anedota precisamos é de um sistema que possa passar informação de um jeito estruturado. Se puder ser facilmente lido como texto, tanto melhor. Ninguém merece ter que ficar editando arquivo CSV, não é mesmo?

Que tal a possibilidade de ver um registro de uma fatura num formato assim?

invoice: 34843

date   : 2001-01-23

bill-to: &id001

    given  : Chris

    family : Dumars

    address:

        lines: |

            458 Walkman Dr.

            Suite #292

        city    : Royal Oak

        state   : MI

        postal  : 48046

ship-to: *id001

product:

    - sku         : BL394D

      quantity    : 4

      description : Basketball

      price       : 450.00

    - sku         : BL4438H

      quantity    : 1

      description : Super Hoop

      price       : 2392.00

tax  : 251.42

total: 4443.52

Esse é um documento YAML, válido. Bonitinho, né? Pena que ninguém mais usa isso por aí… e de que adianta ser capaz de emitir algo assim, se ninguém é capaz de receber? Vou ter que continuar usando XML?
Não necessariamente. Especialmente se está mexendo com web e já ouviu falar de uma outra darling das notações de marcação, JSON.

JSON, essa você já deve ter ouvido falar. Seu browser mastiga isso com uma facilidade tremenda:

{"student": {

  "first name": "John",

  "last name": "Smith",

  "course": {

    "report": [

      {"Subject": "Math", "grade": "A"},

      {"Subject": "English", "grade": "C"},

      {"Subject": "Arts", "grade": "F"}]}}}

 }

É só pedir para o seu interpretador Javascript avaliar essa string, e você tem um objeto que pode processar, e apresentar um relatório lindo para os pais do John, que vão dar uma bronca nele por ele não largar do computador e não ter aprendido a desenhar flores em aquarela.

Deixa eu contar o pulo do gato: todo JSON válido também é YAML. A notação usada em JSON é usada para descrever inline collections em YAML. Se você tiver uma string que seja a representação de um objeto em JSON, ele será visto como um objeto pelo seu parser de YAML (escolha aqui seu parser, na sua linguagem/plataforma favorita).

O que se ganha com isso? Um exemplo: validação e manipulação de formulários. Que tal a possibilidade de não só validar os dados no cliente, mas também pegar os campos de um formulário, verificar se o objeto está consistente, transformar em uma string JSON (usando um emitter apropriado) e enviar para o servidor essa string? Depois, o seu parser de YAML vai te montar um objeto, o qual pode ser muito mais facilmente validado e verificado.

Para quem quiser fazer formulários onde campos podem ser livremente adicionados ou removidos, ou usar toneladas de AJAX em seu aplicativo web, a combinação JSON + YAML funciona e é uma mão na roda.

Distribuição Linux é igual a gosto: cada um tem a sua preferida. Eu já brinquei com pelo menos 4: RedHat, Fedora, Mandrake e Suse. Cada uma tem peculariedades interessantes, caracteristicas próprias que as diferenciam das outras: instaladores gráficos para newbies, bons sistemas de configuração, segurança, aplicativos desktop, entre outros. Escolher a mais adequada para o seu caso pode ser uma tarefa longa.

Encontrei na internet o site Linux Distribution Chooser (http://www.zegeniestudios.net/ldc/index.php) que, a partir de uma série de perguntas, tenta determinar qual a melhor distribuição para o usuário. No meu caso, a resposta foi Mandriva. Em alguns casos, o sistema oferece várias possibilidades. Mandei o link para uma série de amigos geeks, e todos pareceram concordar com os resultados. Para aqueles que querem se aventurar neste mundo, pode ser um bom chute inicial, para evitar uma escolha totalmente aleatória.

O Mac tem uma longa tradição de interfaces gráficas de alto nível. Mas como bom hacker e amante de Linux para trabalho, eu gosto muito de usar o Terminal para executar comandos como SSH, sFTP ou SCP. Apesar disso, confesso que as vezes um programa gráfico torna as coisas mais confortáveis.  O Fugu (http://rsug.itd.umich.edu/software/fugu/) é um ótimo frontend para estas aplicações. Existem versões compatíveis com Mac OS 10.2 até Mac OS 10.4

Desenvolve interfaces web com CSS, HTML, Javascript e requisições assíncronas e não conhece o Firebug? Meus pêsames…

Acho que o Alexandre falou algo do gênero no post sobre YSlow. Bom, caso queira saber o que é Firebug, dê uma olhada neste meu post e no site do dito cujo.

Se você já descobriu as maravilhas de ter o apoio desta ferramenta para desenvolver interfaces web, mas quer saber mais detalhes sobre o seu funcionamento, aconselho este artigo do Google Developer Knowledge Base.

Há mais de um ano, meu caro amigo Miguel escreveu aqui uma dica sobre o FireBug, certamente o plugin do Firefox mais útil para mim quando estou desenvolvendo aplicações para web. Se você é um desenvolvedor, e não usa este plugin, sinto muito.

Agora, através de um artigo de Dan Hardiker, publicado por Jonathan Nolen no Atlassian Developer Blog, conheci o YSlow. Este é um plugin para Firefox, desenvolvido pelo pessoal da Yahoo, que se integra ao FireBug e análisa uma página web baseado num conjunto de regras para aumentar performance de páginas web (também desenvolvido pela Yahoo), dá uma nota à sua página, indicando os pontos que poderiam ser melhorados.

Mais importante do que o plugin, no entanto, são as regras. Conhecê-las e aplicá-las - sempre que for possível - pode fazer uma grande diferença na experiência do usuário ao acessar as páginas por você desenvolvidas. Como teste, utilizei a ferramenta no Gmail,que recebeu uma nota A com louvor, e na página de nosso humilde blog, que foi reprovado com um vergonhoso F (a pior nota possível). Agora é tentarmos, na medida do possível, trabalharmos sobre os pontos que é possível melhorarmos.

Bom, fica aqui a dica.

Powered by ScribeFire.