🎄 성장일지 3.1

책 행복한 이기주의자(웨인 다이어)의 내용에 자극받아 시작하는 소박한 성장기록

살아있는 꽃과 죽은 꽃은 어떻게 구별하는가?<br/> 성장하고 있는 것이 살아 있는 것이다.<br/> 생명의 유일한 증거는 성장이다!

🌳 키워드 (1.0)<br/> 최대한 간단하게 정리, 추후에 보면서 스스로 설명<br/> 🍉 경험 위주로 (2.0)<br/> 단순 정보를 전달하기보다 무엇을 배웠고 어떻게 해결했는지 짧고 간단하게 작성<br/> ❄️ 정해진 템플릿에 맞춰서 (3.0)<br/> 키워드, 경험 모두 좋다. 다만 매일 작성하기로 마음 먹은만큼 핵심만 간결하게 정리할 수 있게 템플릿을 작성 (3.1) 230102부터 시작되는 학습에 관한 내용 추가

🔑 오늘의 키워드

git

• 형상 관리 도구(=버전 관리 시스템) 중 하나
• 개발자의 자산인 소스코드를 효과적으로 관리할 수 있게 해주는 무료, 공개 소프트웨어
• SVN보다 많은 장점이 있어 요즘엔 거의 Git을 사용한다.
  • SVN(=SubVersioN): 중앙 서버에 소스코드와 히스토리를 저장
  • Git: 소스코드를 여러 개발 로컬 PC와 저장소에 분산해서 저장
• Git은 인터넷 연결이 되지 않더라도 로컬에서 버전관리가 가능하다.

commit

• 버전(의미있는 변화)을 기록하는 명령어
• 작업이 완결된 상태에서 커밋한다.
• 규칙적이고 가독성 있는 커밋 메시지는 개발자의 생산성을 올려준다.
  • 즉, 깃 커밋 컨벤션을 꼭 확인하고 습관을 들이도록 하자.
  • 또한, 커밋 메시지는 한 줄이 넘어가지 않게 한다. 그만큼 작업의 단위를 잘 나눠서 커밋을 관리해주는 게 좋다.

pull request

• upstream - origin - local의 관계에서 local에서 코드를 수정하고 origin에 push한다. 이후 이 변경사항을 upstream에도 반영하고 싶다면 Pull Request를 날린다.
• 즉, 내가 수정한 좋은 코드가 있으니 내 branch를 가져가서 검토 후(코드리뷰도 가능) 병합해달라고 요청하는 것이다!
• PR을 통해 코드 충돌을 최소화하고 push 권한이 없는 오픈 소스 프로젝트에 기여할 때 많이 사용한다.

file

• 컴퓨터 등의 기기에서 의미있는 정보를 담기 위한 논리적인 단위
• 저장매체에 대해 추상화된 정보 단위이다.
• 운영체제는 파일 조작에 관련된 기능을 api로 제공한다.
• 아래와 같이 nodejs에서도 file system을 다루는 라이브러리를 제공한다.

const fs = require('fs'); // fs: file system
const fsPromise = require('fs/promises'); // fs와 유사한데, 값들이 주로 promise 객체로 반환된다.

SHA

• Secure Hash Algorithm의 약자로 서로 관련된 암호학적 해시 함수들의 모음이다.
• 이 중 SHA-256은 메시지, 파일, 데이터 무결성 검증 등 널리 사용되고 있다.
• SHA-256은 SHA-2에 속하고 변환을 원하는 문자들을 256 bit 길이의 key로 변환한다.
  • 즉, 변환된 256 bit 형태가 key가 되고 원래의 문자가 value가 되는 Map 형태를 취한다.

zlib

• C로 작성된 데이터 압축 라이브러리
• nodejs에서도 zlib 라이브러리를 제공한다

참고

• Git document
• nodejs - zlib

📝 요약 및 하루 간단 회고

오늘은 깃에 대해 배웠다. 사실 그동안 어느정도 깃을 사용할 줄 알고 있다고 생각했다. 오만이었다. 평소에 잘 사용하지 않던 fetch, rebase나 upstream - origin - local과 같은 레포지토리들의 관계를 제대로 새길 수 있었다. 또, upstream과 origin의 충돌을 방지하기 위해 upstream에서 local로 먼저 fetch, rebase를 진행 하고 이후에 local에서 origin으로 push하여 upstream과 origin의 안정된 동기화를 가져가는 방식이 흥미로웠다.(사실 그 동안은 그냥 local 작업하고 origin으로 push하고 upstream에 PR 날리는 식으로 진행했는데...) 확실히 이렇게 하면 원격 레포지토리들 간의(upstream과 origin) 충돌 위험을 줄일 수 있게 된다. 이 flow를 꼭 기억하도록 해야겠다.

오늘의 잘한 점

• 최대한 미션 구현한 점
• 나무보다 숲을 보듯이 fork부터 add, commit, push 그리고 fetch, rebase 등의 흐름을 이해한

오늘의 아쉬운 점

• 오늘도 마찬가지로 계획에 적힌 전부를 다 하진 못했다.
• 요즘 이 부분이 조금 고민된다. 딱 할 수 있는 것들로만 계획을 짜는 게 좋을지, 최대한 많이 담아두고 거기에 나를 맞춰서 되는 데까지 달려갈지 쪼끔 고민된다.
• 헌데 사실 2가지 방법 모두 흥미롭게 행복하게 열심히 임한다면 각각의 좋은 시너지가 있는 것 같다.
• 둘 다 해보자, 그냥! 그리고 나에게 좀더 잘맞는대로 발전시키자.
• 일단 지금까지 최대한의 계획을 짜봤으니, 이제 내가 정말 현실적으로 해낼 수 있는 정예 계획들을 짜봐야겠다. :)

undefined