오늘도 끄적끄적

오래전에 이 책을 추천받았으나 최근에 읽어보게 되었다.
백엔드 개발자로 일하면서 프론트 엔드 개발자와 의사소통을 원활히 하기 위해서는 서로 네트워크에 대한 기본 지식이 있어야하는 것 같다.
이 글은 빠르게 목차를 리뷰하며 백엔드에게 필요한 내용인지, 프론트에게 필요한 내용인지, 공통적으로 알아야하는 내용인지 개인적인 기준에서 분류해봤다.

들어가기에 앞서

내가 여태까지 봐왔던 네트워크 계층 설명글들은 대부분 OSI 7 Layer를 기준으로 설명을 풀어나가고 있다.
OSI 7 Layer는 각 계층이 하는 역할이 명확해서 설명하기가 명쾌하다.
하지만 이론과 현실 사이의 괴리감이랄까… OSI 7 Layer는 구현하기가 복잡하거나, 성능 등등의 이슈(굳이 여러 계층으로 쪼갤 필요 없이 하나의 장비가 여러 역할을 수행하는 게 더 나을 때도 있으므로)로 인해
실제 구현된 건 대부분 4계층으로 구성된 TCP/IP Stack으로 구현이 많이 돼있다.
이 책은 신기하게도 TCP/IP Stack에 기반해서 각 계층의 역할을 설명하고 있다.
따라서 진짜 구현된 모델에 대한 이해를 증진시키는 데는 좋은 것 같으나 당장 AWS나 다른 글들을 보면 L4니 L2니 L7이니 해서 OSI 7 Layer로 설명된 글들이 많아서
OSI 7 Layer와 책에 설명된 TCP/IP Stack을 매핑시켜 이해하기 위해 책 앞 부분을 많이 왔다갔다 해야하는 단점이 존재하는 것 같다.

또한 책이 TCP/IP Stack에 대한 전반적인 내용을 200페이지도 안 되는 분량으로 녹여내다보니 전반적인 흐름을 알기는 좋으나
각각의 계층에 대해 딥하게는 다루지 않고, 그림도 아기자기 잘 설명돼있어서(+풀컬러) 입문 서적으로 좋은 것 같다.
여기서부터는 백엔드도 딱히 몰라도 되는 내용인 것 같다.

오래전에 이 책을 추천받았으나 최근에 읽어보게 되었다.
백엔드 개발자로 일하면서 프론트 엔드 개발자와 의사소통을 원활히 하기 위해서는 서로 네트워크에 대한 기본 지식이 있어야하는 것 같다.
이 글은 빠르게 목차를 리뷰하며 백엔드에게 필요한 내용인지, 프론트에게 필요한 내용인지, 공통적으로 알아야하는 내용인지 개인적인 기준에서 분류해봤다.

들어가기에 앞서

내가 여태까지 봐왔던 네트워크 계층 설명글들은 대부분 OSI 7 Layer를 기준으로 설명을 풀어나가고 있다.
OSI 7 Layer는 각 계층이 하는 역할이 명확해서 설명하기가 명쾌하다.
하지만 이론과 현실 사이의 괴리감이랄까… OSI 7 Layer는 구현하기가 복잡하거나, 성능 등등의 이슈(굳이 여러 계층으로 쪼갤 필요 없이 하나의 장비가 여러 역할을 수행하는 게 더 나을 때도 있으므로)로 인해
실제 구현된 건 대부분 4계층으로 구성된 TCP/IP Stack으로 구현이 많이 돼있다.
이 책은 신기하게도 TCP/IP Stack에 기반해서 각 계층의 역할을 설명하고 있다.
따라서 진짜 구현된 모델에 대한 이해를 증진시키는 데는 좋은 것 같으나 당장 AWS나 다른 글들을 보면 L4니 L2니 L7이니 해서 OSI 7 Layer로 설명된 글들이 많아서
OSI 7 Layer와 책에 설명된 TCP/IP Stack을 매핑시켜 이해하기 위해 책 앞 부분을 많이 왔다갔다 해야하는 단점이 존재하는 것 같다.

또한 책이 TCP/IP Stack에 대한 전반적인 내용을 200페이지도 안 되는 분량으로 녹여내다보니 전반적인 흐름을 알기는 좋으나
각각의 계층에 대해 딥하게는 다루지 않고, 그림도 아기자기 잘 설명돼있어서(+풀컬러) 입문 서적으로 좋은 것 같다.
여기서부터는 프론트는 딱히 몰라도 된다고 생각하는 내용이므로 목차 뒤에 F/B를 구분해서 달지 않겠다.

오래전에 이 책을 추천받았으나 최근에 읽어보게 되었다.
백엔드 개발자로 일하면서 프론트 엔드 개발자와 의사소통을 원활히 하기 위해서는 서로 네트워크에 대한 기본 지식이 있어야하는 것 같다.
이 글은 빠르게 목차를 리뷰하며 백엔드에게 필요한 내용인지, 프론트에게 필요한 내용인지, 공통적으로 알아야하는 내용인지 개인적인 기준에서 분류해봤다.

들어가기에 앞서

내가 여태까지 봐왔던 네트워크 계층 설명글들은 대부분 OSI 7 Layer를 기준으로 설명을 풀어나가고 있다.
OSI 7 Layer는 각 계층이 하는 역할이 명확해서 설명하기가 명쾌하다.
하지만 이론과 현실 사이의 괴리감이랄까… OSI 7 Layer는 구현하기가 복잡하거나, 성능 등등의 이슈(굳이 여러 계층으로 쪼갤 필요 없이 하나의 장비가 여러 역할을 수행하는 게 더 나을 때도 있으므로)로 인해
실제 구현된 건 대부분 4계층으로 구성된 TCP/IP Stack으로 구현이 많이 돼있다.
이 책은 신기하게도 TCP/IP Stack에 기반해서 각 계층의 역할을 설명하고 있다.
따라서 진짜 구현된 모델에 대한 이해를 증진시키는 데는 좋은 것 같으나 당장 AWS나 다른 글들을 보면 L4니 L2니 L7이니 해서 OSI 7 Layer로 설명된 글들이 많아서
OSI 7 Layer와 책에 설명된 TCP/IP Stack을 매핑시켜 이해하기 위해 책 앞 부분을 많이 왔다갔다 해야하는 단점이 존재하는 것 같다.

또한 책이 TCP/IP Stack에 대한 전반적인 내용을 200페이지도 안 되는 분량으로 녹여내다보니 전반적인 흐름을 알기는 좋으나
각각의 계층에 대해 딥하게는 다루지 않고, 그림도 아기자기 잘 설명돼있어서(+풀컬러) 입문 서적으로 좋은 것 같다.
각 목차 뒤에 F(ront), B(ack)을 적어놨으니 자신의 직군에 맞춰 딥하게 볼지 그냥 흐름만 볼지, 아예 안 볼지 판단하길 바란다.

오래전에 이 책을 추천받았으나 최근에 읽어보게 되었다.
백엔드 개발자로 일하면서 프론트 엔드 개발자와 의사소통을 원활히 하기 위해서는 서로 네트워크에 대한 기본 지식이 있어야하는 것 같다.
이 글은 빠르게 목차를 리뷰하며 백엔드에게 필요한 내용인지, 프론트에게 필요한 내용인지, 공통적으로 알아야하는 내용인지 개인적인 기준에서 분류해봤다.

들어가기에 앞서

내가 여태까지 봐왔던 네트워크 계층 설명글들은 대부분 OSI 7 Layer를 기준으로 설명을 풀어나가고 있다.
OSI 7 Layer는 각 계층이 하는 역할이 명확해서 설명하기가 명쾌하다.
하지만 이론과 현실 사이의 괴리감이랄까… OSI 7 Layer는 구현하기가 복잡하거나, 성능 등등의 이슈(굳이 여러 계층으로 쪼갤 필요 없이 하나의 장비가 여러 역할을 수행하는 게 더 나을 때도 있으므로)로 인해
실제 구현된 건 대부분 4계층으로 구성된 TCP/IP Stack으로 구현이 많이 돼있다.
이 책은 신기하게도 TCP/IP Stack에 기반해서 각 계층의 역할을 설명하고 있다.
따라서 진짜 구현된 모델에 대한 이해를 증진시키는 데는 좋은 것 같으나 당장 AWS나 다른 글들을 보면 L4니 L2니 L7이니 해서 OSI 7 Layer로 설명된 글들이 많아서
OSI 7 Layer와 책에 설명된 TCP/IP Stack을 매핑시켜 이해하기 위해 책 앞 부분을 많이 왔다갔다 해야하는 단점이 존재하는 것 같다.

또한 책이 TCP/IP Stack에 대한 전반적인 내용을 200페이지도 안 되는 분량으로 녹여내다보니 전반적인 흐름을 알기는 좋으나
각각의 계층에 대해 딥하게는 다루지 않고, 그림도 아기자기 잘 설명돼있어서(+풀컬러) 입문 서적으로 좋은 것 같다.
각 목차 뒤에 F(ront), B(ack)을 적어놨으니 자신의 직군에 맞춰 딥하게 볼지 그냥 흐름만 볼지, 아예 안 볼지 판단하길 바란다.

오래전에 이 책을 추천받았으나 최근에 읽어보게 되었다.
백엔드 개발자로 일하면서 프론트 엔드 개발자와 의사소통을 원활히 하기 위해서는 서로 네트워크에 대한 기본 지식이 있어야하는 것 같다.
이 글은 빠르게 목차를 리뷰하며 백엔드에게 필요한 내용인지, 프론트에게 필요한 내용인지, 공통적으로 알아야하는 내용인지 개인적인 기준에서 분류해봤다.

들어가기에 앞서

내가 여태까지 봐왔던 네트워크 계층 설명글들은 대부분 OSI 7 Layer를 기준으로 설명을 풀어나가고 있다.
OSI 7 Layer는 각 계층이 하는 역할이 명확해서 설명하기가 명쾌하다.
하지만 이론과 현실 사이의 괴리감이랄까… OSI 7 Layer는 구현하기가 복잡하거나, 성능 등등의 이슈(굳이 여러 계층으로 쪼갤 필요 없이 하나의 장비가 여러 역할을 수행하는 게 더 나을 때도 있으므로)로 인해
실제 구현된 건 대부분 4계층으로 구성된 TCP/IP Stack으로 구현이 많이 돼있다.
이 책은 신기하게도 TCP/IP Stack에 기반해서 각 계층의 역할을 설명하고 있다.
따라서 진짜 구현된 모델에 대한 이해를 증진시키는 데는 좋은 것 같으나 당장 AWS나 다른 글들을 보면 L4니 L2니 L7이니 해서 OSI 7 Layer로 설명된 글들이 많아서
OSI 7 Layer와 책에 설명된 TCP/IP Stack을 매핑시켜 이해하기 위해 책 앞 부분을 많이 왔다갔다 해야하는 단점이 존재하는 것 같다.

또한 책이 TCP/IP Stack에 대한 전반적인 내용을 200페이지도 안 되는 분량으로 녹여내다보니 전반적인 흐름을 알기는 좋으나
각각의 계층에 대해 딥하게는 다루지 않고, 그림도 아기자기 잘 설명돼있어서(+풀컬러) 입문 서적으로 좋은 것 같다.
각 목차 뒤에 F(ront), B(ack)을 적어놨으니 자신의 직군에 맞춰 딥하게 볼지 그냥 흐름만 볼지, 아예 안 볼지 판단하길 바란다.

문제의 발단

가끔 현재 시간을 기준으로 코드를 짜야할 때가 있다.
이런 경우에 자바의 경우에는 LocalDate, LocalTime, LocalDateTime 등등의 클래스에 있는 static 메서드인 now 메서드로 현재 시간을 구한다.
아래와 같이 말이다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

public class App {
    // 테스트 하기 어렵게 하기 위해서 일부러 메소드가 메소드를 계속해서 호출하는 형태로 작성함.
    // 현재 시간이 오전인지 알아내는 메소드
    public static boolean isAM() {
        return method();
    }

    private static boolean method() {
        return method2();
    }

    private static boolean method2() {
        return method3();
    }

    private static boolean method3() {
        return LocalTime.now().isBefore(LocalTime.of(12, 0));
    }
}

하지만 이렇게 현재 시간에 의존하는 코드를 테스트하기란 매우 어렵다.

일반적인 테이블 구조의 문제점

일반적인 DB 테이블 구조에 맞춰 엔티티를 만들다보면 아래와 같이 만들게 된다.

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
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57

@Entity
public class Deal {
    @Id
    private Long id;

    @Column
    private LocalDate saleStartDate;

    @Column
    private LocalDate saleEndDate;

    @Column
    private int normalPrice;

    @Column
    private int discountPrice;

    public Long getId() {
        return id;
    }

    public void setId(Long id) {
        this.id = id;
    }

    public LocalDate getSaleStartDate() {
        return saleStartDate;
    }

    public void setSaleStartDate(LocalDate saleStartDate) {
        this.saleStartDate = saleStartDate;
    }

    public LocalDate getSaleEndDate() {
        return saleEndDate;
    }

    public void setSaleEndDate(LocalDate saleEndDate) {
        this.saleEndDate = saleEndDate;
    }

    public int getNormalPrice() {
        return normalPrice;
    }

    public void setNormalPrice(int normalPrice) {
        this.normalPrice = normalPrice;
    }

    public int getDiscountPrice() {
        return discountPrice;
    }

    public void setDiscountPrice(int discountPrice) {
        this.discountPrice = discountPrice;
    }
}

객체 지향 관점에서 봤을 때 판매 시작/종료 날짜와 일반가/할인가는 전혀 관련이 없는 데이터이다.
응집력이 낮은 데이터들끼리 모여있으므로 테이블을 아래와 같이 설계하는 게 더 응집도 높은 엔티티가 될 것 같다.

잭슨은 JSON -> Java 클래스로 Deserialize, Java 클래스 -> JSON으로 Serialize 할 때 매우 유용한 라이브러리다.

하지만 잭슨이 나온 이후에 자바 8이 나왔는지 모르겠는데 LocalDate, LocalTime, LocalDateTime 등등의 클래스를 기본적으로 깔끔하게 처리해주지 못한다.
따라서 이번에는 어렵지는 않지만 새로 프로젝트 구성할 때마다 매번 까먹어서 찾아 헤매던 케이스들을 정리해봤다.
또한 예제의 설명은 스프링 부트를 기준으로 설명하겠다.

우선 Deserialize를 안 본 사람은 해당 내용에서 이어지는 포스트이기 때문에 보고 오도록 하자.

3줄 요약

잭슨은 JSON -> Java 클래스로 Deserialize, Java 클래스 -> JSON으로 Serialize 할 때 매우 유용한 라이브러리다.

하지만 잭슨이 나온 이후에 자바 8이 나왔는지 모르겠는데 LocalDate, LocalTime, LocalDateTime 등등의 클래스를 기본적으로 깔끔하게 처리해주지 못한다.
따라서 이번에는 어렵지는 않지만 새로 프로젝트 구성할 때마다 매번 까먹어서 찾아 헤매던 케이스들을 정리해봤다.
또한 예제의 설명은 스프링 부트를 기준으로 설명하겠다.

이 글을 본 다음에는 후속작인 Serialize를 보도록 하자.

3줄 요약

이미지 출처: <박상문의 Photo & Essay>평양 육아원의 모습

Entity

DB의 테이블과 매칭이 되는 개념이라고 보면 된다.
그렇다면 왜 이름이 Table이 아니라 Entity일까…?

만약 DB에 member라는 테이블이 있고, 해당 테이블의 스키마가 아래와 같다고 해보자.