책 오브젝트를 읽다가 좋은 글이 있어서 남겨본다.

코드의 의존성과 실행 시점의 의존성이 다르면 다를수록 코드를 이해하기 어려워진다.
반면 코드의 의존성과 실행 시점의 의존성이 다르면 다를수록 코드는 유연하고 확장 가능해진다.

설계가 유연해질수록 코드를 이해하고 디버깅하기 어렵다.
유연성을 억제하면 코드를 이해하고 디버깅하기는 쉽지만 재사용성과 확장 가능성은 낮아진다.

무조건 유연한 설계도 무조건 가독성이 좋은 코드도 정답이 아니고 이게 객체지향 설계가 어려운 점이다.

 

  장점 단점
유연성을 높이면

재사용성 높아짐
확장 가능성 높아짐

가독성 떨어짐
디버깅하기 어려워짐
유연성을 억제하면 가독성 향상
디버깅하기 쉬워짐
재사용성 낮아짐
확장 가능성 낮아짐

 

 

Leave a Comment

정식 출시 서비스

EC2 인스턴스 Inf1 출시

  • 기계 학습 시 빠른 추론 가속화를 위해 AWS Inferentia 칩으로 구동 되는 4가지 크기로 Inf1 인스턴스를 출시
  • 64 teraOPS 및 8 비트 정수 데이터의 128 teraOPS 성능이 있는 전용 칩에는 고속 상호 연결 및 많은 메모리가 포함
  • 2 페타 OPS 이상의 추론 성능을 활용할 수 있음
  • G4 인스턴스와 비교할 때 Inf1 인스턴스는 최대 3 배의 추론 처리량을 제공하고 최대 40 %의 추론 당 비용을 절감

Amazon EKS on AWS Fargate 정식 출시

  • Amazon Elastic Kubernetes Service
  • AWS Fargate에서 Kubernetes 포드를 실행할 수 있음
  • 쿠버네티스 컨테이너 인프라를 프로비저닝하고 관리 할 필요가 없어서 AWS에서 Kubernetes 기반 애플리케이션을 간단하게 실행할 수 있음
  • AWS Fargate를 사용하면 비용 최적화되고 고 가용성 클러스터를 운영하기 위해 Kubernetes 운영 전문가가 될 필요가 없음
  • Fargate는 고객이 Amazon EKS 클러스터에 대한 EC2 인스턴스를 생성하거나 관리 할 필요가 없음

Amazon S3 Access Points

  • 손쉬운 공유 데이터셋 관리하기
  • 해당 엔드 포인트를 사용하여 데이터에 접근하는 방법을 설명하는 전용 액세스 정책이 있는 고유 한 호스트 이름
  • S3 액세스 포인트 이전에는 데이터에 대한 공유 액세스가 버킷에서 단일 정책 문서를 관리하는 것을 의미했음
  • 이제 다양한 권한을 가진 수백 개의 애플리케이션을 조사하여 시스템에 영향을 줄 수있는 병목 현상을 업데이트할 수 있음

Amazon Redshift

  • 차세대 인스턴스 타입 및 분석 최적화 스토리지
  • 새로운 RA3 인스턴스는 새로운 관리 형 스토리지 모델과 함께 작동하도록 설계됨
  • 새로운 관리형 스토리지는 규모, 성능 및 내구성을 위해 각 인스턴스에 S3가 지원하는 대용량 고성능 SSD 기반 스토리지 캐시를 제공
  • 데이터는 자동으로 적절한 계층에 배치되므로 캐싱 또는 기타 최적화의 이점을 얻기 위해 특별한 작업을 수행 할 필요가 없음
  • SSD 및 S3 스토리지에 대해 동일한 저렴한 비용을 지불하면 추가 인스턴스를 추가하거나 지불하지 않고도 데이터웨어 하우스의 스토리지 용량을 확장 할 수 있음

Amazon Managed Apache Cassandra Service (MCS) 출시

  • 확장 가능하고 가용성이 높으며 관리되는 Apache Cassandra 호환 데이터베이스 서비스
  • MCS는 서버리스이므로 사용하는 리소스에 대해서만 비용을 지불하면 서비스는 트래픽에 따라 자동으로 테이블을 확장 및 축소함
  • 거의 무제한의 처리량과 스토리지로 초당 수천 건의 요청을 처리하는 애플리케이션을 구축 할 수 있음

Amazon Redshift

  • 신규 통합 질의 기능 및 데이터 레이크 내보내기 기능 출시
  • S3 데이터 레이크 및 PostgreSQL 및 Amazon Aurora PostgreSQL 데이터베이스 용 하나 이상의 Amazon Relational Database Service (RDS)에 저장된 데이터를 통합적으로 질의할 수 있음
  • Data Lake Export 기능은 분석에 최적화 된 효율적인 오픈 컬럼 스토리지 형식인 Apache Parquet 형식으로 Redshift 클러스터에서 S3로 데이터를 내보낼 수 있음

Amazon SageMaker Studio

  • 기계 학습 모델을 위한 통합 개발 환경
  • Amazon SageMaker Studio는 모든 ML 개발 단계를 수행 할 수있는 단일 웹 기반 비주얼 인터페이스를 제공함
  • 모델을 구축, 훈련 및 배포하는 데 필요한 각 단계에 대한 완벽한 액세스, 제어 및 가시성을 제공함

Amazon SageMaker Experiments

  • 기계 학습 훈련 과정 추적 및 관리 서비스
  • 기계 학습 모델에 대한 반복을 구성하고 추적 할 수 있음

Amazon SageMaker Debugger

  • 기계 학습 모델 성능 추적 기능
  • 일반적인 훈련 문제가 감지 될 때 경고 및 치료 조언을 생성 할 수도 있음
  • 모델 설명 방법의 초기 단계를 나타내는 모델 작동 방식을 해석 할 수 있음

Amazon SageMaker Model Monitor

  • 완전 관리형 자동 기계 학습 모델 모니터링
  • 개발자가 모델의 개념 편차를 감지하고 변경할 수 있음

Amazon SageMaker Autopilot

  • 고품질 기계 학습 모델 자동 구축 기능
  • Amazon SageMaker Autopilot은 ML 모델에 대한 완벽한 제어 및 가시성을 제공하는 업계 최초의 자동 기계 학습 기능
  • 기계 학습 경험이없는 사람들이 쉽게 모델을 생성하거나 숙련 된 개발자가 팀이 추가 반복 할 수있는 기준선 모델을 신속하게 개발하는 데 사용할 수 있음

Amazon SageMaker

  • Deep Graph Library 지원 시작
  • 2018 년 12 월 Github에서 처음 출시 된 DGL (Deep Graph Library)은 연구원과 과학자가 데이터 세트에서 Graph neural networks (GNN) 모델을 빠르게 구축, 훈련 및 평가할 수 있도록 해주는 Python 오픈 소스 라이브러리
  • 이를 활용하려면 도메인 지식, 컴퓨터 과학 지식 (Python, 딥 러닝, 오픈 소스 도구) 및 인프라 지식 (훈련, 배포 및 스케일링 모델)이 필요한데 이러한 기술을 모두 습득하는 사람은 거의 없으므로 Deep Graph Library 및 Amazon SageMaker와 같은 도구가 필요함

Amazon SageMaker Processing

  • 완전 관리형 데이터 프로세싱 및 기계학습 모델 평가 기능
  • 데이터 과학자와 ML 엔지니어가 Amazon SageMaker에서 사전 처리, 사후 처리 및 모델 평가 워크로드를 쉽게 실행할 수 있는 새로운 Python SDK
  • 본 SDK는 SageMaker의 내장 컨테이너 인 scikit-learn을 사용하며 데이터 세트 변환에 가장 인기있는 라이브러리

Amazon CodeGuru

  • Amazon CodeGuru는 자동화 된 코드 검토 및 애플리케이션 성능 권장 사항을 위한 기계 학습 서비스
  • 서비스 성능을 저하시키고 가장 비싼 코드 라인을 찾은 다음 코드 수정 또는 개선을 위한 특정 권장 사항을 제공
  • CodeGuru는 수백만 개의 코드 검토와 오픈 소스 프로젝트 및 Amazon 내부에서 프로파일 링 된 수천 개의 애플리케이션에 대한 기계 학습, 모범 사례 및 습득한 정보를 기반함
  • 리소스 누수, 잠재적 동시성 경쟁 조건 및 CPU주기 낭비와 같은 코드 문제를 찾아줌

AWS 로컬 영역(Local Zone) 출시 – 미국 로스 엔젤레스 지역

  • 캘리포니아 로스 앤젤레스 지역에서 로컬 영역(Local Zone)을 시작함
  • 새로운 유형의 AWS 인프라 배포 방식으로 특정 AWS 서비스를 특정 지역에 빠르게 제공함
  • 남부 캘리포니아 리전 내부에 로스 앤젤레스와 가용 영역에서 세분화 되어, LA 지역 사용자가 접근하는 서비스에 대해 매우 낮은 대기 시간 (1 자리 밀리 초)을 제공하도록 설계됨
  • 지연 시간에 민감한 트래픽이 높은 애플리케이션에 도움이 됨

AWS Outposts

  • 정식 출시
  • 네이티브 AWS 서비스, 인프라 및 운영 모델을 사실상 모든 데이터 센터, 코로케이션 공간 또는 온프레미스 시설로 옮길 수 있음
  • 온프레미스 및 클라우드에 걸쳐 동일한 API, 동일한 도구, 동일한 하드웨어 및 동일한 기능을 사용하여 일관된 하이브리드 환경을 제공할 수 있음
  • 짧은 지연 시간 또는 로컬 데이터 처리 필요성에 따라 온프레미스에 유지되어야 하는 워크로드를 지원하는 데 사용할 수 있음
  • 서울 리전을 포함해서 주문 가능

미리 보기 출시 예고

Graviton2기반 EC2 인스턴스 (M6g, C6g, R6g)

  • 새로운 Graviton2 프로세서로 구동되는 새로운 Arm 기반 범용, 컴퓨팅 최적화 및 메모리 최적화 EC2 인스턴스를 출시 예고
  • 5 세대 (M5, C5 및 R5) 인스턴스에 비해 상당한 성능 이점을 제공하며 보안에 대한 기준을 높임

UltraWarm for Amazon Elasticsearch Service

  • 대용량 로그 분석을 위한 스토리지
  • 완전 관리 형 저비용 스토리지 계층 UltraWarm은 기존 옵션에 비해 거의 90 %의 비용 절감으로 최대 900TB의 스토리지를 제공
  • Kibana 인터페이스에서 자주 사용하는 데이터를 쿼리하고 시각화 할 수 있음

Amazon Kendra

  • Amazon Kendra는 기계 학습을 기반으로하는 매우 정확하고 사용하기 쉬운 엔터프라이즈 검색 서비스
  • 웹 사이트 및 응용 프로그램에 강력한 자연어 검색 기능을 제공하므로 최종 사용자는 회사 전체에 퍼져있는 방대한 양의 컨텐츠에서 필요한 정보를보다 쉽게 찾을 수 있음

Contact Lens for Amazon Connect

  • 기계 학습을 사용하여 고객 센터의 고객 대화 내 감정과 추세를 이해하는 Amazon Connect 용 분석 기능 세트
  • 고객 센터 수퍼바이저와 분석가는 상담원을 효과적으로 교육하고 성공적인 상호 작용을 복제하며 중요한 회사 및 제품 피드백을 식별하기 위해 호출에서 언급 된 특정 단어와 문구를 기반으로 트렌드, 컴플라이언스 위험을 감지할 수 있음

Amazon Fraud Detector

  • 온라인 결제 사기 및 가짜 계정 생성과 같은 사기성 온라인 활동을 쉽게 식별 할 수 있는 완전 관리형 서비스
  • 사기 수법의 변화를 고정된 규칙이 아니라 기계 학습을 사용하여 분석하여, 비즈니스와 관련된 데이터 세트 및 사기 행위를 기반으로 정확도를 높임

AWS Wavelength

  • 개발자에게 한 자리 밀리 초의 지연 시간으로 최종 사용자에게 서비스를 제공하는 애플리케이션을 구축 할 수 있는 기능을 제공
  • 기존 VPC를 파장 영역으로 확장 한 다음 EC2, EBS, ECS, EKS, IAM, CloudFormation, Auto Scaling 및 기타 서비스를 활용할 수 있음
  • AWS에 대한 지연 시간이 짧은이 액세스는 차세대 모바일 게임, AR / VR, 보안 및 비디오 처리 애플리케이션을 가능하게 함
  • 한국에서는 SK텔레콤이 버라이존, KDDI, 보다폰과 함께 파트너로 선정됨

Reference

[1] https://aws.amazon.com/ko/blogs/korea/aws-launches-previews-at-reinvent-2019-tuesday-december-3rd/

Leave a Comment

Dependency Injection

의존성 주입의 방법은 총 3가지가 있다.

Constructor Injection

  • Spring 4.3에서부터는 단일 생성자의 경우 Autowired Annotation 불필요함
@Service
public class Atin {
  private final Story story;

  @Autowired
  public Atin(Story story) {
    this.story = story;
  }
}

Field Injection

...

@Service
public class Atin {
  @Autowired
  private final Story story;
}

Setter Injection

...

@Service
public class Atin {
  private Story story;

  @Autowired
  public void setStory(Story story) {
    this.story = story;
  }
}

어떤 방법이 가장 좋을까?

여러 가지 방법이 있고, 어떤 형태로 하던 개발에는 문제는 없다.
그러나 프로젝트 개발, 그리고 회사의 팀에서 개발을 할 때는 공통된 코드 스타일 작성이 필요하다.

가장 추천하는 방법은 생성자 주입이다.
스프링 소스를 살펴보면 생성자 주입을 이용한 방법을 사용하고 있다.

생성자 주입이 좋은 내가 생각하는 이유는 다음과 같다.

  • 테스트 클래스 작성시 리플렉션을 이용하지 않고 주입할 수 있다.
  • POJO에 가깝다.
  • 특별한 경우가 아니라면, 의존관계에 있는 객체들은 반드시 의존관계 주입이 되어야 하며 그렇다면 생성자 주입이 그림상 맞다.

[1]의 블로그에 보면 해당 이유를 다음과 같이 설명하고 있다.

  • 단일 책임의 원칙
  • 테스트 용이성
  • Immutabiblity
  • 순환 의존성
  • 의존성 명시

그렇다면 생성자 주입이 가장 좋은 방법으로 생각해 볼 수 있다.
그런데 생성자를 만드는 방법이 꽤 불편하기도 한데 이럴 때 고려를 해 볼 수 있는 점이 lombok이다.

주입이 필요한 객체들을 final로 한 이후에 lombok의 @RequiredArgsConstructor를 사용하면 final로 지정된 객체들이 자동적으로 생성자 때 필요하게 되면서 편리하게 생성자 주입을 사용할 수 있다.

@Service
@RequiredArgsConstructor
public class TestController {
    private final StoryService storyService;
    private final TestService testService;

    ...
}

그러면 lombok을 통한 방법의 생성자 주입이 최선일까?
처음에는 이 방식이 편리해서 사용했고 편리했다.
그러나 이 방식에는 몇 가지 문제가 존재한다.

  • 주입하려는 bean이 1개가 아닌 경우에는 @Qualifier를 사용해야 하는데 lombok 이용시 불가능하다.
  • @Value와 같은 properties 등의 주입이 필요할 경우 불가능하다. 그렇다고 @Value경우는 필드 주입을 쓰게 되면 코드 통일성이 없어진다.
  • final로 지정된 클래스 변수들의 순서가 변경이 되면 생성자도 변경이 되며 TC등에서 문제가 발생할 수 있다.
  • 생성자에 특정 로직 작성이 필요한 등의 이슈가 발생하면 결국 직접 생성을 해줘야 한다.

그래서 결론은, 생성자 주입은 lombok을 사용하지 않고 직접 작성하는 것이 좋다.
다음은 spring sagan 소스이다. 참고용으로 넣어본다.
Spring 4.3 이후 버전이라서 Autowired도 필요가 없다.

@RestController
@RequestMapping(path = "/guides", produces = MediaTypes.HAL_JSON_VALUE)
public class GuidesController {

    private final GuideRenderer guideRenderer;

    private final GithubClient githubClient;

    private final RendererProperties properties;

    private final GuideResourceAssembler guideAssembler = new GuideResourceAssembler();

    public GuidesController(GuideRenderer guideRenderer, GithubClient github,
            RendererProperties properties) {
        this.guideRenderer = guideRenderer;
        this.githubClient = github;
        this.properties = properties;
    }

    ...
}

https://github.com/spring-io/sagan/blob/master/sagan-renderer/src/main/java/sagan/renderer/guides/GuidesController.java

Reference

[1] https://landsnail.tistory.com/entry/Spring-%EC%9D%98%EC%A1%B4%EC%84%B1-%EC%A3%BC%EC%9E%85-%EB%B0%A9%EB%B2%95
[2] https://github.com/sieunkr/spring-tips/tree/master/spring-di
[3] https://javaslave.tistory.com/19

Leave a Comment

개발을 하면서 모델간 매핑을 많이 한다.
DTO, VO, Entity별로도 하고 DTO간 DTO 변환에도 사용한다.
개발자마다 각각 다양한 방식으로 이 부분에 대해 개발을 하는데 문제는 팀 내에서는 동일한 방식을 사용해야 한다.
팀 생산성상 중요하고, 코드리뷰에서 불필요하게 지적하는 시간을 줄일 수 있다.
중요한 점은 팀 내에서 협의하여 공통된 방식에 대해서 합의가 되어야 한다.
정해진 답은 없고, 프로젝트의 성격에 따라 다르겠지만 어느 정도 공통된 점들은 있다.

Model Object

시작하기에 앞서
모델 객체애 대해서 다시 살펴보면
DTO, VO, Entity, Domain Model로 나누어 볼 수 있다.

DTO

  • Data transfer object
  • 목적 : 데이터의 전달
  • 데이터의 전달을 위한 생성자와 getter, setter 로직만 들어가야 하며 기타 로직이 들어가서는 안됨

 

VO

  • Value Object
  • 목적 : 불변 객체로서 데이터 전달
  • 개발자들간 대화를 하다보면 VO에 대해서 특별한 정의를 없이 사용하며 DTO와 크게 다르지 않게 사용하는 경우가 있다.
    • 그러나 프로젝트 내에서 DTO와 VO를 특별한 의미없이 사용해서는 안된다. 나름대로의 목적을 정해야만 함
  • VO의 통상적으로 사용되는 의미는 불변(Immutable)의 의미
  • DDD에서 VO를 불변 객체로 소개

 

불변(Immutable) 객체

  • 한번 생성된 이후 수정되지 않는 의미
  • 데이터를 다룰 때, 종종 수정되어서는 안되는 데이터가 있는데 이를 개발단에서 중간에 수정되지 않게 막음
  • 동시성 프로그래밍(parallel programming)에서 멀티 스레드 처리시 발생하는 문제에서 벗어날 수 있음
  • 생성자 또는 빌더를 통해서만 값을 객체 생성 초기에 넣고, 그 이후로는 getter를 통해서 값을 갖고 오도록 처리

 

Entity & Domain Model

  • Etity는 ORM에서 DB Table와 매핑되는 모델 객체
  • Entity는 데이터 전달의 목적보다 DB Table과 객체를 매핑함으로서, 기존 JDBC API를 이용한 경우 데이터 정보만 전달하게 되면서 객체 지향적이지 않게 생기는 패러다임 불일치 문제를 해결하는 점이 중요
  • DDD를 할 경우에는 Entity를 도메인 모델로 사용한다. 이 경우 Entity에는 도메인 로직이 들어감
  • DDD 관점에서 볼 때, Domain Layer에 위치

 

매핑 개발

Service

여러 서비스에서 사용시 중복코드 발생
서비스 객체에 모델간 매핑 로직은 서비스 객체의 목적에 부합하지 않음

Model Object

  • 장점
    • 빠른 개발시 간편함
  • 단점
    • 서비스가 커지고, 모델간 다양한 매핑이 있을 경우 점점 모델 객체안에 메서드가 많아짐
    • 모델 객체에 모델간 매핑 로직은 모델 객체의 목적에 부합하지 않음
    • Entity안에 VO변환 로직을 넣고, VO안에 Entity 변환 로직을 넣게 된다면 (이러면 안되지만), 양방향 의존으로 인한 스파게티 코드 발생

Mapper

  • 모델간 매핑에 대한 책임
  • 역할 : 모델간 모델 매핑

mapper를 이용한 모델 객체를 사용하게 될 때, 다시 한번 결정을 해야 하는 것이 있다.
라이브러리들을 이용해서 모델간 매핑을 자동화를 할지, 아니면 직접 Mapper를 이용해서 모델간 매핑을 처리할지이다.

여러가지 라이브러리가 있는데 그 중에서 ModelMapper와 MapStruct에 대해 얘기해본다.

ModelMapper

  • 내부적으로 리플렉션을 사용. 그래서 사용을 하지 않는 것이 좋다.
  • 리플렉션으로 인한 성능 이슈 그리고 실제 동작시 발생하다보니 자칫 예상치 못한 결과가 발생할 수 있다.
  • 리플렉션을 쓰는 대표적인 것 중 하나로 Jackson ObjectMapper가 있는데, 이는 모델 변경이 아닌 모델의 포맷에 대한 변경이고 대안이 없기 때문에 사용한다.

MapStruct

  • 리플렉션 사용하지 않음
  • 컴파일시 생성
  • 레퍼런스
    • 국내는 적지만, 미국에서 점점 사용도가 높아지고 있음

 

MapStruct Example

MemberMapper.java

import org.mapstruct.Mapper;

@Mapper(componentModel = "spring")
public interface MemberMapper {

   MemberVO toVO(Member member);

}

 

Member.java

import lombok.EqualsAndHashCode;
import lombok.Getter;
import lombok.Setter;

import javax.persistence.Column;
import javax.persistence.Entity;
import javax.persistence.GeneratedValue;
import javax.persistence.GenerationType;
import javax.persistence.Id;
import javax.persistence.Table;

@Entity
@Getter
@Setter
@EqualsAndHashCode(of = { "memberId" }, callSuper = false)
@Table(name = "member")
public class Member extends BaseEntity {

   @Id
   @Column
   @GeneratedValue(strategy = GenerationType.IDENTITY)
   private Long memberId;

   @Column
   private String memberName;

}

 

MemberVO.java

import lombok.Builder;
import lombok.Value;

import java.time.LocalDateTime;

@Builder
@Value
public class MemberVO {
   private Long memberId;
   private String memberName;
}

 

Kotlin에서 모델 매핑

  • Kotlin에서도 MapStruct를 쓰기도 함
  • 객체 생성 후에 기존 객체에 확장메서드(extenstion function)를 이용한 매퍼

Comments

  1. 이수민 2019.09.06 14:29 Permalink Modify/Delete Reply

    좋은 글 감사합니다~

    혹시 mapper 는 보통 어느 레이어에 두시나요?

    domain.model.member.Member
    domain.model.member.MemberDomainService
    application.member.dto.MemberDto
    application.member.MemberApplicationService

    domain.model.member.MemberMapper
    application.member.MemberMapper
    application.member.dto.MemberMapper
    application.mapper.MemberMapper
    mapper.member.MemberMapper

    Application Layer 에 위치하는게 가장 좋아보이기는 하는데,, 이런거는 정답도 없어서 더 고민되네요

    • 아틴 2019.09.06 15:19 신고 Permalink Modify/Delete

      Mapper는 특정 레이어에 종속적이라고 생각하지 않습니다. Mapper의 목적이 오브젝트와 오브젝트를 변환해주는 것이 목적이기 때문인데요.

      Domain Layer
      Application Layer
      Presentation Layer

      모델 오브젝트의 위치가 중요하다고 생각합니다.
      DTO1을 DTO2로 변경한다고 했을 때, 두 DTO가 모두 Presentation Layer로 같은 Layer에 있다고 하면 Mapper는 Presentation Layer에 있어야 한다고 보구요.

      DTO1은 Domain Layer에 있고
      DTO2는 Application Layer에 있다고 하면 Application Layer에 Mapper가 있어야 한다고 봅니다.

      단순히, 두 모델 오브젝트를 의존할 수 있는 Layer에 Mapper를 두는 것이 맞다고 생각하는 부분입니다.

      DTO1은 Domain Layer에 있고
      DTO2는 Application Layer에 있을 경우
      Mapper가 Domain Layer에 있으면 해당 Mapper는 DTO2를 참조할 수 없어서 매핑을 할 수가 없습니다. (레이어를 패키지로 분리했다면 의존할 수 있겠지만.)
      Application Layer는 Domain Layer를 의존하고 있지만 Domain Layer는 Application Layer를 의존하지 않아야 하기 때문입니다.

      domain.member.dto
      application.member.dto
      application.member.mapper

    • 이수민 2019.09.10 10:49 Permalink Modify/Delete

      모델 오브젝트의 위치에 따라 단순히 생각하면 되겠군요!

      감사합니다

  2. A.S.L 2019.09.09 21:20 신고 Permalink Modify/Delete Reply

    MapStruct 한글로 정리된 글 찾다보니 여기까지 왔네요.
    좋은글 감사해요~

Leave a Comment

iterm2 Theme - zsh2000

item2 정말 마음에 드는 테마


ZSH2000

git clone https://github.com/maverick2000/zsh2000.git

https://github.com/inspectahstack/zsh2000



Color THEME

https://beomi.github.io/2017/07/07/Beautify-ZSH/







'Devlopment' 카테고리의 다른 글

iterm2 Theme - zsh2000  (0) 2018.09.19
[MAC] Intelij vmoption 값 수정  (0) 2018.07.24
텍스트를 로고로 만들어주는 사이트  (0) 2018.06.21

Leave a Comment

DCC

  • Dynamic Currency Conversion

  • 자국 통화 결제, 해외 원화 결제

  • 신용카드 해외 원환 결제 서비스

  • 10%대의 고율 수수료가 붙음

  • 카드 결제 후 원화가 표시된다면 DCC로 결제되었음을 의미

  • 해외고객이 자주 방문하는 오프라인 가맹점을 대상으로 고객이 해외신용카드(VISA & Master & JCB)로 결제 시 당일 고정환율로 환전된 자국통화를 확인하고 결제가 가능하도록 하는 것


MCP

  • Multi Currency Pricing

  • 해외 다중통화결제

  • 해외신용카드(VISA & MasterCard & JCB)로 결제 시 원하는 통화로 결제가 가능하도록 하는 것

  • 소비자 입장에서는 환차익에 따른 손해를 보지 않음


Reference



Leave a Comment

PG and VAN

PG(payment gateway)

  • 전자지불 서비스

  • 전자지불 서비스를 대행하는 회사

  • 인터넷을 통한 전자지불 결제를 처리

  • PG는 VAN을 통해 전자지불 결제를 대행하고, 일부 다른 PG를 통해서 결제대행을 함

  • 전자 지불(인터넷 결제)의 종류

    • 신용카드

    • 핸드폰

    • 800ARS

    • 폰빌

    • 계좌이체

  • 보통 1 ~ 2개 정도만 전문적으로 자체 서비스하고 나머지는 해당 지불회사와 제휴함


VAN(value-added network)

  • 부가 가치 통신망 VAN

  • 가맹점과 카드사 간 네트워크망을 구축하여 카드사용 및 카드전표 매입 업무를 하는 부가통신 사업자

  • 카드 결제 단말기들은 VAN을 통해서 카드사에게 결제를 요청

  • VAN을 구성하는 회사들을 VAN사라고 부름

  • VAN은 전화망을 통해 구성 (요즘은 인터넷망으로도 사용)

  • 주 수입원 :가맹점과 신용카드사에게서 수수료

  • 우리나라의 VAN사

    • 한국신용정보(KICC)

    • 스마트로(SMTR)

    • 금융결제원(KFTC)

    • 케이에스밴(KSVAN)

    • 퍼스트데이타(FDIK)

    • KIS

    • 나이스정보통신(NICE)

    • 등 13군데

  • 신용카드 그리고 신용카드 회사와의 중간에서 전화선 혹은 전용선 통해서 카드승인 및 기타 VAN 서비스를 수행하는 기관


한국의 카드결제 구조

  • 오프라인 카드결제 : 카드가맹점 -> VAN -> 카드사

  • 온라인 카드결제 : 온라인 카드 가맹점 -> PG -> (PG) -> VAN -> 카드사


Reference


Leave a Comment

맥에서 기동 옵션 수정시 위치는 아래와 같다.


위치 : /Users/atinh/Library/Preferences/{IntelliJI}


초기에 파일이 없기 때문에 원하는 파일 idea.vmoptions 또는 idea.properties를 복사해서 넣어준 후 원하는 옵션으로 수정해주면 된다.
기본 파일 위치 : /Applications/InteliJ IDEA.app/Contents/bin/


Reference
[1] https://intellij-support.jetbrains.com/hc/en-us/articles/206544869-Configuring-JVM-options-and-platform-properties
[2] http://ddoong2.com/939





'Devlopment' 카테고리의 다른 글

iterm2 Theme - zsh2000  (0) 2018.09.19
[MAC] Intelij vmoption 값 수정  (0) 2018.07.24
텍스트를 로고로 만들어주는 사이트  (0) 2018.06.21

Leave a Comment

Intelij를 사용하다가 갑자기 자꾸 먹통이 되는 상황이 되었다.

이유를 찾다보니 플러그인 문제다.

나는 "Handlebars / Mustache" 관련 플러그인의 문제였는데 다른 문제가 있는 플러그인도 있는 모양이다.


참고 : https://blog.naver.com/eunjuee2/221291967595


플러그인 설치하고 Indexing이 너무 오래 돌면 참고하자.


Leave a Comment

Spring Boot.

스프링 부트(Spring Boot)

  • 공식 홈 - https://spring.io/projects/spring-boot
  • 스프링 기반으로 상용제품 수준의 단독 실행형 애플리케이션을 복잡한 과정없이 개발할 수 있도록 하는 것

History


기능

  • 단독실행가능한 스프링어플리케이션 생성
  • 기본 설정된 스타터 컴포넌트
  • 내장형 WAS(톰캣, 제티, 언더토우)
  • AutoConfiguration 으로 기본 설정이 제공
  • 상용화에 필요한 통계, 상태 점검 및 외부설정을 제공
  • XML 코드를 생성하거나 요구하지 않음


특징

  • Spring CoC(Convention-over-Configuration) Version (Wikipedia)
  • 최적의 Dependency(라이브러리, 버전) 관리
  • 관례에 따른 기본 Bean 설정(@Configuration)을 미리 제공
  • 상용화를 위한 기능(Actuator 등)
  • Micro Service(Application With Single Responsbility) 구현에 최적화
  • 보안, 모니터링 구현을 프레임워크 레벨에서 지원


Leave a Comment


to Top