Same Con to Hoyci: Entries about Django

en Same Con to Hoyci: Entries about Django https://www.unessa.net/en/hoyci/ Most recent entries about Django from Same Con to Hoyci fi Mon, 22 Sep 2014 13:08:02 +0000 On Flying Starts https://www.unessa.net/en/hoyci/2014/09/flying-starts/ What a start for a blog to end up on the homepage of Hacker News on the first day (with a <a title="Django UI in 2005 vs Django UI in 2014" href="/en/hoyci/2014/09/django-2005-2014/">short post about Django UI</a>). The good: it's surprisingly easy to install a cache plugin to Wordpress. The bad: this blog is not hosted on the Slipmat.io server (because I don't want to install PHP on it) so I missed a great chance to stress-test it.<img class="aligncenter size-full" src="https://www.unessa.net/static/kuvat/hoyci/screen-shot-2014-09-18-at-183557.png" alt="254 Concurrent Users in Google Realtime Analytics" /> To stay with the topic on flying starts, I've been quietly readying the first Slipmat.io tool, a site for taking and making requests in Mixify events, for its official launch. I opened the site for public three weeks ago and I've been working on it ever since. I'm keeping <a href="http://slipmat.io/requests/about/release_notes/">detailed public release notes</a> to keep the users updated and also for myself as a way to get a feel of the progress. Most non-DJs and furthermore non-Mixify users probably have no idea what this tool actually does, so let me explain it quickly. <a href="http://www.mixify.com/">Mixify</a> is a Web site where DJs can play for a live audience by streaming sound (and possibly also video) from their computer to Mixify which distributes it to listeners. Listeners can join these live events and chat with the DJ and other listeners. Many DJs take requests but it can sometimes be cumbersome trough the small chat window that can update really fast if there are lots of listeners actively chatting. MixifyRequests is a site where a DJ can make a request event and get the requests in a nice, organised way with a easy to use admin controls for marking requests played etc. Users can also vote for each others requests and there's a bunch of other features, too. So that's the idea in a nutshell. <img class="aligncenter size-full" src="https://www.unessa.net/static/kuvat/hoyci/screen-shot-2014-09-22-at-183957-1024x548_1.png" alt="MixifyRequests Homepage v0.9a" /> I did the first part of the development in one 10 day sprint, with the idea of getting the first alpha version online in whatever state it would be after 10 days. (Because real developers ship.) The first release had one big showstopper-bug[^1] which was due to my lazy testing of Facebook sign up process, but otherwise everything worked fine. [^1]: Where users who signed up everywhere but from the homepage would get a 500 error after first login because the login view respected 'next' parameter that would redirect them past the view that created an app-spesific user profile of which everything on the site assumed to be there. Thanks to <a href="https://www.getsentry.com/">Sentry</a> I was informed about the bug immediately and got a hotfix in place in about 20 minutes but it had already affected dozens of users of which few of them didn't come back that first night. I decided to do kind of a soft launch by only telling about the site to few selected DJs and by placing a disclaimer on top of every page with a note saying "This site is not officially launched yet. Use it and have fun, but please do not advertise this yet in bigger scale. Thanks!". So far this has worked really well and the userbase has been steadily growing at a rate of about 1-3 new users every day. Thanks to a small number of real users actively using the site, I've gotten loads of good usage data, and most importantly, I've been able to find and fix good number of bugs emerging from situations only real users can get to. (It never ceases to amaze me how actual users always find ways to break code that was supposed to be tested really well.) After the first sprint and the initial production push I changed the development cycle more towards daily productions pushes with the help of feature switches. Last week I sent out an email to all active DJs of the site asking volunteers as future betatesters. Got a few and now I can test and roll out new features in a controlled manner independently of production pushes. Feature switches enable me to keep the development branch in Mercurial very close to stable branch and push bugfixes, not yet polished code and new features on the site daily without exposing anything to the public before the code is ready and tested (live with betatesters). When I want to publish a new feature, I go to the admin, flip a switch, and it's live. Boom! Also, if there are any problems, I can just as easily flip the feature off again, and fix the problem with no hurry. Feature switches are awesome. There are lots of different apps for Django for doing this, I chose <a href="https://github.com/disqus/gargoyle">Gargoyle</a> (mainly because couldn't figure out how to get the newer version called <a href="https://github.com/disqus/gutter">Gutter</a> working). Big props to <a href="https://disqus.com/">Disqus</a> folks for yet another awesome Open Source app. If you're interested in following the development of Slipmat.io site by this lone music loving Django developer, check out <a href="https://twitter.com/slipmatio">@slipmatio</a> on Twitter, <a href="https://www.facebook.com/slipmat.io">Slipmat.io on Facebook</a> and, of course, keep in touch with this blog. And if you have been, thanks for reading this far! (This post was originally posted to my other blog called Spinning Code.) Mon, 22 Sep 2014 13:08:02 +0000 https://www.unessa.net/en/hoyci/2014/09/flying-starts/ django featureswitches hackernews softlaunch Django UI in 2005 vs Django UI in 2014 https://www.unessa.net/en/hoyci/2014/09/django-2005-2014/ I stumbled across my favourite ever tech talk, <a href="https://www.youtube.com/watch?v=cb9KDt9aXc8">the legendary Snakes and Rubies event</a> where Django met Rails, back in 2005. One thing caught my eye while re-watching every minute of the 3-hour event: the Django Web site and the Admin Site app look almost exactly the same today than they did 9 years ago. <img class="aligncenter size-full" src="/static/kuvat/hoyci/screen-shot-2014-09-17-at-225740.png" alt="Screen capture image from Djangoproject.com as it was in 2005" /> Still image of Djangoproject.com from the Snakes and Rubies video, 2005. &nbsp; <img class="aligncenter size-full" src="/static/kuvat/hoyci/screen-shot-2014-09-17-at-225028-1024x559.png" alt="Screen Shot 2014-09-17 at 22.50.28" /> Djangoproject.com, 2014. &nbsp; <img class="aligncenter size-full" src="/static/kuvat/hoyci/screen-shot-2014-09-17-at-225247.png" alt="Still image from Snakes and Rubies video" /> Still image of Django Admin Site from the Snakes and Rubies video, 2005. &nbsp; <img class="aligncenter size-full" src="/static/kuvat/hoyci/screen-shot-2014-09-17-at-225844.png" alt="Screen Shot 2014-09-17 at 22.58.44" /> A screencapture of one Django Admin app (in Finnish -- it still talks also Welsh, among others), 2014. &nbsp; I don't want to comment this in any other way but to notice that it's quite amazing that Djangoproject.com still looks so good and I actually like using it every single day -- it works really well. Way better than most newer homepages of other open source projects. Granted, the Admin app looks a bit more dated, but not too much. And for its purpose, it too works still really well. <a href="http://wilsonminer.com/">Wilson Miner</a> is one kick-ass designer. And Wilson, it's not just a Web site. :) (This post was originally published on my other blog called Spinning Code.) Thu, 18 Sep 2014 12:57:17 +0000 https://www.unessa.net/en/hoyci/2014/09/django-2005-2014/ design django snakesandrubies wilsonminer Redirect to Custom URL After Saving in Django Admin https://www.unessa.net/en/hoyci/2012/07/redirect-custom-url-after-saving/ Here's a quick and dirty admin hack that can save you *lots* of time if you're used to browsing between editing objects in admin and vieving the results on a live site. Put following `change_view`-method in your `admin.py` and now you can make links to admin change page that return you back to where you came from: ```python class BlogEntryAdmin(admin.ModelAdmin): ... def change_view(self, request, object_id, form_url='', extra_context=None): result = super(BlogEntryAdmin, self).change_view(request, object_id, form_url, extra_context) if request.GET.get('return_to', False): result['Location'] = request.GET['return_to'] return result ``` In your template you'd have something like: ```django {% if request.user.is_staff %} <a href="/admin/blog/blogentry/{{ entry.pk }}/?return_to={{ entry.get_absolute_url }}">Edit in admin</a> {% endif %} ``` Of course, if you're smart, you should convert any places that need this kind of functionality with frontend editing tools so you can forget going to the Admin in the first place. But meanwhile, those few lines of code may come in handy! Fri, 27 Jul 2012 02:31:55 +0000 https://www.unessa.net/en/hoyci/2012/07/redirect-custom-url-after-saving/ django admin tip Convention Over Configuration: Django Settings https://www.unessa.net/en/hoyci/2011/07/conventions-django-settings/ I've been working with Django for over five years. Even though **I don't consider myself as a programmer**, one of the advantages I seem to have over less experienced Django developers is that I've developed (together with <a href="http://www.syneus.fi/" title="Syneus Solutions -- In Finnish">our team</a>) strong conventions on how I work. This makes developing faster and generally more enjoyable. Conventions are a tool for efficient workflow and to help read and understand code by other people better. Like so many tools, conventions too can be taken to extremes to the point when then they become magic (Rails, anyone), which in Python community is <a href="http://www.reddit.com/r/Python/comments/ex54j/seeking_clarification_on_pylonsturbogearspyramid/c1bo1v5">considered a bad practice</a>. The Python community has a name for code that feels right: that kind of code is _pythonic_. Good, pythonic conventions are logical and easy to remember but also explicit. In other words good conventions should make sense when you see them first time. Django has many documented conventions (like that models should live in `models.py` and views in `views.py`) and even <a href="https://docs.djangoproject.com/en/1.3/internals/contributing/#coding-style">coding guidelines</a> but there are many places that could use more stronger or better ones. This article is first in a series of discussing conventions related to Django. My goal is not to impose these opinnions to anyone but to share what I've learned while working with Django for over five years. ### Conventions for Django settings Settings are not the sharpest tool in the Django shed. This article is not about crying over the design details, but to make working with them easier. #### Always use relative paths One of the first hurdles one comes up with Django settings is that they aren't very portable. The `MEDIA_ROOT`, `STATIC_ROOT` and `TEMPLATE_DIRS` settings are problematic because the given examples are absolute paths (like `"/home/media/media.lawrence.com/media/"`). Simply by defining your paths as relative you can free yourself from this and move your projects around without breaking your settings. A good convention is to define a `PROJECT_ROOT` setting and make every path in your settings relative to that root. Django settings file is just an ordinary Python module (well, not really, but in this respect it is) so you can use Python to do this: ```python import os PROJECT_ROOT = os.path.abspath(os.path.join(os.path.dirname(__file__), '../../')) MEDIA_ROOT = os.path.join(PROJECT_ROOT, 'media') ``` #### Turn settings into a package Second problem you almost immediately have is a problem of multiple settings files. You can make your life a lot easier by moving settings from ´settings.py´ into several different files in a directory called settings. (Remember that to python `/path/to/your_project/settings.py` and `/path/to/your_project/settings/__init__.py` are the same thing.) Also, because there usually is at least two almost equal settings files (for development and production), it's smart to differentiate common settings and the ones that change for every machine. For this, you can move common settings to `common_settings.py` and then just import that to your other settings files: ```python from common_settings import * ``` Now you can either add an empty `__init__.py` to the settings directory and refer to settings as `DJANGO_SETTINGS_MODULE=myproject.settings.myenv` or you can symlink the current environment settings as `__init__.py`.) You could end up with a directory structure like this: myproject/ manage.py urls.py settings/ __init__.py common_settings.py dev_adrian.py dev_jacob.py dev_simon.py production.py staging.py Now you have one file for common settings and one for each individual environment and they all can live together in version control. #### Store sensitive data outside of settings files Another problematic thing about Django settings is that you're supposed to put things like passwords and API-keys in there. For development environment this seldomly is a problem but what about version control and different settings for staging and production environments? At this point it is a no-brainer: just put all sensitive data to a file outside of version control and import that: ```python from secrets import * ``` Now we don't need to think about storing sensitive data in the version control and we just need to make sure that `secrets.py` is properly protected in the production environment. ### Conclusion Conventions are good and we need them. By using these few simple conventions you can make your Django projects more portable, secure and pythonic. More important than the implemention details is that you follow _some_ conventions. I'm a strong believer of customization and that you should make your own conventions that best fit you yourself or your team. (This, obviously, is not something you shouldn't do when writing your first Django apps but instead when you have been working with Django a while so that you have a general feeling of what works for you and what doesn't.) **Next in the series** I'll talk about arranging the overall project structure and the tools that help keeping your project evolving. Meanwhile, **any comments or tips that you'd like to share?** Tue, 19 Jul 2011 18:53:17 +0000 https://www.unessa.net/en/hoyci/2011/07/conventions-django-settings/ conventions bestpractices idioms django python Controlling iTunes from Python https://www.unessa.net/en/hoyci/2011/07/itunes-from-python/ <a href="http://www.flickr.com/photos/uninen/2448444839/" title="django-tunes by Uninen, on Flickr"><img src="http://farm4.static.flickr.com/3127/2448444839_83b611b31e_m.jpg" width="180" height="240" alt="django-tunes" style="float: right; border: 1px solid blue;"></a><a href="http://www.flickr.com/photos/uninen/2448444839/">Back in 2008</a> I stumbled on then new API on Mac OS X called <a href="http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/ScriptingBridgeConcepts/Introduction/Introduction.html">Scripting Bridge</a> that enables easy controlling of Cocoa apps (like iTunes) from scripting languages like Python. I wrote simple proof-of-concept Django app that turned my iPod touch into a remote control. It was cool, even though it didn't do very much. Now there's of course native iOS apps for this but I was somewhat surprised that there are still not much code for controlling iTunes via Web. I misplaced my original code so I decided to write it again -- just for fun. So here's a working class for controlling iTunes, in 58 lines of Python: ```python # -*- coding: utf-8 -*- from Foundation import * from ScriptingBridge import * class iTunes(object): """ A helper class for interacting with iTunes on Mac OS X via Scripting Bridge framework. To use this, launch iTunes and make sure a playlist or an album is ready. Usage: >>> player = iTunes() >>> player.status 'playing' >>> player.current_track u'Maison Rilax' >>> player.current_album u'Maison Rilax' >>> player.current_artist u'Lemonator' >>> player.pause() >>> player.status 'paused' >>> player.play() >>> player.next() >>> player.current_track u'Not Your Game' """ def __init__(self): self.app = SBApplication.applicationWithBundleIdentifier_("com.apple.iTunes") def _get_status(self): if self.app.playerState() == 1800426320: return "playing" elif self.app.playerState() == 1800426352: return "paused" else: return "unknown" status = property(_get_status) def _get_current_track(self): return self.app.currentTrack().name() current_track = property(_get_current_track) def _get_current_artist(self): return self.app.currentTrack().artist() current_artist = property(_get_current_artist) def _get_current_album(self): return self.app.currentTrack().album() current_album = property(_get_current_album) def _set_volume(self, level): """ level should be an integer between 0-100. """ self.app.setSoundVolume_(level) def _get_volume(self): return self.app.soundVolume() volume = property(_get_volume, _set_volume) def pause(self): self.app.pause() def play(self): # According to AppleScript documentatin there should be a .play() # method, but apparently there isn't. So we fake it :) if self.status == "paused": self.app.playpause() def next(self): self.app.nextTrack() def previous(self): self.app.previousTrack() ``` This could be easily refined into something potentially interesting like a native REST API for iTunes. The downside, of course, is that it only works on a Mac. (The <a href="https://bitbucket.org/Uninen/django-tunes/src">code is available also on BitBucket</a>.) A somewhat related is a project called <a href="http://www.mopidy.com/">Mopidy</a>, which is a Python powered MPD music server for the awesome Spotify music service (that is suposed to finally be launching in US very soon, I hear.). I'm not at all familiar with <a href="http://en.wikipedia.org/wiki/Music_Player_Daemon">MPD</a> but I think it wouldn't be very difficult to build a Django frontend to a server like Mopidy to get a very slick Web-based interface to your music. Now *that* would be cool. Tue, 12 Jul 2011 03:08:24 +0000 https://www.unessa.net/en/hoyci/2011/07/itunes-from-python/ python django itunes scriptingbridge Django Release Party in Helsinki https://www.unessa.net/en/hoyci/2008/09/django-release-party/ Heads up [Finnish Djangonauts](http://djangopeople.net/fi/)! Join us for celebrating the Django 1.0 release at Kaapelitehdas, Helsinki tomorrow evening (Saturday 6th) starting at 5 pm. More information on the location and attendees can be found on the [event wiki page](http://code.djangoproject.com/wiki/VersionOneReleasePartyHelsinki). This is an open invite -- everyone is welcome! See you there! :) Fri, 05 Sep 2008 17:53:24 +0000 https://www.unessa.net/en/hoyci/2008/09/django-release-party/ django releaseparty party helsinki EuroPython 2008, day 3 https://www.unessa.net/en/hoyci/2008/07/europython-day-3/ For me, the main theme for the third and last day of the conference was Django. Day started with a session by Honza Král about Django newforms admin, which gave me a pretty good idea what I have to do in preparing for the migration to the new admin interface. Later on the day I had many interesting discussions about varions Django-related things, including ideas about having something like Django release party here in Europe, too. <a href="http://www.flickr.com/photos/uninen/2655794578/" title="We had time to visit the Vilnius TV tower"><img src="http://farm4.static.flickr.com/3183/2655794578_fcd0aba681_m.jpg" width="180" height="240" alt="At Vilnius TV Tower" align="right" /></a>Turns out there are quite a lot Djangonauts here in EuroPython, we just arent organized very well so most of us don't know about each other. Lively after-conference discussions about career choises, Web Design and working with Django in general were definitely the high point of the conference so far. A couple of hour later on the evening, decisions about quiet evening at the Sky Bar (at the 22nd floor of the conference hotel) were forgotten and, again, we headed for the old town. This time we ended up in some night club and, well, yeah, we had a great time :) Thu, 10 Jul 2008 15:47:00 +0000 https://www.unessa.net/en/hoyci/2008/07/europython-day-3/ django vilnius djangopeople europython europython2008 EuroPython 2008, day 2 https://www.unessa.net/en/hoyci/2008/07/europython-day-2/ I skipped most of the sessions for the day as they didn't seem even remotely interesting to me. But, the ones I did attend where really good. [Last nights partying](http://www.flickr.com/photos/uninen/2647190250/) kept me pretty much in bed for better part of the morning. **Descriptor tutorial** by Raymond D. Hettinger was very good and I think it was actually the first conference tutorial ever that actually teached me something about programming and Python in general. There was quite a bit testing-related material on the **Lightning talks**. One thing I wrote down on my notes was the phrase "Given enough tests, all bugs are shallow" (originally from Linus Torvalds in a form "Given enough eyeballs, all bugs are shallow"). The **keynote talk** for the day was something that absolutely blew my mind. Hans Rosling talked about [Gapminder](http://www.gapminder.org/) and how statstical data and databases should be free. First thing that crossed my mind when listening to him was that "I wonder if Adrian Holovaty has ever talked to this guy -- they'd have much to talk about". If you havent heard about Gapminder or Hans Rosling before, you should definitely [see his talk on last years TED conference](http://www.ted.com/index.php/talks/hans_rosling_shows_the_best_stats_you_ve_ever_seen.html). In Django-terms, thats some cool shit :) ### EuroPartyPython 2008, night 2 <a href="http://www.flickr.com/photos/uninen/2650505935/" title="Smile! by Uninen, on Flickr"><img src="http://farm4.static.flickr.com/3054/2650505935_691962ce17.jpg" width="500" height="375" alt="Smile!" /></a> After Roslings inspiring keynote there was the conference dinner. We ate well and headed again to down town Vilnius. (Todays dream team was [Edgars](http://djangopeople.net/edgars/), [Nicolas](http://djangopeople.net/nicolaslara/) and [me](http://djangopeople.net/uninen/).) The two girls from last night showed up as they had promised. We had great time with them for a couple of hours untill they left early. We stayed at the bar and eventually hooked up with [three cute Lithuanian girls](http://www.flickr.com/photos/uninen/2650505935/). Lots of dancing, beer and fun until the bar closed at 3 am. What a great night -- again! Wed, 09 Jul 2008 04:42:40 +0000 https://www.unessa.net/en/hoyci/2008/07/europython-day-2/ europython2008 europython django hansrosling adrianholovaty testing python EuroPython 2008, day 1 https://www.unessa.net/en/hoyci/2008/07/europython-day-1/ After a long year of exiting projects and neverending days at the office, I found myself again from EuroPython conference at Vilnius. The first conference day was full of interesting happenings, mainly reviving old and creating new connections. For all the sessions I attended during the day, I made some notes on few of them. Here are some basic notes about selected ones: ###Build an App in a Week by Marcin Kaszynski - [favpico.com](http://favpico.com/) etc - Suprisingly many of the attendees (about half) use Django - Use aDjango admin for users, too (not only for admins) - "Commit early, commit often" - Share code only via vcs - Use conventions - @with_template decorator - Note: you can use admin docs (template name) - Tests Do save time - self.login(), get, find - coverage.py - Instant Django This talk was interesting but didn't really give much new stuff (at least for me). There was a discussion about how it makes sense to use convention of naming templates like `app/viewname.html` but I pointed out that if you for some reason want to part from that convention (that I believe most Django developers use), you can just point Django admin site help section to your designer and just document the fact in your modeldocs. No phone calls necassary still and you can have full control of your customized software. ### My God, it's Full of Files by Tommi Virtanen - "I want to work with files in a uniform way no matter where they are" - path.py - eagain.net This talk was interesting, but we clearly need someone that says "yes, I can do this". I, for one, will buy a beer to anyone who makes file- and directory handling more uniform and easier with Python. ### py.test -- Rapid Testing with Minimal Effort by Holger Krekel - looping tests - HTML generation - javascript tests This talk was really interesting. It made me want to try py.test with Django test framework but I suppose that it's not compatible. The talk also made me miss my old two-display setup. Automatically looping tests are very neat. ### Data Portability and Python -- Christian Scholz - OpenId - Yadis - Oauth - FOAF - RDF - microformats - pydataportability.net Very nice talk in every possible way, but there were nothing new for me this time. ### Keynote, Guido van Rossum - "Open source needs to move or die" - what breaks and why - new features - argument annotations - abstract base classes - extended iterable unpacking - new string format method - enables future evolution - 2to3 tool - switch when 1) youre ready and 2) all your dependencies have been ported - "well help libraries to upgrade" - do now - use dict.iterkeys() - "Django has been separating unicode for. years now" - 2.6 warns you with -3 flag - q&a - documentation is changing (will be up for 2.6) - distributing different versions is easy Quido has been brainwashing us. Only a couple of more times this same time and I'll actually agree most of the features and if want to try them. For me this day was a success. Made a couple of new friends, hooked up with old friends and got to listen sme brilliant sessions. During the night we went to a couple of small bars in the old town nd had even more fun. The only unsure thing about this evening was if we're going to see the girls again or not :) Tue, 08 Jul 2008 00:02:46 +0000 https://www.unessa.net/en/hoyci/2008/07/europython-day-1/ django europython europython2008 vilna vilnius We Are Django https://www.unessa.net/en/hoyci/2008/01/we-are-django/ I've always thought that the community is one of the greatest things about Django. Not because Django isn't great but because the people are just so awesome! [Django People](http://djangopeople.net/) is a brilliant new site by [Simon Willison](http://simonwillison.net/) and [Natalie Downe](http://notes.natbat.net/) which brings together Djangonauts all over the world. (Interestingly, I was talking about _exactly_ this same idea yesterday with my friend, in the lines of "there should definitely be something like that". Great minds think alike (I wish) :) I had the pleasure of meeting Simon and Natalie during the Europython conference [last summer](/en/hoyci/2007/07/europython-2007/). Like every other Django people at the conference, they were super-nice and fun to share thoughts with. The various conversations we had with the Web-gang there were definitely one of the highlights of my last year. I hope that Django People will help in finding more same-minded people, both near you and when traveling around the world. If you are Djangonaut, add yourself to the site! And when you do, please include your picture and some information about yourself. It's so much nicer to look at real faces than empty rectangles :) Here's to many more Django friends. Wed, 23 Jan 2008 05:36:08 +0000 https://www.unessa.net/en/hoyci/2008/01/we-are-django/ django djangopeople friends simonwillison nataliedowne community