⇥ Happy holidays to all

December 21, 2007
2 comments

⇥ Permalink

The last business day before the holidays is usually one of the busiest days of the year for me—and today was no exception: we launched a special promotion on our single issues, and announced a brand new book by Cal Evans.

Today was also a really good day to be a phparch.com or pythonmagazine.com user—as previously hinted by our “office mole” we distributed over $180,000 in open-ended coupons (meaning that they have no restrictions and can be redeemed even if they exceed the value of the purchase). Except for a small bug that initially prevented $0.00 purchases from going through (if you’ve tried and had this problem, give it another whirl and it should work), things went off without much in the way of problems.

And so, as I wind down for 2007 and enter that most wonderful state of meditative bliss otherwise known as “vacation time”, I bid each and every one of my friends, readers, colleagues and everyone else who happens to stumble upon this post a happy, safe and peaceful holiday.

⇥ Thoughts for a new year: PHP as the new Java

December 17, 2007
11 comments

⇥ Permalink

If one manages to dig through all the noise on the PHP internals mailing list, there’s a strange feeling of caution coming out of the core development team that, for some reason, just doesn’t feel like it belongs in a PHP discussion list.

Historically, PHP has been developed following the scratch-an-itch method: someone has an idea, or needs something that the platform doesn’t provide, comes up with a solution and either discusses it with the rest of the development team, or (in rarer cases, at least in the past) on the internals list and then posts it to the codebase.

This development process makes for some haphazard functionality, and has, in the past, been the source of many annoyances that need to be handled with extreme care—both in how they are fixed and in how they are maintained for backwards compatibility.

However, some of what are arguably PHP’s most interesting and features have also been born out of this very same system—for example:

Object orientation in PHP 4 were added almost as an afterthought, and it showed. Despite the many problems that they caused, however, they also made PHP development worthwhile for many people and served as the main inspiration for the development of PHP 5, which, in turn, opened the door to many of the new features introduced by the latter.
SimpleXML was perhaps misnamed, still has a lot of limitations and required several point releases before becoming truly usable, but, at least as far as I’m concerned, it’s what makes XML manipulation tolerable in PHP 5. Without it, we’d be stuck with DOM, which, despite using the same underlying functionality, requires, oh, three times as much code.
Type hinting has, more than once, saved my behind. It took it a couple of minor adjustments (e.g.: allowing passing NULL and supporting arrays) before it became truly useful, but without it we’d have a much poorer language from a maintainability perspective.

Overall, the spontaneity with which PHP has been developed in the past is a combination of sheer recklessness (“I’ll commit and deal with the consequences later”) and a process of discovery that improves what is worth improving, while letting the rest wither (but, unfortunately, almost never die).

The recent discussion about namespaces is a clear example of what is wrong about PHP today: not the endless discussion on internals, not the noise-to-signal ratio, but the fact that someone isn’t willing to just jump the gun, commit and let the chips fall where they may. If we continue down this road, I’m afraid that one day we’ll wake up and find ourselves dealing with the new Java: all decisions made by committee, and innovation dead, somewhere in the corner with no-one to care.

⇥ A Black day

December 14, 2007
8 comments

⇥ Permalink

Poor Lord Black! He spent some of his company’s money and, next thing he knows, he’s being convicted of fraud.

As convictions go, everybody seems to be convinced that he got off easy—”just” 72 months in prison and a repayment of around $6M. Personally, I doubt that anyone who learns he has to spend six years in jail would think of having gotten off easy, but journalists obviously have never gotten over him giving them the finger.

What a waste! A person like Conrad Black doesn’t belong in jail—he’s obviously not violent (I would have punched those idiots and their cameras, not just flipped them), and he’s a very capable man. The thought of him folding laundry and cooking lunch (and making sure he doesn’t drop his soap) while taxpayers, well, taxpay for keeping him behind bars.

That’s not justice—it’s stupidity. If you want to punish a person like Conrad Black for what he’s done, there’s no need to humiliate him by throwing him in jail. Justice can better be served by asking Conrad Black to actually repay his debt to society. Instead of locking him up, force him to work his debt off with punitive community service: make him live on the means of a salaried employees—no Bentleys, mansions, private jets… just a monthly salary, like one of the lowly people who used to work for him.

In the meantime, society could take advantage of Lord Black’s obvious talents to do some good—for example, get him to generate at least $60M in revenue for a charity, and limit where the money can come from and in what quantity to prevent his friends and family from simply bailing him out.

That, to me, sounds like a smarter way of punishing a man who is used to walking all over those around him. Since it would keep him out of jail and give himself a chance to make himself respectable again, he’d probably jump at the opportunity and save more taxpayer money by not dragging his trial case on for another five years. In the process, he might actually learn some humility, instead of humiliation, and actually be useful to society, instead of costing it money.

And, if you’re worried about him cheating his way around his community service limitations, have the court impose supervision in a way that becomes more complicated and expensive the less transparent he makes his dealings—and make him pay for it out of his court-imposed earnings.

⇥ A busy box, indeed

December 12, 2007
One comment

⇥ Permalink

I normally reply to comments with comments (somehow, replying with a new post feels like cheating), but in the case of my previous post about BusyBox, the variety of comments makes it impossible, so I want to note a few additional thoughts:

First of all, J.B. Nicholson-Owens posted a very detailed and well-written (if a little acerbic) rebuttal to my post (trackbacks are off in this blog, so if you write something referencing one of my posts, please leave a comment saying so). J.B. and I have a very different idea of freedom, best summarized in this sentence:
Of course we can’t have all possible freedoms, as some freedoms conflict.
Call me a hopeless naïve, but I believe that true freedom doesn’t need to be picked-and-chosen.
Believe it or not, I have read the GPL, and I do understand it. Despite my unfortunate choice of words, I realize that using a piece of GPL software does not require redistribution of the source code. I meant the term “use” in relation to redistributing a binary package.
The goal of my post was not to state that the BusyBox developers don’t have the right to license their software any which way they want, or that they don’t have the right to
enforce the GPL, or that companies that do not comply with it are right, or that (at least according to the GPL) there is a difference between free as in beer and free as in freedom:
Personally, I have no problem with the BusyBox folks suing the pants off of those companies that infringe on their license. They are, after all, very clear on their adoption of the GPL and what they expect those who use their software to do.
I’m not sure how I can make it more abundantly clear than that, so I’m not even going to try.
Ultimately, my point was simply this: is the value of BusyBox enhanced or reduced by their choice of license? Or, otherwise stated, if there were a compatible BusyBox replacement that were licensed under a BSD-style license, would it be more successful?

⇥ Goodbye passwords, goodbye DRM

December 10, 2007
7 comments

⇥ Permalink

At php|architect (and now at Python Magazine), we are often accused of using DRM to protect our PDF files. I have mentioned in the past that this is not true, but the accusations continue—probably thanks to two facts: (a) people have no idea what DRM is and (b) technology really, truly, sucks. Let me explain.

A PDF file can be encrypted using two passwords: an owner password and a user password. At least in theory, the difference between the two is that the latter can only be used to decrypt and access the PDF in accordance with the limitations that have been set with the former. So, for example, if I am the “owner” of the PDF, I can decide whether you can print it (and at which resolution), copy and paste text and figures from it, use it in a screen reader, and so on. These are the real DRM aspects of PDF protection—not the passwords themselves.

Our stamping system uses none of these DRM flags; as far as we are concerned, you are free to copy and paste, print, screen read and do whatever you want with the PDF as long as you comply with our license (which, essentially, means don’t give it around—it’s your copy, and only you can use it).

Unfortunately, the use of passwords has two significant drawbacks. First, most desktop search systems, like Google Desktop or Spotlight, are unable to index password-protected PDFs. Thus, customers have been complaining to us that our “DRM protection” makes using our PDFs inconvenient. Of course, I could point out that this is actually a limitation in the search software, and not something that we actively disable (why on Earth would we want to anyway?), but who’s keeping track?

On top of that, Acrobat (or any other reader) do not allow users to add bookmarks or annotations to a password-protected PDF. Again, this is not something that we actively block, but simply a limitation in the PDF spec.

Why do we have passwords then? Primarily for two reasons. First, they reinforce the feeling of ownership that’s associated with those PDF files. Second, they help protect the personal information that is stamped on the PDF files (like name and user account number) in case someone else gets a hold of them. You’ll notice that I didn’t mention security here—because although the password was making it a little more inconvenient, it didn’t prevent some ill-intentioned idiot from removing all the protection and redistributing the file (after all, we need to allow people to read the PDF, and if you can read it, you can copy it, no matter how “strong” you think the protection mechanism is).

The reality is, passwords made a lot more sense five years ago, when we started publishing php|architect, than they do now. Back then, desktop search was limited (at best), and annotations were not yet part of the PDF spec. Back then, the public at large was not educated enough in the ins and outs of file ownership and, in my opinion, they needed all the reinforcements that we could provide.

Today, password protection has become a liability for us and a nuisance for our readers. It offers no real copy protection (and it never did), and it prevents our users from performing those tasks that matter to them. I have mentioned in the past that I have no sympathy for those who make the obliteration of DRM a crusade, mostly because by and large they seem to have no idea of what they are talking about, but real inconvenience for our customers (current and prospective) is something that I must take note of.

Thus, as we celebrate the fifth anniversary of our publication (has it really been that long?), we have removed all password protection from our PDFs. This means that every PDF you download from our sites (that is, from both php|a and PyMag) starting from today will no longer require a password for opening—including any product that you have purchased from us in the past and that you download again after tomorrow.

I thought this would be a difficult decision to make, but in the end it felt like the smart thing to do, both from a business perspective and from a technical point of view (encryption costs a lot of CPU cycles on our servers!). We’ve got a lot more surprises coming down the pipe… stay tuned!

⇥ Someone should rewrite Busybox

December 9, 2007
14 comments

⇥ Permalink

BusyBox is a very useful set of core UNIX utilities designed with size in mind. As such, it is often used in embedded system, where memory comes at a premium and a compact environment is necessary.

BusyBox is released under the GPLv2, a license which they have been aggressively enforcing, thanks in part to help from the Software Freedom Law Center. So far, they have sued companies like Monsoon Multimedia (note how the plaintiffs’ addresses are redacted from the complaint, but how the defendant’s was left in) and Verizon for selling and distributing products that incorporate BusyBox without disclosing their firmware’s source code as required by the GPL.

Personally, I have no problem with the BusyBox folks suing the pants off of those companies that infringe on their license. They are, after all, very clear on their adoption of the GPL and what they expect those who use their software to do.

Morally, however, I find the GPL repugnant. Its fight-fire-with-fire principle of forcing anyone who uses a piece of software to disclose all their source code in turn betrays its purported ideals of freedom in a disgusting way. There is nothing free about inflicting the GPL on someone just because they use GPL’ed software—it is no different from, say, your cellular provider preventing you from connecting anything but their devices to their network, or forcing you into a contract in exchange for a discount on the cost of your handset.

Open-source software should exist and thrive not necessarily because it is better from a technical perspective (although that is usually a consequence of its other characteristics), but because it is unencumbered with artificial limitations that throttle’s someone’s ability to use it. These could take the form of a commercial developer preventing changes that encroach on their business model, or non-commercial developers who impose limitations on usage and development on others to “encourage” transparency and openness. They are both artificial and limiting—but because the first set of limitations is enforced with profit as the ultimate goal, the peddlers of the GPL want us to think that it is somehow “wrong,” while the GPL’s viral characteristics are just and fair.

As a case in point, I am convinced that if someone came up with an alternative implementation of BusyBox that provides a compatible drop-in replacement that is not, however, encumbered by the GPL, but, say, released under a BSD-style license, BusyBox would suffer an immediate and definitive death for the simple reason that the “freedom value” of the replacement would be so much higher. I would even be willing to be that participation in the development of the replacement would be higher, simply because developers who use the software would not feel constrained by the overbearing limitations of the GPL.

⇥ Signs you’ve been working too long for today

December 4, 2007
6 comments

⇥ Permalink

Write e-mail regarding PDF file and send it to recipient without attachment
Realize mistake, resend e-mail, with PDF, but to yourself
Realize second mistake, resend e-mail with PDF to yourself, but this time copy the intended recipient
Realize you’ve sent the wrong PDF
Resend the e-mail, with PDF and to the correct recipient
The next morning, after having absorbed the third shot of espresso, realize you forgot to click the send button
Write a blog entry about it, hoping that people will read it and think it’s a funny, made up story

⇥ Rule #10 should really be rule #1

December 2, 2007
2 comments

⇥ Permalink

You might have stumbled across an article from Microsoft Technet titled 10 Immutable Laws of Security. It’s a really good piece, and I often point newbie users to it for a quick primers on the do’s and don’ts of security—it’s well written, relatively concise and authoritative.

I love, in particular, Rule #10 on this list, which reads:

Law #10: Technology is not a panacea

I wish more people would pay attention to this rule—outside of the realm of security. The ready availability of technology, together with the “your safety is someone else’s responsibility” attitude that pervades our society, has lulled us into thinking of technology in general, and software in particular, as something that has to be foolproof.

The problem is that software can only be as smart as the person who wrote it. Where more than one person is involved, the software they write is less smart than the sum of the intelligence of its creators. This means that the cost of development is not linear, but becomes exponentially higher with the complexity of the features that are being programmed.

Unfortunately, the complexity of a feature is usually inversely proportional to its simplicity from a user’s perspective. The mere act of insert a key in your car’s lock these days calls upon many high-precision features, both in software and hardware, that make the key and lock safe and secure, impervious to theft and, well, easy to use. But, to you, the user, it’s just a key and lock. If somebody told you that getting the key to fit in the lock and the whole mechanism to work probably took several million dollars worth of development time—and, still, the end product is susceptible to problems like freezing—you’d think that somebody was either crazy or outright lying. If that somebody were an engineer, you’d probably be wrong.

If complexity makes development expensive, in a controlled environment it’s relatively easy to do a bit of cost analysis and determine whether building something is worth the time (and money). A feature that saves, say 5 hours a month of customer support time but takes 100 hours of development time to develop must be considered very carefully—but the math is fairly straightforward.

The real—and hidden—threat behind not managing your development process well is, of course, feature creep and bloat. It is sometimes hard for a developer to refuse writing a new feature in a piece of software because of a number of overlapping problems: programmers like to program, and nothing is quite as challenging and rewarding as writing software that solves a problem—regardless of how real the problem is; it is difficult for a developer to make a user understand that because something looks simple to use, it isn’t necessarily simple to write. And users (including the developers and their increasingly bloated development tools) are simply jaded by the impossibly complex, and yet affordable technology that surrounds them.

How do you solve bloat? With a firm, but simple and unobtrusive development policy:

Analyze every addition. Cost analysis doesn’t have to be complex, difficult or time-consuming. Simply ask the person who requests a feature to give you an idea of how much time that feature will save, and what benefits it will bring. Refuse to take answers like “it would help me greatly,” or “I’ve had many requests about this.” Always, always quantify these things in a way that can be measured.
Estimate the cost of development. This is always hard, but it mostly depends on two things: first, have a clear spec from which to start. Have the developers discuss how a feature is supposed to work with the requesters. Second, get in the habit of coming up with reasonable estimates. Write down the steps required to implement the feature; ask your colleagues for opinions.
Consider the long-term consequences. Even the simplest of changes can have disastrous effects on the long-term viability of your software. A feature that helps your users perform a task that has the potential for creating inconsistencies in your data, for example, is obviously a bad idea—that’s an extreme possibility, but there are usually unintended consequences to writing any piece of software, so be careful.
Always explain a refusal. One of my biggest pet peeves with the PHP bug-tracking system is that it is built with more sarcasm than care. Terming a bug “bogus” and providing a canned answer to a bug report are simply stupid ideas for two reasons: first, they don’t add anything to the knowledge base built into the system, and second they discourage anyone whose skin isn’t thick enough to take it under the chin from ever filing a bug again—what’s the point if they’re going to make fun of you? Similarly, you should never dismiss a feature request on a project you’re working on simply because it’s silly. Remember—the whole point of software is to enable users to perform tasks that they wouldn’t normally be able to perform in the first place; therefore, the users won’t understand how the software works, or why implementing a particular feature is a bad idea, unless you explain why to them. Educating your users also has the side benefit of improving the quality of their relationship with the software they’re using—so that feature requests will, with time, become more reasonable and more useful.

On the subject of cost analysis, I think it’s important to point out that there is a good way and a bad way of doing it… but that’s the topic for a future post.