There’s a million of small jQuery snippets which handle input placeholders (ie. the help/explanation text that’s shown until you actually write something in the field), and when HTML5 gets widespread, they’ll all be obsoleted.
But nevertheless, here’s another one.
this post is more for self reference, but if it’s useful to you, be my guest.
Django 1.3 brought a new template rendering shortcut, render(), which takes care of instantiating RequestContext and passing it to the template renderer.
A pattern in Django views I really like is just passing all the locals to the template. This avoids needless repetition in defining what gets passed to the template. It also keeps me from having views that are too complicated, since I want to minimise the pollution of template context with unneccessary/unrelated variables.
Most of my Django views now end like:
return render(request, template_name, locals())
Could this be further simplified? Turns out it can, since Python is a dynamic language with pretty good support for introspection. It’s possible for a function to get a reference of the caller’s stack frame which contains their locals. So, we can devise a magical function that would pull locals from the parent’s stack.
Here it is (gist):
import django.shortcuts
import inspect
def renderlocals(template):
locals = inspect.stack()[1][0].f_locals
request = locals.get('request')
return django.shortcuts.render(request, template, locals)
Using renderlocals(), the above usage pattern boils down to:
return renderlocals(template)
Since I’m always naming my request variable request, renderlocals() can make the assumption it’s called like that, so no need to pass it in manually. Although I could do the same with template name, I usually pass a string directly, so there’s no benefit there.
Would I actually use it throughout my code? I’m not sure about that. It’s a bit shorter, but it’s also magical (in the negative sense) and makes assumptions about the calling code, which might make it more of a problem than benefit in the long run.
But it was a fun thing to do :)
Sane-default boilerplate to avoid repeating yourself each time you start on a new Django project.
Django comes with a lot of batteries included, but it takes some time to set them up. And usually, the initial few steps are always the same. We can refactor these into a boilerplate empty Django project, and use it as a base for new projects, instead of starting from scratch each time.
That’s what I did with DJ Skeletor. It’s an empty, relocatable (ie. uses no hardcoded paths) Django project, set up to my liking and with a few Django apps that I use in virtually all projects (impatient? jump directly to the examples).
Default Django settings organisation is rather simplistic – it’s just one file. But as soon as you deploy the project to somewhere else than the computer you’re writing it on, you’re going to have at least two sets of settings: development and production.
There are several ways to handle this in Django. I prefer the following:
settings/ directory.settings.base module.settings/dev.py, and production-specific settings are in settings/prod.py; a symbolic link settings/local.py points to the one that should be used in a specific environment.settings module imports settings.base and settings.localThis allows me to have all of the settings code (even per-environment settings) in the git repository. By using the symlink (instead of host name or IP address as some do), I can activate the variant I need without regards to the rest of the environment. This allows me to eg. have several variants of the same project running on the same machine.
A test SQLite database is set up for the development environment. The database file is configured to be test.db in the project root by default.
South is an awesome Django app for handling database schema migrations (ie. table/field changes when you modify your models). If you’re using a database with Django, you want to use South as well.
Django Debug Toolbar is very handy for inspecting what happens when you request a page from Django. It lists things such as SQL queries executed (including how long did they take and why they were executed), signals, logging, exception, request params, etc. I use it all the time for finding and fixing suboptimal database queries.
The app usually defines a white-list of client IPs for which to be shown. As I’m not on a static IP, I find it more useful to have the toolbar show all the time when in development environment, and never when in production.
Sentry helps with exception logging and viewing for your Django project. It can handle multiple Django installs where the logs can be managed from a single place, or it can be used on a per-project basis. The latter is how it’s preconfigured in DJ Skeletor.
Besides logging the exceptions, Sentry can also catch normal logs you create with Python’s logging system. This is also preconfigured in DJ Skeletor.
Enough talk, let’s see some action. First, we’ll create a virtual environment (you do use virtualenv, right? if not, you should) and install prerequisite packages:
virtualenv --no-site-packages myenv
cd myenv
source bin/activate
pip install django django-debug-toolbar south django-sentry
Next, we’ll clone the boilerplate project:
git clone https://github.com/senko/dj-skeletor.git myproject
cd myproject
Let’s activate the development environment and prepare the database:
cd settings
ln -s dev.py local.py
cd ..
python manage.py syncdb
python manage.py migrate sentry
All done, let’s run it!
python manage.py runserver
See? Piece of cake. With boring initial set-up out of our way, we can focus on building an awesome web site or app.
DJ Skeletor is open source and is available on GitHub. Feel free to use it or base your own boilerplate on it – if you do, please share your thoughts in the comments.
If you’re a programmer and couldn’t design if your life depended on it, it’s useful to have the user interface boilerplate handy as well.
If you need a clean, well designed (but definitely not unique or artistic) user interface for your HTML app, I heartily recommend Bootstrap, created and open sourced by the fine folks at Twitter.
If you do need to make a proper, unique design, again no need to start from zero: use HTML5 boilerplate which takes care of a myriad little gotchas for you; and there’s a mobile option as well.
… you never verify that it’ll boot correctly.
The Linode box hosting my VPS had a scheduled maintenance downtime for a couple of minutes yesterday, so they shutdown my VPS and rebooted it afterwards. This was a first downtime since I set it up around 7 months ago. I saw in the VPS management console that the server was correctly rebooted, so I went to sleep, not a care in the world.
BUT
Oops
Let’s practice root cause analysis with five why’s, shall we?
/tmp at some point.Let this post remind me to not cut these corners again. And you, dear reader, check whether you’ve cut them as well.
Every programming language has at least one standard or preferred code style – most have several, and they’re an endless inspiration for bikeshedding.
I’m about to do just that.
Instead of talking about a specific language or community, I’ll look at some general guidelines that are applicable to every programming language. Of course, there are exceptions, but there has to be a good reason to make the exception.
These are just things I picked along the way and found that they’re useful in general. I’ll try to explain why I think each of the guidelines is important, but YMMV – code style is largely a subjective issue, and I’m not here to preach my way is in any way superior for you. It just works best for me.
Spaces and tabs make an ugly mix. In some languages (like Python), mixing them can easily lead to hard-to-find errors. In others, the effect is purely visual, but still ugly.
People have various tab length settings in their editors. Yes, I agree we should all standardize on tab width of 4 (or 8, or 2, or ..), but at this point I don’t think we’ll ever do that. So if you share (as in show or view) code with anyone not following the same style, it’s going to be a mess.
Spaces or tabs? When you’re mainly using tabs, there are still places where a space or two are going to be needed. You’re effectively going to mix them. So don’t, use only spaces.
Okay, that was easy. I also intentionally ignored the fact that some tools require mixing them – make, for example.
If you’re only working in and for Windows environment, and you’re not going to need to share code with developers on other operating systems, you can get by by using Windows-style line ending (CR-LF). In fact, it’s probably going to be easier than the alternative.
Otherwise, use Unix line ending (LF) everywhere. It’s the default on both Linux and OS X, and if your (web app) code is going to be served by some cloud server, it’s probably going to be Linux or some other variant of Unix as well.
Whatever you do, don’t ever mix the two. If you have a hybrid team, some people on Windows and some on OSX or Linux, standardize now.
Trailing whitespace on each line can be trouble, because otherwise identical lines can actually be different. This can wreak havoc with your version control, since it’s easy to change them, without changing the actual content of the line, and the version control will hapilly treat them as code changes.
Fortunately, most editors have the option of automatically trimming the white space when saving a file. No reason not to use it.
This is a tough one. I try to have the content fit in 80 columns. It’s easier to read, as it avoids wrapping (easily mistaken for multiple lines) and horizontal scrolling (downright cumbersome).
This is easier for some languages than for others. I’ve pretty much given up on doing it in HTML. It’s just too verbose for 80 columns to be enough.
So, I try to follow the 80-column rule unless working around it would make the code uglier than if I just let it go beyond col 80. In those cases, I prefer wrapping instead of horizontal scroll.
A file should end with a single newline. That means, no empty lines after the content, but also not having the last line of the code dangling without an ending newline.
This makes it easier on the editors, nicer when using cat or patch, and makes git not complain. Good enough for me.
With everyone supporting it these days (and it being a default on a lot of systems), there’s just no reason not to use UTF-8 encoding. I try to stick to the ASCII part whenever possible, but when I do need it, UTF-8 is the only sane choice.
I’m pretty opinionated with regards to these things, as I’m sure you are as well, dear reader. So please do share your preferred settings for the above in the comments (we’ll agree to disagree, thus avoiding any potential flamewars).
Also, if you have an interesting example where some of these MUST be broken (eg. in Makefile), please do share.
Programmer, entrepreneur, open source enthusiast and all-around geek from Croatia.