10,000 Foot Developer

Our team had some of us working on master in our git repository, and a refactor was done in a branch so the team lead decided we should all move to from the master to the branch because the merge was painful for this particular feature.  If you have this situation and a few commits in the wrong branch here’s a method that might help out using git reset and git stash.  Reset can undo your last commit, and stash can save it off-stream to retrieve whenever you wish.

For this example I have several commits, not pushed,  in the local repository already.  Looking in Tortoise Git log you can see this state  is three commits ahead of origin/HEAD.

The task here is to  back out the commits from master, save them, then recommit them into the branch.  There are several ways to accomplish this in git but I am showing the revert-stash methodology.

Before starting the process, my recommonedation (that you do not need to follow) is to make sure your stash was clear —  I do so that I can just issue a series of pops to get back to my starting point easily on branch without worrying about mistakes.

git stash clear

Then clean up any other code/work in progress so that git status shows clean.

Next start backing out the commits back to the original HEAD.  Each commit should be backed and saved atomically as a separate entry to your stash.  For instance in this example, start at Commit 3 and work back to Commit 1.

git reset HEAD~1        //back out current top commit; 1 every time
git status             //check and see what files you have to stash
git add -A :/          //stage all the files listed
git stash save Commit# //save the commit to whatever name you choose
git status             //a good place to check status and Tortoise log

….repeat.

Now when you do git stash list you can see all the commits ready for moving to the branch, and Tortoise shows master at  origin/HEAD so you know that all changes were removed.

Time to switch branches.

Issue a git branch -a to list all the remotes as well. Switch to your branch:

git checkout remotebranch

Now you can just pop your first stash right off the stack, confirm it works, check it in and move onto the next stash item:

git stash list          //just checking
git stash pop           //takes first one off list and deletes from stash list
git add -A :/           //stage everything
//--> do some merging/work as needed
mvn clean install       //whatever build process you do to test and check
git commit -c "Commit#" //commit your code
git status              //always check your state!!

….repeat.

Now sync it up with remotebranch HEAD:

git pull --rebase //just checking that I'm up to date
git push          //send those commits to the homeworld

All done!

If you shift-ctrl-f or have a save function set to reformat your code in Eclipse, you stop it from formatting a java comment by using a “-” at the top:

/*-
 * Ignore Formatted Code Block 
 *
 *    myMethod()
 *
 *    Main Point
 *        sub point
 *
 *    @method
 *    @paramater
 *    @exception
 */

If you don’t do this you may end up with something undesirable like:

/**
 * Ignore Formatted Code Block 
 *
 *    myMethod()
 *
 *    Main Pointsub point
 *
 *    @method@paramater@exception
 */

Here are two techniques for debugging tests for Java Maven applications running Tomcat as you work in Eclipse.  There’s usually a problem with having two processes running — your test and then your production code (Tomcat) in two different processes.

These tests are integration style tests that run code against something running in a Tomcat container that is started by Maven (along with a database).   Throw your breakpoints in your test code AND your production code.  Also, during the debug process you might have to attach your source code for your production code; it’s not difficult.  You might have to restart the test after that . . .

Method One — Everything in One Process

You can run everything with a Maven configuration in eclipse, but it takes a bit longer for it to run. Setup a new Debug Configuration–>Maven Build in Eclipse.  Mess around with the setup, but this works for me:

Notice in the goals I have

-Dtest=IntegrationTest_1_Test -DfailIfNoTests=false clean install

If you have a more complex parent/submodule Maven pom setup like I do, you’ll need the failIfNoTests so that the entire thing can build before Tomcat kicks off. (Also depends on your project setup in the pom).

Method Two — Remote Process

This method has a few steps but works a bit faster.

1.  Start up your maven tomcat process in DEBUG mode from a command line.   You used to have to set a bunch of MAVEN_OPTS (and still can), but i Maven 3.0.5 and higher you can do this easily with a default port of 8000 by running mvnDebug instead of mvn:

start mvnDebug compile tomcat7:run

You get something like this as it waits:

2.  Create a DEBUG configuration for the remote port in Eclipse with port 8000, then start it with the Debug button:

3.  Run your test like you would in the IDE normally — no need to run it via Maven.  If you Debug your test — then you can throw breakpoints in the test and the code running in Tomcat.  If you just Run your test you will only hit the Tomcat breakpoints.

Staging in git is when you gather all the files you want  together, new, deleted, and unchanged — for a commit.  Once you commit them they are tracked as a commit with a message and a number, and then available to push to a central repository or where ever.

I use the Tortoise Git GUI before I check in that can add/stage in one commit action, then a separate push action.   It’s because I need a graphical view of everything to eyeball before committing.   The command line doesn’t really do it for me, especially if I have a large commit.

But the question often comes up – how to stage manually in git?

Here’s staging from the command line as I do it.  There are two methods that I know of right now.

Navigate to your directory – I usually do this from “parent pom” directory so I can also maven build (for us java developers).  But somewhere in your local repository.

Git’s “add” is a bit dual-meaninged, like many git commands (merge for example which is different for branches versus clones).  It can mean “track me now and stage me” and it can mean “just stage me.”  This idea can be confusing — for instance with a new file why not “add” then “stage”?  But it’s all one execution in that case.

Generally there are three states to “add” to a stage —

• you need to ADD any files to the stage that the repository does not know about that are new files.  This will stage new files for commit.
• you need to ADD any files to the stage that git already knows about that have changes.  This will stage changed files for commit.
• you need to ADD any files to the stage that git already knows about that have been deleted .  This will stage changed files for commit.

 Atomic Staging

First, I use “git status” to see what’s up.  It lists everything changed and everything not tracked by the repository yet.

What I usually do is this for the atomic method:

git status //see what’s up

git add <new file>

git add <changed/deleted file>

To unstage your changes use

git reset

Recover a deleted file with

git checkout — <file>

Be sure to use the full path from git status

After staging –> commit, push.

Interactive Staging

You can also do this same thing interactively, which is what I use – git add interactive.

git add -i

Command 4 let’s you stage the new file by its number, and command 2 let’s you stage a changed file by its number in a list that is presented to you in both cases.  Command 3 let’s you revert from stage very easily.

You can check it out more in depth here:

http://git-scm.com/book/en/Git-Tools-Interactive-Staging

https://www.kernel.org/pub/software/scm/git/docs/git-add.html

After staging –> commit, push.

I do not do blanket adds, like git add –all because one never knows what file is NOT ignored that may pop up into the directory! Like a new .project file or some funky log file.

I *always* diff all files before I check in.

I *always* eyeball my file collection before I stage.

I *always* eyeball my commit before committing.

A few weeks ago I attended a nice little presentation about GIT at our local Chippewa Valley Developers Group meeting. After the show, and discussing the presentation over a couple of brews with a configuration manager and a low level C++ engineer — we thought that a lot of things weren’t clear like release strategy.

I remember when Subversion came out, I was really keen on it because it had a very loose workflow, easily adaptable to many technical processes. In fact if you’ve ever kan-banned, the board *really* starts to look like a release process especially if there are different server environments for say Java web apps. Won’t get into just how bad those environment columns can get – I’ve even seen a board with at least 20 columns of tasks taking up an entire 10X20 ft. wall! A wee bit too much. Git is also loose in this manner, and in my use of Git — I have more experience in Hg and Darcs — and talking with a lot of different points of view I think a pattern emereged that is a great practice for developers.

Festus says — “Why don’t you just go on an Git?”

Here are the two revelations about Git I’ve arrived at:

1. A merge is not a merge is not a merge. That means, merging master and origin (possibly the remote repo, from where you cloned) is NOT the same as merging master and branch. Not at all.
2.  A Developer should ALWAYS develop from a branch. Always.

The first revelation led to the second revelation. But for some reason, in the merge/rebase wars — it was forgotten that a loca branch/master merge was quite differnt than a master/origin merge.

The question that led me to this was, I thought you applied a typical master/origin workflow to a branch. That is, that the realtionship between branch and master was the same as master and origin, such that in branch you would pull –rebase to sync up with master. Not so. There is no pull activity, unless you wish the branch to pull from origin.

The second question was, discussing with the config manager — how to bundle features in such a way that it’s useful to them. It’s a matter of “repository scope.” So this came out of that discussion:

1. Developers should check in early and often with atomic commits.
2. Atomic commits are almost useless to a release manager, they want a feature release. SO they need bigger units of commit because they may want to revert that entire feature, and a set of commits won’t do.

Hence, the branch/master merge creates that package whilst retaining those atomic commits.

For the my developers my workflow is now this when I am assigned work, for a branch named topic:

git checkout -b topic

do a bunch of work . . . .

git commit -m "topic commit 1"

git commit -m "topic commit 2"

now update master from origin . . . .

git checkout master
git pull --rebase

sync my branch to master. . .

git checkout topic
git rebase master

merge into master . . .

git checkout master
git merge topic

and (after checking for changes) push . . .

git push

Onto solving the second part, making commit’s for a config manager.

Note that Git implicitely does a “fast forward” merge for master/branch that plays my commits on top of the master, but there’s never a record of the merge. IN a lot of cases this might be OK, but in many cases we may want a *real* feature branch to retain its unit of checkin. For instance, say the branch was a whole new package, in which case for the config manager we want to do a non-fast forward merge that will remember the commits, but also retain the branch information.

git merge --no-ff topic

Some utilities like “squash” seem like a bad choice for this because they toss the history out — bad for the developer. But this no fast forward merge can do the trick; retain history in all scopes.

(From nvie.com, Vincent Driessen, post “A successful Git branching model“)

The impact of doing development like this is far reaching. For the last years I have been on Subversion checking directly into trunk; and Hg managed a lot of merge and commit history with less work than Git. But the Git community has brought it to my attention — ALWAYS CREATE A BRANCH before you develop.

I wonder how this will impact code writing. Making a feature being aware that it should be able to be reverted when you check it in is WAY different than checking in non-accessible work-in-progress or hard coding out features.

My personal feeling is that to some extent this is a pipe dream. Many projects have some developers changing underlaying libraries while the rest build on top of them — the unit of a “feature” does not sit at the checkin level. So more hands on and use cases are needed to improve what we do, no doubt.

I’m not sure who remembers Yngwie Malmsteen. He was a hair rock guitar player from the 1980’s who was quite honestly the best technical guitarist I have ever seen.  If you get a chance look up a video of him playing arpeggios.  Fast and ON.

He started a band   They played around the United States and of course Europe and Japan.  Um, the world, if you will.

His songs sucked.  Bad.

So here you have a guy with unbelievable talent who can’t write a song anyone will ever remember (anyone except maybe patrons of The Zoo in Winnipeg ).

You of course know what I am getting at.  A lot of times the ability to write a solid, supportable, operational piece of software is more important than the micro-correctness of its parts.

I started to think about this because I was reading Joel S. blogs on hiring, retaining,  and on the so-called best developers there are.  Also because a company I was at had migration after migration of  talent, and kept hiring in the BEST people (so they thought) using the same technique to get them and lose them again.

One for example — was a code rock star they hired who blew the top off their entrance exams; you know, fizz buzz problems, what are the different kinds of state, why override an equals — all those things many of us do not do on a daily basis.  Not that it was important, these things are, but the guy couldn’t code.  He had never used any meaningful tools or had any experience with any real Java architecture, but *had* written a lot with vim and plain old swing type stuff.  In a nutshell, he knew everything about wood but didn’t know how to use a hammer and saw.  The outcome was a great struggle, and a lot of bad rewrites of code because of an inflated ego.  Code reviews would consist of arguments about where to put brackets and the role of “final” in local variable declarations. Never about how to make a better overall application that did what it was supposed to do.

I consider myself an plain old programmer because I have some things I am really great at and some things I am not — good at things like doing data, solving problems in adverse situations, writing web services stacks, thorough testing and getting along with co-workers.   I also have my shortcomings like having not worked on  many service busses, been a while since I’ve touched EJB, UI sometimes bores me (and I have written MORE than my share of Java and JavaScript UI code), and although can do config management (I have set up Hudson/Jenkins servers and integrated them with repositories, build jobs, management tools like Rally etc.) it’s just not my passion.  Plus my memory for everything pedantic just isn’t there.  I only can access so much information.

The few projects I have worked on that have failed ended up having a very opinionated Yngwie’s taking over the teams near the end game.   But they simply cannot tolerate other people’s non-perfection for their own (non)perfection.  One startup I worked on had a Flex front end some years ago, and while we needed a new customer site the Yngwie on that team shot off his mouth and had people expelled to build an unneeded rewrite of the admin piece.    Many of use believe   Code Rewrite is Company Suicide:

The Siren Song to CEO’s Who Aren’t Technical
CEO’s face the “rewrite” problem at least once in their tenure. If they’re an operating exec brought in to replace a founding technical CEO, then it looks like an easy decision – just listen to your engineering VP compare the schedule for a rewrite (short) against the schedule of adapting the old code to the new purpose (long.) In reality this is a fools choice. The engineering team may know the difficulty and problems adapting the old code, but has no idea what difficulties and problems it will face writing a new code base.

It’s almost like being with someone who is OCD.  Another gig I did had a dude who literally did Mark Wahlberg type karate kata in the bathroom mirror (aka the film Boogie Nights) and would come out and insult everyone into submission.  Code did not get written so well and that environment had a terrible blamestorming attitude to our daily existence.  We all cringed (or laughed).

How about a n Yngwie who writes his own build tool when things like Maven, Gradle, and Buildr exist already and are more than adequate?  Seen it.  How about an Yngwie who abstracted classes down so far they hierarchy was 12 deep needlessly?  Seen it. technical skill is fantastic — when used in the correct manner then  technical skill is awesome, when used properly.  But I think there is a bias in our industry to measure something incorrectly — that technical skill is the same as resourcefulness and creativity.

You ever see this video, about the Netscape Rewrite that supposedly put it in the can?  The one thing that sticks out to me in that film is that the people who created it were not the greatest coders, but they CREATED it.  Then later all the uber techno geeks come in and say “this is crap” even though they themselves didn’t invent a Netscape.

It takes all kinds of developers.  But one thing I watch out for is not getting enough opinions on a team.  Many times the Yngwie’s are the loudest and seamingly best choice to ask about something; but if they have no proof of being able to write the song then they might even be the worst coder on the team, the cowboy every manager so fears.

Personally I enjoy a team with a diverse set of skills.  Also, most people I know who produce code for businesses and make money at it are not Linus Torvalds stellar.    How could anyone be?  Heck would most places even pay for a Linus?  And isn’t our industry incremental — a few people making small contributions like a pizza ordering app here, a cool SQL algorithm there; with a few great leaps and bounds — much like Evolution?

It is my opinion that a good dose  of humility makes us all better.  So what if code isn’t perfect, writing code like writing a book is a genesis of getting better; in the application and everything else.

And like most business owners — I appreciate an Yngwie Malmsteen, but I love a George Harrison.

A great little exercise is implementing a sort comparator.

The problem is this:

1. Goal:  Write a concrete implementation to an interface “Comparator”  that sorts an object Zombie by Zombie’s last name property.  Comparator has a method “compare” that you will override with your implementation.
2. The  output is a new list sorted in alphabetical order by last name, ascending.
3. Provided are the Zombie object and the Service, and any information about Comparator.

I fired up my Eclipse editor and wrote it in about 20 minutes. I always use JUnit as a way to run the code — it’s a much better technique I feel than writing a main for this fun little test.

//First the main entity class
package main;

public class Zombie {

	private String firstName;
	private String lastName;

	public Zombie(String firstName, String lastName) {
		this.firstName = firstName;
		this.lastName = lastName;
	}

	public String getFirstName() {
		return firstName;
	}

	public void setFirstName(String firstName) {
		this.firstName = firstName;
	}

	public String getLastName() {
		return lastName;
	}

	public void setLastName(String lastName) {
		this.lastName = lastName;
	}

}

//Here's the service you will use to test your concrete comparator
package main;

import java.util.Collections;
import java.util.Comparator;
import java.util.List;

public class ZombieService {
	@SuppressWarnings({ "unchecked", "rawtypes" })
	public void sortByLastName(List zombies) {
		Comparator comp = new ZombieComparator();
		Collections.sort(zombies, comp);
		printZombie(zombies);
	}

	private void printZombie(List zombies) {
		for (Zombie z : zombies) {
			System.out.println(z.getLastName());
		}
	}
}

//here's the unit test
package test;

import java.util.ArrayList;
import java.util.List;

import main.Zombie;
import main.ZombieService;

import org.junit.Test;

public class ZombieServiceTest {

	@Test
	public void test() {
		List zombieList = new ArrayList();
		zombieList.add(new Zombie("Fred", "Munster"));
		zombieList.add(new Zombie("Count", "Dracula"));
		zombieList.add(new Zombie("Lilly", "Adams"));

		ZombieService zombieService = new ZombieService();
		zombieService.sortByLastName(zombieList);
	}

}


//Here's the comparator implementation  THIS IS THE SOLUTION!
package main;

import java.util.Comparator;

@SuppressWarnings("rawtypes")
public class ZombieComparator implements Comparator {

	@Override
	public int compare(Object arg0, Object arg1) {
		Zombie o0 = (Zombie) arg0;
		Zombie o1 = (Zombie) arg1;
		return o0.getLastName().compareTo(o1.getLastName());
	}
}

The output:

Adams
Dracula
Munster

I am thinking of doing more algorithm studies at a code meetup group I started, which would focus on the fundamental problem solving skills which we may or may not use at work. The idea would be to bring any compiler (maybe groovy, or clojure, ruby, pearl etc.). How about solving the fizzbuzz problem in SQL? What about Fibonacci with QBasic? Many languages, many people, many approaches, many funs! I’ll give it some thought …

I added the project to Bitbucket in the Zombie folder and its Eclipse files:

Zombie