In this edition…
- 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.
