I’ve moved PottyMouth to BitBucket.org, where you can keep up to date with PottyMouth releases, subscribe to feeds, request features, and contribute patches. (It’s also on PyPi.)
In the last few months, I’ve fixed a bunch of poor design decisions on my part around encoding and repr() within PottyMouth, and added new syntax suggested by users. The latest version is 1.2.0.
Even if you’re a halfway decent programmer, these signs that you’re a bad programmer will help you identify bad code.
It’s business as usual over at Ubuntu headquarters. This time the “Root Terminal” menu item, installed in the system menu by default for at least the last few years, is suddenly broken. Irate users commenting on bug reports in Launchpad are dangerously close to starting a full-blown flame war:
Sebastien, your comment seems to imply that Launchpad bug reports are a waste of time. Is this really what you meant? I had been under the impression that Launchpad was intended to be a gateway/portal for bug reporting. If Launchpad reports do not get forwarded upstream automatically once triaged then what purpose does it have? –Russel Winder
and:
With all due respect Sebastien — I can hardly believe that
I’m reading this: “ubuntu only distribute it”.(why even have a bug reporting system in the first place,
one wonders, btw.). –bjd
(That’s right, those are in response to the same Sebastien Bacher I took to task for unhelpful comments on other bugs last year.)
The bug itself isn’t Ubuntu’s fault, but the fact that the menu item survived intact in the default Ubuntu configuration despite being non-functional for (at least) the last four months speaks volumes about what passed for testing on Jaunty Jackalope1.
Temporary workaround, until Gnome fixes this regression and Ubuntu inherits it: change the menu item to gnome-terminal -e 'sudo -i'. It took me longer to write this paragraph than to change that.
Part of an ongoing series.
The relational database is an extremely powerful tool. But sometimes data isn’t very relational, and sometimes transactional, relational, integrity is not as important as it is for, say, a bank. This is one reason why so many sites can get away with mySQL backed by myISAM tables — they’re fine if you’re read-heavy and data integrity is not mission-critical.
Some new projects have sprung up which provide key-value stores or simpler kinds of databases without all the overhead and inflexibility of a relational database.
On the other hand, sometimes data is way more interrelated than a traditional relational database is prepared to handle. Sometimes different kinds of items (i.e. rows) in a database can be related to many other kinds of items in that database, and sometimes end users can create not just new items or new relationships, but new kinds of relationships between items. This type of database is called a graph database, and there are also projects pushing the boundaries of relational in this completely opposite direction.
Pretty much everywhere I interviewed back in February 2008 was either building their own graph database, working on an existing one, or repurposing a relational database (or, in one case, a search backend), to kinda, sorta behave like one. The w3c, not one to be left behind when there’s a specification to be written, is even working on a SQL-inspired query language intended to search them1.
Most applications have some combination of totally un-relational data that can go in a key-value store, some strictly relational data that belongs in a SQL database, and some flexible, highly relational data that belongs in a graph database.
What will happen when these alternative databases start giving traditional relational databases a run for their money? Well, sharding, caching, and normalization all start to sound a lot more complex when the data is in a few different kinds of databases — but then again, maybe optimization won’t be as necessary if a single SQL database isn’t doing all the heavy lifting. Object-relational mappers (and the web frameworks that use them) might need to talk to, and abstract away from, different kinds of databases2.
And the different types of data won’t always be easily separated along table boundaries. Maybe these different types of databases will talk to each other, or maybe they will mature into über-databases that understand lots of different types of data relationships.
But the monolithic, strictly relational, master SQL database is eventually going to go the way of Cobol3.
Part of an ongoing series.
A web application is just a stateless1 application that responds to various requests by performing actions and providing resources. There’s no fundamental reason an application must only communicate over HTTP. Web applications are going to start adding alternative methods of interaction, and I think the first common one will be email.
Perhaps an example will best illustrate this:
Like many web forums, posts to Mosuki‘s discussion forums get mailed out in email. But, unlike any other web forums I know of, they also behave like mailing lists. All the emails have a reply-to header with an email address that identifies the message, the recipient, and the action to be taken if that email address is used. In this case, the contents of a reply email are posted to the forum exactly as if a reply had been posted via the website.
In other words, the action “post a message” can be accessed via a web page and a browser or via a reply-to header and your mail client.
There are other examples of this separation between input/output channels and the application logic. The most obvious is Twitter, which of course can be interacted with via HTTP or SMS2. And the Son of Sam project intends to let you “use modern concepts like handlers, requests, responses, state machines” to interact with email.
Confirm a Facebook friend request, RSVP to an Evite, revert a Wikipedia edit, or reassign a bug report, just by replying to an email or sending an SMS.
There are a number of technical issues inherent a system like this. An application’s framework has to handle multiple input channels, and massage email bodies, HTTP requests, and other input into a least common denominator “request.” Authenticating a user via email, an intrinsically forgeable medium, and protecting against spam, are non-trivial challenges. And a suite of templates suddenly gets a lot more complex when it has to provide views for multiple types of interfaces3 .
This blurring of the line between email, HTTP, SMS, and other communications is not new, strictly speaking. But I think it will become commonplace and even expected. Rather than writing a modern (MVC, stateless, REST-ful, &c.) web application, people will be writing modern (MVC, stateless, REST-ful, blah, blah, blah) applications that have web interfaces, email interfaces, and whatever other interfaces they need.
Stay tuned for the next installment of The next big thing: Taking the relational out of relational databases.
Like Josh Haberman, I was excited to see the changelog for Ruby 1.9, but immediately disappointed by its vagueness and terseness.
This list is meaningless to anyone who isn’t already familiar with the changes that have been happening in Ruby 1.9.x.
For someone like me who tried an older version of Ruby, there’s nothing to read that will tell me whether it’s worth checking out again.
Take this example, from the changelog:
- IO operations
- Many methods used to act byte-wise but now some of those act character-wise. You can use alternate byte-wise methods.
That’s terrifying. If I’m switching to a new version, I need to know exactly which methods have changed and which ones haven’t. Saying that “some” have changed is almost less helpful than saying nothing at all.
Here’s hoping that “improved documentation” will make it into a future Ruby 1.9.x release.
In the same blog post, Haberman makes some inaccurate assertions about Python’s encoding support:
Python has taken an “everything is Unicode” approach to character encoding — it doesn’t support any other encodings. Ruby on the other hand supports arbitrary encodings, for both Ruby source files and for data that Ruby programs deal with.
Incorrect. For the last five and a half years, since Python 2.3, source code in any encoding has been supported, and Python 3.0 will expect UTF-8 by default. And of course, Python supports exactly the same wide range of encodings for data. Python’s approach can best be described as “Unicode (via UTF-8) is default.”
I’ve just posted Relational databases and free-form data over on the Mosuki blog.
There are two quite different reasons for implementing HTML generation on a website. The first reason is to insert dynamic content, content that comes from a database or is algorithmically generated, into pages. The second reason is templating; to ensure that standard, site-wide parts of the HTML, such as headers and footers, are pulled from a single source. The goal of the first is to have a dynamic, database-driven site. The goal of the second is to avoid having to edit tens, or hundreds, of HTML files when the site design changes, and to avoid copy-and-paste coding.
This all-Flash interface (screenshot) is a complete reimplementation of the WordPress blog interface; One single Flash widget fills the entire browser page, and implements not only the home page, but categories, comments (including posting), and article pages. It sounds like the author intends to use it to replace the HTML interface to his blog entirely. It’s a great example of why you should never build an entire website purely in Flash.
Hank Williams makes an excellent point about the restriction that apps on the iPhone may not run in the background.
[the] issue [of resource limiting applications] has been dealt with in Unix, and with real time systems for many years.
In short, this argument is a strategically placed fig leaf, which is easily blown away.
Previously, I thought the no background applications restriction was a good call on Apple’s part. This article totally changed my mind. Williams is right; and Apple will have to lift this restriction before long, or risk being overtaken Android and others.