watist's blog ... I am interested and passionate in building software.

회사에서 일이 많고 시간이 없어지면 서로가 서로에게 소홀하게 되고 상처를 주기 쉽게 된다. 위에서 아래로 일은 끊임없이 내려오고, 사소한 잘못에 대한 지적은 계속 되고. 잘 해보자는 분위기보다는 질책과 추궁의 분위기가 퍼진다. 지시한 업무에 대한 친절한 설명은 이미 바라지도 않는다. 정확한 지시사항과 제대로 된 기획서를 바라는 것도 사치가 되어, 불명확한 지시사항에 여기저기 문제 투성이의 기획서가 배달된다. 서로가 시간에 채여 제대로 업무를 마무리 하지 못한채 아래로, 옆으로 업무만 전달 되고, 결국 마지막에 가서 제대로 되는 일은 하나도 없다. 서로를 도우면서 잘 해 나가면 좋겠지만, 시간적인 여유가 없는 상황에서 마음의 여유를 찾기는 힘들다. 시간적인 여유를 갖아야 한다는 것은 결코 일찍 퇴근해서 가..

난 욕심이 많다. 정말정말 크게 성공해서 지긋지긋한 "일"을 끝내고, 행복하고, 즐거운 "일"만 하고 싶다. 그리고 그 방법 중에 하나가 IT창업이라는 생각을 한다. 근데 생각해 보면 빠방한 조직과 자금을 갖춘 곳에서도 달성하지 못하는 것을 돈도 없고, 사람도 없고, 협력 업체도 없는 상태에서 맨주먹으로 성공을 이룰 수 있을까 하는 의문이 든다. 물론 조직 차원에서 아이디어를 채용하지 않을 수도 있지만, 아이디어만으로 성공하길 바라는 것은 너무 유아스럽지 않나?? 조직도 되고, 자금도 되고, 협력 업체도 되는 곳에서 성공해야 한다. 그 성공의 열매가 나에게 온전히 오지 않는다고 해도 그런 성공의 경험이 다음 성공의 발판이 될 것이다. 아이디어는 조심스럽게 키워가도 된다. 지금은 훌륭한 아이디어보다 성공의..

1. Custom Control 제작시에 추가되는 properties에 atrribute를 추가해서 VS2005 IDE에서 자동으로 표시되게 한다. 2. InputCheckBoxField에서 일반적인 초기화는 base에게 위임하고, cell의 control이 없는 경우에만 처리하는 sense~~ 3. web resource를 사용해 js 등의 파일도 dll에 포함한다. 4. XML 파일로 관리하는 app config - xml로 설정 - project properties에서 설정이 가능 - config 정보에 대응하는 class-property가 필요하다. 이는 system.configration... 을 상속받아 구현한다. - configuration manager class를 사용한다. ** MMS ..

- 정규화 1) 성능을 높이고, 사이즈를 줄인다. 2) 반드시 정규화해라 3) 종속성(determinant. primary key)을 마음대로 상상하지 마라. - DB 모델링의 두 가지 방법 1) 양식지에서 모든 항목을 뽑는 방법 2) 업무를 분석해 테이블과 관계를 작성하는 방법 -> 어느 방식을 사용하든 "정규화"가 중요하다. - 정규화의 이점 1) 분리하면 먹는 메모리가 준다. 2) 분리하면 인덱스를 잘 탄다. 3) 분리하면 교착상태를 회피한다. 4) 분리하면 읽어야 하는 block을 줄인다. -> super type에서 row를 줄여 subtype에서 읽어야 하는 row를 줄인다. - 비정규화 1) 업무비중을 따라서 진행한다. 2) view를 사용한다. ps.. 트리거가 느리다는 것은 잘못된 상식이..

내가 좋아하는 것은 상자와 서랍이다. 내가 이것들을 좋아하는 이유는 그것들이 물건을 정리하는 데 좋기 때문이다. 난 청소를 좋아하진 않는다. 단지, 정리된 상태를 좋아한다. 한줄로 나란히 맞춰진 책상. 주름이 나란히 나있는 청주름치마. 차곡차곡 잘 쌓여 있는 A4용지. 크기는 다르지만 빈틈없이 쌓여 있는 상자들. 어느 하나 흐트러짐 없이 내용물이 잘 들어 있는 서랍 등이 날 기분 좋게 한다. 내가 되고 싶은 것은 많다. 책을 좋아하니까 책을 많이 읽을 수 있는 도서관 사서가 되고 싶다. 그리고 지적인 내용으로 가득찬 교양있는 책을 쓰는 작가가 되고 싶다. 또 그림 그리는 것을 좋아하니까, 그림을 잘 그리는 사람이 되고 싶다. 이 것들을 하나로 합치면 "도서관을 지키며, 그림을 잘 그리는 작가"가 된다. ..

이런 우화가 있다. 두 개발 그룹에게 프로젝트 기간을 정하고 주어진 기간 안에 소프트웨어 개발 프로젝트를 주었다. 첫째 그룹을 즉시 열심히 코딩을 시작했다.둘째 그룹은 매일 만나서 회의만 하였다. 회의에서 서로 의견 충돌도 많다. 중반부에 이르렀다. 첫째 그룹은 거의 다 끝냈다고 했다. 둘째 그룹은 프로그램은 한 줄도 없고 회의만 계속하였다. 후반부에 이르렀다. 첫째 그룹은 갑자기 회의가 빈번해져다. 회의도 심각해졌다. 서로 내가 맞느니 네가 맞느니 하며 종일 싸웠다. 그 와중에도 프로젝트를 완수해야 했기에 여기저기 고쳐가면서 밤새워 일해서 적당히 땜빵으로 넘길 수 있게 겨우 마무리하였다. 겉으로는 문제없는 것처럼 보이나 서로 불안한 마음을 감출 수 없었다. 속으로는 언제 터질지 모르는 시한 폭탄이 남아..

- 사람의 심리는 참 미묘하다. 내가 마음을 놓을수록, 넘겨주는 책임과 권한이 클수록 상대방은 더 조심하게 된다. 왜냐하면 전체 프로젝트의 성패를 자신이 모두 책임져야 하기 때문이다. 그는 절대 속임수를 쓰거나 수작을 부리지 못한다. 이와 반대로 상사가 간섭을 많이 할수록 부하직원은 쉽게 자포자기할 수 있다. 그 직원은 "어차피 내 의견은 받아들여지지 않고, 상사의 의견대로 일이 진행될 텐데, 뭘..., 그리고 혹시 나중에 문제가 생겨도 그것은 어차피 그가 해결할 것이므로 나와는 상관없는 일"이라고 생각하게 된다. p114 - 절대 당신의 오너와 논쟁하려고 하지 말라. 회사가 그의 통제하에 있는 동안엔 모든 결정권은 그에게 있다. 오너에게 "나를 믿어라. 당신은 손떼고 내가 일을 처리하도록 하는 게 옳다..

개발 방법론을 학습하다 보면, 모든 것의 기본은 시나리오라는 생각을 갖게 된다. 잘 쓰인 시나리오는 단어를 뽑아 냄으로써, 용어 사전이 되고, 이를 규칙에 맞게 정리하면 테이블 정의서가 된다. 또, 항목별로 정리하면 요구정의서가 되고, 화면으로 정리하면 화면 정의서가 된다. 이렇게 나온 각종 정의서들은 설계 단계와 코딩 단계에 참조가 되고, 마지막 테스트 단계에선 평가의 기준이 된다. 근데 시나리오보다, 글 보다 이미지가 더 전달력이 강력하다는 생각때문에 화면 정의서가 시나리오를 대신하게 된다. 시나리오에 화면 정의서가 부가 되는 것이 아니라, 시나리오는 없고, 화면 정의서만 남는다. 그나마 화면 정의서의 여기저기에 설명들이 달려 있으면 다행이지만, 정말 화면들만 있는 화면 정의서는 대응하기 힘들다. 일..

작은 꼬투리를 잡고 큰 그림을 놓치는 경우가 있다. 1) 일이 마무리되기가 무섭게 작은 꼬투리를 잡고 늘어지는 사람들이 있다. 2) 전체적인 흐름은 보지 않고, 절자, 이미지, 정열부터 보는 사람들이 있다. 디테일을 챙기는 것과 꼬투리를 잡는 것은 다르다. 디테일까지 잘 하는 것은 일의 성공에 중요한 요소이다. 하지만, 중요한 요소 중에서도 디테일은 일의 성공의 주(핵심)는 아니다. 디테일은 챙겨야 하지만, 디테일이 주가 되면 꼬투리가 되는 것이다. 이렇게 조그만 문제를 크게 하는 잘못을 범하면, 1) 일에 대한 평가가 적절히 내려지지 못하고, 2) 이때문에 작업자들의 의욕이 떨어지며, 3) 결국 일의 성공을 방해한다. 결론은 강력한지, 근거는 충분한지. 전개의 흐름은 타당한지를 봐야 한다. 전혀 핵심이..

- 책(冊 책 책) (옛 서적의) 책으로 맨 것을 세는 단위. 예) 전 102책으로 된 중종실록./권 7에서 25까지를 4책으로 영인하다. - 권(卷 문서 권) (전집 등) 여러 책으로 된 책의 차례를 나타내는 말. 예) 3권에 수록된 내용 - 편(篇 책 편) 책의 내용을 일정한 단락으로 크게 가른 한 부분. 예) 제1편.복잡하다. 편과 책이 모두 책으로 풀이 되는 것이나, 권을 설명할 때 여러 책으로 된 책의 차례라니ㅡㅡa 나름대로는 책 > 권 > 편으로 정리하기로 했다. 정확한지는 모르겠다~~ 궁금하지만, 귀찮아. 정답이 뭘까??이런 쓸데없는 지식인도 있고, http://k.daum.net/qna/view.html?qid=0FKY5나름대로 수긍은 가지만, 딱 떨어지지는 않는 내용도 있다. http:/..