반응형


MAC 터미널에서 혹시나 메이븐(maven)을 통해 빌드해야하는 경우가 있을 경우 메이븐(maven)을 설치해주어야 한다.

밑의 url에 들어가 tar.gz 파일을 다운받아서 압축을 풀어준다.

http://maven.apache.org/download.cgi

그 후 mvn 명령어로 손쉽게 메이븐(maven)을 사용하기 위해 환경변수를 설정해준다.

vi ~/.bash_profile

vi로 열어서 압축을 푼 곳의 디렉토리 위치를 설정해준다.

#path setting
export M2_HOME=/Users/nhnent/Documents/apache-maven-3.5.2   (본인의 압축 푼 경로에 맞게!!!)
export M2=$M2_HOME/bin
export PATH=$M2:$PATH

저장 후 설정 변경을 위해 다음 명령을 실행한다.

source ~/.bash_profile

실행 후 echo $PATH 를 해보면 본인의 PC에 설정된 path들의 리스트가 출력된다.

해당 리스트에 메이븐(maven) PATH가 정상적으로 추가되었다면 mvn -version을 통해 확인해 볼 수 있다.

mvn -version 명령을 내렸을 경우 이런 버전을 나타내는 stdout이 출력되지 않았다면 정상적으로 설치되지 않은 경우이기 떄문에

설치 경로 및 환경변수를 다시 한 번 확인이 필요하다.


반응형
반응형

톰캣은 웹 애플리케이션을 어떻게 관리하는가?


톰캣은 한 번에 여러 개의 웹 애플리케이션을 실행할 수 있도록 설계되어 있다.

웹 애플리케이션은 배포 명세서 web.xml을 가진 WAR 파일로 정의되어 있다. 대개 서버는 하나의 톰캣 인스턴스를 실행하며 관련된 WAR 파일이 톰캣 인스턴스의 webapps 디렉터리에 설치된다. 이는 기본 설정이며 위치를 변경할 수 있다.


톰캣의 구성 요소들

톰캣은 몇 가지 구성 요소로 이루어져 있는데, 그중 하나가 서블릿 컨테이너와 JSP를 처리하는 것이다. 서블릿 컨테이너 구성 요소는 카탈리나(Catalina)라고 하며 JSP 구성 요소는 재스퍼(Jasper)라고 한다.


톰캠 사용 문서를 읽다 보면 이 이름들에 대한 참조를 쉽게 볼 수 있다. 예를 들어 결과 로그 파일의 기본 이름은 catalina.out이고, 톰캣 홈 디렉터리의 환경 변수는 $CATALINA_HOME이다.


기본으로 실행 중인 톰캣 인스턴스는 webapps 디렉터리에서 일어난 변화를 감지한다. 새 WAR 파일이 이 디렉터리에 저장되면 톰캣은 WAR 파일 이름에 대응하는 디렉터리에 파일 내용을 풀어놓고 컨텍스트의 애플리케이션을 해당 이름에 대응시킨다.


예를 들어 BookingApplication.war라는 WAR파일을 webapps 디렉터리에 배포하면 그 파일은 BookingApplication 디렉터리에 압축을 푼다. 톰캣은 WEB-INF 하위에 있는 web.xml 파일을 읽고 정의된 대로 애플리케이션을 실행하고 /BookingApplication 경로를 통해 클라이언트에게 제공한다.


이 접근 방법은 개발 방향을 빠르게 전환하는 데 상당히 유용하다. 지속해서 배포 할 수 있는 방법을 갖게 할 뿐만 아니라 접근할 수 있는 서버에 단위 테스트를 완료해 빌드된 WAR 파일을 자동으로 배포할 수 있으며 통합 테스트를 준비할 수 있기 때문이다. 테스트 범위가 충분하고 팀의 개발 프로세스가 가능하다면 실제 환경에도 자동으로 배포되게 할 수 있다.


# Reference - 자바프로그래밍 면접 이렇게 준비한다.

반응형
반응형

WAR 파일이란 무엇인가?



웹 아카이브Web Archive 파일인 WAR 파일은 자바의 JAR 파일과 같은 역할을 하며, 주로 웹 어플리케이션을 묶는 데 사용된다. 파일 안에는 애플리케이션을 실행하기 위해 컴파일된 모든 클래스 파일들뿐만 아니라 제공되어야 하는 모든 프로퍼티 파일과 다른 설정 파일들도 포함된다.


WAR 파일의 가장 중요한 점은 웹 애플리케이션을 어떻게 설정할지 정의한 배포 명세서(web.xml 파일)가 있다는 것이다. 이 파일은 애플리케이션 서버에게 애플리케이션을 어떻게 배포하고 제공할지에 관한 내용을 명령으로 제공한다.


IntelliJ IDEA나 이클립스 같은 IDE 대부분은 프로젝트에서 클릭 몇 번으로 WAR파일을 생성할 수 있다. 메이븐 상단에 packaging태그를 사용해 쉽게 WAR파일을 생성할 수 있다.




반응형
반응형

동시성 코드와 블로킹(blocking)콜 그리고 아카(akka)

여러 개의 스레드가 동시에 작업을 수행하더라도 synchronized 블록이나 데이터베이스, 네트워크 API 호출 등을 만날 다른 스레드와 나란히 줄을 서서 순차적으로 작업을 수행해야 하는 경우도 있다. 암달의 법칙은 프로그램이 있는 속도의 상한이 이런 순차적 코드가 사용하는 시간에 의해서 제한된다고 말한다. 이러한 순차적 코드의 다른 이름은 블로킹(blocking)콜이다. 조금 과장해서 말하자면 자바 개발자가 스레드를 이용해서 만들어내는 '동시성' 코드는 일종의 신기루다. 사실은 코드 곳곳에 존재하는 블로킹 , 순차적 코드 때문에 전체적인 프로그램의 처리율은 이미 상한이 정해져 있지만 여러개의 스레드가 '동시에' 동작한다는 사실로부터 위안을 받을 뿐이다.


아카(akka) 스칼라(scala)언어로 작성되었지만 아래로 내려가면 자바의 동시성 패키지를 사용하기 때문에 아카를 사용하는 것은 궁극적으로 자바의 Thread Task 사용하는 것과 마찬가지다. 하지만 아카를 사용하면 프로그램 곳곳에 존재하는 순차적 부분, 블로킹 콜을 전부 없애거나 최소한으로 만드는 것이 가능해진다. 아카(akka) 이용해서 프로그램을 설계하는 것은 블로킹 호출이 일어나는 지점을 논블로킹 호출로 전환하는 작업을 수행하는 것을 의미한다.



반응형
반응형

 

 모르면 손 발이 고생하는 Eclipse 단축키에 대해 알아보자. 작업을 할 때 단축키를 사용한다는 것은 굉장히 생산성을 향상시켜주는 일이다. 꼭 단축키를 사용하여 생산성을 향상 시키도록 하자!


[ Eclipse 단축키 ]


기본적으로 Preference > General > Keys에서 대부분(모든) 단축키 확인 가능합니다.
Ctrl+Shift+L : 단축키 보기 Hint

 

[거의 달고 사는 단축키]


ctrl + s : 저장 파일
ctrl + i : 소스 깔끔 정리(인덴트 중심의 자동구문정리)
ctrl + space : 어휘의 자동완성(Content Assistance)
ctrl + 1 : Quick Fix(Rename 주로 사용)
ctrl + shift + M : 캐럿이 위치한 대상에 필요한 특정클래스 import
ctrl + shift + O : 소스에 필요한 패키지의 자동 임포트
ctrl + / : 한줄 또는 선택영역 주석처리/제거
ctrl + Q : 마지막 편집위치로 가기
ctrl + L : 특정줄번호로 가기
ctrl + D : 한줄삭제
ctrl + H : Find Replace
ctrl + K : 다음찾기(또는, 찾고자 하는 문자열을 블럭으로 설정한 키를 누른다.)
ctrl + shift + K : 이전찾기(또는, 찾고자 하는 문자열을 블럭으로 설정한 역으로 찾고자 하는 문자열을 찾아감.)
alt + shift + j : 설정해 기본주석 달기
Ctrl + 객체클릭(혹은 F3) : 클래스나 메소드 혹은 멤버를 정의한 곳으로 이동(Open Declaration)


[
사용하면 유용한 단축키]


ctrl + shift + f : 소스 깔끔 정리
ctrl + 2 + R : Rename(리팩토링)
ctrl + shift + / : 선택영역 block comment 설정
ctrl + shift + \ : 선택영역 block comment 제거
alt + shift + up : Enclosing Element 선택(괄호의 열고 닫기 확인에 유용함)
ctrl + O : Outline창열기
Alt + ->, Alt + <- : 이후, 이전
해당프로젝트에서 alt + enter : Project 속성
sysout > Ctrl + Space : System.out.println();
try > Ctrl + Space : 기본 try-catch 완성
for > Ctrl + Space : 기본 for 완성
템플릿을 수정,추가 : Preferences > java > editor > Templates

 

[알고 있으면 아는척좀 있는 단축키]


ctrl + N :
새로운 파일 프로젝트 생성
ctrl + shift + s :
열려진 모든파일 저장 컴파일
alt + / : Word Completion
alt + shift + R : Rename
ctrl + shift + G :
특정 메써드나 필드를 참조하고 있는 곳을 찾는다.
ctrl + shift + B :
현재커서위치에 Break point설정/해제
ctrl + alt + R
ctrl + f11 :
실행
f11 :
디버깅 시작
f5 : step into
f6 : step over
f8 :
디버깅 계속
ctrl + . :
다음오류부분으로 가기
ctrl + , :
이전오류부분으로 가기
f12 :
에디터로 커서이동
ALT + UP,DOWN :
현재 위치 이동
Ctrl + j :
검색할 단어를 입력하면서 실시간으로 검색
Ctrl + Shift + j :
검색할 단어를 입력하면서 실시간으로 거꾸로 검색
F4 :
클래스명을 선택하고 누르면 해당 클래스의 Hierarchy 있다.
ctrl + alt + up/down :
한줄 duplicate
alt + shift +
방향 : 선택
ctrl + shift + g :
케럿이 위치한 객체가 참조 되는 곳을 찾아 준다

 

 

########################################################

===== 실행 =====
1. Ctrl + F11 :
바로 전에 실행했던 클래스 실행

 

===== 소스 네비게이션 =====
1. Ctrl +
마우스커서(혹은 F3) : 클래스나 메소드 혹은 멤버를 상세하게 검색하고자 할때
2. Alt + ->, Alt + <- :
이후, 이전
3. Ctrl + o :
해당 소스의 메소드 리스트를 확인하려 할때
4. F4 :
클래스명을 선택하고 누르면 해당 클래스의 Hierarchy 있다.


===== 문자열 찾기 =====
1. Ctrl + k :
찾고자 하는 문자열을 블럭으로 설정한 키를 누른다.
2. Ctrl + Shift + k :
역으로 찾고자 하는 문자열을 찾아감.
3. Ctrl + j :
입력하면서 찾을 있음.
4. Ctrl + Shift + j :
입력하면서 거꾸로 찾아갈 있음.
5. Ctrl + f :
기본적으로 찾기

 

===== 소스 편집 =====
1. Ctrl + Space :
입력 보조장치(Content Assistance) 강제 호출 => 입력하는 도중엔 언제라도 강제 호출 가능하다.
2. F2 :
컴파일 에러의 빨간줄에 커서를 갖져다가 키를 누르면 에러의 원인에 대한 힌트를 제공한다.
3. Ctrl + l :
원하는 소스 라인으로 이동
  
로컬 히스토리 기능을 이용하면 이전에 편집했던 내용으로 변환이 가능하다.
4. Ctrl + Shift + Space :
메소드의 가로안에 커서를 놓고 키를 누르면 파라미터 타입 힌트를 있다.

5. 한줄 삭제 CTRL + D

6. 파일 닫기 : CTRL+W

7. 들여쓰기 자동 수정. (3.0 NEW) : CTRL+I 

8. 블록 주석(/*..*/) 추가.(3.0 NEW): CTRL+SHIFT+/

  8.1 Ctrl + / 해주면 여러줄이 한꺼번에 주석처리됨. 주석 해제하려면 반대로 하면 .
9.
(아래)줄과 바꾸기 : ALT+UP(DOWN)

10. 블록 선택하기.  : ALT+SHIFT+방향키

11. 메소드의 파라메터 목록 보기. : CTRL+SHIFT+SPACE
12.
자동으로 import 하기 : CTRL+SHIFT+O

13. 열린 파일 모두 닫기 : CTRL + SHIFT + F4

14. 블록 주석 제거 : CTRL+SHIFT+

15. 전체화면 토글 : CTRL+M

16. 한줄(블럭) 복사 : Ctrl + Alt + (아래)

17. 다음 annotation(에러, 워닝, 북마크 가능)으로 점프 : Ctrl + , or .

18. 픽스 : Ctrl + 1  
19.
메소드 정의부로 이동 : F3
20.
하이어라키 팦업 띄우기(인터페이스 구현 클래스간 이동시 편리) : Ctrl + T 

21. 메소드나 필드 이동하기 CTRL + O 
22. ULTRAEDIT
EDITPLUS CTRL+TAB 같은 기능. : CTRL+F6 

 

===== 템플릿 사용 =====
1. sysout
입력한 Ctrl + Space 하면 System.out.println(); 으로 바뀐다.
2. try
입력한 Ctrl + Space 하면 try-catch 문이 완성된다.
3. for
입력한 Ctrl + Space 하면 여러가지 for 문을 완성할 있다.
4.
템플릿을 수정하거나 추가하려면 환경설정/자바/편집기/템플리트 에서 있다.

 

===== 메소드 쉽게 생성하기 =====
1.
클래스의 멤버를 일단 먼저 생성한다.
2. override
메소드를 구현하려면 : 소스->메소드대체/구현 에서 해당 메소드를 체크한다.
3.
기타 클래스의 멤버가 클래스의 오브젝트라면 : 소스->위임메소드 생성에서 메소드를 선택한다.

 

===== organize import =====
1.
자바파일을 여러개 선택한 소스 -> 가져오기 체계화 해주면 모두 적용된다

 

===== 소스 코드 형식 공통 주석 설정 =====
1.
환경설정 -> 자바 -> 코드 스타일 -> 코드 포멧터 -> 가져오기 -> 프로파일.xml 불러다가 쓰면 된다.
2.
또한 다수의 자바파일에 프로파일을 적용하려면 패키지 탐색기에서 패키지를 선택한 소스 -> 형식화를 선택하면 된다.
3.
환경설정 -> 자바 -> 코드 스타일 -> 코드 템플리트 -> 가져오기 -> 템플리트.xml 불러다가 쓰면 된다.

 

===== 에디터 변환 =====
1.
에디터가 여러 파일을 열어서 작업중일때 Ctrl + F6 키를 누르면 여러파일명이 나오고 F6키를 계속 누르면 아래로
2. Ctrl + Shift + F6
키를 누르면 위로 커서가 움직인다.
3. Ctrl + F7 :
뷰간 전환
4. Ctrl + F8 :
퍼스펙티브간 전환
5. F12 :
에디터로 포커스 위치

 

Alt + 위아래 방향키move line(block)

가장 많이 쓰는 애용 단축키 이다. 설명하자면 단순히 한줄(혹은 블럭)의 내용을 위아래로 옮기는 것이지만, 쓸데 없는 Cut & Paste를 줄여준다거기다, 블럭안팍으로 옮기면 자동으로 들여쓰기까지 해준다.

 

Alt + Ctrl + 위아래 방향키copy line(block)

요즘 아무리 재사용성이 증가했다라지만 프로그래머가 가장 많이 쓰는 기능이라면  머니머니해도 Copy & Paste이다. Alt 방향키가 Cut & Paste라면 이번에 Copy & Paste이다 한줄(혹은 블럭)의 내용을 위/아래 줄로 복사해준다. 역시 쓸데없는 반복작업을 많이 줄여준다.

 

Alt + Shift + 좌우 방향키select block

프로그래머는 섬세한 마우스 손놀림이 필요하다. 항상 정확한 부분부터 블럭을 잡아 카피 페이스트를 해야하기때문이다! 이때 유용한 기능이 바로 이것! 지금 커서 위치의 단어의 의미있는 블럭을 똑똑하게 잡아주고 확장 축소해 준다. 글로 읽어보기 보다 직접 사용해 보라. 멋지지 아니할 수 없다.

 

Alt + Shift + R  : Rename Refactor

게으른 프로그래머의 전형중에 하나가, 제멋대로 작명이다. 설계도 제대로 안하고 제멋대로 작명해서 쓰거나, 오타로 인해 toString toSring이 되어버렸거나.. 이런 경우 가만 내버려두면 그 확산 범위는 잘못하면 프로젝트 전체로 퍼져나가게 되어 걷잡을 수 없게된다. 이때 유용하게 쓸수 있는것이 Rename이다. 리팩토링메뉴에 편리한 기능들이 엄청 모여있지만 그중에 가장 많이 쓰게되는 기능일것이다. 프로젝트 전체에 관계된 이름을 깔끔하게 싹 바꿔준다.

 

Ctrl + Shift + F4 : Close All Opened Window

열려져 있는 모든 파일(View)을 닫아준다. 프로그래밍을 하다보면(특히 JSP Model2같은) 끝없이 파일을 열게 되서 화면이 무척 지저분해 질때까 있다. 그때 살짜쿵 눌러주고 다시 열때 편리하다.

 

Ctrl + Shift + G : Find references

이글을 보고 계시는 대부분의 분들은 사용되는 변수(혹은 메소드, 클래스, 객체 등)의 선언으로 가는 방법 정도는 알고 계실것이다. 바로 Ctrl + 클릭 혹은 F3 이다. 물론 선언으로 바로 가고 싶을때도 많지만 선언된 변수의 참조(사용처)를 찾아가고 싶을때가 더 많다. 그럴때 유용한 것이 이 단축키이다워크스페이스 내에서 참조된 곳을 전부 찾아서 Search View에서 List형태로 보여준다.

 

Ctrl +3 : Quick Access (Eclipse 3.3 Europa)

유로파를 쓰시는가? 그럼 축복받은 단축키 Ctrl + 3을 쓸 수 있다. 보통 단축키를 쓰다보면 마우스에는 손이 잘 안가고 뭐든지 키보드로 해결하려 하게 된다. 하지만.. 모든 기능에 단축키를 부여할 수는 없는법! 그래서 나온기능이 Quick Access이다. 메뉴들을 직접 타이핑해서 찾을 수 있고 history기능까지 제공한다


해당 글 reference : http://strikerhan.tistory.com/8


[ Bobby의 싸가지 ]

한 가지. 무식하면 손 발이 고생한다

두 가지. 무슨 일을 하든 신속히 처리할 수 있는 방법을 생각하고 적용하자.

세 가지. 단축키를 쓰고 안쓰고는 하늘과 땅의 차이다.

네 가지. 손에 익히고 행동으로 옮기자.

 



반응형
반응형

 


 안녕하세요. 오늘은 최근 작업했던 특정 서비스의 웹 개편 작업 중 경험한 장애 상황에 대해 포스팅 해볼까 합니다. 새롭게 단장한 고객센터 페이지를 해당 서비스에 적용하고 테스트 까지 잘 맞췄었는데 그 다음 날 장애 상황을 경험하게 되었습니다.

먼저 현재 회사의 많은 서비스 고객센터 페이지가 API 형태로 붙게 되는데요. 그렇다보니 그 많은 서비스들의 고객센터 페이지를 계속해서 만들어 낼 수도 없는 상황인지라 사이트메쉬와 데코레이터 패턴을 이용하여 신규 서비스가 오픈하면 해당 서비스에 맞게 CSS를 입혀 서비스하는 방식으로 몇몇 서비스들이 이루어지고 있습니다. 최근 특정 서비스의 웹 리모델링에 맞춰 변경된 CSS로 작업을 진행하는 도중 문제가 발생했습니다.


[상 황]

 웹페이지의 리모델링에 맞춰 CSS작업 팀으로 부터 변경 된 CSS를 받아 특정 서비스의 고객센터에 적용해야하는 상황. 물론 CSS를 새로 받게 되면 로컬에서 CSS를 적용시켜보고 웹 페이지를 띄워 노출되지 않는 이미지가 있는지 깨지는 부분이 있는지를 확인하는 작업이 요구된다. 그렇게 여러번의 수정 작업을 마치고 페이코 웹 개편 작업 반영을 하게 되었다. 

 이번 같은 경우에는 해당 서비스의 메인 페이지 및 다른 부분도 모두 개편되는 부분이라서 여러 팀이 순서대로 반영을 하는 상황. 테스터 분들도 모두 동참하여 반영이 이루어졌다. 그렇게 모든 팀의 반영 및 테스트 작업이 약 7~8시간에 걸쳐 진행되었고 잘 마무리 짓게 되었다.


[ 문제상황 ]

반영이 끝난 그 다음날 오전 TTS(TROUBLE TICKET SYSTEM) 5급(등급이 낮을 수록 심각 1~5)을 맞게 되었다. 특정 서비스에 문제가 생길 경우 해당 사이트에 문제 상황이 뜨고 담당자에게 연락이 감. 문제는 고객센터 '1:1문의 페이지'에서 문의를 작성한 후 '완료'하는 버튼이 보이지 않는 상황이었다.

 

[동의란 밑에 아무 버튼도 노출되지 않고 있음]



[정상적인 모습]

 

그 문제상황을 보고 받고 속으로 '어떻게 그렇게 테스트를 여러번 했는데 문제가 났다는 게 말이되나?'하는 의구심을 받고 페이지에 접속한 결과 정상적으로 버튼이 노출되고 있는 것을 확인하였다. 그럼 그렇지 하며 익스플로러에서도 확인 결과 정상적으로 버튼이 노출되고 있는 것을 확인하였다. 


[문제원인 & 처리]

그렇게 뭐지???하고 생각하던 중 팀장님께서 외부망으로 접속해보라고 하셨다. 그렇게 외부망으로 접속을 하자 버튼이 노출되지 않고 있음을 파악할 수 있었다. 문제는 변경된 CSS의 버튼의 이미지 경로가 내부망(#밑에 설명) 주소로 박혀있었던 것이다. 보통은 이미지 경로가 해당 작업 하시는 분의 디렉터리 구조에 맞춰 상대경로로 되어 있어 CSS를 받아 적용해보면 어떤 이미지가 없는지 파악이 가능했고 그 이미지를 요청해서 얻어오는 식이었는데 어떻게 보면 뒤통수를 맞은 격이었다. 그것도 딱 해당 2개의 버튼만 "http://{내부망ip}"로 되어 있었던 것이다. 이에 파일을 다운 받아 프로젝트 내에 넣고 경로를 맞추어 준 후 반영을 했지만 뭔가 씁씁한 기분은 가시 질 않았다.


#내부망 

내부망은 일정 조직 내에서 인터넷이 아닌 내부 네트워크를 통해 PC끼리 자원을 공유하게 하거나 그룹웨어 등을 사용할 수 있게 하는 근거리 통신망(LAN, Local Area Network)로 '인트라넷'을 생각하면 이해하기 쉬울 것 같다. 망분리는 현재 정통망법 시행령에 따라 망법 적용을 받는 기업중 개인정보 100만명 이상, 매출액 100억원 이상의 기업은 의무적으로 망 분리를 실시해야고 한다. 보통 보안적인 이슈 때문에 적용하는 듯 하다.


[느낀점]

이런 문제를 처음 경험해 본 나는 적잖이 당황했던 것 같다. 좀 더 꼼꼼히 파악을 했더라면 좋았을 텐데 그렇기엔 그 긴 CSS를 다 파악하기 힘든 상태였고 웹 페이지에 CSS를 적용 후 깨지는 이미지와 CSS에만 초점을 맞춰 작업을 했던게 이런 문제점을 나았다. 외부망으로 한 번 만 확인을 해보았으면 이런 실수가 발생하지 않았을텐데 하는 아쉬움이 남는다. 이번 경험을 계기로 다음부터는 꼭 외부망으로도 접속해 테스트 해보도록 해야겠다. 



똑같은 실수를 반복하지 말자.



반응형
반응형


 

안녕하세요. 오늘은 작년 신입 교육 때, 딱 1년 전 읽었던 책 ( 열혈강의, 자바 웹 개발 워크북 )에 대해 정리해 보는 시간을 갖도록 하겠습니다. 책상 옆에 놓여있길래 막상 꺼내 펼쳐 보니 잊고 있었던 내용들도 있고 다시 한 번 상기할만한 내용들이 있어 이렇게 정리하게 되었습니다. 이제 막 웹을 시작하시는 분들이 보시기에 좋은 책인 것 같습니다. 정리라는게 챕터별로 정리하는 게 아닌 개인적으로 메모해놓고 다음에 다시 상기해 볼 만한 내용들이나 괜찮은 내용이다 싶은 부분만을 추려 정리하는 것이기 때문에 자세한 내용을 알고 싶으실 경우 책을 사서 보시길 추천해드립니다.

 

 

[ 프록시 서버 (Proxy Server) ]

클라이언트와 서버 사이에서 통신을 중계해 주는 컴퓨터나 프로그램을 말합니다. 프록시 서버의 주된 용도 중 하나는 빠른 전송을 위하여 서버의 응답 결과를 캐시에 저장해 두는 것입니다. 프록시 서버를 두는 두 번째 이유는 보안적인 부분인데, 첨단 기술을 다루는 회사의 경우 내부 사용자의 기밀 유출에 민감할 수밖에 없습니다. 이런 경우 프록시 서버를 이용하면 외부로 전달되는 데이터를 검사하여 특정 단어가 포함된 자료의 송.수신을 차단하거나 보안 팀에 경고 메시지를 보낼 수 있습니다.

 

[ 멀티 프로세스와 멀티 스레드 ]

멀티 프로세스 방식은 클라이언트가 연결 요청을 하면 서버 프로그램은 자신을 복제하여 클라이언트에 대응하게 하고, 자신은 다른 클라이언트의 요청을 기다립니다. 이 방식은 원본 프로세스의 메모리를 모두 복제하기 때문에 자원 낭비가 심합니다. 그에 비해 멀티 스레드 방식은 클라이언트 요청을 처리하는 일부 코드만 별도로 분리하여 실행하기 때문에 전체 메모리를 복제할 필요가 없어, 멀티 프로세스 방식보다 메모리 낭비가 적습니다.

 

[ 요청 헤더 ]

헤더에는 세 가지 종류가 있는데 요청이나 응답 모두에 적용할 수 있는 '일반 헤더(General-header)'와 요청 또는 응답 둘 중 하나에만 적용할 수 있는 '요청 헤더 또는 응답 헤더(Request-header/Response-header)', 보내거나 받는 본문 데이터를 설명하는 '엔티티 헤더(Entity-header)'가 있습니다. 요청 헤더가 담는 헤더명중 User-Agent가 있는데 클라이언트의 정보를 서버에게 알려주는 헤더입니다. 웹 서버는 이 헤더를 분석하여 요청자의 OS와 브라우저를 구분합니다.

 

[ CGI(Common Gateway Interface) ]

웹 서버와 프로그램 사이의 데이터를 주고받는 규칙을 CGI(Common Gateway Interface)라고 합니다. 이렇게 웹 서버에 의해 실행되며 CGI 규칙에 따라서 웹 서버와 데이터를 주고 받도록 작성된 프로그램을 'CGI 프로그램'이라고 합니다.

 

[ 서블릿 컨테이너 ]

서블릿의 생성과 실행, 소멸 등 생명주기를 관리하는 프로그램을 '서블릿 컨테이너(Servlet Container)'라 합니다. 서블릿 컨테이너(Jave EE 기술 중에서 서블릿, JSP 등 웹 관련 부분만 구현한 서버로 아파치 재단의 톰캣, Jetty등)가 서블릿을 대신하여 CGI 규칙에 따라 웹 서버와 데이터를 주고받습니다.

 

[ WebContent/Web-INF ]

웹 애플리케이션의 설정과 관련된 파일을 두는 폴더로 이 폴더에 있는 파일은 클라이언트에서 요청할 수 없다. 따라서 HTML이나 JavaScript, CSS 등 클라이언트에서 요청할 수 있는 파일을 이 폴더에 두어서는 안 됩니다.

 

[ GET 요청으로 넘어온 매개변수 값의 인코딩 설정 ]

GET 요청은 매개변수 값이 URL에 포함되기 때문에 setCharacterEncoding()으로는 문자 집합을 설정할 수 없다. 톰캣 서버에서 server.xml을 열어 <Connector>태그에 URIEncoding 속성을 추가하고, 값은 UTF-8로 설정한다. 웹 브라우저가 웹 서버로 데이터를 보낼 때는 웹 페이지의 기본 문자집합으로 인코딩하여 보내기 때문에 사용자가 입력한 값은 UTF-8로 인코딩되어 서버에 전달된다. 반면 서블릿은 UTF-8(한글 한 자를 3바이트로 표현) 3바이트를 하나의 문자로 인식하지 않고 각각의 바이트를 개별 문자로 취급하여 유니코드로 변환한다. 이렇기에 server.xml에 설정을 해주지 않을 경우 한글이 깨지게 된다.

 

[ SeverletContext 보관소 ]

웹 애플리케이션이 시작될 때 생성되어 웹 애플리케이션이 종료될 때까지 유지된다. 이 보관소에 데이터를 보관하면 웹 애플리케이션이 실행되는 동안에는 모든 서블릿이 사용할 수 있다.

 

[ HttpSession 보관소 ]

클라이언트의 최초 요청 시 생성되어 브라우저를 닫을 때까지 유지됩니다. 보통 로그인할 때 이 보관소를 초기화하고, 로그아웃하면 이 보관소에 저장된 값들을 비웁니다. 따라서 이 보관소에 값을 보관하면 서블릿이나 JSP 페이지에 상관없이 로그아웃하기 전까지 계속 값을 유지할 수 있습니다. JSP에서는 session변수를 통해 이 보관소를 참조할 수 있습니다.

 

[ ServletRequest 보관소 ]

클라이언트의 요청이 들어올 때 생성되어, 클라이언트에게 응답 할 때까지 유지됩니다. 이 보관소는 포워딩이나 인클루딩하는 서블릿들 사이에서 값을 공유할 때 유용합니다. JSP에서는 request변수를 통해 이 보관소를 참조할 수 있습니다.

 

[ JspContext 보관소 ]

JSP 페이지를 실행하는 동안만 유지됩니다. JSP에서는 pageContext 변수를 통해 이 보관소를 참조할 수 있습니다.

 

[ HttpSession ]

HttpSession 객체는 클라이언트 당 한 개가 생성됩니다. 웹 브라우저로부터 요청이 들어오면, 그 웹 브라우저를 위한 HttpSession 객체가 있는지 검사하고, 없다면 새로 HttpSession 객체를 만듭니다. 이렇게 생성된 HttpSession 객체는 그 웹 브라우저로부터 일정 시간 동안 Timeout 요청이 없으면, 삭제됩니다.

 

[ JspContext의 활용 ]

JSP 페이지를 작성하다 보면 <jsp:include>와 같은 특별한 태그를 사용하게 됩니다. 이런 태그들은 JSP 엔진이 서블릿 클래스를 생성할 때 특정 자바 코드로 변환됩니다. 이때 이 태그의 값을 다루는 객체를 '태그 핸들러'라고 부릅니다. 바로 이 태그 핸들러에게 데이터를 전달하고자 할 때 JspContext 보관소를 사용하는 것입니다.  JSP 페이지에 선언된 로컬 변수는 태그 핸들러에서 접근할 수 없습니다. 따라서 태그 핸들러에게 전달할 데이터가 아니라면 JspContext에 값을 보관할 필요가 없습니다.

 

[ EL(Expression Language) ]

EL(Expression Language)은 콤마(.)와 대괄호([])를 사용하여 자바 빈의 프로퍼티나 맵, 리스트, 배열의 값을 보다 쉽게 꺼내게 해주는 기술로 스태틱(static)으로 선언된 메서드를 호출 할 수도 있습니다. EL은 ${}와 #{}를 사용하여 값을 표현합니다. ${표현식} 으로 지정된 값은 JSP가 실행될 때 JSP 페이지에 즉시 반영됩니다. 그래서 ${}을 '즉시 적용(immediate evaluation)'이라 부릅니다. #{}을 '지연 적용(deferred evaluation)'이라 부르는데 UI를 만들 때 사용된다고 합니다.

 

[ DI(Dependency Injection) ]

작업에 필요한 객체를 외부로부터 주입 받는 것으로 다른 말로 역제어(IoC, Inversion of Control)'라고도 부릅니다.

 

[ mybatis ]

mybatis는 반복적이고 지루한 JDBC 프로그래밍을 단순화하기 위해 클린턴 비긴이 만든 작은 라이브러리에서 출발하였다. 이 라이브러리는 iBATIS라는 이름으로 2004년 아파치 소프트웨어 재단에 기부되면서 알려지게 되었다. 좀 더 효율적인 개발 관리를 목표로 2010년 6월 아파치 재단에서 구글 코드로 이사하였고 프로젝트 이름도 mybaits로 바뀌었다. mybatis의 핵심은 개발과 유지보수가 쉽도록 소스 코드에 박혀있는 SQL을 별도의 파일로 분리하는 것이다. 또한 단순하고 반복적인 JDBC 코드를 캡슐화하여 데이터베이스 프로그래밍을 간결하게 만드는 것이다.

 

[ mybatis javaType속성 ]

<result>에서 javaType을 사용하면, 칼럼의 값을 특정 자바 객체로 변환할 수 있다. 다음과 같이 'STA_DATE'칼럼에 대해 javaType을 java.sql.Date으로 설정하면, 칼럼 값을 꺼낼 때 그 객체로 변환된다.

<result column="STA_DATE" property="startDate" javaType="java.sql.Date"/>

 

[ mybatis <id> 엘리먼트 ]

SELECT 문을 실행하면 레코드 값을 저장하기 위해 결과 객체가 생성되는데, SELECT문을 실행할 때마다 매번 결과 객체를 생성한다면 실행 성능이 나빠질 것입니다. 이를 해결하기 위해 SELECT를 통해 생성된 결과 객체들은 별도의 보관소에 저장(캐싱, caching)해두고, 다음 SELECT를 실행할 때 재사용합니다. 이때 보관소에 저장된 객체를 구분하는 값으로 <id>에서 지정한 프로퍼티를 사용합니다.

 

[ mybatis의 SELECT 결과 캐싱 ]

SELECT를 실행할 때마다 결과 레코드에 대해 매번 객체를 생성한다면, 속도도 느리고 메모리도 낭비됩니다. 이를 개선하기 위해 mybatis는 객체 캐싱을 제공합니다. 즉 한 번 생성된 객체는 버리지 않고 보관해 두었다가, 다음 SELECT를 실행할 때 재사용하는 것입니다. 첫 번째 질의를 수행할 때 생성된 결과 객체는 풀(pool)에 보관해 둡니다. 두 번째 질의에서는 질의 결과에 대해 새로 객체를 생성하기 전에, 객체 풀에 보관된 객체 중에서 해당 칼럼의 값과 일치하는 객체를 먼저 찾습니다. 있다면 기존 객체를 사용하고 없다면 새로 객체를 생성합니다. 이것이 mybatis의 객체 캐싱 기법입니다.

 



반응형
반응형

 


 이번에는 최근에 읽은 책인 '읽기 좋은 코드가 좋은 코드다'에 대해서 리마인드도 할겸 조금이라도 생각하게 만들었던 문장들에 대해 정리해보는 시간을 가지도록 하겠습니다. 책을 읽으면서 그동안 저의 안좋았던 코딩 습관들에 대해서 다시 한 번 돌아보는 시간을 가졌고 뭔가 어렵게 짜려고 하기 보다는 심플하면서도 읽기 좋은 코드를 짜도록 노력해야겠다고 다짐하며 정리를 시작하도록 하겠습니다. 가볍게 한 번 읽어주시면 좋을 것 같습니다.



⇒ 코드는 다른 사람이 그것을 이해하는 데 들이는 시간을 최소화하는 방식으로 작성되어야 한다.


⇒ Alt + / = 자동완성(이클립스) >> 그동안 ctrl+space를 많이 사용했는데 옆의 명령어는 바로 자동완성을 해주는 기능


⇒ 팀에 새로 합류한 사람이 이름이 의미하는 바를 이해할 수 있을까? 만약 그렇다면 그 이름은 괜찮은 것이다. (네이밍의 중요성, 내 주관적인 의미에만 집중해서 작성하지 않기!!!)


⇒  대상을 자세히 묘사하는 구체적인 이름을 사용하라. ex) ServerCanStart()보다는 CanListenOnPort()


⇒ 변수명에 중요한 세부 정보를 덧붙여라. 예를 들어 밀리초의 값을 저장하는 변수 뒤에 _ms를 붙이거나 이스케이핑을 수행하는 변수의 앞에 raw_를 붙이는 것이다. 


⇒ 본인이 지은 이름을 "다른 사람들이 다른 의미로 해석할 수 있을까?"라는 질문을 던져보며 철저하게 확인해야 한다.


⇒ 경계를 포함하는 한계 값을 다룰 때는 min과 max를 사용하라.(start, end보다는 경계를 표현하기 위해서는 min, max가 더 정확)


⇒ 주석의 목적은 코드를 읽는 사람이 코드를 작성한 사람만큼 코드를 잘 이해하게 돕는 데 있다.


⇒ 코드에서 빠르게 유추할 수 있는 내용은 주석으로 달지 말자.(너무 뻔한 내용들에 대해서는 주석으로 남기지 않는다.)


⇒ 일반적으로 사람들은 코드가 가진 나쁜 가독성을 메우려고 노력하는 '애쓰는 주석'을 원하지 않는다. 프로그래머들은 이러한 규칙을 대개 좋은 코드 > 나쁜 코드 + 좋은 주석이라는 공식으로 설명한다. (나쁜 코드를 짜고 주석을 다는 방식이 아닌 누가 봐도 이해할 수 있는 좋은 코드를 짜는데 집중하자)


⇒ 좋은 주석은 단순히 '자신의 생각을 기록하는 것' 만으로도 탄생할 수 있다. 즉, 코딩할 때 생각했던 중요한 생각을 기록하면 된다. ex) 놀랍게도, 이 데이터에서 이진트리는 해시테이블보다 40%정도 빠르다. 


⇒ 작성하는 코드의 이러저러한 내용을 훗날 수정할 거라는 생각이 들면, 그러한 생각을 주석으로 작성하는 일은 당연하게 받아들여야 한다는 사실이다. 주석은 코드를 읽는 사람에게 코드의 질이나 상태 그리고 추후 개선 방법 등을 제시하여 소중한 통찰을 제공한다.


⇒ 상세하고 공식적인 문서를 작성해야 한다는 생각에 압도당하지 말라. 잘 선택된 몇몇 문장이 아무것도 없는 것보다는 훨씬 나은 법이다.


⇒ 주석을 다는 목적은 코드를 작성하는 사람이 알고 있는 정보를 코드를 읽는 사람에게 전달하는 것이다. 


[ 주석으로 설명하지 말아야 하는 것 ]


:: 코드 자체에서 재빨리 도출될 수 있는 사실


:: 나쁜 함수명과 같이 나쁘게 작성된 코드를 보정하려고 '애쓰는 주석'. 그렇게 하는 대신 코드를 수정하라.



[ 주석으로 기록해야 하는 것 ]


:: 코드가 특정한 방식으로 작성된 이유를 설명해주는 내용


:: 코드에 담긴 결함. TODO:혹은 XXX:와 같은 표시를 사용


:: 어떤 상수가 특정한 값을 갖게 된 '사연'


⇒ 기본적으로 if/else를 이용하라. ?: 를 이용하는 삼항 연산은 매우 간단할 때만 사용해야 한다. (삼한 연산자로 표현은 간결해지지만 오히려 읽기 이해하기 힘들어지는 연산들이 있다. 이때는 삼한 연산자보다는 읽기 쉽게 if/else를 사용하여 코딩하도록 하자.)


⇒ "전역 변수를 피하라". 전역 변수는 어디에서 어떻게 사용되는지 일일이 확인하기 어려우므로 이는 합당한 조언이다. 또한, 전역 변수의 이름과 지역 변수의 이름이 중복되어 이름공간이 더러워 질 수도 있고, 어떤 코드가 지역 변수를 변경할 때 실수로 전역 변수를 변경하거나 혹은 그 반대의 경우가 일어 날 수 있다.


⇒ 할머니에게 설명할 수 없다면 당신은 제대로 이해한 게 아닙니다. -알버트 아인슈타인 (참 맞는말이다. 무엇인가를 이해했다는 건 해당 지식이 전무한 사람에게도 설명할 수 있어야 한다. 그만큼 제대로 된 이해는 중요하다 )


⇒ 복잡한 생각을 다른 사람에게 설명할 때 중요하지 않은 자세한 내용 때문에 듣는 사람을 혼동시키는 일이 종종 있다. '쉬운 말'로 자신의 생각을 지식이 부족한 사람에게 전달하는 기술은 매우 소중하다. (누군가에게 설명하기 위해서는 해당 부분에 대한 완벽한 이해가 수반되어야 함을 명심하자. 이해하면 설명하고 싶어진다 by 김동범)


⇒ 일반적인 '유틸리티'를 많이 생성하여 중복된 코드를 제거하라.


⇒ 사용하지 않는 코드 혹은 필요 없는 기능을 제거하라.


⇒ 코드를 제거하는 작업을 코딩을 하는데 투자한 시간이 쓸모 없는 시간이었다고 여기는 사고를 버려야 한다. 프로그래밍은 창의력을 요구하는 분야다. 사진사, 작가, 영화감독 같은 사람은 모든 작업 결과를 보존하지 않는다. (코드 리무버가 되기 위해서는 해당 소스 코드에 대한 정확한 이해와 판단이 필요하다. 즉 아무나 코드를 제거할 수 없다.)


⇒ 매일 15분씩 자신의 표준 라이브러리에 있는 모든 함수/모듈/형들의 이름을 읽어라. 라이브러리 전체를 암기하라는 게 아니다. 그냥 그 안에 무엇이 있는지 감을 잡아놓고, 나중에 새로운 코드를 작성할 때 "잠깐만, 이건 전에 API에서 보았던 것과 뭔과 비슷한데..."하고 생각할 수 있기를 바라는 것이다.


⇒ 다른 프로그래머는 종종 테스트 코드를 실제 코드가 어떻게 동작하며 어떻게 사용되어야 하는지에 관한 비공식적인 문서라고 생각한다. 따라서 테스트 코드가 읽기 쉬우면, 사용자는 실제 코드가 어떻게 동작하는지 그만큼 더 쉽게 이해할 수 있다. (테스트 코드의 중요성)


이렇게 리마인드 할 겸 내용을 정리해 보았는데 정리하면서 다시 한 번 머리에 각색이 된 것 같다. 앞으로도 꾸준히 코드를 작성함에 위의 내용들에 유의하며 작성할 수 있도록하고 꾸준히 해당관련 도서 (리팩토링, 클린코드)등을 읽으며 리마인드 해보는 것도 많이 도움이 될 것 같다. 이상으로 포스팅을 마친다.


 




반응형
반응형

 


  안녕하세요. 오늘은 Fiddler를 통해 모바일 웹을 디버깅 하는 법에 대해서 포스팅 해보도록 하겠습니다. 보통 웹 업무를 하다보면 fiddler를 많이 사용하게 되는데 이번 작업을 하던 중 모바일 웹에서 기능 수정 한 부분에 대해서 확인해야 하는 상황이 있었습니다. 하지만 어떻게 해야 할지 도무지 감도 안 오고 그저 생각나는 방법은 '알파나 베타에 수정한 부분을 배포해서 확인을 해야하나?'였습니다. 하지만 fiddler를 사용하면 로컬환경에서도 모바일 웹을 디버깅 할 수 있다는 점! 지금 부터 시작하도록 하겠습니다. 


 1. Filddler란 무엇이냐

 : "웹 트래픽을 모니터링, 조사, 조작할 수 있는 확장 기능을 갖춘 프리웨어 디버깅 프록시"라고 정리 되어 있는 글을 본 적이 있는데 말 자체가 너무 어렵네요. 단순히 말해 클라이언트와 서버가 요청과 응답을 한 번씩 주고 받은 세션의 목록을 보여주는 프리웨어라고 볼 수 있습니다. 말은 이렇게 단순히 했지만 피들러로 할 수 있는 일들은 어마어마 하다는 거


 피들러로 할 수 있는 일


   ⊙ 브라우저, 클라이언트 프로그램, 서비스 등에서 오고 가는 웹 트래픽을 볼 수 있다.

   ⊙ 자동 또는 수동적인 방법으로 어떠한 응답이나 요청도 수정할 수 있다.

   ⊙ HTTPS 트래픽을 복호화하여 살펴보거나 수정하는 것도 가능하다.

   ⊙ 캡쳐한 트래픽을 저장하여 보관해 두고 후에 불러올 수도 있다. 다른 컴퓨터의 트래픽도 이런 식으로 다룰 수 있다.

   ⊙ 클라이언트 프로그램으로 가는 응답을 이전에 캡쳐해 두어 서버가 오프라인 상태라 해도 응답을 재현할 수 있다.

    맥/리눅스 시스템, 스마트폰, 태블릿 컴퓨터 등을 포함한 대부분의 PC와 모바일 기기에서 발생한 웹 트래픽을 디버깅할 수 있다.

   ⊙ TOR 네트워크 등 프록시 서버에 업스트림(upstream)을 연결(chain)할 수 있다.

   ⊙ 클라이언트 컴퓨터나 모바일 기기를 다시 설정하지 않고도 역 프록시(reverse proxy)로 동작하여 트래픽을 캡쳐할 수 있다.

   ⊙ 피들러 스크립트나 .NET 기반 확장 모듈을 통해 새로운 기능을 추가할 수 있어 더 강력해질 수 있다.


 


 그림을 통해 보면 내가 요청한 페이지에 대한 세션 정보와 해당 서버측에서 넘어온 세션 정보 등을 파악 할 수 있습니다. 그럼 이제 본격적으로 모바일 웹을 디버깅 하기 위해서는 어떤 설정들이 필요한지 알아 보도록 합시다.



 2. 모바일 웹을 디버깅하기 위한 Fiddler의 설정 첫 번째

 Fiddler를 키고  상단의 Tools > Fiddler Options 를 클릭하면 밑과 같은 창이 뜨는데 Connections 탭에서 Allow remote computers to connect 칸에 체크를 해줍니다. 말 그대로 외부 기기가 연결될 수 있도록 허용해주는 설정입니다.



  2. 모바일 웹을 디버깅하기 위한 Fiddler의 설정 두 번째 ( 모바일 와이파이 설정 셋팅 )


 Fiddler에서 위와 같은 설정을 맞췄다면 이제 해당 Fiddler에 붙기 위해 사용하고 있는 와이파이 설정을 해줘야 합니


다. 와이파이 설정을 들어가 고급 옵션 표시 항목에 체크를 하면 다음과 같은 화면을 볼 수 있습니다. 프록시를 수동으


로 바꿔주고 프록시 호스트 이름에 fiddler가 설치된 PC의 IP를 입력해 줍니다. 그리고 프록시 포트 부분에는 위의 그


림에서 Fiddler listens on port란에 쓰여있는 포트번호를 적어주고 저장해주면 됩니다. 


  

3. 모바일 웹을 디버깅하기 위한 Fiddler의 설정 세 번 째 ( 로컬 환경으로 호스트 셋팅 )

실제로 모바일 화면에서 웹을 띄워 내가 작성한 코드가 잘 수정되었는지 확인하기 위하여 fiddler에서 Host를 맞춰 줍니다. Fiddler 상단의 Tools를 누르면 HOSTS...라는 항목이 보이고 클릭하게 되면 Host Remapping이라는 창이 뜨게 되고 여기에 호스트 설정을 해주면 됩니다. 


  

4. 모바일에서 접속해 보기

 실제로 모바일로 작업하고자 하는 url에 접속하게 되면 fiddler에 내가 보낸 요청들의 세션이 찍히는 것을 볼 수 있다. 또한 로컬에서 디버깅으로 프로젝트를 띄워논 후 모바일로 해당 페이지에 접속하게 되면 디버깅이 걸려 들어오는 것 까지 확인할 수 있었다. 

 


이렇게 Fiddler를 통해 모바일 웹을 테스트 할 수 있는 방법에 대해서 알아보았다. 혹시나 와이파이 설정 및 fiddler 설정을 다했는데도 제대로 접속이 안되는 경우 디바이스를 재부팅하거나 피들러를 다시 껏다 킨 후 다시 접속해 보기 바란다. 이상으로 이번 포스팅을 마치겠다.





반응형

+ Recent posts