fu: Close-up of Fu, bringing a scoop of water to her mouth (Default)
A Git User’s Guide to Mercurial Queues is pretty good, and has led me to investigate (and use) multiple patch queues.

Guards are much more flexible, and let you disable/enable patches easily, as well as mix and match different groups of patches. Everything you can do with qqueue, you can probably do with a guard.

For my purposes, qqueue is better, though. I don't need all that flexibility. I just want to group patches into logical branches, and be able to work on them as a group, as well as be able to stay "on topic" -- any new patches I create being automatically grouped with the patches I'm currently working on.

qqueue has made a few small changes to my workflow that have made my dev work much easier:
* hg qnew automatically adds a new patch in the same queue you're working on. No need to go back and do "hg qguard +featurename" each and every patch. No more annoying miscellaneous unguarded patches that need to be sorted out!

* hg qq -l brings up a list of all patches in the queue. With hg qguard, to find everything applicable, I'd need to do hg qguard -l | grep $featurename

* hg qq --delete $queuename lets me forget about all patches in a queue with a single command -- just what I need when I'm done with something

I still use guards within the patch queue, but only for small things: I use them to tweak configuration, or to disable a patch before running a test. My tests are almost always in a separate patch from my features code these days ;-)

Disadvantages: it's not easy to move patches from one queue to another and you can't apply patches from two different queues at the same time.

For what I need though, it's perfect.
fu: Close-up of Fu, bringing a scoop of water to her mouth (Default)
Chose an easy bug to do while in the middle of doing reviews, this one was from suggestions -- Bug 2580: Smarter Tag Tracking.

Let's say you were reading an entry and decided that you wanted to be alerted of all new entries that are on the same topic, by tracking all new entries posted under the same tag as one on this entry.

You'd click on the "Track" link, then through to "More options", and then have to scroll through the journal's entire list of tags in order to find the tag you're looking for. Something like this:

image of the complete list of all tags on the journal )

So what was suggested was that we give priority to the entry tags, so they can be easily selected, while still listing the rest of the tags. So something like this:

image of the tags on this journal broken down into two groups: entry tags and other tags )

This one was pretty straightforward -- the toughest part was figuring out how to make the tags dropdown aware that we wanted to target a specific entry. The next toughest part was figuring out how to make the LJ::html_select function handle optgroups.

And done; another suggestion implemented *G*
fu: Close-up of Fu, bringing a scoop of water to her mouth (Default)
Hmm, I've been thinking about this a bit, and I'd like to start noting down what I'm working on, informally.

What this means is that I'll be posting more: sometimes I'll be posting more technical stuff, other times I'll be posting less technical stuff. More technical entries like this one, which include code, will be tagged with "development", so you can either filter that out or read only that. We'll see how it turns out.

Today, while reviewing a patch to allow support requests to be mass-closed, I stumbled upon code that was completely unfamiliar to me:

$dbh->selectall_arrayref( "...", { Slice => {} } )

Usually the first argument to one of the database calls is undef; I've never bothered to figure out why, just chalked it up to something that was over my head. Tonight, it was obviously time to figure out what that first parameter was for!

Discovery number one: the first parameter is not magic. It's actually a hashref of additional attributes, in case you need to override the default settings (such as whether to commit, what to do when the database errors, what format to return the results in). Usually we just pass in undef because we don't need to override the defaults.

Discovery number two: perldoc DBI is useful for seeing the entire API of DBI, but it's very technical (I skipped sections that I thought were irrelevant; it turns out that one of those irrelevant portions was actually relevant)

Discovery number three: unrelated to previous, but taken from perldoc DBI, you can look up the last SQL statement that your program used, using warn $dbh->{Statement} or warn $sth->{Statement}. That prints out the last SQL statement into your logs, including the values of any variables -- useful when you're deep into debugging something.

Discovery number four: perlmonks.org has a page for DBI recipes, which was what made me realize that the whole thing with Slice? Was so you could return a list of hashrefs.
Page generated May. 25th, 2017 02:20 pm
Powered by Dreamwidth Studios