I do agree with the author that using an ORM incorrectly can lead to horrible database performance.  The problem, as I see it, with ORMs is that it’s easy to get up and running with only a basic understanding.  But it only takes one simple, common requirement before you need a deeper understanding of the ORM to prevent disastrous performance.  I’m going to describe the problem as well as the common solutions using one such example:

SELECT customer.first_name, customer.last_name, purchase.grand_total
FROM customer
INNER JOIN purchase ON customer.id = purchase.customer_id
WHERE customer.last_name LIKE '%smith%'

This is a fairly basic SQL query by any standard.  We’re simply joining a purchase and customer table together and returning a small number of columns from each table.  It’s not the most simple query possible, but I would still consider this to be SQL 101 level code.  This is also the kind of query that you would see in the most basic web applications.  Yet returning this result from an ORM with efficient database performance can be surprisingly tricky.

My personal opinion is that some ORM authors and users mistakenly rely on an ORM to avoid ever writing any SQL code.  I’m of the opinion that the benefit is more simply to separate and abstract SQL from the application logic.  If you feel that the point of an ORM is to avoid writing any SQL at all, then the ORM has to be very, very smart (and often overly complicated).  If you feel that the point of an ORM is to abstract the SQL, then custom SQL code can stil be written in your app, but it simply stays separate from the business logic.  I find this an easier approach because otherwise the ORM becomes bloated trying to handle every possible edge case can be done with SQL statements.

Both have pros and cons.  If you don’t write any SQL then theoretically you are abstracted from the dialect of one database vendor.  So you could later migrate from, say MySQL to Oracle without worrying that your application has MySQL-specific code.  In my experience this almost never happens, and when it does there still winds up being problems anyway.  If you feel that the point is to separate the SQL from the application level then your application will wind up with SQL code and that may tie you somewhat to the database engine.  However you don’t have to go to such great lengths configuring the ORM and your SQL is fairly well organized and contained at one level of the application.  In case it isn’t obvious, I favor the later, simpler approach.

The problem with the example query at the basic level is that it doesn’t match 1-to-1 with a single database table and requires an ORM to do a SQL join in order to have efficient performance.  If the ORM relationships are not configured and it doesn’t understand how the two tables relate to each other then the ORM would be forced to do a query on one table first, then loop through the results and query the other table.  For example, there may be 1 query for the customers first and then “n” queries where “n” is the number of customers.  This is what is known as an n+1 query and if you work with ORMs they are a performance destroyer that should be avoided.

ORMs tend to take one of two approaches: a) be very smart with a lot of “magic” or b) be simplistic and require the user to configure everything.  To my knowledge there are 4 common techniques that an ORM uses to deal with the above query:

1. Configure the object mapping at compile time for the foreign key relationship
2. Override the fetching strategy at run-time for the foreign key relationship
2. Use a ORM-specific query language to customize the query at run-time
3. Create a custom object mapping at compile time that abstracts the query

Configure the Object Mapping

With most ORMs there is a concept of a “mapping” where you assign database tables, columns and relationships to objects.  Each ORM is a little different in it’s implementation.  Some require configuration files in the form of XLM, some have compiler directives or meta-data that is added to class itself.  Basically this configuration file then indicates to the ORM how to create the SQL query that will ultimately be sent to the database server.

Override the Fetching Strategy

A “fetching strategy” is what tells the ORM how to join tables.  This is usually configured along with the object mapping, but usually can be overridden at run-time.  The two common strategies are “lazy” and “eager.”  This tells the ORM, for example, when querying the purchases table whether it should always do a join with the customer table (eager), or whether it should query the customer table only when necessary (lazy).  In Phreeze the fetching strategy can be overridden globally for the application or just prior to retrieving some data.

ORM-Specific Query Language

Many ORMs provide a query language that controls the SQL which is ultimately created.  The point of this is that you are writing in a vendor-neutral langage so that you are not tied to one database.  In my opinion this strategy simply trades one language dialect for another and doesn’t separate the SQL logic from the business logic.  I have not personally experienced a business decide to change their database vendor and simple swap it out with zero issues thanks to an ORM.  It’s a beautiful idea but I’ve never seen it work and so I question the point.  Additionally you have to learn a psuedo-language and remote-control the SQL that is generated.  I am not personally in favor of this strategy.

Custom Object Mapping

In my opinion the simplest approach is often the best.  A custom object mapping is a technique where you simply create objects and the ORM allows you to provide the SQL that it will use to issue queries.  This allows you to write the most efficient SQL possible for retrieving the data that you want.  In Phreeze these are called “Reporters”

The main negative to this approach is that you can wind up with overlap in your objects.  For example you may have a Customer object and a Purchase object.  Now additionally you may have a CustomerPurchase object as well which combines the two.  You may have multiple variations of the CustomerPurchase object.  Some people don’t like this duplication, but in my opinion the ORM – relational mismatch has to occur someplace.  I’d rather see some class redundancy than deal with DB performance issues or an overly complex ORM system.

Obviously I’m a fan of using ORMs and my reasoning is separation of SQL from application logic (rather than avoidance of writing SQL code).  Used properly I feel they are a valuable technique for keeping code organized.  I’m sure some ORM and non-ORM users would disagree with my opinions on the matter, but we most likely agree that it is an interesting technical problem.  If you have any thoughts feel free to post a comment.

Great programmers don’t trust their own code and assume that they’ve made mistakes.

What exactly do I mean by that?  Notice I didn’t say that great programmers actually make a lot of mistakes.  In fact great programmers probably make a lot less mistakes than their novice counterparts.  But they approach their code with the attitude that there are bugs that need to be discovered.  If something isn’t working, they tend to assume first that their code is problematic until proven otherwise.  Novices are often quick to blame an API, framework or even the language when their code isn’t working.  I’ve literally gotten into yelling matches with frustrated programmers trying to convince me that a framework is broken.

I think there must be an exponential improvement as you grow.  The better you get, the more you scrutinize your code, the less mistakes you make, the more you scrutinize, etc.

There’s tools and techniques to help ensure code is solid, but the best programmers I’ve known will write solid code with or without them.  Their code is good because they approach programming with a defensive attitude.  It doesn’t matter how many unit tests you write if you are too trusting of your own code.  Buggy software tends to assume best-case-scenarios.  The solid programmer obsesses over his/her code, looking for edge cases.

Do you have a mental process for reviewing your own code?  Leave it in the comments!

I discovered that there’s two Address Book “accounts” on the desktop.  There’s a local account called “On My Mac” and another “iCloud” account.  It’s possible that you might have even more accounts, for example Gmail.  Only contacts added to the iCloud account will sync.  It seems obvious except that there’s no visual indication of which contacts belong to which accounts.   As it turns out “On My Mac” was set as the default account so whenever I created a new contact on my desktop it wouldn’t sync.

My solution was to to first set iCloud as the default account.  From that point on all new contacts would be added to the iCloud account and sync instantly.

That left me with the problem of moving the existing “On My Mac” contacts into iCloud.  So that I could see which accounts were part of the local account I unchecked the “enable” checkbok for the iCloud account.  All of my iCloud contacts became hidden and only the 10 or so local contacts remained visible.  I selected all of the local contacts and dragged them to the desktop, which exported them as vCards.  Next I deleted the local contacts so I wouldn’t have duplicates when I re-import them.  Finally I re-enabled iCloud and dragged the exported vCards back into Address Book.  At this point all of my contacts were in the iCloud account and everything synced as expected.

Once all of my contacts were moved to iCloud I disabled the local account.

This warning technically doesn’t affect or hurt anything but of course after paying for the SSL cert and going through the trouble of installing it, we all want our users to see the green lock icon and not a yellow warning icon!  If you’re running Apache2 the reason for this is that Chrome prefers to use TLS encryption but had to fall back to SSL encryption.  Apache2 supports TLS out of the box but may not be enabled by default.

To enable TLS, open your apache configuration file and add the two lines below:  (The config file is where you previously configured SSLCertificateFile and SSLCertificateKeyFile.  It’s possibly located in /etc/apache2/sites-enabled)

SSLProtocol -all +TLSv1 +SSLv3
SSLCipherSuite HIGH:MEDIUM:!aNULL:+SHA1:+MD5:+HIGH:+MEDIUM

What these lines do is specify that both TLS version 1 and SSL version 3 are supported.  Once you’ve added these lines you need to restart Apache (/etc/init.d/apache2 restart).

If you refresh your browser at this point it’s likely that the warning icon is still there.   Shutting down and re-starting your browser should resolve it.  I suspect that the browser negotiates an SSL connection once and continues to use it until the session expires or the browser is restarted.

One thing that was not packaged in the initial beta release is the Apple Script to automatically accept text invitations.  I find it a huge annoyance to click “Accept” every time a new text comes through.  Fortunately the original iChat AppleScripts work on Messages but you just have to obtain and save it to ~/Library/Scripts/Messages.

Download Auto Accept below and enjoy…

Download AutoAccept.zip

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 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 64 bit version.

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.*.*.*