Some time ago, I wrote here to leave you with a presentation about programmer testing. This post is a kind of follow up, leaving you now with the exercise.
You can see the exercise here
I also have the presentation in PDF stored in google drive. Find it here.
If you have any feedback/comments or whatever, comment this post.
Here are some slides introducing to REST world. Examples are using JAX-RS (JSR 311).
If we’re moving to the cloud-era, the undestanding of this architecture style is essential. In the cloud we are presented with services (Storage, Search, Graph, Geolocation, …) that we can and should use to build applications. Almost all of these services, available in the cloud, provide some kind of interface and happens that, this interfaces is, generally, a RESTful Web Service. If I want collaborate with these services I must talk the same language!! Moreover, exploring this architectural style in new applications opens the door for realy distributed and scalable systems, while the simplicity is kept high!
Here the slides:
PDF can be downloaded from here.
java, programming, Software, Software Architectures, WEB 2.0
:Adrian Colyer is a smart guy and he put together, in a talk, what software architectures will look like for the next years. True is, most of the services you’re using online today follow these architecture principles. Nothing new, thought.
Nothing in this architecture is can go wrong, it’s so simple! This type of architecture is the perfect fit for this ubiquitous platform that is Internet.
Btw, SpringSource makes it really easy to develop applications in this way, just look to Spring Integration project, for example. They have a plenty of projects, built on top of Spring, that makes development of this type of architectures more, and more fun and easy.
(Ignore the sound problems at the beginning 
)
Contrast this with traditional “enterprise” architectures. Which side of the fence you want to be?
In my last post, I gave away some slides where OO Design Principles are introduced. I have an though about the big-fail that was the J2EE (before JEE5), in terms of violating the Interface Segregation Principle.
If you you are fortunate enough to have experienced the pain of writing applications with J2EE, then you recall that, for example, when you define an Stateless EJB, you have to implement the SessionBean interface.
Well, this is a clear violation of the Interface Segregation Principle, your EJB component have to implement the EJB lifecycle callback methods, even if you don’t need them. Right?
For instance:
public class MyComponent extends SessionBean {
public void someCoolBusinessMethod() {
// Business knowledge is coded here
}
public void ejbCreate() {} //Don't have anything to do in this EJB lifecycle callback, but the interface forces me to implement the method
public void ejbRemove() {} //Don't have anything to do in this EJB lifecycle callback, but the interface forces me to implement the method
public void ejbPassivate() { } //Don't have anything to do in this EJB lifecycle callback, but the interface forces me to implement the method
...
}
Latest versions of JEE (5 and 6), allows you to bind methods to component lifecycle events declaratively, with annotations of XML. For example:
public void MyOtheComponent {
public String realBusinessMethod() {
return "I do really cool stuff";
}
@PreDestroy
private void letMeGo() {
//Any business that should run before the object is left to the GC
}
}
They fixed it, but very behind time…
I’ve put a PDF online for the first part of OO Design principles, or guidelines… . Dowload it from here.
This second part is also the last one of this short introduction to OO design principles. I see these principles a the basic conceptual framework to build Object Oriented programs. It is the base model for a lots of cool frameworks out there, some of them you’re using today to build really cool stuff!
I have also the PDF online. If you want to download it for future reference, you can do it from here.
I have been refreshing the SOLID principles in Object Oriented. SOLID stands for:
These are the principles for Object Oriented design, but not following them don’t make me a bad developer, of course. As with any principle, I can violate it if I have a reason to do it.
I had to give a talk about these principles, so I decided get them out and in the next posts, I will publish a slideshare, per principle, that supportted my talks.
To get the talk started, I begin by introducing OO Programming. Oo programming introduction
Nesta história a equipa estava a trabalhar no lançamento de um produto para o mercado. O projecto já dura à um ano e é gerido com técnicas “tradicionais”* de desenvolvimento de software. Uma das iniciativas (ou sub-projecto, ou projecto no contexto de um programa) inclui um site, um blog e um perfil no Facebook, no Twitter e no Youtube, onde se irá anunciar o grande lançamento do produto para o mercado.
Um mês antes do grande lançamento a equipa responsável pela comunicação pergunta ao desenvolvimento: “Quando é que o produto vai estar pronto? Precisamos de uma data para comunicar ao público o grande lançamento”.
A equipa de desenvolvimento respondeu qualquer coisa como: “Já está 85% feito.”
Com uma contas, o gestor de projecto prevê que dentro de um mês o produto estará pronto para o mercado. E foi com esse pressuposto que a equipa de comunicação anunciou a data do lançamento “imprevisível” do grande lançamento no site, no blog, no Facebook, no Twitter e no Youtube.
Mas será que aconteceu o pior?
No dia de lançamento (segundo as expectativas da equipa de comunicação), a equipa de desenvolvimento diz que não é possível lançar o produto hoje.
Infelizmente para a equipa, a data de lançamento calhou a uma Sexta-Feira, quando já todos andavam atacados com o stress pre-release. Depois do problema escalado, a direcção da empresa pede gentilmente que se esforcem ao máximo durante o fim de semana para lançar o produto na próxima Segunda-Feira. Até lhes ofereceu recompensas financeiras.
O produto é lançado na Segunda-Feira, mas apesar do incentivo financeiro, a equipa perdeu muita motivação com este acontecimento. O overtime e sensação de “falha” é sempre um desmotivador e não há dinheiro que “mexa” nessa psicologia.
Agora, porque é que eu gosto das metodologias ágeis para desenvolvimento de software? Não vou aqui falar de tudo, é claro, mas apenas de um ponto que acho importante no contexto desta história tão comum.
Disciplina nas entregas (e tudo que o processo traz de borla)
Será este ponto importante para repensar algumas metodologias de desenvolvimento de Software? Ou assumimos a postura da negação: “Ahh, podia ser pior se tivéssemos marcado um evento com a comunicação social e grandes investidores.”? :)
* Refiro-me aqui às técnicas que apenas são reconhecidas como boas práticas dentro da empresa um por um grupo restrito de empresas.
Este post é para os amantes de Ruby on Rails e não só. É também para os amantes do desenvolvimento de Software.
Para quem não conhece Ruby on Rails (RoR), RoR é uma framework para desenvolvimento ágil de aplicações Web. Utiliza a linguagem de programação Ruby. Uma framework equivalente, mas em Java, pode ser o Tapestry 5, por exemplo, que também é uma framework para desenvolvimento ágil de aplicações Web, mas em linguagem Java.
RoR não é a única framework para desenvolvimento de aplicações Web com Ruby e uma das mais activas frameworks “rivais” ao RoR é a Merb.
A novidade aqui, pelo menos para mim, é o anúncio do merge entre Ruby on Rails e Merb no RoR 3.
Fica aqui um vídeo com a novidade, dada pelo criador do RoR, que não é um anúncio, mas uma aula.
Para quem não liga nada a RoR, pode ver a partir do minuto 45, tem umas excelentes dicas para qualquer pessoa envolvida no desenvolvimento de software.
Quero aproveitar também para emendar um pequeno detalhe num dos meus últimos posts. No post ‘O poder do “E” e do ‘Mas’” quero alterar de Programador para Parceiro . Vejam o vídeo a partir do minuto 58 para perceber porque é que quero mudar isso . Ahh! E vejam também a resposta à primeira pergunta, a partir do minuto 59
Vale a pena ver mesmo quem não quiser saber nada de RoR, mas quiser saber alguma coisa sobre desenvolvimento de Software.
Acho que existe um poder psicológico no “E” e no “Mas”. O “E” tem um poder positivo, de criatividade e colaboração enquanto o “Mas” tem um poder negativo e cria barreiras para a criatividade e colaboração.
Para o demonstrar, considerem as seguinte conversas:
Programador – “Vou conseguir terminar o módulo A a tempo”
Gestor de Projecto – “Sim, muito bem. Mas conseguirás fazer também a documentação a tempo?”
Pensem que isto vos está a acontecer e tentem perceber o roadblock que foi colocado apenas no vosso caminho?
Agora no mesmo cenário mas como uma atitude mais positiva:
Programador – “Vou conseguir terminar o módulo A a tempo”
Gestor de Projecto – “Sim, muito bem e agora temos de nos focar também em entregar a documentação a tempo? Do que precisamos?”
Pensem agora nesta última conversa. Qual delas será a mais construtiva, colaborativa, positiva e inteligente?
Será o conhecimento gratuito ou quase gratuito? Não sei se existem muitas empresas em Portugal a utilizar mailing-lists efectivamente. Acho que as mailing-lists podem ser uma fonte de conhecimento gratuita.
Este poderá ser a história de muitas equipas em muitos projectos. É uma história de uma equipa de desenvolvimento de software que trabalhou para uma pequena empresa de fogões de sala. Eles ganharam um contrato de um projecto para integrar uma aplicação Web, desenvolvida em Java, com o Twitter. O projecto deveria estar pronto em 6 meses, sob pena de perderem 10 000€ por mês de atraso.
A empresa cliente vai experimentar utilizar o Twitter para aumentar as vendas e querem integrar o site com o Twitter. A cliente quer utilizar palavras chave associadas aos produtos para actualizar várias contas do Twitter. Cada actualização automática tem palavras chave de um produto e um link para a página do mesmo.
Depois de alguma pesquisa e análise, decidiram utilizar o Twitter4J, uma biblioteca de software em Java para abstracção da API Restful do Twitter.
Não tinham qualquer conhecimento na biblioteca Twitter4J. Inicialmente estimaram que demorariam cerca de 2 meses para ganhar o conhecimento e experiência necessária para fazer algo do género em seis meses.
Depois de um pequeno brainstorming chegaram a duas alternativas para colmatar a falta de experiência e eliminar, ou reduzir, qualquer risco de atraso.
Alternativa 1 – Contratar um consultor com conhecimento em Twitter4J para trabalhar no projecto durante dois meses que custaria ao projecto cerca de 15 000 euros.
Alternativa 2 – Assumir o atraso de 2 meses que custaria cerca de 20 000 euros.
Como ambas as alternativas custavam bastante dinheiro à equipa, eles decidiram seguir por outro caminho mais arriscado, mas que nunca poderia custar mais que a segunda alternativa. A alternativa seguida foi:
Alternativa 3 – Começar já a desenvolver qualquer coisa, e se tiveram alguma questão bloqueante utilizam as mailing-list do Twitter4J e da API Restful do Twitter.
Eles seguiram com a terceira alternativa, e qualquer dúvida eles colocavam questões nas mailing-lists, tendo não acesso a um consultor, mas a centenas de consultores que lhes respondiam quase imediatamente.
A equipa consegui terminar o projecto com um atraso de 1/2 mês, o que significou um prejuízo para equipa de cerca de 5 000, comparados com os 15 000 da primeira alternativa e os 15 000 da segunda.
Acham que nesta história o conhecimento foi quase gratuito?
Disclaimer: Isto é mesmo só uma história
