개발하는 리트리버

요약

1. TODO 관리 vscode extension Todo Tree

2. 이용해서 문서화 하기

서론

작업을 하다가 당장에 작업을 더 진행할 수 없거나, 어쩔수 없는 사정으로 임시 조치를 하고 넘어가야할 상황이 있다.

우리는 이럴때   // TODO :::  api 연동하기   와 같이 주석을 남겨서 나중에 처리할 일에 넣어둔다. 

그리고 나서 코드 검색에서 TODO 텍스트를 검색해서 있는지 없는지를 확인할 수 있겠지만, TODO 리스트 내역들을 따로 볼 수는 없다. 이에 vscode extension 을 이용해서 TODO를 관리해보려고 한다. 물론 Cursor에서도 동일하게 사용 가능하다.

설치

extension 쪽에서 Todo Tree 를 검색하고 설치해준다.

적용 확인

화살표를 클릭해서 TODOs 를 클릭해주면 현재 프로젝트에 작성되어있는 TODO를 정렬해준다.

추가 적으로 햄버거 버튼을 클릭해서 보기 설정을 바꿔주면 더 깔끔하게 TODO 내역들을 확인할 수 있다.

문서화

회사 업무를 하다보면 TODO 내역들을 관리해야할 필요성이 있다. 위에 내용들을 일일이 타이핑해서 작성하는 것은 하수들.

프로출신들은 한번에 문서화를 끝내버린다. command + shift + p 를 눌러서 Todo Tree: Export Tree 를 클릭하면 깔끔하게 TODO 리스트를 텍스트화 시켜준다.

오늘도 최고의 프러덕트를 위해.

편한 노드 버전관리

여러 프로젝트를 넘나들다보면 node 버전이 문제가 될 때가 있다. 시간이 오래걸리는 문제는 당연아니다.

프로젝트를 실행시키거나, 커밋을 날렸을때 노드 버전관련 이슈가 나오면 "아.." 정도 한탄 한번 해주고 버전을 변경해주면 된다.

이를 단순화 시켜주는 방법이 .nvmrc 파일을 사용하는 것이다.

프로젝트 내에 해당 파일을 만들고 버전을 지정해주면 (ex 20.16.0), nvm use 명령어 하나로 해당 노드 버전으로 변경해준다.

하지만.

노드 버전 찾고 변경하고 하는것보다야 편해졌지만 프로젝트를 변경할때마다 명령어를 쳐줘야만하니 묘하게 거슬린다.

이 또한 자동화 시킬 수 있다면 얼마나 편해질까? ㅇㅈ?ㅇㅇㅈ

이미 프로출신들은 아주 편하게 자동화 시켜놨다는것..

이는 .zshrc 파일에 특정 코드를 추가해줌으로써 달성할 수 있다.

uvm use 자동화 시키기

vim ~/.zshrc 로 파일을 열어주고 아래 코드를 추가해 준다. 

뜬금 zshrc 나만의 팁이 있다면

1. 해당 파일에 생각보다 추가되는 코드가 많기에, 코드를 추가할때 #를 활용해서 추가되는 코드 상단에 내용을 추가해주면 나중에 확인이 편하다. 많아지면.. 이걸 왜추가했는지 기억이??

2. #THIS MUST BE AT THE END OF THE FILE FOR SDKMAN TO WORK!!! 이 위쪽으로 추가할것 ㅎ

코드는 아래와 같다.

# auto nvm use
autoload -U add-zsh-hook
load-nvmrc() {
  local node_version="$(nvm version)"
  local nvmrc_path="$(nvm_find_nvmrc)"

  if [ -n "$nvmrc_path" ]; then
    local nvmrc_node_version=$(nvm version "$(cat "${nvmrc_path}")")

    if [ "$nvmrc_node_version" = "N/A" ]; then
      nvm install
    elif [ "$nvmrc_node_version" != "$node_version" ]; then
      nvm use
    fi
  elif [ "$node_version" != "$(nvm version default)" ]; then
    echo "Reverting to nvm default version"
    nvm use default
  fi
}
add-zsh-hook chpwd load-nvmrc
load-nvmrc

 위 코드를 추가해주고 :wq 로 저장후 나와서 source ~/.zshrc로 적용시켜주면 완료!

후에 .nvmrc 파일이 있는 프로젝트를 열면 아래와 같이 자동으로 적용되는 것을 확인 가능하다.

터미널을 탐방중 루트에 올라가 보면 내가 따로 만든적은 없는 파일들이 많이 보인다.

bin, sbin, tmp...  파일 제목만으로는 무엇을 담고있는지 감이 오지는 않는다.

그런데 생각 보다 친숙한 것들이 파일들에 있다. 이중 오늘은 bin 에 대해서 살펴보자.

저 위에 bin 폴더는 하나밖에 안보이지만, bin 폴더는 생각보다 여기저기에 들어있다. OMG

/bin
/sbin
/usr/bin
/usr/sbin
/usr/local/bin
/usr/local/sbin

영어에 자신이 있다면, 아래 명령어를 입력하면 폴더들에 대한 설명을 볼 수 있다.

$ man hire

해당 명령어를 입력하면 각각의 폴더에 대해서 설명들을 볼 수 있다.

/bin/                user utilities fundamental to both single-user and multi-user environments
/sbin/              system programs and administration utilities fundamental to both single-user
                       and multi-user environments
/usr/bin/         common utilities, programming tools, and application
/usr/sbin/       system daemons & system utilities (executed by users)

/usr/local/       executables, libraries, etc. not included by the basic operating system

정의 자체는 위와 같고 이제 조금 더 깊이 들어가보자 (local 하위에 대한 설명은 없다ㅜ)

sbin

bin과는 큰 차이가 없지만, 사용시에 root 권한이 필요한 친구들이 들어있다.

가끔 명령어를 칠때 sudo.. 로 친적이 있을 것이다. 이런 루트 권한을 필요로 하는것이다.

그럼 bin만 알면 되겠구만!!

bin

폴더 안에 들어가보면 어떤 친구들이 들어있는지 바로 확인가능하다.

ls, kill, rm 등 간간히 사용했던 명령어들이 있다. 이렇듯 여러 사용자에게 기본적으로 필요한 기능들이 여기에 들어있다고 보면 되겠다.

정의로는 리눅스의 기본명령어들이 들어가있다고 볼 수 있겠다.

/usr/bin

여기는 엄청나게 많은 파일들이 있다. 익숙하지 않은 친구들도 있지만, vim, sudo 같은 친밀한 친구들도 여기에 포함된다.

ls, kill 그리고 sudo, vim은 다 비슷한 명령어 아니었던가? 뭐가 다르다고 이렇게 분류되어 있을까.

<GPT 피셜>

/bin 폴더에 있는 ls, kill 등의 명령어는 단일 기능을 수행한다. 폴더 열기, 죽이기 등.

하지만 /usr/bin 폴더에 있는 vim 명령어는 단일 기능보다는 확장된 기능을 제공한다. vim은 파일 열기 외에도 수정할 수 있는 플로우로 유저를 이동시켜주는것을 예로들 수 있겠다.

/usr/local/bin

여기는 사용자가 따로 설치한 파일들이 들어가있다.

따라서 기본적으로는 비어있고 설치한게 있다면 그때마다 추가가된다.

반가운 친구들이 보이는데 node, npm 등의 파일들은 추가로 설치했기에 여기에 위치하고 있다. 

turbo 는 모노레포를 사용시 많이들 사용하는 것중에 하나이다.

본인도 하나의 프로젝트에서 turbo를 잘 사용하고 있는데,

lock 파일을 업데이트 이후에 빌드중에 위 에러가 발생했다.

x Found `pipeline` field instead of `tasks`

문제없이 잘 되다가 갑자기 빌드가 실패하면 언제나 지끈거리는 머리다.. 하지만 위 에러는 그렇게 큰 노력(?)을 요하지는 않는다.

에러 그대로 수정만 해준다면 정상적인 빌드가 가능하다!

루트 폴더의 turbo.json 파일 수정만 가볍게 해주면 된다.

기존 turbo.json

{
  "pipeline": {
    "build": {
      "dependsOn": ["^build"],
      "outputs": ["dist/**"]
    },
    "test": {
      "dependsOn": ["build"]
    }
  }
}

현재는 'pipeline' 으로 되어있었지만 특정 버전 이전에는 'tasks' 로 값이 쓰였다고 한다. 

변경 후 turbo.json

{
  "tasks": {  // pipeline -> tasks
    "build": {
      "dependsOn": ["^build"],
      "outputs": ["dist/**"]
    },
    "test": {
      "dependsOn": ["build"]
    }
  }
}

해당 파일을 수정하고나서 turbo 빌드를 다시 실행시키면 정상적으로 빌드된다.

서론

브랜치를 새롭게 만들고나서 첫 git push를 하면 항상 같은 에러가 우리를 반겨준다. (또 너야?)

fatal: The current branch feature/order-agent has no upstream branch.
To push the current branch and set the remote as upstream, use

    git push --set-upstream origin {새로만든 브랜치 이름}

To have this happen automatically for branches without a tracking
upstream, see 'push.autoSetupRemote' in 'git help config'.

이는 아직 우리가 만든 브랜치가 로컬에만 존재하기 때문이다. 때문에  Git에도 내 브랜치 만들고 거기다가 커밋을 날리는 명령어가 필요한 것이다. 해당 명령어는 git push 뒤에 --set-upstream origin {새로만든 브랜치 이름} 부분을 추가 하면 된다. 그래서 이렇게 나오면 저 명령어를 복사해서 커맨드에 붙여넣기해서 실행한다. 해결 방법은 이리 간단하긴 하다.

하지만 언제까지 이렇게 복붙하는 과정을 할것인가? 프로출신들은 그렇게 시간이 남아나지 않는다! 그냥 git push 명령어만 써도 알아서 만들어주는 세팅이 필요하다!!! (시간 부족 아니어도 은근 귀찮다)

해결책

 $ git config --global push.autoSetupRemote true

이렇게 git config에 해당 세팅을 추가해주면 앞으로 저 에러는 바이바이쥐~

이젠 한방에 에러없이 git에 올려버리.

맥과 같은 리눅스 계열의 터미널에서 사용하던 ls, 하지만 윈도우 명령프롬트에서 ls 를 사용하면 원하는 대로 작동하지 않고

" 'ls'은(는) 내부 또는 외부 명령, 실행할 수 있는 프로그램, 또는 배치 파일이 아닙니다."

라는 대답뿐이 우리를 기다리고 있다.

윈도우 명령프롬트에서 ls와 같은 기능을 사용하려면 dir 라는 명령어로 사용해야한다. 리눅스와 같은 명령어로  사용하려면 간단히 설정이 필요하다.

doskey {원하는 명령어} = {기존 명령어}

위와 같은 구조의 설정이 필요하다. 윈도우 명령프롬트에서 기존 명령어는 dir 이다. 기존 명령어인 dir을 ls 명령어로 사용하고자 한다면, 

$ doskey ls = dir

해당 명령어를 실행해주고 나서 ls 를 입력하면, 우리가 원하는 대로 가능하다!!!

위와 같은 설정을 이용한다면 ls 가 아니더라도 자기가 원하는 설정을 !? 물론 쉽게 까먹기 마련이니 ls 로 해두자..^^

추가적으로 clear 까지 살펴보자면, 

해당 명령어는 윈도우 프롬트에서는 cls 이다.

$ doskey clear = cls

위 처럼 설정해주면 clear를 통해서 명령 프롬트를 비울 수 있다~!

하지만 아쉽게도... 명령 프롬프트를 종료하고 다시 키면 해당 세팅은 초기화되서.. 다시 설정하거나 해야한다..

집에 있는 윈도우 컴으로도 작업 좀 해보고자 하니..  리눅스계열 짱짱

0. 서론

프로젝트 받고 가장 먼저 npm install, yarn 등을 통해 필요한 패키지들을 node_modules파일에 모은다.

보통 문제없이 잘 작동하기 때문에 node_modules파일 안에 있는 내용은 수정할 일이 별로 없다.

근데 만약에 node_modules 내부 코드에 문제가 있으면 어떻게 해야할까?

내가 사용하는 특정 버전에서 다른 모듈과의 호환성 문제가 되거나 하는 상황이 펼쳐진다면 어떻게 해야할까?

버전 사용 이전에 그러한 부분들을 미리 체크하고, 필요하다면 버전을 업그레이드 하는게 제일 최선의 방법일 것이다. 하지만 모든 상황에서 버전 업그레이드가 쉽지는 않다. 내가 접한 것은 react-native와 Xcode 버전간의 문제였다.

react-native의 버전을 최신으로 올려서 문제를 해결해라고들 하지만, 그러기에 react-native 버전이 기존에 너무 낮았기에, 이를 최신버전으로 업그레이드 하는건 배보다 배꼽이 더 커지는? 일이 되어버리는 것이다. 그러다가 찾은 하나의 빛이, node_modules에 있는 react-native에서 특정 파일을 수정하라는 해결책이었다. 특정파일을 수정하고나니 정상적인 빌드가 가능했다.

그런데.. 이를 git에 어찌 반영해야하는가..? node_modules을 앞으로 계속 다 올려...야 하나?? (말도안되는) 이럴때 우리에게 한줄기 빛이 되어주는 것이 바로 patch-package되시겠다.

patch-package는 node_modules 속 커스텀한 상황을 배포상태에서 반영할 수 있게 해준다. 

1. 설치

//package.json

"script" : {
	"postinstall": "patch-package"
},

위에 라인을 추가해주고 $ yarn i patch-package 를 통해서 다운로드 해준다. 그럼 사용할 세팅 준비는 끝이난다.

2. 사용

이제 node_modules  내에서 수정하고 싶은 파일을 수정해준다.

나의 경우 node_modules에 있는 react-native 폴더 안에 있는 특정 코드를 수정했다.

그리고 나서 아래 명령어를 추가해준다. 

$ yarn patch-package react-native(내가 수정한 라이브러리 이름) 

그러고 나면 루트 폴더에 patches라는 폴더가 새로 생기고 해당 폴더 안에 수정한 패키지에 대한 정보가 들어간다!!

이제 yarn 인스톨 시점에 자동으로 node_modules를 덮어쓰게 된다!! 이제 이 폴더를 git에 올려주면 모두가 같은 수정사항을 공유할 수 있게 된다. 올리기 전에 node_modules를 지우고 yarn혹은 npm install을 통해 반영이 잘되는지 한번 더 체크해주는 센스!

4. 결론

패키지 의존 문제가 생기면 해결되기까지 기다리거나 버전 자체를 바꾸는 등의 방법 외에도, 

의존성을 유지하면서 이렇게 직접 수정해서 사용할 수 있다. 좀 더 손쉽게 문제를 타파하는 대안이 될 수 있지 않나 싶다!

역시 Xcode랑 react-native는 친해지기 어렵다!

맥북 마이그레이션 이후에

일반 터미널에서는 문제가 없었는데,

visual studio code에서만 유독 위와 같은 문제가 발생했다.

compinit:480: compdump: function definition file not found

.zshrc:188: add-zsh-hook: function definition file not found

zsh brew로 재설치후

zshrc 파일에 compinit과 bashcompinit 부분을 추가해주고나니

해결완료!

export ZSH="$HOME/.oh-my-zsh"

ZSH_THEME="robbyrussell"

source $ZSH/oh-my-zsh.sh

autoload -Uz compinit
compinit

autoload -U bashcompinit
bashcompinit

export NVM_DIR="$HOME/.nvm"
[ -s "$NVM_DIR/nvm.sh" ] && \. "$NVM_DIR/nvm.sh"  # This loads nvm
[ -s "$NVM_DIR/bash_completion" ] && \. "$NVM_DIR/bash_completion"  # This loads nvm bash_completion

CRUD 정의

CRUD 는 약자로 아래의 함수(기능)을 의미한다.

Create

Read

Update

Delete

너무나도 쉬운 영단어로 되어있다.

이러한 기원은 데이터베이스에 있다고 한다.

이는 SQL에서는

Create = INSERT

Read  = SELECT

Update = UPDATE

Delete = DELETE

로 생각하면 된다. 

어떤 item에 대해서 CRUD개발, 이라고 한다면

해당 아이템을 만들고, 수정하고 지우기까지 하는 작업들을 의미한다고 보면 된다.

REST 정의

REST는 네트워크 애플리케이션 설계를 위한 아키텍처 스타일이며

HTTP 프로토콜이 사용된다. 

우리가 익숙한 GET, POST, PUT, DELETE가 여기에 포함된다.

둘의 차이점?

그럼 REST와는 차이 점이 있을까?

범위

CRUD는 4개의 기능(함수)을 이야기한다.

REST는 네트워크 리소스를 설계하고 상호 작용하는 방법을 정의하는 더 넓은 아키텍처 스타일이다.

작용범위

CRUD는 데이터 베이스와 작동한다.

REST는 HTTP 메서드를 사용하여 CRUD와 유사한 작업을 수행하지만, 네트워크 리소스의 맥락 내에서 이루어진다.

설계

CRUD는 데이터 작업에 중점을 두는 반면REST는 HTTP를 통해 클라이언트가 서비스와 상호 작용하는 방식을 설계하는 데 중점을 둔다.

둘의 비교 글이 좀 있기는 한데,

역할이나 범위, 정의를 생각해보면

 비교 대상이 아닌것 같다는 생각도든다.

참고 : https://www.logicmonitor.com/blog/rest-vs-crud

프로젝트별로의 설정을 해 둘 필요가 있다.

각자의 vscode 설정이 코드에 영향을 주어 

코드 일관성을 해칠 수 있기 때문이다.

vscode를 따로 설정하는 방법은 2가지 이다.

1. .vscode  직접 폴더 만들기

루트 폴더에 .vscode 폴더를 만들고

setting.json 파일을만들어준다.

그리고 { ... } 내부에 원하는 설정을 추가해두면 끝!

 2. 좀 더 쉽게 자동으로 .vscode 폴더 만들기

1번의 방법은 설정 하나하나를 찾아봐야하는 귀찮음이 좀 있다.

[command + shif + p]를 통해서

Open Settings (UI)에 접속한다.

그리고 User가 아닌 Workspace탭을 클릭해준다.

그러고 나면? 이제 하나하나 설정을 UI에서 변경해줄 때 마다 

루트 .vscode/setting/json 파일에 변경이 반영된다.,.!!

auto save 설정을 바꾸니 json파일에 자동으로 추가가 싸악~

이제 우리들의 프로젝트의 일관성 유지를 위해

설정을 하나씩 추가해주자!  이전 글에 있던 import 자동 정리가

하나의 예가 되겠다.

	"editor.codeActionsOnSave": {
		"source.organizeImports": "explicit"
	},

물론 이렇게만 적어두면 다른 사람이 뭔지 파악하기 힘들고 

설정한 사람도 시간이 지나서 무슨 내용인지 까먹을 수 있으니

아래 처럼 주석으로 옆에 표시하거나

settings-desc.json 파일을 별도로 만들어서 관리하는 방법도 있겠다.

	"editor.codeActionsOnSave": {
		"source.organizeImports": "explicit" // 저장 시 미사용 import 정리
	},