Pinderkent

The recent Why so few developers are using Firebird SQL? article has generated a fair amount of discussion, including some at Reddit. For those who might not be aware, Firebird is an open source RDBMS based on the InterBase 6.0 source code that Borland released just under a decade ago. Since then, it has been under continuous development, but really hasn't caught on like other open source databases such as PostgreSQL, MySQL and SQLite have.

About a year ago I was working with a company who was considering the use of Firebird for a new in-house application they were developing. I wasn't directly involved with this particular project, but did talk to some of the developers working on it. Having used InterBase years ago while working on some Delphi-based software, and having heard of Firebird, I was interested in seeing what they had to say about it. While they didn't have many technical complaints, there were a few factors that resulted in them opting to use PostgreSQL instead.

Technically, InterBase and Firebird aren't bad database systems by any means. They do offer exactly what's needed and what's expected by many users. My experience with InterBase years back was that its performance and reliability were quite suitable, and I don't have any reason to think the situation would be any different now. Personally, I would entrust Firebird with valuable data and availability over MySQL. The project I mentioned earlier basically had the same opinion, as I recall. Their complaints weren't of a technical nature.

One significant complaint they did have was with Firebird's documentation. When they looked at it, it was basically the InterBase 6.0 manuals with separate documentation outlining the changes and additions made by the Firebird developers. Checking the Firebird documentation page now, about a year later, it seems that it is still a combination of the InterBase 6.0 manuals and the Firebird 2.0 Language Reference Update document.

Not all of the developers working on the project had used InterBase 6.0, and facing relatively tight deadlines, they didn't expect to be able to get everyone up to speed fast enough if they had to become familiar with InterBase 6.0 first, and then "patch" that knowledge with the Firebird updates. One major benefit of PostgreSQL is that it offers very comprehensive and accessible documentation online. The vast majority of questions and issues can be resolved by referring to the appropriate section of their documentation.

The developers and managers of the project I mentioned earlier also felt more comfortable with the community and development processes around PostgreSQL. I'm not sure what sort of research they did to come to this conclusion, but I recall them saying that they thought the PostgreSQL developer and user community was more "stable". My interest in their findings was more technically-oriented, so I didn't follow up much with respect to this.

Personally, I'd like to see greater adoption of Firebird. I think it has technical merit, and given its heritage it should be production-ready for many users. Streamlining the documentation might help encourage its adoption. It won't be an easy task by any means, but if the Firebird project could produce and then maintain some documentation on par with that which the PostgreSQL project has put together, the burden on new users would be eased greatly. We may then see more people willing to at least give it a try.

I just finished reading Marcus Cavanaugh's recent The Cross-Platform Myth article. The first two-thirds or so of it are quite correct. He points out that when an application is developed for two or more desktop environments that differ in some pretty fundamental ways, like Windows and Mac OS X, the result usually isn't too great. The app likely won't fit in well on one or more of the platforms, which can lead to usability problems, and may even result in users not adopting the software.

At the very end of the article, however, he writes the following:

The only acceptable cross-platform UI toolkit lives in your web browser. If you want your application to work on both Windows and OS X, create a web application. In the browser, you can freely design a custom user interface that won't seem out of place on any operating system. Users understand that web sites operate under different rules.

I find this reasoning quite absurd. First of all, Web browsers are some of the worst-conforming desktop applications around. Early in the article, he even mentions Mozilla Firefox as an example of a cross-platform application that just doesn't fit in anywhere. But Firefox isn't the only browser guilty of this. The Windows port of Apple's Safari Web browser clearly doesn't behave like a typical Windows app, either. And to some extent, the same even goes for Opera.

So not only are Web browsers themselves perfect examples of UIs that target the lowest common denominator, but the environment that they present is that very same philosophy taken to the extreme. The only consistency is that there's inconsistency. The built-in UI controls or widgets are extremely limited. And everyone who has even had to do a minor amount of Web development knows that the environment differs significantly between the different browsers.

When it comes to Web applications, it's not that they "won't seem out of place on any operating system." Rather, it's that they won't fit in with any existing desktop environment. In a sense, Web applications are typically so horrible in that respect that most users can't even recognize how bad these applications are. For some odd reason, users tend to use confusing, inconsistent or poor-quality Web applications far longer than they would the desktop equivalents.

The situation likely won't improve. Like Marcus mentions in a footnote in his article, RIAs only make the bad situation even worse. They allow for further inconsistency in an already inconsistent environment. And the other "innovations" we are seeing are just poor attempts to bring existing desktop application concepts within the browser. The canvas element and O3D are good examples of this. They both pale in comparison even to the cross-platform, desktop-equivalent abstractions of libraries and APIs like wxWidgets, GTK+ and OpenGL.

In fact, the Web development community has even gone so far as to try and abstract away the variety of programming languages we have available with a typical desktop environment. We are stuck using JavaScript, which ends up bringing us the worst of all worlds, like the Web application development environment itself.

All in all, those of us who have developed real desktop applications for years and year end up being quite disappointed with what Web development offers, or more correctly, all that it doesn't offer. We've thrown out everything we learned during the 1970s, 1980s and 1990s, only to replace it with half-baked, browser-based "alternatives" over the past decade. We've essentially taken a huge step backwards, amplifying the very problems that Marcus spoke out against during the first part of his article.

Recently, there was a thread at Hacker News about whether MySQL or PostgreSQL is a better option. These days, I'm not so sure that's even the right question to be asking.

There are many factors to take into account when choosing a database. For some situations, you basically need the functionality offered by advanced database systems like DB2 and Oracle. But many databases need only a small subset of the functionality offered by the more complex database systems. In such situations, the various open source databases are typically a suitable solution.

If you're working on a smaller-scale system that will nevertheless still need to store larger amounts of data, perform more complex queries and support numerous simultaneous users, then PostgreSQL is clearly the way to go. It has over two decades of maturity behind it, and this shows by its high degree of quality and its rich feature set. Even after spending some time working with higher-end database systems, one doesn't generally feel out of place when using PostgreSQL. It typically offers the features and performance necessary for the majority of database-related tasks.

One of the main complaints regarding PostgreSQL is with respect to its support for replication. I'm not sure if these complaints are with much merit. I've seen several enterprise systems making use of Slony-I for replication, with very acceptable results. The performance wasn't always as good as the DBAs I talked to would have liked, but that alone wasn't enough to drive them to other database systems.

On the other hand, for database applications where the data set is smaller, the hardware or hosting environment is more constrained, or the database will be used mainly in a read-only capacity, then SQLite is often the way to go. For being such a small database system, it proves to be a very practical and flexible solution.

Aside from those using it in an embedded or constrained environment, I've seen several companies who use it to power intranet Web sites and applications that receive a fair amount of traffic and use. Given the power of even low-end server hardware today, SQLite proves to be a very effective replacement for MySQL. The fact that it is server-less reduces setup times to almost nothing, and makes creating backups quite painless.

So when intentionally going with an open source database today, SQLite or PostgreSQL are typically the best candidates to choose, depending on the exact situation at hand. To a large degree, we have even seen them squeeze MySQL out of the picture. For those looking for features, reliability, and performance, PostgreSQL is often a better choice than MySQL. On the low end, SQLite usually offers better resource usage, involves less setup and maintenance effort, is easier to back up, but yet is still capable of handling sizable loads without performance problems arising.

So as I mentioned earlier, I think that the question today should not involve MySQL and PostgreSQL, but should instead involve SQLite and PostgreSQL. Only after we have asked the right question can we start to determine which database system is actually better for the needs at hand.

My current work involves working on some Web applications developed using Django. Although I've used Python much in the past, my experience with Django was quite limited. So I recently did some research to become more proficient with it, and will list below some of the Web pages that I found provided the most useful tips and tricks for when using Django.

• Some Django tips: Although an older article, it also makes some good non-Django suggestions, like installing IPython and ensuring your project has a test suite.
• Small Django tips from one newbie to another: Another older article, this one also emphasizes the need for unit testing, and gives some examples (with code) about how to go about this. It also discusses ways to manage frequent model changes during development.
• Usefull tips to start a new project with Django: A slightly dated article that summarizes how to get started with Django, and well as some suggestions for when deploying a production Django application.
• Django Tips: UTF-8, ASCII Encoding Errors, Urllib2, and MySQL: Gives useful tips about handling UTF-8 encoded strings. Although the project I'm working on thankfully didn't make the mistake of using MySQL, this article does include some tips relating to string encoding and MySQL, which may be useful for some people.
• Big list of Django tips (and some python tips too): This offers perhaps the greatest quantity of Django tips in a single page. It's quite complete, covering areas such as deployment, configuration, templating and views, the model, testing, and so forth.
• Tips for Scaling a Web App: While not completely Django-specific, it lists some good ideas for how to develop a database-backed Web application that scales well.
• Django Tips: PIL, ImageField and Unit Tests: Gives some time-saving suggestions about using the Python Imaging Library with Django and unit tests.
• Django Image Uploading: Tips and Tricks: Outlines how to upload images in Django apps, with some suggestions about how to solve some common problems.
• 10 Insanely Useful Django Tips: I think the title of this article overhypes it somewhat. The tips are useful, but they are somewhat common-sense tips, as well. Although I haven't tried it yet, this article did point me to django-debug-toolbar, which sounds like it might be useful.
• 'Practical' tips for working with Django: Includes some suggestions regarding developing custom managers, wrapping generic views, and converting text to HTML before rendering the template.
• Debugging Django: One of the more detailed articles I found suggesting some strategies for debugging Django applications.
• Django development tips: Some ideas for setting up a long-running Django development server in a UNIX-like environment using GNU Screen. More advanced users of UNIX-like systems are probably familiar with this technique, but this article is still a useful reference and tutorial for newer users.
• Django Tips - Unique Date Querysets: A quick suggestion about how to get all of the unique years and months for a data set such as the posts in a blog, or other timestamped data.
• Favorite Django Tips & Features: This thread from Stack Overflow contains a variety of user-contributed tips. Some of them suggest software to use in conjunction with Django, including Jinja2.
• Tips to keep your Django/mod_python memory usage down: Some deployment and configuration suggestions to reduce Django's memory usage when using Apache and mod_python.
• Django Doctest Tips: Some tips for testing Django applications using doctest. Suggests better ways to locate failures, to use conditionals, to check context variables, and to check content type relations.
• djangotips on Twitter: I didn't find the quality of these user-contributed tips as good as those from Stack Overflow or the other pages, but there were a few that seemed like they might be useful.
• Django Tips, Vol. 1: Contains five tips covering topics like the difference between 'blank' and 'null', displaying multiple fields on the same line in the admin, and so on.
• Django cheat sheet: Although this is a cheat sheet, and not really a Web page, this is one of the cleaner cheat sheets that I've seen. I've found it to be a useful reference so far.
• Django performance tips: This article is also older, but many of its suggestions are very sensible and apply even when not using Django, such as using separate database and Web servers if possible, using PostgreSQL, and putting as much RAM as possible into the servers.

Of course, those are just a small sample of the many useful Django resources out there. But for those new to Django, reading through the articles about may help avoid some common pitfalls, as well as offer ideas to help become more productive while getting accustomed to Django.

The Where are the RIA "killer apps"? article that Kas Thomas recently wrote is both insightful and absolutely correct. Despite all the hype around them, he correctly points out that RIAs, short for Rich Internet applications, have been an utter failure. And it's not just one vendor's implementation that has failed, either. We just haven't seen anything truly useful produced using Microsoft's Silverlight, Adobe's Flex and Sun's JavaFX.

In the past, I have written about the lack of technical merit of these RIA platforms. I think this contributes to why we really haven't seen anything truly innovative and useful built upon them. They're such a feeble foundation to begin with that perhaps they can't allow for anything truly useful to be done with them.

One thing we can consider is why some people think we even have a need for RIAs in the first place. The typical argument is that the Web browser just isn't a suitable platform for building more complex applications. This is obviously quite true. The browser and the Web were originally intended for displaying documents and allowing for navigation between them. Over time, hacks like JavaScript were integrated into the more popular browsers, allowing for some degree of programmability. Some developers soon mistook the browser as an application development platform. So here we are today, with many believing that the Web and Web browsers are somehow replacements for our existing desktop environments.

Of course, the Web browser is quite a crippled software development environment. You're limited to essentially one language, JavaScript. Pixel-perfect layout is a huge hassle. When you add in the numerous bugs, incompatibilities and inconsistencies between browsers, life becomes even more difficult. In short, what we could do relatively easily with more traditional application development platforms quickly becomes much more awkward in the Web browser, leading to poor-quality applications that take longer to develop.

RIAs have arisen as a bandage to try and make application development within the Web browser more friendly. Java applets and Silverlight are good examples of vendors trying to essentially push their desktop-oriented platforms into the browser. Of course, anyone who has developed software using the non-embedded versions of those platforms know how much nicer they are to work with than the browser-based variants, and more importantly, how much more productive.

I don't think that RIAs and their platforms can be salvaged. They're a failed technology, built specifically to exist within a feeble technology. If we want our applications to be network-aware and network-accessible, there are much better approaches. And nothing is stopping is from using HTTP; we can use it more effectively if it's not returning HTML, JavaScript, or CSS. So perhaps we should just let these RIA platforms die off, so we can get back to writing innovative software using real application platforms that promote developer productivity.