OOJJRS

('https://www.facebook.com/Meist'이하 '마이스터')은(는) 개인정보보호법에 따라 이용자의 개인정보 보호 및 권익을 보호하고 개인정보와 관련한 이용자의 고충을 원활하게 처리할 수 있도록 다음과 같은 처리방침을 두고 있습니다.

('마이스터') 은(는) 회사는 개인정보처리방침을 개정하는 경우 웹사이트 공지사항(또는 개별공지)을 통하여 공지할 것입니다.

○ 본 방침은부터 2018년 8월 4일부터 시행됩니다.

1. 개인정보의 처리 목적 ('https://www.facebook.com/Meist'이하 '마이스터')은(는) 개인정보를 다음의 목적을 위해 처리합니다. 처리한 개인정보는 다음의 목적이외의 용도로는 사용되지 않으며 이용 목적이 변경될 시에는 사전동의를 구할 예정입니다.

가. 홈페이지 회원가입 및 관리

회원 가입의사 확인, 회원제 서비스 제공에 따른 본인 식별·인증, 서비스 부정이용 방지 등을 목적으로 개인정보를 처리합니다.

2. 개인정보 파일 현황

1. 개인정보 파일명 : 마이스터개인정보처리방침
- 개인정보 항목 : 페이스북 및 구글 인증키 (사용할 경우)
- 수집방법 : 제휴사로부터 제공 받음
- 보유근거 : 정보주체의 동의
- 보유기간 : 1년
- 관련법령 : 소비자의 불만 또는 분쟁처리에 관한 기록 : 3년, 대금결제 및 재화 등의 공급에 관한 기록 : 5년, 계약 또는 청약철회 등에 관한 기록 : 5년

3. 개인정보의 처리 및 보유 기간

① ('마이스터')은(는) 법령에 따른 개인정보 보유·이용기간 또는 정보주체로부터 개인정보를 수집시에 동의 받은 개인정보 보유,이용기간 내에서 개인정보를 처리,보유합니다.

② 각각의 개인정보 처리 및 보유 기간은 다음과 같습니다.

4. 정보주체와 법정대리인의 권리·의무 및 그 행사방법 이용자는 개인정보주체로써 다음과 같은 권리를 행사할 수 있습니다.

① 정보주체는 OOJJRS에 대해 언제든지 개인정보 열람,정정,삭제,처리정지 요구 등의 권리를 행사할 수 있습니다.
② 제1항에 따른 권리 행사는OOJJRS에 대해 개인정보 보호법 시행령 제41조제1항에 따라 서면, 전자우편, 모사전송(FAX) 등을 통하여 하실 수 있으며 OOJJRS은(는) 이에 대해 지체 없이 조치하겠습니다.
③ 제1항에 따른 권리 행사는 정보주체의 법정대리인이나 위임을 받은 자 등 대리인을 통하여 하실 수 있습니다. 이 경우 개인정보 보호법 시행규칙 별지 제11호 서식에 따른 위임장을 제출하셔야 합니다.
④ 개인정보 열람 및 처리정지 요구는 개인정보보호법 제35조 제5항, 제37조 제2항에 의하여 정보주체의 권리가 제한 될 수 있습니다.
⑤ 개인정보의 정정 및 삭제 요구는 다른 법령에서 그 개인정보가 수집 대상으로 명시되어 있는 경우에는 그 삭제를 요구할 수 없습니다.
⑥ OOJJRS은(는) 정보주체 권리에 따른 열람의 요구, 정정·삭제의 요구, 처리정지의 요구 시 열람 등 요구를 한 자가 본인이거나 정당한 대리인인지를 확인합니다.

5. 처리하는 개인정보의 항목 작성

① ('https://www.facebook.com/Meist'이하 '마이스터')은(는) 다음의 개인정보 항목을 처리하고 있습니다.

6. 개인정보의 파기('마이스터')은(는) 원칙적으로 개인정보 처리목적이 달성된 경우에는 지체없이 해당 개인정보를 파기합니다. 파기의 절차, 기한 및 방법은 다음과 같습니다.

-파기절차
이용자가 입력한 정보는 목적 달성 후 별도의 DB에 옮겨져(종이의 경우 별도의 서류) 내부 방침 및 기타 관련 법령에 따라 일정기간 저장된 후 혹은 즉시 파기됩니다. 이 때, DB로 옮겨진 개인정보는 법률에 의한 경우가 아니고서는 다른 목적으로 이용되지 않습니다.

-파기기한
이용자의 개인정보는 개인정보의 보유기간이 경과된 경우에는 보유기간의 종료일로부터 5일 이내에, 개인정보의 처리 목적 달성, 해당 서비스의 폐지, 사업의 종료 등 그 개인정보가 불필요하게 되었을 때에는 개인정보의 처리가 불필요한 것으로 인정되는 날로부터 5일 이내에 그 개인정보를 파기합니다.

-파기방법
전자적 파일 형태의 정보는 기록을 재생할 수 없는 기술적 방법을 사용합니다.

7. 개인정보 자동 수집 장치의 설치•운영 및 거부에 관한 사항

OOJJRS 은 정보주체의 이용정보를 저장하고 수시로 불러오는 ‘쿠키’를 사용하지 않습니다.

8. 개인정보 보호책임자 작성

▶ 개인정보 보호책임자
성명 :오위준
직책 :대표
직급 :사장
연락처 :010-9111-0384, oojjrs@gmail.com,
※ 개인정보 보호 담당부서로 연결됩니다.

▶ 개인정보 보호 담당부서
부서명 :
담당자 :
연락처 :, ,
② 정보주체께서는 OOJJRS(‘https://www.facebook.com/Meist’이하 ‘마이스터) 의 서비스(또는 사업)을 이용하시면서 발생한 모든 개인정보 보호 관련 문의, 불만처리, 피해구제 등에 관한 사항을 개인정보 보호책임자 및 담당부서로 문의하실 수 있습니다. OOJJRS(‘https://www.facebook.com/Meist’이하 ‘마이스터) 은(는) 정보주체의 문의에 대해 지체 없이 답변 및 처리해드릴 것입니다.

9. 개인정보 처리방침 변경

①이 개인정보처리방침은 시행일로부터 적용되며, 법령 및 방침에 따른 변경내용의 추가, 삭제 및 정정이 있는 경우에는 변경사항의 시행 7일 전부터 공지사항을 통하여 고지할 것입니다.

10. 개인정보의 안전성 확보 조치 ('마이스터')은(는) 개인정보보호법 제29조에 따라 다음과 같이 안전성 확보에 필요한 기술적/관리적 및 물리적 조치를 하고 있습니다.

1. 정기적인 자체 감사 실시
개인정보 취급 관련 안정성 확보를 위해 정기적(분기 1회)으로 자체 감사를 실시하고 있습니다.

2. 개인정보 취급 직원의 최소화 및 교육
개인정보를 취급하는 직원을 지정하고 담당자에 한정시켜 최소화 하여 개인정보를 관리하는 대책을 시행하고 있습니다.

3. 해킹 등에 대비한 기술적 대책
<OOJJRS>('마이스터')은 해킹이나 컴퓨터 바이러스 등에 의한 개인정보 유출 및 훼손을 막기 위하여 보안프로그램을 설치하고 주기적인 갱신·점검을 하며 외부로부터 접근이 통제된 구역에 시스템을 설치하고 기술적/물리적으로 감시 및 차단하고 있습니다.

4. 개인정보에 대한 접근 제한
개인정보를 처리하는 데이터베이스시스템에 대한 접근권한의 부여,변경,말소를 통하여 개인정보에 대한 접근통제를 위하여 필요한 조치를 하고 있으며 침입차단시스템을 이용하여 외부로부터의 무단 접근을 통제하고 있습니다.

① OOJJRS(‘https://www.facebook.com/Meist’이하 ‘마이스터) 은(는) 개인정보 처리에 관한 업무를 총괄해서 책임지고, 개인정보 처리와 관련한 정보주체의 불만처리 및 피해구제 등을 위하여 아래와 같이 개인정보 보호책임자를 지정하고 있습니다.

원래는 Visual Studio 2017 에서 내세웠던 빠른 로딩이, 내 사용 경험상 실패였다는 이야기를 하러 들어왔는데,

난데없이 티스토리가 로그인 하면서 늘상 사용해오던 내 크롬을 새로운 기기로 인식하여 메일 인증을 하라는 내용을 보여주어 어그로가 이쪽으로 확 튀었다.

티스토리의 행보가 걱정된다... + 다른 둥지를 알아봐야 하나.

Visual Studio 2017 로딩은 2015 와는 다르게 그때 그때 로딩하는 방식인 듯 한데 내 작업 방식으로는

이게 더 불편한 것 같다. 차라리 로딩을 처음에 다 몰아두고 누를 때마다 반응이 즉시즉시 오는 게 더 좋은데

2017은 반응이 한 박자 늦어서 단축키를 씹거나 엉뚱한 패널이 단축키를 잡아먹어서 이상한 동작을 하는 경우가 너무 잦다.

(ex : 파일을 3개 이상 동시에 열면 다시 창을 닫을 때 로딩을 3번째 파일부터는 안해둔 상태이기 때문에 포커스가 파일에 갔을 때 로딩부터 끝나야 닫을 수 있다거나, 프로젝트에서 Add ... 를 수행할 때 엔트리 구성에 시간이 걸려서 단축키가 엉뚱하게 동작한다거나...)

왠지 조만간 2015로 롤백할 것 같다.

새 둥지를 틀 생각을 하니 너무너무너무너무 귀찮다...

밖에서 Quantity 를 참고하는 곳이 없자 _quantity 가 실제로 액세스되는 곳이 없다며 경고를 보여주고 있다.

2015 보다 더 진보한 모습.

경고를 지우기 위해 대충 작업해두려는데 안 통해서 원인을 알고 난 뒤 잠시 감탄했다.

간만의 포스팅은 영양가 없는 글로부터.

그런데 티스토리가 BlogAPI 기능을 종료해서 Windows Live Writer 를 더 이상 사용할 수 없게 되어버렸다.

...

귀찮아... 이걸 또 찾아봐야 하다니...

http://www.mikebrawley.com/2011/11/command-line-windows-folder-environment-variables/

키워드 생각이 안나서 검색할 때 빡쳤던 것을 반추해서

오늘이 딱 3개월일 것 같은데 왜 휴면 계정이 된 거야!!!

ASUS B85M-G Realtek HD Audio 기준 설정에서 헤드폰과 스피커 설정 전환이 무시당하는 경우가 있다.

이번에는 그래픽 드라이버 업데이트 이후에 발생했는데 (아마도 드라이버에 HDMI 오디오 관련 업데이트가 있어서?) 해결하느라 (레퍼런스도 없고) 힘들었다. 표현할 욕설이나 단어가 시원한 게 없네 시발. 이런 쪽으로는 무지한데다 귀찮기도 하고 자동으로 잘 해주는 날은 요원한가.

기본적으로 디지털 아웃풋은 기본 통신 장치로 놓고, 스피커와 헤드폰을 기본 장치로 설정해야 하는데, 한 번 설정 잘했다고 되는 게 아니라 헤드폰을 뺐다 꽂았다를 반복하며 기본 장치가 설정대로 잘 순환되는지를 봐야 한다.

레퍼런스 삼아 기록으로 남겨둔다.

대상 속성 이벤트는 그룹으로 정렬했을 때 일반적으로 많이 사용하는 대상들이다.

• AutoSizeChanged
• AutoValidateChanged
• ClientSizeChanged
• CursorChanged
• DockChanged
• EnabledChanged
• LocationChanged
• MaximizedBoundsChanged
• MaximumSizeChanged
• MinimumSizeChanged
• ParentChanged
• RegionChanged
• SizeChanged
• VisibleChanged

첫 실행 시

최대화 수행

원래대로 수행

최소화 수행 후 원래대로 수행 (redrawing을 임의로 호출하기 귀찮아서 대충 찍었다)

이동 및 크기 조절

windows key + 화살표로 크기 및 위치 조절

-_- 라이브 라이터를 새로 깔았더니 설정이 다 날아가서 귀찮다… 아악

다른 테스트 결과는 워낙 뻔해서 귀찮아서 스크린 샷 생략

사실 이거 전에도 한 번 설치하려다 통수 맞은 내용인데 포스팅을 안 쓰니 기억이 안 나는 것 같아서 기록 삼아 남겨둔다.

https://support.microsoft.com/ko-kr/help/17779/download-windows-essentials

2011까지는 개별적으로 받고 설치할 수 있었으나 2012부터 Essentials 라는 이름으로 설치 파일이 통합되었으며 Windows 10 을 사용하고 있다면 2011 이하의 버전으로는 설치가 되지 않는다. 물론 Windows 8.1 이후 버전을 지원하는 에센셜이 없어서 아쉽긴 하지만 언젠간 내주겠지…

0x80190194 요런 에러가 나면서 설치가 안 되면 버전을 확인해보자.

나름 불성실하게나마(?) 한달에 몇 번 정도는 로긴 했다고 생각했는데

어제 로그인 시도하니까 휴면 계정이 되었으니 깨우라더라…ㅡㅡ;;

근래 들어 보기 드물게 당황해버렸다.

아직 3개월 안 됐다구…

3월 한 달은 주말마다 팩토리오를 즐겼다면, 4~5월 두 달은 주말마다 아크를 즐기느라 –_- 한동안 격조했었다.

이제 당분간은 할 게임이 없을 것 같아 안도하면서, 작업한 내역을 스샷으로 대체하여 올려본다.

대화 입력창의 컨트롤을 RichTextBox에서 서드파티 TX TextControl 로 교체해 보았다.

사용법도 상식에서 어긋나지 않는데 문서도 잘 마련되어 있어 만족스럽다.

이런 걸 무료로 풀어주다니 제작사에 감사드립니다.

http://www.textcontrol.com/en_US/sites/tx-text-control-express/

Rich Text Editor를 직접 만들기 피곤해서 이래저래 (무료인) 서드파티 라이브러리들을 찾아 헤맸는데, 결국 한 개 찾아내어 소개한다.

원래 유료인 솔루션의 일부를 Express로 제공한 것 같은데 용량이 좀 큰 감은 있지만 상당히 훌륭하다. 지원하는 포맷도 내가 필요로 하는 RTF를 포함하여 여럿 있고 기본으로 제공하는 기능도 무난하다. 텍스트 컬러를 변경하는 버튼이 툴바에 포함되어 있지 않아 조금 당황하긴 했다. 유료 버전에는 포함이려나? 물론 기능 자체는 메뉴를 타고 들어가면 있다.

세상은 아직 아름답다.

웹 서버가 클라이언트의 요청을 처리할 때 일반적으로 path와 query를 통해 호출되는 메소드를 분류한다면, 웹소켓은 태생부터가 기존 웹 동작 방식과 다르기 때문에 이 api 사용법에 있어서도 차이점이 생기는 것 같다.

connectionless이기 때문에 매 요청 시 api를 변경할 수 있는 일반 웹에 비해 웹소켓은 TCP와 마찬가지로 connection-oriented인 관계로 처음 연결 요청 외에는 웹소켓 자체 인터페이스만 갖고는 api를 변경할 수가 없다. (기존 http 인터페이스를 이용하면 되겠지만 이 경우 연결을 끊었다 붙였다… 웹소켓 왜 씀?)

웹소켓은 마치 TCP처럼 필요한 콜백 핸들러가 OnOpen, OnClose, OnMessage, OnError 네 가지 뿐이기 때문에 api마다 메소드를 붙이는 기존 웹 개발 방식과도 실질적인 코드 차이가 발생한다.

결론은 웹소켓은 query 사용하지 말고 TCP처럼 패킷을 정의하자.

C#에서 다음과 같은 분할창이 되도록 해주는 라이브러리다.

기능적으로도 매우 유용한 데다 코드 자체도 라이브러리를 제작할 사람이라면 레퍼런스로 사용할 수 있을 정도로 좋은 것 같다. 단점이라면 문서화가 잘 안 되어 있어서 코드를 직접 분석하지 않고는 사용하기 힘들었다는 점 정도가 있었는데 요즘은 이래저래 (다른 사람들의 협조 아래?) 참고할 만한 곳들도 생기는 듯 싶다.

공식 : http://dockpanelsuite.com/

http://www.independent-software.com/weifenluo-dockpanelsuite-tutorial-cookbook/

https://media.readthedocs.org/pdf/dockpanelsuite/latest/dockpanelsuite.pdf

누리 개발 시 있었던 삽질 하나 기록. 클라이언트 로그 창은 원래 로그인 화면이 있기 때문에 처음부터 메인 화면에 저렇게 붙어있지 않은데, 그래서 로그 창을 먼저 Show() 해버리고 나중에 라이브러리의 메소드인 DockPanel.Show(…)를 다시 호출하면 문제가 발생했다. 해당 창들은 모두 닫더라도 소멸시키지 않고 재사용하기 때문에 Close() 하는 대신 Hide()를 하고 다시 Show(…) 를 하면 되겠지 싶었는데 계속 문제가 나서 코드를 추적해보니, Hide() 함수 또한 재정의되어 있어서 창을 즉시 감추지 않는 문제가 있더란 말이다. 근데 마찬가지로 재정의된 Show() 메소드는, 내부적으로 DockPanel이 설정되지 않은 상태에서는 그냥 Forms.Show()를 호출한다. 하지만 Hide() 메소드는 그런 것 없고 그냥 자기 것만 사용해서 문제가 발생했던 것. 때문에 로그 창의 Hide() 메소드를 Forms의 것으로 캐스팅하여 강제 호출한 다음 다시 Show(…)를 해서 간신히 해결했다는 이야기. 이건 왠지 Hide() 메소드를 수정해야할 것으로 보이는데…. 아, 물론 최신 버전에서는 수정되었을지도 모른다.

오늘은 포스팅 주제 풍년인 듯 하다.

위 두 개 속성의 MSDN 페이지가 한글인 척하고 부분 번역이라서 일단 번역을 첨부한다.

원문 링크 : KeyEventArgs.Handled, KeyEventArgs.SuppressKeyPress

Handled

(키 이벤트의) Handled 속성은 다른 Windows.Forms 소속의 컨트롤들과는 다르게 구현되어 있다. native Win32 컨트롤을 기반으로 하는 텍스트 박스 같은 컨트롤들에서는, (이 속성값이) 발생한 키 메시지를 native Win32 컨트롤을 상속받은 컨트롤(즉, C#에서 만든 TextBox 클래스 본인)에게 전달되지 않게 한다는 의미로 해석된다. 만약 텍스트 박스의 Handled 속성을 true로 설정하면 그 컨트롤은 key press 이벤트를 (C# TextBox 클래스로) 전달하진 않겠지만, (native Win32 컨트롤 자체에는 전달되기 때문에) 유저가 입력한 대로 문자들이 찍히기는 할 것이다.

만약 현재 컨트롤이 key press 메시지를 아예 못 받게 하고 싶다면 SuppressKeyPress 속성을 사용하라.

SuppressKeyPress

key down 메시지 핸들러 같은 곳에서 유저의 입력을 방해하기 위한 용도로 이 속성을 설정할 수 있다.

SuppressKeyPress 값이 true가 되면 Handled 속성 또한 true로 설정된다.

해당 속성의 주석까지 다 털어본 결과 결국 Handled 속성은 기본 이벤트 핸들러를 호출하지 않고 건너뛰겠다는 얘기 같았지만, 여전히 역할상으로 이 두 개가 무슨 차이인지 설명만 봐서는 감이 안 와서 테스트해 보고 다음과 같은 결론을 얻었다.

• KeyDown/KeyUp 핸들러에서 Handled 속성을 true로 설정하면 KeyPress로 처리되는 문자를 제외한 키 입력 처리가 되지 않는다. 즉, 문자열 입력은 정상적으로 되지만 방향키나 Home/End 등이 제대로 동작하지 않는다. 엔터키의 경우는 문자열로 취급되기 때문에 KeyPress가 호출되어 전달은 되지만 시스템적인 처리(라인피드 등)는 되지 않는다.
• KeyPress 핸들러에서 Handled 속성을 true로 설정하면 C# TextBox(Rich 포함)에서 문자 출력이 되지 않는다.
• KeyDown/KeyUp 어디서든 SuppressKeyPress 값이 true가 되면 해당 메시지가 아예 처리되지 않는다. 따라서 KeyPress도 자연스럽게 발생하지 않는다. KeyPressEventArgs에는 SuppressKeyPress 속성이 없다.

이제 명확하게 사용할 수 있겠다!

2월 26일에 스팀에 오픈한 뒤로 4번의 주말을 팩토리오와 함께했다.

주말만 되면 30시간 가량을 이 녀석과 함께 하는 바람에 작업이고 뭐고 전부 보류….

근 10여 년 안에 이토록 빠르게 100시간 플레이 타임을 넘긴 게임이 처음이어서 기념 삼아(?) 올려본다.

물론 엔딩을 보긴 했지만, 아직 끝난 게 아니다…!

TDD의 가장 큰 약점으로 꼽히는 것은 바로 GUI 레이어에 대한 테스트가 어렵다는 것이다. GUI는 특성상 유저의 상호 작용을 필요로 하므로 일반적인 테스트 프로젝트처럼 싱글 스레드 기반의 구조적인 프로그래밍으로는 무리가 있다. 그래도 출력을 밀어넣기만 한다면 어찌저찌 되겠지만 출력 내용이 올바른지 검사해야 하거나 입력까지 필요로 한다면 테스트 시스템을 구축하는 비용이 훨씬 커져서 테스트 기반만 마련하다가 프로젝트가 끝날 판이다. (사실 어플리케이션 환경에 따라서는 그러고도 출력 내용을 검사할 수 없는 게 태반이다)

때문에 TDD 방법론에서는 대개 GUI 쪽 테스트 시스템 구축을 포기하거나 휴리스틱한(이라고 쓰고 수동이라고 읽는) 방법을 선택하는데 GUI 테스트가 많이 필요한 환경에서는 분명 솔루션의 부재가 아쉽다. (아예 없지는 않지만 사실 있다고 보기도 좀 프로그램에게 미안하다)

누리에서도 채팅 기능은 생각보다 복잡해서, 출력도 여러 가지를 요구하지만 입력 데이터도 다양하고 채팅의 종류도 다양하다. (마스터 채팅, NPC 채팅, 시스템 채팅, 주사위, 이미지 삽입, 링크, …) 채팅 내용 자체의 출력은 RichTextBox 등을 사용하면 그럭저럭 편하게 할 수 있지만 다음 화면과 같이 나오게 하기 위해서는 윈도우 컨트롤 중 가장 복잡한 ListView 컨트롤 + Owner Drawing의 조합이 필요하다.

커뮤니케이션 도구인 아틀라시안의 힙챗 중 일부

안타깝게도 TDD를 통해서는 저 내용이 제대로 출력되는지 확인하기가 요원하다. 아무리 단위 테스트Unit Test를 거치더라도 그것은 아래의 이미지에서 보듯이 반쪽짜리 테스트 밖에 되지 않는다.

단순하게 도식화된 채팅매니저, 테스트 코드, 실제 GUI 폼 간의 관계

사실 여기서 구조가 제대로 정비되려면 추가 정비가 필요한데 그것이 무엇인지 생각해보는 것도 괜찮을 것 같다.

실제 사용할 경우에는 크게 문제되지 않지만 개발 도중에는 상당히 불편하다. 주요 기능을 개발하기 위해 매번 테스트용 이메일과 비밀번호를 입력하고 들어가는 것은 생각보다 생산성을 훨씬 떨어뜨린다. DB 작업으로 테스트 데이터가 초기화된 다음이라면 테스트 계정을 또 만드는 것이 한 보따리 작업일 수도 있다.

우리는 바보가 아니므로 다음과 같이 질문할 수 있다.

주요 기능부터 만들고 마지막에 로그인(계정) 기능을 만들면 되잖아요.

하지만 누리의 주요 기능에는 다수의 사용자가 상호 작용하는 서버 접속, 대화 등의 기능이 포함되어 있으므로 계정 관련 기능이 먼저 필요하다.

그럼 다른 방법이 있다.

자동으로 이메일과 비밀번호를 테스트용 데이터로 입력해 두면 되죠.

나쁘지 않은 방법이다. 특히 여러 명이 필요 없는 대다수의 초기 기능을 만들 때에는 아마도 가장 빠르게 이런 방법을 사용할 것이다. 하지만 둘 이상의 접속자가 필요한 기능을 테스트할 때에는 여전히 한 개를 제외한 나머지 인스턴스들은 죄다 바꿔줘야 하는 점에 변함이 없다.

좀 더 나아가자.

인스턴스 별로 각기 다른 테스트용 이메일을 사용하게 하는 건 그리 어렵지 않아요.

자, 조금 신중해질 시점이 왔다. TDD가 어플리케이션 개발에 대단한 기여를 했지만 그 역시 여러 약점을 갖고 있었는데 그 중 하나가 바로 테스트 데이터의 오류에 대한 검증이다. 이 부분을 건드리는 순간 분화구 뚫는 용암처럼 온갖 이론과 철학들이 분출된다. 우리의 이야기가 TDD는 아니지만 지금 이 문제에 집중한다면, t1@mail ~ t10@mail 을 인스턴스 별로 할당하고 집어넣은 것이 기능 개발에 어떤 부작용을 발생시킬 지 고민하지 않을 수 없다는 것이다. 단위 테스트를 통해 어느 정도 해결 가능한 면이 있지만 저 정도의 기능 개발은 필연적으로 통합 테스트 단계를 요구한다. 이 단계가 누락되면 나도 모르게 기능 개발에 테스트 데이터가 감안된 사양이 나와버리고, 저 단계를 집어넣으면 기능 개발에 상당한 시간이 소요된다.

그렇다면 다른 주요 기능의 개발과 테스트를 위해 편리함을 더하고자 테스트 데이터를 넣어 문제 가능성을 높이는 찝찝함을 다른 방식으로 혹은 더 영리하게 피할 수 있을까?

개발 중에만 계정 정보 없이 임시로 생성된 정보로 바로 실행할 수 있게 하면요?

이후의 진행을 두 가지로 나누어볼 수 있겠다. 접속 버튼을 눌렀을 때 기계적인 데이터 생성을 통해 계정 정보를 임시로 만들어 넘겨주는 것과, 계정 정보가 없을 때에 대한 예외 처리를 일일이 작성하는 것. 전자의 방식은 사실상 바로 직전에 이야기한 테스트 데이터에 대한 문제를 고스란히 갖고 있으므로 그다지 진보하지는 못했다. 무작위로 여러 데이터를 조합해서 계정 정보를 만들면 오히려 의도하지 않았던 데이터가 사용되어 테스트에 노이즈가 발생한다. 후자의 방식은, 얼핏 보면 초보 프로그래머나 저지를 법한 막무가내식 작업으로 보일 지도 모르지만 서버와 클라이언트 모델을 사용하고 해킹의 위협이 항상 존재하는 프로그램에서는 방어적 기법으로 도배되는 경우가 많이 있다. 물론, 진짜 로직적인 이유로 데이터가 깨졌을 때와 우리가 의도적으로 데이터를 주지 않은 경우를 구분할 수 없으므로 이 방식이 올바르다는 말은 아니다.

약간 복잡한 이야기로 전개해보자.

세 번째 방법에 데이터 추상화를 끼얹어서 테스트 데이터와 실제 데이터를 구분하면 되겠네요

데이터의 종류도 하나의 데이터로 볼 수 있다. 이에 초점을 맞추면 ‘테스트’와 ‘실제’ 라는 속성은 데이터를 구분하는 주요한 데이터 중 하나다. 따라서 이를 데이터 내의 속성으로 추가하든 상속 구조를 차용하든 둘을 분리하여 처리하는데 활용할 수 있다. 그러나 이 구조는 생각보다 개발 비용이 크다. 데이터는 데이터일 뿐, (올바르다고 이야기하는 구조에서는) 보통 기능을 포함하지 않기 때문에 바로 위에서 이야기한 예외 처리 비용처럼 모든 기능이 테스트용일 경우와 아닌 경우에 대해 구현되어야 하는 문제가 발생한다. 여기에 계정 정보가 잘못되었을 때의 처리를 더하면 모든 기능이 최소한 세 가지 경우에 대해 구현되어야 하는데 마스터 계정, 손님 계정, 관전자 계정 따위가 더해지면 문어발도 부족할 지경이다. 이를 도식화하면 아래와 같이 간결하게 나오는데,

Method가 옆으로 무한정 늘어나는 모습이 아름답게(=객체지향스럽게) 보일 수도 있지만 이는 개발 비용을 계속 증가시켜서 투입할 수 있을 때에나 가능한 방법이라고 하겠다. 사양 변경에 맞춰 코드 변경이 전체에 걸쳐 발생하므로 QA가 할 일도 줄어들진 않을 것이다.

그렇다면 저 약점을 극복할 수 있는 방법이 있으니 더더더 복잡한 이야기를 해보자.

궁극의 오의 DDD를 끼얹겠습니다. 코드 변경 없이 동작할 수 있게 하면 되는 거죠?

TDD와 마찬가지로 DDD 또한 개발 방법론에 끼친 영향이 (현재진행형으로) 엄청난데 약점도 거대한 편이다. 우리가 최초 이 이야기를 시작한 이유를 다시 상기해보자. 우린 다른 기능의 개발 및 테스트를 효율적으로 진행하기 위해(=테스트 비용을 줄이기 위해) 과정을 간소화하는 방법에 대해 이야기하고 있다. TDD를 도입하거나 DDD를 도입하거나 (또는 DOP를 계획하거나) 하는 등의 일은 프로그램 설계 단계에서 미래를 결정 짓는 정도의 일이다. 애초에 프로그램이 DDD로 진행되고 있다면 생각해볼 법한 방법이나, 혼자서 만들고 있다면 이 정도 규모로 설계한 것을 재고하길 권한다. 그 시간에 하드코딩하는 것이 훨씬 빠르다.

위와 같은 과정은 단순한 기능 개발 하나에서도 뭔가를 해결하기 위해 고민하면 흔하게 접할 수 있는 문제다. 그런데 결국 해결하지 못하고 고민이 계속 된다. 그 이유가 무엇일까?

네가 너무 완벽한 해결책을 요구해서죠.

완벽한 해결책이라는 단어를 좀 더 풀어서 설명하자면 다음과 같은 속성을 지녔다고 생각한다.

• 미래에 다른 작업이 추가/수정/삭제 되더라도 영향을 주거나 받지 않는 (시간 조건)
  • 미래에 추후 작업이 발생하지 않는(=유통기한이 영구적인)
• 부분 해결이 아닌, 모든 상황에 대한 해결이 가능한 (상황 조건)
  • 자동 작업 외 수동 조작이 추가로 필요하지 않는
• 비개발적인 상황 조건을 고려하지 않고 모두 적용할 수 있는 (자원 조건)
  • 1인 개발일 때와, 5인 이하 소규모일 때와, 50인 이상 대규모일 때 모두 사용 가능한
  • 개발 시간이 없을 때나 넉넉할 때나 모두 사용 가능한

자, 이 포스팅의 주제에 대해 이야기할 시간이 왔다. 우리가 비록 개발자지만 이러한 문제 해결에 대해서, 혹은 설계에 대해서는 0과 1의 딱 떨어지는 결과가 아니라 굉장히(굉장히 굉장히) Fuzzy한 선택과 집중을 할 수 있는 자세가 필요하다는 것이다. 그 중 선두주자는 유통기한이다. 재작업을 좋아하는 개발자가 별로 없을 거라고 생각하지만, 중요한 것은 그 재작업의 빈도인 것 같다. 보통 두 번째와 세 번째 이유는 당연히 고려하면서도 자신의 코드가 언제까지 유지되는가에 대한 부분은 최소한 자신이 해당 프로젝트를 마감할 때까지는 변경이 없을 거라고 (또는 변경이 없게 만들 거라고) 생각을 많이 하는 듯 싶다. 그리고 그 부분이 고민을 끝나지 않게 만든다.

하지만 위의 사례에서, 일단 두 번째 방법을 택한 다음 1시간 정도를 투자해서 앞으로 4개월 정도 버틸 수 있다면 채산성이 훌륭하다고 본다. 그렇게 기본 기능을 만들고, 더 복잡한 테스트 데이터를 요구하는 시점에 좀 더 작업해서 또 y개월을 버틸 구조를 넣고 하는 식이다. 처음부터 미래를 예측하여 많은 고민을 하는 것은 그렇게 좋지 않다고 이야기하지만, 바로 그것을 버리지 못하는 경우를 많이 보아와서 마침 간단한(?) 사례가 있기에 정리해 보았다.

뭐랄까, 간만에 개발 일지다운 글이 된 것 같다. (정작 개발은 안 하고?)

3주 전 어쩌고 글을 쓴 게 엊그제 같은데 이 글이 한 달 만에 쓴 글이 되었다…

어쩔…

마지막 근황을 올린 게 벌써 3주도 더 지났다니…

정신과 시간의 방이 필요하다.

서버 작업이 커져서 눈에 보이는 게 없을 뿐 작업을 하고는 있다. ご,.ご

물론 회사 서버 작업이 우선이므로 코드가 역수입되고는 있지만 잠시 정신차려보니 한달 가량 커밋을 방기했더라…는…

이런 프레임워크 마련은 빨리 눈에 보이는 것들 만들어서 활용하는 것에 관심이 많은 나 같은 작업자들에게는 고역의 과정이다.

항상 그렇지만 이얍 툭탁 하면 생각대로 만들어지는 프로그램이 있었으면 좋겠다….

시작 – 실행 – sqlservermanager12.msc (2014 버전 기준)

2012는 sqlservermanager11.msc 로 하면 된다.

회사 2008 R2 서버에 설치했을 때에는 저 항목이 잘 나와서 어려움 없이 찾아들어갔는데

집에 윈도우10 위에 설치했을 때에는 항목도 없고 설치 경로로 가도 실행 파일이 없어서 꽤 당황했다 –.-

system32 (혹은 syswow64) 안에 숨겨져 있더라…

익스프레스라서 그런가…?

개발 쪽에 올라오는 페이지들이 누리를 개발하면서 마주치는 이슈 중 분명 까먹을 것 같은 내용들을 정리한 것이다.

아니, 사실은 훨씬 많은데 귀찮아서….

서버 작업으로 프로젝트를 재개할 필요가 있어서 요 며칠 좀 매달렸는데, 이제 감을 슬슬 찾았으니 클라이언트 작업을 시작해도 좋을 듯 하다.

그럼 일지 제목도 나오고 하려나….

var stopwatch = Stopwatch.StartNew();

Thread.Sleep(300);

Console.WriteLine("elapsed      : {0}", stopwatch.Elapsed);

Console.WriteLine("elapsed2     : {0}", stopwatch.Elapsed.Ticks);

Console.WriteLine("elapsedMilli : {0}", stopwatch.ElapsedMilliseconds);

Console.WriteLine("elapsedTicks : {0}", stopwatch.ElapsedTicks);

ㅡㅡ 하 거 설정 최적화하기 힘드네… 어찌 해도 맘에 드는 모양새가 안 나와

Visual Studio에서 제공해주는 유닛 테스트 기능과 .NET의 async 기능을 붙여볼 때 async void 메소드의 유닛 테스트 사용은 보통 권장하지 않는다. async void의 의미는 “너는 저질러라, 나는 간다.” 라서 그렇다. 보통 결과값의 테스트가 중요한 유닛테스트에서 void 리턴형은 자체로도 곤란하지만 내부에서 예외를 던질 경우 좀 더 곤란하다. 다름아닌 유닛 테스트 프로세스의 크래시 ㅡ_ㅡ

다음은 Visual Studio 2015 Community 버전에서 발생하는 에러 메시지인데,

The active Test Run was aborted because the execution process exited unexpectedly. To investigate further, enable local crash dumps either at the machine level or for process te.processhost.managed.exe. Go to more details: http://go.microsoft.com/fwlink/?linkid=232477

async void 리턴형인 메소드 내부에서 예외를 던질 경우 받아서 처리할 타이밍을 비롯하여 아기자기한 문제들이 엮여서 발생하는 것으로 추정된다.

당연히 async Task / await 를 사용하는 식으로 해결 가능하다.

하지만 async void 또한 종국에는 어떤 대리자가 도맡아서 사용하는 경우를 막을 수도 없거니와 그런 녀석들이 테스트에서 배제되는 경우도 바람직하지 않으므로 대안은 필요해보인다. (아니 것보다 일단 저건 vs 버그라고 생각된다)

날짜는 어차피 게시일이 나오니 필요 없고… 제목에 대한 고민이 필요하구나.

작업을 다시 시작해서 일지라도 올려야지 라고 마음 먹은 것이 무색하게도 하필 서버 작업 차례인지라 보여줄 수 있는 것이 없다…!

오늘은 새 계정 생성 기능을 넣었고 아직 본 작업은 시작도 못 한 채 곁가지 작업들을 하고 있다.

윈도우 서버 위에 웹소켓, MSSQL을 이용하고 있다. 웹소켓의 경우는 윈도우즈7 버전까지는 클라이언트 API 들이 지원되지 않아 7월 29일에 윈도우즈10 이 나오길 고대했던 기억이 있다. (윈도우즈8은 건너뛰었으니까…) 날짜까지 기억할 정도로.

웹소켓이나 async 등의 기능을 보고 있자면 요즘 개발은 정말 편해졌구나 하는 생각이 새삼 든다.

-_-

시작한 지 좀 됐지만 바빠서 차일피일 계속 미뤄지는 터라 작업일지라도 남기면서 반성을 좀 해야하지 않을까 싶다.

말 나온 김에 확인해보니 7월 10일에 시작했는데 9월 말까지 작업하다가 2개월 동안 손도 못 댔다….

누리는 ORPG(Online TRPG) 전용 프로그램이며 주변 몇몇만 알고 있지만 누리1이 2003년도에 나왔다는…!

(요즘엔 빌드도 안 될 것 같다)

기본적으로 누리3의 기능을 대부분 계승하고 있으며 누리1 시절부터 추구해왔던 실시간 지도 기능과 주사위 파워 기능을 이번에도 이어가고자 한다.

그에 더해 누리4에서 핵심적으로 기획 중인 기능은 다음과 같다. (누리4에서 추가되는 기능은 굵은 글씨!)

1. 실시간 지도 작성 / 공유 / 전송 기능
1. GM 및 유저별 전용 레이어 제공
2. 미리 작성한 지도 저장 / 전송 기능
3. 외부 텍스처 및 이미지 활용 기능
4. GM이 조작할 수 있는 지도 안개 기능
2. 대화 및 주사위 기능
1. 다양한 글자 속성 설정 기능 (글꼴, 색상, 모양, 효과, …)
2. 대화 종류 지정 기능 (잡담, 캐릭터 대화, GM의 말, NPC 대사, …)
3. 리플레이 저장, 자동 저장 및 복구 등
4. 대화 활동 그래프 (분석용)
5. 주사위 단축키 / 매크로 설정 기능 강화
3. 네트워크 기능
1. 로비
2. 플레이 방 개설 기능
3. 관전
4. 모바일 연동 기능

위의 기능이 전부가 아니라 “이 정도면 확 좋아졌네” 싶은 것들만 일부 정리해서 나열해두었다.

문제는 언제 완성될라나.

로 업그레이드 하면서 계속 로컬DB가 접속이 안 되는 기현상이 발생하기에 내가 오랜만에 해서 뭔가 누락했을 거야라고 타이르고 몇 번이나 재설치해가며 테스트했는데 알고보니

(LocalDB)\v11.0 에서 SQLEXPRESS로 디폴트 서버 이름이 변경되었더라

라는 슬픈 이야기

이런 패치 내역도 보는구만