I Love Salsa~~

Step 1. Repository 생성

1. 오른쪽 상단의 + 표시를 누른 뒤 New repository를 선택

2. Repository name 입력

3. Description 입력

4. Initialize this repository with a README 선택

5. Create repository 버튼 클릭

Step 2. Branch 생성

GitHub는 기본값으로 repository에 master라는 branch를 가지고 있다.

그러나 다른 branch를 생성하여 master에 commit하기 전에 테스트 및 수정하기 위해서 사용된다.

1. master라고 되어 있는 콤보 메뉴를 클릭

2. 새로운 branch 이름 기입(예로 sub-branch)

3. Create branch : sub-branch from 'main' 버튼을 클릭하면 branch가 생성됨

이제 branch는 두개(master와 sub-branch)가 생성이 되었으며, master의 복사본인 sub-branch branch가 생긴 것이다.

이제 새로운 branch에 변경 사항을 추가한다.

Step 3. 변경 사항 commit

1. READM.md를 클릭

2. 내용을 수정하기 위해서 우측의 Editthis file 버튼을 클릭

3. 수정할 내용을 입력

4. 변경 사항에 대하여 commit message을 입력한 후 Commit changes 버튼 클릭

이제 이 변경된 README 파일은 sub-branch branch에만 적용이 되며, master의 내용과 다른 내용이 생기게 된다.

Step 4. Open Pull Request

이제 master branch와 변경 사항이 발생하였기에 pull request를 열 수 있다.

Pull request를 통해서 변경된 내용을 리뷰하고, 프로젝트 소유자(해당 코드 담당자)가 master branch로 pull request merge를 할 수 있다.

1. 상단 메뉴 중 Pull request 메뉴를 누르고, 이어서 New pull request 버튼을 클릭

2. Compare changes 화면 상단의 compare: main을 클릭하여 sub-branch로 선택

3. 비교 페이지에서 변경 사항에 대하여 확인 가능

4. 변경 사항에 대하여 확인이 되었으면 상단의 Create pull request 버튼을 클릭

5. 변경 사항에 대하여 추가 설명이 있으면 입력한 후, 하단에 위치한 Create pull request 버튼을 클릭

Step 5. Merger pull request

변경 사항에 대하여 리뷰가 문제없이 끝났으므로 main branch에 merge를 해야 한다.

1. Merge pull request 버튼을 클릭

2. Comfirm meger 버튼을 클릭

3. main branch로 merge가 완료 되었으므로, Delete branch 버튼을 클릭하여 sub-branch에 대하여 삭제를 진행한다.

4. sub-branch가 삭제되었다는 메시지를 확인

5. 상단 메뉴에서 Code를 클릭한 후 main 콤보 박스를 선택하면 sub-branch branch가 삭제됨을 확인 가능

이상 여기까지가 GitHub의 Pull request를 통한 코드 리뷰 방법을 사용하는 방법을 테스트 해 보았다.

지금까지 찾아본 방법은 Ignored Resource 전부다 다음과 같았다.

Window > Preferences  > Team > Ignored Resources에 패턴을 추가하는 방법이였다.

하지만, 위와 같은 방법으로는 Synchronize에서는 제거되지가 않는다.

다음의 방법을 사용할 경우 Synchronize에서 불필요한 폴더들을 제거가 가능하다.

Synchronize View에 나오는 폴더 중 불필요한 정보는 해당 위치에 마우스 클릭한 후 마우스 우클릭을 클릭하여 팝업 메뉴 중 "Add to svn:ignore..." 메뉴를 클릭하면 더이상 Synchronize 폴더에서 나타나지 않게 된다.

VisualVM으로 WAS의 각종 모니터링을 하고자 할 때 다음과 같은 설정으로 진행한다.

1. catalina.sh에서 다음의 값을 추가한다.

> port 번호는 "netstat -anl | grep 9090" 명령어로 허용여부를 판단해야 한다. 만약 막혀 있으면 iptables 명령어로 해당 포트를 허용해야만 한다.

> hostname은 Tomcat이 구동되는 서버 IP를 입력한다.

2. Tomcat을 기동한다.

3. VisualVM에서 File > Add JMX Connection을 선택한다.

4. Connection : 정보에는 앞서 설정한 "hostname:port" 정보를 입력한 후 "OK" 버튼을 클릭한다.

5. VisualVM 화면 중 Applications의 Remote로 WAS에 대하여 모니터링를 할 수 있다.

삼실에서 javacore 파일 분석 문서 작성하다가 덤프떠서 기록으로 남깁니다.

다음에는 javacore 분석 툴 사용방법을 남겨볼까..

INSERT로 시작되면 구문은 무조건 insert 엘리먼트를 사용한다고 기억하면 오류가 발생한다.

다음와 같은 INSERT INTO SELECT 구문은 update 엘리먼트를 사용해야만 한다.

HttpURLConnection을 사용할 경우 순서를 잘못 정의하여 4시간을 소비하여 알아낸 정보다.

HttpURLConnection으로 OutputStream을 사용할 때 

openConnection > getOutputStream > write > getInputStream > read

와 같이 순서로 진행되어야 하는데 중간에 순서가 틀어지면 제목과 같은 에러 메시지를 구경할 수 있다.

소프트웨어 개발 모델

특성

V-모델(순차적 개발 모델)

1. 요구사항 정의 및 분석 2. 시스템 설계 3. 구현 4. 테스팅 등 일련의 단계(과정)을 통해서 소프트웨어 시스템을 개발하는 폭포수 개발 모델(Waterfall model)에 근간을 두고 있다. 테스트는 한번에 진행되는 것이 아니고, 각각의 개발 단계별 테스트 레벨로 진행된다. 위와 같은 쳬계로 개발 단계의 요구사항 분석, 논리 설계, 물리 설계, 프로그램 코딩 등의 4단계의 개발 활동으로 이루어진다. 이어 V-모델에서 제시하는 테스트 레벨은 컴포넌트(단위) 테스팅, 통합 테스팅, 시스템 테스팅, 인수 테스팅으로 분류된다. 소프트웨어 개발 기간 중에 개발 산출물(Work products - 비지니스 시나리오 또는 유즈케이스, 요구 사항 명세, 설계 문서나 코드)로 테스트 레벨에서 테스트 베이시스(Basis)가 된다.

V-모델에서 테스팅 개념

테스터들은 인도된 제품에 대하여 문제점들을 찾아야 한다. 그러다보니 어쩔 수 없이 개발자와 사소한 의사 다툼이 발생이 될 수 밖에 없다.

다음은 그런 사항을 사전에 개선할 수 있는 내용이 있어 적어 봅니다.

1. 다툼보다는 협력으로 시작한다. 즉, 더 나은 품질의 시스템을 개발하고자 하는 공통적인 목표를 모든 사람에게 주지시킨다.

2. 소프트웨어를 개발한 "사람"에 대한 비평을 배제하고, 중립적이고 사실에 근거한 제품의 결함만을 전달하려고 노력한다.(예로 객관적이고 사실적인 인시던트 리포트를 작성하고 발견한 사항을 리뷰 한다.)

3. 다른 인원이 어떻게 느끼는지, 왜 그렇게 반응하는지 이해하도록 노력한다.

4. 상호간에 의사소통 했던 것을 상대방이 정확하게 이해했는지 확인한다.

주석 :

음, 개발자 입력에서 보면 1번, 2번, 4번이 중요한 듯하다.

공통된 목표 의식과 개발자가 아닌 제품의 관점으로 접근하며, 의사소통이 정확하게 전달이 되었는지가 중요한 듯 하다.

다음의 순서대로 테스팅의 독립성은 높아진다.

1. 테스트 대상 소프트웨어의 개발자가 설계한 테스트(독립성 낮음)

2. (개발팅 내의) 다른 인원이 설계한 테스트

3. 다른 그룹의 독립적인 테스트 팀의 인원, 또는 테스트 전문가(사용성 또는 성능 테스트 전문가 등)가 설계한 테스트

4. 다른 조직 또는 다른 회사의 인원이 설계한 테스트(외부적인 조직에 의한 인증, 아웃소싱)

3번, 4번의 차이점을 확실히 느껴보았다.

4번의 경우는 억울할 때도 가혹 있었다.

테스티의 독립성이 보장되어야 보다 나은 소프트웨어로 발전이 될 것이다.

다음과 같은 결함 유형이 있다(지적 유형?)

1. 기획 시 유입된 결함

- 요구사항의 표준 미준수, 테스트 불가능, 불명확, 불완전, 불일치, 기타 결함

2. 설계 시 유입된 결함

- 설계의 표준 미준수, 테스트 불가능, 불명확, 불완전, 불일치, 인터페이스 결함, 기타 결함

3. 코딩 시 유입된 결함(연관 변수 파악 부족, 예외 사항 고려 부족 등)

- 코드의  표준 미준수, 불완전, 불일치, 인터페이스 결함, 데이터 결함, 기타 결함

4. 테스트 부족으로 유입된 결함

5. 마무리 부족

6. 팀간 의사소통 부족

7. 코딩 실수

"마무리 부족으로 유입된 결함" 유형이 상대적으로 많다면 개발 과정에서 마무리하는 절차를 별도로 가지거나 품질 보증자가 마무리가 제대로 되도록 감시하는 활동을 강화하는 등의 개발 프로세스 개선을 고려해야 한다.

주석 :

"마무리 부족으로 유입된 결함" 유형을 참 많이 내었으며, 이런 유형을 많이 경험해 보았다.

결론은 자신과의 싸움에서 진 것이다.(지속적인 테스팅이 필요함)