'분류 전체보기'에 해당되는 글 256건

  1. 2007.11.25 '프로젝트 자동화'에는 ant와 log4j는 얼마 안들어 있다. [ANT Log4J]
  2. 2007.11.24 중급 개발자가 고급 개발자로 가기 위한 서적!! [refactoring java] 2
  3. 2007.11.22 [sample] Action안에 thread 생성하기
  4. 2007.11.22 프로젝트 과정/결과는 유토피아를 향한다!! [소프트웨어 생존전략]
  5. 2007.11.21 2007 동경 국제 로봇전 참가
  6. 2007.11.21 리스크는 이익이 되어 돌아옵니다. [리스크 관리] 1
  7. 2007.11.20 데몬 위치 찾기
  8. 2007.11.20 professional소프트웨어개발 [소프트웨어 개발]
  9. 2007.11.20 create database 와 연계된 작업
  10. 2007.11.19 alias 추가 / 편집


정말 오래간만에 서평을 쓰게 된다.
한동안 개발에만 열을 올렸더니 책을 볼 기회조차 허락되지 않았다.
지난 실용주의 서적에 대한 Junit에 관한 서평을 쓴 이후로 '실용주의'에 관한 관심이 쏠려
3번째 서적인  "프로젝트 자동화"에 대하여 이야기를 해보려고 한다.
제1편 CVS와 제2편 junit까지 정말 구독자의 기분은 상쾌하게 만들어줬던 실용주의 마지막 3번째는
과연 얼마나 기분좋게 할것인가 기대하는 맘으로 읽기 시작 했다.
결과부터 이야기 하자면 서평자는 주소를 잘못 잡고 있었다.
 
'프로젝트 자동화'가 말하는 것은 표지에 디자인 'ANT&log4j'에 대해서 크게 말하고 있지 않다.
만일 'ANT&log4j' 를 위해서 본 책을 기대에 부풀어 사보게 된다면 약간의 실망을 감내 해야 할 것 이다.
ANT는 깊이가 있어질려다 말았고 log4j는 후반부에 5페이지 정도 분량으로 밖에 소개되고 있지 않다.
정말 'ANT&log4j'에 관해서 알고 싶다면 본 책의 역자가 추천하는 서적
'Java Development With Ant (자바의 또 다른 멋진 도구 Ant 앤트 )'를 보았으면 한다.
 
서평자는 헛된 기대에 책을 보고 예상했던 내용이 크게 부각되지 않아 조금 당황스러 웠다.
이유는 책을 모두 다 보고 책 표지를 다시 보니 불연듯 책 타이틀을 보니 책은 정말 제목데로 만들어 졌다.
'프/로젝/트/자/동/화'
그렇다. '프로젝트 자동화'가 추구하는것은 프로젝트를 자동화하하기 위하여 필요한 ANT, CVS, log4j, ... 등등과 같은
프로젝트 자동화를 위해 사용될 수 있는 도구들을 적절하게 활용된 사례를 기술해 놓았다.
 
실질적인 프로젝트(DocumentManagement System)를 바탕으로 ANT와 CVS, 그리고 5페이지로 언급된
log4j를 사용하고 있는것이다.
 
책 제목은 책 내용을 완벽하게 커버하고 있다.
서평자처럼 "디자인된 표지에 속아 ant는 이정도 깊이인가? log4j는 겨우 5페이지라니.. " 하는 실망감을
가지지 않았으면 좋겠다.
 
자 이제 책 내용을 살펴보도록 한다.
 
● 빌드 (Build) & 릴리즈
책은 미국문화에 이해가 가장 쉽도록 ant를  설명하고 있다. '크루즈컨트롤러' 가 그 예인데 크루즈컨트롤어의 의미는
책 85p에 언급되어있지만 우리나라 문화라면... 아마 리니지 AutoMouse가 아닐까 하는 생각도 해본다. ^^
여하튼 ant의 주된 역할은 프로젝트 진행에 있어 그 어떤 작업환경에서든 동일한 결과를 도출해 낼 수 있도록 하는
"빌드(Build)"에 관점이 기울어져 있는것있다.
 
책이 DMS 기반으로 있기 때문에 ANT의 깊고도 복잡 다단한 부분까지는 접근하지 않고 있다.
아마 불필요하기 때문일것 같고 정말 실전에서 쓸수 있는 것만 '프로젝트 자동화'에 다룬것 이라고 볼 수 있다.
 
 
● 디플로이
디플로이 부분은 여태 내가 디플로이하는 방법보다 보다 효과적이고 강력한 디플로이 방법을 이야기 하고 있다.
단순 ANT로 소스코드를 운영에 반영하고 시스템을 한번 내렸다 올리는 손이 많이 가는 (하지만 내가 지금 그렇게 하고 있는..)
방법보다 더 아름다운 디플로이 방법을 이야기 하고 있다.
 
● 모니터링
서평자는 WEB개발자이기 떄문에 모니터링은 콘솔상에서 쌓여가는 로그파일을 보는게 모니터링 기법이라 생각했다.
하지만 '프로젝트 자동화'에서 말하는 모니터링은 이보다 보다 시각적이고 보다 직관적이다.
여기에 log4j는 모니터링의 한 부분으로써 소개가 되어지고 있다. (그러니 5페이지 될 수 밖에...)
 
 
ant나 log4j는 '프로젝트 자동화'의 한 부분이다.
오히려 본 책은 실용주의 서적 제1편이 말한 CVS의 재 언급이 "오호 이렇게 연결이 될 수 있겠구나" 하는 발상을 가져다 준다.
 
표지만 보고 헛된 기대는 하지 말자!
ANT와 log4j는 함량 미달이다. 하지만 '프로젝트 자동화'는 정말 프로젝트에서 필요한것만 담았다.
ant도 log4j도 cvs가 프로젝트에 어떻게 적용되고 어떻게 사용되는지  다양한 기법들을 담았기에
학문으로써가 아니라 /사/용/할/목/적/으/로  본 책을 접한다면
실용주의의 결정판! 그 '프로젝트 자동화' 가 실망스러움이 아닌 다양한 아이디어를 줄 것이다.
 
서평이 끝났다.
서평자가 보기에 이책이 프로젝트에 필요한 이유는 아래인것 같다..
 
----------------------------------------------------------------------------------------
코드가 길면 길수록 코드를 제대로된 상태로 유지하기 위하여 계속되는 통합의 작업이 더 절실하게 필요하다.
              '프로젝트 자동화 98p'
----------------------------------------------------------------------------------------


중급 개발자가 고급 개발자로 가기 위한 서적!!
 
refactoring java는 프로그램을 짜는 방법이 들어가 있다.
메소드를 선언하는 방법 sub메소드를 만들어 내는 방법, 그리고 그 sub메소드를 호출하고 관리하는 방법..
너무나 고맙게도 고급개발자 (마틴파울러)는 본 서적을 통해 고급! 바로 그들만의 리그에
중급 개발자들을 참여시키고자하는 다분한 의도를 가지고 있다.
 
refactoring java는 이미 많은 서평자들이 엇갈린 의견을 내 놓은것처럼
"해도 그만 안해도 그만" 에서 부터 "꼭 해야하는것!" 하는 다양한 의견을 나타내고 있다.
그도그럴것이 잘 구동되는 소스코드는 건드리지 않는다! 라는 전재 하에서 본 서적은 이야기를 시작 하고 있다.
 
그럼? 잘 구동되는 소스코드를 뭐할려고 건드리는가?
이문제에 답은 refactoring은 누구를 위한 것인가? 라는 질문이 더 잘 어울린다.
refactoring 은 관리자도 스폰서도 위한 작업이 아니다.
refactoring 은 순수 프로그래머들을 위한 작업이다.
 
프로그래머들은 많은 위험에 노출되어있다.
납기일 준수나,  촉박한 일정에 떨어지는 폭탄과도 같은 요구사항들 그리고 가장 기본으로 요구되는 안정된 운영!!
많은 사람들은 프로그래머를 마치 고장난 자판기마냥 동전 몇개만 넣으면 어러가지 음료수를
한꺼번에 쏟아내는줄만 아는데 안타깝게도 프로그래머들은 자판기가 아니라 사람이다.
 
자.. 훌륭한 사람이기에 쏟아질것 같은 요구사항에 미리 미리 대응해 보자.
잘 구동되는 소스코드도 정리해보도록 하고 확장에 용이하도록 분석과 분해를 해봤으면 좋겠다.
납기일이나 촉박한 일정이 다가올것을 염두하고 선수학습하는 맘으로 구조를 짜 맞춰 보자!!
바로 이런 일들을 진행할때 곁에두고 싶은 참고서가 있다면 서평자는 refactoring java를 추천하는 바 이다.
 
● 구독방법
1. 서문과 도입의 글을 필독한다!
    > 모든 refactoring 의 사상이 담겨져 있다.
    > refactoring을 운운하시는 분들은 모두 서문과 도입을 인용 하는것이니 개발자는 꼭! 봤으면 한다.
2. 첫장 부터 타이핑 해가며 한장 한장 따라 시도해본다.
3. 아주간혹 이해가 안간다 하더라도 그냥 .. 그냥 물흐르듯 보자.
 
자세는 키보드옆에 활짝 펴 두고 글도 보면서 차근차근 본다.
 > 정말 이때는 바둑의 기보를 보는 자세가 요구된다. 내가 앞에서 뭐 했는가를 잊어먹으면 곤란해진다.
 
● 책은 이것보다 훨씬 많은것을 동기유발 시킨다.
refactoring java는 UML기반으로 설명을 하고 있다.
서평자 역시 refactoring java를 보고 자주 등장하는 classDiagram 이나 화살표들이 너무 궁금해 RUP책을 보게 되었다.
궁금증이 해결된것은 아니지만 하나의 학습은 다른 학습을 유도하는 시너지 효과를 발휘하고 있다.
 
refactoring java는 코드네이밍 규칙을 이야기 하고 있다.
프로그램 만드는데 작명과 워드랩을 하는 수준은 깔끔과 명확성을 가지고 있다.
refactoring이 전부 내것이 되지 못하더라도 깔끔한 소스코드를 만드는 보너스 팩은 받아누릴 수 있을것이다.
 

사실 서평자는 2003년도 같은 회사 직원 한사람이 이 책을 틈나는 데로 탐독하는것을 봤다.
당시 그는 중급개발자였지만 지금은 고급개발자가 되어있고 지금도 멋진 개발자로써 훌륭히 자기일을 하고 있다.
초입에 들어설때도 그는 면티에 훌렁한 반바지를 입고 빡빡머리에 자유분방함을 가졌지만 소스코드는 그런 외모와는 상관없는
향기를 담고 있었고 알수없는 고수(?)의 흔적들을 볼 수 있었다.
그당시 그가 이 책을 그토록 보고 또보고 하는 이유를 몰랐다.
하지만 그 결과는 나타나고 있고 그 향기는 시간이 지남에 따라 더욱 진하게 퍼지고 있다.
꼭! 본 서적이 원인이였다고 볼 수는 없지만 그래도 그런 그의 향기가 가장 배어나오는게 본 서적이라 위의 예를 들어본다.

Action안에서 thread만드는게 뭐 별거인가 싶지만 생서에 있어서 주의사항은
final 이라는점이다.
 

private void importProcess(final int  data) {
try {
 final Thread t = new Thread(new Runnable() {
  public void run() {
   try {
    threadExecute(data);
   } catch (Exception e) {
   }
  }
 });
 t.setName(threadName);
 t.setPriority(threadPriority);
 t.start();
} catch (Exception e) {}
}

private void threadExecute(int  data) throws Exception {
..
}


서평자는 전에 스티브맥코넬리의 서적을 모두 탐독코자 하였다.
이번에 평하고자 하는 서적은 "소프트웨어 생존전략!"
이름도 그럴듯한 Servival Guide 책이다.
 
2005년3월10일에 구입해서 보기 시작해서 오늘까지 봤으니 거의 2주정도 시간이 걸렸다.
소설책류의 2시간에 비하면 어마어마한 시간이 들어갔다.
서평자는 스티브맥코넬리의 깊은 사상을 이해하려하였고 그가 생존전략! 이라는 거창한 이름을
붇인 까닭을 알고 싶었다.
결과를 미리 말하자면 진정 맥코넬리는 프로젝트의 모든 구성원들이 만족하고 행복해하는
유토피아를 본 서적에서 기술해 놓았다.
 
- 스폰서에게는 프로그램이 완성되어져가는 과정을 보면서 자신의 의견을 적용 될 수 있도록 하였고
- 관리자에게는 잘짜여진 틀 안에서 스폰서와 개발자들사이의 훌륭한 PM 이 되도록 하였고
- 개발자에게는 프로젝트 완료후 기술의 스킬UP과 회사에 강한 소속감을 가질 수 있도록 하였다.
 
정말 놀라운 서적이 아닐 수 없다.
스티브맥코넬리는 3인칭 전지적 관찰자 시점에서 프로젝트에 관여된 3계층(스폰서, 관리자, 개발자) 모두 만족시켜주는 가이드를 제시한것이다.
 
하지만 본 서적이 그토록 유명하게된 까닭은 단지 3계층을 커버하는 수준이였다면 그만큼 유명해지지는 않았을 것이다.
서평자가 보기에 SPSG에 투입되고 연관되어있는 방법론과 서적은 실로 방대하다.

스폰서 / 관리자
 > ROI (투자수익률)
 > 피플웨어 (톰디마르고,  티모시 리스터)             
 > 리스크관리 (톰디마르고,  티모시 리스터)
 > Professional 소프트웨어개발 (스티브맥코넬리)

 
개발자
 > Extreme Programming Installed  (론 재프리즈)
 > Junit (데이브 토머스)
 > TDD (캔트백)
 > RUP (개발방법론: 로즈)

기타 등등..
이런류의 서적들을 모두 총 종합시킨 전과목 참고서 수준이다.
한장 한장 넘기면서 "이 주제는 어디서 본것 같은데..." 하는 느낌과 냄새(?)가 난다는 것이다.
피플웨어나 마일스톤의 경우는 (피플웨어,리스크관리)책 냄새가 나고
스모크테스트나 일별 test계획을 세워서 프로토타이핑을 만들어내는것은 (XPI, TDD, JUNIT..)책 냄새가 난다.
 
만일 위에 언급한 사항들을 모두 보신 분들 이라면 썩 이 책이 신선하게 다가오지는 않을것이다.
하지만 구술도 꽤어야 보배라고 모든 단위 항목 학문을 하나로 꾀어내는 능력은 정말 탁월하다고 칭찬할만 하다.
 
스티브 맥코넬리는 프로젝트 진행단계 단계마다 가장 적당한 방법론의 소개, 행동 방법 등을 기술하였고 프로젝트의 규모에 따라 예외사항까지 기술해 놓았다.
제목 그데로 Guide인 샘이다.
얼마나 가능할련지는 모르지만 가능하다면 내가 참여하는 모든 프로젝트에 본 가이드데로 시행하고 싶은 욕심이 생긴다.^^
 
자 책의 서평을 정리하는 뜻에서 중요한 한가지 힌트를 주고 가름하려고 한다.
스티브맥코넬리는 개발자나 관리자가 움직이는 작은 움직임도 돈으로 계산하도록 하고 있다.
Planning Checkpoint Review를 가장 주의깊게 봤으면 한다.
PCR은 책의 논제가 어디로 흩어지든 항상 중심으로 인도하는 몇개의 끈들중에 하나이다.
PCR은 프로젝트 비용의 10~20%를 확보할 수 있고 PCR은 아키텍쳐를 만들어 내는 중요한 레퍼런스이다.
PCR은 요구사항을 개발!! 하는 도구중에 하나이며    PCR은 완료보고서의 멋진 시작이다^^
사용자 삽입 이미지

2007 동경 국제 로봇전 참가!!

> 스폰서 : 한국 로봇산업 진흥 협회 (http://www.kaira.or.kr/)
> 참관기간 : 2007년11월28일 (수) ~ 11월30일(금)
> 장소 : 일본


스폰서 기관에서 지원해주는 본행사를 통해
로봇의 현 주소와 로봇의 다양한 활용사례들을 보고 오려고 합니다.
모쪼록 이번 자리를 지원해준 협회 관계자 모든 분들께 감사드립니다.

특별히 이번일에 팀장님과 정진혁님과 김영옥님께 다시한번 감사드립니다.
※ 팀장님도 계시는데 성함을 알지 못해서 팀장님이라고 말씀드립니다.

아울러 저를 대신해서 펑크난 업무 지원해준 팀원들 고마워요 ^^


리스크 관리를 사보게 되었다.
code Complete책을 보다가 그 방대한 두꺼움에 압박을 당해 가벼운책으로
진정된 마음을 달래보려 빈맘에 리스크 관리를 보게된것이다.
 
책을 접하게된계기는 "리스크관리"의 저자가 전 피플웨어 저자와 동일했기 때문이다.
본 서평자는 책을 마구잡이식 읽기보다는 저자가 생각과 사상을 이해하려고 하기때문에
주로 저자중심의 그룹별 책읽기를 선호한다.
 
"피플웨어"에서 보였던 톰 디마르고와 티모시 리스터는 전화기가 없는 사무실에 훌륭한 사무 환경을
제공함으로써 진정한 개발자와 관리자와의 순수작업공간을 제시함으로써 개발자들로 부터
큰 호응을 얻었다
실제로 복잡한 사무환경과 너저분한 책상에서 깔끔하고 아름다운 제품을 기대하긴 힘들것 같다
   (그래서 필자도 책상을 정리하고 일을 수행하려는 습관을 들이기 시작함^^)
 
다시 본 서적의 원론으로 다가가보자!!
"리스크관리"는 리스크란! 절대 사라질 수 없으며
우리가 원한다고 피할 수 있는 존재가 아니라는것을 인지시키며 시작한다.
직원이 회사를 그만둘 수 도 있고 , 계획이 변경될 수 도 있고, 자금이 딸려 조기 종료될 수 도 있는 다양한 리스크가 있다.
이런 리스크들은 피하는 존재가 아니라 관리의 대상 인것이다.
 
서적 초기에 DIA (Denver International Airport)의  ABHS 구연에 대한 예를 들어주고 있다.
소송관련 컨설턴트인 톰 디마르고와 티모시 리스터는 DIA의 ABHS 프로젝트에 대한 정확히 어디어디가
리스크였고 이 리스크에 대한 책임을 누가 져야하는지를 본서적에서 집어내고 있다.
 
● 사건의 내용
ABHS Project는 납기일을 준수하지 못하여 소송에 휘말리게 된다.
매일 리스크 비용이 발생하기에 Denver시는 해당 문제에 대한 비용청구를 하게 된다.
과연 누가 이 리스크 비용을 감당하게 될것인가??
 
2명의 저자는 ABHS Project 리스크해결을 위해 다양한 접글을 시도한다.
다른 공항의 개발사례도 분석했는지 유무도 파악하며
충분한 자금이 투입되었는지 여부도 확인 하고
일정에 대한 관리는 잘 이뤄졌는지
개발을 위한 요구사항 명세서 도 살펴보고
개발자가 과연 이것을 개발 할 수 있는 정도의 스킬을 가졌는지도 확인하게 된다.
 
자..
소송관련 컨설턴트의 입장에서 실패한 project에 과실 여부를 분석할때 과연 누가 가장 큰 잘못을 했고
누가 그 비용을 담당해야 옳을 것인가??  (이 답은 책에 나와있습니다. ^^ )
 
아직까지 필자가 경험한 project의 이런 리스크 비용은 고스라니 엔지니어 몫이 된다.
영업하시는 분들이 촉박하게 잡은 일정덕에 개발자들을 날을 새고 일을 하지만 납기일 준수는 하지 못하고
그 덕에 온갖 무시와 홀대를 받으며 겨우겨우 1~2달 말미를 받아 드라마같이 프로젝트를 종료한다.
 
2명의 필자는 이런 우리를 위해 리스크를 관리하는 산출근거와 방법들을 설명해 주고 있다.
리스크 산출은 domain에 밀접한 관련이 있긴 하지만 "리스톨로지"를 통하여 리스크를 관리하고자 하는
그들의 높은 의지를 옅볼 수 있다. (실제 적용유무는 글쎄... ^^)
 
이제 서평의 결말이다.
리스크관리가 이뤄지지 않는 조직에서 리스크를 이야기하는것은 선량한 한명의 가슴에 주홍글씨를 세겨넣는것과 같다.
그곳에선 그를 죄인 취급하고 프로젝트 방해꾼으로 총징한다.  (이런곳에서는 리스크를 말하지 말자!!)
 
하지만 정말 건설적인 프로젝트 완료와 성장지향을 원한다면 위험요소를 꼽아내는 그에말에 귀 기울여볼 필요가 있다.
그사람이 "리스크를 이익" 으로 환원시켜줄 연금술사가 될지도 모르니까 말이다.

데몬 위치 찾기

linux 2007. 11. 20. 13:48

살아있는 process의 위치를 찾는 방법입니다.

1. 프로세서 ID를 획득합니다.
2. 해당 프로세서 ID를 가지고 proc를 찾습니다.
3. proc에서 데몬의 위치를 확인합니다.



[neouser-dev:~/server/neouser]$ps -ef | grep neouser
testuser  2009  1861  0 13:14 ?        00:00:00 ./bin/neouser (testDemon)
testuser 17826 23060  0 13:42 pts/6    00:00:00 grep neouser

[neouser-dev:~/server/neouser]$cd /proc/1861/
[neouser-dev:/proc/1861]$ll
합계 0
dr-xr-xr-x    3 neouser testuser         0 11월 20 13:43 ./
dr-xr-xr-x  478 root     root            0  3월 21  2007 ../
-r--r--r--    1 neouser testuser         0 11월 20 13:43 cmdline
-r--r--r--    1 neouser testuser         0 11월 20 13:43 cpu
lrwxrwxrwx    1 neouser testuser         0 11월 20 13:43 cwd -> /testuser/server/neouser/
-r--------    1 neouser testuser         0 11월 20 13:43 environ
lrwxrwxrwx    1 neouser testuser         0 11월 20 13:43 exe -> /testuser/server/neouser/bin/exe
dr-x------    2 neouser testuser         0 11월 20 13:43 fd/
-r--r--r--    1 neouser testuser         0 11월 20 13:43 maps
-rw-------    1 neouser testuser         0 11월 20 13:43 mem
lrwxrwxrwx    1 neouser testuser         0 11월 20 13:43 root -> //
-r--r--r--    1 neouser testuser         0 11월 20 13:43 stat
-r--r--r--    1 neouser testuser         0 11월 20 13:43 statm
-r--r--r--    1 neouser testuser         0 11월 20 13:43 status



본 서적을 읽게된 경유는 스티브맥코넬리의 서적 4개를 독파하기 위해 잡게 되었다.
모두가 아시다시피 스티브맥코넬리는 단 4개의 서적만으로 모든 기술을 논할만큼 그에 생각의 깊이는 깊다.
사실 이것에 대한 정보는 인사이트 출판사나 너무도 쉽게 이해시켜놓은 도식이 있다.
 
professional소프트웨어개발 (동기부여)
Rapid Development, Code Complete (스터디)
소프트웨어 프로젝트 생존전략 (적용)
----------- 기회가 되면 이 4권에 책을 서평해봤으면 하는 바램이다.
 
오늘 이야기하고싶은 서적은 "professional 소프트웨어개발" 이다.
 
S/W는 부드러웠기 때문에 두리뭉실 평가된 경향이 있다.
S/W가 만일 부드럽지 않고 단단하고 딱딱했으면 지금처럼 한국 사회에 S/W개발자들이 저평가 되지 않았을 것이다.
물론 이공계 기피라는 단어조차 나오지 않았을 것이다.
스티브맥코넬리는 바로 이런 S/W의 부드러운 부분을 보다 구체화 시키고 체계화 시키기 위해 본서를 저술 하지 안았나 싶다.
 
스티브는 엔지니어 들에게 무 비판적 실행맨, 작업맨 으로써의 역할이 아니라
관리자들혹은 의뢰인들과 엔지니어가 직접 이야기 하며 문제를 풀어가고
다양한 분석과 상황판단을 통해 보다 많은 사람이 행복해하는 합의점을 찾아갈 수 있도록 "스티브 우화"를 적어놓았다.
> 피라미드를 움직이는 이집트인
> 화물숭배공학
> Silver Bullets
> 노붐 오르가눔
> 고아출신의 우대
이것 외에도 스티브는 많은 이야기 꺼리를 바탕으로하는 자신만의 사상을 전달하려고 하고 있다.
 
허면 이런 사상의 결론은 무엇인가?
놀랍게도 엔지니어를 보다 레벨화 시키고 정확하게 평가함으로써 성능좋은 엔지니어는 보다 높은 가치를
그렇지 못한 앤지니어는 교육과 훈련을 통해 높은 가치에 다다르게 함에 있다.
 
여기서 잠시 "professional소프트웨어개발" 의 역자를 살펴보자!!
역자는 윤준호씨로 SW-CMM의 ISO 인증을 위해 노력하는 사람이다.
만나보지는 못했지만 그도 역시 스티브의 엔지니어의 레벨화를 꾀하여 S/W를 짜임세 있게 만드는 분 일것 같다^^
 
자.. 다시 책속의 이야기로 들어가보도록 하자!!
책 서두에서는 "고아출신의 우대" 등과 같은 예를 통해 현실상의 엔지니어의 자각을 유도하고 있다.
책 중반부에서는 이런 엔지니어들에게 professional해 짐을 권면하면서 어떠한 방법으로를 이야기 한다.
책 종반부에서는 SW-CMM등과 같은 것을 통하여 레벨화와 모든 엔지니어의 성숙을 권면하고 있다.
 
우리는 본 서적을 통해 SW-CMM의 다음 세대를 준비할 필요가 있다고 본다.
그냥 단순 코더로써 오늘도 저렴한 몸값에 돌을 힘으로만 옮길 것인지
아니면 보다 향상된 엔지니어가 되어 고가의 몸값에 돌을 효과적을 옮길 궁리를 하게 되야하는지
우리는 본 서적을 통해 다가올 미래를 준비할 필요가 있다고 본다.
스티브의 머리속이 아니더라도 그의 눈으로 세상을 바라보고 나역시 다가올 미래를 준비 해야할것 같다

●  Database 생성

CREATE DATABASE testdb;


●  USER추가

insert into user (Host, User, Password, Select_priv, Insert_priv, Update_priv, Delete_priv, Create_priv, Drop_priv, Reload_priv, Shutdown_priv, Process_priv, File_priv, Grant_priv, References_priv, Index_priv, Alter_priv, Show_db_priv, Super_priv, Create_tmp_table_priv, Lock_tables_priv, Execute_priv, Repl_slave_priv, Repl_client_priv)
 values ('**.**.**.**', 'testuser', password('testpwd'), 'N', 'N', 'N', 'N', 'N', 'N', 'N', 'N', 'N', 'N', 'N', 'N', 'N', 'N', 'N', 'N', 'N', 'N', 'N', 'N', 'N');

insert into user (Host, User, Password, Select_priv, Insert_priv, Update_priv, Delete_priv, Create_priv, Drop_priv, Reload_priv, Shutdown_priv, Process_priv, File_priv, Grant_priv, References_priv, Index_priv, Alter_priv, Show_db_priv, Super_priv, Create_tmp_table_priv, Lock_tables_priv, Execute_priv, Repl_slave_priv, Repl_client_priv)
 values ('%', 'testuser', password('testpwd'), 'N', 'N', 'N', 'N', 'N', 'N', 'N', 'N', 'N', 'N', 'N', 'N', 'N', 'N', 'N', 'N', 'N', 'N', 'N', 'N', 'N');




● DB추가

insert into db (Host, Db, User, Select_priv, Insert_priv, Update_priv, Delete_priv, Create_priv, Drop_priv, Grant_priv, References_priv, Index_priv, Alter_priv, Create_tmp_table_priv, Lock_tables_priv)
 values ('**.**.**.**', 'testdb', 'testuser', 'Y', 'Y', 'Y', 'Y', 'Y', 'Y', 'N', 'Y', 'Y', 'Y', 'Y', 'Y');

insert into db (Host, Db, User, Select_priv, Insert_priv, Update_priv, Delete_priv, Create_priv, Drop_priv, Grant_priv, References_priv, Index_priv, Alter_priv, Create_tmp_table_priv, Lock_tables_priv)
 values ('localhost', 'testdb', 'testuser', 'Y', 'Y', 'Y', 'Y', 'Y', 'Y', 'N', 'Y', 'Y', 'Y', 'Y', 'Y');



FLUSH PRIVILEGES;

alias 추가 / 편집

linux 2007. 11. 19. 16:46

alias를 추가 하는 경우는 명령어 창에다

alias testsql='mysql -utestuser -ptestpwd testdb'


를 입력해주면 바로 확인이 가능하다.

하지만 logout하게 되면 본 alias는 사라지게 된다.


> 비 휘발성으로 만드는 방법

[test-dev2:~]$vi .bashrc
 alias testsql='mysql -utestuser -ptestpwd testdb'
[test-dev2:~]$source .bashrc


위와같이 .bashrc에 넣어주는 방법과 .profile에 넣어주는 방법이 있다.
필자의 경우에는
[test-dev2:~]$vi .profile
source .bashrc

이 들어있다. (같다는 이야기)


※ 혹 몰라서 하는 이야기이지만 .bashrs나 .profile의 경우에는 source라는
컴파일 과정이 필요하다
.

1 ··· 15 16 17 18 19 20 21 ··· 26 

글 보관함

카운터

Total : / Today : / Yesterday :
get rsstistory!