kmehan / gt-course-critique Goto Github PK

When a Professor has multiple sections of the same course in the same term, the Critique calculates a simple average of the sections to determine the overall distribution.

For instance:
http://critique.gatech.edu/course.php?id=CS6035
Indicated Prof. Ahamad's sections in Fall 2013 had a 31% Withdrawal Rate. In actuality there are two sections of the class (http://critique.gatech.edu/prof.php?id=AHAMADMUSTAQUE#CS6035)
One section has a 50% withdrawal rate and only 2 students and one section had a 12% withdrawal rate and 25 students. It appears the site is using a simple average (50 + 12) / 2 = 31. The real averaged W rate should be (.502 + .1225) / (2+25) = 15%.

I believe this is related to #16

When sorting by semester, Fall is more recent than spring.

The idea is to perform exact matches on strings in course.php and prof.php.
IMO equals would be the best choice here.

It will also take care of #25.

CS3220 and CS 3220 should both work as search queries.

The terms select on the course/professor page, i.e. example, is not sorted as I would naturally expect it.

Currently it is sorted like:

It should be sorted by year then Fall, Summer, Spring (latest to oldest):

• Fall 2011
• Summer 2011
• Spring 2011
• Fall 2010
• Summer 2010
• Spring 2010
• Fall 2009
• Summer 2009
• Spring 2009
• Fall 2008

Of course the exact sorting is not particular, but right now it is appears to be random.

This is not particularly a bug, but just something I noted and it might be worth discussing the behavior.

When sorting descending, the years sort in descending order (as expected). The semesters could be argued that they are not in descending order, i.e. Fall, Summer, Spring.

The same occurs when sorting ascending. The semesters do not sort.

As I said, it is not particularly a bug, more of a behavior. Should the semesters also sort when sorting or should they remain in the same order, because we are really just sorting years? If so, is the latter clear?

On the class query page such as this the class sections are listed separated by professors. However, I am unable to tell if a professor's class/GPA is relevant to me (example) because I don't know when he last taught the class without clicking on each one individually. This doesn't sound like a huge ordeal on paper, but I find many classes have listings with professors that have moved departments or left.

Since I like to view class data when choosing my next professor, I would love to have the 'Year' column in the class query page where, next to the professor's name, there is their most recent semester of teaching (that class).

No longer in charge of course critique @ gatech. Need to transfer ownership of this github repo to the new owner.

When I go here: http://critique.gatech.edu/course.php?id=BIOL2344

I get this:
McDonald, John F Very Large (50 Students or More) 2.77 20 40 30 6 1 4

But when I go here (or click on his name): http://critique.gatech.edu/prof.php?id=MCDONALDJOHNF#BIOL2344

I get this:
3.77 84 7 6 1 0

When clicking the course link from the professor page, the destination link sometimes is incorrect that there is no results; I clicked on a link from the professor page, there should be at least one result.

Reproduce:

1. Go to here
2. Click on "CS 8999"
3. View lack of data

It may be due to the class having no data, but the result is confusing regardless.

The 'Size' and 'Year' columns sort as text. It seems more logical for them to sort based on number of students and time respectively.

When on the course result page (i.e. course.php), the first and last name of all the professors are not separated by a space.

For example, on this page Conte,Thomas Martin should be Conte, Thomas Martin.

Appears to be a database issue rather than a presentation issue.

Example:
http://critique.gatech.edu/prof.php?id=KUBANEKJULIAM

The app is already filtering out the 0 GPAs, but the grad GPAs of 4.0 are skewing her overall average.

Not sure on how to remedy this.

Currently, while we currently provide what tools are required to run CC, it's unclear how to set up the environment.

The id param in course.php and prof.php should be escaped before use.
LIKE in PDO prepared statement with '%' as :id value ends up spewing all rows.

Steps to reproduce -
Visit - http://critique.gatech.edu/prof.php?id=% or http://critique.gatech.edu/course.php?id=% (your browser might freeze).

As the JDBC ElasticSearch (E.S.) river is causing lots of pain w/our OIT setup, I'm writing a new driver to push MySQL data to E.S. This differs from the JDBC E.S. river which pulls the data. If I do this right the frontend could also pull from ElasticSearch using a REST API and/or have a decent public API.

As the old driver didn't like complex JSON I'm thinking of changing the 'schema' to be:

Courses
"_index" = "course"
"_type" = "undergrad" (graduate)
"_id" = "courseID"

example documentURL = http://localhost:9200/course/MATH1502

example document:
{ "department" : "Math",
"number" : 1502,
"name" : "Calculus 2",
"description" : "This class will go over......etc",
"gpa" : 4.0,
"professors" : { "Morley, Tom" : { "GPA" : 4.0, "profid" : "MORLEYTOM" },
"Last, First" : { "GPA" : 2.1, "profid" : "LASTFIRST" },
}
}

Professor
"_index" = "professor"
"_type" = ...not sure what to put here yet....
"_id" = "profID"

example documentURL = http://localhost:9200/proffessor/BLOUGHDOUGLASM

example document:
{
"name" : "Douglas M, Blough",
"undergrad" : {
"gpa" : 3.8,
"courses" : {
"ECE 3020" : { "gpa" : 4.0, "courseid" : "ECE3020" } ,
"ECE 2030" : { "gpa" : 2.0, "courseid" : "ECE2030" }
}
},
"graduate" : {
"gpa" : 3.2,
"courses" : {
"ECE 4445" : { "gpa" : 4.0}
}
}
}

Is there a way to query the database through HTTP Request? I want to get the GPA info of professors (given a professor name) for a side project I'm working on.

It is possible to remove all classes from the professor page via the Courses select.

It should not be possible.

Currently if you enter in a non-existent course/professor into the URL, the pages that show up are the usual result pages though with "no data available in the table".

It would be better to show a simpler "course/professor does not exist" message and perhaps suggest courses/professors that are somehow-related to their input.

Elastic Search is computing wrong averages. Minor issue as the elastic search grade data is not being used in any aspect.
Can be seen by comparing search.php JSON w/course.php and prof.php values

If an exact match is found for my search, don't make me click it under the results page. Just send me straight to it.

Its not computing the 'average'

Bootstrap's CSS shouldn't have anything non-Bootstrap in it. Removing it and putting it in a separate file would aid with updating Bootstrap when it needs updating.

Everything below .affix:

.dataTables_paginate > ul > li.active > a { background-color: #003049 !important; }
.dataTables_paginate > ul > li:not(.disabled) > a:hover{ background-color: #B18E5F !important; color: white !important;}
.avg { text-decoration: overline; }
.CoursesDisabled , .TermsDisabled, .ProfessorsDisabled { display: none; }
.beta-ribbon { position: fixed; pointer-events: none; top: 0px; left: 0px; height: 75px; z-index: 1; }

Add a search box where the home icon is

When an invalid professor is queried, the Terms select only contains a checkbox with no supporting text.

The selects usually show "No data available in table" when an invalid course/professor is queried.

The terms select should display the same (assuming #11 is not implemented).

When we have the information, we should update the production database for Course Critique to include the Summer and Fall semesters.

When you add multiple classes to view on a professor's page via Courses select, the "average marks" summary table at the beginning does not update to reflect the new classes that were added/removed.

Initially, I think it is the average marks for x professor's instances where x has taught y class. However, since it doesn't update it leads me, the user, to believe it is x's average marks for all x's classes (which isn't right and makes no sense).

Solution:
"Average Marks" should be updated when more than one class (e.g. CS 2200 and ECE 8903) is present and clearly show that for this row in the table is for CS 2200 and the next one is for ECE 8903.