~~ Tales Of Kalstein ~~

find 사용법좀 찾아보다보니...
find utility의 철학 요런 글을 발견.
*nix쪽 유틸리티들은...잘 쓰면 좋긴한데...그 잘 쓰기가 참 쉽지않은게 문제 하하하 -ㅁ-;;;
--help 해서 보이는건 극히 일부분이고 (물론 그것만 써도 잘 쓸수있을지도...) 좀 깊게 보려면 man page를 봐야하고, help로 보이는건 거참...불친절하다 ㅎㅎㅎㅎ
그래도 어쩌리...목 마른 사람이 우물을 파야지. 그리고 원래 *nix쪽은 저래왔는걸~~ 내가 익숙해지는 수밖에.

반면 GUI OS 환경에서는 쉽게 다가서기는 좋은 반면...cmd line 기반이 아니라서 자동화하기에는 좀 빡센 측면이 있다. 뭔가 잘 아는걸 하려면 '에이....뭘 이리 클릭질(;;)을 많이 해야되는겨?' 라는거지 ㅎㅎㅎ

command line에 보다 익숙해지기를 바라며...(CUI라고들하지요~)


ps : 근데 이거 링크가 있는 글귀는 글자색을 넣을수가 없네...ㅡ.ㅡ;; 왜그러지?;;;

생각을 깊게하면 좀 더 난이도를 낮출 수 있다!!

요즘 회사서 기존 소스코드를 분석하고 있는데...수백줄이 각종 for 문으로 왔다갔다 하는 부분이 있었다. 이거 뭐이리 복잡하나...싶어서 봤더니. 결국 찾아내고 싶은 값은 하나. 각종 전역변수들을 들락날락 했던 이유는? 관계된 값을 찾을 때, index값을 이용하기 때문이었다.

즉 간단히 말해서는 RDB의 모습이었다는것. 뭐 취지는 좋다. index 기반이니까 배열으로써 바로 접근이 가능하니까. 속도면에서도 그럭저럭 쓸만할테고...메모리량도 적게먹을테고. 그러나... 코드가 너무 지저분하며, 검색시에는 해당 값으로 정렬되어있지않기 때문에 무조건 for문을 이용해서 linear하게 찾을 수 밖에 없다. 게다가 테이블에는 유일한 값이 있는것이 아니라 중복값이 있을 수 있다. 즉 for 문 안에서 1번 조건을 만족 하더라도, 2번조건에 부합되지않으면 마저 돌아야되는것. 이러다보니 소스코드가 좀 너저분하고 분기문이 많아진다.

찾는 값들을 살펴보니...3비트, 2비트 길어봐야 16비트 정도의 값이다. 다 합쳐보면 32비트 미만일 듯 싶다. (찾는 값들은 key값들로 볼 수 있고, 나머지 value 값들도 존재함) 이럴 때 사용할 수 있는건 뭔가? DB에서 사용되는 BITMAP Index 를 사용할 수 있지않을까. 그러면 검색하고 싶은 조건을 한번에 32비트안에 다 집어 넣을 수 있을테고 (SQL문의 where 절이 되겠다.) 총 entry 개수만큼 iteration만 하면 100% 검색이 가능하다.

총 entry는 너무 많다고? 그럴수있다. 지금 내가 참여하고있는 프로젝트는 소형 기지국 Femto cell 쪽 SW인데 여기는 총 8명 user에다가 각 유저당 8개의 entry를 가진다. 그럼 여기선 64개의 iteration을 가지지만 64명의 user를 지원한다면? 128번의 iteration이다. 제법 많아지게 되는것이지. 그럴경우? 그럼 유저당 검색을 별개로 할 수 있도록 partitioning을 하면 되는것. 그럴경우 256명을 지원한다고 해봐야 메모리는 좀 더 잡아먹을 수 있겠지만 (그나마도 dynamic allocation을 활용하면 극도로 효율적인 운영이 가능하다.) 속도는 MAX 8번의 iteration만으로 가능해진다.

코드도 보기 좋아지고, 속도도 빨라지고...이 얼마나 좋을소냐. 제발 생각좀 하자...생각좀...

ps : 뭐 사실...생각의 부재라기보다는...Data Structure에 대해서 깊게 공부하는 사람이 없어서 더 이런 문제가 있는 것 같다. 프로그래밍의 가장 중요한 요소인데 말이지...쩝.

ps2 : 어찌보면...DB의 역정규화와 상당히 동일한 작업이다. storage는 조금 더 쓰는 방향이 될듯. (entry들의 사이즈가 작아서 큰 문제는 없다)

From "밤새지 맙시다!"

정말 밤새면 뭐가 문제되는지 실례로 보여준달까;;;
특히나 인상깊었던것은 리플중 하나.

----- 인용 시작 -----
"사람들이 초과 근무를 하는 이유는 과제에 주어진 시간 안에 끝마치기 위해서라기보다는, 일을 정해진 시간까지 끝마치지 못했을 때 비난받게 될 것을 우려해 자신을 보호하기 위함이다" 라는 피플웨어의 얘기가 생각납니다.
----- 인용 끝 -----

피플웨어...도서 이름같은데? 한번 읽어봐야겠구낭...
실제로 OT(OverTime)하는 대다수의 이유는...

1. 위에서 시켜서
2. 능력이 시간에 맞출정도로 대단치 않아서
3. 집에 가기 싫어서

정도가 아닌가. 여기서 1-2번은 관리자의 잘못이고(2번의 경우는 실력도 모른채 일을 맡겼다는 거니까. 일하는 사람의 노력을 안했을수도 있긴하다 ^^;;) 3번은...뭐 집에 가서 애보기 싫거나 그런거지 ㅡ.ㅡ;;;