Better Code

Migrated web site from Wordpress to Jekyll

Sun, 13 Mar 2016 00:00:00 +0000

This site as now been migrated from Wordpress to Jekyll. The simplicity and speed of a static web site suits my needs much better that Wordpress.

Some of the old blog posts have been pruned.

Please note that I rarely write blog posts, but when I do I mostly do it on: http://blog.crisp.se/author/maxwenzin.

Check out the Jekyll docs for more info on how to get the most out of Jekyll. File all bugs/feature requests at Jekyll’s GitHub repo. If you have questions, you can ask them on Jekyll Talk.

Blogging on the Crisp blog

Tue, 16 Apr 2013 00:00:00 +0000

At the moment I do most of my blogging (if at all) at http://blog.crisp.se/author/maxwenzin so you’re welcome to go there and read about Five fundamental principles for building software development teams or other posts by me or my Crisp collegues.

Challenges of a distributed Scrum Team

Mon, 26 Mar 2012 00:00:00 +0000

The Mobile Team at Projectplace has people both in Stockholm, Sweden and in Bangalore, India. This gives them a set of challenges that they need to overcome. I current work as a Scrum Master for them at Projectplace and I’ve written a blog post on the Crisp Blog about the challenges of a distributed Scrum Team.

My first Visual Agenda inspired by Gamestorming

Thu, 22 Mar 2012 00:00:00 +0000

Full image

I will be doing some blogging on the Crisp blog from now on.

Here’s a post about my first Visual Agenda, inspired by the book Gamestorming.

Reverse Phone Lookup in Google App Engine

Sun, 11 Mar 2012 00:00:00 +0000

I wrote a small pet-project this weekend based on Java in Google App Engine.

It’s a single-page web app that helps you use directory services (like white and yellow pages) in different countries. Ever needed to search for people in different countries? Hard to find which directory service to use? Well, this app solves that problem for you by knowing the best services and providing you with a single form to use, regardless of which back-end site will provide you with the search result.

I havn’t quite named it yet. It started out with the sexy name “Reverse Phone Lookup”, but since most sites now allow searching for name or phone in the same field, that name was not really appropriate. It now has the totally generic and boring header: Global Directory Search. Yuck. Oh, well. You can reach the app at the following URL:

http://reverse-phone-lookup.appspot.com/

The source code is available at GitHub if you’d like to write some request, or contribute!

Agile Change Strategies

Tue, 06 Mar 2012 00:00:00 +0000

Change Strategies by Henrik Kniberg. Mindmap created in Mindmeister by Max Wenzin. View full map in Mindmeister

Change Strategies

Ask for foregiveness rather than permission
Use metrics
Reversible "experiments"
Set an example
Talk to everyone at once & Capture the intent
Visualize the current situation
Compare options
Make a business case for your change

How-to do Sprint Planning using Jira

Tue, 21 Feb 2012 00:00:00 +0000

I have been using Jira for many years and have worked as a Scrum Product Owner for a few years. I have managed multiple teams, based in different parts of the world. This is my guide to using Jira as a Sprint Planning tool.

When to use a web-based tool instead of a wall board (whiteboard)

When you have distributed teams
When you want to work on your tasks from multiple locations
When you need to share information with outside stakeholders (like customers)

If you have a simpler scenario, try using the simplest tool possible for your task tracking, like a whiteboard.

Before Sprint Planning

It’s the job of the Product Owner to keep the Product Backlog groomed & ordered. The items on top of the backlog should be well enough specified so that they can be moved into a Sprint Backlog. This work is ongoing and often means talking to stakeholders a lot.

Before Sprint Planning I prepare one Jira “bucket” per team. Usually I use one Jira “Version” for each Sprint and add a custom field (“Sprint Team”) to track which team a specific issue belongs to.

I fill the buckets with issues I find suitable for each team until there’s more than enough issues for each team. How do I know how much is enough? Past performance. Do I have estimates on all issues? No, usually not. Perhaps on some.

This results in a preliminary Sprint Backlog. This is not the final Sprint Backlog, but only a suggestion.

I usually juggle a bit with the ordering (prioritization) to make sure the most important issues are on top. Also, if there are any bigger or riskier issues, I move them up the list so they are handled early in the Sprint.

A few days before the Sprint Planning meeting I send out links to the preliminary backlog to the teams. At this time, the suggestion for next iteration should be pretty stable, but changes can still occur.

This enables the team to:

Review the issues in advance (makes for a quicker and less painful Sprint Planning meeting)
Give me feedback on poor priotization, poor team choice etc

Managing left-overs

Hours before the Sprint Planning meeting I kick any unfinished issues from the current Sprint into the preliminary Sprint Backlog for the upcoming Sprint. If there are issues that are not valid any more, I close them with “Won’t fix” or similar resolution. Issues that have been started are usually given a higher priority. (“Stop starting, start finishing”) The full remainder from current Sprint does not necessarily make it to the top of the list for the upcoming Sprint. Priorities change and new things pop up.

During Sprint Planning meeting

It is the job of the Scrum Master to send invites to the Sprint Planning meeting. The Product Owner is just there to clarify the backlog and answer questions. I try to take a backseat position here if possible and let the team drive the planning as much as possible.

Since the teams are often distributed in different parts of the world we usually use Skype for voice and some screen sharing software to display Jira.

Quick overview of Sprint Planning process using Jira:

Display list of issues (preliminary Sprint Backlog) in Jira and talk about the overall goal of the Sprint
For each issue in the list:
1. Team reads the issue
2. Team discusses the issue and asks the PO when in need of clarification
3. Team estimates the issue using Planning Poker or similar technique. Estimation is entered as “Time Remaining” in Jira. (or if estimation is done in “Story Points”, in some other suitable Jira field)
4. When the team feels that they have enough issues to fill a Sprint, the process ends. This is usually done by summing up the “time remaining” on the issues in the Jira “bucket” and when that sum reaches what the team usually manages (their velocity), then they know they have enough. Please note that summing up “Original Estimate” is not a good idea if you have work-in-progress left-overs from last Sprint.

After Sprint Planning

Directly after Sprint Planning I kick all issues that didn’t make the cut to the next version so that the teams bucket only contain what they have committed to for the new Sprint. Then I send a Jira link to the stakeholders so they can see exactly what the new Sprint Backlog contains. I may only send them a list of the issues that didn’t make the cut if I know they were expecting some specific issues.

I usually have some Jira filters for each Sprint to make it simple for the teams to know what issues to work on. I update these for the new Sprint.

Here are some example filter names:

Current Sprint - TODO - Team A
Current Sprint - TODO - Team B
Current Sprint - TODO - Team C
Current Sprint - TO TEST - Team A
Current Sprint - TO TEST - Team B
Current Sprint - TO TEST - Team C

You can probably figure out what these filters show…

Closing thoughts and further reading

I hope this guide gives you some idea how you can make it work. If you wish to read more about Jira in general, visit Atlassians Jira section. If you are unsure of the Scrum terminology used here, or just want to know more about Scrum, check out What is Scrum at Scrum Alliance.

Cheap Oracle virtualization

Tue, 21 Jun 2011 00:00:00 +0000

Summary

Use multiple Oracle instances in the same machine instead of multiple virtualized hosts in the same machine.

Intro

I read an article in Computer Sweden today where Kappahl couldn’t do virtualization of their Oracle databases (article in swedish) because of expensive licence costs. In this article, I would like to offer a simple and cheap option to Oracle virtualization.

Why virtualization?

Organizations want to virtualize their Oracle databases for many reasons, one being to reduce license costs. Other reasons include reducing hardware costs and making it easy to add new databases.

Simply put, hardware virtualization is basically about exchanging many physical servers for a single big server.

You may prefer the wikipedia definition of virtualization, but mine is short, sweet and simple.

The alternative solution

Instead of doing Oracle virtualization using VMWare or Oracle VM, you can install several Oracle instances in a single Oracle installation, in a single machine. This is not what people usually mean when they say virtualization, but you get many of the benefits this way, and it will reduce your Oracle license costs!

Pros

Still easy to start/stop individual instances
Still easy to add/remove individual instances
Still easy to configure memory and disk usage per instance
No need to learn/buy any virtualization technique

Cons

All instances will run on the same Oracle binaries, meaning all will run on the same Oracle version (some may consider this a benefit, when you’ve reached it…)
All Oracle instances will run on the same OS.

Real world experience

I have seen this work very well, especially for testing and development installations. Virtualization of databases in a production environment may not be as common, but there’s no reason it shouldn’t work there aswell.

Don't Repeat Yourself in PLSQL parameters

Mon, 25 Apr 2011 00:00:00 +0000

When writing PLSQL in the Oracle database, you define parameters to a function/procedure like this:

FUNCTION getFullName(iUserId IN INTEGER) RETURN VARCHAR2
IS
BEGIN
   --TODO: Implement this
   RETURN "";
END getFullname;

Instead of writing it like that, consider using a table.column definition as type for your parameter! This way, if you change your table, you will not also have to change your code!

Example:

FUNCTION getFullName(iUserId IN SIGNUP.ID%TYPE) RETURN VARCHAR2
IS
BEGIN
   --TODO: Implement this
   RETURN "";
END getFullname;

Now, if you for some reason change the ID column in the SIGNUP table to be something other than INTEGER, you can leave the code as is! Much more DRY!

Unit testing pl/sql

Sat, 23 Apr 2011 00:00:00 +0000

My situation

I currently have an assignment where there is a large PLSQL code base. It’s been developed actively for about 12 years and works quite well. I am not saying it’s flawless, but quite mature. There’s lots of room for improvement and lots of dead code that needs to be removed.

Some of the plsql is called from the Java DAO layer of a front-end web application, but most of it is used for backoffice functionality. The parts that are accessed from the Java layer are tested through integration tests based on JUnit, but the large part that is only used from the backoffice has no unit test coverage.

Doing something about it

I’ve known about the utPLSQL framework for many years, but never gotten around to actually use it in a Continuous Integration environment. I decided it was time to do something about it and started by adding the installation of utPLSQL to the already in place automated database reinstallation build. The installation part was quite easy, I just dropped the utPLSQL install scripts into our own source control repository and made it part of our db install. Uninstalling utPLSQL was a bit tricker since it creates public synonyms and those are not dropped when the Oracle db user/schema is dropped. (And that’s how we “uninstall” our other schemas normally.) And if I let those public synonyms stay there, I would get errors on the next install. So I simply need to create a small script that dropped those public synonyms as part of the uninstall/install (reinstall :) ) process.

After utPLSQL was part of our db installation, I created a couple of sample utPLSQL tests and tried them out. No problems there. I could run them from the SQL prompt without problem. But what I really wanted was to make them part of the build process in Hudson. So I started writing a JUnit test that would wrap the utPLSQL tests and then it would be runnable from Hudson.

After I while it struck me that I was writing something that someone else had probably written already and after a quick google I found the maven-utplsql-plugin. (insert holy graal sound here) Since we use Maven for the builds, this seemed like a perfect match. However, there were some pitfalls.

Some pitfalls

The maven-utplsql-plugin is currently not available in any public Maven repository. So, I had to download it and install it add it manually to our local Maven repo. The only problem was that our Maven repo was setup not to accept SNAPSHOT releases, and since we didn’t want to change that, I had to HACK the source files in the zip file and replace SNAPSHOT with STABLE in order for our Maven repo to accept the new artifact. In fact, this may lead to that I have to do some contributions to the dev team of the maven-utplsql-plugin to get it up to a RELEASE version and maybe even up on a public repository?

The happy ending

Finally, I added a new task to our db-reinstall profile in Maven. The new task simply calls the plugin which runs the tests. SUCCESS!

My sources

Here’s the Maven plugin for utplsql: https://sourceforge.net/projects/utplsql/

The utPLSQL project: https://sourceforge.net/projects/utplsql/