<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:dc="http://purl.org/dc/elements/1.1/" version="2.0"><channel><atom:link rel="hub" href="http://tumblr.superfeedr.com/" xmlns:atom="http://www.w3.org/2005/Atom"/><description>ELCODO is a web-oriented company located in Poland. We believe in technology, great design and usability. This blog helps us to share the knowledge with community.</description><title>ELCODOlog</title><generator>Tumblr (3.0; @elcodo)</generator><link>http://blog.elcodo.pl/</link><item><title>GG.pl REST API: python-ggapi</title><description>&lt;p&gt;Yesterday, we’ve released simple implementation of GG.pl API. GG.pl is Facebook-like site based on most popular polish IM - Gadu-Gadu.&lt;/p&gt;
&lt;p&gt;&lt;a title="python-ggapi by ELCODO" href="https://github.com/elcodo/python-ggapi"&gt;python-ggapi&lt;/a&gt; is a client library that allows you to send notifications to users, get their data from public directory, and post to dashboard.&lt;/p&gt;
&lt;p&gt;More about GG.pl and it’s API: &lt;a title="GG.pl API" href="http://dev.gg.pl"&gt;&lt;a href="http://dev.gg.pl"&gt;http://dev.gg.pl&lt;/a&gt;&lt;/a&gt; (in polish).&lt;/p&gt;
&lt;p&gt;Library is licensed under OSI BSD license. For manual and download check github: &lt;a title="python-ggapi by ELCODO" href="https://github.com/elcodo/python-ggapi"&gt;&lt;a href="https://github.com/elcodo/python-ggapi"&gt;https://github.com/elcodo/python-ggapi&lt;/a&gt;&lt;/a&gt;&lt;/p&gt;
&lt;hr&gt;&lt;p&gt;Wczoraj wydaliśmy pierwszą wersję modułu Python obsługującego API serwisu GG.pl.&lt;/p&gt;
&lt;p&gt;Pozwala on na pobieranie danych z katalogu publicznego, wysyłanie notyfikacji do użytkowników, umieszczanie wiadomości na pulpicie użytkownika.&lt;/p&gt;
&lt;p&gt;Więcej o API GG.pl: &lt;a title="GG.pl API" href="http://dev.gg.pl"&gt;&lt;a href="http://dev.gg.pl"&gt;http://dev.gg.pl&lt;/a&gt;&lt;/a&gt;&lt;/p&gt;
&lt;p&gt;Dokumentację i kod źródłowy (licencja BSD) można znaleźć na github: &lt;a title="python-ggapi by ELCODO" href="https://github.com/elcodo/python-ggapi"&gt;&lt;a href="https://github.com/elcodo/python-ggapi"&gt;https://github.com/elcodo/python-ggapi&lt;/a&gt;&lt;/a&gt;&lt;/p&gt;</description><link>http://blog.elcodo.pl/post/2131434260</link><guid>http://blog.elcodo.pl/post/2131434260</guid><pubDate>Tue, 07 Dec 2010 08:00:00 +0100</pubDate><category>gg.pl</category><category>python</category><category>api</category><category>rest</category></item><item><title>Tumblr: QuickTumble Safari Extension</title><description>&lt;p&gt;We made simple extension for &lt;a title="Apple Safari" href="http://apple.com/safari"&gt;Safari 5&lt;/a&gt; which allows you to quick post to &lt;a title="Tumblr" href="http://tumblr.com"&gt;tumblr&lt;/a&gt;. It is called &lt;a title="QuickTumble by ELCODO" href="http://elcodo.pl/safari/tumblr/"&gt;QuickTumble&lt;/a&gt; and can be obtained &lt;a title="QuickTumble Safari Extension" href="http://elcodo.pl/safari/tumblr/"&gt;here&lt;/a&gt; for free.&lt;/p&gt;
&lt;p&gt;&lt;span&gt; &lt;/span&gt;&lt;/p&gt;
&lt;p&gt;Currently it provides:&lt;/p&gt;
&lt;ul&gt;&lt;li&gt;&lt;strong&gt;toolbar button&lt;/strong&gt; - toggles bar with shortcuts to add different media types to tumblelog (text, photo, link, etc.)&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;“Tumble Link to this Page” context menu&lt;/strong&gt; for quick posting links to currently browsed page&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;“Tumble Selection as Quote” context menu&lt;/strong&gt; for quick posting selected text on visited page as quote&lt;/li&gt;
&lt;/ul&gt;&lt;p&gt;For screenshots and download link please visit &lt;a title="QuickTumble Safari Extension" href="http://elcodo.pl/safari/tumblr/"&gt;QuickTumble extension page&lt;/a&gt;.&lt;/p&gt;
&lt;p&gt;We love to hear your opinion about it! Please post comments here, on &lt;a title="ELCODO on Facebook" href="http://www.facebook.com/pages/ELCODO/113540645355962"&gt;Facebook&lt;/a&gt; or on our Twitter (&lt;a title="ELCODO on Twitter" href="http://twitter.com/ELCODOsoft"&gt;@ELCODOsoft&lt;/a&gt;). Tell us what you would add, change or remove.&lt;/p&gt;</description><link>http://blog.elcodo.pl/post/972867985</link><guid>http://blog.elcodo.pl/post/972867985</guid><pubDate>Wed, 18 Aug 2010 19:44:03 +0200</pubDate><category>technical</category><category>safari</category><category>safari-extensions</category><category>tumblr</category><category>quicktumble</category></item><item><title>Django: detect user's first login</title><description>&lt;p&gt;Sometimes we want to detect information about user’s first login, e.g. to show account detail or edit form.&lt;/p&gt;
&lt;p&gt;First thought would be to look at &lt;a title="Django docs: User.last_login" href="http://docs.djangoproject.com/en/1.2/topics/auth/#django.contrib.auth.models.User.last_login"&gt;last_login&lt;/a&gt; field in User model, but… it is filled with date after user signed up and doesn’t logged in yet.&lt;/p&gt;
&lt;p&gt;So, can we assume that User.last_login and User.date_joined fields have equal value after registration? I think it is too risky - dates might be equal but it is not guaranteed.&lt;/p&gt;
&lt;p&gt;In this case we must extend our user profile model (more on this topic: &lt;a title="Django docs: Additional information about users" href="http://docs.djangoproject.com/en/dev/topics/auth/#storing-additional-information-about-users"&gt;&lt;a href="http://docs.djangoproject.com/en/dev/topics/auth/#storing-additional-information-about-users"&gt;http://docs.djangoproject.com/en/dev/topics/auth/#storing-additional-information-about-users&lt;/a&gt;&lt;/a&gt;). This is not the cleanest method but the simplest one.&lt;/p&gt;
&lt;p&gt;Let’s add new field to out UserProfile model:&lt;/p&gt;
&lt;pre class="brush: python"&gt;class UserProfile(models.Model):
    """Additional user fields"""
    user = models.ForeignKey(User, unique=True)    
    (...)
    is_first_login = models.BooleanField(default=True,
        verbose_name=_(u"Is first login?"))
&lt;/pre&gt;
&lt;p&gt;Okay, now we need to detect user login and check if it is his first attempt. We will create &lt;a title="Django docs: Writing your own middleware" href="http://docs.djangoproject.com/en/1.2/topics/http/middleware/#writing-your-own-middleware"&gt;custom middleware&lt;/a&gt; to do the check.&lt;/p&gt;
&lt;p&gt;Middleware should be located in settings.py’s MIDDLEWARE_CLASSES after ‘django.contrib.auth.middleware.AuthenticationMiddleware’:&lt;/p&gt;
&lt;pre class="brush: python"&gt;MIDDLEWARE_CLASSES = (
    'django.contrib.sessions.middleware.SessionMiddleware',
    'django.middleware.common.CommonMiddleware',
    'django.contrib.auth.middleware.AuthenticationMiddleware',
    'users.middleware.FirstLoginMiddleware',
    (...)
)
&lt;/pre&gt;
&lt;p&gt;This is FirstLoginMiddleware (e.g. users.middleware.FirstLoginMiddleware):&lt;/p&gt;
&lt;pre class="brush: python"&gt;# -*- coding: utf-8 -*-
from django.core.urlresolvers import reverse
from django.http import HttpResponseRedirect


class FirstLoginMiddleware(object):

    def process_request(self, request):
        if request.user.is_authenticated() and "dont_check_first_login" \
            not in request.session:
            request.session["dont_check_first_login"] = True
            profile = request.user.get_profile()
            if profile.is_first_login:
                profile.is_first_login = False
                profile.save()
                return HttpResponseRedirect(reverse('users:account_edit'))
&lt;/pre&gt;
&lt;p&gt;As you can see, we used session variable named “dont_check_first_login” (long name, isn’t it?).&lt;/p&gt;
&lt;p&gt;It is used to determine that user has already logged in so we don’t query database in each request. Consider caching user profile in real life app - this code is example how to catch first login.&lt;/p&gt;</description><link>http://blog.elcodo.pl/post/926902087</link><guid>http://blog.elcodo.pl/post/926902087</guid><pubDate>Mon, 09 Aug 2010 14:39:38 +0200</pubDate><category>django</category><category>auth</category><category>registration</category><category>login</category><category>middleware</category><category>technical</category></item><item><title>Facebook: Profile tab with your GitHub repositories</title><description>&lt;p&gt;We made simple application for Facebook allowing you to display your open source (public) repositories stored on &lt;a title="GitHub" href="http://github.com"&gt;GitHub&lt;/a&gt;. Obviously, it’s called GitHub Repositories and is available here: &lt;a title="GitHub Repositories Facebook App by ELCODO" href="http://www.facebook.com/apps/application.php?id=120729024640004"&gt;&lt;a href="http://www.facebook.com/apps/application.php?id=120729024640004"&gt;http://www.facebook.com/apps/application.php?id=120729024640004&lt;/a&gt;&lt;/a&gt;.&lt;/p&gt;
&lt;p&gt;Here’s how it looks:&lt;/p&gt;
&lt;p&gt;&lt;img align="middle" src="http://static.elcodo.pl/tumblr/10_fb_1.png" alt="GitHub repository list app" width="503" height="342"/&gt;&lt;/p&gt;
&lt;p&gt;For live demo go to our &lt;a title="ELCODO Facebook Page" href="http://www.facebook.com/pages/ELCODO/113540645355962"&gt;Facebook&lt;/a&gt; page.&lt;/p&gt;
&lt;p&gt;It is very simple at the moment - when you connect app to your profile it will ask for username, then you could add tab to your profile using “+”.&lt;/p&gt;
&lt;p&gt;&lt;br/&gt;We will continue to develop it so GitHub user profile data is displayed and you could change username without having to uninstall app and install it again.&lt;/p&gt;
&lt;p&gt;&lt;br/&gt;Feel free to post ideas, bugs, anything on Application Page. If you like &lt;a title="GitHub Repositories Facebook App" href="http://www.facebook.com/apps/application.php?id=120729024640004"&gt;GitHub Repositories&lt;/a&gt; - install it on your profile and/or like it on Facebook! :)&lt;/p&gt;</description><link>http://blog.elcodo.pl/post/902272368</link><guid>http://blog.elcodo.pl/post/902272368</guid><pubDate>Wed, 04 Aug 2010 11:21:00 +0200</pubDate><category>facebook</category><category>application</category><category>github</category><category>technical</category></item><item><title>Django: How to see if model instance was changed after save (or how to keep model instance state)</title><description>&lt;p&gt;There are situations when you want to know when model instance was changed. E.g. slugs generation when you change title (or maybe this example is discussable when comes to SEO?).&lt;/p&gt;
&lt;p&gt;SEO matters but there are some real-life situations when you need this - let’s look at following example:&lt;/p&gt;
&lt;p&gt;- you’re using &lt;a title="django-mptt" href="http://code.google.com/p/django-mptt/"&gt;django-mptt&lt;/a&gt; or some other method to store your document tree,&lt;/p&gt;
&lt;p&gt;- URL to your document is generated using all ancestor names like: “Document” with parent “Data” has an URL like this: /data/document/&lt;/p&gt;
&lt;p&gt;- you want to rebuild all children URLs when root or any parent document title/slug changes.&lt;/p&gt;
&lt;p&gt;Nevertheless, there is some very simple solution to detect model state.&lt;/p&gt;
&lt;p&gt;In your models.py, add new property like that:&lt;/p&gt;
&lt;pre class="brush: python"&gt;class ExampleModel(models.Model):
    # &lt;&lt;model fields goes here&gt;&gt;
    before_save = None
&lt;/pre&gt;
&lt;p&gt;Now, it’s time for &lt;a title="Django model signals" href="http://docs.djangoproject.com/en/dev/topics/signals/"&gt;signals&lt;/a&gt; - we will use pre_save and post_save. First one for getting before save data, second one to recognize it and do some action.&lt;/p&gt;
&lt;p&gt;It is easy to detect field value change, e.g. title change generates new slug. See following example:&lt;/p&gt;
&lt;pre class="brush: python"&gt;def object_pre_save(instance, **kwargs):
    """Store object state before save"""
    try:
        instance.before_save = ExampleModel.objects.get(pk=instance.pk)
    except Transaction.DoesNotExist:
        instance.before_save = None

def object_post_save(sender, instance, created, **kwargs):
    if instance.before_save.title != instance.title:
    # &lt;&lt;generate new slug method&gt;&gt;
    instance.save()

pre_save.connect(object_pre_save, sender=ExampleModel)
post_save.connect(object_post_save, sender=ExampleModel)&lt;/pre&gt;
&lt;p&gt;Of course, you can do more complex lookups for change since there is complete “before-save” instance avaible at instance.before_save.&lt;/p&gt;
&lt;p&gt;Okay, it is using extra query but if you do it right - e.g. in admin it shouldn’t kill your service. Maybe you have better solution for checking if data has changed? Let us know!&lt;/p&gt;</description><link>http://blog.elcodo.pl/post/825088629</link><guid>http://blog.elcodo.pl/post/825088629</guid><pubDate>Sat, 17 Jul 2010 23:48:00 +0200</pubDate><category>django</category><category>python</category><category>technical</category></item><item><title>Django: register user with invitation code</title><description>&lt;a href="http://github.com/elcodo/django-registration-invitationcode-backend"&gt;Django: register user with invitation code&lt;/a&gt;: &lt;p&gt;We made custom backend for &lt;a title="django-registration" href="http://bitbucket.org/ubernostrum/django-registration"&gt;django-registration&lt;/a&gt; app allowing you to simplify your service beta testing by require an invitation code from user.&lt;/p&gt;
&lt;p&gt;Try it, it’s open source and free to fork and modify!&lt;/p&gt;
&lt;p&gt;Remember that generation and distribution of codes is up to you.&lt;/p&gt;</description><link>http://blog.elcodo.pl/post/810326016</link><guid>http://blog.elcodo.pl/post/810326016</guid><pubDate>Wed, 14 Jul 2010 11:26:32 +0200</pubDate><category>django</category><category>django-registration</category><category>pluggable</category><category>opensource</category><category>technical</category></item><item><title>Django/OpenSource Scalability</title><description>&lt;p&gt;Django is great. No doubts about it. But - sometimes comes the question of scalability, especially in a time-and-budget constrains. Well - the very least we can say is that - our client suddenly decided that he needed about 200 rqs - yes, that’s 200 hundred requests per second - and yes, that’s 1728.000 requestes per day. Well, no problem in achieveing that - so far there’s no talk about budget. Well, there was, the all-dreaded least-cost-budget-criteria. So, ELCODO team stood up for the chalenge and came up with a few interesting, open-source ideas. First of them was the load balancing - here came the ideas about using vrrp/carp. The only real concern was about the instability of the IPv6 implementation - which was easily resolved through aggresive negotiations with the client :)&lt;/p&gt;
&lt;p&gt;The second issue was of similar scale - a choice between using replication of the MySQL database and using a dedicated MySQL server. The dedicated option was chosen. So no architectural or otherwise programistic problems here. One database server and that’s enough for now.&lt;/p&gt;
&lt;p&gt;The first of real problems came with the Django module consisting of some sort of an upload module - the uploaded files needed to be in an exact sync with every server.&lt;/p&gt;
&lt;p&gt;For example - server1.elcodo.pl needed to have the same files ijn /upload/ dir as server2.elcodo.pl. The problem was really easy to resolve - given the use of a replicated, clustered filesystem such as GlusterFS. Under consideration, GlusterFS was the most robust, feature-full choice we could make in under a time limit of several minutes. So, a GlusterFS filesystem was created, using 4 servers as filesystem nodes.&lt;/p&gt;
&lt;p&gt;The last problem is considered by many a no-problem situation, but for us is a really headache-case. The problem of “overall efect”, the situation in which you just spent 8 hourse building the systems and it’s simply too slow. The GlusterFS worked like a charm, giving us near real-time results. The database (not replicated) was working fine, as far as the MySQL settings allowed it). One would suggest that the only problem (besides implementing VRRP/Carp in a reasonable way) was the webserver himself. That is not true. We have considered an advanced Nginx (and eventually a Litghttpd) setup - but the Apache 2.2.* was enough. Using the mod_wsgi module without daemon process seems to be a preety acceptable solution.&lt;/p&gt;
&lt;p&gt;So, to bring some “hard-evidence” and “true statistics”:&lt;/p&gt;
&lt;p&gt;- you can easily serve ~200++ requests/sec with Apache/mod_wsgi on cheap hardware&lt;/p&gt;
&lt;p&gt;- Networked, replicated filesystems - like GlusterFS - are really neat&lt;/p&gt;
&lt;p&gt;- all you need is a good LoadBalancing. Good LB will get you about 70% problems less&lt;/p&gt;
&lt;p&gt;- Have a fat pipe if you want to deliver “fat” content - no cache or otherwise cheating will help you.&lt;/p&gt;

&lt;p&gt;Summing up - 4 servers + Django (mod_wsgi) + MySQL + GlusterFS + LoadBalancing.&lt;/p&gt;
&lt;p&gt;3 hours of work. Hardware/instalation cost below 1000$. And that’s called OpenSource ;)&lt;/p&gt;</description><link>http://blog.elcodo.pl/post/751352877</link><guid>http://blog.elcodo.pl/post/751352877</guid><pubDate>Wed, 30 Jun 2010 01:08:00 +0200</pubDate><category>technical</category></item><item><title>brutto:

The more focus on profit, the less good ideas - Social...</title><description>&lt;iframe width="400" height="225" src="http://www.youtube.com/embed/u6XAPnuFjJc?wmode=transparent&amp;autohide=1&amp;egm=0&amp;hd=1&amp;iv_load_policy=3&amp;modestbranding=1&amp;rel=0&amp;showinfo=0&amp;showsearch=0" frameborder="0" allowfullscreen&gt;&lt;/iframe&gt;&lt;br/&gt;&lt;br/&gt;&lt;p&gt;&lt;a href="http://brutto.tumblr.com/post/637830935/the-more-focus-on-profit-the-less-good-ideas"&gt;brutto&lt;/a&gt;:&lt;/p&gt;
&lt;blockquote&gt;
&lt;p&gt;&lt;a href="http://www.socialhallucinations.com/2010/05/the-more-focus-on-profit-the-less-good-ideas.html"&gt;The more focus on profit, the less good ideas - Social Hallucinations&lt;/a&gt; via &lt;a href="http://blip.pl/s/85619185"&gt;ahajduk&lt;/a&gt;&lt;/p&gt;
&lt;p&gt;jednym tchem&lt;/p&gt;
&lt;/blockquote&gt;</description><link>http://blog.elcodo.pl/post/640306142</link><guid>http://blog.elcodo.pl/post/640306142</guid><pubDate>Fri, 28 May 2010 11:28:17 +0200</pubDate><category>business</category></item><item><title>seapomeranian:

mongoengine vs. django-mongokit - Peterbe.com...</title><description>&lt;img src="http://30.media.tumblr.com/tumblr_l2xelgUAcw1qbv5e0o1_400.png"/&gt;&lt;br/&gt;&lt;br/&gt;&lt;p&gt;&lt;a href="http://seapomeranian.tumblr.com/post/628174338/mongoengine-vs-django-mongokit-peterbe-com"&gt;seapomeranian&lt;/a&gt;:&lt;/p&gt;
&lt;blockquote&gt;
&lt;p&gt;&lt;a href="http://www.peterbe.com/plog/mongoengine-vs.-django-mongokit"&gt;mongoengine vs. django-mongokit - Peterbe.com (Peter Bengtsson on Python, Django, Zope, Kung Fu, London and photos)&lt;/a&gt;&lt;/p&gt;
&lt;/blockquote&gt;</description><link>http://blog.elcodo.pl/post/631163789</link><guid>http://blog.elcodo.pl/post/631163789</guid><pubDate>Tue, 25 May 2010 14:35:05 +0200</pubDate><category>technical</category></item><item><title>Django: the easiest way to run manage commands in crontab</title><description>&lt;p&gt;Sometimes there are some management commands I would like to run from crontab at given time or interval. There are some ways when you import setup_environ from Django but there is much simpler solution.&lt;/p&gt;
&lt;p&gt;For example - &lt;a title="Haystack - Keeping the index fresh" href="http://docs.haystacksearch.org/dev/searchindex_api.html?highlight=update_index#keeping-the-index-fresh"&gt;Haystack search index update&lt;/a&gt;. Let’s do it in one hour interval.&lt;/p&gt;
&lt;pre class="brush: bash"&gt;user@server:~$ crontab -l
PYTHONPATH=":/home/www/project/django/lib/python2.5/site-packages"
DJANGO_SETTINGS_MODULE=project.settings

# m h  dom mon dow   command
0 * * * * /home/www/project/manage.py update_index
&lt;/pre&gt;
&lt;p&gt;So, all you need is to set PYTHONPATH and DJANGO_SETTINGS_MODULE according to your settings. And the trick is that it can be done in crontab.&lt;/p&gt;

&lt;p&gt;&lt;em&gt;Note that this was tested on Debian Linux.&lt;/em&gt;&lt;/p&gt;</description><link>http://blog.elcodo.pl/post/630840282</link><guid>http://blog.elcodo.pl/post/630840282</guid><pubDate>Tue, 25 May 2010 11:28:44 +0200</pubDate><category>django</category><category>crontab</category><category>management commands</category><category>haystack</category><category>search</category><category>technical</category></item><item><title>Mac OS X: ⌘ + ⇥ and Dock stops working</title><description>&lt;p&gt;If your Dock stops responding (e.g. cannot click application icon) and you can’t switch between applications using &lt;span&gt;⌘ + ⇥ (Command + Tab) there is an easy way to deal with it without restart.&lt;/span&gt;&lt;/p&gt;
&lt;p&gt;&lt;span&gt;Just open Activity Monitor (typically ⌘ + ␣), find Dock process and kill process using “Quit Process” option. Dock should be restared after a second and everything should back to normal.&lt;/span&gt;&lt;/p&gt;</description><link>http://blog.elcodo.pl/post/576881000</link><guid>http://blog.elcodo.pl/post/576881000</guid><pubDate>Thu, 06 May 2010 22:25:00 +0200</pubDate><category>tips</category><category>mac os x</category><category>mac</category><category>snow leopard</category><category>dock</category><category>technical</category></item><item><title>Django: how to mark required form field with *?</title><description>&lt;p&gt;If you want to mark required fields with * or some other text/symbol - don’t use some hacks in your python code (Label modify in form class, etc.). Things like that should reside in templates and all you need to do is to apply this:&lt;/p&gt;
&lt;pre class="brush: html"&gt;{% if field.field.required %} &lt;em&gt;*&lt;/em&gt;{% endif %}&lt;/pre&gt;
&lt;p&gt;E.g. form display template:&lt;/p&gt;
&lt;pre class="brush: html"&gt;&lt;form action="." method="post"&gt;
{% csrf_token %}
{% for hidden in form.hidden_fields %}
	{{ hidden }}
{% endfor %}

&lt;dl&gt;
{% for field in form.visible_fields %}
	{% if field.errors %}
		&lt;dt&gt;&amp;nbsp;&lt;/dt&gt;
		&lt;dd&gt;{{ field.errors }}&lt;/dd&gt;
	{% endif %}
	&lt;dt&gt;
		{{ field.label_tag }}
		{% if field.field.required %} &lt;em&gt;*&lt;/em&gt;{% endif %}:
	&lt;/dt&gt;
	&lt;dd&gt;{{ field|safe }}&lt;/dd&gt;
{% endfor %}
&lt;dt&gt;&amp;nbsp;&lt;/dt&gt;
&lt;dd&gt;&lt;input type="submit" value="Submit" /&gt;&lt;/dd&gt;
&lt;/dl&gt;
&lt;/form&gt;
&lt;/pre&gt;</description><link>http://blog.elcodo.pl/post/555561156</link><guid>http://blog.elcodo.pl/post/555561156</guid><pubDate>Wed, 28 Apr 2010 11:31:30 +0200</pubDate><category>django</category><category>forms</category><category>newforms</category><category>tips</category><category>technical</category></item><item><title>"We will either find a way, or make one."</title><description>“We will either find a way, or make one.”&lt;br/&gt;&lt;br/&gt; - &lt;em&gt;Hannibal&lt;/em&gt;</description><link>http://blog.elcodo.pl/post/519133172</link><guid>http://blog.elcodo.pl/post/519133172</guid><pubDate>Tue, 13 Apr 2010 23:58:00 +0200</pubDate><category>wisdom</category></item></channel></rss>

