![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
lance_sibleyOkay, I'm done with winter. It can go away now. Not being able to see in broad daylight because the wind is blowing the snow horizontally into my eyes? Not. Fun.
I left work about 15 minutes earlier than usual to be sure of catching the bus that usually goes by when I'm about halfway to the stop. It's a good thing that I did, because I still only managed to get to the bowling alley about 15 minutes before our start time. (Bridgette didn't show up until the end of the first game, and she was coming from within Toronto.)
My first game started well, with two spares and a strike, and then I went into some kind of funk - I had five open frames in a row. I managed to come out of it at the end, but it was too late to rescue my score. (I would have needed to finish with four consecutive strikes to get my average.) The second game went much better, and the third game better still, except for the tenth frame. I left the 4-pin on my first ball, which normally is an easy spare for me. I overthought it, though, knowing that the game was close, and I threw the ball a touch too hard, missing on the left. (That's not easy, missing the 4-pin on the left and still keeping the ball on the lane.) We ended up losing the game by one measly pin when their #5 bowler got a strike in the tenth and Mario didn't.
My scores for the night: 138, 169, 176. Overall, I'm not displeased with those last two games, except for the final frame when I choked.
This week at work has been productive. I've been working on adding some new privileges to our system, so that users can be allowed to (or prevented from) performing certain functions. It would be easy in a mainframe system, because they're transaction-based; you would just grant permission to the appropriate users to execute certain functions, and the security framework would do the rest. In our system, however, everything has to be coded specifically into the pages and the stored procedures that manipulate the data. (For instance, if a user doesn't have the privilege to view administrative applicants, the search procedure has to have code to check the privilege table before returning - or not returning - those applicants in its result set.)
Most of the work was fairly straightforward, and I got it done last week. There was one privilege, however, that was phrased "Only Search For Approved Occasional Teachers." I asked our client what this meant, and was told, "They should only be allowed to search for approved occasional teachers - not full-time, part-time or contract, and not administrative applicants. Also, they can see the approved occasional teachers, but they should not be allowed to do anything with them." All in all, it required changes to seven stored procedures, three data access modules, and ten pages within the site, plus there are four other pages that didn't have to be changed but which will have to be tested.
One of those stored procedures - the one that executes a search based on criteria entered by the user - is something like 2500 lines in length. And because of the way it's written, as well as the way our searches function, it's extremely complex; the search page is divided into sections, and if none of the options within a section has been selected, then every applicant has to be returned. (For instance, if the user doesn't select one of full-time, part-time, contract or occasional, then that criterion is excluded from the search.) The problem lies in the way it was written - rather than using IF statements, there are WHERE clauses in the SQL which test the value of the search criteria variables. It's completely anti-intuitive and makes figuring out how to change the procedure take about three times longer than it would otherwise. Oh, and the procedure contains multiple steps - first it returns all of the applicants who have applied to the board that's doing the search, then it returns the subset of those who have selected the job types (full-time, part-time, etc.) that were chosen, and so forth.
It's extremely painful to try to figure it all out - which is why it took me two and a half days just to do that part of it. Never mind the other six stored procedures, ten pages, etc.
But I got it (mostly) done this afternoon. Now I just have to test the bejeezus out of the whole thing. And since there are six privileges that can interact with or override each other, and each has two states, that means I have 64 test cases to write and execute (and hope that they all work, otherwise it's back to the grind).
I emailed an Excel spreadsheet to myself before I left work which contains a partial list of some of those scenarios. I should probably find some time this weekend to come up with the rest of the combinations (easy, but tedious) and think about what behaviour I expect to see in each case.
But first, I need to figure out if I'm going out tonight. I don't have to be up at the crack of dawn tomorrow (that's Sunday), but OTOH, it's doing something outside that resembles freezing rain. Ick.
I left work about 15 minutes earlier than usual to be sure of catching the bus that usually goes by when I'm about halfway to the stop. It's a good thing that I did, because I still only managed to get to the bowling alley about 15 minutes before our start time. (Bridgette didn't show up until the end of the first game, and she was coming from within Toronto.)
My first game started well, with two spares and a strike, and then I went into some kind of funk - I had five open frames in a row. I managed to come out of it at the end, but it was too late to rescue my score. (I would have needed to finish with four consecutive strikes to get my average.) The second game went much better, and the third game better still, except for the tenth frame. I left the 4-pin on my first ball, which normally is an easy spare for me. I overthought it, though, knowing that the game was close, and I threw the ball a touch too hard, missing on the left. (That's not easy, missing the 4-pin on the left and still keeping the ball on the lane.) We ended up losing the game by one measly pin when their #5 bowler got a strike in the tenth and Mario didn't.
My scores for the night: 138, 169, 176. Overall, I'm not displeased with those last two games, except for the final frame when I choked.
This week at work has been productive. I've been working on adding some new privileges to our system, so that users can be allowed to (or prevented from) performing certain functions. It would be easy in a mainframe system, because they're transaction-based; you would just grant permission to the appropriate users to execute certain functions, and the security framework would do the rest. In our system, however, everything has to be coded specifically into the pages and the stored procedures that manipulate the data. (For instance, if a user doesn't have the privilege to view administrative applicants, the search procedure has to have code to check the privilege table before returning - or not returning - those applicants in its result set.)
Most of the work was fairly straightforward, and I got it done last week. There was one privilege, however, that was phrased "Only Search For Approved Occasional Teachers." I asked our client what this meant, and was told, "They should only be allowed to search for approved occasional teachers - not full-time, part-time or contract, and not administrative applicants. Also, they can see the approved occasional teachers, but they should not be allowed to do anything with them." All in all, it required changes to seven stored procedures, three data access modules, and ten pages within the site, plus there are four other pages that didn't have to be changed but which will have to be tested.
One of those stored procedures - the one that executes a search based on criteria entered by the user - is something like 2500 lines in length. And because of the way it's written, as well as the way our searches function, it's extremely complex; the search page is divided into sections, and if none of the options within a section has been selected, then every applicant has to be returned. (For instance, if the user doesn't select one of full-time, part-time, contract or occasional, then that criterion is excluded from the search.) The problem lies in the way it was written - rather than using IF statements, there are WHERE clauses in the SQL which test the value of the search criteria variables. It's completely anti-intuitive and makes figuring out how to change the procedure take about three times longer than it would otherwise. Oh, and the procedure contains multiple steps - first it returns all of the applicants who have applied to the board that's doing the search, then it returns the subset of those who have selected the job types (full-time, part-time, etc.) that were chosen, and so forth.
It's extremely painful to try to figure it all out - which is why it took me two and a half days just to do that part of it. Never mind the other six stored procedures, ten pages, etc.
But I got it (mostly) done this afternoon. Now I just have to test the bejeezus out of the whole thing. And since there are six privileges that can interact with or override each other, and each has two states, that means I have 64 test cases to write and execute (and hope that they all work, otherwise it's back to the grind).
I emailed an Excel spreadsheet to myself before I left work which contains a partial list of some of those scenarios. I should probably find some time this weekend to come up with the rest of the combinations (easy, but tedious) and think about what behaviour I expect to see in each case.
But first, I need to figure out if I'm going out tonight. I don't have to be up at the crack of dawn tomorrow (that's Sunday), but OTOH, it's doing something outside that resembles freezing rain. Ick.
