After the first short chapter, the author quickly gets our hands dirty with genuinely useful code based on real-world applications. And this is the book’s strength: its the most comprehensively thorough technical book I’ve read in a long time. If you’ve ever been frustrated because an author doesn’t emphasize a small step in their instructions that turns out to be crucial to make the code work, you’ll appreciate the author’s thoroughness. Every detail of the code implementation is examined, and the author’s reasoning behind his decisions are all plainly laid out for the reader. Because of this, the author is able to provide more than just ‘demo’ code, while still making the progression through the book pretty gentle, so I think this book will appeal to a wide range of experience levels.

When it comes to producing robust applications efficiently, choosing a framework is just the first step. Just as important, is familiarizing yourself with a framework’s plugins and knowing how to use them effectively.

I’ve been using Drupal regularly for about a year now, and I continue to be impressed with it. Not only is the framework itself robust and intelligently architected, but I’ve come to expect that when I need to add a new feature to a site, I can find an existing, mature plugin (or “module” in Drupal’s terminology) that implements it. Not only are these modules great in their own right, but they often work surprisingly well in conjunction with other Drupal modules.

There are so many modules, that it can be a little overwhelming at first. So, although the list of modules I am going to provide is obviously subjective, based on my own use of Drupal, I think it will help orient new Drupal users to some of the more commonly used Drupal modules.

I recently finished implementing a Drupal site that contained premium content, which a user can access only by purchasing a subscription. I am going to describe the general roadmap I followed to implement this, and while obviously somewhat specific to my situation, I think the guidelines provided can be easily adapted to many similar situations.

The need to query LDAP directories arises surprisingly rarely for me. As such, each time, I essentially need to relearn how to do this.

I recently contributed to a PHP based project in which LDAP queries would be needed in certain circumstances, once per session. But in the deployment environment, PHP had not been compiled with LDAP support, and I couldn’t ask for this to be updated.

So, I decided to write the needed function in Java, knowing that LDAP support is part of the Java standard libraries and the server we were deploying to was a Solaris machine, so I knew Java would be available. I could then call the Java program from PHP. Clearly, this approach is far from perfect, but its portable and ultimately I felt it was the best way to work within the constraints of the system. And because such queries would only be executed once a session–and only for certain users–the performance hit of this approach was acceptable.

I’d like to talk more about what I expect to be doing this year, which as an experienced developer, might be somewhat interesting. Then, I’d simply like to speculate on how things that are already happening might play out.

In a previous post, I talked about how to get the most out of the HTML_QuickForm PEAR library. I then wrote an improved version for ONLamp. A reader there asked how to implement a custom form renderer using my HTML_QuickerForm class.

I seem to be writing a lot of “first impressions” posts lately, and I’ve definitely been using several new tools recently. Its fun and strange at the same time; I am doing a lot of learning, which is fun and horizon expanding, but I am also coding less as a result, and because my knowledge of these new tools is necessarily superficial as a newbie, I know that the code I am writing is probably not very good. This week, I started gathering requirements on a project that I initially expected to be coding in JRuby on Rails, only to find out that eventually, I would be handing off the application to a development group that only wanted to support PHP. OK, I thought, I’ll just use CakePHP, which is a Rails clone and one of the best PHP MVC frameworks offered. I know PHP, and I know Rails, so the transition should be smooth. and overall, it has been so far.

As its name suggests, the PHP Extension and Application Repository (PEAR) library, HTML_QuickForm, allows you to quickly and cleanly produce validating HTML forms. In this tutorial, I will walk through a basic implementation of HTML_QuickForm to produce a common contact form and explore ways to get the most out of this library.

If you’ve scanned my blog in the past, you know that I am a big fan of Python and have been obsessed with Django recently, which to date is the most elegantly designed Web framework I have encountered. So far, other than using it on a very small project, I have mostly just been exploring Django and looking forward to using it on a more significant project that’s on my schedule for this summer. Unfortunately, it looks like I won’t be using it on that project after all, and the story behind it, which involves a good deal of office politics and my reasoning as I try to find a way through it, may be of interest to some.

Several weeks ago, I received a frantic call from an administrator of a site running a popular fork of osCommerce, saying he had 72 hours to fix dozens of vulnerabilities reported by ScanAlert–the company behind the “Hacker Safe” PCI compliance logo–or his right to display the Hacker Safe logo would be revoked. I ended up doing the job I was asked to do: I not only eliminated all of reported vulnerabilities, but in the eyes of ScanAlert, the site was now able to display the presumably more stringent Visa branded PCI compliance seal, which it hadn’t been able to do before. Although the customer was relieved and even downright ecstatic about the outcome, I was left with some very mixed feelings about ScanAlert, and the work I had done.