일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | ||||
4 | 5 | 6 | 7 | 8 | 9 | 10 |
11 | 12 | 13 | 14 | 15 | 16 | 17 |
18 | 19 | 20 | 21 | 22 | 23 | 24 |
25 | 26 | 27 | 28 | 29 | 30 | 31 |
- JS Blob
- JS 이미지 미리보기
- 타입스크립트 필수 설정
- TypeScript config
- 프론트 이미지 업로드
- ts 프로젝트 설정 추천
- Null vs Undefined
- ts 필수 설정
- why use interface?
- 인터페이스 vs 타입
- Blob 사용하는 이유
- 공부
- 이미지 서버에 업로드
- 타입스크립트 설정값
- ts.config.json default setting
- Blob이란?
- ts 기초 설정
- Blob?
- Typescript Study
- 인터페이스 타입 비교
- TypeScript
- Blob 청크
- ts 설정
- Typescript Handbook
- Interface vs Type Alias
- ts.config.json
- TypeScript Undefined Null
- ts 설정값
- firebase server
- TypeScript Deep Dive
- Today
- Total
목록전체 글 (12)
RPG처럼 웹 개발하기

React 코드를 작성하던 저는 동료에게 이런 질문을 받았습니다. **님 React 클래스형 컴포넌트 써보셨나요? 왜 함수형 컴포넌트만 쓰는건지 정확한 이유를 잘 모르겠어요 일단 함수형 컴포넌트 작성법이 훨씬 쉽고 React 공식문서에서 권장하는 방법이니까요? 이렇게 대답한 저는 더 정확한 정보를 알려주지 못한 미안함과 React를 사용하고 있으면서도 자세하게 모르고 있었던 저 자신에게 부끄러움을 느꼈습니다. 그리고 해당 질문으로 React 문서를 찾아보게 되었습니다. “언제부터 이렇게 자연스럽게 함수형 컴포넌트로만 React를 사용하게 되었지?” 기존에 Vue 2 를 사용하여 웹 개발을 하고 있었고 회사가 사용하는 프레임워크가 변경됨으로 인해 React로 넘어왔기 때문에 공식문서를 빠르게 찾아보고 왜 ..

HTTP ? 텍스트 기반의 통신 규약으로 인터넷에서 데이터를 주고 받을 수 있는 프로토콜 입니다. 클라이언트가 요청(request)을 보내면 서버가 요청사항에 맞는 응답(response)을 보내는 형태로 작동합니다. (요청) 진구 : 도라에몽! 어디로든 문 내놔! (응답) 도라에몽 : 으..응..! 특징 TCP / IP 를 이용하는 응용 프로토콜 입니다. (인터넷을 통해 데이터를 주고받는 기능을 이용하는 응용 프로토콜) 연결상태를 유지하지 않는 비연결성 프로토콜 입니다. (요청과 응답형태로 작동) 무상태성(stateless) 프로토콜 입니다. (서버가 두 요청간에 어떠한 데이터도 유지하지 않음) TCP : 두개의 호스트를 연결하고 데이터를 교환하게 해주는 프로토콜입니다. IP : 인터넷에 연결되어 있는 ..

인터넷 (네트워크) 의 작동 원리 인터넷? 인터넷의 가장 기본적인 것은, 컴퓨터들이 서로 통신이 가능한 거대한 네트워크라는 것입니다. 두개의 컴퓨터가 서로 통신을 할때, 두 컴퓨터는 물리적 또는 무선으로 연결되어야 합니다. 하지만 위처럼 컴퓨터를 연결하게 된다면 컴퓨터가 많아지는 상황에서는 아래처럼 상당히 복잡한 연결을 하게 됩니다. 위처럼 복잡한 문제를 해결하기 위해 컴퓨터와 컴퓨터 사이에 라우터라는 소형 컴퓨터를 두고 연결됩니다. 라우터의 역할은 각 컴퓨터 사이의 다리 역할이며, 전달받은 데이터를 정확한 지점으로 전달해줘야 합니다. 하나의 라우터만 사용가능한것이 아니라 여러개의 라우터를 연결하며 라우터에서 라우터로, 무한히 확장할 수 있습니다. 하지만 우리는 주변의 사람들에게만 연결할것이 아니고 아주..

“Github branch” 어떻게 사용하고 계신가요? Github branch 전략에 대해 알고 계신가요? 저희 개발팀은 프로젝트를 개발할 때 기능별로 브랜치를 생성하거나, dev 브랜치를 생성해서 곧바로 master 브랜치에 올리곤 했습니다. 프로젝트 단위가 크지 않고 프로젝트에 들어가는 개발자의 수가 많지 않았기 때문에 큰 문제는 보이지 않았습니다. 하지만 프로젝트에 들어가는 개발자의 수가 많아지면 많아질수록 브랜치 관리가 제대로 이루어지지 않아 수많은 브랜치가 존재했고 잦은 conflict 가 발생했으며, master 브랜치에 곧바로 커밋 푸쉬를 진행하는 상황까지 발생했습니다. 당연히 문제가 발생했고 커밋 푸쉬를 하기 전 해당 프로젝트에 참여한 모든 개발자분에게 “이거 지금 마스터에 푸쉬해도 되나..