• About This Newsletter
• What Are You Thinking? => Bimonthly Newsletters
• On the Web => How To Read a PHP Function Definition
• On the Blog => Finding Book Bonus Content
• Q&A => Do You Use Any Tools to Debug Your PHP Scripts?
• What is Larry Thinking => Testing Your PHP Knowledge
• Larry Ullman’s Book News => “Modern JavaScript: Develop and Design”

About This Newsletter

Happy New Year! I hope you are doing well and had pleasant holidays, for those of you that celebrate holidays around this time. I’m going to get right to the newsletter, without any big introduction. I will say in advance that this is going to be a shorter newsletter, for reasons I’m about to explain.

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

What Are You Thinking? => Bimonthly Newsletters

First of all, how difficult is the English language? The term “bimonthly” means both every two weeks and every two months. Seriously? Yikes. Well, the reason I bring it up is that I’m thinking of changing the frequency of the newsletter. Right now, I try to send out the newsletter every 3-4 weeks, and target keeping it under 3,000 words (which I often don’t do). I’m debating putting it out every two weeks (-ish), but cutting the length by about half (as a point of reference this newsletter is the approximate new length). I’d also have to change some of the structure a bit. For example, I’d probably drop the “About This Newsletter” section, and only do some sections some times. What do you think?

You can reply to this email with your thoughts, or quickly vote at this online poll. Thanks in advance for your input!

On the Web => How To Read a PHP Function Definition

It was recently pointed out to me by a couple of readers that they found my explanation for how to read the PHP manual, presented in Chapter 1 of my “PHP for the Web: Visual QuickStart Guide” book, to be confusing. I think that learning how to read the manual is quite important, but I can see now that my presentation of that subject was a bit much at that early stage of the game, at least for absolute beginners. In any case, in that forum discussion, someone shared a link to a page in the PHP manual titled “How to Read a Function Definition”, which they found to be useful. So I thought I’d share it here!

On the Blog => Finding Book Bonus Content

For many of my books, bonus content is made available through the publisher. Sometimes this is material that was intended for the book but had to be cut, such as an appendix or a chapter, and sometimes the material is a true bonus, such as a video screencast. Because it’s not clear for everyone how to access this bonus material, I recently posted instructions for finding bonus material on my blog.

Q&A => Do You Use Any Tools to Debug Your PHP Scripts?

Daniel had asked me this question and the truthful answer is that I generally don’t, crazy as that sounds. Mostly this is because I primarily write PHP code using a text editor, TextMate, that does not have a built-in debugger. That leaves me with using echo statements as my primary debugging tool. I know I can get XDebug working with TextMate on my Mac, I just haven’t felt the need.

On the other hand, I’ve used Zend Studio some, mostly for Flex+PHP development, in conjunction with Flash Builder, and Zend Studio does have a built-in debugger. Debuggers are nice—they report the values of variables, let you walk through code, and so forth, I just haven’t been driven to force myself to use one yet. Certainly if I were to use an IDE more frequently, I would get myself into the debugger habit.

What is Larry Thinking? => Testing Your PHP Knowledge

A friend of mine recently went on a job interview for a position as a PHP programmer and was given this prompt:

$a = 4;
$b = 5;
$c = --$b + $a++;

What is the value of $c?

This is just annoying. The question is trying to test knowledge of the impact that using the postfix and prefix versions of the increment and decrement operators have. In other words, will $b be decremented and then added to $a or will $b be added to $a and then decremented (and, of course, the same goes for the $a value, too)?

Besides being a meaningless example, in no way does this test one’s actual skills as a PHP programmer. It only tests one’s ability to memorize the rules of precedence. I, for one, always considered memorizing the precedence rules to be a waste of time. The list contains many esoteric operators that aren’t commonly used. More importantly, memorizing the list is only useful if you always remember the precedence list accurately. As soon as you slip up, you’ve created a bug. And even if you don’t slip up, relying upon precedence will lead to code that’s not clearly understood (i.e., that doesn’t clearly convey the programmer’s intent). That, to me, is bad code. When I look at that prompt, I don’t wonder what the value of $c is, but rather what the original programmer intended it to be. I know it undercuts the point of the test, but a real PHP programmer should have coded:

$c = (--$b) + $a;
$a++;

That code assigns the same answer to $c—8—and then increments $a, but is much, much cleaner. And, of course, some comments wouldn’t hurt!

It probably would not have gotten me the job, but that’s what my answer would have been. To me it comes down to whether the company is looking for someone that can memorize arcane rules, or someone that actually knows how to program. This is also why I don’t personally put much stock into certifications. Those are just exams that tests one’s ability to memorize and regurgitate rules. Certification exams have little reflection of real-world programming. For example, I might be asked on a certification test the order of the arguments for PHP’s explode() function, which I can never remember for whatever reason. On the test, I’d have a 50-50 shot of getting that question right, but in the real-world, there is a 100% guarantee that I’ll use the function correctly, because I’ll just look up its definition.

Years ago, I was a trainer for Borders Bookstores. As part of the training process, we’d have the new employee go on a treasure hunt to find a slew of books. Inevitably some trainee would get stumped and tentatively ask another, more seasoned employee for help. I loved that, because it accurately reflects the job: when you got stuck, you asked the person next to you.

Many books, tests, and even these simple employee tests put way too much emphasis on knowing facts. Being able to answer a question about a rule or function is not that important in the grand scheme of things. Being able to find answers to questions is far, far more critical. If you rely only on what you know, there will be a time when you won’t know, and then you’ll really be stuck.

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

I just submitted Chapter 14, “Advanced JavaScript,” about two days ago, which means I only have two chapters left (whohoo!). One chapter will be on frameworks, in which I introduce both jQuery and YUI, probably the two most commonly used frameworks. The other chapter will be an example chapter using JavaScript with PHP (and HTML and CSS, of course). I’m thinking right now of doing an auction-like system, which would entail timers and Ajax and DOM manipulation and all sorts of goodies.

I will have those chapters done in the next two weeks, at the latest. I’ve also done the rewrites on the first 8 chapters, and have a few more of those to go. There will be supporting video screencasts to go with the book, and probably a couple of articles to be published online. The end is nigh!

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…

• JavaScript: The Definitive Guide, by David Flanagan (O’Reilly)
• JavaScript: The Good Parts, by Doug Crockford (O’Reilly)
• Pro JavaScript Techniques, by John Resig (Apress)

These are all recommendable books, with their own strengths and weaknesses (I always think of O’Reilly books being technically thorough and excellent, but not great to learn from for beginners.) In skimming some other JavaScript books, not to be named, and working on my own, I’ve been thinking more analytically about why there aren’t more good JavaScript books out there. I’ve come up with two reasons.How JavaScript Used to be Used

When JavaScript first started to be used, what was expected of Web pages was thoroughly different than today. The “World Wide Web” was quite new, and people were just starting to get online. As with most new technologies, the emphasis was on cool over useful. JavaScript, and HTML, were used to demonstrate what could be done, more than what should be done. With HTML, this meant things like the hideous blink tag (if you never saw a blink tag in use, consider yourself lucky). With JavaScript, this meant embedding sounds (ugh!), status bar tickers, popup windows, alerts, changing the cursor, and so forth. At best, JavaScript was used for image manipulation (e.g., rollovers) and minor form validation. Books written at the time, therefore, focused on these things. In other words, by comparison, if everyone wants to use paper shredders to make confetti, books about shredders will show how to make confetti!

Besides how JavaScript was used, there was the issue of who used it. Being a client-side language, JavaScript was primarily the domain of client-side developers: graphic design people, generally without formal programming training, ability, or even interest. With that intended audience, JavaScript books written at the time focused more on how to use JavaScript for specific applications, not how to learn JavaScript as a programming language in its own right. Which, you know, it is. Recipe books are fine, of course, but aren’t effective as a way to learn a language outright.

Also, JavaScript is a comparatively easy language to use, albeit not an easy language to use with absolute reliability. Because of this quality, there may have been less incentive to write books that fundamentally teach the language, as opposed to just showing people how to do the little tricks they think they want to do.

I never wrote a JavaScript book in the time period I’m talking about (the first time I formally wrote about JavaScript was in 2003), but my theory is that how JavaScript was used when most books were first being written is partially responsible for the lack of quality titles. This is a theory. Over time, as these writers did new editions, perhaps they didn’t do such a good job of updating the book to reflect how JavaScript usage has changed. It’s hard to make big changes to a book’s organization in subsequent editions, but, on the other hand, that is part of the job of being a writer. As an example, I was just looking at the fifth or sixth edition of a JavaScript book and noticed that it still has separate chapters on image manipulation (i.e., rollovers and such), cookies, and frames, but only one chapter on Ajax. This isn’t reflective of today’s JavaScript. I’m not saying that JavaScript isn’t still used in these ways, but writing a book is largely about making decisions and prioritizing. Spending one-fifth or one-sixth of a book on these subjects means more important content is being shorted.

What One Needs to Know

The second problem I’ve identified is what one needs to know to use JavaScript. This is still a problem today, one I wrestled with in writing my book. Take a relatively simple and common use of modern JavaScript: form validation. In order to perform form validation in JavaScript, one has to know about:

• Browser events and event handlers
• Writing functions
• Grabbing form element values
• Validating data by type
• DOM manipulation

That’s a lot of information, and some of it (specifically involving events) is browser specific. To highlight why this is a problem as a writer, let’s look at how one can write a PHP book:

1. This is an HTML page.
2. Viola! This is now a PHP page (i.e., file extension and PHP tags).
3. Here’s how to print something using PHP.
4. Here’s how to create a variable.
5. And so forth.

A book on PHP can be written in a linear way because how the language works allows for that. But that’s not possible with a JavaScript book. In fact, in my book, event handling is Chapter 8, writing functions is Chapter 7, form interactions is Chapter 10, and DOM manipulation is part of Chapter 9. But the reader has to be able to do something well before he or she gets to Chapter 10, so what’s the solution?

One option is to encourage use of a browser console to execute bits of JavaScript. I do this in the book, but that’s not an approach that gets relied upon as a teaching tool, as it’s really not how you’ll use JavaScript in the real world. Chapter 3, which is the last chapter before getting into the heart of the language, explains how to use a console to execute a single line or several lines of code, and later chapters use that interface to demonstrate concepts, but the book never relies on that route for you to practice new ideas. The actual JavaScript programming you do won’t be in a console interface.

The other solution I came up with is clearly a cheat, but sometimes one has to cheat. In Chapter 2, I demonstrate and discuss the bare minimum of things:

• Two events: onload and onsubmit
• Creating a simple function
• How to reference a form element

This is enough essential information in order to create forms the user can interact with, and have JavaScript do some teachable and demonstrable stuff in response. Plus, I justify the early introduction with the thinking that: A) most readers have probably dabbled a bit with JavaScript before picking up the book anyway, and, B) it provides a target to work towards.

By comparison, in some of the other books I’ve browsed through, prompt() is used to get input from the user and document.write is used to output results. I don’t know if this is legacy code or the writer’s way of addressing this complication, but it’s bad code, bad JavaScript. One never uses prompt() anymore and almost never uses document.write. It’s stunning, really. In many books, lots of information is conveyed partially using code one would never use. And these are books published within the last year or two.

I have a lot of sympathy for my fellow writers, as writing a book is hard, and JavaScript poses its own particular complications. But hopefully the choices I’m making will result in a good book that does a lovely little language the justice it deserves, and so rarely gets.

The book has three parts (you can see a rough TOC here), with Part 1 laying out the core information, Part 2 teaching the language in itself, and Part 3 introducing more advanced and newer uses of the language (frameworks, HTML5, server-side JS, advanced OOP stuff, etc.). The first draft of Part 1 is done. Chapter 1 explains what JS is and provides some context for using it in today’s environment. Chapter 2 includes a preview of what you’ll learn, and introduces some of the key concepts for using JS in an HTML page (the script tag, handling a simple event, etc.). Chapter 3 introduces the key software you’ll use: text editors and IDEs, browsers, and debugging tools.

Yesterday I submitted Chapter 4, which is the first chapter in Part 2. In it, I talk about how to create variables and assign values to them, and then explain the “simple” types: numbers, strings, and Booleans. The chapter ends with a discussion on type conversion, primarily from strings to numbers, as that can be a common cause of bugs. Tomorrow I’ll start on Chapter 5, which is control structures: conditionals and loops.

Right now the book is slated to be published in January 2012 (yes, yes, sorry for the delay). It should be available to read online as I write it through Safari’s Rough Cuts system. I’ll post those details once I have them.

Thanks again to everyone interested in the book!

• About This Newsletter
• On the Web => Build Seven Good Object-Oriented Habits in PHP
• On the Web => Improving Site Performance: “Smushing” Images
• On the Blog => Great Web Developer Resources
• On the Blog => More on Non-Relational Databases
• Q&A => Uploading Images to Multiple Directories
• Q&A => How Do You Price a Freelance Project?
• What is Larry Thinking => The JavaScript Problem
• Book Giveaway => “PHP for the Web: Visual QuickStart Guide” and “Effortless Flex 4 Development”
• Larry Ullman’s Book News => “PHP and MySQL for Dynamic Web Sites” (4th Edition) and “Modern JavaScript”

About This Newsletter

When it’s time for another newsletter to go out, about three weeks after the last one shipped, I take a look at my pool of possible newsletter links, questions, tidbits, and thoughts, and grab those I’m most intrigued by. As I organize them, sometimes a theme appears, sometimes not, and sometimes I can force a theme upon the newsletter. It turns out that this newsletter falls under the very broad theme of Web Development, covering the full range of HTML, CSS, JavaScript, PHP, and databases. This is where my professional IT career began, twelve years ago, and what most of my work and writing still orbits around today. I gather that Web Development is what most of you do, too. So for many of us involved on the two sides of this newsletter, this one could be titled Doing What We Do. I hope you’ll find a thing or two that piques your interest.

In the next newsletter, I think I might write about my experiences developing mobile applications using Flex 4.5 and Flash Builder 4.5 for PHP. And perhaps do a book giveaway for the fourth edition of my “PHP and MySQL for Dynamic Web Sites: Visual QuickPro Guide” book.

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 => Build Seven Good Object-Oriented Habits in PHP

I recently StumbledUpon a pretty good article titled “Build Seven Good Object-Oriented Habits in PHP“. As the name states, the article presents seven key qualities of good OOP programming, specifically in PHP (although the principles apply to most OOP languages). The best feature of the article is that it demonstrates each point using both bad and good code, clearly making the case for each recommended habit. The article begins with some basic and specific OOP—for example, not making properties public—and moves on to more advanced and abstract OOP theory, such as cohesion and design patterns. All in all, well worth the read if you’re doing OOP in general and OOP in PHP more specifically.

On the Web => Improving Site Performance: “Smushing” Images

In trying to improve my site’s performance, starting with using the YSlow! Firefox extension, I came across the concept of “smushing” images. Smush.it is a Yahoo! service (which is why it’s tied to YSlow!) that optimizes images in such a way as to reduce their size without adversely affecting image quality. I believe I reduced my site’s total image size by about 10-15%, which isn’t huge, but when you’re talking about Web site optimization, every little bit helps. The only thing to be aware of is that sometimes GIFs will get turned into more efficient PNGs, meaning you’ll need to change your HTML accordingly (e.g., from image.gif to image.gif.png).

On the Blog => Great Web Developer Resources

Earlier this month, I posted on my blog a few really great Web developer resources that I came across while doing a last wave of research before writing my JavaScript book. In particular, both Mozilla and Opera have excellent articles discussing the core components of Web development: HTML, CSS, and JavaScript. (Mozilla maintains JavaScript, so that site also has the official JavaScript language reference.) You can definitely get lost following all the threads, but there’s a lot of excellent information presented on just these two sites.

On the Blog => More on Non-Relational Databases

In a newsletter a while back, I posted a blip about MongoDB, one of several new non-relational (aka, no-SQL) databases that have come up in the past couple of years. On my blog, I’ve posted a few more resources, including links to longer articles about several different non-relational databases and the concept as a whole.

Q&A => Uploading Images to Multiple Directories

In his reply to my previous book giveaway, Steven had asked what benefits there are to using multiple directories and subdirectories to store file uploads (he had noticed that Facebook does this). The key benefit, to me, is that taking this approach doesn’t break the server! Most of us never encounter this problem, but there are actual limits as to how many files and folders can be in a single directory. The exact allowed value differs from operating system to operating system (and, depending upon the operating system, the selected file system format can also have an impact), and the value is normally quite large. However, if you take a site like Facebook, with a half a billion (or whatever) users, and if each user uploads just ten images, that’s five billion files! The simple fact of the matter is that if you expect a site to have more than a few hundred uploaded files, you have to store files within multiple directories.

The second reason for dividing where files are stored is it will improve the site’s performance and possibly some of the user interface aspects. Any page that has to list the contents of a directory would benefit from that directory being just one of many, storing a subset of the entire body of files. On a project I worked on years ago, with the potential for thousands (or more) of users, we used a directory structure X/Y/name, where X was the first letter of the user’s last name, Y was the second, and name was a unique identifier, such as the person’s username. So, in that scheme, if I registered with a username of “trout”, my images directory would be u/l/trout. That particular site never lasted long enough to put this approach to the test, but I have reason to believe it would have held up.

A follow up question, then, is how to handle a lot of simultaneous file uploads. The HTTP protocol, through which most Web pages are loaded in the browser, is not a good protocol for transferring large amounts of data. A better solution is to embed a Java or Flash application in the Web page and have that application transfer the data (such applications can do so over other protocols).

Q&A => How Do You Price a Freelance Project?

I was recently asked by someone via email how to go about pricing freelance projects. I don’t know if I’ve discussed this before, and I thought it worth some paragraphs here.

There are two broad factors for determining a rate: global and personal. The global subfactors include supply and demand, implied technical difficulty, regional considerations, and so forth. For example, Web development is still in high demand, but there are a lot of people doing it, so that lowers the general rate. Mobile app development is in high demand and there aren’t quite so many people doing that, so that raises the general rate. Oracle database administration and design is implicitly more technically difficult, and therefore pays better, than MySQL database administration and design. In theory, people in, say, England will charge more than those in, say, Vietnam. But due to a global economy, this consideration is far less binding for many jobs. All of these global factors create a range of rates, from $X to $Y. Before looking at your own situation, you should be aware of a reasonable global rate range (a little research should do it), as you probably don’t want to be charging less than $X or more than $Y, regardless of your personal details. (With some exceptions: when someone hires Eric Meyer to do a CSS project, he can probably charge whatever he wants.)

The personal subfactors start with your own level of expertise and experience. If you’ve been doing, say, Web development for ten years, and have a nice portfolio, it’s reasonable to charge more than if you’re just starting out. If you’ve written a book on a particular subject, you can apparently charge more, whether that’s reasonable or not! Next, you need to factor in your own supply and demand: how busy you are, how badly you need the job, and so forth. One of the hard things about working independently is saying “No” to work, regardless of how busy you already are. But if you really need the work, it’s natural to charge less (in the hopes of improving the odds of getting the job), and if you don’t need the work so much, charge more (with the mentality of “if I am going to do this job, it has to be worth my while”). Finally, you may have to consider your business principles. For example, I get paid nothing for a fair amount of the work I do, such as answering questions in the support forums or via email, or sending these newsletters (actually, those things all cost me some money, but there’s a marketing benefit to them), and I charge educational organizations and non-profits a fraction of my commercial rate. All of these personal factors go into tweaking the global rate to come up with your specific rate, and these personal factors differentiates the price you would quote for a job compared to the price that the person in the building next to you would estimate for the same job.

If there are two broad factors, there is one specific one: the project itself. I charge less if I’m interested in the project, if it’s in an area I’d like to get more involved with, if I feel good about the client (such as the likelihood of more work from that same client), and so forth. I charge more if the opposite is true. And, of course, the total amount has to be commensurate to the complexity and demands of the project itself. And when coming up with a project price, remember that projects almost always take more effort than you were expecting, and how much more effort is equal to how new the technologies and processes involved are to you (e.g., it’s taking me a few days to do my first mobile app using Flex but it’ll probably take me just a couple days to do the next one).

What is Larry Thinking? => The JavaScript Problem

I’m beginning to work full-time (or nearly full-time) on my next book, “Modern JavaScript: Develop and Design”. This book is based upon a proposal that I did about two and a half years ago (I think) for a different publisher. The goal of the book is not just to teach JavaScript but to address what I’m calling The JavaScript Problem. The JavaScript Problem is that the language’s design, capabilities, and history make it unlike any other language. Let’s look at these criteria in reverse order (Chapter 1 of the book, which is nearly written, discusses all of this in more detail).

JavaScript’s history is an ugly one and the end result is that today’s JavaScript is a vastly different beast than that created in 1996. In the late 1990′s, basically you had JavaScript for the Netscape Navigator browser and JScript (similar, but not the same) for Internet Explorer. Programming in JavaScript required lots of conditionals checking not only the browser type but its version, as there would be significant changes from versions 4 to 4.5 to 5. And, at best, JavaScript was used for form validation, but mostly it was used to create annoying alert messages, pop-up windows, and trivial applications of eye candy. Because JavaScript was used entirely within the Web browser, and because it wasn’t taken very seriously by “real” programmers, JavaScript was mostly the domain of client-side Web developers.

Thanks largely to Ajax, JavaScript today is a much more useful tool than it was fifteen years ago. And ironically, even though there are more types of browsers in use—Netscape became Firefox, Apple has Safari, Google has Chrome, and Opera still gets the occasional mention—and therefore more versions, programming to account for the variations has become much easier. Odd as that may sound, it’s due to a change in approach. In today’s JavaScript, instead of coding for the browser or version, one programs for what the browser and version can support. For example, instead of checking the browser version and knowing that these browsers can perform, say, DOM manipulation, JavaScript programmers now just run a test to see if the browser, regardless or type or version, can handle DOM manipulation:

if (document.getElementById) { // Go ahead!

This change in approach is both simple and brilliant. If you want to see if it’s safe to use the getElementById()
method, just check if the Web browser supports it! Part of the reason this new approach works is that even though there are more browsers out there, they have come a long ways towards adopting standards (even Internet Explorer is better, albeit not where it should be).

JavaScript’s history is a problem for three reasons. First, people not up to date with what JavaScript can do, or how to program JavaScript properly, are inevitably misusing or underusing the language. Second, those of us who’ve been working with JavaScript since the early days have to undo our own bad habits. Third, those new to the language will no doubt run across older code, thereby running the risk of picking up their own bad habits, even when learning from fresh. I personally believe that part of the reason there aren’t more good JavaScript books out there is that most of these books are just updates upon updates of books written about the old, now thoroughly-outdated, JavaScript.

In terms of JavaScript’s capabilities, what used to be a language for playing sounds in the browser (ugh) or creating scrolling tickers (ugh), can now do dramatic and wonderful things: DOM manipulation, server-side requests via Ajax, useful animation, and more. “Web 2.0″—a term I despise—is largely JavaScript-based (Rich Internet Applications, RIAs, using Flash still use JavaScript, too). In fact, just a few of the ways that today’s JavaScript can be used, besides in a Web page, include:

• In PDFs
• Internally in many of Adobe’s applications
• To create desktop applications
• As a server-side alternative to PHP or the like

JavaScript is still mostly used as a Web browser enhancement, but what you can do with the language far exceeds that.

Finally, there’s JavaScript’s design. To start, JavaScript is an object-oriented language, but it’s not your typical object-oriented language. In fact, it’s a prototypical object-oriented language. What does that mean? In a typical OO language, which is to say almost all of them, programmers define classes and then create instances of those classes. The typical OO language also has its own defined classes, for common types like Strings, and common needs. JavaScript has its own defined classes, too, but programmers do not create their own classes. Instead, in JavaScript you can create your own object, with its own properties (variables) and methods (functions), and then use that. You can also, thanks to the prototype property, dynamically change the definition of any object, including the core JavaScript objects like String. In simple terms, this means you can alter what information an object can store and what that object can do on the fly (Ruby allows for this, too, although Ruby is not a prototyped language). This key difference in how JavaScript is designed is what makes it possible for true JavaScript wizards (such as John Resig, who created jQuery and worked for Mozilla until recently, or Douglass Crockford, a JavaScript expert at Yahoo!) to do the magic that they do. It’s also what makes modern JavaScript, on the high end, daunting for some new to the language.

The goal of “Modern JavaScript: Develop and Design” is to thoroughly teach today’s JavaScript, of course, so that readers can do what they want/need to do. But it’s important to me that the readers understand why that’s the way to do it, too. JavaScript as a language has plenty of baggage that comes with it, and that baggage needs to be opened and examined, and much of it tossed, in order to fully grasp and appreciate this lovely little language.

Book Giveaway => “PHP for the Web: Visual QuickStart Guide” and “Effortless Flex 4 Development”

There was a nice response to the book giveaway announced in the previous newsletter, with equal interest in the “PHP for the Web: Visual QuickStart Guide” (4th edition) and “Effortless Flex 4 Development” books. (I suspect that Flex’s ability to create mobile apps, thanks to Flex 4.5 and Adobe AIR 2.6 has increased the interest in Flex.)

My thanks to everyone for their interest in the books. I will be giving away copies of the fourth edition of my “PHP and MySQL for Dynamic Web Sites: Visual QuickStart Guide” in September, I expect.

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

As of Thursday, August 18th, the fourth edition of my “PHP and MySQL for Dynamic Web Sites: Visual QuickPro Guide” book is at the printer, which means it should be available at a store (or online) soon. The estimated date I have from the publisher is September 9th.

Almost all of the planned extra material (i.e., the stuff new in this edition) did make it into the printed book. This includes:

• Extra material on database design, JOINs, advanced SQL, and advanced MySQL functions
• A new chapter introducing the jQuery JavaScript framework, walking through form validation, DOM manipulation, and Ajax
• A new chapter introducing Object-Oriented Programming (OOP) in PHP, focusing on the basic syntax and principles, with examples recreating earlier MySQL-based scripts and another example performing date and time validation and manipulation

And this edition has a “Review and Pursue” section at the end of each chapter. That section, as in the fourth edition of my “PHP for the Web: Visual QuickStart Guide” book, has review questions on the material just introduced and prompts for how you can extend the newfound knowledge.

Unfortunately, due to space constraints, it was decided to pull out the appendix and make that a freely available PDF, to be downloaded from the publisher’s Web site. As the appendix is mostly about installation, I don’t think that’s too much of a sacrifice. The appendix also includes in this edition about a dozen pages on server (i.e., Apache) configuration and manipulation. But you can download the PDF to read that material. I don’t have any details as to how you go about finding the appendix on the publisher’s Web site, but will post that information when I have it.

For the first time ever, I’m doing screencasts to accompany the text. These videos will be embedded in some electronic versions of the book and made available separately (as I understand it). Most of the videos demonstrate and expand upon specific book content. I’m hoping to wrap up those videos in the next couple of days.

I’ve been wrapping up my initial extra research for my next book, “Modern JavaScript.” I’m looking forward to writing this and have a good sense of what the book will be. I’ve got a good bulk of the first two chapters written, and am hoping I’ll be able to make good progress in September.

Update: I believe the “release date” is September 9th.

The widget below shows Amazon’s current price for the book. Thanks to everyone in advance for their interest in this book (or any of them)!

• About This Newsletter
• What Were You Thinking? => Doing What I Do
• On the Web => Flash Builder 4.5 for PHP
• On the Web => The Modernizr JavaScript Library
• Q&A => What Do You Think About HTML5, CSS3, and the Future?
• Q&A => Where Are Your Thoughts on HTML5, Browsers, and Mobile Devices?
• What is Larry Thinking => Quantum Computing
• Book Giveaway => “PHP for the Web: Visual QuickStart Guide” and “Effortless Flex 4 Development”
• Larry Ullman’s Book News => “PHP and MySQL for Dynamic Web Sites” (4th Edition) and “Modern JavaScript”

About This Newsletter

Hello, hello, hello. For those of you in the United States, I hope you’re reading this in a quiet, air conditioned room (it’s been a brutally hot summer here in the states)! The three weeks since the last newsletter went by quickly, so much so that it’s actually been about four weeks! This newsletter begins with a reader response to my extended “Careers in IT”/”Doing What I Do” series, posted in the past several newsletters. Next you’ll find references to a few interesting things online, followed by answers to some questions I’ve received (thanks for those!). At the conclusion of the newsletter, there’s a blip about quantum computing, stemming from a fascinating article in The New Yorker a couple months back. All in all, this newsletter is largely about future tech. And, per usual, the newsletter ends with news about my forthcoming books. Oh, and there’s a book giveaway, too, with another one to follow in about a month or so.

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? => Doing What I Do

Over several issues of this newsletter, I discussed careers in IT and doing what I do. Something I’ve mentioned before is that a great thing about working in IT is that you can imagine, and realize, your own projects. This is not something that architects or doctors can do (not ethically, at least!). Specifically I mentioned that you’re able to try to create your own Next Big Thing, and can often do so with little introductory cost. Ross replied with a good point about how “aiming for ‘The Next Big Thing’ may skew the discussion a bit”. There are lots of levels of success, many of them far more attainable than trying to earn yourself billionaire status. Ross says that he tries to objectively analyze a project, determining the likelihood of making money and, at what level. Having a sense of that makes it easier for him to adjust the risk—financial and otherwise—he takes accordingly. The question Ross asks himself is “Can a creation be profitable and sustainable, and do the finances work [for the creator's] personal situation?”

My thanks to Ross for this input, and I hope I didn’t badly misrepresent his perspective. I agree that it’s important to look at projects not just in terms of how financially successful they can be, but also in terms of whether the reasonable estimate of success matches the amount of personal risk. And, Ross’s bigger point is that there are multiple goals one can shoot for, many of them far more attainable than others.

I would also point out that, so long as the personal risk and loss isn’t too great, there’s a lot of value that can be gained through failure. Not that I like it when projects fail, but as Walter Brunell said, “Failure is the tuition you pay for success.”

On the Web => Flash Builder 4.5 for PHP

Version 4.5 of the Flex framework makes it easier to develop applications destined for mobile devices, but version 4.5 of the corresponding Flash Builder IDE also comes with a nice bonus: even better integration with PHP.

PHP is my Web programming language of choice, and in version 4 of the Flex framework and the Flash Builder IDE, Adobe made a purposeful attempt to increase usage of Flex among the PHP community (this is also when I really began embracing Flex). For example, Flash Builder 4 comes with a wizard for connecting to PHP scripts, including creation of boilerplate PHP code. The new Flash Builder 4.5 IDE, recently released, comes in a couple of versions: Standard, Premium (with extra wizards, debugging tools, and profiling utilities), Flash Builder 4.5 for PHP Standard, and Flash Builder 4.5 for PHP Premium. The Flash Builder 4.5 for PHP versions were created in conjunction with Zend, and include an integrated version of Zend Studio 8. As both Flash Builder and Zend Studio are built upon Eclipse, this is a natural fit. And Flash Builder 4 started using Zend AMF to transmit data in Action Message Format between Flash applications and PHP scripts; the two companies have been working together for a while.

Needless to say, if you’re already doing Flex and PHP development (like I am), Flash Builder 4.5 for PHP is the perfect tool. The ability to do all the programming, both server-side PHP and client-side Flex, in one application, will save a lot of time. Just the debugging alone…Flash Builder 4.5 for PHP will let you debug both the PHP script and the Flash application without changing programs!

In terms of pricing, Flash Builder 4.5 Standard is $249.00, if purchased new, and Zend Studio is $299.00 (all prices are in US dollars and accurate as I write this). Flash Builder 4.5 for PHP Standard is $399.00, so there’s a decent price break compared to having the applications individually.

For a good, quick introduction to Flash Builder 4.5 for PHP, see this article at the Adobe Developer Connection.

On the Web => The Modernizr JavaScript Library

HTML5 and CSS3 add useful and cool new features, but, as always, browser support is still an issue. If you want to develop sites using cutting edge options, while still being backwards-compatible, a great tool to use is Modernizr. The concept is simple (and brilliant): Modernizr identifies what features the user’s browser supports and adds corresponding classes to the opening HTML tag. In your CSS, you can then add styling to just those classes. The result is that browsers that support, say, @font-face or canvas, will get the stylized version, and browsers that don’t, won’t. Modernizr also creates a JavaScript object that represents the browser’s capabilities. This object could be used to customize your JavaScript accordingly, too. And Modernizr has IE-specific tools, that add HTML5-like functionality to that browser.

For good, quick introductions, see the Modernizr site, this article at A List Apart, and this article at Web Designer Notebook. Modernizr just came out in version 2 and is open source.

Q&A => What Do You Think About HTML5, CSS3, and the Future?

HTML5 has received a ton of press and talk over the past few months and it definitely needs to be on any Web developer’s radar. Martin wrote in, asking me

Are you excited by HTML5, CSS3, the W3C’s direction of web standards and ultimately the future of where the web is going?  How do you perceive PHP and MySQL adapting within this ever changing environment?

The two simple answers are, “I’m kind of excited” and “I don’t think these changes will have a huge impact on PHP and MySQL”. As for the first answer, I’m not trying to be cynical or jaded here, but we’ve got to keep in mind the glacial pace with which new standards are adapted by corporations. It will be years before HTML5 will be reliable for all the major browsers. And one must keep in mind that the version of HTML5 that will eventually be formalized will undoubtedly be different than the version being discussed today. There are some great new features suggested in HTML5, such as local storage, an email input type, support for regular expressions, and many new elements, but it’ll be eons before those features are going to be universally (or universally-enough) usable in your sites. Now, tools such as Modernizr (just mentioned) help, and going ahead and adopting HTML5 today, with the knowledge that the site won’t work the same in all browsers, is only a problem if universal support is a goal; cutting-edge sites quite blatantly insist that visitors use a good, modern browser.

But the HTML5 proposal is a good thing, as it acknowledges what today’s Web is compared to the Web that was envisioned when HTML was created. On the other hand, where will the Web be in years from now when HTML5 is finally adopted?

I’m intrigued by some of the additions in CSS3, but not being a designer, they don’t have as much of an impact on me as HTML5.

As for PHP and MySQL adapting to HTML5, I don’t see that being much of an issue. PHP and MySQL are server-side technologies; HTML5 is the very definition of a client-side technology. For the most part, switching a site to HTML5 will have no more impact on the server side of things than if you switched from HTML 4.01 to XHMTL 1.1. Now, HTML5 does support client-side storage, so that may affect how you do some things, but I don’t think the impact on PHP and MySQL will be significant.

Q&A => Where Are Your Thoughts on HTML5, Browsers, and Mobile Devices?

On a similar note, Jorge sent in a question, asking me what I think of HTML5, both with respect to its impact on browsers and mobile devices (smart phones, tablets, etc.). In terms of browsers, I’ve just addressed that in reply to Martin’s question, but HTML5 for mobile devices is an intriguing prospect. The difference is this: the mobile platform itself means that mobile users will always have current, HTML5-capable Web browsers. I recently read an interesting article at the Chicago Tribune’s Web site (my home town paper) about using HTML5 for mobile app development (the article does not seem to be currently available). The Financial Times and ESPN just released new applications for mobile devices, but instead of creating standalone apps, they used HTML5 to make Web apps. HTML5 provides all the functionality the apps needed, such as content storage for offline reading, video support, and the ability to respond to touch and gestures. By creating a Web app, one application can reliably work on all the platforms, and the proceeds from the app do not have to be split with Apple or the Android store.

In no way am I suggesting that HTML5 is the only smart way to create mobile apps—there’s still plenty HTML5 can’t do, but this is an interesting turn of events that I, for one, didn’t see coming.

What is Larry Thinking? => Quantum Computing

In the May 2, 2011 issue of The New Yorker (one of my longtime favorite periodicals), there was a fascinating article by Rivka Galchen, titled “Dream Machine“. The article discusses the topic of quantum computing, which I believe will—someday—have a huge impact on our lives. I’ll try to summarize the key points as best as I can, considering I have no science background, but you can check out the article at a library or pay to read it online if you want the full story. Note that text in quotation marks below come verbatim from the article, starting with this assertion:

“With one millionth of the hardware of an ordinary laptop, a quantum computer could store as many bits of information as there are particles in the universe.”

Computers being used today are binary: at the most basic, fundamental level, there are bits, each bit representing either 0 or 1. Everything you do on your computer comes down to zeros and ones. These computers are based upon classical mechanics, discovered by Isaac Newton, although few of us ever think of that when surfing the Web, I’m sure. Classical mechanics, also called classical physics, still accurately describe much of the physical world at large, but on an atomic level, classical mechanics don’t hold up so well. Quantum mechanics, or quantum physics, does a better job of explaining what’s going on in the atomic and sub-atomic levels.

One principle of quantum mechanics is that the same particle can exist in two places at once (this is referred to as superposition). A second principle is that two particles can be entangled: they can communicate with each other “regardless of their distance in space and time”. Whoa. Taking these two principles, a quantum computer is built using quantum bits, or qubits, instead of regular bits. Unlike a regular bit, which can represent 0 or 1, a qubit can also represent 0 and 1, thanks to superposition. Whoa. Thanks to entanglement, qubits can “instantly share information”. Whereas data in a traditional computer must be transmitted from bit to bit, qubits will communicate instantly (and in an un-observable manner). Whoa.

This may all sound quite theoretical, too philosophical to be useful. But venture capital is going into this area, trying to build quantum computers for specific purposes, and Google’s been striving towards quantum-computing since 2006. Yale has already created a two-qubit computer, and Oxford an eight-qubit one. An estimate is that fifty to a hundred qubits would be as powerful as today’s laptop.

To test the capability of quantum computers, researchers try different tests, such as Grover’s algorithm, which is a quantum algorithm for searching an unordered database. A test of Grover’s algorithm can be as simple as four-card monte: four cards are face down, one is a queen, how many steps does it take to find the queen? A conventional computer using a straightforward algorithm finds the queen in an average of about 2.25 steps. (You could probably write that program yourself: check the first card; if that’s not it, check the second; if that’s not it, check the third; if that’s not it, then you know it’s the fourth. There are three steps, maximum, and sometimes you’ll get luckier.) A quantum computer can solve this puzzle in just one step. (The article explains how, but the explanation is complicated.)

That particular example may not sound that useful, so let’s turn to prime factorization (or integer factorization). Take two prime numbers and multiply them: say, 3 and 7 results in 21. You and I know looking at that number–21–that it is the product of 3 and 7. In an instant, most of us can reverse-engineer that calculation. But as the two original prime numbers get larger, it becomes exponentially harder to determine what two primes were used to make the resulting product. In 2009, researchers were able to determine the factors of a 232-digit number. It took hundreds of machines two years to do that. That particular number required 768-bits to be represented in the computer. The researchers estimated that just changing to a 1024-bit number would be about one thousand times harder. But why is this significant? Because prime factorization is the basis of modern cryptography, such as RSA. A conventional computer cannot reasonably break encryption schemes based upon prime factorization, but a quantum computer could break one in an afternoon.

This article on quantum computing was a really fascinating read, in my opinion, and I encourage you to check it out. I hope that my synopsis has been intriguing enough and sufficiently accurate. The article goes into further details about some of the key people involved in these fields, the histories of computers and physics, and some of the technical challenges to quantum computers, like qubit fidelity (e.g., the two-qubit computer solves the four-card monte puzzle in one step, but is only correct 80% of the time). And I didn’t touch upon the Many Worlds theory, which suggests that perhaps quantum computers function by performing calculations in parallel universes! Whoa.

Book Giveaway => “PHP for the Web: Visual QuickStart Guide” and “Effortless Flex 4 Development”

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

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

The complete draft of the fourth edition of my “PHP and MySQL for Dynamic Web Sites: Visual QuickPro Guide” book has now been submitted to the publisher and I’ve completed the rewrites on most of the book as well. Now I need to review the PDF layouts of each chapter, and then it’s off to the printer. Well, after the indexer and other important people take a crack at it first…

Some key new features in this edition will be:

• Extra material on database design, JOINs, advanced SQL, and advanced MySQL functions
• About a dozen pages on server (i.e., Apache) configuration and manipulation
• A new chapter introducing the jQuery JavaScript framework, walking through form validation, DOM manipulation, and Ajax
• A new chapter introducing Object-Oriented Programming (OOP) in PHP, focusing on the basic syntax and principles, with examples recreating earlier MySQL-based scripts and another example performing date and time validation and manipulation

The final page count for the work I submitted isn’t in, but I think I should be able to get the extra material in there.

Along with the above, I’ve removed references to PHP 6 (my “Dewey Defeats Truman” moment, as Paul so brilliantly named it), changed a couple of the examples, fixed any minor problems, and added a “Review and Pursue” section to the end of each chapter. That section, as in the fourth edition of my “PHP for the Web: Visual QuickStart Guide” book, has review questions on the material just introduced and prompts for how you can extend the newfound knowledge.

For the first time ever, I’m doing screencasts to accompany the text. These videos will be embedded in some electronic versions of the book and made available separately (as I understand it). Most of the videos demonstrate and expand upon specific book content. I’m in the process of doing those videos over the next month.

The book should be available in a store near you, and online, within two months at the latest.

In August, I officially turn my full-time attention to my next book, “Modern JavaScript.” Whohoo!

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

For this reason, I was quite happy to see the release of the book “Take Control of Scrivener 2“. I haven’t read it yet (ironically, I’m waiting to complete the book I’m currently working on first), but it’s high on my “to-read” list. Just scanning the 22-page sample that’s available, this looks like a good, fast resource. And at $10 (US) for the book, it’s a steal.

The chapter begins with a discussion of jQuery and JavaScript, and a sidebar on the best development tools to assist in your JavaScript programming (or, more importantly, debugging). Then the chapter shows how to incorporate the jQuery library and how to do a simple test of it. Next, you’ll learn how to select page elements using jQuery, and write an HTML form for the example to follow. After that is coverage of event handling and DOM manipulation, which will round out the example.

The first specific example is a widget cost calculator (similar to one done in PHP earlier in the book), with JavaScript performing the calculations and jQuery being used to show and hide error messages, change the classes assigned to elements, and update the content of the page.

The chapter concludes with several pages on Ajax. That specific example is a login form, with a server-side PHP script validating the login data, and jQuery updating the page appropriately.

I think the chapter presents a good introduction to jQuery, within the context of the entire book. Thanks to the new “Review and Pursue” section, many ideas for where to learn more or to practice what you’ve just learned are suggested.

As I said, I should be submitting this chapter today. Over the week I’ll finish the last remaining chapter: another new one introducing Object-Oriented Programming in PHP. After that, there’s just the appendix and introduction, neither of which will take much time. So I’ll have the first draft of the book done by the end of the month, and I’ve already completed seven chapters of the rewrites. I think the new edition is turning out well, and I’ll be happy to have it complete and on its way to the printer in July!