목록Tech (49)
지나공 : 지식을 나누는 공간
개요 1. Spring Batch 탄생 배경 간략히 자바에는 I/O 기술, 네트워크(tcp, udp 등) 기술, 스레드(병렬처리 가능) 기술, jdbc 기술 등이 표준으로 정의되어 있다. 하지만 배치 처리에서 요구하는 재사용 가능한 자바 기반의 배치 아키텍처는 없었어서 이에 대한 필요성으로 탄생했다. 2. 배치 핵심 패턴 Read : 데이터베이스나 파일이나 큐에서 다량의 데이터를 조회 Process : 특정한 방법으로 데이터를 가공 Write : 데이터를 수정된 양식으로 다시 저장 데이터베이스의 ETL ( Extract 추출하다 - Read, Transform 변형하다 - Process, Load 적재하다 - Write)와 매칭되는 개념인데 배치에서 쓰이는 용어는 Read, Process, Write이다..
신입 과제에서 Scheduler를 사용할 것 같다. 주된 과제가 이건 아니고 Open API 데이터 매핑이 중요한거라 이걸 고민하는게 우선이긴 한데, 그래도 Scheduler를 조금이라도 다루고 있어서 배치 카테고리를 열었다. 게다가 해당 프로젝트를 나중에 Spring Boot Batch로 옮길 예정이라 하셨다. (이 업무가 나중에 내 업무가 될지는 모르겠지만) 암튼 내가 해당 업무를 맡지 않더라도 예전에 Spring Batch 공부를 아주 잠깐 했었으니 Scheduler 보는 김에 같이 보려 한다. 전에 급해서 아무 레포에나 Spring Batch를 정리해둔 적이 있는데 다시 볼 겸 첨부...! 관련 업무도 적혀있는 추억의 이슈ㅋㅋㅋ https://github.com/Hae-Riri/today-alco..
코루틴의 취소에 대해 알아본다. 코루틴의 취소를 알아야 리소스도 해제할테니 잘 알아두자! Canceling coroutine execution fun maini() = runBlocking { val job = luanch{ repeat(1000) { i -> println("job: I'm sleeping $i ...") delay(500L) } } delay(1300L) println("main : I'm tired of waiting!") job.cancel() job.join() println("main : Now, I can quit") } launch는 코루틴 job을 반환하는데 이 job은 취소하는 기능도 가지고 있다. 1000번을 반복하면서 0.5초 간격으로 숫자를 출력하고, 1.3초 지났..
코루틴을 정리하면 비동기 처리를 순차적으로 간단하게 하고, 콜백을 대체할 수 있는 도구다. 뭐가 편해지는 건지 한번 코드로 확인해보자. 코루틴, 뭐가 편해지는걸까? val user = fetchUserData() textView text = user.name 위처럼 코드를 짜면 참 편하다. 바로 서버를 호출하고, 그 결과를 바로 텍스트뷰에 삽입할 수 있으니까. 하지만 위처럼 할 수는 없다. 서버를 호출하는 부분은 네트워크 부분이기 때문에 NetworkOnMainThreadException이 발생하기 때문이다. 지난 포스팅에서 말했듯, 네트워크 작업은 main thread가 아니라 IO thread에서 작업하는 것이다. 근데 지금은 메인스레드에서 네트워크 콜을 하고 있네? 문제다. fetchUserData..
코루틴(Coroutine)? 실행의 지연과 재개를 허용함으로써, 비선점적 멀티태스킹을 위한 서브 루틴을 일반화한 컴퓨터 프로그램 구성요소. 이제 진하게 칠한 단어를 하나씩 공부해보자! 1. 루틴과 서브루틴? 프로그램은 보통 크고 작은 여러가지의 루틴을 조합시켜서 성립되는데 여기서 메인 루틴과 서브루틴으로 나뉜다. 메인 루틴 : 프로그램 전체의 개괄적인 동작 절차를 표시하도록 만들어진 루틴. 서브 루틴 : 반복적인 특정 기능을 모아서 별도로 묶인 루틴. 서브 루틴은 별도의 메모리에 해당 기능을 모아 놓고 서브루틴이 호출될 때마다 저장된 메모리에 이동한 뒤 다시 return을 통해 원래 호출자의 위치로 돌아온다. 서브루틴은 함수와 비슷하다. 코루틴도 루틴의 일종인데, 3가지 차이점이 존재한다. 메인 - 서브..
REST API 의 장점 학습과 사용이 매우 쉽다. 자유도가 높아 원하는 대로 사용 가능하다. json이 응답으로 오면 파싱할 필요도 없다. REST API의 문제점 너무 자주 바뀌는 API (서버에서 자꾸 변경할 때가 많음) 너무 높은 자유도 버저닝(이 가능하긴 하나 손이 너무 많이 감) api 문서를 만들 수는 있으나 코드랑 너무 떨어져 있으니 죽은 문서가 됨 그래서 나온 게 바로 IDL(Interface Description Language) 라고 하는 인터페이스 정의 언어이다. 이것의 큰 장점은 언어에 종속되지 않고 컴포넌트 사이의 통신을 가능하게 한다. 그럼 우리는 이 rest api를 어떤 idl을 사용해서 표현할 수 있을까? 라는 고민을 한다. 첫 번째는 open API로, 그 장점은 아래와..
지금까지의 흐름, 객체 지향 설계 원칙을 따를 때 의존성 주입이 왜 필요했는지 정리해보자. 지금까지의 흐름과 DI의 필요성 1. 새로운 할인 정책 개발 다형성 덕분에 새로운 정률 할인 정책 코드를 추가로 개발하는 것까진 문제가 없다. 2. 새로 만들어진 정률 할인 정책을 적용할 때 문제 발생 새로 개발한 정률 할인 정책을 적용하려고 했더니, 클라이언트 코드인 주문 서비스 구현체 (OrderSerivceImpl)의 코드도 같이 변경해야 했다. 왜냐면 여기서 직접적으로 DiscountPolicy를 FixDiscountPolicy로 구현하고 있었기 때문이다. 얘를 RateDiscountPolicy로 변경하는 순간 DIP 위반이라는 문제가 발생한다. 3. 관심사의 분리 애플리케이션을 하나의 공연으로 생각하자. ..
김영한 님의 강의를 참고했습니다. 객체지향설계의 원칙은? SRP(Single Responsibility Principle) 단일책임 원칙 한 클래스는 하나의 책임만 가진다. 변경이 있을 때 파급효과가 적으면, 다른 곳에 영향을 덜 미치면 단일책임원칙을 잘 따른것임. OCP(Open/closed principle) 개방폐쇄원칙 SW 요소는 확장에는 열려 있으나 변경에는 닫혀 있어야 한다. 확장을 하려면 당연히 기존 코드를 변경하는 것 같지만!!! 다형성을 떠올리자. 인터페이스를 구현한 새로운 클래스를 하나 만들어서 새로운 기능을 구현하잖아? 그런데 문제점이 있다. 구현 객체를 변경하려면 클라이언트 코드를 변경해야 한다는 것이다. 그래서 이걸 해결해야 한다. 객체를 생성하고 관계를 맺어주는 별도의 조립, 설..
오늘은 JPA Auditing에 대한 포스팅입니다. 프로젝트를 하다보면 어떤 데이터의 생성시간, 수정시간, 또는 생성한 사람, 마지막으로 수정한 사람을 저장해야 할 때가 있습니다. 예를 들어 공지사항이나 게시글 등을 저장하는 테이블에 게시글이 작성된 날짜와 시간, 작성한 사람, 수정시간과 수정한 사람 등이 필요해요. 회원 가입이나 주문내역을 저장할 때도 마찬가지고요. 생각해보면 게시글이나 주문내역 처럼 사용자가 직접 생성해내는 데이터들은 웬만하면 데이터 생성일과 수정일을 저장하게 되는 것 같습니다. 근데 이걸 모든 엔티티에 매번 컬럼으로 지정해서 코드를 작성하는 건 번거로워요. 생성 시간 수정 시간 저장을 자동화하고 BaseTimeEntity로 만들어서, 이게 필요한 엔티티들은 모두 BaseEntity를..
03장 마지막 JPA Auditing으로 생성시간/수정시간 자동화하기 BaseTimeEntity는 abstract 클래스로, Entity들의 생성시간과 수정시간을 자동으로 관리하는 역할을 한다. @MappedSuperclass JPA Entity 클래스들이 BaseTimeEntity를 상속할 경우 그 필드들인 createdDate, modifiedDate를 컬럼으로 인식하도록 한다. @EntityListeners(AuditingEntityListener.class) BaseTimeEntity 클래스에 Auditing 기능을 포함시킨다. @createdDate Entity가 생성되어 저장될 때 시간이 자동저장된다. @LastModifiedDate 조회한 Entity의 값을 변경할 때 시간이 자동저장된다.