Sergio and the sigil

So you've been hearing about this Git thing

Posted by Sergio on 2009-06-02

The ALT.NET universe in Chicago gets together again on June 10th, this time to learn and talk about Git, the SCM you're probably tired of hearing people jabbering about and still have not taken the time to look at.

The presenter will be myself and I hope to explain how Git works and how it can be a good alternative even for non open source projects.

Git Without Puns

This month we will take a look at Git, a distributed version control system that has been gaining a lot of popularity since its introduction.

As with everything that is new and is touted as a replacement for an existing product, it's easy to try and map Git's functionality to Subversion, CVS or TFS for example. To better use Git, we should avoid too much comparison and also try to understand how it was built and how it works under the hood.

Here are the things we will be seeing and discussing in this session.

  • Brief tour of Git on Windows (SSH, PuTTY, Git Bash, GUI)
  • Git is distributed. How does that benefits me?
  • Git's object database.
  • Git's main objects (blobs, trees, commits and tags)
  • Git workflows. Choose or create yours.
  • Working with Git
    • Configuration tips
    • Create a repo
    • Clone a repo
    • Add/Commit changes
    • Reference another repo
    • Update repo (to/from)
    • Branching, merging, rebasing
  • Hosting Git
  • Github, social project forking

The Chicago Code Camp has got you covered

Posted by Sergio on 2009-05-19

As a brief inspection of your RSS reader will quickly tell you, it's Code Camp season. Not to be left out of this party, the developers in the Chicago and Milwaukee areas have a great option this year.

The Chicago Code Camp, which happens on May 30th, is strategically located right between these two cities.

The agenda has been published and it's pretty exciting to see so many interesting and useful topics in a single event.

.NET still dominates the schedule but there's a lot of options for developers of virtually all walks of life. Here's a quick summary (we will have 33 sessions but some cover more than one topic)

  • .NET: 20 sessions
  • Ruby: 6 sessions
  • TDD: 6 sessions
  • JavaScript: 3 sessions
  • Functional Programming: 3 sessions
  • Cloud computing: 3 sessions
  • Python: 2 sessions
  • Java: 2 sessions

The bad part is that we can't be at all the sessions we'd like — there will be 5 or 6 concurrent talks. Here are some sessions that interest me in particular:

Those are only a few of the talks. I'm sure you'll be able to find sessions of your own interest. RSVP below. Hope to see you there.

RSVP

Git, SSH, PuTTY, GitHub, Unfuddle, the kitchen sink

Posted by Sergio on 2009-05-06

After reading a good number of the guides for getting Git/ GitHub/ Unfuddle working correctly in Windows, I finally got it sorted out. I had to use a bunch of things I had not used before so I realized it's probably a good idea to share my findings, hoping to help someone else (and maybe myself again) in the future.

Local git is easier

Getting Git to run locally in Windows is not hard. It gets a little trickier when you want to work with remote repositories. Especially if, like me, you have little or no experience using SSH in Windows.

In this post I'll install and configure the tools that enable Git to work with remote repositories (e.g. post changes to a server), which I think is probably what a lot of people will want to do, even if you're just toying with Git or evaluating it.

You will need SSH for serious Gitting

The way Git will authenticate and communicate with hosted repositories like GitHub or Unfuddle is through an SSH tunnel. That means we will need an SSH client to connect to the server and Git will use that connection to securely transfer the repository data up and down.

In Linux or on the Mac, SSH is a trivial thing. It's just part of the default installation. For whatever reason, Windows does not come with an SSH client, so we need to find ourselves a 3rd party client.

PuTTY, a family of tools

Luckily for us, there's a free and very popular SSH client for Windows, called PuTTY. PuTTY is actually a family of utilities that play together to configure and establish SSH (and Telnet) connections.

From the PuTTY downloads page get the following programs and put somewhere in your hard disk. I like to put these types of things in a c:\tools\bin directory, which is included in my %PATH%.

Create your SSH key pair

The most common way to authenticate your SSH connection with the server is using an RSA key pair. The pair contains a public key and a private key. Typically these keys will be stored in two files — make sure that the private key file is in a directory location that only your user account has rights. I'm gonna keep both files in %USERPROFILE%\SSH (type echo %USERPROFILE% in a command window to see where yours is.)

To create a key pair we will use puttygen.exe. Just click Generate and then Save public key and Save private key. I chose to leave the password blank and trust that my directory security is enough to protect my keys. Let's assume I saved my keys at %USERPROFILE%\SSH\private.ppk and %USERPROFILE%\SSH\public.ppk, respectively.

We're not done with PuTTY yet

Before starting an SSH connection with PuTTY, we need to run Pageant.exe. Pageant is a background process that will handle the authentication requests. We will add our private key(s) in Pageant and it will keep them available for new connections, without the need to retype the password (if you entered one) every single time.

Run Pageant.exe, double click its icon in the notification area, and add your private key file. If you specified a password, it will now prompt you for that.

Phew! We are done with the SSH crap. Now on to Git. Finally.

Git via msysgit

There are a few ways of installing the git client in Windows, including downloading and compiling the source. But guess if I want to go down that route. Instead, let's just press the easy button and use a pre-packaged installer.

msysgit is what you'll want to install. Donwload the latest release from the site. The file name of the full installer, as of this writing, will be named like Git-[version]-preview[yyyymmdd].exe.

Run the installer accepting most of the defaults, with the exception of these two screens below. We want to Run Git from the Windows Command Prompt and Use PLink (PuTTY.)

 

After this we should have a working installation of Git. You should be able to use Git from both the Windows command prompt and from the Git Bash shell.

Register your public key with the remote server

Now we need to tell the server that hosts the remote repository that it should expect and accept SSH connections from our machine. The way we do this is similar in GitHub and Unfuddle. We just need to associate our public key with our account on that site.

For example, in my GitHub account settings there's a section called SSH Public Keys, where we can add all public keys that we own. Don't use the public key straight from your PuTTY public key file, it uses a different format. Instead, open Puttygen again and load the private key. The public key, in the right format, will be shown in the big text box at the top of the window. Copy that entire text and paste in a new key in your GitHub settings, as seen below.

Troubleshooting

After all that you should have all it takes to use Git in Windows. Until I got to this point I came across some problems. Here are some of them.

No supported authentication methods available. I got that error while trying to push changes because I either forgot to run Pageant or to add the right key into it. The full error is below.

C:\myproject>git push origin master
FATAL ERROR: Disconnected: No supported authentication methods available
fatal: The remote end hung up unexpectedly

The server's host key is not cached in the registry. Sometimes when connecting to a remote server for the first time, the PuTYY will output this message after your Git command.

The server's host key is not cached in the registry. You
have no guarantee that the server is the computer you
think it is.
The server's rsa2 key fingerprint is:
ssh-rsa 1024 [fingerprint here]
If you trust this host, enter "y" to add the key to
PuTTY's cache and carry on connecting.
If you want to carry on connecting just once, without
adding the key to the cache, enter "n".
If you do not trust this host, press Return to abandon the
connection.
Store key in cache? (y/n)

Taking PeepCode for a spin

Posted by Sergio on 2009-04-28

A rainy weekend and some brain hunger made me finally do something I had been meaning to do for a while. Once I posted about my interest in screencasts and their power to make information memorable. This last weekend I filled up my shopping cart over at PeepCode with a bunch of material that was on my to watch list.

GIT

This video was pretty interesting. It will definitely let you get off the ground quickly with git. I learned and still remember more from this screencast than from any other time spent on documentation and tutorials.

This is one of those screencasts where the author starts cranking out commands at the command line. If you can't stand the command line, you won't like this one. The advantage is that the command line is the same in all platforms.

My only negative comments, which is applicable to almost all the other videos I've watched, is that the author has the habit of clearing the screen way too early and often. At least it's recorded so you can rewind and absorb the information at your own pace.

GIT Internals (PDF)

While on my git learning mode, I went ahead and bought this PDF as well. Boy, this is money. If you're a sucker for internal details, this one is for you.

The PDF was written by Scott Chacon, who is very well known in git circles. The material is dense but is very well explained by Scott. Worth every penny.

The PDF ships with some videos from gitcasts and some handy shell shortcuts.

Rails from Scratch Part 1 and Part 2

I already have a reasonable level of experience with Rails. What made me buy these two episodes was to see a competent Rails programmer showing how he works. After watching both videos I was happy to see that I was not so far off. I know these screencasts are definitely simplified for the newbie and that a number of things changed in Rails since the first edition of this material, but the good advices on how to organize code and use the Rake tasks are still valid.

There's a whole lot more to Rails than it's possible to cram in 2h40 of screencasts but if you need to start somewhere, this is a good choice. I wish there was a little more ActiveRecord and plugins covered but, hey, it's still one of the greatest bargains out there.

Objective-C for Rubyists

I just started watching this one. My early impression (25 minutes in) is that its pace is a little too frantic. I don't buy the argument that knowing Ruby helps you learning Objective-C because of their SmallTalk heritage.

I've been trying to get into Objective-C from books and whitepapers but I had hopes a screencast like this would be more effective. I'm not too optimistic so far (I'll update this post if I'm convinced otherwise.)

Worth the investment

A good thing with the PeepCode episodes is that they are positioned at a price point (US $9.00) that doesn't let you feel too bad, even if you expected more of them. They have definitely been worth more than the sticker price.

I'm looking forward to a few more episodes later this year. RSpec and Haml are on my crosshair.

Blocked .js files keep biting me

Posted by Sergio on 2009-04-03

This is a tip for those working with JavaScript (and possibly other types of files) that is freely available for download. For the nth time in the last few months I spent an unnecessary amount of time trying to find a problem in my code that wasn't really there.

Windows keeps track of the files you save to your hard disk which came from the Internet. Maybe you have seen this problem when you try to open a CHM file that you downloaded and see that it opens to a blank page. The same type of thing happens with JavaScript files that you download. Let's see what happened to me today.

First I downloaded the latest version of QUnit and saved to my application's directory. I did this the usual way, as shown in the image below.

Then I proceeded to use the downloaded testrunner.js file in my HTML page, via a <script src="testrunner.js"></script> tag. When I tried to open my HTML page, I was not expecting to see the particular error shown below.

I started to look for common problems: Did I save the file in the right place? Did I spell its name right? Did I mispell the function name? Did I miss a dependency? No, no, no, and no. All looked good.

That's when I remembered that the file might have been flagged by Windows. I opened its properties dialog and, sure enough, there it was, the infuriating Unblock button.

Ah, that's easy. I just clicked it and refreshed my page. Wah-wah! Problem persists. I tried typing the .js url in the address bar and saw this 401 error message from IIS, not 404.

That told me that there was still something messed up with file access. I checked the file's permissions, comparing to an older .js file in the application. The new one did not grant access to local users, so I added Read access to local users.

Now it works. Depending on how your IIS and/or ASP.NET security is configured, you may not need this last step (e.g. if the process identity already has admin rights, in which case I salute you, brave friend.) The system at hand was a Win2008-x64 installation with the default IIS/ASP.NET settings.

This problem seems to happen to me every other week and I still did not develop the reflex to take care of it right when I download the file. On the other hand, I'm getting better at remembering about it when I see stuff like "function not defined" in an error message.