Final Post

We took the last exam in class yesterday, and I'm not quite sure how it went. As far as the two questions about reflection in Java and Python, I did fine, but I'm afraid I didn't quite remember everything I needed to for the "Tease apart inheritance" question. Maybe that's because I didn't bother to review the Refactoring book too much in depth. We got the final grade for our TA4 submission, and I was very pleased with that. It's been a very productive semester, and I feel like I've learned quite a lot from this class. Farewell CS373...

May 4 - 8

NEWS FLASH: Well, I got my official job offer from IBM this past Tuesday, so I'm pretty excited about that. I'm looking taking a break from class and having my evenings and weekends free again. This constant grind of HW, projects, and studying for exams this semester has really drained me, and I need a break.

This past weekend we made the final submission for the TA matching project. We already had a lot of the required functionality implemented from previous phases. However, we had a few outstanding bugs to fix with the SMP, and a couple other minor things.

Looking back after it's all done, this project was probably the most valuable experience of my undergraduate experience in the CS department. Working with a team to design, implement, and test a (somewhat simple) application is more closely related to what we'll be doing in the real world than the typical "black box" type of spec that we're so often given on projects.

I'm also glad the Downing forces everyone to use Subversion on every project. This was my first time to use Subversion, and I wrote a short post about basic Subversion Stuff if you're just getting started with it. By the way, I also wrote a post about setting up SVN+SSH with Subclipse. I wish I'd been shown some sort of version control tool in my first computer science class here, to be honest. Although, I probably wouldn't have appreciated the value of it at that time.

As far as the future of our webapp, I'd like to transfer it to my own google app engine account and possibly continue to work on it when I feel like it(now that I'm going to have a bit more free time!!!).

April 27 - May 1

CHANGE OF PLANS... Well, originally I had decided to take summer class and graduate December 09. However, in response to a recent email about a 7-month co-op at IBM from June 1 to December 31, I emailed my resume to the guys at IBM here in Austin. Later that afternoon I found myself in an 80 minute phone interview, and a few days later I made a visit to the IBM campus in north Austin. The job is a "Software Support Engineer", and the 7-month work experience will be a much needed break from class. If this opportunity pans out, I'll won't return to classes here until Spring 2010, but I'll return refreshed and re-energized for my last semester. I'll keep my fingers crossed.

April 20 - 24

We submitted the third phase of the project last Sunday, and this week we began looking at a few Design Patterns. We're tying refactoring in with these well-known design patterns. Apparently, Downing explores that design patterns book a lot more in-depth in his CS371p - Object Oriented Programming course. In fact I signed up to take that course in the upcoming fall semester. Glenn Downing definitely has a unique teaching style that I really appreciate, and I look forward to the opportunity of taking another of his courses.

April 13 - 17

This week was another day of presentations and some SQL stuff. Our TA app is definitely the most minimalistic as far as looks go, but at least we have a solid backend. Oh well, that's what graphic designers are for, to make things look pretty...my job is just to make it work.

April 6 - 10

Last weekend my team submitted the second phase of our TA project. After hours and hours of refactoring, we had a code-base that was much more scalable and provided for a more rapid development cycle when we needed to add functionality. Google conveniently includes the Django template system as an option in the app engine. We decided to add this to our application because it allowed us to separate the presentation and business logic a bit more.

New additions to this phase were:

1. introduce the notion of time into the app
   
   
   
   • admin initializes system by choosing a semester, setting up classes (uniques), etc.
   
   
   • applicants apply
   
   
   • instructors apply
   
   
   • admin asks for a match, overrides some matches, and finalizes (for now, fake the match)
   
   
   
   


2. create a database schema consisting of models with properties and relationships and the ability to make queries:
   
   
   
   • models
   
   
   • properties
   
   
   • relationships
   
   
   • queries
   
   
   
   


3. enter a set of test data


4. pick a member of the group to give a demo in class of your models, properties, and relationships

Due to the overwhelming amount of refactoring that we did, we ended up missing the deadline on this submission by a day. Oh well, it was worth it to have more readable and modular code.

March 30 - April 3

This week consisted of presentations from the teams in my section of the course. I really like seeing the other teams' apps because it lets us each show off the various technologies and frameworks that we used. Unfortunately, none of us on my team had really done any real web programming, so needless to say, our app was a bit lacking in many areas. Once we saw the other apps and got some better ideas, we decided to put our newly acquired Refactoring knowledge to work and do a major overhaul of our code. More on that next week...

March 23 - 27

We began reading the Refactoring text this week. It seems like the techniques in the text will be very helpful, especially as the TA matching projects progress.

My group made our first submission for the TA project this Wednesday. Luckily the deadline was extended an extra three days because of spring break. In spite of the extension, my group ended up spending the majority of Monday, Tuesday, and Wednesday in the Taylor basement lab trying to finish all of the requirements. The objectives of this phase were to:

• convert the informal description into a formal specification


• create a series of web forms to collect the required input


• create a series of unit tests of each field of every form


• pick a member of the group to give a demo in class of your forms and their validation

By the way, every group's webapp will be developed on the Google App Engine platform using Python. Here's a pointer to my team's app.

March 16 - 20

SPRING BREAK!!!! w00t w00t

March 9 - 13

We finally finished up the DB Design book this week. Marcus Marler, a web designer for the UT Comp. Sciences dept., also came to class to demo his TA matching system that he designed for the department. The significance of his visit is that he was showing us the fully implemented system that each group in our class would (attempt to) recreate over the next eight weeks.

The purpose of the system is to match graduate students who apply to TA a CS course with courses that need TA's, using the Stable Marriage Problem algorithm, which happened to be individual project that everyone just submitted last weekend. The system has three types of users: Administrators, Faculty, and TA applicants. As the project unfolds, I'll share more.

March 2 - 6

We're STILL reading that wonderful DB design book this week. On a happier note, I've learned about another nifty little gem in the language of Python this week's examples. We looked at Python generator types(amongst other things). Similar to my last post, using Python Generators gives another type of persistent storage for the function. Take a look at this example:

def f (b, e) :
while b < e :
yield b
b += 1

This simple function generates all the integers in the range [b, e). This "yield" machinery seems to function like a sort of stored program counter for the function. Each time the generator is prompted for the next value, the program counter resumes where it left off.

Feb. 23 - 27

The reading assignments for this week are still from the online "DB Design" text. One of the more interesting Python examples we've looked at this week was about function defaults. Take a look at this example:

def h1 (y = []) :
assert(type(y) is types.ListType)
y += [2]
return y

Now, if I were to make these two calls:

h = h1()
h = h1()

h would be equal to [2, 2]
This mutable default array lives on as a sort of memory for the function, which isn't exactly what I would have expected.

Now, if I were to make another call to h1([1]) with an argument, the default array gets wiped away. To be clear, at the end of this sequence of statements:

h = h1()
h = h1()
h = h1([1])

h now equals [1, 2]

and one final call:

h = h1()

results in h equal to [2, 2, 2]

So it seems that the persistent array is actually persistent and surfaces any time an argument isn't give.

Although this strange behaviour might introduce a bug into an unsuspecting programmer's function, it can also be a very attractive way of giving a function some persistent storage...possibly a useful feature if you wanted to write something like a primes generator.