Dev Story..

추석 트래픽(난이도: 상)

이번 추석에도 시스템 장애가 없는 명절을 보내고 싶은 어피치는 서버를 증설해야 할지 고민이다. 장애 대비용 서버 증설 여부를 결정하기 위해 작년 추석 기간인 9월 15일 로그 데이터를 분석한 후 초당 최대 처리량을 계산해보기로 했다. 초당 최대 처리량은 요청의 응답 완료 여부에 관계없이 임의 시간부터 1초(=1,000밀리초)간 처리하는 요청의 최대 개수를 의미한다.

입력 형식

• solution 함수에 전달되는 lines 배열은 N(1 ≦ N ≦ 2,000)개의 로그 문자열로 되어 있으며, 각 로그 문자열마다 요청에 대한 응답완료시간 S와 처리시간 T가 공백으로 구분되어 있다.
• 응답완료시간 S는 작년 추석인 2016년 9월 15일만 포함하여 고정 길이 2016-09-15 hh:mm:ss.sss 형식으로 되어 있다.
• 처리시간 T는 0.1s, 0.312s, 2s 와 같이 최대 소수점 셋째 자리까지 기록하며 뒤에는 초 단위를 의미하는 s로 끝난다.
• 예를 들어, 로그 문자열 2016-09-15 03:10:33.020 0.011s은 “2016년 9월 15일 오전 3시 10분 33.010초”부터 “2016년 9월 15일 오전 3시 10분 33.020초”까지 “0.011초” 동안 처리된 요청을 의미한다. (처리시간은 시작시간과 끝시간을 포함)
• 서버에는 타임아웃이 3초로 적용되어 있기 때문에 처리시간은 0.001 ≦ T ≦ 3.000이다.
• lines 배열은 응답완료시간 S를 기준으로 오름차순 정렬되어 있다.

출력 형식

• solution 함수에서는 로그 데이터 lines 배열에 대해 초당 최대 처리량을 리턴한다.

입출력 예제

예제 1

• 입력: [ “2016-09-15 01:00:04.001 2.0s”, “2016-09-15 01:00:07.000 2s” ]
• 출력: 1

예제 2

• 입력: [ “2016-09-15 01:00:04.002 2.0s”, “2016-09-15 01:00:07.000 2s” ]
• 출력: 2
• 설명: 처리시간은 시작시간과 끝시간을 포함하므로 첫 번째 로그는 01:00:02.003 ~ 01:00:04.002에서 2초 동안 처리되었으며, 두 번째 로그는 01:00:05.001 ~ 01:00:07.000에서 2초 동안 처리된다. 따라서, 첫 번째 로그가 끝나는 시점과 두 번째 로그가 시작하는 시점의 구간인 01:00:04.002 ~ 01:00:05.001 1초 동안 최대 2개가 된다.

예제 3

• 입력: [ “2016-09-15 20:59:57.421 0.351s”, “2016-09-15 20:59:58.233 1.181s”, “2016-09-15 20:59:58.299 0.8s”, “2016-09-15 20:59:58.688 1.041s”, “2016-09-15 20:59:59.591 1.412s”, “2016-09-15 21:00:00.464 1.466s”, “2016-09-15 21:00:00.741 1.581s”, “2016-09-15 21:00:00.748 2.31s”, “2016-09-15 21:00:00.966 0.381s”, “2016-09-15 21:00:02.066 2.62s” ]
• 출력: 7
• 설명: 아래 타임라인 그림에서 빨간색으로 표시된 1초 각 구간의 처리량을 구해보면 (1)은 4개, (2)는 7개, (3)는 2개임을 알 수 있다. 따라서 초당 최대 처리량은 7이 되며, 동일한 최대 처리량을 갖는 1초 구간은 여러 개 존재할 수 있으므로 이 문제에서는 구간이 아닌 개수만 출력한다.

문제 해설

이번 테스트의 마지막 문제이고, 가장 어려운 문제입니다. 초당 최대 처리량이 되는 구간 윈도우를 찾아야 하는 문제인데요. 당연히 처음부터 끝까지 스캔하기에는 범위가 너무 크고, 게다가 ms 단위로 되어 있기 때문에 첫 로그 시각부터 마지막 로그 시각까지 1ms씩 증가시키면서 1000ms 단위의 슬라이딩 윈도우로 풀면 24 * 3600 * 1000 * n * 1000ms 만큼의 연산이 필요하기 때문에 이렇게는 풀 수가 없습니다.

그렇다고 각 로그의 시작 시각부터 마지막 시각까지 1ms 씩 움직이면 time(ms) * n^2 이 되며, time(ms)의 값은 대부분 천 단위 이상이기 때문에 마찬가지로 타임아웃이 발생하여 풀 수가 없습니다. 그런데 자세히 살펴보면 요청량이 변하는 순간은 각 로그의 시작과 끝뿐임을 알 수 있습니다. 따라서, 각 로그 별 2번의 비교 연산만 수행하면 되며 2 * n^2, 빅오로 정리하면 O(n^2)에 풀 수가 있습니다. 빅오에서 제거된 상수항도 매우 작기 때문에 이 경우 무리 없이 문제를 풀 수 있게 되며 C++ 기준으로 10ms를 넘지 않습니다.

물론, 이 문제는 윈도우를 사용하지 않고도 풀 수 있는 방법이 있습니다. 효율적인 알고리즘을 쓴다면, O(n log n)으로 풀 수 있는 방법도 있으니 한 번 고민해보세요. 이 문제는 가장 어려운 문제였던 만큼 정답률은 가장 낮은 17.99%입니다.

흠..머리가 나빠서 뭐라하는지 모르겠지만 그냥 시간을 ms로 변환하여 1000ms짜리 index(즉 ms/1000으로 나눈 값)로 변환해서 Map에 key, value로 넣고 1초 미만, 2초 미만, 3초 미만이냐에 따라서 index값에 각각 접근하여 +1씩 더해주고 가장 큰 값을 구하면 되지 않을까?

신이여, 저에게

내가 바꿀 수 없는 일들을 받아들이는 의연함을 주소서.

내가 바꿀 수 있는 일들을 바꾸는 용기를 주소서.

그리고 이 두 가지를 구별할 지혜를 주소서.

신이여, 저에게

 시간이 필요한 변화에 대한 인내를 주소서.

- 프리드리히 크리스토퍼 외팅거 

그리고 제가 가진 모든 것을 귀중히 여기게 하소서.

다른 어려움을 가진 사람들에 관용을 주시고,

그리고 일어나

 오직 오늘을 위해 다시 노력할 힘을 주소서. 

SVN Repositories 에서 SVN 구성을 보면 Branch , Tag , Trunk 가 있다 .

trunk

- 프로젝트에서 가장 중심이 되는 디렉토리

- 모든 프로그램의 개발 작업은 Trunk 디렉토리에서 이루어 집니다.

- trunk 디렉토리 바로 아래에는 소스들의 파일과 디렉토리가 들어가게 됩니다.

- 단어 자체의 뜻은 mainLine 과 동일한 뜻

branches

- trunk 에서 뻗어져 나온 나무가지를 뜻합니다.

- 프로그램을 개발하다 보면 trunk 디렉토리에서 또 다른 작은 분류로 빼서 개발해야 할 경우가 생김.

- 프로젝트 내의 작은 프로젝트라 생각하면 됨

- branches 디렉토리 안에 또 다른 디렉토리를 두어 그 안에서 개발하게 됨

tags

- 단어 자체의 뜻은 꼬리표 

- 이 디렉토리는 프로그램을 개발하면서 정기적으로 릴리즈 할 때 , 0.1/0.2/1.0 등

- 버전 별로 소스 코드를 따로 관리하는 공간

- 버전 별로 태그를 붙여서 tag 디렉토리 안에 보관한다고 생각하면 됩니다.

http://www.wanaplan.com/en/plan/

http://cybermap.kaspersky.com/

어떻게 하면 조직적인 학습을 효과적으로 진행할 수 있을까요 ?

조직적인 학습을  시작하기 좋은 지점은 바로 스탠드업 회의입니다

스탠드업 회의에서 ‘어제 한 일’, ‘오늘 할 일’, ‘이슈’를 팀원 들이

돌아가며 말하죠

프레임워크 설정 때문에 문제를 겪는 팀원이 있다면 스탠드업 회의에서

이 문제를 이슈로 제기합니다

물론 간단한 설정 문제라면 스탠드 업 회의가 끝나고 해결책을 아는 팀원이

문제를 겪는 팀원에게 해결책을 알려주겠죠

하지만 이런 간단한 설정 문제가 아니라 복잡하게 얽힌 문제고 해결책을 아는

팀원이 없다면 ‘조직적인 학습’이 필요한 시점입니다. 문제와 관련된 팀원들을

모두 화이트 보드에 모이도록 부탁하고 이슈를 제기한 팀원이 문제를 상세하게

설명합니다

설명이 끝나면 문제를 일으키는 근본 원인을 찾습니다. 근본 원인을 찾는 데 도요타에서 사용해서 유명해진 ‘왜’를 5번 반복해서 질문하는 방법을 활용합니다

근본원인을 찾았다면 근본원인을 해결하는 세 가지 대안을 생각해 봅니다. 물론

근본 원인을 해결할 방안이 명확하다면 굳이 대안을 세 개씩이나 만드는 것은

낭비지만 근본원인을 해결할 대책이 명확하지 않을 때 세 가지 대안을 생각함으로써 문제를 다양한 방식으로 고민할 수 있습니다

팀원들이 모여 각 대안의 장점, 단점을 비교해서 가장 적합한 대안을 선택합니다

대안을 평가할 때 말로 팀원들끼리 주고받는 것보다 화이트보드에 각 대안을 나열하고 대안마다 장단점을 기록하는 게 대안을 선택할 때 효과적입니다

이런 해결책의 진행상황은 매일 아침마다 진행하는 스탠드 업 회의에서 보고하기

때문에 팀원들이 쉽게 진척상황을 공유하고 이슈가 발생하면 공동으로 대응할 수

있습니다

스탠드업 회의에서 이슈를 제기하고 팀원들이 모여서 근본원인을 찾아 세가지를

생각하고 해결책을 실행하며 결과를 기록하는 과정은 팀원들이 공동으로 진행하는

팀 활동이기 때문에 이 과정에서 생성되는 지식을 팀 단위에서 자연스럽게 공유하고 습득합니다. 경험으로 체득하는 지식이기 때문에 굳이 기록이 필요하지 않을 듯하지만 프로젝트 팀 밖으로 지식을 전파하고 시간이 지나서 팀원들의 기억이 왜곡되거나 퇴색했을 때 참고하려면 이슈에서 해결책을 실행하는 과정과 결과를

기록으로 남겨야 합니다

기록이 필요하지만 그렇다고 많은 시간을 들이는 것도 옳지 않습니다 따라서 해결책을 수행할 담당자를 선정했다면 담당자는 이슈 내용, 근본원인, 대안 3가지와 선택한 해결책 등을 간략하게 적어서 회의실의 벽에 부착해 놓습니다     

Eclipse에 설치된 plug-in을 삭제하시려면 아래처럼 하시면 됩니다.

- Eclipse 상단의 "Help" 메뉴 선택

- "About Eclipse" 항목 선택
- "Instaallation Details" 버튼 선택
- 제거할 plug-in 선택 후 아래의 "Uninstall.." 버튼 선택

- Eclipse 재시작후 삭제 확인

소스 형상 관리를 위하여 윈도우즈에서 TortoiseSVN을 이용하고 있는데..
더이상 SVN으로 관리할 필요가 없는 프로젝트를 백업 받거나 전달하려다 보면

불필요한 .svn 디렉토리가 포함되어 용량만 차지하고 파일수도 많아 오히려 불편합니다.
일일이 모두 찾아 삭제해줘도 되지만... 아래 레지스트리 명령을 실행하면 간편하게 삭제할 수 있습니다.

아래와 같은 내용을 DeleteSVN.reg 파일로 만들어서 병합(실행)하면,

탐색기(Explorer)에 "Delete SVN Folders" 라는 메뉴가 추가되고 마우스 우클릭시 컨텍스트 메뉴에도 나타납니다.

추가된 메뉴를 선택하면 cmd 창이 하나 나타나면서 .svn 폴더를 모두 삭제합니다.

DeleteSVN.reg

레지스트리에 추가된 메뉴 삭제하려면 아래와 같은 내용을 RemoveDeleteSVN.reg 파일로 만들어서 병합(실행)하시면 됩니다.

※ 유닉스 환경일 경우 아래 쉘 명령으로 삭제할 수 있습니다.

find . -type d -name .svn -print0 | xargs -0 rm -rf

또는

find . -name ".svn" -exec rm -rf {} \;