Archives For MySQL

Choosing a Payment Gateway

September 16, 2010

In my forthcoming “Effortless E-Commerce with PHP and MySQL” book (which is pretty much my only focus these days), I wanted to use two different payment systems. This was part of my overall approach of trying to present as big of a picture as possible as to what “e-commerce” is. For the book’s first example, I wanted to use PayPal. Many developers don’t like PayPal, but for customers, it’s the most recognizable name, and that’s critical when it comes to customers being comfortable spending money at a site. People traditionally think of PayPal’s as a system where the customer leaves the e-commerce site, goes to PayPal’s site, and hopefully returns to the original e-commerce site after making the purchase. This is formally called PayPal’s Website Payments Standard, and is demonstrated in my book. In that example, I make use of PayPal’s IPN (Instant Payment Notification) system, so that the site is notified as soon as the payment is made, whether or not the customer actually returns to the e-commerce site immediately thereafter. Tapping into IPN makes the use of PayPal more professional and reliable for the site itself.

For the second example in the site, I wanted to use a true payment gateway: a system that can be integrated into a site so that the customer never leaves. A secondary, but big, benefit of a payment gateway is that the funds get transferred to the site’s merchant bank account, instead of to a PayPal account. (To be clear, PayPal’s Website Payments Pro works as a payment gateway that can be integrated into a site, but I believe the funds still go into one’s PayPal account.) I’ve used several different gateways over the years, but rarely made the selection myself (normally it’s the client making the choice, based upon their merchant bank account). So I spent some time researching payment gateways to find the one that would be best for the book. Many readers also provided their recommendations (thanks!). Here’s how that search went for me… Continue Reading…

MAMP Pro

September 11, 2010

I primarily use a Mac for everything I do (and by “primarily” I mean just about 99.9% of the time), and have for years. I’m not trying to start an argument over the best computer, I’m just saying I like the Mac. One of the main reasons I prefer Macs is that it’s Unix (based on Free BSD, since the creation of Mac OS X) without being too Unix-y. For many people I know and work with—great with computers but not a geek, it’s easy to appreciate the nice interface and reliability and features and so forth, without an awareness of the underlying Unix stuff. For me, who regularly works with Web servers, I can do anything on my personal computer just the same as I can on a Web server. When I develop projects on my computer, transferring them to a Web server is completely smooth process. But why is this post about MAMP Pro?

For years, Mac OS X was a 32-bit operating system with a 32-bit version of Apache included. When Mac OS X went to 64-bit, a couple of years back, it started including the 64-bit Apache, too. This caused some problems with PHP, because PHP wasn’t ready as a 64-bit version (or, more specifically, some of the libraries PHP uses weren’t 64-bit ready). Like many people on a Mac, I used Marc’s PHP installer to update my version of PHP, rather than build my own (with some exceptions, like when I wanted to play with PHP 6). So, for some time, it was challening getting PHP to play along nicely with Apache on Mac OS X (one option was to tell Mac OS X to run the 32-bit Apache by default). It’s at this time that I started using MAMP.

MAMP is a all-in-one MySQL, PHP, and Apache installer for Mac OS X (for Windows, XAMPP is the most common equivalent). In my opinion, there are three great things about MAMP:

  • It just works.
  • It doesn’t conflict with the built-in Apache.
  • It’s free.

Really, my only complaint is that MAMP doesn’t, by default, store the databases in a separate directory. If MAMP were to store the databases (MySQL and SQLite) elsewhere, upgrading the version of MAMP wouldn’t overwrite the existing databases. This isn’t a big problem, but would be a nice feature to use. (Conversely, it’s easy in MAMP to use a different directory for the Web files; I use the Sites folder in my home directory, which is more in keeping with the standard of not putting user files in /Applications.)

MAMP comes in a free version that I’ve been using, happily, for years. I’ve thought about upgrading to the Pro version off and on, but, when looking at the features, didn’t see the need. One feature MAMP Pro offers is the ability to use dynamic DNS to serve your sites from your computer, even if your IP address changes regularly (which is the case for most home access). This is not something I do or recommend others do (at the very least, it’s probably a violation of most ISP’s terms). But just the other day I needed a Web site to actually send out email, even while testing it on my computer. I came across a quick fix for MAMP (non-Pro) but that didn’t work for me. So I finally upgraded to MAMP Pro, which I really had intended to do by now anyway (as an act of supporting a product that I value that’s made available for free).

It turns out that I’m so glad I upgraded to MAMP Pro. The cost was $59 (US), which was slightly high, but not unreasonable. MAMP Pro is does not install a new or different version of Apache, PHP, or MySQL, it’s just a nicer interface to the MAMP installation. That may not sound significant, but the interface let’s you control MAMP more easily. For example, the basic MAMP interface looks like this, plus its moderate preferences panel:

MAMP Standard Interface

MAMP Standard Interface

MAMP Standard Preferences

MAMP Standard Preferences

The MAMP Pro interface has many more options. The highlights are:

  • Quickly enabling outgoing mail (even if using a custom SMTP server)
  • Dynamic DNS, as already mentioned (not that I’ll use it)
  • Fine control over all logs, including an easy way to view them (great debugging feature!)
  • Checkboxes for enabling/disabling Apache modules
  • And more
MAMP Pro Interface

MAMP Pro Interface

But what MAMP Pro does, which I was unaware of but appreciate most, is make it really easy to create virtual hosts. I’m frequently working on multiple Web sites at one time. With MAMP standard, to switch back and forth, I had to go into the MAMP panel and change the server directory, then restart MAMP. And when I went to look at another site, I had to repeat this process. With MAMP Pro I just create virtual hosts: somesite1 points to this directory; somesite2 points to this one, etc. Then I just go to http://somesite1:8888 in my Web browser or http://somesite2:8888, etc.

MAMP Pro Virtual Hosts

MAMP Pro Virtual Hosts

For each virtual host, I can also tweak the server settings:

MAMP Pro Virtual Hosts Settings

MAMP Pro Virtual Hosts Settings

This is very useful and it makes me wish I had purchased MAMP Pro a long time ago (and no, I’m not getting paid by MAMP to say this; I have no relationship with them at all). To be clear, MAMP Pro is just a sophisticated interface and there’s nothing that MAMP Pro can do that you can’t do yourself by editing the proper configuration files, going into the command line, etc. These days, for me, I’d rather spend the $59 (US) and have something working the way I need it to, quickly and easily, then to spend a frustrating hour trying to get the right syntax to work in a configuration file.

I consider myself to be pretty cheap, preferring not to spend money if at all possible (my policy is: the money I don’t spend today is money I’ll have not to spend tomorrow). But sometimes it’s worth it to part with some cash. I just learned that MAMP Pro is one of those times.

I haven’t been posting much the past couple of weeks because I’ve been working night and day on my “Effortless E-Commerce with PHP and MySQL” book. The deadline for me to turn it all in was August 31st, but I’ve got just a little bit of leeway. I should be wrapping the first draft within the next few days and I’m about halfway through the second draft. To explain…

Basically I write a chapter at a time in Word, passing each along to the editor. The chapters go through a line editor (who looks at word choice, clarity, and style) and a tech editor (who looks at the code and such), then come back to me. At that point I do what’s called an author rewrite (AR), addressing the issues raised by the editors and correcting any thing that I later realized would be a problem (especially on a book like this, where chapters build on each other, it’s common to find when writing Ch 7 that something needs to be said or done in Ch 6). After the AR, the chapter gets turned into a PDF, laid out as it will be in the printed book.

So right now, I’m just about to complete Ch 10 (first draft) and do the AR of Ch 6. The plan is for the book to go to the printer on Sept. 23rd, making it available in stores in October.

In my next couple of posts (soon!), I’ll talk about my selection of Authorize.net as the second payment processor and provide the final table of contents. Thanks to everyone for their interest in the book!

My forthcoming “Effortless E-Commerce with PHP and MySQL” book is now available to read via Safari Books Online. Through the Rough Cuts series, you can read this book as I write it, and even provide feedback that could affect the final text. I just completed Chapter 9, which means there are two more chapters left in the third part of the book. It looks like Part IV of the book will have two chapters as well. I’m hoping to wrap up the first draft of the book over the next two weeks.

MySQL Stored Procedures

August 26, 2010

In the book I’m currently writing, “Effortless E-Commerce with PHP and MySQL”, I’m using stored procedures for one of the two e-commerce sites being developed. Stored procedures, in case you’re not familiar with them, are blocks of code stored in the database. You can kind of think of them like defining your own functions in PHP, although I have to be careful in saying that as MySQL also supports stored functions, which are different in usage than stored procedures, but the premises are similar.

I’m using stored procedures for two reasons. First, they’re more secure, as they hide database details and create an interface that makes it impossible for hackers to adversely manipulate the database. Stored procedures also use a different permissions system, which is an added security benefit. Second, in the book’s example site, I use somewhat of an MVC (Model-View-Controller) approach, separating the data (MySQL), the visual interface (HTML), and the logic (PHP). (To be clear, the site does this without using Object-Oriented Programming or a framework.) The MVC design creates very clean, autonomous files (for example, there’s not an iota of HTML in the PHP scripts and the only queries run are along the lines of CALL stored_procedure_name()). Furthermore, the MVC-based site should scale well, as you can throw server resources at just the parts that need the most help. You can also apply specific caching techniques to each part of the equation.

I first wrote about stored procedures in the second edition of my MySQL: Visual QuickStart Guide, published in 2006, so some extra research was in order on what has changed since then. Along with the MySQL manual, I read a fair amount of MySQL Stored Procedure Programming by Guy Harrison and Steven Feuerstein. It’s a good book that I’d easily recommend (although it also came out in 2006). One of the book’s strengths is that, in the process of discussing stored procedures, it does an excellent job of explaining some of the internals as to how MySQL works. This includes discussions of optimizing any SQL query you might use, whether inside of a stored procedure or not (because the first way to optimize a stored procedure is to optimize the queries it runs).

I was also pleasantly surprised to find how efficiently stored procedures execute in today’s version of MySQL. Stored procedures were notoriously slow when they were first added to MySQL in version 5. But in tests on my computer (running MySQL 5.1.37), stored procedures executed from the command line often ran ten times faster than the procedure’s queries on their own. This is due to how MySQL caches stored procedures, no doubt. When the procedures were run from PHP scripts, the performance difference was even greater (in part because there’s less actual data for the PHP script to send to the database). So along with improved security and data separation, stored procedures today can offer a significant performance benefit.

This all comes at a cost, of course. Stored procedures put a lot more load on the database. Generally I’m an advocate of using the database server as much as you can, but you’d have to be aware of the potential that the database server becomes the bottleneck in your Web site. Second, to create and execute stored procedures, you’ll need a MySQL user with permission to do so.

If you’re not familiar with stored procedures, check out the MySQL manual, the aforementioned book, or search online. Or if you wait a couple of months, you can see them in action in my new e-commerce book!