Category Archives: Development

PREFACE

These are my personal notes that I use every time I reformat or get a new computer. I’ve curated these instructions over the course of 4 years, so they are littered with links to relevant source material and have been stripped down to the exact actionable steps I need to take to get up and running. As such, this post is mostly for my own benefit, and I will regularly update it as my process changes (usually with each new OS X release).

These instructions have been updated to specifically support OS X Mountain Lion (10.8), but should also work with Lion (10.7), Snow Leopard (10.6), and Leopard (10.5).

I might write some follow-up posts about using this setup to create a killer local WordPress Multisite installation, and also porting your dev environment contents to live in DropBox. If so, I’ll link them up here.

Why not just use MAMP?

If you’re wondering, I like to set up my local environment, instead of using MAMP, because I prefer to have it always available. I never liked having a separate application running just so I could access my local dev setup. Also, it has always bothered me that MAMP bundled its own copies of PHP, Apache and MySQL when the only missing component that doesn’t come pre-loaded with OS X is MySQL.

Help, I’m stuck!

It’s worth mentioning here that I’m not a very smart guy, which is why I’ve kept these detailed notes for the last 4 years. These instructions work for me, but they might not work for you. If you get stuck with an issue, I suggest googling around and sharing what you discover here in the comments. It will likely be much faster than asking me for help, and will benefit everyone who reads this (me included)!

A Quick Word about my Terminal Commands

In many of the terminal instructions I use my custom bash shortcut “sub” to open a given file in Sublime Text 2 via command line. You can substitute “sub” for your text editor of choice (e.g. “vi” for Vim, or “mate” for TextMate, or “subl” for the standard Sublime shortcut).

---

Install MySQL

Follow these steps, in order:

1. Download DMG installer from http://www.mysql.com/downloads/mysql/
2. Install MySQL
3. Install MySQL auto-start
4. Install MySQL pref pane
5. Then, configure MySQL:
6. In Terminal: sub ~/.profile
   1. Add this line to the file: export PATH="/usr/local/bin:/usr/local/sbin:/usr/local/mysql/bin:$PATH"
   2. Save and close the file.
7. In Terminal: source ~/.profile
8. Finally, configure MySQL socket (because OS X is looking in the wrong directory): http://www.davewidmer.net/blog/2009/03/upgrading-to-leopard-broke-my-local-development/

---

Configure PHP

These steps are really only to keep you sane while testing uploads and such in your projects:

1. In Terminal: sudo cp /etc/php.ini.default /etc/php.ini
2. In Terminal: sub /etc/php.ini
3. Update upload_max_filesize to something like 64MB (L891 in OS 10.8)
4. Update post_max_size to something like 64MB (L740 in OS 10.8)
5. Save and close

---

Configure Apache

Update httpd.conf:

1. In Terminal: sub /etc/apache2/httpd.conf
2. Uncomment the include for PHP5 (L117 in OS 10.8, L111 in older releases)
3. Uncomment the include Virtual Hosts (L477 in OS 10.8, L623 in older releases)
4. Save and close the file.
5. If you’re running OS X 10.7 or earlier, you’ll also need to enable “Web Sharing” in System Preferences > Sharing.

Setup Virtual Hosts (http://foundationphp.com/tutorials/vhosts_leopard.php):
Note, you’ll want to replace “rzen.dev” with your own custom URL, and “username” with your own OS X username.

1. In Terminal: sub /private/etc/hosts
2. Add the following line to the file:
   1. 127.0.0.1 rzen.dev
3. Save and close the file.
4. In Terminal: sub /private/etc/apache2/users/username.conf
5. Add the following lines to the file:

   1. <Directory "/Users/username/Sites/">
          Options FollowSymLinks Indexes MultiViews
          AllowOverride All
          Order allow,deny
          Allow from all
      </Directory>
      
      <VirtualHost *:80>
         ServerName rzen.dev
         DocumentRoot "/Users/username/Sites/"
      </VirtualHost>

6. Save and close the file.
7. Finally, flush the DNS cache & Restart Apache (you’ll want to do this any time you edit your hosts file and virtual hosts setup):
   1. In Terminal: dscacheutil -flushcache
   2. In Terminal: sudo apachectl restart

In my setup I’ve registered rzen.dev to point to my ~/Sites/ folder, rzen.wp to point to ~/Sites/wordpress/, and rzen.php to point to ~/Sites/phpMyAdmin. This means I’ve created a separate pointer for each domain in my hosts file, and a separate <VirtualHost> container for each in my apache .conf file.

Apache Error Notes

Later, if apache ever goes south and starts spitting 403 Forbidden, or some other error, check the error log. You can open it from inside Terminal: sub /var/log/apache2/error_log

If the problem is “Symbolic link not allowed or link target not accessible”, confirm that your symlinked folder, it’s parent directory, et al, have sufficient permissions for owner and group (http://forums.dropbox.com/topic.php?id=40992#post-337655).

---

The Optional (but recommended) Bits

Install phpMyAdmin

1. Download latest version of phpMyAdmin from http://www.phpmyadmin.net/home_page/index.php
2. Unzip to ~/Sites/phpMyAdmin/
3. Rename config.sample.inc.php to config.ing.php
4. On L36 change $cfg['Servers'][$i]['AllowNoPassword'] to true
5. By default, your login will be root with no password

Install WordPress

1. Download the latest version of WordPress from http://wordpress.org/download/
2. Unzip to ~/Sites/wordpress/
3. Create a new database for your install via phpMyAdmin to use during installation
   • Database server will be localhost
   • Username will be root
   • Password will be blank
4. Pro-Tip: Once installed, edit wp-config.php add define('FS_METHOD','direct'); somewhere before the “That’s All, stop editing here” comment. This will enable direct access to the file system when running automatic updates and make your local dev experience mui guapo.

Install Git

Visit http://git-scm.com/ and download + install the latest version. Done.

Install SVN

For some reason, beginning in Mountain Lion (OS X 10.8), Apple stopped packaging SVN with Mac OS. So, you’ll need to download “XCode Command Line Tools” separately by signing in as a Developer (after registering for a free account using your Apple ID) here: https://developer.apple.com/downloads/index.action.

Alternatively, you can download SVN directly from WanDisco: http://www.wandisco.com/subversion/download#osx. I recommend using 1.7+.

Enable SSL

If you ever have need to test a site or service locally using https://, my co-worker @jtsternberg has written up a wonderfully detailed step-by-step of his experience doing just that. You can read it here: How to set up SSL with OSX Mountain Lion’s built-in Apache

 
For the developers in the audience, I want to take a moment to offer some general advice and good practices as I round out this series about my tenure as a leader and my ongoing role as a developer. Below you’ll find four simple tips, plus a practical reminder. I’ll have more to share in the many months to come, but these are enough to get things started. Without any further ado…

1. Program like a lazy person

Build solutions only when you cannot outsource them and build in the simplest iterations possible.

I’ve personally found that much more can be accomplished when you rely heavily on the work of others. Now, I’m not suggesting you pawn all your tasks off on someone else (that’s the job of a good leader). Nor am I suggesting that you lazily take credit for the work of others (that’s called “being a jerk”). What I am saying is that any solutions you may need probably already exist elsewhere else already, and you should borrow much code from them (if not use them in their entirety).

Building things in their simplest form leaves room for fewer errors and makes for expedited builds (rapid prototyping, multiple iterations, whatever you want to call it), always allowing you to gain features only when they’re actually needed.

Equally important is documenting things as you go (referring to the URLs where you found various components) — future you is never as clever as present-day you, he definitely won’t understand or remember why you built something a specific way.

2. Always pull a fresh copy of any file

Hopefully your team is using a managed codebase with tools like SVN or GIT. If so, you already know the importance of updating your local repository before pushing any changes (and you can skip this section). If that’s not the case, and you’re working with a team of people who are updating a project via FTP, GET HELP NOW! I’m kidding, but I’m also serious… version-controlled code is a godsend, whether you work alone or on a team.

Anyway, if you’re still reading this and you aren’t on a managed codebase, here’s what you need to know: if you’ve had your local copy for more than an hour, assume that it is already out of date and you need to pull a fresh copy from the server. My previous team was unfortunately relegated to traditional FTP at the expense of overwriting each other’s work time and again. That’s the cost of not working with proper version control. Hopefully new dev practices will help you avoid this in the future, but until anything is in place it’s always safest to check with someone before you push any changes.

3. Always Be Testing (ABT)

This is the most cost-effective part of your job, and its the most budget-justifying proof that you’re worth every penny someone pays you. Every time you push a new file to the server you should run it through the testing system to make sure things are okay. If the user cannot checkout, or cannot subscribe, or do whatever it is they are supposed to do that generates revenue for your company, you are bleeding money.

You should also know that you have the authority to challenge everyone else who isn’t testing the pages you build. This includes the project requestor. But, if you are not personally testing everything you also forgo this (important) right to challenge others.

4.Don’t worry about looking incompetent

It’s only when you draw attention to how incompetent you feel that people notice and wonder. I’ve almost never thought, “man, this guy is moving slow” or “man, i don’t think he knows what he’s doing” without a coworker or contractor bringing up their own insecurities first. Trust that we trust you and that we also know things are complicated and take time — You’re good at what you do, and that’s why you were hired. Just keep swimming!

Bonus Tip: Why “5 Minutes” doesn’t always mean five minutes

I covered this important realization on bug-fixing in an earlier post, but I felt it prudent to include again here. Be careful as you offer time estimates, and do your best to help others understand when you’re incorrect.

So, there you have it.

Some of the most practical advice I can give you from several months of being a leader and many years of being a developer. Let me know what you think and keep up the awesome!

I’ll try to keep this brief, as I’m sure you all probably realized this already. Even so, it’s always a good reminder and will help keep developers and non-developers on speaking terms.

I’ve got a simple analogy for you as to why some (many) things take longer to develop than developers initially estimate and, more importantly, why we perpetually believe it will only be “just 5 more minutes” as we continue to debug.

The leaky sink.

Now, a leaky faucet is presumably simple fix. You will usually have a good idea where the problem is coming from because you can clearly see where the water is leaking, but not always. Most leaks can be fixed with what you already have around the house, but sometimes you have to go out an get new parts. Many times you’ll already know how to fix it, but now and again you’ll need to do a bit of research. Lastly, once in a great while you’ll need to call in an expert, because the problem either wasn’t what you expected OR it becomes too big for you to quickly do by yourself.

Sometimes it’s a simple problem… (5min or less)

The best scenario. This is when you didn’t close the tap all the way, or something has come just a little loose. In programming, this would be a typo or a simple logic error. No big deal, it’s already fixed.

Sometimes it’s a different problem… (5min, x2)

This one is annoying. You thought it was a problem with the faucet, but later found out it was a problem with the tap. You’ve already spent 5min working on the faucet, and now realize you need to spend another 5min on the tap. This happens a LOT in programming.

Sometimes it’s multiple problems… (5min, x2, x2, x2)

Now you’re really frustrated. You looked at the faucet and saw it wasn’t there, then you spent 5min on the tap and the leak still exists. Now as you look more closely you see there’s actually another (two, three, four) problems happening underneath the sink. Or, worse, because you fixed one problem you’ve actually created a problem elsewhere (without the steady leak, now a pressure buildup has busted a pipe. $#!&).

Sometimes there’s a false positive… (5min, x2 …. wait 30min, try again)

The leak has stopped! …temporarily, until you or someone else tries to use the faucet again. You’ve spent your 5 (10, 15) minutes fixing what you thought was the problem, and now the problem is back again. In programming, this is especially troubling because now you’re not sure if it’s just a caching issue or something else entirely.

Sometimes there is no problem… (30min for nothing, FML)

There wasn’t a leak, you (or someone else) just splashed some water up behind the sink. In programming, you’ve spent the last 30 minutes chasing a bug that doesn’t exist. Do not pass go, do not collect $200.

Hang on, just 5 more minutes…

Next time a developer tells you “Just 5 more minutes” and they’re wrong, remind yourself that they’re not lying and they’re not bad at estimating (and no, they don’t hate you), they’ve just encountered a new or different (or additional) problem than they set out to fix 5 minutes ago.