[카테고리:] 컴퓨터

이 프로그램은 AutoHotkey를 사용해야 한다.




이 프로그램의 최대 문제점은 한번 클릭했는데 숫자가 5에서 10정도 쑥쑥 올라간다는 것이다. 아무래도 while 문이 한번 클릭할 때 여러번 작동하는 것 같다. 이 문제를 해결하거나, 아니면 VC++에 MFC를 써서 새로운 프로그램을 만들어야 한다.




다음의 문서를 참고해야겠다.




http://visual-c.itags.org/visual-c-c++/85168/




http://msdn.microsoft.com/en-us/library/3158baat%28vs.71%29.aspx




http://www.databaseforum.info/29/1038446.aspx

결국 count.exe 프로그램을 한번 실행시킨 다음에 2초동안 재워버렸다. 2초 내에 2번 클릭하는 일은 절대 없을 것이기 때문이다. (이 프로그램의 용도는 특수 목적이기 때문에 2초 내에 2회 이상 클릭하는 일은 없어야만 한다.)

역시, 시험기간에 딴짓을 해야 효율이 좋다. ㅋㅋ

젠장. -_-; 내일 5과목 시험보는데 프로그램 만들고 앉아있다.

gcc에서 잘 컴파일 된다.

더 이상의 설명은 생략한다.

일단 Autohotkey를 이용해서 특정 영역에 마우스 클릭이 있으면, counts.txt 파일에 숫자 0을 기록한 후 Counting.exe 프로그램을 호출한다.

Counting.exe 프로그램은 호출 될 때마다 counts.txt 파일을 읽어와서 그 파일에 기록된 숫자에 1을 더한 후 다시 그 내용을 counts.txt 파일에 기록한다.

counter.exe 프로그램은 원격에 있는 counts.txt 파일을 네트워크로 읽어온다.

counter.exe 프로그램은 그동안 전체 클릭이 몇번이었는지 기록했다가, counts.txt 파일에 기록된 숫자를 최종 클릭 수에 더해서 전체 클릭 수와 오늘의 클릭 수를 화면에 표시한다.

간단한거 하는데 이런식으로 설계해야 할줄은 꿈에도 몰랐네. -_-;

아키텍처 설계의 중점사안.

1. 화면 영역에 마우스 클릭을 검출하는 루틴 설계는 할 생각 없음. 절대 없음.

2. 마우스 클릭이 있을 때 원격지로 신호를 보내서 카운트를 올리도록 하는 클라이언트-서버 프로그램을 만들 생각 없음.

이제 코딩만이…

int n=0;

위와 같이 선언되어 있다고 하자. 그럼

n++;

이렇게 하면 n=n+1; 이 실행된다.

++n;

이렇게 해도 n=n+1; 이 실행된다.

뭔 차이냐…라고 묻는다면, 아주 작은 차이가 있다. 우선, 최종적으로 n=n+1;이 실행된다는 점에는 변화가 없다. 하지만 다음과 같이 써먹을 수 있다.

int m;

일단 이렇게 하나 선언하고나서

m=n++;

위와 같이 써먹으면, 그 문장은 다음과 같이 작동한다.

m=n;

n=n+1;

하지만 다음과 같이 쓸 수도 있다.

m=++n;

이 문장은 다음과 같이 작동한다.

n=n+1;

m=n;

별 차이 없어 보이지만, 결과적으로 m에 대입되는 값이 달라진다. ++이 n의 뒤에 붙어있을 때는, 일단 대입하고나서 n에 1을 더한다. 따라서 m에는 n보다 1이 작은 값이 들어가 있게 된다. 하지만 ++이 앞에 붙어있을 때는 일단 더하고 나서 대입한다. 따라서 m과 n은 같은 값을 갖게 된다.

이 사소한 차이는, 매우 사소한 차이지만 프로그램을 만들 때 그 결과에 큰 차이를 갖고 오게 된다. 실제로 프로그램을 만들 때 어떤 변수에 +1을 할 일이 굉장히 많은데, 쓸 때마다 한번씩 고민하면서 써 보자. 아무 생각 없이 쓰면 틀린다.

참고로, -1을 해주는 연산자도 있다. 예상했다시피 –이다. 작동방법과 사용방법은 ++과 동일하다.

그럼 **은 뭐냐고? 음…x1을 해주는 연산자라고 생각할 수도 있겠지만 아쉽게도 이중포인터 연산자이다. C++을 만든 사람들도 **의 용도에 대해서 고민하다가 1을 곱하는건 수학적으로 아무 일도 하지 않는다는 것을 깨닫고 다른데에 써먹었을 것이다. 그리고 //도 있다. 이것 역시 1로 나누는 연산자였으면 좋겠지만 **과 마찬가지 이유로 다른 용도로 쓰인다. //뒤에 쓴 문장은 그 줄이 끝나는 부분까지 전부 아무것도 실행되지 않는다. 즉, 프로그램에 설명을 달고 싶을 때 쓰면 된다. 아니면 그 줄을 실행시키기 싫어졌다면 제일 앞에 //을 붙이면 된다.

글꼴에 걸려 있는 파일 보호를 제거한다는 업데이트다. 뭔지는 모르겠지만, “중요”하다고 되어 있고 “권장 업데이트”에 해당한다. 그런데, 이 업데이트는 오피스2010 설치 관리자가 글꼴을 업데이트 할 때 필요하다고 한다. 난 오피스 2010을 이 컴퓨터에서는 앞으로 쓸 생각이 없다. 즉, 나한테 아무 쓸모없는 업데이트라는 뜻이다. 게다가 그런 주제에 이 업데이트를 설치한 후 컴퓨터를 다시 시작해야 한다.

운영체제에 버그가 있지만 오피스2010에서만 발생하는 문제라면, 이 패치는 오피스2010의 배포판 또는 오피스2010의 업데이트에 포함되어야 한다. 만약 그렇지 않다면 이 패치의 설명이 부족한 것이다. 더군다나 MS오피스는 MS윈도우즈가 아니면 사용할 수 없는 프로그램이다. 따라서 오피스2010에 이 패치가 포함된다고 해서 전혀 문제될 것이 없다. (설령 MS오피스가 리눅스, 맥OS등의 다른 운영체제에서 작동하는 것을 지원한다고 하더라도 이 문제는 윈도우즈 비스타와 오피스2010을 썼을 때만 나타나는 문제이므로 오피스2010의 윈도우즈 버전 패치에 포함되어야 한다.)

http://support.microsoft.com/kb/980248

그래서 추가정보를 찾아봤다.

뭘 해야 하는데 권한이 없어서 못한다는 문제가 있다. 그래서

글꼴 파일의 “속성”을 바꾸는 업데이트다. 뭔가 내용을 바꾸는 것도 아닌데

나는 반드시 컴퓨터를 다시 시작해야 한다. 한글판이랑 내용이 다르잖아-_-; 한글판은 컴퓨터를 다시 시작해야 할 수도 있다고 했다(You may restart the computer). 이것은 다시 시작하지 않아도 괜찮을 수 있다는 뜻이다.

그리고 겨우 파일 속성 바꾸는데 컴퓨터를 다시 켜야 한다는 것은, 파일 속성이 굉장히 중요한 시스템 속성에 해당한다는 뜻이다. 운영체제를 어떻게 만들면 내용이 바뀌는 것도 아닌 속성 변경 때문에 시스템을 다시 로딩해야 하는지 잘 이해가 안된다.

리눅스는, 그냥 루트 권한 갖고 덮어쓰면 된다. 맥OS도 비슷할 것이다.

이것은 그러므로 어처구니없는 업데이트라 하겠다. 물론 자기들이 만든 프로그램에 문제가 생겼고 그 문제에 대한 해법을 찾아내서 사용자들에게 제공한다는 것에 대해서는 MS개발자들의 고생을 생각해 줄 수 있지만, 사용자 입장에서 이런 말도 안되는 버그를 운영체제 수준에서 고쳐야 한다는 것은 참 답답한 노릇이다.

그래서, 소개해 보자.

우선, 폭포식 방법이 있다. 이건 밥을 짓는데

1. 몇인분을 지을 것이고, 쌀은 얼마나 넣어야 하고, 물은 얼마나 넣어야 할지 정한다. 쌀과 물의 양을 정확히 알기 위해서는 많은 경험이 필요하지만 실제로 그건 곤란하다.

2. 밥을 짓기 위한 요구사항을 정확히 분석한다. 밥에 어떤 성분들이 들어가야 하는지 고객의 요구에 맞춰서 분석해야 한다. 보리밥을 원하는지 현미밥을 원하는지 흰밥을 원하는지.

3. 밥을 어떻게 할 것인지를 생각한다. 우선, 전기밥솥으로 할건지 가스밥솥으로 할건지 가마솥으로 할건지 파악한다. 물은 생수를 쓸건지 수돗물을 쓸건지 정하자. 쌀을 얼마나 불릴 것인지도 정해야 하고, 밥솥에 사용할 메소드로 압력솥을 쓸건지 그냥 끓일건지 아니면 쪄낼건지 정해야 한다.

4. 밥을 한다.

5. 밥맛을 본다.

6. 준다.

이 방법은, 한번에 많이 할 때 써먹을만하다. 그리고 일단 해놓은걸 물리기 없이 그냥 내놓을 수 있을때 가능하다. 단점은, 밥맛에 대한 피드백이 불가능하기 때문에 맛 없어도 복불복.

이 방법을 조금 개선해서 V자형 방법이 있다. 이것은 폭포식 방법을 그대로 따라가는데, 여기에 추가적으로 밥맛을 보고 맛없으면 다시 하는 과정을 포함한다. 물의 양이 적절한지 계속해서 검증하고, 불린 시간이 적절한지 계속 검증하고, 밥짓는 방법이 적절했는지 계속 검증한다. 각 단계별로 검증해서 최종적으로는 맛있는 밥이 완성된다. 이것은 다른 조건보다 “맛있는 밥”이라는 절대적인 목표를 달성하기 위한 경우에 적절하다.

일정 중심의 모형도 있다. 이건 폭포식 방법을 따라서 밥을 짓는데 중간에 그냥 내놓는다. 밥을 하기 위해서 필요한 요소들 중에 우선순위가 높은 것들을 일단 만족하다가 밥때 되면 그냥 내놓는 것이다. 가령, 현미에 생수를 쓴 압력밥솥에 한 밥을 하고 싶다고 하자. 그리고 우선순위를 현미, 생수, 압력솥 순서대로 정해져 있다고 하자. 근데 현미랑 생수가 있는데 압력솥이 제작중이다. 당장 밥은 먹어야 하는데 압력솥이 올 때까지 기다리려면 그 전에 굶어죽을수도 있다. 따라서 일단 있는 걸 갖고 밥을 해서 내놓는다. 이것은 “밥때는 절대로 놓치면 안된다”는 목표를 달성할 때 적절하다. 우선순위가 높은것부터 해결하는 방법이다. 다만, 나중에 압력솥이 오더라도 이미 밥을 먹은 상태기 때문에 압력솥을 괜히 주문했다는 아쉬움은 남을 것이다.

프로토타이핑 모형을 쓸 수도 있다. 쌀을 적당히 불려서 하얗게 만들어 놓고 밥그릇에 담은 후 “이정도의 밥이면 됩니까?” 물어보는 것이다. 폭포수 방법과 다른 점은, 밥이 별로 맛이 없어 보이면 이것저것 바꿔볼 수 있다는 것이 장점이다. 다만, 밥먹을 사람이 “오오, 이정도면 이제 밥은 금방 나오는거지?”라고 착각하게 될 수 있다는 점이 문제다. 그리고 때깔만 좋은 밥을 보고 맛도 좋을 거라는 착각에 빠질 수 있다는 점이다. 밥이 맛있을지 없을지 불안할 때 사용한다.

점증적 모형은 밥을 조금씩 하는 방법이다. 일단 밥을 해서 내놓고, 점점 더 많은걸 추가한다. 쌀밥을 내놓고, 현미밥을 내놓고, 잡곡밥을 내놓는 방식이다. 일단은 밥을 먹일수 있다는 점에서 애자일하다고 할 수도 있다. 교재에서 나중에 나온다고 하는 익스트림 밥짓기 방법과 유사하다고 한다. 배고프다.

나선형 모형은 밥짓는 과정에 숨어있는 위험요소를 찾아내서 미연에 방지한다. 가령 압력솥이 밥짓다가 터질 수도 있는데, 그걸 방지하기 위해서 그냥 냄비에 밥을 할 수 있다. 이것은 밥짓기가 실패할 수 있는 위험을 사전에 막는 방법이다. 그리고 일단 밥을 해서 성공한 후, 압력솥을 써서 다시 성공시킨다.

진화적 밥짓기 모형은 일단 밥을 내놓은 후 밥먹는 사람의 반응에 따라 빠르게 밥을 새로 지어서 바꿔주는 것이다. 프로토타이핑이랑 비슷할 수 있는데, 프로토타이핑은 먹기 전에 일단 대충 겉보기에만 좋게 만들어 놓고 나중에 밥을 해주는 것이고, 진화적 밥짓기는 일단 먹여보고 반응을 살펴서 그 다음의 밥짓기에 반영한다는 점이 다르다.

자, 이제 당신도 맛있게 밥짓기를 할 수 있다.

2시간동안 다운로드 받고, 2시간동안 패키지 설치하고, 1시간동안 패키지 지우더니

재부팅하고나서 시스템 사망했다.

예전에 구워둔 CD로 복구모드로 들어가서 파일은 백업 받았는데

역시 리눅스도 포맷이 진리인가 -_-;

4월 29일까지 기다릴걸 그랬나 하는 생각이 들지만, 그럼 겨우 7일 후에 훈련소 가는걸;

—————–

추가

일단 포맷했다. Ext4가 문제인 것 같아서 Ext3으로 했다. 어쨌거나 예전에 쓰던 자료는 다 날아갔다.

그냥 새로 포맷해야겠다. 이번엔 꼭 home 파티션은 따로 나눠둬야겠다.

부팅이 20초밖에 안걸린다. 꽤 오래된 맥북인데, 겨우 20초면 부팅이 완료다.

(맥북을 끄지 않고 뚜껑만 덮어서 절전모드로 들고다니는 이유는 켤 때 나는 소리가 너무 커서 부끄럽기 때문이다. 적어도 나는 그렇다.)

소리만 없었어도 그냥 껐다 켰을 것 같다.

좀 더 빨라진 것 같다.

나머지는 좀 더 체험해 보고…