Redddy's Devlog

1부 객체지향1. 절차지향과 비교하기객체지향 이야기가 나올 때 친구처럼 나오는 녀석이 바로 절차지향이다. 절차지향(procedure oriented) 이전에 순차지향(sequential oriented)이라는 패러다임도 있었다.  순차, 절차 이렇게 놓고 보면 둘이 차이가 있는지 헷갈린다. 하지만 영문을 잘 해석해보면 살짝 다르다는 것을 알 수 있다. 순차지향은 진짜 말그대로 순차적으로(sequential) 라는 뜻으로, 코드를 위에서 아래로 읽겠다는 의미이고, 절차지향의 procedure는 직역하면 절차가 맞지만 컴퓨터 공학에서 말하는 Procedure는 사실 함수이다. 때문에 절차지향 프로그래밍은 사실상 함수 지향 프로그래밍으로 함수 위주로 생각하고 프로그램을 만드는 패러다임이다.  이후 "객체지향의..

보호되어 있는 글입니다.

서론문제 상황은 이렇다. 이 글을 쓰기 위해 JDK 8을 설치하고 열심히 디버깅하면서 글에 첨부할 자료들을 캡쳐했다. 그리고 인텔리제이를 종료하고 시간지나 다시 켜니 라이센스 재인증 하라는 알림창이 떴다.  재인증을 하려니 Problem with connection: SSL error probably caused by disabled SNI 와 Received fatal alert: handshake_failure 에러가 발생하였다.  인텔리제이에서 연결을 요청하는데 proxy 문제인지 뭐 암튼 인터넷 연결이 되지 않아 라이센스를 인증하라는데 인증할 수가 없는 그런 상황이었다.  사실 이런 문제 발생 예고는 이전부터 있었다. 언제부터인가 인텔리제이에서 db 커넥션 오류가 계속 발생하고 플러그인을 설치하려..

문제우테코에서 프로젝트를 진행할 때 각 팀당 주어지는 레포지토리는 하나이다. 코딩해듀오는 백엔드와 프론트엔드 브랜치 prefix를 BE와 FE로 정하여 여기에서 작업을 하고 백엔드 코드와 프론트코드 모두 있는 브랜치는 production으로 정하였다. 다시 말해 prefix가 BE면 백엔드 코드만, FE면 프론트엔드 코드만 존재하고 production 브랜치에는 백엔드, 프론트엔드 코드 모두 존재한다.  백엔드 코드와 프론트엔드 코드 각자도생하다가 런칭 페스티벌 즈음에 production 브랜치에서 만났다. 이 브랜치에서 만나는 과정도 CI/CD 파일들이 컨플릭트 나긴 하였지만 어찌저찌 잘 해결하였다.  하지만 문제는 BE/test 브랜치에서 production 코드를 pull 땡겨와 머지하는 실수를 하..

서론우테코 레벨 2 미션을 하면서 생성 요청이 왔을 때 응답으로 201 Created를 반환하고 Location을 내리라는 요구사항이 있었다.   그래서 코드 구현도 UriComponentsBuilder를 사용해서 URI를 만들고 Location 필드에 넣어주었다.   하지만 이렇게 구현을 해도 Post 요청이 왔을 때, Location으로 리다이렉트 하지 않는다. 왜냐 2xx에선 Location에 값이 있어도 그쪽으로 자동 리다이렉트하지 않는다. 레벨 2 당시에는 놓쳤던 부분이지만 이번 레벨 4 미션을 하면서 왜 201 Created에 Location을 말아 넣는지 알았다. 오다 주웠기 때문이다.    리다이렉션웹 서버는 종종 성공 메시지 대신 리다이렉션 응답을 반환한다. HTTP 헤더에서 Locati..

서론Tomcat 구현하기 미션 중 요청을 처리하는 과정에서 공백 제거를 하지않아 예외가 발생했다.   자바에서는 양 사이드 공백 제거를 위해 trim()과 strip() 두가지 메서드를 제공한다. 이 둘은 어떤 차이를 가지고 있고 어떻게 구현되어있는지 알아보자.  공백 확인공백 제거로 들어가기 전 공백 확인 메서드를 살펴보자. 문자가 빈문자열인지 확인할 때 isEmpty() 혹은 isBlank() 메서드를 사용하곤 했다.    isEmpty()를 사용하면 문자열이 딱 "" 요녀석인지만 확인해주고 isBlank()를 사용하면 "" 이외의 공백, 탭, 줄바꿈과 같은 녀석들도 판별할 수 있다.     어떻게 확인하는가? 위 메서드들은 어떻게 문자가 비었는지 알까소스코드를 까보자.  isEmpty() Strin..

레벨 인터뷰 하면서 받았던 피드백을 반영해보자 세웠던 액션 플랜을 준비하기 위한 글이다.    나는코더다에서 카드 게임(Easy)와 카드 게임(Hard)라는 문제가 나왔다.  Easy문제 요약Easy는 상대의 체력 $H$와 내가 가지고 있는 공격력 카드 $N$장과 그리고 각 공격력 카드의 공격력 $d_i$이 주어진다. 카드를 사용하면 상대의 체력은 $d_i$ 만큼 깎이고, $H$가 0이하가 되면 게임은 끝난다. 그리고 각 카드는 한번씩만 사용할 수 있다. 최대한 많은 카드를 사용고자할 때 최대 몇 개의 카드를 사용할 수 있는지를 구하는 문제이다. 모든 카드를 사용하여도 $H$를 만들지 못하면 -1을 반환한다. 문제 접근정리하면 최대한 많은 카드를 사용하여 $H$ 이상을 만들어야 한다. $H$ 이상을 만들..

배경지식우리 코딩해듀오는 예외 상황을 좀 더 구체적으로 표현하고, 또 테스트도 정확하게 하고자 커스텀 예외를 사용하기로 컨벤션을 정했다. 그리고 각 도메인 별로 패키지를 나누어 각 패키지 마다 대빵 예외가 있고, 이 대빵 예외를 상속하는 세부 예외들이 있었다. @RestControllerAdvice도 각 패키지 안에 들어가 대빵 예외들을 잡아주고 common 패키지에선 최상위 예외인 Exception을 잡아주는 구조였다.    초반에는 각 도메인의 대빵 예외가 CoduoException이라는 찐대장 예외를 상속하는 구조였다가 너무 깊은 상속구조를 갖는 것 같아 CoduoExcpetion은 제거하였다.   문제 상황AccessCode로 페어룸을 찾는데 실패하면 PairRoomNotFoundException..

한동안 알고리즘 공부를 멈췄다가 최근에 다시 흥미가 생겨 발을 들이기 시작했다. 이번에는 또 어떤 씹덕 알고리즘을 배워볼까 하다가 이분 매칭이 맛있어 보였다.    모든 간선 용량이 1이고, 정점을 두 개의 그룹으로 나누었을 때, 존재하는 모든 간선의 양 끝 정점이 서로 다른 그룹에 속하는 형태의 유량 그래프를 이분 그래프(bipartite graph)라고 한다.    이분 그래프에서 한쪽 그룹을 A, 다른 쪽 그룹을 B라고 할 때, 간선의 방향이 모두 A -> B일 때, 최대 유량을 구하는 문제를 이분 매칭(bipartite matching) 문제라고 부른다. 위 그림에서는 생략되었지만 소스에서 A로 가는 간선과 B에서 싱크로 가는 간선이 있다고 생각하면 된다.  이분 그래프에서 매칭은 두 그룹의 정점..

프로덕션 준비 기능지금까지 미션을 하면서 열심히 돌아가는 쓰레기를 목표로 코드를 짜고 그 다음에 열심히 또 리팩터링을 해 클린코드로 만들어 나갔다. 하지만 이제는 비즈니스 요구사항만 충족할 게 아니라 서비스에 문제가 있는지 없는지 모니터링해야 한다.   프로덕션을 운영 환경에 배포할 때 준비해야 하는 것들이 있는데 이들을 프로덕션 준비 기능이라고 한다. 지표(metric), 추적(trace), 감사(auditing)모니터링 애플리케이션이 잘 살아있는지, 커넥션 풀이 얼마나 사용되고 있는지 등을 확인할 수 있다.  액추에이터 의존성 추가 스프링 프로젝트에 액추에이터를 설정하려면 아래처럼 의존성을 추가해주면 된다.   implementation 'org.springframework.boot:spring-bo..