BoingBoing has a post this morning about an online casino publishing MD5 hashes of their virtual decks of cards to prove that when a “deck” is generated at the beginning of a game, it does not change throughout the course of the game. That brings up a larger question that I have never figured out, which is why anyone trusts online casinos at all. There are many ways for online casinos to cheat, and very few mechanisms for detecting the cheating or getting your money back if you are defrauded. Are people just that desperate to gamble?

If a casino did a lot of business, they wouldn’t even have to cheat very much to greatly increase their profits. Obviously you could force your customers to lose every time, but they’d leave in droves. On the other hand, you could lower the chances of the customer winning by a percentage point and most people wouldn’t even notice. The casino’s owners would, though, because suddenly they’d be making a lot more money.

What am I missing?

Don’t you hate it when something you think of as a good habit turns out to be a bad habit? I have long been a big proponent of defensive programming. Never assume the arguments being passed to a method are good, always validate everything, and generally protect yourself from other people’s bad code or even your own bad code elsewhere in the system. I’m here to tell you that you can go too far with this philosophy.

The systems design principle “don’t repeat yourself” is often thought of in terms of copy and paste. If you need to do the same thing in two different places, don’t copy the code from one place to another, instead put it in a method and call it from both places so that if the process changes you don’t have to remember to update the logic in more than one place.

A more subtle way to violate this principle and really get yourself tied in knots is to do the same validation in more than one place. Here’s an example of what I’m talking about. You have two classes, one produces widgets, and puts them in a collection. The other takes those widgets and presents them to the user, perhaps on a Web page.

If you’re an MVC person, think of the code that produces the widgets as being in the model, and the code that presents the widgets being in the view. Further assume that the widget-producing code is expected to produce three widgets at a time. You’re writing the code for your view layer, and you want to make sure your code isn’t going to blow up due to bad input.

The first check is a null check. You don’t want to get a NullPointerException that gets passed back to the user. (In Ruby, you need to do a nil check to avoid a NoMethodError.) That’s straight defensive programming, and needs to be kept around.

Depending on how your page works, you may want to make sure that the collection isn’t empty. So you write something like:

if (null != widgets && !widgets.isEmpty()) { // do stuff }

That’s perfectly sensible. You expect there to be three widgets in the collection, so why not also do this?

if (null != widgets && !widgets.isEmpty() && 3 == widgets.size()) { // do stuff }

Here’s where the problems start. First of all, that 3 should be a constant that’s defined elsewhere so that if 3 changes to 4 or 5 or 2, this code gets updated along with everything else. But the truth is that you should leave out that expression entirely. It looks like basic defensive programming, but it’s really business logic. You just codified the “you must have 3 widgets rule” right there in your view layer. When requirements change and the number of widgets becomes variable, this is the piece of code that will keep you up late at night.

Either this is the only place where you check the number of widgets, which is bad because it’s separated from the code that generates the widgets by a great distance, or you’ve just repeated yourself, and when you update your widget generating code, you’ll forget to update this little bit of logic in the view layer and you won’t able to figure out why your new code is generating two widgets just as you’d expect, but they’re not showing up on your Web page.

Larry Lessig pretty much gets to the bottom of the Net Neutrality debate:

One clue to this Net Neutrality debate is to watch what kind of souls are on each side of the debate. The pro-NN contingent is filled with the people who actually built the Net — from Vint Cerf to Google to eBay — and those who profit from the competition enabled by the Net — e.g., Microsoft. The anti-NN contingent is filled with the entities that either never got the Net, or fought like hell to control it — telecom, and cable companies.

Lessig uses this as his introduction to a link to Tim Berners-Lee’s thoughts on the subject, which are not to be missed.

The reason I always harp on stories about missile defense is that the missile defense program is emblematic of government activity that’s expensive, useless, and exists only for symbolic value. It’s hard to make progress when it comes to preventing weapons proliferation, so the government comes up with these missile defense programs that will theoretically keep us safe from the bad people who want to kill us. The only good thing you can say about missile defense is that unlike invading other countries, at least these programs aren’t actually killing people.

Anyway, the latest absurd turn is that in response to threatened North Korean missile tests, the Pentagon has changed the status of the test system in Alaska that never worked to operational. It doesn’t work any better than it did before, but it’s no longer in test mode. That’s a relief.

The book Programming Ruby, also commonly referred to as “the pickaxe book,” is widely regarded in the Ruby community as a must-have. Unfortunately, it doesn’t really meet my expectations. You can find parts of the book online, so you can see for yourself what I’m talking about.

Take a look at the chapter on Basic Input and Output. Let’s say you want to open a new text file and direct your output to that file. This seems pretty basic, and you’d expect to see it explained in a chapter that purports to cover input and output. On this seemingly important topic, readers are given one sentence and no examples:

The same methods that we’ve been using for “simple” I/O are available for all file objects.

Perhaps I am an atypical computer book consumer. If I’m in a hurry to get something done (and I’m always in a hurry), I find the right chapter in the book and skim the code samples to find one that illustrates how to do what I want to do, then I read the surrounding text. I’m not interested in reading the full chapter and drawing inferences, especially in cases like this where I know how to accomplish the same task in about ten other programming languages and I just need to know the syntax. Anyway, here’s the missing example:

f = File.open(“mynewfile.txt”, “w”) f.puts(“a line of text”) f.close

How difficult was that?

Looks like the article on Ceca, a Serbian pop-star/ultranationalist figurehead, is missing a bit of information. The article on her husband, Serbian war criminal Arkan, needs some work as well.

To me these sorts of articles are some of the most interesting cases for how well Wikipedia works. They are obscure to most Americans, so partisans can easily skew what is becoming the historical record for people like Ceca. The concert review describes her as an unrepentant supporter of her husband’s program of ethnic cleansing. The Wikipedia article treats her as a generic pop star, despite some discussion of incorporating her baggage in the article.

Even though I never actually read the book, Lawrence Lessig’s book Code and Other Laws of Cyberspace is often on my mind. The book’s argument that code and algorithms are rules as much as anything else should be always be in the back of the mind of every programmer.

Just look at the different kinds of content management systems out there. The rules for editing content in a wiki are very different than those for editing content in a weblog application, and those rules are the essence of those applications. It’s illegal to share copyright-protected digital media, but there’s lots of code out there that makes it easy to do so. It’s not illegal to watch DVDs from Europe in the United States and vice versa, but DVD players come with code preventing you from doing so.

For an application developer, one of the key considerations (that often doesn’t get considered) is what kinds of user behavior should be encouraged or discouraged. To put it in economic terms, when you build applications you have to think about incentives. For example, let’s say your application provides two features for notifying people of updates, an Atom feed and email notifications. If you want people to use the Atom feed, you hide the “subscribe to email” link in an obscure place and you put feed icons everywhere. There were a couple of items about managing user behavior on the O’Reilly Radar in May, one about Amazon.com allowing customers to provide credit card numbers over the phone, and another about profile photos at various social networking sites. Both looked at how user interface design affects how users behave.

Which brings me to my point. At work we have an application that allows people to collaboratively build a library of frequently asked questions, and it includes mechanisms for reviewing content for public release. It’s actually an application I’m pretty excited about, and that I’ll write more about later. Right now one of our big internal discussions is about who is allowed to view and edit which content, and what they’re allowed to do with it. There are two “code is law” related issues here. The first is that everything in our application is text, so if people can see the content, they can easily share it with people outside the system. That’s beyond our control. The second is that ultimately the code determines the model of participation for the system’s users. Do we allow anyone to edit anything, wiki-style? Or do we lock things down so there’s a privileged class of users who are the gatekeepers for the content? What model furthers the mission of our organization?

The most interesting thing about being a developer is that code establishes the facts on the ground. So even working within the requirements laid out by the organization, we still have a lot of leeway when it comes to establishing how people use the application. The question is whether we’re conscious of that and how we use it. At work, we’re wrangling with the requirements and building the application itself at the same time. The challenge is fulfilling the requirements and building something that enables our users to create the kind of community that we envision. It’s an interesting challenge.

When it comes to Ruby on Rails style, one of the toughest decisions to make is how many controllers you need. The default custom for Rails seems to center around having one controller per model, but that doesn’t always make the most sense.

To discuss this at a high level for a moment, models generally mirror the structure of the database, so there’s one model per table. Controllers are arbitrary collections of actions, but are usually associated with a particular model, so if you have a model called “posts” in a weblog application, you might have a controller called “posts” as well, with actions like list posts, new post, edit post, and so forth. This was generally the pattern I followed when I started creating Rails applications, but increasingly I’m finding there are other ways to group functionality in controllers that make more sense.

For example, one alternate form of organization is grouping functionality by the rights required to use it. In the Rails Recipes book, there’s a recipe for an authorization system that is based on controllers and actions. Grouping actions into controllers based on privilege makes that system easier to apply to an application. For example, I have an admin controller that has all of my actions that are only for administrators, regardless of which model they pertain to, and a feeds controller that requires no authorization at all.

Rails in many ways works like other Web application frameworks that I’ve used before, but the grouping of functionality into controllers is a new way of organizing things to me. In PHP you generally have one template per action (unless you play games with the query string to reuse templates), and with Java frameworks like Struts and Spring, you have one big configuration file for your application and then one “controller” for each action. You could certainly follow either of those patterns in Rails, but it would be ungainly.

Another criteria I use when deciding whether a new controller is needed is URL cleanliness. We added some personalization features to our application, so we created a new controller called “my”. The URLs based on that controller are things like “/my/watchlist”, “/my/contributions”, and “/my/reviews”. They’re very easy to read and remember. All of those actions could just as easily be in another controller associated with a model, but breaking them out made sense to me.

The routes.rb file also comes into play when it comes to making decisions about controllers. You can use it to manipulate URLs in any way that you choose, but as a general rule I prefer to do as little URL hacking as possible and instead stick with the default structure of Rails applications. Using routes.rb, you could use many controllers and make your application look like you use only one or vice versa. Doing so would make things hard on developers, though, because then you lose the default mapping of URLs to controllers and actions, and it becomes harder to map URLs within your application to locations in your code. I prefer to avoid that.

For the other Rails developers out there, are there any rules of thumb you apply when it comes to how many controllers you create?

If more than half of the pictures on your Flickr account are screen shots, Flickr will suppress your images in global search results. The theory is that people come to Flickr to see photos, not group shots of your World of Warcraft guild or the sculpture you just created in Second Life.

This is strictly a business decision. Either Flickr knows their users as well as they think they do, and this is the right call, or they’re cutting off a potential market for no good reason. Which is it? Beats me. The one thing that’s certain is that Flickr is a much better application for sharing screen shots than anything else I’ve seen, for the same reason it’s great for sharing photos.

If images could be categorized as screen shots, Flickr could just add an “include screen shots” flag to searches, so people could specify the kinds of things they care about. I wonder whether it would be difficult to write an image processing algorithm that automatically differentiates between photos and screen shots? I’d bet that it could be done.

Updated: See the comments for the final word on the subject from Flickr head honcho Stewart Butterfield.

The other day I wrote about how YouTube has revolutionized video on the Web by making it accessible to just about anybody, regardless of which platform and browser they use. That’s still not the case for many other Web sites, even sites that launched recently. I have been trying to watch the video clips from fifaworldcup.com (created by Yahoo), and I cannot get them to play on my Mac under Firefox or Safari. That’s broken.

I should note that the MatchCast application is very nicely done. I just wish they could get the video stuff to work for us Mac users.