Branching after committing locally in git

Today I found out that one of my co-workers had a local commit that he wanted to undo, so that he could work on another task that he actually wanted his earlier commit to come after. His question was: How do I undo a commit but keep the files? The answer to that is simple: simply use git reset HEAD^ to point master to the commit before the current HEAD. By default, this leaves the checked out code alone, and it remains as uncommitted changes locally. git reset --hard will check out the previous changes and blow your commit away completely.

On the other hand, branches in git are essentially just pointers to nodes in the repository tree. So, consider doing this instead:

1. git checkout master
2. git branch new_branch
3. git reset --hard HEAD^

What does this do? It creates a new branch that points to the HEAD of the current master, then resets master to point to the previous commit from HEAD. Once that's done, you can continue working in the branch, or make further commits to HEAD. Then, when you're ready to continue work in new_branch, you can rebase it against master and continue on your way as usual!

Gaming Lunches at AT&T Interactive

I started a new job as a Ruby developer at AT&T Interactive (AKA YellowPages.com) in Glendale, CA, back on December 1st. While I've organized gaming lunches at my previous two companies, I've always been a little bit conservative, worrying about being too successful and not being able to handle too many participants. Ha!

Well, having too many participants is a problem I'd love to have. So, I decided to go all out on this one. I worked with HR to send out an allstaff email to get participants. I made up fliers with pull tabs giving the e-mail address to contact to join the mailing list. I hold the gaming events in the main break room, which has room for plenty of people. And I'm varying the games played from week to week so that we'll cover a wide variety of choices, and hopefully we'll bring more people out because of it.

So far, we've played Scrabble, Rummy, and Chess. Scrabble had the best turnout so far: 8 people. Chess was close, with 7 players. This week we'll be playing Hearts.

I have 35 people total on my mailing list so far, and hopefully I'll be able to build the events and get more regular players. These kinds of events need to reach a critical mass before they can be self-sustaining. The group has to be big enough to be able to lose a couple of people here and there and still have at least 5 or 6 attendees every week.

I'll be updating with my status periodically. Have you ever organized an event like this at work? I'd love to hear from you!

New Year's Resolution: 365 Tweets, 52 Blog Entries

Well, 2009 is upon us, and for those of us who believe in them, it's time to make our New Year's resolutions. I have to admit, I've been one of those people who don't believe in New Year's resolutions. After all, if you're not eager enough to do something right now, you're probably not going to stick with it. Want to stop smoking? Do it when you're ready. That might be on January 1st, but it may just as well be on any other day of the year. So why bother making resolutions? And how do you make a resolution that's going to stick?

It's really refreshing to look at today as the first day of a completely new year where I can change important things in my life. Some of those things I wonder about, and others I just have to have the resolve to do, and they are in my reach.

Last year, I made a simple and attainable resolution that I hoped I would be able to stick with, and that would get me back into a habit that I'd been sorely missing: I resolved to read a novel every month. It's a resolution I was able to keep. I didn't have to work too hard to do it. I had about 50 minutes of reading time on the train every day during my commute from Pasadena to my job Downtown at the LA Times. I ended up reading 16 novels last year, up from only two novels in the previous five years.

Why did it work? I think it worked because all I needed was to form a new habit. I had plenty of time to read the books, it was something I truly wanted to do, and all I needed was to make a commitment to myself that I was going to take the time to do it.

This year I'm resolving to be better about social networking. Everybody I know is already involved with social networking, and I'm partly involved already. I know that if I improve my social networking, it will be good for both my personal life and for my career. I have a decent LinkedIn profile, a Facebook account complete with friends from high school I still don't talk to, a Twitter account, and several blogs that I haven't updated in a while. I'm picking two of those for improvement: Twitter and blogging.

For those of you who don't know Twitter, you should really check it out. It's a great way to stay connected to people around you, and of course it's a lot more fun, the more people you know who are active on Twitter.

So, this year, I resolve to:

• Tweet at least once a day
• Post at least one blog entry a week on one of my blogs

Good luck to all of you in the new year!

P.S. Yes, this blog post counts as my first of the year. Maybe this is gonna be too easy. I'm already 1.92% of the way there!

Yu Go Club

I've started a new blog for the Go club here in Pasadena, the Yu Go Club. You can find it here: Yu Go Club Blog In particular, I want to start writing about the future of Human-Computer Go. You can find my first article on the subject here.

Advice to a fellow developer

Here's my advice to a fellow Java developer who asked me how to learn Ruby on Rails. Having gone 100% Ruby on Rails since October of last year, I had a lot to say:

Join a local Ruby group if you can find one in your area. I would say definitely get the newest version of the Rails book, but wait a month or two if a new version is about to come out. Older versions aren't useless, but things change every day. Even the newest book will be missing things before ink even touches paper. I highly recommend Rails for Java Developers as the fastest way for you to get up to speed. After slogging through the Ruby and Rails books, I found RfJD wished I had read it first. They build on what you know from Java instead of starting you from ground zero, and that will save you a lot of time. Build a couple of VERY SMALL projects first before you launch yourself on a big project. Your first few projects will be very messy and hard to maintain, despite your best intentions to the contrary. Practice Ruby with simple problems like the ones at Project Euler. Ask a lot of questions. Shun the Rails Wiki pages. The information there is generally a mix of wrong AND out of date. Watch Railscasts videos. Suffer gracefully. Ask more questions.

Got any more advice to share? Post it here!

BookMooch vs. PaperbackSwap (Part 1 of 2)

I've been using BookMooch to trade books with people, and it's generally worked pretty well for me. However, I found myself ultimately with a number of points and a big wishlist of books that I wanted that nobody offered. Enter PaperbackSwap. I've been a member for about a week now. What do I think about it? I think they got a bunch of stuff right that BookMooch hasn't. Take a minor example: That's a referral banner that I can include in my blog post. I get points if you sign up through it. If you find this post at all helpful, I hope you'll use that banner to sign up for PaperbackSwap. What's the difference, you're asking? The most compelling reason for me is that they have a bigger catalog than BookMooch. Checking out the "Under the Hood" link earlier today, I found that they have around 4 books posted every minute. Right now the site says 2,280,827 books available. One of the most striking differences, to me, is the fact that BookMooch only gives you 2 points to start with (meaning you can request 2 books), and after that you can only ship books to other members or buy points, as a means of getting more points to request books. BookMooch, on the other hand, awards 0.1 points for every book posted and 0.1 points for every book you receive and provide feedback on. This means that BM is creating points constantly regardless of whether you're posting useful books into the system or not. More points received than spent means that it's easy to mooch books, and you don't even have to post books that anybody wants.

Surprising findings using Ruby Arrays as Queues

I'm working on an Aho-Corasick implementation in Ruby, and found something interesting about Ruby. Well, something interesting to a relative newbie, I suppose... Arrays are the Ruby object that people use for Queues in Ruby. Which is a little odd, because the performance of Ruby arrays as queues is pretty poor. Worse, in fact, than inserts into a Hash. This is probably due to the fact that pushing objects into an array requires growing the array. Furthermore, I found that the performance of Array#+ is better than Array#push and Array#<<, even though all three methods ostensibly do the same thing. It turns out that Ruby does have a Queue object that performs well. It's intended for producer/consumer operations across multiple threads, but nonetheless it performs much better as a Queue than arrays do. Here it is, the Queue class in all its glory.