For the first time ever, I plan on selling copies of select books myself. The books will, of course, be signed (inscribed however you want). For the Modern JavaScript: Develop and Design book, I believe I will be able to offer it at $35 $40 (US), plus shipping. This is slightly more than the Amazon price, but I have more overhead (well, different overhead) and fewer employees than Amazon! Plus, Amazon has that whole “economies of scale” thing working for it. I’ll confirm the price and get the e-commerce system setup in the next couple of weeks. If you have any questions or comments, let me know.

ADDITION: Presumably, the book will be available internationally in time, starting with English-language countries such as Canada, the UK, and Australia, followed by translations in other European countries and Asia (that’s my educated guess, based upon how things have gone in the past). Buying the book directly from me will be the fastest way for international recipients to get a copy, by far. I’ll need to receive my copies of the book before I can estimate the shipping costs.

UPDATE: I just heard back from my contact at the publisher and it will cost me more than I had thought to purchase the book for resale. In order to cover my costs, I’ll need to charge $40 (US) plus shipping. Admittedly, this is almost $10 more than Amazon, but the $40 covers the cost of: the book itself, getting the book shipped to me, and packing materials. I think shipping within the United States via media rate will be around $4.

• What Were You Thinking? => Bimonthly Newsletters
• On the Web => Security and Privacy Made Simpler
• On the Blog => My January 2012 Non-Resolutions List
• Q&A => How do you go about designing the main OOP classes for a project?
• Larry Ullman’s Book News => “Modern Javascript: Develop and Design” Done!

What Were You Thinking? => Bimonthly Newsletters

In the previous newsletter, I asked for input on the idea of changing the newsletter from going out every 3-4 weeks but being longer to going out every 2 weeks but being shorter. You were also able to vote in an online poll. About two-thirds of the votes were for the change, although the more passionate responses were against the change, as those recipients already felt they received too many newsletters and emails. I think what I’m going to do, as a happy medium, is to shoot for a schedule where the newsletters come out slightly faster, like every 2-3 weeks, and are slightly shorter. This should be feasible for me to pull off without overwhelming you.

Towards that end, you may note that there’s no “What is Larry Thinking?” section in this particular newsletter. With the new plan for the newsletter, I’m not going to be quite so rigid about what goes into each newsletter, limiting myself to just five or so significant pieces. The bulk of this newsletter answers a question on OOP design.

My thanks to everyone for their input. And please always feel free to provide any feedback, questions, comments, etc., that you may have. (Postscript: Several of you rightfully pointed out that I misused “biweekly” in the text of the newsletter, despite correctly using “bimonthly” in the heading. I indeed meant “bimonthly”, although “biweekly” has the same inexactitude in that it can mean both every two weeks and twice a week.)

On the Web => Security and Privacy Made Simpler

When I was writing my Effortless E-Commerce with PHP and MySQL book, I naturally did a bunch of research, particularly with regards to the various laws that apply. Understanding the programming behind an e-commerce site is relatively simple; understanding all the applicable laws and implications of doing e-commerce is complex. One of the sites I found to be quite useful was the United States Better Business Bureau (BBB).

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, in the U.S. or not, it’s worth your time. 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.

On the Blog => My January 2012 Non-Resolutions List

I’ve never been much of a New Year’s Resolution person: if something is important enough to do, start today, not on some arbitrary date that happens to be the first day of the year. (Or, you know, January 2nd, because the first is a holiday and all.) But this year I happen to have quite a long non-resolutions list. The timing is entirely coincidental: I just happen to be done with my “Modern JavaScript: Develop and Design” book around this time, and I always have a long list of things to do between books. I recently posted on my blog about my immediate plans (aka, my non-resolutions list).

Q&A => How do you go about designing the main OOP classes for a project?

While “diving into” Object-Oriented Programming development in PHP, Chris had emailed me about how one sets up the core classes for an OOP-based site. The specific example—user management with login/logout, roles, etc.—is common and not complex, but Chris didn’t know where to start. In my opinion, OOP is easy enough to use once the classes have been defined; the difficulties arise from coming up with the proper classes in the first place. So let’s look at that process, in the abstract.

Programming is a matter of taking actions with data. In a linguistic sense, it’s very much a noun-verb relationship: the user submits form data to a server; the server stores data in a database; the user requests another page; the server pulls data from a database. Whether you’re using OOP or procedural code, you need to identify both the actions and the data first. What are all the verbs that the user or Web site needs to be able to do? What are all the nouns that will be involved in those actions? Once you’ve identified those attributes of the site, procedural programming focuses first on the verbs, OOP focuses first on the nouns.

To start designing OOP classes, one must first organize the types of data the site will work with, in detail. In a user management system, there’s one obvious noun: a User. The properties of a User include: userId, username, userPass, userRole, dateRegistered, and so forth. (Conventionally, OOP uses camel-case for variable and property names.) When you think you’ve identified the nouns involved, go back and see if all of the actions now have the data that needs to be involved. When a new person registers, a User is created (as both a PHP variable and a record in the database). When a person logs in, a User is retrieved from the database and created as a PHP variable. When a person logs out, the User PHP variable can be destroyed. To see if a person has authority to do X, you’d check the User->userRole property.

In some situations, there will be nouns with overlapping roles and properties, which would suggest that you should create a hierarchy of classes. I think of shapes as being the easiest example to comprehend. All two-dimensional shapes have some common attributes, such as area and perimeter, but triangles have three sides, rectangles have four, and circles have none (but do have a radius). When you find yourself in situations like this, you’ll want to design one master class, in this case, Shape, which you never create instances of. Then you define derived classes—Triangle, Rectangle, and Circle—that you would create instances of. Admittedly, knowing when to create a hierarchy can be tough. You might think with a user roles situation that you’d want common users and administrators as two separate classes, but the only difference between the two types is in what actions each can take, which is easily managed using Access Control Lists (ACLs) or the like. Or, put another way, everything about the two users is exactly the same except for the type, so there’s no need to create separate classes (unlike, by comparison, circles and triangles that have some overlapping properties but other very different ones).

Another common class to use on a site would be one for interacting with the database. You could create your own class for this purpose, or just use the MySQLi object or PDO or the like.

Even in a simple site with content and users, there are other clear nouns: the pages of content. Going back to the language analogy, there are some sentences that have a single noun—Johnny runs or A User logs out—but many have more than one noun—Johnny reads a book or A User views a page of content. The content, then, would also be represented by one or more classes, depending upon the variety in the content displayed. If the content is just information displayed within a template of HTML, then Content might have these attributes: contentId, title, body, createdBy, dateCreated, and dateUpdated. The createdBy could be as simple as a userID integer, or more formally be an actual User instance.

Depending upon how OOP-y you want to be, you may also create classes for generating the HTML pages (i.e., View classes) and for handling actions (i.e., Controller classes). Those move you into the realm of a true MVC architecture, which isn’t always necessary, though.

In asking the question, Chris didn’t originally know how to handle the logging in and logging out and registration and such, not knowing if one makes classes for those. Those are actions performed on, or using, objects, and don’t get represented as classes themselves.

Because I’m going to be writing the third edition of my “PHP 5 Advanced: Visual QuickPro Guide” this year, I expect I’ll be doing a lot of writing on the subject of OOP, design patterns, and the like. If anyone has any more questions or comments regarding these topics, let me know.

Larry Ullman’s Book News => “Modern Javascript: Develop and Design” Done!

I am very, very happy to say that my latest book, “Modern JavaScript: Develop and Design”, is officially done. Like done, done. Last week Monday, I submitted the last chapter to be written, Chapter 13, Frameworks. In it, I quickly discuss how to choose a framework, when you should use a framework, and some common libraries (as a framework alternative). The bulk of the chapter introduces and uses jQuery and the Yahoo! User Interface (YUI) Library. For both I explain how to perform common tasks—selecting DOM elements, DOM manipulation, event handling, and Ajax, and then walk through more advanced examples. For both, the chapter explains an autocomplete example, using a PHP script as the data source. For jQuery, I also discuss the DataTables plug-in. For YUI, I also discuss and demonstrate the Yahoo! Query Language (YQL). For it, I go through a couple of examples, including fetching a weather report and a stock quote. (For the record, I specifically target YUI3, which is an improvement over YUI1 and 2, even if some of the framework is currently in beta.)

Chapter 13 is the first chapter in Part 3 of the book, Next Steps. I already wrote Chapter 14, Advanced JavaScript, which has a heavy focus on closures. Chapter 15, A PHP and JavaScript Example, creates a pseudo-complete auction system. Auctions are set to expire on a certain date and time. Logged-in users can bid on items. All dates and times are shown using Coordinated Universal Time (UTC) or the user’s timezone, if the user is logged-in. Then, JavaScript used to enhance the experience. This includes using Ajax for the login and bid forms, retrieving the latest bids via Ajax (and updating the table of bids with them), and creating countdown timers that show the amount of time left in an auction, when that’s less than an hour. I think the chapter turned out well, and it emphasizes the various ways to pass data back and forth between PHP and JavaScript, a common point of confusion.

Not only is all of the initial writing is complete, but I’ve also done the rewrites on the entire book, and I just—moments ago—finished reviewing the PDF layouts, which is the last step before the book goes to the printer. (As you can tell, there are a lot of overlapping steps here at the end.) I believe the book will still ship, as originally planned, at the end of February.

In support of the book, I’ll also be writing a couple of articles (published online for free) and create some screencasts (to be provided in various places).

If you check out the corresponding README file on GitHub, you’ll find links to other presentations created with impress.js. A couple of presentations are quite useful in that they demonstrate, in my opinion, an overuse of impress.js. Those particular presentations use the rotation feature to such as extent that it makes one dizzy, which is normally not a good quality in a presentation (although one presentation is talking about 3D transformations, so there’s some justification there). One does worry that if impress.js catches on too much, we’ll all be sick of rotating transitions in no time.

For an example of another interesting use of impress.js, check out lioshi toiles, where impress.js creates a site that displays artwork in a truly interesting way. Taken a step further, Al Ingham’s site, uses impress.js for custom navigation and presentation, while still providing direct links to specific pages across the top of the page (because walking through all the “slides” to get where you needed to be is unreasonable).

If only I had any design skills whatsoever…

I am very happy to say that my latest book, Modern JavaScript: Develop and Design, is official done. Well, not done, but close enough to blog about it. I just submitted the last chapter to be written, Chapter 13, Frameworks. In it, I quickly discuss how to choose a framework, when you should use a framework, and some common libraries (as a framework alternative). The bulk of the chapter introduces and uses jQuery and the Yahoo! User Interface (YUI) Library. For both I explain how to perform common tasks—selecting DOM elements, DOM manipulation, event handling, and Ajax, and then walk through more advanced examples. For both, the chapter explains an autocomplete example, using a PHP script as the data source. For jQuery, I also discuss the DataTables plug-in. For YUI, I also discuss and demonstrate the Yahoo! Query Language (YQL). For it, I go through a couple of examples, including fetching a weather report and a stock quote. (For the record, I specifically target YUI3, which is an improvement over YUI1 and 2, even if some of the framework is currently in beta.)

Chapter 13 is the first chapter in Part 3 of the book, Next Steps. I already wrote Chapter 14, Advanced JavaScript, which has a heavy focus on closures. Chapter 15, A PHP and JavaScript Example, creates a pseudo-complete auction system. Auctions are set to expire on a certain date and time. Logged-in users can bid on items. All dates and times are shown using Coordinated Universal Time (UTC) or the user’s timezone, if the user is logged-in. Then, JavaScript used to enhance the experience. This includes using Ajax for the login and bid forms, retrieving the latest bids via Ajax (and updating the table of bids with them), and creating countdown timers that show them amount of time left in an auction, when that’s less than an hour. I think the chapter turned out well, and it emphasizes the various ways to pass data back and forth between PHP and JavaScript, a common point of confusion.

All of the initial writing is now complete. I’ve also done the rewrites on the first nine chapters. I still have to do the rewrites on the last six chapters, but that won’t take long. I will also be doing supporting videos and articles related to the book.

I believe the book will still ship, as originally planned, at the end of February. I am now going to go celebrate!

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.

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.

• About This Newsletter
• What Were You Thinking? => Looking Both Ways
• On the Web => Columbia’s Break Writing Series
• On the Web => The Heisenbug and Others
• On the Web => Take Control of Scrivener 2
• On the Blog => Another “Modern JavaScript: Develop and Design” Update
• Q&A => Should One Enforce Business Ethics?
• What is Larry Thinking => The Dangers of Shared Hosting
• Larry Ullman’s Book News => “Modern JavaScript: Develop and Design”

About This Newsletter

I don’t know if references to just a couple of philosophers or philosophical movements makes a true newsletter theme, but I haven’t had a philosophy theme yet, and as my minor in college was in philosophy and religion, it’s about time. So, a couple of minor, not scary philosophy mentions, and a bunch of somewhat random stuff that I hope will have use and meaning for you.

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? => Looking Both Ways

In a previous newsletter, I referenced a quote I had encountered, attributed to Doug Linder:

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

Because I was unfamiliar with the name, I tried researching who Doug Linder was, but to no avail. Surprisingly, sometime after sending out that newsletter, I received an email from the actual Doug Linder and he and I exchanged a few nice messages. Doug said that he wasn’t intending to come up with something quotable, of course, but had made the comment, specific to error trapping, in a USEnet discussion during the mid-90’s. Someone started using the quote as his or her signature file and eventually the comment got put onto someone’s “collected quotes” list. From there it spread.

Doug said that every so often he pings for references to his “15 minutes of fame” quote, and was pleased to find my use of his comment to be something worth responding to. And I was pleased to hear from him!

On the Web => Columbia’s Break Writing Series

Columbia University has a BreakWriting program that encourages students to write during their December-January semester break, which is nigh upon us. Last year’s series of 16 posts have been put online and are well worth reading if you do any writing (or think about doing any). Each post has oodles of useful, real-world advice, with plenty of tips and recommendations for being as successful as possible when it comes to writing (success here being measured in terms of actually writing, not commercial success).

On the Web => The Heisenbug and Others

I recently came across the term heisenbug, which I really like. It comes from Walter Heisenberg’s uncertainty principle, a tenet of quantum mechanics. Loosely speaking, the principle says that you can either know where a particle is, or how fast it’s going, but not both. Mistakenly, people often think the uncertainty principle says that the act of observing a particle affects it. Regardless of the conventional misunderstanding, heisenbug plays off of this misinterpretation of that principle, describing a bug that behaves differently when you go to observe and debug it. Misnomer aside, I think we’ve all been witness to this on more than one occasion.

The Wikipedia description of the heisenbug is on a page of unusual software bugs. There’s the Mandelbug, the Schrödinbug, and a couple of others. I’m not sure that naming bugs helps, but sometimes it helps to truly know one’s enemy!

On the Web => Take Control of Scrivener 2

I’m a pretty big fan of Scrivener, a writing application for Macs (there is a Windows version currently in beta). For a year now I’ve been using Scrivener to write my newsletter, and I’ve even been writing the JavaScript book starting with it, too. (The entire book is in Scrivener, including all of my notes and research. When I finish the first draft of a chapter, I export it from Scrivener to Word, and then complete it, with formatting, in Word, which is the format required by the publisher.)

There’s something about Scrivener that just works for me: first and foremost, that I’m able to keep everything about a project—the writing, references, notes, etc.—in one place. As with any good piece of software, though, I’ve got a nagging feeling in the back of my mind that I’m not using Scrivener to its fullest potential. And by that I mean I’m absolutely convinced that I could be using Scrivener better.

For this reason, I was quite happy to see the release of the book Take Control of Scrivener 2. I haven’t read it yet (ironically, I’m waiting to complete the book I’m currently working on first), but it’s high on my “to-read” list. Just scanning the 22-page sample that’s available, this looks like a good, quickly-readable resource. And at $10 (US) for the book, it’s a steal.

On the Blog => Another “Modern JavaScript: Develop and Design” Update

I’ll provide a brief update on the JavaScript book at the end of this newsletter, but for a more detailed update status, see this recent blog post.

Q&A => Should one enforce business ethics?

Richard wrote me some time ago, asking about “honor”. Specifically, Richard said that he knew of someone ripping off clients by charging them too much for Web development work, taking advantage of the customer’s lack of knowledge. Richard was wondering what my thoughts were about tipping off the customer, mostly in terms of being a professional and trying to better represent the business he (and many of us) is in. It’s not the kind of question I’m had before (and I’m not sure that my Q&A synopsis does it justice), so I thought I’d take a crack at it.

I have three initial thoughts, and the third speaks more towards what kind of person I am and how I think, than towards how I think anyone else should behave. Which is my third point, as you’ll see. My first thought I that I realized some time ago that gossiping or speaking ill of someone almost always reflects more poorly on the speaker (i.e., you) than on the target. If person A, someone I don’t know that well, says something negative to me about person B, all I’ve really learned is something (negative) about person A. I would think that would definitely be a factor in a case like this, especially when person A represents a business that could benefit from person B being discredited (deserving or not).

My second thought is that people don’t like to look foolish, let alone be told that they look foolish, even—or especially—when they do. Finding out you have spinach in your teeth is embarrassing, but easily overcome. Finding out you’re wasting money is much harder to hear and accept. That may sound like a poor reason not to say something, but it’s a factor. In fact, I’d go further and say that I don’t think most people really want to hear what other people think, unless being directly asked (and sometimes not even then, but perhaps I’m being too cynical). In any case, with these first two thoughts in mind, I would question how effective saying something would be.

My third thought goes directly to who I am. I learned about existentialism in high school and it really struck a chord for me. In particular, I like the notion that we define our own meaning and values (see “Existence Precedes Essence”, if you’re curious). My acceptance of existentialism applies here because, in my mind, we’re responsible for our own actions. If someone else is doing something unethical, that’s on them. One’s ethics dictate one’s own behavior, they’re not a basis for how others should behave.

My final thought, which came later, but should have come first, is that any time one is deciding how to act in a situation, one has to start by verifying what is known. Taking actions under the possibility of false pretenses has a different governing rules and implications than taking actions when certain of what’s true. In Richard’s particular case, what may seem like one person taking advantage of another, may not really be so.

As I said, I did find this to be a good question, although I’m not sure I gave a good answer. To me, the simple answer is: you must be ethical yourself, in your dealings. Time spent thinking about whether other people are behaving appropriately is time that would be better spent doing just about anything else. Of course, that’s much easier said than done. I encourage your feedback on this question.

What is Larry Thinking? => The Dangers of Shared Hosting

In my “Effortless E-Commerce with PHP and MySQL” book, I write a lot about security, naturally, including the security considerations that come from the Web hosting itself. The absolutely most important thing to understand about security is that it’s not a binary thing that can be turned on and off, enabled and disabled. Security is a relative criteria, and as programmers and developers it’s our responsibility to select the appropriate degree of security for the task at hand. There’s nothing you can do that can make a site or application secure or not secure, only more secure or less secure. And here’s the kicker: less secure isn’t always bad and more secure isn’t always better. The only criteria is: Is everything put together secure enough for the situation?

When it comes to Web sites, one major impact on the security of the site itself is the hosting being used, as I also write about in the book. One has to select the right hosting for the site, both in terms of performance (i.e., can the hosting handle the demand) and in terms of security. Both qualities are impacted by the number of clients on the same server. For example, if you have a dedicated server, which will cost you hundreds of dollars (US) per month, it’s your server, and no one else can do anything on that server to undermine your site’s security. (On the other hand, you either need to pay someone to manage the server or be a server security expert in order to maintain the optimum level of security.) Conversely, with shared hosting, you can have literally hundreds of users on the same system. If one of those users does something bad, accidentally or maliciously, that could easily affect your own sites. For example, if there’s a security hole on someone’s site, that hole could be used to bring down the entire server. Or, worse yet, a security hole could be used to exploit the other clients and sites. I’m not saying you should never use shared hosting, but the potential for problems is greater simply because there are more users on the same machine. Still, even among shared hosting, not all hosting companies are equal.

A while back, I wrote a somewhat popular blog posting titled How Web Hosts Prey on Beginners. In the piece, I write about some of the deceptive marketing things companies do to lure new customers. The specific company, not actually named in that piece, is 1&1 hosting, and I’ve heard plenty of negative feedback about them. The worst hosting experience I ever had was with Dotster, who is primarily a domain registrar. I originally used Dotster as a registrar, and when they had a great deal on a Virtual Private Server (VPS), I began using Dotster for my hosting, too. That was a big mistake. They were so terrible as hosts that I didn’t even complete the paid year of hosting. Really, they had no business acting as a hosting company, and I don’t mean that in terms of security, but in terms of customer service and technical support. Dotster, as a registrar, was just not up to the task of being a good Web host. I’ve heard similar comments about GoDaddy (another registrar) when it comes to hosting, and I just think it’s a good policy not to use a registrar for Web hosting. There’s really no need to use the same company for both, anyway. I would also not be inclined to use my Internet Service Provider as a host. The rule of thumb is this: when it comes to finding Web hosting, use a company that only does hosting!

Recently, Scott had emailed me (all the way from Alaska!) about a problem he had discovered through his GoDaddy! shared hosting account. Scott realized one day that he could, using his FTP application, see all the other client directories. This means he was able to see all the client names, which is a fairly bad security hole as those names are likely to be used for access to the server and as the basis of database users.

If you know about security permissions, you know that a client directory is owned by the client, and so Scott wouldn’t have been able to browse through those other directories (not that he would have, anyway). However, if those clients have any files or folders with open permissions on them, then Scott could have seen them (had he wanted to). When you think about it, with any open-source piece of software, there’s a clearly-known structure involved. With WordPress in particular, it’s easily known that the wp-config.php file, found in the root Web directory, defines a the site’s database access information. During the WordPress installation process, this file needs to have open permissions, so that the installer can write to it. The permissions need to be closed up after the installation is complete. If someone installed WordPress and failed to change the permissions afterward, that configuration file would be readable by someone in Scott’s position, even if the parent client directory wasn’t otherwise readable! In other words, anyone with a Go Daddy! account can get access to anyone’s database if the person installed WordPress and made the simple, beginner’s mistake of not correcting the permissions after the installation.

Even if a person does fix those permissions, it’s standard to make the wp-content directory world-writable, so that WordPress can upload files there. This is an even bigger concern, as anyone on the Go Daddy! server could copy a PHP script to that directory and then execute that script in the Web browser, doing all kinds of damage.

The mere visibility of other client directories on a server is a terrible security hole, one that Scott responsibly pointed out to GoDaddy! hoping they would correct it. Thus far, they’ve given him what seems like a bogus response. Again, I’m not saying that you should never use shared hosting—it’s a logical choice for many people, but one has to be aware of the potential security implications. And to start, you should probably check to make sure you can’t see any folders outside of your client directory on the server, because if you can, that means other people on the server can see your directory, too.

Thanks to Scott for sharing this information with me, so that I could pass it along!

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

There was a nice response, again, to my second giveaway of the fourth edition of my “PHP and MySQL for Dynamic Web Sites: Visual QuickPro Guide” book, published in September. Thanks to everyone for their interest. I have no contacted all the winners and I should be mailing out those books this week.

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

The short version of the update (see the aforementioned blog posting for the longer version) on “Modern JavaScript: Develop and Design” is that I just submitted Chapter 10, which means I’m about two-thirds done, with maybe five or six chapters left. I’ve also done the rewrites on the first four chapters and the first two chapters have been laid out as PDFs (which is the next step before being printed). By the time I send this newsletter out, I’ll be about halfway through the rough draft of Chapter 11, on Ajax.

I’m still way, way behind schedule, but I really do think the book is turning out well, which is the most important thing. Hopefully those of you that have been wanting this book will feel that way, too.

The good news is that I just submitted the first draft of Chapter 10, “Working with Forms.” Although forms have been used to some degree since Chapter 2, “JavaScript in Action,” this chapter rounds out the knowledge of forms with respect to JavaScript. The chapter worked out much like a “recipe” type of chapter, with discussions of common tasks plus specific code for performing that task. Some of the examples are:

• Inline error messages
• Tooltips
• Creating a master checkbox (that toggles a group of other checkboxes)
• Linked select menus
• Enabling/disabling submit buttons

The chapter also covers regular expressions, with a focus on validation. Because  regular expressions are complicated, and there’s already a lot of material in the book, I tried to keep the coverage as accessible as possible, without going into too much high-end stuff. The chapter ends with a good and realistic form validation example that combines most of the above.

Before Chapter 10, I finished Chapter 9, “JavaScript and the Browser,” and Chapter 8, “Event Handling”. Chapter 9 in particular was quite long. But now that I’ve covered events in detail, plus DOM manipulation, CSS interactions, and so forth, the possibilities have greatly expanded when it comes to what examples I can use, which makes writing the book easier and more rewarding. By this point in the book, the reader has also created a couple of mini-libraries that make things like event handler registration easy and cross-browser compliant. The book is continuing to emphasize–and demonstrate–progressive enhancement along the way.

I’ve also done the rewrites on the first four chapters and have seen the PDF layouts for the first two. This is my first full-color book and it looks great. Unfortunately, as seems to always happen with me, the page counts are coming back quite high. Between that and how grossly behind schedule I am, I’ll have to make some decisions as to what to keep in Part 3 of the book. Part 2 of the book, which is the meat, has two more chapters remaining: Ajax (Chapter 11) and Debugging and Error Handling (12). Part 3 of the book will definitely have one chapter on frameworks and another on advanced JavaScript programming. There will be at least one more chapter, but I’m not sure what that will be. Possible candidates are:

• HTML5
• Mobile Development
• An example chapter of PHP and JavaScript

I’ve already decided not to do the server-side JavaScript chapter, as I don’t think that many people are doing server-side JavaScript yet, at least not among those that would be reading this book.

As always, if there’s not space to put something in the book, I’ll probably end up writing about those subjects here, or as articles elsewhere (so you’ll still get all the important content, you just won’t have to pay for it).

So that’s where things stand. Thanks to everyone for their interest in the book. Now I’m off to write Chapter 11!

The first is an Introduction to Computer Science and Programming, from an instructor at MIT. It’s definitely for beginners and although it uses Python as its primary language, the goal is to convey the fundamentals and the theories involved. It probably gets a bit too high-end for some, but worth taking a gander at regardless.

The second series is programming literacy’s Core units. This series is much more broad and covers a range of languages and topics. As I write this, the first six units have been completed and are available as YouTube videos, with downloadable PDFs (and other formats) for the slides and notes. On the other hand, the last one was finished about 20 months ago, so there may never be more in the series. Still, it’s approachable and I like that the materials are available for viewing separately. And the price is right!