#musicbrainz-devel

ijabz: groan. fucking allergies are eating my brain alive. I can't think a single straight thought. :(

12297 makes one chnage to serlvet code

anyway, first step is probably getting a very basic timeline up (akin to the old timeline.html)

indexes do or dont need to be rebuilt?

I cant stop sneezing , having to accpet I have got hayfever and will need to get some tablets

as a way of getting me used to how the data flows around through the system, etc.

no need to build indexes

ijabz: tablets dont work for me. :(

I've been eating local honey which made the problem go 90% away.

ianmcorvidae: indeed, I'm trying to think what the smallest starting point is

I never tried them, I didnt have hayfever 2 years ago

but we're in the final throes, and now its bugging me.

then onward to improving that (leaving out/including different lines, zooming, rate of change graph, exact numbers on hover, musicbrainz events, and copyable URLs)

ijabz: raw, unfiltered, local honey daily is the trick!

LOCAL is important.

ok, so a new servlet going out then. can do.

ianmcorvidae: I'm not sure how you like to work, but giving you some tickets on JIRA might be a good way for us to stay on the same page

Yeah, someone I recently got know gave me some honey he made in his garden last week, but bit late for this year isnt it

ijabz: its a long term play.

ocharles: that seems like a reasonable way to work

if you start eating it daily, you can be prepared for NEXT year.

you have to take it in Winter, but I think its good stuff he doesnt strain it fully, so more pollen in it

plus, it means I can put MBS-whatever in my codereview postings, which always looks better ;)

ianmcorvidae: right :)

ijabz: for sure

ianmcorvidae: I think maybe we start with displaying a single statistic over time

ie, graphing count.artist

that makes sense

artist is something that hasn't changed names umpteen times, too, that's probably a good choice :)

yea :)

I think we start with displaying one statistic, then we look at fetching that data via AJAX, with a query like /ws/js/statistic/count.artist

and then we magical expand to have graphs for all known statistics

then we should probably meet again and see what looks like a good next logical task to work on

presumably we want combined graphs, not multiple graphs, yeah?

but other than that, yeah, sounds right

ianmcorvidae: In the end yes, but I think we should start with multiple graphs so we can see what code they have that's similar

okay :)

so we'll start with /statistic/artist and /statistic/edit pages or something

and then look at how we can combine them better

sounds good

yay

so, orient me with respect to the code -- I've read through the Catalyst tutorial and some of the introductory TT stuff

cartman is being dirty. :)

seems very fitting

haha

I'm not sure how data flows through the whole shebang, mostly; what do I need to import/include/require, that sort of thing

ianmcorvidae:

ok, so the most important things for you are Data::Stastistic, Entity::Statistic and Controller::Statistic

I imagine 90% of your work will go on there

Statistics, you mean, or did you mean Statistic?

for which?

I probably meant Statistics

any of them :) Statistics exists for all three, Statistic would be new

oh, weird

good work us at breaking that naming convention

(currently m.o/statistics is the tabular data)

never mind

so yes, Statistics modules

When a user visits /statistic/foo, they are probably going to end up calling the method in Controller::Statistic called 'foo' (hand waving a little here)

"sub foo" in this controller will then collect various bits of from Data::Statistics, which is the interface from the web server to external data

It will usually return something containing Entity::Statistic objects

Entity::Statistics currently represents a collection of statistics for a certain time

that may or may not make sense

It should either represent a timeslice for a statistic, or all statistics for a certain time

As we may want users to choose what to graph, the former might be better

But coding will make that more apparent :)

indeed

So, 'sub foo' has called Data::Statistics, and collected some data

Once it's done transforming it, it puts it in $c->stash, which is a dictionary that is present to templates

(by default the template will be statistics/foo.tt)

yeah

So for graphing count.artist, I think you'll want to add a "artist" action to Controller::Statistics, and use Data::Statistics to collect the interesting information and put in $c->stash

and then all the HTML/JS stuff goes in the template, yeah?

yep

and then in your template you can transform this into inline JS

and then you should have something ready to review :)

cool

potentially unrelated: should I be using the admin/sql/updates scripts after I do git-pull, or should I not worry about it?

mm, are you running a replicated db?

nah, RT_STANDALONE

it might be worth running them when we do server updates then

ie, when we push a new tag out

hm, okay

psql -U musicbrainz musicbrainz_db < {whatever}, or?

oh, there's an upgrade.sh

whoops :)

yea :)

and ./admin/psql READWRITE/RAWDATA

is the best way to open up a psql shell

ah

ijabz: new search server deployed.

I see the ext string in the output now, so we should be good.

oh fuck, there a mistake

an extra ", sorry

commit a fix, post haste, please.

yep

hm. looking at edits on an artist: "Caught exception in MusicBrainz::Server::Controller::Artist->edits "Can't use an undefined value as an ARRAY reference at /home/ianmcorvidae/Source/musicbrainz-server/script/../lib/MusicBrainz/Server/Edit/Historic/AddLink.pm line 18.""

( that line being 'return @{ $self->data->{links} };')

ruaok: done

ijabz: pushed.

rigt, looks okay now

cool

hmm, pwrhaps I should always get it on test first ?

yes, good idea.

trouble is I cant do that myself, so bit of an effort getting it done

well, soon we can hopefully stop doing hotfixes and take the time to properly do this.

ruaok: would it be safe for me to dropdb and then reimport from 20110521-100351 ? (decided I wanted to update my data a bit)

sure.

cool

ianmcorvidae: your data is waaay out of date

ocharles: yeah, this is what I realized; I still have 4/27 data :)

:)

ocharles: i confirmed our AWS keys and they match with whats on the AWS key page.

can you maybe add some debug output to the cover art script if the AWS auth goes wrong?

yes, but tomorrow

the key pairs are marked as active.

ocharles: after I import 20110521-100351 should I also run upgrade.sh again, or?

I just made a new access key. I'll try that.

ianmcorvidae: yea, that looks a bit out of date

okay, cool

(it's latest on ftp.m.o :)

there should be a new one out today or tomorrow, i think

today

will start in under 3 hours

hm

might wait then

I think the statistic table isn't changed, so I can at least start on my work :)

(shocking, I know)

no, that hasn't changed

it's mostly edit stuff that has

ocharles would consider MBS-2281 shoud be a hotfix

ok, move it over then

i'm sure warp feels the same about the RE

ijabz: I'm with you on that.

we've been talking about NGS for two years! it should not come as a surprise to anyone.

yet everyone is surprised.

wtf?

Perhaps they didnt believe it was ever going to actually happpen ;)

haha

I was about to say something along the lines of that

ocharles: and about the style guidelines