ChichaPlanet

Sometimes I end up using Django for the wrong thing, just to dispatch pages and put all my content in the templates. Flatpages are too flat and other DB based content tools are too complex. I just want to use the dispatcher, and the templates (I know, I could use web.py, or whatever other Python tool).

So, In order to save myself some time, I made cheap_pages.py, which is a wrapper for the patterns() method that will populate it with direct_to_template calls.

So instead of doing this:

>>> url(^name/$,
...    direct_to_template,
...    {'template': 'name.html'},
...    name='name')

I can do this:

>>> page('name')

Or instead of this:

urlpatterns = patterns('',
    url(^pages/page1/$,
       direct_to_template,
       {'template': 'page1.html'},
       name='page1')
    url(^pages/page2/$,
       direct_to_template,
       {'template': 'page2.html'},
       name='page2')
    url(^pages/page3/$,
       direct_to_template,
       {'template': 'page3.html'},
       name='page3')

)

I can do this:

urlpatterns = build('pages/', ['page1', 'page2', 'page3'])

I’ve added the file to Google Code under Django-cheap-pages, in case anyone is interested in improving it .

Django and Ruby on Rails seem to have surpassed all other frameworks like Turbogears or Symfony and are the talk of the web developing blogosphere, RoR going as far as making Ruby notable again, making it known to many people, as this language was almost unknown in 2004, before RoR’s opening. When I tried to do a quick web app I had to do, I skimmed over the two frameworks, finally deciding with Django to do my work on. As I moved on, I saw that Django, while not as hyped and AJAXy as Ruby on Rails, is much better and workable with than it’s main competitor. Ten Eight reasons why Django kicks Ruby on Rail’s ass.

1. Python.

Python drives Django, as many would know. Each time you write a line of code in a Django app, if it’s not on templates, you’re writing Python. This means that you’re able to use the large base of Python developers worldwide, and also the amazing number of Python libraries, coming from it’s 16 years of being heavily used, going into places such as Google, NASA and even some games such as EVE Online or the great Civilization IV. Furthermore, since Python has a more active userbase and more frameworks, if Adrian Holovaty, Jacob Kaplan-Moss and all of the Django developers suddenly dropped dead after I finish writing this, the porting of the code would be much easier than if Rails’ development stopped, where you would be stuck in the middle of nowhere if you ran into an issue. And who doesn’t want a language which has an implementation called IronPython?

2. Documentation

Django’s documentation kicks everyone’s ass. Not just Rails’. Django has a pretty documentation, easily understandable by both newbie and expert developers. Then, if by chance there’s something which can’t be found in the official documentation, there’s always a great ticketing system where many people posted code snippets and small howto’s, and awesome blogs such as B-List which help a troubled user to do everything from extending the user model, to being a master over generic views. However, Rails’ documentation seems confusing at first, with external tutorials and a massively confusing documentation repository.

Furthermore, the main Django developers decided to make an open book, which they have posted on the web and is open for comments, using a Django based publishing site they built, and some of Yahoo!’s Javascript libraries. The main problem with the many Rails books that there are is that they do not try to complement the Documentation, they are the documentation.

3. Templating.

Since Django’s inception, the templates have been designed so that there is no need to be a programmer to know how to create the templates. This means that the design can be split, making for skinnable sites and the ability to outsource the design to a designer, and not need that designer to pick up a book on Ruby on Rails’ in order to make the site pretty. Furthermore, since Django tries to keep as much coding away from the template as possible, the template’s are most often much more readable than the ASPish or even Cthulhuian .rhtml syntax that Rails’ programmers and designers have to use to design and display the processed information. Django’s system makes for much better cleanness using filters, which modify the way your text will be rendered, and template inheritance, making it easy to make dynamic websites.

4. Speed

Both Python and Ruby developers pride on the fact that both programming languages are fast. While they are slower than C and Java, they are probably the fastest in development times, allowing the developers to see the clear picture and work as fast as possible, avoiding as many errors on the way as they can. However, while both compete fairly in development times, the actual processing speed for a Python program is much faster than a Ruby program, while they are working on this. However, the same thing happens in the frameworks, which clearly show that Django is faster than both Rails’ and Symfony, a PHP framework. This means that your apps will be able to take a hammering better if they’re programmed using Django than if they’re using Ruby on Rails.

5. Free, JustWorksâ„¢ Admin interface

Django doesn’t need any MySQL managers, SQLite command line interfaces or any way to change records on the database, because it already has one. Every app is able to, by uncommenting two lines, have a full fledged admin interface containing all the modules that were written and have been marked for inclusion in it. Not only that, but the models may be modified so they appear differently in the admin panel, as it is fully customisable, making it easy to show some choices as drop down boxes or radio, or filtering by fields, etc. This is why none of the Django screencasts nor any of the tutorials need anything more than Django and a text editor, while you see all of the Rails’ screencasts, which there are lots, always having an open MySQL manager. Oh, and the admin interface in Django is damn hotâ„¢, too.

6. Generic views and feeds

With Django, there is no need to program when the operations being done are listing or editing objects, listing entries by date, or any of the basic CRUD operations, which means that the developer’s time can be spent doing useful things, not just getting simple things from the database, or directly editing fields. Furthermore, since Django was made in a publishing environment, creating RSS feeds is as easy as choosing what you want to pull out from the database and into the feed, and choosing where the feed will be retrieved from. This manages to take away the boredom in creating web apps, which in many cases involves cutting and pasting a lot of code, to create, edit or view, sort and manage items which are mostly alike. Django takes away all of this.

Django also has what they call the Flatpages, making it easier to create and select the URL of unchanging information, such as an about or contact page. Furthermore, it can also be edited, all using the Django admin, which makes it even easier than using HTML, not having to create a file nor edit urls.py to point the URL desired to the flatpage.

7. Better support and server

While both frameworks do not have much usage of big enterprisey databases, Django goes further than Rails on database support, as it supports MS SQL without having to do ugly hacks. Of course, its support for SQLite, MySQL and PostgreSQL is top-notch, with Postgres being used in all of Lawrence’s sites, which get millions of visitors each day. Furthermore, Django supports, thanks to the Python WSGI more webservers, as it gives more choice for the admin and more flexibility on setup. It does work on mod_python, which is a problem Rails has, as when it is used with mod_ruby, it has some security problems when running multiple sites on the same server, or just using FastCGI, which is not always optimal, especially due to configuration.. Further on, each Django process ends up being cheaper than having Ruby processes, meaning faster web apps.

8. Django is (mostly) buzzword free

Django isn’t plagued by buzzwords, as Rails is. Rails’ is to much that it’s own name, RoR has become a massive buzzword everywhere, even by people who will never program anything. Now that programming Rails is what the cool kids do, there is a lost value on a language, as the hype goes on and on. Especially having things like AJAX, Web 2.0, XML-RPC. Ruby on Rail’s ends up coercing developers into using too much AJAX, because “it’s way too easy”. The problem is that you get people trying to use AJAX where it doesn’t belong, and you get the complaints that the Web is going backwards in speed and loading times. However, Django is the balance. You can use RSS, if you want to. You can use AJAX, if you want to. You can even have sitemaps, if you want to.

If you want to be cool, and have loads of friends, snazzy AJAX for login scripts which end up failing when you forget to provide a fallback, or you can try the techie way, and bask in the tub of good code, simple design and choice, while not losing speed or reliability. Not at all.

EDIT: My apologies to Adrian Zolovaty Holovaty. It is Holovaty, as the developer himself says.

It’s known that programmers swear a lot. There’s always fucks, shits, cunts, bitches, crap. There’s the kernel fuck count, for example, which shows the number of findings of “fuck” and “love” in the Linux kernel, over different versions of the kernel.
Google recently released the Google Code search (beta, of course), which searches through open source tarballs and zips, and tries to find the number of occurences of a specific query, and then showing them. So, nothing more than a Google which searches through code. Of course, what other use could there be than searching the number of occurences of fuck. In different languages.

So, what language is the most sweared one? I used Python, Perl, PHP, C++, C and C#, to get a wide range of programmers. I recorded the number of found and also the number of entries found without anything, to have a rough view of how many packages in a specific language there are, as Google might not have indexed all, and there may be more packages of C than of C# and others. Of course, there will be more fucks in 4′520,000 results I got for C than the 62,800 that the search returned when searching for C#.

Now, the results.

Here, we can see that, while the number of fucks never even gets to 1% of the results, in the highest one, PHP, 0.5% of all the packages found by Google code contain the word fuck, or any of its derivatives, such as fucker, etc. Furthermore, after PHP, which is the language with most occurences of fuck, almost doubling the other two which compete for the second place, those being C and Perl, something not unexpected. The lowest ones, which is no surprise, are C# and Python, Python probably being the cleanest programming language of the ones sorted here.

Update: Surprisingly, Java is down there with C# and Python in the cleanest languages.

Now, the results for fucks by license.

It can be clearly seen that LGPL makes people swear, while GPL and BSD still do, but in a reduced manner.

I’ve recently moved to Epiphany, GNOME’s official web browser. I used to use Mozilla Firefox, but I never really liked it, and always fought with it, especially when used on Linux. However, since the whole “waa waa” scandal made by Mozilla about the usage (or lack) of the official Firefox icon, since it was trademarked and not included in many distros, I politically decided to switch to a browser which in the end resulted in being even better than my old one, one over which Diego had nagged me over the last few months. After a couple of hours of small problems while my brain was adjusting, I got out with a better browsing experience than the one I had when using Firefox.

Features

Epiphany, or Ephy, uses the Gecko engine to render pages, so it has the same accuracy than Mozilla or Firefox, provided it is a version which uses the Gecko 1.8 engine. However, it is especifically developed for the GNOME environment, and does not suffer from windowsitis. There is no need to use specific themes for the browser, as it automatically adapts to the one used in GNOME, to provide with cohesion, which many times other browsers do not provide. Also, as expected, Ephy has tabs, and even the ability to drag and drop tags wherever needed in order to rearrange them, something Firefox only recently got, or had to be provided by extensions.

Epiphany also has a very innovative way to work with bookmarks. Instead of placing them into folders, it tags them, like Gmail does. So, instead of having to decide if an nVidia Linux kernel thread goes in graphics or in kernel, it can be tagged in to graphics and kernel, so it shows up in a search for any of those two terms. It also has smart bookmarks, which allow creating one for the debian package search and just easily typing clex, selecting the correct entry on the address bar, pressing enter and voilá, instant package search. It has many smart bookmarks by default, such as Dictionary, Wikipedia or Google.
Ephy is very integrated with the desktop. You can easily subscribe to a desktop reader like Liferea when getting an RSS feed, and complete integration with the GNOME Deskbar, allowing it to index the history and bookmarks for easy searching using it. Raphaël Slinckx, the dude with the weird hackergotchi on his site and also a developer of the Deskbar applet explains more about it.

Extensions

The browser does not have a centralised repository for extensions, and there is no way to easily install them but downloading the epiphany-extensions package or download them from the web and put them into the .gnome2/epiphany/extensions directory. However, while I can’t get a GoogleTabs extension, or show the time in Timbuctu, I can get extensions which do what I need, such as run Greasemonkey scripts, block ads, allow me to browse using gestures. As Epiphany is very basic by default, there are also many extensions which help configure the browsing environment, such as selecting which tab to focus after closing one, or to make the tab border smaller. This are all very small extensions, and only have 379 lines altogether, counting all the extensions I downloaded and activated. Furthermore, writing extensions is extremely easy, as in a few lines of python, an extension is ready to run.

Super Tab Extra

Basing myself on the Only One Close Button, I created Super Tab Extra, an extension which resized the width of the tabs when there are too many. The name comes from Tab Mix Plus, a very famous Firefox extension which deals with tabs. Well, without further ado, here it is, Super Tab Extra. I hated the way that tabs were managed first, as “due to a GTK bug”, the tabs would not resize. However, apparently Firefox is going to use it too.