Even though Octopres uses Jekyll for generating pages it's layout and the way they expect you to use it with Github Pages is actually quite different. This is my recipe for migrating:

Layout Overview

Now with Jekyll-Bootstrap your directory structure probably looks something like this:

Hal9000:ryber.github.com ryber$ ls
404.html	_includes	archive.html	changelog.md	sitemap.txt
README.md	_layouts	assets		index.md	tags.html
Rakefile	_plugins	atom.xml	pages.html
_config.yml	_posts		categories.html	rss.xml

Your site and the Jekyll code are interwoven. You probably have it all on one branch, and when you push you push the entire thing.

This is not the case with the standard Octopress layout. It looks more like this:

Hal9000:ryber.github.com ryber$ ls
CHANGELOG.markdown	_config.yml		public
Gemfile			  	_deploy			sass
config.rb		    source
README.markdown		config.ru
Rakefile			plugins

Everything you see here with the exception of the _deploy folder (which is listed in the .gitignore will be kept on a source branch in git. The contents of the _deploy folder will be your production branch. Almost all of your work will go into the source folder.

In order to get to the right state we are going to be a little sneaky as we move things around.

Pre-reqs

You will need at least version 1.9.3 of ruby. If you don't have it yet I suggest installing RVM.

After installing make sure you have 1.9.3 like this:

rvm install 1.9.3
rvm use 1.9.3
rvm rubygems latest

The old switcheroo

OK, so what we need to do now in order to get everything into the right place is to move the "main" directory into a branch and keep the master in a subdirectory.

So first make a backup copy of our current state. and then go into the original.

cp -r ryber.github.com/ old.ryber.github.com
cd ryber.github.com

next we need to make a source branch where our Jekyll is going to live. After doing that delete all of the content from the branch.

git checkout -b source
Switched to a new branch 'source'

git rm -r *
git commit -m "clearned out everything from branch"

Next we are going to get the octopress content and copy it into our directory without the git history.

cd ..
git clone https://github.com/imathis/octopress.git octopress
cd octopress
git archive master | tar -x -C ../ryber.github.com 
cd ../ryber.github.com
git add . 
git commit -m "added octopress content"

Now lets make sure we have a working octopress directory. When you CD'd into the dir rvm probably asked you if you want to trust the rvmc file. Do so. Now set up the app:

gem install bundler
rbenv rehash    # If you use rbenv, rehash to be able to run the bundle command
bundle install
rake install

Now we are going to clone your original master branch into the _deploy dir. Yes this is kind of weird. The outer directory will be on the source branch and the _deploy dir will be on the master branch.

git clone https://github.com/ryber/ryber.github.com.git _deploy

Migrating content

This is the hard part. Copy your content over from the /_deploy directory to the /source directory. This is not going to be an exact science. Take a look at what you've got and migrate as neccessary. Your milage may vary.

You can probably get 90% of what you need with these two:

cp _deploy/_posts source/posts
cp _deploy/assets source/assets

The _config.yml file

The two config files are a bit different. You can't just copy the boostrap file over so open them both and copy the individual settings over that you need.

Preview

Run the site and check it out. Make sure everything is what you want it to be. When you do a preview Jekyll will place your files in the public directory (which is also ignored by git)

rake preview

Final Steps

Before you do this check the Octopress rake file and change the deploy_default method to "push". You will find it in a section at the top that looks like this;

## -- Rsync Deploy config -- ##
# Be sure your public key is listed in your server's ~/.ssh/authorized_keys file
ssh_user       = "user@domain.com"
ssh_port       = "22"
document_root  = "~/website.com/"
rsync_delete   = true
rsync_args     = ""  # Any extra arguments to pass to rsync
deploy_default = "push" 

Now we are going to replace your old site with the new site (at last!)

We need to clear out all of the files on the master branch to make way for the new content.

cd _deploy
git rm -r *
git commit -m "cleaning house"
cd ..
rake deploy

When you do the deploy it's going to:

• generate the site and place the contents into the _deploy directory (your master branch)
• add and commit everything present to git's origin master.
• push the master branch to github.

Last don't forget to push your source branch to github!

git push origin source

I have been working as a software developer for about 15 years and I’ve never once feared I would not be able to find a job. Through two recessions, one of which was the biggest economic catastrophe since the great depression, I’ve always had options. I don’t think of myself as a particularly special individual.

The first tech company I worked for (a start-up), folded when the founder’s mom pulled our funding. I had a job less than a week later. The second company I worked for was bought by a competitor. Even though I was not let go myself, my inbox and voicemail were flooded the day it was made public. I was able to leisurely browse and consider offers from all over town. Many with friends who wooed me with lunch and booze. Everyone was hiring. My co-workers who were let go all had jobs within a month. Most of the rest of the staff quit for greener pastures over the following six months. This was during the middle of the worst economic collapse in 80 years.

We need more programmers. The competition is fierce. I spend more than a bit of time for work just recruiting and I can tell you that it’s damn hard. Even when you have good salaries, good benefits, cool technology, and the right company culture, finding people is always hard. It’s not unique to Des Moines either. The same story is true all over the country from northern Virginia to Silicon Valley, if you are even a remotely talented programmer you can make very good money at a pretty low stress job where creativity is richly rewarded.

It’s not going to stop. Companies are finding they can’t just offshore their key products. The quality is just not there because good software requires good communication and that can’t happen when the developers are half a world away. Even if the quality was there we are horribly short of talented developers in India and elsewhere. Think of everything you own that has a computer in it. You phone, your car, your TV. We are painfully short of programmers and the shortage is scheduled to last for the next forever.

If you are a parent and wondering what kinds of jobs you should encourage your children to follow you would do well to expose them to software development. It’s not for everyone; but it’s also not looked at seriously by enough kids.

When I was a kid I would turn on my TI 99/4a and my only option was to program. There was nothing else. Today you have to go out and dig a little more. Still there are some great learning opportunities. Here are a few:

• Code Academy: lets you learn to program from the safety of your browser.
• Alice is a 3d game programming environment for kids.

P.S. When I say "kids" I don't mean "boys". We are even more horribly short on girls.

I’m not a fan of scrum as a methodology or sprints as a practice. I think it is ripe with inefficiencies and waste. The best explanation I can provide comes from the Greeks.

In Greek mythology there is a character named Procrustes. Now old “Crusty” as I like to call him would invite people passing by his place to stay the night. He had a bed for guests and he would get quite upset if they didn’t fit the bed perfectly. So he would make sure they would by either stretching them if they were too short or chopping off their legs if they were too tall. Eventually Theseus stopped by and fitted Crusty to his own bed.

Although it’s not a widely used metaphor today, writers have been using “Procrustean Bed” ever since to describe an arbitrary standard to which reality must be fit. Development sprints are often a Procrustean Bed. We place our stories into them and they tend to expand or contract to meet the time requirement. The very act of saying “this must be done in x time” seems to make the thing take x time. If it’s a simple task the developers tend to buffer it with all kinds of other things (needed or not). If it’s too big to fit then corners get cut.

I much prefer to just do a queue-pull method and concentrate on one thing at a time and letting that thing take the time it needs. I find that the shorter tasks take less time, the longer ones are done right and the team is more honest with the product owners and themselves about how things are going.

About 8 months ago my family look the plunge and ditched DirectTV for a hodge-podge of Broadcast TV and streaming/download services. Like many people we realized that we were paying over $100 a month to watch House Hunters International and Spongebob Squarepants; it just didn’t seem worth it. We haven’t regretted it for a minute. Lots of people have asked me about our setup so here it is:

TV locations:

We have 3 TV’s. Two on the main level. The one in the “Front Room” is the primary entertainment TV where we do the majority of our TV and movie watching. There is another in the “Family Room” which is mostly the kids (I have 4 girls 10, 6, 3, 3). The third TV is in our bedroom on the second floor. All of the TV’s are modern flat screens that are digital ready.

###Antenna: I went through several rounds of antennas before getting the right one. None of the smaller indoor ones would work. I ended up getting [this one] (http://goo.gl/0sD5Q) from Best Buy. It was on one of those tables of things that had been opened and returned so I think I got it for $90. I installed it in the attic. Lucky for me some former owner of my house ran a huge number of phone wires from the basement up to the attic...except they weren’t connected to anything. So I tied the coax to the end in the basement and then pulled it up into the attic. From the basement I ran the coax into a amplification splitter like [this one] (http://goo.gl/1opPD). Then I ran coax through the ceiling and up the floor close to air return registers. To get to the second floor bedroom I just reversed the line on the outside of the house that had previously been used by the satellite. I could have another splitter in the attic and send it down the wall and into a cable TV port that was never used but that’s for a future project.

Overall reception is pretty good. I’m getting all the major networks plus their ”extra” channels. The picture seems better than it did with satellite and they don’t go out as much during storms.

Tivo and other boxes

One of the main things we used our DirectTV box for was DVRing shows. We realized that most of what we were DVRing were broadcast network shows and the few other things we were recording, (like Breaking Bad and The Walking Dead) were available the day after the broadcast on Amazon for a couple of bucks. We still wanted a DVR for broadcast and we also wanted something that would play purchased shows from Amazon or Apple. Since AppleTv does not yet have DVR abilities we got a Tivo.

I have not been blown over by the Tivo. Supposedly this version was to be the magic device that brought together TV with all of the different online services. Yet right off the bat I had to buy a separate wireless card which seemed awkward in 2012. Then most of the online apps (Netflix, Hulu etc) are noticeably slower and crappier than their Roku counterparts. Still the DVR part is quite nice and it’s cool that it can download entire shows from Amazon. Boxee was not around here when I made the switch (or at least I was completely unaware of it). So I’d advise anyone to look at it before settling on a Tivo.

For the family room we get Netflix and Hulu through the Nintendo Wii and in our bedroom we have a Roku. I have to say I really like the Roku. It’s super fast and easy and has by far the best experience of the group. If they would just throw a big old hard drive in there I would replace the Tivo in a heartbeat.

For online services we have Netflix, Hulu and Amazon Prime. We don’t really watch Amazon Prime at all. My wife does quite a bit of our shopping from Amazon and we get prime as part of that but I think I’ve logged into it once. We do get Amazon season passes to our favorite AMC shows but that’s a separate service and they will only download to the Tivo. We also don’t use Hulu a great deal. We might get rid of that if we don’t start watching it more. Netflix streaming on the other hand is the bees knees. We love it and watch it all the time. It’s the secret sauce to the entire thing. The recent addition of Disney content only makes it better.

Overall I can easily say that we really don’t miss Satellite/Cable at all. My only regret is that we didn’t do it sooner. I highly recommend it. Still I would like to petition the powers at be for the following:

• HBO Go without a satellite/cable subscription.
• A generic OSS way to stream recorded shows from one device to another. I should be able to watch DVR content on the Tivo from my Roku

One of the primary criticisms of static languages is that they require needless levels of boilerplate. This can be painfully true, and any C# or Java developer can most likely point to a weird workaround they had to do to use some sealed/final Spring or .Net class. Eventually most large projects become littered with wrappers and adapters and mappers to get objects to “fit” inside the rigid static typing system. But why does the type system have to be so inflexible?

I’ve had an idea for some time that goes something like this. Lets say you have this C# method:

public void DoSomething(HttpRequest request){
request.Params ...
}

Oh Noes! the dreaded HttpRequest class. So full of sealed horribleness; and all we want is the stupid Params. If I want to be able to test this I can either go through the annoyingly complex process of building a HttpRequest object or I can try and swap out HttpRequest for Microsofts wrapper abstraction (or my own). None of that is nice and in the end I will have a bunch of code I don’t need or want.

Wouldn’t it be great if I could just add a interface to HttpRequest? It would solve most of my problems. It would be mockable and could define just the parts I need. Unfortunately I can’t break into Redmond and add an interface to that class.

But why not? Compilers are fast and smart and can figure out all kinds of things. Let say I made this interface for my method:

 public interface IHttpRequest { Params {get;set;}}

I don’t see any reason the compiler (and IDE’s) could not look at the requested interface, look at HttpRequest and say “yep, that works.” It would STILL be type safe. It would STILL happen at compile time. It would NOT require anything to happen at runtime, and it would NOT be the same as duck typing because the object could not be just anything that (might) fulfill the request at runtime. The compiler would simply make a shorthand reference the first time it sees that HttpRequest implements IHttpRequest in the context of the package/assembly.

Maybe for speed there would have to be some kind of keyword on the interface or the param? Maybe not. Hey Anders or whoever is in charge at Oracle…give me a call, we can work it out.

Can anyone verify if there are static languages that do this? I have a hunch that Scala’s “traits” are somewhat like this but I’m not sure.

Simple rules for handling collections. This applies mostly to static languages like C# and Java:

1. Always use generics if you can. Especially in C# where there are major performance advantages.
2. Methods should always accept the simplest abstraction of a collection as possible. Iterable in java, IEnumerable in C#. This gives classes using the method the most flexibility. If you don’t need it to be a list, don’t ask for one.
3. When returning a list return the most fully functioning implementation you can (without going out of your way….this is a very loose rule).
4. When returning collections; if you don’t want people to modify the list then return a Immutable/Readonly list…and let them know it. Don’t hide a Immutable list behind simple interfaces.
5. If the collection you return gets passed around a lot, think about making it into a little class. This can either be a wrapper or just extending a collection type. This will let you tweek the implementation and show intent better.
6. If #5 is applying to a hashtable, dictionary or map have an even lower tolerance for when you make it a class. I almost never expose a map publicly.

Let me preface this blog post by admitting that I do not have a computer science degree. I majored in community & regional planning. I started out as a fine art major. I tended to avoid mathematics because I found it horribly boring and as a result difficult. I have however, been programming since I got a Texas Instruments 99/4A when I was in 3rd grade.

The programming world has been preoccupied with CS vs programmers the last week. I wanted to weigh in on an important point that I don’t think has been made.

Almost anyone can write working software.

Some people can write very efficient software (you can easily make the case that CS helps with this.)

In the world of business programming the most desirable trait for code is that it reads well and that other HUMANS can understand it and work with it. A very elegant, program that can solve abstract problems doesn’t mean anything if other programmers can’t grok how to use it. Once more, code that is easy to understand and read is often also efficient and working.

If I were to create a new major for programmers I think I would put it in the business school. Not with engineering or mathematics. It would center on how to communicate (with humans) through code. How to work with a business to determine requirements. How to make money. It would have required courses in TDD, BDD, CI, agile processes, graphic design, speech communications, and yes, a lot of CS. Most importantly it would have lots of labs where students must make working programs together.

I have been hiring programmers for over 10 years. My impression of recent CS grads is that they have only 1/3rd of the skills I really want. I do think a CS degree is a great start to a career in IT but we really need the universities to give us something a little different.

Last sprint’s pair programming bingo worked out pretty good. There was more awareness of pairing and a desire to make sure everyone filled some squares. This sprint we changed it a little. Our PO generated some cards from http://print-bingo.com/. The cards are random and seem to have a better shot at actually getting bingo for someone.

We have several different teams all working on the same codebase. Recently we did a cross team retrospective and a couple of related issues came up:

1. The teams wanted to know more about what the other teams were doing.
2. A majority of the team members are interested in pairing as a concept but have been reluctant or unsure of how to practice it. This is something the agile coaches have been working on but we really need a kick int he pants.

What came out of the retro was a great idea: Pair Programming Bingo. It works like this:

Each team has a “Bingo Board” listing all team members along the top and the sides. You get to mark a square once you have paired with another team member for at least a morning or afternoon session. We also have a column for “outside” meaning any member of a different team. members who get “bingo” by having a complete line get a prize. Teams that get a blockout get even bigger prizes. One idea is to line the bingo maps up and make it into a kind of competition.

and yes we realize you would only need ½ of a chart but we decided to keep both sides to represent who was the driver and who was the navigator. Anything to encourage more pairing!

More to come as it evolves

I’ve written before about dead code and how it can gunk up you system, slow you down, and cause all kinds of problems. So with Halloween on its way I wanted to muse on something even worse than dead code….undead code. You see most of the code you end up killing in a dead code hunt is not dead yet, its only mostly dead. You have to find out if it’s really holding on for true love or planning on eating your face. So how do you tell? Lets find out.

Dead-Parrot Dead: This is the easy stuff. The class or method that is never invoked. The library that’s only imported but never used. This kind of code is easy to remove, it’s very low risk. Don’t listen to the people who tell you that the code is just resting or stunned. It’s kicked the bucket, shuffled off it’s mortal coil, run down the curtain and joined the bleedin’ choir invisibile!! THIS IS EX-CODE!! Clean up the body. Kill Satisfaction: 1 Zombie head

Ghost Code: Ghost code is actually the most common. You probably have it all over your code base and you don’t even know it. I’ve known developers who have spent their entire careers on projects writing code nobody asked for. Unless you can tie code to a specific business case and it’s bringing value right now (NOT “maybe someday”) then all it’s doing is getting in the way and sucking away your time. Exorcise it now and put it out of it’s misery. Kill Satisfaction: 3 Zombie Heads

Zombie Code: A more subtle form of dead code is zombie code. Code that looks alive but actually wants to eat your brain. This is code that is unreachable due to various reasons. Perhaps its related to a particular entry in a config file that never has a different value. It can also be spotted by a tell tale magic bool being passed to a method which is only ever called with “true” or “false”. At worst the code is strung throughout complex classes and methods that are only used in one particular way with limited expectations. If a developer ever tells you his code is “flexible” be wary, it might be a zombie.

These kind of scenarios can be a little harder to dig out, but often have a single kill point. Once you shoot it in the head it leads to an avalanche of deleted code. Kill Satisfaction: 6 heads.

Vampire Frameworks: Frameworks are pretty, they solve all of your problems and their perfect 19 year old bodies sparkle while they seduce you with their smoldering eyes. Don’t be fooled though! Any frameworks that forces you to generate boilerplate after boilerplate that you don’t find useful (or understand) is pure eeeevil. Even worse are the ones that generate these boilerplate classes themselves and inject their unholy poison all over your app. They suck away your flexibility, your ability to test and your ability to be lightweight. They often are quite good at doing something the way they think you should do it but as soon as you need to do something different (about day 3 in) they make your life a living hell.

Once established, killing off a framework can be quite hard. You need to stop them as early as possible. Kill Satisfaction: 10 heads.