Mais um Website em Django – Vestibular 2010 – UNIPAR

Depois de um longo período sem escrever, segue abaixo o link para o meu último trabalho: O site do Vestibular 2010 da UNIPAR.

O site em questão foi desenvolvido seguindo fielmente os padrões e utilizando Django para criação do Backend. Já no Frontend os efeitos ficam por conta do jQuery.

Vestibular 2010


Definindo Experiência de Usuário – Parte I

Tive a grata experiência de encontrar esta série escrita por Aaron Irizarry em seu Blog, a qual expôe uma visão analítica sobre a percepção do usuário, e me ocorreu que seria interessante publicá-la em português. Enviado o comentário, pedindo a devida autorização para fazê-lo, depois de algum tempo, não mais que 1 hora creio eu, obtive a liberação e o que segue abaixo é a primeira parte da série. Boa leitura.

Em meu esforço para criar uma série útil definindo o que constitui uma boa experiência de usuário, eu fiz uma enquete para ouvir das pessoas o que elas pensam sobre os ingredientes importantes para compor uma grande experiência de usuário. Aqui estão os resultados;

Resultados da Enquete

Esses resultados são muito parecidos com os que eu esperava. A usabilidade recebeu a maioria dos resultados, e todos os seguintes receberam a segunda maior quantidade de votos, você pode ver no gráfico acima que outras opções receberam consideravelmente menos votos, e alguns de vocês até curtiram um pouco comigo votando em nenhum dos acima.

Nesta série nós iremos observar os diferentes aspectos da experiência do usuário, definir seus diferentes elementos, e discutir sua importância para aqueles que interagem com aquilo que nós estamos criando. Nós iremos começar pela observação dos resultados e olhando o que eles nos dizem. Considerando que muitos dos votantes são colegas designers/desenvolvedores eu esperava que resultado mais alto fosse a usabilidade. Em primeiro lugar isso chama a minha atenção para duas coisas.

A maioria destes que votaram sabem o que é importante para um bom design.

A maioria destes que votaram sabem o que é importante para um bom design.

Não, isso não é um erro, deixe-me explicar… A maioria daqueles que votaram (incluindo eu mesmo) trabalha com algum tipo de ambiente de design/desenvolvimento todos os dias. Para alguns de nós isso tem fornecido muita experiência no desenvolvimento de websites, e outras interfaces de usuário, o que foi exibido no número de votos que a usabilidade recebeu em comparação com todo o resto (aparentemente a maioria de nós presta atenção no “Be-a-bá” do design).

Um bom design começa com a usabilidade. Então é bom ver que nós temos nossos fundamentos de um bom design alicerçando-nos. Eu acredito que a usabilidade é a prioridade quando criando um design/produto baseado no usuário… mas nós temos que ser cuidadosos ao definir usabilidade por aí da nossa maneira já que se ela é nosso Zorro os outros componentes avaliados que fazem uma boa experiência de usuário são deixados de lado (Tonto). Em tempos em que nós podemos nos aprofundar na maneira de saber o que sabemos razoavelmente bem, nós pensamos que nós sabemos o que o usuário precisa para ter uma boa experiência de usuário, e na maioria das vezes nós terminados como o pobre marido que dá uma bola de boliche para sua esposa no Natal, ele pensa que ela irá gostar do tempo juntos… jogando boliche. É claro que ele teve boas intenções, mas ele estava um pouco fora de sintonia com o que a sua esposa poderia realmente querer (uma viagem para um spa, pedicure ou simplesmente algo que demonstrasse que ele tem interesse nas suas necessidades.)

Nós devemos nos certificar do nosso crescente número de usuários, simplesmente porque nós “sabemos o que é importante para um bom design”, ou por “ser aquilo que sempre fizemos” Usabilidade é a chave… boa navegação que é fácil de seguir e leva os usuários aos resultados desejados, certificando-se de que a mensagem do projeto/produto é permeada com propósito e clareza, e outros elementos fundamentais precisam estar no lugar para o sucesso do design inicial, mas eu pessoalmente acho que a não ser que cerquemos esses elementos de um bom apelo visual, forte suporte auxiliar e uma boa quantidade de emoções (dando ao usuário as percepções secundárias) o design não será capaz de atingir seu completo potencial, e irá apenas cumprir com o mínimo proposto.

Assim como qualquer time de futebol tem uma estrela (ex.: um Ronaldinho, ou um Rivaldo) e isso definitivamente ajuda a aumentar as chances de sucesso ao ter aquele jogador chave… mas as vezes há algo que o time não consegue dominar, ou atingir altos níveis de sucesso até que seus jogadores sejam cercados de um conjunto de outros jogadores de qualidade dando-lhes apoio. Isso nos leva a entender porque “Todo o resto” recebeu o segundo montante de votos. (41 segundos para apenas 44 votos em usabilidade). Isso realmente nos remete à ideia de uma aproximação bem balanceada para nosso processo de design, nós realmente precisamos considerar o que a resposta ao usuário desejada que estamos tentando atingir é, e então, embasados na usabilidade e pelo time de apoio do apelo visual, da resposta emocional e do bom suporte auxiliar, nós seremos capazes de criar belos websites e experiências de usuário que levarão o usuário à resposta desejada, ajudando nossos clientes e funcionários a atingir um nível mais alto de sucesso.

Agora que observamos os resultados, e olhamos para a necessidade de uma aproximação equilibrada junto a todos os nossos elementos, nós iremos observar cada elemento individualmente. No próximo artigo nós iremos desenrolar a ideia de usabilidade, que nós concordamos ser vital para o processo, mas o que envolve fazer um site usável? Por onde nós devemos começar?

Eu adoraria ouvir o que você acha que é fundamental para desenvolver um site “amigável ao usuário” (compatibilidade com navegador, padrões, acessibilidade). Faça algum barulho e deixe-me saber o que você pensa. Obrigado novamente por ler e dar sua opinião,

Fonte: http://www.thisisaaronslife.com/defining-user-experience-pt1/


Django 1.0 beta1 liberado

Obedecendo o cronograma de liberação do Django 1.0, foi liberada na noite passada a primeira versão de teste “beta” do Django 1.0.

Para pegar uma cópia da 1.0 beta 1, vá até a página de downloads do Django, e procure ler as notas de liberação. Por favor, tenha em mente que essa versão não é destinada ao uso em produção, e é voltada para primariamente para desenvolvedores que estejam interessados em verificar os novos recursos na 1.0 e em ajudar a identificar e resolver  bugs antes da liberação da versão final. As versões 1.0 alpha e beta não receberão suporte a longo prazo e não serão atualizadas com correções de segurança, já que o seu principal propósito é servir como um alicerce no caminho para a liberação final do Django 1.0.

O próximo passo no caminho para o primeiro release candidate do Django 1.0, está agendado atualmente para 21 de Agosto. Se você gostaria de ajudar, por favor verifique a documentação para colaboradores e sinta-se a vontade para juntar-se a um dos sprints de desenvolvimento agendados para o período que antecede a 1.0; o cronograma completo está disponível no roteiro de liberação do Django 1.0.


Caindo na Real: Metodologia para Desenvolvimento de Aplicações Web

Não sei se todo mundo já ouviu falar do Ruby on Rails, que é um framework para desenvolvimento ágil de aplicações web desenvolvido em uma linguagem chamada Ruby, muito parecida com o Python (que também possui frameworks assim), que são linguagens simples, dinâmicas e totalmente orientadas a objetos.

A empresa que desenvolveu o Ruby on Rails, a 37signals, também criou uma nova metodologia de desenvolvimento de aplicações web chamada “Getting Real”, que deu origem a um livro com o mesmo nome. A grande novidade é que esse livro agora está disponível para leitura on-line em português do brasil e pode ser encontrado nesse endereço.

É claro que existem outras metodologias, como a RUP, que é muito adequada para grandes projetos, principalmente os mais complexos, que contam com grandes equipes e que foca a organização e documentação prévia de cada detalhe do projeto, e a XP que é voltada para o desenvolvimento de aplicações privilegiando a comunicação com o usuário e a realização de ciclos rápidos de desenvolvimento focando a divisão do projeto em pequenas partes, aliada a modularização do projeto (e que deu origem a algumas técnicas marcantes, como a realização de testes unitários e a programação em pares).

Já a proposta do pessoal da 37signals foi criar uma metologia que privilegia a utilização de frameworks de desenvolvimento ágil, onde a preocupação com detalhes de implementação é totalmente abstraída e o desenvolvedor se foca apenas na construção da solução para o problema apresentado, podendo ser utilizada tanto em projetos pequenos quanto em grandes projetos. Além disso, as ferramentas de desenvolvimento ágil de aplicações web possuem recursos de auto-documentação e API‘s de fácil compreensão, além de serem desenvolvidas em linguagens de script, como as que eu citei inicialmente, onde o código fonte está sempre à disposição do desenvolvedor seguindo critérios de organização definidos pelo framework, que dentre outras coisas, também oferece a separação entre modelos, controladores e visões ( MVC).

Pois bem, se você leu até aqui eu creio que irá gostar de ler o livro. Ele é curto, divertido e de simples compreensão. Vale a pena perder um tempo e refletir sobre qual metodologia é mais adequada ao seu projeto.

Obs.: Tentei disponibilizar o máximo possível de links no texto pra dar uma força pra quem se sentir meio perdido. Espero que gostem.


Salve Gedit!

Compartilho aqui o texto do Elton Luís Minetto sobre o Gedit. Como tem ficado cada vez mais raro encontrar pessoas que dão o devido valor à boa e velha prática de programar utilizando um simples editor de texto, sem usar IDE’s e ambientes extremamente pesados e complexos eu achei interessante divulgar.

Também tenho utilizado o Gedit há algum tempo, o que acabou se intensificando com a versão 2.16 (muito boa), mas ainda não tinha atentado para o pacote de plugins.

Fica aí a dica.


A Síndrome do "Não Inventado Aqui"

Tenho visto seguidamente ao longo dos anos que trabalho com tecnologia da informação (e estou certo que não sou o único) uma série de situações onde desenvolvedores de software simplesmente ignoram a existência de tecnologias e técnicas simplesmente por não levarem em consideração, ao longo de suas trajetórias, que outras pessoas podem ter feito a mesma coisa anteriormente com uma visão muito mais completa do problema.

Os argumentos para querer “re-inventar a roda” são tantos e tão variados que seria impossível enumerar uma quantidade significativa aqui, assim sendo, deixo aqui esse espaço para que os meus 2 ou 3 leitores ocasionais descrevam aqui as situações impares de NIH (Not Invented Here) pelas quais já passaram.

Apesar de já criticar largamente esse tipo de atitude há um bom tempo, só recentemente tomei conhecimento do termo própriamente dito depois que foi postado um texto sobre o assunto abordando a decisão dos desenvolvedores do Django, o Framework Web com o qual eu venho trabalhando, de não aproveitar o código de terceiros na sua composição, fato esse que vem sendo lentamente revertido mas que foi, de certa forma, até benéfico para a consolidação da ferramenta.

Mas quais benefícios e malefícios a decisão de aplicar ou não as idéias de terceiros podem trazer a um projeto? Pois bem. Quem aqui disse que é preciso usar unicamente um pedaço de software de outra pessoa para fugir da tal síndrome?

É preciso estar atento às mudanças, saber escolher dentro da miríade de opções de tecnologias e técnicas que aparecem todos os dias, aplicar apenas aquilo que traga algum benefício real ao projeto, optando por re-utilizar o código de terceiros ou, em segunda instância, aplicar engenharia reversa, ou ainda, apenas se basear em boas idéias alheias para criar algo que ofereça o melhor dos dois mundos, ou seja, o entendimento e controle total sobre o código e a eficiência já comprovada daquilo que realmente funciona bem em projetos de terceiros.

Fazer valer o ditado que diz que é sábio aprender com os erros dos outros é uma dádiva, principalmente em se tratando de aplicações para web e produtos que devem atender a critérios de usabilidade e acessibilidade. O fato de estar fazendo algo que não é completamente novo e que segue diversas tendências já consolidadas pode castrar de certa forma a criação, mas poupa tempo e esforço, sendo portanto mais produtivo e possibilitando um saldo de disposição para as etapas do projeto onde ela, a disposição, é mais necessária.


Django Book

Está disponível no endereço http://djangobook.com a versão prévia do Livro do Django que está sendo escrito por Adrian Holovaty e Jacob Kaplan-Moss, os dois sujeitos mais envolvidos com o desenvolvimento do Framework Web Django. E pra não dizer que não falei em flores, até a Interface do Livro na Web é um verdadeiro show :-).


CMS’s, frameworks e informações estruturadas

Passei um bom tempo dedicando-me à exaustiva jornada em procura por um sistema de gestão de conteúdos que possibilitasse a construção de um ambiente composto por informações estruturadas e não estruturadas. A primeira grande descoberta é que os CMS’s mais difundidos na Internet são muito enfaixados e que geralmente só conseguem dar conta sem grandes dores de cabeça daquilo para o qual foram originalmente desenvolvidos.

Depois de muito tempo em busca de um CMS’s que fosse capaz de manipular conteúdos estruturados com facilidade acabei descobrindo o Plone, em conseqüência disso me enveredei pelo Zope e aí a lista de acrônimos só foi aumentando, passando por DTML, TAL, ArcheTypes, ArchGenXML, Python Products, ZODB, Zeo Clients, Zeo Servers, Slots, Macros, Python Controllers, etc., ou seja, é possível obter grandes resultados com o chamado “PZP” (Python+Zope+Plone), entretanto é preciso estar disposto a vencer uma curva extremamente ingreme de aprendizagem, além de ter que conviver com uma abordagem que não envolve diretamente bancos de dados relacionais, passando pela utilização de adaptadores e todo tipo de parafernalha que parece que só é utilizada pela própria pessoa que escreveu o código, isso quando é utilizada (vide o caso do MySQLda e outros Database Adapters).

Voltei a fazer a minha peregrinação, conheci o Ruby on Rails (me dei conta que um CMS não poderia me antender naquele momento, devido ao aprendizado com o Zope e a simpatia que acabei criando com o Archetypes), achei interessante, mas ainda pouco funcional, já que a idéia é boa mas não vejo como poderia ser utilizado em projetos sérios sem oferecer uma série de características, além do mais a abordagem de criar aplicações apartir do banco de dados não me agrada, afinal de contas, se vou manipular objetos mais tarde porque não começar logo de uma vez com essa abordagem e abstrair o resto?

Por fim acabei descobrindo o Django, framework este que estou utilizando em um projeto e não tenho do que reclamar. Foi a escolha certa? Ainda não posso dizer, afinal de contas as mudanças na API e o fato de ainda não ter entrado em produção ainda me deixam com a pulga atrás da orelha, mas certamente foi a melhor opção até agora.


Análise do Django

Como já falei aqui anteriormente o Django é um Framework para desenvolvimento de aplicações web escrito em Python que tem por objetivo simplificar a vida do desenvolvedor e possibilitar a criação de aplicações de forma limpa e organizada. Também havia prometido que descreveria a minha experiência com o framework e é por isso que resolvi escrever o texto abaixo.

O primeiro passo na utilização do Django foi fazer a sua instalação, o que não foi difícil, já que bastou seguir as instruções contidas no Tarball. Depois disso, como todo bom iniciante, parti para o processo de leitura do tutorial, disponível na área de documentação do site oficial, e repetição dos passos descritos em meu próprio equipamento.

A utilização é bastante simples, básicamente composta pelos seguintes passos:

  1. Inicialização do projeto, que é feita com o comando django-admin.py startproject projeto;
  2. Configuração da aplicação, que consiste em informar o endereço, login e senha, além do tipo (mysql, postgres, etc) da base de dados a ser utilizada pela aplicação, através da edição do arquivo settings.py;
  3. Criação da aplicação (um projeto pode ser composto por multiplas aplicações), o que é feito com o comando django-admin.py startapp aplicação;
  4. Definição das classes, editando o arquivo apps/aplicação/models/aplicação.py; e
  5. Instalação da aplicação, que é na verdade a geração das tabelas necessárias ao funcionamento da aplicação na base de dados indicada na configuração, o que é feito pelo comando django-admin.py install aplicação.

Omiti alguns detalhes do processo, como a configuração do settings.py para que a aplicação seja adicionada ao projeto e outros pequenos detalhes de implementação, já que não é essa a finalidade desse texto, mas basicamente é assim que a coisa funciona.

Com as devidas definições no modelo, parâmetros especiais, etc. é possível ter uma interface de gerenciamento de dados completa, com direito a mecanismo de busca, níveis de acesso, autenticação, filtragem, além das operações CRUD (Create, Recover, Update, Delete).

Depois da primeira experiência comecei a montar uma pequena aplicação de minha própria autoria (sempre recorrendo à documentação no site oficial) e posso dizer que:

É possível criar aplicações em minutos com o Django, entretanto ainda não comecei a mexer com as views (templates), mas posso garantir que pelo menos o “M” (model) e parte do “C” (controller) da triade MVC, sobre a qual está alicerçado o framework, são postas na tela com pouquissimo trabalho.

Pois bem. Nos próximos dias voltarei a dar notícias do Django por aqui. Python on Rails? Não sei… Mas pode ser até melhor.