Arquivo da tag: desenvolvimento

Desenvolvimento de Web APIs evolui no ASP.NET MVC 4

Fonte: Elemar Jr./InfoQ

A nova versão do framework para desenvolvimento de aplicativos Web da Microsoft, o ASP.NET MVC 4, amplia muito o suporte ao desenvolvimento de aplicações Web API. O framework, agora integralmente open source e disponível no Codeplex, possibilita o desenvolvimento de serviços RESTful com pouco esforço.

Entre as novidades na versão 4, destacam-se a facilidade para criar rotas para recursos (evitando colisão com rotas padrões MVC), a escrita de Actions para cada um dos métodos HTTP, o suporte nativo ao fornecimento de objetos em formato JSON e XML, além do suporte ampliado a URLs de consulta compatíveis com OData.

O ASP.NET MVC Web API permite um novo modelo de desenvolvimento web, em que o servidor provê apenas conteúdo e a geração da apresentação ocorre inteiramente no browser. Ou seja, no lugar de prover o HTML pronto, o servidor pode entregar um composto HTML + JavaScript, deixando que os dados sejam requisitados conforme demanda, via Ajax, para um serviço RESTful. (Importante destacar que o template padrão para aplicações ASP.NET MVC já possui referências para JQuery.) A possibilidade de gerar, automaticamente, respostas em formato JSON facilita consideravelmente a manipulação de código JavaScript.

As novas funcionalidades já são suportadas tanto no novo Visual Studio 11 (ainda beta e disponível para download na versão Ultimate), quanto no Visual Studio 2010 (mediante instalação).

Conforme noticiamos aqui, embora o ASP.NET MVC 4 não esteja completo, a Microsoft já recomenda sua utilização em produção. A Microsoft disponibilizou um mini-tutorial sobre o framework, com artigos e vídeos.

Cuidados com a computação na nuvem

Fonte: Marcelo A. Rezende/IMasters


Temos falado e lido muito sobre Cloud Computing. Acredito que todos já tenham entendido o que é a tecnologia, suas vantagens e, mais que isso, que veio para ficar. Porém, em um relatório divulgado recentemente pela Business Software Alliance (BSA), que aborda iniciativas e políticas para garantir o desenvolvimento da computação na nuvem, um dado negativo chama a atenção: dos 24 países que fizeram parte da pesquisa, o Brasil foi o último colocado do ranking, conseguindo apenas 35 pontos de 100 possíveis.

Um dos pontos que contribuíram para o mal resultado é que no Brasil não há legislação específica para combater os crimes ligados à computação. Quando falamos em Cloud Computing, alguns acreditam que o risco aumenta, pois a concentração de informações em grande quantidade em Datacenter pode ser considerada como ponto crítico. Risco? Será que alguém ainda acredita que deixar os dados da empresa armazenados dentro da própria empresa é mais seguro do que mantê-los em Datacenters? Acreditar nisso seria o mesmo que acreditar que corremos mais risco de sermos assaltados deixando o dinheiro no banco do que os carregando conosco pra cima e pra baixo.

O risco, como em tudo relacionado à tecnologia, está mais relacionado ao processo – principalmente no que se refere às pessoas – do que à tecnologia em si, e com Cloud Computing não seria diferente. Como nosso foco é falar principalmente para micro, pequenas e médias empresas, vamos tratar sobre as medidas que podem ser tomadas para evitar surpresas ao ingressar na nuvem. Essas dicas seguem mais a linha de abordar o processo do que tecnologia:


  • Defina quais aplicações e dados migrará para a nuvem – antes de “comprar por impulso” uma solução baseada na nuvem, cheque se de fato você e sua equipe de colaboradores precisam acessá-la de qualquer lugar. Pode parecer redundante, mas para utilizar uma solução em Cloud Computing é necessário acesso à internet. Claro que cada vez mais isso deixa de ser problema, operadoras oferecem planos de conexão 3G, smartphones e tablets aos montes, mas uma das grandes vantagens em se adotar uma solução na web é que teremos acesso a ela em qualquer lugar que tenha conexão com a internet e que poderemos disponibilizá-la a um numero maior de pessoas. Mas se isso não é fundamental em um primeiro momento, talvez seja necessário reavaliar ou adiar provisoriamente esse plano.
  • Faça um planejamento para a migração – uma vez concluído que sua empresa precisa ou vê vantagens em adotar esse tipo de solução, é necessário que haja um planejamento. O maior impacto estará na mudança cultural pela qual a organização precisará passar, já que pessoas são naturalmente resistentes a mudanças. Sugiro que a migração seja feita de forma gradativa e, sempre que avançar uma nova etapa, teste o ambiente antes de torná-lo definitivo. Isto trará mais confiança aos envolvidos.
  • Escolha a solução adequadamente – o mercado possui diversas empresas capacitadas e que oferecem soluções web. Existem no mercado muitas opções, tanto de aplicações quanto apenas de espaço em Datacenters, mas não se deixe levar pelo preço e nem mesmo pelo nome da empresa. Questione um pouco mais sobre o tipo de solução adotada, a estrutura dos equipamentos, a política de back-up, o tempo de disponibilidade etc. Pesquise na internet sobre problemas com atuais clientes e exija tudo que for oferecido em contrato. Algum tempo atrás, um grande provedor teve problemas e diversas empresas tiveram dificuldades por conta disso.
  • Crie um plano de redundância de internet – Como falei na primeira dica, o principal requisito para quem utiliza uma solução Cloud Computing é o acesso à internet, por isso é importante que ela esteja disponível o maior tempo possível. Vejo algumas empresas que se prejudicam ao adotar uma solução web por não levarem em conta o acesso à internet. Imaginemos uma aplicação crítica ligada ao faturamento da empresa e que esteja hospedada na nuvem; o provedor está OK, mas o que fará se um caminhão passar em frente a sua empresa e arrancar o fio que provê o acesso à internet dela? Irá ficar sem faturar? Hoje, existem planos de acesso à internet a custos baixíssimos e ter dois provedores ligados a um balanceador de carga é fundamental para que não corra o risco de ficar offline inesperadamente.
  • Certifique-se de quem terá acesso às informações – Talvez seja esse o item que mais oferece risco. Adotar uma política que trate os níveis de permissão diferenciadamente e determinando quem, o que, quando e de onde pode ser acessado, e, principalmente, o que pode fazer com aquela informação, garantirá maior segurança. Um vendedor que insere pedidos quando visita os clientes, por exemplo, não precisa ter acesso ao fluxo de caixa da empresa, e nem há razão para que acesse dado algum em um feriado em que não deveria estar trabalhando.
  • Proteja a sua infraestrutura – Se sua empresa tomar todos os cuidados sobre os quais falamos até agora e tiver problemas de segurança, arrisco a dizer que o problema partiu de dentro da própria empresa. É impossível imaginar que uma empresa que migre para a nuvem não utilize firewall em sua rede ou que proteja os terminais com antivírus gratuito. É muito mais fácil uma pessoa obter uma senha ou uma informação privilegiada em um computador da empresa do que quando a informação trafega na internet ou diretamente no Datacenter.

Essas dicas são genéricas e os cuidados a serem tomados com a segurança podem ser diferentes quando mudamos a aplicação, a plataforma e o dispositivo. Porém, acredito que, seguindo os cuidados mínimos, os usuários de Cloud Computing não terão problemas relacionados à segurança.

LESS CSS: Início, Meio e Fim – Conceitos iniciais

Fonte: Fabrício Sanchez!

A internet evolui diariamente, isso é um fato. Tal evolução demanda cada vez mais recursos (tanto para quem utiliza aplicações e serviços web, quanto para quem os implementa).

No sentido de incrementar produtividade e adicionar melhores práticas ao processo de desenvolvimento de aplicações para a internet, a comunidade técnica de desenvolvedores ao redor do mundo constantemente implementa, disponibiliza e mantém novos recursos ativos. Alguns exemplos são:

  • PDF Sharp: um complemento para processar programaticamente arquivos PDF.
  • JSON .NET: um framework de alta performance para o trabalho com JSON.
  • MVC Contribut: framework escrito para desenvolvedores que desejam testar elementos de UI em suas aplicações MVC.

Nesta série apresentaremos os conceitos fundamentais relacionados a um novo framework escrito nos padrões mencionados anteriormente, isto é, desenvolvido e mantido pela comunidade técnica que tem por objetivo permitir a escrita de código CSS de forma otimizada: LESS CSS.

Observação: esta série não ensinará CSS. Aqui, partimos do princípio de que os conceitos relacionados a esta linguagem já são conhecidos por você e nos concentramos apenas em apresentar uma nova forma de trabalhar com eles.

O que é LESS CSS?

LESS é um termo da lingua inglesa que designa “menos – menor quantidade”. A framework alvo de nosso estudo nesta série tem este nome (LESS CSS) não por acaso. LESS CSS é uma framework escrita com o ojetivo de otimizar a escrita de códigos na linguagem CSS, fato este que necessariamente implica na diminuição da quantidade de código escrito. Menos código escrito significa mais performance na renderização das páginas, o que implica em maior velocidade na exibição da informação para o usuário final.

Além das características recém mencionadas, há um aspecto proporcionado por esta framework que é determinante para sua adoção: o desenvolvedor pode escrever códigos mais limpos e elegantes, conforme veremos com a evolução da série.

CSS dinâmico?

Se existe uma palavra que chama atenção de qualquer desenvolvedor que inicia seus estudos em uma linguagem, framework, whatever, está palavra é “dinamismo”. De forma geral, bons devs buscam encontrar melhores formas de escrever seus códigos e, tecnologias que apresentam aspectos dinâmicos, sempre se apresentam como opções interessantes.

Conforme apresenta a imagem do início deste texto, LESS CSS apresenta uma forma dinâmica de escrever folhas de estilos (It’s the dynamic stylesheet language). O “dinamismo” é proporcionado por recursos como: variáveis, mixins, operações, funções, etc. (falaremos individualmente sobre cada recurso nos próximos posts).

Onde funciona?

Uma característica interessante do LESS CSS é que este funciona tanto do lado do cliente quanto do lado do servidor (neste último utilizando Node.js e Rhino). Assim, podemos “escolher” o ambiente para renderização do código LESS. Em post futuro, falaremos especificamente sobre como utilizar em ambos os cenários.

Criando o mind set

Agora que os conceitos estão “saltando a vista”, basta realizarmos uma análise simples em no modelo tradicional de escrita de códigos CSS para obtermos uma auto-justificação do LESS. Assim, considere o código apresentado pela Listagem 1.

#BoxTexto { color: #000; background: #EFEFEF; }
#BoxTexto a { text-decoration: underline; }
#BoxTexto p { font-family: Arial; }
#BoxTexto x {...} #BoxTexto y {...}
#BoxTexto z {...}

Listagem 1. Forma tradicional de escrever código CSS

O problema é evidente, certo? Para que possamos utilizar o mecanismo de herança, precisamos reecrever o mesmo código seis vezes. Em um tempo onde produtividade é fator chave no processo de desenvolvimento de software, este tipo de notação tende a cada vez mais, cair em desuso.

Em contra partida, observe o código apresentado pela Listagem 2.

#BoxTexto {
color: #000;
background: #EFEFEF;
a { text-decoration: underline; }
p { font-family: Arial; }
}

Listagem 2. CSS reduzido

Bem melhor não? Esta é a proposta do framework LESS. O mesmo código escrito de forma mais elegante e inteligente resultando no mesmo aspecto visual entretanto, com mais performance.

WebService em Python

Tive uma necessidade estes dias de criar um webservice em um servidor linux que retornasse os logs de emails do postfix, fazendo um grep (find) pelo usuário, tipo de protocolo e data.

Pesquisei um pouco, e achei uma solução muito boa, fazer o desenvolvimento do webservice em Python, o que é muito simples e de muito rápida execução.

O servidor que eu estava trabalhando usa CentOS e vinha com as bibliotecas padrões do python instalado, caso o seu sistema não venha, um apt-get install python ou um yum install python deve resolver o problema. Mas eu ainda precisava de mais duas bibliotecas que não vinham com a minha distro: fpconst e SOAPpy. Procurei as duas aqui: http://rpm.pbone.net/, achei a que se enquadrava para o meu sistema operacional i586.

Segue as versões de como eu usei:

mkdir /home/pacotes
cd /home/pacotes/
wget http://pypi.python.org/packages/source/f/fpconst/fpconst-0.7.2.tar.gz#md5=10ba9e04129af23108d24c22c3a698b1
wget http://downloads.sourceforge.net/project/pywebsvcs/SOAP.py/0.12.0_rc1/SOAPpy-0.12.0.tar.gz?use_mirror=ufpr
tar -cvf fpconst-0.7.2.tar.gz
tar -cvf SOAPpy-0.12.0.tar.gz
cd fpconst-0.7.2
python setup.py install
cd ../home/SOAPpy-0.12.0
python setup.py install

Pronto, minhas duas bibliotecas já estavam funcionando.

Agora vamos ao webservice:

#!/usr/bin/python
#import das bibliotecas necessarias
from SOAPpy import SOAPServer
import os
import commands
 
#caminho dos arquivos de logs
caminho = '/root/cirolini/'
 
#identifica se o protocolo for pop ou imap e direciona para a pasta solicitada
def protocolo(protocolo):
        if protocolo == 'popper':
                return 'popper/popper.log'
        if protocolo == 'imap':
                return 'imap/imap.log'
 
#literalmente da um grep nos logs que estao no formato popper.log.2010-03-16T08:00-03:00
def buscaLogs(usuario, proto, data):
        proto = protocolo(proto)
        busca = "zgrep " + usuario + " " + proto + "." + data +"*"
        var = commands.getoutput(busca)
        return var
 
#instancia o webservice para rodar na porta 8081 e responder para pesquisas como localhost
server = SOAPServer(('localhost',8081))
#registra a funcao que vamos chamar no nosso cliente
server.registerFunction(buscaLogs,'ns-buscalogs','buscaLogs')
#indica para o webservice nao parar de executar
server.serve_forever()

Acredito que já deixei tudo bem comentado de como funciona.

E segue o nosso cliente:

#!/usr/bin/python
#importa a biblioteca para fazer o webservice via SOAP
from SOAPpy import SOAPProxy
 
#parametro do webservice para ele saber a porta e o namespace (funcao) que vamos chamar
url = 'http://localhost:8081'
namespace = 'ns-buscalogs'
 
#conecta no webservice
server = SOAPProxy(url,namespace)
#isto para dar um dump das informacoes de entrada e saida
server.config.dumpSOAPOut = 1
server.config.dumpSOAPIn = 1
 
#escreve na tela o retorno da funcao do webservice buscaLogs
print server.buscaLogs('rafael','popper', '2010-03-16')

Os retornos ficaram mais ou menos desta forma:

[root@dsv cirolini]$ python cliente.py
*** Outgoing SOAP ******************************************************
<?xml version="1.0" encoding="UTF-8"?>
<SOAP-ENV:Envelope SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/" xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance" xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/1999/XMLSchema">
<SOAP-ENV:Body>
<ns1:buscaLogs xmlns:ns1="ns-buscalogs" SOAP-ENC:root="1">
<v1 xsi:type="xsd:string">rafael</v1>
<v2 xsi:type="xsd:string">popper</v2>
<v3 xsi:type="xsd:string">2010-03-16</v3>
</ns1:buscaLogs>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
************************************************************************
*** Incoming SOAP ******************************************************
<?xml version="1.0" encoding="UTF-8"?>
<SOAP-ENV:Envelope SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/" xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance" xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/1999/XMLSchema">
<SOAP-ENV:Body>
<buscaLogsResponse SOAP-ENC:root="1">
<Result xsi:type="xsd:string">Mar 16 08:46:19: end session - user rafael from 127.0.0.1: time=1 inbox=0/0 quit=1/4/138 stat=1/19/9 auth=1/150099/111 </Result>
</buscaLogsResponse>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
************************************************************************
Mar 16 08:46:19: end session - user rafael from 127.0.0.1: time=1 inbox=0/0 quit=1/4/138 stat=1/19/9 auth=1/150099/111

Fonte: Rafael Cirolini/NerdHead

Heroku lança serviço de provisionamento exclusivo para PostgreSQL

A Heroku mudou a estratégia do seu serviço Heroku Postgres. A partir de agora o serviço provê uma infraestrutura para armazenamento de bases de dados PostgreSQL, independente da solução PaaS (Platform as a Service) utilizada. O Heroku Postgres é uma plataforma disponibilizada com o conceito SQL Database-as-a-Service; a proposta é que os desenvolvedores implementem suas aplicações com o PostgreSQL sem se preocupar com questões como disponibilidade e desempenho, uma vez que estas serão resolvidas pela própria infraestrutura do Heroku.

O Heroku Postgres foi disponibilizado em 2007, mas até agora era oferecido somente como um serviço agregado à plataforma de nuvem da Heroku. O serviço estava disponível apenas para os clientes que desenvolviam e implantavam suas soluções web utilizando o PaaS da empresa. Com a nova estratégia, desenvolvedores têm a opção de utilizar o serviço em conjunto com a plataforma de cloud computing da Heroku ou não. Isso possibilita o desenvolvimento utilizando outra solução PaaS, um ambiente de cloud diferente, ou até utilizando um máquina local.

Segundo a equipe da Heroku, as principais vantagens em utilizar o serviço são a disponibilidade e a capacidade de processamento, além da segurança dos dados:

O Heroku Postgres tem suportado com sucesso 19 bilhões de transações clientes diariamente. A segurança e a durabilidade dos dados são a prioridade número um do serviço. Um conjunto de tecnologias chamado Continuous Protection foi desenvolvido para evitar qualquer tipo de perda de dados, mesmo em caso de falhas catastróficas.

Atualmente são oferecidas seis opções de planos para contratação do serviço. Os preços variam de acordo com o tamanho do cache escolhido, começando em 200 dólares por mês e chegando a US$ 6.400 mensais. Todos os planos incluem backup dos dados, monitoramento 24×7, 2 terabytes de espaço em disco, entre outras funcionalidades.

O Heroku Postgres também fornece uma API para que os clientes utilizem o serviço através da linha de comando ou via website. Para os interessados em mais detalhes, foi disponibilizado material com um guia introdutório, documentação detalhada, tutoriais e artigos sobre o serviço.

Fonte: Eder Magalhães/InfoQ

Canonical resolve descontinuar CouchDB do Ubuntu One

A Canonical decidiu descontinuar o uso do CouchDB como parte do seu serviço de sincronização de dados, Ubuntu One. O anúncio foi feito por John Lenton, gerente sênior de engenharia na Canonical.

De acordo com Lenton, a Canonical trabalhou com a companhia por trás do CouchDB para fazer o banco de dados escalar de uma maneira peculiar. “Nossa situação é única e ficamos incapazes de resolver alguns problemas que surgiram”.

Devido a esses problemas, a Canonical decidiu desligar a maioria dos seus serviços baseados no CouchDB. Bancos de dados de contatos, notas e playlists ainda existirão para usuários para suportar os serviços que eles consomem, mas o acesso externo aos sistemas de banco de dados será descontinuado, e quaisquer outros bancos de dados armazenados no serviço de nuvem do Ubuntu será deletado.

Além disso, a Canonical está descontinuando o desenvolvimento do desktopcouch e, no Ubuntu 12.04, pacotes do Ubuntu One não usarão o CouchDB. Segundo Lenton, a empresa está construindo algo novo, baseado em tudo o que foi aprendido, que recebeu o nome de U1DB. Entretanto, ele não ficará pronto a tempo de ser incluído no Ubuntu 12.04.

Não foram divulgadas datas de quando os bancos de dados serão removidos.

Com informações de The H

Fonte: IMasters

URL do WebService dinâmico

Hoje vamos falar sobre um código importante para quem usa URL dinâmica no WebService. Para quem trabalha com vários ambientes de software, essa solução pode valer muito a pena.

Usado:

Ferramenta de desenvolvimento: Visual Studio.NET (qualquer versão)

Linguagem: C#.NET

Framework 3.5 pra cima

Para quem tem os ambientes devidamente separados, é necessário utilizar alguns dados dinâmicos para evitar retrabalho no momento da compilação. Isto é, alterar só no arquivo de configuração de acordo com o ambiente de desenvolvimento, homologação e produção.

Imagine que exista um webservice dentro da ferramenta referenciada, na pasta Web References. A URL desse webservice aponta diretamente para o ambiente de desenvolvimento, porém, é necessário publicar a aplicação no ambiente de homologação.

O webservice já está no ambiente de homologação e a ideia não é referenciar uma nova URL dentro da ferramenta. (Figura 1)

É preciso que esse apontamento de URL seja dinâmico e esteja de acordo com o ambiente que o aplicativo for publicado, isto é, para homologação pegar a URL de “hom”, para “produção” e assim por diante.

Se não for colocado dinamicamente, para cada ambiente é necessário alterar a URL na ferramenta, compilar novamente e publicar no ambiente. Veja a URL (Figura 2). Esse ambiente é de desenvolvimento.

No terceiro campo (Web Reference URL) está o que é preciso mudar. A primeira coisa é declarar a variável no início do código. (Tabela 1)

private WSRetaguarda.Retaguarda wsRetaguarda; //variavel do webservice

Tabela 1

O próximo passo é gerar um método para verificar a variável e atribuir o valor. (Code 1)

private void InicialzarWebService()

{

if (wsRetaguarda == null)

{

wsRetaguarda = new WSRetaguarda.Retaguarda();

wsRetaguarda.Url = pathWebService;

}

else

wsRetaguarda.Url = pathWebService;

}

Esse code 1 verifica primeiramente se a variável é null. Se for, ele gera uma nova instância e atribui a variável URL passando o path do webservice dinâmico. Esse path dinâmico pode estar dentro do arquivo web.config.

Para quem usa a ferramenta Visual Studio .NET 2010, fica bem simples, porque o arquivo de configuração é dinâmico para cada ambiente. Veja o vídeo abaixo e se informe mais.

Vídeo:

link do vídeo

Depois de criar o método e colocar a variável pegando do web.config, basta chamar sempre este método (inicializarWebService()) antes de chamar qualquer outro método do webservice. Veja o exemplo Code 2.

private void carregarDados()

{

try

{

InicialzarWebService();

DataTable dtResultado = wsRetaguarda.buscaModeloHardware();

cmbScanner.DataSource = dtResultado;

cmbScanner.ValueMember = "mhaId";

cmbScanner.DisplayMember = "mhaNome";

if (dtResultado.Rows.Count > 0)

{

foreach (DataRow dtRow in dtResultado.Rows)

{

this._listaMhaUrlInstalacao.Add(Convert.ToInt32(dtRow["mhaId"]), Convert.ToString(dtRow["mhaUrlInstalacao"]));

}

}

}

catch (Exception ex)

{

throw ex;

}

}

É bem simples e fácil, pois agora não é preciso compilar os dados para atribuir a URL de acordo com o ambiente. Caso você use um new chamando o webservice, essa URL se perde, e volta a apontar para desenvolvimento. Isso porque é a primeira da ferramenta do Visual Studio.NET.

Fonte: Mauricio Junior/IMaster

Desenvolvimento de software não é construção civil

Ao longo dos últimos anos, uma das áreas que mais cresceu foi justamente a de tecnologia voltada para o desenvolvimento de software e, com esse grande impulso, vieram junto enormes problemas que vão desde qualidade, prazos e, principalmente, expectativas de todos os envolvidos no processo, levando grande parte dos projetos a algum tipo de fracasso, conforme podemos observar nos principais estudos relacionados, como o “Chaos report”, promovido pelo The Standish Group.

A arte de desenvolver software é baseada em um modelo completamente criativo e dinâmico, sujeito a mudanças em cada passo, sejam oriundas de uma amplificação no entendimento do valor de negócio por parte do cliente ou em atividades emergentes que surgem logo nos primeiros minutos de codificação em qualquer projeto de desenvolvimento de software.

As disciplinas tradicionais de gestão baseiam-se em muitas ideias aplicadas na própria construção civil e tentam, usando esses princípios, determinar os mesmos fundamentos para projetos de desenvolvimento de software desconsiderando que são modelos completamente diferentes e conduzidos por pessoas criativas. Eu costumo dizer que, ao projetar um prédio nós costumamos ver a evolução da construção, desde a fundação e paredes que vão aparecendo aos nossos olhos. Rapidamente você consegue pegar e medir quanto é necessário de investimento e esforço para atingir o objetivo. Já no software a realidade é completamente diferente, pois é emergente e adaptável em cada passo dado.

É hora de mudar e adotar atitudes mais ágeis que provoquem a colaboração e comprometimento entre todos os envolvidos no ciclo produtivo do software. Estamos falando de pessoas altamente criativas e não de máquinas ou “recursos”.

Em meados de 2001 os principais pensadores da época deram um grande passo reunindo-se para formação do “Manifesto para Desenvolvimento Ágil de Software” que representou um grande marco de mudança contra os modelos tradicionais de desenvolvimento de software com 4 pilares importantes:

  1. Indivíduos e interações mais que processos e ferramentas
  2. Software em funcionamento mais que documentação abrangente
  3. Colaboração com o cliente mais que negociação de contratos
  4. Responder a mudanças mais que seguir um plano

A base principal disso tudo são pessoas felizes colaborando com o processo produtivo que requer adaptação frequente e muita atenção para atender a expectativa do cliente dentro dos objetivos do projeto. No modelo ágil, direcionamos todas as energias em criar um software funcionando orientado aos desejos do cliente que, sabemos, nunca são iguais aos pensamentos originais. Eles emergem e amadurecem junto com as entregas frequentes de software que são apresentadas em cada final de Sprint.

Ao questionar diversos desenvolvedores sobre documentação de software durante a manutenção, nenhum deles confirmou que abre qualquer documentação e sim vai direto ao código fonte resolver o problema. Imagina agora um cenário onde precisa fazer uma mudança, seja qualquer for o tamanho, como terá certeza que não gerou nenhum tipo de impacto no projeto? Não encontrará nenhum documento word que lhe dará essa garantia no código.

Para isso nós usamos outras abordagens no desenvolvimento ágil como TDD (Test Driven Development), orientando o desenvolvimento a testes unitários, gerando uma documentação de negócio no formato de testes que são executados automaticamente, garantindo que aquele código coberto pelos testes não sofreu impacto com a mudança de negócio. Na prática nós desenvolvemos primeiro os testes e depois as regras de negócios, já validando as mesmas com os testes, diminuindo inclusive o tempo de desenvolvimento.

Para alinhar a visão do cliente com as implementações realizadas, temos uma abordagem em desenvolvimento ágil conhecida como BDD (Behavior Driven Development) que permite orientar o desenvolvimento baseando-se no comportamento de negócio desejado escrito em histórias pelo cliente, fortalecendo mais ainda um dos princípios em desenvolvimento ágil que é o valor de negócio.

Para integrar o código fonte desenvolvido usamos a abordagem de CI (Continuous integration), tendo um mecanismo automático para geração de versão e entrega do software funcionando, permitindo uma visibilidade do produto que está sendo entregue e indo além, usando os testes unitários produzidos e outras abordagens para garantir a integridade do código fonte e sua fidelidade aos valores de negócio garantidos dentro dos testes e outros padrões de projeto, como arquitetura em camadas favorecendo a reutilização de software.

A informação mais importante que devemos passar ao nosso cliente é que estamos aptos a fazer mudanças no software e adaptar ao final de cada ciclo para juntos atingirmos os valores de negócio do projeto. Ter o cliente próximo esclarecendo as dúvidas faz a diferença e reduz todo o ruído de diferenças de entendimento, permitindo esclarecer o mais breve possível sempre que aparecer qualquer impedimento ou mudança de rumo.

As pessoas tratadas como pessoas e incentivadas a colaborar produzem cerca de 10 vezes mais, pois são desafiadas a dar o melhor de si e valorizadas pelos resultados proporcionados à equipe de uma maneira rápida, pois com ciclos curtos de projetos conseguirmos alinhar rapidamente qual o resultado de cada equipe de projeto. É muito importante que todos se sintam importantes no processo. Por isso incentivar a participação e compartilhamento de informações resulta em comprometimento.

O desenvolvimento de software como um trabalho criativo e intelectual requer uma atenção dobrada na equipe, motivando e alinhando expectativas, além de iniciativas que valorizem cada entrega de projeto com sucesso, mesmo que seja tirando uma foto da equipe e uma Coca-Cola gelada para cada. Na maioria das vezes a intensão vale mais que a força empregada e, ter um ambiente de trabalho feliz é o maior impulsionador de qualquer projeto.

Compartilhe, escute e provoque criando desafios animadores nas pessoas para que juntas formem uma grande força em prol de uma causa e não de uma regra. Conquiste liderando e multiplique a visão por todos do projeto removendo impedimentos e burocracia que não contribuem em nada com o resultado.

Para ter a melhor estratégia de desenvolvimento em um projeto de software inicie pela formação da equipe e crie mecanismos de qualificação e demais incentivos para manter um grupo forte e orientado a resultados. Acabo por acompanhar muita gente preocupada com quanto tempo uma pessoa está parada na frente do computador e não com o resultado que essa pessoa proporciona ao projeto.

Até hoje venho observando em projetos de “software civis tradicionais” gerentes e analistas estimando atividades para outras pessoas assumirem o compromisso de programar. É logico que sabemos de antemão que os desenvolveres vão concordar e que você já vai dar o prazo sabendo que não será entregue, criando o que eu batizei de mundo “Alice do Software”, onde todos sabem que não vai dar certo, mas continuam vivendo até não aguentarem viver mais dentro do caos e darem o grito de mudança.

De uma vez por todas vamos entender que resultado em um projeto de software se dá pela energia criativa para construir uma solução simples e rápida e não pela quantidade de força empregada ao longo do tempo. Para ter comprometimento é fundamental compartilhar com todos do projeto as informações e objetivos e abrir espaço para escutar e colaborar.

O dia que descobrirem, finalmente, que desenvolvimento de software é empírico, mutável e não pode ser encarado como um projeto de uma obra civil, teremos atitudes diferentes com pessoas felizes desenvolvendo com qualidade desde o início e entregas rápidas alinhando a expectativa de negócio.

Para saber mais:

Fonte: Ramon Durães/IMasters

O desenvolvimento ágil funciona em projetos de hardware?

Vários profissionais de TI tem trazido à tona recentemente a questão da aplicação das práticas ágeis no desenvolvimento de hardware. Nil Johnson escreveu um artigo na Electronic Engineering Times (EETimes): Desenvolvimento ágil de hardware – sem sentido ou necessidade?

Ele colocou a questão:

Deve haver um debate quando se trata de aplicar o Agile no desenvolvimento de hardware? Deveriam os valores e princípios que guiam as equipes ágeis de software também guiar os times que desenvolvem para sistema operacional (System on Chip teams) ; ou as diferenças entre estas duas disciplinas seria muito grande?

Ele continua com uma discussão sobre os valores do Manifesto Ágil e como estes valores formam a base da abordagem ágil no desenvolvimento de software. Ele coloca a questão – Poderia o mesmo funcionar para o desenvolvimento de hardware? – e comenta:

Para qualquer um que vê o desenvolvimento de hardware como um processo criativo, é difícil negar que os valores do manifesto são diretamente aplicados. Mas apenas considerar um conjunto de valores não é suficiente. De certo modo, valores abstratos precisam se traduzir na prática. Felizmente, times de software têm criado práticas que abordam os valores ágeis e muitas delas podem ser aplicadas diretamente também no desenvolvimento de hardware.

Ele reconhece as diferenças entre as abordagens do desenvolvimento de software e de hardware encorajando os times de hardware a abraçarem as práticas ágeis. Ele usa a prática do continuous delivery (entrega contínua) como um exemplo:

Uma prática de destaque é aquela de implantação rápida e contínua aos clientes. Para muitos times ágeis de software, implantação contínua é absolutamente crítico para o sucesso. Infelizmente, sua aplicabilidade no desenvolvimento de hardware – ou a falta dela – tende a ser usado para desacreditar o Agile totalmente. Para desenvolvimento ASIC em particular, implantação contínua não é realista; mas uma prática não ser realista não deve ser motivo de descrédito do conjunto de práticas. Nenhum time ágil de software realiza todas as práticas ao pé da letra; logo não se pode esperar o mesmo de um time de desenvolvimento de hardware.

Ele conclui com um pedido de mudança no foco das organizações de hardware:

Mudanças acontecem no desenvolvimento de hardware. Independentemente se são mudanças nas especificações, na rotatividade de funcionários, na dinânica do time ou novas tecnologias. Não há como evitar isso. As equipes que deixarem de lado os conceitos de Dilbert e as políticas internas para uma forma mais apurada e uma visão mais humana do desenvolvimento de hardware, retratada pelo manifesto, vai fazer desta mudança uma vantagem. Aos times que não se abrirem a esta mudança, irá restar o exercício fútil de tentar encaixar o “quadrado” dos tradicionais processos bem definidos no “buraco redondo” que é o desenvolvimento de hardware atual.

Larry Maccherone escreveu recentemente algo similar sobre as As 10 questões principais sobre quando usar Agile em projetos de hardware.

Ele elenca uma lista de questões e respostas a fim de auxiliar nas decisões sobre a aplicação de abordagens ágeis em projetos de hardware:

  1. As práticas e processos ágeis são efetivos na condução de projetos que não são de software (firmware, eletrônicos, mecânicos, etc.)?
  2. Quais ajustes são necessários no framework de processo Scrum para funcionar bem para estes projetos?
  3. Quais ajustes são necessários em nossas expectativas sobre funcionalidades comerciais mínimas, design emergente e definição de Scrum?
  4. Quais ajustes em nossas expectativas são necessárias acerca de histórias?
  5. Como fica a questão de priorizar histórias estritamente pelo valor gerado ao usuário final?
  6. Deveriam as histórias de usuário ser nossa única ferramenta de gerenciamento de requisitos?
  7. Se histórias de usuário não são nem requisitos oficiais do Scrum, então porque não devemos usar somente nossas práticas tradicionais de requisitos?
  8. O que fazer quando precisamos enviar um protótipo ao fornecedor e não é possível ser feito dentro de uma iteração?
  9. O que fazer com dependências e analise do caminho crítico?
  10. Talvez não precisemos da analise contínua do caminho crítico, mas ainda temos especialistas que não são dedicados permanentemente ao time. Como lidar com isso?

Para cada questão que ele lista uma resposta curta é dada seguida de uma discussão de abordagens práticas para resolver as potenciais incompatibilidades e como endereçá-las.

As práticas ágeis poderiam ser usadas no desenvolvimento de hardware? Quais mudanças seriam necessárias fazê-las funcionar neste contexto?

Nova versão do Orion traz melhorias e novos plugins

O time de desenvolvimento do Orion anunciou a nova versão da sua ferramenta web para desenvolvimento de aplicativos web, o Orion 0.3. Essa nova versão traz melhorias no editor de código, na integração com o Git e no desenvolvimento de plugins para integração com outras ferramentas.

O Orion é a aposta da Fundação Eclipse para criar um ambiente integrado de desenvolvimento (IDE) disponível na web. O objetivo do Orion é mover o desenvolvimento de sistemas para a web, trazendo a experiência já adquirida com IDEs desktop (Eclipse) para a web. A seguir estão descritas as principais melhorias implementas no Orion 0.3.

Melhorias no editor

O editor de código do Orion agora suporta a busca e substituição de conteúdo (find and replace). O usuário pode acionar a busca através da tecla de atalho Ctrl+F. Outra nova funcionalidade do editor é possibilidade de navegar em links (uma url em comentário, por exemplo) através da tecla Ctrl (ou Cmd).

O editor JavaScript não possui mais dependência para o framework Dojo, isso torna o editor mais leve e favorece o uso de outros frameworks JavaScript durante a codificação. Disponível apenas para JavaScript, por enquanto, o Orion tem a funcionalidade de exibir/ocultar (folding) blocos de comentário quando o usuário navega sob uma área demarcada no código.

Também foram implementadas melhorias na sinalização de erros e warnings. Agora o editor consegue diferenciar warnings e erros, além de apresentar o conteúdo em múltiplas linhas, com um layout mais adequado.

Novos Plugins

Foi desenvolvido um plugin para o Bugzilla, com a funcionalidade de vincular o link do bug/melhoria na descrição do commit no Git. Essa informação permanece junto ao histórico de modificações no repositório.

O desenvolvedor passa a contar com um plugin que integra o Orion com o CSSLint, uma ferramenta que analisa a qualidade do CSS. Também foi criado um plugin para o WebDAV, para a integração de arquivos hospedados no Orion com um servidor WebDAV.

Melhorias na integração com o Git

Foi adicionado suporte ao Git cherry-pick. Essa funcionalidade permite que o desenvolvedor rapidamente identifique as mudanças realizadas em um commit de outro branch.

O Orion passa a suportar o Git Rebase. O Rebase é util para sincronizar modificações realizadas em um branch remoto depois que o branch local foi definido. O desenvolvedor passar a ter mais autonomia para realizar o push de conteúdo em branches remotos. Outra novidade é o nome dos branches na página de logs do Git.

Associar uma conta do OpenID com o perfil

O usuário pode vincular uma conta OpenID com o perfil do Orion. O OpenID é um serviço de autenticação que centraliza as credencias do usuário e permite que outros sites/serviços deleguem a ele o processo de autenticação. Com essa funcionalidade, o usuário pode se autenticar no Orion utilizando uma conta do OpenID.

O Orion está disponível online através do OrionHub e para experimentar a IDE basta criar uma conta gratuita. Existe também opção de realizar o download do Orion e usá-lo localmente que, a partir dessa distribuição, conta com um servidor web embutido e permite que o serviço esteja disponível na máquina do próprio desenvolvedor.

Fonte: Eder Magalhães/InfoQ

Boas práticas de programação – filosofias de desenvolvimento

Vou escrever um resumão de alguns conceitos muito importantes para o desenvolvimento de softwares, independente da linguagem que você estiver “falando”.

Conceitos antigos, mas que muitas vezes não são tão difundidos quanto deveriam.

Para evitar uma confusão durante a leitura e alguns comentários perdidos, informo que o nível desse artigo é mediano. Nem muito avançado, a ponto de que um Dev iniciante fique completamente perdido (talvez apenas não entenda alguns trechos, mas nada que atrapalhe a assimilação do todo), e nem tão básico a ponto de ser desinteressante para quem já tem um pouco mais de experiência.

Um dos conceitos mais importantes diz que seus códigos devem ser de fácil manutenção e é impossível que a sua aplicação seja “simples” de refatorar, se ela tiver rotinas idênticas espalhadas “ao Deus dará”. Note que os conceitos que citarei se aplicam a um mesmo projeto. Durante o desenvolvimento de uma aplicação, leve em conta os seguintes pontos:

SOC = Separation Of Concerns

Separe os interesses. Divida rotinas em trechos tão pequenos quanto possível, e tanto quanto ainda fizer sentido. Quando temos um grande problema para resolver, devemos começar separando esse problemão em probleminhas menores e resolvê-los uma vez. Isolando em pequenas partes focadas você privilegiará até o reaproveitamento do seu código.

DRY = Dont Repeat Yourself

Não repita a si mesmo. Se você já programou um trecho de código que resolve uma dada situação e logo mais adiante se depara com a mesma situação, você não deve desenvolver a mesma rotina outra vez ou muito menos replicar o script. Sem essa de Ctrl+C / Ctrl+V (ou command no caso de usar MAC). Também pode ser conhecido por:

DIE = Duplication is Evil

E é o que realmente é. Duplicação é ruim. Ruim para o desenvolvedor, para o desenvolvimento, para futuras correções… Não duplique códigos.

Existem até Design Patterns específicos que tratam desse tipo de questão.

Desacoplamento é o objetivo. Devemos saber que é impossível termos componentes completamente independentes porém o Strategy, por exemplo, pode nos ajudar nisso.

Trabalho com sistemas web. Programo hoje em dia principalmente em php. Não estou falando que “é ruim” instalar o WordPress 2-3, várias vezes para vários clientes, duplicando o core do WP em vários dominios. Digo para você não se repetir num mesmo site, num mesmo projeto.

Se eu já implementei uma rotina de conexão ao banco de dados, não vou duplicar essa rotina. Não vou ter mais que um único arquivo com os dados de configuração. Não vou jogar por vários cantos da aplicação a lógica do cálculo de descontos do e-commerce. Tenho que analisar bem e centralizar para não me repetir ou “reinventar a roda” que eu mesmo já inventei.

KISS = Keep It Simple, Stupid

Mantenha simples. Descarte toda a complexidade que não for realmente necessária.

Lógico que nem tudo é simples. Existem coisas que realmente não são. Porém a idéia do KISS não é deixar fácil, mas sim evitar complicar. Evitar aumentar o custo entregando exatamente o que foi requisitado. E apenas isso.

Você e sua aplicação só ganharão com isso.

KISS é fazer menos, e não fazer da forma mais fácil.

Mantenha o foco. Desse conceito derivam os dois seguintes:

YAGNI = You Aren’t Going Need It

Bastante parecido com o conceito de cima. “Você não vai precisar disso” nos diz para não complicar ou ficar inventando o que não será usado.

É uma tentação comum querermos desenvolver o sistema mais incrível do mundo com as melhores funcionalidades.

Seja racional. Preveja a expansão e escalabilidade, porém não fique dando voltas atrás do próprio rabo sem sair do lugar ou entregar o que foi pedido por estar implementando algo que não era nem requisito e nem necessário naquele momento.

Worse is better, também nos diz exatamente isso. A qualidade não provém somente de mais funcionalidades. Ao pé da letra, “quanto pior, melhor”. Devemos prezar pela praticidade e usabilidade, mesmo que sejamos obrigados a impor limites. Algumas expansões são óbvias e não vamos deixar de fazê-las, porém analise se neste momento é necessária ou não.

Além desses pontos, nunca devemos nos esquecer de identar, comentar, documentar…

Um não concorre com o outro. Use todos juntos, como complementos. Aplicar um desses conceitos te leva ao seguinte.

Ainda não tenho conhecimento suficiente para ensinar. Continuo estudando e espero ter contribuido com alguma coisa, assim como contribui com o meu próprio aprendizado ao me propor a escrever esse texto.

Fonte: William Bruno/IMaster

WordPress, Drupal ou Joomla: qual a melhor solução para o seu projeto?

Com tantas opções de CMS’s disponíveis hoje em dia, com funcionalidades e finalidades diferentes, não faz muito sentido dizer qual deles é o melhor, mas sim qual deles atende melhor as suas necessidades. E, para chegarmos a essa resposta, nada melhor do que uma boa análise das opções que temos disponíveis.

Para começar a brincadeira, trago aqui um pequeno comparativo entre as principais opções livres em CMS’s, baseado em algumas informações do infográfico feito pela DeviousMedia, além de um bate-papo com três especialistas nessas soluções.

WordPress, joomla ou drupal?

Um breve histórico de WordPress, Drupal e Joomla

O mais velho entre os três sistemas é o Drupal, que foi criado pelo programador Dries Buytaert e lançado em 15 de janeiro de 2001. O nome Drupal vem da palavra holandesa “druppel”, que significa “gota”, e atualmente está na sua versão número 7, com uma frequência média de uma atualização a cada 36 dias, desde a sua versão 4.3, lançada em novembro de 2003, num total de 77 atualizações. Aproximadamente 1,6% dos sites da web usam o Drupal, entre eles o The Economist, The White House, MTV, London.gov.uk e The Onion.

Já o WordPress foi criado por Matt Mullenweg a partir do sistema B2/Cafelog, e teve seu lançamento em 27 de maio de 2003. O que começou como um simples sistema para blogs, hoje já na sua versão 3, está consolidado como um CMS bem completo, com uma frequência média de uma atualização a cada 17,8 dias, num total de 164 atualizações. Hoje ele é usado por aproximadamente 14,3% dos sites da web, entre eles o MTV Newsroom, The Ford Story, entre outros. Uma curiosidade é que, desde a sua versão 1.0, a maioria das versões do WordPress leva o nome de um cantor de jazz, como Coltrane ou Gershwin.

Por fim, temos o Joomla, criado a partir do CMS Mambo e lançado em 16 de setembro de 2005. Mantendo uma grande comunidade em vários países e línguas, o Joomla possui 6 versões lançadas, com uma frequência média de uma atualização a cada 49 dias na sua versão 1.5, e uma atualização a cada 25 dias na sua versão 1.6. São 27 atualizações (incluindo versões Beta) entre essas duas versões. Aproximadamente 2,7% dos sites da web usam o Joomla, entre eles estão sites como o Linux.com e o IHOP.

Ambos os sistemas são escritos em PHP, além de serem projetos de código aberto, distribuídos sob a GNU General Public License.

Plugins e Templates

Em praticamente todos os CMS’s, podemos acrescentar novas funcionalidades através de plugins ou módulos, que podem estender o uso do sistema para diversas finalidades. Nesse sentido, o WordPress leva vantagem, tendo os desenvolvedores um número de aproximadamente 14.629 opções disponíveis. No Drupal, esse número é de aproximadamente 8.039, enquanto o Joomla possui uma média de 8.000.

Para quem possui um projeto mais modesto, e pretende abrir mão de uma identidade visual personalizada, usando um modelo de site com funcionalidades definidas e layout pronto, são muitas as opções de templates disponíveis para os diferentes CMS’s. Considerando apenas os templates gratuitos disponíveis nos sites oficiais, temos uma marca de 1415 templates para WordPress e 878 templates para Drupal. No site oficial do Joomla, não constam informações referentes a templates.

Otimização para os mecanismos de busca

Elemento obrigatório na concepção de qualquer projeto web, as técnicas de SEO são hoje uma exigência de praticamente todos os clientes, até daqueles que não têm nem ideia do que isso venha a ser. Mesmo que hoje os principais influenciadores para a definição do posicionamento das páginas nos resultados de busca estejam relacionados à qualidade do conteúdo e à popularidade dos sites, podemos dizer que os primeiros passos para um bom SEO começam na estrutura do código HTML.

Por seguirem bem as práticas recomendadas pela W3C para o desenvolvimento web, ambos os sistemas possuem uma estrutura de código apropriada para o SEO. Contudo, o WordPress ainda leva uma pequena vantagem, por possuir uma estrutura um pouco mais semântica.

Ambos os sistemas possuem boas extensões para SEO, que buscam aprimorar a qualidade de elementos como títulos, sitemaps e URLs. Entre as extensões disponíveis, podemos destacar o WordPress SEO para WordPress, o Pathauto para Drupal, e as extensões AceSEF e sh404SEF para Joomla.

Tecnicamente falando

O WordPress, que ganhou popularidade como uma plataforma para blogs, vem se mostrando a cada dia como um dos CMS’s mais completos que existem. Para Leo Germani do Hacklab, o WordPress foi a ferramenta com a qual ele conseguiu obter os melhores resultados com maior eficiência. “No final de 2006 resolvi adotar um CMS para trabalhar, e experimentei as principais opções. O que me atraiu no WordPress desde o início foi sua simplicidade. Enquanto outros CMS’s demandavam uma curva aprendizado maior, o WordPress se mostrava direto e fácil, tanto do ponto de vista do usuário quanto do ponto de vista do desenvolvedor”, afirma Leo.

Nadir Alves da Bule Comunicação, que já trabalhou com CMS’s como o Plone e o WordPress, afirma que o Joomla possui um grande poder de customização de templates e uma curva de aprendizado muito leve. “As opções de expansão do Joomla sempre foram muito grandes, atualmente existem mais de 8.000 extensões no diretório oficial. Somando isso ao sistema de permissões de usuários e à facilidade de criar websites rápidos e completamente diferentes um do outro, o Joomla tornou-se uma escolha excelente e recomendada aos nossos clientes”.

Já o Drupal é considerando o mais complexo entre as três opções. Mas para Alex Piaz, que trabalha no Instituto Socioambiental (ISA), apesar de a curva de aprendizado do Drupal ser maior em relação aos seus similares, uma vez que você “pega o jeito” tudo fica muito claro, e o desenvolvimento passa a fluir sem maiores dificuldades. “Trabalho com o Drupal desde meados de 2006, pela facilidade de customização e construção de módulos, instalação multisite out of the box, localização e tradução com gettext totalmente desacoplados do core, comunidade atuante e extensa documentação. Tudo isso permite criar websites complexos com muito menos esforço de programação”, conclui Piaz.

As vantagens de cada CMS

Uma das maiores vantagens do WordPress é, sem dúvida, a sua facilidade. Leo Germani considera que esse CMS possui simplicidade e eficiência em todos os sentidos. “Do ponto de vista do usuário, temos um painel administrativo simples, bonito e fácil de usar. Do ponto de vista do desenvolvedor, temos uma arquitetura de templates muito fácil de entender e explorar, uma arquitetura de plugins muito eficiente, e uma estrutura de banco de dados muito simples e poderosa. Além disso, possui uma comunidade imensa e um desenvolvimento consistente, que se mantém firme aos seus princípios: manter o core simples e enxuto, deixando qualquer coisa mais específica para plugins e templates“.

Nadir acredita que a atual expansão e acesso ao Joomla para os novos desenvolvedores pode ser uma grande vantagem sobre os outros CMS’s. “Outra vantagem está no novo gerenciamento de usuários e permissões, que foi a funcionalidade mais esperada para a nova versão, e que agora (versão 1.7) está bem madura e extensível. Nesta nova versão, o sistema multilíngue nativo permite criação e administração de conteúdo para diversos idiomas de forma muito fácil para o cliente”.

Outras vantagens do Joomla levantadas são relativas aos templates e extensões. “A facilidade na criação de templates possibilita que, através de poucas linhas de HTML, seja criado praticamente qualquer tipo de layout em pouco tempo. Outro ponto muito importante são as extensões, que melhoraram muito desde a nova versão, integrando-se bem às novas funcionalidades do core do Joomla, e que possuem uma variedade de funções dificilmente alcançada por outros CMS’s”, conclui Nadir.

Para Piaz, estão nos módulos as maiores vantagens do Drupal. “A quantidade de módulos disponíveis é absurdamente grande, além de o roadmap ser muito claro quanto aos releases. Isso nos dá uma visão de longo prazo (cerca de 3 anos) sobre o caminho a seguir”.

Ainda sobre os módulos, o quesito “compatibilidade” é um dos pontos fortes do Drupal. “Temos praticamente 100% de garantia de que todos os módulos são compatíveis com a versão instalada, ou seja, um módulo feito para a série 6.x irá rodar sem problemas no Drupal 6.1, 6.2 e assim por diante. Um outro ponto importante é que o Drupal sempre oferece um upgrade path a cada nova versão lançada (6.x para 7.x, por exemplo). Assim, a nova versão só é declarada stable quando o upgrade path é disponibilizado”, afirma Piaz.

Para quais projetos cada CMS é indicado?

Muita gente considera que o WordPress é um sistema indicado apenas para a produção de blogs. Leo Germani considera que não há dúvidas de que o WordPress seja realmente a melhor plataforma para essa finalidade, mas que além disso ele é uma ótima solução para sites institucionais ou portais de notícias. “Se você tem um site que é 90% editorial, mas que necessita de funcionalidades como área restrita ou importação de conteúdos externos, o WordPress também é ideal, pois a sua arquitetura de temas e plugin facilita muito para que possamos usá-lo como uma espécie de framework, podendo desenvolver muita coisa sobre ele”.

Quanto ao Joomla, Nadir acredita que ele seja ideal para projetos que vão desde sites de pequeno porte até grandes portais. “Existem projetos específicos para Intranet muito facilitados pelo novo ACL nesta nova versão, e já vimos também uma excelente integração do CMS com o Magento. A gama de possibilidades é muito grande, inclusive diversos sites do governo que requerem muita segurança e estabilidade, hoje utilizam o Joomla“.

Piaz também considera que o Drupal é uma ferramenta ideal para sites e aplicativos web de todos os tipos e tamanhos. “O código do Drupal é bem estruturado, e permite um alto grau de customização sem que seja preciso alterar seu núcleo. Sua robustez pode ser atestada pela quantidade de websites de alto tráfego rodando Drupal“.

Conclusão

Ambos os CMS’s possuem pontos fracos e fortes. Muitos profissionais procuram optar pela ferramenta mais fácil, como é o caso do WordPress, o que pode ser bom em determinado projetos, mas deixar a desejar em outros. Considerando também a questão financeira, profissionais que trabalham com ferramentas mais complexas como o Drupal acabam por ser mais raros, e por isso mais caros.

A verdade é que muitas vezes o uso de um CMS acaba sendo condicionado pela identificação e pelo conhecimento prévio que os desenvolvedores têm na ferramenta. Mas o ideal é que, mesmo que você tenha preferência por um determinado CMS, ainda assim procure conhecer as possibilidades de outros sistemas.

Acredite, saber escolher a ferramenta ideal para cada tipo de projeto pode fazer a diferença.

Fonte: Edu Agni/IMaster