kevin old - my take on life as a geek

Yeah, I know.  Cheesy title. But, it’s true. I’ve been using Git for the past several months and am amazed at it’s powerful simplicity. The concepts are easy to grasp thanks to great documentation and real world examples.

I’d heard all the rage about the other SCM’s. I’ve looked into Mercurial and Bazaar, but wasn’t as impressed with them as I was with Git. After following the timeline of emails as Linus wrote and shared his new creation and watching his visit to Google, I gained a whole new respect for distributed revision control (DRC).

It’d been hard to miss all the talk around DRC, but thought it’s only benefits were to interact with my repository when I didn’t have connectivity. I was almost always connected, so my Subversion repository was all I needed - so I thought. Having read a post about cloning repositories, I decided to investigate why so many people were now using Git. While researching Git, another article about “forking” caught my attention and slowly I started to see all of the wonderful benefits I’d been missing by not using a DRC - specifically Git.

Most notably:

• Branching - the way it’s suppose to work! This is “throw away” branching at it’s best!
• Cloning - This is extremely useful when stumbling across projects on services like Github. Instead of the traditionally checking out a copy of the trunk or a branch in CVS and Subversion, Git clones the entire repository into a local directory for you and “…creates remote-tracking branches for each branch in the cloned repository”. A great example is Reddit. When they released the code, I cloned the repository and every few days I can run “git fetch” to update the remote-tracking branches. I can run “git pull” to update the remote-tracking branches as well as “merge the remote master branch into the current master branch, if any”.
• git-svn - Simply put, this is brilliant!!! Having all of my repositories in Subversion this allowed me to have a “trial run” with Git. I was able to make a local “Git clone” of my Subversion repository, interact with it and “sync” the changes I truly wanted committed to the Subversion repository. I could create as many throw away branches as I liked and the Subversion repository never knew anything about them. Needless to say, the VERY DAY I started playing with Git, I made my last commit to my Subversion repository and haven’t looked back since.
• git-stash - Again, BRILLIANT!!! Stash “saves your local modifications away and reverts the working directory to match the HEAD commit”. Every developer I’ve talked to about this with has the same reaction - (AWESOME!!!!) - as we’ve all been in the situation where they were working on a new feature and they need to fix a bug. Most of us have a “fixes” version of trunk in a separate directory for just this purpose. But with git-stash, you can have this freedom with a single working copy!
• git-diff - Git tracks content, not files. Each commit is tracked by it’s sha1sum, shown beside each when issuing a “git log”.

I was also impressed with the wealth of information and comparisons of Git with other SCM’s others had put together.

Recent news about Gist show the flexibility of Git repositories. Thanks to services like Github Git is gaining more respect and notoriety, almost like the movement when Subversion first came on the scene.

Finally, after months of users begging Google to support Perl on Google App Engine (GAE), there looks to be a positive response as Brad explains.

The majority of the work will have to be done by the Perl community, but Google is giving Brad and other Google developers “20%” of their time to be devoted to this “pet project“.

When launched I played with GAE briefly and once I saw the support for Django I took another look. Since I don’t program daily in Python it takes me longer to the most basic things I as spend my time writing pseudo code when unsure and looking up syntax later. I’ve yet to test the sample Django app out on GAE, but hope to someday soon.

It appears that to the Catalyst community YAML isn’t the best config file format any longer as they’ve chosen to switch in favor of Config::General - which defaults to the "apache config format"

From Config::General’s POD:

The format of config files supported by Config::General is inspired by the well known apache config format, in fact, this module is 100% compatible to apache configs, but you can also just use simple name/value pairs in your config files.

Catalyst::Plugin::DebugCookie even provides the updated configuration style in it’s POD:

 <Plugin::DebugCookie>
    secret_key 001A4B28EE3936
    cookie_name my_secure_debug_cookie
 </Plugin::DebugCookie>

The following command can be used to dump an existing Catalyst app’s config into an Apache style conf file. You’ll definitely have to edit the resulting file, but at least it’s a start.

perl -Ilib -e 'use MyApp; use Config::General; Config::General->new->save_file("myapp.conf", MyApp->config);'

I’m a fan of The Big Idea with Donny Deutsch watched a show I’d DVR’d the other day. The show was about the "Comeback" mindset. Most of us know that our dreams don’t come true overnight and that on the way to our dreams we often have a hard road and sometimes get discouraged. The show featured people who had been knocked down, but came back.

Of the guests on the show the following quote by Dr. Karen Reivich made the most impact on me:

Resilience. It’s learnable. The heart of resilience is believing that you can affect change. [It] might not affect the whole situation, but there is an aspect of the situation you can control.

Excellent advice not only when times are tough, but as motivation when solving even the most difficult day-to-day problems.

I’m not sure how I’ve made it this far in my career and never knew that grep had a color option to highlight the term you’re searching for in the results.  Guess I’ve never really needed it that bad, but since stumbling across this, it’s made things a lot easier to view.

To make this seamless you can add this to your .bash_rc or .bash_profile:

alias grep="grep --color=auto"

Thanks to asommer’s .bash_rc for pointing this out.