@TheKeyboard Always code as if the person who ends up maintaining your code is a violent psychopath who knows where you live.

I’ve been thinking about topics for conference talk submissions a lot lately (I have a serious case of conference envy the last little while), which usually gets my dev juices going and trying to make a better dev environment for myself. I’ve started using a few newer techniques so forgive me if some of these seem old to you, dear reader.

MySQL over an SSH tunnel

I certainly can’t be the only person who has to do development (or refactoring) work involving databases that have GB of data in them. It’s not even remotely practical to copy it over to my laptop, and taking a snapshot is pretty much impossible given the relationships between the tables. It would be 3 times the work to create a tool to give me a snapshot that includes all the proper related records. How do people handle that anyway?

So I discovered via my favourite pair-program-via-IM partner the technique of tunnelling to MySQL over SSH. It couldn’t be easier:

ssh -fNg -L3310:127.0.0.1:3306 user@server.domain.ext
mysql -h127.0.0.1 -P 3310 -u user -p database

You can use whatever port you want at your end, but the key here is telling SSH that you want to map port 3306 on the remote server to a specific port at your own end.

The only downside I’ve seen is that when I was pounding on a remote server with a very involved query that the remote server started writing MySQL tmp files to disk. Files so large that they started to trigger our Nagios monitoring process that look at free drive space. Maybe I shouldn’t do that on a production server. Heh.

Use an editor that supports remote debugging in PHP

I took a Twitter poll and asked how many people actually use debugging tools like xDebug and was surprised by how many don’t. I have used them off an on (more on these days) and now that I’m using vim I have also started debugging stuff inside of vim. Is there *nothing* you cannot bend and twist vim to do for you?

This just further reinforces my recommendation that whatever editor you do decide to use every day, learn it inside and out. Right now I’m trying to break myself of the habit of using the arrow keys to move around in vim, instead relying on the hjkl home row keys to do so. Debuggers are so common in other languages (Ruby and Python have an awesome interactive console to act as a debugger for you) there is no reason except for, I dunno, laziness and an unwillingness to learn how to add an extension to your PHP install, to not at least try using xdebug.

Don’t procrastinate, read the documentation

A side project I’ve been working on has some of the tightest production-level PHP code I’ve ever written in it. Why? Because I took the time to dig into the documentation of the newer features in Cake to see how they apply to the work I’m doing. Containable behavior that is now part of the core. Johnathan Snook’s Multiple Validation behavior. Fat models and skinny controllers. Reusable elements in your pages. Pestering Nate and Garrett via IM to confirm my suspicions on how to tackle certain problems “the Cake way”. It’s amazing what happens when you stop to think about all the techniques you’ve learned and then figure out the best way to weld them all together to solve a problem.

Again, I’ve said this before and will continue to say it: making the effort to fully understand the tools you are using (that includes editor AND programming environment) can only make you better.

If the documentation is bad, don’t even bother using it

My IM pair-programming partner once said to me “Chris, if the documentation is shit then don’t even think about using it.” Lately I’ve seen the wisdom in that. If the documentation is lacking, just forget about using that tool. Of course, if you *do* have the skills to dive right into it and figure out what’s going on then this technique probably doesn’t apply to you.

Learn your version control system, or else have it decide your fate for you.

There is incredibly well-written documentation for what I call the Big Three (CVS, SVN and Git) open source version control systems. For the love of Wotan, go and learn the one you are using beyond how to commit a change. And if you AREN’T using a version control system (no, renaming files to index.php.old.frank is NOT version control) then you should stop calling yourself a programmer. Seriously.

Peer code reviews are good, not bad

Even if it consists of taking 15 minutes to talk with your boss who wrote stuff and says “but I’m not really a programmer” so he understands the changes (for the better that you are making, it pays off huge in the end. Especially when you know they will be going back in to tweak things as they play with the code you wrote.

That’s all I can think of for the moment. What programming techniques or tools have you come across that have made your work go faster or help you produce better code? Let me know in the comments.

I’ve got a whole bunch of little things I want to talk about, as opposed to one big topic. Here we go

• You’ll see a badge on the right side of my blog announcing that I’m speaking at Open Web Vancounver 2008. If you can make your way up to Vancouver on April 14th and April 15th, please come up and support this conference.
• I got an email from someone on the CakePHP mailing list asking me about what sort of setup I have for running my apps. I have a 256 MB slice with slicehost, and I have ZERO complaints about performance. I’m running PHP 5.2.5 under fastcgi (I use nginx as my web server), with MySQL on there to power my blog. In an earlier post I wrote how to create the rewrite rules for CakePHP to work with nginx, so search my archives for that. I’ve got Python on there as well for my upcoming Django work, and soon Apache will be on there to act as my app server for Django.
• Wrote my first Python script for work: it trolls through a bunch of gzipped XML documents, doing some search and replace. 75 lines of pure Python n00bness, built entirely with the help of “Dive Into Python” and google. I’m sure it could be optimized by some more experienced Pythonistas, but it sure felt good to get the first one done and out of the way.
• I’ve decided to start using twitter again, see how long that lasts
• The more I use it, the more powerful I realize jQuery is
• Some ruthless refactoring has caused my Code Igniter code to be a bit more CakePHP-like, in that I’m moving stuff into models and out of the controller wherever it makes sense. That’s a good practice no matter what framework you use
• As much info as there is out there for using Django (the Django project site, the Django book available online), it sure would be helpful to me to find some sort of Django guru who can help me out with some of the finer points of Django and Python itself. I’m trying very hard to not write Python code like I was writing PHP, and I feel like some of the finer points are escaping me.
• I’m working on moving some old CakePHP code I have that runs on PHP 4 over to PHP 5, and having PHP 4 *and* PHP 5 running on the same server. Should be an interesting experience