Firefox is a great browser and is also a great development tool in itself. There are some problems though with the numerous extension available to developers. They are a great resource when programming but they slow down (and in some scenarios they might even break) our normal web browsing.
So the idea is to have a normal Firefox installation to use as our browser and then a separate install (and profile) used only for development purposes. This way we can install tons of development related addons without worrying about slowing down our normal browsing. Of course this is only useful if you use Firefox as your primary browser.
- Download the Firefox installer
- Launch the installer
- Set the destination folder to
c:\dev\Develfox - Uncheck the options to create shortcuts on desktop, start menu…
- Uncheck the option to launch Firefox on finishing the setup
- Go to the installation directory and start a command prompt there
- Run Firefox with the following command:
firefox.exe -no-remote -ProfileManager- Create a new profile and name it Devel
- Exit the profile manager
- Create a new batch file name
develfox.batwith the following contents. It’ll copy on each run the firefox executable to develfox.exe so we can tell it apart from our normal browser on the task manager (we copy it on each run so that automatic updates are correctly applied).
@echo off
copy “c:\dev\develfox\firefox.exe” “c:\dev\develfox\develfox.exe” > null
start “” “c:\dev\develfox\develfox.exe” -no-remote -P “Devel”
- Run Firefox with the following command:
- Still on the installation directory go to chrome and create in there a directory named icons and inside that one another called default. Put in there a custom icon with the name main-window.ico to be used as the application icon. Check out IconBase for some nice ones.
- Create a shortcut on your desktop or another suitable place and use the following properties:
- Target: c:\dev\develfox\develfox.bat
- Start in: c:\dev\develfox
- Change the icon to the one used in c:\dev\develfox\chrome\icons\default\main-window.ico
- Launch the shortcut to execute our new Firefox installation. It’ll be a vanilla one so now it’s time to install our development addons ( Firebug, Webdev toolbar, Yslow, Clearcache, Venkman… ) and also a custom theme so we can easily know in which firefox we are at each moment.
- To further customize our new Firefox installation we can install the Firesomething addon, which allows to change the window title to anything we want.
Following with the series I will introduce in this chapter Cygwin.
Cygwin is an excellent collection of Unix utilities and programs ported to Windows. While its ‘emulation‘ of an Unix like environment is quite good I actually don’t use it. I install it just for the helpful utilities it has. Although I do occasionally use its shell to perform some command line tasks which on Windows’ cmd.exe would be a real nightmare to perform.
Lets set it up and then we can see some tips and tricks.
- Download the Cygwin installer
- Move the installer (setup.exe) to
c:\dev\cygwinand launch it - Set the Root Directory to
c:\dev\cygwinand the Local Package Directory toc:\dev\cygwin\packages - Choose at least the following packages to install. You won’t probably need all of them but in my experience these are the most commonly used and they don’t take much space actually:
- Admin: shutdown
- Archive: unzip, zip
- Base: bash, findutils, grep, gzip, run, tar, sed, termcap, terminfo
- Database: sqlite3
- Devel: binutils, automake, cvs, cygport, gcc, make, subversion
- Editors: nano, vim
- Graphics: ImageMagick
- Interpreters: m4, perl, python, ruby
- Net: curl, openssh, openssl, rsync
- Shells: bash, bash-completion
- Text: less, tidy
- Utils: bzip2, cygutils, diffutils, gnupg, patch, screen
- Web: cadaver, curl, httping, links, lynx, wget
- Now wait for all packages to download and install (it will take a while)
- Once the installation is complete we can launch the Cygwin system by running
c:\dev\cygwin\cygwin.bat - On the first run it’ll create a new configuration and home directory for our user. Follow the instructions given on the terminal to complete the installation.
Ok, so Cygwin is now setup and it’s time to learn a few tips.
On a standard installation Cygwin will create a home directory for the user in c:\dev\cygwin\home\[USER]. However we might want to re-use our Windows folder so we have a unique location for our stuff. To do it we just need to create an environment variable (in System Preferences) called HOME with the path to our profile folder (c:\Users\[USER] in Vista). Now we have to edit /etc/passwd and change the home folder to our Windows profile one (/cygdrive/c/Users/[USER]), we can move the contents of the old home folder to the new one with the following commands:
mv /home/[USER]/* /cygdrive/c/Users/[USER]/.
mv /home/.* /cygdrive/c/Users/[USER]/.
By default the Windows drive letters are accessible in /cygdrive/[DRIVE], that is ok but it’s used often so we can save a few key strokes by creating symlinks at the root of the file system. Create one for each of your drive letters so you can access them as /[DRIVE]/my/path/to/a/file.
$ ln -s /cygdrive/c /c
As we have seen Cygwin uses Unix like paths so to launch Windows programs from the shell we have to make an extra step and that is to convert between paths. Fortunately there is a little tool called cygpath. When used without modifiers it will translate a Windows path to a Cygwin one and when used with the -w or the -m modifiers it will do the opposite conversion.
Another nice tool is cygstart which launches a program (or the default program associated with a document). The good about it is that it will launch the program and detach the process from the console.
For commonly used programs it’s a bit uncomfortable to use cygpath and cygstart, like for example to launch our favourite text editor. In this example I’m going to use Notepad as an example. We just have to change our bash init script (~/.bashrc) to include a function to launch Notepad easily from the command line. Add the following to your .bashrc file:
notepad () {
cygstart “c:/Windows/System32/notepad.exe” “`cygpath -w $1`”
}
Now we can edit the contents of a text file just doing notepad /var/log/setup.log. This is a great way to really integrate Cygwin with Windows, which actually makes the Cygwin system ready for real work.
Another useful utility is cdargs which while not an official part of the Cygwin system can be compiled from source. To install cdargs we just have to download its latests source tarball and unpack it into your Cygwin home directory. Then issue the following commands:
$ cd cdargs-1.XX
$ ./configure
$ make
$ make install
$ cp contrib/cdargs-bash.sh /etc/profile.d/.
$ source /etc/profile.d/cdargs-bash.sh
Explaining how to use this tool is beyond the scope of this article. There is a nice mini tutorial at Linux.com and Google will give you plenty of information about this tool.
There is a lot of software compatible with Cygwin beyond the packages included in the official repository. The Cygwin Ports project offers a few dozens of applications already compiled and ready to be installed. It’s well worth a look.
Besides there are many Unix/Linux applications which can be compiled to be used in Cygwin even if they don’t redistribute the binary packages.
Disclaimer: 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 since coLinux is not compatible with 64bit versions.
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 implementation.
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:/documents%20and%20settings/drslump/projects
# this one is for my subdomains
file:///var/www/subdomains => file:///c:/subdomains
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.map
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 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
Update: It seems that Komodo 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.
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