![]()
사내에서는 URI에 경로를 포함하는 방법으로 개발이 되어있었는데 팀원분과 REST API 버전 관련하여 말하다 보니REST API 특성상 URI에는 자원을 표기하는 것이지 버전을 표기한다는 점에서 어색함이 들어서 시작이 되어 정리가 필요해 보여서 정리를 하고자 한다. REST API 버전을 표기하는 방법으로는 대표적으로 4가지가 있다.1. URI 경로에 표기하는 방법 GET /api/v1/call@RestController @RequestMapping("/api") @RequiredArgsConstructor public class HelloController { private final NewVersionService newVersionService; private final OldVersionServ..
![]()
개발 환경에 따라 API 엔드포인트들이 변화될 수 도 있어 이에 따라 환경분리가 필요하다. .env 파일 Next.js는 .env 파일을 가지고 분리를 한다. NEXT_PUBLIC_XX이라는 Prefix를 가지면 클라이언트 쪽에 환경이 공유된다. *.env.development : next dev의 기본값 *.env.local : 우선순위가 가장 낮은 환경설정 .env.production : next build의 기본값 예시 ) API 주소를 분리 # .env.local NEXT_PUBLIC_API_BASE_URL=http://localhost:8080/api # .env.development NEXT_PUBLIC_API_BASE_URL=http://192.168.0.1:8080/api # .env.pr..
![]()
개요 useState의 대체 함수입니다. (state, action) => newState의 형태로 reducer를 받고 dispatch 메서드와 짝의 형태로 현재 state를 반환합니다. (Redux에 익숙하다면 이것이 어떻게 동작하는지 여러분은 이미 알고 있을 것입니다.) 왜? 기존의 상태관리를 useState를 활용하여 작성하였다 set... 이런 느낌의 함수는 뭔가 괴리감이 느낀다고 개인적으로 생각된다 맹목적으로 값을 셋팅하는 느낌 나중에 복잡성을 해결하기 위해선 useReducer의 도움이 필요할꺼 같다. 또한, 성능 최적화에도 도움이 된다 예시 const initialState = {count: 0}; function reducer(state, action) { switch (action.ty..
![]()
생존형 AWS 프리티어 EC2 유저로 살아온 인생... EC2 프리티어 메모리는 1GB이다. 젠킨스를 도커에 올리는 순간 메모리가 700mb 정도 차서 웹서비스를 구동할 수 없는 상황에 처하여 스왑처리에 대해서 고민하게 되었다. swap 메모리란? > 실제 메모리 Ram이 가득 찼지만 더 많은 메모리가 필요할 때 디스크 공간을 이용하여 부족한 메모리를 대체할 수 있는 공간이라고 하겠다. amazon Linux (센트 OS기반) 설정 1. 스왑 파일 생성 bb는 볼륨 사이즈 count는 볼륨 카운트 sudo dd if=/dev/zero of=/swapfile bs=128M count=16 2. 스왑 파일에 대한 읽기 및 쓰기 권한을 업데이트 sudo chmod 600 /swapfile 3. Linux 스왑..
![]()
Stream을 종결 연산자 이후에 재사용을 하면 IllegalStateException 발생 된다. List list = List.of("2", "4"); Stream stream = list.stream(); stream.count(); //종결 연산자 count 이전에 수행하여 예외가 발생된다. assertThatExceptionOfType(IllegalStateException.class).isThrownBy(() -> { stream.collect(Collectors.joining()); }); 재활용을 위한 트릭 Supplier 클래스를 활용하여 새로운 스트림을 반환하여 처리한다. List list = List.of("2", "4"); //Supplier을 뽑고 Supplier streamSup..
![]()
그라파나 테스트 용으로 도커 컴포즈를 만들었다. 그런데 influxdb와 Grafana간의 버전 차이로 인하여 연동이 되질 않았다. "아래는 내가 맞춘 버전이지만 버전 업데이트시 체크 해봐야 할 듯?" version: "3.8" services: influxdb: image: influxdb:1.8.10-alpine ports: - "8086:8086" volumes: - influxdb-storage:/var/lib/influxdb environment: - INFLUXDB_DB=db1 - INFLUXDB_ADMIN_USER=sa - INFLUXDB_ADMIN_PASSWORD=pw chronograf: image: chronograf:latest ports: - "127.0.0.1:8888:8888" ..
![]()
사내 레거시 프로젝트가 Spring 4.1 환경이어서 Junit5를 이용하여 Spring 테스트를 사용할 수 없다. 4.3부터 누군가 작성하신 깃헙을 통해(https://github.com/sbrannen/spring-test-junit5) 가능 그리하여 Junit 4 환경의 셋팅을 진행. 의존성 설정 하기 Maven 기준 (pom.xml) Junit 4.X junit junit 4.13.2 test
![]()
불변 객체에 대해 정리해보는 시간을 가져보도록 한다. 대부분의 내용은 이펙티브 자바와, 다른 분의 블로그를 인용하였습니다. 왜 불변 객체를 사용해야 할까? 불변 객체는 스레드의 안전하다. 생성과 동시에 값이 할당되고 변경이 불가능한 객체임으로 기본적으로 스레드의 안전하다. 실패 원자적인 메서드를 만들 수 있다. 이펙티브 자바에 따르면 메서드에서 예외가 발생한 후 에도 객체는 메서드 호출 전과 똑같은 유효한 상태이다. (내부 상태를 변경한 적이 없으니 이를 만족한다. 부수효과를 방지 할 수 있다. 객체 생성과 동시에 값이 할당되어 상태에 대한 변경이 내부에서도 이루어지지 않기 때문에 변경에 따른 부수효과를 방지할 수 있으며 이 부분은 사용시점에 가독성과 안정성을 향상한다. GC의 성능을 향상할 가능성이 있..
사내 시스템 구축 중 리액트를 이용하여 3D 모델(glTF)을 활용하여 구축할 일이 초기에는 CRA(Create React App)을 이용하여 구성하다가 빌드 도구인 Vite를 발견하여 환경 구축을 정리하고자 한다. Vite? Vite는 “비-트”라고 읽으며 Dependencies(의존영역), Source code (소스영역)을 나누어 빠르게 빌드되게끔 문제를 해결했다고 한다. *자세한 내용은 해당 URL을 참조. (https://vitejs-kr.github.io/guide/why.html#the-problems) Dependencies 영역 기존 번들러는 JIT 컴파일 방식인 자바스크립트로 작성되어 있지만 Vite는 병렬처리에 유리한 Go언어로 작성된 Esbuild를 이용하여 빠른 번들링을 진행한다고..
![]()
Checked Exception, Unchecked Exception 언제 써야 할까? JAVA의 Checked Exception, Unchecked Exception(Runtime Exception) 두 사이의 Exception 중 과연 어떤걸 써야할지에 대해서 고민해보고 정리해보겠습니다. 생각 정리에 앞서 간단하게 분리를 해보겠습니다. Checked Exception Unchecked Exception 예외 처리가 필요한 예외 임으로 반드시 예외를 처리가 필요하여 try - catch를 강제적으로 수행하게 됨 예외처리를 강제하지 않는다. 컴파일 시점에서 검사 런타임 시점에서 검사 RuntimeException을 상속받지 않은 Exception RuntimeException 을 상속하여 만들어짐 언뜻 ..
![]()
첫 글이 테스트 코드라니 어려운 주제이다. 평소에 테스트 코드에 대해서 중요하게 생각하지 않고 코드를 작성해 왔었다. 최근엔 우아한 테크캠프 프로를 통해 테스트 코드에 대해서 인사이트를 얻어 앞으로 실천하고자 모범적인 테스트 코드에 대해서 정리해보고 내가 작성한 좋지 않은 테스트 코드 사례에 대해서 정리해보고자 한다. 모범 적인 테스트 코드 사례 정리 (출처 : https://docs.microsoft.com/ko-kr/dotnet/core/testing/unit-testing-best-practices) 단위 테스트를 하는 이유 기능 테스트 수행 시간 단축 ⇒ 기능에 대한 테스트 코드를 사용자가 일반적으로 애플리케이션을 열고 등의 행위를 통해 검사하지만 test runner를 통해 간단하게 검증할 수 ..
