Alright, here it is. I know you've all been waiting for it, my inspirational blog about (drum-roll please) cxxTest. cxxTest is some software that can be used for unit testing. A unit test is when a piece of the code is tested to check if it works independently the way it should. This is very useful because this way you can check the small pieces of code as you work, and if something is wrong you can fix it right away, or at least you know where it is. If you write your entire program and then a bunch of stuff goes wrong it will take a while just to figure out where the problems are, much less fix them. I used cxxtest in Iteration 2 of the Where's The Forest!? project. It helped a lot by providing testing mechanisms that I could use to test the code that I had and make sure that it would work with the parser provided by the professor. There were a few problems at first because I didn't really know what I was doing, and it took a little while to figure out how to incorporate the tests into my code. But once I got it going it was great. The tests that I had to run were all through cxxTest and the errors that popped up helped me to pinpoint which parts didn't work, and then I just had to figure out what went wrong and then fix it. It saved me a ton of time in hunting for the problems.
Yo 'sup everyone. In case you hadn't realized this is my blog about versions control and more specifically Subversion. Subversion (svn) is a type of version control software that we are using to create a sample compiler. Version control software basically stores the past versions of files so that they can be viewed at a later date, even if the files have been overwritten. This is very useful, as when working on a large project programmers tend to make changes to their code, and sometimes these changes don't turn out to be very good. This is obviously useful because you can go back and grab a file from a time when it worked, before you screwed it all up by trying to add some feature or improve the run-time, or whatever you were trying to do. Subversion has a repository where all of the files are stored. One nice feature of subversion (and other version control software) is that you can make directories in the repository. This is rather useful as you can split up your files into different folders, such as the different projects, or different versions. For example you might want to save a version that you have working. The version is already in the repository, but you might not want to remember the version number, or the date when this version was saved. So you create a directory that holds this working copy. These working versions are called tags by convention. So we (my partner and I) created a tags folder that contains the finished working versions of our code for the different iterations. This is really nice because sometime in the future, potentially a very long time someone may want to look at the code and maybe try to improve on it. With these tags they can just look in the tags folder, and everything that's in there will work. You don't have to hunt down the correct version. Everything not stored in the tags we store in what we call the trunk, again by convention. We follow convention because we want other people to be able to understand what we did, and if we become used to this, we will be able to understand what other people have done. With svn the repository can be set up so that multiple people can access it. This is awesome because a group of people can be working on a project and everything that they do can be stored in one spot, and constantly updated. This way the programmers don't have to hunt down the other people to try to figure out what they changed and get the other versions from them. Which leads to another feature of Subversion. Whenever you try to update your copy of the files to what is in the repository, Subversion checks if there are any changes. If your copy, and the copy in the repository don't match, Subversion will try to merge the two versions if the differences don't interfere with each other. If changes have been made to the same parts of the code, then Subversion brings up an error message, and outlines the parts that are conflicting. Both the merge and the conflict features are useful because it makes it really easy to see what has changed. All in all Subversion is great.
Working with a partner on a piece of code has both advantages and disadvantages. It's great when you're stumped, or there's a piece of bug that you don't want to work on, and BAM. Your partner did it. AWESOME. In this respect its great. All that you have to do then is ask your partner to explain it to you. And then you move on. Also when you're stuck, it helps sometimes to collaborate. You can each voice your ideas, and sometimes between the two of you a solution can be created. This is usually quicker and easier than trying to figure out what's going on by yourself. Sometimes problems arise however. If you're working separately and both try to fix the same problem this can lead to conflicting updates, and a waste of time with both of you trying to working on the same thing.
When you and your partner have different ideas on what the problems and the solutions are it sucks. You think that it should look like this, your partner thinks it should be like this, and then you waste time trying to prove to each other that each of you is right. This is not really a bad thing, because when you analyze both of the arguments you can come up with the best parts of each person's ideas and end up with a better solution than either of you originally though of. Of course you could also end up with something worse. This happened to me while working on iteration 1. My partner and I were trying to decide exactly how the print function should work. We both had radically different ideas on what to do. We ended up resolving a solution pretty quickly, so it wasn't a very big deal, but it still was a minor annoyance. As I said I didn't have much trouble with this in iteration 1, but it was there and I think it may pop up again, and I see how it could prove to be a big problem, especially if the function in question is very complicated and large.
There were a few hiccups for me in Iteration 1. The problem I mentioned where I didn't agree with what my partner thought it should be, we had a few problems with conflicts when we each tried to submit a chunk that both of us had been working on. It wasn't all bad however. There were a few spots that I didn't really know what was going on and how to set it up and my partner helped figure it out, and with the amount of code that we had to write for all of the different tokens, having a partner helped a lot to lighten the load. So to sum it all up I think working in a group is worth it. There are a few problems that arise, but they can be worked out or even avoided completely with good communication. The amount of help a partner can provide more than makes up for the potential discord in my mind.
First blog. Yay. I hope to learn many things in this class. Uh, never-mind that's waaay too formal. Anyway following the assignment specifications: There aren't a lot of things on the list of Intended learning outcomes that I am really familiar with. I know how to write effective comments (I think) although I don't particularly enjoy it. Writing comments feels like a waste of time, but I do understand the reason behind it and I have found it useful in the past. I just accept it as a necessary (and useful) evil I suppose. I was introduced to the theory of defensive programming, and I understand the concepts. I won't say I'm
particularly good at it, I'm not. Quite frankly my coding skills are trash. But I do understand the idea, and have seen a few sample of what a programmer ought to do. I have never used C++, so I'm hoping to get an idea of how that works in this class. I used C in CSci 2021 and hated it. Java is way better. But I'm hoping C++ will be a little bit nicer. I'll find out in due time. I have no idea how to create a model and implement one when creating a program. The UML is an entirely new concept to me, but if I can figure it
out and use it effectively, I see how it could perhaps speed up, and maybe ease the design and coding process. OK I'm really bored now. I want to learn everything. And I don't know anything, I don't feel like going in depth on one or two topics. In fact I don't think I could if I wanted to. I don't know anything about what we're supposed to learn, so I can't really say anything about them other than the basic "_____ is a really awesome noun. I can't wait to learn more about it!!!!!" (note that's sarcasm). OK I wrote something. Why do I really want to learn any of the things that I'm supposed to learn in this class?
Uh... cuz then I be smarter. Then me does better. Then credit for class I get. I would like to learn to code better as a whole. I need to be able to use different tools to get my code clean and efficient. My code ought to be readable because everything that I write will be absolutely amazing and everyone will want to know how it works so they can copy it and steal my ideas, and then the world will be a better place. Or not. whatever. Oh I also think the regular expression idea is pretty cool. Plus I'm learning about them in CSci 4011 so now I got to learn about regex's twice. I'm so lucky. They are rather useful, as they can feed information about text rather efficiently. Alright I'm done. I didn't really write 1-2 pages so sue me. I don't care anymore.