First off, the latest release adds DBIx::Class::Candy exports. So if you are using DBIx::Class::Candy to define a result, certain methods will be imported into your namespace. For example, DBIx::Class::Helper::Row::SubClass will export a subclass subroutine into your module. Not huge but nice nonetheless.

Next up, we have four shiny new components. Two are ResultSet components and two are Result components. One of the two ResultSet components was originally going to be in the core of DBIx::Class, but I decided to make a helper first to ensure that we iron out the details before we release it in core. That component is DBIx::Class::Helper::ResultSet::RemoveColumns. It does exactly what it sounds like. With it you can do

and the id column will no longer be selected in your ResultSet. I am sure that it has some quirks, but I am not sure what they would be till people use this. So have at it!

The next component, DBIx::Class::Helper::ResultSet::AutoRemoveColumns, is based upon RemoveColumns. Again, the name should make it clear what it does. Currently it removes typically large columns by default, like text, blob, and the like. See the docs for exactly what it removes. (Note: later on I hope to add a component that adds lazy columns as detailed in ovid’s post here. Ovid if you are reading this I can’t comment on your blog.)

Next up is a fairly simple component, DBIx::Class::Helper::Row::StorageValues. It gives you access to the last known stored value of a column. For example:

Building upon that we have my favorite new component: DBIx::Class::Helper::Row::OnColumnChange. This module adds powerful hooks for calling methods when a column has been modified. If you enable StorageValues for the column you hook into you get to look at the old value and the new value, which is pretty cool. There are three hooks: before_column_change, around_column_change, and after_column_change. It automatically takes into account values changing because of accessors as well as by the arguments passed to update. Also note that it allows you to tell it to wrap the call to update and the column change method in a transaction so that you can safely do things to other tables in the method. Anyway, enough talk, here’s a small example:

So basically if relationship status changes from apart to togehter the significant other gets marked as happy, and all of this is done in a transaction, which is pretty awesome.

Anyway, hopefully this makes your job easier. Have a good Friday!

To sum up the previous paragraph: I need to learn to use git-svn. Lets get started:

First off, you need to make a users file. At my company that’s pretty easy since there are like, 12 people who have commit access to svn. This is what it looks like:

Put it in a file named “users” in the current directory. All this does is substitute the svn names (on the left) for the git names (on the right.) Next up, check out your repository:

This assumes that /foo/bar has subdirs /trunk, /branches, and /tags. If yours is different you’ll want to do something like the following:

Of course you might need to do some tweaking there.

Now, we have three other svn:externals repositories in our repo. This is the most ghetto part of all of this, and it’s probably just because I haven’t done the appropriate research. Again, if you know better, just tell me. (Normally with git you’d do this with a submodule, but we aren’t going to do that because we want to directly check the “submodule” out from svn so we can commit back easily. If you don’t know what a submodule is, ignore this )

This will check out the svnexternal1 repo to a folder called $to_name. If you need to check it out to a separate subdir either cd into that dir or change $to_name.

You don’t want to check that into svn because your coworkers already have an svn:externals for that. Normally this would be done with .gitignore, but we won’t use that because your coworkers don’t want a .gitignore file in their repository. Instead you’ll use .git/info/exclude, which is the same thing but not inside of the repo. Just put $to_name on a single line in that file and it won’t show up in your available changes when you need to commit.

Speaking of commiting, how do you commit? Normally your workflow should be the way it is with git. You commit often and when you are ready for a feature to go to the team you push it out. I usually rebase and clean up commits before I push, but that’s up to you. The main difference is that you don’t do git push … Instead you’ll do

git svn rebase actually checks out the new changes from svn and puts them in your repository before the changes you’ve already committed. If there are conflicts you’ll have to deal with those of course, but otherwise it will just pull in the changes and then use dcommit to submit new changes. You should not have any uncheckedin changes when you do this (it will complain if you do) because dcommit actually does a different kind of rebase after checking in changes. It changes your commits to include the svn id so that the git commits match up with the svn commits.

In general that’s all there is to it. At some point I’d like to do a post about how I use git rebase fairly often in my workflow, but this I think is a lot more important. Oh and here are some cool new git features I learned today. Enjoy

If you did not already know, Devel::Dwarn is sugar + good defaults for Data::Dumper. Check it out. Drool. Use it.

Anyway, I figured the new changes were worth mention on the internet, so here goes:

First off, Dwarn now pays attention to list context, so in list context it uses the original behavior, but in scalar context it does what DwarnS does. One of my coworkers got bit by the Dwarn vs DwarnS distinction so much that he only uses DwarnS now. Hopefully this will remedy that issue.

Next up is that Dumper (and also Dwarn because it uses Dumper) no longer returns an object when passed zero arguments. If you used that I’m sorry; but it just bit most of us when we tried Dwarn(@foo) and @foo was an empty list. Sorry, it’s gone!

Last, is the brand new DwarnN. DwarnN is a neat debugging tool which will label your output by the variables passed in. So if you do DwarnN $foo it will print ‘$foo => ‘ . Dumper($foo). Not world changing, but still very helpful!

Hopefully this will ease your job that much more!

I am proud to announce the initial, development version of DBIx::Class::Candy, which should be coming to a CPAN mirror near you very soon. If you just can’t wait, use cpanf to get it right now. The basic gist of it is that you can use:

instead of

There are a few other features, like having it turn on 5.10 or 5.12 features, use a non standard base, and more. Check it out now!

I also did a talk on DBIx::Class::DeploymentHandler. I am a little frustrated with how this talk went down. I am confident that DBICDH is an excellent piece of software that can do some really cool things and I kinda botched the end of the talk (very abrupt.) I wouldn’t call the talk a failure; it had a great turnout and at the very least I got to discuss features with jnapiorkowski, which was fun.

My third talk was about DBIx::Exceptions. It was hard for a couple reasons; first off DBIE isn’t actually done yet. That certainly is not conducive to talking about something. Second, what it ultimately does really isn’t that complicated. The module is almost entirely a function of doing some research. So while I think that the subject is good and interesting, I don’t think it warrants a whole 40 minute talk. I actually had a long discussion with Rob about exceptions in general and he strongly supported the point of view that exceptions in any language are fundamentally flawed. I’ll turn that into a blog post at some point.

I finished all three of the talks in less than forty minutes; I think that was a combination of me talking too fast (DBIC + DBICDH) and not actually having enough content (DBIE.) I would have done better were I less nervous, which should be less and less of a problem as a I practice technical speaking more. I actually did a lot of presentations in college and rarely had these issues, but in college I almost never spoke about software I wrote and my talks were usually from 10 to 20 minutes long. Another thing that I feel is important is that I need to try to add humor to my talks. The talks that are the most engaging are also the ones that are entertaining. I’m not sure I how I could work in jokes etc, but I need to try to do that next time.

In other news, I’m pretty worn out in general from YAPC. I just need a break. So while I will do bug fixes and whatnot for my existing modules, and I still hope to release DBIx::Exceptions very soon, I’m going to try to chill out for about a month before taking on any of the other large ideas I have in mind for the future. Or at least I won’t start them on purpose

Day 1

Not Quite Perl (NQP) A lightweight Perl 6

I can’t help but follow this since I see Patrick fairly regularly in our Dallas.p6m meetings; which is really half Perl 5 and half Perl 6. NQP is an amazing bootstrapping language for Perl 6 that is actually already self-hosting (written in itself!!!) and can do a lot of neat things. And of course Patrick is an excellent and humble speaker, which always helps.

Take a look at the slides (linked to above, page up and page down for next and prev slides) for more information.

For a language as minimal as they could get away with it’s extremely pretty. Note: For all the talks mentioned here, slides != talk.

Plack – Perl web framework & server superglue

Plack is very cool tech, even though Perl is late to the concepts it brings us. The cool thing about the talk was that it starts off really slow and then ramps up to some really amazing middleware that just blows my mind. Miyagawa was an excellent speaker and had lots of fun little jokes in his talks too.

Fey and Fey::ORM

I was told to go to this talk by ribasushi with the sole idea of stealing ideas for DBIx::Class. I was generally unimpressed with the ORM part, but Fey is far better than SQL::Abstract it seems like. Rolsky is very adamant about having no magic in his core, which is fine, but it typically means baseline code will be ugly. It’s certainly a trade off. He has a really cool autojoin feature, which I envy but also know that ribasushi already wants to implement that to an extent. Our $rs->as_query is cool, but he has something like that for EVERYTHING, which yields some interesting results. Of course this is due to his thoughts that pretty stuff belongs in a sugar layer. He has much more powerful relationships, which I envy for now but I also know that we have a branch in progress to give us arbitrarily complex (???) relationships. It seems like he has a global schema, which is too bad, but that’s just how things work sometimes. He wants to keep per db stuff out of the core, which I can certainly see being a good thing, but I also think it’s good that we try to keep all of our per db code up to snuff, so theres a tradeoff there.

Overall I thought rolsky was very honest about the fact that Fey (and Fey::ORM) is about doing things differently due to taste and that’s completely fine. I definitely envy his SQL generation code, but I’d rather SQLA2.

Lightning Talks 1

A/B testing with Perl‎

Look around at some docs on AB testing. The stuff they did with this was amazing. Forget hallway testing. This is where it’s at for usability.

perlopquick – a quick reference for Perl 5 operators‎

Ever want to look up how //= works? Not easy. Check out perlopquick. Awesome stuff for the future of core docs.

Day 2

Perl for CS Grad Students

For this talk I have to give a little bit of background. This year it was attempted to film every single one of the talks unless the speaker explicitly said not to. Cameras et al were paid for by the conference’s budget. Of course, cameras are not all you need. You also need someone to run the cameras. It turns out that ONE MAN (his name is Krishna) did ALL of that for all five tracks. Of course the videos won’t be perfect, but if this becomes a trend it would be a great thing for all of perl.

The speaker of this talk, like probably 33% of all the speakers in general, had technical difficulties getting his mac to work exactly how how wanted with the projector. He (reasonably) got frustrated at this and the wasted time it caused. What bothers me is that krishna was setting up the camera (and mic) as he did in every room every morning and walt said, “Why are you even here?” to krishna, presumably thinking that he was staff of the college (which is of course a great reason to treat a person poorly) and continued to lash out complaining about his technical difficulties. I guess to put a positive spin on this I got to know krishna better for it and I think we all owe him a beer or curry or whatever for all of his hard work (and apparently taking abuse) for doing WAY too much A/V for one person.

The talk was ok.

Iron Mad: The Iron Man Forfeit Talk‎

This was mst’s Iron Man forfeit talk. Watch the video, it’s hilarious. I’m not sure much more can be said

perl5i: Perl 5 Improved‎

I heard about perl5i last year and I thought it was neat. Now I think it’s excellent enough that I might use it in code at work. One thing I think is very good about it is the fact that you must use a version number when using the module, because it is expressly backwards incompatible. Take a look at the module. Very fun.

Lightning Talks 2

Reframing the Death of Perl‎

This basically looked at the psychological term called “framing.” The gist of the talk: when you say “Perl is not dead” people see “perl is dead.” So instead you have to completely reframe and say “Perl is alive” etc. We ended up all yelling perl is alive and scaring prospective students that were visiting Ohio State. Awesome.

Musical Intervals and Chords

This was a talk by ology about (duh) music. Very cool stuff. I wish I could have talked with him more than I did for the few minutes that I did, and especially I wish I had discussed the music stuff with him. Unfortunately he ran out of time in his talk, but what he did say was getting very cool

How I mastered English with Perl

This was a hilarious talk by a man who moved to the US from Japan and learned some english with perl. It focused on Lingua::EN::Inflect, using CPAN as a dictionary, and adorable daughters.

Auction

Not really a talk per se, but still a fun time. Apparently the auction usually takes hours, but this only took 1.5 hours, so not really that bad, and still a lot of fun. I got some O’Reilly coasters (beer mats for you brits) and wes got the new Effective Perl book + autographs. Very cool.

Day 3

Path::Dispatcher

This talk was interesting in structure. It started off fairly slowly but got super cool as it built on itself. It made me want to start writing CLI apps. The fact that it yields such a nice API makes it hard for me to justify why I like the way that catalyst does it’s dispatching (all spread out) but I do think that different ways of doing things are valid. I would love to write some kind of text adventure game with this. Maybe I’ll use it to create a Perl tutorial game?

Cool Perl 6 you can do today

Again, this was Patrick. This talk makes me want to start writing my one off scripts in Perl 6. Unfortunately some of my more interesting “one off scripts” involve creating a DBIC schema and shoving data into an sqlite database so that I can get a feel for my data. Either way, check out the slides, very cool stuff. Also note: I downloaded and installed rakudo in the talk and actually played with it. It’s been a while since I’ve done that and I assure you it’s only gotten easier.

All in all it was a great conference. I liked it better than last year despite the stress of three (supposed to be) forty minute talks. I’ll discuss that in my next post

Major features this has over DBIx::Class::Schema::Versioned:

• Multiple files for migrations
• Perl files in migrations
• Shared Perl/SQL for different databases
• Downgrades
• Not to mention extreme customizability

So try it out today! I am looking forward to getting bug reports soon

Oh also, if it does not quite do what you want…

PATCHES WELCOME!

I am so happy to announce that DBIx::Class has migrated to git!

If people latch on well, this should benefit is in a number of ways. The first thing is that most people should appreciate is the ability to check in to source control without needing to commit to the remote repository. Not only does this make things way faster, it also means that you can work sanely offline. A lot of people did this before with SVK, but SVK is slow and a hassle (I think) to install and setup.

Another thing that this should help is our history. I don’t mean to point out a specific person, I did this all the time with svn (it’s just the nature of the beast,) but take a look at some of these commit messages. The SVK merge messages are pretty obnoxious, but that’s not what I’m referring to. The ones that bother me are the: “Oops,” “Typo,” “Thinko,” etc. With git those can be cleanly squashed into another commit. In fact, I would recommend cleaning up your history before you push every time. This is how I do that:

That will rebase your current branch (all of it) onto master, and give you an editor that will let you fix commit messages, merge commits, and more. If people do not do this I fully intend to do it myself before I merge a branch in, if I do. And that brings me to the next point which we shall discuss.

Workflow

We toyed with the idea of setting up git such that everyone would just use github or gitorious or whatever and ribasushi and I would be in charge of merging remote branches into the DBIC master, but mst veto’d the idea in favor of a more communal approach. Basically the workflow we will use looks like the following:

1. Get a commitbit (liberal policy)
2. Clone the repo (dbsrgits@git.shadowcat.co.uk:DBIx-Class.git)
3. Make a topic branch based on what you are doing, do work on it, whatever
4. Push branch to repo
5. Ask a fellow DBIC’er to review the branch, that includes me, ribasushi, Caelum, and really anyone else with a commitbit
6. If the reviewer thinks everything is sane, the reviewer will merge the branch in; to be a bit more clear, you should not merge your own branch into master, that is the reviewer’s job
7. Delete your branch locally and remotely after everything is merged in, and work on other stuff!

A note about merges, don’t merge master into your branch. It makes for yucky history. Instead, rebase your branch onto master. Currently the thought is that anything except for master can be rebased. Of course if you and another dev are working in the branch you might want to keep that to a minimum, but at the very least you should be rebasing to squash silly commits before you push, and then when you do the final merge into master you should rebase first, so that history remains sane. Of course, the best time to rebase to fix silly history is before you push, and the best time to rebase to make it so that you are fastforwarding master is right before the final merge, so try to only do that then.

At some point I plan on writing a DBIx::Class::Manual::Contributing in the spirit of Moose::Manual::Contributing, but ours will be significantly more lax. In the meantime, just swing by #dbix-class, get your commitbit, and help out!

The Problem

In the Perl community, numerous important git repositories are hosted at shadowcat, but of course if you went to that url you would not be able to see all the work that I have spent on each of those projects. I like the fact that github has a nice concise view of my work.

The Solution

The following is an example of a section from my .git/config in my DBIx-Class-DeploymentHandler:

This lets you push to origin, github, or all. I tend to only pull from origin and push to all. Hopefully this can at least be a reference for people

Recently a certain member of the community has posted a few blog posts that boil down to “Open Source developers should support their open source work as if it were a job.” I will not make a link because I would rather people not read his posts. Normally I feel like the best plan of action for people who make silly statements is to just ignore them, but a good friend of mine pointed out that it would be bad if people got confused and actually bought into this line of thought.

So in foolish manifesto style, I will write the rest of this post with how I think things should be done, not who got what wrong.

Patches Welcome

As a developer of CPAN modules and more tentatively a leader of a small part of CPAN, I will continue to say “Patches welcome.” If people are using the software that I have written for CPAN they are developers and can help implement the code that they need for their given use case. I doubt a non-developer would be able to figure out how to install a CPAN module, let alone use it.

Patches are not just for code though! That is where novice developers come in. In the DBIx::Class world (and I imagine Catalyst and Moose) standard practice is to help a newbie on IRC and then in return ask them for a documentation patch that will have rendered the help session needless. Of course sometimes the documentation needs massaging or you need to guide the newbie as to where the documentation should go, but that’s fine! This is how you get new blood into your contributor pool.

And of course the beauty of the “patches welcome” statement is that by definition only people who actually want the feature will send you patches! I would never ask a random user of my module to implement a feature that they do not need. It is because I needed correct sorting in SQL Server that I got involved with DBIx::Class. I did not ask: “How can I make this happen?” I actually asked someone else to fix it for me, and instead this person (ribasushi) guided me on how to do it myself. To restate the point: patches should be written by the people who will use them.

Meritocracy

One of the beauties of the open source world is that ultimately things are (to an extent) a meritocracy. That means that the people who get stuff done have the most say. As a Perl developer I am much more likely to listen to RJBS or Miyagawa about how to do something or even defer to them over some random developer I have never heard of. Of course there are times when things are done democratically. Recently some of us DBIx::Class developers had a vote about something. mst has even stated to us that when it comes to DBIx::Class he is willing to defer to the other developers if everyone else agrees. But ultimately, because writing software takes skill, the people with that skill make the decisions. Not the people who are the prettiest or richest or have the best marketting. I personally like it that way and will do what I can to keep it that way.

I say this because really, open source programming ultimately is not like regular work. Sure, developers fall off of the face of the planet and stop maintaining their software. But if you need the software that they wrote, you have at least two options; the first is that you contact the author and ask if you can take over the project so that you can get it back to a point where you can use it. If that sounds like too much work you clearly do not really need it. Your second option, if the author does not give you the OK to take over the project, is to fork it. Generally this should be avoided, since it can breed bad blood and often your software and the authors can have incompatibilities, but it is an option nonetheless.

I have done both of the above and it was never a huge problem. So again, in Open Source software, the onus is on the user not the developer; but that is why I use it, personally. If a developer dies, I as the user will be ok because I can fork the project myself.

Social norms

As I already said, the main reason for this post is so that developers inside and outside of the community will not be misled. I do not want new developers using my software expecting that they can just make demands and that I will do what they ask. I am not a hostage and neither is my software. I do not work for free. Anyone who expects me to work for free is either lying to themselves, insane, or is a looter stealing from me. I do not respect the opinions of thieves, liars, or lunatics when it comes to responsibility and I do not plan to respect their opinions.

I strongly believe the above, and I hope that we can all have some healthy discussion about it and hopefully come to agreement. I also have some thoughts on how to help increase the communication between various dissenters and those of us who like things the way they are, but I will leave those for another day.

Update

Turns out that this turned into a meme, so I’ll try to collect all of the related links to this topic here. I’m sure that I left some out, but I tried to include all of the ones that popped up in my feed reader. (Note: I’m not subscribed to all of Iron Man, so I might have missed some)

• chromatic’s thoughts
• dagolden’s thoughts
• perigrin’s thoughts
• jjnapiorkowski’s thoughts
• nperez’ thoughts