Why would I run everything locally ?

Over the last years, a lot of the development agencies in the PHP world, has found out the joys of having local, individual environments for all developers, and managing larger projects through version control like SVN, CVS or, my new favourite, Git. Most people don’t have the luxury of having their own dedicated testserver for development, but you really don’t need one either. If you just have a Mac with OS X, you’ll have everything you need.

The reasons for having a local environment are quite massive: You’re able to have a complete replica of a running website, you’ll be able to develop new features without risking the stability of your public site. You’ll have full control of every setting in Apache, MySQL and PHP, meaning you’ll have the opportunity of testing optimizations and database structures properly, without the risk of destroying everything in a production environment.

Prerequirements

To complete the setup of Apache & friends, you’ll need the assistance of Terminal. If you are not comfortable with Terminal, just feel free to copy’n'paste every command here. Of course, as time passes, and you’re using your new environment, you’ll probably notice the advantages of Terminal anyway.

Setting up Apache

As Apache 2 is bundled with Leopard, this is very easy. Apache is controlled by enabling Web sharing in System Preferences.

Setting up webroots

As you have full control of Apache’s setup, you could actually put your websites whereever you’d like. However, as you already have the Sites folder available in your home directory, I’ll just make use of that. This also ensures, that Time Machine for instance is able to create backups of your sites.

So go ahead and create a directory within Sites for your new site, and try to give it a memorable name (In this example I’ll use jesperrasmussen.com from now on) .

sudo mkdir -p ~/Sites/jesperrasmussen.com/htdocs

While you’re at it, add a general directory for Apache’s logs within Sites, to gather all sites logs within one place, making debugging and log-analyzing a bit easier.

sudo mkdir ~/Sites/logs

Now that that’s done, you should have a couple of nice directories for the virtualhost and its logfiles, so let’s move on.

Setting up a VirtualHost

In the default setting, Apache will see your Sites folder as one site, as it’s setup to allow one personal site per user. To make Apache recognize the new virtual hosts, you need to edit the file /private/etc/apache2/users/.conf in your favourite editor (I recommend emacs or nano for Terminal editing).

The file will look somewhat like this when you open it:

<Directory "/Users/jesper/Sites/">
 Options Indexes MultiViews
 AllowOverride None
 Order allow,deny
 Allow from all
</Directory>

Now, what we’ll do, is that we’ll add the lines for a new virtualhost in the configuration. Furthermore, in my example, there’s an added .dev alias to the domain, allowing me to access the local development version of the site by accessing jesperrasmussen.dev, and access the public version (On another server) by accessing jesperrasmussen.com. Anyway, add the following lines, replacing jesperrasmussen.com with whatever your virtual host is called, and save the file.

NameVirtualHost *:80
DocumentRoot /Users/jesper/Sites/jesperrasmussen.com/htdocs
ServerName jesperrasmussen.com
ServerAlias jesperrasmussen.dev
ErrorLog /Users/jesper/Sites/logs/jesperrasmussen.com-error_log
CustomLog /Users/jesper/Sites/logs/jesperrasmussen.com-access_log common

Restarting Apache

Inorder to test the new site, we need to reload Apache’s configuration files. This is done by testing the new config files first.

sudo apachectl -t

If this says “Syntax OK”, we should gracefully load the changes into Apache. *)

sudo apachectl graceful

Accessing your newly created site

Now, you may think you should be able to access your new site at the domain you’ve entered. But no, you still need one more thing, changing your hosts-file into handling your domain locally (Or at least, the development version). This is done by editing /etc/hosts (Again, using emacs or nano), like so:

sudo nano /etc/hosts

This should load your hosts-file **), which should look like this:

127.0.0.1 localhost
255.255.255.255 broadcasthost
::1 localhost
fe80::1%lo0 localhost

Now, in the bottom of the file, insert a couple of blank lines to seperate your changes from the default parts, and insert this line:

127.0.0.1       jesperrasmussen.dev www.jesperrasmussen.dev

This will force your machine into believing that your domain is located at localhost, thus making the request at your local Apache.

Now, everything should work, try putting a dummy index.html file in your new htdocs directory, and try loading the site in your browser. Next time I’ll have a look at enabling PHP and MySQL support on your standard machine.

Further reading

It’s come to my attention that Patrick Gibson has a fine shellscript for handling the VirtualHost part, making this a lot easier.
You might want to check that out

* Gracefully restarting Apache lets Apache apply the configuration more smoothly, by allowing it’s child processes to keep running with the old configuration, but loading the new configuration for all new processes. This is usually done in production environments, to avoid hard restarting servers, thereby avoiding possible downtime.

** The hosts-file is OS X’s way of overriding DNS locally. It allows you to force a domain to a specific IP-address rather than the one specified in the domains DNS. This is especially useful for testing a development or staging environment with the correct domainname.

Let’s start at the beginning: Getting Things Done is a way of improving productivity. It’s a way of organizing your life, it’s a way of optimizing your day-to-day life and it’s a way to combat stress. This might sound like just yet another scheme to steal money, but it’s not really. The only thing you have to invest in, is the book, and from there on, the implementation of GTD in you life depends on what you make of it.

GTD has had quite a lot of success during the last couple of years, and is in general very popular among especially developers, as it has a very structured approach to projectmanagement, and life in general.

The concepts of GTD

The primary concept of GTD, handles the way we perceive tasks. Usually, a lot of people have things written down on post-its, taking the tasks one by one in no particular order. Usually this means a lot of clutter, or “stuff” as it’s called in GTD.

GTD puts focus on a couple of things to remove stuff, both from our desks and our consciousness, by splitting every project into atomic “bits” representing every single, physical action required for the project to be completed.

The Inbox

The inbox is the source of organizing. Everything goes inhere, just like a mail inbox. The inbox is where you write everything down, ideas, notes, todos, projects etc. The inbox is sorted regularly, taking care of smaller tasks right away, while larger projects are split into single, physical actions described later in this post.

An important note about the inbox, is that a large part of GTD is having the discipline to clean this up, or review it. This is for a lot of people handled on a daily basis, and a more advanced weekly or monthly basis. This is also the largest weak spot of GTD, as it requires a steady discipline to maintain the order of organizing everything regularly, and avoid having a large inbox.

Actions

Actions are the atomic bits and pieces of GTD. Actions define every physical action you have to take to complete the project at hand. Actions make up projects, and inorder to finish a project, one must complete every action within. This could be “Call Jack Bauer about nuclear device”, “Gather information on Ruby development”, “E-mail John from IT about server specs, remember to CC Jack”.

Contexts

Contexts are defined by the surroundings you are currently in. This is a way of organizing actions that can only be fixed while being “at the computer”, “at the office”, “on the phone” or even “In Brazil”. Context are used to group all actions, based on location or the tools at hand, and provides you with a simple list of “Things you’re able to do right now”. This means a context might hold 10 actions for 4 different projects, meaning you’ll be able to focus on what’s actually achievable from your current location, with the current tools.

More reading

As this is a very brief introduction into the world of GTD, which will probably be expanded into more advanced articles later on, I would recommend reading more about GTD, and some general concepts of increasing productivity without adding stress. Here’s a few of my favourite books and sites about GTD.

David Allen - Getting Things Done
43 Folders
What is GTD ?

I usually spend 20-30% of my day in Terminal, doing administrative tasks, ssh’ing to the servers I use for development and for my work, watching logs, debugging etc. This might not be typical behaviour for an OS X user (Which is good, as I think Terminal should be an addition for those who wants the power of it, and not a necessity for “regular” users) , but I find working directly with Terminal to improve my workflow when it comes to the previously mentioned tasks.

As some Mac-users will know, OS X currently comes with bash as the standard shell. Even though bash is often perceived as one of the best shells available in the Unix-community, quite a lot of other shells exist, all with different features, and approaches to shell-work. A couple of years ago I decided to try out Z Shell, also known as zsh, and I’ve never regretted this.

Why run zsh ?

To begin with, it’s not even a big deal switching or trying zsh out. If you are currently using bash, you’ll feel right at home. Zsh uses a lot of the same shortcuts, has support for most of the features bash uses, and this means the only thing you’ll actually notice, is how the extra features just make things easier. Some of the key features for zsh are:

• Nice autocompletion for commands, aliases etc. Zsh allows you to tab through completions if there are multiple possibilities, showing possible completions in a nice grid, browsable even by arrow keys, to make it simple and fast to find exactly the completion you want.
• Autocompletion for remote files. If you are using scp to transfer a file to a remote server, zsh will figure out what you are doing, so if you try to autocomplete while typing the remote part, it will try to connect via ssh and actually perform autocompletion on the remote side.
• Functions in addition to aliases. It’s possible to create entire routines as zsh functions with arguments, allowing for complex functionality for running multiple commands in succession easily.
• Share history across sessions. When running multiple instances of zsh at the same time, the instances are able to share a common history, rather than being limited to only each its own. One of the most frustrating things to a bash user is typing in a long command, then searching for it again the next day via Ctrl+r, only to find it nowhere in the history.

Ok, so how do I change my shell to zsh ?

Enabling zsh in OS X Leopard is really easy. Previously, you had to install zsh from MacPorts, but in Leopard it’s part of the base install, and as such is easily accessed. try writing “zsh” in your bash, and bang! You’re running zsh! To set zsh as your default shell in OS X, and make it run every time you start Terminal, load up Terminal’s settings, and set your default theme to run the command “zsh” on startup.

To change it in older OS X versions, you should be able to use the chsh command. But there are other suggestions as well.

But, but, it’s not working like you promised ?

You’ll need a .zshrc file to take full advantage of zsh. The .zshrc is zsh’s configuration file, and will setup most of the features I’ve mentioned earlier. There’s a couple of ways of getting hold of a .zshrc. You could google for it, and you’ll find a bunch of examples. Another way is to take a look at my sample file . This is not an exact copy of my running .zshrc, but it has a bunch of the most common setups.

To make it work, you have to save the file as .zshrc in your home directory.

Be aware that zsh holds a bunch of more features than I’ve talked about here, and there’s much to explore. Feel free to use my sample file as a starting point, and do change it anyway you’d like. If you find any other useful features in zsh, please let me know, and I’ll make some notes about it here.

Further reading

If you want to know more about the glorious world of zsh, try checking out the official zsh website, containing documentation, the manual as well as some pointers to getting started with scripting in zsh.

Zsh homepage

My sample .zshrc

Zsh Wiki

Back in 1999, I purchased my very first domain. It was called highonpixels.dk , and acted as my personal playground at the time. During the first couple of years, I focused a lot on webdesign and usability, and the website was my first adventures into creating webpages. Alot has happened since then, I’ve matured, gotten a couple of different jobs, and over the years my website faded into the background.

I rarely had the time to update the site, my friends started poking me for more content and new layouts etc., but in the end I just didn’t have the drive for updating a website anymore. Working as a webdeveloper on a fulltime-basis for clients will do that to you, trust me ;)

So what changed ? Well, during the last year or so, I’ve regained a lot of the enthusiasm regarding the web, and the technologies surrounding it. Another thing that has happened, is that I just recently acquired this domain. For the last couple of years it’s been occupied by another danish guy with the same name, and I’ve tried to capture it a couple of times without success. However, in December 2008, magic happened. The domain was released, and I put a couple of hosting-companies on the case of capturing it for me, which happened around Christmas (yay, best christmaspresent for myself ever!).

One of the things I’ve had a lot of advantages from online, has been technical guides. Everything from setting up virtualhosts on a Mac, over learning BASH-scripting to hacking my Xbox to allow it to be a multimedia-player. All of these experiences has helped me a lot, but sometimes I see myself googling for the same themes over and over again. And everytime I need a guide I have to find it again, and hope the site I’m looking for is still available. Initially I thought about running my own Wiki for the guides that I need, but I figure someone else could probably benefit from my mistakes and experiences.

So I’ve decided to launch a blog-like site with those exact subjects. The site will contain guides for most of everything I come into contact with. Expect guides involving Linux/Unix/Mac maintenance, Javascript, MySQL, PHP architecture and development patterns, as well as my personal thoughts, ideas and tips.

Anyway, welcome once more, I will try to make your stay as pleasant as possible.