nemo's dev memos

Stateless protocol (무상태 프로토콜) : 어떠한 이전 요청과도 무관한 각각의 요청을 독립적인 트랜잭션으로 취급하는 통신 프로토콜 - Ex) 인터넷의 기반이 되는 토콜(IP)과 월드 와이드 웹의 데이터 통신의 토대가 되는 HTTP - 통신이 독립적인 쌍의 요청과 응답을 이룰 수 있게 하는 방식 - 서버가 복수의 요청 시간대에 각각의 통신 파트너에 대한 세션 정보나 상태 보관을 요구하지 않는다. cf) 상태 프로토콜(stateful protocol) : 서버의 내부 상태 유지를 요구하는 프로토콜 출처 - 위키백과 : https://ko.wikipedia.org/wiki/%EB%AC%B4%EC%83%81%ED%83%9C_%ED%94%84%EB%A1%9C%ED%86%A0%EC%BD%9C

보호되어 있는 글입니다.

보호되어 있는 글입니다.

보호되어 있는 글입니다.

보호되어 있는 글입니다.

보호되어 있는 글입니다.

보호되어 있는 글입니다.

보호되어 있는 글입니다.

보호되어 있는 글입니다.

보호되어 있는 글입니다.

보호되어 있는 글입니다.

보호되어 있는 글입니다.

보호되어 있는 글입니다.

보호되어 있는 글입니다.

보호되어 있는 글입니다.

보호되어 있는 글입니다.

보호되어 있는 글입니다.

보호되어 있는 글입니다.

보호되어 있는 글입니다.

보호되어 있는 글입니다.

보호되어 있는 글입니다.

보호되어 있는 글입니다.

보호되어 있는 글입니다.

[android:background 속성] - 뷰 전체의 배경을 설정한다. - padding, adjustViewBounds 속성 등이 무시되며, 뷰 전체를 차지하는 배경으로 노출됨 +) adjustViewBounds 속성 : width, height 중 하나는 고정, 하나는 wrap_content일 때 이값을 "true"로 주면 고정값에 따른 이미지 비율에 맞춰 wrap_content크기가 정해진다. [android:src 속성] - 뷰에 이미지 리소스 컨텐츠를 넣어주는 개념 - padding이 걸려있다면 패딩만큼 안으로 밀려서 이미지가 설정되게 됩니다. [결론] >> ∴ 이미지를 넣을때는 왠만하면 src 사용 [출처] - [안드로이드 레이아웃]background와 src의 차이 https://wimi..

Git 에서 특정 한 브랜치에서 다른 브랜치로 합치는 방법으로는 두 가지가 있다. #1) Merge #2) Rebase - Rebase를 하든지, Merge를 하든지 "최종 결과물은 같고 커밋 히스토리만 다르다는 것이 중요하다!! #1 Merge - $git merge 명령어를 사용 - Merge 의 경우, 두 브랜치의 최종결과만을 가지고 합친다. - 이외 Merge는 브랜치 포스팅 참조 - [Merge 과정] * 아직 커밋하지 않은 파일이 Checkout 할 브랜치와 충돌 나면 브랜치를 변경할 수 없으므로 워킹 디렉토리 정리 후 Merge작업을 시작한다. 1) $ git checkout : 다른 브랜치(B) 내용을 병합할 브랜치(A)로 이동 2) $ git merge : 다른 브랜치(B)를 병합할 브랜..

Remote 저장소에 '로컬 수정사항/로컬 브랜치' 올리기 : $ git push : 로컬의 브랜치(LocalBranchName)를 Remote 서버로 전송 - 로컬의 브랜치를 서버로 전송하려면 쓰기 권한이 있는 리모트 저장소에 Push 해야 한다. - $ git commit 과 $git push 비교 : Git은 local repository가 있기 때문에, Git 에서의 commit은 local repository에 저장되는것을 의미하고, 이 커밋사항을 Git remote repository에 저장하려면 push를 해주어야 한다. 1. 로컬 브랜치의 이름과 리모트 서버의 브랜치 이름이 다를 때 : $ git push origin : - 리모트 저장소에 로컬의 브랜치(LocalBranchName) 이름..

리모트 Refs (Remote References) 일단, "Refs"란?? - Git은 모든 'history'를 'Key-Value format'으로 관리한다. ㄴ> 'Key'는 'SHA-1로 만들어진 40자리 해시값'이나 이를 기억하기 어렵기 때문에 "쉬운 이름의 파일"에 해시값이 저장한다. 이런 파일들을 "References"라고 하며, 약자로 "Refs"라고한다. - Git에서 "Refs"는 '.git/refs'에 저장된다. ㄴ> '.git/refs/heads' 디렉토리 내에는 main와 branch파일들이 있다. - Git에서 "어떤 특정한 작업을 가르키는 Refs"를 "branch"라고 한다. 리모트 Refs (Remote references) 란? : 리모트 저장소에 있는 포인터인 레퍼런스...

workflow에 따라 Git의 브랜치를 2개로 나누어 살펴볼 수 있다. 1. Long-Running 브랜치 : 개발을 진행하고 안정화할 브랜치를 추가 후 안정화가 됐을 때 '안정 브랜치(ex 'main 브랜치')'로 Merge할 브랜치 = 즉, main 브랜치에 merge되지 않은 활성화되어 있는 개발용 브랜치 - 이 브랜치는 언젠가 안정 상태가 되겠지만, 항상 안정 상태를 유지해야 하는 것이 아니며, 테스트를 거쳐서 안정적이라고 판단되면 main 브랜치에 Merge 한다▼ 즉, 배포했거나 배포할 코드만 main 브랜치에 Merge 해서 안정 버전의 코드만 main 브랜치에 둔다. - ex) 토픽 브랜치(앞서 살펴본 addQnA 브랜치 같은 짧은 호흡 브랜치)에도 적용할 수 있는데, 해당 토픽을 처리하..

브랜치 관련 명령은 대부분 '$git branch'명령이나 특화된 애들은 또 다른 명령어를 사용한다. 일단 모두 정리해 보자면 아래와 같다! $ git branch 관련 명령어 브랜치 생성 : $ git branch 브랜치 삭제 : $ git branch -d 브랜치 이름변경 : $ git branch -m 로컬 브랜치 목록 조회 : $ git branch 로컬&원격 브랜치 목록 조회 : $ git branch -a 브랜치 목록과 브랜치별 마지막 커밋 조회 : $ git branch -v Merge한 브랜치 목록 확인 : $ git branch --merged '현재 Checkout한 브랜치'에 Merge 하지 않은 브랜치 목록 확인: $ git branch --no-merged 브랜치 이동 명령어 다른..

충돌(CONFLICT)의 기초 "충돌(CONFLICT)이 발생했다" = Merge하는 두 브랜치에서 같은 파일의 한 부분을 동시에 수정하고 Merge하면, Git은 해당 부분을 Merge 하지 못하는(=Merge가 실패) 경우 "충돌이 발생"했다고 말한다. - 충돌이 발생하면 $ git merge 명령어에서 아래와 같은 충돌 메시지 출력한다. $ git merge iss53 Auto-merging index.html CONFLICT (content): Merge conflict in index.html Automatic merge failed; fix conflicts and then commit the result. - 3-Way Merge 시 충돌이 발생하면 Merge 하지 못하므로 Merge 커밋이..