-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
probs page 실구현 문제 #17
Comments
_2. HTML? 다른 언어도 있지 않을까요? 저번에 이거에 관한 이야기(마크다운?)를 봤던거같긴 한데 |
페이지를 따로 분할할것인가 db를 가져와서 뿌려줄것인가에 대한 논의였고 html을 쓸지 아닐지에 대한 얘기는 아니었음, 실제 문제 디스플레이시는 마크다운 쓰는게 맞는 거라 생각함. |
_2. HTML 페이지를 왜 문제별로 만들어 ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ 당연히 DB에 다 넣어야지 |
_5. 분할. 부분점수는 장난이었음 _1. 내부적으로는 번호로 처리하고 디스플레이나 URL은 그렇게 하는게 좋아보임. (어차피 MongoDB는 DB에 삽입된 모든 데이터에 대해 고유한 _id를 자동으로 부여함) |
_1. 문제 코드를 넣는 방식으로, tutorial57 / tutorial_maxflow / IOI11_garden / KOI14_bus / design_tree / puzzle_nqueen15 식의 네이밍으로. |
_4. |
_1. 각 문제의 번호를 매기는 방법이 여러가지가 있는데, 번호 대신 문제 코드를 넣는 것이 제일 바람직해보임. (사례 : oj.uz 'IOI11_garden', 'tutorial4' 등)
-> 장점 : 직관적으로 문제 검색 가능, 서치 엔진과 궁합이 잘됨, legacy 호환성 유지 가능 (기존 코슷 문제 번호로 들어오면 redirect)
-> 단점 : 손이 많이 간다. 길다 (이 문제는 legacy code를 여전히 부여하는 시스템으로 가면 문제가 안될듯)
어차피 문제 작업은 다 손이 많이 갈듯하니 최선이다 생각함.
-> 추가 단점 : 코드를 매기는 규칙이 존재하는가? 규칙이 없으면 코드가 이리저리 꼬여서 일관성을 잃을 가능성이 존재함. 이러한 규칙을 확실히 만들 수 있는가? 없으면 그냥 번호순으로 가는 게 나을 수도 있다.
->>> 번호순으로 간다면, 정말 현행 시스템을 유지할 것인가? 지속가능한가? 다른 번호시스템을 고려해야 할 수도 있다. 하지만, 그 경우 legacy support 문제는?
_2. 문제를 어디서 띄우는가?
-> html 페이지를 각 문제별로 만든다
-> 문제를 그때그때 db에서 받아서 처리한다
_3. 문제 분류 시스템
http://oj.uz/problems
https://www.acmicpc.net/problemset
이러한 식의 pageview 역시 지원해야 함
_4. 추가적인 기능?
_5. 부분 점수 기능? Small / Large 분할?
The text was updated successfully, but these errors were encountered: