• About This Newsletter
• What Were You Thinking? => Ajax and Search Engines
• On the Web => My Web Host, ServInt
• On the Web => 37 Tested PHP, Perl, and JavaScript Regular Expressions
• On the Blog => Review of “Technical Blogging” by Antonio Cangiano
• Q&A => Have You Changed Your Opinion of OOP?
• Q&A => Why does false equal 0?
• Larry Ullman’s Book News => “PHP Advanced and Object-Oriented Programming

About This Newsletter

So, in case you hadn’t noticed (or are new to the newsletter), it now has a new template. It’s a bit more involved than the previous template (two columns instead of just one), but is simpler in other ways, too. The new look will more closely match the updated scheme for LarryUllman.com, whenever I get around to putting that online (aka, July). Basically what I’m going with for the updated site is a white background, minimum of images, blue for headings, and, above all, a clear presentation of content.

To create this newsletter template, I used the template builder from Campaign Monitor, whom I use for these newsletters. Campaign Monitor costs me $30/month (US), but I really think it’s worth it. They have a good product, and the user interface they’ve created is tremendous. In any case, I’m hoping that since I used their system, the resulting template will look reasonably good on most systems and devices.

As always, questions, comments, and all feedback are much appreciated. And thanks for your interest in what I have to say and do!

What Were You Thinking? => Ajax and Search Engines

In my previous newsletter, I answered a question about making Ajax-derived content available to search engines. Yogesh was kind enough to share a link at Google Developers in which Google explains what else you can do to make Ajax-derived content indexable. Thanks, Yogesh!

On the Web => My Web Host, ServInt

Since I’m dishing out accolades (e.g., Campaign Monitor), I’d like to recognize the company I use for Web hosting: ServInt. I’ve been using ServInt for my Web hosting for almost five years now and I’m so, so happy with their service. They only provide Virtual Private Servers (VPS) and dedicating hosting, so ServInt is not for everyone. But I think their packages are reasonably priced and their customer service is excellent. Their customer service is excellent! I’m paying $50 (USD) per month and am happily doing so. I have complete control over my little area of the server and don’t have to worry about what someone else might have done that would bring my site down. I have a few sites on the server, which garner between 500,000 and 1 million page views per month, and the lowest-level Essential VPS setup handles that easily.

There are two reasons I’m mentioning ServInt now. One is that I get asked this question a lot. Although if you’re not interested in a VPS account, these companies have also been recommended in my forums:

• Dreamhost
• HostDuplex
• HostGator

Besides letting you all know about a good hosting company, if you’re looking for one, I wanted to thank the people that have used me as a reference when creating his or her own account with ServInt. I don’t know who has done so, but a couple of people have signed up with ServInt and mentioned me in the past few months, which gives me a small credit on my account. Thanks for that!

On the Web => 37 Tested PHP, Perl, and JavaScript Regular Expressions

Some time ago I stumbled upon 37 Tested PHP, Perl, and JavaScript Regular Expressions. This is just a list of 37 Perl-Compatible Regular Expressions (PCRE) that you can use for common purposes: credit card numbers, dates, postal codes, URLs, email addresses, and more. A good resource to have around!

On the Blog => Review of “Technical Blogging” by Antonio Cangiano

I just recently reviewed the book “Technical Blogging” by Antonio Cangiano. It’s a very good book, and one that I’m happy that I read. For more, check out the review on my blog.

Q&A => Have You Changed Your Opinion of OOP?

In response to my previous newsletter, Marten asked if I have changed my opinion about procedural vs. object-oriented programming. I suspect the question was raised in part because I’m currently working on “PHP Advanced and Object-Oriented Programming: Visual QuickPro Guide“. This is something I’ve discussed in the past, and am happy to go through again. The short answer is no, I have not changed my opinion. And here is what that opinion is:

Procedural programming is better in some situations and OOP is better in some situations.

This is an interesting debate, because PHP is one of the few programming languages that allows you to work procedurally or objectively. You can’t do procedural code with Java, JavaScript, or Ruby, and you can’t use objects with C. In PHP, you can choose to use objects or not use objects.

As for myself, obviously if I’m using JavaScript, Ruby, or ActionScript, I’m going to use objects. If I’m doing C, I’m not. On some PHP projects, I’ll use procedural code. On other PHP projects, I’ll use objects. Obviously any project I do that uses the Yii framework will use objects, as most frameworks are OOP in nature. So I’m totally comfortable with both approaches and I have no preference for one over the other, I always just try to choose the right tool for the job.

That, of course, is what we should all be doing as developers. There are very few absolutes when it comes to programming; there’s mostly just opinions. I’m sure that part of the reason it may have seemed like I didn’t care for OOP is that I don’t care for the presumption that OOP is better than procedural programming. OOP has its strengths and weaknesses, as does procedural programming. One is not categorically better or worse than the other. In PHP, which allows for both, there’s a very strong argument to being comfortable with both approaches so that you, too, can choose the right tool for each job.

This belief of mine also applies to frameworks. People who are really intro frameworks sometimes assert that programming with frameworks is vastly superior. It’s not. Not all the time, that is. For some developers, with some projects, a framework is the better choice. For some developers, with some projects, a framework would be the worse choice.

I like analogies, so I’ll end this with one: I like tools, I like working around the house and being handy. I have probably about 30 screwdrivers and four electric drill/drivers, including a relatively new, and quite powerful, impact driver. The analogy is that this impact driver (OOP) is the better way to drive a screw, but that’s patently false. The driver was much more expensive than any screwdriver, and it’s much heavier, and I need to go looking for the right bit, and I need to keep the batteries charged. And aside from all that, if I had to put a small screw into the back of a picture frame, the impact driver would be a terrible choice. But the same goes for the screwdriver (procedural): if I had to drive a three-inch lag bolt into a post, trying to do that with a screwdriver would be a decision I’d regret for a long, long time.

Do away with the assumptions, learn as much as you can, and always try to choose the right tool for the job.

Q&A => Why does false equal 0?

Matti sent me this question via Twitter, specifically wondering what the difference is between 0 and 1 and true and false in PHP, and why false equals 0. This is a common point of confusion and cause of many bugs. However, the issue isn’t with the differences between these values but rather with how conditionals are evaluated and what equality is.

When you write any conditional in PHP, PHP needs to determine whether that conditional is true or false. For many conditionals, such as comparison, it’s pretty easy to identify true/false: is $x greater than 5 or no? Other conditionals are more subjective, though, and the language needs to define its rules for these situations. For example, if ($x) {. Is that conditional true or false? Well, it depends upon the value of $x, of course.

Obviously, if $x has a value of true, then the conditional is true. The same goes for $x having a value of “something”. It’s also pretty easy to decide that null is going to be treated as false. Things get tricky, though, when you have values such as 0 and an empty string. If $x = 0;, then should that conditional be true or false? The variable has been deliberately assigned a value, but the value is 0. Again, these are the kinds of choices that creators of a language have to make. In PHP, 0, an empty string, false, and null are all considered empty values, which get evaluated as false when used as the basis of a conditional.

Similarly, language designers have to make decisions as to what constitutes equality. If you compare two values of the same type—a string against a string, a number against a number, it is again easy to evaluate equality. It gets complicated when you compare values of different types: if (2 == "2"). That conditional compares the number 2 against the string “2″. These two values are not identical because of their different types, but are they equal?

To compare two different types, languages have to cast (i.e., forcibly convert) one type to the other. Generally, casting converts a value down to a simpler type. In that conditional, PHP will convert the string “2″ to its numeric equivalent, which is 2. When you compare a Boolean against a non-Boolean, the non-Boolean has to be casted to a Boolean. As we’ve already seen, the empty values are treated as false in a conditional, so those values—0, an empty string, null, and false—are cast to the Boolean false. Hence, 0 does equal false.

Fortunately, programming languages tend to be pretty consistent in what gets treated as false (JavaScript also equates 0, an empty string, null, and false). The bugs arise in situations where your code tests for “truthiness” when it shouldn’t. For example, the conditional if ($x) { is fine unless one of the empty values is a valid value for $x. If it’s okay for $x to have a value of an empty string, you’d need to change your conditional accordingly. In PHP, the empty() function can discern between a variable just being set (i.e., assigned a value), and having a non-empty value. As another example, the strpos() function in PHP looks for a needle in a haystack, returning the starting indexed position where the needle is found. If the needle is found at the very beginning of the haystack, then the function will return 0. If you were to do this, you’d have a bug:

if (strpos($haystack, $needle)) {

The assumption is that the condition will be true if the needle is found in the haystack, but as written, the condition will only be true if the needle is found in the haystack but not as the first thing in the haystack. The proper way to write that conditional is:

if (strpos($haystack, $needle) !== false) {

Also note that it’s an identity comparison to false, because using != contains the same bug, as 0 does equal false.

Thanks to Matti for the good question. I hope this has clarified the issue and please, anyone, let me know if you have more questions or comments about this or similar matters.

Larry Ullman’s Book News => “PHP Advanced and Object-Oriented Programming”

First, I continue to receive a lot of positive feedback on the “Modern JavaScript: Develop and Design” book, which makes me very happy. I’ve posted a couple of the comments on my Web site, and currently the book has received five reviews on Amazon, all for five stars. The book seems to be selling well, too, which is great, but knowing that I was able to do what I set out to do—and that my intention actually did match up with what readers wanted—is paramount. My continued thanks to everyone for their interest in the book and for the nice words on it.

Right now, I’m continuing to chug away on the third edition of my PHP advanced book, titled “PHP Advanced and Object-Oriented Programming: Visual QuickPro Guide“. I’ve written four chapters thus far and hope to get another two written before I head off to Istanbul (in 10 days!).

To be clear, layouts are a type of View file. Specifically, whereas other View files get placed within a directory for the corresponding Controller (i.e., the SiteController pulls from views/site), layout files go within views/layouts. But while the other View files are associated with individual Controllers (and therefore, individual pages), layouts are communal, shared by all the pages. Simply put, a layout file is the parent wrapper for the entire site’s templating system. I’ll explain…

The Premise of Templates

When you begin creating dynamic Web sites using PHP, you’ll quickly recognize that many parts of an HTML page will be repeated throughout the site. For example, the opening and closing HTML and BODY tags. Even the site you’re looking at now has repeating elements: the header, the navigation, the footer, etc. To create a template system, you would pull all of those common elements out and put them into one (or more) separate files. Then each specific page can include these files around the page-specific content:

include('header.html');
// Add page-specific content.
include('footer.html'); 

This is the approach I would use on non-framework-based sites. It’s easy to generate and maintain. If you need to change the header for the entire site, you only need to edit the one file.

Templates in Yii

When using a framework, you’ll probably end up with a “bootstrap” approach, where all of the pages are accessed through one file. In the case of Yii, that bootstrap file is index.php. Part of its job is to manufacture the necessary HTML for the requested resource. Whereas the non-framework approach pulls the template files into the page-specific file, Yii pulls all the files from includes and assembles them together. Of these files, the layout files constitute all the common elements; everything that’s not page-specific. If you look at a Yii-generated site, you’ll see that views/layouts/main.php begins with the DOCTYPE and opening HTML tag, then has the HTML HEAD and all its jazz, then starts the BODY, and finally has the footer material and the closing tags. In the middle of the body of the code, you’ll see this line:

<!--?php echo $content; ?-->

This is a magic line as it pulls in the page-specific content. If the site you’re looking at now used Yii, the value of $content would be all the HTML that makes up this post you’re reading. For a Yii example, when the user is looking at site/login, the SiteController‘s actionLogin() method will be called. That method will render the views/site/login.php View page, pulling that file’s contents into the main layout file at that echo $content location. That’s what’s going on behind the scenes.

So here, then, is the first key concept: if you want to change the general look of your Web site, edit the layout file (views/layouts/main.php). If you were to take your HTML mockup for your site, drop in the echo $content; line at the right place, and save it as views/layout/main.php, you will have created a custom look for your Web app. That is the basic principle and it’s essentially that simple.

To take layouts a step further, many sites will use variations on a theme. For example, the first Yii-based site I created used one header for the home page and another header for other pages, with all the remaining common elements being consistent. Or, I worked on an e-commerce project where one category of products used layout A and another category used layout B. If you have this need, there are a couple of ways of going about it.

Creating a Second Layout

The first and most obvious route is to create a second layout file. In the example where the site’s home page used a variation on the template, I created views/layouts/home.php. It was based upon main.php, with the necessary edits. To dynamically switch layouts, I changed the value assigned to the layout property within the proper Controller method:

// protected/controllers/SiteController.php
public function actionIndex() {
    $this->layout = 'home';

And that’s all there is to it. When views/site/index.php would be rendered, it’d use the views/layouts/home.php template.

Although this approach is easy to understand and implement, it has a downside: a LOT of HTML is being repeated between the two layout files. If I needed to change the navigation, I had to edit both files in the same way. This leads us to option B.

Hijacking the Content

More recent versions of Yii will automatically create three layout files when you create a new Web app:

• views/layouts/column1.php
• views/layouts/column2.php
• views/layouts/main.php

Although all three are layout files, you don’t have three different template files. The main.php file still creates the DOCTYPE and HTML and HEAD and so forth. The column1.php and column2.php files simply create variations on how the page-specific content gets rendered. These files do so by hijacking the layout process. For example, here is the entirety of column1.php:

<!--?php $this--->beginContent('//layouts/main'); ?></pre>
<div id="content"></div>
<pre>
<!-- content -->
<!--?php $this--->endContent(); ?>

Again, you have the magic echo $content line there, but all column1.php does is wrap the page-specific content in a DIV.

The column2.php file starts off the same, but adds another DIV (which includes some widgets) before $this->endContent():

<!--?php $this--->beginContent('//layouts/main'); ?></pre>
<div class="span-19">
<div id="content"></div>
<!-- content --></div>
<div class="span-5 last">
<div id="sidebar"><!--?php  $this--->beginWidget('zii.widgets.CPortlet', array(
 'title'=>'Operations',
 ));
 $this->widget('zii.widgets.CMenu', array(
 'items'=>$this->menu,
 'htmlOptions'=>array('class'=>'operations'),
 ));
 $this->endWidget();
 ?></div>
<!-- sidebar --></div>
<pre>
<!--?php $this--->endContent(); ?>

The trick here is the call to beginContent(). Remember how the layout file echoes the page-specific content in the correct place? Well, this call to beginContent() says that we’re about to start rendering the content. The method is provided with the primary layout file to use as the parent (i.e., the layout that encapsulates this content). All that’s happened here is that the content has been hijacked and replaced with slightly modified content. So the content in views/site/login.php gets pulled into column.php, where it’s wrapped within other content, and the combination of that content gets passed to main.php.

There are two tricks to this: first, beginContent() must point to //layouts/main.php. (The // just says to start in the Views directory.) Second, the layout that the Controller thinks it’s using is column1.php, not main.php. I personally think this approach is a bit complicated, particularly for the Yii newbie (yiibie?), but it is useful in situations where the content around the page-specific content needs to be adjusted dynamically.

If you were to open components/Controller.php, you would see this line:

public $layout='//layouts/column1';

That one line says that all Controllers (which inherit from Controller) will use column1.php as its layout. If you were to change this one line to column2, then all Controllers would use that as the default layout. If you were to change this one line to main, then all Controllers would use main.php as the default layout, without the intermediary column layouts.

Again, this is a bit more convoluted than is healthy for newbies, but layouts are just wrappers to page-specific content, whether you use a single layout or intermediary layouts such as column1 and column2. If you’d like a visual representation, there’s a useful image provided among the comments in this article.

Quick Guide

To summarize what’s been covered here…

To change the entire look for the entire site, edit layouts/main.php, but be sure to use the echo $content line where appropriate.

To change the default layout for every Controller, edit this line in components/Controller.php:

public $layout='//layouts/column1';

To change the default layout for every View in an individual Controller, add this line to that Controller’s definition:

class SiteController extends Controller {
public $layout = 'column2';

To change the layout used for a single action, add this line to the corresponding action:

// protected/controllers/SiteController.php
public function actionIndex() {
    $this->layout = 'home';

And remember that column1.php and column2.php just hijack the page-specific content before it gets passed on to the main.php layout file.

I hope this post has been helpful and let me know if you have any questions or problems with layouts in Yii. (And by the way, if you like this post, I’m going to be writing a book on Yii later this summer. Subscribe to my newsletter or follow me on Twitter to stay tuned!)

Short Array Syntax

Historically in PHP, on used the array() function to create a new array, as in:

$empty = array();
$numbers = array(1, 2, 3, 4);
$states = array('AL' => 'Alabama', 'AK' => 'Alaska', 'AZ' => 'Arizona');

PHP 5.4 now has the short array syntax, which just replaces calls to array() with the array operator:

$empty = [];
$numbers = [1, 2, 3, 4];
$states = ['AL' => 'Alabama', 'AK' => 'Alaska', 'AZ' => 'Arizona'];

This is all good and fine, and matches what you might be doing in other languages (such as JavaScript), but remember that you can only do this as of PHP 5.4. This means that unless you know that any server you’ll be using your code on, now or in the future, must be running PHP 5.4 or later.

<?= Always Available

In previous versions of PHP, if the short open tags setting was enabled, you could do this shortcut to print the value of a variable:

<?=$some_var; ?>

Most commonly you’ll see this when using frameworks and templating tools. As of PHP 5.4, this is now always an option, even if short tags are disabled. The only thing to be careful of with this syntax is that it assumes that $some_var has a value.

Built-in Web Server

In my opinion, the coolest addition is the built-in web server in CLI mode. In fact, I’ve already written about it in Chapter 12 of the third edition of my “PHP Advanced: Visual QuickPro Guide“, which I’m currently writing. PHP’s command-line interface (CLI) mode allows you to run PHP commands and PHP scripts from the command-line interface. As of PHP 5.4, that command-line tool also has a basic Web server that can be enabled, letting you test PHP scripts in a Web browser without using Apache or IIS or another Web server application. In short, it just became a bit easier to quickly test some PHP code.

The session_status() Function

PHP 5.4 introduces some new functions, constants, classes, and methods, but the one that most piques my interest is session_status(). This function returns a constant indicating the current session status:

• PHP_SESSION_DISABLED if sessions are disabled.
• PHP_SESSION_NONE if sessions are enabled, but none exists.
• PHP_SESSION_ACTIVE if sessions are enabled, and one exists.

I haven’t played with this yet myself, but imagine it could be a useful debugging tool, at the very least.

Removed Features

Finally, you should be aware that PHP 5.4 has removed several features that have been deprecated for some time. Off these, three are important (in that they used to be important):

• Safe mode is no longer supported
• Magic Quotes does not exist (and the get_magic_quotes_gpc() function always returns false)
• The register_globals directive has been removed

With these three changes, you can officially no longer use features that you hopefully stopped using a long, long time ago.

So there you have the key changes in PHP 5.4, aside from some of the more esoteric things. The changes here aren’t nearly on the same scale as those introduced in PHP 5.1 (e.g. PDO extension enabled), 5.2 (e.g., Filter and JSON extensions enabled), and 5.3 (e.g., namespaces and closures, the Fileinfo extension, the INTL extension), but it’s good that a language that’s been around for so long continues to get tweaked, even in minor ways. Makes you wonder what’s left for PHP 5.5, let alone 6, though?

In versions of PHP prior to 5, in order to change the values of array elements within a loop, you had to do this:

foreach ($array as $key => $value) {
    $array[$key] = "some updated $value";
}

Just changing the value of $value within that foreach loop had no impact on the actual array element, as the loop only received the value of each array element, not the actual element itself.

This doesn’t come up often—if I need to change the elements in an array, I’m likely to use array_walk(), but it’s nice to know that in PHP 5 you can pass array values by reference in a foreach loop, so that changing the value within the loop actually changes the array:

foreach ($array as &$value) {
    $value = "some updated $value";
}

As you can see there, prefacing $value by & means that the variable is passed by reference, not by value, just as you’d have in a function parameter.

Again, perhaps this isn’t a life changing thing to learn (okay, it isn’t), but it’s interesting to know. As I continue to work my way through the PHP manual (again!), I’ll continue to share interesting little tidbits I’m finding, or discovering anew.

As for my schedule, I’m now writing the third edition of my “PHP 5 Advanced: Visual QuickPro Guide” book. That project will take the next couple of months, through June. I’m hoping it will be entirely done (rewrites and all) in early July. I think I’ll have a decent-sized Web project to do in the fall, but other than that, I have no deadlines and obligations for the latter half of 2012. Little things will no doubt come along, but this kind of free time is unusual for me. (And, strangely, isn’t frightening at the moment, although free time come January could be a problem!) So, reasonably speaking, I will be able to work on the Yii book full time as of August 2012. This should coincide nicely with the hopeful release of Yii 2.0 over the summer. Speaking of which…

I’ve been chatting with Qiang Xue, the creator of Yii, and he has graciously offered to act as the personal tech editor for the book. This is a great honor to me, and will be a wonderful asset in making sure the book is as technically accurate as possible. In return, I’m going to help with some of the official Yii documentation (it’s the least I can do). And the good news keeps rolling in, as Alex Makarov, author of the popular Yii 1.1 Application Development Cookbook (Packt Publishing), has generously offered his assistance, too. These are invaluable pieces that are coming together nicely here.

In terms of publishing, my current plan is…

• To self-publish an ebook only. I will release it in mobi, epub, and PDF formats, without any annoying Digital Rights Management (DRM).
• Possibly no DRM.
• Probably no DRM.
• The price would be about $15 (USD).
• People would be able to buy the book in advance, and get each chapter as I write it. Revised chapters would be free updates.
• People would be able to buy just a single chapter and get revisions of that chapter as free updates.

I’m assuming that I’ll create a separate Web site for the book, as I’m also planning on making some of the book’s content freely available in HTML format. This does mean that along with writing the book, I’ll have to create the Web site and the above functionality, but such are the costs of doing things yourself. And I happen to know of a framework that makes Web development a lot faster…

I’ll continue posting updates here and on Twitter (by the way, I’m on Twitter @LarryUllman) as I have them. Yii postings may be sporadic for the next couple of months as I focus on the PHP Advanced book, but rest assured the Yii book is happening.

All thoughts, feedback, input, and offers of money are most welcome!

The posting ends with the most important security fact:

Remember, the most dangerous kind of security is a false sense of it. Thinking you’ve made your application more secure, when in fact you’ve weakened it, is the worst thing you could possibly do.

The previous edition had 14 chapters, plus two that were made available as free PDFs (one on image generation, the other on PDF generation). The current plan for this edition is to cut four chapters, add four entirely new chapters, and the add and remove some chapter sections here and there. The book will also have a “Review and Pursue” section at the end of each chapter, with review questions and pursue prompts.

My goals for this edition of the book were (in no particular order):

• Emphasize and expand the OOP sections
• Add more content geared towards creating larger, more elaborate, professional Web applications
• Add new content based upon changes in technologies since the last edition (specifically changes in PHP from version 5.2 to 5.4)
• Update outdated content (including replacing old approaches with entirely new ones)
• Removing no longer critical content
• Removing content now discussed in other books of mine

For example, new PHP features that will be covered include type hinting, the Nowdoc syntax, and traits. New Web application information include discussions of Apache’s mod_rewrite and phpDocumentor, and a chapter on debugging tools, unit testing, and improving performance. The expanded OOP material includes a chapter on design patterns and a new chapter that creates a whole example using OOP.

With all that in mind, the initial Table of Contents is posted below. New content is in green. Chapters I’ve cut (not reflected below) include one on security techniques (now well covered by my other books), another on e-commerce (I’ve since written awhole book on that), the PEAR chapter (replaced by one on the Zend Framework), and the Ajax chapter (well covered in many of my other books).

If you have any thoughts or suggestions, I’d love to hear them. Thanks!

• Chapter 1: Advanced PHP Techniques
  • Multidimensional Arrays
  • Advanced Function Definitions
  • Type Hinting
  • Anonymous Functions
  • The Heredoc and Nowdoc Syntax
  • Using printf() and sprintf()
• Chapter 2: Developing Web Applications
  • Modularizing a Web Site
  • Improved SEO with mod_rewrite
  • Affecting the Browser Cache
  • Better Documentation with phpDocumentor
• Chapter 3: Advanced Database Concepts
  • Storing Sessions in a Database
  • Working with U.S. Zip Codes
  • Creating Stored Functions
  • Displaying Results Horizontally
  • Storing Binary Data
  • Using PDO
• Chapter 4: Debugging, Testing, and Performance
  • Debugging Tools
  • Unit Testing
  • Profiling Scripts
  • Improving Performance
  • Implementing Server Caches
• Chapter 5: Basic Object-Oriented Programming
  • OOP Theory
  • Defining a Class
  • Creating an Object
  • The $this Attribute
  • Creating Constructors
  • Creating Destructors
  • Autoloading Classes
• Chapter 6: Advanced OOP
  • Advanced Theories
  • Inheriting Classes
  • Inheriting Constructors and Destructors
  • Overriding Methods
  • Access Control
  • Using the Scope Resolution Operator
  • Creating Static Members
  • Abstract Classes and Methods
  • Creating Namespaces
  • Using Traits
• Chapter 7: Design Patterns
  • What are Design Patterns?
  • [[Discussion of Specific Patterns TBD]]
• Chapter 8: Real-World OOP
  • Catching Exceptions
  • Extending the Exception Class
  • Implementing MVC
  • Using the Standard PHP Library
  • OOP-based E-commerce
• Chapter 9: Example–CMS with OOP
• Chapter 10: Networking with PHP
  • Accessing Other Web Sites
  • Working with Sockets
  • Performing IP Geolocation
  • Using cURL
  • Creating Web Services
• Chapter 11: PHP and the Server
  • Compressing Files
  • Establishing a cron
  • Scheduling Tasks on Windows
  • Using PHP’s Built-In Server
• Chapter 12: PHP’s Command-Line Interface
  • Testing Your Installation
  • Executing Bits of Code
  • Creating a Command-Line Script
  • Running a Command-Line Script
  • Working with Command-Line Arguments
  • Taking Input
• Chapter 13: XML and PHP
  • What Is XML?
  • XML Syntax
  • Attributes, Empty Elements, and Entities
  • Document Type Definitions
  • Parsing XML
  • Creating an RSS Feed
  • XML Error Handling
• Chapter 14: Using the Zend Framework
  • Installation
  • Creating and Validating Forms
  • Adding Captcha
  • Implementing Authentication
  • Using Zend_Mail

• On the Web => Follow Me on Twitter! Redux
• On the Web => Three JavaScript Articles I wrote
• On the Blog => MAMP without MAMP
• Q&A => Can I Make a Living as a Writer?
• What is Larry Thinking => Competing for Work
• Larry Ullman’s Book News => “Modern JavaScript: Develop and Design” and “PHP 5 Advanced: Visual QuickPro Guide” (3rd Edition)

On the Web => Follow Me on Twitter! Redux

To reiterate something I said in the previous newsletter, I am now officially on Twitter. You can follow me using @LarryUllman. In the three-ish weeks since I started using it, I’ve only sent out maybe a dozen group tweets (not counting the ones directly to specific people), but at least there have been no “I am now having a sandwich.”-type tweets. Not by me anyway.

So far, a nice ego bump when it comes to Twitter is seeing people mention me (yes, yes, I am an idiot regarding Twitter; I didn’t know about that aspect at all). The annoying and stunning thing is that I’m occasionally getting hit up for technical support. It really quite amazes me that one would think I could provide free, instant tech support, and within 140 characters! Of course, I’m happy to provide free tech support, which is why I created my support forums, but I just don’t think Twitter is the best medium for it.

On the Web => Three JavaScript Articles I Wrote

In support of my “Modern JavaScript: Develop and Design” book, I wrote three articles to be published online by Peachpit Press. All three are now available:

• The Five Biggest JavaScript Misconceptions
• The 10 Best JavaScript Development and Design Habits
• 5 Ways to Improve Your Ajax Performance

The articles don’t require that you have the book. And, of course, they’re free, so check them out when you get the chance. Thanks!

On the Blog => MAMP without MAMP

For a couple of years now, I’ve used, and advocated using, the MAMP application as the easiest way to run a Web server on a Mac. I’ve started to change my thinking about that, as discussed in a recent blog post.

Q&A => Can I Make a Living as a Writer?

“Can I make a living as a writer?” is one of the more common questions I get, and one I never mind answering. Both Helmut and Scott recently asked me about the logistics of being a writer, so it seems like a good time to rehash the topic.

In terms of hard numbers, how lucrative writing a book is all depends upon how well the book sells. As a reasonable basis number, assume you can get $10,000 (USD) to write a book, which is the advance. Some publishers will pay more, some will pay less. It also depends upon who you are and what the book is. But $10,000 is fair. And that money is yours to keep, no matter what happens (assuming you complete the book to the publisher’s satisfaction). If you can write two books per year, that’s $20,000. If you can write three, that’s $30,000. In the past, there have been years in which I wrote three books in a single year, and it’s really hard to do, not just because you have to have three good ideas and enough expertise on three subjects, but because writing a single book is quite draining.

Added to that, write an article a month, just to get some extra income and to help promote the books. Let’s say you’re paid $500 each for those. Most of the articles I write pay less than that, but the occasional article pays dramatically more. One article per month at $500 per is another $6,000. Keep in mind that, as with the books, you have to have the ideas, have the knowledge, and then put forth the effort to get someone to buy the article. That’s all time consuming, but the actual act of writing an article isn’t that hard. It’s really just a professional blog posting.

So now, with a fair amount of work and effort, you’ve managed to bring in $26,000. At least in the United States, from this income you have to pay all the taxes and such, so the actual net may be more like $20,000. Does that constitute a living for you? I’m sure some of you would be losing a lot of money to take that deal and others would be fine with it. But I think that’s what you could reasonably expect as a bottom line if you’re a good writer and put in the necessary work. The other end of the spectrum depends upon how well your books sell.

A good seller in computer books is around 10,000 copies. Different titles have different expectations, but my understanding is that if you sell 10,000 copies, you’ve done well. This number varies greatly, but a decent expectation is that you, the writer, will make $2 per copy sold. If you sell 10,000 copies, that’s $20,000 on that one book. Minus the $10,000 advance, there’s another $10,000 for you. But that $10k will be spread out over some years. In my last statement, I received $11.19 in royalties for my first book published over a decade ago (with three new editions since then). The best part is that you’ve done no extra direct work for that money above and beyond the advance, but you can’t count on it, and you’ll likely have to do a lot of marketing work to help make that happen. Still, by earning advances for writing new titles and hopefully getting royalties on existing titles, you might be able to bring your total yearly writing income up to $30,000 to $40,000. Eventually.

In terms of harder numbers, you could probably consider me to be fairly successful as a computer writer (I mean in terms of actual sales, not necessarily the quality of the books, which is a different criteria). My first book came out almost exactly 11 years ago and I’ve now written 22 books, including revisions. I’ve sold approximately 325,000 copies in sum, for approximately $577,000. That may seem like a grand sum of money (and, to be clear, I’m happy to have earned it), but that’s over 11 years, which is about $52,000 per year during that time. Again, many of you would probably be thrilled with that number (and I’m okay with it), but remember that taxes have to come out of that and I get no benefits whatsoever. In the United States, benefits are normally estimated to be equivalent to the salary itself (i.e., if you’re being paid $40,000 per year, the company is probably spending another $40,000 for your retirement, medical, and other benefits). So one could look at that $52,000 per year as really being more like $26,000 per year, gross, plus benefits. And, again, I do fairly well for a writer. I’ll add that I’m just starting to make money through my blog, but right now that’s a few hundred dollars per year. Perhaps one day I’ll get that to a few hundred dollars a month, but I don’t envision this avenue to be a significant form of income.

There are some very hard numbers for what it might mean to make a living as a writer. For some people, the idea of making, say, $30,000 to $40,000 (USD) per year as a writer would be great. And there are intangible benefits. I work for myself, at home. I don’t commute. I don’t do many meetings. I learn and write about things I’m interested in. And there’s a lot of flexibility in my schedule which helps out tremendously considering the personal demands that I have. For other people, the idea of making that amount of money, with no guarantees, regular paychecks, or benefits would send them screaming to the nearest stable job.

I should add that writing does allow you to make good money doing related things. For example, I also do Web development and other programming, consulting, training, and speaking. My writing does act as a marketing agent for these avenues, meaning it’s easier for me to get work and I can charge a premium for those services.

All things considered, the general advice I have is: while it is possible to make money writing books (and/or articles), I wouldn’t recommend anyone to go into writing for that purpose. The odds of making money, let alone sufficient money, are slim. There’s a lot of competition, the publishing industry is definitely down, and the best payoffs are definitely in the long term. Also, in case I didn’t make this clear, writing a book is really quite hard. If you’re looking to go into business for yourself, there are certainly more stable, lucrative routes. It’d be much better to pursue writing only because you like to write and share what you’ve learned. And I’m not just saying that to cut down on the competition!

What is Larry Thinking? => Competing for Work

Some time back, William asked for my thoughts on how to compete for work, considering foreign competition and a tough economy. Two weeks ago, I was on the other side of the equation for the first time, as I ran a 99designs contest to have a new logo and business card created for me. I’ve been sketching out a blog posting tentatively titled “How Not To Get Work” about that experience, but I’ll toss out some thoughts here, too. (As an aside, the contest went great and I’ll post the details about it on my site soon. I got a great logo and business card, which are currently being used as the basis for a revamping of my Web site.)

This problem—a bad economy and competing with foreign developers who can offer bargain prices—is not new, although it may be new to those who haven’t been freelancing for that long. Just after I started in this line of work, the “dot com” bubble burst. At the time I was getting work through online freelancing sites like elance and guru, sometimes losing out to people that drastically undercut my price. For example, there was a big banking job that I lost out to a company in India that underbid me. That project would have been huge for me—around $22,000, I think, when I didn’t make that in a year, but on the other hand, I wasn’t really prepared or qualified to do that job at that time, so it was probably for the best. In any case, how does one compete?

In my opinion, you have to first accept two facts:

• Just because a competitor is in X country and is willing to do the job for much cheaper, it doesn’t mean that developer won’t do as good as a job as you.
• For the person buying the services, price is logical, significant factor.

I mention these two ideas because you can’t succeed if you get bogged down in excuses. The cost of living in X country may be a fraction of what it is in your country, which makes it possible for developers in X to offer what seem like cut-rate prices. But that doesn’t mean that developer can’t do the job. So the arguments for hiring you instead of those cheaper developers can’t be based upon that assumption. Second, while it is often true that you get what you pay for, it’s also true that business fail when they spend more than they have to. Accepting a cheaper bid doesn’t mean the client is cheap, it means the client is making a sound business decision (hopefully). So what can you do?

There’s only one thing you can control when competing for work: you. Focus on what you can do, not what’s wrong with the other developers or the client’s thought process. Towards that end:

• Above all, be professional in every way. Every single thing you do should demonstrate professionalism on the highest level. This includes how well you handle not getting a job. You never know: your ability to handle failure professionally may just be the reason that the client comes back to you for a future project.
• Communicate well, both in quality and in timeliness. Be prompt, responsive, and literate.
• Offer the best, most appropriate price you can. Be aware of what other prices the client may see, but base your price on what you think is appropriate for the job. Do factor in how much you need the job, how much you want the job, and so forth, but try to strike a balance between asking enough that you won’t be annoyed if you get the job while still being as affordable as you can be.
• Stress and demonstrate your less obvious strengths. While money is a mitigating factor for the client, it’s not the only one. If you can’t compete on a pure cost basis, work on other angles. For example, a developer in X country might be cheaper but may also be 12 hours away; a simple Q&A could take a whole day in that case. Or, if you will be available via IM or Skype, that’s a bonus.
• Do the work in advance. The absolute best way to demonstrate that you’re capable of doing a job, and on time, is to do the job ahead of time. My second client ever, for whom I’m still doing work, was one I got when I did a bit of JavaScript for an elance project he was hiring for. During the bidding process, as part of my bid, I linked to a page where the client could see the finished work. It was easy for that client to hire me at that point. Yes, this means I did work for free, and because it was JavaScript, anyone could have stolen my code, but I had the free time and needed the money, so I went out on a limb. I did that many times when I first started and my success rate was high because of it.

William had also specifically asked about how to convince small business owners to start or revise a Web site. I will say that I’m pretty good at convincing someone to hire me to do a project, but I have no skill when it comes to convincing someone that a project is necessary. In short, I wouldn’t have the vaguest idea how to proceed here. I would guess that it’d be more effective if you tie some of your payment into the site’s success (i.e., establish quantifiable goals that trigger payments or bonuses). That would clearly convey that you believe in the project, but it is risky.

As a final piece of advice, I’ll add that getting the job (and the money) isn’t the only benefit to be gained from trying to get work. There’s a lot to be said for the experience gained by being involved in the process. Certainly that’s a “silver lining” perspective, but if you can handle the failure to win the job, you can learn a ton from just participating. With open eyes, you can see what clients are looking for and what winning developers are doing right. In thinking about my 99designs contest, which had approximately 100 designers, about a third of the designers really didn’t have the skill set to compete. But those designers did get to see what a winning designer does, how a client behaves, and how to manage the interaction. In my opinion, that’s all quite valuable experience.

Larry Ullman’s Book News => “Modern JavaScript: Develop and Design” and “PHP 5 Advanced: Visual QuickPro Guide” (3rd Edition)

The JavaScript book is done and available at a store near you. The early reviews seem to be good, for which I’m quite grateful. I already gave away half of the copies I had to people that replied to previous newsletters, so right now I’m not planning on doing another dedicated “Modern JavaScript: Develop and Design” giveaway. I might have a couple more copies to give away later in the year. We shall see.

Next week I begin writing the third edition of my “PHP 5 Advanced: Visual QuickPro Guide”, which will come out this summer. I’m finished the new table of contents and I’ll put that online soon. The current plan is to cut four chapters that contain material since covered in my other books. I’m adding four new chapters, too:

• Debugging, Testing, and Performance
• Design Patterns
• A chapter that creates a complete example using OOP
• Using the Zend Framework

There are also some minor cuts and additions. The general thrust in this rewrite is to expand the book largely in the areas of Object-Oriented Programming and advanced Web development. The OOP additions include design patterns, implementing MVC, using the Standard PHP Library, and an example application writing in OOP. For the latter, Im specifically thinking about things like using phpDocumentor, PDO, caching, and unit testing.

If you have any thoughts or suggestions, I would love to hear them. Thanks!

PayPal’s Website Payments Pro provides two APIs for processing payments: Direct Payment and Express Checkout. Both allow you to accept debit and credit cards (the specific cards will differ slightly from one region to the next), while Express Checkout also allows users to pay with their PayPal account. In both cases, the customer never leaves your site, unlike when using PayPal’s Website Payments Standard. PayPal does require you to use both APIs in order to use Website Payments Pro. To keep this post from getting too long, I’ll only address the Direct Payment, which most easily correlates to the Authorize.net code in the book. If you need help with the Express Checkout aspect, let me know.

To understand how to use Website Payments Pro instead of Authorize.net for the second example, let’s first look at how Authorize.net is used. The customer begins the checkout process on checkout.php. This script takes and validates the user’s shipping information. Upon successful validation, the user is redirected to billing.php, which takes and validates the billing information, including the credit card. Upon successful validation, the payment is processed by including two scripts: gateway_setup.php and gateway_process.php. For extra security, these two files are stored in a private folder outside of the Web root directory.

Within gateway_setup.php, a bunch of parameters are set within an array named $data:

<?php
$data = array();
$data['x_type'] = 'AUTH_ONLY';
$data['x_card_num'] = $cc_number;
$data['x_exp_date'] = $cc_exp;
// etc. 

Then the gateway_process.php script adds some more details to the array:

// Your account info:
$data['x_login'] = '75sqQ96qHEP8';
$data['x_tran_key'] = '7r83Sb4HUd58Tz5p';
// etc. 

Finally, gateway_process.php converts that data into a useable format for the cURL request, performs the cURL request, and reads the response into the $response variable. Finally, this variable is converted into an array:

$response_array = explode($data["x_delim_char"],$response);

That’s the end of the gateway_process.php script. The script that invokes it—billing.php—will then use $response_array to take the next logical steps.

In order to switch the payment gateway in use, you must replace the code in gateway_setup.php and gateway_process.php. This is much easier than you might think. For PayPal’s Website Payments Pro, you’ll need to change the code in those two files so that instead of creating, for example, $data['x_card_num'], it creates $data['ACCT']. The proper values and their meanings can be found in the PayPal documentation.  This means that gateway_setup.php would contain:

<?php
$data['PAYMENTACTION'] = 'Authorization';

// Billing info:
$data['ACCT'] = $cc_number;
$data['EXPDATE'] = $cc_exp;
$data['CREDITCARDTYPE'] = $cc_type;
$data['CVV2'] = $cc_cvv;
$data['FIRSTNAME'] = $cc_first_name;
$data['LASTNAME'] = $cc_last_name;
$data['STREET'] = $cc_address;
$data['STATE'] = $cc_state;
$data['CITY'] = $cc_city;
$data['ZIP'] = $cc_zip;
$data['COUNTRY'] = 'US'; // Or other, if accepting international orders.
$data['IPADDRESS'] = $_SERVER['REMOTE_ADDR'];

As in the book, these orders are being authorized first and captured later. The actual transfer of funds takes place in a second step, when the order ships. For simplicity sake, you could change the PAYMENTACTION to Sale, assuming that would be appropriate (and legal) in your situation. PayPal also wants you to pass along the customer’s IP address, for fraud prevention purposes. And you’ll need to get the credit card type from the user, which isn’t requested in the book’s original code.

Next, gateway_process.php needs your own information:

// Your account info:
$data['SIGNATURE'] = 'your API signature';
$data['USER'] = 'your API username';
$data['PWD'] = 'your API password';

This information will be determined when you sign up for Website Payments Pro with your PayPal business account.
Next, there’s the payment gateway stuff:

// PayPal Website Payments Pro Stuff:
$data['VERSION'] = '85.0';

// Transaction stuff:
$data['METHOD'] = 'DoDirectPayment';

And then there’s the order information:

// Order info:
$data['AMT'] = $order_total;
$data['CURRENCYCODE'] = 'USD';
$data['INVNUM'] = $order_id;
$data['CUSTOM'] = $customer_id;

The CUSTOM option lets you send your own data along, in this case the customer ID (although the customer ID could also be retrieved later via the transaction ID).

(Note: Dividing the data into these two files may seem odd, but it’s done so that the administrative side can easily use the same gateway_process.php script, after running a gateway_setup_admin.php script. If you need help with the admin process, to capture a prior authorization, let me know.)

Also, the GATEWAY_API_URL constant in gateway_process.php needs to be changed to PayPal’s proper URL: https://api-3t.sandbox.paypal.com/nvp for testing, https://api-3t.paypal.com/nvp for live purposes.

After identifying all the values, the gateway_process.php script converts that data into a string of URL-encoded name-value pairs. That does not need to be changed, nor does the cURL request made at the end of that script.

In response to the request, PayPal will return a string which contains more name-value pairs: TIMESTAMP=X&ACK=Success&VERSION=85&… This must be broken into an array:

$a = explode('&', $response);
$response_array = array();
foreach ($a as $item) {
 list($key, $value) = explode('=', $item);
 $response_array[$key] = $value;
}

This code is a bit different and more complex than the Authorize.net code, as Authorize.net only returns a string broken up by the pipe character (|). But at this point, <strong>$response_array</strong> is usable. Unfortunately, <strong>billing.php</strong> will need to be modified, because that script assumes a numerically indexed array. First, you’ll need to change the call to the stored procedure:

$r = mysqli_query($dbc, "CALL add_transaction($order_id, '{$data['PAYMENTACTION']}', $response_array['AMT'], $response_array['ACK'], '$response_array['PAYMENTADVICECODE']', $response_array['TRANSACTIONID'], '$response')");

After that code, different reactions occur based upon the success of the transaction. To check that, use $response_array['ACK'], which should have a value of Success. Other values include SuccessWithWarning, Failure, and FailureWithWarning. The response array will store the actual reasons in order elements in those situations. The unique transaction ID will be stored in $response_array['TRANSACTIONID']. This would be needed for the capture phase, if using that route. Again, if you need help with updating the admin pieces, let me know.

So that’s the gist of how you would use PayPal’s Website Payments Pro instead of Authorize.net for direct payment with the second e-commerce example in the book. As already mentioned, PayPal does insist that you create an Express Checkout process, too. It’s actually slightly simpler than this code because the user’s billing and shipping information is already stored in PayPal. To integrate this option, you’d add PayPal’s Express Checkout button to your cart.php page, and that would take the user to a different page on your site, where he or she enters his or her PayPal email address and password. This is then sent to PayPal for authorization, along with the order particulars. For more, see PayPal’s documentation.