Git Flow – Concurrent Version on Acid

Git Flow – Concurrent Version on Acid I recently changed from using svn to using git as my concurrent version system, the migration was far easier than my migration from rcs to cvs and on to svn. I am a great believer in the use of branches to make the development experience easier. Many people cite issues with merging and overall consistency of the development tree as reasons why branching does not work for them. Usually I tell them they are doing it wrong, and explain how it could be done to make their lives a whole lot easier. Git Flow Git flow is an extension for git which makes the maintenance of branches a whole lot easier. The functionality allows you to set up master, development and, feature and hotfix branches and gives you the tools you need to easily switch between those branches. For the detractors of branching it teaches them an effective way to create and maintain their branches, making it easier to maintain their code than before. Original, Documentation, Code A short introduction to Git Flow A short introduction to Git Flow from Mark Derricutt on Vimeo. View or comment on Daniël Crompton’s post »

Google Events Cracks Showing #tdd

Google Events Cracks Showing As with most beta products there are many wrinkles which need to be ironed out. So it is to be expected that issues such as Kevin Marks iterates below will ocurre. From a developer perspective the first thing to do is note these issues down, the second thing to do is see whether they can be reproduced. Most developer/test teams would test manually whether they can be reproduced, I would tell them that they should be writing automated integration tests. In team which is already test driven the unit tests will probably already cover this feature, so this means that when this error would be occurring that there is an issue with the unit tests which cover the code. For a team that isn’t already unit testing this is not great place to start their automated testing, and there is never really great place to start once you reach the beta version. Why not test manually? you may ask. For one simple reason, if an issue such as is being described below is not already in your automated tests that’s the actual bug. Had there been a test for it, it wouldn’t have happened, and by writing a test you are ensuring it never happens (again) without knowing about it.

Kevin Marks I tried inviting a non-gmail account to an Event. The email invite looks nice, and contains event details. Ok so far.  I then try to respond to the event without creating a G+ account, or logging in.  I get a web form with Yes/No/Maybe (Good) and 2 unlabelled fields. This is where the lunacy steps in. What you put in these 2 unlabelled slots has to follow G+’s Names Policy (you know, the one that accepts ‘panel heater’ but rejects many real names. http://epeus.blogspot.com/2012/01/google-plus-admits… View or comment on Daniël Crompton’s post »

For Authors of Computer Books

For Authors of Computer Books Abstruse Goose » Arithmetic for Beginners View or comment on Daniël Crompton’s post »

Painful Facts For Developers #programming #foss

I recently saw a note from the Tech Journalist Russell Holly who calls on the Scumbags of the Internet to stop making demands of developers from whom they get their free software:

You don’t demand ETA’s on shit you aren’t paying for. You don’t get angry when something doesn’t work quite right on an Alpha or Beta build of something you didn’t pay for. You don’t start shooting off at the mouth about how you are going to move to someone else’s free software if this developer doesn’t fix the software you didn’t pay for.

I was naturally in agreement with the spirit of what he said. And I think that he and these developers miss a number of simple facts:

User Stories: How small is too small? #scrum #xp #agile

I like a User Story to be precise and target a specific functionality, a Use Case or a logical vertical of a Use Case. This means that a finely scoped task of 2 or 3 hours could be called small. It also depends at what time in the SCRUM backlog a certain User Story is implemented for it to be a small or large User Story.

At the beginning of any development project all User Stories are large, they include many additional variables everything from setting up the initial design patterns, to drastic refactoring to allow for stackable functionality. This means that a task which might take 2/3 hours once there is a working vertical to build on could take considerably longer when everything needs to be build from scratch. Ron Jeffries – SCRUM God – says

Code Review in SCRUM? #xp #agile #mathematics

Recently I was asked by a client to make some estimations regarding a review of a code review for a programming project. The aim of the project is to refactor the existing code for efficiency, check the security and add new functionality. Having done code reviews in the past I had an idea on how it should be done, and little idea on how to quantify the work into an estimate.

How a code review estimate is done now?

Testers in SCRUM? #agile #xp #qa

Testers are very important in SCRUM, before the sprint they help the Product Owner to refine the User Stories are help with “How to Demo” and “Definition of Done”. Doing this during backlog grooming or analysis meetings allows the Testers to suggest User Stories for testing such as in the sidebar, and allows them to product examples which can be used for automated testing, help with sprint planning, among others.

“As a Tester, I want to read a log, so that I can verify that payments have been processed”

During the sprint, while programmers will be implementing the functionality, the testers will be implementing manual test scripts, automated tests and acceptance tests associated with the user story. In some places they develop the automated tests paired with a programmer, and in others they script the tests themselves. The testers would deliver “Running Tested Features”, preferably together with the programmer, which comply with the Definition of Done which the Product Owner, Testers and Team have defined.

Read more articles on Agile, SCRUM or XP…

You can see that Testers are a vital part of any SCRUM team.

Image source: Wikipedia
Sources: Lance Walton, Henrik Kniberg

Kings of Code Conference #kingsofcode

This week I went to the Kings of Code Conference, to “explore and discuss the latest trends, developments and best practices in web and mobile development technologies.” It included a hackbattle, lots of presentations and free beer.

HackBattle

Proof of Concept: XML and SQL mapping with JiBX and Hibernate #orm #hierarchy

I was reading ESB in Action^* while preparing to implement Apache ServiceMix and was interested to read about JiBX, which is a tool for binding XML data to POJOs (Plain Old Java Objects). What it immediately reminded me of was Hibernate, which does ORM (Object Relational Mapping), and the possibilities there were for integration. This brought the thought to my head that together they could be used to create a WebService which could expose features of the database easily.

A search brought me the view of a Hibernate developer who pointed out in 2004 that there was a “impedance mismatches here: object/relational and object/hierarchical.”^[1] And I believe that would be true if it wasn’t for the fact that much of the data in relational databases is mostly hierarchical in nature. Even the core pattern of the embedded indexing in Hibernate Search assumes that the data being indexed is a nested hierarchy or inclusion hierarchy. I won’t get started on the issues that Hibernate Search has due to this impedance mismatch, needless to say there are a number.

The JiXB^[2] documentation is quite clear, and makes it easy to implement.

* I was told to read Camel in Action and ActiveMQ in Action

1. XML Marshalling/Unmarshalling
2. A basic binding

Image source:

Continuing Our Solitary Existence #xp #agile #scrum #programming

It’s thought that programmers have a solitary existence, in hacker movies they are often depicted as being behind a screen in the dark working on their own. Even the popular media images of programmers that are loners. As any programmer knows this is far for the truth, collaboration mostly benefits development. Sharing tasks and bouncing ideas of other developers makes the end products better. Yet with the exception of discussions the actual development task is performed by one person behind one computer.

There are many studies which show that there are even better ways to work, collaboratively create and discuss. Taking all the benefits of working as a team and sharing knowledge reduced to one continuous process rather than incremental tasks. It’s called pair programming, and studies have shown pairs can deliver 127% of what they deliver working on their own.