Dean Story

출처

: https://www.baeldung.com/java-wrapper-classes

: http://jusungpark.tistory.com/17

: https://code.i-harness.com/ko-kr/q/20930e

1. 정의: 

wrapper classes are objects encapsulating primitive Java types.

기본형(primitive type)을 객체로 이용될 수 있게 기본형 데이터를 감싼 클래스이다.

2. 종류:

• primitive type에는 boolean, byte, short, char, int, long, float, double 등 
• non-primitive type이자, reference type인 wrapper class에는 Boolean, Byte, Short, Character, Integer, Long, Float, Double 등

Boolean, Character, Number는 Object class의 자식에 해당하고

모든 숫자와 관련된 wrapper 클래스(Byte. Short, Integer, Long, Float, Double, BigInteger, BigDecimal)들은 모두 Number class의 자식에 해당한다.

3. wrapper class를 사용하는 이유? 

자바 Collection 인터페이스는 객체만 취급하기 때문에 primitive type을 객체로 boxing(또는 wrapping)하여 사용해야 하는 경우가 있다.  

예를 들어, 매개변수로 객체가 요구되는 경우, 기본형이 아닌 객체로 저장해야 하는 경우, 객체간의 비교가 필요한 경우 등에 wrapper class가 쓰인다.

4. Auto Boxing/Unboxing

자바 컴파일러는 기본형 데이터를 자동으로 객체로 변환하여 처리할 수 있는 Auto Boxing을 지원하며,

객체를 자동으로 기본형 데이터로 변환하여 처리할 수 있는 Auto Unboxing을 지원한다.

Object[] objs = new Object[100];
int a = 1;

//Auto Boxing
objs[0] = a;

//Auto Unboxing
int b = (Integer)objs[0];

참고

: http://yacht.yonsei.ac.kr/doku.php?id=yais:linux:manage:gpg

: https://ko.wikipedia.org/wiki/GNU

1. GPG(GNU Privacy Guard) 개념

GPG (GNU Privacy Guard)는 파일의 암호화 및 파일의 무결성 점검 등에 이용할 수 있다. GPG를 이용하여, 암호화를 위한 키를 생성하고 파일들을 암호화 할 수 있다.

암호화 키는 다른 사람들에게 제공할 수 있는 public key와 그 public key로 암호화된 자료를 풀 때 쓰이는, 자신만이 가지게 되는 private key로 이루어진다. 

따라서, 다른 사람들이 자신의 public key로 파일을 암호화 해서 보내주게 되면, 오직 본인만이 자신이 가진 private key를 이용해서 암호를 풀고 원 자료를 획득할 수 있다.

2. GNU(GNU's Not Unix) 개념

GNU는 운영체제 중 하나로서, 컴퓨터 소프트웨어의 모음집이다. GNU는 온전히 자유 소프트웨어로 이루어져 있으며, 그 중 대부분이 GNU 프로젝트의 GPL로 라이센스된다.

"GNU's Not Unix!"(GNU는 유닉스가 아니다!)의 재귀 약자이며, 이렇게 선정된 이유는 GNU의 디자인이 유닉스 계열이지만 자유 소프트웨어인 점과 유닉스 코드를 포함하지 않는다는 점에서 차별을 두려는 것이다.

GNU 프로젝트는 운영체제 커널, GNU HURD를 포함하고 있으며 이는 자유 소프트웨어 재단(FSF)에서 본래 초점을 두고 있었던 것이다.

그러나 GNU가 아닌 커널(가장 유명한 것으로 리눅스)은 GNU 소프트웨어와 함께 사용할 수도 있다. 즉, 허드(Hurd) 커널은 아직 운영용으로 준비되지는 않았는데, 이는 어떻게 GNU 시스템이 일반적으로 사용되고 있는지를 설명한다.

GNU 소프트웨어와 리눅스 커널의 결합은 리눅스(또는 GNU/리눅스)로 알려져 있다.

비교 연산자 ==는 primitive 변수 간의 값의 동일여부를 비교하는 것인데, objective 변수끼리 비교하게 되면, 그 객체의 주소값의 동일여부를 비교하게 된다. 

equals() 메소드는 문자열 간의 값의 동일여부를 비교하는 것이다.

참고: http://inpiringblog.blogspot.com/2015/07/try-catch-finally.html

try {

// 프로그램 실행 로직

} catch(Exception e) {

// 예외발생 시의 로직

} finally {

/* 

1. 기본 실행 순서:

try문에서 예외가 발생하지 않았으면 catch문은 생략되어 try문이 실행된 이후에 finally문이 실행되고, 

try문에서 예외가 발생했으면 try문, catch문 순서로 실행된 이후에 finally문이 실행된다.

try문이나 catch문 안에 return문 또는 throw문이 있다면, 그 return문 또는 throw문 전까지 로직이 실행된 후 finally문이 실행되고 나서 그 return문 또는 throw문이 실행된다(결론적으로 finally문은 무조건 실행된다).

2. catch문과 finally문 안에 throw문이 있는 경우:

try문에서 예외가 발생했으면, finally문 안에 있는 throw문이 먼저 실행되기 때문에 catch문 안에 있는 throw문은 실행되지 않는다.

*/

}

출처: https://stackoverflow.com/questions/4674226/does-github-keep-deleted-remote-branches-in-history-if-so-can-those-be-restore  

* 로컬 Git log를 이용하여 복원 작업이 이루어지기 때문에, 가장 최근에 해당 브랜치를 이용했던 사람이 branch 복원 작업을 진행해야 최신 상태로 복원 가능.

1. 해당 프로젝트의 로컬 directory 경로로 이동

2. 마우스 오른쪽 클릭 후, 'Git Bash Here' 클릭

4. Command창에 아래 순서대로 명령어 입력

   4-1. 아래 명령어를 입력하여 Git log 기록을 조회하고 해당 branch의 commit id 확인

         $ git reflog

   4-2. 아래 명령어를 입력하여 해당 commit id 상태인 로컬 branch 체크아웃

         $ git checkout -b [로컬 branch 이름] [commit id]

3. IntelliJ의 상단 메뉴에서 'VCS' 클릭 > 'Git' 클릭 > 'Fetch' 클릭

   : 해당 로컬 branch 이름으로 체크아웃되었는지 확인

4. IntelliJ의 상단 메뉴에서 'VCS' 클릭 > 'Git' 클릭 > 'Push' 클릭

   : 해당 로컬 branch를 push하여 원격 branch로서 생성

     (참고로, push 시에는 로컬 branch 이름과 다르게 원격 브랜치 이름을 설정할 수 있다.)

참고: 

- https://stackoverflow.com/questions/6630887/using-is-null-or-is-not-null-on-join-conditions-theory-question

- https://community.teradata.com/t5/General/Is-Null-conditions-in-ON-Join-Vs-Is-Null-in-Where/td-p/50758

1. JOIN ON 절에 IS NULL 체크 관련 쿼리문 예시

select *

from TB_PARENT P with(nolock)

left outer join TB_CHILD C with(nolock)

on P.pid = C.pid 

and C.pid is null

결과: JOIN ON 조건문은 테이블들이 서로 JOIN되는 과정에서 적용된다. TB_CHILD 테이블의 pid 컬럼값이 NULL인 것은 없을 것이며 left outer join이 되고 나서야 NULL값이 생성되기 때문에, 위의 JOIN ON 조건은 항상 false가 되어 LEFT OUTER JOIN문은 왼쪽 테이블(TB_PARENT)의 모든 ROW를 반환할 때, 오른쪽 테이블(TB_CHILD) 관련 컬럼값을 NULL로 채워 반환한다. 따라서, 자식이 없는 부모 데이터를 찾을 수 없다.

2. WHERE 절에  IS NULL 체크 관련 쿼리문 예시

select *

from TB_PARENT P with(nolock)

left outer join TB_CHILD C with(nolock)

on P.pid = C.pid

where C.pid is null  

결과: WHERE 조건문은 테이블들이 서로 JOIN된 후에 적용된다. 왼쪽 테이블(TB_PARENT)과 오른쪽 테이블(TB_CHILD)이 LEFT OUTER JOIN되고 나서 where 조건문이 적용되기 때문에 자식이 없는 부모 데이터를 찾을 수 있다.

출처: 

- https://m.blog.naver.com/PostView.nhn?blogId=njk118&logNo=220701895258&proxyReferer=https%3A%2F%2Fwww.google.co.kr%2F

- http://ukjin.tistory.com/130

1. e.getMessage() vs e.toString() vs e.printStackTrace()

e.getMessage(): error 이벤트와 함께 들어오는 메세지를 출력.

e.toString(): error 이벤트의 toString()을 호출해서 간단한 error 메세지 출력.

e.printStackTrace(): error 메세지의 발생 근원지를 찾아서 단계적으로 error를 출력.

2. log4j에서 e.printStackTrace() 메세지를 log에 남기는 방법

logger.error("some error occured!!", e);

또는

logger.debug("some error occured!!", e);

출처: http://blog.bizmerce.com/?p=2533

       https://engineering.linecorp.com/ko/blog/detail/319

1. 정의:

   orchestration은 기능적으로 보다 높은 수준으로 인프라를 관리할 수 있는 automation 작업이다. 

2. 관련 도구:

   - 설정 관리 도구:  Chef, Puppet, Ansible, SaltStack 등

   - CI/CD 관리 도구: Travis CI, Jenkins, Circle CI 등

   - 컨테이너 관리 도구: Docker swarm, Kubernetes 등

출처: https://engineering.linecorp.com/ko/blog/detail/319

       http://bcho.tistory.com/948

- Monolithic Architecture: 하나의 애플리케이션 내에 서비스를 담는 개발 방법론으로서, 개발, 배포, 확장을 단순화하는 장점이 있다.

1. 정의:

   하나의 애플리케이션을 서비스 단위로 구분하여 하나의 기능에 대해 여러 서비스를 조합하여 제공하며 독립적으로 개발, 배포, 확장할 수 있는 개발 방법론.

2. 장점:

   - 코드 이해와 수정이 쉬워진다.

   - 어떤 기능에서 문제가 발생하더라도 다른 기능에 영향을 주지 않아 장애 처리가 쉬워진다.

3. 단점:

   - 성능 저하

     ㄴ서비스간의 호출을 API 통신을 이용하기 때문에 값을 json이나 xml에서 프로그래밍에서 사용하는 데이타 모델 (java object등)으로 변환하는 marshalling 오버헤드가 발생하고 호출을 위해서 이 메세지들이 네트워크를 통해서 전송되기 때문에 그만한 시간이 더 추가로 소요된다.

   - 메모리 요구량 증가

     ㄴ각 서비스를 독립된 서버에 분할 배치하기 때문에, 중복되는 모듈에 대해서 그만큼 메모리 사용량이 늘어난다.

   - 테스팅이 어려워진다.

     ㄴ서비스들이 각각 분리가 되어 있고, 다른 서비스에 대한 종속성을 가지고 있기 때문에, 특정 사용자 시나리오나 기능을 테스트하고자 할 경우 여러 서비스에 걸쳐서 테스트를 진행해야 하기 때문에 테스트 환경 구축이나 문제 발생시 분리된 여러개의 시스템을 동시에 봐야 하기 때문에 테스팅의 복잡도가 올라간다.

   - 운영이 어려워진다.

     ㄴ서비스 별로 서로 다른 기술을 사용할 수 있으며, 시스템이 아주 잘게 서비스 단위로 쪼게 지기 때문에 운영을 해야할 대상 시스템의 개수가 늘어나고, 필요한 기술의 수도 늘어나게 된다.

   - 서비스 간의 트랜잭션 처리가 어려워진다.

     ㄴMonolithic Architecture에서는 RDBMS를 사용하면서 하나의 애플리케이션 내에서 트랜잭션이 문제가 있으면 쉽게 데이타베이스의 기능을 이용해서 rollback을 할 수 있었다. 여러개의 데이타베이스를 사용하더라도, 분산 트랜잭션을 지원하는 트랜잭션 코디네이터 (JTS – Java Transaction Service)등을 이용해서 쉽게 구현이 가능했는데, API 기반의 여러 서비스를 하나의 트랜잭션으로 묶는 것은 불가능 하다. 쉽게 예를 들어서 설명을 하면, 계좌에서 돈을 빼는 서비스와, 계좌에 돈을 넣는 서비스가 있다고 하자. 이 둘은 API를 expose했을 때, 계좌에서 돈을 뺀 후, 계좌에 돈을 넣기 전에 시스템이 장애가 나면, 뺀 돈은 없어지게 된다. Monolithic Architecture를 사용했을 경우에는 이러한 문제를 트랜잭션 레벨에서 롤백으로 쉽게 해결할 수 있지만 API 기반의 Microservice Architecture에서는 거의 불가능하다. 

  이러한 문제를 해결하기 위해서 몇가지 방안이 있는데,

  그 첫번째 방법으로는 아예 애플리케이션 디자인 단계에서 여러개의 API를 하나의 트랜잭션으로 묶는 분산 트랜잭션 시나리오 자체를 없애는 방안이다. 분산 트랜잭션이 아주 꼭 필요할 경우에는 차라리 모노리틱 아키텍쳐로 접근하는 것이 맞는 방법이다. 앞서도 언급했듯이 마이크로 서비스 아키텍쳐의 경우, 금융이나 제조와 같이 트랜잭션 보장이 중요한 엔터프라이즈 시스템보다는 대규모 처리가 필요한 B2C 형 서비스에 적합하기 때문에, 아키텍쳐 스타일 자체가 트랜잭션을 중요시 하는 시나리오에서는 적절하지 않다.

  그럼에도 불구하고, 트랜잭션 처리가 필요할 경우, 트랜잭션 실패시 이를 애플리케이션 적으로 처리해 줘야 하는 데, 이를 보상 트랜잭션(compensation transaction)이라고 한다. 앞의 계좌 이체 시나리오에서 돈을 뺀 후, 다른 계좌에 넣다가 에러가 났을 경우에, 명시적으로, 돈을 원래 계좌로 돌려주는 에러 처리 로직을 구현해야 한다.

  마지막 방법으로 복합 서비스 (composite service)라는 것을 만들어서 활용하는 방법이 있는데, 복합 서비스란 트랜잭션을 묶어야 하는 두개의 시스템을 트랜잭션을 지원하는 네이티브 프로토콜을 이용해서 구현한 다음 이를 API로 노출 시키는 방법이다.

두개의 데이타 베이스는 XA(eXtended Architecture)와 같은 분산 트랜잭션 프로토콜을 써서 서비스를 개발하거나 또는 SAP나 Oracle 아답터와 같이 트랜잭션을 지원하는 네이티브 아답터를 사용하는 방법이다. 기존에 SOA에서 많이 했던 접근방법이기는 하나, 복합 서비스를 사용할 경우, 복합서비스가 서로 다른 두개의 서비스에 걸쳐서 tightly coupled하게 존재하기 때문에, 마이크로 서비스 아키텍쳐의 isolation(상호 독립적)인 사상에 위배되고 서비스 변경시에 이 부분을  항상 고려해야 하기 때문에 아키텍쳐상의 유연성이 훼손되기 때문에 꼭 필요하지 않은 경우라면 사용하지 않는 것이 좋다.

>참고: http://www.dbguide.net/dbqna.db?cmd=view&boardUid=143789&boardConfigUid=31&boardStep=0&categoryUid=206

>참고: https://www.codeproject.com/Tips/81400/Useful-DateTime-Functions

-- 특정 월의 N번째 특정 요일에 해당하는 날짜 찾기

DATEADD(wk, DATEDIFF(wk,0, dateadd(dd,[특정 요일을 구하는 경우의 N번째주에 존재할 수 있는 최대일수]-datepart(day,[MONTH]),[MONTH])), [DAY])

ㄴ [특정 요일을 구하는 경우의 N번째주에 존재할 수 있는 최대일수] 

ex1) 일요일 => 첫번째주:7, 두번째주:14, 세번째주:21, 네번째주:28 

ex2) 월요일 => 첫번째주:6, 두번째주:13, 세번째주:20, 네번째주:27 

ex3) 화요일 => 첫번째주:5, 두번째주:12, 세번째주:19, 네번째주:26 

ex4) 수요일 => 첫번째주:4, 두번째주:11, 세번째주:18, 네번째주:25

ex5) 목요일 => 첫번째주:3, 두번째주:10, 세번째주:17, 네번째주:24

ex6) 금요일 => 첫번째주:2, 두번째주:9, 세번째주:16, 네번째주:23

ex7) 토요일 => 첫번째주:1, 두번째주:8, 세번째주:15, 네번째주:22

ㄴ [MONTH]: 찾고자 하는 월의 날짜 (데이터타입은 datetime 또는 'yyyyMMdd')

ㄴ [DAY]: 찾고자 하는 요일의 값 (-1:일요일, 0:월요일, 1:화요일, 2:수요일, 3:목요일, 4:금요일, 5:토요일)

예) 

-- 이번달의 1~4번째 일요일에 해당하는 날짜 찾기

select DATEADD(wk, DATEDIFF(wk,0, dateadd(dd,7-datepart(day,getdate()),getdate())), -1) -- 첫번째 일요일 날짜

select DATEADD(wk, DATEDIFF(wk,0, dateadd(dd,14-datepart(day,getdate()),getdate())), -1) -- 두번째 일요일 날짜

select DATEADD(wk, DATEDIFF(wk,0, dateadd(dd,21-datepart(day,getdate()),getdate())), -1) -- 세번재 일요일 날짜

select DATEADD(wk, DATEDIFF(wk,0, dateadd(dd,28-datepart(day,getdate()),getdate())), -1) -- 네번째 일요일 날짜

-- 이번달의 1~4번째 화요일에 해당하는 날짜 찾기

select DATEADD(wk, DATEDIFF(wk,0, dateadd(dd,5-datepart(day,getdate()),getdate())), -1) -- 첫번째 화요일 날짜

select DATEADD(wk, DATEDIFF(wk,0, dateadd(dd,12-datepart(day,getdate()),getdate())), -1) -- 두번째 화요일 날짜

select DATEADD(wk, DATEDIFF(wk,0, dateadd(dd,19-datepart(day,getdate()),getdate())), -1) -- 세번재 화요일 날짜

select DATEADD(wk, DATEDIFF(wk,0, dateadd(dd,26-datepart(day,getdate()),getdate())), -1) -- 네번째 화요일 날짜