1.rfce를 통해 편하게 컴포넌트 생성을 할 수 있었다.
확장프로그램이 필요하지만 이미 설치되어 있었는데
이런 기능등에 대해서는 모르고 있었다.
큰 시간을 단축해 주는 것은 아니지만
이런 기능들을 사용하면 여러개의 컴포넌트를 생성할 때
조금 더 편하게 만들 수 있다.
2.이미지 파일을 등록할 경우 서버에 등록하면 점차 서버에 부담이 있을 수 있기 때문에 외부 저장소를 이용하는데
Naver Cloud에서 제공하는 Object Storage가 유용하다.
3.upload를 사용할 때 저장소의 디렉토리 위치를 지정하고 싶은 경우 function 을 통해 매개변수를 지정한 다음 bucket부분을 대체해 줄 수 있다.
4.ACL이라는 기능은 사용자 조건등에 대해 설정하는 부분인데
private, public-read, public-read-write,authenticated-read 등이 있다.
로그인을 통한 회원 데이터를 개인별로 보여주고 싶은 데이터의 경우 authenticated-read로 데이터 접근을 지정할 수 있을 것 같다.
upload 함수를 기왕 만드는 김에 매개변수로 경로뿐만이 아니라 acl등 몇가지 설정을 함께 지정한다면 더 유연하게 사용할 수 있을 것 같다.
(자유게시판 / 개인정보 수정 등의 조건별 제한 설정)
5.DB uri와 key 등은 따로 관리해야 하는데
config폴더를 따로 생성한 다음 key에서 조건에 따라
dev / production 둘 중 하나의 상태로 분기하여 import 해서 사용한다.
또한 외부에서 key가 필요할 경우에는 config폴더의 key.js를 호출하는데
key.js에서는 위에서 분기한대로 배포중이면 production.js를
배포중이 아니라면 dev.js파일을 호춣해 넘겨준다.
이 파일은 .gitignore를 사용해 관리해줘야 한다.
6.git init을 통해 관리하고 싶은데 오류가 날 경우
하위폴더에 이미 git이 들어있는 경우가 있을 수 있으니 숨김폴더를 확인 후 삭제해야 하며
그래도 문제가 발생한다면 git config core.autocrlf true 후 commit을 하면 된다고 한다.
7.Redux는 state를 props로는 관리하기 복잡할 때 사용한다.
일반적으로 몇개 안되는 컴포넌트간의 이동에는 문제가 없지만 props drilling 문제 때문에 5게층 이상의 drilling 현상이 일어날 경우 사용하는 것을 권장하고 있으며 여러개의 상태를 마구 흩뿌리며 사용해 혼란이 있을 것 같은 경우에도 사용하는 것이 좋다.
redux, mobX, React.Context, React Query, Zustand, Recoil 등 여러가지 기능들이 있지만(mobX는 실제 사용하는 것을 보지는 못했다) 아직까지는 redux 또는 react query를 주로 사용하며 redux의 사용이 더 많은 것으로 보인다.
사실 Zustand를 사용할 경우 상태관리가 더 쉽다고 생각되지만 유지보수에 러닝커브도 들어가기 때문에 기존에 사용하던 상태관리를 이용하는 것이 유리한 것 같다.
React.Context는 처음 접했을 때는 Redux와 조금 유사한 느낌을 받았지만 대규모로 사용할 경우 리렌더링에 문제가 생길 수 있어 학습을 할 때는 제외하고는 들어보지도 못했다.
Redux를 그냥 사용하기에는 러닝커브가 있기 때문에
조금 쉽게 사용하기 위해 Redux-toolkit을 이용할 수도 있다.
React와 CRA의 관계처럼
조금 더 Redux의 접근성을 쉽게 하기 위한 표준형이라고 볼 수 있다.
8.Content-MD5 헤더는 콘텐츠의 변질 여부를 판단하기 위해 바디와 같은 형태의 인코딩을 진행해 전송하고
수신할 경우 바디와 같은 조건으로 디코딩해 MD5의 결과를 확인 후 데이터의 변질여부를 판단할 수 있다.
다만 암호화를 통해 내용을 변경한 것일 뿐 추가적 조치를 적용하지 않았기 때문에 암호가 노출될 경우 중간에서 탈취 후 변조한 내용을 전송해도 감지할 수 없다는 문제점이 있다.
(전송의 에러는 발견 가능하지만 해킹에는 동작하지 않는 검증법)
9.Content-Range(담긴 리소스의 범위(분할전송을 요청받은 경우), Content-Type(미디어 타입), Expires(만료일), Last-Modified(최근 수정일) 헤더들은 이름만 봐도 식별이 가능하듯 담긴 데이터의 정보를 나타낸다.
10.Set-Cookie를 통해 쿠키를 전달할 수 있는데
NAME - 이름
Expires - 만료기한(기존 쿠키 삭제는 불가능해 덮어씌우기로 처리한다)
Path - 경로(보안적인 면에서 효능은 없다)
Domain - 지정하지 않는 것이 좋다.(후방일치속성)
Secure - 보안을 위해 https에서만 답장하는 속성(미지정시 http도 가능)
HttpOnly - http/https가 아닌 웹페이지로만 조회가 가능한 속성이다. XSS등의 탈취를 막기 위해 설정한다.
11.다익스트라(Dijkstra) 알고리즘은 특정 경로까지의 최단 경로를 탐색할 때 사용된다.
일반적으로 dp를 이용하는데 꼭 dp라고 하기 보다는
메모라이제이션을 쓴다고 봐도 될 것 같다.
진행 방식은 시작점을 제외한 모든 경로상의(존재하는) 정점들의 거리를 무한대 또는 최대치보다 높게(Infinity가 편하다) 잡은 다음 해당 경로까지의 거리를 현재 저장된 값과 비교하며 Math.min처리를 하는 방식으로 진행한다.
결론적으로 가장 짧은 거리의 이동으로 도착할 수 있는 경로의 이동거리가 마지막에 저장되며, 이동구간을 구하고 싶은 경우에는 비교를 통해 min으로 교체될 경우 교체된 값의 이전 정점을 새로운 배열 또는 객체에 현재 정점과 매칭시킨 후 도착지점에서부터 역순(배열)으로 내려가거나 도착지점에서부터 꼬리물기 식(객체)으로 도착지 -> obj(도착지) -> obj(obj(도착지)) 처럼 시작점이 나올 때 까지 조회하는 방식으로 찾을 수 있다.
인접 행렬은 언제나 O(N^2)의 시간복잡도를 가지며
인접 리스트는 O(NlogN)의 시간복잡도를 가진다.
주의사항으로는 거리를 구하는 문제이기 때문에 간선의 값은 양수여야 한다.
(1).백준 2935번 소음은 제목과 상관없는 덧셈 및 곱셈 처리에 대한 문제였다.
다만 input을 수식형태로 넘기는 것이 아니라 숫자, 식, 숫자가 각각 줄로 분리되어 있어 문자열 처리가 필요하고 숫자의 크기는 각자 100억^10 크기이기 때문에 고민할 필요 없이 BigInt를 사용해야 헀다.
다행히 기호는 +, *밖에 없기 때문에 if문을 통해 출력했다.
let input = `10000
+
10`.split('\n')
if(input[1] === '+'){
console.log(String(BigInt(input[0])+BigInt(input[2])))
}
else{
console.log(String(BigInt(input[0])*BigInt(input[2])))
}

'회고' 카테고리의 다른 글
| [취업준비일지] - 17 (1) | 2022.11.06 |
|---|---|
| [취업준비일지] - 16 (0) | 2022.11.05 |
| [취업준비일지] - 14 (0) | 2022.11.03 |
| [취업준비일지] - 13 (0) | 2022.11.02 |
| [취업준비일지] - 12 (0) | 2022.11.01 |
