sonowz / graduate-adventure Goto Github PK

View Code? Open in Web Editor NEW

5.0 5.0 3.0 727 KB

Graduation Simulator for SNUCSE students

License: MIT License

Python 83.05% JavaScript 3.02% Vue 13.92%

django-rest-framework vuejs web web-services

graduate-adventure's People

Contributors

Stargazers

Watchers

Forkers

skystar-p jhuni0123 mkroughdiamond

graduate-adventure's Issues

Implement credit crawler from MySNU

Refactor from former version
Add tests

Webpage design renewal

For better UX, frontend page should be redesigned.
We can either:

One can design and others improve
Find new designer

Accurate tree evaluation

There are some issues with tree evaluation.

replaceable courses
manual course replacement (e.g. 선형대수학)

Also, thorough testing is required to make sure everything works correctly.

add unit tests #67

Production build

Frontend production build should be implemented.
First problem is to make frontend server proxy backend.
I think we should use express.js, but there could be alternatives.

Webpage layout design

Login page
Current status page
Adding rule page

Backend API specification : Login Page

Request List

mySNU Login
File Login

mySNU Login

Request

POST /api/login/mysnu/

JSON parameter :

Parameter	Description	Example
user_id	mySNU ID	dnsdhrj
password	mySNU password	1234
major_info	Use major info?	True

Optional parameter when major_info is True :

{
  "majors": [
    {
      "type": "주전공",
      "name": "컴퓨터공학전공",
    },
    {
      ...
    }
  ]
}

Response

On login success :

{
  "success": true
}

On login fail :

{
  "success": false,
  "message": "ex)로그인에 실패했습니다."
}

File Login

Request

POST /api/login/file/

File parameter : a file containing course data.

JSON parameter :

{
  "majors": [
    {
      "type": "주전공",
      "name": "컴퓨터공학전공",
    },
    {
      ...
    }
  ]
}

Response

On parsing success :

{
  "success": true
}

On parsing fail :

{
  "success": false,
  "message": "ex)잘못된 파일입니다."
}

Of course, when we use js, we should use use strict. But when we put it in our index.js file, Compile error(cannot find 'Elm') occurs.
So, I commented this line. If I find other way that has no error with use strict, I'll rewrite it.

Database setting

Django DB setting

This will be handled after feature implementation is done and before deployment.

Decide which DBMS to use for deployment
Separate testing and deploy database

Firefox login page rendering is weird

like the screenshot above, DOM rendering appears something wrong.

Chrome is not showing this problem.

Table zooming problem

I changed MajorForm design in login page, but there are some problems. I set its components' sizes in fixed values(like "px", etc.), and they caused zooming problem. (they broke table's shape while zooming.) I had tried to set components' sizes in '%' values, but zooming problem still happened because of padding.

fix MajorForm table zooming problem

Apply equal/replaceable courses

Apply equal or replaceable courses on course database

Acquire relationship information
Apply to database
Apply to rule

Frontend page shows blank screen in Windows

HTTP GET results from Windows environment

http://localhost:8080

<!DOCTYPE html>
<html lang="ko-kr">
  <head>
    <meta charset="utf-8"/>
    <meta name="viewport" content="width=device-width, initial-scale=1"/>
    <title>Graduation Simulator</title>
    <meta name="description" content="Graduation Simulator"/>
  </head>
  <body>
    <div id="main"></div>
  <script type="text/javascript" src="/static\js\main.js"></script></body>
</html>

http://localhost:8080/static/js/main.js

Cannot GET /static/js/main.js

New Main Page

There are prerequisites to be done before making main page.

1. Decide backend tree model
2. Decide page layout (design)
3. Make API specification again

New Project Design Plan

발단

현재 프론트엔드 디자인은 졸업모험 v1의 디자인을 거의 그대로 따왔으며 거기에 시뮬레이션 기능을 덧붙여 추가한 것 뿐이다. 애초에 디자인이 아주 잘 짜여져 있다고는 생각하지 않았지만 프로젝트 구성원 특성상 디자인을 전담할 사람이 없는 관계로 초기 디자인을 따라서 진행중이다.

즉 요구에 맞는 새로운 디자인이 필요한 것이 사실이다. #82

기존 프로그램 분석

먼저 기존에 있던 졸업 시뮬레이션들의 디자인을 분석해보도록 한다.

졸업모험 v1

마이스누 로그인을 통해 수강정보를 받아온다.
컴퓨터공학 주전공만을 지원한다.
상단에는 다양한 진척도가 나열되어있고 전체학점이 게이지로 표현되어있다.
전공, 교양 두 부분으로 나뉘어져 있으며 그 안에서 각 학기별로 나뉘어져 있다.
각 학기에는 수강한 강의 / 미이수한 규정을 작은 chip들로 나타내고 있다.
- 수강한 강의는 수강한 학기에 나타난다.
- 미이수한 규정은 권장학기에 나타난다.
미이수한 규정 위에 마우스를 올려놓으면 툹팁으로 이수하기위해 수강할 수 있는 과목들의 목록이 나타난다.
이수/미이수, 필수/선택은 색을 이용해 구분한다.
수많은 부분이 하드코딩 되어있고 여전히 틀리는 부분이 존재한다.
모바일은 특별히 지원하지는 않는다.

적용

단일 주전공만을 지원하기 때문에 복전, 부전을 그대로 적용할 수 없다 (복/부전은 교양규정이 없음)
이미 수강한 과목이 꼭 학기순으로 정렬되어있어야 할 필요에 대한 의문.
한 페이지 안에서 정리해주기 때문에 한 눈에 알아보기 좋았다.
하지만 만약 시뮬레이션 기능을 한 페이지 안에서만 구현하면 보기 좋을까?

MySNU 졸업시뮬레이션

거의 모든 전공에 대해 지원하는 듯 보인다.
규정들이 리스트형태로 주어져서 각각에 대해 이수여부를 체크한다.
흔한 규정 중 과학과목에 대한 규정이 까다로운데 이를 체크하기위해 꽤나 하드코딩이 되어있을것이라 예상한다.
한 과목이 두개 이상의 규정에 영향을 끼치는 문제를 해결하지 못했을것이라고 예상하고 있다.
따라서 이를 통과한 사람이 졸업 가능한지는 모르겠지만 적어도 졸업 가능한 사람은 이를 통과할 것 같다.
미이수 규정을 이수하기 위해 들어야 하는 과목을 리스팅 하는 기능이 있다.
결과가 표 형태로 나타나고 각각의 행이 규정을 의미하는데 이수하지 못한 규정이 많으면 각 규정을 알아보기 힘들다.
규정을 단순히 병렬로 나타내었기 때문에 복잡한 규정의 경우 유저가 알아보기 힘들다.
표 형태이고 단순한 수치로만 나와있어 다양한 규정에 대한 표현을 함축하지 못하였다.

적용

규정을 일련의 리스트로 나타내고 있다. 물론 리스트이기 때문에 더 복잡해진 부분도 있지만 지금의 규정디자인처럼 완전한 하나의 트리로 일반화를 시킬 필요가 없을지도 모른다는 사실을 인지했으면 한다.

추구하는 기능

타과, 복수전공, 부전공 지원
이수상태 점검 (메인페이지)
시뮬레이션

1. 타과, 복수전공, 부전공 지원

컴공 뿐만 아니라 다른 모든 과를 지원하기 위해선 각각의 규정을 소스코드의 수정 없이 만들 수 있어야 한다. 졸업규정은 1년마다 한번에 새로 나오기 때문에 빠르게 구성할 수 있을수록 좋다.

복/부전공은 주전공 규정과 별개로 하나의 규정으로 구성된다는 점은 주전공과 같지만 교양과 관련된 규정이 없다는 큰 차이점이 있다.

2. 이수상태 점검 (메인페이지)

기본적이지만 핵심적인 기능이다. 정확도도 중요하지만 이를 시각적으로 잘 표현하는 것도 중요하다.

규정의 시각적 구성은 현재 두가지 방법이 알려져있다.

학기단위로 '그 학기에 들은 과목 / 그 학기에 이수해야 하는 규정' 으로 표현 (ex. 졸업시뮬 v1)
규정의 영역별로 표현 (ex. 마이스누, #97)

3. 시뮬레이션

지금까지 존재하던 기능은 현재 상태를 점검하는 것 뿐이었다. 이를 보완하던 기능이 미이수 규정을 이수하기 위해 들어야 하는 과목을 보여주는 것이다. 이에 그치지 않고 학기 단위로 설계하여 완벽한 졸업을 시뮬레이션 할 수 있도록 기능을 제공할 수 있다.

현재 전공 상태를 기준으로 미래에 수강할 과목을 설계할 수도 있지만 복전/부전 여부를 결정하기위해 가상의 전공정보를 기준으로 시뮬레이션을 하고싶을 수 있다. 이를 위해서는 '교과목 중복인정'등의 전공 사이의 상호작용에 대하여 완전하게 알고 있어야 한다.

디자인 논의

현재 로그인 방식은 '마이스누 로그인' 과 '파일 로그인' 두가지로 나뉜다.
'졸업시뮬 서비스'를 이용하기 위해 필요한 정보는 두가지가 있고 이를 얻는 방법의 차이가 로그인방식의 차이이다.
정보를 얻는 방법의 차이는 다음과 같다.

내가 수강한 과목들
- 마이스누: 크롤링하여 가져온다.
- 파일: 수강 리스트 파일을 제출한다.
나의 전공
- 마이스누: 크롤링하거나 직접 입력한다.
- 파일: 직접 입력한다.

이 중 '1. 내가 수강한 과목들'의 수정이 필요할 시에는 서비스 이용 중 '시뮬레이션' 기능을 통해 이루어진다.

'2. 나의 전공'은 현재는 로그인시에만 입력을 한다. 하지만 전공 정보 또한 서비스 이용 중 수정 가능해야 더욱 고차원적인 시뮬레이션이 가능할 것이다. 이러한 정보 수정을 시뮬레이션에만 넣을것인지 기본 전공정보 또한 수정할 수 있을지 고민해야 한다.

메인

메인 페이지에서의 서비스의 목적은

현재까지 얼마나 졸업규정을 이수했는지
그리고 졸업을 위해서 무엇을 더 이수해야하는지

를 알려주는 것이다.

그리고 보여줘야 할 정보의 계층도는

전체 진척도
- 각 전공별 정보
  - 각 규정의 이수/미이수 정보

로 요약할 수 있다.

'각 전공별 정보'에 해당하는 것은 각각의 전공, 복수전공, 부전공인데 현재는 이를 탭으로 구분하여 전공당 한 페이지에 나타내고 있다.

하지만 이에는 문제점이 있다.

주전공/복수전공/부전공의 정보의 양이 크게 차이가 난다.
- 주전공은 전공규정과 교양 규정이 따로 있으나 복수전공과 부전공은 전공규정밖에 없다.
- 게다가 전공규정도 학점수가 주전공에 비해 작기 때문에 정보의 양이 크게 줄어든다.
각 전공에 포함되지 않는 정보를 또 다른 곳에 표현해야 한다.
- 예를 들면 '내가 전공하고 있지 않은 전공의 전선'(타과전선)과 '일선'과목 등이 있다.

따라서 다른 페이지로 구분하지 않고 하나의 페이지 안에서 구분하는 것이 좋을 수 있다.

또한 시뮬레이션 기능을 메인페이지에서 구현하는 것도 좋지 않다고 생각한다. 메인 페이지에서 구현할 경우 시뮬레이션 진행중에는 현재 상태를 다시 점검하기가 어려워지기 때문이다.
따라서 UI는 유지시키더라도 다른 페이지에서 구현하는 것이 좋다고 생각한다.

시뮬레이션

졸업 시뮬레이션에서 시뮬레이션의 역할은 현재 수강정보를 바탕으로 미래에 수강할 과목들을 미리 결정하는 것에 도움을 주는 것이다. 자연스러운 시뮬레이션이 되려면 실제로 유저가 졸업을 준비하는 프로세스를 따라가면 좋을 것이다.

학기 단위로 들을 강의를 추가한다.
- 학기별(1, 2, S, W)로 수강 가능한 과목들은 유의미하게 차이가 있다. 이를 눈에 띄게 구분해야 한다.
시뮬레이션 중인 학기는 기존 엔트리보다 위에 위치하게
- 시뮬레이션 중이므로 시뮬레이션에 해당하는 것을 잘 보이는 곳에 배치
아래에는 수강한 과목이 추가된 메인 페이지와 거의 동일하게 구성

논의 할 점으로는

'나의 전공'의 수정을 시뮬레이션에 포함시킬 것인가
- 기본정보를 수정하는 방식으로 할 수도 있다.
추가할 수 있는 과목의 형태
- 수강편람이 나온 직후에 다음학기를 시뮬레이션 하는 경우에는 실존하는 강의만으로도 부족함이 없다.
- n학기 후를 계획할때 같은 종류의 과거 학기에 존재하는 과목으로 하면 가능하다.
- 혹시 이외의 방법이 있을까?
과목의 추가 방식
- 검색을 이용한 추가
- 추천과목을 통한 추가

모델링

위 분석을 토대로 프론트엔드를 모델링해보자.

틀

페이지의 종류 <네비 바>
옵션들? <드로어>

메인페이지

전공들 전체를 아우르는 정보 <최상단 단일 엔트리>
각각의 전공에 대한 정보 <엔트리>
- 이 전공에대한 요약 <엔트리 상단>
- 전공/교양 규정 <엔트리 내부 분할>
  - 이수한 규정 <분할된 엔트리 내부 리스팅>
    - 이수한 과목 <리스트엔트리 내부 또는 클릭후 팝업>
  - 이수하지 못한 규정 <분할된 엔트리 내부 리스팅>
    - 이수하기 위한 과목<클릭 후 세부정보 팝업>
    - 이수하기 좋은 추천학기 <클릭 후 세부정보 팝업 또는 특별한 효과>
전공/교양에 포함되지 않는 것들 <별개의 엔트리>
- 타과전선(전선인정에 대한 처리?)

시뮬레이션

시뮬레이션 중인 학기들 <최상단>
- 각 학기의 정보 <리스트 엔트리>
  - 학기, 학점 수 등의 정보
  - 과목들
메인페이지 형식의 정보

Login page

Implementing login page from #5

Implementation
Add tests

New Login Page

Page design is not yet decided.
However, since login page will have minimal design, we can start making template from now.

Make sure to include unit tests (Karma seems like standard.)

CI Testing Environments

README.md says

Recommended Requirements

Python ≥ 3.5
node ≥ 6.x

But .travis.yml says

python:
  - "3.5"
  - "2.7"
  - "pypy"

Since pythons are used only in server-side, I think we don't have to test python 2.7.
What's your opinions?

CSS stylesheets should be made out of Elm

We have to manage HTML styles in .css file.
Otherwise elm code readability will become bad.

TODOs:

Refactor Elm code
Move styles into CSS

Decide elm code file structure

There are 2 major file structures suggested for elm codes. Reference

Concerns-focused structure

Create directories by functions (Model, Msg, Update, View),
Then files by modules. (TextBox, Combobox, Graph..)

Modules-focused structure

Create directories by modules,
Then files by functions.

This is a minor issue, but deciding the structure affects code maintenance, and elegance.

Rule schema

Design

Tree-based rule model

Implementation

Implementing schema using YAML
Sample rule data for CSE major
Add tests

Frontend environment setting

Backend API app should be refactored

I think every backend API should be in a app. (ex - api)
API should be more RESTful.
ex) login response returning redirect('/main/') is not proper.
I think login api should return whether it success or not (or token if we use).
And other request of main data return main data.

Service server & HTTPS

Servicing server should be determined and be ready to deploy.
uriel will be the server, but sodrak can be considered later, which is more stable.

Get permission of uriel server
Deploy graduate-adventure
DNS
HTTPS

Backend API Specification : Main Page

Request List

Fetch Main Data
Course Search

Fetch Main Data

Request

GET /api/main/

Response

JSON containing proper data.
Refer to sample.zip in below comment.
Request without login / with expired session will result in 400 Bad Request.

Course Search

This API is for search modal.

Request

POST /api/main/search/

URL-encoded parameter : (may change to JSON)

Parameter	Description	Example
node_title	Name of treenode you want to search for.	생물학 및 실험
title	Search option : course title	실험
code	Search option : code	034.033
credit	Search option : credit	1
category	Search option : category	교양
area	Search option : area	학문의 기초
subarea	Search option : subarea	과학적 사고와 실험
college	Search option : college	자연과학대학
dept	Search option : department	생명과학부

Response

List of JSON as a search result.
Parameters are same as search options above.

{
    "data": [
        {
            "title": "컴퓨터의 개념 및 실습",
            "other_tags": "..."
        },
        {
            "title": "컴퓨터과학이 여는 세계",
            "other_tags": "..."
        }
    ]
}

Adding Rule page

Rule Page

Currently, rule is just using pre-constructed YAML file.

But this preconstrucing rule file needs too much efforts, and is error-prone.

Furthermore, we cannot cover all of that rules, so we should implement Rule Page.

This issue references #5 .

Rule Page should contains:

Select specific rule file and view by tree
Expanding, collapsing tree interface
Generating tree (this should be the most tough work)
Tester, and vote (for preventing trolling)

Maybe this can be done in very end of this project.

Make template of Rule Page
Implementing Rule file selector and tree viewer
Rule generator interface
Voting system

Please request any of adding and deleting above list, and even opinion of rejecting this issue.

Improve CI

Improving CI configurations

Add Elm tests
Apply mocha-loader for webpack
Improve build performance

Building course database

Implement course model
Refactor course crawler from former version
Add tests

Reuse Tree object

Un-evaluated Tree objects can be reused among users with same major & 학번.
I think we can achieve this by making evaluated tree as duplicated.
This can be considered when we have performance issues.

Replace course infos out of expectation

I have thought that replace info can resolve the case of "논리설계실험-하드웨어시스템설계" and "물리학1-물리의 기본1" but there is an exception.

Replacement infos are represented by 'code1 → code2'

So we can think that when we should take course of code1, it can replaced by taking course of code2. This is compatible for case of 논리설계실험→하드웨어시스템설계.

But in case of 물리의 기본1, its replacement info is 물리의 기본1→물리학1.
So we can't design rule of science except 물리의 기본1.

Fortunately, case of 물리의 기본1 can resolved by fix rules like "물리1 : take (물리학1 or 물리의 기본1) and 물리학 실험1" and it dose not deviate much from real rule.

If more exception cases of out of our expectation found, we may have to think more.

Rule schema (tree) #4
Course database #7

Rule schema tests are implemented, but @skystar-p said edge case testing is needed.

Frontend TODOs

I tested current master branch, and found some issues.
TODOs from PR #54 would be handled by @Jhuni0123 .

로그인 button does not have http request (which did before refactoring, so it will be minor problem)
Redirect / to /login (if not logined?)
Release build config
MajorName select form #54
Http request (maybe 로그인 button?) #54
More unittests #54

sonowz / graduate-adventure Goto Github PK

graduate-adventure's People

Contributors

Stargazers

Watchers

Forkers

graduate-adventure's Issues

Implement credit crawler from MySNU

Webpage layout design

Request List

mySNU Login

Request

Response

File Login

Request

Response

Django DB setting

Apply equal or replaceable courses on course database

HTTP GET results from Windows environment

발단

기존 프로그램 분석

졸업모험 v1

MySNU 졸업시뮬레이션

추구하는 기능

디자인 논의

로그인

메인

시뮬레이션

모델링

틀

메인페이지

시뮬레이션

Implementing login page from #5

Concerns-focused structure

Modules-focused structure

Design

Implementation

Request List

Fetch Main Data

Request

Response

Course Search

Request

Response

Rule Page

Improving CI configurations

Building course database

Recommend Projects

Recommend Topics

Recommend Org