Josh Benner's Blog

The Essentials: What I Install on a Fresh Workstation

Josh — Wed, 22 Oct 2008 20:13:15 +0000

This past weekend, for a number of reasons I won't get into now, I performed a complete "re-install" of my primary workstation. Previously, I was using XP Pro SP2, which had been installed and running smoothly on the machine for nearly two solid years. This also meant that my machine had two years worth of my customized configurations, applications, tools, etc., so a re-install also meant bringing a fresh Windows (Vista this time) installation up to speed and in sync with my preferences.

During the process of re-installing all the various programs and utilities that I make regular use of, it occurred to me that I was installing the things that I just couldn't do without -- the tools I keep in my toolbelt at all times. I don't know if I've got everything installed yet, but I know I've installed all the primary tools that I use on a regular basis... and they are listed here:

AVG Free Anti-Virus

http://free.grisoft.com

Regardless of the enhanced security of Windows Vista, the very first thing I installed was AVG Free. This free little anti-virus is great for the price tag and reasonably effective at catching threats.

Firefox 3

http://getfirefox.com

Firefox is by far my browser of choice due to its features, speed, extensibility, standards compliance, and cross-platform support. Along with Firefox I also install a standard battery of extensions, including:

Firebug
Web Developer Toolbar
YSlow
Download status bar
Foxmarks

Notepad++

http://notepad-plus.sourceforge.net/uk/site.htm

For my simple text-editing and random coding, Notepad++ is my weapon of choice. I spent some time taking a look at the editors highlighted over at LifeHacker, but Notepad++ has just the right mix of everything for my taste.

PuTTY/PuTTY Tray

PuTTY: http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html
PuTTY Tray: http://www.xs4all.nl/~whaa/putty/

I've looked at other programs for Windows, but they are either too expensive, too bloated, or just too limited. PuTTY is by far my favorite SSH/terminal program for Windows. I install the full PuTTY package including PuTTYGen and the like, then replace the putty.exe file with the exe from the PuTTY Tray project, to get just a few more nice features that make it that much better.

Zend Studio for Eclipse

http://www.zend.com/en/products/studio/

As covered previously, I use ZSE as my primary IDE for my web development work.

MySQL GUI Tools

http://dev.mysql.com/downloads/gui-tools/5.0.html

During the course of web development, you usually end up interacting with databases a good bit. I've found that the MySQL Query Browser is a handy little tool, especially when working in a local development environment. This is probably a tool I could do without or even find a better fit, but it got installed quickly nonetheless -- because I'm familiar with it.

P.S.: It's a rather large shame that MySQL decided to cripple the free version of MySQL Workbench and charge you $100 for some of the best features. I don't mind paying for software, but the value provided by Workbench is not worth $100, especially when many of those features used to be free.

KatMouse

http://ehiti.de/katmouse/

KatMouse is a little Windows interface tweak that makes the cursor behave a little more like Linux desktops or OS X by allowing you to use the scroll wheel to scroll a window does not have the focus but is directly under the cursor. Once you have this functionality you never want to go back... imagine not having to click in the list of files to scroll through it or not having to switch windows to scroll that web page you have open behind your terminal...

Taskix

http://taskix.robustit.com/

Taskix is simple and to the point: it lets you drag taskbar items to reorganize them. It is lightweight and just works, so I love it. Thanks LifeHacker for turning me on to this little gem.

FileZilla

http://filezilla-project.org/

I have been using FileZilla for (S)FTP transfers for as long as I can remember -- long before it was a slick as it is now. Many agree that FileZilla is the best FTP program out there.

eWallet

http://www.iliumsoft.com/wallet.htm

eWallet is a little addiction I picked up a couple years ago at my last job. This is where I keep all of my passwords and important information, safely encrypted behind my master password. As an added bonus, Illium software (the maker of eWallet) just released an iPhone version of eWallet that syncs over WiFi with your Windows eWallet!

Launchy

http://www.launchy.net/

Since I am using Vista this time around, I thought Vista's nifty search bar in the start menu would replace Launchy. However, my love for Launchy's power, customizability, and great plugins brought me running back into Launchy's arms. Launchy is a simple (although not very light-weight) application launcher that indexes your Start Menu (and whatever you want) and provides a great little hotkey-induced interface for launching your programs, documents, or whatever you want. The excellent PuTTY Plugin makes a great companion to PuTTY as well!

TUGzip

http://www.tugzip.com/

After a long time of using 7-Zip, I found TUGZip about a year ago. TUGZip is extremely fast, has an excellent shell extension (right click on a file and extract it in place), and supports every compression format I've ever heard of... and many that I've never heard of. Best of all, it's free!

CrossClip

http://www.stretchedout.com/products/crossclip/crossclip.php

I started using CrossClip when I started working from home a year ago. My Windows machine sits front and center, flanked by my Ubuntu laptop running virtual machines on the left and my MacBook Pro with OS X on the right. Swivelling back and forth between the platforms is great fun until you realize that you would give just about anything to be able to quickly and easily copy from one computer and paste to the other. CrossClip lets you do that, and it works on Windows, Mac, and Linux (though I don't use it on Linux right now because of synergy), and it turns out I only had to sacrifice $19.95.

Synergy

http://synergy2.sourceforge.net/

Synergy, with all its quirks and oddities, is still the only cross-platform way I've found to use the keyboard/mouse of one computer to control another computer. I use the keyboard/mouse connected to my Windows workstation to also use my Ubuntu workstation to the left.

Note: If you need this functionality between two Windows computers, check out Stardock's excellent Multiplicity.

Jing

http://www.jingproject.com/

Jing is awesome. Never has it been so easy to make a screen capture (with or without voice-over), take a screenshot of just part of the screen, or share your captures with the rest of the world. You have to try it to understand -- I use it regularly to collaborate with coworkers or explain things to clients.

Quick Tip: Route All PHP E-Mails for Development

Josh — Wed, 15 Oct 2008 17:49:33 +0000

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 user@host.tld"

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.

Zend Studio for Eclipse 6.1

Josh — Fri, 26 Sep 2008 18:28:15 +0000

I'm one of "those" people that paid for Eclipse, an open source integrated development environment (IDE). I originally bought it because I love and use Eclipse a lot for my work and I wanted commercially available support for the product on which I depend so heavily.

Zend recently released version 6.1 of Studio for Eclipse, with very little (if any) fanfare or announcements (I didn't know about it until I looked at the download site), compared to the release of 6.0.1 which was heralded in their newsletter, all over their website, and everywhere Zend's press team has any influence. I find this ironic, because 6.1 contains huge improvements and more fixes than the upgrade to 6.0.1 did.

Clearly the biggest change is Studio 6.1's move to being based on Eclipse 3.4, the most recent edition of the IDE. This brings with it a whole slew of fixes and improvements on its own, such as a (marginally) improved install/update engine, more efficiency with how the thousands of Eclipse files are handled, some better over-the-shoulder security, icons and more colors now in various interfaces (such as search), and a whole slew of enhancements to SWT, the graphics engine that renders Eclipse.

Anyone who has used Eclipse/PDT knows that there is a lurking bug that manifests seemingly at random during which the PHP builder/parser will get stuck in some sort of infinite loop. This tied up the workspace task queue, which meant that many other functions were useless when this bug reared its ugly head. The only solution was to kill the Eclipse process and restart it, hoping that your workspace didn't require any Notepad surgery to recover. All that is over in the new version of Studio for Eclipse. Let the villagers rejoice!

A minor annoyance I encountered while updating to 6.1 is that it's not actually an update. Instead, I had to download the full 6.1 release and install it separate from 6.0.x. Zend claims this is because 6.1 uses Eclipse 3.4 -- apparently there isn't an easy upgrade path from 3.3 to 3.4 -- oh well. Overall, though, just installing 6.1 was fine as it was able to load up and understand my workspace just fine. The worst part was re-installing my favorite plugins, like QuickRex.

While Zend solved my biggest gripe about Studio for Eclipse (the building PHP problem mentioned above), they've managed to incorporate a new, really annoying issue. If the Code Analyzer marks a part of your code with a warning or error, in some cases the syntax highlighting just stops after that line. The only way I've been able to get the syntax highlighting to return is to disable the specific error that the Code Analyzer was flagging (usually something like using the value of a function that might not return a value -- duh, then NULL is a possible return!) and rebuild the file. The next time I encounter it, I'm reporting it to Zend to see if that commercial support I paid for really works...

All-in-all -- I'm very pleased with Studio 6.1, and at this point, I'll continue to be a Zend customer, and Studio for Eclipse will continue to be my IDE of choice.

Drupal for Firebug

Josh — Tue, 09 Sep 2008 15:58:35 +0000

Last month Chapter Three announced they were working on a Firefox plugin and Drupal module that would allow Firebug to talk with Drupal. As a Web Developer who uses Firebug heavily every day and who specializes in Drupal, this announcement from Chapter Three got me a little excited -- so I installed the plugin, enabled the module, and gave it a shot.

Installing the DrupalForFirebug Firefox Extension

Downloading and installing the DrupalForFirebug Firefox extension was basically like installing any other extension for Firefox: find it, click the link, let Firefox install it, then restart Firefox. Except one little oddity: in order to download/install from addons.mozilla.org, you have to have an account on the site and be logged in because DrupalForFirebug is in a pre-release status. Not a big deal, so I signed up, clicked the link in my confirmation email, and went on my way downloading the extension.

Installing the DrupalForFirebug Drupal Module

Installing the Drupal module, on the other hand, involved nothing special at all. I just downloaded the module from the Drupal.org project page, unzipped it into my Drupal install's sites/all/modules directory, and enabled the module in the Drupal module administration page (note there are two modules, both required). Also, if you plan to use DrupalForFirebug with a user other than user 1, then you may have to grant the appropriate permissions (I did this for testing things as an anonymous user).

Using DrupalForFirebug

One of the unfortunately rare, but pleasantly surprising events when working with pre-release software, especially software targeted at other developers, is when it works the way it is intended the first time. I took my newly-enhanced Firefox and navigated to the login page of my newly-enhanced Drupal instance and was very pleased to see this section available in my Firebug window:

The DrupalForFirebug module processed the forms on the page (the login form in this case) and output useful information inside a hidden div at the bottom of the page. The Firefox/Firebug extension then pulls that hidden data and puts it into a convenient spot inside the ever-open Firebug interface. And the fun doesn't just stop with outputting FormsAPI arrays. DrupalForFirebug will also tell you useful bits of info, such as:

List of SQL queries, their exection times, and what function called the query (just grabs output from Devel module)
Dump of any user objects loaded during page execution
Dump of any node loaded during page execution
Dump of any view built during page execution

DrupalForFirebug also provides a quick and easy wrapper around Devel's execute PHP code feature, letting you execute arbitrary PHP code on the server from within the Firebug window.

Getting the Most of out DrupalForFirebug

If DrupalForFirebug just had the features already mentioned, it would be worth using. However, the authors took some initiative and included a means for module developers (or debuggers) to output information from their code in a meaningful and well-organized fashion. If you're a seasoned Drupal developer, you've probably done your share of print_r($node) and the like when trying to track down an odd behavior or figure out what data is available to you at the theme level (let's just ignore real-time debugging for now, even though that's still by far my preferred method). The DrupalForFirebug module provides a simple function, firep(), that lets you send in any data, and DrupalForFirebug will wrap it in PRE tags and output it in the General tab of Firebug.

Here's an example I had while working on a site just recently. I had some data stored in the session while going through a wizard-like series of pages. I was debugging the process and I wanted to be able to quickly see what was in the session on each page load. Real-time debugging wasn't ideal for this as there were many page loads during the series of tests I was performing, so instead, I used firep():

function my_module_menu($may_cache) {
  if (!$may_cache) {
    if (module_exists('drupalforfirebug')) {
      firep($_SESSION, 'Session');
    }
  }
}

This bit of code put the entire $_SESSION variable dump into the General tab in Firebug on every page load, so I could get a quick insight into what data was being maintained in the session. Using this I was able to quickly track down a silly typo that was putting the data I wanted into the wrong element of the session variable. If you're wondering what the optional second argument is, it is a label placed above the data output in the Firebug window. This is so you can identify various dumps if there are more than one during a page load.

Conclusion

DrupalForFirebug has earned itself a place in my Drupal toolkit for now. I'm curious to see how often I'll use it over real-time debugging, and I'm anxious to see if the developers of this tool maintain it well and/or take it any further than it already is.

Google Chrome: First Impressions

Josh — Fri, 05 Sep 2008 20:17:17 +0000

Sometime near the beginning of this week I heard something in passing about Google releasing a web browser. At first, I thought that was a cute idea. After a couple seconds of letting it soak in, however, I began to wonder what Google would try to bring to the table that they felt was not already present. I also wondered if Google's banning, then re-instatement of the Mozilla Public License had anything to do with their new browser -- but they're not evil, so that can't be it!

I wasn't really worried about trying it out at all, but a few things conspired to change my mind. First, seeing the CEO of Google being interviewed about Chrome during prime-time. Second, all the blog coverage of Chrome; and, third, glancing over the shoulder of someone trying it out and thinking to myself, "Huh -- looks interesting."

So I downloaded Chrome and set about evaluating it:

Installation

Installation was surprisingly simple and quick. Chrome made things convenient by pulling in all my relevant data from Firefox (including stored passwords -- a reminder that malicious software could get this too!).

Startup

I had heard that Chrome was based largely on WebKit, an excellent Open Source browser engine that is used by Apple's Safari browser. If you've used Safari in Windows, you've probably come to expect to wait a few seconds longer than you're accustomed to waiting while Safari starts up for the first time. This is what I half-expected when starting Chrome, but I was pleasantly surprised when Chrome started up very quickly and cleanly.

Appearance

Having already seen Chrome at a glance, I knew basically what to expect. In general, the interface looks very clean and quick -- just like what we've all come to expect from Google.

Usability

You can't help but feel very unhindered by Chrome's interface. Moving tabs into the title bar is, in my opinion, a cool idea that I jive with (especially nice when the browser window is maximized). The button layout is similar to other browsers, especially Safari, and the configurations and options are easy to find under two buttons to the right of the address bar. I continue to be a little bothered by Chrome responding more than other applications to a single notch on my mouse wheel. Also, scrolling in general sometimes goes noticeably slower than Firefox/IE and shoots the CPU usage pretty high.

Page Rendering

I clicked around for a little while in some of the recent sites I'd worked on, and I couldn't find any rendering errors. After some clicking around to the sites that I frequent I was able to count two instances of not-quite-right rendering of sites that appear fine in FF2/3, IE7, and Safari3.

Often during page loading I would see the various layers get rendered in order. This isn't necessarily bad, because Chrome seems to go pretty quick (at least on my machine) -- but I found this interesting and wonder if it implies something about Chrome's differences even from its WebKit cousins.

Conclusion

I like Chrome. I don't expect to be using it as my primary browser just yet, and I'm not sure if I'd be ready to give up my Firefox extensions. I'll probably use Chrome for quick testing and possibly as just another browser session when testing sites, etc. If you want a simple, quick browser, though -- Chrome doesn't seem like a bad choice. And who knows -- maybe Google is only getting started!

Make Views More Flexible/Maintainable

Josh — Sat, 24 May 2008 15:53:42 +0000

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. On the other hand, source code is easily managed between copies of a site, updates are a breeze, and revisions are natural -- all of this with revision control, such as Subversion. Also, what if you want to implement complicated access rules for your view?

Views documentation has a section on how to programmatically build and render views. This is great, but building a view programmatically takes a lot more time than using the Views UI because you're constantly trying to figure out the table/field names used by the various modules that provide views integration, let alone filter, field, and argument settings. If your development cycle is anything like mine, taking more time on something is not always a luxury you can afford.

Views module also provides an interesting Import/Export feature that allows you to copy/paste a view definition between sites. This helps with moving a view between two copies of a site and even helps a little dealing with updates. If you're diligent, this could be used to deal with revision control as well, but it's still a little clunky if you're maintaining and building sites all the time.

In my opinion, the sweet spot when dealing with views is combining views exports with embedding views in your own PHP code.

Every Drupal site I've developed as ended up with a "custom" or "glue_code" module that does various minor modifications to the site, such as hook_form_alter, hook_nodeapi, hook_menu, etc. I've also started to use this type of module to render and provide default views using the following process:

First, during development of your site, go ahead and design the view using the Views UI as you normally would. We'll call this view example_view.
Once you have the view's page display the way you like it, keep the page display enabled, but clear the URL so that the view page isn't really accessible anywhere on your site.
Now, export the view and copy the large export array that is provided.
Implement hook_views_default_views() in your custom module. Simply paste the exported views array into this function. Be sure your code makes sense and returns something according to the hook spec.
Delete the view from your site, because your custom module will be providing it now.
In your custom module, add a new hook_menu item that points to a callback that will provide the view. For the purpose of this example, our callback is called 'custom_view_page'.

The custom_view_page() function will then look something like this:

function custom_view_page() {
$view = views_get_view('example_view');
return views_build_view('embed', $view);
}

That will retrieve the view (the default one provided by your implementation of hook_views_default_views OR the overridden version if you've defined a view in the UI by the same name), then render it for output. If you need to send arguments to the view, pass them as elements of an array in the third parameter sent to views_build_view().

Benefits:

View definition is no longer in the database.
Updates are performed by updating code base. Simply build updated version of view on dev/staging site, export, and update the hook_views_default_views() implementation.
Revisions of changes to view are kept in source control.
All benefits and flexibility of views is maintained.
Finer control over things like access to the URL that provides the view.
Possible performance gains (untested).

Ecto and Drupal

Josh — Tue, 13 May 2008 03:07:09 +0000

A few weeks ago I read a brief but interesting article by Jeff Whatcott on Getting Ecto Set Up with Drupal. I had heard of Ecto in passing but had never really looked into using it. With all the hubbub around WYSIWYG tools for Drupal and the like recently, I wondered if a good desktop application would be a viable solution, so I figured I'd give Ecto a try for myself.

I was initially very impressed with the relatively simple interface sported by Ecto. After quickly configuring the blog_api module on Drupal and just a few clicks in Ecto I had connected to my Drupal blog and was presented with a list of the blog posts already published. I explored the various configurations and was pleased to find a lot of configuration options -- this isn't just a handy app, Adriaan Tijsseling has done a fine job putting together a fully-featured application workspace.

I decided that I owed Ecto at least a couple blog posts to see if I could use it effectively on my Drupal installation found at jbenner.net. I set about writing my first post with Ecto, and was very comfortable at first, typing away and easily setting basic font styles, adding links, and breaking paragraphs. I was a little confused by the interface to select "Categories" and "Tags" -- as I was entirely sure how they translated into my Drupal environment.

I published the post, then went to my site to check it out. For the most part, things looked okay... there were a few minor formatting things here and there that most likely resulted from oversights on my part while preparing the post. The problems came in when I started inspecting the post in more detail. First, Ecto didn't seem to set my topic tags at all -- for future reference, ignore Ecto's tags, and just use Categories.

Also, I use the pathauto module to automate Drupal's path aliases -- but posting using Drupal's blog_api seems to go right around pathauto. From a Drupal developer's perspective, this will probably make some sense, as I imagine that pathauto does its magic with a combination of hook_form_alter() and hook_nodeapi(). Does blog_api skip various hooks? This might be worth more investigation.

Add to this Drupal's lack of proper time zone handling and you get a rather confusing set of configurations between Drupal and Ecto to get both Ecto and Drupal to show the same (and correct) time. I eventually got a pair of settings that seemed to almost work properly, but the journey was ripe with confusion and lacked a satisfying end. In fairness, I think this may be a shortcoming of Drupal, though I'm not entirely sure in this instance.

Ecto has an option to set the input format to use when it sends the post to Drupal; however, it did not seem to set this correctly in every case. I don't know what was causing the difference in behavior in different instances, but this is an issue worthy of note.

As a note -- don't touch Ecto's summary feature if you're using it to post to Drupal. For some reason, it sends Ecto into a spiral of arguing with Drupal over the contents of your post, and seems to always end up adding what it wants your summary to be at the beginning of your post with broken HTML. You're better either setting your break tag manually in the HTML or creating a custom HTML tag in Ecto and inserting it that way.

Overall, Ecto did a fair job of posting. However, between skipping pathauto and the time zone issues, I can't see myself using Ecto regularly, as I'd find myself in Drupal's node form fixing things up anyway. More importantly, Ecto doesn't really simplify the process of posting blog entries in general, though it does offer some nice tools for performing more advanced blog actions, such as integrating images, or Amazon and Flickr resources. If anything, I could see myself using Ecto to write drafts and performing cleanup and publishing in the web interface. This might especially be handy if I want to start a post while offline.

I don't see myself encouraging any clients to use Ecto with Drupal at this point. I want to emphasize, however, that this isn't necessarily because of problems with Ecto as much as some problems between Ecto and Drupal.

My OS X Toolkit

Josh — Thu, 17 Apr 2008 03:25:09 +0000

After the first day of having the new Mac and playing with iChat, it was time to hunker down and start accomplishing things with the Mac. In the last few years one of the biggest reasons I've been reluctant to get a Mac has been a sense (whether justified or not) that the software selection wouldn't be sufficient for my wants, needs, and tastes. Part of my recent decision to get the Mac was the general feeling that this was no longer the case. I've found this to be true.

I spend a lot of time on my computers. Most of that time is spent using or writing web pages and web applications (and the occasional video game). Web development isn't what it used to be, and tackling everything requires a lot of tools. I'll summarize my needs and the tools that I've settled on using to meet them.

SSH Terminal
Windows: puTTY
OS X: iTerm
Most of the stuff I found on the web about doing SSH in OS X said "just use the terminal!" While I like the OS X terminal, I was hoping to find something to help me manage sessions and generally make all the SSH connections I juggle in a day a little easier to use. Enter iTerm -- it does just enough using its 'bookmarks' and connection and keyboard profiles to make managing multiple console or SSH sessions graceful, and its tabbed interface is another step in keeping my workspace navigable. Oh, and it's free.

Text Editor
Windows: Notepad++
OS X: TextWrangler
OS X comes with a nice little text editor aptly named "TextEdit" that is pretty good, but I like text editors that go the extra mile. I like to search and replace with advanced regular expressions. I like a text editor that implements a good system to manage a bunch of open text files. I like a text editor to do basic syntax highlighting in the event I don't open a file in my IDE. TextWrangler does all of this and so much more. And its free!

Web Browser
Windows: Firefox
OS X: Safari and Firefox
I love Firefox, and it was the very first thing I downloaded on the new Mac. However, I felt I owed it to myself to give Safari a fair shake, especially since I've been impressed with the betas (and recent release) of Safari 3 on windows. Safari on OS X is fast, clean, and nice to use. If Safari had the plugin base of Firefox, rendered a few more sites better, and had some minor usability tweaks... okay and a bunch of other things, I'd use it as my primary browser all the time. For now, I enjoy using both of the browsers side by side.

Development Environment (IDE)
Windows: Eclipse
OS X: Eclipse
I have been very happy with Eclipse on Windows (and Linux) for a few years now, and it just keeps getting better. When I started working on the Mac, I wanted to use whatever was widely used by the Mac development community. A lot of web developers I know who use Mac as their primary OS use TextMate. While I liked TextMate (a lot), between the TextMate price tag ($64), the effort of learning a totally different interface, and the fact that Eclipse works great on OS X... I stuck with what I knew in this department. Expect more on this later.

Local Web Application Stack
Windows: XAMPP
OS X: MAMP
When I develop a web application I almost always work locally and migrate the changes to the live server. This development pattern has so many advantages that I can't believe there are web developers that still don't use it. A few years ago the way to do this was downloading and installing (sometimes compiling) the various components of the stack (usually Apache, MySQL, and PHP). More recently groups like apachefriends have put in great effort to package the components in easy-to-use, point-and-click packages. XAMPP is a great packages for Windows and is also available for OS X. I tried XAMPP for OS X, but when I tried to configure it with things like vhost aliasing and such, it kept resulting in errors and odd behavior. I then tried the free version of MAMP, which I found to be much easier to configure.

A Voyage Home: My Return to Mac OS

Josh — Sun, 13 Apr 2008 06:10:09 +0000

People often ask me how or when I started working with computers, programming, etc. My answers usually hark back to my childhood and my first ventures with my parents' Macintosh Plus, then our family Performa, and my Powerbooks 180c and 540c. Basically, all of my earlier computer encounters were on a Mac, from learning to type to learning my first programming language to discovering the internet for the first time.
Sometime during the late 90s I became frustrated and angry with working in a Mac world and I "converted" to my first Windows machine, vowing to never look back. Since that day I've been working primarily in Windows and Linux, only touching a Macintosh when absolutely necessary... that is, until this last week.
When my new 15" Mac Pro arrived and I opened it and started it up, I was consistently impressed with how easy it was to use, and how well it "just worked." The experience has been a far cry from the agonizing memories I have of Mac OS 8 & 9. I spent some time playing with the software that Leopard comes with, such as iChat, iCal, etc. I have to say... iChat is effective, Photobooth is a blast, and syncing the iPhone with the Mac is an order of magnitude better than with my Windows box.
I've spent a respectable amount of time making the Mac work the way that I like, such as managing hotkeys, setting up my command line environment, and trying to find a software to meet my many needs. The process has been fun and I've been very pleased to find that the solutions available for Mac are closely related to (and sometimes better than) the Windows software that I regularly use (more posts on that later?).
All of this to say that I'm not only happy with the Mac, but I've been overwhelmingly surprised at how much I'm enjoying the experience. I won't be getting rid of my windows or linux boxes any time soon, but the Mac has quickly secured its place in my toolkit.

Adventures with VersionOne

Josh — Mon, 07 Apr 2008 21:44:19 +0000

A few months ago the primary project to which I'm assigned espoused an Agile/XP approach for development... well, a heavily modified Agile/XP approach as there is only one developer (me) working on features/tasks/etc that come from a team of people, funneled through a project manager of sorts before they get to me. Because of the unique relationship we've enjoyed with the client, managing the project has been an interesting challenge since client users are involved closely with the project and are sometimes responsible for tasks such as testing.

We've moved between a few task tracking/project management systems in the process, trying to find software that fit our needs, the latest of which is VersionOne. The client actually came across VersionOne, which I'd only heard of in passing before that point, and asked if it would be a viable system to use during development. After a quick glance by several of our team members, we agreed that the system looked pretty good and was unique in that it was designed with Agile in mind so it supported the Agile/XP workflow in a manner than other ticketing systems didn't. So, over the course of a couple days we migrated to VersionOne and started using it.

The first thing that impressed me about VersionOne (aside from its nice, Web 2.0 shiny look) was how you can customize every view you have access to. You can specify which columns to show, and even which you would like to be able to edit inline (great feature!). This allows for a customized experienced and access to information the way you want it.

It wasn't long before we started running into the challenge of figuring out how to pass information back and forth. VersionOne has nice "Notes" that can be attached to any object (story/defect/issue/request/task/etc); however, as far as I've been able to tell, the overly-complicated but barely useful subscriptions/notifications feature does not allow emails to be sent to let me know when there's been a new note on an object. In fact, the notification system won't send emails at all -- the only option you have is a personalized RSS feed that pushes nearly useless notifications about the various objects (not including when there is a new note).

In pursuit of a workable setup, I discovered that VersionOne has an Eclipse plug-in. I rejoiced. That is, until I installed and used it. The plug-in is horribly buggy and exposes an abhorrently limited set of abilities to the user in the Eclipse environment. All in all, the plugin should be abandoned and they should put some honest time into writing a good Mylyn connector.

Lacking an email option wouldn't even be so bad if the notification system's personalized feed provided useful information about the objects for which it's updating feed items. After a couple days of tinkering with notifications, I've all but stopped paying attention to the notification feed and have been forced to rely on a combination of clever custom statuses, a custom 'status note' text field, and pure memory to determine if an object has been updated in a manner that needs more attention from me.

Overall, however, I've been really pleased with the way VersionOne works and its slick interface. I'm holding out hope that with time I'll either get used to how VersionOne wants me to communicate or uncover a feature I'm not yet aware of that will help bring important information to my attention.