É, e depois da SpringSource (empresa que controla e desenvolve o Spring Framework) comprar a G2One , que é a empresa que “desenvolve” (este sim, entre aspas) o Grails, já vemos uma boa, e acima de tudo, promissora movimentação: http://blog.springsource.com/2008/12/11/spring-integration-in-grails-part-1/

[]s,

Lucas

Quando temos um campo select em um form html usando Ruby on Rails, o procedimento ‘default’ (para selects não dinâmicos), seria algo assim….

<%= f.select :campo, {}, @valores %>

Onde @valores foi definido por um hash, por exemplo:

@valores = {'Lucas' =>'123', 'Xpto' => '111', 'Sbrobow' => '444'}

Porém, como (agora fazendo um paralelo com Java), isso refletiria algo semelhante a um HashMap e não a um LinkedHashMap, fazendo com que a ordem das entradas não seja garantida, para garantir isto, a maneira mais fácil é usar um Array de arrays, desta maneira:

@valores = [['Lucas', '123'], ['Xpto','111'], ['Sbrobow','444']]

Go!

[]s,

Lucas

O Google Reader (google.com/reader) é um leitor de RSS bem bacana do Google, uso ele faz um tempinho já, acho que desde o ano passado, quando o Paulo (Bahiano) me mostrou aqui no trabalho. Nem muito costume de RSS eu tinha naquela época, e de lá pra cá, passo uma boa parte do dia fazendo isso

Bom, um recurso que eu vi que tem, é a possiblidade de você (além de categorizar as entradas, marcar com estrela e etc, como no GMail), é a possibilidade de você “Compartilhar” um post alheio. Isso é fácil de se fazer, basta clicar no “Compartilhar” abaixo de cada entrada do blog.

Você também tem a opção de compartilhar uma entrada, ainda escrevendo alguma informação pequena e objetiva sobre o assunto, por exemplo: “Esse cara tá viajando.”, ou então, “Realmente, Java é muito legal para se fazer isto”, e etc. Com isso, o google gera automaticamente uma página para você, com os feeds que você marcou como “Compartilhados”.

Bom, seria mais ou menos como construir um blog muito rapidamente, sem se preocupar com criar, hospedar, arrumar o template e além de tudo, sem se preocupar com “Escrever” realmente né, uma vez que você irá apenas usar as entradas alheias. :]

Sinceramente, não tinha achado muita utilidade para isso, quando brinquei com a funcionalidade no começo, porém agora (em algum momento no tempo entre a última vez que entrei, ontem) eles adicionaram um recurso que senti falta no começo, que é gerar um RSS através das suas entradas compartilhadas.

(Respire fundo para ler este parágrafo) Isso mesmo,  você seleciona quais são as entradas interessantes, e o Google Reader automaticamente gera um RSS para você repassar para as pessoas que estão interessadas em ler no Google Reader, o que você achou interessante no seu Google Reader (se você tem ela nos seus contatos, você já ve diretamente).

Tá, mas se eu já tenho um blog, e se uma coisa é realmente muito interessante para ler, a pessoa acessando meu blog verá algo a respeito disso, certo? Certo sim! 

Então o que fazer com essa tal funcionalidade? Sei lá ué, faça o que quiser… Eu coloquei um widget no meu Blog fazendo ele ler o RSS das minhas entradas compartilhadas, ou seja, nesse menu aí do lado, tem um bloco chamado “Textos interessantes”, estes textos são entradas que eu compartilhei no meu Google Reader e apareceram aí sem dor nem trabalho nenhum! :]

Gostei muito da combinação! Não se desesperem se começar a aparecer posts de vocês no meu blog, quer dizer, não só que eu leio seu blog, mas sim, que eu gosto de seus textos.

[]s,

Lucas

Incrível, já começaram ontem a vender os ingressos para o GP de Fórmula 1 do Brasil de 2008. A data será a mesma já divulgada anteriormente mesmo, 16, 17 e 18 de outubro… E segundo a ‘imprensa’, a venda só foi adiada segundo pedido dos torcedores.

Convenhamos, o que essa última corrida do ano não fez né… Que bom, mas uma pena só que Interlagos não vai mais ser a última corrida do ano, já que ano que vem, teremos a China fechando a temporada 2009.

Bom, vamos lá, esse é o mapa de lugares do circuito:
 

 

Mapa de lugares - Interlagos 2009

 

E agora, os valores, doces e salgados…

 

 

 

Como sempre, o GP é infelizmente pra quem tem essa grana disponível para gastar… Não adianta, o setor mais barato, que “presta” para valera a pena ir ver lá e não ver em casa, é o M, fora isso, nada mais…

Ainda tou vendo se vai valer a pena ou vou ficar em casa… Ahhhh, qualquer problema, ainda parcelam em 9 vezes (para, é claro, as parcelas acabarem antes do GP), através do site oficial: http://www.gpbrasil.com.br .

 

E ai, vamos?

 

[]s,

Lucas

 

Apenas uma recomendação de um post que li na InfoQ: Challenges in Adopting Scrum.

Um texto bem legal, que mostra que SCRUM, apesar de bem legal e interessante, não vai salvar o mundo nem fazer os terroristas do oriente médio virarem gente boa. Mostra que não adianta aplicar Scrum por aplicar, mas sim que é necessário antes de tudo, um bom entendimento do seu cenário/problema/contexto.

Segue um dos problemas encontrados, que eu achei mais interessate:

Using Scrum as a fix, without knowing the problem – A new methodology should not be adopted because of the hype surrounding it. An organization should try to define their expectations and measurement criteria. Answering questions like ‘Where does the current process hurt?’, ‘What caused the hurting?’, and ‘What would we be able to do when the hurting has stopped?’ would help define objective expectations and measurement criteria.

Bem legal, vale a leitura sim!

Até,

Uma coisa que pensava bastante durante o curso que fiz de CSM, foi na agilidade que teríamos se implantássemos SCRUM onde trabalho.

Sempre consegui visualizar um projeto usando SCRUM totalmente auto-contido, algo como minha própria empresa, ou um projeto com poucas pessoas e foco centralizado, e pensando assim, imaginava como lidar com cerca de 200 pessoas distribuídas em projetos de poucas pessoas, porém projetos muito dependentes entre si, o que na visão inicial que tive de SCRUM, cairia por terra.

Foi aí que no curso o instrutor veio com a história de Scrum of Scrums, que como o nome mesmo diz, seria colocar para funcionar reuniões com pessoas de cada equipe scrum, fazendo uma equipe “acima” daquela outra. E bem nessa questão “acima” foi que eu comecei a pensar e percebi que estaríamos instaurando mais uma hierarquia (hierarquia esta que o Scrum deveria ajudar a inibir, na minha opinião). Mas ok, tudo pelo bem da agilidade.

Hoje, lendo um blog, comecei a ver que se realmente nós tivessemos implantado SCRUM lá, teríamos na reunião de “chefes”, ou seja, na Scrum of Scrums, teríamos realmente uma bagunça, (mesmo segurando a caneta piloto vermelha) visto a quantidade de pessoas que teriam na reunião. Este blog falava justamente da ineficiência de escalar scrum usando o scrum of scrums, afinal, uma vez que você tem muitas pessoas envolvidas, vai começar a precisar de Scrum of Scrum of Scrums, ou como ele colocou, S3, e como ele mesmo disse no artigo, você estaria começando a beirar a imbecilidade. 

Neste artigo Will Read coloca uma possibilidade de comunicação inter-grupos para resolver o problema da ineficiência do SoSoS, de acordo com ele,  desta maneira acaba-se com a repetitividade de informações e de um modo mais objetivo e rápido os grupos todos se comunicam e a informação flui…

 

Com certeza vale a pena dar uma lida no blog, acesse aqui.

Alguém tem alguma experiência com este nível de projetos e equipes em SCRUM? 

 

Meu momento frustação… Já fiz o curso, leio bastante sobre scrum e metodologias ágeis, mas infelizmente não coloco em prática… Eu ainda vou trabalhar em um projeto com SCRUM um dia, alguém me ajuda? 

 

 

Bom, como já disse, não gosto muito de chamar de “legadas” as aplicações que serão ativadas pelo BUS em um arquitetura SOA. A não ser é claro, que realmente façam jus a este nome. O que não gosto é de construir uma nova aplicação que conterá realmente a lógica de negócio do zero, e ainda chamá-la de legada, e olha que isso é mais comum do que pensamos.

Enfim, a nossa grande aplicação que será ativada pelo BUS via JMS, seguindo o desenho deste post se chamará “ReverseIt”, e conterá uma lógica nuclear de inverter a string que receberá como parâmetro. Não vou entrar em detalhes dos detalhes da criação do projeto na IDE, mas basicamente será um “Web Service Project” com o facet do XMLBeans Builder Library, para que ele converta nosso XSD em objetos java facilmente. A aplicação está rodando em um domínio Weblogic Server puro, em localhost:30000.

Vamos definir um schema XSD (dentro da pasta schemas) que contenha a operação de request e de response para a operação. Obviamente como temos um parâmetro string para entrada e outro para saída, ficaria algo bem trivial, basicamente o escrito abaixo:

<?xml version="1.0" encoding="UTF-8"?>
<schema xmlns="http://www.w3.org/2001/XMLSchema" 
        targetNamespace="http://blog.lucastex.com/reverseit" 
        xmlns:revit="http://blog.lucastex.com/reverseit" 
        elementFormDefault="qualified">

    <element name="reverseItRequest" type="revit:ReverseItRequest"></element>
    <element name="reverseItResponse" type="revit:ReverseItResponse"></element>

    (...) definição e descrição dos tipos (...)

</schema>

Agora vamos:

• Criar um web service como de costume
• Configurar entrada do serviço para ReverseItRequest
• Configurar saída do serviço para ReverItResponse
• Escrever a lógica para inversão da palavra
   

public ReverseItResponseDocument reverseIt(ReverseItRequestDocument request) {
    
    (...) 1- Pegar input do request
    (...) 2- Inverter a string
    (...) 3- Retornar no response 

}

Legal, mas até aí temos o nosso Web Service tão padrão quanto todos que já fizemos, vamos agora para as anotações, que vão garantir que o serviço trabalhe de forma assíncrona. Bom, como ele funcionará via JMS, uma coisa que temos que fazer é criar uma fila JMS onde serão colocadas as mensagens que este serviço irá consumir, e também uma fila de resposta, para que ele coloque as mensagens de response. Não podemos esquecer também da ConnectionFactory o nosso serviço. Estes foram os nomes que eu dei:

• Fila de Request: reversit.jms.requestQueue
• Fila de Response: reverseit.jms.responseQueue
• ConnectionFactory: reversit.jms.connectionFactory

@WLJmsTransport(serviceUri="ReverseIt",
		portName="ReverseItPort",
		connectionFactory="reverseit.jms.connectionFactory", 
		queue="reverseit.jms.requestQueue", 
		contextPath = "ReverseIt")

Semana passada eu havia visto este post, acabou passando em branco. Em função até do comentário do Marcos no post de Grails x Rails ter citado, acho que vale a pena deixar o link fácil pra quem precise:

Parte 1: http://thevirtualmachine.wordpress.com/2008/11/13/reducing-grails-deployment-size-by-a-lot/
Parte 2: http://thevirtualmachine.wordpress.com/2008/12/04/reducing-grails-deployment-size-part-2/

 

[]s,

Lucas

Sim, o meu blog as vezes dá problema e fica fora do ar, não é minha culpa, basta dar um F5 e tentar novamente.

[]s,

Lucas

 

Bom, um dos cenários que eu mais tenho visto ultimamente em alguns dos lugares onde tenho passado, é quando o cliente quer disponibilizar um serviço para algum terceiro, porém faz questão (e está certo), que a partir do ponto de entrada do terceiro para o barramento de serviços do cliente esta requisição seja processada de forma totalmente assíncrona. 

Com isso, o cliente (que está processando a requisição) ganha em poder de processamento, e o terceiro (que está gerando a requisição) não percebe o que se passa “under the hood” (eu realmente gosto desta expressão), sendo para ele indiferente o que acontece durante o processamento.

Basicamente, este contexto é uma implementação de um Web-Service que utiliza como meio de transporte uma Fila JMS, ao invés do protocolo HTTP que é usado de costume.

Então, vou colocar aqui um exemplo de como fazer isso usando o Aqualogic Service Bus da Oracle (já era um produto da BEA).

Serão 3 pequenas aplicações para isto.

 

• Aplicação Legacy (é um costume horrível chamar estas aplicações de “legadas” visto que em grande parte dos processos de implementação SOA nas empresas, elas são reconcebidas, ou sofrem pelo menos, muitas alterações): É a aplicação que efetivamente possui a lógica de negócio, receberá a requisição do cliente e devolverá a resposta já processada.

• Configuração do Service BUS: Trata-se da exposição do serviço criado na aplicação legada no service BUS, como uma operação.

• Aplicação Tester: É a aplicação que irá consumir o serviço da aplicação legada, através da operação e endpoint disponibilizado no Service BUS.

Um desenho bem feio, mas aproximado deste cenário poderia ser este abaixo (clique para ampliar)

 

 

Diagrama do exemplo (clique para ampliar)

 

Bom, como meu tempo aqui se resume a pequenos intervalos onde eu poderia escrever isto, vou separar em 3 partes, uma para cada aplicação, um post para cada. Assim que der eu já começo!

Valeu!