carljm

"""
An alternative Django ``TEST_RUNNER`` which uses unittest2 test discovery from
a base path specified in settings, rather than requiring all tests to be in
``tests`` module of an app.

If you just run ``./manage.py test``, it'll discover and run all tests
underneath the ``TEST_DISCOVERY_ROOT`` setting (a path). If you run
``./manage.py test full.dotted.path.to.test_module``, it'll run the tests in
that module (you can also pass multiple modules).

kmike

import functools
import sys
import re
from django.conf import settings
from django.db import connection

def shrink_select(sql):
    return re.sub("^SELECT(.+)FROM", "SELECT .. FROM", sql)

def shrink_update(sql):

ryanmark

/*
 * Take a set of full height screenshots for a range of screensizes.
 *   phantomjs responsive-screens.js http://www.cnn.com/ png
 *
 * This will create a directory tree in your current directory which
 * mirrors the URL. All files will be named with the current time.
 * You can run this on a cron to build an archive of screenshots.
 **/

var page = new WebPage(),

jacobian

Where people struggle learning Django

Over the last 3 years or so I've helped a bunch of companies, small and large, switch to Django. As part of that, I've done a lot of teaching Django (and Python) to people new to the platform (and language). I'd estimate I've trained something around 200-250 people so far. These aren't people new to programming — indeed, almost all of them are were currently employed as software developers — but they were new to Python, or to Django, or to web development, or all three.

In doing so, I've observed some patterns about what works and what doesn't. Many (most) of the failings have been my own pedagogical failings, but as I've honed my coursework and my skill I'm seeing, time and again, certain ways that Django makes itself difficult to certain groups of users.

This document is my attempt at organizing some notes around what ways different groups struggle. It's not particularly actionable — I'm not making any arguments about what Django should or shouldn't do (at least

broglep-work

AWSTemplateFormatVersion: 2010-09-09
Description: 'Registers ecs tasks to a second target group'
Parameters:
  ClusterArn:
    Description: 'ANR of cluster the service resides in'
    Type: String
  ServiceName:
    Description: 'Name of the service to register'
    Type: String
  ContainerName:

acdha

{% extends "admin/object_history.html" %}

{% load adminmedia %}

{% block extrahead %}
    {{ block.super }}
    <script src="{% admin_media_prefix %}js/jquery.min.js" type="text/javascript" charset="utf-8"></script>
{% endblock %}

{% block content %}

acdha

# encoding: utf-8
"""Experimental Solr Grouping / Field Collapsing backend for Haystack 2.0"""
# NOTE: You must be running the latest Pysolr master - no PyPI release yet!
# See https://gist.github.com/3750774 for the current version of this code
# See http://wiki.apache.org/solr/FieldCollapsing for the Solr feature documentation
from __future__ import absolute_import

import logging

from django.db.models.loading import get_model

acdha

Traceback (most recent call last):
  File "/Users/cadams/.virtualenvs/wdl/bin/django-admin", line 11, in <module>
    sys.exit(execute_from_command_line())
  File "/Users/cadams/.virtualenvs/wdl/lib/python2.7/site-packages/django/core/management/__init__.py", line 354, in execute_from_command_line
    utility.execute()
  File "/Users/cadams/.virtualenvs/wdl/lib/python2.7/site-packages/django/core/management/__init__.py", line 328, in execute
    django.setup()
  File "/Users/cadams/.virtualenvs/wdl/lib/python2.7/site-packages/django/__init__.py", line 18, in setup
    apps.populate(settings.INSTALLED_APPS)
  File "/Users/cadams/.virtualenvs/wdl/lib/python2.7/site-packages/django/apps/registry.py", line 85, in populate

johnscancella

# new 4.0 format.
vcl 4.0;

import directors;

backend app1 {
    .host = "ndnpappvlp01.loc.gov";
    .probe = {
        .url = "/";
        .interval = 60s;

azaroth42

Discovery Support Technical Specifications Group Charter

Introduction

Interoperable resources are only useful if they can be found. This has been well-recognized since the early days of the IIIF community, and more recently it has become clear that a concerted effort to standardize patterns that will facilitate discovery, harvesting and synchronization, indexing, and importing of IIIF resources is required.

This group will create specifications that improve the discovery process for IIIF resources, with a focus on leveraging existing techniques and tools, and promoting widespread adoption within the community. It will assist with and steer the implementation of community infrastructure, such as a registry of adopters, validators for the implementations, and transformation tools to generate the required data from existing systems and APIs.

If successful, the work will enable the collaborative development of global or thematic registries, search engines and portal applications that allow developers a