I love jeweler for releasing my gems, however I tend to forget how it is working, so here’s my release workflow.

1. Bump and Commit

Bump the version (usually in lib/a_perfect_gem/version.rb) and git commit my latest changes

2. Doublecheck

git status to check if my working tree is clean

git status
# On branch master
nothing to commit (working directory clean)

Otherwise jeweler will complain

$ rake release
rake aborted!
Hey buddy, try committing them files first

3. Release

Finally do

$ rake release

which will

• tag the commit with "v#{A_PERFECT_GEM::VERSION}"
• push the commit(s) to origin
• push the tag to origin
• build the gem
• push the gem to gemcutter

Props to [technicalpickles].

I recently had to port a very old perl project to a new server, which is running mod_perl- that made me some headache as I didn’t know anything about that environment.

Pages with dynamic form input from CGI::param suddenly seemed to be “cached”, the script did process old variables and emitted wrong output. After diggin’ into mod_perl with this great article the solution was quite easy.

mod_perl somehow keeps a persistent process environment, thus restoring variables declared with my. As I didn’t want to rewrite the whole thing I simply changed lines like

my $type = param("type");

to

local $type = param("type");

and everything works fine and “uncached”. I know there are several pitfalls with local again, anyway, I’m not into mod_perl, things seem to work and a 10-years old medieval project’s running again.

Colleagues keep laughing at me.
It seems that I missed the point in a programmer’s life where he faces a shimmering light at the end of the dark terminal tunnel, where he suddently gets enlightened… and switches to eclipse or Textmate.

Being an IDE-reject I’m used to work with bare-bones text editors, which support syntax-coloring, a bright background and a few well-established keyboard shortcuts like Cmd+c Cmd+v.

That’s all I need.

Ever since I can remember I disliked IDEs and how they suppressed my way of organizing files, tools and minds. And they are slow.

The last 4 years I worked with nedit and my own small file-browser kebap. Two weeks ago me and my colleague Felix discovered scribes, a text-editor for Linux written in Python. Dozens of text-editor came and went away in my life, but for some reasons I really like scribes. Some of its key features I already love are

• streamlined workflows with a simple and clean UI
• jump to files with the F9 file-dialog by typing their name
• code templates which can be triggered while typing
• character pair completion -yeah i hate to close a bracket and move back the cursor by hand
• word completion while typing remembers phrases you typed, like long function names and cryptic variables
• sufficient syntax-coloring for Ruby and PHP (well that could be better)

I really was distracted by the tab-less UI first. “What a mess!” came to my mind. A couple of days later I was conviced that the arrogant attitude of scribes is… cool.
It’s useless to organize your docs in tabs, the more docs you open, the sooner you forget which tabpanel holds the code file you’re looking for. So why not let the F9 file browser keep track of all those files?

Today I noticed that I had 46 opened scribes documents - each in a separate window - while programming at work. Since I simply hit F9 and type in a few characters to jump to the file I completely forgot the “need” for MDIs, tabs, project managers and other “tools”.

Enough praising, let’s hit the keyboard.

Installing scribes 0.4-dev on Ubuntu Jaunty

The 0.3 version shipped with Ubuntu has some bugs, so I recommend the 0.4 version which is almost stable.

sudo apt-get install bzr libglib2.0-dev gnome-common
bzr branch lp:scribes
cd scribes/
./autogen.sh
make
sudo make install

When starting scribes in a terminal, you might get a python exception bitching about
ImportError: No module named gtksourceview2

Well, just do

sudo apt-get install python-gtksourceview2 python-gnome2-desktop-dev python-gnome2-extras-dev

and have fun experiencing a smart, but not too smart editor. Thanks, mystilleef!

Branching

If you’re planning to

• change huge parts of your code at once
• introduce a complex new feature or another API
• switch easily between different - simultaneously running - development processes of your project (actually, that’s called a branch)

you’re better off creating a new branch. As soon as you switch to this branch, the former version won’t get touched anymore. You can easily merge back the changes from the new branch to your master version.

First, list the local branches

git branch

Creating a branch
You start by creating a new local branch

git branch dynamic

we call the new branch dynamic.

Then switch to your new branch. The code will be the exact state when you left the former branch.

git checkout dynamic

You can now apply changes, commit and push to your new branch.

Don’t forget to push the new branch to your remote repository

git push origin dynamic

Merge the branch back
After you think your changes should go back to the master branch, merge ‘em, where the newer will supersede all of master

git checkout master
git pull . dynamic
git push

{is git pull . dynamic + git push =?= git merge dynamic}

Tagging

I often explain a tag in git as a bookmark which lets you return to some specific version of your code. As you can have an unlimited amount of tags, you can have as many bookmarks as you need.
So when you want to take a snapshot of your code saying “if I had releases, and would package my code, this version would be packaged as 2.2.1.tar.gz” why not simply tag it as 2.2.1?

To list the bookmarks you already made, enter

git tag -l

Creating a tag
Right after you found some nifty name for your tag - let’s say we call it 2.3 - create an annotated (not signed) tag with

git tag -a 2.3

Until here the tag will reside in your local repository only and will be pushed to your remote repos instantly if you command

git push --tags

You can switch back to any version you tagged using

git checkout 2.3

which is really helpful for both developers and users since you can distribute multiple versions in one repository.

Deleting a tag
If you simply want to delete a local tag, do

git tag -d v3.3.4

However, if you need to remove that tag from your remote github repository, you simply push nothing to the tag name.

git push origin :refs/tags/v3.3.4