10,000 Foot Developer

I’ve tried my hardest over the years to simplify things, but tools are tools.  A developer’s existence is tools.  When I think about it, sometimes the paradigm is like a good cook where less is more; for instance some people like using 1 IDE for everything — SQL, Java, Javascript.  Although I do cook like that (a good knife does almost everything for me) I kind of stopped doing this as long as the tools are lightweight.  For instance, I can’t use the Springsource Tools version of Eclipse it is too heavyweight and interferes with my other plugins I like to have many times.  In that case, I am more like a mechanic where a specialty tool brings home the bacon.

Also, I always have Windows and Linux around even at home.    So here’s what I’m working with now.

Two Development Boxes

• Fedora 19 with Gnome 3 (one Swing project)
• Windows 7 (three projects, web services)

On the Fedora 19 Machine

IDEs

• IntelliJ 13 Community – is my primary development environment. I need the superior search utilities because the Swing project is massive, at least 1/2 million lines of code.
• Eclipse Juno – because the rest of the team is using that; I have to keep the environments up to snuff.
• Gedit

Languages

• Several JDKs 6 & 7, 32 and 64 bit. I run the Swing app in 32 bit (per requriements) and run the IDE’s in 64 bit.

Tools

• Maven

Repository

• Git
• GitG – for a gui. I always eyeball my stuff before checkin.
• SVN

Data

• MySQL and Workbench

Network

• Terminal
• VNC

Servers

• JBoss 4.3.0.  Yep.
• Apache

Browsers

• Midori
• Chrome
• Firefox

Office

• Open Office

On the Windows 7 Machine

IDEs

• Eclipse Juno for one project
• Eclipse Kepler for the other projects.
• Notepad++

Languages

• Java — same thing with the multiple JDKs.  Plus, Windows is nasty about its own installation.
• Groovy
• Scala
• PHP
• Python
• TCL
• Perl

Tools

• Maven
• Visual VM
• Gitstat
• StatSVN
• KeepFocussed
• Cobertura
• KDiff3
• Portable Apps
• jSimpleX

Repository

• Git
• TortoiseGit
• Git Gui
• Svn
• Hg

Data

• SQLite
• SquirrlDB – a jdbc sql gui
• DBeaver – another jdbc SQL gui

Network

• MobaXTerm
• VNC
• Fiddler
• Putty
• Wget

Servers

• Apache
• Tomcat
• Jetty
• HFS
• NGinx
• NodeJS
• JBoss
• Jenkins
• Gitblit

Project Management

• Fossil
• Kanboard

Browsers

• Opera
• Chrome
• IE
• Firefox
• Safari

Office

• Microsoft Office
• Microsoft Outlook

Notes

• I always zip up my IDE setups for backup and quick sharing/replication if needed.  Also, I find it best to work on a project with its own IDE especially with Eclipse.  There’s always a different team with different preferences, so its almost unavoidable.
• I always portablize my JDKs. Can’t stand it when a JDK has to be “installed” and I have no admin rights on my Win 7 machine now anyway. Lot’s of pathing.  I have everything set up in both operating systems so I can use paths to solve problems.  None of this installation stuff if possible.  Even Linux distros are getting too “instally” for me these days.

I do not use the Spring Eclipse IDE or any other monster-plugin collections. I prefer as slim an IDE as possible. That said I use these in Eclipse, and install like ones as needed in IntelliJ.

• M2E for maven
• EGit
• Anything SVN — the connectors for this are still a pain in the backside though
• Eclemma/Cobertura
• MoreUnit
• FindBugs
• CheckStyle

The point is to be able to write, generate, and test code and do analytics on it as fast as possible.  Also, I prefer external servers for debugging vs. the internal Maven-pom style server plugins.

More configure = good.

Vanilla from box = good.

Ciao for now.

Bad Developer!!!!!!

I was working with an “expert”. He was working on a major refactor that was going to break several hundred of our tests.

Now, probably the best way to do this with ANY repo would be either to branch and make the change, and then do the fixes and merge when it was all good — or just not check in at all. Just stay away from everyone else’s working code!!!!!

Well guess what — the expert made a big boo boo. HE WAS SUPPOSED TO BRANCH DAMMIT BUT DI’NT!!! He did the code change and then did his incremental check in, and proceeded to push ALL the test breakages to the main trunk!!! Well, we didn’t have a Jenkins job running on our trunk to check it (we used git svn, and the job ran on svn/Jenkins while we had our skunk works).

Seeing where this is going? Right. Now the team all checked out and rebased to the breakage. This cost us several hours as a team to resolve. The expert was quite sorry, but also blamed it on no build check. I’d have more sympathy if that particular person wasn’t the one who was the repo nazi for our team. Tsk tsk.

I also ran into an interesting situation.  This error had messed up a lot of my local changes.  Although I’m in the habit of stashing before I check out, I don’t build between checkout and applying the stash  — and then I usually stash pop in the prescribed manner which generally blows away any hope of reapplying the stash again.   Fortunately I had an OK stash I could use, and rolled back before these errored commits came in. Then I branched – which in effect made my branch the trunk while I waited for the fix.  Applied my stash into my branch and continued until the guy fixed what he had.   I could have branched his stuff, checked it in as a remote branch, and rolled the master back but I decided not to out of respect for him to fix his error.  There were some messy merges along the way with this, very time consuming.

There are some very important things to learn working with these distributed repos.

First, a build server is a good buffer for monstrous breakage. But . . . in this case we were all pulling quickly as we worked (me and another developer swapping code changes) so we weren’t waiting for the builds to check out. Do you wait for a good build before checking out? What ensures you didn’t get something in between the build and the result? Nothing . . . . even on a locked down TFS system some years ago we still ran into this problem.

Second, no matter what greater deity of code you may be, you are fallible. Check yourself over and over, more than a monkey looking for lice in its fur.

And third — distributed repos haven’t solved this problem at all.

A new workflow could be deduced from this:  build,stash, build,pull/rebase, build, stash pop,build.  hahaha  🙂   Also, we could all start getting that nervous Ctrl-S tick I have back from the 1990’s, but manifest in git stash over and over.  I do increment commits which require builds — but this behavior also raises the question: should we *even* increment commit if our local build doesn’t work? It could create an accident such as this.

And what if your build takes a LONG time?  Such as the TFS worksite — upwards of 25 minutes with integration tests!  Sweet Fancy Moses . . . .

I suppose one way to fix this would be to pull the revision from the last greatest build. Maybe something can be configured in Git or Hg to do that? Dunno.

The one thing I REALLY love about distributed version control is the ease of branching. There is nothing like it. If you are currently on SVN you know what a pain it is to check out another branch and switch your workspace over, or (gag) try to roll back your local. Not so wtih Git or Hg. Another thing I love is the simplicity to roll back to a previous pointin the code. Super easy, almost zero time.

QA found abug in our code that was assigned to me with these conditions:

• Bug in QA deployment (released 2 weeks ago)
• Bug in DEV deployment (questionable release date)
• No bug in my development machine code.

I couldn’t pinpoint any relevant fixes in the code with a ton of developers checking in on the same files and it looked like DEV code hadn’t been released since QA although the build engineer couldn’t answer that for me.  I dug through the build numbers and it made me more suspicious.

Perfect scenario to branch, rollback, and test. So here were the steps I took from the command line:

1. Made a branch to work in:

git checkout -b oldCodeBranch

2. Check the status to make sure I’m good, and on the branch:

git status

3. Listed the commits so I could grab a commit hash to roll back to:

git log –pretty=format:”%H %cd %an %s”

4. Roll the branch back to the hash, discarding any future changes:

git reset –hard f8b720b2a3

5. Build

mvn clean install

6. Debug

A variation on steps 1-3 if you know the hash (maybe from Tortoise Git; still trying to figure out if Gitg is useful):

git checkout -b oldCodeBranch f8b720b2a3

So this solved my problem:  the bug was fixed but not yet deployed.

I found the error right away; and that the DEV environment build hadn’t been released since the QA release (grrrr what’s the point of DEV then!!!). Then, switched back to master in the blink of an eye and deleted the branch. The speed at which I could accomplish this in Git with such little pain is awesome. Plus, for this particular project I am using git-svn to front the SVN repository, but once I get the code it is *all* in git-land until I push it.

I want to stress something here: the speed an ease that I accomplished this task, compared to something like SVN.  Until a developer goes through these mundane daily tasks they can’t appreciate it and I do, now.  I really encourage using something that lets you branch and change around in your system with ease be it Git, Hg, or anything else.

Check this line out I received from a mouth-breather blindly spamming developers:

Ideal Candidates will have REST or RESTful web services, Spring, Linux OS and a Linkedin Profile.

Woah.  Since when did having a LinkedIn profile become a necessity for being a developer?

More companies are coming out with pre-screen personality tests, requirements to obtain your contact lists and social media requirements — for instance something I mentioned before, where a company said it owned any contacts I made while on my gig — phone, email, social media.  No shit.  I didn’t sign any of that.

Jeff Atwood, Co-founder of Stack Overflow, opted out of LinkedIn years ago questioning the benefactor of such a site.  I have an account but I barely use it.  I do know some, very few, developers who *have* benefited from LinkedIn; and many are on Google+ now.   I also know that recruiters want access to contact lists and have reports they run on LinkedIn data to see if positions open up or companies have activities that may indicate sales opportunities.

I certainly am not hooking up just any strange sales person to my linked in account even if I had 1000 job leads.   For years I’ve gotten spam out of the blue to hook up with strangers on LinkedIn.

Most of the developer groups I’ve seen on it are started by recruiters;  if they throw an event it would be best to show up to this in person and network in person.  That’s how it works for me.

Anyway, I see this as a major “data mining” flag when a company emails out a LinkedIn requirement.  Although it doesn’t say you have to network with them . . .and I wouldn’t.

So — you are using distributed repositories (DRs) like Git or Hg.   And you are thinking — why the heck use branching?  Branching is great for local one-offs but I can copy/paste for that!”

I admit that I have struggled with this questions as well — for instance thinking that SVN is just as good of a tool for developers.  IN the beginning people pushed these DRs but we never, ever used them in the manner that they were intended; they were just shiny new toys.  Some of us, me included, took a lot of guff for not being the earliest of adopters.  After a lot of hands on over the years, working with these repos the correct and incorrect ways I finally have solid arguments for using distributed repositories, especially when it comes to branching.

Note this is *not* in any way an anti-SVN post; that repo has great tooling and was revolutionary when it came on the scene.  You can even use plugins like git-svn with some success in front of a central SVN repository; and in many ways I find build masters preferring its branch and tag methodology.  But I would argue that from a developer’s standpoint a distributed is tough to beat.

1. Fluidity
2. Ease
3. Sharing
4. Functionality

Fluidity

For me the definition of fluidity is how much something aides your development process.  A DR seems in the way at first with the double-check in steps . . .check into your local, check into your central.  But once a developer sees the advantage of the local repo it becomes much easier to create batches of changes locally and then push them up to the central repo.  (Central repo is usually where the build server points and everyone agrees to push to).  DRs accept the merge bumps we all run into and make it part of their process . . . so development becomes something with less in the way.  You can worry less about the checkin  process.

Also, their is the speed of creating and switching between local and remote branches in a DR; uber-fast.  This alone in hands-on makes these tools worth it.

Ease

Have you ever had to work on a branch in SVN? Check out the whole thing and switch workspaces with your IDE — what a pain.  With Git (for instance) I just issue a git checkout branch and nothing else needs to be done. That’s as easy as it gets.  Adding and committing are all as easy as any other repo.

One thing is with RVs is that it’s also *easy* to get into trouble with merging and getting code out of sync.  These systems are more sophisticated so that’s part of the problem.  Git has the merge/rebase  wars, and a lot of time in Hg and Git you’ll see unintended branches pushed out by new users.  This is OK, it takes a while to learn.  Make the learning process easy.  All too often I see an experienced person blowing up on a newb forgetting that they too usually can’t write documentation and probably made the same errors.

But — the flow makes you do small commits; this in the long run helps keep you out of trouble. Easy!

Sharing

Remote branches are SO simple with a DR.  Since they store their diffs much differently — and SVN has to create whole new copies of directories, the speed is so slow comparatively.  Team members can share remote repos in seconds, and with Hg and Git you can fire up local servers in your local directory for sharing right away sans central server.

If you sit down and work with the tools — SVN, TFS vs DRs it doesn’t seem obvious off the bat how this might work.  I have some use cases below that, when you run into them can immediately see how useful sharing becomes outside the central repo; it is very powerful and not immediately obvious to non-coders as to why.

I mention this because often non-coders get to pick the big tools: people like management, paper architects, PMs and build masters, maybe even QA.  Their input is important, but as a developer not always relevant for *doing* the work.  I guess that’s why there is git-svn as a compromise and/or transitional tool.  Sometimes newer management and QA tracking tools, Rally for a while, only worked with more legacy repositories like SVN and TFS.

Functionality

I am a combination command line/UI person.  For instance, I always make sure my build scripts can run on the command line (as will the build server) and in my IDE which is usually Eclipse, sometimes IntelliJ.    You can get intra-build errors that are difficult to debug if you don’t master this.  With a DR — you simply get more tools.  The command line options for Git are endless; I love the interactive staging UI on the command line (git add -i); I also use Tortoise for eyeballing all my files, it lets me add/commit at the same time; the log and branch viewers are fantastic and picking out commits its simple.  The amount of commit history is great as well.

In fact DRs really make you think beyond coding as to how you push forth your code.

—

Some Workflows

Commit types: Build masters and managers are more concerned with feature pushes and rollbacks on a macro level; developers with micro commits and history.  I find DR tooling makes this workflow much simpler.

Branching: A lot of times when there is a large test suite and a refactor or major requirement change must go in a lot of those tests and other code will break.  The main build must not break.   The best way to handle this, with ease, is to use a Git or Hg branch; make your changes while consistently merging trunk into your branch; anyone can work on it as well.  Fix everything, then merge back to the trunk (after a merge from trunk of course).  This is one of the most powerful and easy to do activities with a DR.  You’ll know it when it happens to you.  Many times you can do this by yourself with SVN by just not checking in and making updating from trunk; but you don’t get the ease of branching or the ease of sharability.

Postscript

Using DRs properly and leveraging the features is not immediately obvious; you have to dig in and experience it to see why they might deliver more value.  SVN and TFS are certainly very adequate; I like SVN’s integration into everything there is and I like TFS’s concept of a shared shelveset.  Many build masters prefer SVN’s straightforwardness for *their* tasks.  And SVN was certainly maligned (to CVS for instance) when it first came out.  As developers we should avoid harsh orthodox judgments and see if something will actually put forth value or if we are just doing something for newness/coolness sake.

It’s taken years to see the value for me because almost everyone doesn’t branch/develop the same way on different sites. I guess that’s the lesson.  Again, deferring to SVN which was the first repo to put out this mantra while they were still hosted on tigress.org: “We don’t provide you with a process, just a framework to do YOUR process.”  Brilliant.

And someday there will be something better anyway.