양's World

Camel case, Kebab case, Snake case 그리고 Pascal case

프로그래밍에서의 공백 제거

프로그래밍을 할 때 우리는 보통 단어 사이의 공백을 제거하고 위의 나열된 방식 중에 하나로 문자열을 표현합니다.

왜냐하면 공백(Space)은 프로그램에서 특별한 목적의 키워드로써 활용되기 때문이지요.

예를 들어 나의 방문자수를 나타내기 위해 변수명을 짓는다고 생각해보면,

My Visitor Count로 변수명을 짓고 싶지만 대부분은 int myVisitorCount 형식으로 변환하여 사용합니다.

여기서 My Visitor Count -> myVisitorCount 로 바꾸는 데 사용되는 규칙이 Camel Case이며 이 밖에도 여러 변환 규칙이 있습니다. 하나씩 살펴보겠습니다.

Camel Case(카멜 케이스)

낙타의 쌍봉과 같이 문자열의 첫 문자를 제외하고 단어의 첫 글자마다 대문자로 표현하는 방식입니다. 많은 프로그램 언어에서 컨벤션으로 사용됩니다.

변환 전 : My Visitor Count

변환 후 : myVisitorCount

Kebab Case(케밥 케이스)

생각하시는 그 먹는 케밥이 맞습니다. 카멜 케이스와 달리 모두 소문자로 표현하며 단어와 단어 사이를 대시(-)를 이용하여 구분합니다. 스프링의 yml파일이나 url주소에서 사용됩니다.

변환 전 : My Visitor Count

변환 후 : my-visitor-count

Snake Case(스네이크 케이스)

케밥의 대시(-)와 다르게 언더스코어(_)를 구분자로 합니다. 모든 문자를 대문자로 나타내는 방식도 사용되며 주로 상수 표현 시에 사용됩니다.

변환 전 : My Visitor Count

변환 후 : my_visitor_count

변환 후 : MY_VISITOR_COUNT

Pascal Case(파스킬 케이스)

카멜 케이스와 유사하지만 첫 문자도 대문자로 표현합니다.

변환 전 : My Visitor Count

변환 후 : MyVisitorCount

템플릿 엔진(Template Engine)

템플릿 엔진이란 템플릿 양식과 입력 자료를 합성하여 결과 문서를 출력하는 소프트웨어를 말한다.
그 중 웹 템플릿 엔진은 브라우저에서 출력되는 문서를 위한 소프트웨어이다.

1. 고정적으로 사용될 부분을 템플릿을 미리 작성해 놓고
2. 동적으로 변경될 데이터 부분만 필요시 결합하여
3. 화면(문서)을 완성한다.

어디서 결합하냐에 따라 서버 사이드 템플릿 엔진과 클라이언트 사이드 템플릿 엔진으로 분류할 수 있다.

• 서버 사이드 템플릿 엔진 서버에서 데이터와 미리 정의된 템플릿으로 HTML을 완성하여 클라이언트에게 전달한다.
  Freemarker, Thymeleaf, Handlebars(Handlebars.java), JSP 등

• 클라이언트 사이드 템플릿 엔진
  데이터와 템플릿을 합쳐 클라이언트에서 HTML을 완성한다.
  서버는 api 콜에대한 응답데이터만 제공하면서 화면 랜더링은 클라이언트가 담당하는 구조가 가능하다.
  Handlebars(Handlebars.js), EJS(Embedded Javascript Templates) 등

클라이언트 사이드 템플릿 엔진의 필요성

• 계속해서 페이지를 이동하면서(서버에 데이터를 요청하면서) 화면이 변경되는 것이 아니라, 단일 화면에 특정 이벤트에 따라 화면이 변경되어야 하는 경우 javascript로 html을 변경해야 한다.
• 조작해야할 코드량이 많아지면 관리가 어려우므로 직접 javascript로 DOM을 제어하는 대신에 클라이언트 사이드 템플릿 엔진을 이용하면 좋다.

인텔리제이에서 Run/Debug Configuration을 들어가면 Configuration에서 지정할 수 있는 옵션중에 다음 3가지가 있다.
스프링부트에서 프로파일을 지정하고 싶어서 spring.profiles.active=dev 옵션을 주고 싶은데 지정할 포인트가 3가지나 있으니 혼란스러워 정리해보고자 한다.

VM options

JVM이 어플리케이션을 구동시키면서 참고할 옵션을 지정한다.
Intellij로 스프링부트 어플리케이션을 구동시 ‘dev’ 프로파일 설정을 주고 싶다면 -Dspring.profiles.active=dev 옵션을 지정한다.
콘솔화면 상단의 실행 커맨드에서 -D로 옵션이 지정되는걸 볼 수 있다.

Program arguments

자바 메인함수에 String[] args에 바인딩 될 프로그램 파라미터이다.

Intellij에서 옵션을 지정하면 콘솔화면 상단의 실행 커맨드에서 메인클래스 뒤에 인자로 들어가는걸 볼 수 있다.

spring.profiles.active=dev 로 지정시 메인함수의 String[] args 안에 spring.profiles.active=dev 문자열 자체가 들어가기는 하지만 스프링부트에서 프로파일로 인식되지는 않는다.(기본 default 프로파일로 동작한다.)
스프링부트에서 외부설정으로 인식되게 하기 위해서는 --spring.profiles.active=dev 처럼 ‘-‘를 2개 붙혀서 옵션을 줘야한다. 1개도 안된다 꼭 2개로 주자.

Environment variables

어플리케이션 구동시 OS의 환경변수에 더해서 지정해 줄 수 있는 key=value 옵션이다.
여러개를 지정하고 싶으면 세미콜론(;)으로 구분하여 지정한다. 설정에서 OS의 환경변수를 모두 제외시킬 수도 있다.
스프링부트 프로파일 옵션을 주고 싶다면 spring.profiles.active=dev 을 입력하며 된다.

3가지 방법으로 모두 프로파일 지정이 가능하며, 각기 다른 프로파일을 지정해서 우선순위를 테스트 해보면 Program arguments로 지정한 프로파일로 스프링부트가 동작한다.
두번째는 VM options, 마지막은 Environment variables 이다.

• VM options : -Dspring.profiles.active=dev
• Program arguments : —spring.profiles.active=dev « 우선순위가 제일 높다.
• Environment variables : spring.profiles.active=dev

읽어주셔서 감사합니다. 도움이 되셨다면 광고 클릭 부탁드립니다.

모두 힘내세요! : )

threshold

일단 위 단어를 찾으면 제일 먼저 나오는 뜻은 ‘문지방’이지만 프로그램에서 사용하는 의미는 임계치, 시작점 정도로 이해하면 될 듯 하다.

발단

SpringBoot + Quartz 로 배치관련 어플리케이션을 개발중에 스케쥴링 된 트리거를 정지(pause) 후 재개(resume)하는 기능을 개발하고 있었다. (Trigger는 Job이 실행될 시점이라고 이해하자.)
등록된 Trigger는 Quartz의 Scheduler 인터페이스 구현체에 의해 제어될수 있는데 다음과 같은 호출로 정지/재개한다.

서비스 클래스 코드의 일부이다. 생성된 스케쥴러 빈을 주입받아 TriggerKey를 인자로 등록된 Trigger를 제어한다.

@Autowired
Scheduler scheduler;

public void pause(TriggerKey triggerkey) throws SchedulerException {
    scheduler.pauseTrigger(triggerkey);
}

public void resume(TriggerKey triggerkey) throws SchedulerException {
    scheduler.resumeTrigger(triggerkey);
}

문제는 pause 후 몇 초가 지나고 resume을 해보면 이미 Trigger에 세팅된 시작시점이 지난 Trigger가 resume과 함께 시작해버린다. (실행 되어야 하나 실행하지 못하는 것은 misfire라 하며, Trigger에 misfire 정책을 MISFIRE_INSTRUCTION_DO_NOTHING 으로 했음에도 발생)

예를들어 매분 10초마다 실행되는 Trigger-Job이 있다고 하면,

• 0초에 해당 배치를 pause → 10초에 pause 상태이므로 실행 안됨 → 20초에 resume → 다음 분 10초에 실행

이런 동작을 기대했지만 실제로는 아래와 같이 되어버린다.

• 0초에 해당 배치를 pause → 10초에 pause 상태이므로 실행 안됨 → 20초에 resume과 함께 10초에 실행되어야 할 Trigger-Job이 실행 → 다음 분 10초에 실행

해결

Quartz에서는 misfireThreshold 값이 존재하고 디폴트가 60초로 세팅된다.
Trigger가 재개될 때는 두 가지 스탭으로 실행여부를 결정하는 것 같다.

1. nextFireTime(다음 실행시간)이 (현재시간 - misfireThreshold) 크면 실행한다. 작다면 2번에 따른다.
2. Trigger에 설정된 misfire 정책에 따라 실행한다.(MISFIRE_INSTRUCTION_DO_NOTHING이면 실행 안함)

즉, 나는 misfireThreshold가 60초 디폴트 설정 된 상태에서 60초가 지나기 전에 pause를 풀었으므로 misfire정책에 상관없이 즉시 실행이 되었던 것이다.

그래서 해결법은 misfireThreshold 를 짧게 설정 하던지, pause 후에 60초가 지나서 resume을 하면 된다.
misfireThreshold는 properties 설정으로 다음과 같이 설정할 수 있다.

패스워드 암호화의 이유

패스워드를 평문으로 저장하면 안 되는 이유는 데이터가 노출되었을 때 저장된 패스워드를 알아볼 수 없게 하기 위함이다. DB가 직접적으로 뚫렸거나, DB를 덤프한 파일이 유출되었거나 등 데이터가 유출되는 경로는 무수히 많다.

단방향 암호화 vs 양방향 암호화

단방향 암호화는 평문을 암호화한 값만 저장하고 복호화는 하지 않는(할 수 없는) 것이다. 공격으로 데이터가 뚫렸을 때 복호화가 불가능한 암호화문만 노출되므로 안전하다. 하지만 양방향 암호화의 경우 데이터와 함께 알고리즘과 키값이 함께 노출된다면 모든 데이터를 복호화할 수 있음으로 평문으로 저장한 것과 다르지 않게 된다. 그래서 비밀번호와 같이 암호화가 필요한 데이터는 보통 SHA-256을 포함한 단방향 해쉬 함수를 써서 저장한다. 사용자가 로그인을 시도하면 입력한 값의 암호화문과 저장된 암호화문을 비교하여 판단한다.

해시의 크랙

복호화가 어려운 해시함수를 사용하여 데이터를 저장한다 해도 100% 안전한 것은 아니다. 하드웨어의 발전으로 연산시간이 짧아짐에 따라 무차별적으로 때려 넣는 Brute Force Attack으로 뚫릴 수도 있다. 또한 해쉬 알고리즘이 복잡하여 Brute Force Attack으로는 시간이 오래 걸린다 하더라도 미리 가능한 패스워드 조합을 계산한 테이블(Rainbow Table)을 가지고 단순 비교만 수행하면 알고리즘의 복잡도와는 상관없이 빠른시간 안에 해킹될 가능성이 크다.

Salt Password

해쉬의 가장 큰 적인 Rainbow Table 에 대항하기 위한 효과적인 방법은 패스워드에 salt값(해싱에 추가하기 위한 임의의 값)을 추가하는 것이다.
평문 + salt 의 조합으로 해쉬값을 생성하기 때문에 Rainbow Table의 경우의 수를 엄청나게 늘리게 된다. 여기에 salt값의 길이도 최소 128bit 이상에 고정값이 아니라 랜덤값으로 사용한다면 더욱 안전해진다.

알고리즘

데이터를 공격하기 위한 노력과 비례하여 보호하기 위한 방법도 여러 가지가 있으며 이미 예전부터 많이 사용되는 암호화 알고리즘들이 개발되어 있다. 그중에서 골라 쓰면 된다!
추천 알고리즘 : PBKDF2, bcrypt, scrypt

SHA-256 (참고용으로 간단정리)

SHA(Secure Hash Algorithm)의 한 종류로 256비트로 구성되며 64자리 문자열을 반환한다. 경우의 수가 2^256 이므로 무차별 대입을 통한 공격에 비교적 안전하다.(SHA-512의 경우의 수는 2^512)
아주 작은 확률로 입력값이 다름에도 출력값이 같은 경우가 있으며 이를 충돌이라고 한다. 충돌의 발생 확률이 낮을수록 좋은 함수로 평가된다.
단방향(One-Way) 방식의 암호화기 때문에 암호화된 값을 다시 복호화 하는 것은 불가능하다.

하고싶은 작업

• 로컬에 이미지 파일을 가지고 있으며 해당 이미지 파일은 다른 곳에서 최신화가 이뤄진다.
• 원격의 이미지 파일이 최신화가 되었는지 HTTP 응답의 Lastmodified 헤더를 체크하여 로컬 이미지 파일을 최신화 한다.

RestTemplate

• 스프링부트 웹프로젝트이므로 이미 의존성으로 들어온 RestTemplate를 이용한다. 비동기 방식이지만 어플리케이션에 크게 영향을 주지 않으므로 사용한다.
• RestTemplate으로 HTTP 요청을 날려 응답의 LAST_MODIFIED 헤더를 체크한다.

ZonedDateTime, LocalDateTime

• HTTP 응답의 헤더는 타임존이 GMT로 되어있다.
• Asia/Seoul 지역의 시간으로 변경하여 기준일자와 비교한다.

테스트코드

@RunWith(SpringRunner.class)
@SpringBootTest
public class RestTemplateTest {
    @Autowired
    RestTemplateBuilder restTemplateBuilder;

    @Test
    public void RestTemplate를_이용하여_이미지_최신화() throws URISyntaxException {
        // 체크할 이미지 파일의 URL주소
        String imgSrc = "http://steamcdn-a.akamaihd.net/steam/apps/359550/capsule_sm_120.jpg";
        
        // 스프링부트의 빌더를 이용하여 RestTemplate 생성
        RestTemplate restTemplate = restTemplateBuilder.build();

        // 헤더만을 가져오도록 제공되는 메서드 사용
        HttpHeaders httpHeaders = restTemplate.headForHeaders(new URI(imgSrc));
        String lastModified = httpHeaders.get(HttpHeaders.LAST_MODIFIED).get(0);
        
        // 응답의 헤더는 GMT 시간
        System.out.println("lastModified : " + lastModified); // Fri, 21 Feb 2020 19:40:42 GMT

        // 응답의 시간에 맞는 포맷터를 지정하여 ZonedDateTime(Asia/Seoul) 객체 생성 
        ZonedDateTime lastModifiedZDT = ZonedDateTime.parse(lastModified, DateTimeFormatter.RFC_1123_DATE_TIME)
                                                     .withZoneSameInstant(ZoneId.of("Asia/Seoul"));
        System.out.println("lastModifiedZDT : " + lastModifiedZDT); // 2020-02-22T04:40:42+09:00[Asia/Seoul]

        // ZonedDateTime -> LocalDateTime
        LocalDateTime lastModifiedLDT = lastModifiedZDT.toLocalDateTime();
        System.out.println("lastModifiedLDT : " + lastModifiedLDT); // 2020-02-22T04:40:42

        // 기준일시를 생성하여 체크!
        LocalDateTime stdLDT = LocalDateTime.now().minusDays(1); // 기준일시(하루전) 생성
        if(lastModifiedLDT.isAfter(stdLDT)){ // 기준일시 이후에 변경이 일어나면
            System.out.println("다운로드(최신화) 필요함");
        }else{
            System.out.println("기존과 같음");
        }
    }
}

목표

• Maven에 대한 기본개념 이해
• Maven의 의존성 관리 빌드 자동화 이해

Maven

의존성 관리와 빌드 자동화 기능을 제공하는 툴이며, 프로젝트 내에서 pom.xml을 주설정파일로 하여 동작한다.

의존성 관리

개발시 사용하는 라이브러리에 대해 pom.xml을 기준으로 메이븐 저장소로부터 다운받아 개발자의 프로젝트에 추가해 준다. (로컬저장소의 .m2 폴더에 다운로드 되며 가끔 의존성이 꼬일경우 .m2 폴더 내용을 날려주면 해결되는 경우가 있었다.)

라이브러리 추가를 위해서는 <dependencies/> 이하에 <dependency/> 태그에 작성하며 groupId, artifactId, version 세가지 정보가 필요하다. 보통 maven repository 웹사이트에서 라이브러리를 검색하여 등록한다,

dependency에 <scope>의 경우 compile, runtime, provided, test등이 올 수 있는데 해당 라이브러리가 언제 필요한지, 언제 제외되는지를 나타낸다.

빌드 자동화

메이븐은 자바 프로젝트의 빌드(Build)를 자동화해 주는 빌드 툴(Build Tool)이다. 즉, 자바 소스를 컴파일하고 패키징하여 배포까지 자동으로 해주는 도구이다.

컴파일->패키징->배포 과정(maven build)에 대한 세부 설정값들은 pom.xml에 작성한다.

maven build는 LifeCycle이 존재하며, 메이븐에 내장된 라이프사이클은 default, clean, site 3가지가 있다.

라이프사이클은 세부적으로 페이즈(phase)로 구성되어 있다. 예를 들어 default 라이프사이클은 다음과 같이 7개의 페이즈로 구성되며(전부는 아니고 큰 줄기로하면) 이들 사이에는 실행순서가 존재한다.

mvn install 명령어로 install 페이즈를 실행하면 1번 validate 페이즈부터 6번 install 페이즈까지 순차적으로 실행되는 구조다. (deploy는 실행되지 않는다.)

1. validate
2. compile
3. test
4. package
5. verify
6. install
7. deploy

mvn 명령은 스페이스를 구분자로 여러동작을 한번에 지정할 수 있다.

mvn clean deploy : clean 페이즈 실행 후 1번 페이즈 validate부터 7번 페이즈 deploy까지 실행한다.

위의 Build Phase는 다시 Plugin Goal의 모음으로 이루어져 있다. Phase는 구체적인 작업을 나타내지는 않는다. 예를들어 package는 패키징된 결과물이 jar 파일이냐 war 파일이냐에 따라 다르게 수행되어야 하지만 Phase는 세부정보를 표시하지 않는 상위 개념이다.

pom.xml의 설정에 따라서 Phase마다 수행되는 세부작업을 Goal이라 부르고, Goal들의 집합을 Plugin이라 한다. 각 Phase마다 수행되어야할 Goal들이 맵핑되어 있고, Phase를 실행하면 설정에 맞는 Goal이 수행되는 구조다.

Goal은 하나 이상의 Phase에 맵핑되어 있거나, 맵핑이 되어 있지 않은 것도 있는데 맵핑된 Phase가 없다면 해당 Goal을 직접적으로 호출하여 실행할 수 있다.

mvn clean dependency:copy-dependencies package

1. clean phase 실행(라이프사이클 순서에 따라 순차적으로)
2. dependency:copy-dependencies : dependency plugin의 copy-dependencies goal 실행
3. package phase 실행(라이프사이클 순서에 따라 순차적으로)

메이븐의 빌드자동화를 정리하면,

• LifeCycle : 순서를 가지는 Phase의 집합
• Phase : LifeCycle의 구성요소로 Phase간에는 정해진 순서가 있다.
• Goal : 메이븐이 수행할 구체적인 작업으로 하나의 페이즈는 하나의 골과 맵핑된다.
• Plugin : Goal의 집합

라이프사이클에 따른 페이즈 구성이나 설정에 따라 수행되는 골의 종류 등은 메이븐의 공식 사이트를 참고하고 대략적인 개념정리는 여기서 마무리 하도록 한다.

참고

메이븐 웹 - http://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html#Lifecycle_Reference

메이븐파헤치기(김우용) - https://www.slideshare.net/ssuser5445b7/ss-56566336?qid=927855f5-7c8a-4f88-a834-d31292324fd2&v=&b=&from_search=4

목표

• UTC, GMT, Epoch Time에 대한 이해

UTC, GMT

그리니치 평균시(Greenwich Mean Time, GMT)는 런던을 기점, 웰링턴을 종점으로 하는 협정 세계시의 빠른시간이다.

세계협정시(Coordinated Universal Time, UTC)와 혼용해서 쓰이므로 같다고 생각하면 된다.

(세부적으로는 차이가 있지만 사용하는데 있어서는 같다고 이해하자.)

Epoch Time

1970년 01월 01일 자정(UTC/GMT) 이후로 초단위로 지난시간을 나타낸다.

Epoch Time과 같은 의미의 단어로 Unix Epoch, Unix Time, POSIX Time, Unix Timestamp 등이 있다.

보통 프로그래밍시에 시간 측정을 위해서 사용되는 System.currentTimeMillis()가 Epoch Time을 반환하며, 반환값은 밀리세컨드 단위로 반환되므로 1000을 나눠줘야 초 단위가 된다.

long epoch = System.currentTimeMillis()/1000;

참고 사이트 : https://www.epochconverter.com/