FYI, we just fixed the "Error running style: Died in S2::run_code running EntryPage::print(): Excessive recursion detected and stopped." error which caused the page to stop printing on very deep comment threads.

I'm hip-deep in learning Foundation / SCSS. Hoping to be able to convert our pages over to it. Benefits of Foundation are many-fold, but the biggest ones for me:

responsive, have our pages work on both large screens and smaller screens

consistency in appearance across all site pages

many major decisions already made -- so backend developers don't have to design an entirely new interface for each new thing they're working on, or try to figure out how to make stuff pretty

As for SCSS, if you know CSS, then you can already write SCSS. Plain vanilla CSS is valid SCSS -- granted, without the exciting logic/calculation bits -- but you can toss your .css file into a .scss file and that will work.

Worth sitting down for an afternoon and learn all the basics, but it's also fairly easy to just start with your current level of CSS knowledge, and ramp up slowly, learning bit by bit as the need occurs.

Slightly worried about adding an additional process, and we'll have to figure that out, but it's really nice, and it's going to make it easier to work with all the classes scattered across all the pages.

My goal is to consolidate all the many implementations we have -- I swear each individual page has a different way to style tables / clear floats / hide elements! -- and end up a neat and clean reference that's flexible enough that we're not tempted to add a new class each time something differs by a little bit (e.g., no more .error, .error-box, .error-bar. To my regret I believe those are all mine)

/dev/classes was supposed to be that, but it got bogged down because I was trying to make decisions on-the-fly as I ran into each case, and it was way too easy to go "well $a is special because it differs from $b a little bit, and $c is just like $a but with a border let's keep that too"

So now I'm trying a different way: start with the Foundation classes/implementation, ignore our own classes as much as possible, and only very reluctantly add new per-page CSS.

So much work to do, and it's probably going to end up being one of those long-running conversion projects, but it's humming along nicely.

(much thanks to foxfirefey for starting work on this during YAPC! This whole thing has been something I've been vaguely aware we should do something about, but never actually started until foxfirefey came along <3 Thanks for your enthusiasm and code. You are awesome)

Think LJ Login but for the entire browser and you can keep windows for both accounts open at the same time.

I've been using two browsers for long-term things, and the incognito window for short-term things but I did always wish for a way to have a separate profile in chrome (where my extensions are) while still remembering my history and open tabs for next time.

I'm switching to this method for juggling my personal and official DW accounts -- and probably when testing and debugging as well

Mercurial has a setting which tries to figure out what function you're in, and adds that to the patch output. It's really helpful when reviewing, so I recommend turning it on. For example, compare this diff:

showfunc=true makes Mercurial try to parse out the function the lines are changing in. git=true makes Mercurial behave git-like in some aspects, the most important one being that it'll save changes to binary files (such as images) within the generated patch, so that someone applying the patch will have your image placed into the proper path. That is, without your needing to upload the image separately along with instructions for where the image should go.

Has anyone ever managed to retrieve old comment text from a quick reply -- for example, if you accidentally closed your browser window, and then reopened it again?

I'm currently looking at it, and I see code that says it should be retrieving the saved form values, but I've never had it work, and I'm trying to figure out if it's just my browser / setup, or if it just plain doesn't work.

You could tie perltidy to the mercurial commit hook, and use that as an automatic checker for style before commit.

We have so much old code in various styles, this would be much easier than tweaking things by hand to make everything conform, and once you've gotten past that first big burst of formatting, you could run it again and see any style issues in any new patches.

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.

Thinking about attribution. Right now, we have it so that the committer is logged as the patch author in mercurial, and the patch author is listed in the text of the commit message.

I wonder how much work it would be to have the author be in the mercurial log, and the committer noted in the text for accountability.

On the one hand, it would be easier to pull out a list of names for statistics! On the other hand, some commits need to be attributed to multiple people, and there's no way to log multiple authors for a patch other than just listing them all (which wouldn't help with statistics).

I've been working on updating our implementation of the Atom Publishing Protocol for Bug 852, and I have a patch up there now.

Have several longish comments, but the short version is that our implementation was old to the point where I don't think any clients could use it, so I have felt free to break the old URLs while updating our implementation.

There's lots of nice stuff over at the Test::More documentation. In particular, I've just had a huge "D'OH" moment, and have switched to using is_deeply for many of my new tests where I check complex object structures. (Instead of, say, doing a for loop for each variable).