Então você quer aprender REST?

Mando alguns resources.

Conceitos de REST?
Importante ler sobre o material de Roy Fielding. E olhar o material sobre REST da Wikipedia.

Outro artigo é o que saiu na InfoQ. Tem tradução na InfoQ Brasil.

Livro?

Indico o Rest in Practice, do Jim Webber.

Exemplos de API para trabalhar com o REST? As APIs listadas abaixo são em alguns casos baseadas nos conceitos de REST, mas já vão ajudar em muito.

• http://mailee.me – software de mail marketing que possui api e libera uma conta com créditos para testes.
• http://basecamphq.com/ – software de gestão de projetos que possui api e possui conta gratuita.
• http://aws.amazon.com – A Amazon WebServices provê uma série de APIs para os serviços que podem ser testados na parte gratuita da Amazon.

Ferramentas para trabalhar?

Vou indicar apenas duas:

• Restfulie – projeto liderado pela galera da Caelum, que vale apena ser observado, seguido e apoiado.
• Jersey – API Java muito consistente para fazer trabalhos com REST.

 

uMov.me – 1 year after public launch

Since May of 2009 I’m playing as CIO / CTO for Trevisan Tecnologia, a mobile development company located in the south of Brazil.

My mission here is to create a new culture and help grow the company teams to enable the creation of new products. When I say culture I mean creating a Learning culture based on Lean and Agile practices. Our team is growing a lot and will keep growing. When I say new products, I’m saying Lean Startup style.

Today is a great day. uMov.me is completing 1 year after public release. uMov.me is a mobile platform that enables companies to deliver quality corporate mobile apps faster to the market. It’s simple, fast to develop, and you can find what you need to develop corporate mobile applications.

The good thing is to look back and see amazing things our team done, not only technically but also looking at the product itself. I’m proud to be part of this team.

We have published an infographic telling a bit of the story of this past year.

2011 in review

The WordPress.com stats helper monkeys prepared a 2011 annual report for this blog.

Here’s an excerpt:

A New York City subway train holds 1,200 people. This blog was viewed about 5,700 times in 2011. If it were a NYC subway train, it would take about 5 trips to carry that many people.

Click here to see the complete report.

Revendo 2011: é dia de Java, Java One Latin America e RSJUG de volta!

Então, dias 26 e 27 de agosto ocorreu o É dia de Java 2011, evento realizado na UFSCar junto com a galera do SouJava. Eu tive duas participações no evento, primeiro fazendo o workshop “Da visão a Produção” na sexta-feira a noite. Depois do workshop fui fazer um lanche com Fabio Velloso, Wagner Santos e Dalton Stoqui, e infelizmente foi a primeira vez que eu perdi para um Xis/Bauru/Sanduiche. No sábado fui palestrar sobre métricas, com uma palestra chamada “Da métrica a diversão“. Os fontes usados como base estão aqui no github.

Em novembro de 2011 estava grande a expectativa pelo Java One Latin America. E quando saiu a lista de palestrantes aceitos, lá estava eu! Tive a oportunidade de falar sobre eXtreme Programming, integração e entrega contínua de produtos. Falei sobre diversos tópicos, sobre a importância de termos feedback do nosso cliente sobre o que está sendo desenvolvido, sobre Lean Startup, sobre práticas do eXtreme Programming e depois mostrei alguns exemplos de como podemos “ganhar” em produtividade de deploy de aplicações. Mostrei um exemplo de script Ant fazendo a automação para deploy de um aplicativo no TomCat 7, rodando antes disto uma série de ferramentas para apoio a automação, com testes e auditoria de código. Em outro exemplo, mostrei um aplicativo feito com Play Framework, fazendo deploy no Heroku. Mais sobre a palestra:

Integração e entrega contínua de produtos? Que venha o eXtreme Programming!

Ser capaz de realizar um deploy de forma contínua não requer apenas habilidades no processo de deploy. E não tem nada a ver com reações rápidas a mudanças ou iterações curtas. Tem a ver com prevenção e aplicação de práticas de engenharia de software efetivas. O objetivo desta palestra é falar como as práticas do eXtreme Programming podem ajudar times Java a alcançarem a qualidade de código necessária para que se possa liberar software em produção de forma contínua e segura. Veremos ferramentas opensource, métricas, automação e riscos minimizados. Com participação da equipe toda e melhoria contínua. Lembre-se: entregar software em produção, para fazer bug fix / patching, não é entrega contínua. É bagunça generalizada, que pode ser evitada.

E para fechar 2011, fizemos a “reativação” do RSJUG, o Grupo de Usuários Java do Rio Grande do Sul. Com o apoio de Leandro Nunes, fizemos um evento fazendo um repeteco da minha palestra do Java One Latin America e depois um bate papo para entender como a comunidade do Rio Grande do Sul pode voltar a fazer eventos e criar novas ações. Fizemos uma relação de atividades que poderão ser desenvolvidas em 2012.

Problemas com o RubyGems… atualizando manualmente para resolver o problema!

Estava com problemas para instalar e usar algumas gems… exemplo criar uma aplicação no heroku.

Tentei a atualização do Rubygems através do:
gem update --system

Não deu certo. Erro neste comando também. Os erros que apareciam para mim eram sobre métodos que não eram encontrados no Rubygems. Estava bem estranho.

Acabei tendo que apelar por atualizar o rubygems manualmente, (a) fazendo o download da última versão, (b) fazendo o unzip do pacote e (c) rodando o setup.rb.

Sobre meu ambiente:
- ruby 1.8.7 (2010-01-10 patchlevel 249) [universal-darwin10.0]
- rubygems agora atualizado, é o 1.8.11.
- Mac OS X

Tudo voltou ao normal, agora funciona o gem update –system e tudo mais. Só que eu não sei qual foi a causa raiz. Se por acaso alguém já passou por algo assim, e descobriu o que causou, quero saber!

Desconf 2011: porque você precisa ir?

Antes de qualquer coisa, o que é a Desconf?

A @desconf é um espaço que vai reunir 50 palestrantes, que vão fazer palestras de 5 minutos! Os assuntos? Empreendedorismo, design, metodologias ágeis, user experience (ux), inovação, desenvolvimento web, lições de vida, enfim, o que importa é colocar a platéia para pensar!

Durante o Agile Day 2010 eu falei um pouco sobre a Desconf, no caso da edição que estava por chegar.

Mas e trago a pergunta novamente! Porque você deve ir na #desconf?

Motivo 1: porque eu vou!

Motivo 2: porque você tem algo a dizer. Você tem algo a ensinar. Você tem algo para falar e fazer pessoas pensarem a respeito.

Motivo 3: porque terão open spaces para conversarmos, discutirmos e criarmos mais conhecimento. Certo que vai rolar um sobre Lean Startup!

Motivo 4: porque você poderá praticar habilidades de programação ou de design através de Coding Dojos!

Motivo 5: almoço será pizza, pizza e mais pizzas para a galera poder curtir as atividades no período. É non-stop. Hora de almoço é hora de open space e dojos! E depois certo que vai rolar aquele happy hour para continuar o papo!

Motivo 6: Precisa de mais algum motivo? Se inscreve lá!

Ah, se sua empresa quer ajudar a fazer a diferença, estamos com espaços para patrocinadores!

BABrazil está chegando! 22 a 25 de novembro de 2011

De 22 a 25 de novembro ocorre em Porto Alegre o BABrasil, conferência brasileira sobre análise de negócio. Aqui em Porto Alegre quem tem investido muita energia no assunto é o Luiz Parzianello, parceiro de GUMA-RS/XP-RS de tanto tempo e também fundador e atual presidente do IIBA Porto Alegre.

Eu vou participar do evento, na qualidade de aluno, no curso do Shane Hastie que ocorre nos dias 22 e 23 de novembro. #ficadica para você que estiver em Porto Alegre nestes dias e quer aprender mais sobre análise de negócio.

Empresa muda do eXtreme Programming para o Scrum. Hein?

Como assim? A gente viaja e lê coisas por aí e não vê tudo… não vou citar aqui nome de empresa nem pessoas, mas vou só dar uma opinião sobre o assunto do título.

Primeiro, que eu acredito que Scrum é uma excelente forma de um time começar a trabalhar com Agilidade. Excelente para criar ritmo, de conhecer cerimônias, de trabalhar transparência e uma série de valores que são importantes em times ágeis.

Só que chega um momento que este time não vai mais conseguir avançar no assunto. A velocidade não aumenta, e ainda aparecem problemas relacionados a testes, a escrita de histórias, as entregas não estão consistentes, entre outros assuntos.

Este time vai precisar melhorar processos de teste, processos de aceitação com o cliente, de deploy, enfim, questões relacionadas a práticas de engenharia de software.

Quer dizer que Scrum é ruim? Não… o Scrum é incompleto de propósito. Ele é excelente para estruturar um time e ajudar em questões de planejamento e gestão de projetos.

Não é que o time deixa de usar Scrum e passa a usar por exemplo o eXtreme Programming. Simplesmente o que o time faz é agregar aos seus processos atuais práticas de engenharia de software muito bem documentadas pelo eXtreme Programming, assim adicionando mais qualidade de software ao seu dia a dia. Seja do XP ou do FDD (Feature Driven Development) ou de outra prática que este time andou estudando, exemplo Getting Real. O que se busca são melhores formas para desenvolver produtos.

Mas não para por aí. Depois este time vai querer eliminar mais restrições ainda e vai querer entender onde ele está sendo limitado, e vai querer encontrar formas de entregar mais, de minimizar variabilidade, de aumentar fluxo e aí este time começa a entender e ler mais sobre Lean, começando a fazer sentido a importância dos processos de melhoria contínua (Kaizen!) e eliminação sistemática de desperdícios.

Aí este time começa também a ler mais sobre algumas coisas que vem acontecendo no mundo de hoje, exemplo DevOps, Continuous Delivery, Startups, Lean Startup, e por aí vai…

O ponto é que ao ler uma matéria estilo case, estilo press release, de uma empresa que usava eXtreme Programming há oito anos e escreve no título que passa a usar Scrum… bom, desculpe… mas não faz sentido!

Dizer que está se deixando de usar o XP para usar Scrum, não faz sentido por alguns motivos:

- XP tem foco nas disciplinas de engenharia de software

- Scrum tem foco em cerimônias que apoiam a gestão de projetos iterativos e incrementais.

- As práticas organizacionais do eXtreme Programming são baseadas no Scrum, Planning Game, Stand Up Meeting e por aí vai. Logo, elas não concorrem!!

- Se a empresa estava usando XP há mais de 8 anos, ao passar a usar Scrum sem seguir com as disciplinas do eXtreme Programming estaria fazendo um retrocesso. Se vai deixar de focar em testes automatizados, seja unitário, funcional ou de integração, seja usando TDD (Test Driven Development) ou não. Vai deixar de usar integração contínua, e outras disciplinas essenciais nos dias de hoje em times de desenvolvimento? Eu acho que não… porque não faz sentido!

- O Scrum não define nada sobre vários assuntos. Quando se inicia um “Sprint”, é uma grande caixa preta. Coloque ali os processos que você quiser. Eles devem fazer sentido para sua equipe e para o tipo de trabalho que é desenvolvido. Quando se fala de backlog, escreva do jeito que quiser. Scrum não vai definir nada. Por isto que ele pode funcionar em qualquer área de atuação, não apenas Tecnologia da Informação.

- O normal em uma empresa que está usando eXtreme Programming entregando iterações curtas e muito feedback dos usuários seria passar a adotar princípios e práticas do Lean, para eliminar mais e mais restrições, passando a funcionar em um ciclo de desenvolvimento incremental.

- Uma equipe XP que trabalha com iterações, pode usar todas as cerimônias do Scrum no seu dia a dia e adicionar a isto as práticas de engenharia de software que são formadas como disciplinas do eXtreme Programming.

O mercado brasileiro precisa aprender. E mesmo com todo o movimento nacional, de Agile Brazil, eventos locais, de grupos de usuários locais, a exemplo do GUMA-RS aqui do Rio Grande do Sul, infelizmente os assuntos de verdade não aparecem. Infelizmente acabo vendo matérias sobre estas, que faz parecer é que esta empresa na verdade nunca usou eXtreme Programming.

Quer conhecer mais sobre eXtreme Programming? Fica a dica de uma publicação que fiz com Guilherme Lacerda, com o título Conhecendo o eXtreme Programming. Este foi um trabalho feito na disciplina de Engenharia de Software da UFRGS, ministrada pelo Professor Marcelo Pimenta.
Referência:
Wildt,D. ; Lacerda, G. Conhecendo o eXtreme Programming (XP). In: Coletânea dos Trabalhos de CMP-102 – Engenharia de Software 2010, PPGC-UFRGS, 31 pp, disponível na internet em http://www.slideshare.net/dwildt/conhecendo-o-extreme-programming

Do meio da quadra!

Então!

Estou faz um bom tempo longe do Basquete, quer dizer, bom, consegui voltar a praticar no último final de semana, e vamos ver o quão consistente consigo ser nisto.

O ponto é que adoro o esporte e quero ver o Brasil voltar a curtir como nos tempos de Oscar e Hortência!

Comecei a ler algumas notícias do que vem ocorrendo internacionalmente, assisti alguns vídeos e veio a vontade de escrever mais sobre o assunto, ou pelo menos dar uma opinião de forma mais regular.

Então nesta ideia criei a coluna “do meio da quadra”, onde lá no site da Rising Stars Basketball eu vou ir lançando pequenas ideias, seguindo o princípio do postcard blogging, com posts pequenos buscando a contribuição de quem quer dar sua opinião também.

Então #ficaadica de vocês que curtem o basquete, de visitarem semanalmente ou deixarem o leitor de notícias de vocês apontando para o site da Rising Stars Basketball. Ainda fica a dica de manter o Twitter atualizado nos updates de @rsbasketball e @dwildt, onde os assuntos vão repercutir também.

en: Card, Conversation, Confirmation (a.k.a 3C’s)

Index cards are a great way to keep track of new ideas for a software product. The good thing about them is because they are limited. You can’t get all information into one. And that’s a really good thing. Trust me.

Back in 2003 when I started learning eXtreme Programming, I’ve heard of a story from Ron Jeffries about 3C. And that’s something truly valuable I teach every time I have the chance to.

The 3C concept is based on writing down an idea to an index card, so we can remember about that idea later on. That’s our first “C”.

What we need next is to generate conversations. We need to validate that new idea, with people that can help on that topic. The best thing about having conversations, is to come up with examples that can validate the idea. If it’s a calculation, samples of those. This way, the card becomes “executable”. A card may have extra documentation to help on that process.
And that’s our second “C”. These conversations can help the team to identify some card attributes, like a sense of “value”, priority, risk, whatever-attributes-your-team-likes-to-use.

The third “C” is about confirmation. Having conversations with customers will help us to understand how to validate that card, to make sure that new functionality is ready to go. So that’s what you have to look for, confirmation! From your customers! They will validate and make your idea grow.

What else for index cards?

I saw Jessica Hagy’s Indexed website by a reference from my sister. You can find a book from her at Amazon if you want to.

The thing is: an index card can do a lot to you. Even help you to keep a great conversation flow with your customers. Try it!