Since it’s turned into almost a daily thing for me to open terminal and kill imagent, I decided to write that into applescript and make an icon so I can just click it.  It’s only one line of applescript:

do shell script "killall imagent"

That’s all there is to it, but in case you don’t know or want to deal with compiling that yourself, you can download this pre-built version of kill-imagent.

1. Install ImageMagick

sudo port install ImageMagick

2. Install imagic module

You’d expect to just be able to run “pecl install imagick” and I would probably try it first.  However the instructions below will work if the automatic installation returns the error: ImageMagick MagickWand API configuration program… configure: error: not found. Please provide a path to MagickWand-config or Wand-config program. ERROR: ‘/private/tmp/pear/temp/imagick/configure –with-imagick=/opt/local/bin/’ failed.

Note version is 3.0.1 in these instructions, adjust the commands depending on the version that is downloaded by pecl.

pecl download imagick
tar xvzf imagick-3.0.1.tgz
cd imagick-3.0.1
phpize
./configure --with-imagick=/opt/local
make
sudo make install

The install process will create a file “imagick.so”, but it may not be automatically installed in the correct location depending on your PHP path settings.  The install will output the location of the .so file so if necessary, you can manually move that file to the extensions directory for your web server.

3. Append to php.ini

extension=imagick.so

That should be it.  Restart Apache and view phpinfo.php. There should be a section for ImageMagick

Most of these errors I feel are due to developer fear and paranoia that the end user will see an error message. Nobody wants their customer to encounter bugs and errors, but there is a difference between an app that is solid and one that simply hides problems. It’s much harder to fix a bug that nobody knows is there. I’ve written about this before in my article about insidious bugs.

1. Sticking Your Head in the Sand:

try {
  // ... code here...
} catch (e) {
  // hope this never happens!
}

A try/catch statement with no error handling inside the catch statement is a great way to mask errors. (masking errors is bad!) Your code quietly suppresses the error and no user or developer will see a problem unless they notice unusual behavior of the app or data loss. This seems to be a strategy used when the code contains an expected error that can be safely ignored and shouldn’t halt the program. That is a dubious assumption but assuming it is true, the danger with this strategy is that a different, unexpected error might also occur. Because this try/catch doesn’t discriminate it will mask all errors that occur and will hide a situation that wasn’t anticipated.

A better approach (assuming the exception that can be safely ignored) might be to first ensure the try/catch surrounds only the most minimal code or line in question. Then when the error is caught, verify that this is the expected exception and not something else by checking the exception type, id, etc (depending on the language). It can be helpful to at least write a “warning” to the console or a log file so that when another developer is trying to fix your bugs, he/she will have some clues as to what your logic was when you were writing this code.

2. Attempting to Set Things Right:

try {
  i = x.toUpperCase();
} catch (e) {
  // x must be null.  wonder why...?  oh well, let's fix it!
  i = "";
}

Handling an exception by ignoring faulty input and setting variables to arbitrary, default values can be dangerous. This has a high probability of creating “insidious” bugs because they don’t always address the cause of the exception and simply try to fix it. Again, this masks problems and makes apps extremely difficult to debug.

The optimal way to handle this scenario is to prevent the invalid input at it’s source, before it gets passed into a method or function. If this method is supposed to gracefully handle bad input then it should do so by checking for legitimate values explicitly instead before using them. If the input doesn’t validate then throw an exception. This is a scary concept to novice and sloppy programmers alike because they are afraid of creating errors that must then be hunted down and fixed at the source. However what this really does is to *reveal* bugs in faulty calling code. Revealing bugs is a good thing. It can, unfortunately, open a can of worms and a lot of sloppy calling code now becomes your problem!

3. The Hot Potato:

try {
  // ... code here...
} catch (e) {
  // whew!  good thing we caught this!
  throw e;
}

A useless try/catch that simply re-throws the original exception does nothing to improve the code. This is probably the least harmful mistake because it doesn’t mask errors. However the code is worthless and does nothing to help with debugging or make the app more stable.

The solution is to just remove the try/catch and let the original error occur. The end result is the same.

4. Re-branding Exceptions:

try {
  // ... code here...
} catch (e) {
  // jason said throwing exceptions is good. i wonder what he meant?
  throw new Exception( e.getMessage() );
}

Catching an exception and then throwing a new exception with some of the original info. This example may not mask bugs but it can make the original problem difficult to locate. The stack trace of the original exception probably contains clues about the original source of the error, but you lose all of that information when you create and throw a new exception.

Believe it or not, a good way to handle this is to remove the try/catch. There is one legit reason (in my opinion) to throw a new exception. If you anticipate an exception to occur and 1) you are able to keep the application in a known state and 2) you need the error text to be more friendly or understandable. For example, if you expect a network connection exception to be thrown under normal conditions then you may want to create your own exception that says “Network Unavailable” instead of a allowing a cryptic error message to come from a low-level network API. However you do need to be meticulous and add logic to verify that you are catching only the expected exception and not something else. Because if you are expecting a network exception but instead get an “index out of bounds” then your “Network Unavailable” message is not only masking a bug, but potentially sending another developer on a wild goose chase.

Those are the situations that I was able to think of off the top of my head. Do you have any other try/catch situations worth mentioning? Feel free to leave them in the comments.

1.Turn on Apache

Go to System Settings->Sharing and turn on Web Sharing. If necessary click the button that says “Create Home Folder” which will create a folder called “Sites” in your home directory.  You now have a web server that you can access at http://localhost/~username/  (“username” being your own account login name)

2. Edit /private/etc/apache2/httpd.conf

To enable PHP uncomment (remove the number sign at the beginning of) the line:

#LoadModule php5_module libexec/apache2/libphp5.so

(optional) you can re-map the server root to your home website directory by editing DocumentRoot:

DocumentRoot “/Users/username/Sites”

If you wish to use .htaccess files then look a bit further down AllowOverride and set it to “All” like so:

Options FollowSymLinks
AllowOverride All
Order deny,allow
Deny from all

3. Edit /private/etc/apache2/users/username.conf

Your user directory has it’s own permissions as well which are located in this separate file.  You may wish to enable FollowSymLinks and AllowOverride again here by changing these two lines like so:

Options Indexes MultiViews FollowSymLinks
AllowOverride to All

4. Copy /private/etc/php.ini.default to /private/etc/php.ini

OSX includes a default php.ini file that you can use but you must rename or copy it first.  If you don’t do this then PHP will still run but it will just be using the default initialization settings with no way for you to override them.

Edit these settings in php.ini (some of these settings will not come into play until they are installed)

display_errors = On
mysql.default_socket = /tmp/mysql.sock
pdo_mysql.default_socket=/tmp/mysql.sock
date.timezone = ‘America/Chicago’
include_path = “.:/usr/lib/php/pear”

5. (Optional) Install PEAR

If you use the PEAR libraries you can install them using the included phar file like so:

sudo php /usr/lib/php/install-pear-nozlib.phar
sudo pear config-set php_ini /private/etc/php.ini
sudo pecl config-set php_ini /private/etc/php.ini
sudo pear upgrade-all

6.  Install MySQL

This doesn’t really require instructions, simply download the latest MySQL from mysql.com.  I installed the 32 bit version, however it may be possible to run the 64 bit version as well.

7. (Optional) Install Apache Plugins

If you use encryption you may need to install mcrypt.  Instructions have been provided by Michael Gracie

If you use the Zend debugger you can install that using these instructions.

Using a debugger really pays off in the long run in my opinion.  It gives you so much visibility and insight into what’s happening in your code and allows you to work faster.  Most developers that I know don’t bother installing a debugger for PHP web applications because either they either aren’t aware of how well it works and/or they think the initial setup is a pain.  The setup does have a few steps but actually isn’t difficult.  This video walks you through all of the steps to install the Zend debugger.

Click here to view the embedded video.

Download links referenced in the video:

Zend Studio Web Debugger (Apache Module):
http://www.zend.com/en/products/studio/downloads

Zend Debugger Plugin Install Site (Eclipse Plugin):
http://downloads.zend.com/pdt

Optionally you can download the Zend debugger plugin and install it manually by copying the files to your Eclipse folder instead of using the “Install Site”  That can be downloaded here: http://www.zend.com/en/community/pdt 

Configuration text for php.ini

zend_extension=/usr/lib/php/extensions/ZendDebugger.so
zend_debugger.expose_remotely=always
zend_debugger.connector_port=10000
zend_debugger.allow_hosts=127.0.0.1/32,192.168.*.*,10.*.*.*

http://wwwapps.ups.com/WebTracking/track?track=yes&trackNums=1ZXXXXXXXXXXXXXXXX

If any value is provided for the “track” parameter then the confirmation page is skipped and the user goes directly to the tracking page.  If you’d rather send the user to the confirmation page then just omit that parameter.

Direct URL for FedEx shipment tracking:

http://www.fedex.com/Tracking?action=track&tracknumbers=XXXXXXXXXXXXXXXXX

The version included with WordPress (as of 3.1.3) is 1.2.  However this is not the most recent version of SimplePie.  Attached to this post is SimplePie 1.3-dev which is compatible with version 1.2 but addresses various issues.

If you are having trouble parsing feeds, you may try downloading this file and replacing the file /wp-includes/class-simplepie.php with this one.  Be sure to back up your original file in case anything goes wrong.

Click the package below to download the file:

Luckily there’s a solution. As an example below is a query that will set the priority to “1″ for all customers who have at least one matching purchase record. I realize this is a stupid way to run this particular query, however I am merely posting a simple example of a query to demonstrate the error and workaround. Jeez, get off my back!

A Non-Working Example:

UPDATE customer
SET customer.priority = 1
WHERE customer.id IN
(
  SELECT DISTINCT customer.id FROM customer INNER JOIN purchase ON customer.id = purchase.customer_id
)

The above query will give you the MySQL target table error because we are trying to update the customer table, but the customer table is also used to supply the list of IDs.

A Working Version of the Example Above:

UPDATE customer
SET customer.priority = 1
WHERE customer.id IN
(
  SELECT id FROM
  (
    SELECT DISTINCT customer.id FROM customer INNER JOIN purchase ON customer.id = purchase.customer_id
  ) AS tmptable
)

The query is basically the same, except the inner select is wrapped inside another select. The most important thing to note is that the original select has been given an alias “tmptable“. (The name tmptable is arbitrary, you can give it any alias name.) The alias is important because assigning one will tell MySQL to create a temporary table from this select query. The temporary table may then be used as the source criteria for the update statement.

The reason it is wrapped inside another query is because MySQL syntax does not let you assign an alias to a select query when it is part of an update statement. So we have to put it inside another query which, I suppose separates it from the update statement.

The information about creating the temporary table was borrowed from Xaprb’s blog, who goes into a little more detail about the mechanics.

First you need to have a server that is running VNC, but most likely only has it’s SSH port exposed. I’ll assume that SSH is on port 22 and VNC is on port 5900 (these are the default ports for these services). I’ll also assume that you have the ssh command and a VNC client installed on your client machine.

1. On your client machine, open a command line window and enter the following to create the SSH tunnel:

ssh -N -p 22 USERNAME@YOURSERVER -L 5901/localhost/5900

Replace USERNAME with your server username, and replace YOURSERVER with your server address (ie verysimple.com or 192.168.1.99)

2. Once you enter this command you’ll be prompted for the server password. Enter the password. You will see no feedback in the terminal window, but the SSH tunnel is now active.

3. Open your VNC client and connect to the address “localhost:5901″ If you have a password set for VNC access then you will need to enter that now. If all goes well, you should see your server VNC desktop!

It might seem weird that you are connecting to localhost in your VNC client. But the the SSH tunnel you created is actually routing port 5901 on your localhost to port 5900 on your server.