피로그래밍 12기 1주차 활동 정리 (19.12.31~20.01.06)

화요일(12.31)

인프런 실전 HTML&CSS 22강까지 듣기

 

목요일(01.02)

30강까지 끝내고...

 

부대복귀로 인하여 목요일 수업까지 결석.

 

 

트위터 로그인페이지 카피하기 : 수요일 과제(목요일까지 제출)

 

반성

- id보다 클래스를 자주 사용하는 습관 들이기

- 후손선택자보다 자손 선택자 사용 ( 이후 내부 div에서 코드가 꼬여서 원하는 대로 스타일 지정이 안될 수도 있음)

- 백그라운드 이미지를 만들어 쓰지 말고 백그라운드 색깔넣고 이미지 올려도 되는데... z-index의 사용 시야 넓히기

- 적절한 곳에 overflow:hidden주는 습관 들이기

- a링크에 패딩줘서 버튼 만드는 편법도 괜찮지만.... 그냥 button 태그를 사용하자.

 

금요일(01.03)

팀과제 : 래피드 페이지 프런트 구현하기 - 애니메이션 및 반응형 웹사이트 구현 위주

 

반성

- 반응형 웹페이지 구현? % 단위로 width를 주어서 무난했던 것 같지만 디바이스 크기에 따라 조절하는 것이 부족.

- vh가 디바이스마다 다르다는 것을 고려하지 못했음. 내 노트북에서는 해당 글이 충분히 나오도록 vh를 조절했지만, 더 작은 노트북의 화면에서 그렇지 못했음. div박스의 height를 내부 글 양에 따라 상대적으로 늘어나게 했다면 더 좋았을 듯.

- FAQ의 펼치기는 괜찮았으나 display:none이 켜지는 순간 바로 div박스가 사라지기 때문에 접히는 애니메이션을 넣을 수 없었음. 또한, 눌렀을 때 span태그의 +,-가 바뀌는 것과 글 색깔이 바뀌는 효과를 넣지 못하였음. 근데 이건 css만으로 구현하는 게 편법이라 펼치는 애니메이션/접는 애니메이션/색깔 바뀌기 셋 중 하나밖에 취사선택해야 하는 듯함.

 

 

토요일(01.04)

Gitkraken을 이용한 gui형 github 버전 관리 by 권진환 선배님

-add, commit, push 하고 기록 눈으로 확인하기

add : stage상태로, 비유하자면 보낼 물건을 확인한 상태.

commit -m : add한 stage의 내용물을 메시지를 담은 포장지로 감싸서 발송 준비가 다 된 상태.

push : commit한 내용을 발송.

-master와 branch 차이 알아보고 레포에 branch 따서 푸시하기

GitKraken에서는 feature/login 이런식으로 경로를 적어주면 feature끼리는 따로 모인다고 한다.

origin : remote저장소의 default명이다. origin자체가 특별한 용어나 고유명사는 아니고, 잘 안바꾸는 디폴트 네임이므로 자주 언급되는듯.

repository : 추상적인 이름으로, Git Hub에 올라가 있는 레포(remote repo)뿐만 아니라 pc에 저장된 레포(local repo)도 레포지토리이다.

-branch를 master에 merge 하기

merge : 갈라져나온 branch를 원래 master에 병합하는 것으로, 하고나면 commit 기록을 확인할 수 있다. 심지어는 branch에서 진행된 기록까지 다 시간순으로 master에서 정렬된다. 마치 나루토의 분신이 사라지고 나면 나루토 본체에 그 기억이 들어오는것과 같은 느낌인듯..

-f push: force push라는 뜻으로, local 저장소 파일로 remote저장소 파일을 전부 강제로 대체한다. master branch의 변경사항 그딴거 관심없고 내 코드를 강제로 밀어넣는것. 굉장히 위험하므로 웬만한 회사들은 대부분 락 걸어놓은 기능. 

fast-forward: master branch의 내용을 내 branch로 가져와 최신사항을 반영해줌.

-hosted repo : GitHub, gitlab, bitbucket 등.. / 버전 관리 프로그램: gitkraken, sourcetree 등…

-git-flow 요약도

gi-flow: 마스터는 절대 바로 merge 하지 않는 게 원칙. dev 등 다른 브랜치를 따서 브랜치 끼리 merge 하다가 나중에 마스터에 적용시키고 싶으면 pull request를 신청해서 승인됐을 때만 합치게 함. 이렇게 해야 git hub에서 code conflict를 검사해줌. Git-flow 모델 전체 내용은 우아한 기술 블로그(http://woowabros.github.io/experience/2017/10/30/baemin-mobile-git-branch-strategy.html) 참조. 그런데 요새는 agile하지 않다고 많이 사용되는 방법은 아니라고....

-pull은 remote에서 local로 파일 당겨오는 것.

-pull request 과정 직접 해보기 / 01.05 완료

-rebase의 필요성과 과정

rebase : merge하기 전에 미리 conflict를 해결하자! 라는 의도로 만들어진 기능. master branch의 특정 부분에서 branch를 따 작업을 하고 있었는데, 누군가가 나보다 작업을 먼저 끝내고 master에 merge를 해버렸다. 그러면 내가 갈라져 나온 master branch의 옛날 지점과 내가 앞으로 merge할 master branch의 지금 지점에 차이가 생기기 때문에, 그대로 merge해버리면 commit 그래프가 지저분해지게 된다(이리저리 꼬이고, 띄엄띄엄 붙고). 이 때 내 branch를 master에 merge하기 전에 현재 master에 rebase를 해주면, 내가 갈라져나온 옛날 지점과 현재 master의 차이(즉, 나보다 작업을 먼저 끝낸 이가 추가한 기능)를 확인하고, 추가된 기능이 있는 시점으로 내 branch가 갈라져 나온 부분을 최신화시켜준다(즉, 내 branch가 merge로 master에 돌아가기 전에 master에 추가된 내용을 내 branch에 갱신시켜주는것이다). 결국은 rebase가 끝나도 merge는 해야하지만, rebase를 사용할 경우 커밋그래프를 단순하고 깔끔하게 정리할 수 있어 정말 중요한 기능. 

merge와 rebase의 차이는 정말 중요하니 나중에 꼭꼭 공부해둘것.(https://backlog.com/git-tutorial/kr/stepup/stepup1_4.html)

-issue 관리하는 법

issue : 프로젝트를 진행하는 모든 부분에 대한 일종의 논의사항. '티켓'이라고 부르기도 하는데, 보통 한명의 책임자에게 해당 이슈에 관한 티켓을 주고, 그 책임자가 이슈의 생성 - 진행 - 종료의 발전과정을 추적할 수 있도록 만들어둔다. git-hub에서도 각 레포에 issue를 만들어 추적할 수 있고, @name으로 누군가를 태그할 수도 있음.

commit -m로 이슈 닫기 : 커밋 메시지에 close, closes, close, fix, fixes, fixed, resolve, resolves, resolved 총 아홉개의 키워드를 이용하여 메시지를 보냄과 동시에 이슈를 닫을 수 있음. 메시지 내에 'close #이슈번호' 같은 내용을 포함시키기만 하면 되며, 여러개의 이슈를 한꺼번에 닫을 수도 있다.

 

CSS3 flex 사용법 by 장용석 선배님

-속성 설명

-instagram cloning :  메타 뷰포트, justify-content, align-items, object-fit, display:grid 사용법 미흡

 

meta viewport

브라우저의 표준이나 디바이스의 뷰포트 크기 조절을 위해 정해놓는 룰.

브라우저에 따라 다를 수 있고, 모바일 디바이스냐 pc이냐에 따라서도 다르기 때문에 메타 뷰포트 설정을 통해 크기를 맞춰주는 것이 중요.

<meta name="viewport" content="width=devide-width, initial-scale=1.0">

위 코드가 일반적으로 가장 자주 사용되는 뷰포트 설정법인데, width를 통하여 너비 설정, initial-scale을 통하여 초기 배율(zoom수준) 설정.

height를 굳이 device-height로 설정하지 않아도 되는 이유는, 일부 값만 설정해주면 브라우저에서 알아서 다른 값을 추론하기 때문. initial scale 1.0으로 되어있다면 모바일 기기 화면 회전 시 device-width가 device-height로 바뀌게 알아서 다 조정해줌.

최소 최대 화면 배율 설정이나 줌 불가 옵션을 넣을 수도 있음.

 

justify-content / align-items

전혀 달라 보이는 두 이름과는 달리, 해당 속성들은 display:flex상태에서 서로 다른 방향의 정렬을 맡고 있다.

justify-content는 주축, align-items는 교차축(즉, 주축에 수직인 방향으로)의 정렬을 담당한다. flex상태의 기본 정렬 방식은 row정렬이므로, 그때 justify-content는 가로방향, align-items는 세로 방향으로 정렬시켜준다.

단, align-items의 경우 교차축의 줄이 한 줄 일 경우 많이 사용하고, 두 줄이 넘어갈 경우 align-content를 사용한다. align-content는 align-items에 우선하는 속성으로, 디폴트 값인 stretch로 설정이 되어있지 않다면 align-items를 사용할 수 없다.

flex의 설명과 속성에 관한 자세한 내용은 https://heropy.blog/2018/11/24/css-flexible-box/에 정말 잘 나와 있으니 참조.

 

object-fit

해당 요소가 지정된 너비와 높이에 맞게, "비율을 유지하면서" 가공할 수 있다.

fill: 설정하면 일반적으로 사이즈를 지정해주는 것과 같이 눌리거나 늘어날 수 있다. 종횡비를 유지하지 않는다.

contain: 종횡비를 유지하지만, 지정해준 사이즈에 딱 맞게 가공되지는 않고 가능한 한 많이 확대시킨다. 가로나 세로 사이즈 둘 중 하나가 지정해둔 사이즈에 꽉 차면 더 확대하지 않으므로, 한쪽 사이즈는 다 채워지지 않을 수 있다.

cover: 종횡비를 유지하면서 정의된 너비와 높이를 가득 채울 때까지 확대한다. 즉, contain과는 반대로 가로사이즈와 세로 사이즈가 둘 모두 지정해둔 사이즈보다 커져야 한다. 따라서 정해둔 사이즈를 넘는 사진의 부분은 잘린다.(이미지 중앙이 잘 보이게 모양을 잡고 싶을 때 유용)

none: 중앙을 기준으로 원본사진에서 원하는 사이즈의 크기를 잘라낸다. 기본 알고리즘에 의해 가운데 정렬.

 

display:grid

비교적 단순한 1차원 레이아웃의 flex도 있지만, 조금 더 복잡한 레이아웃을 위한 디스플레이 속성.

찾아보니 flex에 비해 훨씬 더 자유롭게 엘리먼트를 원하는 위치에 지정할 수 있다고 함. 그만큼 최근에 나온 속성이므로 지원 안 하는 브라우저나 버전이 있을 수 있다.

수직 수평의 여러 구조를 만들기 위해 여러 개의 flex container를 이용해야 하는 flex속성과는 달리 grid는 2차원 레이아웃을 지원하므로 한 번에 여러 엘리먼트의 사이즈를 유연하게, 구성을 복잡하게 만들 수 있다.

그러나 하위 버전의 브라우저에서 작동하지 않는 것은 치명적인 문제이므로 대체 css디자인을 사용해야 할 수도 있다.

여러모로 굉장히 유용한 최신의 속성인 듯 하니 다음번에는 이걸 써보는 걸로.

 

-Can I Use(https://caniuse.com)

새롭게 도입된 기술이 현재 얼마나 많은 웹브라우저에서 동작하고 있는가를 보여주는 사이트.

grid의 사용과 같이 신기술을 사용할 때는 대부분, 혹은 모든 사용자가 같은 형식의 프런트를 볼 수 있어야 하므로 어떤 기술을 어느 시점에서 사용해야 하는지 볼 수 있다.

 

-부트스트랩(http://bootstrapk.com)

프론트 웹 개발을 빠르게 할 수 있도록 HTML, CSS, JS를 쉽게 조작할 수 있는 기능을 추가시킨 프레임워크.

맨땅에 헤딩하듯 개발하는 게 아니라, 프레임워크에서 지원하는 유용한 코드/기능 등을 사용하여 디자인을 빠른 시간 내에 만들어 낼 수 있다.

부트스트랩을 이용한 여러 페이지의 예시들도 올라와있어 코드를 따갈 수도 있다.