I run a couple of sites that are based on Wordpress and my blog was one of them. There are several things that annoy me when it comes to Wordpress: too many plugins that you need for a good site updates, updates, updates (I merely spend my time in updating everything and keeping compatible) the Wordpress core code the themes HTML and structure that are PHP files it's PHP PHP-FPM consumes to much memory (if configured to serve a Wordpress site with good performance) So for my blog, which really is static but for the comments, I looked around what tools or frameworks are there to replace the mighty Wordpress with a static site. I wanted something simple, something pythonic. By reading the blogs of people who also had switched from Wordpress I found two tools: Hyde, a pythonic fork of Jekyll, and Pelican. The majority of people who switched chose Pelican, so I did, too. It has more forks on Github and also a repository of plugins. In fact both tools are not very different from each other. Pelican just felt better while using. The switch took me some days, I had a couple of problems to solve/things to ...

Today I've released on Github one of my applications - django-content-bbcode. The parser code is used on my sites and I've decided to refactor it (it's quite old), add some new features (like the tag loader) and release it to the public. There is also pypi package for it. In short django-content-bbcode allows you to replace BBCode alike tags in text (like in articles, news) with whatever you code in Python. I use it to highlight code snippets (with pygments), make nice links to articles by given slug (fetches title, description from database), insert image thumbnails (integrated with frontend image lightbox) and few more. Makes plain text quite dynamic. More detailed description is on Github.

Knowing when a person last logged in is great, except when it isn't. Sometimes you want to know when a user last actually used your app. Since you can stay continually logged in to Django sites we need an alternative way to know when a person was last on your site. If you are using class based views, and you should, then writing a mixin is a good way to go. LastAccessMixin from django.utils import timezone class LastAccessMixin(object): def dispatch(self, request, *args, **kwargs): if user.is_authenticated(): user.accessdata.last_access = timezone.now() user.accessdata.save(update_fields=['last_access']) return super(LastAccessMixin, self).dispatch(request, *args, **kwargs) What Does this Code Do? The first place class based views go is to the disatch method. This "dispatches" the request to the proper place. It determines what type of a request it is be it a GET, POST, HEAD etc. From there it goes to the appropriate method. def dispatch(self, request, *args, **kwargs): We are overriding the dispatch method because it is always called, and only once. We also want to use the dispatch method instead of say get because on some urls we might use a post method, then we wouldn't know the page was used. if user.is_authenticated(): user.accessdata.last_access = timezone.now() user.accessdata.save(update_fields=['last_access']) In the ...

I have a simple video website for my kids and each kid has a separate login. This is so they can each have their own videos, but also so that some videos can be private (ie. hidden from the outside world, or other logged in users). I don't need crazy security though--it wouldn't be the end of the world if somehow someone guessed the magic token and saw some private videos, which are basically just home videos uploaded to Youtube. Videos that I really wouldn't want the public to see don't get uploaded to Youtube in the first place. I couldn't find how to do this easily, although one person on stackoverflow suggested "logging in the user in the view by calling login". The tricky part was figuring out that I had to set the User object's backend to 'django.contrib.auth.backends.ModelBackend'. It's a bit of a hack, but it works, and it's simple. models.py: class MagicToken(models.Model): user = models.OneToOneField(User) magictoken = models.CharField(max_length=128, unique=True)   def __unicode__(self): return unicode(self.user) views.py: from django.http import HttpResponse, HttpResponseRedirect, Http404 import django.contrib.auth.login   class MagicTokenLogin(View): def get(self, request, token): try: magic_token_obj = MagicToken.objects.get(magictoken=token) except MagicToken.DoesNotExist: raise Http404   user = magic_token_obj.user user.backend = 'django.contrib.auth.backends.ModelBackend' django.contrib.auth.login(request, user) ...

Apple ships a patched version of OpenSSL with OS X. If no precautions are taken, their changes rob you of the power to choose your trusted CAs, and break the semantics of a callback that can be used for custom checks and verifications in client software. Abstract If OpenSSL’s certificate verification fails while connecting to a server, Apple’s code will intercept that error and attempt to verify the certificate chain itself with system trust settings from the keyring, potentially throwing away your verification results. Therefore: You can’t limit your trust to certain CAs using SSL_CTX_load_verify_locations. This apparently isn’t news but doesn’t appear to be widely known. Contrary to documentation, returning 0 from SSL_CTX_set_verify’s callback does not make the TLS handshake fail. That makes the callback unsuitable for extra verification purposes (such as hostname verification). MITRE has assigned CVE-2014-2234 for this issue. Apple was not interested in my bug report because they deprecated their OpenSSL years ago. Hence this summary together with work-arounds. The Verify Callback OpenSSL’s SSL_CTX_set_verify allows setting a callback function that is called for each certificate in the chain. It is invoked with the result of OpenSSL’s own verification of each certificate (1 for success, 0 for failure) ...

I'm maintaining my django-ckeditor fork known on PyPi as django-ckeditor-updated. It works with latest Django versions, uses Django file storage, has some new features and fixes. Recently few people including me got write access to the original repository - shaunsephton/django-ckeditor and my commits were merged (not that the PyPi package is still old). When/if the original package will get new and constant releases I'll close my fork, but until then django-ckeditor-update is alive. If you have any issues or pull requests made on the original django-ckeditor please check if they are still valid for current codebase.

he addition of this blog should help people learn more about Django, more often. For a while now there hs been set of things I have wanted to be on GoDjango, but didn't necesarily think they were enough for a full video, or too specific. Goals of the Blog The ultimate goal is to make GoDjango one of the top three places on the internet to come to in order to learn django. To accomplish that here are some of the goals I see for the blog. I hope to provide tutorials about django in a new way Provide more transparency about what is going on with the site instead of a one way stream of communication Provide another avenue of learning django so there are many more topics. About the Blog Eninge Itself This is a custom built blog engine I am creating for this site. However, I am creating it in an open way, but making it an installable app. I have named it dj-blog. The idea behind the installable app is to provide a basic blogging engine which is a bolt on, instead of something that almost takes over the entire code base. I plan to keep ...

The software used for this year's EuroPython conference website is actually a continuation of what was original developed by Markus Zapke-Gründemann and Stephan Jäkel for the very first PyConDE conference in Leipzig 2011. Over the years people joined/moved on but back then just as today the team has always been extremely small so we are always looking for people to help out. If you are in Berlin during the weekend of March 22 - March 23 or simply want to help with the project, there is a coding sprint for the software taking place in the offices of Veit Schiele Communications GmbH. Markus Holtermann will be there and I will join remotely from Graz (Austria) to answer all question you might have and or pair. In the next weeks until the sprint happens I will try to update the project's documentation (which is mostly still focused on the PyConDE-featureset) so that you will have a smoother start. For details please check out the page at meetup.com. If you want to take at the software first, you can find it on Github. "EuroPython Conference Software Sprint in Berlin" was written by Horst Gutmann and is licensed for reuse under Creative Commons ...

Using things like CoffeeScript, Stylus, Less, SASS/SCSS, etc... Is becoming a more and more core part of development, but the problem usually is compiling these assets for use on our site. With django-pipeline this process is now much easier in both development and production. Learn the few easy steps it takes to get started with it.Watch Now...

Das nächste Treffen der Django-UserGroup Hamburg findet am Mittwoch, den 12.03.2014 um 19:30 statt. Dieses Mal treffen wir uns wieder in den Räumen der intosite GmbH im Poßmoorweg 1 (3.OG) in 22301 Hamburg. Die Organisation der Django-UserGroup Hamburg findet ab jetzt über Meetup statt. Um automatisch über zukünftige Treffen informiert zu werden, werdet bitte Mitglied in unserer Meetup-Gruppe: http://www.meetup.com/django-hh Für dieses Treffen ist ein Vortrag über Anpassungen im Django Admin geplant. Es werden Anpassungen gezeigt und erklärt, die über die dokumentierten Optionen hinausgehen. Bei Interesse kann ich außerdem ein wenig über erste Erfahrungen mit der Django 1.7 Alpha-Version und Mozilla-Circus als Prozessmanager berichten. Eingeladen ist wie immer jeder der Interesse hat sich mit anderen Djangonauten auszutauschen. Eine Anmeldung ist nicht erforderlich, hilft aber bei der Planung. Weitere Informationen über die UserGroup gibt es auf unserer Webseite www.dughh.de.

I gave a quick lightning talk at this year’s (and first ever) Django Weekend in Cardiff about how to use django-configurations to improve your Django settings. I posted the slides on Slideshare. There is plenty of documentation about django-configurations so please don’t hesitate to go and read it now, but in case anyone is interested, I’d like to explain why I wrote it. Ever since I’ve used Django it bothered me that I had to use the module settings.py with a bunch of Python variables (with capitalized names no less) to glue together the code that my site is based on. I think it was designed like this to follow the Zen of Python (“Explicit is better than implicit”) but only had relatively small projects in mind. Given the reality of today’s Django ecosystem (~5000 apps on PyPI) it seems ridiculous that Django still encourages new users to accept such conventions as the best practice to structure Python projects. We should not only help them get started quickly but also to grow their project when the time comes. Django is just Python. And yet we’re limiting it to use programming patterns for its configuration that are hard to grow with ...

I work on a test automation framework at my day job. It's Django-powered, and there's a lot of neat stuff going on with it. I love building it! Anyway, yesterday during a meeting, I got an email from a co-worker who seemed to be in a bit of a panic. He wrote that he accidentally deleted the wrong thing, and, being Django on the backend, a nice cascading delete went with it (why he ignored the confirmation page is beyond me). He asked if we had any database backups that we could restore, also curious as to how long it would take. Well, lucky for him (and me!), I decided very early on while working on the project that I would implement a custom database driver that never actually deletes stuff (mostly for auditing purposes). Instead, it simply marks any record the user asks to delete as inactive, thus hiding it from the UI. Along with this, nightly database backups were put in place. I'll be quite honest--I had a moment of fear as I considered how long it had been since I really checked that either of these two things were still working as designed. I implemented the database ...

Django Debugging Bookmarklet Trick

By now Django Weekend 2014 has been over for more than a week ... but now I finally found the time to also write about it! For those who don't know, Django Weekend was a one-track conference that happened between 7th and 9th of February in Cardiff, Wales, UK. All that plus it was awesome! Personally, I'm a huge fan of one-track conferences. They keep everyone extemely focused and you don't "miss" anything. Usually this kind of conference also has a very strictly limited number of attendees which helps making the event feel like an extended family gathering (which is something I always feel when attending a Python conference for some reason). The conference took place at Cardiff University and the talks were presents in an auditorium of the Chemistry Department. Very classy! There were also quite a few students in attendance, for some it was even their very first Python event. Thanks to the location there was also no real problem with any kind of infrastructure (perhaps with the exception of the heating on the sprint day ;-)). In most public buildings that have to deal with tons of students on a day-to-day basis things like Wifi simply usually ...

Some may already know about this - on Kickstarter there is a fund raising for implementing improved PostgreSQL support in Django. Marc Tamlyn is in the lead and at this very moment there are 25 days to go and the project is already reaching extended goals. It looks like we will see another crowd-funding project successful, making Django better. First one - the Django migrations is on its way for a release with Django 1.7.

For a couple of versions now Django has had a nice little API for registering validator functions for specific fields in either forms or models that are checked using the model validation logic: class UserProfile(models.Model): avatar = models.ImageField( upload_to='avatars', validators=[ check_format, check_minimum_resolution ]) What's great about this API is that it encourages the creation of tiny, self-contained value-checks that are easily testable. Both, check_format and check_minimum_resolution, can be tested independently of each other without running into tests that might mix up cases from the other. The downside of the current implementation in Django is, that all validators are always executed, no matter if a previous one already reported an error and therefor the field's value can no longer end up being. Normally, this isn't really an issue but it might become one if one of you validators is rather expensive. In our previous example we had two checks: One for the format of a file and one for the image's resolution. While the first validator can (in a rather naive implementation) be as simple as checking the file's extension, the latter really requires that we open the file and look at its content. Ideally, we'd want to avoid this if ...

Recently, we were faced with the task of writing an API-first web application in order to support future mobile platform development. Here’s a summary of the project from the point of view of one of the developers. Agile API For the first couple of iterations, we had problems demonstrating the project progress to the customer at the end of iteration meetings. The customer on this project was extremely understanding and reasonably tech-savvy but despite that, he remained uninterested in the progress of the API and became quite concerned by the lack of UI progress. Although we were busy writing and testing the API code sitting just beneath the surface, letting the customer watch our test suite run would have achieved nothing. It was frustrating to find that, when there was nothing for the customer to click around on, we couldn’t get the level of engagement and collaboration we would typically achieve. In the end, we had to rely on the wireframes from the design process which the customer had signed off on to inform our technical decisions and, to allay the customer’s fears, we ended up throwing together some user interfaces which lacked any functionality purely to give the illusion ...

Intro Django was actively supported at an early stage of the Python runtime in App Engine SDK through the notable django-nonrel framework, a fork of the original project that adds support for NoSql databases. But starting from the App Engine SDK 1.6.2, released more than two years ago, you can instead deploy Django’s official releases and take advantages from the whole stack using Google Cloud Sql. Case study We’re going to setup a minimal project using Zinnia, a blog engine built on top of Django and a fairly complex web application that leverages several components of the framework, a good benchmark for showing how easy can be deploying on App Engine. Prerequisites Setting up the Google Cloud services goes beyond the scope of this article and is well documented, as well as having a working Python environment, so the following it’s assumed: you already started a Google Cloud project a Google Cloud Sql instance is up and running and you created a database for this project you created a bucket on Google Cloud Storage to store media files you have a working installation of Python 2.7 and pip on your local machine you installed and configured the Python App Engine ...

Django Extensions 开源库是Django框架的扩展功能集合，包括management命令扩展, […]

A few weeks back, the Evennia project made the leap from Google Code to GitHub (here). Things have been calming down so it's time to give a summary of how the process went.Firstly I want to say that I liked Google Code. It did everything expected of it with little hassle. It had a very good Issue system (better than GitHub in my opinion) and it allowed us to use Mercurial instead of Git for version control (I just happen to like Mercurial better than Git, so sue me). Now, GitHub is getting to be something of a standard these days. But whereas our users have occationaly inquired about us making the move, I've been reluctant to do so.  The problem I did have with Google Code was that I got the increasing feeling that Google didn't care all that much about it. It worked decently, but it was not really going anywhere either. What finally made me change my mind though was an event just after summer last year. There was a bug in Google Code that made the links to online clones disappear. It was worse than that - creating new online clones of the main repo didn't ...

Colin Copeland, Managing Member at Caktus, has wrapped up work, supported by UNICEF, as the Community Coordinator for the open source RapidSMS project. RapidSMS is a text messaging application development library built on top of the Django web framework. It creates a SMS provider agnostic way of sending and receiving text messages. RapidSMS has been used widely in the mobile health field, in particular in areas where internet access cannot be taken for granted and cell phones are the best communication tool available. This has included projects initiated by UNICEF country offices in Ethiopia, Madagascar, Malawi, Rwanda, Uganda, Zambia, and Zimbabwe. Modeling RapidSMS on the Django Community The overall goals set forth by UNICEF for this project included improving community involvement by making RapidSMS easier to use and contribute to. Colin accomplished this by using Django's large and active community as a model. The community employs common standards to maintain consistency across developers. Using this best practice for the RapidSMS developers meant easier communication, collaboration, and work transfer. Colin shepherded six releases of the RapidSMS framework over his year long stint including 948 code commits to the repository. Colin broadened engagement in the RapidSMS community by tapping five others at ...

We (Audrey Roy and I) just released the revised, expanded, and slightly renamed second edition of our book on Django. It's called Two Scoops of Django: Best Practices for Django 1.6, and you can buy it right now in print format on our online store or Amazon.com. Two Scoops of Django: Best Practices for Django 1.6 is chock-full of even more material that will help you with your Django projects. We'll introduce you to various tips, tricks, patterns, code snippets, and techniques that we've picked up over the years. We have put thousands of hours into writing and revising its hundreds of pages of concise, example-packed text. Why Should You Purchase the Second Edition? "I read the first edition cover to cover. The second one raises the bar again. It's pedagogical, entertaining, and thoughtful." —Aymeric Augustin, Django Core Developer, Two Scoops of Django 1.6 Reviewer Why should you buy this updated version of our previous book? Well, it's more than a slight rename, it's been revised and expanded! It's Revised Significant portions of the previous material have been revised, incorporating huge amounts of feedback submitted by our readers over the past year. We listened to suggestions, clarified existing content, and ...

We (Audrey Roy and I) just released the revised, expanded, and slightly renamed second edition of our book on Django. It's called Two Scoops of Django: Best Practices for Django 1.6, and you can buy it right now in print format on our online store or Amazon.com. Two Scoops of Django: Best Practices for Django 1.6 is chock-full of even more material that will help you with your Django projects. We'll introduce you to various tips, tricks, patterns, code snippets, and techniques that we've picked up over the years. We have put thousands of hours into writing and revising its hundreds of pages of concise, example-packed text. Why Should You Purchase the Second Edition? "I read the first edition cover to cover. The second one raises the bar again. It's pedagogical, entertaining, and thoughtful." —Aymeric Augustin, Django Core Developer, Two Scoops of Django 1.6 Reviewer Why should you buy this updated version of our previous book? Well, it's more than a slight rename, it's been revised and expanded! It's Revised Significant portions of the previous material have been revised, incorporating huge amounts of feedback submitted by our readers over the past year. We listened to suggestions, clarified existing content, and ...

Old-school web applications were easy to create. Big powerful frameworks like Django give you a lot of tools you can leverage. One weak point of all those WSGI framework is that they didn't integrate well with anything that broke outside the usual request-response cycle. The usual approach nowadays is to use WebSockets for real-time communication between browser clients and web servers. The usual way to do that would be to use a server capable of handling many concurrent connections, and use a message bus from the WSGI app to communicate to that service. That is a lot of moving parts. In my use case where I build a lot of intranet applications, deploying and maintaining all this infrastructure is a very big burden, so the result is usually to not even explore this kind of functionality. However, given that I deploy on Twisted, I wanted to explore what kind of cool things I could build on it. Enter SSE Server-Sent Events aren't that new - they have just been shadowed by WebSockets. They are a simple data format that is send from the server to the client via a plain HTTP connection. The Javascript API is quite simple, and it ...

Saving files in the cloud, be it Amazon S3, Azure, or Rackspace, is very common now and almost a requirement. django-storages makes this seemless. This video shows you just how easy it is to get started.Watch Now...