After getting schooled in class last Wednesday our teams quickly created stronger lines of communication and a hierarchy of leadership, so that we know who to report to, and if that person becomes unavailable, who to go to next. Now that Will is back in town this hasn’t really been a problem, but it’s a comforting thing to have in place.
Even though our team was clearly not as organized or communicative as the other one, this was a major wake-up call for me. It never really struck me how much we look for the leaders around us. I would have assumed that someone would have stepped into the role when there was no one in it, and yet no one did. That includes me too – I realized we had no overall leader and did not do anything about it. Some people didn’t want the responsibility, some people were scared of it, and some, like me, just sat back and did nothing.
I’m actually glad I learned this in this class and not, say, in a work environment. It’s taught me that if I’m not nervous or hesitant to take a leadership role, and the role is called for, that I should just step up and take it, rather than waiting for someone else to. Because that someone else quite possibly won’t show up, or may just be waiting for someone else to take it, like I was.
We’ve all been playtesting the hell out of the program, and it looks like we’ve found a bunch of bugs in it. I think I may have found one too, so I think we’re all set to be done on Wednesday.
I have implemented the collide* functions in our Playfield class. I imagine they work – we either need to create some unit tests, or just get the Player class from the other team and test with that.
I also implemented the placeBoxes() function, which changes the moving Piece into the static block in the grid. I put some debug Assert() calls to make sure the blocks are actually empty. I dunno, it seemed a little easy, but maybe that’s just because we shouldn’t get to that function unless the hard work has already been done.
I think my internship is helping me get the flow of working in a group like this. I’m not worrying about the project as a whole – I’m just focusing on the work my team has been assigned. It’s a lot easier to let everyone do their own share and not worry about every little thing.
I’m still very happy with the work we did in class last Wednesday – I think our planning did well.
We met for class on 10/30 and Prof. Keenan pointed out how poorly our non-designing was going to work for us. So a few of us in the group spent the break talking about our design. We did this until it was time to do class again, and Prof. Keenan was nice enough to end class at about 8:15 so we could continue our work.
It was extremely fruitful. We made an actual design for the game, which just in and of itself was a good thing. Even more beneficial, in my opinion, was that we figured out how to break it up into three concurrent groups of classes. Each group can do their work, and each of them should be able to test the work they’ve done without having to replicate any work from the other two groups. I’m sure there will be a tiny bit of replication necessary, but I think we’ve got a solid plan for concurrent work here.
This is something that I actually was not quite sure we were going to be able to pull off. Classes have to interact, I don’t think every class in a system can be 100% decoupled, right? I mean, someone has to know about the other classes somewhere.
But still, we grouped them into what seems an effective set of three groups. Our team has the PlayField itself, which makes up the grid of spaces and the blocks already settled in it. It will also handle the collision system – it will tell the movable piece if a move it wants to make is valid or not.
This grouping is also responsible for taking the moving piece when it settles and making its blocks part of the unmovable mass of blocks in the grid. So we can actually fill our grid by calling this function many times. So it’s perfectly testable without a movable block. I love it.
I have to work the day after class, which stinks because that’s typically the day I’m most motivated to work. But nonetheless, I know my team is already eager and running, and I’m going to start looking for things to do too.
-Slightly optimized our delete() function. Before, it would walk the entire linked list, even if the node had already been deleted. Now, instead of using a for loop to do that walking I’m using a while loop, so it’s easy to break out once the node has been found. (This assumes each node name is unique, which is part of the spec.)
-Carefully walked through the spec for the Trie data structure. It seems overly complicated, I believe a PCSTree would be easier to implement. I may try that first, and then see if I can rig it into their spec. I would rather have a working class than get bogged down in a spec that’s overly complex….
-I’m realizing right away that having a Trie class to encapsulate the whole idea, and then actually using the TrieNode class as individual nodes in the Trie is a good idea. The PCSTree I’m modeling this after did something like that, it had nodes and then a wrapper class to go around them. Still not seeing much use for the TrieNodeList class though….
-I have the TrieNode::Insert() function operating smoothly. I don’t think I have the unit tests 100% robust, but we’re passing everything that Team 1 sent us for this function, and it feels pretty good to me for the time being.
-Both the insert() and the getNode() functions are now implemented. It appears from the unit tests that they run correctly. The next step will be to implement this class into our Spin class, which may be more than trivial… or it may not, I’m not sure at the moment. I’m nervous to dive into that because I believe other people in the group are currently working in that class and I’m not sure where.
Our group’s assignment was to take a design of a spin list from one team in our class, and implement it. After our meeting last night, it turns out that the spec includes a trie structure to make finding a list of inputed words easier.
When I looked at the trie structure it reminded me of the PCSTrees that I made way back in GAM 475, and is a much simpler idea than what they tried to spec out.
So… since we’re having trouble understanding their spec, I’m just going to build this in a PCSTree style, in order to get it working. From there I will worry about the spec. I’d much rather have a working project than one that isn’t, even if the working project isn’t quite the spec.
I have a suspicion that the simpler PCSTree will be faster than what they’re trying to do anyway, but we’ll see.
I’m back from my wedding and honeymoon, and not a moment too soon. I had a ton of fun, but with two grad classes to deal with, I couldn’t be away for a terribly long time. My team totally stepped up on our second project and has covered for me, so I’ll see how I can help, but I’m not as far behind as I would have been with this project. Great!
Okay, I have to admit, I did not understand the code last week.
I have now replaced two of the three unit tests I have done because the ones I originally picked were way too hard.
A big part of this is that I’m getting married in three days and have a ton of running to do, so I’m feeling fairly stressed about the whole thing. So work is progressing, but it’s hard to concentrate.
That said, I will be sure to finish this project before the wedding, which pretty much kicks off Thursday morning. If it’s not done then, it won’t get done. So this will certainly be done by then – by the end of today, barring something unforeseen.
The easiest function I decided on was the DeflateZipFile::ReadBytes function. Seems pretty simple – only seven lines, and it’s just reading a buffer of bytes. How hard can this be?
Turns out it can be pretty hard. The biggest problem is that I have a line in the function that refers to a ReadFile object that is initialized deep in the class when this function, along with several other functions, initializes and then destroys it.
So I’m having a little trouble figuring out how to do this. I may just need to swap this function out with another one. I haven’t decided yet, but I’d like to work on this one a little more before I give up on it. Maybe something will clarify itself.
I haven’t had a chance to talk with most of my team yet – we’ve all updated our contact info, and I emailed with Deonte a little bit, but I think our timing has been odd so far.
I had a hectic weekend, so I wasn’t able to get any work done. I’m guessing that’s when most people would be free.
So since I didn’t see any sign of activity on the wiki or Piazza, I emailed everyone saying I would be happy to assume the role of Team Lead for this project. As such, I did the following:
- Updated the wiki’s project description with a timeline for the things to get done by Wednesday.
- Added the test project to our team solution
- Chose my own 4 functions to write tests for
I think that’s mostly it for me. The other team members will need to write their tests, and we need to work out the best way for all of us to communicate. But I’m hesitantly ready to say I’m mostly done until class on Wednesday, other than possible communications, which I will respond to asap.
Well, maybe not mastered, but I have finished the second homework project where we got our hands dirty with Perforce branching and merging.
It got a little tricky, but it’s not too hard. I think the first step is to learn the terminology of Perforce – what exactly does it mean by resolving files, merging them, branching them, integrating them. This is actually pretty tricky – I read most of the Practical Perforce book back in winter, so that process taught me what many of these words meant from a technical standpoint.
Once a user has those words understood, Perforce tells you pretty clearly what you are about to do, so ‘all’ you need to do is follow the instructions on the screen. They explain – in their Perforce terminology – exactly what is happening.
So those two steps aren’t easy necessarily, but thankfully for me, I read the Practical Perforce book awhile ago, so it wasn’t too terribly difficult to follow the directions. I’ve never branched or merged before, but I had a theoretical understanding, and with the instructions that Perforce gives as I moved along, I was able to follow things fairly easily.
Onto the next project!