2021-11-25 수업 내용 정리

범고래·2021년 11월 25일
0

비트캠프 수업내용

목록 보기
2/20

(1) git에서 clone 하는 과정

  • $ USER_HOME은 실제로 찾으려고 하면 보이지 않는 폴더다.
    예를 들어 아파트가 분양 받을 당시 33평인데 실제로 거주구역의 넓이를 재보면 28평쯤 된다. 컴퓨터로 치면 이게 USER_HOME (C:\Users)이고, 나머지 5평정도는 아파트에서 공용공간 등으로 할당되어 있을 텐데 이는 윈도우가 차지하는 영역이다.

  • 마찬가지로 $ JAVA_HOME 은 (C:\tools\graalvm-ce-java17-windows-amd64-21.3.0\graalvm-ce-java17-21.3.0) 같이 자바 파일이 설치된 폴더를 말한다.

  • 보통은 $ USER_HOME 아래에 깃 저장소 만드는게 보통이고, (C:\Users\AAAAAAA\git) 내용물은 .git 안에 저장되는데, 이곳에 저장되는 파일들은 분산되어 저장되므로 직접 열어보면 파일의 형태를 찾기 힘들다. 이를 다시 작업 디렉토리로 꺼내려면 git client가 다시 합쳐서 복원하는 역할을 수행해주어야 한다.

  • 이렇게 저장하는 이유는 통상의 방식은 파일 크기가 너무 커지기 때문이다. 따라서 저장소 안엔 모든 내용이 있는 것이 아니라 수정사항, 수정시간 위주로 저장된다.

  • .git에서 꺼낼땐 checkout, 다시 넣을땐 commit이란 용어를 사용한다.

(2) add / commit / push의 관계

  • 파일을 commit하기 전엔 무조건 add하여 스테이지(백업명단 안에 등록) 하여야 한다.

  • add 이후 commit을 수행하여 작업 디렉토리에 있는 파일 중 백업 명단에 등록된 파일을 로컬 저장소에 보관한다. 해당 순서를 따르지 않을 경우 commit이 불가능하다.

  • commit 이후 push 하여 로컬 저장소의 내용을 서버 저장소에 업로드한다.

    ※ 작업폴더에서 서버 저장소로 직접 push는 불가능하다.

(3) push /pull 에서의 충돌 및 병합

  • 동일한 파일을 pull을 한 경우 여러 개발자가 동시에 원본을 수정한 ver 2를 올릴 수는 없다.
  • 나중에 저장소에 push를 하고자 하는 개발자는 ver 2를 다시 pull 한 후 자신의 파일과 merge하여 ver 3를 만들어 push 해야만 올릴 수 있다.

(4) 이클립스 및 VS CODE 설정 및 플러그인 설치

(5) 어플리케이션 빌드와 실행

  1. 인터프리터 방식
  • 개발자가 명령문을 작성하고, 이를 해석하는 해석기(Interpreter)를 통해 운영체제에 전달하고 실행하는 방식이다.

  • 명령문 작성 언어를 programming language 라고 한다. programming이란 컴퓨터가 해야할 일을 기술하는 것을 뜻한다.

  • ex) js개발자가 명령문을 작성하여 (Hello.js) v8 js inerpreter에 전달하면 해석하여 os에 전달하여 실행한다.

  • 특징
    1) 소스 파일이 있어야 한다.
    2) 인터프리터가 설치되어 있어야 한다.
    3) 실행할 때마다 문법검사를 수행한다. 즉, 컴파일 방식에 비해 실행속도가 느리다.
    4) 인터프리터만 설치되어 있다면 os와 cpu에 상관없이 실행 가능하다.

  1. 컴파일 방식
  • 명령문 작성하면 번역기(컴파일러)를 통해 기계어로 바뀌고 이를 실행시키는 방식이다.

  • ex) c/c++ 개발자가 명령문을 작성하여 (Hello.c & Hello.cpp) 컴파일러로 전달한다. 문법검사 , 최적화가 실행된 후, .exe로 기계어가 나오고 실행된다.

  • 특징

    1) 인터프리터 방식보다 실행속도가 빠르다. 그러나 기계어로 바꾸기 때문에 os나 cpu가 다르면 실행이 불가하다.

    2) 소스코드가 없어도 cpu + os에 맞는 바뀐 기계어(실행파일)를 가지고 있으면 실행이 가능하다.
    즉, 실행에 소스와 컴파일러가 필요 없다.

  1. 하이브리드 방식
  • 컴파일 방식과 인터프리터 방식이 합쳐진 경우이며 과정중 가장 많이 다룰 자바가 이를 사용한다.

(6) V8 자바스크립트 엔진과 Node.js

  • 크롬엔 V8과 webkit, 2개의 핵심엔진이 있다.

  • webkit은 html과 css를 처리하는 기능을 하고, v8은 javascript를 처리하는 기능을 한다. 하지만 그냥 js 파일이 아니라, html 파일 안에 <script>태그를 넣고 그 안에 js 코드를 넣은 형태로만 가능하다.

  • Node.js는 V8 오픈소스 엔진을 탑재하고 있으며, js 파일을 일반 프로그래밍 언어처럼 CLI 환경에서 바로 실행가능하도록 만들어주는 역할을 한다.

(7) CPU와 명령어

  • cpu마다 명령어가 다르다. 예를 들어, 인텔 cpu(i7, i9)는 인텔 cpu가 이해할 수 있는 명령어로 작성한 명령문만 가능하다.

  • 다른 cpu라도 같은 명령어를 사용할 수도 있다. 예를 들어, amd cpu(라이젠)는 인텔 cpu 명령문을 처리할 수 있게 만들었으며 이를 인텔 호환 cpu라 한다.
    인텔용 프로그램을 따로 변환할 필요 없이 그대로 실행가능하다.

  • 반면, arm cpu (애플 - m1, m1pro, m1max / 삼성 - 엑시도스) 등은 인텔 명령문은 실행이 불가하다. 이를 실행시키기 위해서는 arm cpu가 이해할 수 있는 명령어로 작성되어야 한다.

(8) CPU와 OS

  • 인텔 cpu 기계어로 번역한, 윈도우 11의 경우 인텔 cpu서는 기동한다.
    만약 마이크로소프트에서 amd cpu에서 윈도우 11이 돌아가게끔 따로 만들지 않는 이상 원래는 돌릴 수 없는 게 정상이나, amd cpu는 애초에 인텔과 호환되게 만들어서 해당 윈도우 11의 기동이 가능하며, 인텔 cpu의 명령을 그대로 실행할 수 있다.

  • 반면, arm의 경우 cpu 명령이 다르기 때문에, 기존의 인텔용 윈도우를 arm cpu에서 실행할 수 없다. 해당 윈도우 11과 호환이 되지 않으므로, 제공되는 arm 윈도우를 따로 깔아야 한다. (windows 11 on arm)

    ex 1) 동일한 intel cpu에 하나는 window 11, 다른 하나는 리눅스가 설치되어 있다. application은 같은 인텔 cpu 명령어를 사용하고, 윈도우 11의 포멧에 맞춰 명령어를 나열한다.
    이 경우 같은 app이 실행 가능할까?

    기계어가 인텔 cpu 명령어인 것은 맞으나, 리눅스가 원하는 포멧으로 명령어가 나열되지 않았고, 리눅스에 없는 윈도우 가능을 이용한 명령이 들어 있으므로 실행이 되지 않는다.

    ex 2) 각각 다른 호환성의 cpu에 같은 window 11이 설치되었다. 인텔 cpu용 명령어를 사용하고, 명령어 포멧은 같다.
    이 경우 같은 app이 실행 가능할까?

    명령어를 작성한 후 컴파일을 통해 번역하는게 순서지만, 인텔 cpu용 명령, window 11 포멧이므로 arm에선 실행조자 될 수 없다.

    ※팹리스 : 공장 없이, 설계도만 만드는 업체를 의미한다.
    ※파운드리 : 설계도를 받아서 만들기만 하는 업체를 말한다.

(9) 안드로이드 앱과 CPU와 OS

  • 안드로이드 앱의 경우 제작 후 바로 플레이스토어에 올라간다.

  • 다운로드받기 직전에 컴파일이 되고, 그 다음에 다운로드 받는 방식을 사용한다.

(10) 인터프리터의 동의어

  • Engine

  • VM (Virtual Machine)

  • player

  • Runtime Engine(Runtime)

profile
끝없는 대양에서의 항해를 위해

0개의 댓글