Summer courses always go by too fast. The amount of work and material is compressed so tightly that it's a little hard to keep up with it as well as a job and the semblance of a social life. This week we had our first test in the course and while it wasn't quite what I expected, overall it wasn't too bad.
The test focused on mostly lecture topics with one problem that related to our first project. However, I was expecting at least one question on the assigned reading. See, for the day of the test we had at that point been assigned part of the introduction of our text, two sections on limits and an entire chapter (100 or so pages) on streams. Being the diligent student I am, I read all of that for the test, the last two parts the night before. Unfortunately the test didn't have a single question regarding the reading, or at least nothing that wasn't covered in the lecture. To be honest I was a little relieved, because my reading comprehension is not so great between 10 and 12 on the night before a test. It's just frustrating that I spent a significant time reading something I didn't need to, when I could have spent that time preparing differently for the test. Though in the end, this is a small gripe because I feel I did rather well on the test, so I probably shouldn't complain too much.
This does bring up an interesting debate I've noticed recently in college. The decision between using a text and not seems to be becoming a bigger issue with teachers, administration and students. Probably because the price of these books keep skyrocketing and are contributing to the increase in student debt and back problems. I've had teachers that didn't require a text and taught the whole course from their own notes and materials. And I can see how this could be very difficult for every professor to accomplish due to the time it would require to prepare all the material. Though I will say I feel like I have gotten more out of any lecture than out of any text I've every had to read. Not to say that I can't see the appeal of a text book. A centralized collection of information on a course is nice to have when you can't contact the teacher or a fellow student and you have a pressing question. I don't see this issue disappearing though, there's big money in text books and it's simply easier to teach out of one than not, but maybe someday the lug of weight I have/had to carry around will be a thing of the past.
Saturday, June 25, 2011
Sunday, June 19, 2011
It Takes Two For Summer Learning
Another week and another project. This time the problem of choice is the Stable Marriage algorithm. For those interested in it, please go here.
Perhaps more interesting is this was the first time I did pair programming for a project. Unlike the group project hell of grade/high school, pair programming has multiple benefits. After reading a couple of papers on it, one of which had dubious conclusions, I was slightly sold on the idea. With the addition of extra credit and an able partner with a similar schedule I decided to take the plunge. Here are my personal results.
Overall, I'd say the experience was pleasant. It took us about 7 hours of working, but we did the whole assignment in one run. Another person helped to do all the extraneous 'paperwork', i.e. setting up wikis, repositories, etc., in a shorter amount of time. Also having a second person to bounce ideas against helped wrap my head around implementing a working algorithm from the basic structure in my head. And probably most beneficial was another set of eyes to catch any errors in writing or syntax, and honestly this probably saved us the most amount of time. At one point or another we both mentioned that the other saved us several hours of beating our heads against a wall by finding an all to obvious but elusive bug.
However, the whole process wasn't painless. Given adequate time two different minds can come up with two wildly different solutions to a problem. Trying to combine those solutions into one program can be quite tricky. I fear our final solution was more complicated than it needed to be due to the cobbled style of our writing. We attempted to allow each other to write what we had in our heads, and did our best to make the two ideas work together. On the whole it was very successful and we found a working and optimal solution that met the project guidelines. Though I do think though that this led to more time spent coding and debugging than if we had each wholly implemented our own solution.
Saying all of this I still believe that pair programming to be a positive exercise in coding and I intend to attempt to do the rest of the projects in a pair. If only because those extra points make it such an easy choice.
Perhaps more interesting is this was the first time I did pair programming for a project. Unlike the group project hell of grade/high school, pair programming has multiple benefits. After reading a couple of papers on it, one of which had dubious conclusions, I was slightly sold on the idea. With the addition of extra credit and an able partner with a similar schedule I decided to take the plunge. Here are my personal results.
Overall, I'd say the experience was pleasant. It took us about 7 hours of working, but we did the whole assignment in one run. Another person helped to do all the extraneous 'paperwork', i.e. setting up wikis, repositories, etc., in a shorter amount of time. Also having a second person to bounce ideas against helped wrap my head around implementing a working algorithm from the basic structure in my head. And probably most beneficial was another set of eyes to catch any errors in writing or syntax, and honestly this probably saved us the most amount of time. At one point or another we both mentioned that the other saved us several hours of beating our heads against a wall by finding an all to obvious but elusive bug.
However, the whole process wasn't painless. Given adequate time two different minds can come up with two wildly different solutions to a problem. Trying to combine those solutions into one program can be quite tricky. I fear our final solution was more complicated than it needed to be due to the cobbled style of our writing. We attempted to allow each other to write what we had in our heads, and did our best to make the two ideas work together. On the whole it was very successful and we found a working and optimal solution that met the project guidelines. Though I do think though that this led to more time spent coding and debugging than if we had each wholly implemented our own solution.
Saying all of this I still believe that pair programming to be a positive exercise in coding and I intend to attempt to do the rest of the projects in a pair. If only because those extra points make it such an easy choice.
Monday, June 13, 2011
A New Semester, New Self Taught Unix
In an effort to score some extra credit for my summer class at UT, I return to this blog. The topics will probably be much more Computer Science-y than previous posts, so you are warned if you're not a visitor from my class.
I am taking CS378, which is a course on the Standard Template Library (STL) and Generic Programming in C++. The class is taught by Professor Downing, who I've not had the pleasure of having yet at UT, and so far it's a pretty interesting course. Fortuitously I took a course on C++ last semester, so a lot the intro of the course is familiar ground. (Though I am now dreading returning to Java since it's been almost a year since I had to use it...).
For this week's post I'm going to talk about the first assignment for the class, which I finished up on Sunday. The task was to write a program to solve a variation of the Collatz problem. That part of the assignment was a breeze, even the added component of inserting some variation of a cache to speed up the computation. The more difficult part of the assignment was learning (teaching myself) how to use the infrastructure required for the course. In particular, this class requires a project host (with issue tracker and wiki) and a source control repository. And as I am learning is a recurring theme in CS courses at UT, I had to develop a slightly deeper skill set of Unix commands.
Having completed the Biochemistry program at UT it's very interesting comparing the styles of teaching in that program to the ones in the CS department. Biochem tended to be very hand holding on the practical aspects and intensely rigorous on the theory, while CS appears to do the opposite. I don't mean to say that theory courses or tests in CS are easy, but in my experience they're easier than my previous studies. However the amount of skill I've been required to develop either on my own or with fellow students is staggering in CS as compared to Biochem. The funny thing is I think I might like the CS style more, but then again I'm a bit of a masochist.
I am taking CS378, which is a course on the Standard Template Library (STL) and Generic Programming in C++. The class is taught by Professor Downing, who I've not had the pleasure of having yet at UT, and so far it's a pretty interesting course. Fortuitously I took a course on C++ last semester, so a lot the intro of the course is familiar ground. (Though I am now dreading returning to Java since it's been almost a year since I had to use it...).
For this week's post I'm going to talk about the first assignment for the class, which I finished up on Sunday. The task was to write a program to solve a variation of the Collatz problem. That part of the assignment was a breeze, even the added component of inserting some variation of a cache to speed up the computation. The more difficult part of the assignment was learning (teaching myself) how to use the infrastructure required for the course. In particular, this class requires a project host (with issue tracker and wiki) and a source control repository. And as I am learning is a recurring theme in CS courses at UT, I had to develop a slightly deeper skill set of Unix commands.
Having completed the Biochemistry program at UT it's very interesting comparing the styles of teaching in that program to the ones in the CS department. Biochem tended to be very hand holding on the practical aspects and intensely rigorous on the theory, while CS appears to do the opposite. I don't mean to say that theory courses or tests in CS are easy, but in my experience they're easier than my previous studies. However the amount of skill I've been required to develop either on my own or with fellow students is staggering in CS as compared to Biochem. The funny thing is I think I might like the CS style more, but then again I'm a bit of a masochist.
Subscribe to:
Posts (Atom)