Officially unofficial
Jul. 7th, 2015 08:00 amThis journal is now officially unofficial. It's been great! Stay tuned for more official updates over on ![[site community profile]](https://www.dreamwidth.org/img/comm_staff.png)
dw_news.
dw_news.
Mobile Styles
Aug. 4th, 2014 06:55 pmRe: users being unhappy with stuff on mobile, we're going to have a code push soon that should fix some of the problems and also give them options to adjust or turn off the mobile view
Re: the navstrip not working on core1, ...it took me too long to realize what was going on but they're being printed at the bottom of the page. we'll have that fixed by the code push too
again thanks all; if there are any other issues, especially if they're patterns that come up that I haven't mentioned above, please again let me know
Re: the navstrip not working on core1, ...it took me too long to realize what was going on but they're being printed at the bottom of the page. we'll have that fixed by the code push too
again thanks all; if there are any other issues, especially if they're patterns that come up that I haven't mentioned above, please again let me know
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.
Have fun.
Have fun.
Foundation
Jul. 3rd, 2013 07:43 pmI'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 ![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
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)
I have a new co-minion!
For her first code push while officially part of the team, she made a song
(Welcome aboardmisskat)
For her first code push while officially part of the team, she made a song
(Welcome aboard
misskat)Switching between accounts in Chrome
Nov. 15th, 2012 12:12 pmSo apparently it's really easy to switch between sets of accounts in Chrome
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
Interesting CSS effect
Apr. 16th, 2012 12:28 amWhat's the Deal with :target in CSS?
Here's a neat effect to mark out the currently linked-to comment item. Put this in your journal's CSS:
Then switch which comment is currently active by editing the #cmt... at the end of the URL.
I have custom comments turned off in my journal, so here's a demo of :target in action on a separate page.
Note: not currently useful for anything because we don't link to our comments this way -- but still kinda neat!
Here's a neat effect to mark out the currently linked-to comment item. Put this in your journal's CSS:
Then switch which comment is currently active by editing the #cmt... at the end of the URL.
I have custom comments turned off in my journal, so here's a demo of :target in action on a separate page.
Note: not currently useful for anything because we don't link to our comments this way -- but still kinda neat!
Lots of bug reports came in while I was asleep :) Currently using the post-it method of triaging: write it down, stick it the wall, get to it later.
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:
With this one:
Voila, instant context :) To turn it on, edit your .hgrc file:
nano ~/.hgrc
And then paste this section in it:
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.
--- a/bin/upgrading/s2layers/core2.s2 Tue Aug 30 22:12:52 2011 -0500
+++ b/bin/upgrading/s2layers/core2.s2 Wed Aug 31 04:45:59 2011 +0000
@@ -331,6 +331,8 @@
var readonly Tag[] tags "Array of tags applied to this entry.";
var Image userpic "The userpic selected to relate to this entry.";
+ var Image userpic_orig "FIXME";
+ var int itemid "Server stored ID number for this entry";
var readonly string{} metadata "Post metadata. Keys: 'music', 'mood', 'location', 'groups', 'xpost'. Comment metadata. Key: 'poster_ip'";
@@ -378,7 +380,6 @@
var bool new_day "Is this entry on a different day to the previous one?";
var bool end_day "Is this the last entry of a day?";
- var int itemid "Server stored ID number for this entry";
function print_metatypes(bool icon, bool info) "Print the metatype information for this entry";
With this one:
--- a/bin/upgrading/s2layers/core2.s2
+++ b/bin/upgrading/s2layers/core2.s2
@@ -331,6 +331,8 @@ class EntryLite
var readonly Tag[] tags "Array of tags applied to this entry.";
var Image userpic "The userpic selected to relate to this entry.";
+ var Image userpic_orig "FIXME";
+ var int itemid "Server stored ID number for this entry";
var readonly string{} metadata "Post metadata. Keys: 'music', 'mood', 'location', 'groups', 'xpost'. Comment metadata. Key: 'poster_ip'";
@@ -378,7 +380,6 @@ class Entry extends EntryLite
var bool new_day "Is this entry on a different day to the previous one?";
var bool end_day "Is this the last entry of a day?";
- var int itemid "Server stored ID number for this entry";
function print_metatypes(bool icon, bool info) "Print the metatype information for this entry";
Voila, instant context :) To turn it on, edit your .hgrc file:
nano ~/.hgrc
And then paste this section in it:
[diff]
showfunc=true
git=true
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.
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.
perltidy is so tempting
Mar. 1st, 2011 11:37 pmYou 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.
And yet, and yet...
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.
And yet, and yet...
I just stuck this in my .bashrc file, to let me easily find out which repositories have had commits since the last time it was tagged, so I can put a new tag on it:
( bash scripts )
( bash scripts )
Mercurial Queues
Feb. 9th, 2011 09:14 pmA 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.
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.
Commit attribution
Feb. 7th, 2011 03:24 pmThinking 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).
Eh, hm.
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).
Eh, hm.
map, sort, map
Feb. 5th, 2011 01:23 pmThe Schwartzian transform came up briefly in conversation in #dreamwidth. It is a way to sort by a calculated value, useful when calculating for said value is expensive.
I think I have seen it before, but I didn't realize it was a common enough idiom to have a name. I like how deceptively confusing it is, but once it is explained line-by-line it suddenly makes sense!
I think I have seen it before, but I didn't realize it was a common enough idiom to have a name. I like how deceptively confusing it is, but once it is explained line-by-line it suddenly makes sense!
Supporting Atom Publishing Protocol
Jan. 11th, 2011 12:54 amI'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.
That is, I've removed support for:( old urls )
And I've implemented a new interface:
( new URL breakdown )
Does anyone have any concrete reasons I shouldn't push forward with this?
Also, any suggestions for how / whether to support posting to communities? What URL should we use? :-)
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.
That is, I've removed support for:( old urls )
And I've implemented a new interface:
( new URL breakdown )
Does anyone have any concrete reasons I shouldn't push forward with this?
Also, any suggestions for how / whether to support posting to communities? What URL should we use? :-)
Test::More documentation
Jan. 1st, 2011 10:56 amThere'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).(no subject)
Dec. 3rd, 2010 11:23 amOh hey, you can make the jQuery validation plugin do both a summary of all errors before the form, and a per-field error message (best of both worlds?)
I'd been worrying that we'd need to do our own implementation, but now it looks like we don't. Ain't open source grand?
I'd been worrying that we'd need to do our own implementation, but now it looks like we don't. Ain't open source grand?
