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.
Hola! This is the first post after a really freaking busy past year, and what's more important, this is the first blog post of Nomadblue as a brand new development company! We expect to disrupt the way startups in Santiago de Chile and LatinAmerica are working to develop their ideas and projects.
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!
When doing documentation work, be it regular documentation, how-tos, or wikis, I always use reStructuredText syntax if I have the chance, so eventually if I have to provide documentation in other forms, I can convert source text into other formats like HTML or PDF seamlessly. This same rule applies to wikis, which are, after all, a collaborative way of producing documentation. On GitHub wikis are also git repositories. So you can clone it and work like any other repo. Great, isn't it?
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.
I recently released a little application I wrote for personal use. I am very scrupulous mantaining my music collections. I fancy having them in lossless formats, specially FLAC for storage and Apple Lossless for playback in iTunes. To achieve a decent level of tidiness, I wrote some Python code so I can organize the files and associated metadata tags right from the command line.
The app can be found in its project page here.
Please comments, forks, jokes, donations or awards welcome!
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).
Last Monday the Spanish Government sent the parliament the latest draft for the Ley de Economia Sostenible (Sustainable Economy Act), which contained riders modifying the current laws on copyright and interactive services. These amendments give the Spanish Ministy of Culture the administrative power to take down websites (or order ISPs to block those hosted overseas), all without a court order and in the name of 'safeguarding Intellectual Property Laws against Internet Piracy'. For this reason some of us have written a manifesto that is being published today all over spanish weblogs and media.
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!