Trabalhar com a Web é uma das minhas paixões, programar é outra. Atualmente trabalho com desenvolvimento Web, o que, dada a primeira afirmação, deveria me fazer muito feliz, mas não é 100% assim.

Trabalhar com desenvolvimento para Web é muito legal e muitas vezes desafiador, mas nos últimos meses venho me sentindo cada vez mais desmotivado e desinteressado. Explico. Não é que eu tenha deixado de gostar de programar, mas é que cada vez mais tenho feito um trabalho que considero básico e trivial. Isso é desestimulante.

A empresa onde trabalho tem alguns poucos projetos legais mas na sua maioria são coisas banais do ponto de vista de um desenvolvimento desafiador. Não estou dizendo que o trabalho feito aqui seja inútil ou que não tenha relevância para a sociedade, pois não seria verdade afirmar isso. Mas do ponto de vista do desenvolvedor é tudo "mais do mesmo".

Estou em um ponto de saturação. Já não tem mais a mínima graça fazer aplicações CRUD básicas e sem nenhuma problemática realmente inteligente.

O que tem me dado algum prazer é trabalhar com o Drupal, mas como já disse outro tempo atrás, não tenho mais interesse em implementar vários sites. Meu interesse com o Drupal é criar módulos novos, e deixar para que outras pessoas possam criar seus próprios sites. 

Como não posso simplismente sair da empresa (tenho família para sustentar) o jeito é intercalar com o desenvolvimento e documentação do Drupal para ver se a frustração é menor.

Esse artigo é a continuação de um outro, escrito há alguns dias atrás.

Recomendo que você leia também o primeiro artigo, uma vez que eles se complementam.

Então vamos lá!

Não modifique o core do Drupal

Essa é uma recomendação muito comum mas geralmente não é ouvida pelos novatos.

Como o Drupal é um projeto mantido por uma comunidade muito ativa, sempre há alterações e correções no seu código base. Ao alterar o core do Drupal você pode acabar tornando sua instalação insegura. Além disso você irá tornar, automaticamente, seu código incopatível com os novos releases do Drupal, o que, automaticamente irá fazer com que você fique sem poder atualizar quando sair uma correção.

Suponhamos que você criou um projeto, alterou o core do Drupal mas agora outra pessoa vai dar manutenção nesse projeto. Se você, por acaso, esqueceu de avisar das alterações, isso pode tornar a manutenção muito penosa.

Uma excessão é quando você está corrigindo um bug, ou fazendo uma melhoria, e espera devolver isso para a comunidade. Obviamente você terá que rastrear e ver se o patch que você enviou será incorporado ao próximo release do Drupal. Se isso não acontecer você terá que manter isso de qualquer forma. Por isso nunca é recomendável se fazer esse tipo de alteração em sites que irão para produção.

Segurança

Segurança é importante. Quando você vai manter um site no ar, é importantíssimo se manter atualizado. O Drupal dispõe de uma newsletter onde todo aviso de correções de segurança são enviados. Quem mantém um site com Drupal deve estar atento a essa lista, de preferência assinando a newsletter ou sempre atento à divulgação na página de avisos de segurança.

Testes

Antes de colocar um projeto online, é de suma importância fazer testes. Os testes ajudam a encontrar problemas e evitam colocar um site com falhas críticas online.

Existem várias ferramentas que podem ser usadas para criar um ambiente local para testes. O XAMMP e o MAMP são as ferramentas mais comuns.

Toda vez que você for instalar um módulo novo, fazer atualizações e/ou correções no seu site, procure fazê-lo localmente. Baixe uma versão igual a que está no seu servidor de produção, e faça os testes. Se tudo correr sem problemas é sinal de que você pode por no ar.

Alguns pontos importantes a serem observados:

• Nunca desenvolva ou teste no ambiente de produção. O Drupal é fácil de instalar localmente, não compensa o risco;
• Teste os seus backups com regularidade em um ambiente diferente. Isso assegura que seus backups estão funcionando e você não é pego de surpresa sem saber como restaurar um backup.
• Teste toda atualização localmente. Evite por seu site em risco.

Gestão de arquivos e pastas

O Drupal contém vários arquivos e pastas sob uma determinada estrutura. Essa estrutura existe para facilitar o nosso entendimento e trabalho.

Ao criar um site simples (não-multisite) você deve criar uma estrutura dentro da pasta sites/all para os seus módulos e temas. Essa estrutura visa facilitar a atualização futura do seu site, uma vez que você só precisará fazer backup do que estiver dentro da pasta sites (e, obviamente, do banco de dados). Essa estrutura é composta de duas pastas: modules e themes. Asssim, a estrutura final ficaria: sites/all/modules e sites/all/themes.

Em sites múltiplos (multisites) você deve posicionar os módulos e temas específicos dentro da pasta de cada site. Assim, se você tem um site chamado www.example.com você irá criar: sites/www.example.com/modules e sites/www.example.com/themes

Se você desejar pode renomear o arquivo update.php no entanto, ele já contém proteções para evitar abuso. Também, se você quiser, poderá remover o arquivo install.php uma vez que ele só é necessário na instalação do site.

É uma boa prática deixar o arquivo CHANGELOG.txt (ainda que com outro nome), para que você se lembre qual versão está aquele site (ou conjunto de sites). Quem administra muitos sites pode acabar se esquecendo e não fazendo a atualização.

Por último, ao construir um tema ou módulo, evite espaços nos nomes. Isso pode causar problemas em sistemas opreracionais não-windows. 

Conclusão

Com esses dois pequenos artigos espero ter mostrado os benefícios de se trabalhar de acordo com as melhores práticas.

Essas melhores práticas vêm de testes e experiências de usuários, e existem para fazer sua vida mais fácil. Tente se guiar por elas, e certamente seu trabalho, e dor de cabeça, será menor.

Abraço

Já faz algum tempo que quero escrever alguma coisa sobre o Drupal mas faltava um assunto específico. Resolvi então que vou começar do básico para quem quer desenvolver com o Drupal: As melhores práticas.

Esse é o primeiro de uma série sobre melhores práticas do Drupal 

Início 

Geralmente quando vamos desenvolver com base em algum framework ou CMS já existente, existe algum manual ou recomendações de melhores práticas para esse desenvolvimento. Com o Drupal não é diferente. Existe um guia de melhores práticas no site do Drupal, e ele vai servir de base para esse texto.

Planeje antes de começar!

Quando vamos desenvolver algum projeto, seja um site, seja a construção de uma casa, antes, precisamos planejar. Sem planejamento, muitas vezes, acabamos deixando passar algo e na hora de implementar, dá aquela dor de cabeça.

É na hora do planejamento que vemos se aquela funcionalidade vai conflitar com outra, ou se aquele item que consideramos visualmente bonito vai caber dentro do contexto. Gaste um bom tempo (mas não todo o tempo) planejando o que você vai fazer.

O Drupal possui uma gama enorme de módulos que podem ser combinados para fazer o seu trabalho mais fácil, então veja se você não está reinventando a roda, e pense em usar alguns desses módulos também.

Esteja pronto para mudanças

O Drupal, bem como boa parte dos projetos Open Source, é muito dinâmico e de tempos em tempos há novas atualizações. Algumas são atualizações de segurança, outras nova versões com várias novas funcionalidades.

Temos sempre a mania de querer o mais novo e com os mais lindos recursos na hora que eles saem. Esteja pronto para mudanças, mas seja moderado ao fazê-las. Como o Drupal tem muitos módulos de terceiros que, eventualmente, você vai acabar usando esteja certo de que eles já são compativeis com a versão mais nova do Drupal, antes de decidir atualizar o Drupal do seu site.

Um site que esteja maduro e bem construído, não precisará de novas atualizações quando elas saem. Mas esteja pronto para a evolução. Um prazo que se recomenda para fazer essa atualização é de 12 a 24 meses.

Um ponto importante são as atualizações de segurança. Essas devem ser aplicadas sempre que saírem(desde que sejam indicadas para o seu caso, é bom lembrar), pois não impactam (geralmente) no funcionamento, mas na segurança.

Se envolva com a comunidade

O Drupal é um software Open Source e que trabalha com o modelo de comunidade. Quando você usa o Drupal você se torna parte da comunidade. Você pode ser um membro atuante ou não, isso vai depender do seu perfil e interesse. No entanto, a recomendação é que você esteja sempre em contato com a comunidade.

Um dos princípios do Software Livre é a possibilidade de retornar algo que você melhorou. Isso é importante para o projeto, uma vez que você pode ajudá-lo a se tornar mais forte e pode ser importante pra você, dependendo do seu interesse na comunidade. Se você fez algo que pode ser devolvido à comunidade, devolva! O Drupal e os módulos de terceiros que você está usando, foram devolvidos para a comunidade em algum tempo, então que tal fazer o mesmo?

Ser um membro ativo também nos possibilita estar à par do estado do projeto e como ele irá evoluir. Isso também nos ajuda a nos planejar para as atualizações que virão. Em alguns casos você inclusive pode participar dessa decisão.

Faça backups

Uma coisa que muita gente esquece, mas que é fundamental: backup! Vez ou outra enfrentamos problemas que podem acabar afetando o nosso site e/ou sistema. Pode ser um problema físico em um dos servidores, uma empresa que deixa de prestar serviços e vários outros problemas. Ter um backup é de suma importância.

Ter um backup não significa, no entanto, que o mesmo esteja funcionando. Teste, de tempos em tempos, os seus backups. Veja se tudo está sendo feito da forma correta. Se em um momento você precisar restaurar um backup e ele não estiver funcionando, será o mesmo que nunca ter feito um.

Teste seu código

O Drupal é uma ferramenta extremamente flexivel, e assim você pode fazer muitas coisas com ela. Mas, no calor do desenvolvimento, às vezes deixamos passar alguma coisa, que pode estragar o nosso trabalho.

Teste exaustivamente o seu código. Seja um módulo, um bloco, um tema. Teste tudo muito bem antes de aplicar a mudança. Testes são muito importantes.

Um ponto que merece maior destaque são os blocos do Drupal. Se um bloco estiver com erro, o site inteiro pode parar de funcionar. Uma forma simples de testar o código antes de colá-lo para funcionar dentro de um bloco, é criar uma página, definir o "Formato de entrada" como sendo PHP e alí testar o seu código. Se tudo der certo, então você poderá usá-lo no seu bloco.

Fim da parte I 

Chegamos ao fim dessa primeira parte. Em breve vou postar aqui uma nova parte desse artigo, falando mais sobre outras boas práticas para o desenvolvimento com o Drupal.

Se você quiser ir se adiantando, basta dar uma olhada na página do manual que estou me baseando. 

Até breve! 

Olá a todos!

Começo de semana produtivo esse .

Depois o módulo Blogroll de ontem, hoje foi a vez de um módulo para validar (e incluir) CPF e CNPJ que funciona em conjunto com o módulo CCK.

Esse módulo surgiu de um post do Druval Tabach no Drupal Brasil, perguntando se exisita algo. Me propus a fazer e agora está aí (no final da página).

Como de costume ele é GPL e sugestões, comentários e MacBooks são bem vindos :-p

Abraço

UPDATE: Corrigi um problema com a validação do CNPJ (Obrigado Durval). Também inclui um campo que valida tanto CPF quanto CNPJ. E aproveito para mencionar que esse módulo foi baseado no zipcode.

Olá a todos!

Geralmente quando eu visito um site e gosto do que foi escrito eu olho o blogroll dessa pessoa para ver se encontro mais
textos interessantes. Então, por isso, eu gosto de publicar um blogroll
dos sites que acho interessantes.

Eu mantenho um blogroll há algum tempo, mas sempre tive que atualizá-lo manualmente e, nos últimos tempos, ele acabou ficando desatualizado em relação ao que ando lendo.

Então, essa semana eu li uma notícia no Blog do Google Reader que falava um pouco do que dois funcionários do Google fizeram nos seus 20% de tempo livre (todo funcionário do Google tem 20% do seu tempo livre, para trabalhar com qualquer projeto que ele queira).

Um deles (Steve Lacey) deu uma sugestão para o time de desenvolvedores do próprio Google Reader: implementar um gerador de Blogroll à partir das tags que você usa para categorizar seus Feeds.

Pois bem, lá fui eu ver o tá blogroll. Muito bonitinho e tal, mas muito limitado, uma vez que ele só me dá alguns poucos padrões visuais, e nenhum deles se encaixa com o padrão visual do meu site.

Diante disso, resolvi criar um pequeno módulo para o Drupal, que se alimenta desse recurso, e gerar meu próprio blogroll, baseado no do Google Reader.

Então nasceu o módulo Blogroll (você pode baixar no final dessa página). Esse módulo foi feito e testado apenas no Drupal 5, e é o responsável pelo blogroll aí da direita. Ele está na sua primeira vesão, que ainda pode ser considerada beta, então use por sua conta e risco.

Se alguém baixar o módulo, usar e tiver críticas ou sugestões é só comentar aqui ou enviar uma mensagem pelo formulário de contato.

Abraço

P.s: Um dia gostaria de trabalhar em uma empresa que me libera 20% do meu tempo para trabalhar com o Drupal. :-)

Olá a todos!

Há alguns dias atrás postei algumas coisas falando de dois plugins pro gEdit. Naquela época eu não tinha me dado ao trabalho de procurar um relato ou extensões recomendadas por outras pessoas, apenas olhei os plugins disponíveis no site do gEdit.

Pouco tempo depois eu encontrei no blog do Elton Luís Mineto um post interessante sobre alguns plugins para tornar o gEdit mais parecido com o Textmate.

Instalei alguns dos plugins indicados, e o gEdit ficou bem bacana. Encontrei um plugin (Gemini) que inclusive faz o trabalho do Bracket Completion com muito mais eficiência.

Diante de todos esses plugins, mais o que o gEdit traz, resolvi abandonar o vim de vez. Não que eu o ache ruim (pelo contrário, ele é excelente), mas o gEdit me dá muito mais velocidade na hora de trabalhar.

Continuarei usando o vim, sempre que precisar usar algo remoto (ssh) mas agora o meu editor padrão é o gEdit.

Recomendo a todos que já viram algum screencast do Textmate em ação e que, como eu, achou fantástico, experimente instalar uns plugins para o gEdit e veja como ficam próximos os dois editores.

No site do Nando Vieira também tem uma lista legal de plugins

Até breve!

Olá a todos!

A pedido de alguns amigos, fiz algumas correções no funcionamento da extensão que busca as cotações de ações da Bovespa. São elas:

1) Tirei as mensagens de alerta quando a extensão não alcaça o servidor, colocando-as como item no lugar da ação;
2) Agora as cotações vêm diretamente do site da Bovespa, e não mais do Yahoo! Finanças;

Quem estava usando a versão anterior e adicionou ou removeu alguma ação da lista padrão, precisará editar sua lista de ações, trocando a URL do Yahoo Finanças pelo símbolo, assim, o que antes era:

http://br.finance.yahoo.com/q?s=VALE5.SA

Vai virar:

VALE5

E assim vale para todas as outras. A exceção é para o índice ^BVSP que não existe com esse nome na bovespa. Quem deixou o padrão, não precisa mexer.

Quem ainda não baixou pode baixar aqui.

Algumas melhorias ainda podem ser feitas, mas ficará para uma próxima versão. E por falar em próxima versão, essa é uma melhoria que eu devo fazer em seguida: automatizar a atualização. Para evitar que vocês precisem baixar daqui ehehe.

Continuo insistindo: quem quiser me doar um Macbook, por favor não hesite em me contactar :-p

Críticas, sugestões e comentários são bem vindos!

Abraços

Olá a todos!

Essa semana precisei fazer uma substituição de termos à partir de uma expressão regular, e descobri que o gEdit(na versão 2.15.9 que é a que tenho no trabalho) não suporta busca por expressões regulares. Então fui ao pai de todos os desesperados, o Google, e achei um cara que tinha feito metade do caminho: uma extensão que pesquisa com expressão regular, mas que não faz o replace.

Então, o que eu fiz? Mexi nela e coloquei a opção de subsituição do termo da expressão regular :-)

A extensão ainda pode ser melhorada com, por exemplo, uma opção de substituir todas as ocorrências(atualmente ele só faz uma por vez).

Abaixo está o arquivo zip, e basta você descompactar em ~/.gnome2/gedit/plugins

[UPDATE] Graças ao software livre, aqui tem uma versão melhorada, feita à partir da minha versão.

Olá a todos!

Já faz um tempo que tenho tido frequentes discussões com um amigo sobre usabilidade no Gnome e KDE.
Eu sou usuário do Gnome desde 2001. Antes disso usava KDE e gostava muito. Nessa época o Gnome ainda estava muito atrasado e pouco interessante. Em 2001/2002, no entanto, foi lançado o Gnome 2, e me deu vontade de testar pra valer. Gostei muito do que vi e tirei completamente o KDE e comecei a usar só o Gnome.

Desde então venho acompanhando os avanços do Gnome, e comparando com outras interfaces gráficas. Vejo que o Gnome tem sido bem consistente no caminho que tomou.

Uma das coisas mais fantásticas no Gnome (pra mim) é a sua simplicidade e organização. É sempre muito fácil achar alguma coisa no Gnome, seja nos seus menus, seja no Nautilus.

Eu estava conversando com um outro amigo sobre a simplicidade do Mac OS X e sobre como o Gnome se assemelha a ele, e fui apresentado ao princípio KISS - "Keep It Simple, Stupid!" Dei uma pesquisada e vi que, apesar de não estar escrito dessa forma, esse é o princípio que rege o Gnome (e o Mac OS X). A idéia me agradou, e ultimamente vejo simplificando ainda mais as coisas que tenho feito.

Discutindo com esse meu amigo do KDE, ele colocou que o KDE é redundante, pois tem vários caminhos para a mesma coisa.
Isso, para mim, não é uma vantagem, principalmente se considerarmos um usuário novato em ambientes não-Windows.
Quando se tem em vários lugares a mesma coisa, o usuário não assimila direito o caminho. Se você tem no menu, 3 ou 4  lugares em que pode chegar ao Kterminal, como você pode criar um rastro na sua mente, se toda vez você acaba indo por um caminho diferente?
Digo isso considerando a grande maioria, é claro que sempre tem gente que consegue memorizar as coisas com mais facilidade, mas essa não é a regra geral.

Acho que o KISS é um bom princípio e que deve ser usado sempre que possível. À partir de agora tentarei cada vez mais usar esse princípio sempre que for desenvolver um novo projeto.