You Should Use Vagrant

Setting up a web development environment has always been something of a pain. Sure, we web devs don’t have to deal with compilers and libraries and whatnot to get coding, but when it comes time to run your stuff, you need a server.

Assuming you don’t have endless resources to set up development servers remotely, and considering the pain of pushing code to a remote over and over while you write it, this has usually meant building your own server to test on. If you’re a linux user, you’ve probably gone through the steps of installing Apache and MySQL locally, a php interpreter, and so on, turning your desktop into a hybrid workstation-server. Maybe you’ve moved on from that and started using XAMPP or MAMPP or some other canned, all-in-one solution.

Then, once you’ve got everything dialed in how you want it, it’s time to start a new project and now you have to juggle vhost configurations. Then you need to work on some legacy code that needs PHP 5.2 to function, so you have to juggle multiple server setups. Then you decide to dabble in something like Rails or Django, so you install more dependencies and more libraries on top of every php extension and PEAR module you already installed for those PHP projects. Then you get a new computer, and uhhhh…

I went through variations on this theme for years, then I discovered Vagrant, and I’m never going back.

Continue reading

vim: Not so scary after all?

I’ve been using Sublime Text as my primary editor for a little over a year now, and while it’s a fantastic editor, it hasn’t quite been scratching my itches lately. I’ve used a handfull of editors and IDEs for web development over the years: notepad, notepad++, bluefish, kate, gedit, netbeans, and on and on. The whole time, even since my early Linux days as a teenager trying to install Slackware on my 486 (66DX with a sweet turbo button, for the record), there’s been whispers of that editor; The way of the ancient masters, the old greybeards who have spent years meditating in the caves of their server rooms to finally become one with unix: vim.

OK, I’m exaggerating slightly, but only slightly. I (and many others) always assumed that using vim was hard. Over the years I’d flirted with it here and there, firing it up only to get frustrated that I couldn’t even edit a config file before giving up and switching to nano (after spending five minutes figuring out how to quit).

Yet as time passed, more and more of my peers used vim simply as a matter of course. I gradually became embarrased to nano in front of my colleagues. Considering my recent discontent with my current editor, and a preponderance of my fellow developers using vim, I decided I’d finally bite the bullet and learn to use the thing.
Continue reading


I was first introduced to PsySH back at OSCON last year. While I still haven’t used it much as a debugger, I’ve found that a REPL is a handy tool to have around.

A PHP what?

PsySH implements a Read-Eval-Print-Loop, or REPL, for PHP. This might sound simple, but a REPL Reads input, Evaluates that input, Prints it to the console, then Loops back to the read step. What’s that look like, you ask? Let’s see.

>>> $foo = "Hello"
=> "Hello"
>>> $bar = "World"
=> "World"
>>> $foo . $bar
=> "HelloWorld"

Notice that after every input line, we get a corresponding output. The program is reading our input ($foo = “Hello”), evaluating it (this is an assignment, so it’s straightforward), printing it out, then prompting for input again.

Wait, We Already Have one of Those

“But wait,” I hear you say, “PHP already has an interactive mode!” True, php -a exists, but have you actually used it? It skips the Print part of that whole REPL thing, it has a tendency to crash if you accidentally have a PHP fatal error, and it doesn’t really do much aside from giving you access to a PHP interpreter.

“But wait,” I hear you say, “Facebook already did that!” Yes, phpsh is a thing that facebook did, but they seem to have forgotten about it (last updated three years ago at the time of this writing) and it has this inconvenient dependency on Python. As in, it’s written in Python, and you need to have Python available in your environment to use it. Hmm.

OK, but why?

Remember the bad old days before in-browser css inspectors? Styling elements was a major pain, right? Edit your stylesheet, save, refresh the page in the browser. Hmm, that div still doesn’t look right, let me try again, edit, save, refresh, ad nauseum. Now, thanks to the miracle of property inspectors and live style editors, we can fiddle with css directly in the browser, get real-time feedback, and save it down to our stylesheets only when we’re satisfied with the result.

So why wouldn’t you want to write all your code like this? Turns out you can write functions in the interactive shell as well:

>>> function addThese($a, $b) {
... $result = $a + $b;
... return $result;
... }
=> null
>>> addThese(5, 6);
=> 11

Forgot what arguments array_push() takes? No problem, just install the PHP manual and you can look it up right from the shell:

>>> doc array_push
function array_push(&$stack, $var, $... = unknown)

Push one or more elements onto the end of array

array_push treats array as a stack, and pushes the passed variables onto the end of array.
The length of array increases by the number of variables pushed. Has the same effect as:
]]> repeated for each var.

array $array The input array.
mixed $var The pushed value.

int Returns the new number of elements in the array.

OK, fine, how do I use it?

I’m glad you asked! PsySH is written in PHP and is available as a precompiled phar. If you just want to use it as a REPL, it’s as easy as:

chmod +x psysh

PsySH is still a young product (currently version 0.1.0) but already a useful tool. If it looks interesting, check it out on GitHub and consider contributing issues and code if you wind up finding it useful.