PSA: It is easy to extract 7zip files on a mac if you have brew.

I feel like this blog is about the constant changing back-end that powers this blog. Recent changes include

Namecheap

When I went to move my blog from github to s3 I ran into a major roadblock with Namecheap. Somehow my account had got into a state where I couldn't edit my dns host settings. Live support says that the only way to fix it is to convert my dns to another platform and risk downtime. I have to renew this domain in about a week. I moved dns settings to amazon route 53 and in about a week I am up for renewal so I may switch from namecheap to hover. I don't interact with my domain settings very often but when I do I want them to work!

Jekyll

Its been several years since the Octopress 2.0 release and there hasn't been much traction. At the end of the day octopress is just a pretty wrapper around jekyll. So I got rid of the wrapper and I am using straight jekyll. Most of effort to convert it was finding the few built in octopress plugins I was using.

Amazon S3

The blog content was previously held on github pages. I moved it over to S3. It is very impressive how fast S3 is at rendering static content. The blog loads almost instantly. On github it could still take a second or two to load the static content. I am pushing the site content with jekyll-s3.

Twitter Boostrap

A good chunk of the work I am doing at work right now involves the Bootstrap library. To continue to build out my knowledge base I am using a boostrap based theme that I will be customizing.

This post is meant to capture why we transitioned to Git from Subversion and what we learned along the way.

Code Reviews

The main reason I started to consider switching version control systems was we had a work flow issue that was causing members of our team to be non productive for days at a time. As a team we had instituted mandatory code reviews to try to maintain a high level of code quality. Our software was deployed into the pentagon network so it was important to know what was being built and how it was being built.

The work flow with subversion was:

1. Tasking came into a senior developer.
2. The senior developer assigns the task to a team member.
3. Team member emails a patch with the requested changes.
4. A senior developer reviews the patch.
5. If accepted the team member commits his changes to Subversion.

The sticking point was step 4 "A senior developer reviews the patch." If the senior developer was busy with her own tasking or not in the office the team member could not continue to make changes for other tasks. This waiting period could last for hours to days. We tried to allow commits prior to review but we were finding that changes were slipping through the cracks unreviewed.

Distributed Version Control

Git separates the concept of committing changes and sharing those changes with a remote repository. Committing is a local action that adds your changeset to your complete clone of the remote repository. When you are ready to share one or more commits you execute a push.

Because commits were local actions it allowed team members to commit changes prior to a code review and to continue there work even in the absence of a senior developer. As time permitted, patches would be reviewed and the team members would then be permitted to push changes to the remote repository.

Local commits fixed a very specific work flow issue we were having with code reviews and improved the productivity of our team.

Initial Commit

When a new project was created a developer would would work on that project till it got to a point where it was ready to be put in Subversion. At that point she would create a new folder in Subversion, checkout that folder, add all her local files to the fresh checkout and commit her changes to the remote repository.

The result of this was every project had this mystery commit with the message of "initial commit." There would be no information how it got to that state, it just was.

By executing a git init command, you can turn any folder in your filesystem into a Git repository. This project will be unattached from any remote repository ready for you to begin making local commits. At the time you are ready to share your project with the team you can create a remote git repository, attach your local git repository to the remote repository and push all your commits to the remote repository.

Being able to instantly create a repository in any folder greatly minimized the amount of history lost from the "initial commit."

Missing Files

Ever forget to commit a file that is part of a change? This leads to those awkward commits in Subversion with a message like "Oops forgot to commit Xyz.java." In Git local commits that have not been pushed to a remote repository can be modified without consequences. If you forgot a file amend your previous commit prior to pushing your changes to a remote repository.

Pitfalls

• Most developers do not know Git; staff will require training. I highly recommend the book Pro Git.
• Window's support is not as strong as Subversion but it is improving every day. Msysgit and TortoiseGit are the definitive windows clients.
• It is overly complex to get a Windows git server running. I recommend sticking with Linux for the server. Its a difference between minutes to setup to hours or days.
• Sometimes a developer will forget to push changes prior to deployment day; this is a training issue. Check the logs prior to deployment to verify expected changes.
• By default git allows developers to rewrite history and modify changes on the server if they execute push with a force option. This can be turned off with a configuration change.
• There are sometimes more than one way to do things in Git. If this is the case then there isn't a universally agreed upon way. I recommend picking a work flow and sticking with it. This is especially bad with rebase vs merge.

I wrote a Gradle script to convert a markdown file to a PDF. Despite being 38 lines it was quite a little challenge to discover which libraries needed to be strung together and how to use them. Hopefully this can help someone in the future.

This demo out of siggraph is stunning. They use the kinect to create 3D models of entire rooms.

I love new toys. I decided to move my domain from pointing at blogger to pointing at github pages. So, that means mindjunk.org has gone from wordpress on dreamhost to vpslink to blogger to github pages powered by octopress. I decided not to try to bring over my old content from blogger.

I am playing alot with Amazon EC2. I spawned up a micro instance thats operating out of the free tier to act as my private git server. Took about 20 minutes from account creation to cloning a project. I work with git servers alot at work so it may take you longer to get going. The basic steps are:

1. sign up for a amazon web services account
2. create a new micro instance. Defaults are fine. (Make sure its the one with the star)
3. login using your new ssh key
4. sudo yum update
5. sudo yum install git
6. sudo adduser git
7. sudo su -l git
8. mkdir ~/.ssh
9. touch ~/.ssh/authorized_keys
10. chmod 500 ~/.ssh
11. chmod 500 ~/.ssh/authorized_keys
12. add your public key to authorized_keys
13. mkdir ~/repos
14. git init --bare ~/repos/test.git

As you can see I got Octopress working! Tried to do it twice so I could capture the steps. This is by no means a definitive guide but this is exactly the order of commands I ran. I am sure some steps could be removed or reordered. Enjoy!