It was only after Iteration 1 was complete did I realize how much I didn't understand going into it. Not only did the translator turn out to be far more complicated than my mental pseudo code had indicated, but the amount of creative thinking required to solve the regular expression puzzles was far greater than I had imagined. Although my partner and I felt we had understood the labs we had completed up until that point, a much higher level of understanding was necessary for the implementation of Iteration 1. As a whole, even though what we are working towards in Iteration 2 and 3 might be a more complex system, I feel as though Iteration 1 will be the most challenging of the steps in completing this project, just due to the amount of ignorance I was unaware I had.
After the first two labs, my biggest issue was svn. The svn lab itself was very guiding, telling us what to type in, and pointing out details for us to take note of. The questions it required us to answer were also very useful in what they were trying to make us understand. It required us to figure out what the symbols meant when svn tried to communicate with us, the users. The issue I ran into was an incomplete picture of what svn was actually doing. I understood the concept of a server somewhere, storing shared files that we could download to a local system to edit. I understood that we could only upload our changed files if those files didn't overwrite any changes made by someone else with access. The issue I ran into was the actual manipulation of the files locally. I was one of the "troubled children" who screwed up their local copies by attempting to copy and paste full directories to and from my group's root folder. I actually had this happen twice, as I had mistakenly thought that I had understood the cause of the first file mix-up, only to later learn I understood very little. While the TA's fix was both needed and appreciated, it did not add to my understanding of what was causing the issues. So while the questions being asked in the svn lab were directing us towards important pieces of knowledge, I feel it would have been more effective to tell us straight forward what was going on, and to ask us if we understand at a later point.
When it comes specifically to the completion of Iteration 1, the least painful way to complete it would be to have competed and understood the preceding labs. I'm not saying I didn't complete the labs, but it isn't difficult to get someone else's code to run properly if we are only adding a specific element to the code. I was able to complete the labs, understand what it was I added, and still not fully understand the rest of the implemented code. Well, it turns out those labs were actually teaching us something. Specifically, an understanding of how lab 3 worked was essential to understanding how to build our scanner for iteration 1.
Working in pairs actually worked rather well for this Iteration. Any more people and I feel as though you wouldn't have your hands in all the important pieces of the project, but working by myself, I never would have figured out how to accomplish what we did. My partner and I drew up on paper how we imagined the scanner to work. This helped us have a picture of what was needed to be accounted for early in the coding. For the design and construction of all the objects and classes, my partner and I went out of our way to work together, in person, on the same computer. This was so we could be on the same page as we designed independent working pieces that effected our objects. We designed what our regular expressions would look like, how our scanner would read, and where we would put our test cases. Once this chore was complete, we were able to split up and work through email, skype, and svn. We didn't need to worry about compatible code, because at that point, we were merely working on specifics. We already knew everything was compatible, because we designed it together. I worked primarily on the regular expression definitions, while he worried more specifically about the scanning, reading, and special cases involved in doing both. This is where svn proved itself useful. I was able to edit the regular expressions, adding comments, definitions, and tests, all while my partner was editing the same file in a different location. We were able to consistently merge our changes and view each other's comments, as well as run each other's tests. This was key once we ran into errors upon trying to run our code. I was able to write test after test for a problem, while my partner was able to run the tests and try and analyze what they told us about our broken code.
The one issue we ran into that was frustrating beyond belief, was with our implementation of our backslash "\" regular expression. It failed my tests, it failed the tests provided to us, and yet, everything indicated we had defined our regular expression correctly. We attempted to use Piazza, parsers, more test cases, and yet nothing seemed to result in a suggestion that either the tests, or the regular expression was incorrect. Eventually, we deleted the "\" in all the test cases, and replaced it with the exact same symbol, thinking that maybe the field itself was screwed up somehow. It turned out that this was the solution. Our regular expression was correct the entire time. The issue was that, for some reason, the "\" character in all the tests was analyzed as being different than what it was. I'm still not sure how this happened, or why, but now I know to try everything when code like that is broken. This is about as frustrating as an error can get though.
For iteration 2, we are going to start earlier, and make sure we have a complete understanding of the labs upon beginning. Svn should no longer be an issue. Though it was a hassle to learn, its uses are now apparent to me. At no point do you need to sit down and attempt to memorize the inner-workings of svn. You will use it enough, that by then you finish Iteration 1, you will have all the commands you need to know, memorized.
