Almost. I do have more time this week than I did the previous week, and even more than the week before that, and so on. The last time I was out at HQ someone who had just found out that I was writing a book asked how in the world I had the time to do it. What, with starting a new job at a start-up and all. Quite honestly, I don't know how I managed. The last few months have been little more than a blur.
Here's a few highlights. As you know, America elected its first black President. Hooray! I didn't vote for him. That's a whole other, guilt-ridden post that will come out at some point.
Around the same time I finished up my book. This past Tuesday I got the final draft after the layout guys had got it ready for publication. According to the schedule I have, the printers should be setting it up as we speak.
Working with everyone at Pragmatic Bookshelf has been an unbelievable honor and an amazing learning experience. I thought I knew a fair amount about writing. Working with professionals showed me exactly how much I didn't know. Good thing I draw my monthly paycheck from another line of work.
This last week Meg and I put in an offer on a new house right off of downtown Lawrence and had it accepted. There's a great story revolving around the offer process that, again, is a post unto itself. We're set to close the first part of December assuming everything continues along smoothly.
It's a great, nearly 100-year-old house two blocks from the heart of Lawrence. Stoked doesn't begin to describe how excited we both are, but there's some miscellaneous to take care of. Speaking of which, if you know of anyone in Lawrence who would love a killer deal on a townhouse through July of '09, let me know.
On the code front, I've got back to coding for fun. With the book and talks and everything that's been happening for the last few months I had almost forgot how much of a joy it is to sit down and hack on code just for the joy of creating something.
One of my co-workers, Brian McCallister, created a mailing list for Yet Another Bug Tracker, or yabt. The last time I was in Cali we were talking about how we both wanted a simple bug tracker that stored everything in the repository. Whenever you've got your code, you've got your tickets too.
Both of us have been kicking around the idea for years, he finally did something about it a few weeks ago and I've been playing with some code this week. I posted what I anticipate the initial CLI looking like. If you're interested in participating, join up and share your thoughts.
Other than that, not much is happening around here. I've got some much needed vacation time schedule for after Thanksgiving, just in time to get ready to move! :-)
While I've been writing my Git book, I keep trying to pick up new tricks and figure out places to use them. A came across a post on git rebase --interactive and knew I had to find an opportunity to play with this. This morning, that opportunity came.
I've been working on some performance enhancement at work this week. I use Git locally for all of my development, then push back to our central Subversion repo once my changes are done and approved for the main repository. Timing for the changes I made earlier in the week was bad, so I was going to hang on to them for a week and push them when our engineering/QA department can absorb them more easily.
... the observant reader should be picking up on the past-tense here ...
So as part of my changes I created a Registry to share a single instance of an object around instead of going the Singleton route or putting the data in the global scope. Pretty useful all round, but silly me didn't think to put that in a branch by itself so I could pull that change around as necessary. No worries.
Light Bulb! "Ah ha! I'll just switch into my branch and use git rebase --interactive to rewrite all of those commits and squash them together. A quick git cherry-pick later and I'll have my Registry object in this new branch on some other functionality I'm working on."
If you've ever used git rebase you can probably see where this is going. If you haven't, it's probably one of the more dangerous commands—if not the most—in Git. It will literally let you reshape the history of the repository. Running with scissors is child's play. No, rebase can really screw you over. Imagine riding a unicycle while juggling four meat cleavers and you'll have the idea. Really, and I mean really impressive to watch, but one false move and you're screwed.
So back to my experience. I proceeded to weed through the 80 or so commits from Monday afternoon and Tuesday morning and pull out everything that didn't relate to the code I wanted. "Git will just ignore those" I naively thought. I got it down to the 8 or so commits that had to do with my registry object and its tests and squashed them all into one commit. I knew I was rewriting the history, but it never occurred to me that I was rewriting history. I let rebase do its thing, then cherry-pick'd my newly created revision and was off.
Until this afternoon. Rumor of my changes had made it around the office and someone else wanted to see them. Since I only track our trunk and not all of our branches and I'm the only there using Git, the easiest solution was to just create a patch to send to him. Simple enough. Use git merge --squash and git diff --no-prefix --cached and I'd have a patch he could apply directly to his copy and we're set.
Needless to say, when I started reviewing the patch, I notice there was a lot missing. :-(
Lesson learned. Don't play with live data when trying new stuff out. When you miss a bean bag while you're juggling, you don't loose your toe...
Either I'm making up for time I spent slacking, or I just took 4 years off of my life today. Today I managed to:
- Have my git book from Pragmatic Bookshelf announced: Pragmatic Version Control Using Git - It'll be on a shelf near you this fall and in PDF form before then.
- I filed my taxes (not completely today - I'd already done then, just hadn't submitted them yet)
- Proved conclusively that an installation stack wasn't stable for production (which is always fun when it's a random failure and you're having to play by the Law of Large Numbers)
- Proved conclusively that another stack was stable
- Should be able to prove or disprove a third stack configuration by the end of the night
- Got PHPT setup for inclusion into PHP as a replacement for the run-tests.php code which means it'll be distributed as part of the core PHP product
- Got PHPT onto the Google Summer of Code project list for the upcoming summer (as part of it becoming part of php-src)
- Fleshed out a killer business idea with a buddy of mine
- Wrote what I think was a pretty good article on relational databases
- Spent an hour at the gym this morning doing a lower-body workout
And it's just now 5. ;-)
If you follow my tweets, you'll have seen that I'm writing Pragmatic Version Control Using Git. Needless to say, I'm pretty excited. Of all of the publishers to write for, the accidental ones have always been high on my list since the quality of their books is so universally high.
I've been wanting to write a book for awhile now, I just could never figure out what on. Some time last year I decided that I wouldn't push it until some topic felt right. This past winter as I learned Git it started to feel right. Before I committed to a book, I decided to write an article (which should appear in over the summer in php|architect). When I finished the article I realized I had barely scratched the surface and that it would take a full book to do the topic justice. And now a few weeks after my initial pitch to the Pragmatic Programmers, I'm set to start.
The market for this book is wide open right now. There is nothing available in print form on Git so the newbie is left to manpages and random blog posts that Google turns up. You can find out how to do just about anything, and in the time-honored Perl tradition, you can find out 10 different ways to do most things. For someone just interested in evaluating it, though, there isn't much out there. Find answers to the questions "what good is it?" (in a non fanboy way) and "how do I use it every day?" requires some digging. By the time I get through with this book, I plan on having both of those questions, and a few more answered.
Since this is my first book, I'm sure there'll be blog posts aplenty about the process and such. Right now I'm raring to go, using most of my free time to write. We'll see if I still feel that way after the third rewrite of an intro paragraph to some odd ball chapter. :-) If you're interested in following this, I'll be tagging posts with git book (atom feed of git book posts).
Finally, if you're feeling generous with your links, I'd love the help getting the phrase "git book" to the top of Google. Only one post tagged and I'm already on the front page, but it never hurts to have a few inbound links too ;-)
I've been kicking around the idea of a book on Git. I think it's a great tool, but there's a lack of an accessible guide to get started with. In any book on a new technology or tool, there's the initial sales pitch. Why should you use this? How is it better than what you're already doing? Than its alternative? I'm trying to answer those questions right now for myself. It's only a few paragraphs of the entire book, but I think having the answers will help keep me on track for the rest of the book. Here's what I have right now.
Distributed
One of the main reasons for using Git over the two traditional version control systems—CVS or Subversion—is its distributed architecture. Instead of having one central repository, or one central point of failure, each developer clones the entire repository. Changes can then be pushed back to a central source, or a completely different source.
In the workplace, this allows for multiple layers of code review before the code makes it into the main repository. Each developer would push their changes back to their team's repository, with the team captain pushing changes back to the main company repository after they've been reviewed and the unit tests are verified.
In the open-source community, distributed means that no one company or person controls the repository. Any developer could easily publish their changes with the exact same history up to their change. These changes could then be incorporated by developers that are still tracking the official repository, allowing them to try them out without leaving their version control software unused.
Easy Branching and Merging
Branching within Git is easy and without much overhead. Tracking multiple branches, merging changes from many branches in to one, tracking changes across multiple merges. All of these are considered esoteric in most version control systems, only for the most advanced user. While they still take some practice in Git, doing them is straight forward.
Tags are Just Tags
If you moved from CVS to Subversion, you were probably surprised the first time you realized you could change code that you "tagged". Git enforces the "gentleman's agreement" found in Subversion by not allowing anyone to write directly to a tag, treating it as just a named snapshot.
Network Not Required
It is easy to forget in the age of always-on broadband connections, but we don't always have a network connection. Since your working copy is your repository, you don't need access to a network connection to track changes. You can safely work on your code on your next plane trip, tracking your changes the entire time, then sync with your repository after you've landed.
Can Communicate with Subversion
In the centralized world of Version Control Systems (VCS), Subversion has become the defacto standard for new servers. Having the ability to communicate with SVN means that your entire company does not have to switch to Git just to suit one team or one developer. They can maintain their copy of the repository along side the existing infrastructure and push and pull changes to Subversion seemlessly.
Anyone out there using Git have anything more to add? What's the obvious thing I'm missing?
