How Far I'll Go

오늘 9장 협업, 소스관리, 디자인, 10장 정리 파트까지 다 읽었다. 드디어 완독! 뿌듯하자너~

깃(Git) : 리눅스 개발자 '리누스 토발즈'가 개발한 프로그램으로, 주된 기능은 소스코드의 버전을 관리

커밋(Commit) : 코드 변화를 기록하는 것

커밋 로그(Commit Log) : 무엇이 변화했는지, 무엇을 개발했는지 적어주는 메모

브랜치(Branch) : 개발 중에 새로운 방향의 개발을 추가해야할 때, 기존 개발에 이어서(덮어씌워서) 작업하지 않고 새롭게 가지를 쳐 작업하는 것. 하나의 프로젝트를 진행할 떄, 동시에 여러 기능을 충돌없이 작업할 수 있음

머지(Merge) : 각각의 브랜치에서 작업한 코드를 합치는 기능

원격저장소 : 깃허브(GitHub), 비트버킷(Bitbucket) 등이 있다.

가이드 : 디자이너와 개발자 간의 협업을 위해 필요한 디자인 요소의 넓이, 높이 등등의 수치. 디자인 작업 결과물의 수치를 보여주는 스케치, 재플린, XD 등의 프로그램을 활용

디자이너 : 각 프레임워크에서 제공하는 가이드 문서 숙지 필요

애플 기기 방침↓

https://developer.apple.com/design/human-interface-guidelines/guidelines/overview/

구글/안드로이드 기기 방침↓

https://material.io/design

개발자 : 디자인 구현을 위해 UI(User Interface)를 바라보는 감각 필요

기초 지식 쌓으려고 읽었는데, 개발자와 협업하는 사람들에게 도움이 될 만한 책이다.

앞으로는 점점 개발의 영역도 넓어질 것이고, 협업하는 분야도 많아질거라.. 알아두면 좋을 듯! 

이제 다음 스텝으로 넘어가서 웹 퍼블리싱 공부부터 시작이닷

(2)에 이어서... 6장 웹, 7장 데이터베이스와 이미지 처리, 8장 프레임워크와 라이브러리

요즘 돈 버느라 공부도 블로그도 못했다.

시간이 좀 지났지만 그래도 포기하고 놓아버리기 싫어서 다시 공부하고 기록.

HTML (Hyper Text Markup Language) :

• '유럽 입자 물리 연구소(CERN)'의 '팀 버너스리'로부터 유래
• 서로 다른 운영체제/애플리케이션을 사용할 경우, 파일 호환에 문제가 생길 수도 있는데, 이를 해결하기 위해 운영체제나 프로그램에 상관없이 일정한 형식(HTML)으로 작성한 문서를 제안
• HTML 문서는 브라우저만 있으면 웹사이트에 접속해 동일한 정보를 제공
• HTML은 정보를 체계화한 '태그'라는 코드로 구성 (like wikipedia)
• HTML은 '프로그래밍 언어'가 아닌 브라우저가 볼 수 있는 문서를 작성하는 언어

CSS (Cascading Style Sheet) :

• 정보전달에만 초점이 맞춰진 HTML에 디자인을 입히는 코드
• '디자인' 영역의 코드가 분리되어 HTML은 '정보'만 표현하고 CSS는 '디자인'만 표현해 보다 깔끔해짐

HTML + CSS 작업을 '퍼블리싱', '마크업' 작업이라고도 한다.

JavaScript : HTML / CSS로 구현하기 힘든 기능을 위해 웹쪽에서 프로그래밍 언어 역할을 하는 언어

cf) 검색어 자동완성의 경우 :

'a'까지만 사용자가 입력 → JavaScript가 'a'까지 타이핑한 것을 감지 → 실시간 검색어 목록을 조회하는 API 요청 (GET) → 검색포털 서버 → 'a'에 대한 실시간 검색어 목록을 JSON 형식으로 응답 → JavaScript가 응답을 열어서 HTML로 바꿈

웹 / 애플리케이션

• 우리가 웹에 들어가서 보는 것은 서버의 원본(HTML파일, 연결된 CSS, JavaScript, 이미지, 동영상..)을 다운받은 사본
• '새로고침' 즉, 페이지에 접근할 때 마다 바뀐 파일을 다시 다운받음 → 수정이 용이하고, 실시간으로 반영됨
• 단점 : 네트워크가 느리거나 인터넷이 마비된 환경에서는 다운로드가 느림 (네트워크의 영향을 많이 받음)
• 반면, 애플리케이션은 사용자 기기에 저장(cf. 카카오톡 대화는 폰에 저장)되기 때문에 네트워크의 영향을 덜 받음
• 네이티브 애플리케이션: 각 운영체제의 네이티브 언어로 만든 애플리케이션, 사용성이 좋음
• 하이브리드 애플리케이션
  • 애플리케이션의 특정 부분에 '브라우저'를 올리는 방식, 수정이 용이
  • 웹 부분/애플리케이션 부분은 API 문서로 파악
  • 웹과 애플리케이션 각각의 장/단점을 흡수 및 보완하며 발전한 방식

브라우저

• 브라우저의 역할: HTML에 적힌대로 정보를 보여주고, CSS에 적힌대로 디자인을 입혀주며, JavaScript에 적혀있는대로 동작하게 해줌
• 브라우저는 애플리케이션이기 때문에 사용하는 브라우저에 따라 그 안의 구현방식이 다름
• HTML, CSS JavaScript의 특정 기능이 브라우저별, 버전별로 작동하지 않을 수 있음 → '브라우저 버전의 파편화'
• 참고 : 브라우저/버전 별로 기능을 사용할 수 있는지 알려주는 사이트

반응형 웹

• 브라우저의 가로 넓이(스마트폰, PC, 패드 등 다양한 기기에 따라)에 '반응'하여 구성 요소가 변하는 기술
• 다른 CSS를 적용하는 것이 아니라, 공동으로 사용할 CSS 코드들은 두고, 레이아웃 위주로 나눠 작업해 각 기기의 디자인을 구현하는 방식
• 즉, 웹페이지의 크기(비율)가 사용자의 기기에 맞춰 자동으로 변형된다는 의미
• 넓이에 따른 CSS 코드를 추가하는 것보다 시간 및 비용을 절약할 수 있음

데이터

• '무결성' : 데이터는 단 1%의 결점도 없어야 한다.
• 관계형 데이터베이스 (RDB, Relational database) : 데이터 관리의 주요 방법론
• Schema, Database(구조) 안에 들어 있는 Table1, Table2, Table3(데이터)가 관계 맺고 있는 것
  • (cf. 엑셀의 Sheet: Table / 엑셀 파일 자체: Schema, Database)
• 관계형 데이터베이스 관리 시스템 (RDBMS, Relational database management system)
• 데이터들을 파일로 만들어서 저장하고 관리해주는 소프트웨어
  • cf. MySQL, OracleDB, MSSQL, MariaDB 등등
• 클라이언트와 서버 모두 데이터베이스 관리시스템(DBMS)를 돌릴 수 있고, 데이터를 저장할 수 있음
• cf. 스마트폰에서 알람시간(8:00, 8:10, 8:20...)을 맞춰두면 클라이언트의 데이터 (인터넷이 없어도 이용가능)
• cf. 앱스토어 화면은 어떤 스마트폰에서 접속해도 똑같음, 서버의 데이터
• 클라이언트: 로컬, 내부DB, 네이티브, 클라, 프론트, 프론트엔드
• 서버: API 요청, DB, 백, 백엔드
• API 문서로 어디의 데이터인지 확인 가능함

이미지 처리

• 이미지 파일은 클라이언트 혹은 서버 컴퓨터에 있음
• 각 컴퓨터는 이미지 주소를 통해 이미지에 접근
• 이미지를 교체하려면 파일을 바꾸거나 다른 주소로 지정
• API 문서에서 이미지 주소(URL)를 확인해 프론트엔드/백엔드 어느 영역인지 구분 가능
• 사용자가 업로드하는 이미지(SNS에 업로드하는 등)의 경우, '관계'가 있는 데이터이기 때문에 이미지 주소를 DB에 넣어서 관리

프레임워크

• 특정 소프트웨어를 개발하기 위해 제공되는 틀, 매뉴얼, 코드
• 거대 IT 회사들이 개발자들로 하여금 자사 애플리케이션을 쉽고 빠르게 개발할 수 있도록 프레임워크를 만들어 제공하는 경우
  • 애플 - Objective-c, Swift - Cocoa (UIKit, AppKit 등등) / 구글 - Java, Kotlin - Android Framework
• 특정회사가 소유하지 않는 웹의 경우
  • 웹 - JavaScript - Angular.js(구글 제공), Vue.js(Evan You 제공), React.js(페이스북 제공)
• 서버도 웹과 마찬가지로 특정 회사 소유가 아니기 때문에 다양한 프레임워크 존재 (아래는 각 언어별로 유명한 프레임워크)
  • Ruby - Rails / Java - spring / python - Django / JavaScript - Express.js

라이브러리

• 다른 사람들이 만들어놓은 코드를 이용한다는 측면에서 프레임워크와 같음
• 하지만 프레임워크가 큰 틀, 구조라면 라이브러리는 보다 작은 요소, 도구와 같은 개념
• 자유도가 더 높음, 예를 들어 한 프로젝트에 프레임워크는 하나만 쓸 수 있지만, 라이브러리는 함께 사용 가능

이제 이 책은 두 챕터가 남았다.

남은 두 챕터 화이팅해서 정리하고, Do it 시리즈 정리도 해야지

화이팅

(1)에 이어서 4장 API와 JSON / 5장 애플리케이션 읽고 정리.

4장 API와 JSON이 양이 많고 처음에 이해가 잘 안되어서 몇 번 다시 읽어야 했는데, 반복해서 읽고 필사로 정리하니 확실히 이해가 잘 된다! 100%는 아니어도 한 90% 이해한 것 같다. 뿌듯해~

API

• 클라이언트, 섭와 같은 서로 다른 프로그램에서 요청과 응답을 주고받을 수 있게 만든 체계
  • 이때, 요청을 '정확한 곳'으로 보내야 원하는 응답을 받을 수 있다. 이는 '서버주소/a'의 형태로 정의한다.
  • 이러한 기능을 만드는 것이 서버 개발자이고, 주소 정의는 서버 개발자의 주도하에 이루어진다.
  • 클라이언트 프로그램은 정해진 서버 주소에 요청을 보낸다. 즉, API는 서버 개발자가 개발하고, 클라이언트 개발자가 사용한다.
  • API를 통해 요청과 응답을 주고 받을 때는 데이터도 포함된다.
  • 클라이언트가 서버에 요청할 때, 요청은 데이터를 다루는 방식에 따라 크게 CRUD(Create, Read, Update, Delete) 4가지 요소로 나눌 수 있음
  • CRUD 별로 서버주소가 생기고, 너무 많아져서 관리가 힘들어지는 문제가 발생하기 때문에 REST(Representational State Transfer)ful API라는 사회 운동이 발생함. 
  • RESTful API는 CRUD를 하나의 주소로 관리하는 대신, 어떤 요청을 보냈는지 메소드(함수)로 파악한다.
    • Create : POST
    • Read: GET
    • Update: PUT(전체) / PATCH(일부)    데이터 전체 수정 / 데이터 일부 수정
    • Delete: DELETE
  • 클라이언트에서 요청을 보내면, 서버는 코딩된대로 생각하고 응답을 한다.
  • 응답에는 잘 되거나, 잘 안되거나 두가지 경우가 있다.
  • 잘 되었을 때: 200번 코드
  • 잘 안되었을 때: 클라이언트 요청 문제 - 400번대 코드(cf. 404) / 서버 문제 - 500번대 코드
  • 응답에 데이터가 필요한 경우도 있다.
  • 요청(Request)와 응답(Response)에 데이터를 주고받음으로써 API 요청이 완성된다.
  • 참고: HTTP 상태 코드

• 소프트웨어가 다른 소프트웨어의 기능을 쓰기 위해 중간에 필요한 체계. 쉽게 말해, 기능을 사용하기 위해 주소로 요청을 보내면 응답을 해주는 소프트웨어끼리의 체계
  • 클라이언트와 서버가 아닌, 한 컴퓨터에 여러 소프트웨어가 함께 있는 경우
  • 개발 중인 A 소프트웨어에서 B 소프트웨어의 b 기능을 사용하고 싶을 때, API를 사용해서 기능을 요청한다.
  • 이 API는 B 소프트웨어, 즉 응답을 보낸 쪽에서 만든다.
  • SDK(Software Development Kit): API를 제공해주는 소프트웨어
  • SDK를 설치하면 SDK에서 제공해주는 API를 통해 요청을 보내고, 개발 중인 소프트웨어에 기능을 넣을 수 있다.
• JSON: API로 요청과 응답을 (혹은 데이터를) 주고받을 때의 형식
• 깃북(Git Book): 깔끔한 API 문서 작성을 도와주는 서비스
• 애플리케이션: 설치해서 사용하는 모든 프로그램 (운영체제 위에 올라가는 프로그램, 설치해야 하는 프로그램, 응용프로그램, 애플리케이션, 어플, 앱 등을 모두 애플리케이션이라고 한다.)

냅다 코딩하던 시절에 서울시 Open API로 미세먼지 값 불러오기를 해봤었는데, 그땐 솔직히 API가 뭔지 알려주지도 않았고 알려줬다고 한들 100% 이해하지 못했을 것이다. 당시에 나오는 형식도 JSON이라는 사실을 이번에 알게 되어서 신기하고 재밌다. 역시 아는 만큼 보임

HTML/CSS/Javascript 공부를 3개월 정도 하다가 다시 또 3개월 멈춘 상태

사실 HTML/CSS/Javascript를 공부했다고 하기도 부끄러운 게, 냅다 실전으로 코딩부터 하는 인강을 들었었다.

컴퓨터에 대한 기초 지식은 1도 없이 시작하다보니 멈추니까 또 하나도 기억이 안 나서 

인터넷 검색으로 추천 받은 <비전공자를 위한 이해할 수 있는 IT 지식>을 읽고 나름대로 정리하는 걸

이 블로그의 시작으로 하려고 한다.

개발자: 프로그래밍 언어를 통해 운영체제 위에 돌아가는 프로그램을 만드는 사람

• 프로그래밍 언어: 컴파일러에 명령을 전달하기 위해 쓰는 언어 (cf. C언어, Java, Python ...)
• 컴파일러: 인간의 언어를 컴퓨터 언어로 변환해주는 프로그램
• 운영체제: 보조기억장치(HDD/SSD)에 있는 실행에 필요한 데이터를 메모리(RAM)로 가져와 CPU가 연산, 처리하는 과정을 담당하고, 하드웨어를 관리하는 소프트웨어 (cf. Windows, Android, Mac, iOS ...)

네트워크: 컴퓨터들이 연결되고 통신할 수 있는 것

• LAN: Local Area Network 
• MAN: Metropolitan Area Network
• WAN: Wide Area Network
• 클라이언트: 네트워크를 통해 서버에 데이터를 요청 //프론트엔드
• 서버: 네트워크를 통해 요청된 데이터를 전달 //백엔드
• 리눅스: 데이터 전달을 '처리'하는 서버 프로그램을 돌리기 위해 서버 컴퓨터에 주로 사용하는 운영체제
• IP 주소: 인터넷에 접속하는 순간 위치에 맞게 컴퓨터가 갖는 주소로 위치, 컴퓨터에 따라 고유함. 즉, 이동하면 IP 주소가 계속 바뀐다. 12자리 숫자가 마침표(.)를 이용해 네 가지 부분으로 구분되는데, 최근 컴퓨터 대수가 늘어남에 따라 한계가 있어(0~255의 숫자만 사용) 숫자 구분을 4개에서 6개로 늘린 IPv6를 함께 사용한다.