기록들 https://github.com/ndgndg91

Git 을 이용해서 진행하는 개발 업무를 하다보면, 급한 이슈로 인해서 현재 작업하던 것을 제쳐두고 해당 이슈를 처리해야 할 일이 있다. 그러면 해당 작업을 불가피하게 commit 혹은 stash 를 이용하여 현재까지 작업한 상태를 보존해야 한다. 여담으로, 개인적으로 stash 를 상당히 비추한다. 그 이유는, commit 이 안된 stash 의 경우 실수로 날려버리면 복구가 불가능하다. 실제로 업무를 하다가 실수로 기존 stash 를 clear 해버려서 하루종일 작업한게 날아갈 뻔해서 진땀을 한바가지 흘린 적이 있다. 다행히도 commit 을 했어서, commit hash 를 통해서 복구를 했었다. 따라서 stash 보단 commit 을 자주하여, squash 를 애용하겠다고 생각했다. 다시 돌아와서 얘기하자면, 급한 이슈가 자주 발생하면 할수록, 도중에 흐름이 끊겨서 설계한 대로 commit 단위를 쪼개기가 어려워지고 의미있는 commit message 작성이 어려워진다. 따라서 commit 단위를 관리하기 위해서 squash 를 통해 commit 메세지를 관리하는 방법을 블로깅 해보려고 한다. 단적인 예로 아래와 같이 Pageable 이라는 feature 에 대해서 3가지로 나눠졌다. 해당 예제는 여러사람들과 같이 협업이 아니라 혼자 진행하고 있는 사이드 프로젝트라서 브랜치가 하나이다. 또한 전제로 이 기능은 매우 간단하며, 하나의 commit 으로 관리되는것이 더 효율적이라고 판단된 사항이다. 따라서 3개의 commit 을 하나로 통합하는 예제이다. 그렇다면 이제 진행해 보자. 아래와 같이 commit 내역에 오른쪽 클릭을 하고, interactively rebase from here.. 를 선택한다. 아래와 같이 하나의 commit 내역만 대상에 뜬다. 따라서 HEAD~3 을 합치고 싶은경우, HEAD~3 의 commit 을 다시 오른쪽 클릭하고 동일하게 진행해준다. 아래와 같이 HEAD~3 co...

최근에 Medium 에서 아주 신기한 글을 봤다. spring 에서 전략 패턴을 구사하는 내용인데, 새로운 DI 방법을 보고 너무 신기했다. 혼자 다른 곳에 적용하고 싶어서 이것저것 건들다가 손을 댔는데, 예제가 허접하다. 양해 부탁한다. 우선, 해당 글 링크 https://medium.com/javarevisited/implementing-the-strategy-pattern-with-spring-de2bad3abc2f 전략 패턴이란 해당 글에서 이렇게 설명한다. The   Strategy Pattern   is a behavioral design pattern that enables selecting an algorithm at runtime. 런타임에서 알고리즘을 선택하는 행동적인 패턴이라고 한다. 처음 듣는다면, 설명 만으로 한번에 이해하기 조금 어려울 수 있다. 해당 글에서는  e-commerce   주문 영역을 다루고 있다. 필자가 구현해본 예제는 조금 전략패턴에 맞지 않는 도메인과 구조일 수 있다는 점 다시 한 번 양해를 구한다. 전자제품, 의류, 음식, 책은 Product 를 상속받은 구조이며, TABLE_PER_CLASS 전략으로 각각의 테이블로 구성하도록 설계했다. 아래에서 Product 를 확인할 수 있다. 그리고 아래에는 Product 를 상속받은 Book class 의 구조이다. Author, Weight, Size 는 @Embedded 를 사용하여 구현하였다. Electronics, Clothing, Food class 는 생략하겠다. 그렇다면, 어디서 전략패턴을 구사하고 있는가를 이제 보자. 필자가 가장 신기했던 부분이 바로, 아래에 있다. productCode PathVariable 을 이용하여 ProductType enum 을 이용하여 serviceName 을 가져오고 service 들이 있는 Map 에서 원하는 service 를...

올해 들어서 블로깅을 너무 안했다. 그래서 기초적인 것이지만 spring boot 에서 MariaDB 설정을 블로깅을 해보겠다. 우선 필자는 build tool 로 gradle 을 선택했다. 따라서 아래와 같이 필요한 의존성을 추가한다. security 와 web 은 해당 내용과 관련이 없지만, 필자가 개발하는 프로젝트에 필요해서 추가한 것이다. 따라서 아래 이미지에서 MariaDB 설정에 필수 의존성은 spring-boot-starter-data-jpa 와 mariadb-java-client 이다. 그리고 다음으뢰, application.yml 에서 아래와 같이 datasource 설정을 해준다. url, username, password 는 개인 mariadb 서버 설정에 맞게 넣어준다. 이제 설정은 끝났다. 왜냐면 spring boot 가 알아서 해준다. spring boot 의 장점이다. 설정이 너무쉽다. 왜냐면 아래와 같이 @SpringBootAppliation 이 다 알아서 해준다. 엄밀히 말하자면, @SpringBootApplication 을 까보면, 아래와 같이 @EnableAutoConfiguration 이 있다. 이녀석이 자동으로 해주는게 정말정말 많다. 이녀석을 까보고 공부하는 것도 재밌는일이 될 것 같다.

혼자서 이거저거 만지고 개발하다 보니까 mysql, mariadb, postgre 등 여러 RDB를 사용했었다. 그러다가 문득 다른 DB 간에 테이블과 해당 테이블에 있는 Data가 필요하게 되어 편하게 옮기는 방법 없을까? 찾다가 내가 한 방법을 블로깅 한다. DataGrip 툴을 이용해서 먼저 DDL CREATE TABLE 을 뽑아낸다. 아래 이미지 처럼 해당 스키마이든 해당테이블을 선택하고 오른쪽 클릭을 하고, SQL Scripts 에 마우스를 올리면 오른쪽 처럼 Generate DDL 이라는 문구를 찾을 수 있다. 아래 처럼 DDL 을 뽑을 수 있다. 물론 mysql, mariadb 같은 경우 SHOW CREATE TABLE 문을 사용할 수 있지만, 테이블이 여러개일 경우, 혹은 전체 스키마를 다 따야할 경우 테이블 하나하나 하고 있을 수 없다. 그럴 때 이렇게 사용하면 좋을것 같다. 그렇다면 이제는 특정 테이블의 Data 들을 INSERT 구문으로 뽑아보자. 아래와 같이 우선 SELECT * FROM table; 을 하든 뭘 하든 추출하려는 데이터셋을 query 로 돌린다. 그리고 아래처럼 row 들을 선택하고 오른쪽 클릭을 한다. 우선 아래처럼 Data Extractor:~ 를 보면 여러가지 방법이 있다. INSERT 문의 두 가지가 가능하다. 1. SQL Inserts 2. SQL-Insert-Statements.sql.groovy 두 가지 중 하나를 선택한다. 그리고 아래 처럼 Dump Data 로 가서 파일을 생성하든지 클립보드에 출력하든지 선택하면 된다. 나같은 경우, 파일로 생성했다. 따라서 아래처럼 파일을 생성한다. 그리고 파일이 생성되면, DataGrip 오른쪽 하단에 아래와 같은 얼럿이 나온다. 파일을 눌러서 열어보면 아래 이미지와 같이 Insert 문으로 변환된 것을 볼 수 있다.

최근에 주기적으로 특정 시간에 특정 알람을 보내야하는 사이드 프로젝트를 진행하면서, Quartz 를 사용해 보았다. 그래서 개발하고 그에 따른 후기를 남겨본다. 먼저 알람 발송 시점은 아래와 같다. 그날 그날 휴일인지 평일인지에 따라서 또한 평일인 경우 주간인지 야간인지에 따라 담당자가 다르다. 따라서 해당 담당자에게 "너 이제 일해야됨!!" 이렇게 알람을 보내는 서비스를 개발했다. 알람 방법에 대해선 생략하고,  어떻게 Scheduler 를 활용 했는지에 초점을 두고 글을 쓰려고 한다. 먼저, 주간, 야간, 휴일 근무시간이 어떻게 되는지 정리해보겠다. - 주간 : working day (not holiday, not weekend) 09:00 ~ 18:00 - 야간 : working day (not holiday, not weekend) 18:00 ~ 23:00 - 휴일 : holiday ( including weekend ) 09:00 ~ 23:00 우선 공통점을 뽑아낸다면, 하루 전은 모두 공통되어 있다. 내일 담당자에게 전날에 22:00 에 "내일 너 일해야됨!" 을 보내야 한다. 따라서 주기적으로 22:00 에 발송을 보내야 한다. 그리고 나머지 시점은 각각 고유하게 시각을 가지고 있다. 시점과 해당 시점에서 해야하는 일을 정리해보면, 아래와 같다. 1. 22:00 - 오늘이 working day 인지 holiday 체크 후 working day -> 내일 주간 담당자와 야간담당자에게 알람을 보낸다. holiday -> 내일 휴일 담당자에게 알람을 보낸다. 2. 09:00 - 오늘이 working day 인지 holiday 체크 후 working day -> 오늘 주간 담당자에게 알람을 보낸다. holiday -> 아무것도 안한다. 3. 08:55 - 오늘이 working day 인지 holiday 체크 후 working day -...

AWS 에서 EC2 를 처음 생성하면, Timezone 은 기본으로 UTC 로 설정되어, KST 기준 -9 시간이 된다. 따라서 KST 기준 시각으로 어떤 작업을 해야 될 경우 Timezone 을 KST 로 변경해야 한다. 아래 이미지를 참고하면 된다. 참 쉽죠잉~?

회사에서 AWS 를 사용하고 있고, APN 파트너가 되면 회사측에서도 여러가지 혜택이 있다. 사내에서 AWS 자격증을 취득한 사람이 없기 때문에, APN 파트너가 될 수 없다. 따라서 사내에서 AWS 자격증 취득자에게 보너스를 준다고 해서 도전했다. 물론 필자는 DevOps 에 관심이 있기도 했지만,, 향후에 쿠버네티스에 대해서 공부를 하고 EKS 에 대해서 공부하고, 프로페셔널에도 도전해 볼 생각이다. 아래는 AWS APM partner 혜택 및 요구사항이 나와있다. https://aws.amazon.com/ko/partners/technology/ 간략하게 AWS 자격증 종류에 대해서 알아 보자면, 기초 -> 어소시에이트 -> 프로페셔널 -> 전문 분야 순으로 난이도가 올라간다고 보면된다. 그중에 내가 취득한 단계는 어소시에이트중이고, 개발자이다. 향후에 프로페셔널인 DevOps 도 생각 중이다. https://aws.amazon.com/ko/certification/?nav=tc&loc=3 Associate Developer 에 디테일한 사항을 보겠다. 우선 객관식으로 총 65문제이며, 130분의 시간이 주어진다. 1000점 만점에 통과 기준 점수는 720 점이다. AWS 에서 제공하는 맛보기 문제. https://d1.awsstatic.com/training-and-certification/docs-dev-associate/AWS_Certified_Developer-Associate_Sample_Questions_v2.0_FINAL.pdf 시험은 한국어로 지원이 가능하다. 동시에 영어로 문제 및 보기를 볼 수도 있다. 영어로 지원을 하게 되면, 추가로 응시시간을 30분? 더 준다. 130분이면 상당히 긴 시간이기 때문에, 한국어로 지원해서 번역이 이상하다고 생각되면, 영어로 보기를 해서 풀면 된다. 개이득! 시험비는 170,000원이 들었다. https://aws.amaz...