What is Larry Thinking? #55 => Good Companies, Books, and Answers

In this edition…

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:

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!).

Series

Blog post categories

Note