Tom Claessens

from inventory.inventories.models import Catalog
from django.contrib import admin

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.

Installing AMP (Apache, MySQL, PHP) can sometimes be a real pain on a *nix based system. A lot of popular distributions make it easy for you with package managers like APT, YUM, etc. but when you compile everything from source you often run into unforeseen issues. I’ve had my share of problems so I decided to (initially for my own reference) write down the process of compiling an AMP stack from source on Mac OS X (MacBook Pro).

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!)

(more…)

I’ve build a few personal computers and servers for scratch. Nothing gives you the joy of handling high-tech hardware, put it all together inside the enclosure and push the power button. The following seconds are pure excitement. When the LEDs start to burn, fans start to spin and hard disk(s) start to generate their typical grinding noise you know you’ve done a good job.

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.

As some of you might know the core system behind Mac OS X, Darwin, uses several features of FreeBSD as underlying foundation. This of course means that some of the features of FreeBSD (and Linux in general) are available (either through Terminal or directly in Cocoa).

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.

(more…)

At some point, when a project becomes popular, availability becomes an issue. For a client it’s important their platform (website, intranet, etc.) is up and running 99,99% of the time (actually they want it to be available 100% but no one is brave enough to guarantee such service).

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%)