17 Nov
Making Mistakes So You Don’t Have To: Development Tools
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.
Article Tags >> CakePHP || development tools || documentation || MySQL
Posted by Neon on 17.11.08 at 10:23 pm
“Don’t procrastinate, read the documentation”
This is so so true! I get questions at work from people working on Cake applications who know PHP, but are just trying to copy entire chunks of controller code into new controllers and wondering why it doesn’t work.
Nothing worse than seeing all that raw php in an application, which is doing the same thing that helpers and framework functions are there for.
Posted by Dieter_be on 17.11.08 at 10:23 pm
“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.”
They can call themselves programmers, as long as they don’t call themselves *developers*
Posted by derek martin on 17.11.08 at 10:23 pm
“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.”
That perfectly describes the problem I’m having at the moment. I’ve inherited a codebase from a developer who *obviously* knows LOTS of stuff inside and out. He setup the server. He wrote the framework. He wrote the logic. He wrote the ORM (php + mysql5.1 + stored procedures). He wrote the javascript. What he forgot to do is “STOP AND THINK”. As a result, the code is hard to read, and offers 7 different ways to do anything… but only 1 way is un-deprecated, and which of the 7 that is remain un-documented
He was too busy to stop, think, refactor. Pushed by tight deadlines and being a 1-man-army, his battle-cry was “I’ll fix that later”. That’s fine when it’s always going to be a 1-man-shop, but now they’re trying to scale to more developers, and after staring at the code for SIX WEEKS, I can still barely make heads or tails of it… and I’ve been a full-time professional php developer for 8 years now. It’s ridiculous!
p.s. — did you choose the words that show up in your captcha? Mine currently says “overconfidence”