Dreamweaver
I’ve been using Dreamweaver for quite some time now. In fact, I’ve been using Dreamweaver since I stopped using straight notepad. I use Dreamweaver as a text-editor only. I never use the preview tools, and truth be told, about 90% of the bells and whistles that Adobe has built in are sort of wasted on me. But here’s what I do like:

• Intellisense: As a tool, I have come to depend on Dreamweaver to finish my thoughts for me…and also to provide some gentle suggestions for what is available when I am writing CSS
• Ctrl+Shift+U: If I had a nickel, for every time I use this shortcut…I love the ability to quickly make changes locally and then push them over to the server
• File Manager: I think Dreamweaver generally does a good job at this
• Site Manager: I have set up so many sites that I can’t tell if this is inuitive, or that I’ve created some sort of strange coding muscle memory.

And really, that is what I use Dreamweaver for. Dreamweaver is a bit of a bloated program…but it’s not Adobe’s fault. It HAS to be because many many people out there utilize all the other neat stuff it probably has to offer. Me, I just don’t care.

TextMate
I decided that as part of this whole “switching to Mac” experiment that I would try out other tools. And so, on the suggestion my friend Marc Amos, I started with TextMate. And you know what, I like TextMate…a lot. It is truly what it claims to be…a friend of text. It is lightweight, simple, unobtrusive…everything a true text editor should be. Unfortunately, I’m looking for a bit more of a committed relationship…a little more give and take. Not a lot, I’m not needy…but TextMate just wasn’t giving me everything I needed. I say this with all honesty, “It’s not you TextMate…it’s me. Let’s promise to stay friends, ok?”

Coda
Mostly because I promised myself that I would give everything a fair chance, I didn’t stop there. And so I checked out Panic’s Coda. It was as if the folks at Panic knew what I wanted, and built a tool with JUST that functionality. Coda is lightweight…well organized…intuitive…and not a BIT over-built. See the list of things I mentioned that I use in Dreamweaver? Yeah, that is pretty much all it does…and that is a breath of fresh air. There is a CSS-editor built in, which I will never use - because call me a purist, but I like to code my CSS by hand. The intellisense is a step or two BETTER than Dreamweaver. I went into a PHP document and started coding, and there were all of my methods…as well as hints for all the potential arguments built right in. Setting up sites is easy and kind of fun. And most importantly, although I may not have Ctrl+Shift+U…with Coda, now I have Option+Cmd+P. I can imagine developers being able to use Coda as a tool in a number of different ways…and that is EXACTLY how it should be. I spent about 15-20 minutes on the Coda site watching their well made “demo” videos, and then played for maybe 15 minutes after that…and I felt like a super-user. Good stuff Panic…when my trial runs out, barring some unforeseen major problem…you will have my $99.

So it’s here…I am writing this entry from it in fact. I have been playing with it for exactly 2 hours, 8 minutes and 9 seconds (thank you iPhone timer). In that time, I’ve done all the things you typically do when setting up a new machine. Got all my basic apps (mail, IM, etc) configured. Got all my MUST have tools (Firebug, etc) installed.

My VERY first impressions are all very positive. I keep looking for things, and not being able to find them…but then as soon as I ask for a little assistance (thank you Paul Kelley and Marc Amos) something became overwhelming clear. I wasn’t unable to find what I was trying to do because it was hidden - but rather because I am so conditioned to look deep in some directory, or hidden in some config file - that I was unable to see the MOST obvious solutions. It truly is brilliantly simple.

The whole hand-gestures thing is really cool - and I can see that I am already addicted to it. However, now I need to relearn all my keyboard shortcuts. I tend to use the mouse/trackpad as little as possible - and getting used to the different shortcuts will take SOME getting used to, but that was to be expected. As I type, I am installing Quicksilver which looks VERY promising (more on that after I try it out).

Text Editors 
So now the big question. Which text editor will I end up using for the bulk of my work…the actual CODING. I am currently a Dreamweaver guy, but I am going to use this opportunity to try out some of the other tools out there. I am installing Coda and TextMate to start out with, but am hoping to get a BETA of Espresso to try out as well.

Other Ins Outs and What-Have-Yous
So, the other tools that have yet to be decided on are:

• SVN
• FTP
• Open Office or the iWork Suite
• Twitter Client

So, now that I look at it, it’s a pretty short list.

Anyone who knows me well in my “developer” life, has probably heard me more than once threaten to leave Microsoft once and for all and try my hand at developing on a Mac. I currently develop on a Thinkpad T61p running <eek>Vista</eek>. This is my third Thinkpad, and to be honest, I like it just as much as I liked all the others. It is dependable, durable, comfortable…all the things you look for in a laptop. So why am I leaving my Thinkpad? I would love to say that I have a compelling and rational explanation for the move…but sadly, I do not. So it boils down to this: The MacBook Pro is a gorgeous peice of technology, and I want one. I mean c’mon…I sometimes work 12 hours a day on this thing - do I really need to justify the move? I think not.

I have seen front-end developers - who I respect greatly - swoon over their Macs. I have watched fan-boys document the unpacking process. I have tuned into the live-blogging at Mac events.  So in the past, I have flirted with the idea of switching to Mac. In fact, just before I bought THIS Thinkpad, I walked into the Mac Store with cash in hand. The “genius” who approached me was so arrogant and generally obnoxious, that I walked out of the store, went home and bought my Thinkpad from Lenovo.

Why Not Use Linux?
I love Linux…I really do. I believe in Linux, certainly more than I believe in Apple. So, why not use Linux? I mean, with all the good options out there these days (Fedora, Ubuntu, Suse) I should be able to find one that will suite all of my needs - and plus, I spend half my day working on Linux when I am on the server. Here’s the thing…a part of my job is being able to develop in PHP/MySQL, but also in .NET. In order to take advantage of using Microsoft’s IDE, I need at least ONE Microsoft box kicking around. I could use VMWare Fusion on the Mac…but no matter how many reassurances I get from the Mac folks out there - I just don’t want to end up coding in a VM, even if it’s only part of the time.

Two Hours and Counting
So I did…I ordered my MacBook Pro and in two hours, I am heading off to the Fedex pickup location to pick it up, bring it home and open it (undocumented). But today, it occurred to me that the reason I have never quite made the leap, was because I don’t KNOW all that many PHP/.NET/AJAX developers who use a Mac exclusively. So for the next few days, or maybe weeks, I am going to use the Practical AJAX blog to document my experiences switching to my Mac. I hope that these entries can serve as a point of reference for any other developers out there who are on the fence. I don’t know on which side of the fence I will land on - but I am excited either way.

The Plan
So here’s the plan. The MBP is going to serve as my primary development machine. I am going to repurpose my Thinkpad, blow <eek>Vista</eek> off of it - and install Fedora as well as VMWare Server. I’ll then install a bunch of Microsoft VMs for testing and any dedicated .NET development I need to accomplish. In fact, I think i’ll document the repurposing of my Thinkpad here as well. At the end of the day I will have eliminated Microsoft from the equation (at least as a base OS) entirely.

So, I ask the question: “Can an AJAX developer really work exclusively on a Mac?”. I don’t know, but I intend to find out.

I recently completed what I would consider a fun small project for Dangerbird Records. The crux of the project, was that one of their bands, The Eulogies, armed with iPhones would be snapping shots from the road and emailing them to their site. We then ran a cronjob which pulls in the images and stores a reference to them in a database.

Now, the fun practical AJAX side of this was how the simple little slideshow I built works. When the page loads, the slideshow populates three images:

• The current image being shown
• The next image
• The previous image

This same thing happens every time the user clicks Next/Previous. The page makes an ajax call, preloading the next TWO potential images.
This way, when the slideshow (built using jQuery) switches images, the preloading is always already done - without having to bulk preload all the images when the page loads. Simple, practical…the way AJAX should be! You can see the Eulogies AJAX slideshow in action here.

A conversation I have had on more than one occasion revolves around form validation. Client side or server side? I think we all know that the answer is, and always has been: BOTH. That being said, AJAX provides a delightful way to accomplish both tasks at once.

Using AJAX, we can actively examine the users input as they are typing - and help them get to end result we are looking for. Below, you will find a very basic example I mocked up to demonstrate what I am talking about. As you start typing your email address into the form field - we are sending AJAX requests to a PHP script which is running a quick regular expression check to make sure the email address is valid. In reality, in order to make this worthwhile, the AJAX call would need to be doing something slightly more useful - like verifying that the email address has not already been registered. This PHP script sends a response back, and using some basic dHTML - give the user an alert (although in this case a rather rude one). The other thing we are doing here, is unlocking the ability to ‘Submit’ the form - once our criteria has been met. You will see that the Submit button is disabled until we get a valid email address.

Example: AJAX Email Validation Enter email below.

Now, this is admittedly a very simple example - but I think it serves to demonstrate a very useful, and quite practical technique. Some other common uses for this type of AJAX validation are:

• Checking for available usernames against an existing database
• Suggesting alternative available usernames based on previously entered data
• Examining password strength
• Populating extra form fields (city, state, country) once a user enters a zip-code

This method delivers the best of both worlds as far as validation is concerned. It provides the immediacy that Javascript has previously delivered, but also the security of server-side validation. Keep in mind, that if the user has disabled Javascript - this method also will not work - so make sure to use the same server side validation functions when the form is actually submitted.

AJAX (Asynchronous Javascript and XML) is not a new technology, but rather a collection of inter-related technologies being used simultaneously to create an application-like experience for web users. AJAX is not new…although its acronym is only about three years old. Since about 1995, there have been many ways to accomplish this same task - using iFrames, the XMLHttpRequest object, etc. And now, with AJAX frameworks popping up everywhere, and being integrated into server-side tools like .NET 2.0, etc - it would be foolish of me to use this blog as ‘How-to Guide’. And furthermore, I am not interested in telling you how to develop your AJAX programs.

That being said, I AM interested in exploring AJAX as a tool from a theoretical perspective. Unfortunately, when most people think of AJAX their minds go directly to some incredible full featured application (most likely developed by Google) or to it’s limitations, affecting things like SEO, development cost, traditional browsing, analytics, etc.

The goal of this blog, as its name suggests will be to explore the space between these two sets of extremes. Practical AJAX, which can be both incredibly powerful, and in many cases - contrary to popular belief - both time and money saving. Where possible, I will provide working examples of concepts I am discussing and I would love to hear people’s ideas for possible future blogs.