Skip to content

태그: 개발

총 91개의 글이 있습니다.

api아키텍처

GraphQL은 정확하게 데이터를 요청하는 방법을 설명하는 구문이다. 서로를 참조하는 복잡한 엔티티를 사용하는 애플리케이션의 데이터 모델을 사용하고, 그것을 다양한 방식으로 조회해야 할때 유용하게 사용된다. 최근 GraphQL 생태계는 Apollo, GraphiQL, GraphQL Explorer와 같은 강력한 도구와 라이브러리로 확장되고 있다. GraphQL 동작방식 GraphQL은 GraphQL API에서 만들 수 있는 모든 쿼리와 반환하는 모든 타입에 대해 설명하는 스키마를 정의하는 것으로 시작한다. 스키마 정의 언어(SDL)에서는 엄격한 타입 정의를 사용하기 때문에 스키마 정의가 쉽지 않다. 쿼리 전에 스키마를 통해 쿼리에 대한 유효성 검사를 한 뒤 본 요청이 백엔드 애플리케이션에 도달하면, 전체 스

api아키텍처

REST는 설계적 제약 조건으로 API 스스로에 대한 설명이 가능하여 수 많은 API 소비자에게 채택될 수 있도록 정의된 API 아키텍처 스타일이다. 오늘날 가장 대중적인 REST API 아키텍처 스타일은 2000년 Roy Fielding의 박사 학위 논문에 처음 소개되었다. REST API는 서버 측에서 JSON 및 XML과 같은 간단한 형식의 데이터로 표현 가능하게 한다. REST 동작 방식 REST는 SOAP만큼 엄격하게 정의되어 있지 않다. RESTful한 아키텍처는 6개의 설계 제약 조건을 준수해야 한다. 일관성 있는 인터페이스 : 장비 또는 애플리케이션 타입과 무관하게 목표 서버와 통신하도록 일관성 있는 통신 방법을 허용한다. 무상태 : 요청 자체가 요청을 처리하는 데 필요한 상태이고 서버와 세

api아키텍처

RPC란 원격 프로시저 호출이라는 뜻으로, 다른 컨텍스트에서 함수의 원격 실행을 허용하는 사양이다. RPC는 로컬 프로시저 호출 개념을 확장한 것이지만, HTTP API 컨텍스트에 포함되는 개념이다. 초기 XML-RPC는 XML 페이로드 데이터의 타입을 보장하기 어렵다는 문제를 가지고 있었다. 그래서 차후의 RPC API는 보다 정형화된 JSON-RPC를 사용하여 SOAP보다 단순한 구조를 지닌 SOAP의 대안으로 인식되었다. 그중 gRPC는 2015년 Google에서 개발한 최신 버전의 RPC이며, 로드밸런싱, 추적, 상태 확인, 그리고 인증을 위한 플러그인을 지원하기 때문에 마이크로 서비스 연결에 매우 적합하다. RPC 동작방식 클라이언트는 원격 프로시저를 호출하고 매개 변수와 추가 정보를 직렬화하여 생

api아키텍처

SOAP는 XML 형식의 고도로 표준화된 웹 통신 프로토콜이다. XML-RPC 출시 1년 후에 SOAP가 출시되었기 때문에 SOAP는 XML-RPC로부터 상당 부분을 물려받았다. 이후 REST가 출시되었을 때, SOAP와 REST는 같이 사용되었지만, 곧 REST만 사용하는 추세가 시작되었다. SOAP의 동작 방식 SOAP 메시지는 다음과 같이 구성된다. 메시지의 시작과 끝을 표시하는 envelop tag 요청 또는 응답 body 메시지가 특정 사항이나 추가 요구 사항을 결정해야되는지에 대한 정보를 나타내는 헤더 요청을 처리하는 도중 발생할 수 있는 오류에 대한 안내 SOAP API 로직은 웹 서비스 기술 언어(WSDL)로 작성된다. 이 API 기술 언어는 endpoint를 정의하고 실행 가능한 모든

아키텍처및방법론

CQRS는 Command Query Responsibility Segregation 의 약자로, 단어 그대로 해석하면 “명령 조회 책임 분리”를 뜻한다. 즉, 우리가 보통 이야기하는 CRUD(Create, Read, Update, Delete)에서 CUD(Command)와 R(Query)의 책임을 분리하는 것이다. CQRS가 필요한 이유 Application의 Business 정책이나 제약은 데이터 변경(CUD)에서 처리되고, 데이터 조회(R) 작업은 단순 데이터 조회를 처리하는데, 두가지 작업 모두를 동일 Domain Model로 처리하면 필요하지 않은 Domain 속성들이 생겨 복잡도가 증가한다. 도메인의 여러 속성들이 얽히면 유지보수의 비용이 증가하고 Domain model은 설계의 방향과 다르게 변질

DDD는 Domain Driven Design, 즉 도메인 주도 설계이다. 도메인을 중심으로 애플리케이션을 설계, 구성하는 방법이다. 도메인(Domain) 도메인이란 ‘소프트웨어로 해결하고자 하는 문제 영역’을 의미한다. 한 도메인은 다시 하위 도메인으로 나눌 수 있고, 도메인들은 서로 연동하여 완전한 기능을 제공한다. 이 도메인은 소프트웨어의 요구사항을 이해하는데 중요한 요소이다. 서비스를 통해 어떤 문제를 해결할 것인지, 어떤 도메인을 다룰 것인지, 도메인끼리의 관계가 어떠한지 확실하게 알아야 요구사항을 제대로 이해하고 개발을 효율적으로 진행할 수 있다. 도메인은 사용자가 누구인가, 어떻게 사용하냐에 따라 같은요소라고 할지라도 계속 바뀔 수 있고, 형태가 고정되어있지 않은 추상적인 요소이다. 하지만 소프

DDD의 아키텍처

도메인 주도 설계에서는 도메인을 중심으로하여 애플리케이션을 설계, 구성한다. 애플리케이션은 도메인 외에도 표현, 응용, 인프라스트럭처 등의 영억으로 나뉘어있고 각각의 역할을 수행한다. application전체를 구성하는 아키텍처 요소에 대해 알아보자. 대표적으로 DDD에서는 위와 같은 구조의 Layered Architecture를 가진다. 계층별 설명 1. Presentation Layer (표현 계층) 사용자 요청을 해석하고 응답하는 일을 책임지는 계층이다. 사용자에게 UI를 제공하거나 클라이언트에 응답을 보내는 모든 클래스가 포함된다. Client로부터 request를 받아 response를 보내는 API를 정의한다. 2. Application Layer (응용 계층) 사용자의 요청을 전달받아 시

도메인영역

도메인 영역의 주요 구성요소는 아래 다섯가지가 있다. 요소설명엔티티(Entity)고유의 식별자를 갖는 객체이다.도메인 모델의 데이터를 포함하며, 해당 데이터와 관련된 기능을 함께 제공한다.밸류(Value)고유의 식별자를 갖지 않는 객체로, 주로 개념적으로 하나인 도메인 객체의 속성을 표현할 때 사용된다. (ex. 주소, 배송상태)엔티티의 속성뿐만 아니라 다른 밸류 타입의 속성으로도 사용될 수 있다.애그리거트(Aggregate)애그리거트는 관련된 엔티티와 밸류 객체를 개념적으로 하나로 묶은 것이다.도메인 관계 복잡도를 낮추기 위해 여러 하위 도메인을 독립된 객체군으로 나눈다.리포지터리(Repository)도메인 모델의 영속성을 처리한다.애그리거트 단위로 도메

이벤트 스토밍

이벤트 스토밍이란 도메인에 관련된 모든 이해 관계자가 모여서 화이트 보드와 포스트잇을 활용하여 이벤트를 중심으로 업무들 간의 상호 연관성을 찾기 위해 진행하는 워크숍 방법론이다. 도메인 전문가와 개발자를 학습 과정에 참여시키기 위해 설계되었고, 모든 사람들이 시각적으로 도메인에 시각적으로 접근할 수 있게 해준다. 이벤트 스토밍을 하는 이유? 이벤트 스토밍의 가장 큰 목적은 도메인지식을 공유함으로써 전체 비스니스가 어떻게 돌아가는지 한눈에 볼 수 있는 지도(타임라인)를 만드는 것이다. 각 도메인 전문가들의 도메인 지식은 모두 분산되어 있기 때문에 한번에 전체 지도를 그리기 힘든데, 이벤트 스토밍은 그 지식을 모아 정리할 수 있도록 한다. 이벤트 스토밍 하는 법 이벤트 스토밍을 하기 위한 준비물은 “포스트잇과

바운디드 컨텍스트의 모델은 서로 독립적이지만 바운디드 컨텍스트 자체는 독립적이지 않다. 컨텍스트는 각자 독립적으로 발전할 수 있지만 컨텍스트끼리는 서로 상호작용해야 하기 때문에, 그 사이에는 항상 접점이 생기는데 이를 컨트랙트(Contract) 라고 부른다. 바운디드 컨텍스트 간의 연동, 즉 컨트랙트에 대한 고민은 솔루션 설계에서 평가되고 다뤄져야 한다. 바운디드 컨텍스트간의 연관관계를 나타낸 컨텍스트 맵의 예시이다. 바운디드 컨텍스트 간의 관계는 두 컨텍스트를 작업하는 팀 간의 협력적 특성이나, 설계에 따라 달라질 수 있다. 컨트랙트가 상호작용하는 패턴은 크게 협력형 패턴 그룹과 사용자-제공자 패턴 그룹으로 나뉜다. 또는, 아예 협력하지 않는 분리형 노선을 채택할 수도 있다. 협력형 패턴 그룹(Coop

HexagonalArchitecture

아키텍처및방법론

The Hexagonal Architecture is a very powerful pattern. It helps you create more sustainable and better testable software by decoupling the business logic from the technical code. 만약 비즈니스 로직(Domain)이 특정 라이브러리에 의존성을 가지고 있다면 기술 스택을 업그레이드하고 바꿔야 할떄, 모든 비즈니스 로직과 infrastructure를 갈아 엎어야 할 것이다! 육각형 아키텍처(Hexagonal Architecture)는 그러한 문제를 해결하기 위해 기술과 비지니스 로직 사이를 분리하여 비지니스 로직이 기술에 구애받지 않고 동작할 수 있도록 하는 아키텍처이

MSA의 장단점

마이크로서비스 아키텍처의 장점 크고 복잡한 애플리케이션을 지속적으로 전달/배포할 수 있다. (CI/CD) MSA를 구축하면 크고 복잡한 애플리케이션을 지속적 전달/배포할 수 있다. MSA는 다음과 같은 세가지 방법으로 지속적 전달/배포를 실현한다. 테스트성: 지속적 전달/배포를 하려면 자동화 테스트가 꼭 필요하다. MSA는 상대적으로 크기가 작아서 자동화 테스트를 작성하기 쉽고 더 빨리 실행되며, 애플리케이션 버그도 적은 편이다. 배포성: MSA는 독립적으로 배포할 수 있기 때문에 개발자가 자신이 담당한 서비스 변경분을 배포할때 다른 개발자와 복잡한 협의 과정을 거칠 필요가 없다. 그래서 프로덕션에 변경분을 반영하기가 훨씬 수월하다. 자율성, 느슨한 결합: 작은 팀이 여러개 결합되어있는 기술 조직을 꾸려나

메시지 브로커

브로커리스 메시징 브로커리스 아키텍처의 서비스는 메세지를 서로 직접 교환한다. 장점 송신자가 보낸 메시지가 브로커를 거쳐 수신자로 이동하는 것이 아닐, 송신자에서 수신자로 직접 전달되므로 네트워크 트래픽이 가볍고 지연 시간이 짧다. 메시지 브로커가 성능 병목점이나 SPOF(단일 정야좀)가 될 일이 없다. 메시지 브로커를 설정/관리할 필요가 없으므로 운영 복잡도가 낮다. 단점 서비스가 서로의 위치를 알고 있어야 하므로 서비스 디스커버리 메커니즘을 사용해야한다. 메시지 교환시 송신자/수신자 모두 실행중이어야 하므로 강ㅇ성이 떨어진다. 전달 보장같은 메커니즘을 구현하기가 어렵다. 브로커 기반 메시징 메시지 브로커는 모든 메시지가 지나가는 중간 지점이다. 송신자가 메시지 브로커에 메시지를 쓰면 메시지 브로

사가는 MSA에서 분산 트랜잭션 없이 데이터 일관성을 유지하는 메커니즘이다. 사가는 일종의 로컬 트랜잭션인데, 각 로컬 트핸잭션은 ACID 트랜잭션 프레임워크/라이브러리를 이용하여 서비스별 데이터를 업데이트한다. 주문 서비스의 createOrder() 작업은 6개의 로컬 트랜잭션을 가진 주문 생성 사가로 구현된다. Txn:1 주문 서비스: 주문을 APPROVAL_PENDING 상태로 생성한다. Txn:2 소비자 서비스: 주문 가능한 소비자인지 확인한다. Txn:3 주방 서비스: 주문 내역을 확인하고 티켓을 CREATE_PENDING 상태로 생성한다. Txn:4 회계 서비스: 소비자 신용카드를 승인한다. Txn:5 주방 서비스: 티켓 상태를 AWATING_ACCEPTANCE 로 변경한다. Txn:6 주문

사가는 단계를 편성하는 로직으로 구성된다. 시스템 커맨드가 사가를 시작할 때 해당 편성 로직은 첫 번째 사가 참여자를 정하여 로컬 트랜잭션 실행을 지시하고, 트랜잭션이 완료되면 모든 단계를 실행 될때까지 계속 그다음 사가 참여자를 호출한다. 로컬 트랜잭션이 도중에 하나라도 실패한다면 사가는 보상 트랜잭션을 역순으로 실행한다. 이와 같은 사가를 편성하는 로직은 두 가지 종류가 있다. 종류설명코레오그래피(choreography)의사 결정과 순서화를 사가 참여자에게 맡긴다. 사가 참여자는 주로 이벤트 교환 방식으로 통신한다.오케스트레이션(orchestration)사가 편성 로직을 사가 오케스트레이터에 중앙화한다. 사가 오케스트레이터는 사가 참여자에게 커맨드 메시지를 보내 수행할 작업

시맨틱 버저닝

마이크로서비스 애플리케이션은 클라이언트를 다른 서비스 팀이 이비 개발한 경우가 대부분이기 때문에 서비스 API를 변경하기가 어렵다. 서비스를 클라리언트를 모두 찾아 강제로 업그레이드시키기도 쉽지 않다. 또 요즘은 유지보수시 서버를 내리지 않기 때문에 규칙적인 단계로 서비스를 업그레이드하여 신구버전을 동시에 실행해야한다. 시맨틱 버저닝 명세는 API 버저닝에 관한 유용한 지침서이다. 여기에ㅔ는 버전 번호를 사용하고 증가시키는 규칙들이 면시되어있다. 시맨틱 버저닝은 원래 소프트웨어 패키지의 버저닝 용도로 쓰였지만, 분산 시스템의 API 버저닝에도 사용할 수 있다. Major : 하위 호환되지 않는 변경분을 API에 적용 Minor : 하위 호환되는 변경분을 API에 적용 Patch : 하위 호환되는 오류 수정

MSA에서는 각 서버가 서로 통신함으로써 여러 도메인이 엮인 요청을 처리할 수 있도록 한다. 이때 서버간 통신을 위해 일반적인 IPC인 REST를 사용할 수 있지만, REST는 동기 프로토콜이기 때문에 호출한 서비스가 응답할 때까지 클라이이언트가 대기해야한다는 단점이 있다. 따라서 서비스가 동기 프로토콜로 통신하면 그만큼 애플리케이션 가용성은 저하될 수밖에 없다. 서비스가 모두 HTTP 통신을 사용한다면, 어느 하나의 서버가 내려갔을때 제대로 동작할 수 없다. 동기 상호 작용 제거 이를 해결하기 위해 비동기 만 있는 서비스를 정의해서 해결할 수도 있지만, 어쩔 수 없이 서비스에 동기 API를 포함시켜야 할 경우가 많다. 이런 경우에는 동작을 조금 우회한 비동기 처리 기법을 사용할 수 있다. 비동기 상호 작용

트랜잭션 격리

사가를 사용하는 경우, 여러 서버와 도메인에 걸친 트랜잭션을 보장해줄 수 있지만 트랜잭션의 완전한 격리를 완벽히 보장할 순 없다. 따라서 dirty read나 nonrepeatable read 등의 문제들이 생길 수 있는데, 이런 문제들을 해결하기 위해선 사가의 격리를 위한 전략을 사용해줘야한다. 이를 위한 전략으로는 아래와 같은 것들이 있다. 시맨틱 락(Semantic Lock) 보상 가능 트랜잭션이 생성/수정하는 레코드에 무조건 플래그를 세팅하는 대책이다. 레코드가 아직 커밋 전이라서 변경될지 모르니, 다른 트랜잭션이 레코드에 접근하지 못하도록 락을 걸어놓는 것이다. 그 플래그는 재시도 가능 트랜잭션(사가 완료) 또는 보상 트랜잭션(사가 롤백)으로 인해 해제될 수 있다. 잠금된 레코드를 어떻게 처

트랜잭션 로그 테일링 패턴

메시지 브로커는 보통 메시지를 적어도 한 번 이상 전달한다. 클라이언트나 네트워크, 혹은 브로커 자신에 이상이 있는 경우 같은 메시지를 여러번 전달할 수도 있다. 하지만 이때 메시지를 여러번 전달함으로 인해 중복 메세지가 발생하여 멱등하지 않은 시스템에 지장을 주거나, 메시지 순서가 꼬여 잘못 처리될 수도 있다. 이를 해결하기 위해 ID를 기록하여 검사하거나 DB 폴링 방식을 사용하기도 한다. 이때 사용할 수 있는 정교하고 성능이 꽤 좋은 방식중 하나로는, 트랜잭션 로그 테일링 패턴이 있다. 말 그대로 메시지 릴레이를 통해 DB 트랜잭션 로그(커밋 로그)를 tailing하는 방법이다. 애플리케이션에서 커밋된 업데이트를 각 DB의 트랜잭션 로그 항목(log entry)으로 남긴다. 그리고 그

1. 단일 책임 원칙 (Single Responsibility Principle, SRP) 하나의 모듈는 하나의 책임만 가져야 한다. SRP를 적용하면 메소드의 책임 영역이 확실해지기 때문에 한 기능이 수정되었을 때 다른 연쇄작용을 일으키지 않는다. 또, 책임을 적절히 분배함으로써 코드의 가독성이 향상되고 유지보수가 용이해진다. 2. 개방 폐쇄 원칙 (Open-Closed Principle, OCP) 소프트웨어 요소는 확장에는 열려있으나 변경에는 닫혀 있어야 한다. 코드를 수정하거나 기능을 추가할 일이 생겨도 기존 구성 요소는 바뀌지 말아야한다. 추상화와 다형성으로 구현할 수 있다. 3. 리스코프 치환의 원칙 (Liskov Substitutiong Principle, LSP) 서브 타입은 기반 타입이 약속한

응집도와 결합도

응집도와 결합도는 코드의 관심사와 연결관계가 어느정도로 구분되어있고, 얽혀있는지를 나타내는 정도이며, 모듈의 독립성을 판단하는 두 가지 지표이다. 응집도는 모듈 내부의 기능적인 집중 정도, 결합도는 모듈과 모듈간의 상호 의존 정도라고 할 수 있다. 높은 응집도와 낮은 결합도를 가진 코드가 객체지향적으로 좋은 코드로 여겨지며, 객체지향 원칙 중 개방 폐쇄 원칙(Open-Closed Principle, OCP)과 연관있는 개념이다. 응집도(Cohesion) 응집도는 모듈에 포함된 내부 요소들이 하나의 책임/ 목적을 위해 연결되어있는 연관된 정도이다. 응집도가 높다는 것은, 하나의 모듈또는 쿨래스가 하나의 책임 또는 관심사에만 집중되어있다는 것을 뜻한다. 응집도가 높으면 그 모듈이 처리할 수 있는 기능 중 하나

빌더 패턴은 복합 객체의 생성 과정과 표현 방법을 분리하여 동일한 생성 절차에서 서로 다른 표현 결과를 만들 수 있게 하는 패턴이다. 빌더 패턴을 사용하면 객체를 생성할 떄 필요한 값만 넣을 수 있다. 그리고 파라미터룰 사용한 생성자가 아니라 변수명을 명시하여 생성하는 것이기 때문에 변수 순서가 바뀌거나 새로 추가될때 유연하게 대처할 수 있고 매개변수가 많아져도 가독성을 높일 수 있다. 구현하는 것이 복잡하기 때문에 직접 구현하면 코드 구조가 읽기 어려워진다는 단점이 있다. Lombok에서 제공해주는 @Builder 어노테이션을 사용하면 Lombok이 자동으로 빌더를 만들어준다. 예시 코드 @Getter@Setterpublic class Pizza { String name; String to

싱글톤 패턴

싱글톤 패턴은 애플리케이션이 시작될 때, 어떤 클래스가 최초 한 번만 메모리를 할당(static)하고 인스턴스를 생성하여 사용하는 패턴이다. 똑같은 인스턴스를 여러개 생성하지 않고, 어디에서 접근하든 기존에 만들었던 인스턴스를 이용하도록 한다. 예시 코드 public class LazyInitSingleton { private static LazyInitSingleton instance; private LazyInitSingleton() {} public static LazyInitSingleton getInstance() { if (instance == null) { instance = new LazyInitSingleton(); }

추상팩토리 패턴

서로 관련있는 여러 객체를 만들어주는 인터페이스를 만들어 구체적으로 어떤 클래스의 인스턴스를(concrete product)를 사용하는지 감추는 패턴이다. 구체적인 객체 생성 과정을 추상화한 인터페이스를 제공한다는 점에서 팩토리 메소드 패턴과 비슷하지만 팩토리 메소드 패턴은 구체적인 객체 생성 과정을 하위 또는 구체적인 클래스로 옮기는 것이 목적이고, 추상 팩토리 패턴은 관련있는 여러 객체를 구체적인 클래스에 의존하지 않고 만들 수 있게 해주는 것이 목적이라는 점에서 다르다. 예시 코드 @Getter@Setter@AllArgsConstructorpublic abstract class Pizza { private String name; private Sauce sauce; private

팩토리메소드 패턴

팩토리 메소드 패턴은 부모(상위) 클래스 코드에 구체 클래스 이름을 감추고, 자식(하위) 클래스가 어떤 객체를 생성할지를 결정하도록 하는 패턴이다. 구체적인 객체 생성 과정을 추상화한 인터페이스를 제공한다는 점에서 추상 팩토리 패턴과 비슷하지만 추상 팩토리 패턴은 관련있는 여러 객체를 구체적인 클래스에 의존하지 않고 만들 수 있게 해주는 것이 목적이고, 팩토리 메소드 패턴은 구체적인 객체 생성 과정을 하위 또는 구체적인 클래스로 옮기는 것이 목적이라는 점에서 다르다. '확장에 대해 열려있고 수정에 대해 닫혀있어야 한다'는 개방-폐쇄 원칙(OCP)을 만족하는 객체 생성 방법이다. 예시 코드 @Getter@Setter@NoArgsConstructorpublic abstract class Pizza {

프로토타입 패턴

기존 인스턴스를 프로토타입으로 사용해 새 인스턴스를 만드는 패턴이다. 비슷한 객체를 여러개 만드는 경우 인스턴스를 생성하는 복잡한 과정을 거칠 필요 없이 새 인스턴스를 만들 수 있다는 장점이 있다. 예시 코드 java의 Cloneable 인터페이스와 Object의 clone() 메서드를 사용하면 프로토타입 패턴을 간단하게 사용할 수 있다. @Getter@AllArgsConstructorpublic class Pizza implements Cloneable{ String name; String topping; String sauce; @Override public Pizza clone() { try { return (Pizza) super.cl

데코레이터 패턴

데코레이터 패턴은 주어진 상황 및 용도에 따라 객체에 책임을 덧붙이는 패턴이다. 기본 기능에 추가할 수 있는 기능의 종류가 많은 경우에 각 추가 기능을 Decorator 클래스로 정의 한 후 필요한 Decorator 객체를 합함으로써 추가 기능의 조합을 설계 하는 방식이다. 데코레이터 패턴은 객체의 결합 을 통해 기능을 동적으로 유연하게 확장 할 수 있게 해준다. 예시 코드 public interface CommentService { void addComment(String comment);}public class DefaultCommentService implements CommentService{ @Override public void addComment(String comment)

브릿지 패턴

브릿지 패턴은 구현부에서 추상층을 분리하여 각자 독립적으로 변형할 수 있도록 하는 패턴이다. 즉, 기능과 구현에 대해 별도의 클래스로 구현하여 서로의 코드에 간섭하지 않고 변형, 확장할 수 있도록 하는 것이다. 예시 코드 @AllArgsConstructorpublic abstract class Pizza { private String name; private Recipe recipe; public String result(){ return recipe.getName() + " " + name; }} public class CheesePizza extends Pizza { public CheesePizza(Recipe recipe){ super("치즈

어댑터 패턴

어댑터 패턴은 클래스의 인터페이스를 사용자가 기대하는 다른 인터페이스로 변환하는 패턴이다. 기존 코드를 변경하지 않고 원하는 인터페이스 구현체를 만들어 사용하는 것이기 때문에 기존 코드가 하던 일과 특정 인터페이스 구현체로 변환하는 작업을 각기 다른 클래스로 분리하여 관리할 수 있다는 장점이 있다. 예시 코드 public interface UserDetails { String getUsername(); String getPassword();} public interface UserDetailsService { UserDetails loadUser(String username);} public class LoginHandler { private final UserDetailsSer

컴포짓 패턴

컴포짓 패턴이란 객체들의 관계를 트리 구조로 구성하여 부분-전체 계층을 표현하는 패턴으로, 사용자가 단일 객체와 복합 객체 모두 동일하게 다루도록 한다. 복합 객체와 단일 객체의 처리 방법이 다르지 않을 경우, 그 관계를 전체-부분 관계로 정의할 수 있는데, 이 전체-부분 관계를 효율적으로 처리하기 위한 디자인 패턴이 컴포짓 패턴이다. 예시 코드 대표적인 컴포짓 패턴의 예시는 파일 디렉토리 구조이다. 내가 있는 폴더가 다른 폴더의 자식 폴더인지, root 폴더인지에 상관없이 똑같이 다룰 수 있다. 컴포짓 패턴을 사용하면 재귀적인 트리 구조를 구현할 수 있다. public interface Composite { String getName(); String getTree(String tab);

퍼사드 패턴

퍼사드 패턴은 클라이언트가 사용해야 하는 복잡한 서브 시스템 의존성을 간단한 인터페이스로 추상화 하는 디자인 패턴이다. Client는 서브시스템의 존재를 모르는 상태로, 오직 facade클래스에만 접근할 수 있도록 하는것이 특징이다. 예시 코드 public class PizzaFacade { private final Chef chef = new Chef(); private final Oven oven = new Oven(); public Pizza makingPizza() { Pizza pizza = chef.makingDough(); pizza = chef.addToppings(pizza); return oven.grillingPizza(p

프록시 패턴

프록시 패턴은 인터페이스를 사용하고 실행시킬 클래스에 대해 객체가 들어갈 자리에 대리자 객체를 대신 투입하여, 클라이언트는 실제 실행시킬 클래스에 대한 메소드를 호출하여 반환값을 받는지 대리 객체의 메소드를 호출해서 반환값을 받는지 모르도록 하는것을 말한다. 프록시 패턴을 사용하면 실제 메소드가 호출되기 이전에 필요한 기능(전처리등의)을 구현객체 변경없이 추가할 수 있고, 구현클래스에 직접 접근하지않고 Proxy를 통해 한번 우회하여 접근하도록 되어있기 때문에 흐름제어를 할 수 있다는 장점이 있다. 예시 코드 public interface HelloService { String run();} public class HelloServiceImpl implements HelloService{ @

플라이웨이트 패턴

플라이 웨이트 패턴은 동일하거나 유사한 객체들 사이에 가능한 많은 데이터를 서로 공유하여 사용하도록 하여 메모리 사용량을 최소화하는 패턴이다. 플라이웨이트 패턴에서는 일부 오브젝트의 상태 정보를 외부 자료 구조에 저장하여 플라이웨이트 오브젝트가 잠깐 동안 사용할 수 있도록 전달한다. 예시 코드 @Getter@Setterpublic class Pizza { private String name; private int price; private Dough dough; private Sauce sauce;} 피자가 있다. 이제부터 피자를 아주 많이 만들어서 배송할건데, 만들 때 마다 새 인스턴스로 생성해서 배송하기엔 메모리가 너무 아깝다. 그래서 자주 변하지 않고, 범위가 작은 속성인 도

메멘토 패턴

메멘토 패턴은 객체를 이전 상태로 되돌릴 수 있는 기능을 제공하는 소프트웨어 디자인 패턴이다. 현재(원본) 상태를 저장하는 객체인 Originator에서 특정 상태를 저장하는 Memento 객체로 변환하여 CareTaker에 저장하는 구조이며, 핵심 객체의 데이터를 계속해서 캡슐화된 상태로 유지하는 것이 특징이다. 예시 코드 @Getter@Setterpublic class Originator { private String state; public Memento saveStateToMemento() { return new Memento(state); } public void getStateFromMemento(Memento memento) { state =

방문자 패턴

방문자 패턴은 알고리즘을 객체 구조에서 분리시키는 디자인 패턴이다. 기존 클래스 필드 정보를 유지하면서 새로운 연산을 추가하는 방식 중 하나이다. 비슷한 동작을 수행하는 로직을 Visitor 객체에 모을 수 있기 때문에 코드를 유지보수하기 좋지만, Element와 Visitor 간의 결합도가 상승한다는 단점이 있다. 예시 코드 public interface Element { void visit(Visitor visitor);} public class ElementA implements Element{ @Override public void visit(Visitor visitor) { visitor.visit(this); }} public class ElementB im

상태 패턴은 상태 패턴 인터페이스의 파생 클래스로서 각각의 상태를 구현함으로써, 상태를 객체화시키고 상태전이 메서드를 구현할 필요 없이 상태객체가 슈퍼클래스에 의해 정의한 메소드를 호출하여 사용하도록 하는 패턴이다. 상태 전이를 위한 조건 로직이 복잡한 경우 이를 해소하기 위해 사용될 수 있다. 예시 코드 public interface State { State feelingBetter(); State feelingBad(); void printCurrentEmotion();} public class Happy implements State{ @Override public State feelingBetter() { return this; } @Overr

옵저버 패턴

옵서버 패턴은 객체의 상태 변화를 관찰하는 관찰자들을 생성하여, 즉 옵저버들의 목록을 객체에 등록하여 상태 변화가 있을 때마다 메서드 등을 통해 객체가 직접 목록의 각 옵저버에게 통지하도록 하는 패턴이다. 옵저버 패턴을 활용하면 다른 객체의 상태 변화를 별도의 함수 호출 없이 즉각적으로 알 수 있기 때문에, 이벤트를 자주 처리해야하는 프로그램에서 적합하다. 예시 코드 public interface Publisher&x3C;V{ void add(Observer&x3C;Vobserver); void delete(Observer&x3C;Vobserver); void notifyObserver(V message);} public class NewsPublisher implements Publis

이터레이터 패턴

이터레이터 패턴은 컬렉션 구현 방법을 노출시키지 않으면서 집합체 안에 들어있는 모든 항목에 접근할 수 있도록 하는 패턴이다. java의 stream이 대표적인 이터레이터 패턴의 예시이다. 예시 코드 @RequiredArgsConstructorpublic class ArrIterator implements Iterator&x3C;Integer{ private final Integer[] list; private int position = 0; @Override public boolean hasNext() { return position &x3C; list.length; } @Override public Integer next() { retu

인터프리터 패턴

인터프리터 패턴은 자주 등장하는 문제를 간단한 언어로 정의하고 재사용하는 패턴이다. 인터프리터 패턴을 사용하면 반복되는 문제 패턴을 언어 또는 문법으로 정의하고 확장할 수 있다. 쉽게 말하면, 일정한 형식을 갖춘 텍스트(String)를 해석해서 규칙에 맞는 로직을 실행할 수 있도록 하는 것이다. 어떤 용도로, 어떤 언어를 구현하는지에 따라 정말 다양한 코드가 나올 수 있지만, 보통 명령을 입력받아 해석하는 Parser와 그것을 바탕으로 로직을 실행하는 Expression으로 나뉜다. 예시 코드 항이 2개인 간단한 덧셈, 뺄셈 식 계산을 인터프리터 패턴으로 구현했다. public interface Expression { Integer interpret(String context);} @NoArgsCo

전략 패턴은 프로그램이 진행되면서 캡슐화된 로직을 선택할 수 있게 하는 디자인 패턴이다. 로직 실행은 인터페이스에 의존을 시키고 인터페이스를 구현한 로직들을 전달해줌으로써 분기처리 없이 유연성을 갖출 수 있다. 객체지향 원칙중 개방-폐쇄 원칙(Open-Closed Principle)을 지키기 위한 디자인 패턴이다. 예시 코드 @Setter@AllArgsConstructorpublic class Coupon { private DiscountStrategy discountStrategy; public int discount(int price) { return discountStrategy.execute(price); }} public interface DiscountStrat

중재자 패턴

중재자 패턴은 객체간 커뮤니케이션을 하는 경우 중재자를 생성하여 객체끼리의 결합을 약화하는 디자인 패턴이다. 중재자 패턴을 사용하면 N:M 개의 객체, 또는 N:1개의 객체간의 데이터 전달도 구현할 수 있다. 객체의 통신을 다룬다는 점에서 옵저버 패턴과 비슷하지만, 옵저버패턴은 한 객체에서 일방적으로 데이터를 송신하는데 반해 중재자패턴은 양방향으로 데이터를 전달할 수 있다는 것이 차이점이다. 예시 코드 @Getter@Setterpublic abstract class Colleague { protected String name; private Mediator mediator; private String message; public Colleague(String name) {

책임연쇄 패턴

책임 연쇄 패턴은 객체를 연결리스트와 같은 사슬 방식으로 연결한 후에 요청을 수행하지 못하는 객체인 경우 책임을 다음 객체에 넘기며 책임을 넘기는 형태의 패턴을 말한다. 각각의 체인은 자신이 해야하는 일만 담당하기 때문에 집합 내의 처리 순서를 변경하거나 처리객체를 유연하게 추가 또는 삭제할 수 있다. 예시 코드 @AllArgsConstructorpublic class RequestHandler { private RequestHandler nextHandler; public void handle(Request request) { if (nextHandler != null){ nextHandler.handle(request); } }} 요청을

커맨드 패턴

커맨드 패턴은 요청을 객체의 형태로 캡슐화하여 사용자가 보낸 요청을 나중에 이용할 수 있도록 매서드 이름, 매개변수 등 요청에 필요한 정보를 저장 또는 로깅, 취소할 수 있게 하는 패턴이다. 어떤 로직에 대한 요청을 객체화 시킴으로써, 코드를 수정하거나 교체하기 쉽게 하고, 유지보수성을 높인다. 예시 코드 @Setter@AllArgsConstructorpublic class Lamp { private boolean power; public boolean isOn(){ return power; }} @Setter@AllArgsConstructorpublic class AirConditioner { private boolean power; public boolean

템플릿메소드 패턴

템플릿 메소드 패턴은 동작 상의 알고리즘의 프로그램 뼈대를 정의하는 행위 디자인 패턴이다. 템플릿 메소드 패턴은 여러 작업들이 동일한 구조를 갖지만, 일부 동작은 각각 다르게 구현해야할 때 사용된다. 템플릿 메소드 패턴은 전체 실행과정을 구현한 상위 클래스(추상 클래스)와 실행 과정의 일부 단계를 구현한 하위 클래스(구체클래스)로 나뉘며, 추상 메서드를 재정의함으로써 알고리즘의 구조를 변경하지 않고 알고리즘의 특정 단계들을 다시 정의할 수 있게 해준다 예시 코드 public abstract class Human { abstract void Introducing(); void eating() { System.out.println("밥먹기"); } void sleep

디자인패턴

디자인패턴

디자인 패턴이란 프로그래밍을 할 때에 공통적으로 생기는 문제를 해결하고자 설계한 일정한 코드의 패턴이다. 애플리케이션이나 시스템을 디자인하는 과정에서 자주 발생하는 문제를 해결하는데에 쓰이는 형식화 된 관행이자, 재사용 가능한 해결책이기도 하다. GoF 디자인 패턴 종류 디자인 패턴에 대해 다루는 유명한 책 중 하나인 ‘GoF의 디자인 패턴’에서 다룬 디자인 패턴의 종류는 다음과 같다. 1. 생성 패턴 (Credential Patterns) 객체 생성과 관련된 패턴이다. 객체의 생성과 조합을 캠슐화하여 특정 객체가 생성되거나 변경되어도 프로그램 구조에 크게 영향을 받지 않도록 유연하게 설계하는 것이 목적이다. 싱글톤(Singleton) 패턴 클래스의 인스턴스를 오직 한개만 생성하여 제공하는 패턴

위임 패턴(Delegate Pattern)

디자인패턴

소프트웨어 엔지니어링에서 delegate pattern(위임 패턴)은 객체 합성이 상속과 동일하게 코드 재사용을 할 수 있도록 하는 객체 지향 디자인 패턴이다. 상속(inheritance) vs 합성(composition) 객체지향 시스템에서 기능의 재사용을 위해 구사하는 가장 대표적인 기법은 클래스 상속, 그리고 객체 합성(object composition)이다. 클래스 상속 서브클래싱, 즉 다른 부모 클래스에서 상속받아 한 클래스의 구현을 정의하는 것. 서브클래싱에 의한 재사용을 화이트박스 재사용(white-box reuse)이라고 한다. ‘화이트박스’는 내부를 볼 수 있다는 의미에서 나온 말로, 상속을 받으면 부모 클래스의 내부가 서브클래스에 공개되기 때문에 화이트박스인 셈이다. 상속의 장점 컴파

자막 파일 포맷

자막 파일은 영상 콘텐츠에 텍스트 정보를 동기화하여 표시하는 파일 형식이다. SRT, SBV, VTT, SMI 네 가지 주요 포맷이 널리 사용되며, 각각의 특성과 용도가 다르다. SRT (SubRip Text) 가장 범용적으로 사용되는 자막 포맷이다. 텍스트 기반의 단순한 구조로 거의 모든 미디어 플레이어에서 지원한다. 구조: 자막 번호, 타임코드, 텍스트, 빈 줄로 구성된다 시간 형식: HH:MM:SS,mmm --HH:MM:SS,mmm 자막 번호를 통해 순서 관리가 명확하다 100:00:01,000 --00:00:04,000안녕하세요, 여러분. 200:00:04,500 --00:00:06,500오늘은 자막 파일 형식에 대해 설명한다. 00:00:04,000안녕하세요, 여러분.200:00:04

The Go language comes with a built-in template language, but not very many template functions. Sprig is a library that provides more than 100 commonly used template functions. argowf에서 sprig 예시

Hammerspoon은 macOS용 데스크톱 자동화 및 시스템 컨트롤 도구로, Lua로 사용하여 macOS의 다양한 기능을 제어할 수 있게 해준다. 설치 및 설정 기본 설치 Terminal windowbrew install --cask hammerspoon Spoon 설치 시스템 Spoon은 Hammerspoon의 모듈 시스템으로, 재사용 가능한 기능들을 패키지화한 것 SpoonInstall: Spoon 관리를 위한 기본 도구 예시 luahs.spoons.use("SpoonInstall", { config = { github_path = "~/.hammerspoon/Spoons/" }}) 설정 파일 구조 ~/.hammerspoon/├── init.l

hls, dash와 cmaf

HLS (HTTP Live Streaming) 애플(Apple)이 개발한 스트리밍 프로토콜 전체 온라인 스트리밍 시장의 약 70%를 차지 iOS/macOS 기기에서 필수적으로 사용하는 FairPlay Streaming DRM은 HLS를 통해서만 적용 가능 기술 구성 컨테이너: m3u8 플레이리스트 + MPEG2-TS 청크 (fMP4도 지원됨) 코덱: H.264 (AVC), H.265 (HEVC) DRM 호환성: FairPlay Streaming (기본) Widevine (추가 지원) 암호화 방식: AES-CBC 모드 (SAMPLE-AES 포함) MPEG-DASH (Dynamic Adaptive Streaming over HTTP) MPEG에서 표준화된 스트리밍 포맷 HL

해상도(Resolution)는 영상의 가로 픽셀 수와 세로 픽셀 수를 의미한다. 예를 들어, 854x480은 가로 854픽셀, 세로 480픽셀로 구성된 화면이다. 해상도는 물리적으로 존재하는 픽셀 수만을 나타내며, 화면 비율(Aspect Ratio)과는 직접적으로 일치하지 않을 수 있다. SAR (Sample Aspect Ratio) 각 픽셀 하나의 가로 대 세로 비율을 뜻한다. SAR이 1:1이면, 하나의 픽셀은 정사각형이다. SAR이 1:1이 아닐 경우, 픽셀은 직사각형 모양이 되어 화면 전체에 왜곡을 발생시킨다. SAR은 인코딩 시점에 설정되며, 영상의 해석 방식에 영향을 준다. SAR을 조정함으로써, 같은 해상도를 유지하면서도 영상의 논리적 비율(DAR)을 수정할 수 있다. • 일부 문헌이

Mise는 개발 환경을 손쉽게 관리할 수 있도록 도와주는 도구로, 다양한 프로그래밍 언어와 툴을 한 번에 관리할 수 있다. asdf, fnm, nvm 등의 버전 관리 도구와 유사하지만, 실행 속도가 더 빠르다. 기능 멀티 런타임 관리 mise는 하나의 도구로 여러 언어와 런타임을 관리할 수 있다. 예를 들어, Node.js, Python, Ruby 등의 버전을 동시에 설치하고 관리할 수 있다. Terminal windowmise use node@18 [email protected] 위 명령어를 실행하면 현재 프로젝트에서 Node.js 18 버전과 Python 3.10 버전을 사용할 수 있다. .tool-versions 파일을 통한 버전 고정 프로젝트별로 특정 버전을 고정하려면 .tool-versions 파일을 사용하면

Box Plot(상자 그림)에서 그 부분들은 각각 다른 통계적 의미를 가짐: 상자(Box) 부분: ▪ 박스의 아랫부분(Q1, 1사분위수): 데이터의 25%가 이 값 아래에 있음 ▪ 박스의 윗부분(Q3, 3사분위수): 데이터의 75%가 이 값 아래에 있음 ▪ 박스 내부의 가로선(중앙선): 중앙값(데이터의 50%) 수염(Whiskers, ––| 부분): ▪ 상단 수염: Q3 + 1.5 IQR(사분위 범위) 까지의 데이터 ▪ 하단 수염: Q1 1.5 IQR 까지의 데이터 개별 점들: ▪ 수염을 벗어나는 점들: 이상치(Outlier) 시각적으로 데이터의 분포, 대칭성, 이상치를 한 눈에 볼 수 있게 해줌.

Native messaging

브라우저 Native Messaging은 확장 프로그램(Extension)이 외부 네이티브 애플리케이션과 직접 통신할 수 있도록 하는 기술이다. 보통 웹 브라우저 내에서 실행되는 확장 프로그램은 보안상의 이유로 로컬 파일이나 시스템 리소스에 직접 접근할 수 없다. 하지만, Native Messaging을 사용하면 브라우저 확장이 특정한 네이티브 애플리케이션을 실행하고 JSON 메시지를 주고받을 수 있다. Native messaging을 사용하면 브라우저 확장 플러그인에 아래 같은 기능을 추가할 수 있다. 파일 시스템 접근: 확장 프로그램에서 로컬 파일을 읽거나 쓰는 작업 수행 네이티브 애플리케이션 제어: 특정 데스크톱 애플리케이션을 실행하고 상태를 확인 보안 관련 작업: 키보드 보안, 암호 관리 소프트웨어

상단 탭 목록 없애기 아래 명령어 실행 ls ~/Library/Application\ Support/Firefox/Profiles/ .default-release로 끝나는 경로 들어가서 mkdir chrome &x26;&x26; vi chrome/userChrome.css userChrome.css 파일에 아래 내용 삽입 @namespace url("http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul"); tabbrowser-tabs { visibility: collapse !--1:403F53">;} nav-bar { border-top: 0px !--1:403F53">; margin-left: 200px; marg

rebase 쉽게 하는법

rebase via merge Let me share one possible way to resolve rebase conflicts. I call it rebase via merge. It can help if you want to rebase a branch with many commits and many conflicts are expected. First, let’s create a temp branch and force all conflicts to show up with a regular merge git c

In a workflow employing relatively long lived topic branches, the developer sometimes needs to resolve the same conflicts over and over again until the topic branches are done (either merged to the “release” branch, or sent out and accepted upstream). This command assists the developer in this process by recording conflicted automerge results and corresponding hand resolve results on the initial m

비트레이트

프레임 레이트 frame rate 프레임 레이트 단위는 fps(frame per second)이다. 30fps라면, 1초에 30장의 프레임이 재생된다. 초당 재생되는 이미지 수가 많아지면 동영상이 더 부드럽게 재생된다. 비트 레이트 bit rate 비트 레이트 단위는 bps(bits per second)이고, 초당 처리하는 데이터 크기를 의미한다. 동영상에서 화질은 해상도와 함께 비트레이트 크기가 중요한 역할을 한다. 해상도가 아무리 높아도 비트레이트가 낮으면 화면이 뭉개진다. 그렇다고 비트레이트를 무턱대고 높인다고 화질이 무조건 좋아지는 것도 아니라 해상도에 맞는 적당한 비트레이트를 선택해야 한다. 물론 비트레이트를 높이면 해상도에 따른 화질이 보장되기는 하는데, 비트레이트가 너무 높으면 쓸데 없이 동영상

ffmpeg [options] [[infile options] -i infile]... {[outfile options] outfile}... 파일 정보 확인 ffmpeg로 입력 파일 정보 확인 ffmpeg -i input.mp4 -hide_banner 옵션을 사용하면, FFmpeg의 로고와 불필요한 버전 정보 없이 파일 정보만을 출력한다. ffprobe ffprobe는 FFmpeg 패키지의 일부로, 미디어 파일의 스트림 정보를 보다 상세하게 분석할 수 있다. 해상도 확인 ffprobe -v error -select_streams v:0 -show_entries stream=width,height -of csv=s=x:p=0 input.mp4 너비, 높이, 코덱 이름, 비트레이트 확인 ffp

컨테이너와 코덱

컨테이너 포맷(Container Format) 앞서 말한 것처럼 동영상 확장자는 오디오, 비디오 데이터인 스트림(Stream)을 하나 이상 가지고 있는 보관함 역할을 하며 이를 컨테이너 포맷(Container Format) 혹은 래퍼 포맷(Rapper Format)이라 부른다. 스트림(Stream)은 데이터, 패킷, 비트 등 일련의 연속성을 갖는 흐름/데이터를 의미하는데 간단히 컨테이너가 가지고 있는 비디오, 오디오 데이터라 생각할 수 있다. 컨테이너가 가지고 있는 비디오, 오디오 스트림(Stream)들은 코덱(Codec)을 통해 가공된 데이터들이다. 왜 코덱을 통해 가공을 했을까? 코덱(Codec) 코덱은 코더(Coder)와 디코더(Decoder)의 앞글자를 딴 합성어로 용량이 큰 영상을 다른 곳으로 이동

EME(Encrypted Media Extension)의 약자로, DRM이 걸려있는 영상 컨텐츠를 사용자가 단말기에서 보안 프로그램 설치 없이 사용할 수 있게 해주는 기술이다. EME를 적용하기 위해선 아래 네 가지가 필요하다. 암호화된 영상이 저장되어있는 스토리지 서버 콘텐츠를 암호화된 형태로 저장하고, 재생시 영상을 반환한다. Shaka Packager와 같은 도구를 사용해 암호화할 수 있다. 복호화 키가 들어있는 라이센스 서버 콘텐츠 재생에 필요한 암호화 키를 안전하게 발급한다. 인증서 영상을 복호화할 때, 복호화키와 인증서를 같이 가져와 인증해야한다. 이 인증서는 개인적으로 발급받기 어렵다. 따라서 인증서를 생성하여 나눠주는 Pallycon 등의 서비스를 사용할 수 있다.

Nightly build 매일 발생하는 소프트웨어에 대한 수정사항을 포함하고 있는 소프트웨어 배포버전이다. 소프트웨어는 테스트가 되어 있지 않을 수 있기 때문에 매우 불안정한 상태이다.

map, noremap map, noremap 둘다 특정키를 매핑하는 역할을 한다. 둘의 차이는 recursive vs non-recursive 이다. 에를 들어 :map j gg:map Q j 를 하면 j를 누르면 gg를 누른 것과 동일한 효과를 얻게 된다. 만약 대문자 Q를 누른다면 j로 매핑한다음 다시 j가 gg를 가리키므로 결과적으로 Q는 gg를 수행하게 된다. 그래서 map을 ‘recursive’하다라고 얘기한다. 매핑되는 키의 또다른 매핑되는 키를 찾아가게 된다. 하지만 nor

압축 알고리즘

BZIP2: Burrows-Wheeler 알고리즘을 사용하는 형식이다. DEFLATE: LZSS 및 Huffman 코딩을 기반으로 한 압축 알고리즘이다. Deflate는 Avro 파일 형식에만 해당된다. GZIP: Deflate를 기반으로 한 압축 알고리즘이다. Athena 엔진 버전 2 및 3의 Hive 테이블과 Athena 엔진 버전 2의 Iceberg 테이블의 경우 GZIP은 Parquet 및 텍스트 파일 스토리지 형식의 파일에 대한 기본 쓰기 압축 형식이다. tar.gz 형식의 파일은 지원되지 않는다. LZ4: Lempel-Ziv 77(LZ7) 패밀리의 알고리즘도 최대 데이터 압축이 아닌 압축 및 압축 해제 속도에 중점을 둔다. LZ4에는 다음과 같은 프레이밍 형식이 있다. • LZ4

웹 바이탈(Web Vitals)은 웹페이지 유저들의 사용 경험을 측정하는 구글의 표준화된 웹 성능 측정 기준이다. 사이트의 전반적인 로딩 속도, 상호작용, 웹페이지의 시각적 안정성, 보안 문제 등 여러 요소를 포함하고 있으며, 웹 사이트가 검색 엔진 결과에 표시되는 위치에 영향을 미친다. 검색 엔진에서 최적화하고 전체적으로 유저에게 좋은 환경을 제공하려면 코어 웹 바이탈을 개선해야한다. 성능 지표 중 주요항목으로는 6가지가 있다. FCP (First Contentful Paint) : 첫번째 텍스트 또는 이미지가 표시되는 시간 TTI (Time to Interactive) : 사용자 인터렉션이 가능해질 때까지 걸리는 시간 SI (Speed Index) : 페이지 속도. 얼마나 빨리 표시되는지 TBT (T

sitemap.xml 사이트맵은 사이트의 페이지, 동영상, 기타 파일들의 관계에 대한 정보를 제공하는 파일이다. 검색엔진 크롤러는 자동으로 홈페이지에서 시작하는 링크를 따라가 페이지를 탐색하는데, 홈페이지에서 모든 페이지를 접근할 수 없거나 페이지 갯수가 많은 경우(약 500개 이상) sitemap.xml 파일을 설정해놓으면 크롤러가 사이트를 더 효율적으로 크롤링할 수 있다. 사이트에 리치 미디어 콘텐츠(동영상, 이미지)가 많거나 Google 뉴스에 표시되어야 하는 경우 sitemap 파일로 추가 정보를 제공하는 것이 좋다. 크롤러에서 인식할 수 있는 사이트맵 형식은 여러가지가 있다. 사이트맵 형식장점단점XML 사이트맵URL에 대한 가장 많은 정보

설정파일 위치: ~/.config/tridactyl/tridactylrc vimR 연동 vimR을 연동하면 브라우저 입력창에서 vim 입력기를 열어 편집할 수 있다. editor 옵션으로 vimR이 아닌 다른 도구를 설정할 수도 있다. brew install --cask vimr 설정파일에 아래 내용을 추가한다. set editorcmd /opt/homebrew/bin/vimr --wait 참고

git branch를 실수로 reset하여 복구하고 싶을 때가 있다. 그런 경우 git reflog를 사용해 특정 명령어 실행 전의 코드로 돌아갈 수 있다. (git log -g --abbrev-commit --pretty=oneline도 사용할 수 있다.) $ git refloga1b2c3d (HEAD -wip/goofy, origin/develop, origin/HEAD) HEAD@{0}: checkout: moving from wip/goofy to developa1b2c3d (HEAD -wip/goofy, origin/develop, origin/HEAD) HEAD@{1}: reset: moving to a1b2c3d7aa62eaab5fdc1dfa83993d9b9e78bde5c7d8e9f HEAD@{

truborepo remote cache .turbo/cache가 캐시 경로임 그걸 업로드해서 remote 공유해서 쓸 수 있게 하는 게 remote cache

New Architecture

JIS 맨 처음엔 RN에서 js 엔진으로 JSC(Apple에서 만든, safari에서 쓰이는 엔진)가 사용되었는데, 브릿지의 책임이 커지고 서로 강결합된다는 문제가 발생했다. 이러한 문제를 해결하기 위해 엔진 인터페이스(JSI)가 만들어졌다. JIS는 Native와 JS 코드가 직접 상호작용할 수 있도록 한다. 즉 JSI라는 인터페이스를 통해서 자바스크립트가 호스트 쪽 객체의 레퍼런스를 직접 가질 수 있도록, 그리고 호스트 쪽 메소드도 직접 호출할 수 있도록 한다. 데이터 전달 과정 네이티브 모듈 인프라로 전달 js runtime이 c++로 전해주고, 네이티브 모듈 인프라로 전해서 처리 뷰도 같은 식으로 전달해서 UI Manager로 전해서 처리 (메모리 업데이트 되면 JS에 반영이 되어서 표시

리액트 네이티브는 iOS와 안드로이드에서 동작하는 네이티브 모바일 앱을 만들기 위한 자바스크립트 프레임워크이다. 리액트 네이티브의 동작 원리는 리액트의 가상(virtual) DOM과 관련되어 있습니다. DOM 수정은 매우 값비싼 동작이기 때문에 리액트는 페이지의 변화를 바로 렌더링 하는 대신 메모리의 가상 DOM을 이용해 변화가 필요한 곳을 계산하고 최소한의 변경사항만 렌더링한다. 리액트 네이티브는 같은 원리를 이용해 브라우저의 DOM이 아닌 오브젝티브-C API를 호출하여 iOS 컴포넌트를 렌더링하고, 자바 API를 호출하여 안드로이드 컴포넌트를 렌더링한다. 이는 브릿지가 대상 플랫폼의 네이티브 UI 요소에 접근하는 인터페이스를 제공하기 때문에 가능하다. 스레딩 모델 리액트 네이티브는 다음의 다중 스레드

소프트웨어 공학

소프트웨어 공학 수업 기말고사 대비 정리입니다. 소프트웨어 공학 공학에는 정해진 기간과 주어진 비용이라는 제한이 있기에, 문제 해결을 위한 기술과 공학적 원리를 활용해야 한다. 그리고 이를 실무에 적용해 문제 해결의 절차를 만들고 반복적인 절차를 개선해 표준을 만들어낸다. 소프트웨어 개발의 어려움을 해결하기 위해 공학을 적용하는 것이 소프트웨어 공학이다. 비용 산정 기법 하향식 전문가 판단 기법 델파이 기법: 전문가의 편견에 영향받지 않도록 조정자를 둠 상향식 코드 라인 수(Line Of Code): 코드 라인 수를 구하고 노력 산정 개발 단계별 노력 기법: 각 단계의 노력 투여를 맨먼스(M/M)로 구함 수학적 COCOMO: 라인 수를 추정하고, 이를 준비된 식에 대입해 M/M 계산 (가

테스팅 용어

테스팅의 기초 테스팅: 소프트웨어 제품과 관련 작업 산출물이 특정 요구명세를 만족하는지 결정하고, 목적에 부합하는지 입증하고 결함을 찾아내기 위해 해당 산출물을 계획, 준비, 평가하는 정적/동적인 모든 수명주기 활동으로 구성된 프로세스 커버리지: 특정한 커버리지 항목이 테스트 스위트에 의해 이행되는 백분율 정도 디버깅: 소프트웨어에서 장애의 원인을 발견하고, 분석하여 제거하는 절차 테스트 오라클: 테스트 대상 소프트웨어의 실제 결과와 비교할 목적으로 예상 결과를 결정하는 근거 밸리데이션: 요구사항이 컴포넌트나 시스템을 특정하게 의도적으로 사용 또는 활용하는 것을 충족시키는지 조사에 의해서나 객관적인 증거 제공으로 확인하는 것. 베리피케이션: 명세된 요구사항이 충족되었는지를 조사에 의해서나 객관적인 증거

Apache Airflow는 초기 에어비엔비(Airfbnb) 엔지니어링 팀에서 개발한 워크플로우 오픈 소스 플랫폼이다. 워크플로우란 의존성으로 연결된 작업(Task)들의 집합을 말한다. 예를 들어 ETL의 경우 Extractaction Transformation Loading 의 작업의 흐름을 가지는 워크플로우이다. Airflow를 사용하면 프로그래밍 방식으로 워크플로우를 작성, 예약 및 모니터링할 수 있다. Key Concept DAG (Directed Acyclic Graph) 단어 뜻 그대로 순환하지 않는 그래프, DAG(대그)라고 부름 반복이나 순환을 허용하지 않음 순차적으로 작업(task)이 이루어지며, 순환 실행을 방지하기 때문에 매우 중요함 → 논리적 오류는 교착상태(deadloc

Vim 이동 기본 이동 -h, j, k, l : 좌, 하, 상, 우 커서 이동 - : 줄의 처음 위치로 커서 이동 gg : 맨 위로 커서 이동 shift + g : 맨 아래로 커서 이동 단어 단위로 이동 w : 단어의 시작 위치로 커서 이동 (오른쪽 방향) b : 단어의 시작 위치로 커서 이동 (왼쪽 방향) e : 단어의 마지막 위치로 커서 이동 (오른쪽 방향) ge : 단어의 마지막 위치로 커서 이동 (왼쪽 방향) 한 문장 내에서 이동 0 (숫자) : 라인 맨 앞으로 커서 이동 ^ : 문장 맨 앞으로 커서 이동 $ : 문장 맨 뒤로 커서 이동 현재 페이지에서의 이동 shift + h : 현재 보이는 페이지에서 커서를 맨 위로 이동 shift + m : 현재 보이는 페이지에서 커서를 중간 위치로

커서 이동 행 k : 커서를 한 행 위로 이동 j : 커서를 한 행 아래로 이동 - : 커서를 앞 행의 처음으로 이동 + : 커서를 다음 행의 처음으로 이동 ^ 또는 0 : 커서를 현재 행의 맨 처음으로 이동 $ : 커서를 현재 행의 마지막으로 이동 글자 l : 커서를 한 글자 오른쪽으로 이동 h : 커서를 한 글자 왼쪽으로 이동 단어 w : 커서를 다음 단어의 첫 글자로 이동 b : 커서를 앞 단어의 첫 글자로 이동 화면 이동하기 반 화면 Ctrl + u : 반 화면 위로 이동 Ctrl + d : 반 화면 아래로 이동 한 화면 Ctrl + b : 한 화면 위로 이동 Ctrl + f : 한 화면 아래로 이동 행 Ctrl + y : 화

GTM은 ‘코드추적을 용이하게 해주는 도구이자 태그 관리 툴’이다. 기존에는 Google Analytics(GA), 페이스북 픽셀 등과 같은 트래킹 툴을 각각 설정해야 했다. 하지만 GTM은 트래킹을 위한 코드의 삽입, 수정, 삭제 모두를 효율적으로 관리할 수 있게 해준다. GTM 코드만 삽입하면, 새로운 마케팅 툴을 여러 개 추가하더라도 추가적인 코드작업 없이 손쉽게 설치 할 수 있다. 핵심 용어 태그 데이터를 어디로 전달할 지를 정의한다. 데이터를 추적해 활용하는 트레이싱 툴을 등록하면 된다. 트리거 어떤 경우에 실행할 지를 정의한다. 트리거 조건을 충족했을 경우 데이터가 전송된다. 트리거 유형은 사용자의 창 로드, 클릭, 스크롤 등이 될 수 있다. 변수 어떤 데이터, 값을 전달할 지를

Git Flow 는 2010년 Vincent Driessen 이 작성한 블로그 글을 통해 유명해지기 시작한 Git Branching Model중 하나로, Git의 사용 방법론이다. GitFlow는 프로젝트를 런칭한 이후에도 코드를 관리하기 용이하게 하고, 프로젝트에서 발생하는 다영한 워크플로우의 구현이 가능하기 떄문에 많은 개발자들이 사용하는 방법론으로 자리잡게 되었다. 에디터와 IDE에서 플러그인으로 지원하는 경우도 많다. 브랜치의 종류가 많아 복잡하고, release와 master의 구분이 모호하기도 하지만 프로젝트의 규모가 커지면 커질수록 소스코드를 관리하기에 용이하다는 장점이 있다. GitFlow의 브랜치 Git Flow는 크게 5개의 branch 를 사용한다. 그중 가장 중심이 되는 브랜치는

GitFlow의 브랜치 전략의 복잡한 부분을 생략하여 간략화한 브랜치 전략이다. github flow는 master 브랜치 하나만을 가지고 진행하는 방식이다. GitHub Flow는 master와 feature, 두개의 브랜치로 나뉜다. Github Flow의 개발 과정은 다음과 같다. master 브랜치에서 개발이 시작된다. 기능이나 버그에 대해 issue를 작성한다. 팀원들이 issue 해결을 위해 master 브랜치에서 생성한 feature/{구현기능} 브랜치에서 개발을 진행하고 커밋한다. 개발한 코드를 master 브랜치에 병합할 수 있도록 요청을 보낸다. 즉, pull request를 날린다. pull request를 통해 팀원들간에 피드백을 주고받거나 버그를 찾는다. 모든 리뷰가 이뤄지면

Gitlab은 Git의 원격 저장소와 코드 리뷰, 이슈 트래커 기능등을 제공하는 소프트웨어로, 설치형 Github라는 컨셉으로 시작된 프로젝트이기 때문에 Github와 비슷한 면이 많다. 1. 패키지 종류 GitLab 패키지는 3가지로 구분된다. GitLab CE : Community Edition으로 설치형이고 아무런 제한 없이 무료 GitLab EE : Enterprise Edition으로 설치형이고 매월 유저당 과금 (참고) GitLab.com : 클라우드형이고 개인이 가입해서 사용하면 무료 2. 기능 Git 저장소 및 관리 프로젝트 생성하면 자동으로 git 저장소가 생성됨 그룹 및 팀원 그룹을 만들고 팀원을 지정해서 그룹 단위로 접근 권한을 관리할 수 있음 업무 관리 마일스톤을 설정

Selfhosted Runner

Self-hosted Runner란 Github Actions에서 사용자가 지정하는 로컬 컴퓨팅 자원으로 빌드를 수행하도록 설정하는 기능이다. 주로 배포작업이 많아 배포가 지체되거나 서버 비용이 부담되는 경우 사용한다. 설정 방법 Github Actions을 사용하고자 하는 저장소에서 Settings Actions Runners로 이동한다. 설정하고자 하는 로컬 머신에 해당되는 OS를 선택하면 OS 별로 설정하는 방법이 Download와 Configure란에 설명되어 있다. Linux 기준으로는 다음과 같다. Download Terminal window Create a folder$ mkdir actions-runner &x26;&x26; cd actions-runner Download the latest

Git에서는 어떤 이벤트가 생겼을 때 자동으로 특정 스크립트를 실행하도록 할 수 있다. 이 훅은 클라이언트 훅과 서버 훅으로 나눌 수 있는데, 클라이언트 훅은 커밋이나 Merge 할 때 실행되고 서버 훅은 Push 할 때 서버에서 실행된다. 프로젝트의 .git/hooks 폴더에 들어가서 해당 훅의 이름을 파일명으로 쉘스크립트를 작성하면, 해당 훅이 특정 상황에 자동으로 실행된다. 분류에 따른 훅은 아래 표와 같다. Commit workflow hook 훅설명pre-commitcommit 을 실행하기 전에 실행prepare-commit-msgcommit 메시지를 생성하고 편집기를 실행하기 전에 실행commit-msgcommit 메시지를 완성한 후 commit 을

githook을 위한 perl command

perl option Perl은 심플한 프로그래밍 언어 중 하나이다. CLI에서 perl 명령어를 통해 짧은 스크립트를 실행할 수 있다. 아래와 같이 텍스트 대치 등 간단한 처리 스크립트를 작성하는 데 사용하기 좋다. Terminal windowperl -p0e 's/__PROJECT_TREE__/`cat`/se' "$readme_template" > "$readme" &x22;$readme&x22;"> 실행 제어 -e : 스크립트로서 실행할 스트링을 지정하여 Command Line에서 수행 -M : 펄 모듈을 로드하는 옵션이며, Default Import 하지 않을 경우 -m 옵션을 사용 -l : 표준 장소 앞에서 모듈을 검색하기 위한 디렉토리 지정 -c : 펄 프로그램을 컴파일(실행전 에러

파일트리 자동생성

레포지토리 폴더에 .git/hook/pre-commit 파일을 생성하여 아래 스크립트를 넣으면 커밋시에 README.md 파일에 트리가 자동으로 생성된다. (mac 기준) !/bin/bash export LANG=UTF-8 function generate_project_tree() { tree /Users/rlaisqls/Documents/github/TIL -tf --noreport -I '~' --charset ascii $1 | gsed -e 's/[|]-\+/╊━/g' | gsed -e 's/[|]/┃/g' | gsed -e 's/[`]/┗━/g' | gsed -e 's/[-]/━/g' | gsed -e 's:\(━ \)\(\(.*/\)\([^/]\+\)\):\1[\4]

기존 TIL Repository는 파일을 추가하거나 수정한 뒤 수동으로 커밋하는 방식으로 운영했다. 하지만 혼자 작성하다보니 버전 관리에 대한 이점도 크게 없고, 생성이나 수정에 대한 커밋을 각각 나눠서 하는게 번거로워서 그냥 하루에 한 번씩 local crontab을 돌려 자동으로 커밋하도록 하는 쉘 스크립트를 작성하였다. 크게 복잡한 내용은 없고 그냥 git . add 한 뒤 커밋하는 것이 전부이다. 단, 작성중이어서 커밋하면 안되는 파일은 접두사에 +를 붙여서 표기하고 gitignore에 커밋되지 않도록 설정해줬다. +로 정한 이유는 명령어상 다른 특별한 의미가 없으면서 파일명 앞에 들어갈 일이 없을 것 같은 기호였기 때문이다. +autocommit.sh를 정의한다. !/bin/bash Y=$(dat

Intellij Profiling tools

IntelliJ IDEA Ultimate를 사용하고 있다면 Profiling tools을 사용하여 애플리케이션에 대한 부가적인 분석 정보를 얻을 수 있다. 세부 기능으로는 애플리케이션의 실행 방식과 메모리, CPU 리소스가 할당되는 방식에 대한 분석을 제공하는 Async Profiler, 애플리케이션이 실행되는 동안 JVM에서 발생한 이벤트에 대한 정보를 수집하는 모니터링 도구인 Java Flight Recorder 등이 있다. 또한 애플리케이션의 특정 시점의 스냅샷으로 메모리를 분석하거나(Analyze memory snapshots) 애플리케이션이 실행되는 도중에도 CPU와 메모리 현황을 실시간으로 확인할 수 있는 기능(CPU and memory live charts)들이 있다. 기능 Profiling A

Makefiles are a simple way to organize code compilation. This tutorial does not even scratch the surface of what is possible using make, but is intended as a starters guide so that you can quickly and easily create your own makefiles for small to medium-sized projects. A Simple Example Let’s start off with the following three files, hellomake.c, hellofunc.c, and hellomake.h, which would represent

Apache Spark는 빅 데이터 워크로드에 주로 사용되는 오픈 소스 분산 처리 시스템이다. Apache Spark는 빠른 성능을 위해 인 메모리 캐싱과 최적화된 실행을 사용하며, 일반 배치 처리, 스트리밍 분석, 기계 학습, 그래프 데이터베이스 및 임시 쿼리를 지원한다. 장점 빠른 성능: Apache Spark는 방향성 비순환 그래프(DAG) 실행 엔진을 사용함으로써 데이터 변환에 대한 효율적인 쿼리 계획을 생성할 수 있다. 또한, Apache Spark는 입력, 출력 및 중간 데이터를 인 메모리에 RDD(Resilient Distributed Dataset)로 저장하므로, I/O 비용 없이 반복 또는 대화형 워크로드를 빠르게 처리하고 성능을 높일 수 있다. 애플리케이션을 신속하게 개발: Apac

mermaid로 그릴 수 있는 다이어그램은 아래와 같은 것들이 있다. 플로우 차트 (Flowchart) 시퀀스 다이어그램 (Sequence Diagram) 간트 차트 (Gantt Chart) 클래스 다이어그램 (Class Diagram) User Journey Diagram Git graph Entity Relationship Diagram 플로우 차트(Flowcharts) 모든 플로우 차트는 각 상태를 나타내는 Node와 Node를 이어주는 간선(Edge)으로 구성된다. 우리는 mermaid를 통해 다양한 화살표, 간선 타입, 서브 그래프로 플로우차트를 간단하게 그려낼 수 있다. flowchart LR A[구매] --> B; B[유저, 파라미터, \n 어뷰징 검증] --> C; C{cl

정보 보안에는 인증(Authentication, authn)와 인가(Authorization, authz)라는 개념이 있다. 간단히 말하자면 authn은 정체성 또는 그 유저가 누구인지와 관련있는 반면, authz는 권한 또는 누군가가 할 수 있는 것을 다룬다. 둘은 연관되어있지만 서로 다른 개념이고, 유저를 식별하고 접근을 관리하는(IAM)에서 중요한 요소이다. Authentication(authn)이란? authn은 사용자의 신원을 검증하는 행위로서 보안 프로세스에서 첫 번째 단계이며, 사용자 또는 장치가 누구인지(또는 무엇인지)를 확인하는 것을 의미한다. 신분을 확인함으로써 사용자가 합법적인지 확인하고자 하는 것이며, 잘못된 사람에게 정보가 노출되지 않도록 보장한다. 일반적인 authn 방법에는 아래

FineGrained와 CoarseGrained

Fine-grained는 사전적으로 “결이 고운”, “미세한”이라는 의미를 가지고, Coarse-grained는 “결이 거친”, “조잡한”의 의미를 가진다. Grain은 곡식 혹은 낱알을 뜻하는데, 알갱이가 거칠고 큼직큼직헌지, 곱고 세밀한지에 따라서 Coarse와 Fine으로 나누어 표현한다고 이해할 수 있다. Fine-Grained 하나의 작업을 작은 단위의 프로세스로 나눈 뒤, 다수의 호출을 통해, 작업 결과를 생성해내는 방식 예를 들어, Do라는 동작이 있다면 해당 함수를 First_Do(), Second_Do()로 나누어 작업 결과를 생성해냄 다양한 “Flexible System” 상에서 유용하게 쓰일 수 있음 Coarse-Grained 하나의 작업을 큰 단위의 프로세스로 나눈 뒤, “Sin