// 9 Junho 2007
A dot vem acompanhando e se inspirando nos passos da 37signals desde sua fundação e não é para menos que a tecnologia da qual fazemos uso para a codificação de nossos sistemas web é o framework Ruby on Rails, por eles desenvolvido.
Uma vez que o Rails é diretamente derivado dos paradigmas que fazem do Ruby uma linguagem tão produtiva - a Linguagem Centrada no Programador (ou, Programmer-centered Language) - nada destoa ou parece sobrar na sinergia entre ambas as ferramentas.
Se o Ruby é uma linguagem poderosa e que oferece tanta flexibilidade quanto qualquer outro servidor de aplicação orientado a Web, o framework Rails (como todo framework) tem como objetivo a viabilização de um trabalho mais produtivo no que se refere as tarefas mais corriqueiras e que se colocam entre o programador e o término de seu trabalho. O diferencial, contudo, vai ficando evidente quando o programador começa a fazer uso efetivo do Ruby on Rails.
A estrutura sugerida pelo Rails garante que sua filosofia de desenvolvimento venha a reboque e se instale entre as más práticas e os vícios do programador, empurrando-as para o lado até caírem de cima da mesa direto dentro do cesto de lixo.
Boa parte da programação em Rails garante uma experiência de codificação mais agradável e produtiva, cortando caminhos que normalmente levariam a um trabalho sistemático e repetitivo e tirando da frente do programador tudo aquilo que normalmente é obstáculo.
A linguagem, que é totalmente orientada a objetos, foi desenvolvida por Yukihiro Matsumoto - carinhosamente apelidado de Matz pela comunidade de tecnologia - em meados de 1993 e teve seu lançamento público em 1995.
Com a evolução da velocidade dos processadores, o barateamento de memórias e outros componentes, as linguagens de programação vêm - desde a década de 90 - se concentrando menos em capacidade de otimização de código gerado e muito mais em fornecer ferramentas de alto nível que ofereçam para o programador um conjunto de blocos de construção que garantam maior velocidade de desenvolvimento, ainda que o código gerado não seja o mais eficiente.
O fenômeno parece um pouco com o que fez com que a Usabilidade se popularizasse. Passadas as décadas nas quais o usuário tinha pouco acesso a tecnologia, esta tinha mesmo de deixar de ser tão centradas nas necessidades do implementador e passar a se concentrar no usuário. Muito semelhante mesmo ao que vem acontecendo com as linguagens de programação, que vêm deixando de ser tão centradas no que a máquina precisa e passando a se concentrar em oferecer um conjunto mais agradável e produtivo para quem desenvolve o sistema.
Esta “Centralização no Humano” é uma característica muito clara no Ruby on Rails e fica ainda mais clara quando se percebe que Matz também se calcou em outros princípios tão em voga em Usabilidade, como o “Princípio das Poucas Surpresas” e o “Não Repita a si Mesmo” (ou, Principle of Least Surprises POLS e Don’t Repeat Yourself DRY).
A despeito de suas claras diferenças, se comparada com outras linguagens, o Ruby tende a não surpreender ou entrar em conflito com a intuição do programador, o que é um grande avanço sobretudo para quem tem o Ruby como sua primeira linguagem de programação.
Este princípio acaba emprestando ao programador um poder desmedido quando - ainda inexperiência na ferramenta - precisa deduzir ou intuir o que deve fazer sem olhar um manual de referência.
Tanto a linguagem quanto framework de Matz seguem uma linha mestra bastante nítida depois que você começa a fazer uso das ferramentas, a norma da convenção como sendo mais importante que a configuração, o que tenta tirar de uma vez por todas a noção de que quanto mais parametrizável um sistema melhor ele é.
Isso vai desde a regra de formação do nome de uma tabela no banco de dados, a partir de uma classe até as convenções que o próprio usuário pode criar dentro do Ruby on Rails.
No momento em que o Ruby on Rails monitora a criação de uma classe “Cliente” e automaticamente nomeia a tabela correspondente como “Clientes”, o estabelecimento de uma cultura de convenções começa a se fazer presente, liberando o programador de se preocupar em ser criativo com o que menos deveria demandar criatividade.
Model-View-Control
O Ruby on Rails tem ainda a característica de ser implementado usando o padrão arquitetural conhecido como Model-View-Control, que reduz o acoplamento entre o modelo de dados, interface de usuário e lógica de negócios, o que empresta flexibilidade na hora de efetuar manutenções corretivas ou evolutivas, uma vez que cada projeto de sistema acaba sendo um projeto de integração entre camadas autônomas.
Conforme a filosofia da ferramenta, o Ruby on Rails impõe gentilmente suas convenções para o bem do programador, que começa a pensar o MVC como sendo uma forma ágil de desenvolver projetos sem perder de vista onde está o que e sem ter de se descabelar quando o contratante resolve modificar os requisitos de um projeto.
Muito da inclinação do Ruby on Rails para ser uma ferramenta de desenvolvimento de alta produtividade reside nas características de estruturação do código. Mesmo um novo programador, entrando em um projeto, tem mais chances de entender aquele bando de código, graças em parte a princípio da convenção sem configuração. Além disso, como a lógica está toda compartimentada em um esquema MVC tanto o acesso ao que já foi feito quanto uma eventual alteração é bem mais fácil de ser implementada.
Conclusão
Estamos em um ecossistema tecnológico onde fábricas de software fazem de tudo para vender projetos de desenvolvimento em Java, usando bancos de dados cuja escalabilidade necessita de muito dinheiro e muito hardware, onde projetos menores são rotulados de projetos pouco importantes e pouco lucrativos.
Não precisa ser assim… Mesmo sistemas de maior porte podem ser levados a cabo, sem maiores problemas e com baixíssimo custo de propriedade, por ferramentas como Python com Turbo Gears ou Django, CakePhP e Ruby on Rails.
Cada ferramenta tem vantagens intrínsecas, que são ou não afins dos requisitos de projetos identificados para o projeto a ser desenvolvido. Nós da dot temos motivo para preferirmos desenvolver em Ruby on Rails: ele mostra o caminho sem se colocar no seu caminho; é elegante sem que nos faça tropeçar nesta elegância; e usa das boas práticas de forma pragmática e sem academicismos supérfluos.
O custo de processamento e memória dos servidores vêm caindo já há duas décadas além de todas as expectativas. Concentrar-se em linguagens e frameworks que exijam sucessivas otimizações no código e sintonia entre hardware e software, embora possa alcançar alguns micro-segundos a mais de velocidade do sistema, pode vir a se mostrar uma faca de dois gumes, aumentando o acoplamento entre camadas.
No fim, o que é mais importante?
A dot considera como um bom investimento a criação de um sistema que garanta saúde financeira para a contratante e velocidade na implantação dos entregáveis, mantendo baixo custo de propriedade e garantindo escalabilidade.
Nos parece que o homem/hora, de quem produz um sistema, onera mais, hoje, o custo total de um projeto, do que o gasto relativo em hardware para torná-lo mais rápido, caso necessário.
Diante desta realidade, nos escapa o motivo que faça uma corporação escolher um alto custo de desenvolvimento e um maior custo de propriedade, quando o caminho mais curto entre não-Ter e Ter um sistema é usar um framework como o Ruby on Rails no desenvolvimento de seus projetos.
Bruno Accioly
// 6 Fevereiro 2007
Quando os primeiros sistemas de informação chegaram às Empresas nas décadas passadas, as preocupações giravam em torno de automação de processos repetitivos e isolados. Mas as coisas mudaram assim como a época mudou.
O mercado de software reagiu a esta mudança, produzindo complexos sistemas corporativos com o objetivo de auxiliar o fabricante ou o gestor de uma empresa nas importantes fases do seu negócio, incluindo o desenvolvimento de produtos, compra de itens, manutenção de estoques, interação com os fornecedores, serviços a clientes e acompanhamento de ordens de produção.
Os Enterprise Resource Plannings ou ERPs são softwares multi-modulares projetados para serem independentes de plataforma, com interface GUI e arquitetura cliente/servidor que utiliza ou está integrado a uma base de dados relacional.
A branda utilização dos ERPs evidenciou um novo problema.Devido à própria natureza desse tipo de sistema, informações necessárias ficam restritas ao contexto do mesmo, indisponíveis a outros Sistemas.
Tal restrição tem como reflexo uma demanda feita por usuários e dirigentes de grandes corporações por uma ponte que possa unir os diversos sistemas espalhados pelos departamentos das empresas, ou seja, eles estão demandando a unificação das aplicações.
Em paralelo a esta nova demanda, o crescimento da Internet e as múltiplas soluções de TI existentes criaram uma nova necessidade, a criação de uma ponte entre os sistemas da Empresa e os novos recursos disponibilizados pela Internet.
Percebemos com isso que a integração de sistemas e dados é uma necessidade crescente.
EAI ou Enterprise Application Integration é o termo formal que contempla a integração de aplicações corporativas e um conjunto de ferramentas e tecnologias.
A integração de aplicações permite o compartilhamento de informações dentro da mesma organização ou com parceiros. Isto gera vantagem competitiva. A maior parte das organizações utiliza vários tipos e versões de sistemas desenvolvidos ao longo dos anos. Mainframes, servidores Unix, servidores NT e outros constituem a base tecnológica para a maioria das corporações. Estes sistemas possuem valor nas empresas, mas o seu valor agregado pode significar pouco se estes não puderem trocar dados com outros sistemas.
Como a dependência das corporações em relação à tecnologia tem crescido e se tornado mais complexa, a necessidade por um método de integração de aplicações em um único arsenal de processos de negócios tem sido a prioridade.
Fica claro, portanto, que uma Plataforma de Integração e um Modelo de Integração Definido é uma opção estratégica para qualquer Empresa que queira tirar o máximo proveito de seus investimentos em TI.
Ela procura combater visões monolíticas que vão contra a natureza distribuída, colaborativa e dinâmica das Empresas e impõe uma metodologia de colaboração de sistemas que mantém a agilidade e a capacidade de adaptação dos mesmos, atendendo as necessidades das Empresas no curto, médio e longo prazo.
É importante reconhecer que o EAI é um acrônimo novo que sintetiza e permite a implementação de um plano estratégico de integração de aplicações que é crítico para as empresas atualmente. As corporações que não integrarem suas aplicações não se tornarão empresas competitivas.
Angelo Braga
// 15 Janeiro 2007
Em um mar de prestadores de serviços aptos a desenvolver websites e aplicações web, o que diferencia o projeto gráfico de cada um deles é a sua filosofia no desenvolvimento destas soluções.
O design em ambiente Web, seja em um site ou em uma aplicação, serve para tornar a estada do usuário confortável e aconchegante, como uma sala de visitas onde há poltronas confortáveis e tudo ao alcance da mão.
Quando publicamos um site na web, temos que considerar que o usuário não vai enxerga-lo com os mesmos olhos que os seus criadores.
Um site que é bonito e agradável na tela de quem o concebeu pode não funcionar da mesma forma aos olhos do usuário, como uma embalagem de algum produto, que pode funcionar muito bem em anúncios de revista, ou em uma mesa de jantar, e não ser tão eficiente em uma prateleira de supermercado, quando exposta ao lado de outras centenas de produtos.
Usuários de Internet são ariscos, desconfiados, e um site tem que conseguir conquistar sua confiança, deve fazer com que se sinta seguro, e para isso, deve ter um design consistente, que passe a mensagem com clareza e objetividade.
O conceito do website pode ser maravilhoso e revolucionário, mas se seu design não for bem feito, o usuário não se sentirá confiante em explorar seu conteúdo. Como quando se compra um automóvel usado, onde se a lataria estiver em mal-estado, não importa que o motor esteja bom, pois ninguém vai chegar a testa-lo.
Nosso objetivo é de produzir soluções web completas, feitas sob medida para as demandas do cliente, e seu design deve servir para que as mensagens nele contidas sejam transmitidas de forma limpa e leve, e suas funcionalidades sejam simples e fáceis de usar.
Para se chegar a este resultado é necessária uma análise criteriosa para se descobrir o que o cliente realmente precisa, para que o design do site seja voltado para os seus objetivos, sem se perder pelo caminho com opções e informações desnecessárias.
As vezes a intenção de se oferecer um “a mais” para o usuário provoca um ruído na comunicação, atrapalhando o cumprimento do objetivo original.
Para que a sua solução web sirva da melhor forma aquilo que se propõe, a mensagem deve vir em primeiro lugar, seguindo a velha máxima “a forma segue a função”.
Um bom exemplo dessa filosofia é o avião. Os aviões são belíssimos, com suas formas aerodinamicas e arrojadas, e sua beleza vem exclusivamente da sua funcionalidade. Ninguém cogita que seria melhor se o toalete ficasse sobre a asa, ou que a turbina ficaria mais bonita dentro da cabine do piloto.
Com um site funciona da mesma forma. Nunca os elementos de identidade visual, ou a apresentação de animações em flash ou de funcionalidades discutível, devem ficar entre o usuário e a mensagem, por que esta é a razão primordial da existência da solução web.
Mairus Maichrovicz