Test
The test was pretty much what I expected format wise. I think that it was missing some of the more current stuff we had taken a bit of time in class on. The reading questions are never my favorite, but remembering potty names for pair programming was probably my least favorite. Knowing the proper way to pair program is important, knowing the exact analogy being made in a section of a paper is less important.
Database Design
I've never had the experience of working on a large project dealing with a database. During one of my summers, I had a very small database shared between three people and it was understandably not a huge headache. :) The mention of a DBA (say what?) or database administrator was new to me. I've never encountered one in my summerly adventures. I do see how databases make rapid development a lot more difficult even from my 3 person database adventures, so normal databases must be pretty bad. It seems like a good thing to know how to handle.
Project
I'm looking forward to the next project. This is one that I've heard mentioned in the lab many-a-time. It seems like another one of those projects where you kind of wish you had all the time in the world to play with it and speed it up, but sadly, you don't, and there are other things to be doing.
Sunday, September 25, 2011
Sunday, September 18, 2011
Week #3
Unfortunately, I missed a day of class this week. The code samples at least showed me what the we covered, and some of the material came up again in the next class, so it should be fine except for that -5 pts and +1 to missed quizzes. :( We're still covering basic but invaluable things to know in the language you're using. Not knowing how efficient your code is can absolutely destroy the usefulness of all your hard work, and the sad thing is we don't get taught about surprisingly inefficient things (like string concat) even after we've used it many, many times.
On the project side of things: My partner and I got a simple solution accepted by Sphere pretty quickly, but it was really really slow, so we're working on getting our faster solution accepted.
On Extreme Programming:
Honestly, I was really happy to be done with the XP book we were assigned. It has a lot of great advice about getting a product out there and then some wishy-washy stuff. In the end, it just got to be ridiculously repetitive. I wish there was a book that was exactly the same but about half the size, because they could manage to fit it in that amount of space if they didn't repeat themselves that much.
The Afterword was the combined most enlightening/frustrating part of the book. It was enlightening because of the point he was making about it being validation centric. Releasing things that work is important. Nobody can argue that. (The huge problem of releasing things that pass all the tests but still aren't that great still exists though.) On the other hand, the "because XP does everything to the extremes" being repeated drove me absolutely crazy. NOOOO! I know XP has extreme in the name, but to do everything to the extremes is never a good idea. Whenever the book mentioned taking something to the extreme (and then softly mentioning in the background that its actually impossible to do it that way), I cringed so much. If pretending works for you, then it works, I just don't like pretending in this kind of situation. I'll stay with my Almost Extreme Programming.
I don't know where the line gets drawn between good ol' programming practices and extreme programming from the book, because they speak like they created everything. Nevertheless, the goals of XP seem like great things to get done: improved communication, constant validation, changing design. If anybody is under the impression that there are people out there doing pure waterfall method right now, that is sooo wrong. Employees and teams and companies have evolved. Some better than others. Some companies do pick up Agile/XP. The team I was on at Cisco Systems was changing to Agile shortly after I left. Others take bits and pieces (but I don't give XP credit for those bits and pieces, I give credit to multiple people figuring out the same thing because it tends to be the right thing). In my opinion, all of the things that are good about XP can be achieved in other ways, without this weird system.
I'm actually going to spend more time looking into other methodologies when I have more time. Somebody out there has probably already created what I see as the perfect programming methodology -- I kinda hope nobody has because I prefer the way I work not having a name that can be hyped and sold. Need to get some rest for the career fair for now though. :)
On the project side of things: My partner and I got a simple solution accepted by Sphere pretty quickly, but it was really really slow, so we're working on getting our faster solution accepted.
On Extreme Programming:
Honestly, I was really happy to be done with the XP book we were assigned. It has a lot of great advice about getting a product out there and then some wishy-washy stuff. In the end, it just got to be ridiculously repetitive. I wish there was a book that was exactly the same but about half the size, because they could manage to fit it in that amount of space if they didn't repeat themselves that much.
The Afterword was the combined most enlightening/frustrating part of the book. It was enlightening because of the point he was making about it being validation centric. Releasing things that work is important. Nobody can argue that. (The huge problem of releasing things that pass all the tests but still aren't that great still exists though.) On the other hand, the "because XP does everything to the extremes" being repeated drove me absolutely crazy. NOOOO! I know XP has extreme in the name, but to do everything to the extremes is never a good idea. Whenever the book mentioned taking something to the extreme (and then softly mentioning in the background that its actually impossible to do it that way), I cringed so much. If pretending works for you, then it works, I just don't like pretending in this kind of situation. I'll stay with my Almost Extreme Programming.
I don't know where the line gets drawn between good ol' programming practices and extreme programming from the book, because they speak like they created everything. Nevertheless, the goals of XP seem like great things to get done: improved communication, constant validation, changing design. If anybody is under the impression that there are people out there doing pure waterfall method right now, that is sooo wrong. Employees and teams and companies have evolved. Some better than others. Some companies do pick up Agile/XP. The team I was on at Cisco Systems was changing to Agile shortly after I left. Others take bits and pieces (but I don't give XP credit for those bits and pieces, I give credit to multiple people figuring out the same thing because it tends to be the right thing). In my opinion, all of the things that are good about XP can be achieved in other ways, without this weird system.
I'm actually going to spend more time looking into other methodologies when I have more time. Somebody out there has probably already created what I see as the perfect programming methodology -- I kinda hope nobody has because I prefer the way I work not having a name that can be hyped and sold. Need to get some rest for the career fair for now though. :)
Sunday, September 11, 2011
Week #2
Another week in Software Engineering. Finished Collatz, and it wasn't as stressful of an experience as it was last year. It still took longer than I expected because I attempted to make it faster, but it didn't actually make much of a difference. I'm very glad that the extra credit was only required for one of the languages, since I was having trouble with the python being accepted, and I heard it was a problem with the skeleton which I would have been very unlikely to find.
V2 was also very weird, since it forced you to give the wrong answer. Comparing it with the readings for this week, I would say it's teaching the wrong lessons. "Only make the size of a number as large as it needs to be" = things exploding in space, but on land we're forced to do it. =)
Still going over the basics of Python in comparison to Java. Haskell is also thrown in there and I'm not exactly sure why we're including it also. It's a really weird language.
I'm looking forward to getting into pair programming even though its another OOP project.
Monday, September 5, 2011
Week #1
The first week (plus the little half week beforehand) was very very similar to Object Oriented Programming CS371P. Pretty much take the same content and swap in some Python for C++. I'm sure the repetitiveness will end quickly as we move past the first project, but I don't have much to say about the content of the class currently. I expect all the arm twisting by now. :)
I'm as excited about this class as I was for OOP. For OOP, I took the class to improve my C++, plus I had heard that it was a good class to take because you learn things you actually use out there in the real world. I had wanted to take Software Engineering since before I took OOP, for no other reason than "That's the title of my future job. I might want to take that class". Of course, I've learned more about what the course is actually about, learned how much you get out of a Downing class, and think it sounds like a great class to take. I took a one hour python class, but I still have much to learn on that front. The whole entire situation with group projects puts you in an environment that resembles the real world much more than any other part of this CS program which is something I'm looking forward to.
The Downing Experience of class is still definitely there, and I don't think I'll ever be fully prepared to be called on. :P
I'm as excited about this class as I was for OOP. For OOP, I took the class to improve my C++, plus I had heard that it was a good class to take because you learn things you actually use out there in the real world. I had wanted to take Software Engineering since before I took OOP, for no other reason than "That's the title of my future job. I might want to take that class". Of course, I've learned more about what the course is actually about, learned how much you get out of a Downing class, and think it sounds like a great class to take. I took a one hour python class, but I still have much to learn on that front. The whole entire situation with group projects puts you in an environment that resembles the real world much more than any other part of this CS program which is something I'm looking forward to.
The Downing Experience of class is still definitely there, and I don't think I'll ever be fully prepared to be called on. :P
Subscribe to:
Posts (Atom)