I still need to explore much more in Python and Django, but it looks promising. When I’m finished with this framework, I guess I’ll advocate it just as much as some fellow colleagues to be used as a base CMS for a multitude of clients.

I’ll just focus on the commands (as written paragraphs won’t be of much use) and give additional information / advise where necessary. A ‘\’ or backslash on a command line instruction means that for readability I put a single command on multiple rows. So when you’re working in Terminal.app, you should type everything on a single line.

Final note: some settings / paths might be different on your system – so reason and attention might be necessary (and some shell experience comes in handy too!)

Install Apache

Get a fresh copy of the latest stable production version of the Apache web server. (I’m using version 2.2.14)

$ cd ~/Downloads
$ tar -xzf httpd-2.2.14.tar.gz
$ cd httpd-2.2.14
$ CFLAGS=”-arch x86_64″
$ ./configure –prefix=/usr/local/apache2 –enable-mods-shared=all -with-ssl=/usr -with-mpm-prefork \
-disable-unique-id -enable-ssl -enable-dav -enable-cache -enable-proxy -enable-logio \
-enable-deflate -with-included-apr -enable-cgi -enable-cgid -enable-suexec
$ make
$ sudo make install

The installation of Apache is now completed. You should definitely read up on the documentation of Apache so you can configure it so it suits your needs. The configuration file is located at /usr/local/apache2/conf/httpd.conf (if you use a different ‘–prefix’, your config file is available at PREFIX/conf/httpd.conf).

$ sudo apachectl start

If you didn’t see any errors in Terminal, Apache is now started and running. You can verify this by running the following command:

$ ps -ax | grep httpd

You can also verify your installation by opening a browser window and browsing to “http://localhost/” – if you see a “It works!” page, that’s Apache in full effect!

Install MySQL

Because we like free software (free in free source and cheap) I opted for MySQL community server as database server. Installing MySQL is the same as installing any other application on a Mac. Download and mount the DMG image and double click .pkg file and follow the instructions.

By default MySQL installs itself at /usr/local/mysql-5.1.43-osx10.6-x86_64 (I’m using version 5.1.43) but creates a symbolic link at /usr/local/mysql. By default, the MySQL socket file will be created at /tmp/mysql.sock if you ever need to configure third party tools that require the socket location. It’s also good practice if you’ll only need local access to MySQL, you create a my.cnf configuration and activate “skip-networking” (by uncommenting the line). Doing so, MySQL won’t be listening at the default network port 3306.

Sample configuration files to start from are located under /usr/local/mysql/support-files/ (by default, you should copy any of the available my-*.cnf files to /etc/my.cnf to activate it).

Install PHP

In order to install PHP, depending on the options / features you like, it’s possible you have to install additional packages first. FreeType, iconv, libjpeg, mcrypt, libpng, … this list can be *virtually* unlimited. Installation of these additional packages is beyond the scope of this document. Basically it comes down to downloading the archive, run ./configure, make and make install.

If you’ve downloaded and installed all required packages / libraries for your setup, it’s time to download a fresh copy of PHP.

$ cd ~/Downloads
$ tar -xzf php-5.3.2.tar.gz
$ cd php-5.3.2
$ ./configure –prefix=/usr/local/php –mandir=/usr/share/man –infodir=/usr/share/info \
–sysconfdir=/etc –with-config-file-path=/etc –with-zlib –with-zlib-dir=/usr \
–with-openssl –enable-exif –enable-ftp –enable-mbstring –enable-mbregex –enable-sockets \
–with-mysql=/usr/local/mysql –with-pdo-mysql=/usr/local/mysql \
–with-mysqli=/usr/local/mysql/bin/mysql_config \
–with-apxs2=/usr/local/apache2/bin/apxs \
–with-mcrypt –with-gd –with-jpeg-dir=/usr/local/lib –with-png-dir=/usr/X11R6 \
–with-freetype-dir=/usr/X11R6 –with-xpm-dir=/usr/X11R6 –with-xsl=/usr/lib –with-iconv-dir=/usr/local/bin
$ make
$ make test
$ make install

Again, the paths and options are specific for my desired setup of PHP. If you’re interested in the available options, run ./configure –help and you’ll see a list of all parameters. Also running ‘make test’ is important because it can inform you about possible errors before installing PHP. Don’t ignore these otherwise you might have an unstable or not properly functioning PHP installation.

Normally, PHP adds the correct configuration settings to your Apache configuration file so PHP is automatically loaded when your webserver starts. If you were already running Apache (as we tested it after installation) there’s actually no need to stop / start the webserver but you can reload its configuration.

$ sudo apachectl graceful

Next we’ll create a test file so we can see if PHP is actually working and running under Apache.

$ echo ‘<?php phpinfo(); ?>’ > /usr/local/apache2/htdocs/phpinfo.php

Open a browser window and go to http://localhost/phpinfo.php. If everything is in working order you should see a detailed information page autogenerated by PHP. It should look like the screenshot below.

Install xdebug

Xdebug will make your code debugging a more pleasant experience, so I suggest you install this package immediately. Download the latest stable release http://xdebug.org/download.php. (I’m using a beta release here)

$ cd ~/Downloads
$ tar -xzf xdebug-2.1.0beta3.tgz
$ cd xdebug-2.1.0beta3
$ phpize
$ ./configure –enable-xdebug –with-php-config=/usr/local/php/bin/php-config
$ make
$ sudo cp modules/xdebug.so /usr/local/apache2/modules/xdebug.so

Next step is to make your PHP installation aware of xdebug, so:

$ vim /etc/php.ini

Add the following line (I suggest to bundle any additional zend extensions together): zend_extension=”/usr/local/apache2/modules/xdebug.so”. Of course, paths are all dependent on your particular installation so there might be slight differences, adjust accordingly.

$ sudo apachectl graceful
$ cd /usr/local/apache2/htdocs
$ echo ‘<?php var_dump($_SERVER); ?>’ > xdebug_vardump.php

Open a browser window and browse to http://localhost/xdebug_vardump.php and you should see a similar page as in the screenshot below.

Fore more information about xdebug and its use you should consult the xdebug documentation pages.

Additional tools

Your basic setup is now up and running. Read up on how to configure your Apache web server so you can use VirtualHosts. Get some additional knowledge about how to use your /etc/hosts file to add so called “localhost” domains (e.g. http://project.localhost).

Here’s just a list of additional tools I suggest you take a look at:

• Eclipse PDT
  An integrated development environment with error checking, syntax highlighting and debugging (too many options to list!) for PHP
• Subversion
  A code repository that keeps track of all changes. Allows you to rollback to previous release states of your code (also handy when working in teams). Instead of using SVN from the command line, take a look at the SVN for Eclipse plugin which brings SVN functionality from within the Eclipse IDE.
• MySQL GUI tools
  Visual tools to manage your MySQL server and execute (test) queries, create tables, etc. You could also use phpMyAdmin, which is available in your browser to manage MySQL.

Before I put a server or computer into “production”, I think it’s import to test its capabilities and check for possible performance and stability issues right from the beginning. It’s always possible you made a mistake on the application of thermal paste between the heat sink and the CPU, you’ve got yourself buggy memory modules, etc. In order to verify that everything is in working order and good shape (also applies to new laptops) I do a “burn-in” test. If a system passes the burn-in process, it’s generally a good measure of how the system will perform during its first production use.

The tools I use is a “torture” tool and an application to monitor vital system information (CPU temperature, voltages, fan speed).

• SpeedFan
• Prime95

First I load up Prime95 and run a test with the default settings (use the highest possible torture tests available). Then I open SpeedFan and Task manager and monitor the first hour of the test. If nothing goes out to extremes it’s safe to leave the system behind and let the test do its work. On my personal computer, now converted to a Windows Server 2008 Enterprise edition, the CPU temperature went all up to 80° C which was way too high. I shut down the system and checked every part of the installation and found out there was a problem with the termal paste between heat sink and CPU. After reapplying the termal paste, temperatures didn’t went over 50° C.

I usually let the test run for about a night (8-10 hours). If the system never crashed or ran out of memory, you know the hardware and software is doing its job and you won’t be facing premature hardware failure on any of the components. I’ve never really ran hard disk tests. Any suggestions to test that (for instance on a database server) are welcome.

As you can see in the screenshot above, I’m running the test on our home file server. CPU load and memory usage get to the roof but CPU temperature was stable at 41° C. As expected (because I carefully select my hardware) the system didn’t even blink during these torture tests. Of course, this test might seem a bit overkill on a fileserver but you can never be too sure. It’s also a good test for anyone wanting a stable gaming setup. Don’t forget to include a 3D Mark 06 test synchronously ran during the torture test to ensure your GPU can also handle the load.

One of the consequences is that so called “hidden files” on the filesystem (files preceded with a ‘.’ are considered as hidden) are also hidden in the GUI on Mac OS X. As a result (for web developers for instance) it’s sometimes a bit tedious to edit a HTACCESS file. (.htaccess) One way to edit these files for instance is to open Terminal.app (you can use Spotlight), navigate to the folder that contains the file you want to edit and type:

$ vim .htaccess

Of course, you can just type ‘vim /path/to/.htaccess’ too instead of going through lots of folders. The point here is that it’s not straight forward to edit such hidden files from inside the GUI of Apple. Some smart editors (like TextWrangler for instance) have a build-in “Open Hidden” option under the File menu. There’s a way to enable “show hidden files in Finder, through a command which should be executed in Terminal.

$ defaults write com.apple.finder AppleShowAllFiles TRUE
$ killall Finder

The first line sets the property “AppleShowAllFiles” to true and the second line kills the Finder process (which is automatically restarted). Smart as you are you probably figured out by now that if you issue the same commands again but set TRUE to FALSE in the first command, hidden files are again unvisible in Finder.

But issuing these commands frequently becomes a nightmare because they’re quite lengthy and you’re lazy. A solution is to use Automator which comes standard with every OS X installation. Below you’ll find a screenshot guide to optimize the process and make these commands easily accessible just like any other application.

Open Spotlight (⌘ + space by default) and type “automator”. Open the application and choose Application from the available options.

Now you need to select an Action, so we’ll use the search function (again, we’re lazy) and enter “script”, drag the “Run shell script” icon to the right side of the screen. Copy / paste the lines posted above to create your first application, which will show all hidden files in Finder.

We’re almost there. Now choose “File”, “Save As…” and use the settings below to create your first Automator program.

Now repeat each step for a “Hide hidden files” except change the first command to FALSE. Next time you need to show / hide hidden files, just open Spotlight and start typing the name of the action you want (“hide hidden” or “show hidden”) and select your application.

People often start with hardware optimization such as installing faster hard drives, faster CPU’s, more memory, … and they’re right doing so. Hardware is tax-deductible and cheaper than hiring a developer to optimize the code source. However at some point it’s necessary to sit down and actually review the code if no options are left (except doing a major hardware upgrade).

Query optimization is obviously one of the first items looked at. Queries to a database server (often on not so fast 7200 rpm disks) slow down the whole application. Inefficient use of resources and looping or requesting the same data over and over again, not caching query results all lead up to a slow application. You definitely should take a look at those things but what else can you do?

External image hosting

You could start by using an external hosting partner to host images / photographs for you. ImageShack, Flickr, etc. are all viable services but are often bandwidth-limited or blocked by corporate firewalls. A solution for these problems is Amazon web services S3 (Simple Storage Service) which is often an inexpensive solution compared to upgrading available disk space.

HTTP compression*

This feature can be configured by tweaking the web server software – and should be enabled FIRST THING. It’s free bandwidth if you think about it. Most browsers support it and it saves you up to 66% of transferred text data which is a lot in the end. This reduction is by the way applied to all fiels served (HTML, JavaScript and CSS). If you’re working with Apache, take a look at mod_deflate.

Host RSS feeds somewhere else

If you provide RSS feeds for your content, you can choose a third-party service like FeedBurner (owned by Google). An additional bonus is that you have usage statistics for your feeds so you can track your subscribers in more detail.

Reduce content size

You can do some compression yourself by limiting the amount of data your webserver sends to a browser.

• Eliminate whitespace where possibly (but keep HTML readable)
• Compress your CSS file (CSS drive CSS compressor)
• Refactor your JavaScript code (shorter variable and functions names)
• Minify your JavaScript code (JSMin – removes unnecessary white space and comments from your JavaScript files)

These changes should make the whole experience faster though keep in mind that if you’re getting a tremendous traffic increase, the tips listed above won’t suffice but all small tweaks help.

* UPDATE: enabling mod_deflate

In order to enable mod_deflate, edit your httpd.conf file and make sure LoadModule deflate_module modules/mod_deflate.so is enabled. (if not, remove the comment character). Next find the following part in the httpd.conf file

<Directory />
Options FollowSymLinks
AddOutputFilterByType DEFLATE text/html text/plain text/css application/x-javascript
AllowOverride None
Order deny,allow
Deny from all
</Directory>

This is your root directory. Whatever you enable here is automatically active for all other path / site definitions (including virtual hosts) as well. Add the line that’s in bold type and save your httpd.conf file. Restart apache (graceful – to reload the new configuration) and monitor your access log file – it should contain additional ZIP information.

“GET /filers/storageOverview HTTP/1.1″ 1318/3971 (33%)

Content shift

In the past I made the decision to only write about photography. Post my own work, link to a nice strobist guide or just write down an experience. However, as you can read in my About page, I’m no longer active as a photographer (profession) so I’d quickly run out of sources. That’s why this blog will contain personal opinions, technology-related articles, etc. as well from now on, next to of course the necessary photography-related content.

Design

The previous release, a few weeks ago was a bit inspire-less. That’s why I worked a few evenings on a new theme and you’re looking at the result right now. I like it (perhaps might change a color or two) but of course I’m open to suggestions.

Language decision

As the title indicates, a decision has to be made and I think this is a difficult one. Which language should I use on my blog? I’m native Belgian, so my first language is Dutch. I came down to a small list of advantages for each possible language.

Dutch

• Easy to write;
• Possibility to write opinions about local things which readers can relate to;
• Readers can get “jokes” which are often difficult to translate to another language and still make sense

English

• Reaching many more possible readers

Of course, a mix of both is possible as well. But I’m afraid it might get a cluttered look. Any opinions and experiences are welcome. Keep in mind though that a switch to Dutch would also mean I have to look again in the code so the interface is Dutch as well.