......!

Polygon의 첫걸음은 General Info를 적는 것에서 시작한다고 해고 과언이 아닙니다. 실제로 General Info(일반적인 정보)가 의미하는 것처럼, 문제의 기본 골격을 설정해놓는 것이 General Info의 역할입니다. 이는 다음 포스팅 때 설명한 Statement와 겹치는 감이 없잖아 있지만, 분명한 차이점이 존재합니다.

• General Info의 모습입니다. 여기에는 문제의 프로그래밍적인 부분보단, 문제 자체를 설정하는 부분이라 보시면 편할 것 같습니다. 하나하나씩 뜯어보도록 하겠습니다.

• Input file: 입력 방식을 결정합니다. 입력 데이터는 물론 파일로 존재합니다만, 이를 파일을 통해서 입력할지, 아니는 표준 입출력 방식을 사용할 지 결정합니다. 물론 그 이외의 선택지(ex. Output-only)도 있겠지만 Polygon에서 지원하는지는 잘 모르겠습니다.
  
  하지만 왠만하면 stdin(표준 입력 방식)을 사용하기를 권장하겠습니다. 파일 입출력도 물론 여러 대회에서 많이 사용하지만, Polygon 시스템 상 표준 입출력이 훨씬 더 안정된 상태이기 때문에 본 시리즈에서는 표준 입출력만을 사용하겠습니다.

• Output file: 출력 방식을 결정합니다. 마찬가지로, stdout 사용을 추천드립니다.

• Time limit: 시간 제한을 설정합니다. 250ms (0.25초) 에서 15000ms (15초)까지 가능합니다. 보통 1000ms 내지는 2000ms지만 문제에 따라 다양한 Time Limit이 가능합니다.

• Memory limit: 메모리 제한을 설정합니다. 4MB부터 1024MB까지 가능합니다. Codeforces Round는 보통 256MB를 사용하나, 특수한 풀이를 요구하는 문제의 경우는 Memory limit를 상당히 낮게 잡는 경우도 많습니다.

• Interactive: 문제가 Interactive 문제인지 설정할 수 있습니다. Interactive 문제란 특정한 함수를 이용 및 구현하여 주어진 과제를 수행하는 문제입니다. 대부분의 경우 ‘어떠한 함수를 구현하라’고 주어지고 일반적으로 main 함수를 제출하는 것이 아닌, 그 함수만 제출하게 됩니다. 말로 설명하기 힘드네요. 대충 이런 문제들이라 보면 되겠습니다. 아무튼 Codeforces Round에서는 제공하지 않습니다. 그래도 Polygon 시스템 상으로 만들 수는 있습니다. 다만 이를 만드는 과정을 본 시리즈에서 언급할 지는 모르겠습니다. 나중에 기회가 되면 리뷰하는 걸로…... 그래도 Codeforces에 다음과 같은 정보는 나와 있습니다. 그래도 이해가 안 되시면 한 번 topcoder에서 문제를 풀어보세요.

• Well-formed: test(테스트 케이스)가 특정 규격을 잘 맞추었는지 나타냅니다. 이 항목을 체크된 상태로 test를 생성시 이 규격에 맞게 일부 whitespace character 및 control character 등이 추가 및 제거됩니다. 이 경우 test를 저장할 때 ‘Added test has been reformatted because of the problem well-formed policy’ 라는 구문이 추가적으로 나타납니다. 규격을 해석하자면 다음과 같습니다.

• 각 줄이 EOLN(End of Line)으로 끝나야 합니다. 즉, 각 줄에 맨 마지막에는 ‘\n’ (enter)문자가 와야 합니다. 예를 들면, 어떤 문제의 input이 한 줄에 정수 하나로 끝일 때, test를 만들 때 정수 하나를 집어넣고 반드시 ‘\n’가 와야 합니다. ‘\n’을 기준으로 작동하는 입력 함수들이 많기 때문입니다(ex. C의 scanf) ‘\n’는 기본적으로 Windows/Mac에서는 CR LF의 두개의 char로, *nix 환경에서는 LF로 해석되는 문자이지만, Polygon은 이를 알아서 내부적으로 변환해줍니다.
  만일 줄의 끝에 EOLN이 없을 경우, 자동으로 ‘\n’이 추가됩니다.
  
  
• character code 값이 32보다 작은 문자가 입력되지 않아야 합니다. ASCII 코드를 보면, 32 미만의 값을 가진 문자들은 대체로 control key이기 때문에, 일반적으로 입력받을 일이 전혀 없는 문자입니다. 단 여기에서 ‘\n’(CR : 0x0D / LF : 0x0A)는 제외됩니다.
  만일 그러한 문자들이 있을 경우, 전부 SPACE(0x20)으로 교체됩니다.
  
  
• 각 줄이 SPACE로 시작하거나 끝나면 안됩니다. 이러한 경우가 있을 경우 해당하는 SPACE 문자는 제거됩니다.
  
  
• 2개 이상의 연속된 SPACE가 없어야 합니다. 있을 경우, 단일 SPACE 문자로 대체됩니다.
  
  
• 빈 줄이 없어야 합니다. 즉 ‘\n’만 있는 줄이 없어야 합니다. ‘\n’만 있는 줄이 있는 경우, 해당 줄은 삭제됩니다.
  
  
• 파일이 비어 있으면 안 됩니다.

이 Well-formed의 여부는 옆에 있는 ‘Well-formed: true/false’를 통해 알 수 있습니다. 여기까지를 저장하고자 하시면 화면에서 바로 보이는 Save를 누르면 됩니다.

이러면 저 Advanced의 용도가 궁금해지죠. 복잡할 것 같지만, 정작 Advanced에 들어가면 매우 직관적인 메뉴가 보입니다.

각각을 설명하면 다음과 같습니다.

• Problem Name: 문제 이름입니다. Rename을 통해서 문제 이름을 재설정할 수 있습니다. Rename은 Commit Changes와 무관하게, 누르는 순간 적용되며, View Problems에서 Discard를 한다고 해서 원래 이름으로 돌아가지도 않습니다.

• Clone problem to: 문제를 해당 이름을 가진 상태로 복제하는 기능입니다. 주의할 점은 Clone은 가장 최신의 revision을 복제하는 것이기 때문에, 현 상태에서 Commit Changes를 통해 저장되지 않은 변경사항은 복제되지 않습니다.

• Delete Problem: 문제를 삭제하는 것입니다. 다만 문제를 삭제해도 내부의 데이터는 삭제되지 않고 서버에 남아 있게 됩니다. 애초에, 삭제된 문제도 View Problem에서 스크롤을 밑으로 내리면 보이는 Show Deleted에서 접근 가능하고, 심지어 Commit Changes까지 가능합니다. 다만 이 경우 문제의 이름이 해시값 마냥 이상하게 바뀌며, 이 괴상한 이름은 수정이 불가능합니다. 문제를 복원하지 않는 한 말이죠. 삭제된 문제는 문제를 선택할 때 보이는 Restore나, 문제에 들어가서 General Info-Restore를 통해서 복원될 수 있습니다.

이제 Advanced를 나오면, 밑에 조그맣게 Tags와 Add tag가 보입니다. Tag는 보통 다음과 같은 2가지 이유로 사용합니다.

1. 정해의 접근법을 나타내기 위해서 (ex. math, data structure, greedy, sqrt-decomposition)
2. 문제 자체를 분류하기 위해서. 두 가지 양상이 있습니다. 첫번째로는 문제가 어떤 형태의 문제인지 나타내기 위해서 쓰거나(ex. strings), 아니면 이 문제가 어떤 대회의 문제인지 나타낼 때 쓰기도 합니다(ex. ioi2011, looksery-cup)

Tags의 진가는 View Problems에서 필터링해서 볼 때 나타납니다(라고 개발자님께서 말씀하십니다). 의미 있는 tag를 문제에, 못해도 하나라도, 예를 들면 implementation이라도 추가하시길 바랍니다.

tags에서 밑을 보면 Statement description과 Problem tutorial이 있습니다. 여기에는 각각 문제 설명과 문제 해설을 text로 적으시면 됩니다. 문제 설명은 누가 봐도 이 문제가 무얼 요구하는지 알 수 있게 적어놓아야 하고, 문제 해설은 Codeforces Editorial처럼 간략간략한 핵심 아이디어를 말하면서 풀이를 전개해나가시면 됩니다. 저장은 Problem tutorial 밑의 Save를 누르시면 됩니다. 참고로 Draft는 일종의 임시 저장 기능이라고 생각하시면 됩니다.

어째 간단히 설명하는 감이 있지만, 이 부분은 다음에 설명할 Statements랑 겹치기 때문입니다.

여기까지가 General Info였습니다. 다음은 Statement입니다.

Polygon 계정을 만들고 Login하면 View Problem 창에 있을 겁니다. 물론 방금 전에 계정을 만드셨으니 등록된 문제는 없겠지요. 그때는 간단히 New Problem 버튼을 누르면 됩니다.

이 때 문제의 이름을 설정하게 됩니다. 문제의 이름은 간단한 명칭으로 통용될 정도여야 합니다. 일반적인 문제 제목이 아니라 간단하게 'brackets' 'bang' 'flip' 이런 식으로 말입니다. 문제 제목에는 알파벳 소문자와 대시(-)만을 사용할 수 있습니다.

참고로, 문제 이름 가지고 깊은 고민하지 않으셔도 됩니다. 왜냐하면 문제 제목은 언제든지 바꿀 수 있기 때문입니다. 아무튼 문제 자체를 만드는데 성공하셨다면 Edit session에 왠지 누르고 싶어지는 Start가 나타나며, 이를 누를 경우 문제 제작이 시작됩니다.

그리고 드러서는 순간......뭔가 할 것이 많아보이는 창이 하나 뜹니다. 바로 문제의 Gerenal Info 창입니다. 

이 창의 역할에 대해서는 다음 포스팅에서 진행하도록 하겠습니다. 지금 주목할 것은 스크롤을 조금만 내리면 나오는 ‘Commit Changes’라는 버튼입니다.

Commit Changes는 지금까지의 변화를 Polygon 서버에 저장하는 기능입니다. 물론 이를 누르지 않고 그냥 창에서 나가도 기존의 변화 상태는 저장됩니다. 그러나 Commit Changes는 이 상태를 하나의 revision으로 저장하여 보존해놓는데 의미가 있습니다. Commit Changes를 누르면 다음과 같은 창이 나타납니다.

각 항목의 의미를 설명하자면 다음과 같습니다.

• Problem: 문제 이름입니다.

• Changes: 변화한 파일 및 디렉토리의 개수입니다. 문제를 만들기만 하고 적은 게 없는데 왜 Changes가 21이나 되냐고요? 문제를 만드는게 근간이 되는 파일이나 디렉토리 등이 기본적으로 생성되었기 때문입니다.

• Commit message: 무엇이 변했는지 적는 창입니다. 버그 수정, 개선점 등의 업데이트 내용을 적으면 되겠습니다.

• Warnings: 말 그대로 경고입니다. 아직 문제가 ‘제대로’ 만들어지지 않았다는 것을 의미합니다. 지금은 뭐 한게 없으니 경고가 우후죽순으로 생겨나지만, 하나하나 사라지게 될 겁니다.

• Minor changes: 기본적으로 Commit을 할 경우, 이 문제에 작업하는 모든 사람에게 Commit Changes를 통해 이메일이 발송됩니다. 다만 굳이 이메일을 보낼 필요까지 없는, 약간의 사소한 업데이트 및 개선이라면 ‘Don’t send email notification(이메일 공지를 보내지 않습니다)’ 버튼을 눌러 이메일을 발송하지 않도록 할 수 있습니다.

위 사항을 숙지하고 Commit(확인) 버튼을 누르면……

별로 달라진 것이 없어 보이지만, 자세히 보면 Problem revision이 0에서 1로 된 것을 알 수 있습니다. 즉, 하나의 저장본이 생긴 셈입니다.

이제 View Changes에 들어가면 revision의 내용, 즉 어느 파일이 추가(A), 변경(M), 삭제(D)되었는지, 또 각 revision의 Commit Message가 나타납니다(‘Created a prob’). 특정 revision에서의 특정 파일을 다운로드받을수 있는 등, 자주 해서 나쁠 것이 없는 기능입니다.

이제 잠깐 다시 나와볼까요. 상태에서 상단 메뉴바에 있는 View Problems를 눌러보면……

약간의 변화가 생겼습니다. Modif.(수정 날짜)에 시간도 들어가 있고(시간은 다만 모스크바 시인 MST로 표기됩니다), Info에는 만들어가야 할 것들 : statements, tests, solutions, checker, validator 등이 보입니다. 문제를 계속 이어서 만드려면 Continue를, Commit Changes하지 않는 내용을 없애고 최신의 revision으로 되돌리려면 Discard를 누르면 됩니다(Discard는 문제를 삭제하는 것이 아닙니다).

다음 포스팅에는 General Info 항목부터 손을 보도록 하겠습니다.

추신. View Changes에서 각 revision을 보다보면 ‘switch’라는 링크가 있습니다. 그 revision으로 덮어쓰는 기능입니다만, 가급적 사용하지 마시길 바랍니다. 하위 revision으로 바꾼 후 Commit Changes를 하려고 하면 conflict, 즉 revision 간 충돌이 일어나, 문제를 열지 못하게 되기 때문입니다. 이때는 Discard를 함으로써 덮어쓰기 전으로 돌아갈 수는 있지만, 괜히 상황을 복잡하게 만들고 싶으신 게 아니면 누르지 마시길 바랍니다. 이미 언급했듯이, 하위 revision의 파일을 열람 및 다운로드가 가능하니까요.