내 생각 행렬의 곱셈이 가물가물 했다. 어렸을 때 배웠던 걸로 기억하는데, 여하튼 행렬의 곱셈을 살펴보기로 하였다. 그림을 보니 예전 기억이 다시 돌아왔는데, 행렬의 곱셈에서는 특정한 조건이 있다. 바로 곱하려는 matrix1 의 행의 갯수와 matrix2 의 열의 갯수가 같아야 한다는 점이다. 위에 그림을 참고하면 무슨말인지 바로 이해할 수 있을것이다. 다행이도 프로그래머스 문제 조건에는 곱할 수 있는 행렬들만 인자로 주어진다고 한다. 그러니 이 부분에 대해서는 딱히 신경쓰지 않아도 될 듯 하다. 다만, 추후에 랜덤한 행렬이 오는 경우라면 조건을 걸어주어야 할 듯 싶다. 저번 문제의 실수를 하지 않기 위해, 시간 복잡도를 먼저 따져보았다. 각 행렬의 행과 열의 최대값은 100! 따라서 n = 100 이..
그냥 쉽게 풀려고 했는데, 생각대로 되지 않아 시간내에 푸는걸 실패했다. 이쯤되면 난 알고리즘에 재능이 없는것 같기도... 일단 계속 풀어보자 문제 https://school.programmers.co.kr/learn/courses/30/lessons/87390 프로그래머스 코드 중심의 개발자 채용. 스택 기반의 포지션 매칭. 프로그래머스의 개발자 맞춤형 프로필을 등록하고, 나와 기술 궁합이 잘 맞는 기업들을 매칭 받으세요. programmers.co.kr 첫 생각 처음에 문제를 제대로 이해하질 못했는데, 1행 1열 부터 i행 i열 까지라는 의미를 제대로 파악하지 못했다. 그런데 예제 코드를 통해 설명하는 부분을 보면서 의미를 알게 되었다. 예를 들어 i = 1 이라면 (1,0)(1,1)(0,1) 모두 ..
동기분과 함께 새로운 사이드 프로젝트를 진행하기 위해, repository 를 구성하는 과정에서 한번 front web 과 server 를 하나의 repository 에서 관리해보고자 하였다. 다만 현재 진행하려는 서비스가 monorepo 개념이 필요한 것인지는 의문이었으며, 조금 더 monorepo의 활용방안과 의의를 알기 위해 계속 공부중이다. 이번 포스팅에서는 간단하게 Nx 를 활용하여 초기 Next.js, Tailwindcss, React-query 를 세팅한 경험을 다루고자 한다. 조금 더 monorepo에 대한 개념이 잡힌다면 그때 monorepo에 대한 자세한 포스팅을 준비해야겠다. (왜 turborepo 대신 Nx 를 선택했는지부터..) Nx 의 workspace 를 생성하면서.. yarn..
지난 포스팅에서 SWR 을 사용하는 주된 이유인 캐싱에 대해 알아보았는데, 간혹 캐시 데이터가 화면을 렌더링 할 때 불편하게 작용할 때가 있다. 페이지에 따라서 캐시된 데이터가 아닌 최신의 데이터를 보여줘야 하는 경우가 있다. 이런 경우라면 지난 포스팅에서 알아보았듯 no cache, no store 설정을 통해 캐쉬화 되는 것을 막을 수 있다. 어떠한 페이지는 캐싱을 활용하는것이 훨씬 유리한 경우도 있다. 변화가 거의 없는 블로그 포스팅 글이나, 테이블의 페이지내이션 시 각 페이지별 데이터 들은 사용자가 수시로 확인하는 데이터이기 때문에, 확인할 때마다 데이터를 받아오는것은 손해라고 할 수 있겠다. 반면, 평소에는 캐싱이 유리하였다가 특정 이벤트 시 최신의 데이터가 필요할 상황이 있다. 즉, 즉각적으로..
사이드프로젝트(Closet)가 배포까지 완료되어, 이제 마무리 단계라고 생각할 때 쯔음 여러 의류를 저장한 다음 무한 스크롤을 시험해보려 하고 있었다. 데이터가 10개 이상은 저장되었어야 그 이상의 데이터를 저장한 다음 이제 목록 페이지로 이동하여 의류들을 살펴보려고 하는데, 이미지가 s3 에서 제대로 업로드 되지 않고 깨지는 현상이 발생했다. 오류를 살펴보니 502 gateway out. 특별한 코드 문제가 없는것을 보니 결국은 제 시간안에 이미지를 처리하지 못한다는 것인데, (pm2 monit 에서는 오류가 발생하지 않고) 무엇이 문제일지 잘 파악이 되질 않았다. 문득 front 인스턴스의 pm2 shell 속도가 급격하게 감소하는 것을 보고, 뭔가 front 인스턴스에 과부화가 생긴것은 아닐까 의심..
프로젝트에서 프론트엔드 부분을 담당하면서 작업을 이어가다 보면, 어느 순간 무한 스크롤 기능을 구현해야 하는 순간이 오게 된다. 아무런 방법을 모른다고 가정 할 때, 머리속에서 방법에 대해 떠올려보면 아마도 가장 먼저 생겨나는 방법은 웹 브라우저 내 스크롤바의 위치에 따라 데이터를 fetch 해오는 과정이 떠오를 것 같다. 물론 아닐수도 있지만 나는 그랬다.. 그야 아주 직관적인 방법이기 때문이다. 스크롤 바가 화면 맨 아래로 이동이 되었을 때, 그 순간 추가적으로 데이터를 가져오게 되면 그게 무한 스크롤이지 않을까. 브라우저에는 이렇게 스크롤 바의 위치를 표현해주는 API 를 제공한다. 이벤트에 구독하여 매 움직이는 순간마다 위치를 가져올 수 있는데, 이를 이용하면 충분히 직관적인 스크롤 이벤트를 구현..
수많은 사용자가 사용하는 웹 사이트가 있다고 가정해보자. 이러한 웹 사이트는 수많은 유저들에 의해 다양한 요청이 서버에 도착할 것이고, 서버는 이에 맞는 응답을 네트워크를 통해 전달할 것이다. 네트워크의 제한된 대역폭에 비해 출력량이 많아진다면 당연하게도 네트워크 지연이 발생하게 된다. 즉 대역폭 병목현상이 발생하게 된다. 물론 이벤트성 페이지에서 12시 정각에 상품 구매창이 열린다던지, 대학 수강신청과 같이 한 순간에 대량의 유저가 몰리는 경우와 같이 어쩔수 없이 지연이 발생하게 되는 상황은 지연이 발생할 수 밖에 없는 과정을 인정하고 이에 대한 해결책을 강구해야할 것이다. (이벤트 페이지의 구매창 클릭 버튼을 맨 밑에 위치시키는 등으로 급격하게 너무 쉽게 사용자가 몰리는 상황을 예방하는 방법도 있겠다..
저장하고자 하는 의류들의 데이터를 서버에 잘 저장하였다면, 저장된 데이터를 사용자에게 잘 보여주는 것 역시 중요할 것이다. 저번 포스팅까지 ItemForm.tsx 컴포넌트를 구현하면서 저장하는 add 페이지와 details 페이지에서의 데이터 수정 과정에 대해서 다루어보았다. 이제 실제 의류들의 목록을 유저에게 보여주는 페이지를 구상하기 위해(이를 앞으로 Store 페이지라고 하겠다) 코드를 작성하기 전 고려해야 할 부분들에 대해서 생각해보았다. 이번 포스팅은 고려했던 사항들 중 데이터에 대한 페이지네이션을 구현할 때 기존 offset 방식이 아닌 cursor 개념으로 접근하려 하였는지에 대해서 다뤄보고자 한다. 일정 수량의 데이터를 서버로부터 가져올 때 흔한 커뮤니티의 게시판을 생각해보면, 아래에 페이..
