Digital Media and Communications Insights, Inc.::Newsletter Archives

Newsletter Archives

What is Larry Thinking? #28 (May 29, 2010)

In this edition...

About This Newsletter
On the Blog => HTML5 Video
On the Web => Second Excerpt from “Effortless Flex 4 Development”
On the Web => Google “recursion”
On the Web => Editra Editor
On the Web => Google's Ajax Libraries API
Q&A => What are the dangers with PHP's allow_url_fopen setting?
What is Larry Thinking? => Partly Cloudy with a Chance of Savings
Larry Ullman's Book News => “Effortless Flex 4 Development” and more

About This Newsletter

No particular theme this time, just some stuff I've found, the answer to a good question sent in some time back, and news about my forthcoming books. In my next newsletter I'll probably do a giveaway, but feel free to keep those questions and comments coming in the interim. As always, thanks for reading!

On the Blog => HTML5 Video

In recent weeks I've come across two new players for video in HTML5. Because HTML5 has a video element, you can now embed video in an HTML page without using a plug-in. The players that control the actual playing of the video are written in JavaScript. You can find more information about these two players, and HTML5 in general, here.

On the Web => Second Excerpt from “Effortless Flex 4 Development”

Peachpit Press, publisher of my forthcoming “Effortless Flex 4 Development” book, has published another excerpt of the book online, free for anyone to read. (Technically New Riders is the publisher, but New Riders is owned by Peachpit.) This article represents a few pages from Chapter 4 of the book, “Event Management”. It follows the previous excerpt (also from Chapter 4), which you should probably read first if you haven’t. The first excerpt largely discusses event handling theory; in this excerpt you’ll see how to turn that theory into actual code. Even if you don’t yet know Flex and ActionScript, you should still be able to follow along. Most importantly, Flex is largely an event-driven approach to application development (conversely, Flash Professional is primarily a timeline-driven approach), so this section is really a key insight into what it’s like to use Flex.

I’ve also completed one “5 Tips in 5 Days” blog posts series for Peachpit’s site, although it has not yet been published, and am working on a second now. One series will be specifically on the Flex 4 framework and the other will be on Flash Builder. Flash Builder, in case you’re not familiar with it, used to be called Flex Builder and is just a commercial IDE for developing using Flex. You don’t have to use Flash Builder as the Flex 4 framework and its SDK are available for free, but it does ease the process significantly. The book does not assume you’re using Flash Builder, either. There are specific instructions for how to create Flex applications using a text editor and the command-line IDE, but there are also areas that cover how you would do X or Y using Flash Builder. Most of the book focuses on the Flex framework, so it doesn’t matter what development tools you’re using.

On the Web => Google “recursion”

I can't remember where I first saw this, but as an amusing little diversion, trying Googling the word “recursion”. Someone at Google certainly has a clever sense of humor!

On the Web => Editra Editor

I've recently come across the Editra text editor, which is currently in its alpha release. Editra runs on most operating systems (there are installers for Windows and Mac OS X and you can install it on Linux/Unix from the source) and is free for personal use. It has all the basic text editor features and supports a ton of programming languages. It'll be interesting to see how this project evolves but keep it in mind if you're looking for a good, free text editor.

On the Web => Google's Ajax Libraries API

In my blog series on using YSlow! to test and speed up your Web site, I came across the concept of CDN. Short for content delivery network, this is something I hadn't personally considered before because it requires using multiple servers to provide content to the end user. For most sites, you won't be managing multiple servers; However, there is still a way to use CDNs, thanks to Google's Ajax Libraries API. In any situation, most of the content on your site will be stored on your server, including the media, CSS, HTML, that coming from a database, etc. But there is one thing you might easily be able to get elsewhere: some of the JavaScript.

Say you're using a common JavaScript framework, which many of us are by now. Normally you would upload a copy of the framework to your site. When the user loads your page in their browser, the browser will also need to load your copy of the framework, as it won't already have a copy (assuming this is the first visit). But, if your framework comes from another common server, it's possible that the user will already have a copy of that and will not then need to download it again, thereby speeding up the rendering of the page. This is where Google's Ajax Libraries API comes into play. Using it, you can tell the browser to download jQuery, MooTools, or whatever from Google. If the user has already been to a different site (completely unrelated to yours) that also used that same version of the same library from Google, the browser won't have to download the framework again.

Q&A =>What are the dangers with PHP's allow_url_fopen setting?

In a previous newsletter I had posted about the PhpSecInfo tool that will inspect your PHP configuration for possible security concerns. One reader, Jim, tried this and received a warning about PHP's allow_url_fopen setting being enabled and asked how dangerous this was. First, let's look at what allow_url_fopen does.

The fopen() function is used to open files. It can be overtly used in your code but it's also implicitly used by functions such as file_get_contents(), include(), and require(). These last two are important, because they're used all the time by even relatively basic PHP sites. If allow_url_fopen is set to true, then PHP has the ability to open URLs with fopen(): in other words, you can open files from other servers, not just those on your own server. If you're using include() and require(), you can include files from other servers, not just your own. In itself, this is not a security concern. The problem comes when an fopen(), include(), require(), or other functions make use of user-derived data.

For example, on my own site, where I have a separate section for each book I've written, the book's ID is passed in the URL. That ID value is then used to dictate which modules are included. Fortunately I run the ID through a switch and then determine the module to be included based upon acceptable values of the ID. I say "fortunately", because almost as soon as I revamped my site using this system, I started seeing error messages because malicious users were trying to change id=XXXX in the URL to id=http://www.somesite.com/somebadcode.txt. I checked out that somebadcode.txt file and it was a bunch of PHP code meant to inspect my server and dispaly information. If that file was included, the code would be include and run as if it were a PHP script on my own server. Not good! This didn't end up being a problem for me, because my PHP script was written to only acknowledge accepted values, but it could have been an easy way for hackers to get access to my site. Clearly, properly filtering the data was the fix, but disabling allow_url_fopen would prevent some problems even if my data wasn't properly filtered. This is kind of like the register_globals setting issue, which isn't a security risk in itself when enabled, it's only a security risk when your programming relies upon register_globals.

Even if allow_url_fopen is disabled, you still need to be careful when using user-derived data in any file-related calls, however. If I passed id=somefile.html in my URL and didn't validate the ID value before including that file, a user could change that to id=.htaccess (or whatever) in order to fish for potential information. And if you do need to open files on other servers, the recommendation is to use the cURL library instead.

What is Larry Thinking? => Partly Cloudy with a Chance of Upscaling

For the past year or so, there's been tons of talk about "Cloud Services". Amazon and Aptana were the first two companies offering cloud services that I came across (Aptana in conjunction with Jaxer, their server-side JavaScript tool), but there are tons of alternatives these days. Cloud computing, simply put, is Internet-based computing as opposed to local computing. For example, instead of installing Microsoft Office on every computer, a business might use Google Docs instead. There are many ways cloud computing can be used (just check out Amazon's services for a representative list), but the two most common purposes are data storage and data processing.

There are a couple of obvious benefits to using cloud computing. The first is reliability: by taking work off of your own computer and putting it on a more expansive network, you're tapping into presumably better infrastructure (and may also have secondary backups this way). Another benefit is ease of maintenance: somone else is now responsible for keeping the servers running and secure (and most likely this is a team of people with more knowledge and experience). A third benefit is scalability: if I max out my server's capacities, there's little I can do. But a cloud server is part of a large network that can balance and share the data and workload among many, many computers. And this brings me to how cloud computer can help the average Jane...

As Clint pointed out in response to a previous emails, cloud services are an excellent way to ensure that your Web sites can scale well but without spending too much money up front. From the research I've done on cloud computing services, how much you pay is based upon how much in terms of resources you use. If your site is really busy, has lots of data to store and process, you use more cloud services and get billed more, but your system doesn't crash or seize up. I think cloud computing is something anyone should consider on any project they suspect could be quite busy and demanding in the future. You just need to make sure that you're bringing in the income, or have money in reserve, should your usage spike and you get hit with that several thousand dollar bill!

Larry Ullman's Book News => “Effortless Flex 4 Development” and more

I am very happy to say that my “Effortless Flex 4 Development” book is finished and will be heading off to the printer soon. I think the book turned out pretty well and the feedback I've seen from third-parties was positive. The publisher was also kind enough to give me another 80 pages once it seemed clear that I wouldn't be able to cover everything I wanted in the originally allotted space. I'll be giving away a few copies of the book (probably in the next newsletter) and keeping everyone informed as to when it becomes available in bookstores.

After I wrap up a couple of little Web sites over the next week, I'm on to my “E-Commerce with PHP and MySQL” book. This book will also be written for New Riders, meaning it won't have the same steps and two-column structure as the Visual QuickStart/Pro Guides I often do. As I found on the Flex book, the lack of formal structure freed me up as to how I write about things. It allows me to discuss things in more depth and not necessarily come up with an example of every point.

For this e-commerce book, I'm going to create a rough table of contents which will be a guide as to what I plan on discussing. These will be the big topics like security, user interface, search engine optimization and marketing, etc. The book will use two example sites to demonstrate these concepts in terms of actual code. So I'll then develop all the code for both examples in the book before I do any writing. I can't normally write books in this way (because there's rarely one, concrete end goal), so it'll be interesting here. This approach will also give me some flexibility as to the final content depending upon the alloted pages. For example, I might have a chapter about adding Ajax features to one of the projects and this chapter would make it in if possible. If not, it could be published as an online extra. Once I get the working versions of both examples completed, I'll post those URLs here for anyone to look at, learn from, and provide feedback on.There's also a forum thread in which people can make suggestions as to what I do and do not discuss.

After I complete the e-commerce book, my hope is to begin on my self-published JavaScript book. I already started on it, some, and have a rough table of contents, but now it's time to really churn it out. The book is going to teach JavaScript in the same way I teach PHP: what you really need to know from A to Z. So you'll start by actually learning JavaScript, instead of just cobbling together code and not knowing why it works (or, more likely, doesn't). JavaScript is a comparatively small language in terms of variable types, functions, and so forth, so the learning will be the first third or 40% of the book. Then I'll demonstrate practical uses of JavaScript, which are applications of that knowledge. That section will include both writing JavaScript from scratch and how one would do the same things using frameworks (probably jQuery and at least one other example framework).

My intent is to put it online for free as a series of HTML pages and to also sell it as a PDF and in Kindle format through Amazon. It's not a problem writing the book myself, but in order to "publish" it, I'm going to need to use a program such as InDesign to lay the code and figures out in chapters myself. So I'm going to have to learn something new here.

I'm already in talks with Peachpit Press for what titles I'll do in 2011. Fourth editions of my "PHP for the Web: Visual QuickStart Guide" and "PHP and MySQL for Dynamic Web Sites: Visual QuickPro Guides" are likely candidates.

specializing in digital media technologies