Acabei de assistir ao primeiro webcast do Fábio Akita na Locawebcast, dando uma breve introdução a Ruby on Rails àqueles que estão interessados em ter uma primeira impressão ou mesmo tirar dúvidas iniciais. Achei que ficou bem legal.
Se você está interessando em conhecer Ruby on Rails, acho que vale a pena você também assistir.
Há situações em que precisamos de nested classes, seja para agrupar logicamente classes que apenas fazem sentido num determinado local, ou mesmo para melhorar o encapsulamento. A API Java padrão está repleta de bons exemplos. Mas é preciso algum cuidado para não fazer mal uso delas.
O que é uma nested class?
De maneira bem simples e direta, uma nested class é uma classe membro de outra classe – conhecida como enclosing class.
Java dispõe de dois tipos de nested classes:
1. Static Nested Classes, que são classes sintaticamente residentes em outra classe, mas que usa esta apenas como namespace.
Este tipo de nested class não tem acesso a membros de instância de sua enclosing class.
A sintax para instanciar este tipo de nested class é bem trivial:
StaticNestedClass obj = new EnclosingClass.StaticNestedClass();
2. Non-static Nested Classes ou Inner Classes, que além de residir sintaticamente em outra classe, também tem acesso a membros de instância desta – pois sua instância resite na instância de sua enclosing class.
Este tipo de nested class tem uma sintax bem exótica de instanciação, mas até que intuitiva, quando você entende o conceito de inner class. Veja:
InnerClass obj = objEnclosingClass.new InnerClass();
Por que intuitiva? Porque uma vez que uma instância de inner class está diretamente associada a uma instância de sua enclosing class – e só pode existir nela -, nada mais natural do que criar esta instância a partir da instância de sua enclosing class.
Por motivos óbvios, inner classes consomem mais tempo de processamento e memória que static nested classes.
Quando usar uma ou outra?
Sabendo quais são os tipos de nested classes possíveis no Java – estáticas e não estáticas – e suas naturezas, podemos ter uma idéia clara de quando usar uma ou outra.
Simples, não?
Este é o titulo de um artigo bem legal que o Rodrigo Yoshima postou em seu blog ontem. Se você se interessa por desenvolvimento Web, vale a pena conferir.
Aliás, falando em JBoss Seam, a Caelum lançou um super curso, rápido e objetivo, que você pode conferir o conteúdo programático aqui. Como sempre, qualidade indiscutível.
Esta foi a melhor notícia que recebi nos últimos tempos: Uma master conferência de Rails Brasuquíssima! OmG! Era tudo que eu queria!
Segundo o Akita:
Confirmei as presenças do próprio David Hansson (somente ele será via video online, ele estará na Europa nesse dia, os outros serão presenciais); o grande Chad Fowler ; os mantenedores do JRuby, Charles Nutter e Thomas Enebo ; diretamente da Holanda, da Phusion teremos Ninh Bui e Hongli Lai ; o mantenedor do RSpec, David Chelimsky ; o criador do Github, Chris Wanstrath ; ninguém menos que Dr. Nic Williams ; o escritor do livro The Rails Way, Obie Fernandez ; também Jay Fields, da ThoughtWorks.
E também muitos grandes Railers brasileiros como Manoel Lemos, da Brasigo ; Carlos Eduardo, da e-Genial ; Fabio Kung, nosso JRuby-man, da Caelum ; o grande Vinicius Teles da Improve it ; George Guimarães do Pagestacker.
A notícia completa está aqui.
[Novo endereço: leandrosilva.com.br.]
Não, não quero começar nenhum flame war em torno de JRuby e Groovy.
O que ocorre é que ontem um cara que tem um blog legal, o Diego, fez um comentário num de meus posts que me fez pensar a respeito… Até agora…
Na hora, sinceramente, não tive nada de muito substancial para responder, porque ainda não havia pensado a respeito. Mas tenho que confessar que isso ficou martelando a minha cabeça o tempo todo… Existe alguma vantagem de se usar Groovy invés de JRuby?
Bem, lendo e pensando a respeito, cheguei a algumas simples conclusões:
Se você tem familiaridade com Java e quer permanecer 100% no ambiente Java, sem a perspectiva de migrar, Groovy é a melhor opção pra você.
Porque a sintaxe de Groovy é muito parecida com a de Java; Groovy traz consigo uma porção de vantagens de uma linguagem OO moderna e dinâmica, como meta-programação, duck type, e closures; e você ainda pode programar usando objetos Java e Groovy numa mesma classe, de forma totalmente transparente (já que .groovy ao ser compilado se transforma em um .class qualquer).
Só que, mais uma vez: Não há qualquer possibilidade de se rodar código Groovy fora de ambiente Java, porque Groovy foi especificamente criada para ser uma “alternativa” à linguagem Java.
Se você quer que seu código seja portável para outras plataformas de runtime, tal como .Net, por exemplo, JRuby é o melhor pra você.
Acho que este é um dos fatores primordiais na escolha de JRuby invés de Groovy. Porque o fato da sintaxe de Groovy ser próxima à de Java, sinceramente, pra mim não quer dizer nada – aprender uma nova sintaxe não é coisa de outro mundo; e é até legal. Agora, portabilidade, isto sim faz a diferença – quando necessário, claro.
Você pode escrever, por exemplo, uma aplicação Ruby on Rails comum e coloca-la para rodar em um web container Java, sem muito esforço. Aliás, se você estiver usando o NetBeans, ele faz isso pra você em um ou dois cliques. E se num dado momento decidir rodar, sei lá, num Mongrel, tudo bem, você pode fazer isso sem problema algum. Isto é fantástico!
Se você quiser se manter 100% compatível com a MRI, isto é totalmente possível, porque JRuby é uma implementação completa de Ruby para a plataforma Java. E se você quiser aproveitar algum código escrito em Java, você também pode fazer isto – mas neste caso, claro, sacrificando a portabilidade.
Outro fator primordial que vejo é “comunidade”.
A comunidade JRuby tem crescido a cada dia – claro que por conta do próprio Ruby/Rails. E a indústria de software tem investido nisto, aja vista o ótimo suporte do NetBeans a Ruby/Rails; e a própria contratação de membros chaves do JRuby pela Sun há algum tempo.
E a comunidade Groovy? Bem, acho que Grails tem ajudado a levanta-la. Mas o seu barulho ainda não é dos maiores não. (Espero que isto mude.)
E o fim deste pensamento, qual é?
Use JRuby. Use Groovy. Use o que melhor atender aos seus próprios requisitos e aos de seu cliente. Porque não há apenas uma linguagem de programação, nem uma única solução pra tudo!
Atualmente estou propenso a usar tanto JRuby [on Rails] quanto Groovy [on Rails]. O que vai me fazer decidir entre um e outro serão os requisitos do momento – e a expectativa futura.
Então, seja JRuby ou Groovy, o que importa é desenvolver o software certo, no tempo certo, com a qualidade certa.
(Valeu Diego, por me fazer pensar um pouco sobre isto.)
Até a próxima!
Hoje de manhã postei algo rápido sobre Grails. Agora, vontando do almoço, acabei de ver um post do Brian Guan, um dos engenheiros do LinkedIn, sobre a sua experiência com Grails no LinkedIn.
Até a próxima!
[Novo endereço: leandrosilva.com.br.]
Sei que já não é mais tão novidade assim, mas só agora pude gastar um tempo pesquisando e fazendo uns testes. Do que estou falando? Hammm… O titulo dá uma idéia do assunto… Grails! Ou, para os mais eruditos, Groovy on Rails.
O que Grails, afinal?
Grails é a resposta da Plataforma Java ao desenvolvimento web ágil, dinâmico, sem toda aquela parafernália de 7.203 arquivos XML para configurar, 3.412 classes dos frameworks jAbc, J-XPTO e JSeila Oq+ para estender, e mais uns 1.300 arquivos JAR para “bibliotecar”.
Esta maravilha do mundo Java segue a filosofia de frameworks web full stack, tais como Ruby on Rails e Django. E segue fundamentalmente o conceito de Convention over Configuration, que pode ser resumido em uma simples frase: “É ótimo poder configurar, mas é péssimo ser obrigado a fazer isto”. Sendo assim, tudo tem um padrão de nome a seguir e um local bem definido para estar.
O que está por trás?
Grails não foi construido a partir do nada. Muito pelo contrário. Ele está fundamentado sobre frameworks de mercado mais que consagrados:
– Hibernate, sobre o qual esta o GORM (Grails ORM);
– Log4J, controle de log;
– Spring, injeção de dependência e MVC;
– Jetty, web container embutido;
– SiteMesh, templates de página web.
E tudo isto sendo “colado” e “manipudalo” pela linguagem Groovy, que para quem viveu os últimos anos em Marte, é uma linguagem orientada a objetos, fortemente tipada e dinâmica, desenvolvida para a Plataforma Java, como alternativa à própria linguagem Java.
Vale a pena usar Grails?
Para o seus projetos, só você mesmo pode responder. Mas o fato é que já existe muita coisa por ai rodando em cima de Grails. Um exemplo? O site da PepsiCo, por exemplo, que é um caso relatado no site do Grails.
Minha opinião? Se você quer uma alternativa dinâmica ao desenvolvimento web rápido para a Plataforma Java, dê uma olhada em Grails. Você não vai se arrepender.
Agora, se para você, desenvolvimento “confiável” e “bem feito” é sinônimo de centenas de milhares de XMLs, JARs, frameworks, e linguagem estaticamente tipada (porque o compilador te faz errar menos), esqueça Grails. (Mas… Uma dica: Sai dessa, meu chapa!!! rsrsrs)
Valeu!
Ontem participei do Google Developer Day 2008, evento patrocinado pelo Google. (Tá, tá, isto está óbvio, eu sei!) O evento aconteceu no WTC São Paulo, um lugar bem bonitão e tal; e tudo na faixa. Sim, di gratis.
Gostei bastante do evento, apesar dos assuntos terem sido tratados de maneira muito superficial, deu pra ter uma boa idéia sobre os produtos do Google for developers, que, sinceramente, eu não tinha.
Bom, vamos lá… Das apresentações que eu vi…
AppEngine – Permite que você coloque seu aplicativos Web para rodarem na infra-estrutura do Google. Ele é muito simples, você faz e testa seu aplicativo em sua máquina e, quando estuver pronto, apenas faz upload para o AppEngine e ele está no ar.
Uma das coisas que achei interessantes do AppEngine é que você usa o data store do Google, invés de um banco de dados relacional; e também pode usar o sistema de login do Google para a sua aplicação.
Ah! Um detalhe: Por enquanto, o AppEngine está disponível apenas para aplicações Python. Mas, segundo os apresentadores, outras linguagens estão vindo por ai – Java, Ruby e PHP foram as citadas.
Gears – É uma extesão de browser Web que permite você executar aplicações Web off-line. Ele armazena localmente um banco de dados relacional para seu aplicativo, que pode ser pesquisado e atualizado por JavaScript. E tudo isso de forma assíncrona!
Achei fantástico para aplicativos de uso em campo – como pesquisas e vendas, por exemplo.
OpenSocial – Define uma API comum para aplicativos sociais, permitindo total interoperabilidade entre estes. Com o crescimento dos aplicativos de redes sociais, não precisa nem dizer a importancia de algo assim, né?
Queria também ter visto as apresentações da API de Mapas e do Android, mas… Não se pode ter tudo sempre… ='(
O Akita também registrou a sua impressão sobre o evento – a gente se trombou por lá ontem e trocou umas idéias. Um ponto que ele citou e que concordo em genero, número e grau foi falta a Wi-Fi. Meu, precariedade total… Pelo amor de Deus! Levei meu note e quanto tentei conectar a uma rede, nada! Mas quanto a pessoas no note, eu vi bastante gente sim – principalmente com Mac.
(Ah! Tenho um protesto a fazer: Minha camiseta veio GG, eu pedi P!!!)
No geral, gostei muito do evento. Valeu muito a pena…
Às vezes me perguntam quando uma Sprint é considerada bem sucedida. Normalmente respondo com outra pergunta: Qual é o alvo da Sprint?
Notoriamente, todos os itens de um Sprint Backlog são relevantes. Porém, nem sempre todos estes são vitais para o dado momento do projeto – neste caso, é possível viver mais um timebox sem eles. Ter esta percepção te ajuda a descobrir o quando uma Sprint foi bem sucedida.
Scrum é viciado em ROI. Sendo assim, o sucesso da Sprint está intimamente ligado ao ROI do cliente. Se o que o time conseguiu produzir e entregar com total qualidade ao final da Sprint é exatamente o que o cliente precisava para começar (ou continuar) a ter lucro com seu negócio, ótimo, a Sprint foi bem sucedida!
Agora, se ao final da Sprint o cliente não tem nada de relevante e que trague algum valor ao seu negócio, a Sprint foi um fracasso. Talvez, não um fracasso total; mas ainda assim, um fracasso.
Quer sucesso na sua Sprint? Dê lucro ao seu cliente… É o que ele mais gosta…
Até a próxima!
Sábado passado participei do Agile Requirements Workshop com o Alexandre Magno e o Adail Retamal.
O nível do workshop foi realmente excelente. Muito conteúdo, muita prática, muita discussão, literalmente, muita formação para qualquer profissional ágil. User stories, Features, Mapas Mentais, Engenharia de Requisitos, e outros assuntos foram tratados com muita propriedade pelos dois. =)
Um momento que achei impressionante foi quando o Alexandre, ensinando o valor da comunicação, disparou: “Não combinei nada com o Adail, mas, Adail, fica tranquilo, eu assumo o prejuizo, tá? Quem quiser ir embora ‘só com a apostila’, eu devolvo 90% do valor pago pelo workshop. Você pega a apostila, vai embora, e eu te devolvo 90% agora mesmo. Quem quer?” O que vocês acham que aconteceu? Ninguém nem piscou! Porque o conteúdo que esses caras tem para passar é muito, muito, além do que qualquer apostila. Comunicação é tudo – e, acredite, esses caras sabem bem o que significa isso.
Enfim, ótimo evento, quem não foi perdeu. Mas, como o Alexandre mesmo anunciou, mais edições estão por vir!
Não fique de fora!
CØdeZØne! 