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 호출 테스트를 손쉽게 수행할 수 있..