Its funny how the little things always hang us up. I get asked frequently what is the difference between git fetch and git pull at least once a week and sometimes it’s by the same people. This originally made me think that I was not doing a good job of explaining it but I am now realizing that it’s because I didn’t have a simple understanding of it.

Stick with me here. I love specifications, “rules that guide” if you will. Once when doing a REST API I decided to attempt to commit to memory Chapter 5 of Roy Fielding’s dissertation - it’s riveting you should have a read when you have a lot of free time (I personally liked it others might not). I was able to quote it and stand on the dissertation and RFC2616 to create an API that strictly followed the “rules.”

Ironically, learning the complexities of a given protocol or system and focusing on that alone has the potential to lead us down the road of inept teaching on the subject we call ourselves an “expert” of. That fancy RESTful API I built was stable, predictable and behaved to spec; and that was the problem.

The protocol choked the humanity out of the API and made it in some respects seriously difficult to use because of its rigidity. Some “got” it but most just got frustrated. I struggle with this because even as I explained the details of the specification a human connection was never made - I knew the complexities of REST but never grasped a simple understanding of it.

Being a better social developer today than I was ”yesterday” and opening my mind to the fact that most anything that is complex has simple pieces I now have a desire to explain through simplicity and drop the obscurity. Frankly I don’t have time to be obscure and explain things using the detailed schematics or protocols of technology - it’s wasteful and I want to get things DONE.

With this in mind let’s see if I can successfully do this with the fetch vs. pull question.

git fetch vs. git pull

Explained the old way (using obscurity and foreknowledge)

git-fetch : Right from the spec

Fetches named heads or tags from one or more other repositories, along with the objects necessary to complete them.

The ref names and their object names of fetched refs are stored in .git/FETCH_HEAD. This information is left for a later merge operation done by git merge.

When refspec stores the fetched result in remote-tracking branches, the tags that point at these branches are automatically followed. This is done by first fetching from the remote using the given refspecs, and if the repository has objects that are pointed by remote tags that it does not yet have, then fetch those missing tags. If the other end has tags that point at branches you are not interested in, you will not get them.

git-pull : Right from the spec

Incorporates changes from a remote repository into the current branch. In its default mode, git pull is shorthand for git fetch followed by git merge FETCH_HEAD.

More precisely, git pull runs git fetch with the given parameters and calls git merge to merge the retrieved branch heads into the current branch. With –rebase, it runs git rebase instead of git merge.

repository should be the name of a remote repository as passed to git-fetch(1). refspec can name an arbitrary remote ref (for example, the name of a tag) or even a collection of refs with corresponding remote-tracking branches (e.g., refs/heads/:refs/remotes/origin/), but usually it is the name of a branch in the remote repository.

Default values for repository and branch are read from the “remote” and “merge” configuration for the current branch as set by git-branch(1) –track.

Taught the new way (using simplicity and hindsight)

See image above.

So it’s dark and you’re on some back road driving like you own a light cycle. You come around a corner at blazing speeds and wham! You get hit with light from some on coming drivers high beams.

Given that you had yours on as well you quickly switch to low beams, just as your road comrade does the same. You pass the other driver knowing that he’s giving you the approving nod of good road citizenship because you respected the shared space the two of you where in.

The unspoken rule of quickly switching to low beams to show your common man respect and to play it safe isn’t a new idea. I sometimes wonder if two horse-drawn carriages were approaching each other, was it an expectation of the horseman that each would dim their lamps as to not blind the other with the shearing light of a 1x candle (I have a long commute into work)?

I also wonder, more appropriately, what unspoken road rules should I be following as a developer to show my fellow committer respect or what things can I do that will help them safely stay on the road? Here are my top five:

1 Respect the road - be a Boyscout not a Zealot

When I was a boyscout I was constantly told: “Leave the campsite in better shape than you found it.” We also had moments where we’d setup camp leave to go do boy-scouty things and come back and the leaders had changed the camp around completely leaving us all to wonder where our tents were. There is a difference between cleaning up and rewriting and there is an appropriate time for each. Working effectively with legacy code

2 Pull over to help someone change a flat

If you see someone struggling with code (especially code you wrote) stop and help them. It is a certainty that you will need the same some day and there is no telling what things you’ll learn by paring up. How to pair program

3 Stay out of the bus and bike lanes

Not that you cannot cross through those lanes but if someone is preparing for a release or trying to solve an issue in a section of code stay out of the branch that they are in unless you’re helping out (see above). Pushing code on top of something that is in “gold” or that is in an unstable state will just frustrate your code comrades

4 Cover your trailers

You ever been driving behind a truck or trailer and something comes flying out - you swerve, freak out and cause collateral damage. We all have technical debt, it happens. When creating new code make sure its covered; when changing legacy code make sure your changes are covered. The idea is simple: cover your code with tests - you’ll appreciate it and so will you’re road buddies. If you aren’t familiar with code coverage / testing checkout this quick tutorial to help get you started.

5 Maintain your car

Have you ever been behind that car that is leaking something or that is providing a spy-like smoke screen because it’s burning oil? Are you that car? Just like you maintain your car machine you have to maintain your code machine. Make sure to factor into your estimates or code-thoughts some re-factor time. Think of it this way, if you are not refactoring your code or you can’t think of better ways to do what you have done - you might not be learning anything. The fact is that there is no such thing as the holy-grail pattern; with every new framework or language or protocol there is often a “better way” or a more efficient approach. If you are afraid of changing legacy code, imagine what your manager or customers must think - maintain your car.

These are my top five “respect the road” rules - what are yours?

What could a developer say about the end of an 8 year awesome head-spinning journey and the beginning of an amazing God driven adventure?

1
2

craft> fellowshiptech.pop "Nick"
craft> newrelic.push "Nick"

For the past several months I have felt the absence of peace in what I had been doing at Fellowship Technologies. Not that I wasn’t putting my heart into what I did, or that the people aspect was making me miserable or even that the work was a tyrannical laundry list. Quite the contrary, even though sometimes it was a challenge to move forward because of process or technical debt I loved the people I was blessed to work with and I pressed into the work that we needed to do to try and make a difference in the world.

A little history before I go on…

Rewind a little over 8 years ago. I went to interview for a new gig at Fellowship Church in Grapevine, TX for a web developer position because I felt that I would make more of a difference in the world then throwing web bits at Gamestop.com (another awesome gig that I was blessed to have). I had the interview and I didn’t feel 100% about it, though that could’ve been because they were doing some things in classic ASP and talking about moving to PHP.

Later that week I got a call from the guy that I would be replacing and he said, “I liked what I heard in the interview - what do you think about going to do this start up thing with me and some other guys - we’ll be writing software for churches…”

I’m sorry, could you say that again? Did you say software for churches? I didn’t know there was a need for that. Apparently there was, in a big way.

I joined up, and they threw me and another dev in a closet at the church and… 8 years, 5 conferences, 4 different office buildings, more devs, a billion lines of code, 48 applications, a gazillion (sp?) rows of data, many really awesome people, a whole lot of long nights and foosball games, and one acquisition and IPO - here I stand a changed dev; a changed person.

So where is the peace?

I’m not going to go into some long diatribe about the hardships I faced because frankly there really were none. Sure there were things I dissagreed with or got frustrated by but Active is a great corporate body trying to solve some really hard problems. So then, why am I leaving?

My first motivation is something I have been fighting for months now - God has been telling me to pick my mat up and move. Bottom line, as a Christian, I could not avoid the pull. I mean, after all why would I move? Great benefits, I was comfortable / confident in what I did, great support system in Texas, loved the people I worked with - why would I not have peace?

Second, my wife and I had grown so much in our marriage with God we could face what a complete family reboot meant - so our hearts were in the right spot for change. We agreed that no matter what, if we disagreed on anything around change we would not do it.

Third, I read and understood the holstee manifesto. I remember talking to my wife telling her that I really felt like I was not good enough to do anything really “great.” To which she promptly replied, “You arn’t. Quit trying to rely on what you think you know and rely on the plan God has for you.” Boom! I love my wife.

What did I do about it?

After getting the pride smack-down by my beautiful wife. I decided to list out 7 companies that inspired me; that, as a dev, I looked up to. I then wrote a few thoughts down on why I would want to be a part of the amazing work each company was doing.

Flying is learning how to throw yourself at the ground and miss.

New Relic was, of course, at the top of the list. As a dev how could you not look up to and admire the shockwave they have sent through the worldwide developer ecosystem. They have fundamentally changed the way many developers and Ops guys work together - empowering developers worldwide to get better by understanding what is actually going on with, and how to fix their software - who wouldn’t want to be a part of making dev life’s better?!?

The engineers at new relic have done for monitoring what DHH and Matz did for software - they have revolutionized how we make great bits. New Relic genuinely cares about their people and the developers they serve and it is evident time and time again as we use the software and as I interact with the team. There are some of the most ingenious and brilliantly minded people in that group. It is literally a polyglot’s paradise where they have guys who are experts in Ruby, PHP, Python, Java, and .NET and they all work together innovating on an amazing product - there is no company out there like it!

So I took a leap. I was swooned by the amazing team and the love they showed me right up front and the hard to miss excitement everyone had for what they do there.

Now what?

1
2

life> rm -r "/God/FloydFamily1.0"
life> mkdir "/God/FloydFamily2.0"

My family (5 rock solid kiddos and a beautiful and patient wife) and I are doing a complete reboot - moving et. al. Are we sad to be leaving our friends and family, yes definitely. Has it been easy, not entirely but we trust in how we are being led. I am humbled by how orchestrated this entire thing has been from it’s beginning until now - we are definitely looking forward to the adventure.

Find me on the Twitters if you ever want to chat about life change or geek out over tech.

[tl,dr] Ask yourself (and your developers) is what I am doing what I want to do? If I am doing side projects what makes those so interesting? Because if they are really where I volunteer my “free” time then why is that not my day job? If your still struggling with the questions read the holstee manifesto for some inspiration, then come back.

Often times I hear developer “happiness” come up when turn over happens. It’s all part of the “game” right? As a creative, why would you stay somewhere that was not helping you become a better painter or a place where you would get really excited about what you do?

To be pragmatic, I feel like I need to claim reality as well - we as devs also need / have to do the grimy grind work because not every line of code creates an epic bloom of fireworks. Face it, we have to mix our paint if we want the really cool colors.

I’ve been thinking a lot on the signs of complacency or waining enthusiasm developers face on long running projects; what keeps us motivated and how do we recognize that the “passion” has left? Then I thought ”soup stone!”

It’s funny how a common cause motivates people. For instance if you’ve ever done the startup thing then you know that everyone has a lot to do and has many hats to wear. Generally there is never much whining about what they “want to do” rather there is a lot of moving on what they “need to do” - need becomes want because of the cause.

Let’s play a little metaphor game with the soup stone folk story:

Say that the stone is the company (because without people and product all a company really is, is an idea, a dream) and the ingredients added to the soup by others is the code that is written to motivate and move the company. What happens if your developers start pursuing other projects on the side and take their ingredients there. Why would they do that? What would motivate them to continue working on the mythical soup to make it a real soup?

Sharing is a massive problem for companies.

I’m not talking about OSS necessarily but something along the lines of the mentality where “as developer in company X I am not challenged nor am I motivated to be exceptional therefore I will go make products of my own that do excite me.” On one hand you want your developers to be challenged and grow, on the other hand wouldn’t you want your developers to be so excited about what your doing to not have to go and do the side gig thing to get the dev itch scratched?

Is it possible to ask a dev: “what can we do to get you more interested in what you’re doing here?” - who wouldn’t want to be energized and excited about their day job allowing you to make your night job “life.”

When you use software do you find yourself to be frustrated or helped? When I design or build something I have a hard time seeing it from the end-user’s perspective; I get too excited about the idea or flash of potential.

Detaching myself and deciding that I am a user rather than the developer is hard for me. I used to find it difficult to watch people use the software I created… always wondering if it was good enough, if they’d like it or if I created an app where people become pixel hunters waiting for alt text to appear rather than users trying to get something done.

I really don’t feel that way anymore, the fact is it will never be good enough or perfect it will just be what it always has been - my best effort. If it doesn’t work I’ll start over or change it; if it does make someone’s life better then I’ll do something else.

One of the most amazing things about creating software is that if you did it once, you can do it again and most likely you’ll do it better. One of the best ways to learn how to get better is to be quiet, watch and experience your software with your users and listen to everything they say, even if you disagree with them - especially if you disagree with them.

Here’s a book I pretty much keep in hand all the time: Continuous Delivery by Jez Humble and David Farley. Not that it’s a really super enjoyable read, but it helps me remember how doing this software thing we do can be awesome for both the dev and user.

This book is primarily focuses on Continuous Delivery and not Continuous Deployment per se, it etches into an architectural area (around pages 347-349) that I feel every software ecosystem should have.

Feature Dark

dark side rule #1: Releasing small, even unfinished bits into production is ok and will actually save you from head aches.

Delivering features into customers hands should be exciting not terrifying - how many of you have placed bets on the success or failure of a gargantuan release? Why do we have humongous deployments that are scary? Being big and scary didn’t really work out for the dinosaurs did it and it won’t work for your software either. Create a parallel page, work on the model first - do something other than stop to wonder how you’re going to eat the elephant (i.e. big things need to be eaten one bite at a time).

dark side rule #2: Putting software into production does not always mean that you are putting it into the hands of your users. Your software should have toggles that turn features (partial or otherwise) on for either some or all users

I believe that developers should be able to release code right to production, bottom line. If you disagree then you either need to get new developers or you need to start trusting the ones you have. I also believe that every commit after going through quality gates should go right to production once it hits master.

Write your code so that if the doomsday scenario of someone elbowing the keyboard won’t put your latest UX redesign in front of your customers. Histrionics aside make your software “releasable.” Don’t expect a magic bullet here either, this will take team maturity and some patterns for everyone to stick to (like the ones @chadmeyer and I created - pushing features dark). Best idea here is to come up with an easy to understand / use patten and make sure that the business is tooled to flip those switches.

dark side rule #3: Let your business worry about releasing the software to the customers and let your developers worry about writing and deploying said software

See - cd vs. cd. Look @ your keyboard, go ahead I’ll wait……

If the symbols <,>,{,},# are worn then you are a developer. Do what you’re good at - write and deploy code.

If the # key or the letters a,t,t,n,. are worn then you know who you are. Go put the software developed into the hands and minds of the customers

dark side rule #4: Your features might not always fit into or be able to be feature dark

You just won’t. There will be organizational challenges, changes, events and technical roadblocks that will take time to get past. The goal here is to incrementally get there. Be pragmatic.

dark side rule #5: Ruled by fear your competitors are… deploying software all the time you will be…

See amazon, flickr, so on.

Note: The dark side rules are my own creations and are only based on my experience with what works and does not work while I have been in dev shops trying to achieve CD, so take them with a grain of salt to season your own rules.

What is it about bit-rot that seems to drive us away from quality? Here’s the analogy:

Let’s say you just bought this massive steak that you’re going prep before the game. So you know you’re gonna create an awesome rub then toss it on the grill at a solid 600° and just go to town on the beautiful cow bouquet.

You get to the counter and it is covered in the remanence of last night’s game fest. Baring any cultures that the CDC might want to take for posterity do you really stop and think… “Hmmmmm, should I clean the counter before I do the rub throw-down on this $50 steak?” No you don’t… so why do we do it with the code we write?

You’re in some pretty rough code and you add a beautiful bit of code to it, do you leave the other bits around it trashed; lipstick on a pig. Word to the wise, be a boy scout, leave it in a better condition than you found it.

Docs:
apidock
railsapi
rails guides
envylabs rails cheatsheet

Teaching tools:
hackety-hack.com/
codeschool.com/courses/rails-for-zombies
codeschool.com/courses/try-ruby
rubylearning.org/
railscasts.com/
teachmetocode.com/
rubyrogues.com/
ruby.railstutorial.org/
guides.rubyonrails.org/
rubyflow.com/
refactormycode.com/
pry.github.com/

Screen / pod casts:
peepcode.com/screencasts/ruby-on-rails
rubyshow.com/
www.destroyallsoftware.com

irc:
#rubyonrails (irc.freenode.net)
#ruby (irc.freenode.net)

Books
Why’s (Poignant) Guide to Ruby
The Pickaxe
Beginning Rails 3
Beginning Ruby
Humble little ruby book
Exceptional Ruby

As I sit here listening to the TRON soundtrack I recognize that the flashy code of movies like TRON, anit-trust, hackers and the like have changed the ideal picture of what coding something looks and feels like.

I have to admit, Hollywood makes slamming out bits look cool and easy - not nerd cool like node.js or mongodb but more like socially acceptable “teen” cool like eating Pringles, drinking mountain dew or jolt and getting away with “something.” Right now I am snacking on Pringles and drinking mountain dew - the propaganda worked!

Though my boys haven’t seen those movies they are familiar with the “hacker” architype of a guy mashing keys having code fly across the screen to save the world from total meltdown! So, as I expected we hit a productivity wall with the “code” part of this project.

Needless to say here is my 6 year old’s first lines of code:

    public Earth(){    
        super(750, 750, 1); 
        addObject(new Turtle(), 0,350);
        Greenfoot.playSound("mnhaon.mp3");
    }

and the 4 year old’s in the Turtle class:

public void act(){
    moveLeft();
}

It took us roughly 30 minutes of them typing (20 minutes) and going through the greenfoot API docs by themselves (10 minutes) to get that done. At this point and time they saw a turtle run left across a white screen and they were done, shutdoor. I expected this so I did have a back up plan….

Making media for the game: They spent the remainder of or time making trucks, turtles, backgrounds and recording sounds for the game. I wrote the remaining code and added some snips from Michael Kölling’s blog.

What we learned:

• Making games together can be fun and we can actually get something enjoyable done in a short period of time.
• Greenfoot is a great platform for new developers and there are others out there such as: Alice, Kudo, scratch and others, so there is really no excuse to not teach your kids if they are interested.
• My boys were too young (6 and 5 years old) to code. Kind of obvious but I really wanted to see where they were at as far as logic thinkers - I was impressed with there ability to articulate what they wanted to do all I had to do was write the code

The bits:

• Framework: Greenfoot (Java)
• Hardware: imac
• Time: roughly a week (1hr per day)
• Process: scrum
• Output: source | game in gallery | stand alone game

If you have time please let my boys know what you think about their project, I know they’ed love to see your comments and thoughts, they worked really hard and I am super proud of them for doing all that they did and trying as hard as they did. Related posts: kid gamification - planning, kid gamification - day 1, kid gamification - day 2

The boys wanted to get stomping on the project code right away (I did too) but I knew this would be a great opportunity to distill some of the assumed magic of code and that it takes a lot more than copy-n-paste and a browser. I think a lot is gained and lost on the magic of the interwebs with the “it just works” mentality. Not that things have to be difficult or over baked but I believe that there is much to be gained for having a “big picture” perspective to software.

Today we focused on:

• getting our project all planned out using sudo scrum (didn’t want to get wrapped up in teaching them the process in depth; just that there is a process and it can help)
• a repo going on github
• creating a greenfoot scenario
• theme music - because every great game has cool theme music, and we were doing a lot of admin stuff for the project and I wanted the kids to have fun mixing music.

Project planning:

Using scrum, we generated cards and hijacked the grocery list whiteboard and began planning. I asked the kids questions like what do you want the game to do?, how do you think it should work?, how will you play the game? what do you want things to sound like? and so on. Their answers, to my surprise, were somewhat practical for a 5 and 6 year old. I assumed that they would say things like, “I want to control the turtle with my mind,” or “the turtle can fly and breathe fire to destroy the trucks.” The answered with we can use the “arrow keys” or “w:a:s:d” to move the turtle (apparently we need to lay off the games, their familiarity with default game controls and their ability to name them was frightening). Here are the resulting cards from their answers:

• Make game sound effects(truck sounds, turtle sounds, turtle getting hit sounds)
• Make code project
• Make story about why the turtle is doing what he is doing
• Make the turtle and truck graphics
• Make place to put our code so we dont loose it
• Make music
• Make turtle move
• Make trucks move
• Make world for trucks and turtle

Getting a repo going:

I let them type the commands in terminal, they said it felt like they were super spies trying to save the world (I never really thought of it that way…)

We…

• generated ssh key - just follow the instructions here
• setup a github account - just follow the instructions here
• created a local repo - - just follow the instructions here
• pushed the code

Creating a greenfoot scenario:

If you are parent of really young kiddos with limited attention spans like me I would recommend going through the greenfoot tutorial before you begin your senario with your kids. The tutorial will get greenfoot setup and get you aquatinted with the greenfoot API

Creating the theme music:

This was pretty fun. The kids mixed samples using Aviary audio editor. You can listen to the sample mix here.

Once we did the mixdown on the samples we made into an mp3 using the same tool and added it to our github repo.

That was it for today. Tomorrow we should have some working code g2g. We will spend the next 3 days working on code, testing and content. Finishing the game at the end of the week.

Related posts: kid gamification - planning, kid gamification - day 1, kid gamification - day 3, the finale