I use Vagrant boxes for almost all of my development work. I recently came across this simple yet incredibly time-saving Vagrant tip. I use NFS to share files between my host computer and Vagrant box. While Vagrant makes this quite trivial to do Vagrant does require elevated permissions to mount the NFS share which means I need to enter my password everytime a Vagrant box starts up. This isn’t a huge deal as I only restart my Vagrant boxes a few times a week but I frequently will start up a box then go do something else while it boots and when I return later I see my box sitting at the password prompt. By adding a few lines to my /etc/sudoers file I just type vagrant up and I’m done.

1. Open up terminal. (CMD+SPACE, type in terminal)

2. Type in:
sudo visudo

3. Enter your password.

4. Add these lines to the bottom of the file.
Cmnd_Alias VAGRANT_EXPORTS_ADD = /usr/bin/tee -a /etc/exports
Cmnd_Alias VAGRANT_NFSD = /sbin/nfsd restart
Cmnd_Alias VAGRANT_EXPORTS_REMOVE = /usr/bin/sed -E -e /*/ d -ibak /etc/exports
%admin ALL=(root) NOPASSWD: VAGRANT_EXPORTS_ADD, VAGRANT_NFSD, VAGRANT_EXPORTS_REMOVE

In case you aren’t familiar with vim, press i to insert text, when done, press ESC, then : followed by wq then press enter.

Your done! Wait 5 minutes (because you just typed in your password like 30 seconds ago). Then type vagrant up from your project root and don’t enter your password.

Share

I have installed the PHP extension Xdebug on multiple platforms and for some reason I keep forgetting how I manage to do it every time.

Below are the steps I followed to get Xdebug working with Zend Server CE 5.04 with PHP 5.3 on Windows 7 Ultimate 64-bit.

[ad name=”Google Adsense-1-box”]

  1. Download the correct Xdebug extension from here.
    Note: Although I am running a 64-bit OS, Zend Server CE 5.04 is 32-bit and requires 32-bit extensions so I downloaded the 32-bit version of Xdebug php_xdebug-2.1.0-5.3-vc9-nts.dll
  2. Copy the DLL to C:\Program Files (x86)\Zend\ZendServer\lib\phpext\
  3. Add the following lines ABOVE [Zend] in your php.ini file which is located at C:\Program Files (x86)\Zend\ZendServer\etc\php.ini
    [xdebug]
    zend_extension="C:\Program Files (x86)\Zend\ZendServer\lib\phpext\php_xdebug-2.1.0-5.3-vc9-nts.dll"
    
  4. Restart Apache
  5. Log in to the Zend Server GUI at http://localhost:10081/ZendServer and check the PHP Info page for Xdebug
  6. If you have an Xdebug section then it works. Now you’ll want to probably add some more configuration to the [xdebug] section of the php.ini file. See xdebug.org for more info.
Share

Version Control Can Be Dangerous

Version control for a website sounds like a great idea. Everyone wants to be able to make risk-free changes to their website. It’s a great feeling to know that at any given time you can revert to previous versions of files. With a VCS (Version Control System) like Subversion, you get a nice central location for all your code, a web interface to browse your files and, well, it’s a great thing to brag about to all your techie friends. The only problem is that it can seriously screw up your web development workflow if the implementation of such a system is not thought out carefully.

One Dilly of a Pickle

The biggest potential hurdle in setting up a VCS for web development is the web server. Unless you’re an HTML-only web developer (hopefully they don’t even exist anymore), then you either have a special development web server set up or you use your live web server to test out your scripts. Once you’ve figured out how to check your files in and out via your VCS, you’ll realize that you need to get these files to your web server. If you don’t have root access to your server, you might be in trouble. At this point you’ll want to stop everything and re-evaluate implementing VCS into your web development workflow. I’ve had to re-evaluate my processes a few times and the following describes what I’ve learned about various web workflow methods I have experimented with, as well as a detailed description of my current web development workflow.

 

[ad name=”Google Adsense 468×60″]

Remote Web and Subversion Server Accessed by Samba Share…

…a theoretically simple setup, but practically, it turned about to be a nightmare. I set up a basic LAMP box and also installed Subversion on it. I also set up a Samba share and created Apache virtual hosts to map to those shares. The theory was that I would check out files from the Subversion server to my local machine to a network drive mapped to the Samba share. So when working on files I could just CTRL+S and see my changes immediately on the remote server. When I was happy with the changes I would commit them. This setup almost worked, except for the checking in part. I kept getting file permission errors whenever I tried commit due to the Windows Subversion client not having permissions to write to the Samba share. I spent quite awhile trying to figure out what was going on, but I knew that if it takes this much effort to get it working, then no thanks. I don’t like my development to be put on hold because I can’t save my work properly.

There was one additional disadvantage of this method. By using Samba shares, I was limited to only local development unless I wanted to use VPN or SSH tunnels. It was time to move on.

Remote Web and Subversion Server with Files Checked in to Test

This method involves having Subversion installed to your web server and having it automatically export your project on commit to your web directory. This works pretty well. Your code is safe, as it’s checked in to your server constantly. The only problem is that checking in a file every time you make a change gets very annoying very quickly. There’s also the post-commit script that has to be configured properly, and if you have multiple projects you’ll have to account for that in your post-commit script. In my opinion, it’s not worth the trouble.

 

[ad name=”Google Adsense 468×60″]

How I Do It

I use three machines for development: an iMac running OS X 10.6 and a ThinkPad running Windows 7 at home, and a PC running Vista at work.

On each of these machines, I use Zend Studio 7.1 as my IDE and Zend Server CE 5.0 as my local web server.

Each one of my projects gets its own repository on my Subversion service hosted by Springloops. In most cases, for each project I have two deployment servers set up: one for production and one for staging.

Zend Studio handles all my Subversion tasks, although I sometimes use Tortoise SVN (Windows) or a terminal (Mac or Linux) for other non-code-related files.

I set up virtual hosts to point to each one of my projects’ working copy located in my Zend Studio workspaces folder.

My Typical Coding Session

My typical coding session would go like this:

Update local working copy of my project in Zend Studio.

Write some code and test on local development web server (Zend Server CE).

When I’m happy with those changes, I will commit them in Zend Studio, and then Springloops will automatically deploy the code to my staging server.

Once the site has been fully tested, I log in to my Springloops account and manually deploy my site to my production server.

But What About Databases?

You may have noticed I haven’t mentioned databases. Due to the potentially catastrophic issues that could occur from mixing staging and production databases, I keep them separate. I use both local and remote MySQL servers, depending on the type of project. I manually syncronize them when necessary by using phpMyAdmin.

Share

Springloops might seem like just another hosted Subversion service, but it has one amazing feature that sets it apart from all the other hosted Subversion services I have researched.
That feature is Deployment. Springloops provides the ability to deploy your code to multiple servers either by their web interface or automatically by just committing a file to your repository.

For example:
Let’s say you have 2 servers: a development server and a production server.
In Springloops’ web interface, you might configure your development server to deploy automatically on commit and set your production server to be manually deployed to. With a setup like this, developers can always have access to the latest version on the development server, and once development is finished, the code can be deployed to the production server. Any organization can easily fit Springloops in with their current development workflow.

Springloops pricing is pretty good. Plans range in price from free to $96 per month. The free plan only provides 100MB of space, 3 projects and 3 deployments per day. The seconds plan costs only $9 and allows 10 projects, 2GB of space and unlimited projects.

Don’t take my word for it, sign up for a free Springloops account and try it for yourself.

[ad name=”Google Adsense 468×60″]

Share