What Should Be Left Out

Basically any feature that can be provided by another reusable app should be left out. Why should we re-implement something that is already done… and reviewed by others… and tested. Of course this doesn’t necessarily mean providing no convenience functions.

• No admin. Because we already have one.
• No theming. For the love of Flying Spaghetti Monster, you don’t need any theming other than what django.template offers. Pre-built themes are for turn-key solutions.
• No comments or contact forms. (See django.contrib.comments and django-contact-form)
• No official markup format (or formats). This can be handled in the templates without difficulty. But, maybe, pluggable content filters is a good idea. I haven’t made up my mind on this one entirely. It won’t use any markup format by default, that is for sure.

What Should Be Included

Remember, every project has a different set of needed features for its blog. Some need catagories, some need tags and some others need both. But it would end up as a disaster if we implemented each one of those features into a single app. Instead I think it should consist of many small apps that work together. But I wouldn’t want to end up having huge spaghetti of apps that all depend on one another, like Pinax does. A minimal amount of core apps2 and then everything else should be optional. By optional I mean you don’t have to install packages you won’t need.

I think the components (apps) should be activated via adding to INSTALLED_APPS and configured with settings. I can’t think of any parameter that needs to be changed dynamically, so why not use the established way of doing configuration in Django.

Two must have features for such a blogging app are previews and scheduled publishing. It is possible that you sometimes write a post quickly and publish it immediately. But I suppose nobody will say they don’t care about these two features.

Built-in feeds and sitemaps are also nice to have.

Multiple instances of this blogging app running on the same project? À la admin. I can’t make my mind on this one. Sure it would be a nice feature. But it could complicate the code. Peehaps too much for a not so common case.

What do you think about the general idea? Are there any other must-have features? Would you be willing to learn a new app when you are already comfortable with another blogging app?

1: Even though it’s written in the abomination called PHP. But since there are plugins for everything I don’t have to touch the code.

2: One sounds like a good number, if possible.

Real Communities

I think having local communities is a great idea. I don’t know, because we don’t have any in Türkiye2. So I am just guessing they should be cultivating and fun at the same time. We do have many local pseudo-communities though. There is some activity, people come and go, some of them stay much longer than the others. But they never progress towards a community. I think this is because they make the fundamental mistake of localizing community support. They translate documentation intended for highly technical people and create new channels that no advanced user will bother to participate. In short, they attempt to sidestep the language barrier.

If want to be a programmer you need to know English. It is not optional. It is not a requirement of being a good programmer. You are at most an excellent script kiddie without proper English skills. Obviously, knowing perfect English doesn’t make you a great programmer instantly. It will increase the resources you can access dramatically, though. And most importantly it will give you the chance to know more about what you don’t know. Stay in your little world to play with your mates who know just as little as you do and you will never improve.

A Foolish Endeavour

Some people, who spend time with these pseudo-communities, know English well enough. They are probably acting with good intentions when they provide support in their native language. But they are actually wasting their time. Having been solved one specific problem doesn’t make the other person a better programmer. On the contrary they are giving local users another reason to avoid solving the real issue. The function of a community should be supporting each member’s continuous improvement. That doesn’t necessarily mean solving their technical problems for them3.

What is wrong with asking questions in a native language if on a local channel or face to face with local people? Nothing. There is absolutely nothing wrong with that. It would be silly to speak another language there. But if you really want to improve, you can tap into a greater source of information. It is your choice. Pseudo-communities will only take you so far. Because they are only generating more newbies, and not supporting newbies become experienced users. Do they produce anything but empty talk?

Why should a local community produce anything? What should the product be? I will probably write another post about this soon. But feel free to post your ideas and critics in the comments.

1: Obviously, it only makes sense if your native language is not English.

2: I would very much like to be proven wrong on this one. If you know any, please write a comment and don’t forget to include a website and date of the last meeting.

3: Also note that there is a difference between helping someone solve a problem and solving the problem. Spoonfeeding does more harm than good.