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

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

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!

In a recent newsletter, I answered a question about how I spend my time between projects. For me, the biggest projects I have, in terms of stress and time consumption, are the books I write. The client projects–Web development and such, no matter how big or complicated, never seem to be that much of a burden. Mostly this is because I find programming to be much easier than writing about programming, and because it’s fun to make things happen, to implement new concepts. Over the course of a year, I’ll work on any number of projects, ranging from consulting a couple of hours here or there (i.e., helping to steer the actual developers) to doing all of the development myself. When these bigger projects are done, I’m pleased to have them off of my list, but there’s never the huge sigh of relief that I have when I’ve finished a book. And that sigh says: now I can do these other 20 things that have been waiting for me!

With the completion of the JavaScript book on the horizon, I’ve been making my January to-do list, and salivating over all the things I’ll be getting done. Certainly, what I will actually do won’t be nearly as long as this list, but one can dream, no? My next deadline isn’t until this summer, which is when I have to turn in the third edition of my PHP 5 Advanced: Visual QuickPro Guide book. Although I’d like to, for a change, get that book done well in advance! Still, I have a bit of time to really put a dent in my “someday” to-do list.

First on my list is to exercise more often. I feel like I’ve gained five pounds for every book I’ve written (all that sitting), and while I’ve exercised more than never over the past few months, I’d like to do much, much better. We could all probably use more exercise!

After exercise, which is a daily and on-going goal, I’ve grouped my dream tasks into four categories:

• Things to work on
• Books to read
• Work things I really should get done
• Personal things I really should get done

The last category is of little interest to you, I imagine, or wouldn’t mean much regardless (mostly construction projects around the house). The work things I really should get done are those things that don’t get done during my books and big projects. For January, this primarily means creating an HTML5 version of this site’s design, plus a corresponding version for my forum. Before I redid this site in October of 2010, the site had become woefully outdated and I want to insure that doesn’t happen again. If time allows, I’ll do a mobile version, too, and make sure everything is performing as well as can be.

The books to read are both personal and work related. I want to read one or two parenting books, a novel, and some work-related books. I’m specifically looking to read The Pragmatic Programmer by Hunt and Thomas first. I’ve heard good things about it. Then, coincidentally, I have a couple of ebooks from The Pragmatic Bookshelf on my computer awaiting a few moments of time. As I read these, I’ll no doubt be posting my thoughts about them here.

Finally, there’s my “things to work on” category, which is a broad category of topics without definitive targets or concrete tasks. Normally these items are a matter of improving my skills in specific areas. Right now I’m thinking honing my abilities and knowledge with respect to Launchbar and TextMate, two Mac apps I use all the time. I know for a fact that I’m underutilizing both. The time I spend improving my skills with them now will pay dividends over the rest of the year. As time allows, I also plan on continuing to write my Yii book, although I’ll probably do that as blog posts, too.

So there are my January 2012 non-resolutions. Which will likely also be my February 2012 non-resolutions. Sadly, at least a quarter of them will end up on my September 2012 resolutions, too!

UPDATE: I just literally finished all the work on the Modern JavaScript: Develop and Design book yesterday, so thus far, I’ve done pretty much none of the things on my list, including exercise more. Ugh. But how about that February list…

• About This Newsletter
• What Were You Thinking? => Using JavaScript
• On the Web => Introduction to MongoDB
• On the Web => The Protocol-Relative URL
• On the Web => 10 Steps to Becoming a Great Web Developer
• On the Blog => My Yii Book Update
• On the Blog => Adobe’s Significant Flash and Flex Changes
• Q&A => How Do You Choose Between Competing Technologies?
• Q&A => How Do You Spend Time Between Projects?
• What is Larry Thinking => Starting a New Project
• Book Giveaway => “PHP and MySQL for Dynamic Web Sites: Visual QuickPro Guide” (4th Edition)
• Larry Ullman’s Book News => “Modern JavaScript: Develop and Design”

About This Newsletter

Hello, hello. Not a very cohesive theme in this newsletter, but in it, I write about: Web development technologies, how to start new projects, and how to spend one’s downtime. Oh, and there’s one of those bookgiveawaythingies that y’all like so much!

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? => Using JavaScript

In my previous newsletter, I asked for input as to how you use JavaScript, what you know you’re confused by, what you’d like to learn more about, and so forth. I received oodles of replies, which were very much appreciated. I haven’t responded to quite everyone yet, but do plan to still. And all respondents are going into a pool of candidates for a free copy of the book when I have my copies to give away (that looks like February now, or thereabouts).

The bulk of the responses emphasized that I just need to do what I do normally, but this time for JavaScript. In other words, there’s a certain way that I go about presenting technical information that seems to work for many people, and I need to be true to those inclinations. That’s quite flattering and reassuring, as I often second-guess myself when writing new books. It’s also a good reminder not to over extend myself or the book, and as I do the rewrites I’ll be certain to adjust accordingly.

I remember that when I first started writing computer books, I looked at the books that were out there, and many writers seem to want to impress the reader with what she or he (i.e., the writer) knows. Maybe wasn’t the intent, and maybe other writers just have a broader sense of what readers need to know than I do. In any case, my belief has always been that a technical book isn’t about what I know but about what you, the reader, needs to know. Further, it’s not my aim to impress you with my knowledge, but for you to be impressed by what you’ve managed to learn and do. So, as I finish the JavaScript book and perform the rewrites, this is a good reminder for me to keep the content simple (-ish), straightforward, and, above all, useful. When I question if some tip or sidebar is too advanced or unnecessary, that’s probably an indicator that it is.

A good idea that came up a couple of times is to demonstrate and discuss key JavaScript libraries. The book will already introduce some frameworks, but I think libraries merit coverage, too. I’m also now debating doing a chapter on mobile JavaScript. I’m leaning towards doing one, but am pressed for time.

Finally, a couple of people have volunteered to act as proofreaders on the book. The offer is much appreciated, and something I would have definitely taken advantage of if I was self-publishing. However, as this book is going through a traditional publisher, there are already several proofreaders involved. Adding more proofreaders might help catch a thing or two, but would further overwhelm me (it takes a lot of work to assign chapters, read feedback, and so forth) and I’m already so very behind. But I thank everyone again for their offers to help.

And my thanks once again to everyone for their thoughts and feedback. If you have any more suggestions, please keep them coming!

On the Web => Introduction to MongoDB

phpmaster recently posted an article titled Introduction to MongoDB. I’m not entirely sold on non-relational databases yet, in that while I can see how wonderfully beneficial they can be in many situations, they’re not as ubiquitously useful as all the hype would seem to suggest. But in any case, a good article like this one is worth the time to read. The article introduces MongoDB, shows how to install support for it in PHP (although the instructions are for Unix-like systems), and provides code for actually interacting with a MongoDB database.

On the Web => The Protocol-Relative URL

Some time back, I came across this excellent nugget of information that Paul Irish has put forth about the protocol-relative URL. I don’t want to reveal the details here (it’s a short article, and you ought to read it), but the gist is that there’s a very simple way to link CSS, images, JavaScript, and whatever other resources so that they’ll be served over HTTP on HTTP pages and provided over HTTPS on HTTPS pages. I wish I had thought to use this when I wrote my e-commerce book (instead of using two different header files)! Sometimes the simple solution is the most brilliant one…

On the Web => 10 Steps to Becoming a Great Web Developer

I just recently Stumbled Upon an article titled 10 Steps to Becoming a Great Web Developer. Even though the article is two years old, I think it does a great job of laying out the steps one would take to become a Web developer, starting with the basics of HTML, then moving into a server-side technology, and then getting into SQL, CSS, and JavaScript. On the higher end, there are regular expressions, Unix/Linux commands and administration, Web servers, version control, and frameworks. I would question some of the specific resources mentioned, but overall this is a nicely presented list and I can’t argue with the order. Two years later, perhaps the only thing I would add would be to start learning about mobile Web development, and a commenter on my original blog posting suggested XML and JSON, which would be good additions, too.

On the Blog => My Yii Book Update

In my blog and in these newsletters, I’ve informally mentioned my intent to write a book on the Yii framework. In theory, I would be writing it about now, but I’m very much behind on my JavaScript book so that’s not happening at the moment. I have been receiving more questions about this potential book, so I recently posted a quick update on the reasons for the book, how I plan on doing it, and when that might actually happen.

Thanks to anyone interested in that book!

On the Blog => Adobe’s Significant Flash and Flex Changes

I just posted the following on my blog today, and thought I’d share it here since it’s so topical…

Last week, or thereabouts, Adobe announced that it was discontinuing support for Flash on mobile devices. This is, by all accounts, a wave of the white flag in Adobe’s battle against Apple and its iOS devices (if only Steve Jobs were alive today to celebrate). I didn’t think too much of that decision: it does make sense to use HTML5 or native apps for dynamic content to be run on mobile devices anyway. And Flash would still continue to run on desktops, where something like 99% of browsers have the plug-in and 90-some% of video is run through Flash. Flash is such a large component of Adobe’s various technologies that I can’t imagine Adobe leaving it behind.

And then Adobe announced today that it was offering Flex to the Apache Software Foundation (managers of the ubiquitous Apache Web server, among other projects).  Apache will need to vote on whether to accept Flex or not. This announcement does surprise me, as Flex is used not only for Flash creation, but also desktop and mobile application development via the AIR platform. Adobe says it will continue to support Flash and Flex, but clearly Adobe is moving more towards HTML5.
An interesting, and rather big, development. One does not normally think of a technology with such a large market share being outright dropped. We shall see how this plays out…

Q&A => How Do You Choose Between Competing Technologies?

Richard emailed me recently, asking how I approach the situation where two competing technologies can be used for a given project. With his specific example, Richard was trying to decide between using HTML5 or Flash for an animated game. Assuming that both technologies were equally capable of performing the task, how does one make the choice? In simplest terms, Flash will provide the same experience for all users, so long as their browser supports Flash. This, unfortunately, rules out most (and as recently announce, all) mobile devices. Conversely, HTML5 will work equally well on all modern browsers, but will not work at all on older ones.

In response to Richard, I came up with two criteria for making any decision as to what technology to use for a project. First, one has to determine what technologies can achieve the task. Sometimes that alone makes the decision for you, when there’s only one possible solution. Considering the range of technologies and programming languages out there, this is rarely the case these days. For example, for a while, one could only develop iOS apps using Objective-C. But in most situations, there will be more than one option.

The next question is twofold then: who is the target audience and what needs to be supported? In this particular example, if the target audience is mobile users and outdated browsers don’t need to be supported, then HTML5 makes sense. If the target audience is all desktop users and mobile devices don’t need to be supported, then Flash. If everyone needs to be supported, then both technologies is the best solution.

With my own work, I normally aim for the broadest support over the newest thing, unless the point is the newest thing (e.g., you can’t make a site about HTML5 and have it be backwards compatible). I’m really not on the cutting edge of technologies, as many people are. I may be relatively on the cutting edge of useful technologies, but my goal is always to use the best tool, not the coolest one.

A third criteria that I failed to include in my reply to Richard, but is worth considering, is what technology you, the developer, are strongest with. Now, to be clear, this should not have a significant impact on the decision. I’ve seen people use technologies for the wrong tasks too many times, simply because that was the technology the person knew best (e.g. creating graphical desktop applications with PHP, which is possible, but not wise). My point with this criteria is that if you have two comparable choices and you’re stronger with one, then use that by all means. The project will go faster and the end result will be better.

Q&A => How Do You Spend Time Between Projects?

David posed this question, asking me specifically, I believe (as opposed to asking for general advice towards this end). Being me, I’ll both answer for myself and give some advice.

When you work for yourself, the time between projects is especially important. For starters, this is time you’re not making money, so it needs to be used wisely. But if you treat the time between projects as an investment in yourself, and therefore your business, hopefully the period without money coming in will pay off in time. I don’t actually have much time off between projects, which is both a good thing (i.e., I’m busy making money) and a bad thing (I’m stressed and secondary things aren’t getting done). But when I do have downtime, at that moment, I look to the past and I look to the future.

In terms of the past, downtime between projects is when you should make sure that you’ve done everything that needs to be done but got put on the back burner while you were toiling away. This can be replying to emails, doing a little something for a client that wasn’t a priority, and updating your own Web site, LinkedIn profile, and so forth. When I overhauled my Web site a year ago, I was aghast by how out of date and unhelpful it had become. Having such public, poor representations of yourself out there is bad for business in the long run, even if only a little bit. You should have some sort of task management application, and in it you should keep a running list of “high priority someday” tasks, such as those I’ve just mentioned. Complete as many of these as you can as soon as your downtime begins, because if you don’t do it then, when will you?

In terms of the future, it’s largely a matter of improving one’s skills, whether that means learning something new or solidifying existing knowledge. In my task management application, I have a running list of topics that I’m interested in (these are non-high-priority-but-someday tasks). I take some time to investigate those during these little breaks.

Finally, I think it’s really important to recharge one’s batteries during these downtimes, whatever that may mean for you. To me, that primarily means getting away from my computer and doing something active. Part of the reason that I suspect I’m struggling in completing this JavaScript book is that I didn’t have enough (well, any) downtime between it and the previous book I wrote.

Time spent not working may seem like time spent not getting things done and not making money, but there’s a lot to be said for having some recovery time between projects. And I think, perhaps unmeasurably, such downtimes reap their own benefits in the long run.

What is Larry Thinking? => Starting a New Project

Last week, a friend came over to my house, hoping to learn about Web development. This friend has almost completed her PhD from Cornell in computer science, has taught college-level classes on programming languages, and worked at Google, too, so her technical knowledge is excellent, probably exceeding mine. She’s wanting to learn Web development, and while she has had no problems picking up the syntax and fundamentals of PHP, the big picture of Web development was eluding her. We went over a few things and, at one point, she asked how I had learned this or that. And, to be completely honest, I’ve been doing this long enough now, and my memory regarding my own development is sketchy at best, that I couldn’t answer her. But I can certainly recall that starting a big Web project, especially when you’re just beginning, is a daunting enough task as to be overwhelming, and perhaps you, too, don’t know where to begin.

Simply put, projects are a combination of data, functionality, and presentation. Games have a lot more of the latter two and many Web-based projects focus on the data, but those are the three elements, in varying percentages. When you go to begin a new project, it’s in one of these three areas that you must begin. And you should always start with the functionality, as that dictates everything else.

The functionality is what a Web site or application must be able to do, along with the corollary of what a user must be able to do with the Web site or application. The functionality needs to be defined in advance, and ought to be clearly stipulated in the contract (when there is one). Use a paper and pen (or note-taking application), and write down everything the project requires:

• Presentation of content
• User registration, login, logout
• Search
• Rotating banner ads
• Random monkey appearances
• Et cetera

Try your best to be exhaustive, and to perform this task without thinking of files and folders, let alone specific code. Be as detailed as you can about what the project has to be able to do, down to such things as:

• Show how many users are online
• Cache dynamic pages for improved performance
• Not use cookies or only use cookies
• Have sortable tables of data

The more complete and precise the list of requirements is, the better the design will be from the get-go, and you’ll need to make fewer big changes as the project progresses.

Once you’ve come up with the functionality (with the client, too, if one exists), it’s time to start coding and creating files and folders. You can start that process from one of two directions: the data or the presentation. I’m a data-first person, but let’s look at the presentation side to start.

If you’re a designer, or are working with clients that think in visual terms primarily, it makes sense to begin any new project in terms of how it will look. You may want to start with a wireframe representation, or actual HTML, but create a series of pages that provides a usable bases for how the site will appear from a user interface perspective. You don’t need to create every page, and in a dynamically-driven site you actually shouldn’t, but address the key and common components. The end goal is the HTML, CSS, and media, in a final or nearly-final state. Once you’ve done that, and the client has accepted it, you can work your way backwards through the functionality and data.

If you’re a developer, like me, incapable of thinking in graphical terms, it makes sense to begin any new project from the perspective of the data: what will be stored and how the stored information will be used. For this task, you’ll want to use a paper and pen, or a modeling tool such as the MySQL Workbench, but the goal is to create a database schema. Always err on the side of storing too much information, and always err on the side of pure normalization (when using a relational database). Once you’ve done that, I normally populate the database with some sample data. This allows me to then create the functionality that ties the data into a sample presentation. By doing so, I, and the client, can confirm that it’s looking and working as it should. From there, you can implement more functionality, and then have the presentation finalized.

So that’s the process in a nutshell.

Book Giveaway => “PHP and MySQL for Dynamic Web Sites: Visual QuickPro Guide” (4th Edition)

You must be subscribed to the newsletter to qualify for the book giveaway.

Larry Ullman’s Book News => “Modern JavaScript: Develop and Design”

I just submitted Chapter 8 of “Modern JavaScript: Develop and Design”, which means I’m about 50% done with the first draft (well, first submitted draft: there are multiple internal drafts prior to that). Progress is still going more slowly than I’d like, but… I always hope I’m about to turn a corner and speed up and one of these days, I will. In fact, I’ve got another deadline to shoot for (having blown past the original), so I will be doing everything I can to get this done ASAP. If anyone knows how to put more hours in the day, or days in the week, please let me know!

Since my last newsletter, I’ve written chapters on: arrays and objects (Chapter 6); functions (Chapter 7); and events (Chapter 8). Next is Chapter 9, on the browser (including CSS and DOM manipulation), Chapter 10, on forms, and Chapter 11, on Ajax. With the core concepts of JavaScript behind me (really, Chapters 4-7), these chapters are getting into more interesting and useful stuff. For example, two events have been used ever since Chapter 2, but now the examples can take advantage of other events. And although most of the chapters in the book thus far use an HTML form is some way, the forms chapter can now be more of a “cookbook” type chapter, explaining how to best work with specific form element types.

The third part of the book, beginning with Chapter 13, is still somewhat up in the air. There will be a chapter on frameworks, one on HTML5 and JavaScript, and another on advanced programming. Depending upon time and space, I’ll do a chapter on libraries (individual libraries, as opposed to frameworks), server-side JavaScript, and JavaScript for mobile apps.

I first started using the Yii framework about two and half years ago. I’ve never been much of a framework person, but Yii really felt right to me, quite similar to Ruby on Rails, which I also always liked. Being a writer, after learning to use the framework, I wrote an introductory series on the subject, which has been quite popular. In all modesty, many have suggested it’s the best documentation available. In fact, the creator of Yii liked my series so much that he listed it prominently on the official Yii documentation page (it’s now under tutorials). Some time after writing that series, I started thinking about writing a full book on Yii, because that’s what I do.

When I decided to write a book on Yii, I figured I’d self-publish it, for a couple of reasons. First, even though I have a wonderful relationship with Peachpit Press, I’m not sure they’d want to do a book on Yii, as the market is kind of small. Second, even if Peachpit would publish such a book, I doubt I’d make much money on the project, considering the small market. By comparison, if I self-publish, I can make 4-5 times per book what I’d make if I went through a publisher. The higher per copy amount could be enough to make up for the smaller sales, ending up with a project that’s financially worth my time to do (sorry to be crass about the money, but writing a book is a lot of work and I do have bills to pay!). Fourth, I’ve been intrigued about self-publishing for some time. And, fifth, self-publishing would give me the opportunity to distribute the book in unique formats and channels, such as a chapter at a time.

If I had my act together (which is to say, if my life were other than it is, in about ten ways), I would have been on the ball and published this book a year or more ago. Sadly, that has not been the case. I keep fairly busy work-wise, and I don’t actually have the time (due to personal constraints) to put in 40-hour weeks, so it’s really hard to add new projects, especially on the level of an entire book. Moreover, self-publishing means no guaranteed money, so I’d have to not do paying work while not making money working on the Yii book, which is a tough situation to be in.

All that being said, it is still my intention to write and self-publish a book on Yii. The only question is: when? This is the question I’m getting asked a lot lately. Before I do anything towards a book on Yii, I still have to:

• Finish my Modern JavaScript: Develop and Design book (which I’m weeks late on as is)
• Write one more article in support of my PHP and MySQL for Dynamic Web Sites: Visual QuickPro Guide (4th Edition) [I've written two out of three articles, but I'm weeks late on that, too.]
• Come up with a list of videos to do in support of my Modern JavaScript: Develop and Design book
• Actually do those videos
• Continue doing the Web development and other work I have for my clients

So…yikes. Don’t get my wrong: I’m quite fortunate to be busy, but yikes! I’ll be crying if I haven’t finished all of the above by the end of this year, which means in theory I can begin the Yii book at the beginning of 2012. However, I have the third edition of my PHP 5 Advanced: Visual QuickPro Guide due at the end of April. That does give me four months, but I’d like actually make that deadline for a change (my publisher is wonderfully understanding, but…).

Also, along with writing the Yii book, I’m going to have to come up with a site and an ecommerce system and so forth (I already have the software that can output PDFs, ePubs, and mobis). If I’m being optimistic, perhaps in 2012 I can do two Yii chapters per month, but the PHP 5 Advanced book will need to be my first priority. I also don’t want to start the Yii book, get some people paying for it (in part or in whole), and then have the project drag out. I don’t know. We shall see.

I very much thank everyone for their interest in my writing a book on Yii and I hope to make that happen. If you follow the blog and/or subscribe to my newsletter, you’ll get updates as to how this is progressing, when and if it does actually progress.

• About This Newsletter
• What Were You Thinking? => The JavaScript Book
• On the Web => Flash Builder 4.5/Flex 4.5 for Mobile Apps
• On the Blog => Cookies and Sessions in Yii
• On the Forum => FALSE Comparisons in PHP
• Q&A => Could You Say More About Stored Procedures?
• What is Larry Thinking => Doing What I Do: Web Development
• Larry Ullman’s Book News => “PHP and MySQL for Dynamic Web Sites” (4th Edition) and “Modern JavaScript: Develop and Design”

About This Newsletter

Another three weeks(-ish), another newsletter! It may only matter to me, but I’m happy to say that since I started using Scrivener to write this newsletter (in late 2010), I’ve done a much better job in getting these out regularly. Although, since they only go out once a month, or slightly better, it may always seem to you that the newsletters come from out of the blue. Anyway…in this newsletter I present a random collection of stuff, including the conclusion of my on-going series on building a career in IT. In my next newsletter, I plan on speaking, briefly, about quantum computing, having recently read a fascinating article on the subject.

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? => The JavaScript Book

In the previous newsletter, I posted a question about whether it matters to you if I self-publish my intended JavaScript book or if I use a traditional publisher. I also asked the general question as to what readers look for in a book, beyond the content and perhaps writer. There was an excellent response and I thank everyone for their thoughts.

The bottom line was that most people don’t care about the publisher. Some people specifically like, say, O’Reilly books or the Visual Quick* Series, but many don’t pay much attention to the publisher (I’ve always suspected that many readers don’t pay much attention to who the writer is either). The strongest feedback was just for it being made available in specific formats—PDF, print, what-have-you, and that it be of good quality.

It was also nice, and quite flattering, to hear many people express their interest in purchasing the book, regardless of whether I self-publish or use a traditional publisher. I am, indeed, fortunate to have the readership that I do.

Thanks again to everyone that responded and to those of you interested in this book. The actual decision regarding this JavaScript book can be found in the “Larry Ullman’s Book News” section at the end of this newsletter (this is called “burying the lead”!).

On the Web => Flash Builder 4.5/Flex 4.5 for Mobile Apps

Version 4.5 of both the Flex framework and the Flash Builder IDE just came out and the outlook is very exciting. As announced some time ago, the focus in Flex 4.5 is on developing for mobile apps. This means a new wave of components optimized for mobile platforms. That alone might sound “kind of cool”, but this release is much, much bigger than that.

Instead of using Flex to write Flash content that runs in a Web browser in a mobile device (but not on Apple devices), thanks to Adobe AIR 2.6, you’ll be able to write true mobile apps in Flex. With the initial release, you’re able to create apps for the Google Android platform (the largest platform, in terms of sales of mobile devices today). Version 4.5.1 was just released, which adds support for iOS (iPod Touch, iPhone, and iPad) devices and the Blackberry Tablet OS. To summarize:

If you know Flex, you can create mobile applications that run on all major mobile platforms in no time at all!

This could not come at a better time for me. I have a couple of mobile app ideas that I want to develop and was planning on learning how to do so later this year (yes, yes, I’m totally on the cutting edge of the mobile app craze, eh?). I was still hemming and hawing over whether to pursue the iOS route, which would be natural for me (I primarily use Macs and am comfortable with the C family of languages), or go the Google Android route, which would be harder (Java is the default language there), but technically has a broader market. And now, thanks to Flex 4.5 and Adobe AIR, I won’t have to choose between them.

To see the development process, and the output, in action, check out this sneak peek video at Adobe. There’s also this pretty good article on mobile development using Flex and Flash Builder. It’s a very impressive concept and, as far as I know, the only “write once, run everywhere” development solution for mobile apps. This, of course, is the promise of Adobe AIR itself, which allows you to write one application that can run on multiple operating systems (I still seem to be a bigger fan of AIR than the world at large).

On the Blog => Cookies and Sessions in Yii

In my ever-ongoing series on the Yii framework, I’ve recently written two postings on managing state using the framework. The first is on sessions; the second on cookies. Neither is particularly difficult to do using Yii, once you know the right code, of course. With cookies, Yii has built-in extra security measures you can take, for example, to help prevent Cross-Site Request Forgery (CSRF) attacks.

On the Forum => FALSE Comparisons in PHP

I’m hoping that you’ll take this as a comfort, but you should be aware that we all, no matter how long we’ve been programming, are capable of creating bugs when programming. Through the keen testing of a reader, a bug was caught in the second example site from my “Effortless E-Commerce with PHP and MySQL” book. It’s a common enough mistake that I should have caught it myself and yet… You can read my formal explanation regarding the specific code in the forum, but the premise is this:

Say you have the conditional if ($var) {. That conditional will be TRUE so long as $var has a TRUE value. But what is a TRUE value? It’s easiest to understand what a TRUE value is by knowing what a FALSE value is. These are all FALSE values:

• FALSE (case-insensitive)
• NULL
• (No actual value)
• “” (An empty string)
• 0
• 0.0
• ‘0′

There are a couple of other higher-end FALSEhoods, such as an empty array. It should be fairly obvious that FALSE, NULL, no actual value, and an empty string are all FALSE values; the bug arises when you forget that zero, in any form, is also FALSE. And here’s how it can manifest itself as a bug (this is a different example than the one in the book and referenced in the forum)…

The stripos() function is used to identify whether or not string Needle is found within another string Haystack. If the Needle is not found, stripos() returns FALSE. If the Needle is found, stripos() does not return TRUE, but rather returns the indexed position where Needle begins in Haystack. This code, therefore, could be a problem:

if (stripos($haystack, $needle)) {…

The intent is to see if $needle exists in $haystack. However, if $needle is the first part of $haystack, stripos() will return 0, which will be interpreted by that conditional as FALSE. The bug-free solution is to change the conditional to test if the value returned by stripos() is not identical to FALSE:

if (stripos($haystack, $needle) !== false) {…

Note that you have to explicitly use the not identical operator (!==), as using the not equal operator (!=) would again be a bug, as the zero returned by the function would, in fact, be equal (but not identical) to FALSE.

Again, I hope you can take some solace in knowing that we all make mistakes, no matter the level of experience (or maybe that’s depressing?). I personally find it frustrating to make mistakes that I’m already aware of as a possibility, but on the bright side, making mistakes you know about makes them easier to fix!

Q&A => Could You Say More About Stored Procedures?

Oguz had prompted me to write a bit about stored procedures in general and in MySQL in particular. Stored procedures are one of those higher-end database concepts which you may have heard about but never really used (other examples include VIEWs and UNIONs). I previously wrote about stored procedures in my “MySQL: Visual QuickStart Guide” and my “PHP 5 Advanced: Visual QuickPro Guide“, and then relied upon them extensively in the second example of my “Effortless E-Commerce with PHP and MySQL“.

Both stored procedures and stored functions fall under the category of stored routines, added to MySQL in version 5.1 (and MySQL is still adding features in this area). A stored routine is simply a memorized set of SQL queries and code. Think of it like taking any block of PHP code that interacts with a database, has conditionals, does something with the query data, etc., but store all of that in the database itself. The primary difference between a stored procedure and a stored function is that a stored function can return only a single value whereas a stored procedure can return an entire result set (i.e., multiple rows of multiple columns of data). For example, in “PHP 5 Advanced”, a stored function is created that returns the distance in miles between two points on the globe, which involves complicated trigonometry using latitude and longitude. A call to that function is then part of a standard SELECT query, as if it were any other predefined MySQL function. Conversely, in “Effortless E-Commerce with PHP and MySQL”, stored procedures are used to update shopping carts, return a list of sale items, and much more. Both types of routines can also take arguments, just like functions in PHP.

Stored routines offer several benefits, the most important of which is improved security. Because all of the database references—table and column names—are in the stored routines, a PHP script using those routines need not have any knowledge of the particulars of the database. Further, a stored routine can use its arguments in queries with the same security as prepared statements, thereby preventing SQL injection attacks. Applications with the highest level of security requirements, such as banking, rely upon stored routines.

You can also get better performance using stored routines, both because the routines can be cached and because less data has to be transferred to the database (just the data itself gets transferred; all the SQL is already in the database). Using stored routines also offers improved application portability, in that many different types of clients—PHP scripts, command line tools, GUI applications, etc.—can make use of the same stored routines.

There are arguments against using stored routines, too. For starters, you’ll need a relatively current version of MySQL, and the ability to create an execute stored routines (these are permissions not necessarily offered by, for example, shared hosting environments). Stored routines also marry your applications to specific database applications (e.g., MySQL or Oracle), although stored routines are part of the SQL standard and may be somewhat translatable from one database application to the next. And, as with most things, there’s a learning curve involved and debugging applications that use stored routines becomes a bit harder.

You can find out more about stored routines in the books I mentioned, in the MySQL manual’s main page for stored routines, and in the stored routines FAQ and restrictions pages of the MySQL manual.

What is Larry Thinking? => Doing What I Do: Web Development

In this newsletter I’m finishing what became a series on IT careers. I first wrote about becoming a better programmer, in two parts(1 and 2). Then I wrote about building a career and how I got here. Next, I wrote about some of the specifics of what I do, focussing on the writing side. In the previous newsletter, I discussed training. This leaves me with the last thing that I do: Web and application development (i.e., programming).

Web and application development jobs have a wide range of possibilities with a wide range of potential income. Small, simple jobs may pay a few hundred dollars; big, complex, and well-funded projects can pay tens of thousands or hundreds of thousands. Getting any job, regardless of size, is a two-step process: 1) finding out about the job; and, 2) convincing the client to hire you.

There are online sites for finding projects, but you’ll be competing with everyone else there. You’ll have better luck by networking: connecting with people, businesses, and organizations that might be able to make use of your abilities. For example, for a couple of years I was the outside programmer that did the dynamic functionality for a graphic designer. She got the projects, managed the clients, the contracts, and the billing, and I just did my share of the work. A perfect arrangement for me! Local user groups, schools, and similar communities can be good ways to hook up with people in a casual way that might pan out down the line.

As for convincing clients to hire you, the most important criteria in my mind are good communication skills. Everyone says that communication skills are important, but not that many people excel in this area, and way too many don’t even try to communicate well. Be clear, responsive, and punctual in your communications! Doing so demonstrates that you have a level of professionalism needed to do the work itself. If you can’t clearly express yourself in an email, if you fail to answer questions asked of you, or if you’re negligent in responding promptly, it suggests that the work you do will be poorly put together, will fail to meet expectations, and not be done on time, either.

Secondarily, you’ll need to have a portfolio showing what you’re capable of. If you don’t have a portfolio, then give them something that they can look at. One of my very first clients, for whom I’m still working, wanted a bit of JavaScript coding for his site. At that time I had no portfolio to show him, so as part of my bid, I did the work itself and presented that. Nothing more clearly indicates your ability to do a project than actually doing the project! Further, the client could also see, before he hired me, that the project would be finished quickly (because it already was). Yes, I ran the risk of making no money for my efforts, but at the time I needed the work and had to go out on a limb. It really panned out, and I would do it again if I felt I had to (arguably, I have had to in the past, as getting published involves some amount of writing on spec).

And this leads me to a point that you’ll (hopefully) learn in time as you grow your skills and your budget: you’ll always adjust your bids not just to the project and the client but to your situation. When I’m especially busy or if a project isn’t that interesting, clients will get the “I don’t really want to do this project but if I am going to do it, I’m going to get paid well” bid. When I’m not that busy or a project is interesting, I’ll provide a cheaper bid. Life is always a matter of time versus money, and the professional is constantly making adjustments along that scale.

As a final cornucopia of thoughts, first, don’t be afraid to overbid. Even if you’re desperate, you may really come to regret getting a project at a low bid. If anything, it tells you a lot about a client that wants the lowest price: you probably don’t want to work with people that want things on the cheap. There is no doubt you will sometimes make less money on a project than you should (and hopefully sometimes make more), but try not to plan on shortchanging yourself. For that matter, have a good contract in place with expectations clearly laid out so that you don’t get steamrolled.

Next, you could consider becoming a specialist in one area: CMS (e.g., Joomla), WordPress, etc. You run the risk of not being able to get work as easily, because you are so specialized, but you may also be able to make more money, and get better at a smaller set of skills faster, by narrowing your focus.

And lastly, if you’re working on a project and you’re having problems and aren’t going to make the deadline, handle the situation professionally. Never hide from clients, be as honest as you can, and always reply to emails promptly. For more strategies along these lines, check out this nice article.

So that’s it on my long series on building a career in IT. As happens with me, all the time, what started off as a simple idea expanded and expanded. I worry that I ran out of steam at the end here, but hopefully you’ve benefitted from this discussion somehow, and I’ve helped you, in whatever small way, in pursuing your dream of an IT career (as for me, my dream involves a hammock overlooking the Caribbean Sea).

Larry Ullman’s Book News => “PHP and MySQL for Dynamic Web Sites” (4th Edition) and “Modern JavaScript: Develop and Design”

I’m very pleased to say that I’ve completed the first draft of the fourth edition of “PHP and MySQL for Dynamic Web Sites: Visual QuickPro Guide” (and by “first draft”, I mean the first draft submitted to the publisher; there are multiple writing drafts just to get to that point). As with the fourth edition of “PHP for the Web: Visual QuickStart Guide“, I added a “Review and Pursue” section to the end of each chapter. I also expanded the coverage of SQL and MySQL, including much more on JOINs. One new chapter introduces the jQuery JavaScript framework, with examples of form validation and performing Ajax requests. Another new chapter introduces the fundamentals of Object-Oriented Programming, using the MySQL Improved extension for several examples, and the DateTime class for another. In the appendix, I’ve included a few pages on configuring the Apache Web server, providing the syntax for performing common tasks such as password protecting directories and URL rewriting.

Last, but not least, I am pleased to announce that I have in my hands a contract to write the book “Modern JavaScript: Develop and Design” for Peachpit Press. This is the publisher I’ve worked with the most, and so I’m quite comfortable with them. The book will be in a new series, titled “Develop and Design”, specifically created for code-based books (the first title in the series is on ActionScript). The series does not use the two-column format like the Visual QuickStart/QuickPro series (which some people like, some people don’t), and will be in full color, a first for me. The publisher has allotted me up to 600 pages, which is quite a lot, and by using a publisher, the book will have the widest possible availability (Peachpit Press really worked with me on making this happen). I’ll begin formally writing the book in late July or early August so that it comes out by the end of the year. Once again, my thanks to everyone for their interest in this book, and for all of the feedback.

So, CodeLobster is an IDE for PHP that runs on Windows. It’s available in both a free and “professional” version, the professional version costing $100 (US). The free version comes with an HTML editor and inspector, a CSS editor, a JavaScript editor, a PHP editor, and a PHP debugger. This all includes the standard features such as code completion, code collapsing, browser preview, project management, FTP, and so forth. The professional version includes all of those features, plus plug-ins for specific tools and frameworks: CakePHP, CodeIgniter, Drupal, jQuery, Joomla, Smarty, Symfony, WordPress, and Yii. In other words, the professional version gives you code completion, contextual help, and so forth for these additional tools that you may also be programming in.

As I said, I haven’t personally used it, but if you’re looking for a PHP/Web Development IDE, it may be worth checking out.

What you’ll want to do to create a cookie is create a new object of type CHttpCookie: Yii’s class for cookies. Here, then, is the syntax for setting a cookie in Yii:

Yii::app()->request->cookies['name'] = new CHttpCookie('name', 'value');

You must use the same name value in both places, replacing it with the actual cookie name. Remember that the cookie’s name, and value, are visible to users in their browsers, so one ought to be prudent about what name you use and be extra mindful of what values are being stored.

Tip: Because the cookie’s name must be used twice in the code, you may want to consider assigning the cookie’s name to a variable that is used in both instances instead.

Once you’ve created a cookie, you can access it (on subsequent pages, because cookies are never immediately available to the page that set them), using Yii::app()->request->cookies['name']->value. You have to use the extra ->value part, because the “cookie” being created is actually an object of type CHttpCookie (and Yii, internally, takes care of actually sending the cookie to the browser and reading the received cookie from the browser).

To test if a cookie exists, just use isset() on Yii::app()->request->cookies['name'], as you would any other variable.

To delete an existing cookie, just unset the element as you would any array element:

unset(Yii::app()->request->cookies['name']);

To delete all existing cookies (for that site), use

Yii::app()->request->cookies->clear();

By default, cookies will be set to expire when the browser window is closed. To change that, you need to modify the properties of the cookie. You can’t do so when you create the CHttpCookie object (i.e., the only arguments to the constructor are the cookie’s name and value), so you must separately create a new object of type CHttpCookie, to be assigned to Yii::app()->request->cookies later:

$cookie = new CHttpCookie('name', 'value');

Then adjust the expire attribute:

$cookie->expire = time() + (60*60*24); // 24 hours

Then add the cookie to the application:

Yii::app()->request->cookies['name'] = $cookie;

You can manipulate other cookie properties using the above syntax: domain, httpOnly, path, and secure. Each of these correspond to the arguments to the setcookie() function. (You can also manipulate the value of the cookie through $cookie->value and the cookie’s name through $cookie->name). For example, if you want to limit a cookie to a specific domain, or subdomain, use domain; to limit it to a specific folder, use path; and to only transmit the cookie over SSL, set secure to true.

You can also improve the security of your cookies by setting Yii’s enableCookieValidation to true, in the Yii configuration file:

return array(
    'components'=>array(
        'request'=>array(
            'enableCookieValidation'=>true,
        ),
    ),
);

Cookie validation prevents cookies from being manipulated in the browser. To accomplish that, Yii stores a hashed representation of the cookie’s value when it gets sent, and then compares the received cookie’s value to ensure they are the same. Obviously there’s extra overhead required to do this, but in some instances, the extra effort is justified by the extra security.

Finally, one good reason to use cookies in a Yii-based site, even if the site is otherwise using sessions, is to prevent Cross-site Request Forgery (CSRF) attacks. A CSRF works like this: malicious site A has some code on it, such as an image tag whose src attribute points to a page on site B that does something meaningful: http://www.example.com/page.php?action=this. When any viewer loads the page on site A, the use of that src attribute has the effect of that user performing a request of the page on site B.

As an example, let’s say that an administrator at your site logs in and does whatever but doesn’t log out. The administrator therefore still has a cookie in her or his browser indicating access to the site (i.e., the user could open the browser and perform admin tasks without logging in again). Now let’s say that the src attribute on malicious site A points to a page on your site that deletes a blog posting. If the administrator with the live cookie loads that page on site A, it will have the same effect as if that administrator went to your site and requested that page directly. This is not good.

To prevent a CSRF attack on your site, first make sure that all significant form submissions use POST instead of GET. You should be using POST for any form that changes server content anyway, but a CSRF POST attack is a bit harder to pull off than a GET attack.

Second, set enableCsrfValidation to true in your configuration file:

return array(
    'components'=>array(
        'request'=>array(
            'enableCsrfValidation'=>true,
        ),
    ),
);

By doing this, Yii will send a cookie with a unique identifier to the user. All forms will then store that same identifier in a hidden input. The form submission will only be handled then if the two identifiers match. With the case of a CSRF attack, the two identifiers will not match because the form’s identifier will not be passed as part of the request (I hope this is clear; if not, let me know). Note that this only works if you’re using CHtml to create your forms (if you manually create the form tags, Yii won’t insert the necessary code for preventing CSRF attacks).

The most important thing to remember about cookies, which I’ve already stated, is that cookies are visible to the user in the browser. And unless you’re using SSL for the cookies, they are also visible to anyone else while being transmitted back and forth between the server and the client (which happens on every page request). So be careful of what gets stored in a cookie! If the data is particularly sensitive, use sessions instead of cookies.