Visualizing user stories from idea to production
Posted by Marco Mulder mid-afternoon: October 25th, 2009
In many Scrum projects, user stories that are Done at the end of a sprint have not yet been put into production. In other words, production is often not part of the Definition of Done. There can be several reasons for this. Examples are:
- additional acceptance or integration testing is needed that can not (yet) be done within the sprint;
- user stories have dependencies on hardware of software from an external party that is not yet available;
- minimal marketable features are bigger than what can be produced in one sprint.
JUnit 4.7 @Rules!!!
Posted by Wilfred Springer mid-afternoon: October 23rd, 2009
It took me a while before I really understood what this @Rule business in JUnit 4.7 is really about, but I like it!
Taking OpenLayers to the next level?
Posted by Kris Geusebroek terribly early in the morning: October 23rd, 2009
Attending the FOSS4G conference in Sydney I have been attending a lot of presentations and involved in discussions about the OpenLayers JavaScript framework. see also my previous blog post on My Opensource GIS experiences.
Especially the Birds Of a Feather session yesterday made me really enthusiastic about the next level of OpenLayers.
Scala actors for the enterprise: introducing the Akka framework
Posted by Arjan Blokzijl just before lunchtime: October 22nd, 2009
Last week me and some of my colleagues had the pleasure of being on the receiving end of an excellent training given by Jonas Bonér. The topic was his new pet project: the Akka framework. Perhaps you've played around with Scala lately, and also have taken the first steps in using its Actor library. Simply stated, an Actor is a unit of execution that (usually asynchronously) processes messages and encapsulate their state. An actor does not expose its state, and messages are processed sequentially. The Actor model has been around for quite some time, but today the best-known Actor implementation is Erlang.
The Actor model has been implemented in the standard Scala library by Philipp Haller (for the interested reader, a solid reference is for instance this article explaining how actors in Scala work). In most Actor examples written in Scala, it is not uncommon to find only EchoActors, PingPongActors, and FibonacciSolvingActors. Nice examples, but perhaps you might wonder if they are of any use in enterprise Scala at all. Next to this, if you're interested in concurrent, message passing processing models, STM's, NoSQL data stores, and occasionally wonder what the future in enterprise computing might bring, than Akka might be just the framework you're looking for. This blog is intended to provide a brief introduction into one feature of this framework: Akka's supervisor Actors. It is mostly based on the knowledge extracted from Jonas during the training, and I hope to whet your appetite for it.
Parsing Text with Scala
Posted by Jan Vermeir in the late afternoon: October 21st, 2009
In my efforts to teach myself Scala, I tried solving a problem I've tackled in various languages, 6510 assembly code (didn't get far...), pl/sql, Java (with and without Drools) and Groovy among them. Usually I get bogged down in some detail of the language so I never get to reap any actual benefits of my efforts in daily life. The plus side of this never ending task is that by now I don't have to spend effort on defining a problem but instead can start coding right away.
So this story is about how to parse text in Scala and is part of THE software package that will automagically generate a menu for a week and the shopping list for that menu together with whatever else my family will need that week and send it to www.albert.nl and have the groceries delivered to my door.
(more...)
The XML Instance Gamut
Posted by Wilfred Springer terribly early in the morning: October 19th, 2009
If you happen to be in the business of writing software serving XML documents or consuming XML documents - and if you read this post, then there is a fair chance you are - then there is always one big challenge: how do you make sure your service or client is capable of dealing with all of the XML documents you could possibly expect to be passed around?
And if you happen to come from the test-driven world, the answer is obviously: by testing it. However, if you try to do that, things might be harder than you expect at first.
What about schemas?
Organizing Archetypes
Posted by Wilfred Springer in the late evening: October 14th, 2009
Maven archetypes are an excellent way of allowing people to create instances of a particular type of project without having them to know or worry about all of the peculiarities and details. (And the latest incarnations of the Maven Archtetype Plugin are actually way better than I realized: somewhere down the line, they introduced the ability to use Velocity templates for parameterizing the output. Nice!)
(more...)
Java callout on the Oracle / AquaLogic Service Bus – Invoking static methods in any jar file
Posted by Jeroen van Wilgenburg mid-morning: October 11th, 2009
Sometimes a service bus is not sufficient for the job at hand. You can use EJB's and JMS queues, but that might be overkill. That's where a java callout might come to the rescue. This article will show you how to do a callout with 'complex' objects. On the bus you can pass around java objects or use them on the bus (this requires a small transformation step). I used the AquaLogic service bus version 10.2, but I think it should work any version that supports java callouts. The only difference can be the version of xmlbeans (AL 10.2 uses version 1.0.3)
(more...)
ESB as a political thing
Posted by Viktor Grgic mid-afternoon: October 5th, 2009
Many have assumption that IT / software architecture is a thing of logic. So, there are many discussions about ESB and that we should not have those. The fact is that in large companies, we do not often do architecture - we do politecture. The politics drive the architecture. It's not the way it should be, but that's the way it is.
Let's do one more shot...why do we need ESB? This time from politecture perspective:
Preventing a mess
It allows for a greater degree of control on delivered solutions. Before you even think about creating another quick and dirty integration solution; there is that annoying ESB compliancy making sure that integration mess created with each new technology is at least visible.
Disruptive Innovation
An alternative like REST is a "disruptive innovation" and does not fit in the line of old mindsets (CORBA, RMI, EJB, SOAP, WS-*,...). ESB fits in this line. Of course, it is a matter of time before something like REST wins from ESB's.
Legacy
Quite often the cleanest solution is to change or replace the legacy in case of integration problems. So you still don't need an ESB. But the real problem is who is going to let you change that legacy that has not been changed and (barely) working in production for a long time.
Archives
Xebia Sites
Categories
- Java (282)
- Agile (109)
- General (50)
- Testing (42)
- Performance (42)
- Hibernate (36)
- Scrum (33)
- Podcast (31)
- Architecture (31)
- Spring (28)
- SOA (24)
- Maven (22)
- Project Management (22)
- Middleware (23)
- Deployment (14)
- Flex (17)
- JPA (17)
- Eclipse (15)
- Xebia Labs (15)
- Quality Assurance (14)