Evergreen ILS Website

IRC log for #evergreen, 2014-01-15

| Channels | #evergreen index | Today | | Search | Google Search | Plain-Text | summary | Join Webchat

All times shown according to the server's local time.

Time Nick Message
07:02 timf joined #evergreen
08:07 collum joined #evergreen
08:31 akilsdonk joined #evergreen
08:41 Shae joined #evergreen
08:46 kbeswick joined #evergreen
08:48 finnx joined #evergreen
09:03 berick tpac accessibility question for you all... the red $1.23 fines amount shown in the patron summary of the tpac (once logged in, assuming fines) does not have a high enough luminosity contrast ratio w/ the background (green) to be considered accessibile.
09:04 berick thinking about changing the color to match the Checked Out / On Hold count color (yellow-ish) instead, which contrast very highly
09:05 berick a mostly-red color does not appear to be an option
09:05 * berick is playing with http://www.dasplankton.de/ContrastA/
09:05 berick for that text size, the ratio has to be at least 4:1
09:06 * berick is impressed that so much of the tpac is just fine in this regard
09:06 berick after all the recent work
09:06 mmorgan joined #evergreen
09:06 berick anyway, if anyone has alt suggestions, i got my ears on
09:09 tsbere Huh. MVLC's choices don't work either, apparently, by that determination. Not that our choices would be community-appropriate, granted...
09:11 berick beware that as the text size / weight increases, the required ratio goes down
09:11 berick http://www.w3.org/TR/UNDERSTANDING-WCAG​20/visual-audio-contrast-contrast.html
09:11 kmlussier berick: I don't have an alternate suggestion, but I had once heard that yellow is a more difficult color for older people to see.
09:12 berick so, lots of the tpac seems to have a low ratio, but it's actually fine, cuz it's 14pt/bold
09:12 berick kmlussier: that's too bad, the other high-contrast colors for that dark green are pink-ish / purple-ish
09:12 berick not very attractive
09:13 kmlussier No, not at all.
09:13 tsbere berick: Honestly, I find the different colors distracting and had considered making them all uniform.  The Green "Ready for Pickup" and red "Fines" (which stays red even when 0 or negative, which is a complaint itself) is distracting and to some misleading.
09:13 kmlussier I'm not sure if what I heard was fact or myth, but it might be worth looking into.
09:14 dbs tsbere++
09:14 berick tsbere: i feel the same.  related, i'm really hoping we can avoid the insane color explosions the staff client -- 8 penalties, 8 different colors!
09:14 * dbs is not a fan of much color either
09:15 * tsbere would prefer symbols for penalties if we don't trust people to read text, and then we can show more than just one and not have to worry about color blind people having issues
09:15 dbs red and green have their own color blindness issues, too (family members have that)
09:15 berick kmlussier: i don't know, but given that we already use that color, i'm emboldened ;)
09:16 berick tsbere: +1
09:17 mrpeters joined #evergreen
09:18 kmlussier berick: I just did a quick search and didn't see anything to support what I just said, so I withdraw my concern.
09:18 berick kmlussier++ thanks
09:25 * berick borrows bootstrap's "sr-only" class to add some hidden accessibilty navigation to the tpac
09:32 yboston joined #evergreen
09:40 dbwells berick: Not saying it applies here, but as an old graphic design trick, a subtle text shadow can often increase contrast without being too noticeable.  For example, adding something like 'text-shadow: 0 0 2px #000000;' to #dash_fines certainly helps.  Is it enough?  In this case, hard to say.  I do agree with the others that a different overal strategy might be better here.
09:40 dbs berick: just switch it all over to bootsrap while you're at it!
09:41 berick dbwells: ah, i like it.  i'll play around with that.
09:41 * dbs raps an ode to his old boots: https://plus.google.com/11674729​2129029460979/posts/55yY5Z3s7m5
09:41 berick dbs: hah
09:42 * berick would rather spend his time porting autosuggest to non-dojo
09:43 dbs _that_ would be great
09:43 berick yowza, that's a lot script files for so few features
09:44 dbs I'm still shocked the browser people haven't come up with an <input type='autosuggest' src='json_feed'> standard widget
09:44 berick and rest assured when they do, IE won't support it for 8 years :(
09:53 * dbs was tempted to mess more with the OpenSearch functionality last night, e.g. to use the full name of the library rather than the shortname for the search engine widget, but realized that a) many libraries would have crazy long names and b) probably .05% people would actually use it anyway
09:55 bshum dbs: I haven't tested the latest branch, but remember fiddling with it back in the day. I think the only part that made me wary was how scoping could be applied if possible.
09:56 bshum I'll try it again when I get a moment to breathe.
10:02 kbeswick_ joined #evergreen
10:04 keynote2k joined #evergreen
10:04 dbs bshum: there are no real options for scoping; the code takes whatever your current search library is and uses that for the widget scope
10:05 dbs So if you're searching at BR4 when you add the widget to your browser, you'll get a search engine widget named "BR4" that searches at "BR4". Of course you can adjust your search as normal after the search returns results, because it returns results in TPAC as of this branch
10:05 bshum dbs: That might be why it wasnt entirely happy with me then. Our system is only making use of the pref_lib and doesn't set scope unless someone manually chooses something.
10:05 jwoodard joined #evergreen
10:06 dbs bshum: I'm not sure you tried this branch ever, as I'm sure it didn't exist until around midnight last night
10:06 bshum Well... Right. Fine, I'll just have to go test it now then. :)
10:06 dbs :)
10:07 * bshum should rename our top level someday from CONS...
10:14 bshum dbs: Ahh, I see.  The hostname stuff?
10:14 bshum Either way, works fine and does what I expect now.
10:15 bshum dbs++
10:16 bshum With one tiny thing
10:16 bshum I think there's a hanging " at the end of the base.tt2 change
10:16 bshum So it shows up at the top of the TPAC
10:21 mllewellyn joined #evergreen
10:23 dbs bshum: good catch!
10:23 dbs I will stare at my midnight branch
10:23 dbs yep, I see it. will force-push the fix
10:25 bshum Heh, it's fun how logc=SHORTNAME works as a variable now.
10:25 * bshum remembers when that didn't
10:25 bshum Oh how things change
10:25 dbs locg
10:25 bshum Well, locg
10:25 bshum Right :)
10:50 mcooper joined #evergreen
11:16 * csharp sends a carefully worded email to a library staffer who has been scheduling 5-6 concurrent item list reports at a time
11:17 rjackson-isl csharp I feel your pain!
11:17 csharp book title: "Staring at the Midnight Branch" by dbs
11:18 * bshum would buy that book.
11:24 jboyer-isl does anyone know what a query that looks like this might be for:
11:24 berick "the night was...  sultry.  And so was the code"
11:24 jboyer-isl SELECT  count(DISTINCT "mmrsm".source ) AS "count", "mfae".field AS "id", "mfae".value AS "value" FROM metabib.facet_entry AS "mfae"  INNER JOIN metabib.metarecord_source_map AS "mmrsm" ON ( "mmrsm".source = "mfae".source )  INNER JOIN config.metabib_field AS "cmf" ON ( "cmf".id = "mfae".field )  WHERE ( "cmf".facet_field = 't' ) AND ( "mmrsm".source IN (
11:24 jboyer-isl (and then a bunch of ids). I'm guessing OPAC related because of the facet fields, but that's just a guess.
11:25 eeevil jboyer-isl: it's part of facet counting, yes
11:26 eeevil the list of IDs is the current superpage of visible records
11:26 jboyer-isl ok. Occasionally they'll appear to get "stuck" and hang around 5+ minutes, just wanted to make sure we weren't knocking out anything important.
11:27 eeevil you're not. if you can grab the whole query and share an EXPLAIN of it, that would be great.  could just be out-of-date stats for a table, or tuning required ... or could be "that case wants a new index"
11:28 jboyer-isl I'll see if it's in the logs. pg_stat_activity cuts current_query short so I'm not 100% that's the end of the relevant bits.
11:29 eeevil cool
11:37 csharp jboyer-isl: you might look into pgfouine http://pgfouine.projects.pgfoundry.org/ - we use that to track long-running queries - setup is pretty simple - also pgbadger is supposed to be good, though I haven't used it http://sourceforge.net/projects/pgbadger/
11:38 csharp berick++ # just saw your quote from dbs's book - lulz
11:41 jboyer-isl Thanks csharp, I'll check them out.
11:49 jboyer-isl Looks like I entered my nick wrong on the paste site: http://paste.evergreen-ils.org/53
11:49 jboyer-isl Re: that query plan, I've seen worse. I'm thinking disk io is such a bottleneck that it's causing huge delays semi-randomly. (That query doesn't take more than 3-4 seconds usually)
11:51 jboyer-isl Actually, in this case I know it's disk io, because there are some issues to be dealt with. :/
12:11 eeevil jboyer-isl: was that one of the ones that was /actually/ stalling, or just representative of the query shape in general?
12:12 eeevil (specific parameters can sometimes change the plan chosen)
12:12 jboyer-isl Same type, different time.
12:12 eeevil parameter values, I mean
12:12 jboyer-isl I can look for the one that was stuck, but I thought only the ids would be different.
12:14 eeevil yes, but if the IDs fell into a set that was pathologically /included/ in the stats histogram for the facet value table, PG might think that it should use a seq-scan because "hey, the request IDs seem to make up more than 10% of the sampled data"
12:15 eeevil long shot, but possible. another possibility is, of course, an i/o storm as you suggest :)
12:20 jeff today's excuse: IO storms off the atlantic seaboard.
12:20 jeff (off the moons of jupiter?)
12:20 * jeff ducks
12:20 smyers_ joined #evergreen
12:22 jboyer-isl jeff: Comsmic Rays. A bunch of Ray Ramono clones in Intel bunny suits.
12:22 jeff *groan*
12:22 jboyer-isl BAH. Cosmic is not comsic.
12:22 jeff MS Cosmic Sans
12:22 jboyer-isl Could only help.
12:24 * csharp has enjoyed the perfect view of Jupiter in the east over the last couple of weeks
12:26 dMiller__ joined #evergreen
12:28 jeff this all started with someone's slow query log and ended with me putting a hold on Blade Runner
12:28 pastebot "jboyer-isl" at 64.57.241.14 pasted "QP comparison" (34 lines) at http://paste.evergreen-ils.org/54
12:30 jboyer-isl eeevil: You were right, though I'm not sure why it would be a problem.
12:33 csharp @eightball *do* androids dream of electric sheep?
12:33 pinesol_green csharp: What are you asking me for?
12:33 stevenyvr2 joined #evergreen
12:37 stevenyvr2 left #evergreen
12:38 stevenyvr joined #evergreen
12:41 eeevil jeff: I read "... excuse: IO ..." as "excuse::IO" and was about to ask where one might avail themselves of that particular module
12:42 gmcharlt eeevil: surely you mean Blame::IO
12:42 eeevil gmcharlt++
12:43 jeff heh. just realized i have a report called bucket_list.jrxml
13:40 csharp jeff++
13:41 afterl joined #evergreen
13:41 csharp @blame IO
13:41 pinesol_green csharp: It's all IO's fault!
13:58 jeff wishing i could checkpoint my brain sometimes.
13:59 jeff serializing thoughts to ascii just doesn't cut it at times.
14:18 pinesol_green [evergreen|Galen Charlton] LP#1234201: fix menu item to display patron requests (if summary is horizontal) - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=f7a049d>
14:19 kbeswick joined #evergreen
14:23 bshum @hates horizontal summary display
14:23 pinesol_green bshum: (hates [<channel>] [<user>]) -- Find out what <user> hates
14:23 bshum @hate horizontal summary display
14:23 pinesol_green bshum: The operation succeeded.  bshum hates horizontal summary display.
14:24 bshum @hate vertical summary display
14:24 pinesol_green bshum: The operation succeeded.  bshum hates vertical summary display.
14:24 jeffdavis @whocares diagonal summary display
14:24 pinesol_green jeffdavis: I can't find anyone who loves or hates diagonal summary display.
14:39 dMiller___ joined #evergreen
14:57 jboyer-isl @love diagonal summary display
14:57 pinesol_green jboyer-isl: The operation succeeded.  jboyer-isl loves diagonal summary display.
14:57 jboyer-isl Being late to the party doesn't mean it's not a party.
14:59 jeffdavis :)
15:03 csharp @whocares display
15:03 pinesol_green csharp: I can't find anyone who loves or hates display.
15:26 DPearl1 joined #evergreen
15:27 jboyer-isl Here's a fun question in case anyone knows: If you run autogen.sh -u on multiple bricks, should the cache key be the same each time it runs (provided no changes are made)?
15:28 dMiller__ joined #evergreen
15:34 gmcharlt jboyer-isl: yes, the cache key should be identical; if it isn't, it indicates that there's a difference in the files it's checksumming
15:35 pastebot "gmcharlt" at 64.57.241.14 pasted "list of files that the cache key is calculated from" (7 lines) at http://paste.evergreen-ils.org/55
15:35 jboyer-isl That's what I expected. Makes the 2 different results I just got less amusing though.
15:35 jboyer-isl thanks for the list of files too
15:35 jboyer-isl gmcharlt++
15:37 gmcharlt also, nowadays -u isn't really necessary
15:37 gmcharlt and if you use that option at all, it need only be used once
15:38 jboyer-isl ok. Are there any potential issues, or is it basically a noop the second+ times?
15:41 gmcharlt jboyer-isl: it refreshes actor.org_unit_proximity in the DB
15:41 gmcharlt it's unecessary because triggers on actor.org_unit handing updating the proximity list nowadys
15:42 gmcharlt and even back when it was useful, it only needed to be run just once after any changes to the OU tree
15:46 jboyer-isl I see.
16:02 jeff note to self: next time, reserve hotel room before getting travel request approved
16:03 jboyer-isl jeff: dates filling up?
16:12 jeff default date range resulted in no availability. i adjusted to 3/18 - 3/22 and it was happier
16:14 jeff > Connect to see which of your Facebook friends are going to Evergreen 2014 International Conference.
16:29 kmlussier jeff: Which date was the problem?
16:32 snowball joined #evergreen
16:32 kmlussier Oh, I see. It's strange that it defaults to an ending date of 3/23. We didn't block rooms on that day.
16:34 * jeff nods
16:34 jeff i booked for not-quite-the-dates-i-need and will call to adjust. :-)
16:35 kmlussier Yes, if you call and they have the right rooms available, they might be able to extend the discount to those additional days.
16:39 jeff hate hate hate booking travel.
16:41 jboyer-isl joined #evergreen
17:05 mrpeters left #evergreen
17:11 dcook joined #evergreen
17:42 mmorgan left #evergreen
18:10 Callender joined #evergreen
18:11 pinesol_green` joined #evergreen
18:12 smyers__ joined #evergreen
18:13 bshum_ joined #evergreen
18:17 keynote2k joined #evergreen
18:18 kmlussier joined #evergreen
18:22 dac joined #evergreen
18:32 dcook joined #evergreen
18:49 keynote2k joined #evergreen
18:53 ktomita joined #evergreen
18:53 fparks joined #evergreen
18:56 fparks_ joined #evergreen
19:08 sseng joined #evergreen
19:08 fparks joined #evergreen
19:08 smyers_ joined #evergreen
19:08 ktomita_ joined #evergreen
19:10 dconnor joined #evergreen
19:11 ktomita__ joined #evergreen
19:12 smyers_ joined #evergreen
19:12 sseng joined #evergreen
19:12 fparks joined #evergreen
19:14 dconnor_ joined #evergreen
19:14 sseng_ joined #evergreen
19:33 ktomita joined #evergreen
19:50 ktomita_ joined #evergreen
19:54 ktomita joined #evergreen
19:59 ktomita_ joined #evergreen
22:11 stevenyvr2 joined #evergreen
22:11 stevenyvr2 left #evergreen
22:28 stevenyvr joined #evergreen
23:23 mrpeters joined #evergreen

| Channels | #evergreen index | Today | | Search | Google Search | Plain-Text | summary | Join Webchat