준의 개발 공부

Bare-Git Repository를 이용한 dotfiles Migration

KwonPodo — Wed, 23 Nov 2022 22:18:45 +0900

BackLink: Bare-Git Repository란?

References

기본적인 틀은 dotfiles의 변화를 기록하는 Bare-Git Repo를 $HOME/.cfg 라는 사이드 폴더에 생성하여 $HOME 을 Workspace로 삼는 것이다.

그리고 해당 Bare-Git Repo들에게만 작동하도록 특별히 지정한 git aliases 들을 설정하여 다른 로컬 git 파일들에서의 작업에 지장이 가지 않도록 Workspace Configuration을 해준다.

사실 Bare-Git Repo 보다는 이 Workspace Configuration이 중요하다.
실제로 Non-Bare Git Repo도 Workspace Configuration만 동일하게 설정한다면 Bare-Git Repo와 동일하게 작동함을 확인할 수 있다.

dotfile들을 추적할 Git Repo를 $HOME 디렉토리의 .cfg 라는 이름의 bare-git repo로 관리한다.
Git Repository의 Workspace 또는 Working Tree를 환경변수에 지정되어 있는 $HOME 디렉토리로 설정한다.
dotfile들을 본래의 위치를 유지한채로 git add and git commit 를 통해 Git Repository로 추적한다.
만든 Git Repository를 Github에 Push하여 저장한다. → 이를 통해 dotfile들은 백업되며 언제든지 복제가 가능해진다.
이렇게 만들어진 Github의 레포지토리의 dotfile들을 언제든 다른 머신에서 clone 하여 사용할 수 있다.

결과적으로 이렇게 관리하는 dotfile들은 자기자신이 있어야 하는 위치에서 변하지 않고 자리를 유지할 수 있으며, 그 어떤 symlink 없이 관리가 가능하고 Git이라는 버전관리시스템의 모든 혜택을 받을 수 있다!

Overview of storing dotfiles in a Git Repository

Storing your dotfiles using bare-git repository
1. git init --bare $HOME/.cfg
2. alias config='/usr/bin/git --git-dir=$HOME/.cfg/ --work-tree=$HOME'
3. echo "alias config='/usr/bin/git --git-dir=$HOME/.cfg/ --work-tree=$HOME'" >> $HOME/.bashrc
4. config config --local status.showUntrackedFiles no
5. config add .vimrc + config commit -m "add .vimrc" + config push
Installing
1. echo ".cfg" >> .gitignore
2. git clone --bare <remote-git-repo-url> $HOME/.cfg
3. alias config='/usr/bin/git --git-dir=$HOME/.cfg/ --work-tree=$HOME'
4. config config --local status.showUntrackedFiles no
5. config checkout
6. config add .vimrc + config commit -m "add .vimrc" + config push

Line by line breakdown

Storing your dotfiles using bare-git repository

1. `git init --bare $HOME/.cfg`

$HOME 에 .cfg라는 이름으로 dotfiles를 기록하는 Bare-Git Repo를 만든다.

2. `alias config='/usr/bin/git --git-dir=$HOME/.cfg/ --work-tree=$HOME'`

기본적으로 Git 명령어들을 실행하면 해당 명령어들이 실행되어 반영되는 곳은 레포지토리 내의 /.git 폴더에서 해석되어 실행된다. 이는 Git Program이 실제로 추적하고 관리하는 것은 .git 폴더이기 때문이다.
그리고 이러한 일반적인 상황에서 Git은 Workspace는 해당 레포지토리(디렉토리)로 인식한다.

/usr/bin/git --git-dir=$HOME/.cfg/ --work-tree=$HOME 에 주목하자.
/usr/bin/ 경로에 위치한 git 프로그램을 실행하여 옵션으로 --git-dir=$HOME/.cfg/과 --work-tree=$HOME 을 전달한다는 의미를 지니며, 옵션 --git-dir=$HOME 은 Git Repo를 $HOME/.cfg 디렉토리로 설정하고 --work-tree=$HOME은 Workspace를 $HOME 디렉토리 전체로 지정한다는 의미를 지닌다.
따라서 /usr/bin/git --git-dir=$HOME/.cfg/ --work-tree=$HOME {어떠한 Git 명령어} 의 의미는 $HOME/.cfg 를 Git Repo로 지정하고 $HOME 디렉토리 전체를 Workspace로 지정한 상태에서 어떠한 Git 명령어 ex) status, add, commit, push, pull ....etc 들을 실행하겠다는 의미이다.

명령어 alias는 명령어의 별병을 지어주는 리눅스 명령어로, /usr/bin/git --git-dir=$HOME/.cfg/ --work-tree=$HOME 이라는 긴 명령어를 config라는 짧은 커스텀된 명령어로 줄여준다.
다만 .zshrc 나 .bashrc 와 같은 쉘 자체의 설정파일에 저장되지 않았기에 시스템을 재부팅할 때마다 위 명령어를 실행해줘야 하는 불편함이 따른다.

3. `echo "alias config='/usr/bin/git --git-dir=$HOME/.cfg/ --work-tree=$HOME'" >> $HOME/.zshrc`

리눅스의 echo 명령어를 통해 해당 별칭 지정 명령어를 터미널 쉘 설정 파일에 저장한다. 이로써 재부팅할때마다 위의 2번 명령어를 실행할 필요가 없어진다.

4. `config config --local status.showUntrackedFiles no`

기본적으로 Git은 git status 명령어 사용 시 다음과 같이 Workspace 내에서 사용자가 레포지토리에 git add 를 통해 추적 리스트에 추가하지 않은 파일들도 보여준다.
이러한 파일들을 untracked files라고 부르며 현재 Workspace로 지정된 곳이 $HOME 디렉토리인 만큼 어마무시하게 많은 파일들이 뜸을 볼 수 있다.

이러한 현상을 방지하기 위해 이 명령어는 해당 Git Repo의 설정을 사용자가 실제로 Workspace에서 추적하게끔 git add 명령어로 추가한 파일들만 git status 명령어로 볼 수 있게 바꿔준다.

5. `config add .vimrc` + `config commit -m "add .vimrc"` + `config push`

이제 환경설정은 모두 완료되었다.
앞서 alias 명령어로 지정한 config 명령어를 통상적으로 쓰는 git 대신에 활용하여 관리가 필요한 dotfiles들의 변화를 기록하고 github에서 이를 유지할 수 있다!

Installing

1. `echo ".cfg" >> .gitignore`

앞으로 Git Repo로 사용할 .cfg 가 자기자신을 추적하면 오류가 발생하기에 이를 .gitignore에 넣어줌으로써 방지한다.

2. `git clone --bare <remote-git-repo-url> $HOME/.cfg`

이제 자신의 Github에서 원하는 레포지토리를 Bare-Git 레포지토리로 clone 해준다.

3. `alias config='/usr/bin/git --git-dir=$HOME/.cfg/ --work-tree=$HOME'`

앞서 했던 alias 를 설정해준다.
여기서 echo "alias config='/usr/bin/git --git-dir=$HOME/.cfg/ --work-tree=$HOME'" >> $HOME/.bashrc 를 하지 않고 1회성 별칭지정을 하는 이유는 앞으로 가져올 .basrc .zshrc 등등과 같은 터미널 쉘 설정파일들도 있다고 가정했기 때문이다.
만약 없다면 설정파일에 적어두면 된다.

4. `config config --local status.showUntrackedFiles no`

마찬가지로 config status 명령어 사용 시 불필요하게 많은 파일들을 보지 않기 위한 설정을 해준다.

5. `config checkout`

git checkout 명령어는 독특하게도 하나의 명령어이지만 여러가지 기능을 지닌다.
그중 하나는 바로 Working Tree 파일들을 복원하는 것으로, 이번에 실행하는 config checkout 명령어는 가장 Git에 기록되어 있는 가장 최근의 Workspace 상태로 Workspace를 복원하는 역할을 한다.
즉 clone 하여 만든 Bare-Git Repo인 .cfg 에 기록된 dotfiles들을 실제로 Workspace로 지정된 $HOME 디렉토리에 생성하는 역할을 한다.

주의
다만 이렇게 바로 checkout하여 복원하면 에러메시지가 발생할 수 있다.
Github에 보관되어 있는 dotfiles들 중에 현재 로컬에 존재하는 dotfile이 있을 수도 있기 때문이다.
이 dotfiles들을 찾아서 백업해두거나 제거한 뒤에 다시 명령어를 실행하면 원활하게 실행이 된다.

6. `config add .vimrc` + `config commit -m "add .vimrc"` + `config push`

이제 $HOME 디렉토리에서 원하는 dotfile들을 GIt에 추가하고 커밋하면서 관리할 수 있다!

아래는 실제로 나의 VIM 설정을 적용한 모습이다.
개인적으로 배경색은 터미널의 설정을 이용하기에 Ubuntu Bash 쉘의 기본 색이 적용되어있다.

Bare-Git Repository란?

KwonPodo — Wed, 23 Nov 2022 22:12:04 +0900

References

What is a Bare Git Repository?

git init은 원하는 디렉토리 내에서 git을 활성화할 때 쓰는 명령어다.
이를 실행하면 Git 프로그램에서 주시하는 해당 디렉토리에 대한 모든 Git 관련 데이터를 저장하고 관리하는 .git 이라는 디렉토리가 생성된다.

통상적으로 사람들이 git init 명령어를 통해 어떤 디렉토리에서 Git을 활성화하거나 Github에서 git clone 명령어로 레포지토리를 어떤 디렉토리로 clone 할 때 해당 디렉토리를 'git repo'라고 부른다.
이 용어는 다소 틀린 감이 없잖아 있는데 이는 사실 정확하게 보면 cloning을 통해 구축된 디렉토리 내부는 working space(or Working Directory) 와 git repo 로 구분되기 때문이다.

이에 대해 알아보자.

Workspace (Working Directory)

File tree representation of the repo at a given commit hash.

=> git commit hash에 저장된 가장 최근의 기록을 가지고 File Tree 형태로 구현된 형태.
이름에서 알 수 있듯이 '작업'을 위한 공간이며, 실제로 있는 파일들을 수정, 추가, 삭제 및 커밋하여 나의 변화를 기록할 수 있는 공간이다.

Git Repo

Contents of the actual Git Repository which contains everything Git Program needs to maintain the repository. A.K.A .git directory

예시를 위해 gitTest라는 디렉토리를 생성하고 github에서 무작위 디렉토리를 가져와 clone 해보았다.
아래는 위에서 정의된 Workspace를 보여준다.

해당 Workspace는 사실 git branch main의 commit hash 중 아래에서 하이라이팅된 가장 최근의 commit hash를 실제 디렉토리 형태로 구현한 것에 불과하다.

진정한 의미의 Git Repository란 사실 터미널에서 ls -al 명령어로 숨김파일까지 다 보였을때 나오는 .git 디렉토리이다.

위에서 Workspace와 Git Repo의 차이에 대해 어렴풋이 알았으니 이제 Bare-Git Repository에 대해 알아보자.
용어에서 알 수 있듯이 Bare-Git Repo란 위에서 관찰했던 Workspace와 Git Repo 중, 순수한 Git Repo를 의미한다.
git clone --bare {url} {filename} 명령어를 통해 Bare-Git Repo를 생성할 수 있으며 그 내용물은 아래와 같다.

자세히 관찰해보면 몇가지 내용물들이 빠진 채로 생성됨을 알 수 있다. (이유는 아직 못찾음)

index
logs
refs

또한 git status, git add, git checkout 등등의 평소에 Git에서 쓰던 명령어들이 안먹히는 것을 확인할 수 있는데 이는 해당 디렉토리가 Workspace가 아니기 때문이다.
사실 이 명령어들뿐 아니라 git commit 을 제외한 대부분의 명령어들이 먹히지 않는다.

그렇다면 일견 보기에 아무런 쓸모없어 보이는 디렉토리는 어디에 써먹는 것인가?

The point of bare-git repo is that you can't do anything with it.
The reason the bare-git repo exists is that now this can be used by another repo/workspace to actually push, pull, clone from this.

=> 이렇게 만들어진 Bare-Git Repo는 다른 디렉토리/Workspace에서 이 Bare-Git Repo를 push, pull, clone 하는 데 사용할 수 있으며, 이는 일반적인 git clone, git init 으로 만들어지는 Repo들은 할 수 없는 기능이다.

앞서 만들었던 baekjoon_nonbare를 지우고 Bare-Git Repo인 baekjoon_bare를 clone하여 다시 baekjoon_nonbare 이름으로 생성하여 보았다.

clone된 baekjoon_nonbare 디렉토리 내부를 보니 Workspace로 생성되었음을 확인할 수 있다. 또한 git remote -v 로 확인한 원격저장소는 Bare-Git Repo임을 볼 수 있다.

새로운 new.txt라는 파일을 만들어 baekjoon_nonbare 디렉토리에서 git add, git commit, git push를 해보면 정상적으로 push가 되어 baekjoon_bare git log 에 기록됨을 볼 수 있다.

Bare-Git Repo? Github?

지금까지 했던 내용을 정리해보면, 일반적으로 우리가 Git Repository라고 부르던 것은 사실 Workspace와 .git 디렉토리에 저장된 데이터(.git directory === Git Repo)로 나뉜다는 것을 알았다.
Workspace를 제외한 나머지, Git Program에서 버전을 관리하기 위한 데이터들만을 가지고 만들어진 디렉토리를 Bare-Git Repository라고 부르며 이렇게 만들어진 레포지토리는 특이하게도 그 자체로는 아무런 조작을 가할 수 없으며 로컬에 저장되어 있음에도 불구하고 git clone 이 가능하여 원격저장소로 기능할 수 있음을 확인할 수 있었다.

Bare-Git Repository의 핵심은 원격저장소로 기능이 가능하다는 점이다.
이는 Bare-Git Repo가 '공유'의 공간으로 기능함을 의미한다.

여러 개발자들이 협업하는 프로젝트에서 모든 변경점들이 반영되어 기록되는 중앙화된 공간이 필요하고, 해당 프로젝트의 개발자들이 모두 접근 가능한 저장소가 있다면

사실상 Github와 기능이 유사하며 Localized된 Github라고 간단하게 생각할 수도 있을 것 같다.

Github가 있는데 이런 기능이 왜 필요하냐는 생각이 들 수도 있지만 이는 애초에 잘못된 의문이다.

Github보다 Git이 먼저 나왔기 때문이다. Git이후에 나온 클라우드 서비스가 Github이기 때문에 이러한 기능이 있어야함이 옳다.

자료구조와 알고리즘에 관해

KwonPodo — Tue, 30 Aug 2022 13:16:24 +0900

알고리즘의 정의

알고리즘이란 주어진 문제를 해결하기 위한 '잘 정의된' 동작들의 유한 집합이다.
-<C로 배우는 알고리즘>, 이재규 -

알고리즘이란 쉽게 생각하면 어떠한 문제를 직면했을 때 해당 문제를 풀기 위한 방법이다. 해당 문제의 상황 자체를 이해하여 입력값이 필요하다면 입력값을 지니고, 그 입력값으로 문제를 해결했는지를 알기 위한 출력값이 최소한 한개 이상 필요하다.
위의 동작이란 문제를 풀기 위한 세분화된 단계들을 의미하며 이는 컴퓨터에서 명령어들을 말한다. 그렇다면 '잘 정의된' 명령어란 무엇일까.

명확성
명령어는 수행환경에서의 동작이 명확해야한다.
=> 명확해야 한다는 의미가 내게는 다소 모호한데, 이는 내게 어느 누가 보더라도 해당 명령어가 같은 동작을 한다는 의미로 해석된다.
다시 말해, 항상 그리고 누구든 해당 명령어를 보면 같은 동작이 머릿속에 그려져야 한다는 뜻이다.
유효성
명령어는 유효해야 한다.
=> 유효해야 한다는 의미가 뭘까.
어떠한 명령이 유효하다는 의미는 실현이 가능해야 한다는 뜻이다. 이는 시간과도 직결된다. 주어진 문제의 환경 내에서 일정한 시간안에 해당 명령어가 유효하게 동작할 수 있는가?가 바로 명령어의 유효성이다. 만약 어떠한 수들의 집합 내에서 가장 큰 수를 찾는 동작이 있다고 하자. 문제의 제한된 시간 동안 해당하는 수를 찾을 수 있다면 이는 유효한 명령어가 될 수 있지만, 집합의 크기가 장히 커 시간 내에 가장 큰 수를 찾을 수 없다면 이는 유효한 명령어가 될 수 없다.

이러한 명령어들의 집합은 유한해야 한다.

알고리즘의 유한성
어느 알고리즘이던 간에 사용하는 이유는 문제를 효율적으로 해결하기 위함이다. 헌데 해당 알고리즘을 이루는 명령어가 유한하지 않고 무한하다면, 알고리즘은 계속해서 돌아가며 문제는 해결되지 않는다.
이는 의미가 없기에 알고리즘의 단계(명령어)는 유한해야 하며, 끝이 나야 한다.

자료구조의 정의

자료구조란 메모리상에 올라와 있는 데이터들을 보다 효율적으로 저장하고 사용하기 위한 논리적인 규칙 혹은 구조이다.
주어진 문제에 대하여 '무엇을 어떻게 하여 해결한다'라고 생각을 한다면, 알고리즘은 '어떻게'를 담당하며 자료구조는 '무엇'을 담당한다.
단순하게 생각을 한다면 자료구조는 문제를 해결하기 위한 도구이며 알고리즘은 그 도구를 사용하는 방식이 된다고 할 수 있다.
사용하고자 하는 알고리즘에 따라 그에 효율적인 자료구조가 존재하며, 쓰이는 자료구조에 따라 그를 활용하는 효율적인 알고리즘이 존재하기에 적절한 알고리즘-자료구조의 선택이 전체 문제해결 기법의 효율을 가른다고 볼 수 있다.

추상적 자료 구조(Abstract Data Structure)

자료구조의 사용법과 내부의 세부적인 구현이 분리되어 있는 자료구조를 말한다.
대표적으로 큐, 스택 등등이 있다. 스택의 경우 기본 연산인 pop, push, top이 정의되어 있지만, 항상 같은 이름으로 정의되어 있기에 내부적인 구현을 바꾸더라도 명시되어 있는 pop, push, top의 역할은 그대로 유지된다.

알고리즘의 분석 (Analysis of Algorithm)

경험적 분석

단순히 보자면 해당 알고리즘을 프로그램으로 구현하여 실행시켜서 실행 시간과 소요 메모리를 비교해 보는 것이다.
확실하고 명확하지만, 사용하는 컴퓨터의 CPU와 같은 하드웨어의 영향을 받아 보편적이지 않다는 단점이 있다.

수학적 분석

실제 컴퓨터 없이 알고리즘을 구현한 코드를 보고 기본적인 명령어들을 수행하는 가상의 컴퓨터를 기준으로 명령어의 실행횟수를 계산해 보는 것이다.
경험적 분석과는 달리 사용하는 컴퓨터의 하드웨어에 의존하지 않아 보편성을 지닌다고 볼 수 있다.

복잡도 (Complexity)

=> 입력의 크기(n)에 대한 컴퓨터의 자원의 사용량을 식으로 표현한 것을 말한다.
컴퓨터의 자원은 시간과 공간(메모리)이다.

공간 복잡도 (Space Complexity)
시간 복잡도 (Time Complexity)

주의
복잡도는 입력값(n)에 따라 달라질 수 있다. 이는 세가지 경우로 나뉜다.

모든 경우 복잡도(every-case complexity) : 모든 경우에 대해 동일한 자원 소모를 지닐 경우
최악의 경우 복잡도(worst case complexity) : 이 알고리즘에 대한 입력이 자원 소모가 최대치가 되도록 할때, 이때의 자원 소모량을 의미한다.
평균의 경우 복잡도(average-case complexity) : 평균적인 경우에 대한 자원 소모량이다. (찾기 힘들다..)

시간 복잡도의 계산은 프로그램 실행 시, 모든 명령어들이 시행되는 횟수로 계산한다.
여기서 명령어들은 기본적인 동작들, 예를 들어 '비교'나 '교환'같은 동작이다.
원칙적으로는 '모든' 명령어들의 시행 횟수이기에 다 세는 것이 맞지만, 그렇게 된다면 복잡도의 식이 너무 복잡하게 되며 실행하는 컴퓨터에 따라 달라지기도 하기에 실용성이 떨어진다.
복잡도의 계산은 이 알고리즘이 얼마만큼의 메모리와 시간을 소모하는지 파악하기 위함인데 전부 세는 것은 이에 맞지 않다.
따라서 점근적 복잡도(Asymptotic Complexity) 라는 복잡도 계산법을 사용한다.

점근적 복잡도(Asymptotic Complexity)

이는 미적분학에서 배웠던 극한의 개념과 비슷하다.
입력의 크기를 n이라고 할때, n에 대한 최고차수를 비교의 기준으로 사용하는 것이다.
예를 들어보자.
$$\displaystyle \lim_{x \to \infty} \cfrac{3x^3+2x^2+1} {x^3+x} = 3$$
최고차수를 제외한 나머지 하위차수나 상수값들은 n이 무한히 커질 때는 의미가 없기에 버린다는 생각이다.
위 수식을 보면 최고차항을 제외한 나머지 차수는 관심도 없지 않나. 이러한 맥락으로 복잡도를 본다면,

$$ O(3n^3 + n^2 + n) == O(n^3) $$ 라고 할 수 있겠다.

점근적 복잡도를 표기하는 방식은 3가지가 있다.

O - 표기법 (Big O Notation): 상한 성능
(\Omega - Notation ) : 하한 성능
(\Theta - Notation )

주로 사용하는 기법은 O - 표기법으로 이는 아무리 시간이 오래 걸린다고 해도 표기한 최악의 경우는 넘지 않는 다는 것을 보증하는 표기법이다.

여기서 상한/하한의 개념은 이산수학에서 배웠던 내용이라 어떻게 연결을 시킬 수 있을 듯 한데, 그 부분은 따로 다시 복습을 한뒤에 글로 정리를 해보아야겠다.

파이썬 비교 연산자 is VS ==

KwonPodo — Fri, 19 Aug 2022 00:01:25 +0900

References : Python Comparison Equivalence VS Identity

Python Comparison Operator

파이썬의 참/거짓 판별에 대한 공식문서에 들어가보면 is 연산자와 == 연산자를 확인할 수 있다.
뭔가 직관적인 의미상으로는 둘다 동일한 것인지에 대해 판별하기 위해 도입한 연산자인 것 같은데, '무엇'이 동일한지에 대한 명확한 이해가 필요해 보여 정리를 해보자 한다.
이를 확인하려면 영어 공식문서를 보는 것이 훨씬 명확한듯하다.

공식문서에서는 다음과 같이 명시되어 있다.

== 연산의 경우 Equal이라는 표현을 쓰며, is 연산자는 Object Identity라는 표현을 쓴다. 다만 개인적으로는 == 연산자는 Equal이라는 표현보다는 Equivalent라는 표현이 어울릴 듯 하다.

Equality VS Equivalence (동일과 동치)

l1 = [1, 2, 3]
l2 = l1
l3 = [1, 2, 3]

print(l1 == l2) # True
print(l1 == l3) # True

print(l1 is l2) # True
print(l1 is l3) # False

이산수학에 나오는 동치관계(Equivalence Relation)와 '동일하다'의 개념(Equal)을 활용한다면 이해가 위의 코드가 왜 저렇게 동작하는지 이해가 한결 편하다.
'동치관계'와 '동일'의 개념을 한눈에 그리자면 다음과 같다.

동치관계

어떠한 두 요소 a 와 b가 동치관계라는 것은, 두 요소가 어떠한 속성(또는 어떠한 측면)에 대하여 동일한 값을 지니고 있다는 뜻이다.
예를 들어 리틀이라는 이름을 가진 리트리버와 빅이라는 이름을 가진 진돗개는 '종족'의 측면에서 둘다 '개'라는 동일한 값을 지니므로 동치관계라 할 수 있다.

동일하다

어떠한 두 요소 a 와 b가 동일하다는 것은 정말로 두 요소가 동일한 것이라는 의미를 지닌다.
에를 들어 리틀이라는 리트리버가 주인 a에게서 다른 주인 b에게 입양되었다.
a가 과거에 데리고 있던 리틀은 주인 b가 현재 데리고 있는 리틀과 동일한가에 대해 '동일하다'라고 할 수 있다. 둘은 같은 개체이기 때문이다.
이를 영어로 표현하자면 Object Identity로 간편하게 이해할 수 있다.

이산수학에서 배운 상단의 두가지 개념을 그대로 활용하여 파이썬의 is, == 연산자를 이해해보자면 is 연산자는 '동일하다.(Equality or Object Identity)'로 알 수 있고 == 연산자는 '동치관계(Equivalence)'로 이해할 수 있다.

다시 코드를 보자.

l1 = [1, 2, 3]
l2 = l1
l3 = [1, 2, 3]

print(l1 == l2) # True
print(l1 == l3) # True

print(l1 is l2) # True
print(l1 is l3) # False

이제는 이 코드를 이해할 수 있다. 동일하다면 동치일 수 밖에 없으니 리스트 l1 과 l2는 동일하며 동시에 동치이므로 True를 반환한다.
반면 l1과 l3의 경우, 둘은 리스트의 '요소들의 값'이 모두 동일하다는 측면에서 동치관계이므로 == 연산자는 True를 반환하지만, 각기 다른 개체이므로 is 연산자는 False를 반환해 준다.
이때 is 연산자는 두 객체의 '동일' 여부를 메모리주소로 확인하는 듯 하다.

파이썬은 모든 것이 객체로 이루어져 있으며, 또한 참조로 움직인다고 나는 알고 있다. 이 때문에 위 코드의 2번째 줄의 l2 = l1에서 l2변수에는 현재 l1이 참조하는 메모리의 주소가 전달된다.
이러한 점에서 파이썬의 변수전달 방식이 전부 참조(Call by Reference)인지, 아니면 값 복사(Call by Value) 또한 존재하는지에 대해 새로 궁금증이 생겼다.
기존에 쓰던 언어가 C/C++이다보니 아직은 파이썬이 내부적으로 어떻게 돌아가는지에 대한 이해가 부족해보인다.
이에 관해선 따로 공부를 하고 정리를 해 볼 필요가 있어 보이는데, 이는 나중으로 미룬다....ㅎ

[백준/C++] 2902 KMP는 왜 KMP일까?

KwonPodo — Sun, 14 Aug 2022 22:11:43 +0900

문제

https://www.acmicpc.net/problem/2902

2902번: KMP는 왜 KMP일까?

입력은 한 줄로 이루어져 있고, 최대 100글자의 영어 알파벳 대문자, 소문자, 그리고 하이픈 ('-', 아스키코드 45)로만 이루어져 있다. 첫 번째 글자는 항상 대문자이다. 그리고, 하이픈 뒤에는 반드

www.acmicpc.net

풀이

해석

문제 자체의 난이도도 브론즈2 수준으로 그닥 어렵진 않지만 이 문제를 포스팅하는 이유는 C++로 문자열을 잘라내는 것이 Python만큼 간단하게 되지 않기 때문이다. Python으로 이 문제를 푼다면 list(str.split('-'))으로 문자열을 분리해서 리스트로 묶어내고 각 첫 글자만 모아 출력하면 간단히 끝난다. 하지만 C++에서는 이렇게 문자열을 Split해주는 메서드가 지원되지 않기에 따로 구현을 해주어야 한다.

위 코드에서는 따로 부분 문자열을 추출하지 않고 구분자(Delimeter: '-')의 위치를 찾아 이를 기준으로 답을 도출해 내었다.

만약 부분 문자열을 추출한다면 따로 <string>헤더의 string::substr()와 string::find() 함수들을 조합하여 반복문을 돌려서 구해야 한다.

<string>의 함수들을 사용한다면 위처럼 하며, 찾아보니 <sstream>의 stringstream이나 istringstream 객체를 이용하는 방법들이 있는데 이는 C++ 자체의 입출력 관련 개념들과 객체들에 대한 이해가 필요로 해보여 일단은 내가 잘 알고 잘 쓸 수 있는 <string>쪽의 메서드 들로 구현해보았다.

언젠가 입출력, 버퍼, 스트림에 대한 개념정리를 해야할 듯 싶다.

[백준/C++] 1018 체스판 다시 칠하기

KwonPodo — Thu, 11 Aug 2022 13:33:14 +0900

https://www.acmicpc.net/problem/1018

1018번: 체스판 다시 칠하기

첫째 줄에 N과 M이 주어진다. N과 M은 8보다 크거나 같고, 50보다 작거나 같은 자연수이다. 둘째 줄부터 N개의 줄에는 보드의 각 행의 상태가 주어진다. B는 검은색이며, W는 흰색이다.

www.acmicpc.net

문제

문제 분석

나는 이 문제를 정상적인 체스판과 '다른' 부분들의 개수를 찾는 것이라고 생각했다. 여기서 정상적인 체스판이란 8 x 8의 W부터 시작하는 체스판과 B부터 시작하는 체스판, 2 종류이다. 프로그래밍이니 B와 W라는 표현은 적합하지 않으므로, 각각 0과 1로 치환하여 2차원 벡터를 만들었다. => 이 두 벡터는 chess1, chess2라 명명한다.

멀쩡한 체스판과 '다른' 타일의 개수를 찾는다는 것은, 내적을 의미한다. 물론 통상적인 내적연산인 a1 * b1 + a2 * b2 + ...가 아닌, '다른' 것을 찾는 것이기에 XOR연산을 통해 내적연산을 변형한다. 즉, 내가 사용할 내적 연산은 a1^b1 + a2^b2 + ...가 되겠다.

입력받는 보드의 크기는 8 x 8 보다 크거나 같을 것이므로 해당 내적연산을 체스판을 1칸씩 상하좌우로 움직여가며 행하며, 이 모든 '다른'타일들의 개수, 즉 내적연산의 결과값들을 모두 따로 벡터에 저장하여 그 중 최솟값을 찾는다.

정상적인 체스판의 종류는 앞서 말했듯 두 종류이므로 내적 연산도 두번씩 한다.

코드

초반에 체스판들을 이리저리 옮겨가며 내적값들을 구하는 for문 안에서 index값들이 머릿속에서 꼬여 엄청 헷갈렸었다. 덕분에 이번 주차 문제들 중 푸는 법을 일찍이 알았음에도 구현이 어려워 가장 오래걸렸던 문제였기에 기억에 남는다.

[백준/C++] 1316 그룹단어 체커

KwonPodo — Thu, 11 Aug 2022 13:31:06 +0900

https://www.acmicpc.net/problem/1316

1316번: 그룹 단어 체커

그룹 단어란 단어에 존재하는 모든 문자에 대해서, 각 문자가 연속해서 나타나는 경우만을 말한다. 예를 들면, ccazzzzbb는 c, a, z, b가 모두 연속해서 나타나고, kin도 k, i, n이 연속해서 나타나기 때

www.acmicpc.net

문제

해석

연속되어 있는 단어들 중, 앞서 나온 단어가 후에 동떨어져서 출현한다면, 해당 단어는 그룹 단어가 아니다.

따라서 스트링으로 받고, 연속되는 지점이 끊기는 지점 (ex- aaabc에서 마지막 a에 해당하는 지점)에서 해당 문자가 뒤쪽 스트링에 나타나는지 확인하여 나타난다면 no를, 나타나지 않는다면 yes를 출력한다.

코드

[백준/python] 1673 치킨 쿠폰

KwonPodo — Thu, 11 Aug 2022 13:22:14 +0900

https://www.acmicpc.net/problem/1673

1673번: 치킨 쿠폰

강민이는 치킨 한 마리를 주문할 수 있는 치킨 쿠폰을 n장 가지고 있다. 이 치킨집에서는 치킨을 한 마리 주문할 때마다 도장을 하나씩 찍어 주는데, 도장을 k개 모으면 치킨 쿠폰 한 장으로 교환

www.acmicpc.net

문제

코드

풀이

문제 해석이 조오끔 난해했다. 맨처음 n마리의 치킨을 시키면 그만큼의 도장이 또 생기고, 그를 k 번 나눈 몫만큼의 치킨을 또 시킬 수 있고, 그만큼의 도장이 또 생긴다. 이렇게 생긴 도장이 맨처음 시킨 치킨 n마리만큼의 도장//k 만큼을 합친 것 만큼 또 합쳐져 시킨을 시킬 수 있다.

이를 while 문으로 계속 돌려 끝까지 돌린다음 나온 총 먹은 치킨 값이 답으로 도출이 된다.

[백준/python] 9012번: 괄호

KwonPodo — Thu, 11 Aug 2022 13:20:21 +0900

https://www.acmicpc.net/problem/9012

9012번: 괄호

괄호 문자열(Parenthesis String, PS)은 두 개의 괄호 기호인 ‘(’ 와 ‘)’ 만으로 구성되어 있는 문자열이다. 그 중에서 괄호의 모양이 바르게 구성된 문자열을 올바른 괄호 문자열(Valid PS, VPS)이라고

www.acmicpc.net

문제

풀이

맨처음에는 각 짝을 찾는 탐색형식으로 문제를 풀려고 했는데, 그렇게 하면 너무 번거롭게 됨을 깨닫고 방법을 찾다가 간편한 방식을 찾았다. 바로 '()'를 찾아 이를 문자열에서 제거하는 것이다. 그렇게 계속해서 제거하다보면 결국 짝이 맞는 문자열만이 공백이 되고, 안맞는 문자열은 한쪽 괄호만이 남게 된다.

C++로 풀어보려 했지만, 파이썬에 구현되어 있는 아주 간편한 str.find()함수를 내가 구현해야 하는 번거로움이 있었다. 그렇게 따로 함수로 구현하고 푸는 것보단, 이렇게 파이썬에 구현되어 있는 함수를 가져다가 활용하는 것이 편하다. 물론 내가 구현하는 것도 의미가 있지만, ㅎ....(귀찮다 ㅎㅅㅎ)

확실히 파이썬이 문자열 처리같은 부분이 굉장히 편리한 듯 싶다.

결론은 파이썬 만세다!

백준/C++14 2839번 설탕 배달

KwonPodo — Thu, 11 Aug 2022 13:19:10 +0900

https://www.acmicpc.net/problem/2839

2839번: 설탕 배달

상근이는 요즘 설탕공장에서 설탕을 배달하고 있다. 상근이는 지금 사탕가게에 설탕을 정확하게 N킬로그램을 배달해야 한다. 설탕공장에서 만드는 설탕은 봉지에 담겨져 있다. 봉지는 3킬로그

www.acmicpc.net

코드

풀이

맨처음에는 아주 단순하게 접근했다가 틀렸다,,

요지는 결국 최소한의 총 봉투 수로 n을 나눠담아야 하는 것이기에 5kg 봉투를 최대로, 3kg 봉투를 최소한으로 가져가는 것을 목표로 한다.

로직은 다음과 같다.

1. 5로 나눠지며 나눠진 수가 또 3으로 나눠진다면 바로 깔끔하게 5kg 봉투를 최대한으로 갖고 3kg 봉투를 최소한으로 갖는 봉투 수를 구할 수 있다.

2. 만약 위처럼 나눠지지 않는다면, 어쩔 수 없이 3kg 봉투를 하나 추가하고 ( n -= 3) 1번 분기로 돌아가 다시 테스트 해본다.

3. 계속해서 5kg봉투를 최대한 많이 쓰는 방향으로 루프를 돌리지만, 만약 n -= 3을 계속 했는데도 1번 분기를 만족하지 않고 음수가 나온다면 이는 5kg 봉투와 3kg 봉투로 나눠담을 수 없는 n이기에 -1을 출력한다.

준의 개발 공부

Bare-Git Repository를 이용한 dotfiles Migration

BackLink: Bare-Git Repository란?

References

Overview of storing dotfiles in a Git Repository

Line by line breakdown

Storing your dotfiles using bare-git repository

1. git init --bare $HOME/.cfg

2. alias config='/usr/bin/git --git-dir=$HOME/.cfg/ --work-tree=$HOME'

3. echo "alias config='/usr/bin/git --git-dir=$HOME/.cfg/ --work-tree=$HOME'" >> $HOME/.zshrc

4. config config --local status.showUntrackedFiles no

5. config add .vimrc + config commit -m "add .vimrc" + config push

Installing

1. echo ".cfg" >> .gitignore

2. git clone --bare <remote-git-repo-url> $HOME/.cfg

3. alias config='/usr/bin/git --git-dir=$HOME/.cfg/ --work-tree=$HOME'

4. config config --local status.showUntrackedFiles no

5. config checkout

6. config add .vimrc + config commit -m "add .vimrc" + config push

Bare-Git Repository란?

References

What is a Bare Git Repository?

Workspace (Working Directory)

Git Repo

Bare-Git Repo? Github?

자료구조와 알고리즘에 관해

알고리즘의 정의

자료구조의 정의

추상적 자료 구조(Abstract Data Structure)

알고리즘의 분석 (Analysis of Algorithm)

경험적 분석

수학적 분석

복잡도 (Complexity)

점근적 복잡도(Asymptotic Complexity)

파이썬 비교 연산자 is VS ==

References : Python Comparison Equivalence VS Identity

Python Comparison Operator

Equality VS Equivalence (동일과 동치)

[백준/C++] 2902 KMP는 왜 KMP일까?

[백준/C++] 1018 체스판 다시 칠하기

[백준/C++] 1316 그룹단어 체커

[백준/python] 1673 치킨 쿠폰

[백준/python] 9012번: 괄호

문제

풀이

백준/C++14 2839번 설탕 배달

1. `git init --bare $HOME/.cfg`

2. `alias config='/usr/bin/git --git-dir=$HOME/.cfg/ --work-tree=$HOME'`

3. `echo "alias config='/usr/bin/git --git-dir=$HOME/.cfg/ --work-tree=$HOME'" >> $HOME/.zshrc`

4. `config config --local status.showUntrackedFiles no`

5. `config add .vimrc` + `config commit -m "add .vimrc"` + `config push`

1. `echo ".cfg" >> .gitignore`

2. `git clone --bare <remote-git-repo-url> $HOME/.cfg`

3. `alias config='/usr/bin/git --git-dir=$HOME/.cfg/ --work-tree=$HOME'`

4. `config config --local status.showUntrackedFiles no`

5. `config checkout`

6. `config add .vimrc` + `config commit -m "add .vimrc"` + `config push`