One of the first projects I did at work was to make a web/javascript based interface for a piece of hardware that we sell. The machine is very underpowered so pushing a lot of the complexity to the client makes sense. It was a great project and is one of the few that I haven’t had to make modifications to since I finished it nearly two years ago.

Well, it turns out we are making a new version of the hardware and I have to add a ton of options to the UI. That is pretty easy in general, but first I have to get the app up and running. There’s NO WAY I’m going to flash the firmware every time I need to make a change to the javascript. What do I do instead? Mock the hardware with Plack!

Here’s the code I’m using:

The first and second line make a basic file server which serves up all the images and whatnot. The rest, the mount commands that is, rearrange things so that instead of using our pre-gzipped files it points to my source files. That way we can leave the html static but I don’t have to waste time copying stuff all over the place all the time.

Awesome!

I am proud to announce a new release of DBIx::Class::Helpers. There are five major changes in this release.

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!

Over a year ago I read this blog post. To be honest at the time I thought it was mostly silly and I still feel that way. The things that are important to me in an ORM are capabilities, not subjective prettiness of code. But, I also get tired of typing repetitive things, especially __PACKAGE__->. That’s just too many shift keys! So after working on a few different modules and accruing various bits of knowledge here and there I learned what I needed to to create a sugar layer for DBIx::Class that doesn’t throw the baby out with the bath-water.

---

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!

This year Rob Kinyon and mst convinced me to do some speaking at YAPC. I ended up doing three forty minute talks. The DBIx::Class one was certainly the easiest, but also the one I was least invested in. I didn’t write DBIx::Class and it’s a big enough project that the slides nearly wrote themselves.

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

So I just got back from my second YAPC. Again I had to leave early, but not as early as last time, so that’s good. Instead of summarizing every single talk I went to, I’d like to highlight some of my (most and least) favorites.

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

Do you remember when you first realized that you were not the only person with a perspective in the world? I do. I was 5ish and I remember looking into the car to the left of me and seeing another person looking at me from their respective car. I remember thinking, “This is not what it is like from their point of view.” I distinctly remember reevaluating things all day that day. I am sure that I was still just as selfish and childish as I was before that moment, but it certainly changed my point of view.

---

I am proud to announce, after three months of work, that DBIx::Class::DeploymentHandler is at a point where I’d call it stable and usable. DBICDH is a much more flexible replacement for DBIx::Class::Schema::Versioned. Castaway did a great job with making Schema::Versioned, and without it there is no way I would have gotten started on DBICDH, but it is my sincere hope that this will be the recommended tool instead of Schema::Versioned from now on. Rob Kinyon and mst had significant influence on the overall API and design, so it is at least influenced by Very Smart people. ribasushi helped a lot later on by pointing out poorly named methods and directories as well as helping me use SQL::Translator correctly since he knows all of its weaknesses and strengths.

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!

Woohoo! git!

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!

I am writing this post to address a problem that I could see appearing in our community. If it offends you feel free to let me know. If you comment on my blog as a troll, I will delete your comments. Feel free to put them on your blog where they reflect on yourself

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

I’m proud to announce a new version of DBIx::Class::Journal after almost three years of different people working on different parts!

It’s certainly not complete. The main issues for me are:

1. It only versions tables with single column PK’s
2. It has no simple way to have related data in the journal

The former is a SMOP, the latter, on the other hand, is a very serious architectural issue which I don’t think can even safely be solved. It *might* be as simple as just replicating all of the relationships in the original result and then adding in another column to the relationship which points to a version of that result. Or it might not. I need to consider it and look at things, but I think it can be done.

Honestly, if I had all the time in the world, I’d rewrite ::Journal from the ground up and make it a lot more malleable. Unfortunately I don’t have all the time in the world and personally I don’t have much use for it. Parts of my job do, but they only pay so much for features

Anyway, enjoy it! It should be pretty solid. Just make sure you read the limitations before use.

I really should have posted this sooner. Certainly before I began my next project. Oh well.

I am proud to announce the next bit of mstware! Log::Contextual is a small module for making your life easier when it comes to logging. Instead of bringing yet another logging infrastructure into the mix (see Log::Log4perl and Log::Dispatch), this module is a thin wrapper around any logging system you choose to use. (Note: we are working with authors of major logging packages to work seamlessly with L::C, but at the time of writing most need some form of adapter.)

There are a few major features worth noting. First off, ridiculously convenient interface. Once you’ve set up your logger (presumably in the startup of your app or whatever) all your logging code will look like the following:

Another great thing is that, like Devel::Dwarn, all of the logging functions are identity functions; that is, they return their arguments. That means you can do cool things like the following:

Of course, in Perl you may be passing around complex references and the above will get cumbersome fast, so we added shortcuts specifically for logging out data structures:

The automatic stringification is done with Data::Dumper::Concise, so you will get reasonably indented output for free.

In a separate package we are going to provide a module to basically turn the logging functions into no-ops at compile time, thus giving you the ability to have your code run just as fast if it never had the logging functions in in the first place. I’ll post more on that once it’s released.

So what are you waiting for? Go log stuff!