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

최근에 레거시를 유지 보수하면서, JS 및 JQuery 를 만지는 일이 있었다. 일을 하면서 select 태그의 option 태그를 selected 가 아닌, 특정 value 값을 기준으로 option 태그를 선택 후 해당 텍스트값을 가져와야 하는 작업이 필요했었다. 보통 select 태그를 사용하게 되면, selected 인 option 의 value 혹은 text 값을 핸들링 하는데, 해당 케이스는 보통 케이스와 달라서 아주 잠깐 당황했었다. 해결법은 물론 있다. 레거시를 만지면서, JQuery 를 최대한 걷어내고 있는데, JQuery 선택자를 이용하면 매우 간단하게 해결할 수 있다. 예를 들어, 아래와 같이 한 줄 이면 간단하게 해결이 가능하다. 근데, 요즘 JQuery 를 사용하지 않는데 이점이 더 큰것을 알아가고 있어서 JQuery 를 사용하지 않기로 결심했다. 따라서 namedItem 이라는 method 를 사용해보았다. https://developer.mozilla.org/en-US/docs/Web/API/HTMLSelectElement/namedItem The  HTMLSelectElement.namedItem()  method returns the  HTMLOptionElement  corresponding to the  HTMLOptionElement  whose  name  or  id  match the specified name, or  null  if no option matches. name 혹은 id 속성을 이용해서 Element 를 선택한다. 아래에서 확인할 수 있듯이, Edge 와 IE 에서는 name 속성이 지원이 안된다고 한다. 따라서 id 속성을 이용하는것이 크로스 브라우징에 매우 유리하다. 그럼 우선 예제를 보자, 아래와 같이 fruits 라는 id 속성을 가진 sele...

반 버논의 도메인 주도 설계 구현(DDD Domain Driven Design)이라는 책을 요즘 보고있다. 여러가지 도움되는 개념도 많다. 그 중에 하나인 자가 캡슐화의 개념을 한 번 다뤄보겠다. 마틴 파울러 형님께서 '자가 캡슐화는 심지어 같은 클래스 내에서부터 모든 데이터로의 액세스가 접근자 메소드를 거쳐가도록 설계하는 방법이다.' 라고 말했다.  말로만 들어선 언뜻 이해하기 어렵다. 그래서 예제를 통해서 풀어나가려고 한다. 우선 User라는 Entity = aggregate root 가 존재한다. 식별자로써 Long 타입의 id 그밖의 중요한 username, password 와 값 객체인 Person 을 가지고 있다. 중요하게 볼 것은 기본 생성자와 setter 들의 접근 제어자이다. protected 로 선언했다. protected 로 선언한 이유는 같은 모듈안에서만 호출하도록 모듈간의 의존성을 제거하기 위함에도 있다. 더욱 강력하게 기본생성자를 private 으로 만들고, 파라미터 생성자만 protected 로 공개할 수도 있다. 그리고 setter 들도 또한 private 으로 만들어서 오직 파라미터 생성자만이 속성/특성을 설정할 수 있도록 한다면, 불변하게 만들수 있다. 또한 매개변수가 있는 생성자를 보면, 변수 할당을 자신의 내부 세터로 위임한다. 각 세터에게 상태의 일부를 설정하는 계약 조건을 결정토록 하고 있다. 각 세터는 Entity 를 대신해 개별적으로 null 이 아니라는 제약을 검사해서 인스턴스 계약을 집행한다. 이는 Assertion Guard 라고도 한다. 이 기법의 이점은 몇가지가 있다고 한다. 1. 객체의 인스턴스 변수를 추상화할 수 있도록 해준다. 2. 이를 통해 해당 객체를 담고 있는 많은 다른 객체에서 손쉽게 특성/속성을 가져오는 방법을 제공한다. 3. 또한 이를 통해 계약의 의한 설계를 이행한다. 4. 값의 불변성을 유지할 수 있다. 하지만 이 기법을 많이 ...

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 -...