일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
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 |
- Depromeet
- flab
- Hot Publisher
- js 개발자라면 알아야하는 핵심 컨셉
- OOAD
- 버전관리
- Round Robin
- 건국대학교
- RxJava
- spring boot
- 자바스크립트
- spring
- CLI
- Git
- github
- 멘토링 후기
- 디프만
- 큐시즘
- CPU Scheduling
- Cold Publisher
- Hot Publish
- 마블 다이어그램
- Observable
- 원격 저장소
- 파이썬
- js
- time slice
- OS
- 생활코딩
- 에프랩
- Today
- Total
목록전체 글 (46)
글쓰는 개발자
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
디자이너와 프로그래머가 만났을 때, 디프만 12기 지원 후기 2021년 12월, NHN에 입사하여 지인들께 축하받던 때가 엊그제 같은데 벌써 1년차가 3개월도 채 남지 않았습니다.(나이도 한 살 더... ㅜㅜ) 한동안 신입 교육받으랴, 팀에도 적응하랴 여기저기 바빴지만 이제는 어느정도 적응도 했고, 또 다른 성장의 길을 탐색하고 있습니다. 때마침 지인을 통해서 알고 있던 디프만 동아리의 12기 모집이 시작되었고 시기도 지금이 적기인 것 같아 백엔드 포지션으로 지원하여 오늘(9월 22일) 최종 합격 메일을 받았습니다 :) 관련하여 회고 겸, 다른 분들 참고 겸 하여 후기를 남깁니다. 목차 디프만? 지원 동기 서류 전형(1차) 면접 전형(2차) 디프만? 디프만은 디자이너와 프로그래머가 만났을 때의 약자로, ..
목차 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으로 흘려보내는 행위를 선언적 프로그래밍 방식으로 사용하는 프로그래밍 패러다임이다. 선언적 프로그래밍 선언적 프로그래밍은 명령형 프로그래밍에 대조..
6개월간의 F-lab 멘토링 회고(2021.01 ~ 2021.07) 2021년 1월부터 7월까지, 조금 더 좋은 개발자가 되고 싶다는 마음에 F-lab 멘토링에 참여하였습니다. 멘토링을 받으면서 개발자가 어떤 방향으로 노력해야 하는지 깨달을 수 있었고, 그러한 깨달음을 바탕으로 올바른 방향을 잡고 꾸준히 노력하여 멘토링을 시작할 때보다 조금은 더 나은 개발자가 될 수 있었다고 생각합니다. 또한 감사하게도, NHN에서 그간의 노력들을 좋게 봐주셔서 현재는 NHN 개발자로 재직 중에 있습니다. 저는 멘토링을 하면서 많은 도움을 받았고, 좋은 결과도 얻을 수 있었기에 F-lab 멘토링을 고민하고 있을 또 다른 개발자분들께 조금이나마 도움이 되고자, 저의 경험을 공유합니다. 목차 멘토링, 어떤 계기로 신청하게 ..
진행하고 있던 프로젝트가 기능 요구 사항을 어느 정도 구현하여서, 드디어 애플리케이션을 Dockerize 하여 Google Cloud Platform에 배포하였습니다. 축하해주세요! 🥳 이번 프로젝트에서 Docker를 처음 써보아서 힘든 점이 참 많았지만, 다양한 자료를 참고하여 성공적으로 배포하였고, 그 과정에서 겪었던 시행착오를 공유하고자 합니다. 제 글이 도움이 되어 더 빠르게 완성하시길 기원합니다! ※ 배포 환경 패키징: Windows 10, openjdk 10 배포: Google Cloud Platform, Cent OS 7 목차 Overall Structure 프로젝트 배포용 파일 생성 Docker Desktop 설치 및 Dockerfile 작성 Docker 이미지 생성 및 Docker hub..
스프링 MVC를 통해 처음 스프링을 접하면서, 굉장히 혼란스러웠던 기억이 납니다. 의존성 주입, AOP, PSA, Application Context 등 스프링을 구성하는 방대한 용어들이 쏟아지니, 초심자 입장에서 쉽지 않았던 경험이었네요. 그중에서도, 유독 이해가 되지 않던 것이 DispatcherServlet이란 친구였습니다. DispatcherServlet의 작동원리니, FrontController니 하는 일련의 개념들에 대해서는 각각 이해할 수 있어도, 그래서 DispatcherServlet이 왜 존재하는데?라는 의문은 항상 남아있었습니다. 최근에 Servlet을 자세히 공부하면서, 왜 스프링 MVC가 DispatcherServlet을 사용하는지 이해하게 되었고, 그 이유를 아래와 같은 짧은 문장..
이번 포스팅에서는 스프링 캐시를 적용하면서 읽기 성능을 향상했던 경험을 공유하고자 합니다. 나름대로, 캐시란 무엇인가에 대해 정의를 내려보았습니다. 데이터의 실시간성을 약간 포기하고, 큰 성능적 이점을 얻는 것 물론 캐시는 이미 공식적인 정의가 존재하지만, 기존의 정의에서는 '실시간성을 포기한다'라는 trade off를 추론을 통해 알아내야 했기 때문에, 그 부분까지 확실하게 함께 담아 정리해보았답니다. 😄 그럼, 캐시를 적용하기까지 과정은 어땠는지, 어떻게 캐시를 통해 성능을 개선했는지 이야기해보도록 하겠습니다. 목차 캐시? Spring Cache Abstraction Local Cache vs Global Cache 캐싱 적용하기 캐싱 & 성능 확인 캐시? 위키백과에서 찾아본 캐시의 정의는 다음과 같..
우리가 개발하고 있는 서비스는 어느 규모까지 성장할까요? 우리가 개발하고 있는 서비스는 얼마나 많은 사람들이 사용하게 될까요? IT 서비스를 개발한 경험이 있는 사람이라면, 위와 같은 질문을 한 번쯤은 던져볼 수 있을 것이라 생각합니다. 그럼, 질문에 대한 답은 무엇일까요? 조금 허무하시겠지만, 저는 "아무도 모른다"라고 생각합니다. 당연한 거 아닌가요? 네 맞습니다.. 하지만, 그렇다고 해서 아무런 대책 없이 일단 만들어보자!! 하고 서비스를 개발했다가 좋은 일이 생겨 서비스의 규모가 커지고 많은 사람들이 이용하게 된다면, 담당 개발자는 마냥 웃을 수는 없을 겁니다. 어쩌면 퇴사를 진지하게 고민할지도... 동일한 서비스를 제공하는 시스템이라 할 지라도, 규모가 큰 서비스와 규모가 작은 서비스는 다방면에..