I had specifically wanted to discuss PHP 6 because of its intended support for Unicode, which is what the code in the book requires for a couple of examples. Even though PHP 6 was shelved, the key components have since been integrated into PHP 5.2, 5.3, and the forthcoming 5.4. Transliteration, the ability to convert text from one alphabet to another, was demonstrated in the book using the PHP 6 str_transliterate() function. That function went belly-up, and PHP 5.4 now has the Transliterator class instead. The documentation for the class in non-existent, but here’s what I figured out…

As with many things in PHP, you can use the Transliterator class as an object or procedurally. Let’s look at the procedural approach first, which is what the book also does. The function that does all the work is transliterator_transliterate(). Its first argument is a either a string identifying the transliteration to conduct, or a Transliterator object. Its second argument is the text to be transliterated.

In the Transliterator class, transliterators are defined using the syntax from-to. So Bengali-Tamil will transliterate from the Bengali alphabet to the Tamil alphabet. Keep in mind this is just the replacing of characters from one alphabet to the corresponding characters in another. This is not translation!

To get the list of possible transliterators, invoke the transliterator_list_ids() method (Figure 1):

echo '<pre>' . print_r(transliterator_list_ids(), 1) . '</pre>';

Figure 1

Returning to the code in the book, in Script 14.4, trans.php, my name using the Latin alphabet was stored in a variable called $me. Then, an array of destination alphabets was created:

$me = 'Larry Ullman';
$scripts = array('Greek', 'Cyrillic', 'Hebrew', 'Arabic', 'Hangul');

Next, a for loop iterated through the array. Within the array, originally, the str_transliterate() function was called:

foreach ($scripts as $script) {
    echo "$me is " . str_transliterate($me, 'Latin', $script) . " in $script.\n";
}

With the updated Transliterator class, the proper syntax is now (Figure 2):

echo "$me is " . transliterator_transliterate ("Latin-$script", $me) . " in $script.\n";

And that’s all there is to it! (To reiterate, this does require PHP 5.4 or greater.)

Figure 2

To do the same thing using object-oriented programming, you’d first create a new Transliterator object:

$t = Transliterator::create("Latin-$script");

Then you call the transliterate() method of the object, providing the text to transliterate as the first argument:

$t->transliterate($me);

And there you have it!

The Transliterator class can be told to transliterate forwards, or in reverse, allowing you to go from an alphabet written in one language to an alphabet written in another.

• What Were You Thinking? => Bimonthly Newsletters
• On the Web => Security and Privacy Made Simpler
• On the Blog => My January 2012 Non-Resolutions List
• Q&A => How do you go about designing the main OOP classes for a project?
• Larry Ullman’s Book News => “Modern Javascript: Develop and Design” Done!

What Were You Thinking? => Bimonthly Newsletters

In the previous newsletter, I asked for input on the idea of changing the newsletter from going out every 3-4 weeks but being longer to going out every 2 weeks but being shorter. You were also able to vote in an online poll. About two-thirds of the votes were for the change, although the more passionate responses were against the change, as those recipients already felt they received too many newsletters and emails. I think what I’m going to do, as a happy medium, is to shoot for a schedule where the newsletters come out slightly faster, like every 2-3 weeks, and are slightly shorter. This should be feasible for me to pull off without overwhelming you.

Towards that end, you may note that there’s no “What is Larry Thinking?” section in this particular newsletter. With the new plan for the newsletter, I’m not going to be quite so rigid about what goes into each newsletter, limiting myself to just five or so significant pieces. The bulk of this newsletter answers a question on OOP design.

My thanks to everyone for their input. And please always feel free to provide any feedback, questions, comments, etc., that you may have. (Postscript: Several of you rightfully pointed out that I misused “biweekly” in the text of the newsletter, despite correctly using “bimonthly” in the heading. I indeed meant “bimonthly”, although “biweekly” has the same inexactitude in that it can mean both every two weeks and twice a week.)

On the Web => Security and Privacy Made Simpler

When I was writing my Effortless E-Commerce with PHP and MySQL book, I naturally did a bunch of research, particularly with regards to the various laws that apply. Understanding the programming behind an e-commerce site is relatively simple; understanding all the applicable laws and implications of doing e-commerce is complex. One of the sites I found to be quite useful was the United States Better Business Bureau (BBB).

I’m currently going through some items in my “to read” folder, and am reading, or perhaps re-reading, the Better Business Bureau’s PDF titled “Security & Privacy – Made Simpler. If you do any e-commerce, or even just Web development, in the U.S. or not, it’s worth your time. It’s a 22-page document that discusses almost every facet of e-commerce, such as:

• Developing a security and privacy plan
• Creating and communicating your security and privacy policies
• Good employee screening and policies
• Common hack/theft strategies
• General Internet security
• Proper handling of customer data
• Payment processing
• What to do in the event of a data breach
• A preview of international e-commerce considerations

The document also has many resources listed in these and other categories. You can download the PDF from that page, but there are also related FAQs and more on the BBB’s site.

On the Blog => My January 2012 Non-Resolutions List

I’ve never been much of a New Year’s Resolution person: if something is important enough to do, start today, not on some arbitrary date that happens to be the first day of the year. (Or, you know, January 2nd, because the first is a holiday and all.) But this year I happen to have quite a long non-resolutions list. The timing is entirely coincidental: I just happen to be done with my “Modern JavaScript: Develop and Design” book around this time, and I always have a long list of things to do between books. I recently posted on my blog about my immediate plans (aka, my non-resolutions list).

Q&A => How do you go about designing the main OOP classes for a project?

While “diving into” Object-Oriented Programming development in PHP, Chris had emailed me about how one sets up the core classes for an OOP-based site. The specific example—user management with login/logout, roles, etc.—is common and not complex, but Chris didn’t know where to start. In my opinion, OOP is easy enough to use once the classes have been defined; the difficulties arise from coming up with the proper classes in the first place. So let’s look at that process, in the abstract.

Programming is a matter of taking actions with data. In a linguistic sense, it’s very much a noun-verb relationship: the user submits form data to a server; the server stores data in a database; the user requests another page; the server pulls data from a database. Whether you’re using OOP or procedural code, you need to identify both the actions and the data first. What are all the verbs that the user or Web site needs to be able to do? What are all the nouns that will be involved in those actions? Once you’ve identified those attributes of the site, procedural programming focuses first on the verbs, OOP focuses first on the nouns.

To start designing OOP classes, one must first organize the types of data the site will work with, in detail. In a user management system, there’s one obvious noun: a User. The properties of a User include: userId, username, userPass, userRole, dateRegistered, and so forth. (Conventionally, OOP uses camel-case for variable and property names.) When you think you’ve identified the nouns involved, go back and see if all of the actions now have the data that needs to be involved. When a new person registers, a User is created (as both a PHP variable and a record in the database). When a person logs in, a User is retrieved from the database and created as a PHP variable. When a person logs out, the User PHP variable can be destroyed. To see if a person has authority to do X, you’d check the User->userRole property.

In some situations, there will be nouns with overlapping roles and properties, which would suggest that you should create a hierarchy of classes. I think of shapes as being the easiest example to comprehend. All two-dimensional shapes have some common attributes, such as area and perimeter, but triangles have three sides, rectangles have four, and circles have none (but do have a radius). When you find yourself in situations like this, you’ll want to design one master class, in this case, Shape, which you never create instances of. Then you define derived classes—Triangle, Rectangle, and Circle—that you would create instances of. Admittedly, knowing when to create a hierarchy can be tough. You might think with a user roles situation that you’d want common users and administrators as two separate classes, but the only difference between the two types is in what actions each can take, which is easily managed using Access Control Lists (ACLs) or the like. Or, put another way, everything about the two users is exactly the same except for the type, so there’s no need to create separate classes (unlike, by comparison, circles and triangles that have some overlapping properties but other very different ones).

Another common class to use on a site would be one for interacting with the database. You could create your own class for this purpose, or just use the MySQLi object or PDO or the like.

Even in a simple site with content and users, there are other clear nouns: the pages of content. Going back to the language analogy, there are some sentences that have a single noun—Johnny runs or A User logs out—but many have more than one noun—Johnny reads a book or A User views a page of content. The content, then, would also be represented by one or more classes, depending upon the variety in the content displayed. If the content is just information displayed within a template of HTML, then Content might have these attributes: contentId, title, body, createdBy, dateCreated, and dateUpdated. The createdBy could be as simple as a userID integer, or more formally be an actual User instance.

Depending upon how OOP-y you want to be, you may also create classes for generating the HTML pages (i.e., View classes) and for handling actions (i.e., Controller classes). Those move you into the realm of a true MVC architecture, which isn’t always necessary, though.

In asking the question, Chris didn’t originally know how to handle the logging in and logging out and registration and such, not knowing if one makes classes for those. Those are actions performed on, or using, objects, and don’t get represented as classes themselves.

Because I’m going to be writing the third edition of my “PHP 5 Advanced: Visual QuickPro Guide” this year, I expect I’ll be doing a lot of writing on the subject of OOP, design patterns, and the like. If anyone has any more questions or comments regarding these topics, let me know.

Larry Ullman’s Book News => “Modern Javascript: Develop and Design” Done!

I am very, very happy to say that my latest book, “Modern JavaScript: Develop and Design”, is officially done. Like done, done. Last week Monday, I submitted the last chapter to be written, Chapter 13, Frameworks. In it, I quickly discuss how to choose a framework, when you should use a framework, and some common libraries (as a framework alternative). The bulk of the chapter introduces and uses jQuery and the Yahoo! User Interface (YUI) Library. For both I explain how to perform common tasks—selecting DOM elements, DOM manipulation, event handling, and Ajax, and then walk through more advanced examples. For both, the chapter explains an autocomplete example, using a PHP script as the data source. For jQuery, I also discuss the DataTables plug-in. For YUI, I also discuss and demonstrate the Yahoo! Query Language (YQL). For it, I go through a couple of examples, including fetching a weather report and a stock quote. (For the record, I specifically target YUI3, which is an improvement over YUI1 and 2, even if some of the framework is currently in beta.)

Chapter 13 is the first chapter in Part 3 of the book, Next Steps. I already wrote Chapter 14, Advanced JavaScript, which has a heavy focus on closures. Chapter 15, A PHP and JavaScript Example, creates a pseudo-complete auction system. Auctions are set to expire on a certain date and time. Logged-in users can bid on items. All dates and times are shown using Coordinated Universal Time (UTC) or the user’s timezone, if the user is logged-in. Then, JavaScript used to enhance the experience. This includes using Ajax for the login and bid forms, retrieving the latest bids via Ajax (and updating the table of bids with them), and creating countdown timers that show the amount of time left in an auction, when that’s less than an hour. I think the chapter turned out well, and it emphasizes the various ways to pass data back and forth between PHP and JavaScript, a common point of confusion.

Not only is all of the initial writing is complete, but I’ve also done the rewrites on the entire book, and I just—moments ago—finished reviewing the PDF layouts, which is the last step before the book goes to the printer. (As you can tell, there are a lot of overlapping steps here at the end.) I believe the book will still ship, as originally planned, at the end of February.

In support of the book, I’ll also be writing a couple of articles (published online for free) and create some screencasts (to be provided in various places).

If you present video on Web sites, whether you use the JW Player or not, it’s worth checking out to know where things stand. LongTailVideo intends to maintain and update that article as changes in the industry (such as statistical changes and the like) evolve.

If you check out the corresponding README file on GitHub, you’ll find links to other presentations created with impress.js. A couple of presentations are quite useful in that they demonstrate, in my opinion, an overuse of impress.js. Those particular presentations use the rotation feature to such as extent that it makes one dizzy, which is normally not a good quality in a presentation (although one presentation is talking about 3D transformations, so there’s some justification there). One does worry that if impress.js catches on too much, we’ll all be sick of rotating transitions in no time.

For an example of another interesting use of impress.js, check out lioshi toiles, where impress.js creates a site that displays artwork in a truly interesting way. Taken a step further, Al Ingham’s site, uses impress.js for custom navigation and presentation, while still providing direct links to specific pages across the top of the page (because walking through all the “slides” to get where you needed to be is unreasonable).

If only I had any design skills whatsoever…

I am very happy to say that my latest book, Modern JavaScript: Develop and Design, is official done. Well, not done, but close enough to blog about it. I just submitted the last chapter to be written, Chapter 13, Frameworks. In it, I quickly discuss how to choose a framework, when you should use a framework, and some common libraries (as a framework alternative). The bulk of the chapter introduces and uses jQuery and the Yahoo! User Interface (YUI) Library. For both I explain how to perform common tasks—selecting DOM elements, DOM manipulation, event handling, and Ajax, and then walk through more advanced examples. For both, the chapter explains an autocomplete example, using a PHP script as the data source. For jQuery, I also discuss the DataTables plug-in. For YUI, I also discuss and demonstrate the Yahoo! Query Language (YQL). For it, I go through a couple of examples, including fetching a weather report and a stock quote. (For the record, I specifically target YUI3, which is an improvement over YUI1 and 2, even if some of the framework is currently in beta.)

Chapter 13 is the first chapter in Part 3 of the book, Next Steps. I already wrote Chapter 14, Advanced JavaScript, which has a heavy focus on closures. Chapter 15, A PHP and JavaScript Example, creates a pseudo-complete auction system. Auctions are set to expire on a certain date and time. Logged-in users can bid on items. All dates and times are shown using Coordinated Universal Time (UTC) or the user’s timezone, if the user is logged-in. Then, JavaScript used to enhance the experience. This includes using Ajax for the login and bid forms, retrieving the latest bids via Ajax (and updating the table of bids with them), and creating countdown timers that show them amount of time left in an auction, when that’s less than an hour. I think the chapter turned out well, and it emphasizes the various ways to pass data back and forth between PHP and JavaScript, a common point of confusion.

All of the initial writing is now complete. I’ve also done the rewrites on the first nine chapters. I still have to do the rewrites on the last six chapters, but that won’t take long. I will also be doing supporting videos and articles related to the book.

I believe the book will still ship, as originally planned, at the end of February. I am now going to go celebrate!

The main reason I wanted to use PHP6 when I wrote the third edition of my “PHP and MySQL for Dynamic Web Sites: Visual QuickPro Guide” book is the intended support for Unicode. I had not seen this before, but I guess the attempted move to Unicode resulted in PHP scripts requiring twice as much memory as before, with a noticeable lag in performance. This is why the developers had to scrap those plans. But PHP 5.4 has “inline support” for several new languages, including Japanese and some dialects of Chinese. In other words, PHP5.4 has kind of a Unicode-light support. This Unicode support won’t be activated unless specified during the installation process.

I’m not sure where this leaves actual PHP6, but PHP5 is certainly a most excellent tool in its own right. I did use PHP5.3 in the fourth edition of my “PHP and MySQL for Dynamic Web Sites: Visual QuickPro Guide” book, and will make use of PHP5.4 in the third edition of my “PHP 5 Advanced: Visual QuickPro Guide”, due out later this year.

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

Please use the poll below to vote. If you have any specific comments, please post them using the comments form. Thanks for your input and for your interest in what I do!

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…