In this edition…

• About This Newsletter
• What Are You Thinking? => The JavaScript Book
• On the Web => Improving Application Performance
• On the Web => Opera Dragonfly
• On the Blog => UTC and Time Zone Support in MySQL
• On the Blog => How I Cut My Bandwidth in Half
• Q&A => Should I use PHP or JavaScript to Handle API Data?
• What is Larry Thinking => Doing What I Do: Training
• Larry Ullman’s Book News => “PHP and MySQL for Dynamic Web Sites” (4th Edition) and More!

. In this one, I’ll look at using cookies. Neither is that difficult, but as with all things regarding frameworks, the solution may not be obvious at first. And there are some ways to make use cookies in Yii in a more secure manner.

I’m often asked why I like the Yii framework, which is easy enough to answer: for starters it requires PHP 5 and uses jQuery natively. Then I like how it auto-generates a lot of code and folders for you. From there, it just kind of works and makes sense to me. In other words, Yii feels right. And unless you really investigate the framework’s underpinnings, how it feels (and can you get it to do what you need to do) is a large part of the criteria in making a selection.

The question I can’t really answer is what advantage Yii has over the X framework. The only other PHP framework I’ve used extensively is the Zend framework. The Zend framework has a lot going for it and is worth anyone’s consideration. To me, its biggest asset is that you can use it piecemeal and independently (I’ve often used components of the Zend Framework in Yii-based and non-framework-based sites), but I just don’t like the Zend Framework as the basis of an entire site. It requires a lot of work, the documentation is overwhelming while still not being that great, and it just doesn’t “feel” right to me.

Admittedly, Opera is about the fourth browser on my list (after, in order, Safari, Chrome, and Firefox), but the release of Opera Dragonfly may just change that for me, at least when it comes to Web development. Historically I’ve always relied upon Firefox’s Firebug extension when I need a good development debugging tool, but the Firefox browser has become such a memory hog for me that I’ve stopped using it on a regular basis. Of course, it’s probably a memory hog exactly because I’ve installed so many extensions (Firebug and the Web Developer Extension and …)!

On a cursory glance, Dragonfly may have everything I need:

• DOM viewer
• JavaScript debugger, allowing you to set breakpoints, inspect the values of variables, and set conditions to watch for
• HTML and CSS editor
• Resource inspector (what resources are loaded by the page)
• Network traffic tool, a must for debugging Ajax, including the ability to craft your own requests to see the response
• And more.

Unlike Firebug and other extensions, Dragonfly is built into Opera. Also unlike any comparable tool, Dragonfly can be used for remote debugging, including content destined for mobile devices or televisions!

I’m currently working on the fourth edition of my “PHP and MySQL for Dynamic Web Sites: Visual QuickPro Guide” book, due out later this summer. In it, I discuss how to effectively use MySQL’s support for time zones. Specifically, there’s an argument to be made for storing dates using Coordinated Universal Time (strangely enough, abbreviated UTC). UTC is commonly the same time as Greenwich Mean Time (GMT), except during the summer when the UK is an hour ahead of UTC. And that’s the point of using UTC: storing times (and therefore dates) in a format indifferent to any particular time zone. By comparison, my forum software or my blogging software may likely be storing times using the local time zone for the server. That may not seem like a problem until I move the site from one server to another in a another time zone, thereby introducing a disparity in the times. How critical of an issue is that? Well, it depends upon the application, but there’s an easy fix: storing times and dates in UTC.