We have been busy lately working on some projects (still under development) that required a notification system for the different events triggered by the users activity. You know, the kind of notifications from your favorite social networks for things like "Congratulations ! You have unblocked a new bagde" or "User Slothie is now following you", usually received via email and also displayed on the site itself.
Creating a pluggable Django app to just embed the GA code seemed overkill to me, so I created this post as a quick reference for next Django web projects.
This is the first of a series of posts about which libraries and tools we use for our Django development. Almost every Nomadblue project will have the following packages in their requirements.txt pip file. Probably most of the readers won't find much news here; however, eventually someone can realize he was missing something that could be leveraging their productivity or making life easier.
A few weeks ago, I released a simple Django app to manage models for simple newsletters. The package itself is blatantly useless if we do not use it on a project that integrates with other parts, so I created a fully-equipped system that can create propaganda, assign it to subscribers and queue it ready to be sent whenever I need to.
Hey you, political leader, founder of a new religion or spiritual guru! With this application, your acolytes will receive the official organizational propaganda pamphlets right into their inboxes. Keep them updated with the Truth!
In a previous post about django translations in this blog, I shared how to achieve a quick system that allowed me to manage translations stored in models and served using a template tag. In this post I will explain how to serve images that contain translated text and, hence, a localized image exists for each language.
Lately I have added comments to my company blog. We have it localized, so things turned out to be not so straight forward as one can think.
My Django blogging app, django-nomadblog, is sporting a new look after I added many features I needed for some of my present and future project developments. Mainly, I wanted to turn this app into a multiple blogging system, which means I am able to create and manage multiple blogs from the same installation, via admin interface. The implementation of this followed some improvements in the code and the modularity of the app itself.
During this past week I have been attending DjangoCon, which took place in Berlin thanks to the German Django Association, a non-profit organization founded by german djangonauts. Interesting talks about Django, WSGI, NoSQL, testing, CouchDB, MongoDB, South or front-end design, to name a few. And in the evening or night, geeks gathered in Berlin pubs for beers and fun.
I came to a dirty but practical solution for one minor project I had to develop for a client who wanted a website with i18n capabilities and also needed to have the different translations for each candidate values each in a different field, in the same model. That is, one field for each language. Here in this post I explain how to achieve it.
Well it was time already to give some more code into the public domain and the community, so I decided to release my personal way of starting new django projects. I call it django-nbskel ("nb" for nomadblue and "skel" for skeleton).
Many applications, and specially today's web applications -- which involve concepts as collaboration or content driven by the users -- need the flexibility to support delegation of permission granting to objects by other trusted agents. A clear example is a social networking site, where the users want to allow or deny access to their profiles or pictures, open or close their different communication channels like receiving friendship requests or private messages. django-rbac tries to champion this by introducing some key features from the Role-Based Access Control (RBAC) proposal. In this implementation users (subjects) are assigned different roles that, in turn, have (or not) privileges over objects. With this permission system, the owner of an object can give privileges to certain roles. For example, a user can grant access to other users trying to read some personal info only if they belong to, at least, one of the roles specified in the permission rule.
In a project with an application named concerts that lists concerts from european cities, consider a classic two-level URLconf where the root urls.py module "includes" (i.e. uses the include method from django.conf.urls.defaults) a second URLconf module.
DRY (Don't repeat yourself) is always a good coding practice I try to follow, at least whenever deadlines allow me to do so. Even for a bunch of code bits, it helps keeping clean and modular.
Talking about views, I find myself using different techniques and approaches to write a single function that centralizes all the logic and, at the same time, behave differently, depending on who is calling it.
This is a basic Django application implementing the most simplest form of a blog (from my point of view, of course). It has been written with an eye on keeping modularity as far as possible, so you won't find lots of goodies in the code, but just a couple of features to help you start hacking.
A whole weekend doing some fun coding has produced this brand new kid on the blogosphere. Soon I will write my first "real" post, in the meantime I can't wait to leave the URL to django-nomadblog, the django app that I built to run this weblog:
You will need Mercurial to clone it out. Hasta pronto!