Category Archives: github

GitHub isn’t your CV, and GitHub commits don’t show your talent

I previously wrote about how GitHub isn’t your CV, and went on the even close my LinkedIn profile because of how little value it actually provided.

GitHub’s eye candy

Lately, I noticed people posting things like diagrams of burnout based on a dwindling number of commits to GItHub. Once again, it seems like GitHub likes to invent metrics and measures that seem to me little more than eye candy. Yet I fear managers and engineers using them as hiring metrics.

As my best example of such useless eye candy, I will point out myself. I am a self dubbed editor-at-large for Spring’s Getting Started Guides. The side effect is that if you go check out all the guides, you’ll find my name spread across almost all of them. I can probably claim 80%+ of the commits as well. It makes my GitHub profile look crazy with bursty rates of activity. For a full comparison, compare myself to my colleague Roy Clarkson. GitHub is showing that I have over 2600 commits for the pat year while Roy has 610. I fear that if Roy and I were somehow applying for the same position, someone might use that crazy metric to make a decision!

The truth is, Roy is a project leader for both Spring Mobile and Spring for Android. Roy has tackled countless problems, and being a one-man-band for two projects, has tackled an armada of issues with no one but himself. Passing on him due to a silly metric would be foolish.

The reason I have so many commits under my belt is that I wrote a tiny script that made it easy to roll the guides whenever a new version of Spring Boot comes out. It looks like this:

#!/usr/bin/env python

import os
import re
import sys

if len(sys.argv) < 2:
    print "Usage: %s " % sys.argv[0]
    sys.exit(1)

with open(sys.argv[1]) as input:
    with open(sys.argv[1] + ".new", "w") as output:
        content = input.readlines()

        for line in content:
            if "1.1.9.RELEASE" in line:
                output.write(re.sub("1.1.9.RELEASE", "1.1.10.RELEASE", line))
                pass
            else:
                output.write(line)

os.rename(sys.argv[1]+".new", sys.argv[1])

That 22-line app has saved me hours upon hours of effort and allowed our guides to stay up-to-date with the latest releases of Spring Boot. It’s the reason that when Phil tweets about a newly released version of Spring Boot, I usually tweet about the guides being updated within the hour. My teammates have come to assume my answer to a given problem is, “I can write a script for that.” And this app is nowhere to be found in my GitHub profile.

All code requires context to be properly evaluated

That is the kind of code and context I would carry into an interview. It shows that I know more than one language. I know that not everything is a Java application. It shows that I also understand the dividends paid in saving engineering time. And it shows that I understand the value of keeping documentation up-to-date.

The unfortunate side effect is that GitHub now shows me with MANY days of having bursts of over 50 commits. The thing is, if you were to hire me, there is no guarantee that I would be knocking out 50 commits on key software components. (Unless I write a script that starts doing document updates the same as I do now.)

Hiring others isn’t easy

I have actually hired people in the past. Long ago, when I received my first promotion, my manager explained that I had reached a level where interviewing candidates would be part of my annual evals. I took that on full steam. I interviewed dozens of people. I quickly learned that the one hidden question to ask yourself is, “would I want to work on the same project, side-by-side, with this person?” As can be expected, not everyone was perfect.

But nothing in a resume or any other publicly visible metric tipped me off about the best nor the worst people that worked directly for me. One person took over the mission critical app I had led for years. He had new ideas I would never have thought up. Another was a copy-and-paste developer that couldn’t seem to learn new lessons. He didn’t last six months. There was no way to know this short of actually working with them for a few months.

People, please don’t pick pre-fabricated metrics and eye candy as your criteria to hire and fire. Use real talent and judgment. And be ready to ask yourself, if this person doesn’t work out, what will be your course of action?

GitHub offers more ways to develop than I’ve ever seen!

computer_coffeeHave you moved your code base to github in the past year? Earlier than that? Or are you contemplating heading that way.

There are means and opportunities you can’t possibly imagine when you do this. Of course, the immediate benefit is that 100,000s (if not millions) of developers will already be familiar with this platform for sharing code. It’s a great way to look at individual files, pick out lines, create issues, process feedback, and make contributions, all starting with editing a single word in someone’s comment.

But that is just the beginning. With the rise of forking, people can take projects in new directions. Experiment, prototype, throw away ideas that led into dead ends.

On top of that, the people at github invented the concept of organizations. A lot of people start with creating projects in their own personal space. But you can create an independent organization, and use it as the means to coordinate groupings of projects and other things. And get this: a repository isn’t confined to a releasable software project.

3021OS_mockupcover_normalRecently. I published Learning Spring Boot. All the code is available online for free. Naturally I want you to buy my book so I you can learn all the detailed semantics. But for those that have the book, they can grab a nicely distributed copy of the source and not have to type all in by hand.

Then when my editor started discussing some sort of contest where people submit sample projects built with Spring Boot, I realized that github was PERFECT for such an idea. I immediately created the https://github.com/learning-spring-boot organization, put the source code for the book there, and went on to set up a separate repository dedicated to the contest.

With github’s ease of forking and submitting pull requests, I have directed all contestants to fork the contest, code their Spring Boot application entry, and submit it as a pull request. That way, the judges can visit each entry and easily evaluate it. It also provides the means for contestants to tweet their entries, encouraging others to “star” their entries.

And who knows what will come next? If the contest is a success, we can always hold another one. Or whatever else we think of down the road.

The point is, by embracing github, you open the door to an incredible set of possibilities that you can’t even imagine right now.

Cheers!

The neatest feature of #git I didn’t know was there

I have been using git for several years now. But like any other tool, you don’t REALLY know all its power without using it in the craziest situations. I’ve just discovered a core aspect of git that totally drives me nuts given what it can do!!!

Git is a distributed version control system, right? Those of us using it with github are probably well aware of pull requests, making local commits, and doing various day-to-day operations. But something I didn’t understand until I had to process a pull request from the Spring community was exactly WHAT a git commit was.

Git commits are hashed. The don’t use counters, because they must be unique across any machine. You can’t depend on the counters working correctly. Instead, the idea is that people can develop separately, in another repository, and then submit pull requests to make a contribution. I as the developer can then merge your pull request. Sounds great, right? But did you just skim over that that sentence, “merge your pull request“.

What are we doing when we “merge your pull request“? It typically means we are pulling changes from your forked clone to mine, but once you realize that there is zero requirement for a relationship between your fork and mine, you discover that commits can be pulled into ANY repo and branch.

For Spring’s getting started guides, we have a central repo where people can write entirely new guides, and submit them as pull requests. But we don’t merge them there. Instead, we create a whole new repo and pull in the commits there. And we do that after you have made your contribution. If you look at those commits, it will appear as if everything was created, developed, and published there. But it wasn’t.

For any guide, the tentative author first creates a draft for a guide. Authors are encouraged to create a fork of that central repo and then start making their edits. At that point, everything can be pushed up to a branch. The author crafts a pull request. From there, we could merge back to the original master, but we don’t want to. Instead, we want each guide in a separate repo to suitably manage each guide separately. This lets us take all of the author’s handiwork, and put in that separate repo.

Basically, commits are self contained. If you develop something on one branch, and I development on another branch, it’s possible to merge both of these efforts into a third branch in a totally separate repository. And it doesn’t matter if one is a forked clone of the other. Clean things up, and we can turn this all into a pull request back to the original master. Or it can go elsewhere.

The point is, breaking up work into commits, sharing them with others on branches, whether on your fork or not, you can keep things nicely segmented. Then it becomes easy to hammer out issues and fold things together. And the side effect is that ALL commits retain their history, status, and who wrote what. You can squash things if you wish, whereupon some of the history is flattened. But this type of flexibility is incomprehensible when using something like subversion.

Chapter 2 shows #SpringBoot + #java + #spring #mobile + #jquery. Fun!!!

learning_spring_boot_ch2I just shipped off chapter 1, “Quick Start with Groovy”. Last night, I dug through and updated the code samples along with outputs to Spring Boot 1.1.1.RELEASE, which went out late yesterday. It really is awesome having that effort minimized thanks to AsciiDoc! Basically, I edited the code directly, re-ran the bits where I had captured console outputs so I could recapture them, and made other suitable updates.

Now it’s time to dig in deeper on chapter 2, “Quick Start with Java”. The neat thing with Spring Boot is that what would be usually trimmed down to toy apps due to space constraints can really show off some slick stuff.

ch2_fodtIn this chapter, I am writing an app that will scan multiple GitHub repositories for open issues and print them out on a web page. It shows the name of the repository, a hyperlink to the issue, and the title. I could put more, but I think this gets the point across.

From there, I will ramp up things wicked cool by adding mobile support. I’ll plug in super simple automatic view switching between desktop and mobile views thanks to Spring Mobile. And I will add a mobile view with jQuery Mobile. Given the rise of mobile-based apps, I think this will be VERY appealing to my readers.

And once again, thanks to AsciiDoc, I don’t waste time on typesetting code. Instead, I WRITE the code, and add explanations and details, a lot like writing reference docs. Yum!!!

Introducing…toolbox!

No, this isn’t a new open source project. Instead, its my toolbox of useful scripts.

I spent half a day figuring out how to limit network traffic on my system to emulate a customer’s slow network link. After manually typing ipfw commands to turn on bandwidth limits and then turn them off, I decided to capture the sequence in a command script.

Having just updated this blog site to include a link to my github handle, the idea became crystal clear: put the script under git version control and share it with others on github.

The pros:

  • it provides online backup of my toolbox of scripts
  • it is easy to version the updates and distribute them to my other boxes
  • over time, these scripts can probably be enhanced to run on other platforms
  • you can partake of the benefits!
  • hopefully, in the future, I can partake of yours.
The cons: none that I can think of
I hope you find it useful.