Video: Intro to Git

I gave my Introduction to Git talk again at the local Drupal User's Group.

Andrew Berry filmed the talk, and we recorded the laptop screen for the slides and command line activity. He put it all together in a video which you can download at archive.org.

The lights were off so people could see the screen, so you won't see much of me, but the slides are there.

If you want to grab the updated slides and scripts for yourself, you can download them via git with the following command:

	git clone http://foursquare.net/intro_to/.git

Thanks to Khalid Baheyeldin, Andrew Berry, and Bob Jonkman for their help and equipment, and thanks to the Drupal group for their welcome.

Syndicated 2010-07-21 21:25:58 from Chris Frey's Blog - Entries tagged advogato

KWLUG: Introduction to Git

I presented my Introduction to Git talk at KWLUG tonight. I was pleased to hear that folks found it enlightening.

You can grab my OpenOffice slides, as well as the demo scripts I used during the presentation, by using git:

	git clone http://foursquare.net/intro_to/.git

If you missed tonight's talk, I'm also booked to give it at the next Drupal User Group meeting on Thursday, July 15, 2010, at 7pm. You can find more details here. That meeting is at 58 Queen St. in Kitchener (across the street from the old KWLUG meeting place).

Special thanks to Paul Nijjar for providing the laptop tonight and the setup.

Syndicated 2010-07-05 22:39:10 from Chris Frey's Blog - Entries tagged advogato

Programmer Ethics

apenwarr,

That is a pretty comprehensive list. I'm probably in the same camp as you claim to be, having broken every one.

The rules are pretty strong as well. I'm still mulling them over in my mind, but there is one that sticks out as unwise, or poorly written. It is #3, which says: "I will not write a program that fails to do tomorrow what it was able to do yesterday."

Taken purely literally, this prevents all change, all experimentation, all feature-level refactoring. I'm sure this is not what the rule was intended to say. I'm assuming it is more of an encouragement for better testing, so that a bugfix in one area doesn't break a feature in another.

Even taking this rule as a Testing Rule, I think it overreaches. There are steps that programmers can take to prevent regressions, but to assume that it is possible, or even common, to prevent them all is wishful thinking.

I think a better rule would be something like: "I will not refuse or hinder the fixing of a bug that I have caused."

Syndicated 2010-05-23 18:27:14 from Chris Frey's Blog - Entries tagged advogato

Bike Safety

It's almost that time of year again, when people get out on their bikes and enjoy the fresh air blowing in their faces, and the benefits of exercise.

Instead of merely slapping on a helmet and thinking you're bulletproof, though, take a look at this excellent site on bike safety: How To Not Get Hit By Cars.

Whether you wear a helmet or not, the primary goal for safety should be to avoid an accident in the first place. And this site explains the dangers logically and clearly.

I remember being very impressed by the site the first time I found it a few years ago. It changed the way I ride on the streets. I hope it will help improve your safety as well.

Syndicated 2010-05-11 18:50:21 from Chris Frey's Blog - Entries tagged advogato

Time Conversion: timegm()

redi, thanks for the pointer to timegm(). Both GNU and BSD, you say? Nice. I did not know that function existed.

It would still be nice if timegm() was in a library of its own instead of libc. But that's probably asking too much.

Good to know. Thanks!

Syndicated 2010-05-05 13:39:29 from Chris Frey's Blog - Entries tagged advogato