PPAK

multipart/form-data multipart/form-data 는 http 를 사용해 데이터를 주고 받는 상황에서 하나의 body 에 여러 데이터를 넣어야 하는 경우를 구현하기 위해 만들어진 Content-Type 이다. (e.g 사진을 전송하는데 이에 대한 설명을 함께 포함해서 전송하고 싶은 경우에 사진은 image/jpeg 타입이지만, 설명은 text/plain 으로 전송해야 하는 경우, 웹브라우저 관점에서는 폼 데이터를 전송할 때 사용하는 Content-Type 이다) 위 사진은 HTTP Request 의 구조이다 multipart/form-data type의 데이터를 전송하겠다는 것의 의미는 ContentType 헤더 값으로 multipart/form-data 를 사용하는 것이고 body..

개인 프로젝트를 진행하면서 코드 변경 사항을 테스트, 빌드하고 빠르게 배포하고자 간단한 CI/CD 를 구축할 필요가 있었다. 파이프라인을 무엇으로 구축해볼까... 하다가 관성적으로 Jenkins 가 먼저 떠올랐는데, 살짝 지루할 것 같기도 했고 개념적으로만 이해하던 Github Actions 을 이번 기회에 직접 써볼까 해서 사용하게 되었다. 이번에 Github Actions 를 도입하면서 내가 확인해보고 싶었던 것들은 아래 두 가지고 1. Github Acitons workflow 작성 방법의 간결함 (-> 문법이 익숙하지 않은 동료들에게 설명하기 쉬운가) 2. Github Actions 을 통한 파이프라인(workflow) 구축 속도 및 확장성 (-> 파이프라인을 추상적으로 구축하기 쉬운가) 이것 외..

지난 포스팅 에서 Hazelcast 에 대해 간략히 알아보고 user-code-deployment 를 사용해 Distributed Computing 과정에서 발생하는 문제점을 해결했다. 그때는 팀에서 이미 구축해놓은 클러스터에서 작업을 진행 했었는데, hazelcast 에 대해 조금 더 깊게 알아보고 싶고 버전업도 할 겸 직접 클러스터를 배포해 보았다. v5.0 부터는 IMDG 가 아닌 hazelcast platform 으로 이름이 바뀌면서 이미지 내부 폴더 구조나 설정 파일, 클러스터 시작 방법 등등이 변경되었다. 개인적으로는 말 그대로 platform 의 의미를 살려서 hazelcast 중심의 생태계(손쉬운 배포부터 세부 설정 방법까지 제공, 플러그인 강화 등등) 를 구축해나가려고 하는 것 같았다. ..

작년에 이어 올해도 이 블로그에 23년 회고를 작성해보고자 한다. 지난 서두에서 그 어느 때보다 짧았던 2022년이라고 표현했는데, 그 말이 무색할 만큼 2023년은 너무 짧았고, 정신없던 한 해였던 것 같다. 2023년은 지난 날의 노력에 대한 작은 결실을 이룬 기념비적인 해이기도 하지만 그 과정에서 스스로 그 어느 때보다 불안했던 한 해라고 말하고 싶다. 2022년 톺아보기 그 어느 때보다 짧았던 2022년 한 해가 끝나간다. 오늘 졸프 최종 성과발표회가 끝나 찐종강을 하기도 했고, 올해 무엇을 했나 정리도 할 겸 어찌보면 고리타분할 수 있는 한 해 마무리를 주제로 ppaksang.tistory.com 졸업, 취업 올해 졸업을 했다. 본래 8학기 졸업을 하면 내년 2월이 되겠지만, 한 학기 당겨서 졸..

Spring Rest Docs 는 API 인터페이스를 손쉽게 만들기 위해서 사용하는데, Spring MVC Test 혹은 WebTestClient를 통해 생성된 파일(adoc 파일, snippets)을 조합하는 방식으로 수행한다. 비슷한 목적으로 Swagger를 사용하곤 한다. Swagger의 경우 프로덕션 코드에 Swagger 코드가 섞여 들어가는게 다소 부담됐고 변화하는 API 스펙에 맞춰 Swagger 코드 또한 수정해야 했었는데, Rest Docs는 테스트 코드를 바탕으로 문서가 생성되기 때문에 이러한 문제가 해결 된다. 즉, 테스트를 통과한 코드에 대해서 문서를 생성하기 때문에 잘못된 문서를 제공할 일이 줄어든다. 물론, Swagger를 사용하면 웹에서 API 호출 테스트를 손쉽게 수행할 수 있..

입사하고 시간이 얼마 안 지났지만 굉장히 다사다난(?)한 일들을 겪었는데, 그 중 하나가 조직 이동이다. 연말 회고에서 그 때의 심경을 남기겠지만 이번 포스팅은 그 과정에서 운이 좋게도(?) 새로운 프로젝트를 시작하면서 Spring Cloud Data Flow(SCDF) 구축한 내용에 대해서 남기고자 한다. 이전에 스트림, 배치 기반의 마이크로서비스 개발 경험이 없어서(이번에 처음 Stream, Task 개념에 대해 학습했다) SCDF가 기존의 비슷한 역할을 수행하는 솔루션들과 비교했을 때 얼마나 큰 효용이 있는지 체감 못했지만, 현재 사용하는 입장에서 느낀 편리한 점은 스트림/배치 파이프라이닝이 굉장히 편하고, 모니터링 구축이 용이하다는 것이다. 기본적으로 Spring Cloud Stream과 Bin..

지난 포스팅에서도 언급했듯 2023년도에는 현실적으로 운영 가능한 시스템을 구축하는 능력을 키우는데 초점을 맞췄다. 그 중 하반기는 탄탄한 시스템을 구축하기 위한 협업 방식을 습득하는데 집중했고, 이를 위해 프로그래밍 스킬 외에도 다양한 소프트 스킬을 키우기 위해서 노력했다. 특히, '내가 새로운 팀에 합류하게 되면 어떻게 잘 적응할 수 있을까' 라는 생각을 중심으로 고민했고 결과적으로 협업에 도움될 수 있는 보편적이고 포괄적인(기본이 되는) 능력을 키우고자 했다. 클린 코드는 이러한 포괄적인 능력을 키우는데 굉장히 적합한 책이라고 생각한다. 책의 앞부분에서는 클린한 코드를 작성하기 위한 여러 가지 패턴(단순히 코드를 작성할 때 주의할 점부터 클래스 작성법, 테스트, 예외 처리 방법까지)을 소개하고, 뒤..

'XXX를 어떤 단위로 분리하지?' 와 같은 자문을 프로젝트를 진행하면서 많이 했었다. XXX는 프로젝트가 될 수도, 패키지가 될 수도, 도메인, 클래스가 될 수 있는데 대게 도메인 모델과 작성한 클래스를 어떤 기준으로 분리할지에 대해 자주 고민했던 것 같다. 마침 팀에서 진행하는 스터디에서 평소에도 읽어보고 싶던 DDD 관련 책을 읽는다고 해서 참여하게 됐고, 약 2달에 걸쳐 책을 읽은 내용을 정리해 보고자 한다. 먼저 최범균님의 '도메인 주도 개발 시작하기' 책은 개발을 시작한지 얼마되지 않은 나도 이해하기 쉬울 정도로 가벼운 예제 + 자세한 설명을 제시한다. 특히, Java 베이스의 Spring과 JPA를 함께 사용하는 개발자들이 이해하기 쉬운 예제들을 많이 포함하고 있다. 책에서는 OOP를 중심으..

이번 포스팅에서는 Hazelcast를 프로젝트에서 사용하면서 정리한 내용을 간단하게 적고, 내가 겪은 Hazelcast 관련 문제에 대한 상황과 해결(?)한 방법을 설명하고자 한다. 본 포스팅에서는 Hazelcast 환경을 구축하는 방법, 클러스터를 배포하는 방법을 다루지 않는다. Hazelcast는 IMDG를 지원하는 분산 메모리 시스템이다. Redis 역시 클러스터링 기술을 통해 IMDG를 지원하지만 대용량 트래픽 환경에서 Hazelcast가 더 유리한 점이 많다고 한다. (아래 특징을 통해 확인) 다만, Redis에 비해 늦게 출시되고 사용자가 적은탓인지 레퍼런스가 매우 부족했고, 공식문서를 살펴보며 대부분 개발했다. 아래에 자료조사를 통해 얻게된 Hazelcast의 특징에 대해서 기술하겠지만, 내..

객체지향의 사실과 오해는 약 2달, 오브젝트는 부록을 포함해 약 600페이지 가량의 오브젝트 책을 5달에 걸쳐 다 읽었다. 중간에 다른 일들이 바빠져 2달 정도는 쉬었지만 아무튼 정말 많은 내용을 담고 있는 책 두권을 어찌저찌 한번 읽어봤다. 객체지향의 사실과 오해는 책이 얇기도 하고(읽고 나서 시간이 지나 내용을 까먹기도 했고) 가볍게 읽을 수 있어 두번 읽었다. 오브젝트를 선택한 계기는 '객체지향의 사실과 오해' 책을 읽고 나서 더 디테일한 코드 레벨의 관점을 '오브젝트'에서 얻을 수 있겠다고 생각했기 때문이기도 하고 여전히 올바른 객체지향 프로그래밍이 무엇일까에 대해 다른 사람들의 이야기가 더 궁금했던 이유도 있다. 객체지향의 사실과 오해는 작년 중순(22년 8월)쯤에 처음 읽었는데, 당시에 자바로..