What is Larry Thinking? #44 => Web Development

In this edition…

About This Newsletter

When it’s time for another newsletter to go out, about three weeks after the last one shipped, I take a look at my pool of possible newsletter links, questions, tidbits, and thoughts, and grab those I’m most intrigued by. As I organize them, sometimes a theme appears, sometimes not, and sometimes I can force a theme upon the newsletter. It turns out that this newsletter falls under the very broad theme of Web Development, covering the full range of HTML, CSS, JavaScript, PHP, and databases. This is where my professional IT career began, twelve years ago, and what most of my work and writing still orbits around today. I gather that Web Development is what most of you do, too. So for many of us involved on the two sides of this newsletter, this one could be titled Doing What We Do. I hope you’ll find a thing or two that piques your interest.

In the next newsletter, I think I might write about my experiences developing mobile applications using Flex 4.5 and Flash Builder 4.5 for PHP. And perhaps do a book giveaway for the fourth edition of my “PHP and MySQL for Dynamic Web Sites: Visual QuickPro Guide” book.

As always, questions, comments, and all feedback are much appreciated. And thanks for your interest in what I have to say and do!

On the Web => Build Seven Good Object-Oriented Habits in PHP

I recently StumbledUpon a pretty good article titled “Build Seven Good Object-Oriented Habits in PHP“. As the name states, the article presents seven key qualities of good OOP programming, specifically in PHP (although the principles apply to most OOP languages). The best feature of the article is that it demonstrates each point using both bad and good code, clearly making the case for each recommended habit. The article begins with some basic and specific OOP—for example, not making properties public—and moves on to more advanced and abstract OOP theory, such as cohesion and design patterns. All in all, well worth the read if you’re doing OOP in general and OOP in PHP more specifically.

On the Web => Improving Site Performance: “Smushing” Images

In trying to improve my site’s performance, starting with using the YSlow! Firefox extension, I came across the concept of “smushing” images. Smush.it is a Yahoo! service (which is why it’s tied to YSlow!) that optimizes images in such a way as to reduce their size without adversely affecting image quality. I believe I reduced my site’s total image size by about 10-15%, which isn’t huge, but when you’re talking about Web site optimization, every little bit helps. The only thing to be aware of is that sometimes GIFs will get turned into more efficient PNGs, meaning you’ll need to change your HTML accordingly (e.g., from image.gif to image.gif.png).

On the Blog => Great Web Developer Resources

Earlier this month, I posted on my blog a few really great Web developer resources that I came across while doing a last wave of research before writing my JavaScript book. In particular, both Mozilla and Opera have excellent articles discussing the core components of Web development: HTML, CSS, and JavaScript. (Mozilla maintains JavaScript, so that site also has the official JavaScript language reference.) You can definitely get lost following all the threads, but there’s a lot of excellent information presented on just these two sites.

On the Blog => More on Non-Relational Databases

In a newsletter a while back, I posted a blip about MongoDB, one of several new non-relational (aka, no-SQL) databases that have come up in the past couple of years. On my blog, I’ve posted a few more resources, including links to longer articles about several different non-relational databases and the concept as a whole.

Q&A => Uploading Images to Multiple Directories

In his reply to my previous book giveaway, Steven had asked what benefits there are to using multiple directories and subdirectories to store file uploads (he had noticed that Facebook does this). The key benefit, to me, is that taking this approach doesn’t break the server! Most of us never encounter this problem, but there are actual limits as to how many files and folders can be in a single directory. The exact allowed value differs from operating system to operating system (and, depending upon the operating system, the selected file system format can also have an impact), and the value is normally quite large. However, if you take a site like Facebook, with a half a billion (or whatever) users, and if each user uploads just ten images, that’s five billion files! The simple fact of the matter is that if you expect a site to have more than a few hundred uploaded files, you have to store files within multiple directories.

The second reason for dividing where files are stored is it will improve the site’s performance and possibly some of the user interface aspects. Any page that has to list the contents of a directory would benefit from that directory being just one of many, storing a subset of the entire body of files. On a project I worked on years ago, with the potential for thousands (or more) of users, we used a directory structure X/Y/name, where X was the first letter of the user’s last name, Y was the second, and name was a unique identifier, such as the person’s username. So, in that scheme, if I registered with a username of “trout”, my images directory would be u/l/trout. That particular site never lasted long enough to put this approach to the test, but I have reason to believe it would have held up.

A follow up question, then, is how to handle a lot of simultaneous file uploads. The HTTP protocol, through which most Web pages are loaded in the browser, is not a good protocol for transferring large amounts of data. A better solution is to embed a Java or Flash application in the Web page and have that application transfer the data (such applications can do so over other protocols).

Q&A => How Do You Price a Freelance Project?

I was recently asked by someone via email how to go about pricing freelance projects. I don’t know if I’ve discussed this before, and I thought it worth some paragraphs here.

There are two broad factors for determining a rate: global and personal. The global subfactors include supply and demand, implied technical difficulty, regional considerations, and so forth. For example, Web development is still in high demand, but there are a lot of people doing it, so that lowers the general rate. Mobile app development is in high demand and there aren’t quite so many people doing that, so that raises the general rate. Oracle database administration and design is implicitly more technically difficult, and therefore pays better, than MySQL database administration and design. In theory, people in, say, England will charge more than those in, say, Vietnam. But due to a global economy, this consideration is far less binding for many jobs. All of these global factors create a range of rates, from $X to $Y. Before looking at your own situation, you should be aware of a reasonable global rate range (a little research should do it), as you probably don’t want to be charging less than $X or more than $Y, regardless of your personal details. (With some exceptions: when someone hires Eric Meyer to do a CSS project, he can probably charge whatever he wants.)

The personal subfactors start with your own level of expertise and experience. If you’ve been doing, say, Web development for ten years, and have a nice portfolio, it’s reasonable to charge more than if you’re just starting out. If you’ve written a book on a particular subject, you can apparently charge more, whether that’s reasonable or not! Next, you need to factor in your own supply and demand: how busy you are, how badly you need the job, and so forth. One of the hard things about working independently is saying “No” to work, regardless of how busy you already are. But if you really need the work, it’s natural to charge less (in the hopes of improving the odds of getting the job), and if you don’t need the work so much, charge more (with the mentality of “if I am going to do this job, it has to be worth my while”). Finally, you may have to consider your business principles. For example, I get paid nothing for a fair amount of the work I do, such as answering questions in the support forums or via email, or sending these newsletters (actually, those things all cost me some money, but there’s a marketing benefit to them), and I charge educational organizations and non-profits a fraction of my commercial rate. All of these personal factors go into tweaking the global rate to come up with your specific rate, and these personal factors differentiates the price you would quote for a job compared to the price that the person in the building next to you would estimate for the same job.

If there are two broad factors, there is one specific one: the project itself. I charge less if I’m interested in the project, if it’s in an area I’d like to get more involved with, if I feel good about the client (such as the likelihood of more work from that same client), and so forth. I charge more if the opposite is true. And, of course, the total amount has to be commensurate to the complexity and demands of the project itself. And when coming up with a project price, remember that projects almost always take more effort than you were expecting, and how much more effort is equal to how new the technologies and processes involved are to you (e.g., it’s taking me a few days to do my first mobile app using Flex but it’ll probably take me just a couple days to do the next one).

What is Larry Thinking? => The JavaScript Problem

I’m beginning to work full-time (or nearly full-time) on my next book, “Modern JavaScript: Develop and Design”. This book is based upon a proposal that I did about two and a half years ago (I think) for a different publisher. The goal of the book is not just to teach JavaScript but to address what I’m calling The JavaScript Problem. The JavaScript Problem is that the language’s design, capabilities, and history make it unlike any other language. Let’s look at these criteria in reverse order (Chapter 1 of the book, which is nearly written, discusses all of this in more detail).

JavaScript’s history is an ugly one and the end result is that today’s JavaScript is a vastly different beast than that created in 1996. In the late 1990’s, basically you had JavaScript for the Netscape Navigator browser and JScript (similar, but not the same) for Internet Explorer. Programming in JavaScript required lots of conditionals checking not only the browser type but its version, as there would be significant changes from versions 4 to 4.5 to 5. And, at best, JavaScript was used for form validation, but mostly it was used to create annoying alert messages, pop-up windows, and trivial applications of eye candy. Because JavaScript was used entirely within the Web browser, and because it wasn’t taken very seriously by “real” programmers, JavaScript was mostly the domain of client-side Web developers.

Thanks largely to Ajax, JavaScript today is a much more useful tool than it was fifteen years ago. And ironically, even though there are more types of browsers in use—Netscape became Firefox, Apple has Safari, Google has Chrome, and Opera still gets the occasional mention—and therefore more versions, programming to account for the variations has become much easier. Odd as that may sound, it’s due to a change in approach. In today’s JavaScript, instead of coding for the browser or version, one programs for what the browser and version can support. For example, instead of checking the browser version and knowing that these browsers can perform, say, DOM manipulation, JavaScript programmers now just run a test to see if the browser, regardless or type or version, can handle DOM manipulation:

if (document.getElementById) { // Go ahead!

This change in approach is both simple and brilliant. If you want to see if it’s safe to use the getElementById()
method, just check if the Web browser supports it! Part of the reason this new approach works is that even though there are more browsers out there, they have come a long ways towards adopting standards (even Internet Explorer is better, albeit not where it should be).

JavaScript’s history is a problem for three reasons. First, people not up to date with what JavaScript can do, or how to program JavaScript properly, are inevitably misusing or underusing the language. Second, those of us who’ve been working with JavaScript since the early days have to undo our own bad habits. Third, those new to the language will no doubt run across older code, thereby running the risk of picking up their own bad habits, even when learning from fresh. I personally believe that part of the reason there aren’t more good JavaScript books out there is that most of these books are just updates upon updates of books written about the old, now thoroughly-outdated, JavaScript.

In terms of JavaScript’s capabilities, what used to be a language for playing sounds in the browser (ugh) or creating scrolling tickers (ugh), can now do dramatic and wonderful things: DOM manipulation, server-side requests via Ajax, useful animation, and more. “Web 2.0″—a term I despise—is largely JavaScript-based (Rich Internet Applications, RIAs, using Flash still use JavaScript, too). In fact, just a few of the ways that today’s JavaScript can be used, besides in a Web page, include:

In PDFs
Internally in many of Adobe’s applications
To create desktop applications
As a server-side alternative to PHP or the like

JavaScript is still mostly used as a Web browser enhancement, but what you can do with the language far exceeds that.

Finally, there’s JavaScript’s design. To start, JavaScript is an object-oriented language, but it’s not your typical object-oriented language. In fact, it’s a prototypical object-oriented language. What does that mean? In a typical OO language, which is to say almost all of them, programmers define classes and then create instances of those classes. The typical OO language also has its own defined classes, for common types like Strings, and common needs. JavaScript has its own defined classes, too, but programmers do not create their own classes. Instead, in JavaScript you can create your own object, with its own properties (variables) and methods (functions), and then use that. You can also, thanks to the prototype property, dynamically change the definition of any object, including the core JavaScript objects like String. In simple terms, this means you can alter what information an object can store and what that object can do on the fly (Ruby allows for this, too, although Ruby is not a prototyped language). This key difference in how JavaScript is designed is what makes it possible for true JavaScript wizards (such as John Resig, who created jQuery and worked for Mozilla until recently, or Douglass Crockford, a JavaScript expert at Yahoo!) to do the magic that they do. It’s also what makes modern JavaScript, on the high end, daunting for some new to the language.

The goal of “Modern JavaScript: Develop and Design” is to thoroughly teach today’s JavaScript, of course, so that readers can do what they want/need to do. But it’s important to me that the readers understand why that’s the way to do it, too. JavaScript as a language has plenty of baggage that comes with it, and that baggage needs to be opened and examined, and much of it tossed, in order to fully grasp and appreciate this lovely little language.

Book Giveaway => “PHP for the Web: Visual QuickStart Guide” and “Effortless Flex 4 Development”

There was a nice response to the book giveaway announced in the previous newsletter, with equal interest in the “PHP for the Web: Visual QuickStart Guide” (4th edition) and “Effortless Flex 4 Development” books. (I suspect that Flex’s ability to create mobile apps, thanks to Flex 4.5 and Adobe AIR 2.6 has increased the interest in Flex.)

My thanks to everyone for their interest in the books. I will be giving away copies of the fourth edition of my “PHP and MySQL for Dynamic Web Sites: Visual QuickStart Guide” in September, I expect.

Larry Ullman’s Book News => “PHP and MySQL for Dynamic Web Sites” (4th Edition) and “Modern JavaScript”

As of Thursday, August 18th, the fourth edition of my “PHP and MySQL for Dynamic Web Sites: Visual QuickPro Guide” book is at the printer, which means it should be available at a store (or online) soon. The estimated date I have from the publisher is September 9th.

Almost all of the planned extra material (i.e., the stuff new in this edition) did make it into the printed book. This includes:

Extra material on database design, JOINs, advanced SQL, and advanced MySQL functions
A new chapter introducing the jQuery JavaScript framework, walking through form validation, DOM manipulation, and Ajax
A new chapter introducing Object-Oriented Programming (OOP) in PHP, focusing on the basic syntax and principles, with examples recreating earlier MySQL-based scripts and another example performing date and time validation and manipulation

And this edition has a “Review and Pursue” section at the end of each chapter. That section, as in the fourth edition of my “PHP for the Web: Visual QuickStart Guide” book, has review questions on the material just introduced and prompts for how you can extend the newfound knowledge.

Unfortunately, due to space constraints, it was decided to pull out the appendix and make that a freely available PDF, to be downloaded from the publisher’s Web site. As the appendix is mostly about installation, I don’t think that’s too much of a sacrifice. The appendix also includes in this edition about a dozen pages on server (i.e., Apache) configuration and manipulation. But you can download the PDF to read that material. I don’t have any details as to how you go about finding the appendix on the publisher’s Web site, but will post that information when I have it.

For the first time ever, I’m doing screencasts to accompany the text. These videos will be embedded in some electronic versions of the book and made available separately (as I understand it). Most of the videos demonstrate and expand upon specific book content. I’m hoping to wrap up those videos in the next couple of days.

I’ve been wrapping up my initial extra research for my next book, “Modern JavaScript.” I’m looking forward to writing this and have a good sense of what the book will be. I’ve got a good bulk of the first two chapters written, and am hoping I’ll be able to make good progress in September.

Series

Blog post categories

Note