This summer I'm revisiting my short apprenticeship at Object Mentor. I'll be posting commentary on all my posts from the summer of 2004 exactly 5 years later to the day.
Today was the first day of my Advanced Object Oriented Design (AOOD) class. David's teaching Paul and I in order to make sure he's familiar with the material and can teach paying customers next week. After covering the usual X.P. verses Waterfall stuff and briefly touching on how good OO design can keep your code loosely coupled (in a tightly coupled design each class depends on several other classes, which in-turn depend on a few other classes and so on. The bad news is that changing one class means that you have to change every other class that depends on it. And since everybody is holding hands with everybody else, that could mean hundreds of changes for each modification. No me gusta. Loosely coupled code has objects that, through interfaces and clever structure, can be changed without having to track down bunches of dependencies) we moved on to some UML (Unified Modeling Language -- a way to get a global view of the code you are about to write). Which is cool because although I've been looking at and trying to draw UML for a month or so now, I could really use some formal training. We used UML to design a state machine that strips code of its comments. In a few languages (mostly C derived) two slashes mean that the rest of the line is a comment and should not be read by the compiler. Or anything between a slash and a star and then another star and a slash is a comment. For example:
Not a comment // comment all the way 'till the end 'o the line
Not a comment /* comment */ not a comment
So we wrote out a bunch of UML and it was pretty interesting. I like all the cases where the object loops back to itself -- I don't know why I find that cool, I just do. After working on that SMC for a week or so I had a pretty good foundation in State Machines but it was fun to try out my ideas on something new. Later we had to make a UML diagram for a cash register. There were a number of user stories which we had to accommodate. Knowing something about teaching, it didn't come as a great surprise that this exercise was supposed to be a bit of a failure. The were multiple dependencies and inversion violations and single responsibility problems as far as the eye could see. And this was after an hour's work. But the point of the class is to get us to be able to use design patterns to eliminate (or at least minimize) these problems. It's basically a patterns class. Patterns are the idea that many programming problems boil down to the same idea and that there are well thought out ways to deal with these common problems.
Oh, and I've got a potential solution to the Word Press problem. The install.php file needs to be run by the server. In other words, I need to request the file from Apache which knows to execute .php files. Interesting. This was nowhere in the installation notes, but I guess they probably assumed that anyone trying to set up a server would know how things are done with servers. I didn't have much time today to try out this idea (which Micah came up with) but maybe tomorrow. Although, with the class this week I won't have a lot of extra time.
Weird that I just had dinner with David (Chelimsky) and his lovely lady friend Flor and now I'm writing about him teaching me a class. David and I actually live in the same condo complex in Rogers Park. This happened more or less by accident. David currently works for Articulated Man and I for Obtiva -- we've never worked together professionally but have remained friends.
Did you see that part about how you're not supposed to run the install.php file through the command line but by hitting it through a web-browser? I didn't know at the time that Apache would just figure the rest out and the people who wrote the instruction manual probably didn't think they had to point out something so basic. A common problem when I was getting into software was that no explanation was basic enough for the likes of me.