dept_form.html

This page returns all of the employees in a selected department.

add_employee.html

This page uses Ajax to add an employee to the database (note: the version running on this site does not actually execute the INSERT query that updates the database.)

search_form.html

This page provides a simple search to retrieve employees by last name.

There’s no navigation within or among the pages. You’ll need to click Back to return to this page to see another example. To run one of the examples without Ajax (to see what that’d be like for visitors that can’t use the Ajax version), disable JavaScript in your Web browser.

I’m currently going through some items in my “to read” folder, and am reading, or perhaps re-reading, the Better Business Bureau’s PDF titled “Security & Privacy – Made Simpler“. If you do any e-commerce, or even just Web development, it’s worth reading. It’s a 22-page document that discusses almost every facet of e-commerce, such as:

• Developing a security and privacy plan
• Creating and communicating your security and privacy policies
• Good employee screening and policies
• Common hack/theft strategies
• General Internet security
• Proper handling of customer data
• Payment processing
• What to do in the event of a data breach
• A preview of international e-commerce considerations

The document also has many resources listed in these and other categories. You can download the PDF from that page, but there are also related FAQs and more on the BBB’s site.

1. Head to Peachpit.com (almost all of my books are published by Peachpit Press)
2. Click on Account Sign In at the top of the page.
3. If you don’t already have an account with Peachpit.com, click the Create a new one… link to register.
4. After you have registered, login.
5. On your account page (after logging in), click Registered Products.
6. On the Registered Products tab, click Register Another Product.
7. Follow the instructions to register the book.
8. Return to the Registered Products page.
9. For the book in question, click the Access Bonus Content link. That will take you to a page with all the bonus content for a given book.

Besides being able to access bonus content, there are other benefits to registering at Peachpit’s site. And while you’re there, you can also check out my author page, which lists the books I’ve written for Peachpit, the articles I’ve published there, and the blog postings I’ve published there. Both the articles and blog postings are viewable without registration or logging in.

I hope that helps anyone having trouble finding the material they’re looking for.

I first started using the Yii framework about two and half years ago. I’ve never been much of a framework person, but Yii really felt right to me, quite similar to Ruby on Rails, which I also always liked. Being a writer, after learning to use the framework, I wrote an introductory series on the subject, which has been quite popular. In all modesty, many have suggested it’s the best documentation available. In fact, the creator of Yii liked my series so much that he listed it prominently on the official Yii documentation page (it’s now under tutorials). Some time after writing that series, I started thinking about writing a full book on Yii, because that’s what I do.

When I decided to write a book on Yii, I figured I’d self-publish it, for a couple of reasons. First, even though I have a wonderful relationship with Peachpit Press, I’m not sure they’d want to do a book on Yii, as the market is kind of small. Second, even if Peachpit would publish such a book, I doubt I’d make much money on the project, considering the small market. By comparison, if I self-publish, I can make 4-5 times per book what I’d make if I went through a publisher. The higher per copy amount could be enough to make up for the smaller sales, ending up with a project that’s financially worth my time to do (sorry to be crass about the money, but writing a book is a lot of work and I do have bills to pay!). Fourth, I’ve been intrigued about self-publishing for some time. And, fifth, self-publishing would give me the opportunity to distribute the book in unique formats and channels, such as a chapter at a time.

If I had my act together (which is to say, if my life were other than it is, in about ten ways), I would have been on the ball and published this book a year or more ago. Sadly, that has not been the case. I keep fairly busy work-wise, and I don’t actually have the time (due to personal constraints) to put in 40-hour weeks, so it’s really hard to add new projects, especially on the level of an entire book. Moreover, self-publishing means no guaranteed money, so I’d have to not do paying work while not making money working on the Yii book, which is a tough situation to be in.

All that being said, it is still my intention to write and self-publish a book on Yii. The only question is: when? This is the question I’m getting asked a lot lately. Before I do anything towards a book on Yii, I still have to:

• Finish my Modern JavaScript: Develop and Design book (which I’m weeks late on as is)
• Write one more article in support of my PHP and MySQL for Dynamic Web Sites: Visual QuickPro Guide (4th Edition) [I've written two out of three articles, but I'm weeks late on that, too.]
• Come up with a list of videos to do in support of my Modern JavaScript: Develop and Design book
• Actually do those videos
• Continue doing the Web development and other work I have for my clients

So…yikes. Don’t get my wrong: I’m quite fortunate to be busy, but yikes! I’ll be crying if I haven’t finished all of the above by the end of this year, which means in theory I can begin the Yii book at the beginning of 2012. However, I have the third edition of my PHP 5 Advanced: Visual QuickPro Guide due at the end of April. That does give me four months, but I’d like actually make that deadline for a change (my publisher is wonderfully understanding, but…).

Also, along with writing the Yii book, I’m going to have to come up with a site and an ecommerce system and so forth (I already have the software that can output PDFs, ePubs, and mobis). If I’m being optimistic, perhaps in 2012 I can do two Yii chapters per month, but the PHP 5 Advanced book will need to be my first priority. I also don’t want to start the Yii book, get some people paying for it (in part or in whole), and then have the project drag out. I don’t know. We shall see.

I very much thank everyone for their interest in my writing a book on Yii and I hope to make that happen. If you follow the blog and/or subscribe to my newsletter, you’ll get updates as to how this is progressing, when and if it does actually progress.

• About This Newsletter
• What Were You Thinking? => Storing Uploaded Files in Multiple Directories
• On the Web => NoSQL Standouts
• On the Web => Optimizing Web Page Performance
• On the Web => Dive into HTML5?
• On the Blog => How Web Hosts Prey on Beginners
• What is Larry Thinking => Looking Both Ways
• Book Giveaway => “PHP and MySQL for Dynamic Web Sites: Visual QuickPro Guide” (4th Edition)
• Larry Ullman’s Book News => “PHP and MySQL for Dynamic Web Sites” (4th Edition) and “Modern JavaScript”

About This Newsletter

I used to regularly do crossword puzzles, although I sadly don’t anymore (I don’t get a regular newspaper and I just can’t get into doing crossword puzzles on the computer). If you’ve done crossword puzzles, or know someone that does, you know that what crossword puzzles really teach you is an esoteric list of words that are unusable in daily life. Olio is one such word: a miscellaneous collection of things. This newsletter has no discrete theme, so when searching for a title, I thought of olio. Olio: that’s what you’re getting here. And, if you’re lucky, it may also be the answer to 44 Down.

A couple of notes… First, in my previous newsletter I had suggested that this issue might have my thoughts about doing mobile development with Flex 4.5, which I’ve been playing with for the past month. I haven’t gotten around to writing up anything yet, and there’s enough to say on the subject that I’ll probably just cover the material through several blog posts. Or maybe it will be in the next newsletter. Who knows? Second, I’m giving away copies of the fourth edition of my “PHP and MySQL for Dynamic Web Sites: Visual QuickPro Guide” in this newsletter, as I just received my copies of the book last week.

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

What Were You Thinking => Storing Uploaded Files in Multiple Directories

In the previous newsletter, I answered a question about storing uploaded files in multiple directories. Jamie was kind enough to bring to my attention a video in which a member of the YouTube development team explains how they made YouTube scalable. The video is an hour long, but if you’re curious about how a site like YouTube is developed and how to design scalable Web sites, it’s worth your time (although some of it is a bit high-end technical). Around the 13:50 time marker, the speaker begins talking about handling thumbnails, which is when YouTube got in a position where they could no longer accept new videos, as they had maxed out the number of files allowed per directory. Another point being made in the presentation, which I might expound upon in a future newsletter, is that YouTube’s main concern wasn’t the site’s performance but rather the performance of their developers, which is to say: How quickly one can make changes to the system on the fly was a much higher priority.

Thanks, Jamie, for the reference!

On the Web => NoSQL Standouts

InfoWorld recently posted a good and long article discussing the particular strengths and weaknesses of various NoSQL (aka, non-relational) databases. If you’re intrigued about what NoSQL databases are all about, and maybe even thinking about starting to play around with one, it’s well worth your time to read.

As for me personally, CouchDB and MongoDB are still most attractive, in some part due to their use of JavaScript and JSON, and in part because of existing PHP libraries for interacting with these database applications.

eWeek also had a recent article discussing NoSQL databases, titled Does NoSQL Matter for Your Organization?. This is a great question, because the benefit of non-relational databases—significant speed and scalability improvements—is something that only a small subset of sites really needs. The article also has a couple of good links to more useful information on the subject of non-relational databases.

On the Web => Optimizing Web Page Performance

While doing some research, I came across an article describing how browsers download Web page resources. The article explains that the HTTP/1.1 specification recommends that browsers download page components—images, CSS, JavaScript, and other media—two at a time. This means that if your site has two CSS scripts, two JavaScript inclusions, and 12 images, that the browser has to go through eight series of downloads, not counting the initial request for the HTML. However, the specification is per hostname, meaning that if some of the content is set to come from, say, www1.example.com and some from www2.example.com, that effectively doubles the number of downloads that can be made simultaneously, thereby greatly improving the site’s performance. As the article points out, in their tests, performance got worse when they attempted to use more than four hostnames (and most browsers have a limit to how many things they can download simultaneously regardless of the points of origination).

Anyway, this is an older article, but worth the quick read. The article contains links to two other good (but dated) discussions of this and related issues. This article is part of a larger four-part series on optimizing Web page performance.

On the Web => Dive into HTML5

Some time ago I came across a book titled “Dive Into HTML5”, written by Mark Pilgrim. Although the work was also published as an O’Reilly book titled “HTML5: Up and Running”, you can read the content online at diveintohtml5.org. It’s a very clear, well-written, informative book, and a lovely Web site, too.

On the Blog => How Web Hosts Prey on Beginners

I was recently reading Popular Science (which I get a lot out of), when I ran across an ad for a major, well-known Web hosting company. Obviously the company focuses on cheap hosting—the company’s plans start at $5 (US) per month, but a few things in the ad caught my eye. In particular, the ad reminded me of how many Web hosting companies, particularly those that provide cheap hosting, prey on the ignorance of beginning Web developers. And so I wrote about How Web Hosts Prey on Beginners in a blog post.

What is Larry Thinking? => Looking Both Ways

I randomly came across this quote, attributed to a person named Doug Linder:

A good programmer is someone who looks both ways before crossing a one-way street.

I have no idea who Doug Linder is (perhaps three of you will email me with this information), but it’s a really good quote. Restated, good programmers don’t rely upon expectations. I would suggest this corollary:

A bad programmer makes assumptions.

That may be a bit harsh—perhaps more nicely said as “An amateur programmer makes assumptions”, but the fact is that making assumptions leads to bugs, user interface issues, and security vulnerabilities. One of the hardest things as a developer, I think, is imagining how other people might use the software you create. Maybe it’s just me, but when I program, I have a sense of what the application (including Web sites) should do and how it should be used. It’s very difficult for me to manufacture what other things people might try to do with the system I’ve created. But it’s exactly the ability to properly handle non-standard, including malicious, uses of a site or application that elevates the program’s security level and professionalism.

As an example, one of the first things I do when testing the usability and security of a script is to submit its form without doing anything to the form at all (i.e., enter no data; make no selections). What happens then? Are server-side errors shown, such as PHP’s undefined variable? The same goes for pages that expect to receive values in the URL: What happens if no value is present in the URL? What happens if the value is a string instead of an integer? What if it’s a negative integer instead of a positive one? Smartly written software works as it should when used correctly and responds with appropriate messages—not server errors—to the end user when used incorrectly.

As another example, when many beginning programmers write a PHP script that handles an HTML form, there’s an assumption made that the PHP script will only handle the form as written. What most beginners don’t realize is that it’s very easy to fake an HTML form and submit any type of form data to your PHP script. For example, a site has form.html which gets submitted to form.php. And let’s say that the form has a gender dropdown menu, with option values of M and F. An assumption might be that the PHP script will only receive either of those characters, making that associated variable safe to use in a query such as INSERT INTO users (…, gender, …) VALUES (…, '{$_POST['gender']}', …). This actually leaves the script vulnerable to SQL Injection attacks…

I could create on my own computer a form that contains a textarea named gender and any other necessary elements in order to pass whatever other validation the server-side script is performing. I set the form’s action attribute to point to the site’s form.php script, even though the form is loaded from my own computer. Into that textarea, I enter ‘;DROP DATABASE users;. This turns the query into INSERT INTO users (…, gender, …) VALUES (…, '';DROP DATABASE users;', …). The theory is that the initial apostrophe I used terminates the query, making it syntactically invalid, and then the DROP DATABASE users; query gets executed instead. Not good. In this particular case, that security hole would be easily closed by actually verifying that gender has a value of M or F, not assuming it does just because your HTML form is written that way.

This is just one example that’s easy enough to both do and undo. But I want to stress that assumptions don’t just create security holes for malicious people to exploit, they also create pits for your site’s users to fall into, thereby making your site less usable or entirely unusable. I’ve certainly been to many sites where I had no idea what was expected of me (from a user interface perspective) or what I needed to do to continue using the site. In short, assumptions were being made on the front and end that I wasn’t privy to.

So, your assignment, should you choose to accept it, is to revisit a legacy script or piece of code you’ve written and see what, if any, assumptions you’ve made. Because you never know when some idiot is driving down the wrong way of a one-way street!

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

You must be subscribed to the newsletter to qualify for the book giveaway.

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

I’m pleased to say that on Friday, September 9th, I received my hardcopies of the latest edition of “PHP and MySQL for Dynamic Web Sites: Visual QuickPro Guide”. This would suggest that the book should be available for purchase, or in bookstores, now or very soon. For details about the book, please see its corresponding pages. I’ve also created a new forum for this edition. Thanks to everyone for their interest in the book!

I’m also pleased to say that I’ve officially begun writing my next book, “Modern JavaScript: Develop and Design.” The first two chapters are on their way to the editors! The first chapter presents a history of JavaScript in Web development terms, ending with today’s conventions. It’s a short chapter that could have been used as a long introduction, but I think there’s an argument to understanding JavaScript’s history in order to best use it today. Also, you’re likely to run across legacy code, so it’s beneficial to be able to recognize what you should no longer be doing.

The second chapter covers the importance of the DOCTYPE and then introduces HTML5. I will be using HTML5, in a limited way, in this book for all of the examples. This is partly because HTML5 has some great new form elements that are usable now and partly because HTML5 is clearly the future standard. Next, the chapter discusses key approaches to Web development and JavaScript programming: graceful degradation, progressive enhancement, and unobtrusive JavaScript. If you’re not already using these last two approaches, they’ll change the way you think about Web development and design. The chapter then jumps right into a real-world use of JavaScript—form validation, in order to whet your appetite and provide a sense of what you’re working towards.

After I send off this newsletter, I’ll begin writing Chapter 3. It goes through the “tools of the trade”: browsers, validators, debuggers, Web resources, and so on. And that concludes Part 1 of the book; Part 2 starts teaching JavaScript as a standalone language.

I believe the book will be made available online as I write it, and I’ll post details about that once I have them.

Thanks to everyone for their interest in the book!

• About This Newsletter
• On the Web => Build Seven Good Object-Oriented Habits in PHP
• On the Web => Improving Site Performance: “Smushing” Images
• On the Blog => Great Web Developer Resources
• On the Blog => More on Non-Relational Databases
• Q&A => Uploading Images to Multiple Directories
• Q&A => How Do You Price a Freelance Project?
• What is Larry Thinking => The JavaScript Problem
• Book Giveaway => “PHP for the Web: Visual QuickStart Guide” and “Effortless Flex 4 Development”
• Larry Ullman’s Book News => “PHP and MySQL for Dynamic Web Sites” (4th Edition) and “Modern JavaScript”

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.

Update: I believe the “release date” is September 9th.

The widget below shows Amazon’s current price for the book. Thanks to everyone in advance for their interest in this book (or any of them)!