[우지석]Week2

[jisurk]

요구사항

기본

• UI 디자인 기초 토픽을 수강해 보세요. (https://www.codeit.kr/topics/ui-design-basics)
• 피그마 디자인에 맞게 PC사이즈 랜딩 페이지,회원가입 페이지를 만들어 주세요.
• React와 같은 UI 라이브러리를 사용하지 않고 진행합니다.
• 랜딩 페이지의 url path는 루트(‘/’)입니다.
• 로그인 페이지의 url path는 ‘/signin’ 입니다.
• 회원가입 페이지의 url path는 ‘/signup’ 입니다.
• 아래로 스크롤 해도 “Linkbrary” 로고와 “로그인” 버튼이 있는 상단 네비게이션 바(Global Navigation Bar)가 최상단에 고정되게 해주세요.
• HTML, CSS 파일을 Netlify로 배포해 주세요. (참고: https://www.codeit.kr/learn/5309)
  https://weekly-mission-jiseok.netlify.app/

심화

• palette에 있는 color값들을 css 변수로 등록하고 사용해 주세요.
• 비밀번호 input 요소 위에 비밀번호를 확인할 수 있는 아이콘을 추가해 주세요.

주요 변경사항

스크린샷

멘토에게

• 셀프 코드 리뷰를 통해 질문 이어가겠습니다.

[kiJu2]

위클리 미션 진행하시느라 수고 정말 많으셨습니다. 지석님.
코드 꼼꼼히 확인해보고 리뷰 하도록 할게요 !

[kiJu2]

commit 단위를 더욱 자주, 작게 해보시는건 어떠실까요?

git을 다룰 때 commit은 "언제 해야 하는가"를 생각해보신 적 있으신가요?
흔히 하는 말이 있습니다:

커밋은 합칠 수 있지만 나눌 수 없습니다.

그럼 커밋을 언제 해야 할까요?

저는 다음과 같은 룰을 지키며 커밋을 하는걸 권장 드립니다:

1. 커밋을 하는 단위는 커밋 메시지 한 줄로 설명할 수 있는 행동
2. 하나의 목표 혹은 액션이 달성될 때

관련하여 읽으시면 좋은 아티클을 추천드릴게요:

tl;dr

관련 변경 사항 커밋
커밋은 관련 변경 사항에 대한 래퍼여야 합니다. 예를 들어 두 개의 다른 버그를 수정하면 두 개의 별도 커밋이 생성되어야 합니다. 작은 커밋을 통해 다른 개발자가 변경 사항을 더 쉽게 이해하고 문제가 발생한 경우 롤백할 수 있습니다. 준비 영역과 같은 도구와 파일의 일부만 준비하는 기능을 통해 Git을 사용하면 매우 세부적인 커밋을 쉽게 만들 수 있습니다.

자주 커밋
커밋은 커밋을 작게 유지하고 관련 변경 사항만 커밋하는 데 도움이 되는 경우가 많습니다. 또한 이를 통해 코드를 다른 사람들과 더 자주 공유할 수 있습니다. 이렇게 하면 모든 사람이 정기적으로 변경 사항을 통합하고 병합 충돌을 방지하는 것이 더 쉬워집니다. 대조적으로, 대규모 커밋을 갖고 이를 드물게 공유하면 충돌을 해결하기가 어렵습니다.

미완성 작업을 커밋하지 마십시오
논리적 구성 요소가 완료된 경우에만 코드를 커밋해야 합니다. 자주 커밋할 수 있도록 기능 구현을 빠르게 완료할 수 있는 논리적 청크로 분할합니다. 깨끗한 작업 복사본이 필요하기 때문에(브랜치 확인, 변경 사항 가져오기 등) 커밋하고 싶은 유혹이 든다면 Git의 «Stash» 기능을 대신 사용하는 것이 좋습니다.

커밋하기 전에 코드를 테스트하세요
완료되었다고 생각하는 일을 저지르고 싶은 유혹에 저항하세요. 철저하게 테스트하여 실제로 완료되었는지, 부작용이 없는지(알 수 있는 한) 확인하세요. 로컬 저장소에 설익은 것을 커밋하려면 자신만 용서하면 되지만, 코드를 다른 사람과 푸시/공유하는 경우에는 코드를 테스트하는 것이 훨씬 더 중요합니다.

원문 보기

또한 깃 커밋 메시지 컨벤션도 함께 읽어보세요:

tl;dr:

커밋 메시지 형식

type: Subject

body

footer

기본적으로 3가지 영역(제목, 본문, 꼬리말)으로 나누어졌다.

메시지 type은 아래와 같이 분류된다. 아래와 같이 소문자로 작성한다.

feat : 새로운 기능 추가
fix : 버그 수정
docs : 문서 내용 변경
style : 포맷팅, 세미콜론 누락, 코드 변경이 없는 경우 등
refactor : 코드 리팩토링
test : 테스트 코드 작성
chore : 빌드 수정, 패키지 매니저 설정, 운영 코드 변경이 없는 경우 등

원문보기

[kiJu2]

파일명을 의미있게 짓는게 어떨까요?

단순 파일명만 보아도 어떤 이미지인지 유추할 수 있도록 파일명을 짓는게 어떨까요? 😊

[kiJu2]

alt를 좀 더 구체적으로 작성해볼까요?

alt를 꼼꼼하게 작성했군요 ! 좋은 습관입니다.
다만, alt는 스크린 리더 사용자에 대한 보조 텍스트가 될 수 있으므로 "어떠한 이미지 인지"를 작성해주는 것이 좋아요 !

alt의 목적

• 인터넷 연결이 끊겼을 때 대체되는 이미지
• 스크린 리더 사용자를 위한 대체 텍스트
• 이미지를 볼 수 없는 환경에서 이미지를 대체하기 위한 텍스트
  등 목적을 알게 된다면 alt를 어떻게 사용하시면 될지 알 수 있을 것 같아요.

다음은 하버드 에듀케이션에서 제안하는 alt 규칙입니다:

tl;dr

• Write Good Alt Text
• Add alt text all non-decorative images.
• Keep it short and descriptive, like a tweet.
• Don’t include “image of” or “photo of”.
• Leave alt text blank if the image is purely decorative
• It's not necessary to add text in the Title field.

원문 보기

[kiJu2]

엇 여기 alt는 안써있네요 !

[kiJu2]

alt가 모두 비었습니다 !

Suggested change

	<a href="https://www.facebook.com/"
	><img src="./img/facebook.svg" alt="" name="Facebook"
	/></a>
	<a href="https://twitter.com/"
	><img src="./img/twitter.svg" alt="" name="Twitter"
	/></a>
	<a href="https://youtube.com">
	<img src="./img/youtube.svg" alt="" name="Youtube"
	/></a>
	<a href="https://instagram.com"
	><img src="./img/instagram.svg" alt="" name="instagram"
	/></a>
	<a href="https://www.facebook.com/"
	><img src="./img/facebook.svg" alt="Facebook logo" name="Facebook"
	/></a>
	<a href="https://twitter.com/"
	><img src="./img/twitter.svg" alt="Twitter Logo" name="Twitter"
	/></a>
	<a href="https://youtube.com">
	<img src="./img/youtube.svg" alt="Youtube Logo" name="Youtube"
	/></a>
	<a href="https://instagram.com"
	><img src="./img/instagram.svg" alt="Instagram Logo" name="instagram"
	/></a>

[kiJu2]

Suggested change

	<a href="index.html">
	<a href="/">