Unit testing, while certainly not the most glamorous part of programming, is
essential to making sure that what code you write functions as you intended it to. A
unit test is testing the smallest portion of your code at a time, to make sure it
functions correctly. Typically, this is calling a single method, to see if it returns what
you want it to, but it is most certainly not limited to that. Using very small tests like
this, from the bottom up, is a very good way to test your program to make sure it
works, just compiling, running and hoping for the best is not a good way to do this. It
is very difficult to diagnose an error when you run your entire program at one time.
CxxTest is the testing framework that we have used to perform unit tests on our
program, and it is a tool that I would recommend to anyone that wants to use unit
tests on their program. While at first the syntax of it is a little strange and
off-putting, it is well worth the effort to learn it. Once you do, and you understand
how it works, you will be able to run tests on your program easily and efficiently. It
uses various TS_ASSERT commands, which look similar to a method call, to test your
program. Once you add in every test you want to run, you can run cxxTest, and it
will output how many tests your program passed out of how many were ran total.
With cxxTest, it is easy to run a multitude of tests on your program, meaning that it
will not take you a lot of time to fully test your program.
Implementation of cxxTest is not difficult either, as your class of tests is just written
into a header file. Then, when you want to run cxxTest, just simply use the command
# cxxtestgen.pl --error-printer -o readInputRunner.cpp MyTest.h, and from there it's a
matter of compiling and running the file returned from cxxTest, in this case
readInputRunner.cpp. Unit testing with cxxTest is easy, efficient, and accurate.
There is no reason why you shouldn't want to unit test with it! Some people might
think that they don't need to run unit tests at all, but how else are you going to know
if your program works like you think it does without running unit tests on it?
Unit testing, while certainly not the most glamorous part of programming, is
Subversion is a source control program. It is a database, of sorts, that allows us to
upload files for easy access on its most fundamental level, but source control is used
for reasons beyond that. It allows easy access for a third-party to look at your code,
and give you feedback about what you did, instead of having to send out emails or
some other clunky process. Finally, source control allows you to revert back to a
point in time where you knew your program worked, a powerful tool if you are trying
to make dramatic changes to a program. However, Subversion isn't a perfect system,
and is not the end-all-be-all solution for version control.
Subversion is an extremely convenient system. Say you have multiple people working
on a big project. One simple command, svn update, will update all files in your
repository, reflecting any changes that might have been made by other people after
you worked on it last. No need to go through and add in all the updates yourself. svn
status will show you if you need to update your files or if they are okay to be edited.
svn add is the way to add in new directories and files into your repository, and once
you are done editing those files, the first time and every time thereafter, the
command svn commit -m "Your Comment Here" will save any alterations that you
made in your repository. When committing changes made into your repository, every
file that has been altered will be shown, and it will have an A or C next to its name.
Any A's you see are good, this means that all changes made to a file were successfully
updated in your repository. However, and C's that are shown are conflicts that arose
when Subversion tried to update a change you made. Now, instead of having to go
find out how that happened yourself, Subversion will add in text to the file to
indicate which lines of the file are causing the conflict, using easily noticeable lines
of >>> and ===. In this way, one of the big problems of version control systems,
conflicts, are very easily and gracefully handled by Subversion. We had a conflict
arise when working on our latest iteration of our project, and because of how easy
Subversion makes it to see the conflicts, it was very easy for us to figure out the
problem and how to fix it.
Subversion, while a very good version control system, is not perfect. The initial
learning curve for it is rather steep. An understanding of all of its features will only
be learned once a few hours are spent playing with it and seeing just what it is
capable of. Subversion is not something that can just be jumped right into. Though it
took me longer than most to understand it, a majority of people I have heard from
had to spend a decent amount of time on picking up the gist of the system. Another,
smaller, problem is that Subversion is a little picky sometimes with trying to do what
you want. For instance, trying to check-in a file into Subversion before adding it will
just fail, and it will not alert you to why you can't check the file in. This specific
thing is a mistake you think you would only make once, but occasionally you will be
in a hurry and forget that first step. I have, and its something I have forgotten more
than I should.
Subversion is a good version control system, and one that I would have no problem
using in the future. It's method of conflict resolution is it's biggest advantage, but it
also has a wide range of easy to use features that make it nice to use. While it can
be picky about somethings, nothing is perfect, and they are easy to deal with.
Working in groups on a project changes the entire dynamic of how that program will get
created, something that is exemplified the larger the project is. Collaborating with
other people to get something done brings with it many benefits, but not all is golden.
Bringing in more people to finish a project can create additional challenges that would
not be present if someone was working on a project on their own.
The benefits of working together in a group of people are huge. The total workload can
be split among people, making it easier for each individual to get the project done.
They will need to spend less time on the project, or it frees up more time that they can
spend working on that one part of code, making sure that it works, and even adding
more things so that it has a higher functionality. If each part of a program works a little
bit better because each person got to focus on one thing, then that will result in a far
more advanced program as compared to the person who has the bare minimum for
everything. Additionally, if there is an extremely difficult constraint, or a very
complicated implementation of something is required, being able to brainstorm ideas
with other people can be very useful. Being able to band together to overcome some
difficult task when it needs to be done, then having everyone go back to their own part
of the program, is critical. Adaptability of a group of people is something that cannot be
underestimated, and simply cannot be replicated by someone who is working on their
own. While this next aspect may seem obvious, and it is, it is still a crucial aspect of a
group that can't go unmentioned. Having more people working on a project at once will
cause that program to be finished faster. Now, if the program is designed to be able to
be completed by one person before a due date, then this is less relevant. But, outside
of that, many programs simply wouldn't be finished within a reasonable time simply
because there wasn't enough manpower behind it. Now, with these benefits of working
in groups known, one needs to make sure that they have a group that will be able to
provide those. Making sure to create a group of people that can effectively accomplish
tasks together is absolutely the most important. Having a group of people that enjoy
working together, while not as important, can cause the group function better with each
other, and will help making all that time you spend on creating that huge program much
more bearable. Spending a little bit of extra time making sure that you surround
yourself with people that want to work together, and can effectively do so, will just
enhance your groups capabilities.
As you can see, working in groups is a very good way to create programs, especially
when compared to trying to do everything alone. Collaborating with others will allow
your program to have more features, will cause it to be finished faster than someone
working alone, and a group can come together to overcome some difficult task that
normally would leave a single person stumped for a long time. There are a huge amount
of benefits of working in a group, and it is something that should be considered for
anything that someone needs to create.
Never had a blog before, so I'm not really sure how to start this. Here goes nothing!
Coming into 3081W, I was a bit nervous. Writing anything had never really been my strong suit. Syntactically, I was alright, but I was never very good at forming a cohesive argument or paper as a whole. Luckily, it seems like we will be writing a lot about Computer Science and 3081W related topics, so hopefully it won't be too bad. Some of the topics for 3081W are the Intended Learning Outcomes, of which some I know fairly well and a couple that I don't.
First off, the good news, the things I already know fairly well coming into the class. Writing effective comments is always something that I felt was an important part of programming, and is something that is frequently overlooked, or left to the end to be rushed through. This is because nearly everything we have done so far is just individually, and we know how it works, so we don't need to comment it that well. But, in the real world, whole teams of people will be working on one program. If that program is poorly commented, nobody will know how that program works, and will be unable to do anything to it or debug it if something goes wrong. Clear, concise comments allow everyone to under stand how your program works, I feel that I am pretty good at writing clear comments because nearly every programming class I have had has pushed it on me, so I started to do it. The more and more I did it, the more I was able to understand precisely how and why my program worked. So that, even after detailed comments weren't required, I still found myself doing them just because it helped me understand everything so much more.
However, there are a couple things I don't know and would love to learn much more about in 3081W. They are some tools for automation and documentation generators. These are tools that I have never really used in my Csci life, but are things that would be incredibly useful for me to know. Automation in particular is something that I really hope the class teaches me more about. Before, anything in the past I made, once it works, it was done. Turned in, and left alone. Nothing more had to be done with them. Automation was something that I never even thought about, but the more I think about things I will code in the future, it is something that is becoming more and more important, and my desire to learn about it is growing. Ideally, this class will give me a great introduction to it, and that I may learn more about it in the future.
Documentation is also something that has never been required of me to use so far for anything I have coded. For little things that I have done though, it isn't necessary. But, in the future, with bigger projects and more and more people working on things, documentation is going to be more important, and in greater volume. Something that could generate the documentation for me, is a tool that would be critically helpful for the rest of my life, and is another thing that I hope this class can introduce me too and dip my toe into the subject.
3081 should be a fun class, with a wide variety of things that will be done, and a lot of helpful things will be taught to me. Hopefully, I will be able to make use of these things to make me a better programmer.