일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | |||||
3 | 4 | 5 | 6 | 7 | 8 | 9 |
10 | 11 | 12 | 13 | 14 | 15 | 16 |
17 | 18 | 19 | 20 | 21 | 22 | 23 |
24 | 25 | 26 | 27 | 28 | 29 | 30 |
- ffi-napi
- react-native-dotenv
- npm package
- html
- github lfs
- custom printing
- adb pair
- ELECTRON
- vercel git lfs
- github 100mb
- Failed to compiled
- nextjs
- Each child in a list should have a unique "key" prop.
- animation
- 티스토리 성능
- adb connect
- react-native
- rolldown
- Git
- device in use
- silent printing
- 이미지 데이터 타입
- github pdf
- dvh
- augmentedDevice
- camera access
- camera permission
- Recoil
- electron-packager
- Can't resolve
- Today
- Total
목록전체 글 (337)
Bleeding edge
벌써 메셔에 들어온지 5달이 지났다. 첫 프로젝트를 마쳤을 때는 굳이 프로젝트에 대한 후기나 회고를 쓸 필요가 없는 것 같아서 노션에만 간단히 메모를 남겼었다. 하지만 두 번째 프로젝트가 끝났을 때 첫 번째 프로젝트가 끝났을 때 내가 부족했던 것과, 어떤 것을 더 개선할지를 메모하고 이전 프로젝트와는 다르게 잘한 것에 대해 메모할 필요가 있다고 생각했다. 첫 번째 프로젝트 Swalo 1. 개인적으로는 Nextjs가 익숙하지 않아서, Nextjs에서 지원하는 메서드들을 제대로 사용하지 못했었다고 생각한다. 2. 피그마대로 컴포넌트를 설계하다가 폴더관리에 실패했다. 3. DTO 변경이 생겼을 때 수정하는데 시간이 너무 오래 걸렸다. 2번은 리팩토링을 통하여 개선을 하였고 1번 같은 경우에는 처음는 부족했었지..
프론트와 백엔드가 원하는 것들이 완벽한 타이밍에 구현이 세팅된다면 이를 고민할 필요가 없겠지만, 개발은 항상 원하는 대로 진행되지 않는다. 지난번 프로젝트에서는 서버 dto가 변경되는 경우를 고려하지 않고 구현을 하여서, 서버 dto가 변경되는 경우에 많은 비용을 사용하였던 경험이 있었다. 이번에는 이 경험을 살려서 dto를 좀 더 flexible하게 코드를 짰기 때문에 dto 변경은 부드럽게 대응하였다. 하지만 특정 페이지의 정보를 서버에서 받아올 때 서버에서 구현이 안된 경우에 개발이 살짝 지연되었던 것이 아쉬웠었다. 아무래도 그 기간이 서버팀이 많이 바쁜기간이라 그랬던 것도 있었지만, 내가 api mocking을 쉽게 하였다면 좋았을 것 같다고 생각해서 axios로 간이 api mocking을 만드..
1. 사용할 배열을 선언한다. const promiseStringArray = ["string1", "string2", "string3"]; 2. 순차적으로 실행하기 위해서 reduce를 사용한다. 시작(initial Value)은 Promise.resolve()으로 시작한다 promiseStringArray.reduce(async(prev, current)=>{ }, Promise.resolve()); 3. accumulator에 체이닝 준비한다. const previousPromise = await prev.then(); 4. 비동기를 실행한다.(예시함수 이름을 func로 사용하였다) await func(current); 5. Promise로 체이닝을 건다. return Promise.resolve(..
분리가 필요했던 이유 package.json에 script와 process.env.NODE_ENV를 이용하여 production이나 development를 구분하는 방법도 있지만, vercel에서 배포를 하는 환경에서는 환경변수를 변경하여 사용하는 것이 편리하다고 생각하였고, 이번 프로젝트는 특히 서버에서 실행하는 알고리즘이 변경되는 일이 종종 있어서, production과 development는 그대로 유지하면서 local에서만 다른 알고리즘을 테스트 해보는 상황이 있었기 때문에 더욱 필요했다. Vercel 1. 수정하고 싶은 Project에 들어가서 Setting에 들어간다. 2. Environment Variables로 이동한다 3. process.env에서 사용할 Key와 Value를 입력한다. ..
예시 1. git commit을 마치고 push를 하는 순간에 hush에 의해서 push에 실패한 경우. 2. 혹은 로컬에만 남겨두고 push를 안한 경우 안되는 경우 로컬에 남아있고 아직 push를 안한 경우 git commit --amend --no-edit
https://www.lainyzine.com/ko/article/creating-ssh-key-for-github/
서론 개발자들이 협업을 하다보면 git conflict를 만나게 된다. 물론 정말 완벽한 순서대로 개발을 하면 문제가 안생길 수도 있지만 항상 완벽한 상황에서 개발을 할 수 있는 것이 아니기 때문에 이 글을 쓰게되었다. Rebase and merge를 사용하는 이유 Pull request를 받는데는 merge, sqush and merge, rebase and merge 세 가지 방법이 있다. 이 방법을 설명하기이 앞서 우선 conflict이 발생하기 위한 상황을 미리 가정해보자. 현재 git log 상황이 다음과 같다고 가정하자. merge는 F1, F2, M1, M2의 과정을 다시 합쳐주는 commit을 만들어준다. sqush and merge는 f1, f2에 대한 과정을 모두 없애고 suqush m..
https://korband.tistory.com/33 [#git] 여러 커밋(commit) 하나로 합치기 의식의 흐름(?)으로 개발을 하다보면 똑같은 커밋 메세지 또는 대충 쓴 커밋 메세지로 푸시하는 경우가 많다. 이런 경우 커밋 메세지를 하나로 합치거나 수정할 수 있으니 정신이 맑은 날에 한번 korband.tistory.com
에러 이미지 : 요약 : yarn.lock 에 문제가 생겼다. 해결 : package.json의 dependeny 관련 캐럿(^)들을 정리해주고, yarn install로 정리하자 참조 글 : https://stackoverflow.com/questions/63801444/error-your-lockfile-needs-to-be-updated-but-yarn-was-run-with-frozen-lockfil