On Schwern

For those who have not heard, Schwern was arrested recently for domestic violence. I have no comment on the charges - I don't know what happened. AND NEITHER DO YOU.

My heart goes out to the victim (whom I will not name). Her experiences must have been terrifying and I'm glad that she is safe now. She has a huge amount of support, support many victims of domestic violence never receive.

What I do know is this:

1. Domestic violence is horrific. It's something that should never happen and must be stamped out.
2. If Schwern did do the crime, he should do the time. Hard time.
3. The Perl community, at least the several hundred people I've known over the past 10+ years, do not condone this sort of behavior. And, yes, I feel very comfortable speaking for all of them.
4. Schwern, for all of his faults, has done many good things to increase gender diversity in the many OSS communities he has been a part of.

Like all of us, he is not black or white. He is a three-dimensional person, with greatness and horrible flaws. Every single person who reads these words has done things they are deeply ashamed of. Knowing him, I'm sure Schwern, a decade from now, will deeply regret his actions and choices of the past few days.

THIS DOES NOT EXCUSE HIS ACTIONS, NOR AM I APOLOGIZING FOR HIM.

I only hope and pray that people do not throw the baby out with the bathwater. Schwern is a brilliant developer whose contributions to Perl were a small, but key, part of how the Web was won. He's also a troubled man who, like all of us, occasionally makes horrible decisions. And before you say "Well, I'd never do that!", you probably have done something else equally horrible in another arena. Imagine how you'd feel if all your secrets were out.

So, if this episode leads you to change your behavior in any way, let it be one of these:

1. Give support to someone you know who's dealing with shit. You never know when you might save a life.
2. If you know a batterer, report them. You might save a life.
3. Public shaming never helped anyone. Ever. Don't do it. It's a form of abuse.

Release of DBIx::Class::Sims

(xpost from the DBIx::Class mailing list, with formatting)

Announcing the initial release of DBIx::Class::Sims. This is a schema extension that allows you to sanely and easily generate good-looking and legal test data, only specifying the actual rows you care about in your test and letting DBIC figure out the rest. (Repo is https://github.com/robkinyon/dbix-class-sims)

Let's assume you have a standard Artist->Album->Track schema where Artist->has_many(Albums) and Album->has_many(Tracks).

my $ids = $schema->load_sims({

    Track => [

        { name => 'Hello, Dolly' },

        { name => 'Moonlight Sonata', album.artist.name => 'Beethoven' },

    ],

});

That will do exactly what you think it should do. It will generate a randomized artist with a randomized album that has a single track called "Hello, Dolly". It will also generate another artist with a name of Beethoven who has a randomized album that has a single track called "Moonlight Sonata". All other columns will be randomized.

The return value $ids will be a hashref that will look something like:

$ids = {

  Track => [

    { id => 1 }, { id => 2 },

  ],
};

Corresponding to the rows in the tracks table that you requested to be created.

Now, if someone goes ahead and adds a Studio table and Studio->has_many(Albums) (because artists create albums in studios, but don't always stick to the same studio), then your test doesn't break and it doesn't change. At all. For each album that's created, a randomized studio will be generated. Because you didn't specify anything, the same studio will be used for every album. (Remember - your test is about tracks, so you don't care if the same studio is used.)

If, for some reason, your application requires that all artists have at least 2 albums to be legal, that's easily specified as well.

my $ids = $schema->load_sims(

    { Track => [ {} ] },

    { Artist => { albums => 2 } },

);

The randomization part comes from the sim types. You can add the type to each column and a reasonable-looking value will be generated instead of the default_value. Right now, the only type that has been written is us_zipcode. More will be forthcoming and you can release your own CPAN distribution with types if I'm too slow in adding them.

As with everything else DBIC-related, patches are welcome (as pull-requests on github) and discussion is on this mailing list or #dbix-class in IRC.