First, the test. I was pleased with how you did. While the averages on my tests are usually lower, I think I asked the questions that mattered and you all just did well. That's a good thing! I was only kidding about making things trickier!
Second, the class. Things seemed Ok to me today. I think the command pattern is pretty straight forward and the example in the book is better than most because it seems more realistic. Most of you seemed to be with me; we'll see if that's true when you work on the lab.
Third, the paper. I would like to see your drafts before break, but I do have email over break and will give at least some feedback whenever you give it to me. I just don't promise to be as available over break as I usually am! I still think you've never written a paper like this, so expecting to do it well without any feedback is naive. I'd really prefer to help you than to have to grade incomplete papers.
Tuesday, February 27, 2007
Wednesday, February 21, 2007
Singleton
Boy, the Singleton lecture was fun! You all did a great job with the dining philosophers game. It's interesting to me how many different variations of solutions students come up with for that problem. For this class, the details of that problem are irrelevant; my goal in playing the game was for you to see the devious scheduler and I think we achieved that goal very well.
When we went into the various options for Singleton implementations, more of you were participating than ever before and, more than any class I've ever had, you seemed able to spot the places where the devious scheduler could rear it's ugly head. In previous classes, the double checked locking examples have always confused everyone and making them see why you need two conditionals was a terrific challenge. This time, you were right with me!
At this point, I'd say at least three quarters of you are actively participating in class and are really thinking about what we're doing and where we're going. That's a HUGE improvement from where we started the year and I'm really impressed with you. With those skills, we'll have some fascinating discussions as we get into the more complex patterns.
Obviously, I think Singleton went well. However, if you have questions, please ask them. We aren't going to do a Singleton lab (we have an exam and it'd be pretty trivial), but I think you'll see one in our big project.
If you have questions about the exam, I'll be on line most of tonight and I'll be in my office early (7ish) tomorrow morning!
When we went into the various options for Singleton implementations, more of you were participating than ever before and, more than any class I've ever had, you seemed able to spot the places where the devious scheduler could rear it's ugly head. In previous classes, the double checked locking examples have always confused everyone and making them see why you need two conditionals was a terrific challenge. This time, you were right with me!
At this point, I'd say at least three quarters of you are actively participating in class and are really thinking about what we're doing and where we're going. That's a HUGE improvement from where we started the year and I'm really impressed with you. With those skills, we'll have some fascinating discussions as we get into the more complex patterns.
Obviously, I think Singleton went well. However, if you have questions, please ask them. We aren't going to do a Singleton lab (we have an exam and it'd be pretty trivial), but I think you'll see one in our big project.
If you have questions about the exam, I'll be on line most of tonight and I'll be in my office early (7ish) tomorrow morning!
Monday, February 19, 2007
Factories
I liked both of our factories days (the lecture and the "lab"). We are beginning to get to the point where we can talk about more details than just the structure of the pattern. Good software developers know the patterns; great ones know when to apply them.
In the lecture, walking through the code instead of having me present it modeled an important skill: learning to read someone else's code. I wasn't kidding when I said that one of the first things you'll have to do on the job is make sense of someone else's code. Strategies for making sense of code that is made of many classes are useful things to know.
However, I also liked the discussions that we had about the pros and cons of each of the factory patterns. Those are the things that development teams debate when they are selecting a design and learning to weigh those considerations is an important goal for this class. We carried that much further when we talked about the paper. I know you all hate papers, but I think that it'll give you an experience that will be valuable when you graduate.
I'd like to offer some sage advice: when your management (or faculty member) offers to review something before it's due date, you should take advantage of that mentoring opportunity. This paper is very different from anything you've had to do in the past and it counts for a good portion of your grade (it is one of two projects), so getting advice for a more senior member of the team doesn't show weakness - it shows wisdom.
In the lecture, walking through the code instead of having me present it modeled an important skill: learning to read someone else's code. I wasn't kidding when I said that one of the first things you'll have to do on the job is make sense of someone else's code. Strategies for making sense of code that is made of many classes are useful things to know.
However, I also liked the discussions that we had about the pros and cons of each of the factory patterns. Those are the things that development teams debate when they are selecting a design and learning to weigh those considerations is an important goal for this class. We carried that much further when we talked about the paper. I know you all hate papers, but I think that it'll give you an experience that will be valuable when you graduate.
I'd like to offer some sage advice: when your management (or faculty member) offers to review something before it's due date, you should take advantage of that mentoring opportunity. This paper is very different from anything you've had to do in the past and it counts for a good portion of your grade (it is one of two projects), so getting advice for a more senior member of the team doesn't show weakness - it shows wisdom.
Thursday, February 8, 2007
Decorator Lab
I was pleased with today's lab! Some of you asked very good and insightful questions which made me very happy! I don't know why, but Decorator seems easier than Observer for students every semester. I'm glad we've hit on something that seems to be going better; maybe we're over the hump . . .
Tuesday, February 6, 2007
Decorator Lecture
I certainly had fun in class today. As always, I hoped for more questions, but maybe it's OK. At least you're talking to me now. :)
With today's lecture, I was trying to show you real code for a bunch of examples because the decorator is easy to see, but the details can be strange to follow. You really have to be disciplined about delegating to the inner object because you can't depend on the order in which the decorators will be applied (in other words, no decorator should make assumptions about which things it wraps).
My mom suggested that I force you to talk more during class by making you repeat what I just said. I really don't want to do that because I want you to learn how to ask questions. As an alternative, let me give you a suggestion: any time I say something, you should be asking yourself, "Why is it that way? Could it be any other way? If something changed, how would that affect the pattern?" For example, when I say all of the decorators have to be subclasses of an abstract decorator class, you should be thinking, "Why is the decorator an abstract class? Could it be an interface? What would happen if I had two different categories of decorators? etc." Always be trying to figure out the motivations for and the limits of each pattern we discuss. Maybe that will generate some questions next time!
With today's lecture, I was trying to show you real code for a bunch of examples because the decorator is easy to see, but the details can be strange to follow. You really have to be disciplined about delegating to the inner object because you can't depend on the order in which the decorators will be applied (in other words, no decorator should make assumptions about which things it wraps).
My mom suggested that I force you to talk more during class by making you repeat what I just said. I really don't want to do that because I want you to learn how to ask questions. As an alternative, let me give you a suggestion: any time I say something, you should be asking yourself, "Why is it that way? Could it be any other way? If something changed, how would that affect the pattern?" For example, when I say all of the decorators have to be subclasses of an abstract decorator class, you should be thinking, "Why is the decorator an abstract class? Could it be an interface? What would happen if I had two different categories of decorators? etc." Always be trying to figure out the motivations for and the limits of each pattern we discuss. Maybe that will generate some questions next time!
Thursday, February 1, 2007
Observer Lab
Today's lab met my expectations, and I think I need to re-make my point about efficiently using your time.
I have no doubt that, if you bang your head against it enough, every one of you could figure out how to build this code on your own. However, most of you barely got through making PriceHistory observable (any many of you didn't even get that far) before class was over. This means that you've spent a lot of time on material that isn't central to the topic we're studying. There are a limited number of hours in a day and you have more classes than just mine, so I have trouble believing that you have time to bang your head long enough to do this on your own. It's a question of using your time efficiently.
When you leave school and get a job, they are going to want you to be an independent problem solver. However, they are also going to want you to be able to recognize when you are wasting their money by banging your head over a problem. You will be part of team that is depending on you to get things done efficiently. The abilities of knowing when you're stuck and knowing how to ask insightful questions that are targeted on getting the job done are part of being a strong developer.
I really do want to help and I enjoy answering your questions, so please try to use the resources around you more efficiently!
I have no doubt that, if you bang your head against it enough, every one of you could figure out how to build this code on your own. However, most of you barely got through making PriceHistory observable (any many of you didn't even get that far) before class was over. This means that you've spent a lot of time on material that isn't central to the topic we're studying. There are a limited number of hours in a day and you have more classes than just mine, so I have trouble believing that you have time to bang your head long enough to do this on your own. It's a question of using your time efficiently.
When you leave school and get a job, they are going to want you to be an independent problem solver. However, they are also going to want you to be able to recognize when you are wasting their money by banging your head over a problem. You will be part of team that is depending on you to get things done efficiently. The abilities of knowing when you're stuck and knowing how to ask insightful questions that are targeted on getting the job done are part of being a strong developer.
I really do want to help and I enjoy answering your questions, so please try to use the resources around you more efficiently!
Subscribe to:
Posts (Atom)
