im-d-team/dev-docs

내가 일주일간 공부하거나 알게된 내용을 공유하는 공간 📱

Im-D Blog

MockUp Design

• draw.io
• 메인 색상

Page

• index : 메인 페이지
• blog : blog 페이지
• tag : tag 검색 페이지
• blog post : 블로그 Post 페이지

Component

• AuthorCard
• Card
• Header
• NextCard
• Pagination
• Post
• PostList
• Tag
• TagList

Data

• Avatar Image(추후 URL로 변경 예정)
• Author
• Blog Post Markdown

Feature

• Tag 검색
• 블로그 포스트 내 이동
• 페이스북, 깃헙 이동
• 사진클릭시 깃헙 이동
• 댓글

🔒 Post Rule

• 새로운 포스트는 data/blog/ 하위에 YYYY-MM-DD--Title의 형태의 디렉토리를 만들어 작성한다.

  • 디렉토리의 Title에는 영문만 작성한다.
  • 해당 디렉토리 안에 index.md를 만들어 글을 작성한다.

• index의 최상위에 적어야하는 내용은 아래와 같다.

  title: 'test 문서입니다.'
  createdDate: '2019-03-16'
  updatedDate: '2019-03-17'
  author: Jinseong
  tags:
  
  - rendering
  - optimization
  - browser
  - html
  - css
  - http
  
  image: test.jpg
  draft: false
  
  ## markdown 올바르게 작성하기
  

  • 글 작성시 사용되는 resources는 모두 같은 디렉토리에 담는다.
  • title은 글 내부의 제목이며 외부에 노출되는 제목이기도 하다.
  • 게시글은 createdDate를 기준으로 정렬된다.
  • author는 data/author.json에 미리 입력해둔 정보를 이용한다.
  • tag는 검색에도 이용되니 최대한 자세히 적고 camelCase를 이용한다.
  • image는 thumnail과 게시글 최상위의 사진이다.
  • draft를 통해 작성하고 있는 글은 숨길 수 있다.
  • title을 적기 때문에 h1의 내용은 따로 작성하지 않는다.

• prettier를 적용하여 문서작성 스타일을 통일시킬 것. (vscode 플러그인)

dev-docs's Issues

test

레포를 더럽히지 않고 사진올리기

로컬사진을 자신의 레포에 올리지 않고 .md 파일에 추가하는 방법을 소개합니다.

사진을 깃헙 저장소에 넣고 사용해보기

Reporsitory 관리 방법 논의

Reporsitory 관리 방법 논의

앞으로 Dev-Docs Repository 관리 방안에 대해서 의견을 제시하고 방향성을 정해보는 시간

Contributors

추가 의견은 Comment로 달아주세요. 👍 Comment에 대한 결정의 과반수 혹은 대다수가 만족하는 경우 반영하도록 합니다.

👉 @BKJang @SeonHyungJo @Dae-Hwa @Eugene94 @JHRla

자신의 글을 올리는 방법(== Pull Request하는 방법)

[다른 이슈로 빼기]

❗️ ❗️ 꼭 지켜주세요 ❗️ ❗️

1. 커밋 메시지

커밋 메시지는 통일을 합니다. 기본적인 이모지와 이름은 통일을 하며 뒤에 나오는 내용은 자유롭게 합니다. 단, 다른사람이 봐도 알아볼 수 있도록 합니다.

:pencil2: {자신의 이름} / {자세한 내용}

ex) :pencil2: SeonHyungJo / Add 최신_브라우저의_내부_살펴보기.md

2. PR Branch

PR을 하는데 사용되는 브랜치는 통일을 합니다.

{ Date }/{ your_name }

ex) 20190512/SeonHyungJo

모든 날짜는 매주 일요일을 기준으로 하며 뒤에 위치하는 이름은 커밋메시지의 이름과 동일하게 합니다.

이렇게 사용하는 이유는 /를 기준으로 하나의 폴더처럼 보이게 되어 날짜별로 각각의 브랜치를 나눌 수 있으며 추후 1주가 밀리게 되는 경우 같은 브랜치를 사용하지 않는 방법으로 도입하게 되었습니다.

Merge 작업 관련

• Merge 작업은 일주일 동안 서로서로 리뷰를 달아준다.
• 차주 같이 보면서 내용을 살펴보고 추가 수정내용 확인 및 Merge를 진행한다.
• Merge된 브랜치는 삭제한다.
• 차주 작업된 내용은 Meeting-Minute, Dev-Docs READEME.md에 적는다.

Label(완료)

• needs review : 리뷰가 필요한 PR
• approval + 1 : Reviewer 중 1명이 승인한 경우(Comment와 함께 작성)
• approval + 2 : Reviewer 중 2명이 승인한 경우(Comment와 함께 작성)
• needs author response : 작성자의 응답이 필요한 경우

[공지사항] PR, Review 남기는 방법, Approve 방법

PR을 날리는 과정 살펴보기

기존 : fork를 해서 PR을 날리는 방법
현재 : Im-D/Dev-Docs 를 clone 받아서 처리하는 방법

Repo 내려받기

1. 자신이 원하는 위치로 이동한다.
2. git clone으로 해당 레포지토리를 내려받는다.

git clone https://github.com/Im-D/Dev-Docs.git

서버에 커밋하기

1. 자신의 브랜치를 만든다.

브랜치를 만드는 기준은 관리 방법 논의에서 나온 기준으로 만든다.

{ Date }/{ your_name }
Ex) 20190512/SeonHyungJo

2. 자신의 글을 맞는 폴더 위치에 만든다. (맞는 폴더가 없는 경우 새로 생성한다.)
3. 글작성이 완료되면 add, commit을 한다.

커밋메시지는 관리 방법 논의에서 나온 기준에 따라 적는다.

:pencil2: {자신의 이름} / {자세한 내용}

ex) :pencil2: SeonHyungJo / Add 최신_브라우저의_내부_살펴보기.md

4. 서버에 push를 한다.

push를 할 때는 자신의 현재 브랜치를 확인하고 서버의 자신의 브랜치와 동일한 브랜치에 push를 한다.

git push origin { Date }/{ your_name }
// ex) git push origin 20190512/SeonHyungJo

PR작성하기

1. Im-D/Dev-Docs에 들어가서 새로운 pull request를 만든다.

2. pull request 작성시 제목은 커밋메시지의 뒤에 있는 내용을 적어준다.

ex) 최신 브라우저의 내부 살펴보기

3. reviewer는 모든 contrubutor로 설정한다.

4. label은 기본값으로 needs review를 넣는다.

5. ❗️ PR내용에는 자신이 작성한 글의 주소를 넣어주세요 ❗️

서버에 push를 하게되면 자신의 브랜치가 생성이 된다. 자신의 브랜치로 변경을 한 후 작성한 글로 이동하여 주소창에 주소를 복붙하면 된다.

Review 방법

내가 보고자 하는 PR을 들어가게 되면 상단에 FileChanged를 클릭한다.

리뷰를 하고자 하는 line에 마우스를 올려놓게되면 +버튼이 생기게 되고 클릭을 한다.

해당 라인에 대한 Comment를 남긴다.

우측 상단에 위치한 finish your review를 클릭하여 자신의 리뷰를 등록한다.

등록하게 되면 PR의 하위에 생성이 된다. 또한 해당 리뷰에 Comment를 올릴 수 있어 소통이 가능하다.

반영이 완료가 되거나 끝난 리뷰는 해결처리를 한다.

Approve 방법

해당 PR에 대해서 나는 승인을 했다라는 의미를 부여한다.

File Changed에서 Approve를 선택하고 Comment를 날려주면 된다.

기본은 아래를 따른다.

확인했습니다. 👍 

Github Custom Notification 사용하기(사용자 설정)

새로운 기능으로 추가된 Notification 설정하기

새로 추가된 기능은 최하단에 위치한 Custom이다.

Custom을 클릭해서 들어가게 되면 아래와 같이 3가지를 Checkbox로 선택할 수 있으며 @mention이 추가되면 알림이 오는 방식이다.

우리 스터디원들은 Issue와 Pull Requests 정도만 해도 된다.

Slack Issue open TEST

Slack Issue open TEST

커밋 메시지 형식

커밋 메시지를 좀 더 알아보기 좋은 형태로 변경하자.

위와 같이 나온 배경은 아래의 링크를 들어가면 알 수 있습니다.
⬇️
#138 (comment)

---

해당 이슈에서 확정된 내용은
https://github.com/im-d-team/Dev-Docs/blob/master/Rules/Commit.md
에 업데이트됩니다.

❌ Deprecated Table

file	deprecated
Browser / 웹 브라우저의 작동 원리	웹 브라우저의 작동원리
Language / 함수형 프로그래밍	Functional
Javascript / Module	Module B_Module AMD와 CommonJS
Language / Currying	Functional
Language / 고차함수(High Order Function)	Higher Order Functions
Javascript / Build Tool	Build_Tool
Javascript / Event Delegation	이벤트 위임(Event Delegation)
Performance / Repaint Reflow	Repaint와 Reflow
Language / Reactive	Reactive
Javascript/ 이벤트 루프(Event Loop)	EventLoop_Advanced B_EventLoop EventLoop
Javascript/ MutationObserver, ResizeObserver, intersectionObserver	EventLoop_Advanced
기본적인 렌더링 최적화 방법	기본적인 렌더링 최적화 방법
Async-Await	Async-Await
CallByReference	CallByReference
Promise	Promise1 Promise2
setState	setState
CSS Animation vs JS Animation	CSS 애니메이션 vs JS 애니메이션 Animation
CORS	JSONP(JSON Padding)와 CORS(Cross-Origin Resource Sharing)
쓰로틀링과 디바운싱	throttling과 rAF 쓰로틀링과 디바운싱
점진적향상 우아한하향	점진적향상 우아한하향
XSS	XSS와 CSRF
CSRF	XSS와 CSRF
rAF	throttling과 rAF

test (1)

2019 Google I/O Extended

Session1. What’s new in web

신속성

• 이미지 레이지 로딩
• google chrome hands on update (canalia)
• light house / peformance budget

확장성

• web perception toolkit
• Sharing API
• Duplex on the web - google io keynote 25:00)

안정성

• HTTP vs HTTPS
• 프라이버시 제어를 더 쉽게(사용자가 자신의 데이터의 사용 정보에 대한 접근성 향상)
• Same site Cookie(CSRF에 대한 보호) = 쿠키 헤더 : ‘sameSite:strict’
• Fingerprinting Protection

현재 웹의 한계 & 극복

• Native app vs Web (App Gap) : PWA(Progressive Web App)

Session2. Flutter 알아보기

크로스 플랫폼

• 하나의 코드로 다양한 플랫폼에서 동작
• 기존의 Native 경험을 해친다
• 크러블 슈팅의 어려움

크로스 플랫폼 언어의 종류

• Xamarin
• RN(React Native) : JS bridge를 통해 통신하기 때문에 성능 고려 필요
• Flutter
• Electron
• Kotlin/Native

Flutter

• Fuchsia OS의 애플리케이션을 만들기 위해 만들어졌다가 발전
• Dart라는 언어를 기반으로 개발
• Skia를 통해 캔버스에 바로 렌더링(Skia : 안드로이드 내부에서 화면을 그릴 때 쓰는 그래픽 엔진)
• 낮은 버전의 os도 지원 가능
• Cupertino(iOS), Material UI(Android) 를 주로 쓰지만 꼭 쓰진 않아도 됨
• Platform 구분으로 Widget 구현
• Row, Column으로 화면 구성(RN의 flex)
• 플랫폼을 모든 위젯마다 나눠서 개발해줘야 하는게 가장 큰 단점이 아닐까?(모듈화가 필수)
• 비동기 호출은 async/await를 사용하며 JS의 async/await와 구현 방식은 동일
• Flutter desktop의 상용성이 높아진다면 꽤나 강력할 수 있을 것 같음

Flutter Web

• Skia가 아닌 js 컴파일러를 통해 브라우저에서 그리게 됨
• 아직 지원하지 않는 Widget이 꽤 됨
• 아직은 프리뷰 버전
• 디버그 모드에서만 동작
• 아직은 사용하지 말자.

Session3. Google Search and Javascript sites

우리가 만든 사이트는 어떻게 구글 검색에 노출될까

Javascript의 사용성

• 전통적인 웹 사이트: 사용자의 인터렉션만을 위해서만 사용
• 현대의 웹사이트: ajax로 데이터만 주고 받고 콘텐츠를 js로 생성한다. 자바스크립트를 이해하지 않고는 콘텐츠를 이해할 수 없다.(google bot + pupeteer)
• 즉, 우리가 만든 spa사이트는 검색 결과에 더 이상 노출에 영향을 미치지 않는다.
• 상위 노출의 문제 : SEO(검색엔진 최적화)

[SEO]Robots.txt

• 구글 봇이 어디까지 크롤링할 것인가 => 보통 크롤링을 막기 위해 사용하지 더 검색이 잘되기 위해 사용하진 않음
• 검색이 아예 되지 않게 하려면 : 도메인을 통째로 나누는게 어떨까
• 검색이 되지 않아야 하는 내부 페이지 : 인증을 거쳐야만 볼 수 있도록 하면 크롤링 되지 않음

[SEO] 올바른 <title>의 사용

• 적절한 콘텐츠를 설명하면서도 사이트를 잘 설명하도록

[SEO] 올바른 description의 사용

• 선언과 충분한 설명이 필요
• 제대로 해놓지 않으면 컨텐츠의 일부 내용들을 가져와 검색 결과에 노출

[SEO] 올바른 HTML 사용

• navigation : 구글 검색은 기본적으로 검색을 기반으로 크롤링
• 제목 : 태그를 주로 사용

[SEO] 반응형 웹 디자인

• 모바일을 지원하는 페이지를 우선적으로 노출
• 모바일을 지원하는지 아닌지 판단하는 기준은 pupeteer에서 나름대로의 알고리즘으로 판단하는데 이는 light house를 한 번 돌려보면 가능

[SEO] Structured Data 사용

• 데이터를 통해 컨텐츠를 소개(schema.org) => 구글 서치에서 지원하는 structured data는 검색!

[SEO] Light house

• 현재 웹 페이지의 성능 등을 분석해주는 Tool (web.dev로 들어가면 light house 지원 항목 확인 가능)

[SEO] 그 이외..

• 속도!
• 모바일 지원!
• 국내 웹 사이트 : 나무 위키가 가장 잘 되어있음...(SEO와 컨텐츠의 관련성은 없음..)
• festa도 Good 👍

즉, SPA는 검색 결과에 영향을 주지 않는다!

Github에서의 Auto Branch Delete기능에 따른 Mergify Rule 변경

요즘 Github에서 sponsor, template 등등 새로운 기능 마구마구 만들어 내고 있는데, 이번에? 새로 추가된 기능으로 Merge된 브랜치를 자동으로 지우는 기능이 생겼습니다.

이는 기존에 우리가 사용하고 있는 Mergify Rule과 동일한 기능입니다.

결론적으로

• mergify.xml rule 제거
• Dev-Docs Auto branch delete 기능활성화

수정을 원합니다.

어떠신지 의견주세요

마크다운 형식 정하기

#138 (comment)

🔨 Dev-Docs Fix up Progress

파일	주제	할당자	완료
렉시컬 속이기 - eval()	Scope
	eval()
웹 브라우저의 작동 원리	웹 브라우저의 작동 원리 (CSS, JS 위치 제외)	@devjinius	✅
Module	javascript의 module (시간의 흐름에 따라)	@SeonHyungJo	✅
	브라우저에서의 Module
함수형 프로그래밍	Functinonal Programming	@BKJang	✅
Currying	Currying	@BKJang	✅
고차 함수(High Order Function)	Higher Order Function	@BKJang	✅
Event Delegation	Event Delegation	@devjinius	✅
Javascript BuildTool	Javascript BuildTool	@SeonHyungJo	✅
Performance / Repaint와 Reflow	Repaint Reflow	@SeonHyungJo	✅
Virtual DOM	Virtual DOM	@devjinius	✅
Language / Reactive	Reactive	@devjinius	✅
Javascript/ EventLoop Advanced	Event Loop	@BKJang	✅
	MutationObserver, ResizeObserver, intersectionObserver	@BKJang	✅
Javascript/ EventLoop	Event Loop	@BKJang	✅
Javascript/ B_EventLoop	Event Loop	@BKJang	✅
렌더링 최적화	기본적인 렌더링 최적화 방법	@SeonHyungJo	✅
CallByReference	CallByReference
	Iteration Protocol	@BKJang	✅
	Generator와 async-await	@BKJang	✅
Callback hell	Callback hell
Promise	Promise
setState	setState
CSS 애니메이션 vs JS 애니메이션	CSS 애니메이션 vs JS 애니메이션	@SeonHyungJo	✅
CORS	CORS	@devjinius	✅
쓰로틀링과 디바운싱	Throttling, Debouncing
점진적향상 우아한하향	점진적향상 우아한하향	@BKJang	⚒
XSS와 CSRF	XSS
	CSRF
throttling과 rAF	rAF	@SeonHyungJo	⚒