Django Eadred gives you some scaffolding for generating sample data to make it easier for new contributors to get up and running quickly, bootstrapping required database data, and generating large amounts of random data for testing graphs and things like that.

For v0.2, I added some helper methods for generating names, email addresses, sentences and paragraphs. It's definitely the case that these helpers won't handle all use cases, but I think they'll help specific ones.

There are no backwards-compatability problems with v0.1.

To update, do:

pip install -U eadred

• docs: django-eadred.readthedocs.org
• pypi: http://pypi.python.org/pypi/eadred/0.2
• github: https://github.com/willkg/django-eadred

I work on a few projects that had a need for generating sample data to make it easier for new contributors to get up and running quickly with little effort. These projects are fairly data-driven---they're kind of useless without data.

To satisfy that need, we wrote an app in richard to generate sample data across all the other apps in the project. Then I rewrote it for input.

Then we had a hankering for it in SUMO, plus I thought it made sense to turn it into its own app. So I spun it out into its own project.

Thus django-eadred was born.

Generally, it allows you to define a sampledata.py module with a generate_sampledata function that takes command line options to generate sample data for any app you want to generate sample data for.

You can use it to define different ways of generating sample data specified by the command line.

You can use it to generate random data, non-random data, initial data, data for contributors, sample data for large data sets, fixture data, etc.

Check out django-eadred.readthedocs.org for use cases, documentation and project details.

I'm in the process of passing off maintenance to a few people who expressed interest on the pyblosxom-devel mailing list. Towards that goal, I've moved pyblosxom to a new github repository under the pyblosxom organization. Thus it's now at:

https://github.com/pyblosxom/pyblosxom

I then forked it, so you can continue looking at my fork if you so desire, but I probably won't be doing anything with it going forward.

I've been working on Pyblosxom since January 9th, 2003. The initial commit from Wari is on November 24th, 2002. I discovered that (according to the commits), I was the second person to commit to the codebase. I didn't know that.

In January of 2012, I started a hiatus from Pyblosxom. We had done a ton of overhaul work for 1.4 and 1.5 and I was tired and wanted to work on other things.

I've decided it's time to end my reign as maintainer of Pyblosxom. I sent an email to the pyblosxom-devel list as such. Further, I contended that maybe it's time for the project to end altogether.

Yes, I suggested maybe it's time to end the project. The reasons are two-fold:

1. The code has a ton of technical debt. There are a lot of plugins that need a lot of help. There's a lot of squirrely code. I've done a poor job of fixing the "Where can I find plugins?" and "Where can I find pretty flavours?" problems. Those are big problems and potentially require a lot of maintenance.
2. It's really hard to fix architectural problems with Pyblosxom without changing the scope of the project. I contend it's way easier at this point to just start a new one.

Anyhow, I'm a little sad and I'll have to figure out what to do with my blog, but I think it's been a long time coming and it feels good to put it to rest.

So, two things:

1. If you're interested in maintaining Pyblosxom, hop on the pyblosxom-devel mailing list and say hi!
2. I cut a lot of my teeth on this project. Most of the current problems are my fault. If you're a current user of Pyblosxom, thank you for using something I spent a ton of time on and cared very much about and thank you for your patience as I figured a lot of things out.

On to new horizons!

A few months ago, I "took over" maintenance of elasticutils. We use it in SUMO as the API for building search queries with elasticsearch.

One of the first things I did was spend some time figuring out whether we should keep working on elasticutils at all. django-haystack also provides a django-ish API for working with elasticsearch. Why have two libraries that at a high level do the same thing?

The thing is that they're not exactly the same. django-haystack is really great and supports a variety of backends for search, elasticsearch being one of them. Right now, it only has support for elasticsearch in 2.0 which is in either an alpha or beta state now (their web-site could use some updates). However, because it supports a bunch of backends, it only supports functionality that works across all of them.

elasticutils, on the other hand, is elasticsearch-specific. As elasticsearch adds functionality, we can, too. That's the compelling reason to keep working on this library. However, django-haystack has some awesome ideas that we'd like to implement in elasticutils, too. This will fix some sharp edges in elasticutils, but also make it much easier for projects to switch from one to the other.

Currently, elasticutils only handles the query side of things. django-haystack handles that, but also has an API for defining mappings, indexing, and all the other things you need with a search system.

Thus, Rob Hudson and I are going to embrace and extend elasticutils to:

1. fix the current situation where it seems every elasticutils user is actually using their own branch with additional functionality in it (ew!)
2. implement the rest of the things you need with a search system
3. document the things we've learned while working with elasticutils because at a minimum, it seems most of the Mozilla projects that use elasticutils bumped into, spent time on, and solved the same problems---that's a huge waste of time and a failure on my part

One of the things users of a library need is for the library to be a mature project with releases, tagged version, documentation, tests, stability, reliability, reproduceability, communication, community and all that. Thus, I'm also going to spend some time to turn this into a real project. Towards that end, I created #elasticutils on irc.mozilla.org where we'll talk dirty elasticutils stuff. If we end up with more people pitching in, we'll create a mailing list. But for now, IRC will do.

My next step is to spend a little time cleaning up what's in the master branch, then tag and release a baseline version.

After that, I'm going to spend time identifying, thinking about and merging in the divergent functionality in the various branches while Rob works on continuing his imperative mapping work.

I think in a couple of months, we'll be in a better place and that'll make it easier for Mozilla projects and anyone else who wants to use elasticutils to use and contribute to it.

If you're a user of elasticutils, please come hang out with us! Let us know how we can better help you.