I’ve been reading up on PHP development frameworks, and Symfony has been bounced around among my co-workers as a very, very good one. Based on my own research, I’m inclined to agree; it’s scalable, easy to install, highly configurable, and uses all the development best practices that we learn about in school and rarely get a chance to use in real life. Best of all, it comes bundled with an object-relational mapper (ORM) called Doctrine; this lets me define my databases using an object-based approach, and focus on proper object-oriented design while letting the ORM figure out how to store those objects in a relational format.

Because there’s a new version of Symfony scheduled for release in November, and nothing I want to use it for will be ready before then, I decided to set up a development environment on my MacBook that I could play around with. I started looking for guides on good ways to set that up, and discovered something interesting. Most of the guides on the internet for installing Symfony under MAMP followed the same basic steps:

1. Install MAMP.
2. Install PEAR (a PHP package manager).
3. Use PEAR to install Symfony.

But on the official Symfony installation guide, it specifically says not to install it using PEAR. And none of those guides account for getting the still-in-development 1.3 framework. Clearly, there was a failure to communicate somewhere along the line, and I was going to have to figure out my own way to get my dev environment set up just the way I like it. And you all get to benefit from it!

Note: This guide should NOT be used in setting up production environments! MAMP is not meant for proper web hosting, and you should never use a non-stable release of anything in a critical system.

The Boring But Important Part: Installing and Configuring MAMP and PEAR

First, go install MAMP, an all-in-one Apache/MySQL/PHP stack that’s great for development and testing. Just follow their drag-and-drop instructions and you should be good to go.

A few maintenance issues first. Symfony is pretty memory intensive, so we might as well account for that now. Open up /Applications/MAMP/conf/php5/php.ini and edit the line:

memory_limit = 8M

to:

memory_limit = 32M

I also strongly recommend you find and set the following properties to Off, for security/compatibility reasons:

short_open_tag = Off
magic_quotes_gpc = Off

As well, open up a Terminal window and run the following two commands:

sudo mv /usr/bin/php /usr/bin/php-old
sudo ln -s /Applications/MAMP/bin/php5/bin/php /usr/bin/php

This will ensure that running PHP from the command line will use the PHP installed with MAMP, instead of the system default. If you access phpinfo() through a web browser, and run php -v from a Terminal, both should list the same version number.

Right, that’s MAMP; now we need to configure PEAR, a PHP extension repository. We won’t use it to install Symfony, but we still need it because Symfony uses it to grab a few of its own dependencies. Thankfully, MAMP comes with it, so we just need to enter:

sudo ln -s /Applications/MAMP/bin/php5/bin/pear /usr/bin/pear

to make sure calling it from the command line works. If you want to, you can run:

pear upgrade-all

to bring PEAR up-to-date with the latest version. Stop and re-start your servers in MAMP, and you’re done!

The Fun Part: Installing Symfony

I’m going to be borrowing steps extensively from the Practical Symfony book, and once we get to a certain point you’ll be able to follow their steps to finish off your environment. First we have to decide where we’re going to base our application; I put all of my projects under a Programming sub-folder in my Documents folder.

mkdir -p ~/Documents/Programming/MyProject
cd ~/Documents/Programming/MyProject

Note: If you want to use SVN for source control on this project, head to the section after this one right now. If you just want to develop on your own, keep reading.

Now we need to get the latest version of Symfony. But instead of using PEAR or downloading a stable package, we’re going to get the latest code straight from their SVN repository, because that’s how I roll:

mkdir -p lib/vendor
cd lib/vendor
svn co http://svn.symfony-project.com/branches/1.3 symfony

After a whole lot of loading, you’ll have the latest version of Symfony ready to go. Run the following from the Terminal:

cp lib/vendor/symfony/data/bin/check_configuration.php /Applications/MAMP/htdocs/check_configuration.php

And try visiting http://localhost:8888/check_configuration.php. You’ll get a quick summary of all the requirements that you need to meet to properly run Symfony, and whether you meet them or not. If it says you don’t have a PHP accelerator installed, open up your MAMP preferences and turn on XCache.

If everything’s worked so far, head on over to Practical Symfony Day 1 and start following their instructions from “Project Setup” onwards. That will take you through the rest of the process in creating your first Symfony application. It’s literally nothing than a couple of command-line instructions and a bit of Apache configuration. I bet you’re thinking “Hey, that was pretty easy!”

Well, when have we ever been satisfied with easy?

The Crazy Part: Putting the Whole Thing in SVN

This solution works well enough for people who want to work by themselves on one computer. But what if you develop on multiple machines? Or you need multiple people to work on your application? Or you want to develop along two different paths without either one affecting the other? That’s where source control comes in; I can just use SVN to get the latest version of my project anywhere, just like I used it to get the latest version of Symfony. Hey, since they’re both in SVN, wouldn’t it be nice if I could get the latest version of both my project and Symfony at the same time?

Oh yes.

Let’s assume we have a directory ~/Documents/Programming/MyProject (which we created above) and an SVN project already set up (at http://svn.mywebsite.com/MyProject, for example). We start by creating a few useful directories:

cd ~/Documents/Programming/MyProject
mkdir branches
mkdir tags
mkdir trunk

If you want to know why you’re creating those directories, read the official SVN documentation. Otherwise, we’ll import those into our repository:

svn import . http://svn.mywebsite.com/MyProject -m "Initial import"

then delete our original directory and get an actual working copy:

cd ..
rm -rf MyProject/
svn co http://svn.mywebsite.com/MyProject/trunk MyProject
cd MyProject

Now that we have an empty project that’s SVN-ready, we can do the same thing we did to get the latest version of Symfony… almost.

mkdir -p lib/vendor
svn add lib
svn commit -m "Added vendor directory"

Here’s the key; instead of getting Symfony directly, we’re going to tell our SVN repository to link to their SVN repository as an external source:

svn propedit svn:externals lib/vendor

This will bring up your command-line editor of choice (mine is vi). Add the following line:

symfony http://svn.symfony-project.com/branches/1.3

Save and quit the editor, then run:

svn update

to get the latest version of Symfony from SVN, just by updating your own project! Perfect! Follow the rest of the steps outlined in the Practical Symfony documentation to generate the rest of the framework, then just run:

rm -rf cache/*
rm -rf log/*
svn propedit svn:ignore cache
svn propedit svn:ignore log
svn add *
svn commit

This will add all of the files you’ve generated to SVN, except for the cache and log directories, which you probably don’t need to track. And there you have it! A fully packaged Symfony application that you can access using SVN, and that automatically pulls the necessary files from Symfony’s repository. The best part of this set up is that you can have all of your different environments (development, staging, production) as checkouts of the same repository with the least possible amount of customization. The only thing it doesn’t handle is configuring Apache, but that’s a lot more likely to need configuration on a per-machine basis anyways.

mamp, osx, symfony

Welcome! Come in, I love having visitors. Hungry? Need anything to drink? Pardon the mess, I just moved in myself and I’ve been too busy to properly unpack and set up. Give it a few weeks, and you’ll think I’ve been here forever.

My old site was created to let my family and friends keep track of where I was in the world without my having to e-mail people directly. Since I’m not traveling as much as I used to, my writing is simultaneously going in three different directions:

• Research: My time with the EASy group was an utterly fascinating experience, and I’d like to think it has helped me determine the kind of work I want to do in the future. But whenever I try to describe what I studied, I am immediately asked about whether the robots I build will ever take over the world (they won’t). The first dozen or so times were cute, but now I feel like I’m just not explaining it well enough. So this site will become a dumping ground for any fascinating links and research I come across that help show what exactly I do, as well as demonstrations of a few papers I’m going to try and replicate.
• Development: I noticed while job-hunting recently that, for a web developer, I don’t actually have a lot of work that I can show off online. Many of the projects I’ve worked on are down for renovation or otherwise unavailable. And frankly, even if I did have access to the actual code I wrote, I wouldn’t feel comfortable making it open to anyone other than the company that paid me to write it. So this site will also be a place to highlight the tips and tricks I’ve picked up in my years of web development and programming, and all code will be made available for other developers to ridicule see.
• Life: I’ve been told that I’m not a typical computer nerd, and in my eyes that’s a very very good thing. I cook, I play capoeira, I’m socially and environmentally conscious, I love cinema, I bike, and I have strong opinions on topics I know nothing about, although I suppose everyone does. The last thing this site will do is let me get all the random thoughts in my head out into the open, where I hope the Internet will pick them apart like vultures so that I can rebuild them better and stronger, just like Steve Austin in that show I haven’t seen.

So why not just do that on the old site, you ask? Because I have a serious issue with “stuff” in my life. Whether it’s physical possessions, receipts, ongoing projects, daily reminders, or whatever, stuff tends to pile up faster than I have the ability to deal with it. I’ve been gradually developing the two skills I need in order to prevent this from happening; the ability to deal with stuff faster, and the ability to avoid new stuff, or at least to decide where it goes before it turns into the generic “what do I do with this” kind of stuff. While everyone has a different approach to this, one of my favourite techniques is rebooting. Instead of trying to fix a big pile of stuff, simply make a new empty pile, make brutal and harsh decisions about really needs to go from the old pile to the new, and trash the rest. Chances are, if you’ve had something sitting in that old pile waiting for your attention for a month, you’ll never get around to it anyways. And once you have a nice clean space to work in, you suddenly find yourself motivated to keep it that way.

Hence, the new site. Instead of re-designing and re-editing my old website, I’m starting from scratch and bringing in the posts from other locations that I want to be here. That includes both my old Japan travel journals and the stuff I’ve posted on Facebook lately. Wordpress was good enough to bring in all my old posts, complete with the original posting dates. Unfortunately, it wasn’t good enough to bring over all of the embedded images in those posts, nor fix the links to sites that have broken since the time of writing. I’ll be touching up all of the old posts and bringing them into the new Web 2.0 format soon, so if you want to read them in the meantime, now you know why they look so screwed up.

That explains the new design, or lack of. But why did I get a new domain name when I already had a perfectly good one? Frankly, because I didn’t think it was a good one. When I was posting about living in Japan, I wanted a domain that reflected that, so a play on my name using the Japanese alphabet actually made sense. Now that I’m writing about whatever happens to be in my head when I put finger to keyboard, I wanted something a bit more general and personal. Not gonna lie, I spent a lot of time trying to think of a catchy new name; I was even reading blog marketing tips, for some reason. But nothing seemed to stick, and in retrospect, of course it didn’t, because I’m not trying to market my site and become a (barf) professional blogger. And I was resistant to using my own name for a while, mostly because of my slight paranoia regarding the potential for things I say online coming back to me in real life.

As you can see from the URL bar, I got over it. I figure that, even if I never mention my name in my writings, I’d inadvertently give up enough details for a motivated individual to put the pieces together anyways. I’ve Googled my own name (you know you’ve done it too) and there’s nothing out there that I feel the need to hide; it’s mostly just public profiles and technical posts related to my previous jobs and research. Hell, most of the hits are for a misspelling of a Latvian hockey player. It’s easy to remember for anyone who already knows me, and because my name isn’t exactly common, it hadn’t been taken yet. And once this site is properly up and running, the only thing all my writings will have in common is the fact that I wrote them. So davezoltok.com it is.

Now, sorry to kick you out the door, but I have to get this place cleaned up, and it’s likely to look worse before it gets better. Stop by anytime, coffee’s always on.

No tags