|
Course:Object-Oriented Software Development (SE-450-802) Quarter:Winter 03/04 Time: M 17:45 - 21:00 Location: Loop Campus |
James Riely PhD Associate Professor [email protected] Instructor homepage
|
Select a Page:
Summary 1 2 3 4 5 6 7 8 9
What are the major strengths and weaknesses of the instructor?
1. Professor like to jump or go back and forth on topics, so it got confusing what topic he was writing/talking about
2. His knowledge of the field is simply incredible, and it showed in his lectures. He understood when the class as a whole was on target, and when we weren't, he changed directions appropriately and made sure we all understood. He clearly knows how to teach this class.
4. The major strengths of the instructor is the humorous and intellectual approach he takes towards teaching. He doesn't talk down to students and speaks with them as equals (even though he's obviously a lot smarter than most of us!!!) :) No weaknesses that I'd complain about.
5. Professor Riely provided an environment very conducive to learning the material. He always appeared to be very enthusiastic and knowledgeable on all topics. I would definitely enroll in another course he teaches in the future.
7. Energetic, seemed to really enjoy teaching class, not afraid to be opinionated. These are all good things.
9. Strengths: Knows the material backwards and forwards, happy to explore and answer questionsWeaknesses: Some organizational issues
What aspects of this course were most beneficial to you?
2. yeesh...everything! Studying the design patterns were loads of fun. Studying the intricacies of java wasn't as fun...but nonetheless very important.
3. Writing large amounts of code.
4. Learning really how to program in object-oriented paradigm instead of just going through the motions. This is a vital class in a programmer's development.
7. Knowing more about what the OO Patterns people are talking about, instead of avoiding it from afar.
8. The multi-phase explanation of behavior and design patterns. Showing the code, the problem solved, class diagrams and interaction diagrams was very effective.
9. The final project. Paradigm-shiftingly difficult, but I learned a lot.
What do you suggest to improve this course?
2. He was changing the notes this quarter, so I wish they were a little more concise...but overall they were fine. I think a lot of the early topics we covered about Java...most people should have already known...so going through them faster would be great, and focusing much more on patterns would be better.
3. We could cover much more material. I think a lot of class time was spent going over material in the reading and assignments rather than moving on to new material. It is good to spend a lot of time coding but the time requirement of the course was a bit too much. I spent a lot of time doing a lot of easy programming for assignments and project. This was good practice but not the best value for my time.
4. I like Dr. Jia's book, but it doesn't apply to this course completely. The most important texts for this course are: "Design Patterns Explained" by Shalloway (a recommended text) and, even more importantly, "Effective Java" by Bloch. The "Effective Java" text should be REQUIRED for this class because it closely tracks lecture topics. It's not a recommended text though. PLEASE CONSIDER THIS!!! It will help future students in my humble opinion.
5. The Course Text by Xiapong Jia did not seem appropriate for this course. There were many holes in the book with respects to preparation for the Core Exam. However, the "Effective Java" book by Jeremy Bloch (recommended by Professor Riely) seemed to be much more suite to this cours.
6. Write more detailed instructions of what has to be done for each assignment. It took me quite a bit of unnecessary time to figure out what neeeds to be done on some of the assignments.
7. A little more feedback on the project. It's binary, all or nothing until the end, and while I realize it'd be very time-intensive, stylistic or other comments in the meanwhile would be nice. (If I'd really wanted that, I suppose I could've just asked, though...)
9. Use the COL tools. GNU is great, but the class shouldn't be about all of us trying to find a way to make efficient usage of the GNU tools that you have chosen to use as a seemingly-unnecessary alternative to the tools that DePaul provides (i.e. class announcements, discussion groups, etc.). Unless the tool that you want to use adds functionality that is missing from the existing COL tools, PLEASE use the tools that we all already know how to use so that we can focus on learning the subject matter of this course.
Comment on the grading procedures and exams
2. Grading was fine. And for the first time, i have had an exam in CTI that actually made me sweat!!!!!!!!!!!!!!!!!!!!!!!
6. The mid-term was not very hard, but it was a problem that we were required to do too much work for 2 1/2 hours, so I lost points not from not knowing what I was doing, but because I did not have enough time to complete it. For some students that might bring in a "no time left" panic factor while taking the exam which results in not showing the actual student's knowledge. Reconsider reducing the amount of questions, or increasing the time for the exam. I consider not having enough time is considered unfair.
9. The exam that we have taken seemed like a fair assessment of what we had learned. Grading seemed fair.
Other comments?
1. Professor liked to "scratch" himself (lower private part of the body).
2. Awesoem professor, awesome class...need I say more?
7. Fun class. I was wary at first, but the fact that Riely was willing to teach an OO development class by spending the first half of the quarter talking about something _besides_ inheritance made me happy. "Object-oriented" might actually mean something nowadays.
9. Just one thing, really. Please put your examples together before class. Don't make us watch and wait, then draw, scratch out, correct code and diagrams while you figure out an example up in front of the class. This makes our notes a mess to try to decipher later, outside of class. E.g, if you know that you are going to talk about nested classes and provide an example of same, put it together before class so that you know what you are doing when you get in front of the class. When you know what you are doing and not figuring it out as you go, it makes it easier for us to follow you. Obviously I'm not talking about when you deal with specific questions raised inside class, I mean the examples built into the lesson plan. Usually you have one example in the class notes but you build on that on the board for examples and that's when it gets unpredictable.Mostly, though, this was a great class. This is just kind of a pet peeve.