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

The reason I mention Atwood’s piece is because Rands in Repose had a very nice reaction post titled “Please Learn to Write“. Maybe it’s because I am a writer, but the suggestion—Hey, if you want to improve yourself, communicate better.—rings true to me.

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

The interview is part of a new SmashingMagazine series called “How I Work”. As they describe it:

These interviews revolve around how thinkers and creators in the Web world design, code, and create. The goal is not to get into the specific nuances of their craft (as that information already exists online), but rather step back and learn a bit about their habits, philosophies, and workflow for producing great work.

For that reason, the interview is useful whether or not you do any JavaScript programming, as Crockford has great insights into programming in general. Just two things that caught my attention…

WHAT WERE THE TRAITS OF THE WEAK PROGRAMMERS YOU’VE SEEN OVER YOUR CAREER?
That’s an easy one—lack of curiosity. They were so satisfied with the work that they were doing was good enough (without an understanding of what ‘good’ was) that they didn’t push themselves.

and …

HOW MUCH OF A LANGUAGE DO YOU NEED TO KNOW?
Virtually every programming language is too big. Language standards have difficulty removing unnecessary features but as users we can choose not to use it.
I would say you can do 100% with knowing 50% of the language.

As for the first, the greatest thing about working for myself is the ability to learn whatever I want. I’m not pigeonholed into one subject or career. I can see what interests me and expand my knowledge as I see fit. (On the other hand, I’d certainly make more money if I specialized but there’s more to life than making money, they say.)

As for the second, that’s an interesting suggestion, and one I’ve not heard before. To be fair, when I write a book on a language, I have to make decisions about what to discuss and what not to (e.g., never cover goto!), but I wouldn’t have put that number at 50% or in that area. Still, it’s great that an expert on a language admits that much of it isn’t necessary, at least not most of the time.

After the interview, which isn’t too long, there are two video clips worth checking out. Both are around an hour long, but will give you a sense of what Crockford does in his Master Class videos. One of those videos, and many more, can be found in Yahoo!’s excellent YUI Theater.

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?

I started blogging relatively recently, about two or three years ago, I think. In retrospect, I’m not sure why I started blogging, as I had no game plan and no intent of making money from the blog. I suspect the impetus was supporting my books, but that’s probably as much as I thought about it. Eventually I added a single Amazon widget to my site, again as a way to promote my books. In part because of the success of my Learning the Yii Framework series, I was surprised when I started getting decent traffic to my site, and making a bit of money through the Amazon widget. To be completely transparent about the money, I make around a few hundred dollars per year with the site set up as is. I’m not quitting my day job on that, but it is enough to pay for my hosting costs, as well as my monthly newsletter, and my forum software. After seeing a mist of potential in this area, and with 2012 being the year of legitimizing much of my business, I read “Technical Blogging.”

Like any well written book, it’s well organized, broken down into five sequential parts:

• Part I — Plan It
• Part II — Build It
• Part III — Promote It
• Part IV — Benefit from It
• Part V — Scale It

In my own situation, I had already done parts two and four on my own blog, without ever giving much thought to parts one and three. Clearly, it’s hard to know if your site is succeeding when you’ve established no goals for it! And while my primary goal is to sell more books, after reading just the first part, I was able to come up with other, more immediate and tangible goals.

The book’s structure is sound, but the strength of the book is this: lots of concrete, specific advice. The book has decent breadth in the topics it covers, but always provides exact recommendations. For example, in the Build It chapter, Mr. Cangiano talks about the software and hosting options, from using WordPress to more geeky options like Jekyll. After covering the range of options, you get specific advice:

“Opt for a self-hosted WordPress installation if you are the kind of person who doesn’t mind dealing with a remote Linux box.”

and

“If you don’t have an IT background or would like to test the waters before committing to something… I recommend Blogger (from Google) due to…”

This approach—presenting the options, with pros and cons, and then making recommendations—continues throughout the book, even when it comes to the money and statistics. Mr. Cangiano explicitly talks about the hits his sites get and is bravely honest about the income, too. He discusses, for example, the effectiveness of various social media sites, and how much he earns from ads vs. Amazon referrals vs. sponsorships. Providing the details, regardless of their personal nature, makes it really easy for the reader to make his or her own decisions. For example, I don’t have any ads on my site now (a la AdSense), which is very much my preference. But I was worried that I was missing out on good money because of this value of mine. Mr. Cangiano, in a table citing his monthly income for a given month, shows that AdSense accounted for only 3% of the total. Knowing that, Mr. Cangiano has saved me from going through all the hassle of integrating AdSense, bothering viewers with random ads, only to make a smidgen of money.

The area in which I learned the most is promoting the blog via social media and other avenues, such as Reddit. All marketing stuff is foreign to me, and I’m just finally getting involved with social media. In fact, I’m in the process of creating a new theme for my site, which will more prominently feature my social media connections (and, more importantly, give more space to the content itself). Over the summer I’ll work harder to implement the social media tools, and I’ve set some goals for where I’d like to be in a year from now.

All in all, I have literally seven pages of notes that I took while reading the book. And while I’ve only begun using this new-found knowledge, I have no doubt that what I learned from “Technical Blogging” will pay off. If you do technical blogging as well, I would highly recommend it!

In the post, Berkun distinguishes between three aspects of writing a book:

• Anyone can write a book (i.e., you can write one right now, without needing anything else)
• Getting published (which is a separate issue from writing a book)
• Becoming famous and wealthy

I know there are some people that would like to write a book as an experience, or as a way of sharing what they’ve learned. And some others like the imagined prestige and riches that come with writing a book. I’ve done quite well over the past decade, having written 22 books and sold over 350,000 copies, but I can verify that the prestige and riches aren’t all that you might imagine (I recently discussed the economics in a newsletter). That being said, I’m quite happy that I’m making a decent living doing something that I always dreamed of doing. I’ve been working for myself for 13 years now, which is something.

In any case, if you’re interested in the topic, check out Berkun’s post. It’s short, and well written. At the bottom, you’ll find links to more good articles on writing, if you’re not too discouraged by that point! His “Why You Fail at Writing” is pretty good for helping you accomplish that goal of writing a book.

If you have any questions you’d like to ask me about what it means to be a writer, just let me know!

• About This Newsletter
• On the Web? => Properly Salting Passwords, The Case Against Pepper
• On the Road => Istanbul and Silicon Valley
• On the Blog => My New Logo and Business Card from 99designs
• On the Blog => Five Ways to Lose Work
• On the Blog => Yii and Me (aka, the Yii Book)
• Q&A => How Do I Make Ajax Content Available to Search Engines
• Q&A => Can You Use .html Instead of .php?
• Larry Ullman’s Book News => “PHP 5 Advanced: Visual QuickPro Guide” (3rd Edition)

About This Newsletter

To repeat what I’ve said in the past two newsletters, I am now officially on Twitter. Hopefully next month, I’ll get the Twitter “follow me” link on my main site and add it to this newsletter template. But in the meantime, you can follow me using @LarryUllman. I’m doing better about sending out tweets, and I do retweet things that I think are notable or useful. In fact, I sent out a tweet a couple of days ago asking for good newsletter questions, and I received a few, one of which I answer here. Even an old dog can learn a new trick, I guess.

Also, I would love to have more questions to answer in forthcoming newsletters. I tend to get the most questions when I do a book giveaway, and I haven’t had one of those in a while, so the well is running a bit dry.

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

On the Web => Properly Salting Passwords, The Case Against Pepper

Anthony Ferrara, creator of the PHP PasswordLib library, just recently posted a discussion of using salts and pepper to improve the security of a stored password. Mostly, the article is a discussion of why a pepper is unnecessary (and if you don’t know what a “pepper” is, just read the article), but the posting also does a good job of explaining the purpose of a salt, and why the salt does not need to be a secret. The posting is relatively short, and is something I think everyone can benefit from reading.

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.

On the Road => Istanbul and Silicon Valley

For the first time in a long time, I’m going to do some work-related traveling. I used to travel somewhat regularly for conferences and training seminars and the like. But then I had kids and other personal issues came up, so I cut back. I think the last time I travelled for work was when I spoke at a Voices That Matter conference in Nashville, TN in 2008!

My first trip is to Istanbul, Turkey, at the end of May. I’ll be speaking at the E-commerce Expo on May 30th (the site is in Turkish, so you’ll want to use a browser like Chrome that will translate the page for you). I will have about two other days to see what I can of the city, so if anyone has any recommendations of what to see and do, or where to eat, please let me know. I’ve heard nothing but great things about Istanbul and am really looking forward to it. Oh, and my speech—Building a Successful E-commerce Venture, or Failing Gracefully—should be good, too.

At the end of June, I’ll be doing two days of training on JavaScript and jQuery at the Mid-Pacific ICT Center Summer 2012 Faculty Development Week in Fremont, California. I’m tentatively thinking about making myself available for drinks or dinner on Thursday, June 28th, although I haven’t thought it through, yet. If you’re in the area and think you’d like to meet, let me know and I’ll see what makes sense from there. Thanks!

On the Blog => My New Logo and Business Card from 99designs

In March, I finally got around to having a new logo and business card created, using 99designs. It wasn’t a driving need for me, but it was about time. I wrote about the contest experience in one blog post. In another blog post, I show the end results, and also some of the terrible logos and business cards I’ve had along the way (i.e., the ones I designed).

I’ve since hired a designer to modify my CSS to use the new logo and colors. This is going to go with a new WordPress theme, which I’m hoping to get online in May. Hoping. After that I’ll also update this newsletter template.

On the Blog => Five Ways to Lose Work

In the previous newsletter, I wrote about competing for work. Getting work is a frequent topic of conversation I have with readers, and between that question, and my recent experiences with 99designs, I wrote a blog post titled “Five Ways to Lose Work”. Although some of the examples in that post come from my 99designs experience, it’s not really about 99designs, but more about the common mistakes people make when trying to get a project. My intent is that by recognizing these mistakes, you’ll be less likely to make them, and therefore have a better chance of getting work.

On the Blog => Yii and Me (aka, the Yii Book)

Many people have appreciated my Learning the Yii Framework series and are awaiting a formal Yii book written by me. This is something I have been hoping to do for sometime. It looks like that time will be the latter half of 2012. Almost definitely. In a recent blog post, I announced my current plans and thinking about the book. I was also very pleased to say that Qiang Xue, the creator of Yii, has generously agreed to act as the technical editor for the book. Now it’s just a matter of writing it!

Q&A => How Do I Make Ajax Content Available to Search Engines?

I’m digging way through the archives to find questions to answer, and I came across this one sent in by Richard back in October of 2008. It’s probably way too late to help Richard, but perhaps my answer can be of use to others. Here’s the prompt (summarized by me):

I have a discussion board that pulls posts via Ajax, which means that posts aren’t being indexed by search engines. I updated the system so that all posts are displayed by PHP, to make them search engine visible, and then use Ajax for new posts since the user got online, but are there other places where Ajax presents this sort of problem?

This brings up a very good point that every Web developer ought to be aware of. It’s obvious that if someone disables JavaScript, they can’t see the JavaScript functionality on a site. Statistically, only around 1-3% of all users have JavaScript disabled. However, all search engine bots are unable to see JavaScript-derived content. This means that all content on your site that’s created by JavaScript will not appear in search engines. This is especially ironic as many sites use JavaScript for the most important content. So what’s the solution?

The solution is actually the same solution for all JavaScript-based sites. Unless the site absolutely has to require JavaScript, you should always start with a non-JavaScript version first. A non-JavaScript version will be accessible by all search engines and by, well, anyone. The non-JavaScript version may not be pretty or cool, but it will be functional, which is most important. Then you can add the JavaScript layer to implement the cool, or more interactive, version. This process is called “progressive enhancement” and is a cornerstone of modern JavaScript, as explained in my “Modern JavaScript: Develop and Design” book.

If, for whatever reason, you don’t want to take this approach, then simply create alternative versions of your content that would be available for search engines. This could be as simple as a site map that links to non-dynamic versions of the content.

Q&A => Can You Use .html Instead of .php?

This question came in from @enxaneta_info via Twitter:

Is it possible to replace the .php extension with .html?

The short answer is yes. A file’s extension just tells the computer what application should be used to execute that file. With Web files, the extension tells the Web server how to treat that file. Normally, the .php extension indicates that the code therein should be run through the PHP module. If you wanted to use .html, you’d just need to tell the Web server to send all files with a .html extension through the PHP module. (This is done via an AddType directive in the Apache configuration file.)

One benefit of doing this is that it allows you to hide what type of server-side tool is being used. On the other hand, there is certain to be a performance hit as the Web server will send every page through the PHP module. But if you have a site that only contains PHP scripts and has no HTML files, this is a reasonable change to make.

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

I’ve formally started writing the third edition of my “PHP 5 Advanced: Visual QuickPro Guide” book. You can view the initial Table of Contents on my Web site, along with some discussion of my approach to this edition. The new edition is tentatively titled “Advanced PHP and Object-Oriented Programming: Visual QuickPro Guide”, to better reflect the book’s focus.

If you have any thoughts on the book’s table of contents, please share them on that blog posting page. As I said, I’m writing the book now, and it will be my primary focus for the next two months. Ideally the first submitted draft will be completed by the end of May (although that will be a stretch), and the book will come out by the end of summer.

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!