오늘도 끄적끄적

SpringProperties 클래스

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41

// ...
import java.util.Properties;
// ...
public final class SpringProperties {

    private static final String PROPERTIES_RESOURCE_LOCATION = "spring.properties";
    
    private static final Properties localProperties = new Properties();


    static {
        try {
            ClassLoader cl = SpringProperties.class.getClassLoader();
            URL url = (cl != null ? cl.getResource(PROPERTIES_RESOURCE_LOCATION) :
                    ClassLoader.getSystemResource(PROPERTIES_RESOURCE_LOCATION));
            if (url != null) {
                try (InputStream is = url.openStream()) {
                    localProperties.load(is);
                }
            }
        }
        catch (IOException ex) {
            System.err.println("Could not load 'spring.properties' file from local classpath: " + ex);
        }
    }
    // ...
    @Nullable
    public static String getProperty(String key) {
        String value = localProperties.getProperty(key);
        if (value == null) {
            try {
                value = System.getProperty(key);
            }
            catch (Throwable ex) {
                System.err.println("Could not retrieve system property '" + key + "': " + ex);
            }
        }
        return value;
    }
    // ...
}

1. PROPERTIES_RESOURCE_LOCATION(spring.properties) 파일을 읽어서 InputStream에 넣고
2. localProperties.load(is)를 통해 Properties에 위에서 읽어들인 InputStream을 load 하고
3. 나중에 필요할 때 키 값을 통해 프로퍼티를 불러오고 있다.

localProperties는 Properties라는 자바 표준 API를 사용하고 있기 때문에 저 spring.properties에는 어떻게 키와 프로퍼티를 구성하는지 알아보자.

Properties

TDD By Example 책을 보다가 감명 받은 부분을 정리해봤다.
기본적으로 아래 4가지 원칙을 따라 진행한다.

1. Red - 실패하는 작은 테스트를 작성(최초에는 컴파일 조차 되지 않음)
2. Green - 빨리 테스트가 통과하게 끔 수정(이를 위해선 어떠한 죄악도 용서됨)
3. Refactoring - 모든 중복을 제거(2번에서 수행한 죄악들을 청산)

해당 포스트는 프랑(CHF, 스위스 통화)을 달러($)로 변환하는 간단한 테스트를 작성하는 것부터 시작한다.

프랑에서 달러로 변환하기

아래와 같은 간단한 코드들을 이번 예제에서 사용해보자.

TDD By Example 책을 보다가 감명 받은 부분을 정리해봤다.
기본적으로 아래 4가지 원칙을 따라 진행한다.

1. Red - 실패하는 작은 테스트를 작성(최초에는 컴파일 조차 되지 않음)
2. Green - 빨리 테스트가 통과하게 끔 수정(이를 위해선 어떠한 죄악도 용서됨)
3. Refactoring - 모든 중복을 제거(2번에서 수행한 죄악들을 청산)

책에서는 달러($)와 프랑(CHF, 스위스 통화)의 연산에 대한 조그만 테스트를 시작으로 두 통화 사이의 중복을 제거해나갔다.
해당 포스트는 클라이언트에 영향 없이 상속 구조를 마음껏 고칠 수 있는 방법에서 제거하지 못한 중복인 plus 메서드를 제거하는 것으로 시작한다.
(기본적으로 코틀린, JUnit5, kotest를 사용했다)
기본적인 내용은 내가 감명깊게 느낀 부분을 설명하기 위해 TDD로 진행해나가는 과정이고 실제 이 포스트의 핵심은 마치며를 보면 된다.

각 하위 클래스에 있는 plus 메서드 제거하기

기본적으로 소스 코드는 아래와 같다.

TDD By Example 책을 보다가 감명 받은 부분을 정리해봤다.
기본적으로 아래 4가지 원칙을 따라 진행한다.

1. Red - 실패하는 작은 테스트를 작성(최초에는 컴파일 조차 되지 않음)
2. Green - 빨리 테스트가 통과하게 끔 수정(이를 위해선 어떠한 죄악도 용서됨)
3. Refactoring - 모든 중복을 제거(2번에서 수행한 죄악들을 청산)

책에서는 달러($)와 프랑(CHF, 스위스 통화)의 연산에 대한 조그만 테스트를 시작으로 두 통화 사이의 중복을 제거해나갔다.
해당 포스트도 위 두가지 통화에 대해 덧셈 연산을 테스트 하는 작은 코드로 시작한다.
(기본적으로 코틀린, JUnit5, kotest를 사용했다)
기본적인 내용은 내가 감명깊게 느낀 부분을 설명하기 위해 TDD로 진행해나가는 과정이고 실제 이 포스트의 핵심은 하위 클래스의 직접적인 참조 줄이기를 보면 된다.

Dollar 클래스 구현하기

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

class DollarTest {
    @Test
    fun `$5 + $2 = $7`() {
        // Given
        val five = Dollar(5)
        val two = Dollar(2)

        // When
        val actual = five + two

        // Then
        val expected = Dollar(7)
        actual shouldBe expected
    }
}

themes/next/_config.yml을 보면 아래와 같이 기본적으로 ‘더 읽어보기’가 세팅돼있다.

1
2
3
4
5
6
7
8
9

# Automatically excerpt (Not recommend).
# Use <!-- more --> in the post to control excerpt accurately.
auto_excerpt:
  enable: true
  length: 150

# Read more button
# If true, the read more button would be displayed in excerpt section.
read_more_btn: true

하지만 NexT Theme 7.6.0 이상의 버전에서는 위와 같이 설정이 돼있어도 ‘더 읽어보기’가 나오지 않는다.
이럴 때는 hexo-excerpt 플러그인을 설치해주면 해결된다. 🎉
https://github.com/theme-next/hexo-theme-next/issues/1245#issuecomment-558486354

If you are using NexT 7.6.0 and later, please install the plugin: https://github.com/chekun/hexo-excerpt

인증서는 왜 쓸까

A가 데이터를 보냈는데 이게 진짜 A가 보낸 건지 아닌지를 검증할 수가 없다.
인증서는 A라는 사람이라는 것을 보증해주는 문서라고 보면 된다.
따라서 A한테 메세지가 올 때 A의 인증서가 오지 않는다면 A라고 취급을 하지 않으면 된다.
하지만 개나소나 인증서를 발급할 수 있으면 A 행세를 아무나 낼테니까 **인증된 기관(CA, Certificate Authority)**으로부터 적절한 절차를 거쳐 인증서를 발급받을 수 있다.

우리가 알고 있는 TLS 인증서(https 도메인마다 발라져있는) 같은 경우에도 이런 절차를 거쳐 발급된다.
그리고 이런 인증서들은 **X.509(공개키 인증서 포맷의 표준)**라는 표준을 준수한다.

막연하게 양방향 암호화 하면 당연스레 AES를 떠올리고, 제대로 모른 채로 사용했다.
이제부터라도 조금은 알고 써야겠다는 생각이 들어서 살짝 정리해봤다.

양방향/단방향 암호화

양방향 암호화는 암호화 및 복호화가 가능하다는 소리다.
휴대폰 번호 등등 민감한 개인정보는 암호화 해서 저장해야하는데 고객 정보를 식별하기 위해선 복호화도 가능해야한다.
혹시나 키와 DB가 털린다면 복호화가 가능하므로 적어도 개인정보는 마스킹 한 후에 암호화해서 저장해야한다.
양방향 암호화 알고리즘에는 DES(보안에 취약), AES, SEED(국내에서 개발, 공인인증서에 사용됨) 등등이 있다.

단방향 암호화는 암호화만 가능하고 복호화는 불가능하다는 소리다.
비밀번호와 같이 암호화 한 값들끼리 단순히 비교만 하면 되고, 복호화 할 필요가 없는 정보들은 단방향 암호화 해야한다.
혹시나 키와 DB가 털려도 복호화가 불가능하기 때문에 암호화된 값만 알 수 있지 원본 비밀번호는 알 수 없기 때문에 양방향 암호화 보다는 좀 더 안전하다.
이런 특성 때문에 비밀번호 찾기 대신에 비밀번호 재설정 기능 밖에 지원 할 수 없다. (비밀번호 찾기를 지원해주는 사이트는 보안이 매우 안 좋은 사이트이다.)
단방향 암호화 알고리즘에는 해시 알고리즘이 사용되며 SHA256, SHA512, MD5(무작위 대입 공격에 약함) 등등이 있다.

코틀린의 장점을 하나 꼽자면 Non-null 타입을 지원한다는 것이다.
모든 곳에 null을 없앨 수 있는데(100% 순수 코틀린 코드로만 짠다면)
통제할 수 없는 부분은 클라이언트로부터 받는 Request이다.

그래서 Request에는 어떤 타입을 써야할지 삽질을 해봤다.

기본값을 사용하자.

1
2
3
4
5
6
7

class DTO(val name: String? = null)

@RestController
class Controller {
    @PostMapping
    fun test(@RequestBody dto: DTO) {}
}

위와 같을 때 request body의 name에 아무런 내용도 입력하지 않으면 name에 기본값 null이 잘 세팅된다.
기본값이 전부 존재하면 default constructor가 생성돼서 객체를 손쉽게 생성할 수 있다보니 테스트 할 때 용이하다.

연차 대비 너무너무 느린 개발 속도를 향상시키기 위해 나만의 Cheetsheet를 하나씩 만들어야겠다.
처음 접하는 코틀린 환경에서 자바에서는 좀 할만했던 DTO의 (De)Serialize 관련해서 적어보았다.
모든 설명은 JSON으로 request와 response를 주고받는 HTTP API 기반으로 진행하기 때문에 엄밀히 따지면 부정확한 내용들이 많다.

용어 설명

간단하게 용어들을 집고 넘어가자.

DTO(Data Transfer Object)

데이터를 전송하는데 사용하는 객체

돈으로부터 자유로워지려면 어떻게 해야할까?
월급을 얼마를 받던 상관없이 내가 원하는 삶을 살 수는 없을까?
지금은 내가 일을 해서 돈을 벌지만, 내가 일을 못하게 되면 어떤 삶을 살아야할까?
그렇다면 평생 일을 할 수 있다면, 죽을 때까지 계속해서 일을 해야하는 걸까?

사람마다 일과 삶(Working & Life), 그리고 돈에 대한 가치가 다 다르겠지만 내 스스로 기준을 정하고 내가 원하는 삶으로 이끌어나가기 위해서 책을 읽은 내용을 토대로 좀 정리해봤다.

자산과 부채

로버트 기요사키의 부자 아빠, 가난한 아빠에서는 다음과 같이 설명하고 있다.

자산은 내 지갑에 돈을 넣어주고, 부채는 내 지갑에서 돈을 꺼내간다.