LazyWeb: Escolhendo um framework

November 11th, 2009 § 7 comments § permalink

Um amigo de Belo Horizonte me consultou esses dias sobre uma questão fundamental para a aplicação que ele está planejando começar a escrever nos próximos dias: framework de programação usar (e por extensão, qual linguagem)?

Como minha experiência nos últimos tempos tem sido confessadamente restrita a Rails e alguns experimentos em outros, resolvi apelar para a caridade dos meus leitores. Qual framework você usaria para seu próximo projeto?

Esse meu amigo não tem problemas com linguagens de programação em si. De fato, a não ser que seja algo tão esotérico quando Haskell ou Erlang, ele é capaz de se familiarizar com uma linguagem ou framework em alguns dias.

Obviamente, não posso dar muitos detalhes sobre a aplicação, mas dá para dizer que o objetivo é escalar gradualmente. Ela não precisar começar escalando para o mundo inteiro, mas um caminho seria bom. Um outro detalhe nesse aspecto é que a aplicação é comparativamente particionada: um usuário terá acesso a alguns itens e compartilhará esse acesso com algumas dezenas ou centenas de pessoas. Esses itens possuem moldes variáveis e seriam bom ter flexibilidade na criação do mesmos.

Finalmente, hospedagem é uma questão também. Não necessariamente preço, mas facilidade. Linode é uma opção mas preferivelmente algo que possa ser colocado em alguma coisa pequena e ir escalando conforme a necessidade, no estilo do Heroku (o que limitaria a Rails, claro). Python parece uma boa opção, mas ele precisa de evidências.

E aí, alguém anima a ajudar um pobre compadre em armas? :D

Sinergia Arquitetural

October 27th, 2009 § 3 comments § permalink

syn•er•gy |ˈsinərjē|
noun
the interaction or cooperation of two or more organizations, substances, or other agents to produce a combined effect greater than the sum of their separate effects

— Apple’s Mac OS X Dictionary

A definição acima não é muito padrão mas expressa bem o conceito em que a palavra é entendida hoje em dia. Sinergia vem do grego sunergos, que literalmente significa trabalhar em conjunto.

Em inglês, a palavra data de cerca de 1650, e tinha um sentido bastante medicinal, podendo indicar tanto a ação cooperativa entre dois ou mais músculos do corpo para a realização de um esforço ou a ação combinada de medicamentos ou drogas para criar um estímulo maior no paciente.

O Wikitionary define sinergia também com o “comportamento de um sistema que não pode ser previsto pelo comportamento de suas partes”, o que é uma definição bastante interessante e diversa do sentido necessariamente positivo que a palavra ganhou nas últimas décadas.

De fato, sinergia hoje em dia é considerada uma buzzword, uma palavra sem significado para indicar a vontade de que algum esforço conjunto qualquer resulte em mais lucro, para qualquer valor de lucro, do que um esforço individual das partes envolvidas–a palavra-chave na mudança de definição aqui sendo “vontade” versus o efeito real.

No meu trabalho com arquitetura de software, entretanto, sinergia é algo que faz sentido naturalmente no desenho de sistemas. De fato, sistemas de sistemas tender a exibir isso de uma forma quase que óbvio já que não é possível desenhar os mesmos de outra forma. Não é sem motivo que a página na Wikipedia que explica o conceito usa sinergismo, uma variação de sinergia para explicar a motivação primária desse objetivo. O Unix é um exemplo bem óbvio disso e algumas pessoas chegam a se referir a isso como o Tao do Unix pelo fato de que as peças se encaixam com tal perfeição que é impossível pensar em trabalhar de outra forma.

Sistemas de sistemas fazem sentido em praticamente qualquer situação em que a complexidade das partes individuais torne o sistema final potencialmente (e exponencialmente) difícil de ser descrito de maneira consistente.

Essa é uma das razões, inclusive, pela qual as pessoas se decepcionam tanto com frameworks como Rails ou Django quando precisam de expandir aplicações já existentes para níveis maiores de complementaridade ou escalabilidade. Frameworks fechados simplesmente não exibem esse tipo de sinergia integral necessária para garantir que os princípios aplicáveis em aplicações menores sejam os mesmos de aplicações maiores. O resultado é que, essencialmente, todos esses princípios são violados à medida que o sistema precisa crescer resultando em um entendimento completamente diferente do que se desejava a princípio. Funciona, mas sem elegância ou beleza.

A despeito do significado amortecido, uma reflexão cuidadosa sobre sinergia e sua aplicabilidade ao desenho de sistemas faria bem a qualquer desenvolvedor ou arquiteto de sistemas. Sapir-Whorf sendo fraca ou não, um entendimento real é impossível se o vocabulário natural é desprezado.

Eu não…

May 8th, 2008 § 22 comments § permalink

  • Eu não escolheria Rails para escrever uma aplicação Web que consistisse, em sua maior parte, em processamento fora da interface com o usuário, ou cujo maior ponto fosse uma API;

  • Eu não escolheria Django para uma aplicação cujo domínio fosse extremamente complexo, com modelos dinâmicos, tabelas construídas on-the-fly, e funcionalidades similares;

  • Eu não escolheria Seaside para uma aplicação que consistisse em recursos individualizados, independentes e cujo referenciamento fosse essencial;

  • Eu não escolheria ASP.NET para um site inerentemente visual, cuja interface externa com o usuário fosse a parte essencial da aplicação;

  • Eu não escolheria Castle Monorail para aplicações de pequeno ou médio porte em que manutenção fosse mais importante do que o desenvolvimento de nova funcionalidade;

  • Eu não escolheria Ruby para aplicações de rede onde o potencial de instabilidade fosse maior do que o normal;

  • Eu não escolheria Python para um ORM ultra-adaptável;

  • Eu não escolheria ASP clássico ou PHP puro para coisa nenhuma.

Django People

January 22nd, 2008 § 0 comments § permalink

Simon Willison acaba de lançar um site para identificar desenvolvedores trabalhando como Django. Apropriadamente chamado de Django People, o site permite que você cadastre uma mini-biografia e uma série de outras informações pessoais que outros desenvolvedores logados podem acessar.

É bem similar ao Working with Rails mas com o foco em localização para juntar pessoas interessadas que estejam próximas. Boa iniciativa.

O efeito ASP

January 16th, 2008 § 13 comments § permalink

Muito do meu desenvolvimento diário, para minha infelicidade, ainda é feito em aplicações legadas em ASP e PHP. Desnecessário dizer, não é um trabalho muito agradável mesmo quando a aplicação foi construída com um cuidado maior do que simplesmente gerar arquivos e mais arquivos em uma tentativa de trazer ordem ao caos.

Aplicações ASP são capazes de infligir terror ao mais corajoso desenvolvedor Web. A mistura de lógica e apresentação vem sendo usada há vários anos para exemplificar o que há de pior da área e não sem razão. Atualmente, para falar a verdade, é muito raro que eu aceite um contrato de manutenção ASP se a aplicação não atende certas práticas que eu estabeleci como referência. O trabalho simplesmente não vale a pena, por melhor que seja o pagamento.

Nos últimos anos, é claro, eu tenho tentado me dedicar mais e evangelizar, sempre que possível, novos modelos e frameworks de desenvolvimento. Nem sempre a empresa aceita mudar para algo que ela considera esotérico e fora da realidade do mercado, mas algumas vezes a vontade de reduzir o time-to-market vence o medo e algo de interessante acontece.

Estamos hoje há mais de três anos do início da evolução do desenvolvimento Web que frameworks como Rails e Django começaram e acho que estamos começando a ver os reais efeitos que o desenvolvimento nestes novos paradigmas está tendo. O uso de MVC está se tornando uma constante e mesmo a questão de desenvolvimento guiado por testes está se firmando como algo mais comum em locais onde usualmente se via um processo menos elaborado.

Nos últimos tempos eu tenho recebido alguns propostas para completar ou manter aplicações Rails já existentes e estou surpreso com a baixa qualidade do que estou vendo. De fato, no que tange a falta de cuidado com o código e a mistura de lógica e apresentação, eu só não compararia o nível dessas aplicações ao que usualmente vejo com ASP porque pelo menos a parte de convenção versus configuração segura os abusos mais berrantes.

Eu ainda não tenho dados suficientes para dizer a mesma coisa de Django, mas é possível notar um pouco disso nas aplicações e projetos espalhados pela Web que pouco cuidam em promover técnicas como TDD ou mesmo um reuso mais efetivo de código. E quanto promovem, o que se vê são usos pouco significativos dessas técnicas como a eterna persistência em testar o funcionamento de camadas ORM. Isso é válido também para quase todos outros framework Web, independentemente de linguagem e estruturação.

Parte do motivo desse uso incorreto é explicada pela soma de dois fatores distintos: o fato de que poucos programadores são realmente capazes de entender o que OOP significa e o fato de que Rails, Django e todos esses outros frameworks promovem uma versão mais light, por assim dizer, de OOP que efetivamente isola muitos programadores de um desenho mais efetivo do domínio do problema.

Eu fico pensando no mercado daqui a cinco anos, quando o mesmo estiver inundado de aplicações nesses novos frameworks. Provavelmente, não haverá diferença nenhuma em termos de manutenção para o que vemos hoje. Aplicações realmente bem feitas permanecerão confinadas a um pequeno conjunto dentro da indústria. Um efeito ASP em ação.

A revolução ainda espera e Frederick Brooks continua mais válido do que nunca. Rails e Django podem ser indolores no começo, mas eu tenho pena dos programadores que terão que manter o que está sendo criado hoje.

Rails ou Django? Rails e Django!

December 7th, 2007 § 6 comments § permalink

Os dois frameworks irmãos, Django e Rails, receberam recentemente sua dose de atenção da revista Info. O mais interessante é que, nos dois casos, o Python e o Ruby foram considerados os pontos fracos dos seus respectivos frameworks.

Embora eu não tenha lido as matérias na íntegra, eu imagino que os autores das mesmas tenham pensando em ter que aprender uma linguagem nova como o ponto fraco e não nas linguagens em si como algum problema. Novamente, não posso dizer se os autores são programadores mas, se não forem, também é possível entender porque chegaram a uma conclusão assim.

Negativismo à parte, eu acho interessante a atenção que novas linguagens estão recebendo, principalmente as dinâmicas. O fato de que as linguagens são consideradas um problema é mais uma reflexão do mercado do que da realidade de uso das mesmas. Qualquer programador que valha metade do seu cargo sabe que aprender novas linguagens é essencial para sua permanência no mercado, mesmo que ele vá usar uma delas na maioria do tempo.

A proximidade das matérias me leva a crer que a consciência do Rails, Ruby, Django e Python está crescendo como nunca. Quando matérias desse tipo se tornam mainstream, não demora muito para que se filtrem também para o topo da escala decisória.

O que fica, pelo menos como eu considero a questão, é uma lição para programadores Web. Aprender somente Ruby ou somente Django pode ser menos trabalhoso mas aprender os dois provavelmente faz bem não só para sua carreira em termos de crescimento técnico como também em termos de mercado.

Where Am I?

You are currently browsing the Django category at Superfície Reflexiva.