All Posts

간혹 이클립스로 개발하다보면 어쩔수없이 강제 종료를 하게되는데, 이때 이클립스 플러그인으로 톰캣을 연동해 사용하다 강제 종료 했다면,톰캣 포트가 죽지않아 강제로 죽여야 하는 상황에 놓이게 된다. 유닉스나 리눅스면 netstat 또는 ps 와 같은 명령어로 PID를 찾고 kill 명령어로 해당 PID 를 찾아 죽일수 있으나, Windows는 당췌 알수없어, 매번 구글링을 하게 된다. 이젠 이 구글링 하는것도 귀찮아 정리해야겠다. ㅇㅎㅎ 열린 포트의 PID 확인하기 netstat -ao 위의 명령어를 사용하면, 아래와 같은 형식으로 출력된다. Proto Local Address Foreign Addresss State PID TCP 나의-컴퓨터:10000 somewhere.com LISTENING 666 죽이고 싶은 포트가 10000번 이었는데,.. 10000번 포트를 차지하고 있는 프로세스는 666 이구나!! 프로세스 강제 종료하기 netstat는 리눅스나 윈도우즈나 동일한데 맥에서는

오늘은 타임로그 관련 공식 3탄, 비공식 4탄입니다. 본래 계획했던 글쓰기 일정보다는 약간 늦었습니다. 글쓰기 앞서, 안타깝게도 이번에는 번다운차트가 없습니다. 지난 Sprint6 가 너무나 정신없이 흘러가버려서 스크릿샷 뜨는걸 잊어버렸습니다.ㅜㅜ 정말 슬픕니다. 왜냐면, 이번 Sprint6 번다운 챠트는 그동안 제가 그렸던 그래프중에서,.. 가장 자랑할만한 그래프였꺼든요.. 일정산정도 거의 정확했고, 일정한 개발속도를 유지했으며, 특별한 이슈도 없어서,.. 보통 마지막에 위로 올라가곤했던 예상시간 그래프(노란색그래프)도 초기 예상한 일정대로 한치의 흐트럼 없이 진했됐던 Sprint 였습니다. (오히려 릴리즈 마지막날 역으로 일정이 감소됐습니다.) 백문이 불여일견이라고, 번다운차트를 보여줘야 이해가 빠를텐데.. 아깝네요..ㅜㅜ.. 어떻게든 그래프를 살려서 보여드리도록 하겠습니다. 이상 각설하고, 이번 포스트의 주제는 정확한 일정산정하기 입니다.!! 정확한 일정 산정하기 정확한 일정을

내가 가고 싶은 여행 어제 오늘, 예비군 훈련가면서 책을 한권 들고 갔는데.. 이제 1/3 정도를 읽은것 같다. (민희, 파스타에 빠져 이탈리아를 누비다. 라는 책..) 오늘은 독후감을 쓰려는게 아니기 때문에 책 내용은 패스~!! 여튼, 이 책은 다른 유럽관련 책들보다는 재미있다. 보통은 어디를 가면, 뭐가 있으니, 꼭 들려라 하는 그런 여행 가이드인데 반해, 이 책의 파스타를 주제로, 글쓴이가 이탈리아 곳곳을 누비며, 기록한 음식기행에 가깝다. 그 때문인지 책속의 내용들이 어렵지 않게.. 쏙쏙 들어오고,..(아무래도 글을 맛갈나게 잘쓰는듯..) 나도 저렇게 여행하고 싶다 라는 생각이 자꾸든다. 단순히 목적지를 찍는 여행이 아니라.. 한군데를 찍더라도, 현지인과 직접 교감하는 그런 여행.. 이번에 할수 있을까? 왠지 주요 관광지만 찍고 올듯.. ㅎㅎㅎ 이제 앞으로 95일 도대체 어디를 가야할지 아직 일정도 확정짓지 못했다. 아는것이 너무없다. 예전에 혼자 전국일주를 하겠다며, 일주일

오늘 미투머니 테스트 코드를 작성하다가 그동안 안개속에 쌓였던, 정규식의 맘을 헤아리게 되어 몇가지 공유합니다. 제가 말하고자 하는 내용은 사실 이 포스트에 다 있어요. 정규식 RegExp Vs String정규식은 기본적으로 문자열 패턴을 응용한 놈입니다. 그러니 당연히 String 객체와는 뗄레야 뗄수가 없는 놈입니다. 생각해보면 너무나 당연한 사실을 그동안 크게 신경 안쓰고 있다가 이제야 깨달았네요. 정리하면, 정규식은 2가지 형태로 사용할수있습니다.1. 정규표현식 객체(RegExp)를 사용하는 방법2. 문자열 객체(String)의 정규식 메소드를 이용하는 방법 메소드만 정리하면 대강 이렇습니다. RegExp.test() - Boolean 값을 리턴 RegExp.exec() - 매칭된 값을 Array로 리턴 String.split() - String.match() - String.replace() - String.search() - RegExp.test() Vs RegExp.ex

이번에는 예전에 작성한 하루에 얼마나 일하고 있나요? 에 이어서 2번째 시리즈입니다. 본래는 타임로그관련 3번째 포스트네요. 첫번째 포스트는 여기에 실었습니다. 이전 포스트에서는 타임로그를 작성법과 더불어, 타임로그 통계 정보들을 공유 드렸는데요.. 이번에는 개발속도에 대해서 이야기 하려 합니다. 개발 속도와 추정 개발 속도를 이야기 하기 앞서, 지난 Sprint 5 에 대한 번다운 차트부터 봅시다! [[ 이 글의 이미지도 역시 날려먹었네요. ㅜㅜ ]] 이전 포스트에서도 밝혔지만, 전 위와같은 챠트를 이용해, 현재 내가 얼마나 일하고 있는지.. 그리고 앞으로 또, 얼마나 일해야 맡은 일을 완료 할수있는지 추정하고 있습니다. 그래프를 보시면, 이번 스프린트5 에서는 지난 스프린트와는 다르게 기간을 3주로 잡았습니다. 물론 3주로 잡은 나름의 이유는 있었죠. 여하튼, 빨간 가이드 라인과 녹색 그래프가 거의 비슷하게 일치하는 매우 준수한 그래프입니다. 평균 개발속도는 4~5를 왔다갔다 하