October 25, 2009 - 4:47pm | 10 comments
The Apache module mod_vhost_alias and its VirtualDocumentRoot directive can really be a great time saver for local development (some googling will explain why in more deapth). Basically, my local dev is set up so that I just have to create a directory in my aliases directory, and I just then navigate my browser to a URL matching the name of that new directory, and apache knows exactly what to serve automagically.
I think my previous posts have already indicated that my development environment, specifically my IDE, is important to me, and that I make a habit of exploring my options on a regular basis. For the last 7 months I've been using NuSphere's PhpED, which I've really enjoyed. The only things that I've been just a little dissatisfied with is that it only runs on windows and that its window arranging capabilities are not as robust as Eclipse. But, having seen a few tweets about NetBeans, I decided to visit this old acquaintance once again.
I had used NetBeans ages ago when I was learning a little bit of Java. It was good enough... for Java. Then, some time ago I had tried NetBeans 6 (I don't recall which minor version), because I learned they were working on building a PHP IDE out of NetBeans, which intrigued me. At the time, I simply felt NetBeans didn't stack up to Eclipse, and I hadn't yet discovered PhpED. However, with some recent twitter traffic about NetBeans, I figured I'd give the latest incarnation a spin to kick the wheels a little.
As I explained in my previous post, I've been on the hunt for a new PHP IDE. During past searches for this type of tool, I've always taken a glance at NuSphere's PhpED and usually went away screaming rather quickly because of how clunky, ugly, and just plain annoying the interface was (keep reading, though, they fixed this!). My last look at PhpED was verison 5.2 quite some time ago -- it was a good improvement over previous PhpED versions, but it couldn't compete with the Eclipse-based options (at least in the terms that mattered to me).
Which brings me to an important note: what I look for in an IDE is probably not exactly what another coder will look for in an IDE. From what I've experienced, choice of tools for most coders is 50% features/capabilities and 90% preference (oh hai, math!). For me, here is a list of features that are important:
I do a lot of work involving PHP-based web development. I often find myself needing to test e-mail functionality of a complex PHP application (such as Drupal), but I want to be sure that emails won't be sent to any of the unsuspecting users in the database of the application I'm testing.
Do accomplish this, I make a small but important change to my php.ini (actually in my conf.d/dev_mail.ini -- but it's the same thing):
sendmail_path="/usr/sbin/sendmail -i firstname.lastname@example.org"
This tells PHP to use this command line whenever the mail() function is used to send an email. PHP's default here is "sendmail -i -t". The -t tells sendmail to scan the message text for To:, Cc:, and Bcc: headers to determine where to deliver the mail. By eliminating the -t we tell sendmail to use the email address(es) on the command line to determine delivery, thus making sure that no matter what PHP's mail() tells sendmail, it will deliver to the address you want.
Any Drupal developer worth his salt at least knows of the Views module. The shear usefulness and time-saving nature of views has earned the module a place in every Drupal site I've developed. However, because views are stored in the database and their presentation is controlled by the views module itself, managing views between staging/live sites, handling updates, and tracking revisions become difficult issues when dealing with Views.
I've been using CakePHP 1.2.x for projects at work, where our primary database back-end is Microsoft SQL Server. Maybe I'm just missing something, but it seems to me that SQL Server outputs datetime values in an odd way (by odd, I mean not parsable by strtotime). When pulling datetime values out of SQL Server, CakePHP will render them as PHP strings just as they are returned from the server, in this format:
Jan 10 2008 12:25:07:000PM
Now, strtotime parses incoming values according to GNU Date Input Format, which is incompatible with the output from SQL Server (note the milliseconds). To make life easier when working woth models that describe MSSQL tables with datetime fields, using this behavior can make things a little easier.
June 3, 2007 - 10:58pm | 1 comment
At work a few months ago, I was directed to started looking into some options for developing small database applications. So, I set out on my quest to find the best solution out there. Several weeks, and at least as many frameworks later, I finally found a solution that seems to work.