https://leetcode.com/problems/valid-parentheses/

풀이

1안

class Solution {
    public boolean isValid(String s) {

        int length = s.length();

        if(length % 2 != 0) return false;

        HashMap<Character, Character> map = new HashMap<>();
        map.put(')', '(');
        map.put(']', '[');
        map.put('}', '{');
        Stack<Character> stack = new Stack<>();

        for(Character c : s.toCharArray()) {
            if(c == '(' || c == '[' || c == '{') {
                stack.push(c);
            } else {
                if(stack.isEmpty() || stack.pop() != map.get(c)) {
                    return false;
                }
            }
        }

        return stack.isEmpty();

    }
}

속도면에서는 빠르지만, HashMap을 사용해서 메모리를 많이 차지했다.

2안

class Solution {
    public boolean isValid(String s) {

        Stack<Character> stack = new Stack<>();

        for(Character c : s.toCharArray()) {
            if(c == '(' || c == '{' || c == '[') {
                stack.push(c);
            } else {

                if(stack.isEmpty()) return false;

                if(c == ')' && stack.pop() != '(') {
                    return false;
                } else if(c == '}' && stack.pop() != '{') {
                    return false;
                } else if(c == ']' && stack.pop() != '[') {
                    return false;
                } 
            }
        }

        return stack.isEmpty();

    }
}

메모리는 적게 사용했지만, 속도가 이전보다 살짝 느려졌다.

3안

class Solution {
    public boolean isValid(String s) {

        Stack<Character> stack = new Stack<>();

        for(Character c : s.toCharArray()) {
            if(c == '(') {
                stack.push(')');
            } else if(c == '{') {
                stack.push('}');
            } else if(c == '[') {
                stack.push(']');
            } else {
                if(stack.isEmpty()) return false;
                if(stack.pop() != c) return false;
            }
        }

        return stack.isEmpty();

    }
}

속도는 1안 과 같지만, 메모리는 HashMap을 쓰지 않아 덜 차지하였다.

근데 사실, 그래프로 봐서 그렇지 별 차이는 안나는 것 같.ㅇ...

스택

스택(Stack)은 "쌓다"라는 의미로 하나씩 쌓아올리고, 뺄 때는 위에서부터 빼는 구조이다. LIFO(Last In First Out) 구조라고도 한다. 반대로는 큐(Queue) 구조가 있는데 먼저 들어간 것이 먼저 나오는 구조이다. FIFO(First In First Out) 구조라고도 한다.

당장 우리가 하는 코딩에도 스택구조가 떡하니 있다. 메소드 안에서 메소드를 호출하고, 또 메소드를 호출했다고 생각해보자.

A() { 
    B()
}

B() {
    C()
}

C() {
    ...
}

A를 호출하고 B를 호출하고 C를 호출하고, C가 끝나면 종료되고, B가 종료되고, A가 종료된다. 바로 이게 스택구조이다.

또한, 우리가 사용하는 웹 브라우저에서 '뒤로가기' 기능도 스택이 될 것이다.

스택에는 pop, push가 있다. push는 삽입연산이다. 스택에 데이터를 삽입한다. pop은 삭제연산이다. 스택에서 데이터를 뺀다. 이때, 가장 마지막에 들어갔던 데이터가 빠질 것이다.

자바에서 사용하는 메소드는 아래와 같다.

public E push(E item)

Pushes an item onto the top of this stack. This has exactly the same effect as: addElement(item)

public E pop()

Removes the object at the top of this stack and returns that object as the value of this function.

public E peek()

Looks at the object at the top of this stack without removing it from the stack.

-> pop()은 제일 위에 있는 요소를 추출하면서 리턴도 해주는데, peek()은 리턴만 해주고 추출은 하지 않는다. 즉 그대로 스택에 남아있다.

public boolean empty()

Tests if this stack is empty.

[참고] https://docs.oracle.com/javase/8/docs/api/java/util/Stack.html

https://school.programmers.co.kr/learn/courses/30/lessons/42576?language=java

풀이

import java.util.HashMap;

class Solution {
    public String solution(String[] participant, String[] completion) {

        HashMap<String, Integer> map = new HashMap<>();

        for(String c : completion) {
            map.put(c, map.getOrDefault(c, 0) + 1);
        }

        for(String p : participant) {
            Integer count = map.getOrDefault(p, 0);

            if(count == 0) {
                return p;
            } else {
                map.put(p, count - 1);
            }
        }
        return "";
    }
}

Interface Map<K,V> - 내 기준 알아두면 좋을 것 같은 메소드

default V getOrDefault(Object key, V defaultValue)

Returns the value to which the specified key is mapped, or defaultValue if this map contains no mapping for the key.

key 값으로 매핑되는 Value 가 있으면, Value 를 리턴. 없으면 defaultValue 를 리턴.

default V putIfAbsent(K key, V value)

If the specified key is not already associated with a value (or is mapped to null) associates it with the given value and returns null, else returns the current value.

key 값으로 매핑되는 값이 없으면 value 를 넣고 null 을 리턴. 있으면 현재 value 를 리턴.

default V compute(K key, BiFunction<? super K,? super V,? extends V> remappingFunction)

Attempts to compute a mapping for the specified key and its current mapped value (or null if there is no current mapping).

지정된 key와 매핑된 값을 계산해서 새로운 값을 넣어준다. (매핑된 것이 없을 경우엔 null)

Map<String, Integer> map = new HashMap<>();
map.compute("addOne", (key, oldValue) ->  oldValue == null ? 0 : oldValue + 1);
System.out.println(map.get("addOne")); // 0

map.compute("addOne", (key, oldValue) ->  oldValue == null ? 0 : oldValue + 1);
System.out.println(map.get("addOne")); // 1

default V computeIfAbsent(K key, Function<? super K,? extends V> mappingFunction)

If the specified key is not already associated with a value (or is mapped to null), attempts to compute its value using the given mapping function and enters it into this map unless null.

지정된 key 가 value와 관계가 없으면(혹은 null이라면), function 으로 매핑한 값으로 계산을 하고 map에 넣음.

Map<String, Integer> map = new HashMap<>();
String value = map.computeIfAbsent("apple", key -> "red " + key);
System.out.println(value); // red apple

value = map.computeIfAbsent("apple", key -> "green " + key);
System.out.println(value); // red apple

default V computeIfPresent(K key, BiFunction<? super K,? super V,? extends V> remappingFunction)

If the value for the specified key is present and non-null, attempts to compute a new mapping given the key and its current mapped value.

지정된 key 의 value 가 존재하고 non-null 일 경우, 주어진 key 와 현재의 value로 새로운 매핑을 계산함.

Map<String, String> map = new HashMap<>();
map.put("Apple", "Red");


String str = map.computeIfPresent("Apple", (key, oldValue) -> key + oldValue + "Good");
System.out.println(str);    // AppleRedGood


String str_null = map.computeIfPresent("none", (key, oldValue) -> key + oldValue + "Hello");
System.out.println(str_null);     // null

https://school.programmers.co.kr/learn/courses/30/lessons/1845?language=java

풀이

import java.util.HashMap;

class Solution {
    public int solution(int[] nums) {

        int length = nums.length;
        int maxCount = length / 2;

        HashMap<Integer, Integer> pocketmons = new HashMap<>();

        for(int i = 0; i < length; i++) {
            pocketmons.put(nums[i], 1);
        }

        int answer = pocketmons.size() > maxCount ? maxCount : pocketmons.size();

        return answer;
    }
}

HashMap을 이용하면, key값이 중복되지 않기 때문에 이를 이용하였다. nums[i]를 키 값으로 하여 HashMap에 넣고, 마지막에는 그 size()를 구하여 maxCount 보다 클 경우에는 maxCount를 최대포켓몬 수로 정하고, 반대일 경우에는 size() 값을 최대포켓몬 수로 정하였다.

해시

hashCode

HashMap은 hashCode를 이용하기 때문에 대용량 데이터를 조회하는데 유용하다. 여기서 hashCode란 해시 알고리즘에 의해 생성된 정수 값이다.

HashMap은 key값을 통해 hashCode(정수)를 생성하고, 생성된 hashCode를 bucket에 접근할 수 index로 변환해 배열에 값을 저장한다. 즉, 하나하나 확인을 하는 것이 아니라, key값을 hashCode로 변환하고 해당 값을 index로 변환해 바로 탐색하는 것이다. 그렇기 때문에 대용량 데이터에서 조회가 빠르다.

하지만, hashCode를 만드는 알고리즘이 좋지 않으면, 만든 hashCode가 같아질 수 밖에 없기 때문에 배열의 한 방에 많은 데이터가 들어가게 된다. 이런 현상을 충돌현상이라고 하는데, 이것을 피하기 위해 Hash Algorithm을 잘 만들어야 한다.

만약 아래처럼 구현한다면 이 클래스로 생성된 모든 객체들은 다 똑같은 해시코드를 갖는 것이기 때문에 충돌현상이 생겨 문제가 될 것이다.

    @Override
    public int hashCode() {
        return 1; // 모든 객체들이 해시코드를 1을 갖게 됩니다.
    }

원래는 배열의 인덱스를 조회하는 것이기 때문에 시간복잡도가 O(1)이었겠지만, 이런식으로 충돌이 일어나면 탐색하는데 O(n)까지 걸릴 수가 있다.

위 코드는 극단적인 예시이지만, hashCode는 다른 Key값으로 동일한 hashCode를 만들어 내기도 하는데, 그 이유는 key 값은 문자열이고 그 가짓수가 무한한데 비해 hashCode는 정수이기 때문에 알고리즘이 아무리 좋아도 어떤 Key들은 중복되는 hashCode를 만들어낼 수 밖에 없기 때문이다.

또는, 다른 hashCode를 받았지만 Index로 변환하는 과정에서 동일한 Index를 받는 경우에도, 한 Index에 값이 몰리기 때문에 충돌이 일어나서 O(n)까지 걸릴 수가 있다.

bucket

HashMap에서 데이터를 담는 공간을 bucket이라고 칭한다. 자바에서 해당 bucket의 크기는 동적으로 변경된다.

HashMap의 기본 생성자에서 capacity는 16, load factor는 0.75로 생성되는데, threshold = capacity * load factor 가 된다. 여기서 threshold는 버킷의 크기를 변경할 때의 임계점이라고 생각하면 된다.

즉, threshold는 16 * 0.75 = 12가 되는데, 이 말은 버킷안에 저장된 데이터가 12개가 넘어가면 bucket의 크기를 늘린다는 이야기이다. HashMap은 버킷의 크기를 늘릴 때 2배를 늘린다. 즉, 원래사이즈 16의 2배인 32개가 되는 것이다. 따라서 데이터가 많아지면 메모리를 많이 사용하게 된다.

사이즈가 변경되는 과정을 rehashing 이라고 하는데, 해당 과정에서 사이즈만 변경되는 것이 아니라 해시코드를 다시 계산하여 해당 키-값들의 버킷 위치를 다시 정하게 된다.

개발의 세팅은 반이라고 ... 세팅하면서 엄청난 오류들을 마주할 마음의 준비를 하고 세팅에 들어갔다.

1. Setting

먼저 build.gradle 에 아래와 같은 dependency 를 추가해준다.

implementation 'org.springframework.boot:spring-boot-starter-graphql'

그리고 application.properties 에 아래와 같이 설정을 넣어준다.

#/graphql/schema HTTP를 통해 스키마 조회 가능 여부
spring.graphql.schema.printer.enabled=true
#graphiql 페이지 사용 여부
spring.graphql.graphiql.enabled=true
#graphiql 페이지 경로(기본이 /graphiql임)
spring.graphql.graphiql.path=/graphiql

여기서 graphiql 페이지가 무엇이냐면! 이렇게 데이터 통신을 테스트해볼 수 있는 페이지이다. 그래서 위처럼 세팅을 해두면 http://localhost/grqphiql 로 접속하면 저 페이지로 들어갈 수 있다.

2. Scheme

생각보다 세팅은 너무 허무하게 끝났고, 이제 Scheme을 등록해주면 된다. 일단 맨 처음 보여줬던 사진들처럼 많은 변수들을 넣어야 하지만, graphql은 Date 형 같은 Variable을 제공하지 않아서 이 부분은 나중에 추가하기로 하고, 정말 테스트를 위해 간단한 값들만 넣어봤다. resources/graphql/schema.graphqls 경로에 넣으면 된다. (없으면 생성)

type Query {
    findCultureNearby: [Culture]
}

type Culture {
    id: ID
    seq: Int
    typeCode: String
    title: String
    thumbnail: String
}

그리고 Controller를 생성해준다.

@Controller
public class CultureGraphqlTestController {

    @Autowired
    private CultureService cultureService;

    @QueryMapping
    public List<CultureVO> findCultureNearby() {
        return cultureService.findAll();
    }

}

graphql은 메소드명과 Query안의 명칭을 매핑해서 해당 메소드를 호출해주기 때문에 명칭을 제대로 맞췄는지 확인해주어야 한다.(위 코드에서는 findCultureNearBy 메소드명을 사용하였다.)

3. Test

아직 뭐가 뭔지 모를 수도 있다. 하지만 http://localhost:8080/graphiql?path=/graphql 여기를 들어가서 이제 내가 불러오고 싶은 쿼리를 작성해보면 대충 감이 올 것이다.

query {
  findCultureNearby {
    id
    title
  }
}

findCultureNearBy 쿼리를 호출할 것인데 id 랑 title 값만 필요하다는 의미이다. 위처럼 호출하하면 아래와 같이 정말 필요한 값만 보여준다.

만약에 쿼리를 아래처럼 바꾸면 돌려주는 값도 당연히 달라진다.(API를 추가하지 않았지만 말이다!!)

query {
  findCultureNearby {
    title
    thumbnail
  }
}

분명 단점도 존재한다. 앱 개발할 때 편하려고 백엔드 개발할 때 한 번 더 고생해야된다는 점? (앱에서 변수 입력하기 싫어서 한 짓인데 결국 백엔드에서 한 번 더 입력했음...ㅋㅋㅋㅋㅋㅋ 알아서 Model 읽어다 세팅해주면 안되겠니..? ㅠㅠ) 그리고 graphqls 에서 작성할 때 사용할 수 있는 데이터형이 너무 한정적이라는 점

• Int: 부호가 있는 32비트 정수.
• Float: 부호가 있는 부동소수점 값.
• String: UTF-8 문자열.
• Boolean: true 또는 false.
• ID: ID 스칼라 타입은 객체를 다시 요청하거나 캐시의 키로써 자주 사용되는 고유 식별자를 나타냅니다. ID 타입은 String 과 같은 방법으로 직렬화되지만, ID 로 정의하는 것은 사람이 읽을 수 있도록 하는 의도가 아니라는 것을 의미합니다.

이게 전부임... 그래서 새로운 데이터를 사용하려면 생성해줘야함(아까 말한 Date 형 같은 경우가 이에 해당) 아마 이 때문에 첨부파일 형태도 지원이 안되지 않을까 싶은데 ...

일단 테스트 용으로 해본 것이기 때문에 효율은 어떨지는 써봐야 알 것 같다. 기회가 된다면 알아서 graphql이 생성되는 방식으로 개발을 한 번 해보고 싶다.

끝 -*

[참고사이트] https://graphql-kr.github.io/learn/schema/ https://www.graphql-java.com/tutorials/getting-started-with-spring-boot/

그래서 다양하게 디버그 콘솔에 찍어 보면서 내 나름대로 이해하게 된 것들을 정리하고자 한다. (잘못된 부분은 댓글로 남겨주면 수정하도록 하겠습니다!)

내가 의문을 가졌던 코드는 아래와 같다.

#include <bits/stdc++.h>

using namespace std;

int a[10];
int b[10][10];

int main() {

    fill(&a[0], &a[10], 100);

    for(int i = 0; i < 10; i++) {
        cout << a[i] << " ";
    }

    cout << '\n';

    fill(&b[0][0], &b[0][0] + 10 * 10, 2); //여기서 의문을 갖게 되었다.
    for(int i = 0; i < 10; i++) {
        for(int j = 0; j < 10; j++) {
            cout << b[i][j] << ' ';
        }
        cout << '\n';
    }

    return 0;

}

1차원 배열로 생각하면 &a[1] 은 a + 1 과 같다. 그러면 2차원 배열로 생각하면 b[0][1]과 b[1][0]은 포인터로 어떻게 표현될까? 가 나의 의문이었다. 단순하게 나는 b[0][1] 이 b + 1 로 표현될 것이라고 착각했고, 값이 다르다는 것을 확인할 수 있었다. 왜 다를까? 나는 10 * 10 배열이더라도, 메모리에 저장되는 순서는 차례대로 이기 때문에 b + 1 이 &b[0][1]과 같을 것이라고 생각했다. 디버그 콘솔로 찍어보니 메모리에 +4를 증가시키면서 순차적으로 저장되는 것은 맞았지만, 그렇다고 해서 b + 1 이 &b[0][1] 이 지칭하는 것은 아니었다. 왜그럴까? b[10][10] 은 아래 그림과 같이 생각하면 될 것 같다. 때문에 b + 1 은 b[0][[1] 과 같은 것이 아니라 b[1][0] 와 같은 것이 맞는 답이다. 그러면 여기서 &b[0][1] 은 포인터로 어떻게 표현하는 것일까? 위 그림에서 보듯, b + 0 안에서 또 1을 증가시켜야 한다. 숫자 배열이기 때문에 포인터를 1 증가시킬 때마다 4가 증가한다. b는 포인터를 1 증가시킬 때마다 4 * 10(배열의 크기) = 40 이 증가한다. 뒤 숫자만 비교했을 때 58 - 30 = 28(16진수)을 10진수로 바꿔보면, 40이 나오는 것을 알 수 있다.

위의 그림들은 다 이해를 쉽게 하기 위해서 그린 그림이고, 실제로 메모리엔 차례대로 저장된다.

추가적으로, &b[0][1] 은 &b[0][0] + 1 으로 &b[1] 은 &b[0] + 1로 표현할 수 있다는 것도 알아두자.

https://hanghaeplus-coyukdae.oopy.io/

그림과 같이 다양한 종복이 존재했고, 처음엔 테트리스에 도전해보려고 하다가 산소도 가야하고 전도 부쳐야하고 바쁜 일정들 사이에서 잠깐 잠깐 하기에는 행맨 게임이 제일 간단해보여 행맨 게임으로 도전해 보게 되었다.

리액트로 시작하려하다가, 평가하시는 분들이 편하게 평가하려면 그냥 html 만 열어도 바로 평가 되게끔 html, js 만 이용해서 간단하게 만들기로 했다.

예전에 어쩌다가 html의 canvas를 알게 되었는데, 생각보다 쉽고 간편해서 이걸로 한 번 도전해 보기로 했다. 그런데 canvas를 쓰니까 뭔가 이쁜 맛이 없어서 후회 중이다....

대충 화면은 이렇다... 초간단 초심플... 디자인적 감각이 없는 사람인지라 어쩔 수가 없다...

여러번 실패하면 이렇게 그림이 하나하나 생기면서 행맨이 그려진다. 이 부분에서 canvas를 사용했다.

var hangman = {

    canvas : document.getElementById("canvas"),
    x : 150,
    y : 50,
    r : 30,

    setBase : function() {

        ctx = canvas.getContext("2d");
        ctx.strokeStyle = 'black';
        ctx.lineWidth = 3;

        ctx.beginPath();

        ctx.moveTo(this.x, this.y);
        ctx.lineTo(this.x, this.y + 250);

        ctx.moveTo(this.x, this.y);
        ctx.lineTo(this.x + 100, this.y);

        ctx.moveTo(this.x - 20, this.y + 250);
        ctx.lineTo(this.x + 50, this.y + 250);

        ctx.stroke();

    },

    setRope : function() {

        ctx = canvas.getContext("2d");

        ctx.lineWidth = 3;

        ctx.beginPath();

        ctx.moveTo(this.x + 100, this.y);
        ctx.lineTo(this.x + 100, this.y + 50);

        ctx.moveTo(this.x + 50, this.y);
        ctx.lineTo(this.x, this.y + 50);

        ctx.stroke();

    },

    setHead : function() {

        ctx = canvas.getContext("2d");

        ctx.lineWidth = 5;

        ctx.beginPath();

        ctx.arc(this.x + 100, this.y + 50 + this.r, this.r, 0, 360);

        ctx.stroke();

    },

    setBody : function() {

        ctx = canvas.getContext("2d");

        ctx.lineWidth = 5;

        ctx.beginPath();

        ctx.moveTo(this.x + 100, this.y + 50 + this.r * 2);
        ctx.lineTo(this.x + 100, this.y + 50 + this.r * 2 + 50);

        ctx.stroke();

    },

    setArms : function() {

        ctx = canvas.getContext("2d");

        ctx.lineWidth = 5;

        ctx.beginPath();

        ctx.moveTo(this.x + 100, this.y + 50 + this.r * 2 + 10);
        ctx.lineTo(this.x + 50, this.y + 50 + this.r * 2 - 10);

        ctx.moveTo(this.x + 100, this.y + 50 + this.r * 2 + 10);
        ctx.lineTo(this.x + 150, this.y + 50 + this.r * 2 - 10);

        ctx.stroke();

    },

    setLegs : function() {

        ctx = canvas.getContext("2d");

        ctx.lineWidth = 5;

        ctx.beginPath();

        ctx.moveTo(this.x + 100, this.y + 50 + this.r * 2 + 50);
        ctx.lineTo(this.x + 50, this.y + 50 + this.r * 2 + 95);

        ctx.moveTo(this.x + 100, this.y + 50 + this.r * 2 + 50);
        ctx.lineTo(this.x + 150, this.y + 50 + this.r * 2 + 95);

        ctx.stroke();

    },

    setHands : function() {

        ctx = canvas.getContext("2d");

        ctx.lineWidth = 5;

        ctx.beginPath();
        ctx.arc(this.x + 50, this.y + 50 + this.r * 2 - 10, 5, 0, 360);
        ctx.stroke();

        ctx.beginPath();
        ctx.arc(this.x + 150, this.y + 50 + this.r * 2 - 10, 5, 0, 360);
        ctx.stroke();

    },

    setFeet : function() {

        ctx = canvas.getContext("2d");

        ctx.lineWidth = 5;

        ctx.beginPath();

        ctx.moveTo(this.x + 50 + 10, this.y + 50 + this.r * 2 + 95 + 5);
        ctx.lineTo(this.x + 50 - 10, this.y + 50 + this.r * 2 + 95 - 10);

        ctx.moveTo(this.x + 150 - 10, this.y + 50 + this.r * 2 + 95 + 5);
        ctx.lineTo(this.x + 150 + 10, this.y + 50 + this.r * 2 + 95 - 10);

        ctx.stroke();

    }

}

위치를 쉽게 바꿀 수 있게 하기 위해서 시작 좌표 x, y 를 제일 처음 지정해주고, 각각 부위마다 함수를 따로 구현해 줬다. 그래서 실패할 때마다 아래와 같이 특정 부위 함수를 호출한다.

switch(counts) {
  case 1:
    hangman.setBase();
    break;
  case 2:
    hangman.setRope();
    break;
  case 3:
    hangman.setHead();
    break;
  case 4:
    hangman.setBody();
    break;
  case 5:
    hangman.setArms();
    break;
  case 6:
    hangman.setHands();
    break;
  case 7:
    hangman.setLegs();
    break;
  case 8:
    hangman.setFeet();
    game.failGame();                  
}

성공하거나 실패했을 시, 알파벳 카드를 사용하지 못하게 막거나 Restart 를 눌렀을 시 다시 카드를 사용할 수 있게 원상태로 돌려놔야 하기 때문에 아래와 같은 함수를 사용했다.

reverseAllCards : function(isBack) {
  blanksDivs = document.getElementsByClassName("cards");

  for(var i = 0; i < blanksDivs.length; i++) {
    blanksDivs[i].disabled = isBack;
  }
}

isBack이 true일 경우 뒤집어 졌다는 의미로 클릭이 불가능하고, false일 경우 뒤집어 지지 않았다는 의미로 클릭이 가능하다.

단어 같은 경우, 내가 만든 것에는 따로 갯수 제한이 없지만 항해 플러스 문제에서는 10자 이하의 단어만 허용했었다. words 라는 변수에 단어를 추가로 넣어주기만 하면 랜덤으로 뽑아서 제출해준다.

const words = [
    "apple",
    "banana",
    "umbrella",
    "triangle",
    "cave",
    "sunglass",
    "chair",
    "legal",
    "illegal",
    "valuable",
    "chemical",
    "delicious",
    "active",
    "creative",
    "actual",
    "wonderful",
    "slim",
    "fat",
    "stupid",
    "actual",
    "double",
    "creative",
    "show",
    "eternal",
    "exalt",
    "exert",
    "exploit",
    "explicit",
    "revolve",
    "ethereal",
    "give",
    "get",
    "grain",
    "great",
    "bad",
    "goverment",
    "trim"
];

// 랜덤으로 단어를 하나 추출
word = words[Math.floor(Math.random() * words.length)]

특정 알파벳 카드를 선택했을 때, 문제 제출된 단어에 포함된 단어인지 확인하는 로직은 아래와 같다.

onClickCard : function(btn) {

          // _ _ _ _ _ 와 같이 알파벳이 들어나는 elements
        blanksDivs = document.getElementsByClassName("blanks_cards");
        isCorrect = false;

          // 클릭한 알파벳은 사용하지 못하게 막아준다.
        btn.disabled = true;

          // 문제 단어 글자수 만큼 for 문을 돌면서 알파벳을 비교한다.
        for(var i = 0; i < word.length; i++) {
            if(word[i].toUpperCase() == btn.innerText.toUpperCase()) {
                blanksDivs[i].innerText = word.charAt(i).toUpperCase();
                isCorrect = true;
                  // correctCounts가 문제 단어 글자수와 같아지면 성공으로 처리하기 위해, 증가시켜준다.
                correctCounts++;
            }
        }

        if(!isCorrect) {
            counts++;
            switch(counts) {
                case 1:
                    hangman.setBase();
                    break;
                case 2:
                    hangman.setRope();
                    break;
                case 3:
                    hangman.setHead();
                    break;
                case 4:
                    hangman.setBody();
                    break;
                case 5:
                    hangman.setArms();
                    break;
                case 6:
                    hangman.setHands();
                    break;
                case 7:
                    hangman.setLegs();
                    break;
                case 8:
                    hangman.setFeet();
                    game.failGame();                  
            }
        }else {
            if(correctCounts == word.length) {
                game.successGame();
            }
        }

    }

처음에는 이미지를 내가 그려놓고 하나씩 보여줄까 했는데, 그림 그리는게 귀찮았다... 그래서 그냥 타이핑으로 모든 것을 해결하겠다는, 정말 무의미한 의지로 ㅋㅋㅋ canvas를 이용해보았다. 완성하고 보니 너무 허접해 보여서 후회중.. 그냥 그림그릴걸... 그래도 추석동안 뭔가 하나 해봤다는게 나에게 큰 의미로 다가온 것 같다.

이 시기를 기점으로 앞으로 뭔가 작은 것 하나라도 해서 velog나 git에 꾸준히 올려야겠다는 의지를 다잡으려고 한다. (사실 저번주부터 올리고 있었는데, 깃 계정을 잘못 등록해서 이상한데에 잔디가 심어졌다...ㅠㅠ)

끝-*

깃허브 : https://github.com/f-exuan21/hangman

출처 : 외워서 끝내는 네트워크 핵심이론 - 기초 (인프런)

그런데 회사에 출근하고 iOS 12에서 실행시켜봤더니... 이 따위로 뜨더라... 아마 Inset Grouped은 버전이 좀 올라간 뒤에 생긴 것 같다.. 회사 특성상 최저 버전이 11이기 때문에, 디자인을 맞춰줘야한다는 왕고집이 발동되어 Inset Grouped 를 포기하고 Grouped로 갈아탔다. ( Grouped 를 하면 아래 사진 처럼 된다. )

그래서 필요한 작업들을 다 하고 나니까, 원했던 padding 이 죽어도 안잡히더라... 양 옆에 그냥 잉꼬부부마냥 아주 딱 붙어있다.

그래서 또 구글링에 이은 구글링을 하다가 해결했다..!

class PastMeetingTableViewCell: UITableViewCell {

    @IBOutlet weak var subject: UILabel!

    @IBOutlet weak var dateAndTime: UILabel!


    override func awakeFromNib() {
        super.awakeFromNib()
        // Initialization code
    }

    override func setSelected(_ selected: Bool, animated: Bool) {
        super.setSelected(selected, animated: animated)

        // Configure the view for the selected state
    }

    // cell 너비/패딩 조절
    override var frame: CGRect {
        get {
            return super.frame
        }
        set {
            var frame = newValue
            frame.origin.x += 20
            frame.size.width -= 2 * 20

            super.frame = frame
        }
    }

}

cell을 구성하는 컨트롤러에서 frame을 override 해서 값을 바꿔주었더니 되었다. width를 줄이고 origin의 x값도 변경시켜주었다!

(검은 블록은 회사 관련된 정보가 써있어서 가리기...) 사진을 보면 왼쪽 오른쪽 아주 이쁘게, 내가 원한만큼(각각 20) 마치 패딩이 잡힌 것처럼 보이는 것을 확인할 수 있다!

extension UIView {

    func setGradient(color1: UIColor, color2: UIColor) {

        let gradient: CAGradientLayer = CAGradientLayer()
        gradient.frame.size = CGSize(width: 300, height: 300)
        gradient.colors = [color1.cgColor, color2.cgColor]
//        gradient.startPoint = CGPoint(x: 0.0, y: 0.0)
//        gradient.endPoint = CGPoint(x: 1.0, y: 1.0)
        print(self.bounds.size.height)
        gradient.frame = bounds
        layer.masksToBounds = true
        layer.insertSublayer(gradient, at: 0)
//        layer.addSublayer(gradient)
    }

}

위처럼 header 라는 UIView 안에 card 라는 UIView 를 넣고, setGradient() 라는 함수를 만들어서 gradient를 주려고 했는데, 아무리 해도 안먹히더라...

대체 왜그럴까 하고, card.layout.size.height 랑 card.layout.size.width를 출력해보니 둘 다 0, 0 이 나왔다...

검색을 해보니 card.layoutIfNeeded() 를 추가해주니 잘 되었다. (주석처리 되어 있는 것)

그런데 layoutIfNeeded() 를 사용하는 것을 피하라는 말이 있어서, frame에 대해서 조금 더 공부를 했다.

https://babbab2.tistory.com/44 (공부한 사이트)

하지만 대체 왜 size 의 모든 값들이 0이 나오는지 모르겠어서, 찾아보니

When you set up your views in viewDidLoad() the actual sizes have not yet been calculated. Try measuring the width in viewDidAppear(). By that time everything should be set up.

viewDidLoad() 일 때는 아직 실제 사이즈가 계산되어지지 않고, viewDidAppear() 일 때 측정하면 값이 나온다고 한다. 아마 UITableViewDelegate의 func tableView(_ tableView: UITableView, viewForHeaderInSection section: Int) -> UIView? 같은 경우도 아직 viewDidAppear()가 호출된 상태가 아니기 때문에, 즉 뷰에 띄워진 상태가 아니기 때문에 무수한 0을 뱉어낸 것 같다.

그래서 혹여나! 싶어서 viewDidLoad() 에다가 setGradient()를 다시 호출해보았다.

    override func viewDidAppear(_ animated: Bool) {

        super.viewDidAppear(animated)

        card.setGradient(color1: UIColor.black, color2: UIColor.blue)

    }

완전잘됨...!!

UIViewController의 LifeCycle을 찾아보고 한 번 테스트 해봤다.

(213.0 이라고 출력된 것은 무시해도 된다.) viewDidAppear() 이전까지 frame.size 출력 값이 다 (0.0, 0.0)인 것을 확인할 수 있었다! 그리고 viewDidAppear() 이전에 tableView와 관련된 함수가 호출되는 것까지 확인했다. 그러다보니 frame값이 0이 나온 것 같다.

역시 사람은 서칭을 해야해...b

Spring Boot Configuration Annotation Processor not configured

인터넷에 검색해보니 build.gradle에 아래와 같이 추가를 하면 된다고 한다.

dependencies {
...
    annotationProcessor "org.springframework.boot:spring-boot-configuration-processor" // Use ConfigurationProperties
}

그런데 이걸 추가하고 또 확인해보면 이번엔 새로운 문구가 뜬다.

re-run spring boot configuration annotation processor to update generated metadata

인텔리제이에서는 그냥 Invalidate Caches... 해주면 해결된다!

일단 제일 처음 aws 의 Beanstalk에 들어간다. 간단하게 '시작하기'클릭! 환경 설정을 해준다. 이후로 나는 어차피 테스트하고 지울거기에 다음,다음,다음만 눌러주었다.

그리고 파일을 업로드 하기 위해서 작성했던 코드를 빌드를 진행해준다.

빌드할 때 특징은 application.properties 파일을 따로 만들었다는 것이다. application-proc.properties로 하나 만들고, 빌드할 때 VM Options 에 -Dspring.profiles.active=proc 를 추가해주었다. 만약 proc이 아닌 dev 나 그런것들을 쓰고싶다면, 저렇게 사용하면 된다. 또! 중요한 것은 Beanstalk은 기본적으로 5000포트 라고 한다. 그래서 application-proc.properties에 server.port=5000 또한 추가해주고 aws의 RDS를 생성해서 데이터베이스도 따로 세팅해주었다. 쨘 성공!

Spring boot 3 미만에서는 springfox-swagger2 와 springfox-swagger-ui 를 의존성 축라해서 사용해야 하지만, 3 이상부터는 그냥 하나의 의존성만 추가해주면 된다.

implementation 'org.springdoc:springdoc-openapi-starter-webmvc-ui:2.0.2'

보면 이름이 다른 것을 알 수 있다. 구글링해서 찾아봤는데, 사람마다 하는 이야기가 달라서 좀 헷갈리긴 한다. 일단 swagger는 2020을 마지막으로 업데이트가 되지 않고 있다. 그 사이에 나온 게 SpringDoc(2019년)인데, 비교적 최근까지 업데이트가 되었다.

Springdoc은 Webflux라는 논 블록킹 비동기 방식의 웹 개발을 지원하도록 되어 있으며, springfox보다 더 사용하기 쉽다고 한다.(둘 다 심도있게 써보진 않아서 나는 비교하지 못하겠다.)

일단 한번 사용을 해보자.

application.properties 에 아래와 같이 등록해 줄 수 있다.

# spring doc
# springdoc.swagger-ui.path=/swagger-ui.html
springdoc.api-docs.path=/api-docs/json
springdoc.packagesToScan=com.hyeon.demo.controller
# springdoc.pathsToMatch=/boards

주석 처리되어 있는 것은 내가 추후에 쓰지 않으려고 한 것이다.

• springdoc.swagger-ui.path=/swagger-ui.html : HTML 페이지를 보여줄 url을
• springdoc.api-docs.path=/api-docs/json : json 페이지를 보여줄 url을 정한다.
• springdoc.packagesToScan=com.hyeon.demo.controller: API 문서를 작성할 패키지명을 넣어준다. 여러개 넣으려면 그냥 ,(쉼표) 써서 연결해 작성하면 된다.
• pringdoc.pathsToMatch=/boards : API 문서를 작성할 API 범위를 지정한다. /boards와 같이 쓰면 /boards 인 API 만 작성되어지고, /boards/** 와 같이 작성하면 /boards/ 하위 API 들이 다 작성되어진다.

여기 에서 더 다양한 값들을 찾아볼 수 있다.

그 후 나는 SwaggerConfig.java 를 생성하였다.

@Configuration
public class SwaggerConfig {

    @Bean
    public GroupedOpenApi publicApi() {
        return GroupedOpenApi.builder()
                .group("board-public")
                .pathsToMatch("/boards/**")
                .build();
    }

    @Bean
    public GroupedOpenApi adminApi() {
        return GroupedOpenApi.builder()
                .group("board-admin")
                .pathsToMatch("/**")
                .addOpenApiMethodFilter(method -> method.isAnnotationPresent(Admin.class)) //@Admin이 붙어 있는 Method만
                .build();
    }

    @Bean
    public OpenAPI springShopOpenAPI() {
        return new OpenAPI()
                .info(new Info().title("Board API")
                .description("Simple Board API")
                .version("v0.0.1"));
    }

}

GroupedOpenApi 같은 경우는 그룹을 생성해준다. 저렇게 생성해주면, 페이지를 열었을 때 아래와 같이 셀렉트 박스를 통해 선택할 수 있게 된다.

이 후 서버를 실행해보면, 아래와 같은 페이지가 나타난다.

추가적으로, .addOpenApiMethodFilter(method -> method.isAnnotationPresent(Admin.class)) 에 있는 Admin.class 는 @interface 즉, 어노테이션이며 아래와 같이 선언만 해주었다.

public @interface Admin {

}

이 어노테이션이 달린 메서드만 추려내서 board-admin 그룹에 보이게 된다.

끝 -*

• 내용은 1글자 이상 1000글자 이하여야 한다.
• 제목은 공백으로만 이루어질 수는 없다.
• 게시글의 id(PK, primary key)로 특정 게시글을 조회했을 때, 존재하지 않는 게시글일 경우 에러 메시지로 응답하기
• 게시글을 수정할 때, 게시글 작성할 때의 유효성 검사 조건과 동일하게 가져가야 한다.
• 게시글의 id(PK, primary key)로 특정 게시글을 삭제하기 위해 조회했을 때, 존재하지 않는 게시글일 경우 에러 메시지로 응답하기
• 검색 키워드는 공백을 제외한 1글자 이상이어야 한다.

마지막 검색 키워드 관련된 것은 나중에 보면 알겠지만 내가 조건을 좀 달리했다. 어차피 공부하려고 하는 거니까 이것저것 시도해보는 것은 좋은 것일 거다...(아마...)!

build.gradle에 아래와 같이 validation체크를 위해 의존성을 추가해준다.

implementation 'org.springframework.boot:spring-boot-starter-validation'

준비는 다 됬으니, BoardRequest.java에서 요구사항에 맞게 어노테이션을 사용해서 유효성 검사를 해보자.

제목은 공백으로만 이루어질 수는 없다.

    @NotBlank(message = "제목은 NULL이 아니어야 합니다.")
    private String title;

@NotNull : 모든 타입에 대해 NULL을 허용하지 않는다. @NotEmpty : 아래 타입들에 한해서만 지원하며, NULL과 ""를 허용하지 않는다. - CharSequence (length of character sequence is evaluated) - Collection (collection size is evaluated) - Map (map size is evaluated) - Array (array length is evaluated) @NotBlank : NULL과 "", " "(whitespace)를 허용하지 않는다.

내용은 1글자 이상 1000글자 이하여야 한다.

    @Size(min = 1, max = 1000)
    private String content;

@Size : 문자열이나 배열ㅇ릐 크기를 검증하는데 사용된다.

게시글의 id(PK, primary key)로 특정 게시글을 조회했을 때, 존재하지 않는 게시글일 경우 에러 메시지로 응답하기

먼저 BoardServiceImpl을 수정해주었다.

    @Override
    @Transactional
    public Board update(int id, BoardRequest boardRequest) {
        Optional<Board> board = repository.findById(id);
        if(board.isPresent()) {
            board.get().update(boardRequest.getTitle(), boardRequest.getContent());
            return board.get();
        } else {
            return null;
        }
    }

해당 id값을 가진 게시글이 존재하면 수정을 거친 뒤 true를 반환해주고, id값을 가진 게시글이 존재하지 않으면 바로 false를 반환해준다.

그 후, BoardController 에서 아래와 같이 반환해준다.

    @PutMapping("/{id}")
    public ResponseEntity<?> updateBoard(@PathVariable("id") int id, @Validated @RequestBody BoardRequest boardRequest) {
        Board board = boardService.update(id, boardRequest);
        if(board == null) {
            return ResponseEntity.status(HttpStatus.NOT_FOUND)
                    .body("Invalid Board Id.");
        }
        return ResponseEntity.status(HttpStatus.OK)
                .body(board);
    }

게시글의 id(PK, primary key)로 특정 게시글을 삭제하기 위해 조회했을 때, 존재하지 않는 게시글일 경우 에러 메시지로 응답하기

수정과 마찬가지로 BoardService와 BoardSerivceImpl 로직들을 수정해주었다.

    @Override
    public boolean delete(int id) {
        Optional<Board> board = repository.findById(id);
        if(board.isPresent()) {
            repository.deleteById(id);
            return true;
        } else {
            return false;
        }
    }

id를 통해 조회했을 때 값이 있으면 해당 게시글을 삭제하고 true를 반환해준다. id를 통해 조회했을 때 값이 없으면 바로 false를 반환해준다.

그러면 BoardController.java에서는 아래와 같이 리턴 값을 이용해 유효성 검사를 해준다.

    @DeleteMapping("/{id}")
    public ResponseEntity<?> deleteBoard(@PathVariable int id) {
        boolean isDeleted = boardService.delete(id);
        if(!isDeleted) {
            return ResponseEntity.status(HttpStatus.NOT_FOUND)
                    .body("Invalid Board Id.");
        }
        return ResponseEntity.status(HttpStatus.OK)
                .build();
    }

게시글을 수정할 때, 게시글 작성할 때의 유효성 검사 조건과 동일하게 가져가야 한다.

이는 같은 BoardRequest 를 사용하기 때문에 따로 수정하지 않아도 똑같이 적용된다!

검색 키워드는 공백을 제외한 1글자 이상이어야 한다.

드디어 내가 좀 생각을 바꿔서 추가했다는 기능에 도착했다. 나는 공백이 글자의 좌,우에 존재하면 지워주고 공백이어도 검색이 가능하도록 바꾸어보았다.

그 이유는, 어차피 게시판에서 빈 칸인 상태에서 검색하는 케이스도 있다고 생각했기 때문이다. 그래서 나는 아래와 같이 그냥 title에 trim()메소드를 이용해서 whitespace를 지워주었다.

    @GetMapping()
    public ResponseEntity<?> findAllBoards(@RequestParam("title") String title, Pageable pageable) {
        List<Board> boards = boardService.findAll(title.trim(), pageable); //title.trim()
        return ResponseEntity.status(HttpStatus.OK)
                .body(boards);
    }

끝-*

먼저, Repository interface 를 수정해주었다.

    List<Board> findByTitleContainingOrderByCreatedAtDesc(String title, Pageable pageable);

    List<Board> findByTitleContainingOrderByCreatedAtAsc(String title, Pageable pageable);

원래는 이렇게 있던 것을 아래와 같이 수정하였다.

     List<Board> findByTitleContaining(String title, Pageable pageable);

Service 도 마찬가지로 수정해주었다. 원래는 직접 order 파라미터를 받아서 DESC일 경우와 ASC일 경우를 분기처리해서 각각 다른 Repository 메소드를 타게 했는데 이제 하나로 통일하였다.

    public List<Board> findAll(String title, String order, Pageable pageable) {
        if(order.equalsIgnoreCase("DESC")) {
            return repository.findByTitleContainingOrderByCreatedAtDesc(title, pageable);
        } else {
            return repository.findByTitleContainingOrderByCreatedAtAsc(title, pageable);
        }
    }

이렇게 되어 있던 것을 아래와 같이 수정하였다.

    public List<Board> findAll(String title, Pageable pageable) {
        return repository.findByTitleContaining(title, pageable);
    }

그리고 이제는 더이상 필요없는 order 파라미터를 컨트롤러와 서비스 쪽에서 삭제해고, 파라미터를 보내서 테스트를 해보니 매우 잘 작동하였다!

Request

Response

sort 파라미터 안에다가 배열로 우선 순위대로 나열할 파라미터를 나열하면, 그 순서대로 정렬해준다. 그리고 파라미터 옆에 ",DESC", ",ASC"를 붙이면 내림차순 오름차순이 설정이 된다. 너무 유용하니 꼭 기억해 두어야 겠다.

끝-*

Optional 클래스는 Integer나 Double 클래스처럼 'T'타입의 객체를 포장해 주는 래퍼 클래스(Wrapper class)입니다. 따라서 Optional 인스턴스는 모든 타입의 참조 변수를 저장할 수 있습니다. 출처 : 코딩의 시작, TCP School

우리는 코딩을 하다가 NullPointException(이하, NPE)를 많이 접하게 된다. 항상 코드를 짜다 보면, 나같은 경우도 가장 많이 걱정하는게 NPE이다. 그러다보니 사실 많이 번거롭고 코드도 길어지고... 나름 스트레스다...ㅠㅠ 특히 생각하지 못한 곳에서 NPE가 터지면.... 😵‍💫

NULL을 개발한 사람도 나중에는 자신이 "10억불 짜리 큰 실수"를 했으며, NULL을 만든 것을 후회한다고 하였다.

NPE를 피하기 위해 우리는 아래와 같이 항상 null체크를 해주어야만 했다.

      Board board = getBoard(); //Board 객체를 가져오는 어떤 함수라고 가정
      if(board != null) {
          User user = board.getUser();
          if(user != null) {
              // 하고 싶은 일 작성
          }
      }

이렇게 객체안의 객체도 계속 null체크를 해주어야 NPE로부터 마음이 편해질 수 있었다. 그런데 Optional이 등장하면서 아주 편리해졌다.

      Optional<Board> board = Optional.ofNullable(getBoard());
      Optional<User> user = board.map(Board::getUser);

      board.

나같은 경우는 iOS 개발을 시작하면서 Swift를 공부했었는데, 거기에서 Optional이 있어서 아주 편했던 기억이 난다.(문법 자체는 그동안 공부했던 java나 c와 같은 언어와 달라서 당황했지만...;;) 아무튼 오늘은 이 Optional에 대해 한 번 공부해보려고 한다.

Optional 선언

1. static Optional empty()

비어있는 객체를 리턴해준다. Null 값이 올 수도 있는 변수의 자료형을 제너릭 타입으로 선언한다.

      Optional<T> opt = Optional.empty(); //Null이 올 수도 있음

2. static Optional of(T value)

Null이 아닌 명시된 값을 가지고 있는 Optional 객체를 반환한다. Null인 경우 NPE를 던진다.

      Optional<String> opt = Optional.of("Apple");

3. static Optional ofNullable(T value)

명시된 값이 Null이 아니면, 명시된 값을 가지는 Optional 객체를 반환한다. 명시된 값이 Null이면, 비어있는 Optional 객체를 반환한다.

      Optional<String> opt = Optional.ofNullable(null);

Optional 메소드

1. T get()

Optional 객체에 저장된 값을 반환한다.

2. T isPresent()

저장된 값이 존재하면 true를 반환하고, 존재하지 않으면 false를 반환한다.

3. T orElse(T other)

저장된 값이 존재하면 그 값을 반환하고, 존재하지 않으면 인수로 전달된 값을 반환한다.

4. T orElseGet(Supplier<? extends T> other)

저장된 값이 존재하면 그 값을 반환하고, 존재하지 않으면 인수로 전달된 람다 표현식의 결과값을 반환한다.

5. T orElseThrow(Supplier<? extends X> exceptionSupplier)

저장된 값이 존재하면 그 값을 반환하고, 존재하지 않으면 인수로 전달된 예외를 발생시킨다.

6. Optional or(Supplier<? extends Optional<? extends T>> supplier) - java 9

중간처리 메서드로 기본값을 제공할 수 있는 공급자 함수를 정의할 수 있다. 기존에 제공중인 .orElseGet()과 유사하지만, 중간에 체이닝을 통해 우선순위를 결정할 수 있다. 물론 .or() 연산 중에 비어있는 옵셔널이 된다면 다음 .or() 메서드로 진행하게 된다.

  String result = Optional.ofNullable("test")
          .filter(value -> "filter".equals(value))
          .or(Optional::empty)
          .or(() -> Optional.of("second"))
          .orElse("final");
  System.out.println(result); // print 'second'

7. void ifPresentOrElse(Consumer<? super T> action, Runnable emptyAction) - java 9

첫번째 매개변수인 action은 유효한 객체를 받을 경우 실행하고, 두번째 매개변수인 emptyAction은 유효한 객체를 받지 못한 경우 실행한다.

  Optional.ofNullable(null)
      .ifPresentOrElse(value -> System.out.println(value), () -> System.out.println("null")); // print 'null'

8. Stream stream() - java 9

Optional 객체를 Stream 객체로 전환한다.

  List<String> result = List.of(1, 2, 3, 4)
    .stream()
    .map(val -> val % 2 == 0 ? Optional.of(val) : Optional.empty())
    .flatMap(Optional::stream)
    .map(String::valueOf)
    .collect(Collectors.toList());
  System.out.println(result); // print '[2, 4]'

Optional<List> 와 같이 사용하면 Optional도 null체크를 하고 List도 null체크를 해야하기 때문에 가독성이 떨어진다. 항상 List를 사용할 때에는 List를 채워주는 것이 좋다.

  List data = Optional.ofNullable(somethingList).orElse(Collections.emptyList());
  if (!data.isEmpty()) {
      // do something...
  }

끝-*

참고 자바 옵셔널 [JAVA] Optional이란?

데이터를 가져올 때 검색, 정렬, 갯수제한 기능을 추가해 보려고한다. 갯수제한을 그냥 limit로 보는게 아니라 Pagination느낌으로 해보려고 한다.

Spring Data JPA가 제공하는 PageNation이 있는데, Pageable과 PageRequest이다. Pageable은 페이지네이션 정보를 담기 위한 인터페이스, PageRequest은 구현체이다.

Pageable 인터페이스를 확인해보면, pageNumber, pageSize, offset과 같은 페이징 구현에 필요한 값들을 편하게 구할 수 있는 메소들을 추상화 시켜놓은 것을 확인할 수 있다.

이제 이것을 이용해서 한 번 구현해보자!

먼저 Repository를 구현해보자.

    List<Board> findByTitleContainingOrderByCreatedAtDesc(String title, Pageable pageable);

위의 구문은 title 단어가 들어 있는 제목을 탐색하고(findByTitleContaining), created_at을 기준으로 내림차순(desc)을 하겠다는(OrderByCreated) 의미이다.

이것을 Service 계층에서 사용해보자. 이전에 만들어 놓았던 findAll() 메소드를 수정해서 사용할 것이다.

    @Override
    public List<Board> findAll(String title, String order, Pageable pageable) {
        if(order.equalsIgnoreCase("DESC")) {
            return repository.findByTitleContainingOrderByCreatedAtDesc(title, pageable);
        } else {
            return repository.findByTitleContainingOrderByCreatedAtAsc(title, pageable);
        }
    }

나는 내림차순, 오름차순을 구분해 주고 싶어서 Repository에 메소드를 하나 더 생성했다.

아무튼, findAll() 메소드가 받는 매개변수도 달라졌기 때문에 Controller 계층도 수정을 해줘야한다.

    @GetMapping()
    public ResponseEntity<List<Board>> findAllBoards(@RequestParam String title, @RequestParam String order, Pageable pageable) {
        List<Board> boards = boardService.findAll(title, order, pageable);
        return ResponseEntity.status(HttpStatus.OK)
                .body(boards);
    }

이제 모든 준비는 끝났다! 포스트맨으로 API를 호출해 보면,

    [GET] http://localhost:8080/boards?page=0&size=5&title=영화&order=asc

[
    {
        "id": 5,
        "title": "어린왕자 만화영화 봤니?",
        "content": "재밌더라~",
        "createdAt": "2023-05-14T15:33:31.000+00:00",
        "updatedAt": "2023-05-14T15:33:31.000+00:00",
        "isDeleted": null
    },
    {
        "id": 6,
        "title": "어린왕자 만화영화 봤니?",
        "content": "재밌더라~",
        "createdAt": "2023-05-14T15:34:26.000+00:00",
        "updatedAt": "2023-05-14T15:34:26.000+00:00",
        "isDeleted": null
    },
    {
        "id": 7,
        "title": "어린왕자 만화영화 봤니?",
        "content": "재밌더라~",
        "createdAt": "2023-05-14T15:34:30.000+00:00",
        "updatedAt": "2023-05-14T15:34:30.000+00:00",
        "isDeleted": null
    },
    {
        "id": 8,
        "title": "어린왕자 만화영화 봤니?",
        "content": "재밌더라~",
        "createdAt": "2023-05-14T15:36:10.000+00:00",
        "updatedAt": "2023-05-14T15:36:10.000+00:00",
        "isDeleted": null
    },
    {
        "id": 9,
        "title": "어린왕자 만화영화 봤니?",
        "content": "재밌더라~",
        "createdAt": "2023-05-14T15:37:51.000+00:00",
        "updatedAt": "2023-05-14T15:37:51.000+00:00",
        "isDeleted": "N"
    }
]

이런 결과가 나오는 것을 확인해 볼 수 있다. 데이터들은 내가 계속 같은 값만 넣어서 똑같은 값을 보여주는 것일 뿐이다... 잘보면 createdAt 시간은 다르다... ㅎㅎ

page를 1로 바꾸면 이 데이터들 다음 데이터부터 5개가 출력된다.

끝 -*

ORM(Object-Relational Mapping)은 대체 무엇일까? 이것은 자바의 객체와 데이터베이스(이하, 디비)를 연결하는 프로그래밍 기법이다. 예를 들어, 자바의 객체로 Board라는 객체가 있고 title, content 필드가 있다고 가정해보자. 이것을 디비로부터 값을 받아와서 넣어주려면 SQL 쿼리를 이용해야 한다. 그러면 우리는 또 SQL을 공부하는 번거로움을 갖게 된다. (그런데 나는 사실 SQL을 아주 좋아한다...)

아무튼! ORM은 이런 번거로움을 없애주고 디비의 값을 마치 객체처럼 사용할 수 있게 해준다. 즉, SQL 공부를 하지 않아도 자바 언어로 디비 값을 조회 및 조작할 수 있게 되는 것이다. 이걸 해줄 수 있게 해주는 도구가 바로 ORM이다.

그런데 어렵고 복잡한 쿼리문 같은 경우는 자바 코드로 치는데 한계가 있을 것이다. 이것은 어쩔 수 없다고 생각한다... (편리함 대신 얻는 대가랄까...)

2. JPA와 Hibernate

스프링을 돌리다보면 JPA, Hibernate 단어를 많이 접하게 된다. 나같은 경우도 JPA, JPA 거리기만 했지 정말 JPA가 무엇이고, Hibernate가 무엇인지 잘 몰랐다. 오늘의 공부를 통해 확실히 알아가도록 하자.

JPA는 자바에서 RDBMS를 사용하는 방식을 정의한 인터페이스이다. 인터페이스이기 때문에 이를 실제로 사용하기 위한 구현체를 추가로 갖춰야하는데 그 중 하나가 Hibernate되겠다.

즉, *Hibernate = JPA 인터페이스를 구현한 구현체이자 자바용 ORM 프레임워크 *이다.

3. 엔티티 매니저 + 영속성 컨텍스트

엔티티 매니저와 영속성 컨텍스트는 JPA의 중요한 컨셉 중 하나이다.

엔티티

엔티티는 디비의 테이블과 매핑되는 객체를 의미한다. 디비의 테이블과 직접 연결된다는 특징이 있어서 자바 객체와 다르게 엔티티라고 따로 지칭한다.

엔티티 매니저

엔티티 매니저는 엔티티를 관리해 디비와 어플리케이션 사이에서 객체를 생성, 수정, 삭제하는 등의 역할을 한다. 이런 엔티티 매니저를 만드는 곳이 엔티티 매니저 팩토리이다. 만약에 회원 두 명이 동시에 책을 빌리면, 회원 1의 요청에 대응해줄 엔티티 매니저와, 회원 2의 요청에 대응해줄 엔티티 매니저를 엔티티 매니저 팩토리에서 각각 생성해주는 것이다. 그리고 이렇게 생성된 엔티티 매니저들은 필요한 시점에 디비와 연결한 뒤에 쿼리를 실행한다.

BUT, 스프링 부트에서는 직접 엔티티 매니저 팩토리를 만들어서 관리하지 않고, 스프링 부트 내부에서 엔티티 매니저 팩토리를 하나만 생성해서 관리하고 @PersistenceContext 또는 @Autowired 어노테이션을 통해 엔티티 매니저를 사용한다.

그리고 스프링 부트는 기본적으로 빈은 하나만 생성해서 공유하므로 동시성 문제가 발생할 수 있다. 그래서 실제로는 엔티티 매니저가 아닌 실제 엔티티 매니저와 연결하는 프록시(가짜)엔티티 매니저를 사용한다. 필요할 때 디비 트랜잭션과 관련된 실제 엔티티 매니저를 호출하는 것이다.

쉽게 말해 엔티티 매니저는 Spring Data JPA 에서 관리하므로 우리가 직접 생성하거나 관리할 필요가 없다.

그리고 추가적으로 엔티티 매니저는 기본적으로 UPDATE를 제공하지 않는다. JPA는 트랜잭션의 범위에서 엔티티 객체의 상태가 변경되면 이를 트랜잭션 커밋 시점에 반영한다.

영속성 컨텍스트

영속성 컨텍스트는 JPA의 중요한 특징 중 하나로, 엔티티를 관리하는 가상의 공간이다. 영속성 컨텍스트는 아래와 같은 특징을 가지고 있다.

1. 1차 캐시 영속성 컨텍스트는 내부에 1차 캐시를 가지고 있다. 이 때 키는 @Id 어노테이션이 달린 필드 값이 되겠다. 엔티티를 조회하면 1차 캐시에서 먼저 조회해 값을 반환한다. 1차 캐시에 값이 없으면 디비에서 조회해 1차 캐시에 저장하고 반환한다.
2. 쓰기 지연 쓰기 지연은 트랜잭션을 커밋하기 전까지는 실제로 디비에 질의문을 보내지 않고 쿼리를 모아두었다가 트랜잭션을 커밋할 때 한 번에 실행하는 것을 말한다. 이를 통해 디비 시스템의 위험 부담을 줄일 수 있다.
3. 변경 감지 트랜잭션을 커밋하면 1차 캐시에 저장되어 있는 엔티티의 값과 현재 엔티티의 값을 비교해서 변경된 값이 있다면 변경사항을 감지해 변경된 값을 디비에 자동으로 반영한다.
4. 지연 로딩 지연로딩은 쿼리로 요청한 데이터를 어플리케이션에 바로 로딩하는 것이 아니라 필요할 때 쿼리를 날려 데이터를 조회하는 것을 말한다. 반대로 조회할 때 쿼리를 보내 연관된 모든 데이터를 가져오는 즉시 로딩도 있다.

엔티티의 생명주기

public class EntityManagerTest {

    @Autowired
    EntityManager em;

    public void example() {
        // 엔티티 매니저가 엔티티를 관리하지 않는 상태 = 비영속 상태
        Member member = new Member(1L, "홍길동");

        // 엔티티가 관리 상태가 됨 = 관리 상태
        em.persist(member);

        // 엔티티 객체가 분리된 상태가 됨 = 분리 상태
        em.detach(member);

        // 엔티티 객체가 삭제된 상태가 됨 = 삭제 상태
        em.remove(member);
    }

}

• 비영속 상태 엔티티 객체를 생성했지만 아직 영속성 컨텍스트에 저장하지 않은 상태

• 영속 상태 엔티티 매니저를 통해서 엔티티를 영속성 컨텍스트에 저장한 상태를 말하며 엔티티 매니저에 의해 관리된다.

• 준영속 상태 영속 상태의 엔티티를 더이상 관리하지 않는 상태이다. 1차 캐시, 쓰기 지연, 변경 감지, 지연 로딩을 포함한 영속성 컨텍스트가 제공하는 어떠한 기능도 동작하지 않는다. 식별자 값을 가지고 있다.

• 삭제 엔티티를 영속성 컨텍스트와 디비에서 삭제한다.

4. 스프링 데이터 JPA

위와 같은 코드들을 개발자가 계속 작성해가면서 관리하면 매우 번거로울 것이다. 스프링 데이터는 비즈니스 로직에 더 집중할 수 있게 디비 사용 기능을 클래스 레벨에서 추상화하였다.

이전까지는 아래와 같이 메서드 호출로 엔티티 상태를 바꿔주었다.

@PersistenceContext
EntityManager em;

public void join() {
    Member member = new Member(1L, "홍길동");
    em.persist(member);
}

이제 스프링 데이터 JPA를 사용하면 아래와 같이 하면 된다.

public interface MemberRepository extends JPARepository<Member, Log> {
}

끝 -*

참고자료

엔티티와 엔티티매니저 JPA, Hibernate, 그리고 Spring Data JPA의 차이점 What is ORM, how does it work? JPA 영속성 컨텍스트란? [도서] 스프링 부터 3 백엔드 개발자 되기

특정 한 게시판을 조회하는 API를 만들어 보려고 한다.

먼저 Service 코드부터 작성해보자.

    @Override
    public Board findOne(int id) {
        return repository.findById(id)
                .orElseThrow(() -> new IllegalArgumentException("not found : " + id));
    }

findById 는 CrudRepository 에 있는 메소드이다. id 를 기반으로 Board를 탐색한다. 서비스 코드를 작성했으니 컨트롤러를 작성해보자.

    @GetMapping("/{id}")
    public ResponseEntity<Board> findOneBoard(@PathVariable int id) {
        Board board = boardService.findOne(id);
        return ResponseEntity.status(HttpStatus.OK)
                .body(board);
    }

이러면 벌써 게시글 하나 조회하는 API는 작성이 완료되었다. JPA를 이용하니 더욱더 간단하다.

2. 게시판 수정 API 만들기

게시판 수정 API도 위와 마찬가지로 하면 되지만, 한 가지 단계를 더 추가해야한다. 이전에 만들었던 Board DTO 객체에 update 메소드를 추가해준다.

    public void update(String title, String content) {
        this.title = title;
        this.content = content;
    }

그 후 이전에 했던 방법과 마찬가지로 각각 서비스와 컨트롤러 부분 코드를 작성해준다.

    @Override
    @Transactional
    public Board update(int id, BoardRequest boardRequest) {
        Board board = repository.findById(id)
                        .orElseThrow(() -> new IllegalArgumentException("not found : " + id));
        board.update(boardRequest.getTitle(), boardRequest.getContent());
        return board;
    }

그런데 업데이트 메소드를 보면 위에 @Transactional 이 붙은 것을 확인할 수가 있다. 이 어노테이션은 매칭한 메서드를 하나의 트랜잭션으로 묶어준다. 예를 들어 내가 A의 계좌에 돈을 송금하면 A의 계좌엔 돈이 입금 되어야 하는데, 돈이 송금되고 나서 시스템이 멈춰버리면 돈은 감쪽같이 사라지게 된다. 그렇기 때문에 이 두가지 작업을 하나로 묶어서, 즉, 트랜잭션으로 묶어서 한 단위로 실행하게끔 만드는 것이다. 여기서는 Board를 읽어오는 단위와 수정해주는 단위를 하나로 묶어서 작업한 것이다.

    @PutMapping("/{id}")
    public ResponseEntity<Board> updateBoard(@PathVariable int id, @RequestBody BoardRequest boardRequest) {
        Board board = boardService.update(id, boardRequest);
        return ResponseEntity.status(HttpStatus.OK)
                .body(board);
    }

컨트롤러는 이전과 다를바가 없다.

3. 게시판 삭제 API 만들기

삭제도 마찬가지로 별 다를게 없다. 각 서비스 코드와 컨트롤러 코드를 작성해 주자.

    @Override
    public void delete(int id) {
        repository.deleteById(id);
    }

    @DeleteMapping("/{id}")
    public ResponseEntity<Void> deleteBoard(@PathVariable int id) {
        boardService.delete(id);
        return ResponseEntity.status(HttpStatus.OK)
                .build();
    }

삭제를 마지막으로 CRUD API를 다 만들었다! 끝 -*

가장 먼저 엔티티를 구성해보겠다.

나는 일단 제목과 내용을 우선적으로 넣을 것이기 때문에 이정도로 간단하게만 구상해보았다.

이제는 코드로 엔티티 클래스를 하나 만들어 보자.

@Entity //Entity로 지정
@Getter
public class Board {

    @Id // PK로 지정
    @GeneratedValue(strategy = GenerationType.IDENTITY) // 기본키 자동으로 1씩 증가
    @Column(name = "id", nullable = false)
    private int id;

    @Column(name = "title", nullable = false)
    private String title;

    @Column(name = "content", nullable = false)
    private String content;

    @CreationTimestamp
    @Column(name = "created_at")
    private Date createdAt;

    @UpdateTimestamp
    @Column(name = "updated_at")
    private Date updatedAt;

    @Column(name = "is_deleted")
    private String isDeleted = "N";

    @Builder
    public Board(String title, String content) {
        this.title = title;
        this.content = content;
    }

    protected Board() {

    }
}

@Entity가 붙은 클래스는 JPA가 관리해주며, JPA를 사용해서 DB테이블과 매핑할 클래서는 @Entity를 꼭 붙여야만 매핑이 가능하다.

@Getter와 같은 경우는 getXXX 메소드를 자동으로 생성해준다. 예를 들어 title같은 경우는 getTitle()을 통해 그 값을 읽을 수 있다.

@Builder와 같은 경우는 생성자 위에 입력하면 빌더 패턴 방식으로 객체를 생성할 수 있게 된다. 빌더 패턴을 사용하면 어떤 필드에 어떤 값이 들어가는지 명시적으로 파악할 수 있다.

예를 들어 기본 생성자와 같은 경우는

new Board("잭과 콩나무 읽어보셨나요?", "어린아이가 읽기 너무 좋아요.");

와 같이 되겠지만, 빌더 패턴을 사용하면

Board.builder()
    .title("잭과 콩나무 읽어보셨나요?")
    .content("어린아이가 읽기 너무 좋아요.")
    .build();

이렇게 사용할 수 있다. 딱 보면 title에 어떤 값이 들어갔고, content에 어떤 값이 들어갔는지 쉽게 유추할 수가 있다.

2. 레포지토리 만들기

repository 패키지를 새로 만들고 Repository 인터페이스를 한 번 생성해 보자.

public interface BoardRepository extends JpaRepository<Board, Long> {

}

BoardRepository는 JpaRepository를 상속받는다. JpaRepository는 CrudRepository를 상속받는데 이 클래스에는 기본적인 CRUD 메소드가 포함되어 있다.

3. 서비스 코드 작성하기

@Service
public class BoardServiceImpl implements BoardService {

    BoardRepository repository;

    @Autowired
    public BoardServiceImpl(BoardRepository repository) {
        this.repository = repository;
    }

    // 게시글 리스트 불러오는 메소드
    @Override
    public List<Board> findAll() {
        return repository.findAll();
    }

    // 게시글 저장 메소드
    @Override
    public Board save(BoardRequest boardRequest) {
        return repository.save(boardRequest.toEntity());
    }

}

4. 컨트롤러 코드 작성하기

@RestController
@RequestMapping("/board")
public class BoardController {

    BoardService boardService;

    @Autowired
    public BoardController(BoardService boardService) {
        this.boardService = boardService;
    }

    @GetMapping()
    public ResponseEntity<List<Board>> findAllBoards() {
        List<Board> boards = boardService.findAll();
        return ResponseEntity.status(HttpStatus.OK)
                .body(boards);
    }

    @PostMapping()
    public ResponseEntity<Board> addBoard(@RequestBody BoardRequest boardRequest) {
        Board board = boardService.save(boardRequest);
        return ResponseEntity.status(HttpStatus.CREATED)
                .body(board);
    }

}

@RestController 어노테이션을 붙이면 HTTP 응답으로 객체 데이터를 JSON 형식으로 반환한다.

return 객체로는 ResponseEntity를 지정했는데, 아래와 같은 응답코드와 함께 객체를 반환해준다.

• 200 OK : 요청이 성공적으로 수행됨
• 201 Created : 요청이 성공적으로 수행되었고, 새로운 리소스가 생성되었음
• 400 Bad Request : 요청 값이 잘못되어 요청에 실패했음
• 403 Forbidden : 권한이 없어 요청에 실패했음
• 404 Not Found : 요청 값으로 찾은 리소스가 없어 요청에 실패했음
• 405 Method Not Allowed : 지정된 메소드가 허용되지 않음
• 500 Internal Server Error : 서버 상에 문제가 있어 요청에 실패했음

이 외에도 응답코드가 여럿 있으니 필요하면 찾아보자.

이제 이 상태에서 서버를 구동하고 Postman으로 테스트를 해보자.

Get 방식의 /board API에 요청을 했더니

이렇게 미리 넣어둔 데이터들이 잘 나오는 것을 확인해볼 수 있다.

Post 방식의 /board API도 마찬가지다.

이렇게 API 두개를 만들어보고 테스트까지 완료했다. 이와 마찬가지 방식으로 삭제와 수정, 그리고 한 개의 게시글 조회 API까지 만들어 보려고 한다.

끝-*

일단 가장 먼저 Rest API란 무엇일까? Rest API란 URL의 설계 방식을 의미한다. 주소와 메서드만 보고 요청의 내용을 파악할 수 있다는 강력한 장점이 있어 많은 개발자들이 사용한다고 한다.

그러면 Rest API는 어떻게 사용할까?

1. URL에는 동사를 쓰지 말고, 자원을 표시해야 한다.

예를 들어서 게시판의 내용을 리턴해주는 API를 만든다고 해보자. /getBoard?Id=1 /board?id=1 물론, 둘 다 사용해도 되지만, 어떤 개발자는 getBoard가 아닌 showBoard와 같이 사용한다면 API는 엉망이 될 것이다. 그래서 Restful API를 설계할 때는 이런 동사를 사용하지 않는다.

2. 동사는 HTTP 메서드로

HTTP 메서드란 서버에 요청하는 방법을 나눈 것이다. 주로 사용하는 것들로는 GET, POST, PUT, DELETE 방식이 있다. 각각 POST-CREATE, GET-READ, PUT-UPDATE, DELETE-DELETE의 역할을 하는데 이것을 CRUD 라고 부른다.

특정 게시글을 가져오려면 GET /board/1

특정 게시글을 생성하려면 POST /board/1

특정 게시글을 수정하려면 PUT /board/1

특정 게시글을 삭제하려면 DELETE /board/1

과 같이 사용하면 된다.

위 규칙들을 지켜가며 게시판 API를 앞으로 개발해 나가 보겠다.