Here's a method for getting that new foreign key column to be non-nullable and without a default.



## Django migrations are awesome

Django has a solid ORM and some nice database migrations to go with it. First, make a change to your model in python code, then run:

```bash
python manage.py makemigrations
```

The the migrations will be generated based on your model changes since the last migration. To apply the migrations in the database, run:

```bash
python manage.py migrate
```

But what if you want to make a migration for a new non-nullable field?

## Protective parent

Well, Django wants to help you do the right thing. And if you add a new non-nullable field to the model and run `makemigrations`, it'll balk and warn you that you can't make a new non-null field because you might already have rows without that new column, and those rows can't violate the non-null constraint on the column.

It'll report something like:

```
~/myapp ❯ python manage.py makemigrations
You are trying to add a non-nullable field 'created_by' to mymodel without a default; we can't do that (the database needs something to populate existing rows).
Please select a fix:
 1) Provide a one-off default now (will be set on all existing rows with a null value for this column)
 2) Quit, and let me add a default in models.py
```

## Give in and add the default

To get the migrations to run, add the default one way or the other.

That might look like:

```python
from django.contrib.auth.models import User
from django.db import models

class MyModel(models.Model):
    # ...
    created_by = models.ForeignKey(User, default="")
```

Now you'll be able to `makemigrations`.

## Then turn around and remove it

But now you're sneaking out the bedroom window...

Adjust your model again, removing the default: 

```python
from django.contrib.auth.models import User
from django.db import models

class MyModel(models.Model):
    # ...
    created_by = models.ForeignKey(User)
```

You run `makemigrations` again, and you're set: new column, no default, non-nullable.

A bit of a run-around? Yes. Do you have a better way to do this?

A method for getting that new foreign key column to be non-nullable and without a default.

Add a Migration for a Non-null ForeignKey Field in Django

Django comes with some awesome CLI tools.  Manage.py is a beast of magic and lore.  And it loves the fantastical kingdom of Heroku, where is romps with merry measure twixt the ether.  But, when I've tried to go through a dumpdata of a previous site, syncdb on a migration to Heroku, and loaddata for moving the data, I've run into a snag on django_content_type_app_label_key more than once.  Here are some resolutions.



The Error Stack
---------------

Specifically, when I do a sync of the database:

```bash
heroku run python manage.py syncdb
```

It works like a charm.  And then a loading of the data:

```bash
heroku run python manage.py loaddata data.json
```

It runs for a bit then spews this small hiccup:

```bash
Running python manage.py loaddata data.json attached to terminal... up, run.2
Problem installing fixture 'data.json': Traceback (most recent call last):
  File "/app/lib/python2.7/site-packages/django/core/management/commands/loaddata.py", line 174, in handle
    obj.save(using=using)
  # ...more stack trace...
  File "/app/lib/python2.7/site-packages/django/db/backends/postgresql_psycopg2/base.py", line 44, in execute
    return self.cursor.execute(query, args)
IntegrityError: duplicate key value violates unique constraint "django_content_type_app_label_key"
```
Lovely.

It turns out that `syncdb`, in addition to running the DDLs for your table creation also populates the `django_content_type` table.  And then when you loaddata it tries to repopulate the table, violating the unique constraint on the content type name.

Make the Magic Live Again
-------------------------

There are a couple ways around this:

### Dump Something Specific
When you dumpdata, only [dump specific apps](https://docs.djangoproject.com/en/dev/ref/django-admin/#dumpdata-appname-appname-appname-model) instead of the whole project.  For example:

```bash
python manage.py dumpdata myApp
```

### Django 1.3 Exclude
If you're on Django 1.3 or above, you get a nice new option with dumpdata to [exclude certain apps](https://docs.djangoproject.com/en/dev/ref/django-admin/#django-admin-option---exclude).  So you could run:

```bash
python manage.py dumpdata --exclude contenttypes
```

### Try in Vain to Reset
Another one I tried (but didn't work) was:

```bash
heroku run python aprilandjake/manage.py reset contenttypes 
```


### Sql Truncate
Or, if you're still trying to dumpdata on your whole project, you could `syncdb` on Heroku and then truncate the data out of `django_content_type` like this:

```bash
heroku run python aprilandjake/manage.py dbshell
```

And then [truncate](http://swik.net/django/Django+Community+Aggregator?page=2) (inside the dbshell):

```bash
truncate django_content_type cascade;    
```

Problem for me is that didn't work either.  I am on the super cheap in Heroku, so I get this lovely denial:

```bash
Running python manage.py dbshell attached to terminal... up, run.5
Error: You appear not to have the 'psql' program installed or on your path.
```

(It's not available in a [shared database](http://devcenter.heroku.com/articles/heroku-postgresql)):

```bash
heroku pg:psql
!  Cannot ingress to a shared database
```

### Delete via Admin UI
And finally, if you want to get rid of the data via the admin UI, set it up to appear as editable.  In an [`admin.py`](https://docs.djangoproject.com/en/dev/ref/contrib/admin/#modeladmin-objects) in your project, try something like this:

```python
from django.contrib.contenttypes.models import ContentType
    
class ContentTypeAdmin(admin.ModelAdmin):
  list_display = ['name', 'app_label']
  fieldsets = (
    ('', {
      'classes': ('',),
      'fields': ('name', 'app_label')
    }),
  )

  admin.site.register(ContentType, ContentTypeAdmin)
```

Now you should be able to loaddata and feel the Django wind in your hair and the Heroku grass beneath your feet again.

Django comes with some awesome CLI tools.  Manage.py is a beast of magic and lore.  And it loves the fantastical kingdom of Heroku, where is romps with merr

django_content_type_app_label_key Constraint on Heroku

Django's manage.py script comes with some great utilitarian commands.  Two of my favorites are dumpdata and loaddata.  I've used these commands recently to migrate a Django app's data to the same Django app now running on Heroku.  Here's a little taste of the glory.



[Django](https://www.djangoproject.com/) is awesome.  [Heroku](http://www.heroku.com/) is awesome.  [Combined](http://devcenter.heroku.com/articles/django>) they are awesomeerest.

First, get your data out of your existing Django app with manage.py's [dumpdata](https://docs.djangoproject.com/en/dev/ref/django-admin/#dumpdata-appname-appname-appname-model):

```bash
python manage.py dumpdata --natural --indent 2 > data.json
```
  
By default it comes out as json, but you can [change that](https://docs.djangoproject.com/en/dev/ref/django-admin/#django-admin-option---format>).  The two options used above have now become common-place for me, providing:

- "--natural" - use this baby for when you dump contrib.contenttypes ContentType.  Since we're taking the whole db, odds are that you're using it, since most interesting django apps do.
- "--indent" - make it human-readable instead of a single-liner.

The "> data.json" is just some Unix'y redirect goodness to stash the output of your dumpdata command in the data.json file.

Now you want to get your data.json into the db of your Heroku-based Django app.  Heroku allows you the ability to run [one-off processes](http://devcenter.heroku.com/articles/oneoff-admin-ps) such as the loaddata command.  But the next hurdle will be getting your data.json onto the Heroku server.  This is always handled in a git push.  And to make it a little bit more interesting, let's say that the code you have isn't particularly sensitive, but the data is.  So, we're going to commit the data.json, push it, remove the latest git commit, be able to push our code to the origin server, and still run loaddata on Heroku.  Sheesh.

Ok, so commit your file:

```bash
git add data.json
git commit -m "Added data"
```
  
Push it to Heroku:

```bash
git push heroku master
```
  
[Remove commit](http://stackoverflow.com/questions/927358/git-undo-last-commit/927386#927386):

```bash
git reset --soft HEAD^
```

[Remove file](http://stackoverflow.com/questions/1505948/how-do-i-remove-a-single-file-from-the-staging-area-of-git-but-not-remove-it-fro/1505968#1505968) from staging area:

```bash
git reset HEAD data.json
```
  
Save your code w/o data included:

```bash
git push origin master
```
  
And now you should still have data.json on your Heroku server and be able to run loaddata:

```bash
heroku run python manage.py loaddata data.json
```
  
If it all works, your data fixtures should be found and you should see a confirmation message that they were loaded into the db.  Just like a dream.  The only thing that would make it better is if you never had to commit data.json at all.  Too bad Heroku couldn't pick up local file input like it can pick up STDIN in a 'heroku run' command!

Update: "Force"
-------------------------------

Also note that if you continue to commit to git locally on future enhancements to your app and then want to push again to Heroku, you'll likely get an error message:

```bash
git push heroku master
To git@heroku.com:myProject.git
 ! [rejected]        master -> master (non-fast-forward)
error: failed to push some refs to 'git@heroku.com:myProject.git'
To prevent you from losing history, non-fast-forward updates were rejected
Merge the remote changes (e.g. 'git pull') before pushing again.  See the
'Note about fast-forwards' section of 'git push --help' for details.
```

To get around this, next time you push to Heroku, try:

```bash
git push heroku master -f
```

And force it to do your bidding.

Django's manage.py script comes with some great utilitarian commands.  Two of my favorites are dumpdata and loaddata.  I've used these commands recently to

Django loaddata on Heroku

Jquery, Ajax, Json, Django -- this is quite a laundry list of technologies.  In fact, it's pretty much the whole stack: client tech, server requests, over-the-network data format, and a backend app server.  In the following slidedeck and example code, we're going to touch on the whole stack and not get too deep into any one area.  By the end, you should be able to at least have a grasp of what technologies one can use in an Ajax Django application, a little bit of what they're capable of, and then, hopefully, a list in your brain that you can go back, reference, and then drill into specific technologies when you want to go build something similar yourself.



Here's the breakdown of the [slideshare slidedeck](http://www.slideshare.net/rockycode/jquery-ajax-json-on-django):

Jquery
---------

- A Javascript framework
- "Write less, do more"
- Select the dom - $(".selection")
- Traverse the dom - $(".my").parent()
- Manipulate the dom - $(".my").append("dectomy")
- Provides an Ajax API - $.ajax()
- Framework for providing your own functionality (plugins) - $(".new").operate()

Ajax
---------

- Asynchronous Javascript and Xml
- Jquery API - $.ajax(), $.get(), $.post(), $.getJSON()

Json
---------

- JavaScript Object Notation
- Terse
- Flexible, nestable
- Native in Javascript

Django
---------

- Web framework built on Python
- "encourages... clean, pragmatic design"
- Django-piston - mini-framework to create RESTful APIs for your data


Because this presentation was originally written for a Django-loving audience who wanted to know more about Jquery, Ajax, and Json, I decided to make the most basic Django app that could easily function with the other (mostly) client-based technologies.  

Sample App
--------------

The result was the "ask" app ([source here](https://bitbucket.org/jtsnake/ask>)).  In the app, we have what is basically an FAQ.  Previously on the Internetz somewhere, I saw a fun FAQ where two people answered every question and almost the most fun thing for me was comparing the answers of the two people to one another.  The difference in their answers was often humorous and entertaining in addition to answering the question.  The questions were also often ridiculous.  This seemed like a fun format, so I asked my friend, [Steve](http://rockycode.com/blog/author/steveo/) to answer a few questions with me, and we created the app.  Techs:

- [Jquery](http://jquery.com/)
- [Jquery Templates](http://api.jquery.com/category/plugins/templates/)
- [Sammy.js](http://code.quirkey.com/sammy/)
- [django-piston](https://bitbucket.org/jespern/django-piston/wiki/Home)
- [Django](http://www.djangoproject.com/)

On the backend, django-piston allows us to easily define handlers for the data that we want to expose through a RESTful API.  We define the urls to get to the handlers at, and boom!, we have json-flavored data being queried by Django, and displayed to requesters at the defined urls.

From here, we're very client heavy.  

Jquery Templates
--------------------

Jquery gives us an easy api to $.get() the data that we want.  We use Jquery Templates to do what Django templates may normally do for us:  Apply markup to our dynamic data.  With Jquery Templates, the server can send almost-raw data and the client, which seems to be a naturally fitting place for presentation transformation anyway, can now be fully in charge of what markup data should be displayed within.

Sammy.js
------------

We also used just a portion of Sammy.js, the routing feature, to take care of the controller logic.  I like the Sammy.js routing for the same reason that I like the Django urls.py routing: it's very imperative, which I feel is elegant:  "Here's my url pattern, and here's the logic that goes with that."

Why SOUIT
-------------

[SOUIT](http://souit.org/) = Service-oriented User Interface Technology.  Why would we want to create an app like this?  Doesn't Django have the ability to do this all for me -- url routing, templating?  It does.  But that doesn't mean that it wouldn't be more fitting to have this happen elsewhere, if only partially.  Since browsers are becoming beefier and more capable of handling client side transformations like templating and with tools like Jquery and Sammy that make request and response routing very clean, why not try it there?  Throw in the requirement of "asynchronous"ity, and you may just be happy you have the ability to do all this on the client.  And it's cool -- worth an additional 5 points.  Plus, now that our web client is essentially a single-page app with all the smarts it needs to function, we can consider different backend technologies too.  Hmmm, a database that exposes its data through mere REST APIs?  CouchDb, maybe?

What do you think?  This example 'ask' application is definitely not extremely compelling, but what are the best uses of this particular client-heavy technology stack that you can think of?

Jquery, Ajax, Json, Django -- this is quite a laundry list of technologies.  In fact, it's pretty much the whole stack.

Jquery, Ajax, Json on Django

Here is a "new and shiney" presentation for running Django on Jython.  It's based on my experiences with the <a href="https://wiki.python.org/jython/DjangoOnJython">DjangoJython tutorial</a>.

As is discussed in the slide deck, and hence the subtitle of the presentation, much could be helped by more careful reading of documentation.  Well, moments ago, I decided that I hadn't checked out django-jython 1.1.  Well.... turns out many more problems could have been helped by using this later version.  Sweet!



<iframe src="https://docs.google.com/present/embed?id=dcsq834g_86dgfnbkdg&size=m" frameborder="0" width="555" height="451"></iframe>

Here is a "new and shiney" presentation for running Django on Jython.  It's based on my experiences with the <a href="https://wiki.python.org/jython/DjangoOn

Django on Jython Intro

At Sort 2009, a technical conference at the LDS Church, I gave a presentation on my favorite all-in-one web framework, Django.  It's a great tool, and here's a look at the slides produced to accompany my presentation.  Also, checkout bitbucket for the <a href="https://www.bitbucket.org/jtsnake/hymnorganizer">source code</a> for the demo project.



<iframe src="https://docs.google.com/present/embed?id=dcsq834g_62fspdmdgk" frameborder="0" width="410" height="342"></iframe>

At Sort 2009, a technical conference at the LDS Church, I gave a presentation on my favorite all-in-one web framework, Django.  It's a great tool, and here'

Django Intro Presentation

django-admin.py is a utility script that is used by django to start projects, etc.  Sometimes, it seems that it's available to me in the terminal.  At other times, it melts away, unavailable.  So, where is it, and how do I make it findable?



django-admin.py is in the your site-packages/django/bin/ directory.  And that brings up another good point.  Where is your site-packages directory specifically?  You can find it with this command:

```bash
python -c "from distutils.sysconfig import get_python_lib; print get_python_lib()"
```

Once you find the site-packages directory, go to the bin/ subdirectory to find the django-admin.py.  You just need to put this in your path so that it's findable from wherever you need to use it.  Here's a possibility:

```bash
cd /usr/local/bin/ &&
sudo ln -s [site-packages]/bin/django-admin.py django-admin.py
```

django-admin.py is a utility script that is used by django to start projects, etc.  Sometimes, it seems that it's available to me in the terminal.  At other

Find django-admin.py

In software development, be <a href="http://en.wikipedia.org/wiki/Don%27t_repeat_yourself">dry</a>, and define data once.  But, what if that data needs to be used in many places?  This is the case with parts of a web page, for instance, that are common to many different pages.  Django has a great mechanism for this: it is context processors.



You can define a context processor, containing within in the things that you would like to be present and available for use within the given context.  There are two ways that I've found to include context processors: Per request or for all requests.

#### Per Request

Pass the context processor into the request in your view.py:

```python
from aj2 import context_processors as cp

def content_collection(request, slug):
  return render_to_response('content/content_list.html', locals(),
    context_instance=RequestContext(request, processors=[cp.content_common]))
```


That means that when the content_list.html template is loaded, all content_common variables will be available in that template context.  Those variables are:

```python
from aj2 import util

def content_common(request):
  return {
    'default_theme' : util.get_default_theme(),
    'friends': util.get_friend_list(),
    'fp_highlight': util.get_random_fp_highlight(),
    'collections': util.get_collection_list(),
  }
```

#### For All Requests

Sometimes you don't have absolute control of all the views in your project (ie, plugins).  So, what if you want to apply the context processor to those views as well?  The best way that I've found is by including the context processor definition in the settings.py file:

```python
TEMPLATE_CONTEXT_PROCESSORS = (
  'aj2.context_processors.content_common',
)
```

Glory, glory, django.

Just make sure that you put the auth context processor in with the TEMPLATE_CONTEXT_PROCESSOR entries that you're adding, otherwise you'll get this message:

```bash
ImproperlyConfigured at /admin/

Put 'django.core.context_processors.auth' in your TEMPLATE_CONTEXT_PROCESSORS setting in order to use the admin application.
```

Context Processors Put Content On Multiple Pages

The amount of content on the blog and its pages has become substantial (in length only) enough to make it a worthwhile idea to paginate it (spread the content over multiple pages).  Django makes it very easy!  There are some nice objects available for paginating.



The amount of content on the blog and its pages has become substantial (in length only) enough to make it a worthwhile idea to paginate it (spread the content over multiple pages).  Django makes it very easy!  There are some nice objects available for paginating.

First, query your objects, and put them into a Paginator object that gives you some paginatory functions. (How many times do you think I can use a form of paginate on this page?).  I query mine, then use a util function to put them into a paginator:

```python
# in view.py
from aprilandjake.blog import util

def home(request):
	entries = util.paginate(request, Entry.objects.filter(active=True).order_by("-date_created"))
	# ...


# in util.py
def paginate(request, obj_list, num_per_page=10):
	paginator = Paginator(obj_list, num_per_page)
	try:
		page = int(request.GET.get('page', '1'))
	except ValueError:
		page = 1
	try:
		objects = paginator.page(page)
	except (EmptyPage, InvalidPage):
		objects = paginator.page(paginator.num_pages)
	return objects
```

<strong>Note:</strong>
<ul>
<li>You can pass your result set straight into the paginator.</li>
<li>I've defaulted the results per page to 10.</li>
<li>The first try/catch is to make sure that the page number is an integer.</li>
<li>The second try/catch makes sure that the page number doesn't go out of range</li>
</ul>

You'll have to change your iteration of your object in your template to look for the entry.object_list.  That is because your object is really a paginator object now.
```python
{% for e in entries.object_list %}
	{{ e.stuff_to_print }}	
{% endfor %}
```

Finally, we have to put the paginator UI on the page.  Again, we can use the paginator object's very nice functions to help us here.  Because I want to reuse this pagination control and use it on many different objects, I'm going to make an inclusion tag for it:
```python
# in my template tags file: blog/templatetags/aprilandjake_tags.py
from django import template
register = template.Library()

def paginator(object):
    return {'object': object}
register.inclusion_tag('includes/_paginator.html')(paginator)
```

To use it, load the custom tag for your template, place it where you want your pagination controls to appear, and pass in your object collection:
```python
{% load aprilandjake_tags %}

{% paginator galleries %}
```

The included html (_paginator.html) is thus:
```html
{% if object.object_list %}

<div class="pagination">
	{% if object.has_previous %}
		<a href="?page={{ object.previous_page_number }}" class="prev">&laquo; Previous</a>
	{% endif %}

	<span class="current">
		Page {{ object.number }} of {{ object.paginator.num_pages }}
	</span>

	{% if object.has_next %}
		<a href="?page={{ object.next_page_number }}" class="next">Next &raquo;</a>
	{% endif %}

	<div class="clr"></div>
</div>

{% endif %}
```

<strong>Note:</strong>
<ul>
<li>The check for object.object_list is just precautionary for if you have this inclusion tag included on a page that isn't actually using a paginated object.</li>
</ul>

To me, it's amazing how awesome this pagination object is that is built into django.  With a few quick and easy changes, pagination is added with very little pain to us.  w00t!  Go, Django!

The amount of content on the blog and its pages has become substantial (in length only) enough to make it a worthwhile idea to paginate it (spread the conte

Django Pagination

I really need an answer to this question.  Why?  Because I was, until recently, on the verge of shutting down the comments on the site because of the load of blog spam that I was receiving.  It was insufferable.  But, luckily, Django came to my rescue again and made a potential solution very pain-free -- except for one problem.



My friend Josh introduced me to a good little captcha for Django: <a href="http://django.agami.at/media/captcha/">Captcha for Django 1.1</a>.  There are several other captchas out there: <a href="http://code.google.com/p/django-captcha/">Djaptcha</a>, <a href="http://www.mysoftparade.com/blog/mathematical-captcha/">MathCaptchaForm</a> and some good <a href="http://www.rkblog.rk.edu.pl/w/p/django-and-captcha-images/">tutorials</a>.  But, I like this captcha solution for a couple reasons: 
- Josh suggested it, and let's face it, that carries a lot of weight. ;)
- This solution jives well with ModelForm, which I use for all of my comment forms.  Most of the other code that I found was for forms.Form.
- This solution favors composition over inheritance:  It is a form field instead of a subclass form type.

You can download the tarball <a href="http://django.agami.at/media/captcha/captcha.tar.gz">here</a>.  Also available <a href="http://code.google.com/p/django-captchas/source/browse/trunk/captchas/imagecaptcha.py">here</a>.

A short explanation of the file is available <a href="http://django.agami.at/media/captcha/">here</a>.

The explanation prompts you to unload the tar into the django.contrib directory.  I'm thinking this is probably how things used to jive in Django Land, but I didn't put it there and just put it in my project.  site-packages might have been a better place.  

You can attach the captcha field to any model form by just including it in the class:

```python
from django.newforms import ModelForm
from aprilandjake.captcha import CaptchaField

from aprilandjake.blog.models import EntryComment
	
class EntryCommentForm(ModelForm):
	class Meta:
		model = EntryComment
		exclude = ('active', 'entry')
	captcha = CaptchaField(label='Captcha', options={'fgcolor': '#0099ff', 'bgcolor': '#efefef' } )
```

Also seen are just a few of the many options for the CaptchaField.  You can apply these for every captcha field you write or globally in settings.py:

```python
CAPTCHA = {
        'fgcolor': '#000000', # default:  '#000000' (color for characters and lines)
        'bgcolor': '#ffffff', # default:  '#ffffff' (color for background)
        'captchas_dir': None, # default:  None (uses MEDIA_ROOT/captchas)
        'upload_url': None, # default:  None (uses MEDIA_URL/captchas)
        'captchaconf_dir': None, # default:  None  (uses the directory of the captcha module)
        'auto_cleanup': True, # default:  True (delete all captchas older than 20 minutes)
        'minmaxvpos': (8, 15), # default:  (8, 15) (vertical position of characters)
        'minmaxrotations': (-30,31), # default:  (-30,31) (rotate characters)
        'minmaxheight': (30,45), # default:  (30,45) (font size)
        'minmaxkerning': (-2,1), # default:  (-2,1) (space between characters)
        'alphabet': "abdeghkmnqrt2346789AEFGHKMNRT", # default:  "abdeghkmnqrt2346789AEFGHKMNRT"
        'num_lines': 1, # default: 1
        'line_weight': 3, # default: 3
        'imagesize': (190,55), # default: (200,60)
        'iterations': 1, # default 1 (change to a high value (200 is a good choice)
                         # for trying out new settings
                         # WARNING: changing this value will lead to as many images in your
                         # "captchas" directory!)
        }
```

When I implemented this for aprilandjake.com, Josh helped me out and showed me where the code needed to be tweaked:  On line 174:

```python
def value_from_datadict(self, data, name):
```

was changed to

```python
def value_from_datadict(self, data, files, name):
```

Voila!  It worked like a charm.

But then I uploaded it to my server and tried it out -- no dice.  I couldn't figure it out.  A couple days later, I was determined to find the problem...  After a frustrating while and some good 'ol debugging print statements, I determined that the problem was that because I put my project under version control and didn't bother to remove .svn folders from production, they were being pulled in by the captcha code, thinking it was an option for a font in the 'fonts' subdirectory of the module.  To get around the problem, I needed to change the code around line 110 from:

```python
fontdir = path.join(cs['captchaconf_dir'], 'fonts')
fontnames = [path.join(fontdir, x) for x in listdir(fontdir) ]
```

to

```python
import glob
/** ... */
fontdir = path.join(cs['captchaconf_dir'], 'fonts', '*.ttf')
fontnames = [path.join(fontdir, x) for x in glob.glob(fontdir) ]
```

Using the wildcard *.ttf protected against using non-fonts in PIL as ImageFont objects.  listdir() doesn't support wildcards, so glob.glob() was required.

Take that, spam!

I really need an answer to this question.  Why?  Because I was, until recently, on the verge of shutting down the comments on the site because of the load o