Pinderkent

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.

Today I read an article that discussed a variety of issues relating to Microsoft Windows today, including the general disappointment surrounding Windows Vista, and the apparent lack of interest in Windows 7, especially in the enterprise. It goes on to suggest that Microsoft themselves are responsible for this, and Apple will gain the most from this situation.

I don't think we're really seeing Microsoft tarnishing the Windows brand. In some sense, it's not even possible for them to do that. Many people, and not just Mac users, have an extremely low opinion of Windows to begin with, along with many of Microsoft's other software products. Although the NT-based systems typically don't suffer as badly from the chronic crashes and security flaws that plagued Windows 95, Windows 98 and Windows ME, users of those earlier versions will forever associate the names "Microsoft" and "Windows" with poor-quality software. Even today, I rarely meet people who outright like Windows. Most of its users just seem to tolerate it.

If anything is causing Windows to become more irrelevant, it's the widespread move towards Web-based applications. This isn't a novel observation, by any means. It has been obvious for some time now that many applications that were formerly desktop apps have been replaced by Web-based alternatives for a large number of people. People using Web-based email services like Microsoft's own Windows Live Hotmail and GMail instead of desktop mail clients is one significant example.

The move towards Web-based applications is a trend that has been common within enterprise software development for years now. More and more companies are replacing what were traditionally desktop applications with Web-based alternatives. Now this often isn't a good idea; there are some applications that are much better left as standalone apps. But in many domains, the software the users are interacting with is solely browser-based, and thus the underlying desktop operating system is essentially irrelevant.

When the user is interacting mainly with a Web browser, it really doesn't matter what operating system is underlying it. Mozilla Firefox and Opera alone are typically good enough for using most Web-based apps. So the need for Microsoft's software is diminished. This is why GNU/Linux has become more appealing for many enterprise users. It's not about GNU/Linux being more capable than Windows, but rather the opposite; it's easier and cheaper to strip GNU/Linux down to provide just the bare essentials for running the browser used to access the Web applications.

Microsoft saw the threat that Web-based apps posed to desktop applications, and put forth their Windows Live and Office Live initiatives. I'm not sure if these have been as successful as Microsoft would have hoped. In my experience, I've seen little to no serious adoption of these technologies in enterprise settings. This is one area where Web-based applications typically aren't as useful or acceptable. Many enterprise users want greater control over their documents, namely where they are stored and who can access them.

I think it's doubtful that Apple will truly make significant inroads into the enterprise. While some such users will likely switch to Apple's hardware and software, and others will no doubt consider it, given the current cost of Apple's offerings I don't see it happening on a wide scale. Much enterprise computing has been driven by large purchases of lower-quality and very low-cost PCs. As mentioned before, with many organizations moving towards Web-based applications, the need for overly powerful PCs is diminished. With low-end PCs still being suitable, many IT managers will need to cut costs by using GNU/Linux instead of Windows, rather than purchasing more expensive hardware/software combinations from Apple.

So we're likely looking at a more diversified computing world, with some users using desktop apps, others mainly using Web-based apps, and many using a mix of both. It's very unlikely that we'll see Apple's products, or any other company's products, achieve the same market share that Windows holds. There's just too much impetus at this time for such significant changes, even if future versions of Windows are as poor as Windows Vista was.

Recently, a new version of the freshmeat.net Web site was made public. For those who may not be aware, it is (or at least was) one of the best software directories out there. Its emphasis on open source software makes it particularly useful. But until this new version, it also presented a very clean interface that was practical to use. Unfortunately, I think we have lost much of this usability with this latest version of the site.

Let's start with one thing the previous design of the Freshmeat site did right. Notice that it uses the entire width of the browser window. This is very useful for those of us with larger monitors or those of us with higher screen resolutions. While we often want to restrict the width of a prose-based Web site to improve readability, as in the case of blog postings and news articles, I don't think it works so well in the case of Freshmeat's new design. Its width is currently 960px, which leaves literally inches of wasted space on even just a 22-inch widescreen monitor at a resolution of 1680x1050.

The image below compares the old design at the top, above the red line, to the new design at the bottom of the image, demonstrating how the old site made more effective use of screen space:

On the old design's main page, along the left side and throughout the center of the page, we get a listing of the most recent software releases. This very quickly tells us the name of the project with the new release, the new release version number or identifier, when the release notice was posted, a summary describing the software, a summary describing the changes, as well as other information like categories the software falls under, its license, and relevant URLs. We get access to a lot of information very quickly. This is something else the new design isn't as effective at doing.

As an example, we can look at the entry for the NorfelloCMMS OS 2.0.0 release, made on November 22, 2007. Under the old design, it looked like:

With the new design it now looks like:

One thing to notice is the different date format. The previous design mentioned the release year, which is absent from the new design. As is shown by this example, it's important to show the year, as we may be looking through the archives at releases several years old.

Another difference is that of the length of the description. This is perhaps the worst aspect of the new design. Notice that with the new design, it's truncated after a couple of lines, with it necessary to click the "more.." link to see the full description. On the other hand, the old design provided the full description. While something can be said for writing short, concise descriptions, sometimes it isn't possible to do that effectively in the mere 200 characters that the new design seems to allocate to project descriptions. A truncated description like that is more awkward to work with than a description that is slightly too long.

Although not visible in the NorfelloCMMS OS 2.0.0 release example, it looks like the change descriptions are truncated as well under the new design. The old design displayed the full changelog, without truncating it and forcing the user to click on a link to see the rest of the changes.

Where available, a screenshot is shown for each release. Unfortunately, on the main page, the screenshot thumbnail is nearly useless. They're just too small to be of any practical value at 90px by 70px. Unfortunately, clicking on the thumbnail brings you to the project page, which has only a slightly larger, but nearly as useless, 133px by 100px image. It takes yet another click on that thumbnail to finally display a larger, somewhat comprehensible, version of the screenshot.

One other useful feature of the old release entries was the hierarchical categories. For example, the NorfelloCMMS OS 2.0.0 entry was listed under "Information Management :: Issue Tracking", "Office/Business" and "Office/Business :: Scheduling" with the old design. With the new design, it's under the single-level "Office/Business", "Information Management" and "Scheduling" tags. I personally found the old hierarchy more organized than the new scheme.

The greater usage of images, in the form of per-release screenshots and gravatars, has also increased the size of a request for the various pages. Although it's not a perfect example because it's an archived version of the page, the November 22, 2007 release listing comes in at a mere 48 KB, according to Firebug. The new listing for that date comes in at 426 KB. Although not a huge deal in these days of widespread broadband Internet access, that does translate to the difference between a site that feels snappy, and a site that feels slow.

The above highlights just a few of the problems I've noticed with the new site. I've tried to give it several days of use, to see if it'll grow on me, but so far it hasn't. Some of the more serious issues, such as the truncation of the descriptions and changelogs, would be relatively easy to fix. Others, such as the new tagging scheme, may be more difficult. And although I probably won't stop using Freshmeat altogether, as it is a valuable resource, its usability has taken a hit for me.

Today at Reddit there was a posting about a simple 2D bouncing ball physics simulation written in JavaScript. This is the latest example of a simple JavaScript demo that, for some inexplicable reason, gets many people excited.

Thankfully, there are some other people who see these JavaScript demos for what they truly are: something to not get excited over! One of the best replies to that Reddit posting points out how it ought to be easier to make such demos in JavaScript than in other programming languages. And that poster also correctly points out that there's no need to get excited over such trivial applications.

Another reply pointed out the demo's extreme similarity to Pong, a game from the early 1970s. It's also somewhat similar to Breakout, a game from the mid-1970s. Indeed, many of these JavaScript demos are often no more original than what we had over 30 years ago. Mind you, the equivalents from 25 or 30 years ago ran on computers with a small fraction of the processing power and memory of a typical desktop PC today. The developers back then actually had significant hardware constraints, unlike those behind the JavaScript demos of today.

Several others noted just how poorly this demo performs, even on modern systems when using modern Web browsers. One such user reported that it could animate at most five balls on his laptop with an Intel Atom processor before it became unusable. Although Atom processors aren't the most powerful by any means, they should be more than sufficient for the computation necessary to perform basic 2D collision detection and animation.

One user reported that it lagged in Firefox 3 on Mac OS X. Another reported performance problems while using Firefox on Linux.

As usual, we can't have a discussion about JavaScript demos or games without mentioning the unreasonable memory requirements of these demos. I think that poster's claim of 200 MB of RAM usage is, unfortunately, quite realistic. Using Firefox 3.0.5 on Linux, just starting up Firefox resulted in a process that was using 456 MB of virtual memory (as reported by top), with a resident size of 75 MB. Drawing a slightly downward sloping horizontal line, which allowed for approximately three balls to be on the screen simultaneously at the default drop rate, bumped the virtual memory usage up to 523 MB, with 176 MB resident. And extending that line somewhat longer, to allow about eight simultaneous bouncing balls at the default drop rate, bumped the memory usage up to a whopping 587 MB virtual, with 204 MB resident. After leaving the demo running for several minutes, it had stabilized at that point.

I don't think I'll ever understand how somebody could possibly become excited, even in the slightest, over these sorts of JavaScript demos. What they demonstrate was usually demonstrated better, using a fraction of the resources and processing power, two or three decades ago! The performance is typically terrible, even on higher-end PCs a month or two old, using modern Web browsers. It's not surprising to see 100% CPU usage, as well as hundreds of megabytes of memory being used. So in the end, all they do is exhibit essentially no innovation, poor performance, poor resource usage and prove yet again how awful JavaScript is for such simple applications. In short, there's absolutely nothing to be "amazed" or "excited" about with these JavaScript demos.

The recent 6 Signs of Adaptive PHP article gives some examples of different PHP coding techniques. Unfortunately, it only bothers to cover the supposed "benefits" of each, without any consideration of how such techniques can prove to be problematic.

The first technique suggests passing all arguments to a function within a single associative array. The supposed "benefits" all promote laziness, namely in that all parameters become potentially optional, and less or no change is needed to any invocations of the function if parameter changes are made.

Not mentioned in that article were the drawbacks. One obvious problem is the vastly increased verbosity, both when it comes to handling default values, and when it comes to invoking the function. Default parameter values, as offered by languages like C++ and even VB.NET, are syntactically superior to this approach.

Even the very concept itself is flawed, as it's much better in terms of maintainability and clarity to have an explicit list of parameters. For one thing, this technique makes it much less obvious to other programmers how to call the function. Given the general lack of documentation associated with most PHP applications, it's likely that anybody wishing to use the function would have to consult the code of the function itself. It also inhibits the ability of the interpreter to check that the correct number of arguments have been passed to the function.

Furthermore, if one has a function that has so many optional parameters that such a technique is needed, perhaps too much is being done in that single function. It would appear that such a function is a good candidate for heavy refactoring.

The second suggestion recommends checking for functions and classes before making use of them, such as those exposed by a plugin module. This sounds risky. When it comes to plugins, the host application should insist that any plugins conform to a strict API. Working with plugins that may just decide not to export a certain required function, for instance, is a recipe for disaster. If a plugin module doesn't provide the proper interface, it should not be loaded.

The third suggestion is perhaps the only one that's sensible. It suggests using require_once() to prevent multiple inclusions of some external PHP code. Indeed, this typically is a good idea.

The fourth suggestion recommends that associative arrays be used to return multiple values from a function. While this isn't as bad of an idea as the use of an associative array to store parameter values, this seems to indicate that PHP should offer a more lightweight construct such as the tuples found in languages like Python and Standard ML. Sticking with what PHP already offers, perhaps even an object could be returned, rather than an associative array.

The fifth suggestion recommends the use of an __autoload function. The very existence of this function suggests that PHP has some serious shortcomings when it comes to allowing for the sensible separation of code. On one hand, this sort of dynamic loading is the sort of functionality that PHP should offer transparently.

Furthermore, it indicates a laziness on the part of PHP developers who wish to write code making use of classes defined in other source files, but who are unwilling to put forth the small amount of effort needed to explicitly include such files.

In addition, the three notes in the __autoload documentation should make developers hesitant to use such functionality. It appears that it interferes with the semantics of exception handling, it's not available when using PHP in its interactive mode, and has risks associated with the validity of the class names passed to it. Frankly, it sounds like yet another PHP "bandage" meant to patch over problems in the language and programmer laziness, while at the same time introducing far more severe problems.

The final suggestion recommends that the directory of the script be determined by calling dirname(_FILE), especially for the purposes of location other PHP files to include. For the given example, the use of a relative path should be sufficient.

The PHP community has a long history of not fixing the problems with their language and its most common implementation. Far too often we've seen "solutions" like these, which end up being messier and more convoluted than had the problem with PHP itself just been fixed sensibly. It's no wonder that so many PHP Web apps are buggy, full of security holes and essentially unmaintainable; the language itself is inherently broken, the workarounds are just as broken and full of caveats, and together they result in nothing but problems.