I have added a new page, Speaker Bio, that summarizes my speaker appearances. Hopefully it is complete and I will do my best to keep it updated.
I have just come home after spending three amazing days in Krakow as one of the speakers at the Java Developer Days Conference there. The organizers of this conference takes well care of their speakers and you feel welcome all the time. And I am sure the attendees feel the same.
Apart from my talk, my greatest achievement at the conference was to win a a signed copy of Practical API Design by implementing a simple application using bck2brwser. My contribution: Duke2Brwser. Hope this may inspire you to try it out. Just activate the HTML/Java Project Support plugin in NetBeans and go ahead!
It’s my first time at JavaOne since Oracle took over the show. It is definitely smaller than before, but still as vibrant as it used to be. The good old JavaOne feeling is still there and this year the Keynote was back at Moscone.
For more information about Java, check out the OTN site.
The content catalog for JavaOne is available. The abstract for my presentation, From the Spring Framework to Java EE 7 (CON3598) can be found there together with more than 500 other sessions. Still haven’t registered?
I am at the final stage preparing my presentation on A Pragmatic Approach to Continuous Delivery for jDays next week. Hope to see you there! I will make the slides from the presentation available here shortly after the presentation.
Summer time means less people at work and more time to think ahead what to do the remaining part of the year. In my case it means that I have signed up for a talk called A Pragmatic Approach to Continuous Delivery at jDays, a Swedish Java Developer Conference located in Gothenburg. Read the abstract here, and vote for it here if you think it sounds interesting.
While I was at it, I also proposed a lightening talk on the same subject to Smidig 2012, a Norwegian Agile Developer Conference in Oslo.
This post is not about generating traffic. Nevertheless it probably will since the concept of Responsive Web Design is pretty hyped these days. Everybody seems to be talking about it an I am a bit concerned that the wrong people will start thinking it is the solution to everything without understanding what it is.
First of all, it is not about technology. The technologies and techniques involved have been around for a while, even though they are constantly improving hand in hand with the browser support for CSS3 and HTML5.
Responsive Web Design is all about mindset. It is about getting away from the print-on-paper-influenced-960px-wide-look-the-same-in-every-browser way of thinking. It is about convincing the customers that it is not only okay, but actually required, that your site looks different in different browsers. It is about creating the best possible user experience regardless of what browser or device you are using.
Just remember that there are still lots of situations where the responsive approach is not the way to go and a “mobile” or “tablet” version of your site is the preferred solution.
Agila Sverige is a wrap. It has been two exiting days with a lot of great presentations and interesting topics discussed at the Open X sessions.The slides from my presentation can be found here: Arkitektrollen – Agila Sverige 2012 (text is in Swedish).
If you want more information about The Agile Architect Pattern, see my previous post about it here at this site.
Guide the team to reduce technical debt before it becomes a problem.
The nature of agile development is to deliver working software continuously. This means that the focus for all actors (Product Owner, Scrum Master and Team) is on the functionality delivered in each iteration. As a consequence, technical debt is considered okay and is likely to increase for each iteration completed. Often, this is allowed to go on until the debt has reached a level where the velocity of the team is starting to decline. After a while something has to be done, and the term Refactoring Sprint is introduced. A refactoring sprint is in this context an iteration totally devoted to paying off technical debt, thus no functionality is delivered for an entire iteration.
How it works
The Agile Architect Pattern prevents the scenario from the motivating example from happening by introducing an Agile Architect role. The Agile Architect can be seen both as a member of the team and as well as a stakeholder. This makes him/her able to both work with the team members, guiding them while trying to identify architectural issues as well as discussing requirements for future iterations with the technical resources from the client. While the team has a iteration-by-iteration time frame, the agile architect can see a few iterations ahead making sure the architectures evolves in a way that (hopefully) will not cause major problems ahead.
When to use it
The Agile Architect Pattern should be used in any project spanning over enough iterations likely to cause the technical debt large enough to slow the team down. It is important that the Agile Architect is comfortable both in the code domain acting as a guide for the team as well as on a higher level of abstraction to be able to interact with the client technical resources.