| *** vidasp has quit IRC | 00:11 | |
| *** jinty has quit IRC | 00:44 | |
| *** tiredbones has quit IRC | 00:49 | |
| *** tiredbones has joined #schooltool | 00:49 | |
| *** srichter has joined #schooltool | 01:24 | |
| *** jelkner has joined #schooltool | 02:33 | |
| jelkner | th1a: tom, u here? | 02:33 |
|---|---|---|
| th1a | jelkner: Just got back from the grocery store. | 02:49 |
| jelkner | i'm on the phone | 02:50 |
| jelkner | brb | 02:50 |
| jelkner | is now a good time to call? | 02:53 |
| th1a | Sure. | 02:54 |
| srichter | th1a: I think I have a flexible plan for the gradebook | 03:24 |
| th1a | I was just going to send you a note too. | 03:24 |
| srichter | jelkner: I hope you were not offended by my most recent mail about developmentn process | 03:24 |
| srichter | th1a: ok | 03:25 |
| jelkner | srichter: i must of missed that | 03:25 |
| jelkner | please fill me in | 03:25 |
| th1a | It was a while ago. | 03:25 |
| srichter | (I sent the mail about a week ago | 03:25 |
| srichter | about development process) | 03:25 |
| jelkner | can you summarize? | 03:25 |
| jelkner | do you mean the email you sent to help us with our class? | 03:26 |
| jelkner | about 2 weeks ago | 03:26 |
| srichter | yes | 03:26 |
| jelkner | that was great | 03:27 |
| srichter | Feb 23, 06 :-) | 03:27 |
| srichter | Re: Assignment for zope3class | 03:27 |
| jelkner | yup 2 weeks | 03:27 |
| jelkner | yes, i read it in detail | 03:27 |
| jelkner | thanks | 03:28 |
| jelkner | th1a: email sent | 03:28 |
| th1a | jelkner: Thanks. | 03:28 |
| th1a | srichter: So what's the plan? | 03:28 |
| jelkner | ok, gotta go. | 03:29 |
| jelkner | cya all later... | 03:29 |
| *** jelkner has quit IRC | 03:29 | |
| th1a | I was thinking that perhaps all activities in the gradebook should be in a 2 level hierarchy to cut out the name duplication problem. | 03:29 |
| th1a | "Term" requirements (for the report card) would be in ['term']['e4a'] | 03:30 |
| th1a | something like that. | 03:30 |
| srichter | even easier | 03:31 |
| th1a | Regular tests, assignments would be in ['assignments']['e4a'] | 03:31 |
| srichter | Will will have ``GradeItem`` objects that wrap requirements or can be anything | 03:31 |
| th1a | And if you were evaluating the same standard in different projects, the project would be the top level | 03:31 |
| th1a | ['moby dick']['e4a'] | 03:31 |
| srichter | all they have to have is a title and know how they represent themselves in the gradebook | 03:32 |
| th1a | And...? | 03:36 |
| srichter | nothing end | 03:36 |
| srichter | nothing and | 03:36 |
| srichter | it will make the gradebook so flexible that I can put anything pretty much in it | 03:37 |
| th1a | How do they connect to the requirements? | 03:37 |
| srichter | so some grade items will be created from the requirement structure as it is now | 03:37 |
| srichter | others from the report requirements | 03:37 |
| th1a | So just a wrapper layer. | 03:38 |
| srichter | since grade items will be unique, a requirement can be connected to several grade itesm | 03:38 |
| srichter | yep | 03:38 |
| th1a | To avoid namespace collisions. | 03:38 |
| srichter | not only that | 03:38 |
| srichter | but it will also make the gradebook layout more flexible | 03:38 |
| srichter | so that we can have different types of items in them, like simple requirements, but also computed ones, like final grades | 03:39 |
| th1a | OK. I'll take your word for it for now. | 03:40 |
| srichter | I know that's the way to go | 03:41 |
| srichter | I feel good about it | 03:41 |
| srichter | and it addresses the issue I mentioned early in the morning that our APIs are not flexible enough | 03:43 |
| srichter | this is the solution I was looking for :-) | 03:43 |
| srichter | 3 strikes at once, cool :-) | 03:44 |
| th1a | OK then. | 03:46 |
| th1a | I'm tired. | 03:46 |
| srichter | oh, I love it even more now :-) | 03:46 |
| srichter | it fits the story so well | 03:46 |
| srichter | I think I will have some good rough idea by tomorrow | 03:47 |
| *** srichter has quit IRC | 04:24 | |
| *** srichter has joined #schooltool | 04:24 | |
| *** didymo has joined #schooltool | 04:24 | |
| *** th1a has quit IRC | 05:09 | |
| *** auxesis has quit IRC | 06:09 | |
| *** ignas has joined #schooltool | 09:47 | |
| *** vidasp has joined #schooltool | 09:55 | |
| *** jinty has joined #schooltool | 10:27 | |
| *** alga has joined #SchoolTool | 10:38 | |
| *** vidasp has quit IRC | 10:54 | |
| *** Aiste has quit IRC | 11:03 | |
| *** didymo has quit IRC | 11:47 | |
| *** alga has quit IRC | 12:23 | |
| *** thisfred has joined #schooltool | 12:40 | |
| *** mgedmin has joined #schooltool | 12:46 | |
| *** alga has joined #SchoolTool | 12:49 | |
| *** faassen has joined #schooltool | 13:07 | |
| *** th1a has joined #schooltool | 13:18 | |
| *** jinty has quit IRC | 13:42 | |
| *** Aiste has joined #schooltool | 13:47 | |
| *** jinty has joined #schooltool | 13:59 | |
| ignas | mgedmin, and what if we'd just add a Timezone argument to expand method for allday events, which is ignored if there are none | 14:44 |
| ignas | or changing the interface would be a bad idea | 14:44 |
| ignas | i think making it non-keyword would prevent some future bugs | 14:45 |
| mgedmin | ignas: you mean ICalendar.expand(first, last, alldaytz=EuropeVilnius)? | 14:46 |
| ignas | i mean ICalendar.expand(first, last, alldaytz) | 14:46 |
| mgedmin | sounds better than implicitly using the timezone of the first/last arguments | 14:46 |
| mgedmin | +1 | 14:46 |
| ignas | so one could not miss it | 14:46 |
| *** alga has quit IRC | 14:48 | |
| *** vidasp has joined #schooltool | 14:53 | |
| *** jinty has quit IRC | 14:54 | |
| *** alga has joined #SchoolTool | 15:30 | |
| * th1a cracks his knuckles. | 16:25 | |
| * alga blinks | 16:25 | |
| alga | How is your health? | 16:25 |
| th1a | I feel like an old man who has had diarrhea for a week, thanks. | 16:26 |
| faassen | th1a: ugh, I hope you didn't catch that here | 16:28 |
| srichter | good morning | 16:29 |
| faassen | hey. | 16:29 |
| faassen | hey srichter :) | 16:29 |
| srichter | hey :-) | 16:29 |
| th1a | I'm not sure what type of bug I've got. I didn't go to the doctor because every morning it seems like I'm better and then every evening I feel like crap. I just called the doctor though. | 16:29 |
| th1a | srichter and I covered a lot of territory in our meeting yesterday. | 16:30 |
| th1a | OK... agenda. | 16:30 |
| th1a | Let's see if we can wrap up POV's stories first, | 16:31 |
| th1a | then discuss what Infrae will be doing when. | 16:31 |
| th1a | You awake, ignas? | 16:31 |
| th1a | One outstanding question is the "attendance dashboard." | 16:31 |
| ignas | yep i am here | 16:32 |
| th1a | Basically, we need a page that a clerk or school administrator can refer to check for pending issues. | 16:32 |
| th1a | Workflow stuff they need to do. | 16:32 |
| th1a | So it should probably be a top level page, | 16:32 |
| th1a | with some viewlets. | 16:32 |
| ignas | and probably we need a way to identify clerk/school administrator | 16:32 |
| th1a | Well, we've got groups. | 16:33 |
| th1a | Is that not sufficient? | 16:33 |
| ignas | oh, forgot about them | 16:33 |
| th1a | faassen thinks we need roles, but we'll avoid that if we can at this point. | 16:33 |
| faassen | I don't know what we'll need, I just worry about the way groups are now. | 16:34 |
| th1a | Given the somewhat chaotic state of our navigation, for the moment it probably makes most sense to stick a link "Attendance" that shows up for people in the right groups under "Navigation." Consider that a temporary hack. | 16:35 |
| th1a | Unless someone has a better idea. | 16:35 |
| srichter | Shane once suggested that from a permission point of view principals, roles and groups are all the same; they are all grouping permissions; so their existence is rather arbitrary and you could add and remove as many layers as you like | 16:35 |
| srichter | th1a: I started a dashboard already, though it would need some real love and work; I am not sure you are willing to invest there right now | 16:36 |
| th1a | Then in the corrections story, you'll need to make a viewlet for the attendance dashboard that lists the corrections waiting to be approved. | 16:37 |
| faassen | srichter: technically that may be true, but from the perspective of a comprehensible user interface and human thinking that isn't necessarily true. | 16:37 |
| srichter | the dashboard I started should forward you to the attendence dashboard of course | 16:37 |
| th1a | srichter: We're just a bit jammed up right. | 16:37 |
| srichter | yeah, I agree | 16:37 |
| th1a | srichter: Oh, you mean in terms of the first screen a user sees. | 16:37 |
| srichter | yep | 16:38 |
| th1a | OK. | 16:38 |
| * mgedmin checks whether 0.11.4 and 1.2.4 are announced on schooltool.org and finds that they aren't yet | 16:38 | |
| srichter | for a clerk that would include the attendance management screen | 16:38 |
| th1a | mgedmin: If someone other than me wants to post things on schooltool.org, they're welcome to. | 16:39 |
| th1a | ignas: Are there other loose ends in the attendance stories? | 16:40 |
| th1a | Have you worked out the two homeroom mess? | 16:40 |
| ignas | yes, i had to merge two stories as they were overlaping | 16:40 |
| ignas | Period Absences Inheriting from Day Absences and Day Tardies | 16:40 |
| ignas | is the new name | 16:40 |
| ignas | when i'll know what is involved in the dashboard story i'll send you the result for a review | 16:41 |
| th1a | OK. Sounds right. | 16:41 |
| povbot | /svn/commits: * srichter committed revision 5786: | 16:41 |
| povbot | /svn/commits: - Factored date range into its own module. | 16:41 |
| povbot | /svn/commits: - Moved date range tests to README.txt; currently deactivated, see below. | 16:41 |
| povbot | /svn/commits: - Started writing some science fiction about how we (Tom and I) would like | 16:41 |
| povbot | /svn/commits: terms to work. | 16:41 |
| th1a | Do you get the idea for the dashboard story now? | 16:42 |
| ignas | add a view that everyone in a school admin group can see | 16:42 |
| ignas | display attendance work items relevant to school admins in that view | 16:42 |
| th1a | Don't we have a clerk group too? | 16:43 |
| ignas | yes we do | 16:44 |
| ignas | so make the view visible to School admins and clerks | 16:44 |
| th1a | Right. | 16:44 |
| ignas | now should the explanation workflow include have more than one role ? | 16:45 |
| th1a | OK. Any idea when you guys will be ready to get going on that? | 16:45 |
| ignas | or are we still using only 1 role of school admin and allowing everyone to perform actions ? | 16:45 |
| ignas | you mean when we will start working on the contract, or the dashboard story ? | 16:46 |
| th1a | We haven't bothered to clean up the permissions on taking attendance because srichter is going to fix the section permission situation. | 16:47 |
| th1a | ignas: working on the contract. | 16:47 |
| ignas | as soon as you will confirm the contract and our estimates | 16:48 |
| th1a | I'm a little unsure of what the overall situation with permissions in the attendance workflows are. | 16:48 |
| th1a | The end result should be that only school administrators and clerks can do those actions or see the dashboard. | 16:48 |
| *** Aiste is now known as Aiste|away | 16:49 | |
| th1a | I'm not sure what that means internally at this point. | 16:49 |
| ignas | at the moment we are not using workflow permissions, it all depends on the view | 16:49 |
| srichter | th1a: I am pretty deep into the term and gradebook stuff right now, so POV could take on the session permission stuff if they wanted to | 16:49 |
| th1a | srichter: True. | 16:50 |
| th1a | srichter: Why don't you sent ignas your story. | 16:50 |
| ignas | thus if you have access to a view that pushes through a correction - you can convert a tardy to an absence and etc. | 16:50 |
| th1a | See if we can add it to their work. | 16:50 |
| srichter | I think I have not written the permission story yet, only the one about fixing the API | 16:51 |
| th1a | srichter: Yeah, well, perhaps they should be the ones to do that. | 16:51 |
| th1a | It is more relevant to what they're doing than what you're doing. | 16:51 |
| th1a | ignas: So there could be two levels of permissions, on the views and in the workflow itself, but right now we're only doing it on the views. | 16:52 |
| th1a | ? | 16:52 |
| ignas | yes | 16:52 |
| ignas | which means that in our workflow there is only 1 actor/person | 16:52 |
| th1a | Well, for the moment, if it works right on the views that's probably sufficient. | 16:53 |
| ignas | while with the addition of a dashboard - we will have 2 factual roles - a teacher and admins/clerks | 16:53 |
| th1a | Ah. | 16:53 |
| th1a | Well, use your judgement. | 16:54 |
| ignas | i'll look into it | 16:54 |
| th1a | OK then. | 16:54 |
| th1a | Let's talk Infrae. | 16:54 |
| th1a | I just booked a flight to San Diego for next Tuesday. | 16:55 |
| ignas | i'll need you to review the explanation XPDL with "corrections" added some time into the contract | 16:55 |
| th1a | I'll be there for two days. | 16:55 |
| th1a | We should probably have a conference call with Infrae. | 16:56 |
| th1a | Or I guess it isn't a conference call if there are only two parties, but you know what I mean. | 16:56 |
| th1a | Discuss how this might work. | 16:56 |
| th1a | Filling in some background... | 16:56 |
| th1a | what we're considering doing is having High Tech High act directly as Infrae's client for the gradebook. | 16:57 |
| th1a | Not have everything piping through me so much. | 16:57 |
| faassen | the gradebook and whatever else they need changed to make it work for them. | 16:57 |
| th1a | Yes. | 16:58 |
| faassen | though of course if any change impacts schooltool core we will discuss this. | 16:58 |
| th1a | RIght. | 16:58 |
| faassen | what I'm hoping for is that the real world input will help streamline bits of ST. user interface definitely I hope. | 16:58 |
| th1a | So... in the meantime. | 16:58 |
| th1a | Yes. | 16:59 |
| mgedmin | that would be very nice | 16:59 |
| th1a | It will still take a while to get the gradebook stuff ramped up for Infrae, between getting HTH ready to go and srichter finishing some big changes we discussed yesterday (and hopefully he can explain shortly). | 16:59 |
| th1a | So I'm going to write up demographics stories for Infrae. | 17:00 |
| faassen | okay. :) | 17:00 |
| th1a | Which should be quite straightforward. | 17:00 |
| th1a | And I should be able to have done tomorrow. | 17:00 |
| faassen | okay, then I hope to be able to start some work on that second half of this week. | 17:01 |
| th1a | srichter: Do you want to summarize the changes in the gradebook you came up with? | 17:02 |
| th1a | faassen: Excellent. | 17:02 |
| srichter | aehm, I am not sure I can do that at this point without saying next week, I changed my mind :-) | 17:02 |
| th1a | OK, I have a question then. | 17:02 |
| srichter | the basic idea is that the gradebook should not be directly coupled to the requirements tree | 17:03 |
| srichter | but have an abstraction called grading items | 17:03 |
| srichter | requirements will be wrapped to be grading items | 17:04 |
| th1a | You mentioned last night that this might allow cells to do calculations? | 17:04 |
| srichter | this allows us to have a grade book that is independent of the requirements tree, which is what we need to fulfill all use cases | 17:04 |
| srichter | yes, so one special type of grade item would be one that does some calculation | 17:05 |
| th1a | So might the user be able to enter calculations like in a spreadsheet? | 17:05 |
| th1a | Thus have some of the weighting, etc, just implemented that way? | 17:05 |
| faassen | I'd recommend against user programming abilities in schooltool. | 17:06 |
| faassen | that's opening up quite a bit of issues security-wise alone. | 17:06 |
| faassen | (and maintenance) | 17:06 |
| srichter | right, no user programming | 17:07 |
| th1a | Well, I don't know if it would have to qualify as user programming to be useful. | 17:07 |
| srichter | we will code the computation ourselves | 17:08 |
| srichter | we would just provide choices, if available | 17:08 |
| th1a | So could we do this: | 17:08 |
| th1a | Teacher keeps their exam scores in the gradebook during the term. | 17:08 |
| faassen | it'd already be nice to allow us to implement calculationsl ike in a spreadsheet, sort of. plug in different calculation abilities at least. | 17:08 |
| th1a | At the end of the term, the final grade is magically added as a column to the gradebook. | 17:09 |
| th1a | The teacher selects the final grade column, tells it to average all the exam scores and apply the school grading scale. | 17:09 |
| * tiredbones BOOKMARK | 17:10 | |
| th1a | Gets the final grades automatically computed. | 17:10 |
| th1a | And can still manually change them if desired. | 17:10 |
| srichter | something like that yes | 17:10 |
| th1a | OK. That's what we want. | 17:11 |
| th1a | Roughly. | 17:11 |
| th1a | Making it feel spreadsheet-y is good, I think. | 17:12 |
| th1a | Also srichter and I worked out how events will mark the passage of terms. | 17:13 |
| srichter | we just have to hide a lot of the computation complexity from the teacher | 17:13 |
| th1a | Basically, each term (year, semester/trimester, marking period) will have a standard set of events. | 17:13 |
| th1a | setup, begin, end, close, teardown. | 17:14 |
| faassen | setup and teardown? | 17:14 |
| faassen | what's the difference between end, close and teardown? | 17:14 |
| th1a | Setup indicates that you're actively beginning to work with the term. | 17:14 |
| faassen | who is 'you'? | 17:15 |
| th1a | It is simply there so that if you, the school administrator, | 17:15 |
| ignas | end - the time when term ends, close - the time when you finish all activities associated with the term, teardown - when term is archived ? | 17:15 |
| faassen | that would require an explicit archiving event, instead of terms being automatically archived just because the 'current' state moved forward. | 17:15 |
| th1a | want to set up terms for the next three years for some reason, the 2009 year won't be cluttering up your interface. | 17:15 |
| th1a | Or at least that's what we were thinking. | 17:16 |
| faassen | so setup is basically publishing it? | 17:16 |
| th1a | In a sense, yes. | 17:16 |
| faassen | so an event can be unpublished and then published. it has a date range during which we're actually in the term. I don't know what 'closing' means. | 17:16 |
| faassen | I guess unpublished. | 17:17 |
| faassen | anyway, and what do these events do? | 17:17 |
| faassen | these are calendar events? | 17:17 |
| th1a | 'end' is specifically the end of classes. 'close' is the end of active use of the terms, for example, when the grades have all been submitted. | 17:18 |
| th1a | Zope3 events. | 17:18 |
| th1a | Well, for example, you might only want the final grade added to the gradebook at the end of the term. | 17:18 |
| faassen | concerning archiving, I hope we can archive things without having to move them anywhere, like between folders or whatever. | 17:18 |
| th1a | faassen: Well, that's an open question. | 17:19 |
| th1a | It certainly gets beyond my understanding of the ZODB's performance characteristics. | 17:20 |
| faassen | it's not just performance. | 17:20 |
| srichter | it all depends on how meaning ful your names should be | 17:20 |
| faassen | it's just somewhat easier to reason about unmoving data, sometimes. just change the view on the data instead. | 17:21 |
| th1a | Maybe what we really need to do is make sure we're putting the data in the right place the first time. | 17:22 |
| faassen | you can always off a view on the data that's moving. the data itself doesn't have to go anywhere. | 17:22 |
| th1a | Like sections should always be contained by a term perhaps. | 17:22 |
| faassen | not off, offer. :) | 17:23 |
| th1a | Which reminds me of one last thing... | 17:24 |
| th1a | We're not going to twist POV's arm until they use it, but it certainly looks like a catalog will be needed for the gradebook. | 17:24 |
| th1a | So would we have one catalog object that has multiple indexes? Is that how it works? | 17:25 |
| faassen | if you're indexing a certain type of object, typically you'd have a catalog with a number of indexes for it in there. | 17:25 |
| faassen | I know the innards of the z3 catalog a bit so feel free to ask me questions. | 17:26 |
| th1a | OK... each component will need its own catalog, since they're meant to be independent. | 17:26 |
| srichter | concerning placing things: let's not move things too much around right now; we have other problems to solve; I think we can revisit this, once we have some time to breathe | 17:26 |
| faassen | also I'd recommend we adopt the hurry.query component as that makes querying the catalog a lot easier. | 17:26 |
| faassen | srichter: sounds good. just don't want to start moving stuff more. :) | 17:26 |
| th1a | srichter: Yes, we won't move the earth under your feet. | 17:26 |
| srichter | my brain is hurting from all the requirements Tom dumped on me yesterday | 17:27 |
| srichter | :-) | 17:27 |
| th1a | My brain hurt yesterday from all the requirements I conceived yesterday. | 17:27 |
| th1a | Actually, srichter, here is part of the reason it felt so complicated. | 17:28 |
| th1a | What we're trying to do now is to integrate ALL of the evaluations into a unified framework. | 17:28 |
| faassen | th1a: my brain hurts too when I think about ST requirements. | 17:28 |
| faassen | th1a: that's why I so desperately want to connect it to a complete customer goal. :) | 17:28 |
| th1a | Which is the right way to do it. | 17:28 |
| *** jinty has joined #schooltool | 17:29 | |
| th1a | Whereas, we could also say, "this progress report is just a special annotation on the student," make up a form and voila! | 17:29 |
| srichter | I am confident that we will have a really solid story by next week | 17:29 |
| th1a | But by trying to keep this all in one requirement/assessment framework, it should be much better for querying/reporting/analysis down the road. | 17:30 |
| th1a | More flexible and powerful. | 17:30 |
| ignas | th1a, will you want anything except for "correction" work items in the attendance dashboard ? | 17:30 |
| th1a | ignas: I think there is one more. I'll look at the stories. | 17:31 |
| th1a | OK, time's up. | 17:31 |
| th1a | Thanks for coming folks. | 17:31 |
| * th1a strikes the virtual gavel. | 17:31 | |
| faassen | okay, thanks Tom. :) | 17:31 |
| * mgedmin waves bye | 17:31 | |
| ignas | th1a, so when will you send a summary for the dashboard story for me to estimate ? | 17:34 |
| th1a | An hour? | 17:34 |
| ignas | ok | 17:35 |
| ignas | and what about the new story srichter has started working on ? | 17:35 |
| th1a | srichter: Can you shoot a copy of that to ignas? | 17:36 |
| srichter | the term stories? | 17:36 |
| th1a | Specifically the section API? | 17:36 |
| th1a | Is there enough detail in that to make sense to him? | 17:37 |
| *** mgedmin has quit IRC | 17:40 | |
| srichter | yeah | 17:42 |
| srichter | it is very little | 17:42 |
| srichter | I have not looked in detail at it, but we know about the "get all students" thing already | 17:42 |
| srichter | I think we walso have to review whether we want to support adding groups | 17:43 |
| srichter | I think it is not needed | 17:43 |
| th1a | Adding groups to sections? | 17:44 |
| th1a | It is needed for elementary schools and any form-oriented system like Lithuania's. | 17:44 |
| srichter | oh, good point | 17:45 |
| srichter | I wonder whether adding a group should just be treated as add all students in this group | 17:45 |
| srichter | but then you could not add a student to form 1 and have it appear in the section | 17:46 |
| th1a | Right. | 17:46 |
| srichter | on the other hand it is questionable how useful it is | 17:46 |
| th1a | srichter: It is necessary. | 17:46 |
| srichter | if you have a larger school, you will have multiple math sections for form 1 | 17:46 |
| srichter | ok, so then we just need a convenience method to get all students | 17:46 |
| srichter | in fact, I would hide any other direct data access | 17:47 |
| th1a | Yes. | 17:47 |
| th1a | ignas: OK, just sent you a mail. | 17:55 |
| *** ignas has quit IRC | 17:56 | |
| *** ignas has joined #schooltool | 18:05 | |
| *** faassen has left #schooltool | 18:10 | |
| ignas | th1a, so dashboard will contain day tardies/absences and correction requests, both as viewlets | 18:10 |
| th1a | Yes. | 18:10 |
| ignas | ans srichter will send us one more story to be included in this contract ? | 18:12 |
| ignas | s/ans/and | 18:12 |
| th1a | srichter: is that happening? | 18:16 |
| th1a | Or do you want to send it to me to finish? | 18:16 |
| srichter | what stories again? | 18:19 |
| srichter | The session one is trivial | 18:19 |
| srichter | provide an API call that will return all students | 18:20 |
| *** carljm has joined #schooltool | 18:20 | |
| th1a | Isn't there a problem getting the instructors for a section? | 18:21 |
| th1a | ignas: For the sake of your sanity, I think you can assume you've got all the stories. | 18:21 |
| th1a | srichter and I can figure out what we're talking about later. | 18:21 |
| *** ignas has quit IRC | 18:32 | |
| *** ignas has joined #schooltool | 18:53 | |
| *** mgedmin has joined #schooltool | 18:55 | |
| povbot | /svn/commits: * srichter committed revision 5787: | 19:02 |
| povbot | /svn/commits: Added Comment Score System. | 19:02 |
| povbot | /svn/commits: * srichter committed revision 5788: | 19:08 |
| povbot | /svn/commits: Create a branch for my work. I expect that I will be breaking the code heavily all over the place, but I first want to finish the unit doctests before implementing UI and other necessary fixes. | 19:08 |
| ignas | th1a, maybe you could tell me when is the next deadline ? | 19:16 |
| ignas | so i could estimate the time we will need for irc meetings/bug fixing | 19:17 |
| ignas | s/bug fixing/overhead | 19:17 |
| ignas | though i guess you should see stories and estimates first | 19:18 |
| th1a | I think you need to tell me when you can have it done. | 19:18 |
| ignas | what do you think of april 11 ? | 19:27 |
| ignas | optimistic | 19:29 |
| th1a | That's a good date. | 19:29 |
| ignas | i didn't think about the preparation for releases | 19:29 |
| ignas | will there be any ? | 19:29 |
| th1a | We need to do the first serious release of SchoolTool 2006 around the end of April. | 19:30 |
| *** regebro has joined #schooltool | 19:30 | |
| regebro | Hi, I'm trying to make a testcase (in Zope2) that uses a specific ZODB. | 19:30 |
| regebro | srichter said you had done something like this in schooltool | 19:31 |
| ignas | now that i have consulted with others, April 18 for completion of this contract, which leaves us with ~2 weeks for the release sounds less risky | 19:31 |
| regebro | but all I found was one test that doesn't really use a testcase at all... | 19:32 |
| ignas | this contract is going to be difficult on user interaction stuff, as some parts are tricky to design properly ... | 19:32 |
| regebro | which is the db-conversion-test. Have you done something else that I can't find? | 19:32 |
| srichter | no, that was the one I was referring to | 19:33 |
| srichter | but you could easily convert this to a unit test | 19:33 |
| regebro | OK, that's what I suspected, srichter. | 19:33 |
| regebro | No, it copies that database to a temp directory, goes there and starts the server. | 19:34 |
| srichter | you can do this in a unit test | 19:34 |
| regebro | There is no way I can make that into a unit test, at least not under Zope2. | 19:34 |
| srichter | I don't know about Zope 2 | 19:34 |
| srichter | it's definitely not a problem in Zope 3 | 19:35 |
| srichter | we do this all the time by bringing up all of the ZCML stuff for functional tests, for example | 19:35 |
| regebro | Not with a custom zodb. | 19:35 |
| regebro | Don't know why it works in Zope3, but there you go. :) | 19:36 |
| regebro | In Zope2 there is the ZopeTestCase that makes some serious magic to use a DemoStorage. I've been trying to hook into that, and completely failing. | 19:37 |
| srichter | why should it not work? all you have to do is bring up the server in Python neglecting the config file | 19:37 |
| regebro | No, I need to somehow make me own config-file, I think. | 19:37 |
| srichter | yeah, the problem is that Zope 2 can really only do functional or integration tests | 19:37 |
| srichter | ZopeTestCase brings up far too much | 19:37 |
| srichter | but it has to, because everything is coupled to everything else | 19:38 |
| regebro | Yup. | 19:38 |
| srichter | mmh, I guess the best choice would be not to use ZopeTestCase, though then other stuff might not work | 19:38 |
| srichter | sigh | 19:38 |
| regebro | I have no problem makig a DemoStorage, that wraps my Data.fs in readonly mode. But I just can NOT get the app to use it. :/ | 19:38 |
| regebro | I tries without ZopeTestCase too, still have no idea how to do it. Ah well. | 19:39 |
| regebro | It's evidently a pure Zope2 problem. | 19:39 |
| regebro | I was hoping that the technique you used would work for me, but it doensn't..... | 19:39 |
| regebro | Thanks anyway.... (and now back to the regular program) | 19:40 |
| *** regebro has left #schooltool | 19:40 | |
| srichter | mgedmin: how do I generate the current datetime with a timezone | 19:51 |
| *** mgedmin has left #schooltool | 19:51 | |
| *** mgedmin has joined #schooltool | 19:52 | |
| srichter | mgedmin: how do I generate the current datetime with a timezone | 19:52 |
| mgedmin | grr, I hate this bug: http://bugzilla.gnome.org/show_bug.cgi?id=333744 | 19:52 |
| mgedmin | srichter: import datetime, pytz; return ptz.localize(datetime.datetime.utcnow()) | 19:52 |
| mgedmin | assuming you want any timezone | 19:52 |
| srichter | well, you left me a big XXX :-) | 19:53 |
| mgedmin | and utc will do | 19:53 |
| mgedmin | if you want some specific timezone, I think you have to do | 19:53 |
| srichter | yeah, any timezone will do; it's just to keep ST happy | 19:53 |
| mgedmin | return pytz.localize(...utcnow()).astimezone(othertz) | 19:53 |
| srichter | I don't want the schooltool.requirement package to depend on the SchoolTool application settings | 19:54 |
| srichter | mmh, pytz.localize not found | 19:55 |
| srichter | ok, got it | 19:56 |
| srichter | pytz.utc.localize | 19:56 |
| srichter | makes more sense too | 19:56 |
| *** Aiste|away is now known as Aiste | 19:59 | |
| srichter | th1a: are you ready to answer some tough questions about multiple evaluations? :-) | 19:59 |
| srichter | th1a: Never mind, I think I will be okay for now | 20:05 |
| th1a | srichter: What have you got? | 20:20 |
| *** ignas has quit IRC | 20:21 | |
| *** thisfred has left #schooltool | 20:41 | |
| *** jinty has quit IRC | 20:45 | |
| *** vidasp has quit IRC | 20:54 | |
| srichter | th1a: oh, I just finally gave up storing evaluations as a mapping | 21:15 |
| srichter | Bummer, but it is the right thing to do | 21:15 |
| srichter | I am now using a flat list | 21:15 |
| th1a | Gave up? | 21:16 |
| srichter | but this will make chaining of Evaluation query adapters easier | 21:16 |
| th1a | Gave up on last night's idea? | 21:16 |
| srichter | yep, I tried hard to support multi-evaluations in a sensible manner keeping the mapping API | 21:17 |
| srichter | no, last night's idea on grade items stands | 21:17 |
| srichter | I totally love it | 21:17 |
| th1a | I'm not sure what you mean by a mapping. | 21:17 |
| srichter | in the original implementation evaluations were stored as mappings (dictionaries) from requirement -> evaluation | 21:17 |
| srichter | now we decided we want to have multiple evaluations for a requirement, so: requirement -> [eval1, eval2, ...] | 21:18 |
| th1a | Where are the evaluations contained? | 21:18 |
| srichter | unfortuantely, the Python mapping API is not very useful once you have a mapping to a list | 21:19 |
| srichter | IEvaluations(Person) | 21:19 |
| th1a | I see. | 21:19 |
| *** jinty has joined #schooltool | 21:47 | |
| srichter | I think that Paul will really hate those changes :-) | 21:47 |
| th1a | We may have a fork. | 21:48 |
| srichter | naeh, not because of the evaluations API | 21:49 |
| srichter | if he really wants the high-level functionality he can add it to his code | 21:49 |
| srichter | like we write our custom requirement and evaluation implementations | 21:49 |
| povbot | /svn/commits: * srichter committed revision 5789: | 22:15 |
| povbot | /svn/commits: - Implemented inherited requirement interface. | 22:15 |
| povbot | /svn/commits: - Refactored evaluations storage. Made it much simpler and allow for | 22:15 |
| povbot | /svn/commits: multiple evaluations of a requirement. It is up to the packages using this code to add more semantics adn high-level APIs to this implementation. | 22:15 |
| povbot | /svn/commits: Paul, I know you are not going to like this new way, but I suggest you implement the former API in your code and add the necessary semantics. | 22:15 |
| *** ignas has joined #schooltool | 22:33 | |
| *** alga has quit IRC | 22:39 | |
| tiredbones | clear | 22:40 |
| tiredbones | ls | 22:40 |
| tiredbones | sorry | 22:40 |
| th1a | srichter: We're going to have to do a schooltool.commendation screencast. | 22:41 |
| tiredbones | When zope3 is first installed is the directory ~/zope3/etc/package-includes created or do I do create that? | 22:45 |
| srichter | th1a: ok, if you have the technology and do the talking :-) | 22:46 |
| srichter | I'll do it in German :-) | 22:46 |
| srichter | th1a: btw, why did you think of it now? | 22:47 |
| th1a | Just watching that big web frameworks screencast. | 22:47 |
| srichter | yeah, it is really nice | 22:48 |
| mgedmin | tiredbones: it is created when you run mkzopeinstance | 22:48 |
| mgedmin | (if you're using instances instead of just the subversion checkout) | 22:48 |
| tiredbones | mgedmin, thnks | 22:49 |
| tiredbones | srichter, In your book on ch13 I don't see where you indicate we have to run mkzopeinstance. | 22:52 |
| srichter | chapter 13 is not about installing Zope 3, but about building a first application | 23:04 |
| srichter | I am pretty sure that mkzopeinstance is mentioned in the installation chapter | 23:05 |
| carljm | srichter: what's the url for that book? | 23:13 |
| *** alga has joined #SchoolTool | 23:13 | |
| tiredbones | carljm, google zope3book | 23:14 |
| carljm | seems it's the same one i'm already reading, but I don't see any chapter 13 | 23:15 |
| carljm | just sections a,b,c,d.. | 23:15 |
| srichter | chapter 13 is the first chapter in section C I believe | 23:17 |
| srichter | it is the first chapter of the messageboard package | 23:17 |
| carljm | yeah i see, sorry, stupid question. the TOC just doesn't list things by chapter # | 23:18 |
| tiredbones | carljm, If you want the code I beleave you have to use the svn version. | 23:19 |
| carljm | tiredbones: what's the svn: url? - i'm trying what's listed on the website and keep getting "no repository found" | 23:25 |
| *** carljm has quit IRC | 23:30 | |
| *** ignas has quit IRC | 23:38 | |
| *** jinty has quit IRC | 23:43 | |
| *** mgedmin has quit IRC | 23:56 | |
Generated by irclog2html.py 2.15.1 by Marius Gedminas - find it at mg.pov.lt!