Posting mostly for my own reference…

One thing I find that I need to do a lot is position a footer bar across the bottom of the page. The most common way to do this is to set a fixed position on the element and anchor it to the bottom using this css:

 #footer {
      width: 100%;
      position: fixed;
      bottom: 0;
      height: 75px;
 }

Unfortunately, this doesnt work quite right in IE. When using this style definition in IE, the footer gets locked into a specific position in the viewport and when you resize from the corner anchor the footer does not move with the window.

The proper cross-browser way to declare a fixed position footer is to use negative margins, like this:

 #footer {
      width: 100%;
      position: fixed;
      top: 100%;
      margin-top: -75px;
      height: 75px;
 }

This appears to function properly in every browser I’ve looked at so far.

Several times over the past months, I’ve received questions about the software and setup that I use to run the mattberther.com blog and related pages. Since the site recently underwent a dramatic change in tooling, I want to detail what I chose and why.

Before the change, the site was powered by wordpress. I had my own rackspace virtual server that I was using to host the apache and mysql server servers required by wordpress. Wordpress is not a bad piece of software, but what I realized is that it tries very hard to be all things to all people.

Enter the blog engine Im using now: toto

Toto’s philosophy is akin to mine: use the best tool for the job. Toto’s website states that “everything that can be done better with another tool should be”. To that end, toto doesn’t use complicated web frameworks. It doesn’t use a database. There’s no built-in commenting support. If you want comments, you’ll use disqus. It also relies on git for version control. When you combine toto with a Heroku account, you also use git to deploy the site. Its designed to be used with a proxy cache for high availability and fast response times.

Migrating the posts from the mysql database to the text files proved to be relatively straightforward, using a simple ruby script to iterate over the rows and format a text file that matched toto’s expectations. Importing the comments into the disqus platform was equally straightforward using their JSON API.

I much prefer the simplicity of this new setup. The entire blog engine weighs in at about 300 lines of code. If running a blog without putting your hands on the metal and being able to control every nuance of your blog platform appeals to you, then certainly take a look at the toto/heroku combination. If not, then I believe that wordpress is a fine solution.

More and more, I have developed a passion for the Git source control system. I love how Git stays out of my way, until I need to use it. Git offers a very easy way to test things out, whilst utilizing the benefits of source control. In the traditional, connected model of source control, experimentation proves to be somewhat difficult because you don’t want to corrupt your main development line. Branching and merging with most other systems is a nightmare at best. With Git, branches are very cheap and merging is virtually painless.

I use Git for side projects as well as a few of the open source projects I am a part of. However, during the day, my organization uses Microsoft’s Team Foundation Server for source control. I find that in a connected source control model, I am constantly waiting on TFS to catch up. Either it’s out too lunch, or it needs to download and checkout a file before I can edit it. Experimentation is tough, for the reasons I mentioned earlier. Surely, there has to be something better, while still keeping TFS in the organization.

Enter Git-TFS… Git-tfs is a two-way bridge between Git and TFS created by Matt Burke. It allows me to clone a TFS repository and use Git for source control (without the hassles of being tied to a TFS server). This means: 1) no more waiting on TFS, 2) no more locked files, 3) no more requiring network connectivity to work on a project. At a time that I believe a development effort is ready to be committed to the main line, I use git-tfs to push my changes to the TFS server so that the rest of the team can get them.

Sound interesting? Here’s how to get started:

First step’s first. You need to have a Git installation on your machine. I use msysGit 1.7.6 preview 20110708, but this should work with newer versions as well. I just used the default installation options, specifically, I chose to use the Git Bash only when prompted about how to use Git from the command line. I chose this option because it did not otherwise modify my system.

Once you have a Git installation, you need to install the git-tfs plugin, which is available on github at https://github.com/spraints/git-tfs. Installing the plugin is pretty straightforward. You can choose to either download or build it yourself. I went with the download option and extracted the zip file to c:\git-tfs. Once the files are in place, git has to know how to find them. The easiest way to do this is to add c:\git-tfs to your path (Advanced System Settings | Environment Variables).

At this point, you are ready to clone a TFS repository using git-tfs. You can do this one of two ways:

git tfs clone http://tfs:8080/ $/TeamProject/folder

or

git tfs quick-clone http://tfs:8080/ $/TeamProject/folder

At this point, you are ready to open your project. If you’re using Visual Studio (which you likely are), you may still have the TFS source control bindings in place. There’s several ways to handle this. You could 1) disconnect your network cable while starting the project, 2) update all of the projects to remove the source control bindings, or 3) install GoOffline.

Option one is obviously less than desirable. Option two is reasonable, however, we are assuming that others on the team continue to use TFS and need to have the bindings in place. That leaves the GoOffline solution. GoOffline is a free Visual Studio add-in that adds a Go Offline button to the Source Control menu. When the solution is in offline mode, any file renames or moves happen without communicating with the TFS server. Perfect!

I prefer to work in feature branches (sometimes also referred to as topic branches). Again, branches are cheap in Git and this allows me the ability to experiment while enjoying the comforts of source control and not forcing experimental changes on my team. My typical workflow with git-tfs looks something like this:

# create and checkout a new branch for feature
git checkout -b feature_name

# write tests and code

# commit my changes with a meaningful commit message
git commit -am "meaningful commit message"

# repeat the code/commit process until the feature is complete

# when ready to commit the changes to the TFS repository, first sync any newer changes from the master

# switch to the master branch
git checkout master

# pull new changes from the TFS server
git tfs pull

# switch back to the feature branch
git checkout feature_name

# import the changes from the master branch onto our feature branch
git rebase master 

# last but not least, push to TFS
# optionally, add --build-default-comment which will create a default commit message
git tfs checkintool 

The checkintool command brings up the TFS commit dialog which allows you to associate checkins with work items and modify the commit message. Importantly, the push to TFS is done as a single commit, so regardless of how many times you commit to your git repository, the change pushed to TFS reflects only the final result and not the journey it took to get there.

I have only been using this workflow for a little while now, but for now, I am very happy with it. Your mileage may vary. Please let me know in the comments if you’re using this and how it’s working for you.

Goals and Goal Setting:

In the book What They Don’t Teach you at Harvard Business School, Mark McCormak discusses the importance of setting goals. The students in the 1979 Harvard MBA program were surveyed and asked “Have you set clear, written goals for your future and made plans to accomplish them?” Only three percent of the graduates had written goals and plans; 13 percent had goals, but they were not in writing; and 84 percent had no specific goals at all.

Ten years later, the members of the class were surveyed again. The 13 percent of the class that had goals were earning an average of twice as much as the 84 percent who had no goals at all. However, the three percent that had clear, written goals were earning on average, ten times the other 97 percent combined.

For many of us, during this time of year, we begin to look at performance reviews for our team members. An important part of a good performance review are effective goals for the coming year. I am certainly not a management expert and most of the ideas that I will share with you today are not my own. However, I do see value in each of the ideas. For me, these ideas make the goal setting process easier. I certainly hope that they can do the same for you.

Top Tips:

• Strong relationships with directs is paramount
  • Many management leaders propose that having weekly one-on-ones is the single most important way to cultivate a positive relationship with your direct reports.
  • 10/10/10 agenda
    • 10 minutes for the direct to discuss whatever they want
    • 10 minutes for you to discuss whatever you would like with the direct
    • 10 minutes to discuss business and progress toward goals
• Create MT goals (measurable and timely) and use SMART to validate them
  • Examples:
    • By April 30, 2011, consolidate the presentation models used by the company’s applications.
    • Integrate the new ERP system with the CRM system by October 31, 2010.
• Create goals that intersect business and individual objectives
  • Examples:
    • By April 30, 2011, combine multiple automated test frameworks into a single framework and increase coverage of automated tests by 20% using the consolidated framework.
    • Complete Microsoft developer certification 70-515 by April 30, 2011.
• Emphasize cross-team collaboration
  • Examples:
    • Participate in a mentorship program to grow understanding of our organization’s business by April 30, 2011.
    • Participate in a mentoring program to enhance leadership and communication skills by December 31, 2009.
• Create personal goals
  • Examples:
    • Run a 5K race in less than 32 minutes by April 30, 2010
    • Receive a belt promotion in my chosen martial art by December 31, 2011
• Be flexible

“I’m much more likely to accomplish something if I write my goals down and share my goals with others. Recruiting the support of other people also helps keep me on track.”

“What was/is valuable to me is taking into account what I want to do when setting goals. That results in my engagement right from the start.”

“I think the addition of a personal goal is a great idea. It’s good for promoting personal improvement and makes the goal setting process less painful.”

I have used this model for a number of years. The quotes above are a few pieces of feedback that I received from my team regarding these ideas.

I find the windows command prompt somewhat limiting and have never really been able to make the leap to Powershell. Personally, I like to use a Cygwin shell for command line work. I am comfortable in a unix shell with previous Linux and Mac experience. I’m not an expert by any means, but I can get by.

Recently, I installed the Cygwin shell on my 64bit Windows 7 system. After installing the developer tools and trying to compile ruby 1.9.2, I found that I had a tremendous amount of problems building. Id see numerous errors that stated:

unable to remap file to same address as parent
ruby ### fork: child XXX - died waiting for dll

The most commonly referenced solution was to rebase by doing the following:

1. Start –> Run
2. cmd.exe
3. cd c:\path\to\cygwin\bin\
4. ash.exe
5. ./bin/rebaseall
6. Reboot

However, this did not work for me. I found a message on the cygwin mailing list stating that the gems may not add information to the proper paths and that we must create the list manually.

To do this, first from your cygwin shell do:

find /lib/ruby/gems -name '*.so' > /tmp/ruby.gems.local.so.lst

Then, follow steps the steps above, replacing step five with:

./bin/rebaseall -T /tmp/ruby.gems.local.so.lst

Since performing this, I have not seen any more of the remap file errors. Your mileage may vary though.