A wise man once suggested that one of the steps in teaching yourself programming involved working with people better than you. (See Teach Yourself Programming in Ten Years)

Even though I feel I’m a pretty competent software developer, I’m very excited to join another developer for which I have a truly profound respect. I’ve only recently made the career move of working on the web full time, and this is a great opportunity for me to kickstart this phase of my career by working with a Rails / REST / jQuery guru.

Starting today, I’m working for GiraffeSoft, with James Golick. We’ve wanted to work together for a while, and the stars have finally aligned to make this possible.

I’m ready to bet that setting up and deleting remote branches is something you do rarely enough that you always find yourself looking up the documentation. Or maybe it’s just me.

Due to its roots, Git supports a wide array of usage scenarios for interacting with remote repositories, and we love it that way. It’s a big factor in the flexibility and power of the tool.

However in simple scenarios, there’s still a bunch of commands you must run to accomplish simple tasks. I believe the commands for the simple scenario can be simpler.

Last January, Carl Mercier created git-remote-branch. I’ve found this script very useful and, with his permission, I’ve decided to keep moving it forward and add a few features to it.

I’m kind of jealous. This guy put out 2 freaking good blog posts in 3 days. These are apparently his first 2 blog posts ever, too :-)

You’ll never find a group who wears their ignorance of technology more proudly than the average business person. “I’m not a computer guy,” they’ll say with a big smile on their face. Well gee, the personal computer is only the most significant invention to come along in the past 100 years.

By Tales of an IT Director

Git is one hell of a powertool.

Like with any such tool, as soon as you get to know it enough, you start pushing the boundaries. Git gives you a lot of control over your repository:

• trivial branching and merging (even with long lived branches);
• rebasing as a cleaner alternative to merging;
• stashing aside your changes for a quick fix elsewhere;
• extracting logical, distinct commits from a multi-hours coding spree;

The list goes on…

More traditional version control systems don’t give you as much power as Git by any stretch of the mind. They are like taking a walk in the woods with your parents, at age 14.

You’re probably gonna see and do neat stuff, but you sure ain’t gonna get lost or anything.

Quote from the Git documentation:

<branch> When this parameter names a non-branch (but still a valid commit object), your HEAD becomes detached. Junio C. Hamano – the checkout documentation

Git – the only SCM that beheads its users.

This is part two of an ongoing series about Rubinius:

• Rubinius for the Layman, Part 1: Rubies All the Way Down
• Rubinius for the Layman, Part 2: How Rubinius is Friendly

In this shorter second installment, I’ll present the ways in which Rubinius will be friendly to your multiple personalities:

• you, the programmer;
• you, the (potential) contributor.

Rubinius is programmer-friendly

Backtraces

The first reason why I consider Rubinius more programmer-friendly is the better backtraces. I’ll show some examples run from each interpreter’s interactive console.

I’m taking a break from the Rubinius for the Layman series. I don’t know why my posts always spiral into multi-thousand words essays :-) Even worse, when I try to write about Rubinius it’s so easy to get into ratholes and start fiddling, poking at and exploring this wonderful beast. All of that instead of writing, of course.

Tonight’s fiddling led me to playing around with my .irbrc file. I guess we’ve all searched for examples of config files for IRB at one time or another. When you spend a lot of time into your interactive console, you naturally end up wanting to tweak it to your liking.

This is part one of an ongoing series about Rubinius:

• Rubinius for the Layman, Part 1: Rubies All the Way Down
• Rubinius for the Layman, Part 2: How Rubinius is Friendly

In January, Antonio Cangiano wrote an article titled Why Engine Yard, Rubinius and Merb matter. In his article he discussed the financing of Engine Yard. More specifically, he discussed why EY was not just another irrelevant startup being funded by starry-eyed investors. Au contraire! Engine Yard is already recognized as a solid hosting service provider for Ruby on Rails, and has a customer base. He then went on to discuss how they are going to use the money to fund the development of Merb and Rubinius by hiring the main contributors and paying them to work on these projects.

These two projects are very important for the future of the Ruby ecosystem. Rubinius is an attempt at a very powerful Ruby VM while Merb is an attempt at a solid alternative to Rails, with its own distinct advantages. It’s great to hear that EY has taken it upon themselves to basically put both projects on steroids.

For a while now I have wanted a bit more control than wordpress.com could offer me. Now has come the time to make the move.

Be sure to subscribe to the new feed.

The main reason why I make the move now is of course to begin the dogfooding process with Defensio.

I’m not going to bore you with a long post about moving a blog. Sorry for the inconvenience :-)

Ruby will get under your skin. You will miss its features and quirks when you’re not using it. You might even find other languages insufferable, once you get comfortable with Ruby.

After you’ve started using Ruby, there’s a significant chance you’ll start loathing whatever code base you currently have to work on. Especially if it’s a statically compiled language. A code base you used to think was ok, except for its few quirks.

After a while of perusing the different Ruby-related blogs, you’ll have heard other Rubyists speak of their work with words like beauty, productivity, expressiveness, conciseness, fun and you’ll realize just how far your current language is taking you from all of these words.