What Is Larry Thinking? #46 => JavaScript, Sexism, and Bad User Interface

October 21, 2011 — 10 Comments

In this edition…

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!

If you enjoyed this post, then please consider following me using your favorite social media, the RSS feed, and/or by subscribing to my newsletter. Or go crazy, and buy one or more of my books . Thanks!

10 responses to What Is Larry Thinking? #46 => JavaScript, Sexism, and Bad User Interface

  1. I’d like to see an example on how to make tool tips (I think that’s what they’re called?). Those boxes that popup when you mouse-over certain elements. Accordion style menus would be another one I’d like to see, too.

    I really enjoyed the bit on Unix file management by the way. I wish I had this 3 months ago before I decided to dive into Linux.

    • Thanks, Richard, for the suggestions. And I’m glad you benefited from the Unix permissions discussion. That’s an obtuse system, especially for beginners.

  2. Oh also, I’d love to hear your opinion on a Nettuts+ article about the best way to learn PHP. Here is a link:

    http://net.tutsplus.com/tutorials/php/the-best-way-to-learn-php/

    I already disagree with their book choices (except for the David Powers book, I’ve heard it’s excellent) but I’m curious to your thoughts on the rest of it. I gave a shoutout to your books in the comments section. =]

    • Hello Richard. Thanks for the question and for the shout-out on that page. In just skimming the article, there doesn’t seem to be much actual content there. Quick thoughts:
      #2: Installing XAMPP is a good recommendation, but Mac users should install MAMP.
      #4 If you go to Khan and Lynda, you’ll be overwhelmed with options.
      #5 I’ve not read any of those books but I’ve also heard very good things about David Powers’ work.
      #6 – #12 aren’t all that meaningful or useful.
      #13 is a good policy, but has nothing to do with learning PHP.
      I’ve seen some good stuff on Nettuts+ before, but this seems like a throw-away article to me. Just my opinion, of course.

  3. Larry, I haven’t been on the forums in a while, but as you know, I’m a big fan of JS and see lots of uses with it. The following are some things that would be great:

    1) Event handling (button clicking, keyboard events, form radio buttons, etc.)
    2) DOM manipulation (DHTML)
    3) Ajax (Honestly, I think this is essential.)
    3a) Using Ajax to search autosuggest functions like Google.
    3b) Returning string data vs. XML data vs. JSON, etc.
    4) Feature testing vs. browser sniffing
    5) How to write your own modules (i.e., best practices, self-invoking functions, etc.)
    6) Closure (And please, a good explanation. I had to wade through so many bad, bad explanations before I finally got this. This is an essential JS concept though, I think, especially since it ties so much into JS’s uniqueness of having functions in functions, and all the features that that unlocks.)
    7) Pseudo classes (Perhaps not essential, but of interest to some)
    8) Popular JS libraries (i.e., jQuery, swfobject, etc.) and usage examples
    9) JSON
    10) JS code quality tools (i.e., JSLint)
    11) JS best practices (Another essential part, I think. Douglas Crockford covers this well in his “The Good Parts” book, and it’s pretty much what JSLint tests against. The problem with JS, is that even people who *can* use it, often write really sloppy, inefficient code.)
    12) Minifying JS (Helpful tools)
    13) 100% unobtrusive JS
    14) Advanced but awesome end project: WYSIWYG editor

    Well, I could probably think of more, but that’s enough for now. Really, it’s amazing that JS is probably the most essential language to the evolution of the Web (and I think JS itself needs to evolve), but so few people properly understand it.

    Larry, I’m cheering for you to write a good book about it all (no pressure!).

    • Thanks, Jonathan, for the input. Almost all of these are already in the plan. I’m not sure I can do closures; we’ll have to see. It’s a tricky subject and not something everyone needs, particularly those that might be buying this book. I do like the idea of covering popular libraries. Thanks, too, for the support!

  4. Another suggestion I saw someone post was inline form validation using javascript. I’d also love to see how this would look while including the validation code for the server side in PHP, too. Seeing how these two go together would be awesome.

  5. Hi Larry,

    First off – I can’t tell you how excited I am that you are finally publishing a JavaScript book. I learned PHP through your Visual QuickStart/QuickPro Guides, and it’s because they were written in a logical, really easy to understand manner. I have always seemed to think differently than most people I know, and when someone tries to teach me something without explaining the logic behind it, I’m lost. I need to grasp the principles first and then the rest falls into place. Your books have always helped with that, and they’ve always been so full of actual examples that all along I’ve felt I’m making progress.

    So, on to my hopes for the JavaScript book. I’ve always known JavaScript was a big component of building websites but never been entirely sure what all it is capable of. Being first an HTML developer way back when, then learning CSS, then PHP and on to WordPress and MySQL, I feel like my skill set has been getting bigger but never really fully rounded out. Reading and hearing so much about HTML5 and the DOM and how that is supposed to change everything just reaffirms that I really need to figure out what JavaScript is for. Beyond the obvious building up of a basic skillset, I would really love to see some information about how you think JavaScript will continue to be extended into the future when more browsers implement HTML5 in more extensive ways. I’d also like to see an Ajax example, perhaps extending a PHP shopping cart to display the number of items in the cart immediately when the user adds something to the cart – before you even navigate to another page. I have a feeling my single biggest obstacle is understanding object-oriented programming better. I seem to be wired with a functional brain: I think of everything in steps. Objects still elude me.

    Maybe an appendix of more advanced JavaScript resources? I hear so much about JQuery these days, especially since mobile devices have exploded and so many still have no Flash, so a section of the more popular libraries or suggestions on where to learn more would be very welcome.

    It might also be helpful to readers to mention plugins or tools that you use to debug. I’ve used the Web Developer add-on for Firefox for awhile now and have recently started paying more attention to the little red X’s at the top of the bar; if there are any JavaScript errors, it will tell you exactly what they are. I did see that you mention a chapter on tools, so you’ve probably already got that covered.

    Good luck with finding the time to complete the book – I have a little one myself and have found myself with much less time for development than I used to have. But I think they more than make up for it. :)

    Sincerely,
    Elaine Shannon

    • Hello Elaine. Thanks for the input and for the very nice words on my work. I hope my JavaScript book can live up to expectations! As for your detailed thoughts (and thanks again!), Part 3 of the book is focused on next steps for both you, the developer, and for the future of JavaScript, including HTML5, frameworks, and hopefully popular libraries and mobile development. It’ll depend upon space. You’ll definitely get plenty on OOP, but in an accessible way. For rather complex reasons, I think JS is actually easy to approach in OOP terms, at least on the beginning to intermediate level. I’ve done a bit on debugging and debugging tools, but will probably amp that up during the rewrites.

      Thanks again for the detailed feedback. It’s very much appreciated. My first goal is giving readers the book they want! Oh, and congrats on the little one. They’re much better than work any day!

      Cheers,
      Larry

Trackbacks and Pingbacks:

  1. What Is Larry Thinking? #47 => Random Monkey Appearances – Larry Ullman - November 20, 2011

    [...] for your interest in what I have to say and do!What Were You Thinking? => Using JavaScriptIn my previous newsletter, I asked for input as to how you use JavaScript, what you know you’re confused by, what you’d [...]

Comments are great, but I'd strongly prefer any requests for assistance get made in the support forums. Thanks!