0.오늘은 무얼 했는가
오늘은 나름 괜찮게 잔 것 같습니다.
어떤 재밌는 꿈을 꾸다가 깨서 안타까웠던 것만 기억이 나네요.
아침에 일어나 데일리 스크럼하고, 프로젝트의 UI 부분을 다듬었습니다.
그러다가 11시에 Git 특강이 있다고 해서 듣고, 13시가 다 돼, 점심식사를 했습니다.
이후, UI 쪽을 계속 손 보다가, 14시에 프로젝트를 GitHub를 통해 병합하는 과정을 거쳐...
15시부터 피드백 반영해 수정하고, 17시에 다시 잠시 프로젝트 관련 회의를 진행했습니다.
그리고 저녁 식사 후에, 19시부터 다시 프로젝트 관련해서 회의 진행하다가...
19시 30분쯤 코드 카타를 풀고, 8시 40분에 데일리 스크럼을 진행했습니다.
1. Git과 GitHub 사용법
21년 당시, 푸릇푸릇했을 때, 졸업작품을 만들면서, 팀원들이랑 협업하기 위해 GitHub를 처음 건드려봤었습니다.
"이거 대체 어떻게 하는 건지... 그냥 파일 올려버리면 되겠지?"
하고 그냥 파일 올렸던 기억이 나네요.
그리고 한동안 쳐다도 보지 않았다가 최근에 정보처리기사 공부를 하면서 마주치게 됐습니다.
근데 뭔가 이름이 이상해서 보니까 Git이더라고요. Git은 형상 관리 도구로써 어쩌고 저쩌고
그래서 Git이랑 GitHub는 무슨 차이일까 궁금증을 갖고 찾아보니까
Git은 버전을 관리하는 거고, GitHub는 그걸 공유한다는 것 같더라구요.
그것도 모르고 그냥 써야 한다니까 써야 했던 제가 있었습니다.
하지만 오늘!
특강을 통해서 Git과 GitHub에 대해 공부했습니다!
1-1. 그래서 Git과 GitHub는 뭔데?
사실 위에 나온 대로 Git은 버전을 관리하고, GitHub는 그걸 공유하는 건데요.
Git은 버전(형상)을 관리해서, 이전 버전에 어떤 일이 있었고, 현재 버전과는 어떤 차이가 있는지 비교해볼 수 있고, 현재 버전에서 오류가 생긴다면, 이전 버전으로 돌아갈 수 있기도 합니다.
이전에 프로젝트 진행할 땐 항상 그냥 한 파일에서 수정, 추가, 삭제했었는데...
이걸 미리 알았더라면 더 좋았겠죠?
GitHub는 백업, 협업 등을 위해 사용하는 온라인 코드 저장소입니다.
이게 꼭 필요한 이유는 일반적인 메일을 통해서는 절대 코드를 보낼 수 없기 때문입니다.
아무래도 Injection 공격이나, XSS 같은 보안적인 문제때문에 방지를 해놨겠죠?
그래서 GitHub라는 코드 저장소를 통해 다른 사람과 공유하고, 인터넷에 코드를 보관해두는 형식을 사용하는 것입니다.
물론, 다른 방식의 코드 저장소도 있겠지만, GitHub의 특별한 점은 Git을 사용한다는 거죠.
온라인 상에 코드를 공유, 저장하면서, 형상 관리까지 가능하다면
협업 도구로 쓰기 안성맞춤이라고 볼 수 있겠습니다.
1-2. Git 과 GitHub는 어떻게 쓸 수 있을까?
라고 일단 제목은 지어놨지만, 아직 더 공부해야 하는 부분이 많고... 기초적으로 쓸 수 있는 것 위주로 특강을 들었기에, 이에 대해 먼저 정리하겠습니다.
개념적인 부분이나 명령어에 대해선 이후에 좀 더 공부해볼게요.
먼저 Git의 명령어를 쓰기 전에, Git Bash를 켜고, 디렉토리를 내가 저장하고 싶은 곳으로 이동해줘야 합니다.
cd /내가 가고싶은 디렉토리명/...이후엔, 초기화를 진행해야 합니다. 초기화를 한다는 건, 새 Repository를 만든다는 뜻입니다.
git init위 명령어를 입력해주면, 해당 디렉토리에 .git 폴더가 몰래 생성되는데요. 이는
ls -a위 명령어를 입력하면, 볼 수 있습니다. ls는 현재 디렉토리 내 파일 목록인데, -a를 뒤에 붙이면 숨겨진 파일까지 다 볼 수 있습니다.
어쨌든 초기화를 했으면, 파일을 추가해줘야겠죠?
git add 파일명위를 입력하면, Repository에 올리기 전에 Staging Area라는 곳에 가게 됩니다.
git commit -m "메시지"위처럼 메시지를 포함해 입력해주면, Repository로 Commit됩니다.
...
갑자기 Repository라든지... Staging Area라든지 너무 이상한 단어들이 많이 나오는데 이에 대해 먼저 알고 갈 필요가 있어 보입니다.
1-3. Git의 세 영역
위 사진을 보면 한번에 이해할 수 있을 정도로 간결한데요.
우리가 작업하는 폴더를 Working Directory라고 부릅니다.
그리고, 이를 Repository라는 곳으로 보내면, 형상 관리를 위한 도구로써 역할할 수 있게 해주는 거죠.
근데 그 전에, Staging Area에 먼저 보냅니다.
왜일지 생각해봤는데, 아무래도 확인 절차라고 보는 게 맞는 것 같네요.
우리가 어떤 제품을 구매한다거나, 어떤 사이트를 탈퇴한다고 하면, 그 전에 한 번 더 물어봐주는 것처럼
Commit 전에 한 번 더 물어봐주는 느낌이네요. 그리고, 이런 식으로 하면, Commit하기 위한 과정이 간결해지기도 할 것 같습니다.
어쨌든, 이후, Commit을 통해 Repository에 보냅니다.
이렇게 저장된 Repository는 나중 가서 필요하면 Checkout해서 버전 관리를 할 수 있겠죠?
1-4. GitHub에는 어떻게 올릴까?
Git으로만 쓰기는 아깝죠. 아무래도 회사에서의 개발은 협업을 통해 이뤄지기 때문에, GitHub도 알아둘 필요가 있습니다.
먼저 Git에서만 쓰던 Repository를 GitHub에서도 만듭니다.
원격 저장소에서 Git을 쓰기 위해서겠죠?
그 후, 협업자를 초대하고, 설정한 뒤, 코드 반영을 위해 준비해주시면 됩니다.
git push origin 브랜치명다 설정했으면, 브랜치에 위 명령어를 통해 코드를 올릴 수 있습니다. 기본적인 브랜치는 master 또는 main으로 설정돼 있으니, 둘 중 맞는 걸로 치면 되겠습니다.
git clone 주소
git pull그리고, 위 명령어들을 통해, 이를 가져올 수도 있습니다.
clone의 경우는 아무것도 없을 때 그대로 복사해오는 것이고,
pull은 내가 가진 코드와 push된 commit을 확인하고, 차이가 생기면 가져오는 것입니다.
우선 이 정도만 해도 간단하게 GitHub에 코드를 올리고, 협업할 수 있습니다.
2. DP, PX
오늘은 사실 GitHub, Git 특강 말고는 거의 이 부분을 공부한 것 같네요.
Kotlin도 아직 부족해서 더 공부해야 하는데... 일단 이 내용부터 볼게요.
안드로이드 앱을 개발하다보면, DP, PX가 자주 나와요.
어떤 걸 쓰냐에 따라 화면이 기종에 따라 변하게 되는데요.
DP는 밀도 독립적 픽셀(Density-independent Pixels)로, 160dpi 화면에서의 물리적 픽셀 하나를 뜻합니다.
여기서 dpi는 인치당 도트(Dots per inch)로, 1인치에 얼마나 많은 점이 들어가냐를 말합니다.
즉, 160dpi는 1인치에 160개의 점이 들어가 있다는 뜻이 됩니다.
PX(Pixel)은 화면의 가장 작은 단위로, 매우 작은 사각형의 점입니다.
왜 픽셀이라는 단위를 두고, DP라는 새로운 단위가 만들어졌을까요?
왜냐하면, 기기들의 디스플레이의 dpi가 다르기 때문입니다.
예를 들어, 크기는 같지만, dpi가 다른 두 디스플레이가 있을 때, dpi가 160인 디스플레이는 320인 디스플레이보다 한 점의 크기가 더 큽니다.
만약 px을 사용해 화면을 구성하게 되면, 서로 화면이 다르게 되고,
이는 일부 기기에서 호환이 어려운 앱을 만들 수 있겠죠?
그래서, 160dpi를 기준으로, 1 dp는 1 px인 dp라는 단위를 만들게 되었습니다.
이렇게 되면, 160dpi의 디스플레이와 320dpi의 디스플레이도 1dp로 표현 가능하니까요!
결론은, DP를 쓰면, 여러 기기들의 화면을 일일이 신경 쓸 필요 없이 화면 구성이 가능하다는 겁니다.
오늘 하루 종일 공부했는데 코드도 없고,
이렇게 짧은 이유는 아직 해당 부분을 다 구현 못해서인데요...
후에, 구현 다 하고 나서 다시 올려보겠습니다.
3.코드 카타
오늘의 코드 카타 문제는 대충 만든 자판이었습니다.
아래는 제가 쓴 답입니다.
class Solution {
fun solution(keymap: Array<String>, targets: Array<String>): IntArray {
var answer: IntArray = IntArray(targets.size)
//타겟 순서대로 진행
for(i in 0..targets.size - 1) {
answer[i] = 0
//타겟의 문자열을 문자로 나눔
for(j in 0..targets[i].length - 1) {
var index = 999999
for(k in 0..keymap.size - 1) {
val c = keymap[k].indexOf(targets[i].get(j)) + 1
if(c > 0 && c < index) index = c
}
if(index == 999999) {
answer[i] = -1
break
}
else answer[i] += index
}
}
return answer
}
}오늘 코드 카타 하면서 느낀 점은
뭔가 해결이 안 되면 굳이 계속 그쪽에 매달릴 필요가 없다는 것입니다. 처음에는 계속 이상한 것만 하면서 for문과 if문만 늘려나갔었는데, 어떻게 풀어야 할지 다시 생각하고, kotlin의 확장함수도 생각해보면서 방법을 쉽게 찾았던 것 같습니다. 그리고, Kotlin을 사용하기에, indexOf 같은 다양하고 간편한 문법들을 생각해 풀면 좋을 것 같다는 생각이 들었습니다. 열심히 Kotlin 해야 할 것 같네요.
4. 끝
오늘은 무엇보다 협업 과정이 많았습니다. 코드를 GitHub에 올려서 충돌이 나기도 했었고, 서로 완성한 화면에 대한 피드백들을 주고 받았습니다. 저 혼자 할 때는 못 봤던 아쉬운 부분들이 팀원들과 함께 하니까 더 잘 보이는 것 같네요.
갇힌 생각보다는 열린 생각을 가져야 한다는 걸 다시 느끼게 됐습니다.
끝.
참고 자료
