risatrix

class Command(NoArgsCommand):
    help = "Output flatpage info as a csv"

    print 'hello, flatpage'

    def handle(self, **options):
        pages = FlatPage.objects.all()
        test_pages = FlatPage.objects.filter(url__icontains='test')
        interactive_pages = FlatPage.objects.filter(url__icontains='interactive')
        js_pages = FlatPage.objects.all().exclude(extra_js=u'')

risatrix

https://docs.djangoproject.com/en/1.5/ref/contrib/syndication/#custom-feed-generators
http://stackoverflow.com/questions/660836/django-way-of-specifying-channel-image-in-rss-feed
http://www.devinterface.com/blog/en/2011/01/how-to-create-a-custom-feed-in-django-using-the-syndication-feed-framework/
http://runnable.com/Up-BKcQBS3ZKAAG_/how-to-create-rss-feeds-in-django-for-python-and-utils
https://docs.djangoproject.com/en/1.7/_modules/django/utils/feedgenerator/
https://christiankaula.com/howto-django-syndication.html
https://djangosnippets.org/snippets/1648/

risatrix

I think deciding whether to build or not to build reflects the larger paradox of programmers saying over and over again that we shouldn't re-invent the wheel...but then doing it anyway, out of a desire to get a perfect/"right" solution. Or maybe just out of an urge to understand the system fully (this is why I myself re-invent wheels all the time, because I want to understand the deep logic behind the "right" way). And yes, if you have all the time in the world, you can probably make a beautiful perfect thing. But we don't, ever.

Anyway, here are some examples from our own org where hindsight is 20/20, and where the decision was "code the thing fully, or not?"

1. Our contact form. Originally built as its own app within Django, probably out of a desire to do things the "right" way, i.e. the Django way, i.e. to have the url map to a named view of an isolated app. However, this meant that it had to be configured with Mandrill, that it stored every communication in the database, and that it required tech's inte

risatrix

Here's our template for what should go in a pull request. This seems overly-verbose, but will help us:

• manage technical debt
• link pull requests to sprint tasks
• give future developers a lot more context
• give reviewers the context they need to understand the problem you're trying to solve and the acceptance criteria you're trying to meet.

It's nice, but not required to fill everything out when you first open your pull request. This template shouldn't be a barrier to contributing code - and you can open a PR with the words WIP in front, to let us know it's not quite there yet, then go back and update information at any time.