Advertisements

General Musing

blaze your trail

Posts Tagged ‘programming

Git Flow – Concurrent Version on Acid

leave a comment »

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.

OriginalDocumentationCode

View or comment on Daniël Crompton’s post »

Advertisements

Written by Daniël W. Crompton (webhat)

June 30, 2012 at 10:23 am

Google Events Cracks Showing #tdd

leave a comment »

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 »

Written by Daniël W. Crompton (webhat)

June 29, 2012 at 10:41 pm

Posted in Uncategorized

Tagged with , , ,

For Authors of Computer Books

leave a comment »

Written by Daniël W. Crompton (webhat)

June 27, 2012 at 11:15 pm

Painful Facts For Developers #programming #foss

with one comment

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: Read the rest of this entry »

Written by Daniël W. Crompton (webhat)

December 18, 2011 at 3:44 pm

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

with 3 comments

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 Read the rest of this entry »

Written by Daniël W. Crompton (webhat)

November 28, 2011 at 3:44 pm

Posted in programming

Tagged with , , ,

Code Review in SCRUM? #xp #agile #mathematics

with 7 comments

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?

Read the rest of this entry »

Written by Daniël W. Crompton (webhat)

October 24, 2011 at 3:35 pm

Posted in programming, risk

Tagged with , , , , , ,

Testers in SCRUM? #agile #xp #qa

leave a comment »

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 , or

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

Image source: Wikipedia
Sources: Lance Walton, Henrik Kniberg

Written by Daniël W. Crompton (webhat)

October 19, 2011 at 12:03 pm

Posted in business, programming, risk

Tagged with , , ,

%d bloggers like this: