• About This Newsletter
• What Are You Thinking? => Using JavaScript
• On the Web => Amazon Silk: A New Mobile Browser
• On the Web => Steve Jobs and Dennis Ritchie, in Memoriam
• On the Blog => Why There Are Few (No?) Good JavaScript Books
• Q&A => Could You Explain File Permissions?
• What is Larry Thinking => Sexism and Bad User Interface
• Book Giveaway => “PHP and MySQL for Dynamic Web Sites: Visual QuickPro Guide” (4th Edition)
• Larry Ullman’s Book News => “Modern JavaScript: Develop and Design”

About This Newsletter

Life is busy here and I’m well behind schedule on all fronts, so this newsletter is getting out about a week to ten days late. I’m taking consolation in the fact that I’ve kept pretty close to a three-week schedule for the past year (about 15 newsletters sent in that time). Rather than blather on, let’s get on with the show!

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

So I’m working on my next book, “Modern JavaScript: Develop and Design.” As I write about in a blog post (also mentioned later in this newsletter), JavaScript is kind of a tricky language to write a book about, as a lot of information is required just to do a basic thing such as form validation. Like any of my books, I’m working hard to use lots of good, real-world examples to demonstrate the new information being taught. Thus far, with two real code chapters in the bank, most examples are based upon form validation and data manipulation. These are obviously crucial uses of JavaScript, and good ways to practice some of the early material. Some readers have let me know that they’re hoping to see lots and lots of examples, so I thought I’d go ahead and send a direct request out asking what, if any, specific examples or topics you’d like to see in the book. What do you know you need to use JavaScript for? What are you curious about? What have you seen that you know is confusing to you and you’d like clarification on?

All thoughts and suggestions are welcome and very much appreciated. As an incentive, I’ll go ahead and give away ten copies of “Modern JavaScript: Develop and Design” to people with the best responses.

On the Web => Amazon Silk: A New Mobile Browser

As you may have seen, Amazon announced their new lineup of Kindles recently, from the $79 base version to the $199 Kindle Fire, a rival to Apple’s iPad. One thing that piqued my interest about the Kindle Fire is that it includes a new, custom Web browser, named Silk. Amazon posted an introduction to Silk, along with a six-minute video, on their site, too. A lot on that page and in the video is marketing hype, but they raise some interesting points about the fact that Web browsers are fundamentally the same as they were 15 years ago, and aren’t ideal for today’s use, especially with all the mobile devices. Now the solution they came up with seems to be something akin to a reverse CDN: Whereas a CDN takes the load off of one server and shares it across a network of servers, Amazon Silk uses Amazon Web Services (AWS) to reduce the load on the device. From just what I’ve seen, it doesn’t seem like they’ve addressed a problem with browsers, but rather with the HTTP protocol, introducing their own gateway to improve the communications. It’ll be interesting to see what impact this new approach has, and how, if at all, it affects Web development in the years to come.

On the Web => Steve Jobs and Dennis Ritchie, in Memoriam

As I’m sure you’re all aware, Steve Jobs, one of the founders of Apple, passed away just recently. You may also know that I’m a pretty big fan of Apple. I first learned to program Basic on an Apple IIe, the first computer I purchased was a Macintosh Color Classic, and I’m probably on my 10th or 12th Mac by now. I’m not saying Macs are better than PCs, and they’re certainly not cheaper, but I definitely prefer them. A lot has been said and written about Jobs since his passing, such that I have little to add, except I would offer that I what I think was the most brilliant thing that happened during Jobs’s tenure was the ability to get non-Mac people to buy Apple products. For decades, if you purchased an Apple product, you were buying either a Mac or Apple software to run on a Mac. This accounted for at best about 5% of the computing population. Thanks to the iPod, iPhone, and iPad, almost all computer users and a majority of mobile phone users have one or more Apple products, whether or not they ever bought an Apple computer (and many of these people have since started buying Macs, too). Just brilliant, and the clear reason why Apple has become one of the most valuable companies in the world. Had you told me 15 years ago that Apple would become a dominant computer company and Bill Gates a prominent philanthropist, I wouldn’t have believed you.

Jobs’s other huge success was with Pixar, although he probably had less directly to do with Pixar’s success than the brilliant talents employed there. Jobs purchased what became Pixar from George Lucas, helped build it up, and when Pixar was purchased by Disney, Jobs became the single largest shareholder of Walt Disney. Quite the life. If you’d like one more little blip about Jobs, check out his Stanford commencement address from 2005. In it, Jobs talks candidly about work, life, and death.

Days after Steve Jobs passed away, Dennis Ritchie died, garnering much, much less media attention. Dennis Ritchie arguably had a bigger impact on computing and the world than Jobs, but is no household name. If you’re not familiar with Ritchie, all he did was create the C programming language, and helped develop the Unix operating system. C is one of the most important programming languages of all time. It has greatly influenced many other languages, and is still used widely today. In fact, PHP, Python, and Perl are all written in C! Unix, and its inspired variants such as Linux, is running most of the Internet, along with Apple’s iOS devices, Tivo’s, and many other devices.

On the Blog => Why There Are Few (No?) Good JavaScript Books

Just yesterday, I posted a blog article discussing my thoughts on why there are so few good JavaScript books. In part this post stems from time spent skimming through other JavaScript books and thinking “Really, you’re doing that in this book?” And, in part, in formally writing a JavaScript book now myself, I’m aware of some of the unique challenges that JavaScript poses for writers.

Q&A => Could You Explain File Permissions?

File permissions and file paths are probably two of the things that I get the most questions on, and that beginners are most often confused about. Some time back, Martin had asked if I’d explain file permissions, and even though a previous newsletter touched upon the subject, it’s worth going into again and in more detail. For a couple of reasons, I’m going to ignore Windows permissions and focus on *nix, which includes Unix, Linux, and Mac OS X. First, all these operating systems share the same permissions scheme. Second, statistically, most Web servers are running one of these operating systems. Third, permissions in Windows rarely need to be altered or cause problems, in my experience. And, fourth, you’re much more likely to be confused by *nix permissions, which are as follows…

File and folder permissions are an operating system’s way of dictating who can do what to that file or folder. There are three permissions that can be granted or denied: read, write, and execute. For files, read means the ability to literally open and read the file; write means the ability to modify the file; and execute means the ability to run the file (e.g., as an executable or a script). For directories, read means the ability to see the names of the files in the directory; write means the ability to modify the directory (such as create, rename, or delete files and folders therein); and execute means the ability to traverse the directory (i.e., be able to go into it). You’ll see these permissions represented by both letters—r, w, and x—and octal (base-8) numbers: 4 (read), 2 (write), and 1 (execute). These numeric values correspond to bits, meaning that different sums from 0 to 7 represent unique permission combinations. For example, 5 has to be read plus execute; 6 has to be read plus write; and, 7 is all three (5, 6, and 7 are the most common permissions digits you’ll see).

Now for every file and folder, these permissions can be set for three types of users: the owner, the owner’s group, and everyone. For example, on a Web server, you may have an account under the username trout. Your username will also be associated with a group, such as clients. Other people with accounts on the same server will have different usernames but may be part of the same group. There will also be other groups, such as staff or mysql. The permissions on any file or folder can be set as three octal digits, where the first digit represents the owner’s permissions, the second represents the owner’s group’s permissions (i.e., the permissions for other people in that group), and the third digit represents the permissions for everyone else. 644 permissions mean that you can read from and write to that file or folder, while everyone else can only read from it. Written using letters instead of octal numbers, you’ll see a file or folder’s permissions represented using 10 characters: the first reflects other details about the file or folder (I won’t get into that here); the next three are for the owner’s read, write, and execute permissions; the next three for the owner’s group’s read, write, and execute permissions; and the last three for everyone’s. Thus, the octal 644 becomes -rw-r–r–. The octal 755 is -rwxr-xr-x.

So there are the basics and the hieroglyphics you’ll occasionally see; what does this mean in actual application? For starters, you need to understand that the third category—everyone else—means everyone else on the computer, not everyone else in the universe. For example, if you create a directory with open permissions—777 or -rwxrwxrwx, that doesn’t mean anyone with an Internet connection can modify that directory’s contents. No. You can only modify a directory’s contents if you have access to the server’s file system, which means you’ve connected to the server via FTP or command line (SSH, telnet) access. And that kind of access requires using an account recognized by the server. But what about loading a Web page in the browser? Well, that is a type of server access, but not file system access. When a user goes to a Web site in the browser, the user isn’t interfacing with the server’s file system, but actually with the Web server software, such as Apache. Apache then does the actual accessing of the file system. So don’t fret that assigning open permissions to a file or directory means that anyone in the universe has access. That’s not the case.

But it is the case that an open file or directory on the server is accessible by any valid user on that server, assuming that other restrictions are not in place and that the user knows about its existence. For examples of restrictions, PHP can easily be limited as to which directories it can access and which it cannot. The same goes for Apache. In fact, the biggest security concern isn’t that people can access and manipulate your files and folders, but rather that software running on the server can. And this is where you have to be careful. Many hacks take advantage of security holes in scripts or applications to make Apache and PHP—the software already running on the server—do something malicious. All things considered, this doesn’t mean you should be cavalier about assigning open permissions, but it does mean that it’s not out-and-out irresponsible to use them when needed. Speaking of which…

The last real-world issue you’ll come across, which is a big complication for many, is establishing the correct permissions to allow for file uploads, or for PHP to write a text file, and the like. When you upload files to the server using FTP, or even create a directory using FTP, the owner of the uploaded file or folder will be you. The PHP script that needs to write to that text file or directory (in this case, “write” means to modify the directory by moving a file into it), will be running as a different user, namely the user that the Web server software (e.g., Apache) is running as (Apache commonly runs as “nobody”). In order for PHP to do what it needs to do, permissions need to be modified so that the Apache user can write to it. Normally this means using 755 as the permissions.

If you do need to create open directories and files, there are ways you can improve the security of using them, most of which I highlighted in that previous newsletter. For starters, always try to put these directories outside of the Web root directory, and then use a proxy script to safely fetch the contents. By doing so, you’re able to mitigate the increased security risk of having open directories and files by adding a layer of protection against accessing the content therein.

What is Larry Thinking? => Sexism and Bad User Interface

About fifteen years ago, when I was working at Borders bookstores (RIP), a co-worker got married. Afterward, she was talking one day about how she had gone into her bank to add her new husband to her account. The bank added her husband to the account and let her know that her husband would have to come in and authorize her before she could access the account herself. Wait, what? Yes, she went in, added her husband, and was no longer able to use the account that only moments earlier had been hers. This is because the bank’s policy was for men to be the primary account holders. As soon as her husband was added to the account, it became his account. This is just a lovely bit of institutional sexism, I think, especially when you consider that I’m talking about the mid-1990’s here, not 1950! I do not know what happened beyond that—I would hope she’d change banks, but beyond the sexism, it amazed me that a system was in place in which a person has the power to disempower themselves. A very strange concept.

My wife works in the field of education, which in the United States is known for many things, among them having broad, institutional dictums imposed upon schools and faculty. A frequent cause of problems is the software people are forced to use. Having software forced upon you is a hazard all employees face, but given the situation of public schools, such software is inevitably created under the worst of all possible situations:

• The software needs are identified by a committee of people, none of whom will actually be using the software.
• Undoubtedly a requirement is that the software can run on old, outdated computers.
• The budget will be tight.

Take these three things together, and you can plan on getting software that takes way too long to complete, that will be outdated and impractical upon its released, and that will be used for far too long from there. This sounds jaded, perhaps, and I’m certainly exaggerating some, but this is essentially the situation the American education system, if not the entire American government, is in when it comes to developing custom software.

The reason I’m thinking about this now, is that my wife was using one of these less-than-ideal applications the other day. The application itself is kind of like project management software and she was responsible for maintaining a project’s particulars through this system. Due to a lack of good documentation, she had misidentified her role on the project (within the system) and went back in to change her role. She selected what she thought was the right role for her account on that project and ended up removing her own administrative ability to manage the project. In other words, she locked herself out, and she was ostensibly the project manager! Again, why would someone create the ability for an administrator to de-administer themselves? And, what’s worse, absolutely no warning was given to my wife (i.e., the user) that this would be a consequence of the action about to be taken.

By comparison, my role on a project was just turned over to someone else, and part of that project involved making use of Amazon’s resources. Amazon, which I feel generally does everything right, did not allow me, the administrator, to just remove my name and email address from the system, thereby shutting out anyone’s access. Instead, to make the switch from me to this other person, I had to add her to the system and give her administrative access. She, then, could go in and remove my administrative access. Was this a bit more complicated? Yes. But it was the right way to handle this scenario and it worked without problem.

This, then, is a call to you: the next time you’re working on a Web site or application, think about the user interface and make sure it makes logical sense. Write the functionality so that administrators cannot disable their own access to the system. And include great documentation, and provide many, clear warnings when actions are about to be taken that are permanent. Oh, and if you’re running a bank, how about letting a person know that she is about to be blocked out of her own account? Or, you know, just make your policies less sexist.

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

As I expected, there was a wonderful response to my “PHP and MySQL for Dynamic Web Sites: Visual QuickPro Guide” (4th edition) giveaway. Unfortunately, I haven’t yet had the time to respond to everyone, or really anyone. For this I apologize, and I hope to do that within the week. So if you wrote in hoping for a book, rest assured that just because you haven’t heard from me yet means you won’t be getting a copy (conversely, it doesn’t mean you necessarily will, either). What really happened is that I’m just swamped. Apologies again!

I’ll be able to give away a few more copies of this book in a future newsletter.

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

I just submitted Chapter 5 of “Modern JavaScript: Develop and Design”, which means I’m about 30% done with the first draft (well, first submitted draft: there are multiple internal drafts prior to that). Progress is going more slowly than I’d like, but I’ve had sick kids and other personal issues making it harder to get to work. I always hope I’m about to turn a corner and speed up. One of these days, I will!

The first three chapters cover Part 1 of the book, which represents the fundamentals of JavaScript. Chapter 1 is a bit of an introduction to JavaScript overall. Chapter 2 provides a sneak peak at how JavaScript is used in a Web browser. Chapter 3 discusses and demonstrates several tools you’ll want to use.

The second part of the book is the heart of JavaScript as a true programming language. Chapter 4 covers simple data types (numbers, strings, and Booleans). Chapter 5 is on control structures: conditionals and loops. Now I’m turning to the fun stuff, and the topics that differentiate JavaScript from other languages. This includes objects (Chapter 6), functions (Chapter 7), events (Chapter 8), and the browser (Chapter 9). Hopefully by the next newsletter I’ll have those four chapters written. Hopefully!

Oh, and it may be time for me to buy a new gizmo!

In the Fall of 2010, I was finally able to purchase my name as a domain, allowing me to switch from using my company’s domain name (www.DMCInsights.com) to this domain for all my work stuff (the company is just me and no one cares about the company). In the process, I went from a custom site to using a WordPress-based one. The custom site primarily used PHP to handle the templates, but it also pulled some content, such as book errors, out of a database, and ran the newsletter system. Part of the justification for moving to WordPress was that I had previously (and finally) created a blog on a subdomain of my company’s site, and consequently the blog had the most frequent updates (by far). The “main” pages of my old site were not being updated with any frequency, making the site erroneously seem inactive, so the blog needed to be moved to the forefront. Another part of the justification was that by using WordPress, I would easily get a search engine for my entire site, something I had never gotten around to adding to the old site. In the process of switching, I also created a new template, based upon the Carrington Theme. The transition from the old site to this new one wasn’t perfect, but overall I think it went well enough. I’ve had to spend some time putting out little fires (there was an issue with redirects and I have to occasionally debug conflicts between the Flash widget and the navigation menus), but just by creating the new site, I was able to revisit and update all of the site’s content, which is something I should have done long ago.

The downside to using WordPress, or any Content Management System (CMS), is that general-purpose software is always going to be less efficient than a custom solution. WordPress, while being an excellent product, simply cannot be both flexible and optimal (from a performance standpoint). Once you start using plug-ins, performance is hindered even more so. After putting the new site online, I started analyzing its performance, using YSlow! (which I’ve written about previously). YSlow! makes specific recommendations for improving a site’s performance, which is a great way to get started. Once you know what you’re doing, however, or are looking at the site on a micro level, you’ll start paying more attention to what YSlow! reports as the resources being loaded: the number and size of requests being made. What I saw was a lot more CSS, JavaScript, and media being loaded than I had expected. I had specifically chosen a theme that was relatively simple in terms of images and yet… And then there are all those CSS files and JavaScript libraries! Ugh. The problem, in hindsight, was obvious: many of the plug-ins added their own CSS, images, and JavaScript to each page. The first, and most important, step for improving a site’s performance is common sense: Limit how much stuff the visitor has to download.

There are two ways of limiting the amount of content to be downloaded. First, you can outright eliminate the need. This is not always possible, but should be the first goal. With a standard site, you may be able to cut the amount of media used. You should also remove outdated references to CSS, JavaScript, and media once those assets are no longer needed. For example, after altering the settings for this theme, there were many resources that no longer needed to be loaded and you might encounter the same thing after a major redesign. Second, you can combine downloaded content together: multiple CSS files can be turned into one; multiple JavaScript files into one; and multiple images into a couple of CSS sprites. This isn’t always possible, or appropriate, but is worth investigating. With images, you can also use Yahoo!’s Smush.it tool to make images as small as possible. I was able to reduce the combined size of all the images by about 15% or more using it (your results may be better as this site uses few and small images). CSS and JavaScript files can be minimized to shrink their sizes down.

With this WordPress site in particular, restricting the number of images, CSS files, and JavaScript includes required actively tweaking, and sometimes replacing, the plug-ins in use. Some of the smartest plug-ins allow you to disable their automatic CSS and JavaScript inclusion, leaving it to you to manually add that content to the theme’s primary files instead. If you’re also using WordPress, take a moment, or a day, to really investigate what your plug-ins are doing. In some cases I was able to outright disable the plug-in and hardwire its functionality to my theme.

The second change I made to the site (in February), which had a huge impact on the site’s performance and its bandwidth was embracing a Content Delivery Network (CDN), specifically Amazon’s Cloudfront. Most of the site’s supporting resources—CSS, JavaScript, and images—are now being provided by Amazon’s worldwide network. The original goal for using the CDN was to provide content to visitors from servers closer to their geographic location, but this also means that a ton of served data is not being provided by my server. For the month of April, that amounted to approximately 8GB! When I first learned about CDNs, I assumed they were only for huge sites that could afford the expense, but Amazon’s Cloudfront has definitely changed that equation. My cost for the month of April: $1.77 (US). As I’ve written about separately, for the first year, the cost of Amazon’s Simple Storage Service (S3) is free, so next year this total cost will increase, but, still, it will be very cheap for what I’m getting.

If you run the numbers, in April I used 13GB less bandwidth than in January. Assuming that the incoming bandwidth is inconsequential, after deducting the 8GB served by Amazon’s Cloudfront, there’s still another 5GB of data that’s no longer being provided by my server. Much of that was by eliminating the amount of data to be downloaded (i.e., step one), but I suspect another key change, made in March, was the switch to new forum software. Again, the intent here was not to change the bandwidth, or really even to improve the performance, but rather upgrade an important and sorely outdated aspect of my site. The forum probably gets as much traffic as the main site and I strongly suspect that the new forum software is optimized more thoroughly than the open-source alternative I had previously been using.

As I said, I’m not even closing to hitting the bandwidth limitations on my hosting account, but less bandwidth used (for the same amount of traffic) is a good thing. Not only does it imply better performance for my site’s visitors, but it also means that it’ll be that much longer before I need to spend the extra money on bigger or more servers. But perhaps the more important lesson I learned is how useful it is to do thorough examinations of your Web sites, especially after the’ve been up for a while. A Web site is a dynamic thing that needs to be maintained and updated, not posted once and forgotten.