일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | ||
6 | 7 | 8 | 9 | 10 | 11 | 12 |
13 | 14 | 15 | 16 | 17 | 18 | 19 |
20 | 21 | 22 | 23 | 24 | 25 | 26 |
27 | 28 | 29 | 30 |
- 디프만
- js
- spring boot
- time slice
- 마블 다이어그램
- Round Robin
- Observable
- 생활코딩
- OOAD
- 원격 저장소
- CPU Scheduling
- RxJava
- github
- 큐시즘
- Cold Publisher
- Hot Publish
- Git
- 자바스크립트
- flab
- 에프랩
- 건국대학교
- CLI
- OS
- 파이썬
- Hot Publisher
- 버전관리
- spring
- 멘토링 후기
- Depromeet
- js 개발자라면 알아야하는 핵심 컨셉
- Today
- Total
목록Development (34)
글쓰는 개발자

Single 데이터를 1건만 통지하거나 에러를 통지한다. 데이터 통지 자체가 완료를 의미하기 때문에, 완료 통지는 하지 않는다. 데이터를 1건만 통지하므로, 데이터 개수를 요청할 필요가 없다. onNext(), onComplete()가 없으며 이 둘을 합한 onSuccess()를 제공한다. Single의 대표적인 소비자는 SingleObserver이다. 클라이언트 요청에 대응하는 서버의 응답이 Single을 사용하기 좋은 대표적인 예이다. Maybe 데이터를 1건만 통지하거나 1건도 통지하지 않고 완료 또는 에러를 통지한다. 데이터 통지 자체가 완료를 의미하기 때문에 완료 통지는 하지 않는다. 단, 데이터를 1건도 통지하지 않고 처리가 종료될 경우에는 완료 통지를 한다. Maybe의 대표적인 소비자는 M..

Flowable과 Observable의 비교 Flowable은 Reactive Streams의 인터페이스를 구현하고, Observable은 그렇지 않다. 아래의 Flowable는 Publisher를 구현하고 있다. /* Flowable.java */ public abstract class Flowable implements Publisher { ... } /* Publisher.java */ package org.reactivestreams; // reactive streams 패키지 public interface Publisher { public void subscribe(Subscriber

목차 Reactive Streams? Cold Publisher & Hot Publisher Cold Publisher & Hot Publisher 예제로 살펴보기 Reactive Streams? 리액티브 프로그래밍 라이브러리의 표준 사양(https://github.com/reactive-streams/reactive-streams-jvm) 리액티브 프로그래밍에 대한 인터페이스만을 제공함 RxJava는 Reactive Streams의 인터페이스들을 구현한 구현체이다. Reactive Streams는 다음 4개의 인터페이스를 제공 Publisher Subscriber Subscription Processor Publisher public interface Publisher { public void subs..

목차 Reactive Programming Reactive Programming 필수 요소 예제 Reactive Programming? In computing, reactive programming is a declarative programming paradigm concerned with data streams and the propagation of change. 컴퓨팅에서 반응형 프로그래밍은 데이터 스트림 및 변경 전파와 관련된 선언적 프로그래밍 패러다임입니다. 간단하게, Reactive Programming이란 데이터 변경 이벤트를 감지하여 stream으로 흘려보내는 행위를 선언적 프로그래밍 방식으로 사용하는 프로그래밍 패러다임이다. 선언적 프로그래밍 선언적 프로그래밍은 명령형 프로그래밍에 대조..

Stage 2030 Analysis에서는 크게 두 가지 To-Do가 있다. 하나는 외부 Actor가 시스템에 접근하기 위해 필요한 Interface 역할을 하는 Operation들을 시스템 수준에서 분석하고 찾아내는 것이고, 다른 하나는 개발에 참여하는 개발자들이 전체적인 시스템 도메인에 대해 파악하기 위한 시간을 가지는 것이다. 본격적인 시스템 해부 및 설계의 단계로 넘어가기 위한 중간 단계로써, 이 단계를 거치면서 개발의 방향성이 더욱 구체화된다. INDEX Use-Case Model Use Case System Operation Domain Model Traceability Analysis 1. Use-Case Model Use-Case Model은 사용자가 시스템에게 기대하는 행동을 Operati..

현대의 대부분의 OS들은 Round-Robin Algorithm의 변형 형태의 Algorithm을 통해 프로세스들에게 CPU를 공평하게 분배하려 한다. [OS] Virtualization #2.CPU Scheduling 대부분의 프로세스들이 I/O 작업을 더 많이 필요로 하는 I/O-bound job이긴 하지만, 여전히 CPU의 처리를 더 많이 필요로 하는 CPU-bound job 또한 있기 마련이다. I/O-bound job은 Response time이 중요하기 때문에 짧은 Time Slice를 가지는 Round-Robin이 꽤나 효과적인 반면, CPU-bound job은 Turnaround time이 더 중시되어서 상대적으로 긴 Time Slice를 가지는 Round-Robin algorithm이 더..

지난 포스팅 객체지향 개발 방법론(OOAD) : OOP, UP에서 OOP, UP에 대해 소개하였다. 이번 포스팅부터는 본격적으로 OOPT에 대해 소개하려 한다. OOPT의 첫 번째 단계인 Stage 1000 Planning 단계에서는 이름처럼 제작할 시스템에 대한 명칭, 전반적인 계획, 비전, 투입 금액 산정, 요구사항 정의 등의 스케치 작업들을 수행한다. 시스템 개발 측면에서 크게 할 일은 없고, 비즈니스와 관련한 내용들이 오히려 주를 이룬다. 회사 내에서는 프로젝트 착수전 보고 단계이며, UP에서는 feasibility study를 수행하는 Inception Stage로 대응될 수 있다. INDEX Activity 1001. Define a draft plan Activity 1002. Create ..

이전 포스팅인 [OS] Virtualization #1.Limited direct execution에서 OS가 다른 프로세스들보다 상위 권한을 가지고, 그렇게 주어진 권한을 통해 각종 컴퓨터 자원들을 프로세스 사이에서 적당하게 분배하는 것이 어떻게 구현되는지 간략한 수준으로 소개하였다. 이번 포스팅에서는 상위 권한을 가지게 된 OS가 각 프로세스들에게 CPU를 할당하는 정책인 CPU Scheduling 정책에 대해 소개하려 한다. INDEX Workload Assumptions Scheduling Metrics FIFO(First In, First Out) SJF(Shortest Job First) STCF(Shortest time to completion first) RR(Round-Robin) 1. ..

OS의 역할은 부족한 컴퓨터 자원을 효율적으로 분배하는 것이다. 한 프로세스가 CPU를 너무 오래 점유하면, OS는 프로세스로부터 CPU를 뺏어 다른 프로세스에 할당한다. 어떠한 데이터가 자주 사용되지 않는 경우, OS는 해당 데이터를 CPU로부터 더 먼 곳에 배치하고 자주 사용되는 데이터를 CPU에 더 가까이 배치하여 실행 속도를 향상시킨다. 또한 어떠한 유저가 프로그램 내에서 하드웨어를 제어하는 명령을 실행할 때에, 이것의 핸들링을 담당하기도 한다. 여기까지 OS의 역할을 아는 것은 좋은데, 다음과 같은 의문을 제기할 수 있다. '프로세스가 실행 중이라는 것은 CPU가 프로세스에 할당되어 있다는 뜻이고, OS 또한 작업 수행을 위해 CPU 할당을 받아야 하는 시스템 소프트웨어인데 어떻게 중간에 OS가..

모든 일에 있어 가장 중요한 일은 개요(또는 목차)를 잡는 것이라고 생각한다. 개요를 잡고 무언가를 시작하게 되면, 큰 문제에 직면하더라도 그것을 조각내서 단순화하여 생각할 수 있고 개요 간의 관계 또한 선명하게 살필 수 있으며 전체 맥락도 빠르게 파악할 수 있는 등의 여러 가지 장점이 많다고 생각하기 때문이다. 이 개요라는 것은 비단 문장에서뿐만 아니라 어떤 영역에서든 적용될 수 있고, 각 영역에서 정의하는 그들만의 단어로 표현되는 듯하다. 소프트웨어 개발에 있어서 이러한 개요는 '설계'라는 단어로 표현할 수 있지 않을까. 무턱대고 각종 IDE를 실행하여 일단 코드를 써 내려가는 것보다는, 먼저 시스템에 대한 도메인을 파악하고, 아키텍처를 잡고 각 모듈들간의 관계에 대해 파악하는 등의 일련의 '개요 잡..