2022년도 끝났다. 2022년은 개인적으로도, 회사에서도 많은 일들이 있었다. 아주 난이도가 높은(?) 한 해였던 것 같은데 그런 만큼 동시에 많은 것들을 느끼고 배울 수 있었다. 1년 전 회고를 쓸 때 블로그 글을 열심히 쓰겠다고 다짐했던 것 같은데 그 다짐은 딱히

함수형 프로그래의 핵심 중 하나는 description과 evaluation을 분리하는 것이다. description과 evaluation의 분리는 lazy evaluation을 통해서 이루어질 수 있는데, lazy evaluation이란 말 그대로 descriptio

회사에서 ZIO에 대해 소개하는 발표에서 활용했던 자료이다.https://docs.google.com/presentation/d/16vXtZPZ_7gNzMErHmAJ07BkQFqez3AI5TeU5cq4MqSY/edit?usp=sharing

지금까지 있었던 몇 차례의 글로벌 금융 위기들을 살펴보면서 현 금융 제도가 가진 모순점을 지적하고, 앞으로의 금융 위기는 어떤 식으로 전개될 지 예측하고 있다. 무엇보다도 현대의 금융 시장은 복잡계라는 것을 강조하며 파생상품과 레버리지가 판을 치고 있는 지금 syste

확신의 한 해

Wiki웹소켓(WebSocket)은 하나의 TCP 접속에 전이중 통신 채널을 제공하는 컴퓨터 통신 프로토콜이다. 웹소켓 프로토콜은 2011년 IETF에 의해 RFC 6455로 표준화되었으며 웹 IDL의 웹소켓 API는 W3C에 의해 표준화되고 있다.웹소켓은 HTTP와

agar.io 클론 코딩githubScalaAkka Http, Akka Stream, Akka ActorWebsocketspray-json유저는 하나의 원으로 표현되고, 큰 원이 작은 원을 잡아먹음으로써 크기를 키워나가는 게임두 원의 중심 사이의 거리가 큰 원의 반지름

kotlin + spring webflux + arrow 를 이용해 functional polymorphic한 architecture로 http server를 구축해보는 실습 코드입니다.githubspring webflux가 사용하고 있는 reactor framewor

Monad를 구성하는 기본수단이 unit과 flatMap이었다면, Applicative는 unit과 map2를 기본수단으로 하는 특질이다.applicative 특질은 그 이름이 시사하는 것처럼 unit + map2 말고도 unit + apply 를 기본수단으로 가지도록

Monad Functor가 map을 가지고 있는 자료 구조들을 일반화한 특질인 것 처럼, Monad는 unit과 flatMap을 가지고 있는 자료구조를 일반화한 특질이다. Monad 만들기 arrow의 kind를 이용해서 Functor를 만들었던 것처럼 monad

우리는 함수형 프로그래밍 패러다임을 지원하는 많은 언어에서 다양한 자료 구조에 대해 map 함수를 지원하는 것을 알고 있다. 이러한 이른바 "map 함수를 구현하는 자료 구조"를 일반화한 특질을 Fucntor라고 부른다.functor는 어떤 형식(type)에 대한 것이

깃헙 코드 바로가기하나의 모노이드는 다음과 같은 요소들로 구성된다.어떤 형식 AA 형식의 값 2개를 받아서 하나의 값을 산출하는 결합적 이항 연산 op.이 연산 op에 대한 한등원 zero.그리고 op는 아래와 같은 결합 법칙을 만족해야 한다.그리고 항등원 zero는

Property Based Testing(속성 기반 검사)이란 어떤 함수에 대한 테스트 코드를 작성할 때, 함수를 실행한 결과값을 기반으로 Assert를 하는 것이 아닌 그 함수가 가진 속성을 기반으로 Assert를 하는 테스팅 방식을 의미한다.예를 들어, List&l

본 책의 저자인 조영호님께서 쓰셨던 또 다른 책인 "객체지향 사실과 오해"라는 책은 내 생각에 불필요한 비유가 너무 많은 것 같아서 조금 읽다가 책을 덮었었는데, 이 책은 반대로 중요한 의미를 담고 있는 문장들을 밀도 있게 꾹꾹 눌러담은 느낌이었다. 같은 의미의 말을

아키텍처 설계와 관련된 내용들을 폭넓은 범위에 걸쳐 다루고 있는 책이다. 특히 기술적인 내용 이외에 비즈니스 아키텍쳐를 설계하는 방법에 대해 설명하는 부분도 존재한다. 기대했던 내용은 아니지만 유익한 내용이었던 것 같다. 다만 책이 쓰여진 지 시간이 좀 지났기 때문에,

내용 자체는 당연한 말들의 연속이었다. 하지만 그 당연한 것들이 모두 명확하게 머리에 들어있는 사람은 많지 않다. 모든 개발자들이 리팩토링에 대해 이것저것 떠들곤 하지만, 그들 중 대부분은 상당 부분 빈약한 근거에 의존한 막연한 원칙들에 따라 리팩토링을 하고 있을 것이

spring boot와 axon framework 환경에서 SAGA pattern을 활용해 분산 트랜잭션을 구현해보는 실습 코드입니다.모든 아키텍쳐가 그러하듯 MSA에서도 단점과 한계들이 존재하는데, 그 중 하나는 일련의 db access 작업에 대해 atomicity

이벤트 소싱은 영속 데이터를 어떤 식으로 저장할 것인지에 관한 것으로, 전통적인 데이터 저장 방법은 현실 세계의 것들을 직접적으로 표현하고 있는 도메인 객체(혹은 DB layer와 domain layer 사이의 간극을 해소하기 위한 DTO 객체)를 db에 담는 방식이었

멀티스레드 티켓 예매 서버 구현 프로젝트를 진행하면서 아쉬웠던 점들을 개선하여 low latency 서버를 다시 한 번 만들어보고자 한다.기존에 구현했던 WAS는 spring MVC를 이용해 만든 것으로, 순간적으로 많은 수의 요청이 들어왔을 때 비효율적으로 많은 스레

github 바로가기여러 독립된 프로세스에서 하나의 자원을 공유해야 할 때, 데이터에 결함이 발생하지 않도록 하기 위해서 분산 락을 활용할 수 있다. 분산 락을 구현하기 위해서는 데이터베이스 등 여러 프로세스가 공통으로 사용하는 저장소를 활용해야 하는데, 이번 실습에서