I definitely enjoyed the whole experience of this class. I think if there was one more thing I would like to have learned, I think it would be function pointers. I don't think I quiet understood them. I have read online posts about function pointers, but they don't seem to click to me. I think downing does a great job of explaining things in general and I think I would gain from his explanations.
I was okay with the experience of blogging overall. I didn't have too much things that I wanted to blog about. I probably will not continue blogging after this class. But I'm glad I got the chance to know what it was like, because I did want to try blogging before but never got enough motivation to actually do it.
I definitely enjoyed the class. I think if I knew about it earlier, I would take his software engineering class, so I can get some experience in web programming. Unfortunately, I don't think I have any more room in my schedule for it.
Lastly, I'm much more comfortable with c++ now, I think I may be more comfortable then java. I remember when I was trying to show someone else how to code something, I default to c++ syntax.
I hope everyone else enjoyed the class, good luck on the final, and have a good break.
Saturday, December 3, 2011
Friday, December 2, 2011
Metrics Suite for Objected Oriented Design
This was an interesting paper, because I never knew there were metrics for software out there. I always just kind of thought software as something that is hard to judge, almost like an art piece. You can't really score an art piece, but make some observational comments about it. This paper talks about a new metric system to evaluate OOP designs.
The author attempts to improve previous metrics, because he believes previous metrics were not mathematically rigorous. Then he uses a metric defined by Weyuker to show that his metrics are better. However, I see there are still ways to go before metrics can become something that people can agree upon. The Weyuker's criterias uses notions of monotonicity, interaction, noncoarseness, nonuniqueness, and permutation. To show how these apply, he lists several examples. For example with nonuniqueness, it tries to capture the idea that two classes can have the same metric classes, meaning they are equally complex. The metric system cannot be such that all classes have different metric value. This is definitely useful in that a class has a different complexity even by having a different name. For example, two classes with the same function but different name (one a descriptive and another name a cryptic name) could have different metric value, and the nonuniqueness and noncoarseness would account for the value of the metric value. One of the criterion, I personally don't agree with which is monoticity. He means that given a class P, and a metric unit, u, u(P) <= u(P+Q), Q being another class. It is to measure that adding another class would only increase complexity. But I could think of instances where adding a class would demonstrate what the other classes are doing. For example, if class P was draw, and class Q was deckofcards, then it would make it obvious what the whole system was doing. While class P by itself makes the class ambiguous in terms of whether draw was referring to drawing a picture or drawing a card.
To determine the metrics, he uses Booch's outline of what are the essential features of object oriented programming. Booch listed them as: identification of classes, the semantics of classes, relationship between classes, and implementation of classes. Hence, all the metrics are centered around how the classes are defined and the relationship between the classes. He cites that the central them of OOP is classes, and that it is agreed upon by others though there are criticism of this. He does however admit that this system would not capture the dynamic behavior of the system, since it does not collect any information about the run time behavior.
For example, one of his metric was weighted methods per class. This is a number summing up all the complexities of each method in a class. He believes the higher the number it'll mean more time and effort to maintain the class, and larger number means more effect on children, and more methods mean very specific class. I don't think the way he determined the complexity of the methods is very rigorous.
Second metric: depth of inheritance tree. The basis for this metric is the scope of classes. How much the parent classes may affect the child classes. For example, if there is a great depth in the class hierarchy, then it is possible the child has a lot of methods that it inherited from the parents and it will become hard to predict how the child will behave. I think this is one of the best criterion for the oop metric. I think programmer often think in terms of 2 or 3 depth of inheritance, and after that I think people forget about the parents, so in a deep tree, I would forget what behaviors the child has inherited.
Third metric: number of children. This can suggest several things. The higher number of children will be good since there will many reuse of functions, but higher number of children also means the parent has to be extremely robust, and kind of suggest a strong single point of failure. It would indicate the need for perhaps breaking up the inheritance tree into different category to reduce the number of children.
Fourth metric: coupling between object classes. This means the how many classes a certain classes is attached or depends on. This could result in very bad programs and leading to highly unmodular design. If there is a change in one class, then all the classes that are coupled must also change in order to match that design. This metric is a good indicator of how maintainable the code will be in the long run. If there needs to be change everytime a small snippet changes, then it will be very hard to maintain the code. When the code really blows up, at certain point it will be beyond maintaining.
Fifth metric: response for a class. This refers to the idea of the set of responses a class can make to a message. This relates to idea of method overloading and dynamic binding between class hierarchies. For a particular message, if there are many methods that can be potentially be executed, then it makes it really hard to debug, and when the code gets large again, then it'll be really hard to figure out exactly what method is being called. Some of the worst bugs that I've had to deal with circles around this. I would be coding something and something behaves nothing like what I expected, then I start changing up the code to do something ridiculous and I get confused to why it won't change. Then I would have to trace the code even further to determine that it went on to call a different method than I expected. Not only does this increase in complexity, it also increase the run-time since the program has to determine which method to execute.
Last metric: lack of cohesion in methods. The way he determines cohesiveness between the methods is by looking at which local variable the method uses. The more local variables they share, the more cohesive these functions are. He suggests that if there is lack of cohesion, then the functions should be separated in to more subclasses because there isn't enough encapsulation. However, I don't particular agree with the reasoning, because from experience, I feel like there are instance when classes are well-defined but the method don't share too many local variables. I don't really know the reasoning for my statement. However, I can definitely understand how a class can be bloated when there is a different set of variables for each of the methods, and the entire program essentially being under one class.
These all have to do with how classes are defined. I think class definition are a very important point in oop design, but I think there can be many subtle things outside of class definition that could be useful for metrics. I think a lot of them are kind of common sense to programmers who have been programming for a decent amount of time. I think many people implicitly understand these concept and probably have even applied them during programming, but I think it is still useful to explicitly state and read about why decisions we make during class implementations matter. Overall the paper was pretty interesting, it opened me up to a topic that I didn't know existed, and it was interesting to read about how he collected the data to use against his metrics.
https://wwwbroy.in.tum.de/lehre/vorlesungen/vse/WS2004/1994_chambers_metric_suite_oo.pdf
The author attempts to improve previous metrics, because he believes previous metrics were not mathematically rigorous. Then he uses a metric defined by Weyuker to show that his metrics are better. However, I see there are still ways to go before metrics can become something that people can agree upon. The Weyuker's criterias uses notions of monotonicity, interaction, noncoarseness, nonuniqueness, and permutation. To show how these apply, he lists several examples. For example with nonuniqueness, it tries to capture the idea that two classes can have the same metric classes, meaning they are equally complex. The metric system cannot be such that all classes have different metric value. This is definitely useful in that a class has a different complexity even by having a different name. For example, two classes with the same function but different name (one a descriptive and another name a cryptic name) could have different metric value, and the nonuniqueness and noncoarseness would account for the value of the metric value. One of the criterion, I personally don't agree with which is monoticity. He means that given a class P, and a metric unit, u, u(P) <= u(P+Q), Q being another class. It is to measure that adding another class would only increase complexity. But I could think of instances where adding a class would demonstrate what the other classes are doing. For example, if class P was draw, and class Q was deckofcards, then it would make it obvious what the whole system was doing. While class P by itself makes the class ambiguous in terms of whether draw was referring to drawing a picture or drawing a card.
To determine the metrics, he uses Booch's outline of what are the essential features of object oriented programming. Booch listed them as: identification of classes, the semantics of classes, relationship between classes, and implementation of classes. Hence, all the metrics are centered around how the classes are defined and the relationship between the classes. He cites that the central them of OOP is classes, and that it is agreed upon by others though there are criticism of this. He does however admit that this system would not capture the dynamic behavior of the system, since it does not collect any information about the run time behavior.
For example, one of his metric was weighted methods per class. This is a number summing up all the complexities of each method in a class. He believes the higher the number it'll mean more time and effort to maintain the class, and larger number means more effect on children, and more methods mean very specific class. I don't think the way he determined the complexity of the methods is very rigorous.
Second metric: depth of inheritance tree. The basis for this metric is the scope of classes. How much the parent classes may affect the child classes. For example, if there is a great depth in the class hierarchy, then it is possible the child has a lot of methods that it inherited from the parents and it will become hard to predict how the child will behave. I think this is one of the best criterion for the oop metric. I think programmer often think in terms of 2 or 3 depth of inheritance, and after that I think people forget about the parents, so in a deep tree, I would forget what behaviors the child has inherited.
Third metric: number of children. This can suggest several things. The higher number of children will be good since there will many reuse of functions, but higher number of children also means the parent has to be extremely robust, and kind of suggest a strong single point of failure. It would indicate the need for perhaps breaking up the inheritance tree into different category to reduce the number of children.
Fourth metric: coupling between object classes. This means the how many classes a certain classes is attached or depends on. This could result in very bad programs and leading to highly unmodular design. If there is a change in one class, then all the classes that are coupled must also change in order to match that design. This metric is a good indicator of how maintainable the code will be in the long run. If there needs to be change everytime a small snippet changes, then it will be very hard to maintain the code. When the code really blows up, at certain point it will be beyond maintaining.
Fifth metric: response for a class. This refers to the idea of the set of responses a class can make to a message. This relates to idea of method overloading and dynamic binding between class hierarchies. For a particular message, if there are many methods that can be potentially be executed, then it makes it really hard to debug, and when the code gets large again, then it'll be really hard to figure out exactly what method is being called. Some of the worst bugs that I've had to deal with circles around this. I would be coding something and something behaves nothing like what I expected, then I start changing up the code to do something ridiculous and I get confused to why it won't change. Then I would have to trace the code even further to determine that it went on to call a different method than I expected. Not only does this increase in complexity, it also increase the run-time since the program has to determine which method to execute.
Last metric: lack of cohesion in methods. The way he determines cohesiveness between the methods is by looking at which local variable the method uses. The more local variables they share, the more cohesive these functions are. He suggests that if there is lack of cohesion, then the functions should be separated in to more subclasses because there isn't enough encapsulation. However, I don't particular agree with the reasoning, because from experience, I feel like there are instance when classes are well-defined but the method don't share too many local variables. I don't really know the reasoning for my statement. However, I can definitely understand how a class can be bloated when there is a different set of variables for each of the methods, and the entire program essentially being under one class.
These all have to do with how classes are defined. I think class definition are a very important point in oop design, but I think there can be many subtle things outside of class definition that could be useful for metrics. I think a lot of them are kind of common sense to programmers who have been programming for a decent amount of time. I think many people implicitly understand these concept and probably have even applied them during programming, but I think it is still useful to explicitly state and read about why decisions we make during class implementations matter. Overall the paper was pretty interesting, it opened me up to a topic that I didn't know existed, and it was interesting to read about how he collected the data to use against his metrics.
https://wwwbroy.in.tum.de/lehre/vorlesungen/vse/WS2004/1994_chambers_metric_suite_oo.pdf
Sunday, November 27, 2011
Weekly Blog #13
I hope everyone had a good thanksgiving. I definitely had a good time at home spending time with my family and getting to eat some good food. I took some work home and didn't get anything done. Now I have so much work to look forward to now.
It is so hard to believe that this semester will be over in just a week, then just finals. Luckily, I have a very light finals week schedule.
I'm so glad we didn't have to do any project over the break. I think it would have been just painful getting to organize meeting with a partner, and it is hard to just get stuff done over the break in general when I am at home. I am already looking forward to the winter break.
Just looking back, I don't think I ever wanted to miss this class on purpose. I may have missed a few due to oversleeping, but I never thought to myself that I didn't want to go because the lectures were useless. I felt like the lectures were always useful and I could get most or all the information that I needed just from the lecture. Often, I feel like the lectures go over my head, and I miss a lot of stuff unless I go through the book. However, I felt like materials were explained very clearly in the class. I sometimes wish I took notes because I don't understand what he put some of the codes on the slides, the comments help, but sometimes there are no comments.
Monday, November 21, 2011
Weekly Blog #12
It feels pretty good not to have a project in this class anymore. Overall I think this class had a very fair amount of homework. I think the ratio of how much I learned in this class to how much work was needed is huge. I think downing is definitely a good lecturer and I am definitely glad I took this class. I kind of wish I took this class little earlier in college so I can have these, what seems to be basic, knowledge. I'm surprised how much basic knowledge I was missing.
The handle class lessons are pretty interesting, I guess people use this tactic to protect against pointer bugs since it can almost impossible to debug in a huge program.
One really important thing I learned in this class is regarding blogs. I've read some of Joel's blogs before, but just once in a while, but since we read it quiet often in this class, I found myself going to his site myself to read some of his other blogs. Then I ran into some other blogs by other well-known software engineer bloggers. I've definitely come across good writers and across good and interesting ideas. I definitely can broaden my perspectives and learn a lot more and efficiently by reading what other people are thinking and are doing.
The handle class lessons are pretty interesting, I guess people use this tactic to protect against pointer bugs since it can almost impossible to debug in a huge program.
One really important thing I learned in this class is regarding blogs. I've read some of Joel's blogs before, but just once in a while, but since we read it quiet often in this class, I found myself going to his site myself to read some of his other blogs. Then I ran into some other blogs by other well-known software engineer bloggers. I've definitely come across good writers and across good and interesting ideas. I definitely can broaden my perspectives and learn a lot more and efficiently by reading what other people are thinking and are doing.
Sunday, November 13, 2011
Weekly Blog #11
One thing I wanted to find out from blogging was whether I would like it. I don't think I like it too much, I don't find myself wanting to post something in a blog. I am only reminded weekly from everyone's posting that I need to do it for the extra credit. I probably will not continue blogging after this class, but I'm glad I got to try it.
I'm glad we don't have any more project after thanksgiving for this class. It is a nice break. I think the class stuff is getting more difficult, I wish I took some notes, because I am not able to recall everything from his codes anymore. The paper on gender difference was interesting, but I didn't think any of the findings were surprising at all.
As thanksgiving approaches, I was just thinking about the things I'm thankful for, and I'm really thankful for the opportunity to be at UT and studying here. I feel like it is so much hard work, but I often forget that it is a privilege to be studying at a university. I'm glad for the great faculty and the great cs program, at the end of it all, I do like what I'm learning and I'm really thankful that I get to be here.
I'm glad we don't have any more project after thanksgiving for this class. It is a nice break. I think the class stuff is getting more difficult, I wish I took some notes, because I am not able to recall everything from his codes anymore. The paper on gender difference was interesting, but I didn't think any of the findings were surprising at all.
As thanksgiving approaches, I was just thinking about the things I'm thankful for, and I'm really thankful for the opportunity to be at UT and studying here. I feel like it is so much hard work, but I often forget that it is a privilege to be studying at a university. I'm glad for the great faculty and the great cs program, at the end of it all, I do like what I'm learning and I'm really thankful that I get to be here.
Sunday, November 6, 2011
Weekly Blog #10
Only one more project left in this class and we are done. I'm glad there is not a project due after thanksgiving. Time really does goes by fast as you grow older. I feel like freshmen year I did so much stuff, but now I feel like I'm not doing as much and time is just going by faster. I heard someone once wisely said "when you are young, each moment makes a big portion of your life, but when you are older, each moment is grows smaller and smaller in significance due to all your previous moments." It was something like that I don't know if he took it from someone, I wish I knew what the exact quote was if he did take it from some book or something.
This was my first time using piazza, from what I heard a lot of cs professors use it, but that was not the case for me. I had a very good experience with it, I really enjoyed how there was a live audience who would listen to your problems and answer them and help you through problems. I also liked the fact that the professor visited the page frequently to answer question in a timely manner. I wish I had something like piazza in some of my class from freshmen year when I had so much trouble understand everything. Sometimes the skeleton that was provided would be buggy, and I would spend all night trying to fix my code and only to find out near the due date that it was the skeleton. Sometimes asking questions to friends would help but sometimes your friend might not have gotten far enough to reach that problem. So I feel like piazza was really good, because different people will work on the project earlier throughout the semester and we can help each other if you happened to start early.
This was my first time using piazza, from what I heard a lot of cs professors use it, but that was not the case for me. I had a very good experience with it, I really enjoyed how there was a live audience who would listen to your problems and answer them and help you through problems. I also liked the fact that the professor visited the page frequently to answer question in a timely manner. I wish I had something like piazza in some of my class from freshmen year when I had so much trouble understand everything. Sometimes the skeleton that was provided would be buggy, and I would spend all night trying to fix my code and only to find out near the due date that it was the skeleton. Sometimes asking questions to friends would help but sometimes your friend might not have gotten far enough to reach that problem. So I feel like piazza was really good, because different people will work on the project earlier throughout the semester and we can help each other if you happened to start early.
Sunday, October 30, 2011
Weekly Blog #9
I have done the darwin's world project before except it was called critter world or something. From what I can remember it was almost exactly the same except there were more instructions. I did it in java and our professor provided a skeleton for us so all we had to write was an interpreter. I remember in that class he also provided a graphical simulator where we can actually see all the little critters (species) move around and attack each other. They all had different colors and I think all the critters were shaped as a triangle.
I've been looking around in my free time for a little bit to pick a paper to write a blog about, but I haven't had a chance to find a good that was related to the class. Did anyone have any luck with this?
Now I feel like we are really going deep into the details of c++, I'm not sure how much of it is related object oriented programming as the class name suggests. It seems like we are going more into design tradeoffs between java and c++. I still think it is useful, since I didn't know most of the stuff before. I'm just really looking forward to thanksgiving at this point, and hope everyone had a safe Halloween.
I've been looking around in my free time for a little bit to pick a paper to write a blog about, but I haven't had a chance to find a good that was related to the class. Did anyone have any luck with this?
Now I feel like we are really going deep into the details of c++, I'm not sure how much of it is related object oriented programming as the class name suggests. It seems like we are going more into design tradeoffs between java and c++. I still think it is useful, since I didn't know most of the stuff before. I'm just really looking forward to thanksgiving at this point, and hope everyone had a safe Halloween.
Sunday, October 23, 2011
Weekly Blog #8
I didn't feel too good about the test at the end. After checking I think I got most of it correct, including the destructors but at the time of the test I didn't feel confident and felt like I was guessing the whole time.
The grades projects I think took a lot longer than I expected, there was a lot of formatting issues and many small changes to make to fit the consensus.
I just read the next project and it seems interesting, I've done a similar project before where the creatures behave in similar ways. I can't believe the semester is almost coming to an end, I definitely did learn a lot from this class and it was worth my time. I honestly picked this class randomly to get another cs upper division and feel like it was a great decision and would recommend others to take it.
I still have not grown an appreciation for unit tests however. I still think the same way as I did before, I don't think they are all that useful. One exception to that might be, when I change code to cover a corner case, I might be changing an important invariant in the code, which can be checked quickly through a unit test. However, I haven't had that problem with the projects in this class as I think they are pretty-small scale, so for this class, I feel like I had to write a lot of units compared to what they are worth.
Acceptance are a little bit better, but it wasn't that enjoyable to do it if we had to write a complex program for it. I thought they were useful if they were quick to write. Usually I didn't find too many bugs after writing the unit tests.
The grades projects I think took a lot longer than I expected, there was a lot of formatting issues and many small changes to make to fit the consensus.
I just read the next project and it seems interesting, I've done a similar project before where the creatures behave in similar ways. I can't believe the semester is almost coming to an end, I definitely did learn a lot from this class and it was worth my time. I honestly picked this class randomly to get another cs upper division and feel like it was a great decision and would recommend others to take it.
I still have not grown an appreciation for unit tests however. I still think the same way as I did before, I don't think they are all that useful. One exception to that might be, when I change code to cover a corner case, I might be changing an important invariant in the code, which can be checked quickly through a unit test. However, I haven't had that problem with the projects in this class as I think they are pretty-small scale, so for this class, I feel like I had to write a lot of units compared to what they are worth.
Acceptance are a little bit better, but it wasn't that enjoyable to do it if we had to write a complex program for it. I thought they were useful if they were quick to write. Usually I didn't find too many bugs after writing the unit tests.
Sunday, October 16, 2011
Weekly Blog #7
Man we are starting pretty late on the project for this one. I think we just had bad schedules that didn't work out this time. We haven't really done much and hoping to get most of it done tomorrow and the following day.
I hope the next test will not have a question like the first question from the last time. But I may need to make more use of my cheat sheet this time in case those random facts appear in the test.
I feel like we are really getting into a lot of the nuances of the languages now, I'm really starting to lose track where I am sometimes. I feel like before much of the behaviors in the language made sense, but some of these, I don't know the reason behind the decisions, so I'm not up to date on all the semantics of the language. Hopefully by the time the exam this Friday I can get everything straightened out.
I just glanced at the calendar and was surprised at how far we are into the semester and I feel like it is almost over. Definitely have learned a lot this semester so far, and I'm looking forward to some other interesting things that we will get to learn.
I also appreciate the fact that are forced to use c++, because that is the language we are not introduced to in this school. I'm the type who wants to learn but won't do it if i don't have do, so I think if we were given the option to choose between java and c++ then I would have picked java. I think there are definitely useful things in c++ and I always wanted to get familiar with the stl containers in c++.
I hope the next test will not have a question like the first question from the last time. But I may need to make more use of my cheat sheet this time in case those random facts appear in the test.
I feel like we are really getting into a lot of the nuances of the languages now, I'm really starting to lose track where I am sometimes. I feel like before much of the behaviors in the language made sense, but some of these, I don't know the reason behind the decisions, so I'm not up to date on all the semantics of the language. Hopefully by the time the exam this Friday I can get everything straightened out.
I just glanced at the calendar and was surprised at how far we are into the semester and I feel like it is almost over. Definitely have learned a lot this semester so far, and I'm looking forward to some other interesting things that we will get to learn.
I also appreciate the fact that are forced to use c++, because that is the language we are not introduced to in this school. I'm the type who wants to learn but won't do it if i don't have do, so I think if we were given the option to choose between java and c++ then I would have picked java. I think there are definitely useful things in c++ and I always wanted to get familiar with the stl containers in c++.
Sunday, October 9, 2011
Weekly Blog #6
The allocator project was pretty simple, but had trouble testing for boundary cases. I just had to manually look into to the a[n] array to make sure that it was working correctly. But besides that it seemed pretty simple, I'm enjoying the book, seems to explain everything pretty well except I don't really care for some of the languages and since I've never seen the syntax for those languages before sometimes its not perfectly clear and I have to stare at it for a while. Even when I eventually figure it out, I don't really get much out of it.
I was looking into some AI algorithm because I'm doing a senior design project on augmented reality checker application for android. I read some articles and found out (this was a while ago) that checkers has been solved and there are AIs which are completely unbeatable (that AI playing against each other will result in draw). I read to more about it recently and read about how chess is still under research for the optimal solution and shogi (a japanese chess) is an even harder problem to solve due to some interesting moves that are possible with some pieces. Then read that one of the most difficult board game problem to solve is go (originated from China). The rules are amazingly simply but room for strategy is humongous. I used to play back in korea, it was pretty big there, but no one really plays here.
Does anyone play? I recently looked around and found a server that hosts go games, let me know if you play :) http://www.gokgs.com/applet.jsp
Sunday, October 2, 2011
Weekly Blog #5
I'm glad we are getting to doing some cool OOP stuff now. I think I'm finally getting used school schedule now after the first round of midterms.
I haven't had a look at the assignment just yet, but I don't think it'll be too difficult, but then again I know there are unit tests and acceptance tests to write, as well as documentation, so it won't be too simple.
I think there has to be more testing this time since we don't have sphere to kind of use as a check this time. So the acceptance tests and unit test from classmates will be more valuable now compared to the previous assignments.
I plan on trying out writing unit tests before the actual testing, I still haven't done this before and it looks like it'll prove to be pretty useful now.
The book is getting into stuff that I didn't know so well before, and class materials are beginning to be completely new stuff. I feel like before I knew most of the stuff and just got reinforced with some new information, but now it seems most of it is new to me, and I'm glad I'm getting a lot out of it.
I haven't had a look at the assignment just yet, but I don't think it'll be too difficult, but then again I know there are unit tests and acceptance tests to write, as well as documentation, so it won't be too simple.
I think there has to be more testing this time since we don't have sphere to kind of use as a check this time. So the acceptance tests and unit test from classmates will be more valuable now compared to the previous assignments.
I plan on trying out writing unit tests before the actual testing, I still haven't done this before and it looks like it'll prove to be pretty useful now.
The book is getting into stuff that I didn't know so well before, and class materials are beginning to be completely new stuff. I feel like before I knew most of the stuff and just got reinforced with some new information, but now it seems most of it is new to me, and I'm glad I'm getting a lot out of it.
Sunday, September 25, 2011
Weekly Blog #4
I have seen and read about templates and generics in data structures and algorithms, but I think back then I was much more concerned about learning basic programming that I didn't pay any attention to advanced concepts. Now that I hear them again it makes much more sense and I can definitely see many uses for them in real life.
Some features likes these I never really had to learn, because if I needed to write multiple functions with different parameters then I would just copy and paste functions and change a few things. I never knew the language supported such things. I really hope that we get to about function pointers, because I don't think I have a complete grasp on it, and Prof. Downing does a good job of explaining concepts clearly.
I thought the test was pretty fair, though I thought some of the first few questions were more detail oriented than I expected.
Overall, I think the workload in this class has been pretty decent, I'm happy with the workload balance and how much I am getting out of the class.
Sunday, September 18, 2011
Weekly Blog #3
Now I feel like this class really should have been part of the curriculum, because I am a learning about a lot of features I have been using in a language.
For example, I have always wanted to read something or learn more about exceptions because I never quite understood why I was typing certain things (like throws Exception in the function line). I also know a more detailed behavior of how exceptions behave now.
I like how the professor speaks loud and very clearly, I almost never get lost by what he says, because he is so precise. So far, a lot of the topics we are covering are not new, but most of the information that I have been learning have been really covering up a lot of holes that have accrued in my knowledge.
The book has been pretty good too, although I don't really enjoy it when I see all different kinds of implementation or syntax in multiple languages. I only care about a few of them, and some of them I never heard the language existed before. I don't mind when it mentions a few language with odd behaviors, but I don't really need to know the syntax of all of those languages.
I'm still not finding the issue tracker to be too useful. I think this is because I'm not really working on a big project. My partner and I know all the issues that we are going through and we kind of know them all, and so issue tracker seems redundant. I can see the usefulness when there are multiple people working on a project and have dependencies though.
I feel like we haven't talked too much about the object-oriented features in class like inheritance and polymorphism. However, I'm glad we went through these details about the language, because I learned a lot. I'm excited to get to the object-oriented part of the class and hopefully learn a lot of new things there too.
For example, I have always wanted to read something or learn more about exceptions because I never quite understood why I was typing certain things (like throws Exception in the function line). I also know a more detailed behavior of how exceptions behave now.
I like how the professor speaks loud and very clearly, I almost never get lost by what he says, because he is so precise. So far, a lot of the topics we are covering are not new, but most of the information that I have been learning have been really covering up a lot of holes that have accrued in my knowledge.
The book has been pretty good too, although I don't really enjoy it when I see all different kinds of implementation or syntax in multiple languages. I only care about a few of them, and some of them I never heard the language existed before. I don't mind when it mentions a few language with odd behaviors, but I don't really need to know the syntax of all of those languages.
I'm still not finding the issue tracker to be too useful. I think this is because I'm not really working on a big project. My partner and I know all the issues that we are going through and we kind of know them all, and so issue tracker seems redundant. I can see the usefulness when there are multiple people working on a project and have dependencies though.
I feel like we haven't talked too much about the object-oriented features in class like inheritance and polymorphism. However, I'm glad we went through these details about the language, because I learned a lot. I'm excited to get to the object-oriented part of the class and hopefully learn a lot of new things there too.
Sunday, September 11, 2011
week2
I got to start on the 2nd project of the semester with a partner. I haven't had a programming partner in such a long time, and the times I have done pair programming it wasn't with a friend. But this time, I did pick a friend as a pair programmer and it was really enjoyable.
I feel like it was a good pair because we were both concentrating and wanted to get the project done. But at the same time, we were both relaxed and had a good time because we still had a lot of time left.
I never used a source control before with a partner, and I found it to be really useful to use Git. We would split some of the work like coming up with unit tests for particular cases, so that we can put down all the corner cases that we can think of. Then we came up with unit tests together to see if we could think of more together. But it was very easy transition to merge our work together.
So far, I haven't been really enjoying writing the unit tests. I feel like I haven't had too many problems with the functions and it seems useless. But perhaps, I'll come to appreciate them later when the projects get more difficult.
The reading has been pretty good, I feel like I knew most of the material, but I can see a lot of new information coming that I'm excited to read about. The papers have been pretty good too, and I look forward to reading more of them.
I feel like it was a good pair because we were both concentrating and wanted to get the project done. But at the same time, we were both relaxed and had a good time because we still had a lot of time left.
I never used a source control before with a partner, and I found it to be really useful to use Git. We would split some of the work like coming up with unit tests for particular cases, so that we can put down all the corner cases that we can think of. Then we came up with unit tests together to see if we could think of more together. But it was very easy transition to merge our work together.
So far, I haven't been really enjoying writing the unit tests. I feel like I haven't had too many problems with the functions and it seems useless. But perhaps, I'll come to appreciate them later when the projects get more difficult.
The reading has been pretty good, I feel like I knew most of the material, but I can see a lot of new information coming that I'm excited to read about. The papers have been pretty good too, and I look forward to reading more of them.
Sunday, September 4, 2011
Blog #1 First Sunday
As I'm finishing up on the first project, I feel like a lot of this is really over-kill, but honestly I can't think of any better way to learn these tools. I kind of wish there was an introductory course that taught these tools early in my college life, because a lot of these tools are used in the industry and classes, and it is really useful.
I do appreciate how Downing explaining all these small details that I've always been looking over. For example, the import statement in java, I always did think that statement was importing libraries, I did not know java had always loaded all the libraries. Also about c and c++ have two buffer for its own output stream. I guess I got away without knowing these details, but I feel like I should have learned this in the beginning.
I realize it is good practice to do documentation, commenting, and writing good variable name, but I do find these part of the tasks to be really tedious. I just saw the post about the fact that Downing may have left some of his code to be vague intentionally and we may have to change them. So I guess I'm going back to my code to change those variable names.
One things that I was really pleased about this project was Assembla, I knew something like that was out there, but never bothered to look. But now I know a place where they provide free repository, and I can make use of it!
I do appreciate how Downing explaining all these small details that I've always been looking over. For example, the import statement in java, I always did think that statement was importing libraries, I did not know java had always loaded all the libraries. Also about c and c++ have two buffer for its own output stream. I guess I got away without knowing these details, but I feel like I should have learned this in the beginning.
I realize it is good practice to do documentation, commenting, and writing good variable name, but I do find these part of the tasks to be really tedious. I just saw the post about the fact that Downing may have left some of his code to be vague intentionally and we may have to change them. So I guess I'm going back to my code to change those variable names.
One things that I was really pleased about this project was Assembla, I knew something like that was out there, but never bothered to look. But now I know a place where they provide free repository, and I can make use of it!
Sunday, August 28, 2011
Hello World
I think this is a common way to start off a CS blog. I'm starting this blog for a class to talk about cs topics, but I may continue this on.
Subscribe to:
Posts (Atom)