I’d remind hiroki and yurimingo that tomorrow is the approximate midterm point of the course for you. (well, the course from our perspective)
Q: i don’t have any idea what i should check
A: You can move that over to test “iftrophy” instead. most of the unit tests should probably be in Hiroki’s code. (As a side note, I’m getting a little worried about the common code in yurimingo and hiroki’s patches – we’re setting ourselves up for manual merge…)
Q: if it’s possible, could you give me a screenshot of the specific banner its referring too, there’s so many banners that I can’t figure out the exact one. I’m good with what the changes require tho, just can’t find which banner it is.
A: currently it’s just the text box. which works like the fields. might be a couple things to figure out, play around with. I’m going to be doing a round of reviews tonight and tomorrow. glanced at it and in general it looked fine. there will be some things to fix.
Q: It looks difficult for me ” We need to move the trophy “type” logic out into the TrophyManager. TemplateTags, etc, should not care about palindromes or milestones. This adds a maintenance burden, and is fragile.”
A: so, I’m concerned that too many pieces of the code outside of the TrophyManager know about the types of trophies we have. the templatetags, for example, look specifically for palindrome and milestone trophy types. this was fine for those two trophies, but now that we’re more serious about trophies, this is not sustainable. basically, the only place that should know anything about specific trophies should be in TrophyManager. the template tag and any other code should ask TrophyManager. For example, it might call a function on TrophyManager, passing the review request, and then get a result back
Q: I want to do something to make adding a trophy_type easier. but I don’t see how to implement it.
A: ok, after this meeting, how about we talk and sketch out a spec.