rvf, software e mitos

Archive for novembro 2008

E se você fosse cego, ajudaria? Sensacional post do Aurélio. Você, que acha que sua vida é ruim, difícil, sem oportunidades, etc. deveria ler.

Anúncios

Lembram daquele papo sobre frameworks web? Então, iniciamos esta semana lá na empresa algumas provas de conceito em cima de algumas tecnologias para definir o que utilizar num próximo projeto, como esperamos algo produtivo, ágil e com uma curva de aprendizado pequena, decidi dar uma chance ao Grails e estudá-lo. Gostei do que vi, como o próprio slogan do projeto diz “the search is over” (a procura acabou), o projeto é sensacional, não foi a toa que a SpringSource o comprou.

Grails (i.e. Groovy on Rails), uni uma linguagem dinâmica e muito poderosa chamada Groovy que roda diretamente em cima da JVM, com um back-end poderoso que conta com consagrados frameworks como spring, hibernate, acegi, sitemesh… e um conjunto de scripts bem definidos para automatizar tarefas, até então, demoradas e complicadas -comparadas a rotina dos frameworks da moda-. Grails faz uso de conceitos como convention over configuration (CoC) e Dont Repeat Yourself (DRY), que significa que se você seguir o padrão do framework você não vai precisar configurar nada e que você não precisa dizer ao framework o óbvio, respectivamente. Depois que entender isso, você vai se perguntar “por que nossos trilhões de frameworks não pensaram nisso antes?”

Sim, o Grails se baseia na idéia do Ruby on Rails (RoR), nada demais, oras. Temos aí duas ótimas ferramentas para desenvolver software de maneira ágil.

Aguardem por novidades deste bixinho por aqui. 😉

Tags:

Quando conheci Java, no inicio de 2007 durante meu primeiro estágio com desenvolvimento de software, morava ainda em Foz do Iguaçu, foi aquele trilhão de novas informações de uma vez só na cabeça, onde eu mal sabia por onde começar. Consegui aprender a usar alguns frameworks, mas isso sempre me deixou bem impaciente, principalmente pelo motivo de que, quando eu aprendia um novo framework, ou ele mudava de versão com uma nova nada compatível com as anteriores, ou alguém ia lá e criava um novo que entrava na moda, e aí ficava difícil acompanhar. Confesso que até hoje isso me irrita.

A nova era da Internet, conhecida como Web 2.0 começa a colocar para escanteio frameworks baseados em ações, citando alguns conhecidos como: Struts, WebWork, Spring MVC, Mentawai, e mais uns 208420984092… também sobrou para os baseados em componentes e eventos, como: Jsf, Seam, Shale, etc. mas estes ainda vão ter um tempo a mais de mercado, ou conseguirão uma evolução se conseguirem se adaptar.

O problema não é a idéia que os mesmos tentam passar, nada contra action-based x component-based, cada proposta tem seu espaço, o que acontece é uma evolução natural, onde o que vale mesmo é a produtividade em conjunto com a simplicidade. Vejamos: para criar um novo sistema baseado em algum destes citados, você era obrigado a fazer uma quantidade enorme de configuração, baseado numa curva de aprendizado bem grande. Saber Java não faria a menor diferença.

Neste novo ideal surgem propostas como a volta do velho e bom Java para se fazer o que precisa, não importanto o seu ambiente, se é desktop ou web. Tecnologias interessantes começam a tomar destaque perante a comunidade de desenvolvedores, em especial Google Web Toolkit e o Wicket, da Apache, onde o desenvolvimento se torna algo centralizado a linguagem, sem se ater muito a outras coisas, algo bem parecido com o puro Swing. Também aparecem soluções para os nossos amigos lá de cima, onde o esquecido Java Script toma a frente e vira solução para a camada de apresentação como resposta a tecnologias baseadas em stream/flash, contando com uma nova (ou não tão nova assim) legião de membros, como o próprio GWT (que no final das contas, gera JS), ExtJS, JQuery, Prototype, Dojo, YUI, etc. O que esta parte significa? Uma camada bem definida não atada a tecnologia Java necessariamente e compartilhada por comunidades de outras plataformas. O que isso gera? A gama de conhecimento se torna homogênea, e todo mundo sai ganhando.

Recebi alguns questionamentos a respeito do post sobre ‘não levar UML tão a sério’, de pessoas que, provavelmente entenderam errado. Fique claro que, eu não quis dizer para simplesmente largar qualquer prática aplicável e sair codificando igual um lunático, não. A questão é muito simples, e nem deveria ser explicada novamente, mas lá vamos nós novamente:

  • Não leve UML tão a sério, quando ela não foi levada a sério de inicio, ou seja, quando o seu código não tem nada ha ver com o seu modelo, neste caso, para que continuar?
  • UML vai te ajudar –e muito- para uma visualização panorâmica do seu negócio, onde pessoas como seu chefe, empregada, filhos, etc. possam entender sem precisar olhar código.
  • UML vai te ajudar a planejar melhor o domínio da sua aplicação, mas isso não é nada obrigatório, não esqueça.

Se eu faço modelos UML nas minhas experiências? Sim, às vezes. Quando eu acho que o framework pode me ajudar em algo, qual o motivo para não utilizar? O ideal é você pensar o seguinte (e não cabe apenas a utilização de UML): Use as coisas quando elas possam ajudar e não atrasar/atrapalhar a vida. Você vai saber quando.

A propósito, como estou estudando -quando me sobra tempo- para a prova SCJA, acabei lendo um livrinho muito interessante sobre UML, grátis e em PDF: http://grace.evergreen.edu/csf/java08w/Uml.pdf

Enjoy!

Tags: ,

Conversando com um conhecido estes dias, o mesmo disse que está passando por poucas e boas por causa de um projeto que, quando aparecem manutenções, são de cair os cabelos. Claro, o software deve ter sido criado por um projetista não muito interessante, no meio disso, algo mais sério me chamou a atenção: O sistema utiliza o Framework Struts 1 customizado por algum desenvolvedor que passou por ali. Ainda não entendeu? Isso significa que o sistema está preso a uma versão especifica de um framework (que diga-se de passagem, ninguém mais merece Struts, ainda mais, customizado!), onde qualquer atualização do mesmo acarretaria em verificar os pontos alterados e tentar atualizar, ou seja, fora de cogitação! E então, a ferramenta entra em processo de end of life.

Você não deve customizar um framework (ha não ser que sua intenção seja enviar patches ao projeto), eu sei que as vezes parece ser tentador, mas evite. Considerando que esteja trabalhando com uma linguagem OO, a melhor opção seria estender funcionalidades e especializar aquelas classes que você esta pensando seriamente em estrupar customizar hardcoded like.



  • Nenhum
  • Adolfo: Muito bom este post. Acho que tudo isso pode ser resumido em uma única palavra: humildade (isso não significa não defender seu ponto de vista).
  • Adolfo: Olá Robson, Alguns modelos até consegui identificar em alguns projetos que já trabalhei... Com algumas coisas eu concordo e outras não... Q
  • milah: Eu tenho um Amazon L71. Até 2 meses atrás não tive problemas com ele. Já troquei a placa de lan dele, por uma que capta melhor wi-fi. Só que ago