We had the last test today. It was a bit tougher than the first two. We'll see how I did -- but I definitely feel like I'm going to need the 10 points from this blog.
Anyway, I saw this yesterday and thought it noteworthy. This student found out about a musician's death and quickly posted a harmless but falsified quote on the musician's wikipedia entry. Some legit media outlets ran with the quote. Pretty interesting, and indicative of very poor journalistic integrity. I feel like it's hard to trust much these days, and this does not help my apprehension.
SCHOOL'S OUT!
P.S., check this out. Seriously.
Friday, May 8, 2009
Thursday, May 7, 2009
For those interested...
I don't know how many other kids grew up playing Blizzard's StarCraft, but I was excited and nostalgic when I saw that Blizzard/Battle.net had opened up their beta signups for StarCraft 2! Apparently all you do is sign into your Battlenet account and click on Manage My Games. There should be a link to "Beta Profile Settings" there. This comes from Slashdot.
While I love StarCraft (and will play the beta/final release), I am really waiting on the beta period for Diablo 3. If anyone played Diablo 2, you remember how addicting that game was. Fire Sorcs, Corse Explosion Necros (before they got nerfed on the first patch :( ), WW barbs, hammerdins. I feel like I'm 14 again. Although I was playing Diablo 2 well into high school (and even some in college, I'm ashamed to say).
TA4
Our TA4 submission was probably our best one of all. And we didn't even work in the lab together the final Sunday! All of us worked together over gmail/gchat and got our respective tasks done. Not to mention we all had worked hard on our own piece of the final project before the weekend to avoid the clusterf*ck that had been our last two submissions.
My job was to implement the Class Search and Applicant Search. What I did was create various fields to narrow down search results. For example I had a "What semester?" dropdown, and an "Assigned Or Unassigned TAs" dropdown, a multiselect box of all specializations, a select field for programming languages, instructors, previous courses. All of these could be used to narrow applicants results.
The way I implemented the search was by starting with every ApplicationEntry we had in the datastore. I would .get() each ApplicationEntry's key and use it as the key in a dictionary, results_dict. For the values, I used a boolean value that was initially set to True. As each field was probed for input, I would run through the dictionary, only modifying an entry if the input in the respective field restricted the Applicant from being returned as a result.
Thus, if the user wants ApplicantEntrys from the semester Fall 2009, we would test the semesterKey in each ApplicationEntry to see if it was Fall 2009. If not, we set the value in results_dict to False.
We did this for each field that showed input, and then once we were done, we built a list of all ApplicationEntrys that were still True in results_dict after all search fields were completed, and returned the list to the django template file, where the results were displayed.
Our project probably looked the most basic out of all of them, but since the graders say they weren't taking points off for how the app looked, we did not care.
My job was to implement the Class Search and Applicant Search. What I did was create various fields to narrow down search results. For example I had a "What semester?" dropdown, and an "Assigned Or Unassigned TAs" dropdown, a multiselect box of all specializations, a select field for programming languages, instructors, previous courses. All of these could be used to narrow applicants results.
The way I implemented the search was by starting with every ApplicationEntry we had in the datastore. I would .get() each ApplicationEntry's key and use it as the key in a dictionary, results_dict. For the values, I used a boolean value that was initially set to True. As each field was probed for input, I would run through the dictionary, only modifying an entry if the input in the respective field restricted the Applicant from being returned as a result.
Thus, if the user wants ApplicantEntrys from the semester Fall 2009, we would test the semesterKey in each ApplicationEntry to see if it was Fall 2009. If not, we set the value in results_dict to False.
We did this for each field that showed input, and then once we were done, we built a list of all ApplicationEntrys that were still True in results_dict after all search fields were completed, and returned the list to the django template file, where the results were displayed.
Our project probably looked the most basic out of all of them, but since the graders say they weren't taking points off for how the app looked, we did not care.
TA3
TA3 submission did not go smoothly. We had issues all the way up to midnight and even then we took a late-submission hit and resubmitted Monday after realizing that our matching algorithm was not working correctly. But we got it working and did fine.
Our algorithm added +1 points to a TA if he/she had listed the specific specialization and/or programming language(s) that was desired by an instructor of a class (each type a new class was considered, all available TAs started with zero points). +2 if a TA was "qualified" to teach a course, and +3 if he/she had taught the course previously.
We thought we had it all worked out until we found that our matching code was using TAs from all semester. Thus John from Fall 2008 and John from Spring 2009 could be assigned to a Fall 2009 class even though they are the same person spread among 3 semesters). So we had to resubmit but it was all OK. Hopefully TA4 will go a lot smoother. We'd better use our time wisely for the next submissions since they are stressing that they won't be as lenient for the final iteration.
As for the algorithm, a few simple modifications were used to implement the point system. After that, it was comparable to dropping in a fancy new engine into an old car. All we had to do was make the connections. A nice little break from having to code a huge piece of software since we all already had it from Project 3.
Our algorithm added +1 points to a TA if he/she had listed the specific specialization and/or programming language(s) that was desired by an instructor of a class (each type a new class was considered, all available TAs started with zero points). +2 if a TA was "qualified" to teach a course, and +3 if he/she had taught the course previously.
We thought we had it all worked out until we found that our matching code was using TAs from all semester. Thus John from Fall 2008 and John from Spring 2009 could be assigned to a Fall 2009 class even though they are the same person spread among 3 semesters). So we had to resubmit but it was all OK. Hopefully TA4 will go a lot smoother. We'd better use our time wisely for the next submissions since they are stressing that they won't be as lenient for the final iteration.
As for the algorithm, a few simple modifications were used to implement the point system. After that, it was comparable to dropping in a fancy new engine into an old car. All we had to do was make the connections. A nice little break from having to code a huge piece of software since we all already had it from Project 3.
TA2
TA2 was a hectic submission. Almost no work had been done prior to extended deadline (Wednesday after Spring Break). Thus we were all in the Taylor basement until midnight. We all had separate pages to code and we were pretty disjoint during this iteration (SB and all).
However, we ended up doing OK. Our database scheme consisted of the typical things you'd think you needed: TAApplicationEntry (holds all applicant info), UserEntry (holds names, user-types, and eids), SemesterEntry (to remember what semester was active, if TAs could apply/instructors submit preferences), ClassEntry (holds all data related to specific classes), CourseEntry (holds all courses taught), MajorEntry, ProgrammingLanguageEntry, etc. Tough to work out a useable schema but we did it and I think it works well.
However, we ended up doing OK. Our database scheme consisted of the typical things you'd think you needed: TAApplicationEntry (holds all applicant info), UserEntry (holds names, user-types, and eids), SemesterEntry (to remember what semester was active, if TAs could apply/instructors submit preferences), ClassEntry (holds all data related to specific classes), CourseEntry (holds all courses taught), MajorEntry, ProgrammingLanguageEntry, etc. Tough to work out a useable schema but we did it and I think it works well.
TA1
TA1 went good. We learned a lot on the fly. We first hardcoded every field we had with pure html in all of our .py files. We quickly realized that this practice would be cumbersome and extremely 'non-robust.' We saw one group made a Field class and extending subclasses such as "TextBoxField," "SelectField," and "MultiselectField." This made life infinitely easier, as well as enabled us to use the Django templates by passing a dictionary with strings as the keys and any other data type (lists, booleans, whatever) as the values, that were THEN callable inside the template .html files. This was a very useful implementation and had we not done that, our subsequent TA submissions would have been the cause of many more headaches than they were anyhow.
Monday, March 23, 2009
Oops?
Yeah, been a while since the last post. Got caught up in pre-SB tests and SB itself. But school is starting up again today for the home-stretch. Got absolutely no work done over spring break and will spend most of my night in the Taylor basement. My team has not communicated but I'm confident we'll be fine as we'll iron out who does what today in class. More to come after I work on my part of TA1.
Subscribe to:
Posts (Atom)