사건의 발단 CI / CD 자동 배포를 공부하던 중 Docker Image를 만들어야 했다. 그런데 분명 코드가 문제 없다고 생각했는데, /bin/sh: 1: [npm,: not found npm이 없다는 오류를 내는 거였따?! 분명 처음에 node를 From을 통해서 받아왔는데, 안될 이유가 없었다... 해결 FROM node:18.12.1 RUN mkdir -p /client WORKDIR /client ADD . /client/ RUN npm i RUN npm run build ENV HOST 0.0.0.0 EXPOSE 3000 CMD ['npm', 'run', 'start'] 뭐가 문제인지 보이십니까?! 정말 홀리 몰리한 문제였습니다. FROM node:18.12.1 RUN mkdir -p /cl..

지금까지 React Query에 대해서 공부를 했었는데, redux devTools은 있는 것을 알았는데, React-Query DevTools이 있다는 것은 방금(글쓰기 전 ㅋ ) 알아서 지금 추가로 정리하려고 글을 작성한다. 기본적으로 Dev Tools은 React-Query에서 기본적으로 제공하기 때문에 추가적인 패키지를 설치할 필요가 없다. 또한 Development 모드에서만 작동하고, Production 모드, 즉 배포 상태에서 제외 시키는 작업은 안해도 된다. import React from "react"; import ReactDOM from "react-dom/client"; import "./index.css"; import App from "./App"; import reportWeb..

문제 설명 숫자나라 기사단의 각 기사에게는 1번부터 number까지 번호가 지정되어 있습니다. 기사들은 무기점에서 무기를 구매하려고 합니다. 각 기사는 자신의 기사 번호의 약수 개수에 해당하는 공격력을 가진 무기를 구매하려 합니다. 단, 이웃나라와의 협약에 의해 공격력의 제한수치를 정하고, 제한수치보다 큰 공격력을 가진 무기를 구매해야 하는 기사는 협약기관에서 정한 공격력을 가지는 무기를 구매해야 합니다. 예를 들어, 15번으로 지정된 기사단원은 15의 약수가 1, 3, 5, 15로 4개 이므로, 공격력이 4인 무기를 구매합니다. 만약, 이웃나라와의 협약으로 정해진 공격력의 제한수치가 3이고 제한수치를 초과한 기사가 사용할 무기의 공격력이 2라면, 15번으로 지정된 기사단원은 무기점에서 공격력이 2인 무..

정말 많은 글이 있고, 많이들 알아보는 내용이다. 과연 이 둘의 차이는 어떤 것이 있을까? 프레임워크 ▶ 설계부터 코드 작성 스타일까지 모두 도구의 방식을 따라야 한다. ▶ 짜여진 프레임 내에서 작업하기 때문에 프레임워크이다. 라이브러리 ▶ 도구를 사용해서 생산성을 개선하는 것에 포커스가 잡혀있다. ▶ 인터페이스를 크게 제약하지 않는다. ▶ 전체 설계까지 영향을 미치지 않는 것이 보편적이다. 강제성 개발을 할 때 정해진 방식으로 개발을 해야하는지? 자유롭게 개발을 할 수 있는지? 제어권이 개발자에게 있는지? 툴에 있는지? 강제성에서의 차이가 있을 것이다. 그렇다면 내 블로그에 많이 올라오는 React는 라이브러리일까? 프레임워크일까? ▶ 자유도가 높으니 라이브러리이다! ▶ 홈페이지에 라이브러리라고 적혀있..

GitHub Actions? 소프트웨어 개발에서 Pull Request, Push 등 작업을 할 때 마다 자동화된 작업을 할 수 있게 해주는 기능이다. 자동화 작업을 하는 경우는 아래와 같다. ▶ CI / CD 이번에 하게되는 작업으로, 자동으로 Push 후 빌드를 해서 배포를 해주는 작업을 할 것이다. 프로젝트를 작업할 때 자동화를 시키면 매번 수동으로 배포하는 일을 할 필요가 없어진다. ▶ Testing Pull Request를 보내면 자동으로 테스트 하는 작업도 구현이 가능하다. 그래서 테스트 성공하면 PR을 Open 또는 Close가 가능하다. ▶ Cron Job 특정 시간대에 스크립트를 반복해서 실행할 수 있는 기능을 구현할 수 있다. GitHub Actions의 구성 요소 GitHub Acti..

들어가며 바로 어제 2주차 회고를 작성했는데 사실 이번주는 3주차이기 때문에 이어서 바로 3주차 회고를 하겠다 ㅋㅋ... Keep 확실한 피드백 ▶ 프로젝트를 진행하면서 아닌 것 같은 부분에 대해서 돌려 말하지않고 확실하게 의사 전달을 하였다. ▶ 돌려서 말하는게 당장의 관계에는 좋겠지만 전체를 봤을 때는 잘못 이해하거나, 더 많은 충돌을 발생시키는 것 같다. 기술 도입 ▶ 처음 사용해보는 기능을 바로 프로젝트에 도입할 정도로 공부해서 도입하였다. ▶ 하지만 아직 초반 단계여서 진행을 하다보면 부족한 점이 생길 수 있다. Problem 작업 속도 ▶ 약 6주간 진행하는 프로젝트인데 벌써 3주가 흘렀다. ▶ 하지만 생각보다 완성까지 시간이 걸리는 느낌이고, 초조함을 느껴 추후 리팩토링이 필요해보이는 코드가..

들어가며 변명아닌 변명을 하자면, 사실 회고는 지난주에 작성을 했는데, 내가 블로그에 올리는 것을 까먹고 있다가 지금 작성하게 되었다 ㅋㅋ.... ㅠ Keep 소통 ▶ 코드 리뷰를 열심히 했다. ▶ 피드백을 할 때, 착하게 하지 않게 피드백을 했다. 디자인을 해본 것 ▶ 디자인은 전혀 자신이 없어서 시도를 하지 않았는데, 이번에 팀에 디자인을 할 인원이 없어 내가 조금씩 수정하면서 해봤다. ▶ 로고를 만들었다. Problem 레이아웃에 시간이 너무 오래 걸렸다. ▶ 디자인에 신경을 쓰다보니 생각보다 페이지 레이아웃에 시간이 오래 걸렸다. 집중 ▶ 코딩을 할 때, 동시에 여러개를 신경쓰다보니 클린 코드에 신경을 못쓴 것 같다. 필요 기술에 대한 결정이 느림 ▶ 피드백에 대해서는 이제 필요하다고 생각되는 것..

앞서 비즈니스 로직에 대한 피드백을 받은 후 술먹은 듯한 게시글을 쓰고 다시 한번 비즈니스 로직에 대해서 공부를 해봤다. 멘토님께서도 너무 고민하고 있는 것이 눈에 보이셨는지, 본인이 생각하는 비즈니스 로직이란 특정 도메인에서 해당 도메인의 데이터를 중심으로 일어나는 서비스의 핵심 로직이라고 하셨다. 여기서 내가 생각하지 못한 단어가 등장했는데, 바로 도메인이다. 지금까지 비즈니스 로직을 알기 위해서 공부했을 때 디자인 패턴에서 사용하는 비즈니스 로직 등 자연스럽게 디자인 패턴으로 구분한 로직은 전부 비즈니스 로직이라고 생각했다. 하지만 도메인을 추가해서 검색을 했을 때는 전혀 다른 검색 결과가 나오게 되었다. 그래서 비즈니스 로직과 비즈니스 로직이 아닌 것으로 공부를 이어나갔다. 먼저 비즈니스 로직에 ..