A web development environment (I) - Introduction

This will be a series of posts dedicated to document my current development setup. This setup tries to be the one of a Ninja. It won’t end up with a bunch of boring application windows typical of a bald engineer. It also won’t be a group of black terminal windows running vi as a pseudo operating system like the average geek wannabe. I’m in the search of the Ninja feeling, with white on black text editors, translucent terminals and a dose of eye candy so that I feel special without having to resort to browsing youtube with Lynx.

After many years I am finally happy with my current development setup. It fits my needs and this series of articles should serve myself as a reminder on how to setup the different pieces. However I guess that it will also be of inspiration for other developers who haven’t already found their peace of mind with their environment.

I’ll focus on Microsoft Windows systems but most of the stuff can be easily implemented in other operating systems. Actually much of the things I do for windows come standard in several operating system distributions, it’s just that I happen to like Windows (which obviously harms my geek status).

The main building blocks for this environment are the following ones:

Cygwin
A collection of very useful Unix utilities for Windows.
coLinux
Wonderful virtualization software to run Linux side by side Windows.
Debian
The only Linux distro I know a bit about. It’s fantastic so I don’t have the need to search for a better one.
PHP5
Currently the programming language of my choice.
Console2
An excellent terminal emulator with lots of eye candy.
Firefox
The browser that came to rule them all.
A lightweight text editor
Everyone has its favorite
A heavy IDE
Komodo and Eclipse to the rescue
Several utilities to ease our lives
TortoiseSVN, kdiff3, wincachegrind, total commander…

Before we begin I would like to note the following:

  • All tools are installed in C:\dev. I don’t like polluting the standard Windows installation with the development tools. Besides, it allows to easily backup most of the environment.
  • I’m using a 32bit version of Windows Vista since coLinux is not compatible with 64bit versions.

Xdebug bookmarklet

Nothing really new since there is already a firefox extension which does just the same, but I also wanted to support other browsers.

So this bookmarklet toggles the cookie Xdebug uses to check if it should debug the running script or not!.

Toggle Xdebug

Drag it to your bookmarks (or favorites or whatever your browser calls it) toolbar so it’s easy to access. Assign it a keyboard shortcut, if your browser has that function, and you’re done.

By default it’ll prompt for the idekey to be used by Xdebug, it’s a good idea to modify the idekey variable at the start of the bookmarklet’s source with your idekey or with default if you’re not using a DBGp proxy.

Introducing DBGp Path Mapper intercepting proxy

My current IDE of choice, Komodo, brings native support for the DBGp protocol to debug source code either locally or from a remote server. It has however some issues with its path mapping implementation1.

Since it’s not the first time I stumbled upon this kind of issue (my previous Eclipse PDT experience was troublesome too) I finally tried to solve it. The solution is an intercepting proxy server which listen for connection from the debugger to modify the messages it sends to the IDE with custom path mappings.

To define the path mappings we use a file with a set of paths on each line. The path tuples are separated by the => operator, placing the path understood by the debugger on the left side and on the right the path as understood by the IDE. The file looks like this.

# Mapping for projects
file:///var/www/projects => file:///c:/Users/DrSlump/projects
# this one is for my subdomains
file:///var/www/subdomains => file:///c:/subdomainsCopy to clipboard

Note that the path mappings are case insensitive to avoid problems on Windows.

To run the path mapper server we just need to call it from a terminal like so:

$ php5 dbgp-mapper.php -i 192.168.0.5 -m dbgp.mapCopy to clipboard

The -i option specifies the IP or host of the computer where the IDE is running, while the -m option points to the file where the path mappings are defined. There are also other options which you can check by seeing the built in help using the -h argument.

By default it will bind itself to the port 9000, which is DBGp default one, so if you are running this on the same computer as your IDE you will have to change the port either in this tool or on your IDE.

The source is available via this subversion repository

  1. It seems that Komodo’s uri mapping works properly after version 4.2.0. In my case I was having problems but after rebooting the system it started to work properly. 

TextMate, the myth

Source code editing and programming tools in general are one of those things I like to be up to date with, you never know when you’re going to find a killer tool which will boost your productivity.

For a couple of years I keep hearing about an awesome editor for Macs called TextMate. People even comment on forums and blogs that they are thinking to switch to Mac just to use it.

Well, I switched to Mac a few weeks ago and one of the first things I installed was this TextMate editor. Given all the hype around it I thought it was going to be my new favourite editor. However there is a lot of myth around this software. For the last year I’ve been using Eclipse on Windows as my heavy work IDE with Notepad++ as casual editor for quick operations. Now on the Mac Eclipse runs quite slowly so I’ve been using TextMate a lot in the last days and while it’s a great replacement for Notepad++ it doesn’t come close to a real IDE. The Bundles are nice and expose a lot of possibilities but they are useless to work on a big project.

When you have to deal with a few hundreds library files (Zend Framework, Doctrine, Pear…) plus another few hundreds of the project then there is nothing else to do that to use a real IDE with professional tools like integrated debugger, a real code parser, a code explorer and powerful refactoring tools (at least a good find and replace dialog with regular expression support). Then there are some extras like bracket pairing, code versioning, code formatting and smart indentation.

Sure some of you could argue that TextMate’s power is on its snippets/bundles customization but lets be serious. I don’t mind writing function or class constructs continuously, it can get tedious but what really hurts your performance is having to leave the file your are editing because you don’t remember the exact spelling of an obscure method from a rarely used class, or you can’t recall what was the order of the arguments for that function that you checked just two hours ago.

Given that Eclipse is running like a dog on my system I’ve searched for an alternative and to my surprise I’ve found a killer one. ActiveState’s Komodo IDE, which I had trialed a few months ago in Windows but didn’t really paid attention to it. It’s dialogs are a bit buggy, the default colour schemes are quite ugly, it takes ages to load, is very expensive and it’s not the easiest to configure to a point where it’s useable but… it’s really customizable and has a ton of features out of the box. Moreover there is Komodo Edit which is free but doesn’t have an integrated debugger, so I’m going to settle on it and will keep Eclipse for remote debugging. Let’s see if ActiveState drops the price so it can get more popular. By the way, it also has support for code snippets and macros which can make most of the stuff that TextMate’s bundles can do.

So right now, I’m using Komodo IDE and TextMate. When the trial periods of both are over I’ll have a combination of Komodo Edit, Eclipse and Smultron for the fast editing.

PS: Excuse the lack of links… google is your friend