fu: Close-up of Fu, bringing a scoop of water to her mouth (Default)
I forgot that this week was mine, oops. Anyway if you have something, comment here *G*
fu: Close-up of Fu, bringing a scoop of water to her mouth (Default)
I got sick of typing ?usescheme=* six times for each webpage I was working on, so I turned to the Chrome extension docs.

It took me about 30 minutes to whip up an extension which does all the typing for me, with one click:


I dispensed with some of the niceties (like an icon to click on -- I just click on blank empty space), and it's otherwise very rough, but it's usable. No more typing ?usescheme=blah six times on each page *G*
fu: Close-up of Fu, bringing a scoop of water to her mouth (Default)
Doing massive massive cleanup of the site CSS. If I do everything right, everything should just work and it should be easier to work on frontend moving forward.

Have committed all patches that I might otherwise break in my cleanup, but ignoring the rest for now so I don't lose my train of thought.

It is just Thursday! That's good, I thought it was Friday and I'd run out of time *g*
fu: Close-up of Fu, bringing a scoop of water to her mouth (Default)
While deep in the bowels of S2, trying to track down something unrelated, I stumbled across the allow_others attribute for properties, which allows custom values to be saved for properties which usually show up in a dropdown.

Possibly helpful for things like oh, date formats or margins or whatever.

There's no frontend for it, but it would be simple enough to make it so that if you have a custom value (say one entered via the layer editor), it would show up in the dropdown (so it wouldn't be wiped when you use the customization wizard). Otherwise, just show the default set of values (as before).

Another possible interface would be to have a "custom..." option which would show a hidden text box using JS, but that's a bit more work and probably not worth it unless we had a specific use case in mind.
fu: Close-up of Fu, bringing a scoop of water to her mouth (Default)
Meant to try for a code push this morning, but my connection has been crawling, so I'm putting it off until I have better access. Want to make sure that I don't lose control halfway through.

Will see how things look in a couple of hours.
fu: Close-up of Fu, bringing a scoop of water to her mouth (Default)
Going to try out a new routine:

one day commit/review
one day misc coding
one day update page

That way nothing gets backlogged too much while I'm busy doing other things. Not sure how well it will work, but it seems worth a try.
fu: Close-up of Fu, bringing a scoop of water to her mouth (Default)
Was about to post an entry musing about some odd behavior I'd run into on entry preview, and then it occurred to me that I could probably track down the cause with a couple of moments of investigative work.

Few minutes later, I have a patch, a bug filed, and a fix committed.

(The things I get up to while procrastinating from writing the news post, oops)
fu: Close-up of Fu, bringing a scoop of water to her mouth (Default)
Huge weight off my back, and I'm glad to have it reviewed and committed. We still have the frontend to do, but the end is in sight, yay :)

I do miss being able to get vgifts from close friends, just a bright spot to my day.

The other thing that's been looming over me has been the Post Entries Page revamp. With the review queue finally under control, and now that there's no more background guilt over vgifts, I can concentrate on getting this done. (Long overdue!)

ETA: Hmm, this entry about the procrastination guilt cycle sounds awfully familiar.
fu: Close-up of Fu, bringing a scoop of water to her mouth (Default)
Code push went off with just a few hiccups (yay). Now doing some test runs on data migration (migrated users will be able to rename userpics again. Yay)
fu: Close-up of Fu, bringing a scoop of water to her mouth (Default)
There is an LJ::is_web_context() function.
fu: Close-up of Fu, bringing a scoop of water to her mouth (Default)
I finally have mogilefs set up on my dev environment! I threw everything I could at it, I'm not sure what finally stuck, but I can finally get around to reviewing a couple of patches that have been waiting forever (sorry!)

I suspect that either I had a missing dependency, or the packages I was trying before were trying to copy some of the files to the wrong place (and thus erroring because they weren't authorized).

I would like to start with a clean installation at some point, and document actual working steps, cutting out everything that's irrelevant, but that can wait.

For now, I bask. (And tomorrow I review *g* -- or that is the plan, anyway!)
fu: Close-up of Fu, bringing a scoop of water to her mouth (Default)
Have been working on the update page, and I think we're ready to unveil another version for this next news post.

There's a bunch of work still to be done in order to adapt it to different site schemes, and to pull in the various account data -- tags, icons, mood themes -- so that everyone can play with it properly. Let's just say that it's more than I'd hoped, but much less than I feared.

But I think barring any unforeseen need for another major rewrite, we can put out a mockup with dynamic data (and site schemes) in the version after that.

Then the backend and integration of new functionality, including saving your settings. Inching closer and closer to our goal.
fu: Close-up of Fu, bringing a scoop of water to her mouth (fu)
Saturday was fruitful! Spent a big chunk of it conferring with [personal profile] foxfirefey about what it would take to upgrade to OpenID 2.0 from OpenID 1.1 (we have the appropriate module in the backend, but need to update the arguments we pass to it).

Then went on a commit run. I hate rejecting patches! Especially when the patches are so very close. On the flip side, they are pretty close, so it shouldn't take a great deal to fix them. (That is, add on or tweak, but not completely rewrite).

But while I will occasionally allow myself to work on Saturday (or not-work on Saturday, as need be), Sundays are completely hands-off.

So. I'm making myself leave the laptop at home, as I have been trying to do these past three weeks (I succeeded the first week! *g*).
fu: Close-up of Fu, bringing a scoop of water to her mouth (Default)
Hm. Stuck on this point:

Identifier Recycling says that you can use a unique fragment in the Claimed Identifier for a successful login.

The Claimed Identifier is defined as "the Identifier obtained by normalizing the User-Supplied Identifier, if it was an URL."

"normalizing" is a link to another section which states:: "If the URL contains a fragment part, it MUST be stripped off together with the fragment delimiter character "#".

Also, trying to figure out whether I'm supposed to return the Claimed Identifier in the response, assuming they authenticated successfully, even if the request didn't contain the Claimed Identifier.

And thirdly, I'm not sure exactly how to make the Claimed Identifier discoverable; I'm seeing some references to localId, but I am under the impression that that may differ from the Claimed Identifier.

May need to do some code digging into the Net::OpenID::Server and Net::Openid::Consumer modules.
fu: Close-up of Fu, bringing a scoop of water to her mouth (fu)
Second version of the update page demo went out with the weekly news post, and we've received a lot of good constructive feedback to chew on. The feedback on big things seems to have clustered around a few topics, and many of the issues that were brought up during the first iteration now seem to be non-issues; it feels like we're moving forward, and that makes me happy.

One thing that's been brought up in this iteration is how the new page seems busier, and how we need a simple view. I've been talking things over with other people, and giving serious thought to this; it's interesting because making things simple is not, in itself, simple!

It's definitely something that needs careful thinking about, so I've put it aside to simmer and have been working on other things.

Finally figured out the cause of the annoying red flash. In some cases, the body background color flashes briefly when the scrollbar position changes. It's specific to Firefox, but doesn't happen to Firefox on all OSes. The reports I've seen show that it occurs on Linux and Windows (and I've managed to duplicate there), but I haven't seen it yet on a Mac which is what I have on my laptop.

Now that I've tracked it down, it's much less mysterious, though no less annoying. I can't get rid of it entirely, but I've been able to make it much less painful by removing the redness. I wonder what it would take to get it fixed in Firefox itself? Hmmm.

Other stuff that's not out yet, new tags are editable now, and there's a full list of tags on the page *handwave*. I need a second opinion on how everything looks, which I shall get at some point *g* I was convinced that the full list would take much more effort than it actually did, but it's done now, and I hope that it proves to be useful *g*

GSoC is coming to an end! I'm eager to get the new RTE integrated into the next version. I also want to see what the update page looks like in other site schemes.

I keep meaning to post about how it actually feels to work for Dreamwidth, but I keep putting it off. One thing that has changed, though, I appear to have turned into a morning person. I used to drag my heels getting out of bed, but lately I have been getting up at 6/7am to do work. Somehow all this seems worth waking up early for. Scary thought, but also fun.
fu: Close-up of Fu, bringing a scoop of water to her mouth (Default)
Am supposed to be on a plane on my way home, but due to flight delays which were out of my control, I ended up stuck in San Francisco overnight.

Soooo I texted Mark to let him know I was in the area and available to work and voila, code push. (Thanks for everything, air traffic control!)
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.
fu: Close-up of Fu, bringing a scoop of water to her mouth (Default)
[personal profile] jadelennox's comment in news, asking me if I'd like to discuss more WAI-ARIA options for the update page made me realize that though I've been reading up on the basics, there's still a lot I don't know, and I am not nearly enough familiar enough with the landscape to figure out what the best resources are.

So, lazyweb, what are your favorite resources for accessibility, with a focus on web development? Blogs, lists*, irc channels*, webpages, reports, books, etc. I have a bunch of tabs open right now for reading, but more links are always welcome.

* caveat that the lists and channels are comfortable having new people and lurkers *g*
Page generated Oct. 20th, 2017 07:38 pm
Powered by Dreamwidth Studios