arthur's blog

KCachegrind- or in this case QCachegrind- has a great visulaization of the call graph.

There are a number of tools that are quite wonderful for investigating PHP's call stack. I am rather fond of KCachegrind (which I suppose makes me a bit nostaglic). Having regretfully followed Apple's upgrade path I have found myself without KCachegrind. The instructions that I wrote previously for installing KCachegrind on OSX no longer work because Fink's KDE packages are unfortunately not ready for 10.7+.

Happily there is a fairly painless way to work around this. This post is where I started from. Basically it eshews using KDE and instead just installs the QT libraries to run KCachegrind. This makes the process much less time consuming and seemingly less prone to dependency issues. I had to change a few things so I've repeated the steps here, however credit goes to Paul Kehrer for the direction.

• Download QT and install it. I used 5.0 beta version and seems to work fine.
• Install Graphviz.  I used fink -b install graphviz
• Download KCachegrind from: http://kcachegrind.sourceforge.net/html/Download.html
• Unpack KCachegrind and navigate into the directory and into qcachegrind. I used qmake-4.8 -spec macx-g++; make
• open qcachegrind.app should open up the application. You can move it to your Applications directory if you want.
• I modified my xdebug settings in php.ini to use: xdebug.profiler_output_name = callgrind.%R.%t This lets KCachegrind open the grind files without having to select the "All Files (*)" option. There is a patch metioned here: https://gist.github.com/1029580 that lets KCachegrind open any file type though I think this has actually been applied to current releases. Plus, if you change the output file name I think this is somewhat moot.
  

How do you reduce the barrier to becoming an authenticated user in Drupal? There are a few goto solutions: Email Regiatration, Login Toboggan, captcha on the user registration form, etc. These are effective and well tested solutions that allow new users to register and reduce the threat of bot registrations. Single signons with Facebook or Twitter are also viable options and arguably reduce the barrier with the lowest risk. Unfortunately they require third party account which doesn't meet the need for a user who wants an account only on your site. 

In my mind Login Toboggan offers an interesting solution to this issue by creating a specific role for a user that can be created and logged in but not given full rights until they confirm their registration. Where it doesn't lower the barrier is that it still requires creating a username and password during account creation. 

The thought experiment here is how much of the registration form can we strip away to get a user created without out overly risking bot registrations. Since email addresses are for the most part unique, is it possible to use only an email address to create an account without a username or password? The following is a flow chart that this kind of registration might use with a nod to Email Registration module. Proto code forthcoming.

I sized the background images for this blog based on view port size. There are sized versions for each breakpoint in order to reduce page load size- the 480x320 size saves more than 80k for the intial page load compared to the desktop version. I'm building the page this way with the smallest version of the image as the default and then selecting what is an "appropriate" size based on media queries. Each viewport size is a crop from the same background image so even when resizing the browser you aren't thrown too far off from the orginal perspective of the image. I used CSS to fix these backgrounds- this prevents the background image from scrolling which means that the image can be cropped to standard viewport sizes keeping file size lower.

One of the annoying things about using Tar is that unless you remember -C the files that you are archiving include their full path. This means that when you go to extract the files you get the full directory tree. Though there are clearly good reasons for this, when you're just trying to put together a few files to send out this is probably not behavior that you want.

Poking at Drupal's ArchiverInterface it I ran into this problem. I want to be able to build arbitrary archives of single files at the root of the archive that can be used elsewhere without having to munge file paths at a later date. Using both types of archiving (Tar and Zip) that are implemented in core the files in my archives have their full paths. Looking at the code this seems to be borne out.