각종 HTML 태그들

span,div

• 의미 없는 괄호들로, 유동적으로 사용 가능하다.

<div id="main-section">

인라인 요소

• 일반적인 인라인 요소에는 수직 여백을 적용할 수 없다.

대체 인라인 요소

• 이미지

비대체 인라인 요소

• 앵커태그

• 앵커 속성은 상속을 받지않는다.

target

• href target 을 '_blank' 로 지정하면 문서가 새 페이지에서 열린다.

<a href="html-css-basics-summary.pdf" class="button" target="_blank"

a: 속성

a:hover

• 사용자가 링크 위로 마우스를 가져가면 링크에 스타일을 적용

a:active

• 링크를 클릭하는 순간 링크에 스타일을 적용

footer a:hover,
footer a:active {
  background-color: rgb(255, 186, 58);
}

em 태그

• 강조

strong 요소

• 강한 강조

섹션 래핑

• main 에서 섹션을 나누기 위해서 사용
• section

호스팅 & 배포

웹의 작동방식

1. 주소를 입력하면 브라우저는 서버에 요청을 보냄

2. 서버는 HTML,CSS,JS 코드를 저장하고, 응답과 함께 브라우저로 다시 전송

파비콘

• 웹에서 조그만한 형태의 아이콘

<link rel="icon" href="images/favicon.ico">

버전관리 깃 & 깃허브

깃 Git

• 버전제어 시스템(VCS)으로 변경사항을 추적하고, 소스코드 기록을 관리함

• 로컬에서 작동한다.

• 레퍼지토리에 있는 모든 추적된 파일과 폴더들을 바탕으로 최근 상태를 비교하고 변경된 부분을 코드 스냅샷에서 작업시 반영

• 각각의 커밋들은 싱글 코드 스냅샷을 대표

• git branch 로 브랜치를 관리

깃 명령어

git merge

• 두개의 브랜치를 합친다

git merge [feature]

merge 충돌

• 1. 수정을 한다
• 2. 수정을 받아들인다. => 수정된걸 commit

git reset

git reset --hard HEAD~1

현재 branch 정보

 git branch --show-current

git branch 삭제

git branch -D feature

작업 디렉토리의 변경사항 취소

git checkout -- .

• 작업 디렉터리에서 변경한 모든 내용을 마지막 커밋 상태로 되돌립니다.
• 파일 변경, 새 파일 추가 또는 기존 파일 삭제가 포함됩니다.

깃허브

• Git 을 사용하여 버전제어를 하기위한 웹 호스팅 서비스

개인 인증 토큰

• 모든 저장소에 대한 권한 부여.
• 깃허브

개인 인증 토큰 삭제 (다른 컴퓨터에서 Git 연결하려면)

git credential-osxkeychain erase
host=github.com
protocol=https

특정 레포지토리에 공동작업자 추가

• 비공개 레포에 공동 작업자 추가

멘토링 QnA

Q. 신입 백엔드 개발자(스프링 기반)가 갖춰야할 역량의 미니멈은 어느 정도 수준일까요? 당연히 모든 면에서 깊이있게 잘 알고 있다면 좋겠으나, 현실적으로 ‘최소한 이 정도는 갖췄으면 좋겠다’ 하는 수준이 어느 정도인지 자세히 알고 싶습니다. (프레임워크, DB, CS 지식, 등 너무 분야가 넓을 수도 있을 것 같은데 만약 그렇다면 일단 가장 중요한 한 두가지만 골라서 말씀 해주셔도 감사하겠습니다)

• 기본적인 CRUD 개발은 해야하고, 면접질문에서 나오는것들이 최소 역량이야. 예를 들어 'Spring 서블릿까지 처리되는 과정. 스프링의 플로우를 이해하고 쓰는가? '

• 인증 인가 정도는 구현해봤으면 좋겠다. 필터에서 처리하는 것이 스프링 전체의 과정에서 어느 과정에 있고, 그것이 전체 플로우에 얼마나 영향을 미치는가 등 스프링의 주요 플로우 의도를 파악하는게 중요한거같아.

• 데이터베이스는 기본적인 쿼리 작성 수준은 되야하고, 인덱스를 어떻게 잡는가에 대한 개념. 그렇지만 기본적인 수준에서의 쿼리들은 작성할 수 있어야한다.

• CS 지식은 그 원리를 파악하면서 공부해야해. 원리를 잡기 위해서 CS 지식이 필요한데, 이걸 알고 있는가가 메인 중점.
  Ex) 소수점 연산에서 오차가 발생할 수 있는 문제 등, 언더플로우 오버플로우가 왜 발생하는가?

• 오류를 찾을 수 있는건 CS 깊이와 연관이 있기 때문이야.

Q. 안녕하세요! 비전공자이고 경력도 없는데 정보처리기사 외에 다른 자격증을 더 취득하는게 나을까요?(서버 등등,,,) 아니면 포트폴리오에 더 시간을 쓰는게 맞을까요?

• 포트폴리오를 높이는게 훨 좋다. 포트폴리오의 문제해결 과정 기록을 남겨놓는다면 훨씬 가치가 있어.
• 조급해하지말고, 꼭 기록을 많이 남겨놓아야해.

Q. 저번에 말씀하신 부분에 대해, 기술스택이 해당기업에 부합하는 것 보다 부합하지 않더라도 본인만의 기술스택들의 사용이유, 깊이있는 지식 등이 오히려 더 매료시킬수 있다는 것으로 이해했습니다! 타입스크립트나 next.js 등을 사용하는 기업에 가고 싶다고 가정했을경우, 비교적 얕게 공부하더라도 해당 공부들이 우선 되어야할지, React,js로 한 프로젝트에서 그런 문제해결능력이나, 기타 라이브러리, 툴사용에 대한 본인만의 고민을 잘 녹여내는 것과 본인이 진행해본 기술스택을 좀더 심도있게 학습하는것이 우선되어야할지 궁금합니다.

• 넓이 있는 경험보아 < 깊이있는 경험에 훨씬 가치를 많이준다.

Q. 더하여 강사님께서 생각하시는 좀 더 경쟁력있는 프론트엔드 개발자로서의 역량이 무엇일지 말씀해주시면 감사하겠습니다! (문제해결능력, 알고리즘능력, CS지식, 백엔드지식, 넓은 프론트 기술스택, 프로젝트 경험....)

• 프론트엔드에서 문제해결능력이 좋은 사람은 구현 속도가 빠른 사람, 복잡한걸 단순화 잘하는 사람

• 프론트 엔드에서는 알고리즘능력은 조금 덜필요해. 채용전형에 합격할 정도면 되거든. 로데씨를 도배하는거 만으로도 해결이 가능해서 다루는 개체수가 작기 때문에 아무런 알고리즘을 써도 느리지 않거든.

• 넓은 프론트 기술스택 이건 별로 안 중요하다고 생각해.

Q. 멘토님께서 보시기에 ‘개발자로서의 문제해결능력’이란 무엇이라고 생각하시나요??

-이 책을 추천합니다.
https://www.aladin.co.kr/shop/wproduct.aspx?ItemId=22740732

Q. 그럼 예를들어, 시간 관계로 타입스크립트 학습이 본인생각에 얕게 되었을경우 면접에서,다뤄본적은 있지만, 잘 모른다고 솔직하게 말씀드리는게 나은방향일까요?

• 아는데까지는 이야기하고, 모르는건 모른다고 얘기하는게 좋다고 생각해.

Q. 프레임워크에 대한 역량에 대해서 인증인가 관련해서 말씀해주셔서, 최근에 spring security를 공부하면서 고민이 되었던 부분에 대해서 질문을 드려도 될까요? spring secutiry와 jwt로 인증과 인가를 구현하고자 할 때, JWT토큰이 서버측에서 만료가 되지 않는다는 취약점 때문에 refresh 토큰이 탈취되었을 경우를 대비해, 보통 redis를 이용한다는 것 까지는 이해했습니다. 그런데 혹시 redis나 여타 캐시 혹은 db에 refresh토큰을 저장해서 비교하는 방법 말고, jwt의 취약점을 보완 할 수 있는 다른 방법은 없을까요..?

• 토큰이 만료 되었다라는것은 모든 키관련 인증 방식의 보안 이슈. 이 부분은 그냥 발생할 수 있는 상황이라고 보면 좋아. DB 든 어디든 저장하지 않고 해결할 수 없는 방법은 없어.

• refresh 토큰을 저장하지 않고 쓰는건 어려워. 또한 탈취도 무조건 발생해.

• API 들은 다 허용하고, 특정 액션을 할때만 access 토큰을 재확인. DB의 IO를 최대한 줄이는 전략을 택해.

• 탈취 되어도 GET 은 마음것해라~. 대신 GET 이 아닌 경우에는 아무것도 할 수 없을 거야.

Q. 단편적으로 생각하긴 어렵겠지만, 시니어 개발자로서 주니어 개발자의 서류나 면접 전형을 보실 때 중점적으로 보시는게 있을까요?ex) 서류라면 - 프로젝트에서 어떤 기술을, 어떻게 구현했는지, 어떤 내용에 대해 블로깅 했는지, 블로깅 주기, 프로젝트의 난이도나 수 등 면접이라면 - 기술 스택에 대한 이해도, 깊이 등

• 어떻게 구현했는지 보다는 이걸 구현하면서 '이슈'가 없었을까? 이슈가 더 궁금해. 어떤 구현과정에서 이슈가 없는건 불가능하거든. 그 문제를 숨기는건 좋은 성향이 아냐.

• 문제가 발생했을때 어떻게 해결했을까를 초점에 맞춰서 본다.

• 학습한 내용을 위키처럼 정리한 블로그는 좋은 점수를 주기 어려워. 어떤 내용에 대해서 정리한것은 변별력이 없어. => 쓸데 없다.

• 블로깅 주기는 상관없어.퀄리티가 좋으면 개수는 상관없어.

• 블로깅 보다는 깃허브가 훨씬 좋아

• 프로젝트의 수는 안중요하지만 난이도는 중요해. 기술문제를 겪을만한 주제인가가 중요. 진짜 내가 사용하고 싶은 App을 만들었다 보다는 기술 이슈를 겪을 만한

데이터베이스 동시성 이슈를 어떻게 풀어나갈지에 대한지에 대한
엠큐를 써보고 싶었는데 엠큐를 쓸만한 프로젝트.

• 메이저 오픈소스 프로젝트에 작은건이라도 기여를 한사람이 있으면 좋은 점수를 준다.스타에 상관없이 내가 쓰는 패키지나 이런것에 기여를 한것이 유의미.

• Spring 에서 디스팩처 서블릿까지 서빙되기 과정. 인터셉트가 어느시점에 처리되는가 원리를 파악을 하고자해야해. 원리에 관심이 없으면 거의 탈락..

• 면접관과 소통을 하면서 대화를 하는것도 좋은 것같아.

Q. 아까 알고리즘 관련해서 생긴 궁금증인데 그럼 백엔드 측면에서 실무에서 알고리즘 능력이 많이 필요한가요? 현재 코딩테스트에 합격하기 위한 알고리즘 공부만 하고 있습니다. 아직 큰 프로젝트나 실무를 경험해보지 않아서 이를 잘 못느끼고 있는데 실무 프로젝트에서 알고리즘의 사용이 어떨때 많이 필요한지 궁금합니다.

• 프론트 보다는 훨씬 많이 필요해.

• 코테를 합격하기 위한 알고리즘을 공부하면서, 코테를 통해 실무역량을 매칭시키려고 노력해야해.

• 회사의 의도는 알고리즘을 적절히 선택할 수 있는 역량을 기대해. 동작원리를 파악하고. 적절한 선택의 기준이 무엇인가를 파악하는게 중요해. BIG O 표준법의 의미를 이해하는 사람이 좋아.

• 빅오 표기법이 좋은 알고리즘 쓰면 되는가가 착각이야.

• 실무는 빅오 보다는 N 이 작아야해. N 을 못줄이면 효율이 안나와. 그래서 그 부분을 이해하기를 기대하면서 코테를 보는거야.

• 주니어에게 보통 기대하고 전달하는것은 약간 심플한 작업의 경우. 심플한 문제는 알고리즘이 별로 안중요한데, 실제 큰 프로젝트에 무게감있는 일을 맡으면 점점 필요해져.

• 특정 알고리즘의 원리를 파악하기 보다는 핵심을 파악해서 10억건의 데이터를 처리한다 => 어떤식으로 처리량을 구현하고 배분해야 원하는 성능과 결과물을 낼 수 있을까? 이걸 기대한다. 데이터의 적절한 선택을 하는데 있어서 알고리즘이 필요한거야.

• 퀵소트를 외우는건 중요X . 매커니즘의 이해가 중요해. 특정 트리가 왜 어떨 때 사용이 되는가가 중요해.

Q. 프로젝트를 진행한다면, 현재 프로젝트에서는 일어나지 않을 상황(카오스 몽키 같은 라이브러리를 사용해서 시스템을 망가뜨린다면?과 같은 what if)을 생각해보고 대응책을 코드에 반영하고 기술하는 게 포트폴리오를 평가받을 때 플러스가 될까요?아까 답변 해주셨던 넓이, 깊이의 관점과도 연관되어 있는데,

1. 단순히 다양한 기술을 적용해 프로젝트를 만드는 것
2. 다양한 문제 상황을 생각해 보고 코드를 그에 맞게 작성하는 것
   중에 프로젝트를 만들 시간이 한정되어 있다 보니까 참 고민이 되는 지점입니다 ㅠㅠ

• 대응책이 얼마나 유의미한지에 대한 설득이 중요해. 퀄리티로 갈 수 있냐가 중요한데, 접근 자체는 재밌게 볼 수 있다. 다만 퀄리티가 중요해.

• 무조건 후자가 좋아. 원리파악을 하는 수준으로 해봐.

• 그 상황이 발생한다면 어떻게 할까? 이걸 많이 드러내는 사람한테 좋아.

• 그래서 다양한 기술을 마음껏 쓰는 프로젝트와, 깊이 있는 프로젝트 두개를 하는게 좋아.

Q. 백엔드에서는 DB동시성이슈를 겪는 프로젝트가 중요하다고 하셨는데, 프론트엔드는 프로젝트할때 어떤 기술이슈를 겪어보는 게 좋을까요?

• 느린 상황을 주는게 좋아. 강제로 지연을 발생하게 하는 기능을 넣어도 좋고, 서버가 느린 응답일때 빠르게 개선하는것.

• 복잡한 화면을 구현할때 어떤 기준으로 컴포넌트나, 재사용가능하게 코드 관리를 하느냐가 기술이슈는 아니지만 관심있게 볼 수 있어.

Q. 멘토님 오늘 깃 강의를 들었는데 커밋을 어떤 단위로 나눠서 해야할지 말씀주실 수 있을까요?

• 여러 커밋의 단위는 하나의 작업을 목표로 하는게 좋다. 커밋의 단위가 자신만의 기준을 세워야해. 어떠한 하나의 단위다- 하는거지. 내가 생각하는 하나의 작업기준을 정해야해.

Q. 면접 질문에 대한 공부를 어떻게 해야할까요?

• Git 에 저장된 유명한 면접 질문들 실제로 많이 쓰이고 있어.
• 면접질문은 유출이 잘되서 잘 찾아보는것도 의미가 있긴해.
• 면접 스터디도 좋고.