날짜: 2022년 5월 6일 오후 8:01 코드 Algorithm/64061.py at main · Junroot/Algorithm 풀이 stack을 이용하면 되는 문제다. 복잡한 로직은 필요하지 않다.

날짜: 2022년 6월 29일 오후 1:39 코드 Algorithm/60063.py at main · Junroot/Algorithm 풀이 BFS를 통해 최소 경로를 탐색하면된다. 여기서, 로봇이 이동할 수 있는 경우를 체크하는 과정이 조금 복잡하다. 조건문을 이용한 분기처리로 구현해야된다.

날짜: 2022년 6월 28일 오후 3:58 코드 Algorithm/60062.py at main · Junroot/Algorithm 풀이 결론부터 말하면 완전탐색이다. 나같은 경우는 dist가 가장 큰 값의 위치를 먼저 선택한 뒤, 원형을 직선으로 변환한 뒤 직선 형태로 만든 뒤 가장 적은 사람이 필요한 경우를 찾았다. 이렇게 하면 점화식 형태로 문제를 풀 수 있기 때문이다.

날짜: 2022년 6월 28일 오후 3:54 코드 Algorithm/60061.py at main · Junroot/Algorithm 풀이 문제 조건을 그대로 구현하는 시뮬레이션 문제다. 구조물을 제거할 때는 일단 제거하고 자신이 영향을 줄 수 있는 구조물들을 ‘구조물을 추가할 때의 조건’을 만족하는지를 체크했다.

날짜: 2022년 6월 28일 오후 3:52 코드 Algorithm/60060.py at main · Junroot/Algorithm 풀이 바이너리 서치를 이용해서 문제를 풀었다. words를 정렬한 뒤, 쿼리를 만족하는 word를 lower bound와 upper bound의 차로 개수를 구했다. 쿼리와 단어를 비교하는 법은 아래와 같다. 글자 길이가 다른 경우 길이가 더 짧은 것을 작은 값으로 취급 글자 길이가 같은 경우 사전순 비교 쿼리에 ?가 나온 순간부터 같은 단어로 취급(접미사가 ?인 경우를 고려해서다. 접두사의 경우는 처리하지 않았다. 위 방식대로 하면 접두사에 ?...

날짜: 2022년 3월 8일 오후 3:47 코드 Algorithm/60059.py at main · Junroot/Algorithm 풀이 단순히 모든 경우의 수를 다 구해보면 되는 문제다. 겹쳐지는 부분 계산을 좀 신경써야되는데, 특정 lock위치에 대한 key의 위치값 차이를 delta로 두고 모든 가능한 delta값을 루프를 돌면서 탐색했다.

날짜: 2022년 6월 23일 오전 11:45 코드 Algorithm/60058.py at main · Junroot/Algorithm 풀이 단순 구현문제다.

날짜: 2022년 6월 20일 오전 10:45 코드 Algorithm/60057.py at main · Junroot/Algorithm 풀이 문자열의 길이가 최대 1000밖에 되지 않으므로, 모든 압축 단위를 한 번씩 진행해도 O(n^2)로 시간초과가 발생하지 않을 것이다.

키-값 저장소: 비 관계형 데이터베이스로 저장소에 저장되는 값은 고유 식별자를 키로 가진다. 키는 일반 텍스트일 수도 있고 해시 값일 수도 있다. 키는 성능상의 이유로 짧을수록 좋다. 문제 이해 및 설계 범위 확정 다음 특성을 갖는 키-값 저장소를 설계해 볼 것이다. 키-값 쌍의 크기는 10KB 이하이다. 큰 데이터를 저장할 수 있어야 한다. 높은 가용성을 제공해야 한다. 따라서 시스템은 설사 장애가 있더라도 빨리 응답해야 한다. 높은 규모 확장성을 제공해야 한다. 따라서 트래픽 양에 따라 자동적으로 서버 증설/삭제가 이루어져야 한다....

상속보다는 컴포지션을 사용하라 간단한 행위 재사용 재사용을 위해 상속을 사용했을 때 단점 상속은 하나의 클래스만을 대상으로 할 수 있다. 상속을 사용해서 행위를 추출하다 보면, 많은 함수를 갖는 거대한 BaseXXX 클래스를 만들게 되고, 굉장히 깊고 복잡한 계층 구조가 만들어진다. 상속은 클래스의 모든 것을 가져오게 된다. 따라서 불필요한 함수를 갖는 클래스가 만들어질 수 있다. 인터페이스 분리 원칙 위반 상속은 이해하기 어렵다. 작동 방식을 이해하기 위해 슈퍼클래스를 여러 번 확인해야 한다. 재사용을 위해 컴포지션을 사용했을 때 장점 코드의 실행을 더 명확하게 예측할 수 있다....

널 가능성 널 가능성(nullability): NPE를 피할 수 있게 돕기 위한 코틀린 타입 시스템의 특성 코틀린을 비롯한 최신 언어에서 null에 대한 접근 방법은 가능한 한 이 문제를 실행 시점에서 컴파일 시점으로 옮기는 것이다. 널이 될 수 있는 타입[] 모든 타입은 기본적으로 널이 될 수 없는 타입이다. 널을 받을 수 있게 하려면 타입 이름 뒤에 물음표(?)를 명시해야 한다. 널이 될 수 있는 타입의 변수가 있다면 그에 대해 수행할 수 있는 연산이 제한된다. 메소드를 직접 호출할 수 없다....

전송 계층의 역할 전송 계층은 목적지에 신뢰할 수 있는 데이터를 전달하는 역할과 전송된 데이터의 목적지가 어떤 애플리케이션인지 식별하는 역할을 한다. 전송 계층의 특징을 설명하면 신뢰성/정확성과 효율성으로 구분할 수 있다. 신뢰성/정확성: 데이터를 목적지에 문제없이 전달하는 것. 연결형 통신이라고 한다. 연결형 통신은 상대편과 확인해 가면서 통신하는 방식이다. TCP 효율성: 데이터를 빠르고 효율적으로 전달하는 것. 비연결형 통신이라고 한다. 비연결 통신은 상대편을 확인하지 않고 일방적으로 데이터를 전송하는 방식이다. 동영상처럼 효율적인 데이터 전송이 필요한 애플리케이션에서 사용한다....

기능 명세 vs 기술 명세 5장에서 이야기 했던 명세는 기능 명세에 해당한다. 기능 명세(functional specification) 사용자 관점에서 젶무이 어떻게 동작할지를 기술 구현은 신경 쓰지 않는다. 화면, 메뉴, 대화 상자 등 기술 명세(technical specification) 프로그램 내부 구현을 기술한다. 자료 구조와 관계 형 데이터베이스 모델과 프로그래밍 언어, 도구, 알고리즘 선택과 같은 항목을 다룬다. 명세서에 넣는 단골 항목 면책 조항: 현재 명세가 완벽하지 않다는 것을 알리는 방어적 내용. 저자: 명세에서 무엇인가 잘못된다면, 이를 수정할 책임있는 명세서 소유자를 지정해야 하며, 이 사람 이름이 명세서에 찍혀 있어야 한다....

데이터베이스는 세부사항이다 애플리케이션 내부 데이터의 구조는 시스템 아키텍처에서 대단히 중요하다. 하지만 데이터베이스는 데이터 보델이 아닌 소프트웨어일 뿐이다. 아키텍처 관점에서 이러한 유틸리티닌 저수준의 세부사항일 뿐이라서 아키텍처와는 관련이 없다. 데이터베이스 시스템이 우위를 차지할 수 있었던 이유는 디스크 떄문이다. 느린 디스크를 개선하기 위해 색인, 캐시, 쿼리 계획 최적화가 필요했다. 이를 위해ㅅ 데이터 접근 및 관리 시스템이 필요했다. 파일 시스템: 문서 기반. 문서의 이름을 기준으로 조회할 떄는 잘 동작하지만, 내용을 기준으로 검색할 떄는 크게 도움되지 않는다....

단위 테스트의 세 가지 스타일 단위 테스트의 세 가지 스타일 출력 기반 테스트 상태 기반 테스트 통신 기반 테스트 테스트 품질: 출력 기반 > 상태 기반 > 통신 기반 출력 기반 테스트 정의 SUT에 입력을 넣고 생성되는 출력을 점검하는 방식 출력 기반 테스트 스타일은 사이드 이펙트가 없는 순수 함수 방식으로 작성된 코드에만 적용된다. 상태 기반 스타일 정의 작업이 완료된 후 시스템 상태를 확인 상태는 SUT나 협력자 중 하나, 또는 데이터베이스나 파일 시스템 등과 같은 프로세스 외부 의존성의 상태 등을 의미할 수 있다....

교착 상태의 개요 교착 상태의 정의 교착 상태: 2개 이상의 프로세스가 다른 프로세스의 작업이 끝나기만 기다리며 작업을 더 이상 진행하지 못하는 상태. 교착 상태 vs 아사 상태: 아사 상태는 운영체제가 잘못된 정책을 사용하여 특정 프로세스 작업이 지연되는 문제고, 교착 상태는 여러 프로세스가 작업을 진행하다 자연적으로 발생하는 문제다. 교착 상태는 시스템 자원, 공유 변수(또는 파일), 응용 프로그램 등을 사용할 떄 발생할 수 있다. 자원 할당 그래프 자원 할당 그래프: 프로세스가 어떤 자원을 사용 중이고 어떤 자원을 기다리고 있는지 방향성이 있는 그래프로 표현한 것이다....

REST 컨트롤러 작성하기 서버에서 데이터 가져오기 @CrossOrigin(origins = ["*"]) @RequestMapping(path = ["/design"], produces = ["application/json"]) @RestController class DesignTacoController( private val tacoRepository: TacoRepository ) { @GetMapping("/recent") fun recentTacos(): Iterable<Taco> { val pageRequest = PageRequest.of(0, 12, Sort.by("createdAt").descending()) return tacoRepository.findAll(pageRequest).content } } @RestController: @Controller와 @ResponseBody를 지원하는 애노테이션 @ResponseBody: 리턴 값을 HTTP 응답 바디에 직접 쓰는 값으로 사용한다. 응답 바디를 직접 작성하는 방법으로는 이외에도, ResopnsEntity 객체를 반환하는 방법이 있다. @RequestMapping produces: HTTP의 Accept 헤더에 사용되고 HTTP의 Content Negotiation에 사용된다....

프로세스 간 통신 프로세스 간 통신의 개념 프로세스 내부 데이터 통신: 하나의 프로세스 내에 2개 이상의 스레드가 존재하는 경우의 통신. 프로세스 내부의 스레드는 전역 변수나 파일을 이용하여 데이터를 주고 받는다. 프로세스 간 데이터 통신: 같은 컴퓨터에 있는 여러 프로세스끼리의 통신. 공용 파일 또는 운영체제가 제공하는 파이프를 사용하여 통신한다. 네트워크를 이용한 데이터 통신: 여러 컴퓨터가 네트워크로 연결되어 있을 때의 통신. 프로세스가 소켓을 이용하여 데이터를 주고받는다. 💡 같은 컴퓨터에 있는 프로세스끼리도 소켓을 이용하여 통신할 수 있다....

수평적 규모 확장성을 달성하기 위해서는 요청 또는 데이터를 서버에 균등하게 나누는 것이 중요하다. 해시 키 재배치(rehash) 문제 나머지 연산으로 해시를 배치하는 것은 데이터 분포가 균등할 떄만 잘 동작한다. 또한, 서버가 추가되거나 기존 서버가 삭제되면 대부분의 키가 재분배된다. 안정 해시 안정 해시: 해시 테이블 크기가 조정될 떄 평균적으로 k/n개의 키만 재배치하는 기술 k: 키의 개수 n: 슬롯의 개수 기본 구현법 해시 함수를 사용해서 서버 IP나 이름으로 링 위에 서버를 배치한다. 해시 키도 똑같이 배치한다....

아키텍처란? 아키텍처의 주목적: 시스템의 생명주기 지원 시스템을 쉽게 이해하고, 쉽게 개발하며, 쉽게 유지보수하고, 쉽게 배포하게 해준다. 팀 구조에 따라 아키텍처가 결정이 날 수도 있다. 작은 규모의 팀이라면 모노리틱 시스템으로 개발할 수도 있다. 팀 규모가 클 때, 안정된 인터페이스가 없고 잘 설계된 컴포넌트로 분리되어 있지 않다면 각 팀마다 하나씩 컴포넌트를 가질 가능성이 높다. 소프트웨어 아키텍처는 시스템을 단 한 번에 쉽게 배포할 수 있도록 만드는 데 목표를 두어야 한다. 개발 초기 단계에 MSA를 사용하자고 결정할 경우, 컴퓨넌트 경계가 뚜렷해지고 인터페이스가 안정화되므로 시스템을 매우 쉽게 개발할 수 있다고 판단할 수 도 있다....