3081 tag:blog.lib.umn.edu,2012-03-05:/kirc0126/myblog//15973 2012-03-08T20:05:04Z Movable Type Enterprise 4.31-en Iteration 1 Thoughts tag:blog.lib.umn.edu,2012:/kirc0126/myblog//15973.345442 2012-03-09T00:42:08Z 2012-03-08T20:05:04Z Overall, Iteration 1 went fairly smoothly for my partner and I. We both had done work with regular expressions before, although not in C. I've also done a reasonable amount of programming in C and a little in C++, although... kirc0126 Overall, Iteration 1 went fairly smoothly for my partner and I. We both had done work with regular expressions before, although not in C. I've also done a reasonable amount of programming in C and a little in C++, although its been a while. That's not to say it went perfectly- it was slightly tricky dealing with pointers and the regular expressions. Most of the time spent on that part was designing how we'd organize the regular expressions and apply them to our scan input. There was minor issues elsewhere, but most of the debugging done was dealing with how we handled the regular expression/input interaction.

One thing that we found to be helpful was to try to break up large functions into smaller sub-functions. This made it easier to test and if tests failed, to pinpoint the point of failure within the sub-function.

The biggest challenge with Iteration 1, was not so much on the code side, but was dealing with the scanner_tests.h file. Not running or compiling it, but the fact that with that particular file, it wasn't possible to use a debugger (such as gdb) to step through the scanner code. While unit tests can tell you which function or method is failing (or individual regular expression, as the case may be), its hard for them to tell where in the function its failing- which is where an effective debugger can come in handy. I know that learning to write unit tests, and using them are important, but using a debugger is also an important skill. I understand that by preventing us from using a debugger we are almost forced to get better at writing unit tests, but it also seems foolish to limit the size of the toolbox we can work with.

As far as teamwork goes, I found that using subversion to be extremely helpful. I use a different software package for version control at work, which integrates with my IDE that i use. The subversion CLI was relatively clunky and could be unreliable at times (there were a few merge issues, but nothing serious), but having access to a repository was worth the headaches that the interface could cause. Working with subversion was a lot better than emailing code back and forth like I've done on previous collaborative software projects. It also helped that my partner is a coworker of mine- so we're in frequent communication anyway.

Moving forward, I think the biggest change will be to try to divide functions into even smaller pieces and write lots of different tests for them. I think if we had done a better job writing tests we would have been able to figure out the issues we had with our regular expression/input text interaction sooner.

]]>