심심해서 nginx에 대해서 검색하고있었는데 비기너스 가이드 beginners_guide가 번역된곳이 없는거같아서 번역해본다.

영어실력이 미천하니 참고로만 봐주시면 좋겠다.

원본 링크 http://nginx.org/en/docs/beginners_guide.html

글 작성일 2021.06.08

목차

  • 시작, 멈춤, 리로딩 설정
  • 설정파일(컨피그파일) 구조
  • 정적파일(Static content) 제공
  • 간단한 프록시 서버 만들기
  • FaxtCGI Proxing 세팅

이 가이드는 nginx에 대한 기본적인 소개화 함께 nginx를 이용해서 수행할 수 있는 간단한 작업에 대해서 서술하고있다. 글을 읽는 사람의 시스템에 이미 nginx가 설치 되어있다고 가정하고 설명을한다. nginx가 아직 설치되지 않았다면 ** 인스톨 페이지 ** 를 참조하도록하라. 이 가이드는 nginx를 시작하는법과 멈추는법, 설정(configuration)을 리로드 하는법, 설정파일의 구조 설명, nginx가 정적 컨텐츠(static content)를 제공하도롱 설정하는법에 대한 설명, nginx를 프록시 서버로 설정하는법, FastCGI 애플리케이션으로 세팅 하는법에 대해 설명한다.

nginx는 하나의 마스터 프로세스와 몇개의 워커 프로세스를 가진다. 마스터 프로세스의 주된 목정은 설청파일을 읽고, 수행하는것과 워커프로세스를 관리하는것이다. 워커 프로세스는 실제 요청을 수행한다. nginx는 워커 프로세스 사이의 효율적인 요청(request)분배를 위해서 이벤트 기반 모델, OS 종속적인 메카니즘을 사용한다. 워커 프로세스의 숫자는 설청 파일에 정의되어있고 주어진 설정량 만큼으로 고정될수 도 있고 사용 가능한 CPU 코어 숫자에 따라서 자동으로 조정될 수 도 있다. (자세한 사항은 워커 프로세스 를 참조하라)

nginx와 모듈들의 동작 방식은 설정파일에 정의되어있다. 설정파일의 디폴트 이름은 nginx.conf이고, /usr/local/nginx/conf, /etc/nginx, /usr/local/etc/nginx의 경로에 위치한다.

시작, 멈춤, 리로딩 설정 Nginx Start / Stop / Configuration 리로드

nginx 시작을 위해선 실행 가능한 파일을 실행시켜야한다. 일단 nginx가 실행되면 -s 옵션을 이용하여 실행파일을 호출해서 제어할 수 있다.
아래와 같은 문법을 사용하면된다.

nginx -s signal

signal은 아래 중 하나가 될 수 있다.

  • stop -- 빠른 종료(fast shutdown)
  • quit -- 적절한 종료(graceful shutdown)
  • reload -- 설정파일 리로드
  • reopen -- log 파일 재 오픈

예를 들어서 워커 프로세스들이 현재 수행중인 요청을 완료할때가지 기다린 후 nginx프로세스를 종료하길 원한다면 아래와 같이 명령어를 실행하면된다.

nginx -s quit

|위 명령어는 nginx를 실행시킨 계정과 같은 계정에서 실행해야 동작한다.|

설정파일의 변화는 nginx에 리로드 명령어를 보내거나 재시작 하기 전까지는 적용되지 않는다. 설정파일을 리로드 하기 위해선 아래의 명령어를 사용한다.

nginx -s reload

마스터 프로세스가 설정을 리로드 하라는 신호를 받으면 마스터 프로세스는 새 설정의 문법 검사(syntax validity)를 수행하고 새로운 설정을 적용하려고 시도한다. 설정 적용에 성공하면 마스터 프로세스는 새로운 워커 프로세스를 실행시키고, 이전 워커 프로세스들에게는 종료 메시지를 보낸다. 설정 적용에 실패하면 마스터 프로세스는 설정을 롤백하고 이전 설정으로 작업을 진행한다. 종료 메시지를 받은 이전 워커 프로세스들은 새로운 컨넥션을 받는것을 중지하고 현재 요청을 완료한 후 종료된다.

요청(signal)은 kill같은 Unix툴에 의해서 전송될 수 도 있다. 이경우 요청은 주어진 Process Id를 참조하여 직접 프로세스에 전달된다. nginx의 마스터 프로세스의 process ID는 default로 nginx.pid 파일에 적혀저있고, 기본 경로는 /usr/local/nginx/logs 또는 /var/run에 있다. 예를들어 마스터 프로세스의 process ID 가 1628일 경우 nginx를 적절한종료(graceful shutdown)하기위해서 아래의 명령어로 QUIT 요청(signal)을 보낼 수 있다.

kill -s QUIT 1628

실행중인 nginx 프로세스를 리스트화 해서 보기위해서는 ps유틸을 사용할 수 있다.

ps -ax | grep nginx

nginx에 요청을 보내는 방법에 대한 더 자세한 정보를 원한다면 Controlling nginx 문서를 참조하라

설정파일(컨피그파일) 구조 Configuration File's Structure

nginx는 모듈로 구성되어있고, 각 모둘들은 설정파일에 명시된 지시(directives) 따라 컨트롤된다. 지시(directives)들은 간단한(simpmle) 지시 들과 블럭 지시들로 나뉘어진다. 간단한 지시는 스페이스(공백)로 나뉘어진 이름과 파라미터로 구성되어있고 마지막에 세미콜론(;)으로 끝난다. 블럭 지시는 간단한 지시와 같은 구조로 되어있으나 세미콜론으로 끝나지않고 중괄호({})로 둘려싸여진 추가적인 지시(instructions)들의 셋을 가지고있다. 블럭 지시는 중괄호 안에 다른 지시를 가지고 있을 수 있고, 이를 컨텍스트(context) 라고 부른다.(ex, events, http, server, location).

설정파일 의 컨텍스트 밖에 위치한 지시들은 main컨텍스트로 간주된다. event 와 http 지시는 main 컨텍스트에 위치하고, server 컨텍스트는 http 컨텍스트, location 컨텍스트는 server 컨텍스트에 위치한다.

# 표시 뒤의 글자들은 주석이된다.

정적파일(Static content) 제공 Serving Static Content

웹서버의 중요한 역할은 (이미지나 정적 html같은)file을 제공하는것이다. 우리는 요청에 따라서 적절한 위치에서 파일을 제공하는 예제를 구현해볼 것이다.
HTML파일은 /data/www에서 제공하고, 이미지 파일은 /data/images 에서 제공하도록 하자. 이렇게 하기위해선 설정파일을 수정해야한다. http블럭에 있는 server블럭에 두 경로를 세팅해보자.

먼저 /data/www 디렉토리를 만들고 index.html 파일을 만들어서 적절한 글자를 좀 써두자. 그리고 /data/images 디렉토리를 만들고 적절한 이미지 몇개를 넣어두자.

다음으로 설정파일을 열자. 디폴트 설정파일에 이미 server 블럭예제가 들어있다. 대부분 주석처리가 되어있다. 이제 모든 블럭의 주석처리하고 새로운 server 블럭을 만들어보자.

http {
    server {
    }
}

일반적으로 설정파일엔 몇개의 server블록이 포트번호와 서버 이름으로 구별되어있다. nginx가 어떤 서버가 요청을 수행할지 결정하면 서버브럭 내에 정의된 위치 지시문(location directives)의 파라미터에 대해 리퀘스트 헤더에 지정된 URI를 테스한다.

아래의 location블럭을 server블럭에 추가해보자.

location / {
    root / data/www;
}

이 location블럭은 리퀘스트의 URI와 비교할 "/" 프리픽스를 지정했다. 매칭되는 리퀘스트에서 URI는ㄴ root 지정된 root 경로를 추가하게된다. 즉, /data/www를 추가하여 요청된 파일을 로컬 파일 시스템의 경로로 연결한다. 매칭되는 location 블럭이 여러개 있다면 nginx는 가장 긴 프리픽스를 선택하게된다. 위의 location블럭은 프리픽스의 길이가 1이기때문에 다른 모든 location블럭이 일치되지 않는 경우에만 사용되게 된다.

이제 두번째 location 블럭을 추가해보자.

location /images/ {
    root /data;
}

위 블럭은 리퀘스트가 /images/로 시작되는 경우에 매칟된다. (/images/로 시작되는 요청은 location / 에도 매칭 되지만 /의 길이가 더 짧기때문에 /images/로 매칭된다.)

server블럭의 결과는 아래와 같을 것이다.

server {
    location / [
        root /data/www;
    }

    location /images/ {
        root /data;
    }
}

이 블럭은 이미 스탠다드 포트인 80포트의 요청을 리슨(listen)하는 서버의 설정으로 동작하게된다. 그리고 로컬 머신에서 'http://localhost/"에 연결할 수 있게 된다. /images/로 시작되는 URI 리퀘스트에 대한 응답으로 서버는 /data/images 디렉토리의 파일을 전송해줄것이다. 예를 들어서 "http://localhost/images/example.png" 리퀘스트에 대한 요청으로 nginx는 /data/images/example.png 파일을 전송해줄것이다. 만약에 해당 파일이 없다면 nginx는 404에러를 넘겨준다. URI가 /images/로 시작되지 않는 요청에대해서는 /data/www 디렉토리로 매핑한다. 예를들어서 "http://localhost/some/example.html" 이라는 요청을 받으면 nginx는 /data/www/some/example.html 파일을 전송한다.

새로운 설정 파일을 적용하기위해서, 아직 nginx를 실행하지 않았다면 시작하도록하고, 이미 시작했다면 reload 시그널을 nginx의 마스터 프로세스에 보내주면 된다.

nginx -s reload

만일 예상대로 동작하지 않는 경우엔 access.log파일과 error.log파일에서 원인을 찾을 수 있다. 해당 파일은 /usr/local/nginx/logs 또는 /var/log/nginx 디펙토리에 있다.

간단한 프록시 서버 만들기 Setting Up a Simple Proxy Server

nginx가 자주 사용되는 방식 중 하나는 프로식 서버로써 사용하는것이다. 프록시서버란 리퀘스트를 받은 후 프록시된 서버로 해당 리퀘스트를 전달해주고, 프록시된 서버가 돌려준 응답을 다시 요청한 클라이언트에게 돌려주는 서버이다.

이제 우리는 기본적인 프로식서버 설정을 할 것이다. 이 프록시 서버는 로컬 디렉토리에서 이미지와 파일 리쿼스트만 받고 다른 모든 요청들은 프록시(된) 서버로 넘긴다. 이 예에서 두 서버 모두 하나의 nginx인스턴스에 정의될 것이다.

먼저 프록시(된) 서버를 만든다. nginx의 설정 파일에 아래의 내용을 추가해서 server블럭 하나를 더 만든다.

server {
    listen 8080;
    root /data/up1;

    location / {
    }
}

이제 이코드로인해서 8080포트를 리슨 하는 단순한 서버가 만들어졌다.(이전엔 listen이 없었기때문에 스탠다드 포트인 80을 사용하고 있었다.)
이 서버는 모든 리퀘스트를 로컬 파일 시스템의 /data/up1 디렉토리로 매핑한다. 해당 디렉토리를 생성하고 index.html 파일을 넣어두자. root는 server 컨텍스트에 위치해 있다는 점을 기억해두자. 이런 root는 location블럭이 root를 가지고 있지 않을경우 사용된다.

다음으로 이전섹션에서 사용한 server 설정을 사용해자. 해당 설정을 수정해서 프록시 서버 설정으로 변환해보자. 첫번째 location 블럭 안에 프로토콜과 함께 proxy_pass 명령을 만들자. 이름과 프록시 될 서버의 포트를 파라미터로 설정해둔다. (우리의 예제에서는 http://localhost:8080이다)

server {
    location / {
        proxy_pass http://localhost:8080;
    }

    location /images/ {
        root /data;
    }
}

우리는 두번째 location 블럭을 수정할 예정이다. 현재는 /images/ 프리픽스를 가진 요청은 /data/images 디렉토리에 매핑되고있다. 이제 요청에 일반적인 파일 확장자를 가진 요청이 있는경우 매칭되게 만들기 위해서 location 블럭은 아래와 같이 변경된다.

location ~ \.(gif|jpg|png)$ {
    root /data/images;
}

파라미터는 정규식이다. URI가 .gif, .jpg, .png 로 끝날경우 모두 매칭된다. 정규식은 반드시 ~ 로 시작해야한다. 이제 일치하는 리퀘스트는 /data/images 디렉토리에 매핑되게 된다.

nginx가 요청을 수행하기위해서 location 블럭을 선택할때 먼저 location 명령어가 특정한 프리픽스를 가지고 있는지 확인한다. 앞서 말한것처럼 가장 긴 프리픽스를 가진 location을 기억하고있고, 정규표현식을 체크한다. 만일 정규표현식에 매칭되는 location이 있다면 해당 로케이션을 선택하고 없는 경우엔 기억하고있던 location을 선택한다.

우리가만든 프록시 서버의 설정을 아래와 같다.

server {
    location / {
        proxy_pass http://localhost:8080;
    }

    location ~ \.(gif|jpg|png)$ {
        root /data/images;
    }
}

이 서버는 .gif, .jpg, .png로 끝나는 요청을 필터링하고 (URI를 root명령어의 파라미터로 추가해서 )/data/images 디렉토리로 매핑할 것이다. 그리고 다른 모든 요청은 이미 설정해놓은 프록시드 서버로 전달한다.

새로운 설정을 적용하기위해서 nginx에 리로드 시그널을 보내야한다. 이전 섹션에서 사용한 명령어를 사용한다.

nginx엔 프록시 서버 설정에 사용가능한 다양한 설정 명령어들이 있다.

FaxtCGI Proxing 세팅 Setting Up FastCGI Proxying

nginx는 리퀘스트를 FastCGI 서버로 라우팅 하기위해서도 사용된다. FastCGI서버는 어플리케이션을 실행하는 다양한 프로그래밍 언어와 프레임워크로 만들어진 서버를 말한다.

FastCGI 서버와 함께 사용하는 대부분의 nginx 설정은 proxy_pass 명령어 대신 fastcgi_pass명령어를 사용한다. 그리고 fastcgi_param명령어를 이용해서 FastCGI 서버에 파라미터를 전달한다. FastCGI서버가 localhost:9000으로 접근 가능하다고 가정해보자. 이전 섹션에서 기본으로 사용한 프록시 설정을 변경해보자. proxy_pass 명령어를 fastcgi_pass명령어로 변환하고 파라미터를 localhost:9000으로 변환한다. PHP에서는 스크립트 이름을 정의하기 위새허 SCRIPT_FILENAME 파라미터를 사용한다. 그리고 QUERY_STRING 파라미터를 이용해서 리퀘스트 파라미터를 전달한다. 변경된 설정은 아래와 같다.

server {
    location / {
        fastcgi_pass  localhost:9000;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        fastcgi_param QUERY_STRING    $query_string;
    }

    location ~ \.(gif|jpg|png)$ {
        root /data/images;
    }
}

이제 이설정이 서버가 스태틱 이미지 요청을 제외한 모든 요청을 FastCGI프로토콜을 통해서 프록시된 서버인 localhost:9000으로 보내게된다.

반응형

코틀린 시작하기

코틀린의 특징

  • Java와 형태는 다르나 의미가 유사한 문법을 가지고있기때문에 Java개발자라면 쉽게 학습이 가능하다.
  • 클래스 상속 없이 클래스에 도메인 특화 편의 메소드 추가가 가능하고, 오리지날 클래스의 메소드터럼 사용할 수 있다.
  • 델리게이션을 지원해서 상속보다 더 좋은 디자인이 가능하다. 델리게이션은 타입 안정적으로 사용할 수 있다.
  • if-else 문 대신 argument-matching문법을 사용할 수 있다.
  • 이미 존재하는 함수를 확장하는것이 쉽게 가능하다. 기본 파라미터 기능이 있다.
  • 명시적 인자 사용이 가능하다.
  • 연산자 오버로딩이 가능하다.
  • 우아하고, 표현력이 강하고, 간결하다.
  • C스타일의 프로시저, 스칼라 스타일의 스크립트, Java같은 객체지향형 코드, 스몰톡/얼랭과 같은 함수형 스타일 코드 모두 사용 가능하다.
  • 코루틴과 컨티뉴에이션으로 비동기 프로그래밍 영역에서 혁신을 이끌고 있다.

코틀린이 좋은 이유(와 나의 생각)

  • 다양한 프로그래밍 패러다임
    • 객체지향,함수형, 절차지향, 스크립트, 비동기 프로그래밍 등 다양한 프로그래밍 페러다임을 제공하기때문에 그중 상황에 맞는 방식을 사용하면된다.
    • 보일러 플레이트 코드가 없다.
    • 더 적은 코드로 동일한 일을 할 수 있다.
  • 타입 추론으로 사용하는 정적 타입
    • 강력한 타입 추론을 해주기때문에 시간낭비할 필요가 없다.
    • 타입 추론이 명확하지 않은 경우 개발자에게 타입 명시를 요청한다.
    • 널러블 / 널불가 타입이 구분되어있다.
  • 풀스택 개발을 위한 히나의 언어.
    • 한번의 코드 작성으로 백엔드, 모바일, 네이티브, 웹어셈블리 등의 코드로 컴파일(혹은 트랜스파일)이 가능하다.
    • ( 가능하긴하나 아직 적극적으로 사용하긴 조금 어려운 부분이 있지 않은가 하는 생각이 든다.)
  • 자연스럽고 우아함
    • 보일러플레이트 코드가 필요 없다.
    • 세미콜론이 옵셔널이다
    • 인픽스 어노테이션 사용이 가능하다.

코틀린 설치 및 사용

  • 인텔리J를 사용중이라면 함게 설치되어있다.
  • 별도로 설치를 원하면 https://kotlinlang.org 에서 다운로드 및 설치할 수 있다. 자세한 설치방법은 공식 홈페이지를 참고하도록하자.

설치 확인

cli에서 다음과 같이

kotlinc-jvm -version

본인의 경우는
info: kotlinc-jvm 1.4.31 (JRE 15.0.2+7)
이렇게 출력이 나왔다.

우리가 늘 하는 Hello World 만들기

적절한 폴더에 hello.kt라는 파일을 만들고 아래와 같이 코드를 넣어본다.

//hello.kt
fun main() = println("Hello World")

cli로 실행시키기

kotlinc-jvm hello.kt -d hello.jar

위 명령어를 실행시키면 hello.kt 코틀린 코틀린코드를 Java바이트 코드로 컴파일시키고 hello.jar를 만들어둔다.
jar를 java툴을 이용해서 실행시키면된다.

java -classpath hello.jar HelloKt

hello.kt는 main함수만 가지고있고, 클래스가 아니기때문에 코틀린 컴파일러가 자동으로 확장자를 제거한 파일 이름을 가지고 Kt라는 접미사를 추가한 클래스이름을 만든다.

실행결과는 당연히
Hello World가 나온다.

classpath cli옵션을 열거하지않고, jar옵션으로 실행 가능하다. main()함소를 찾을때 코틀린 컴파일러가 jar 파일에 Main-Class 매니패스트 어트리뷰트를 추가한다.

java -jar hello.jar

현재는 코틀린 스탠다드 라이브러리를 사용하지 않았기 때문에 실행이 잘 되지만 코틀린 스탠다드 라이브러리의 클래스와 함수들을 사용하는 경우 java툴로만 실행한다면 java.lang.NoClassDefFoundError예외가 발생하면서 실패한다. 이를 방지하기위해서는 kotlin-stdlib.jar파일을 클래스패스에 추가해줘야한다.

kotlinc-jvm hello.kt -d hello.jar
java -classpath hello.jar:$KOTLIN_PATH/lib/kotlin-stdlib.jar HelloKt
//위도우인경우 %KOTLIN_PATH% 를 사용, 콜론(:)이 아닌 세미콜론(;)으로 구문해야한다. 등록된 환경변수를 사용하면된다.

ide로 실행하기

코틀린 공식 홈페이지 및 각 ide의 홈페이지와 라이브러리를 참고하면 될거같다. 여기서는 굳이 언급하지 않도록하겠다.

REPL실험

cli에서 kotlinc-jvm 이라고 입력하면 REPL이 실행된다.
아래와같이 조금 사용해보자.

//kotlinc-jvm
Welcome to Kotlin version 1.4.31 (JRE 15.0.2+7)
Type :help for help, :quit for quit
>>> 7 + 5
res0: kotlin.Int = 12
>>> val list = listOf(1,2,3)
>>> list.map{ it * 2}
res2: kotlin.collections.List<kotlin.Int> = [2, 4, 6]
>>>

종료할땐 컨트롤D 를 사용하거나 :quit 라고 입력한다.

REPL에선 이미 존재하는 코드를 불러와서 실행시킬수도 있다.

kotlinc-jvm

Welcome to Kotlin version 1.4.31 (JRE 15.0.2+7)
Type :help for help, :quit for quit
>>> :load hello.kt
>>> main()
Hello World!
>>>

이렇게 REPL에선 존재하는 코드를 컴파일 없이 실행할 수 있다.

스크립트로 실행하기

코틀린은 스크립트로 사용가능하다. 여타 스크립트에 비해서 좋은점이라면 스크립트를 위해 따로 문법 공부를 할 필요가 없다는 점이 있을것이고, 코틀린 스크립트는 문법 오류가 있는 경우 스크립트 실행 전에 실패를하기때문에 컴파일 후 칠행하는것 만큼 안전하다.

연습을 위해서 디렉토리에서 .kts 확장자를 가진파일을 리스팅 하는 스크립트를 만들어보자.

//listktsfile.kts
java.io.File(".")
    .walk()
    .filter { file -> file.extension =="kts" }
    .forEach { println(it) }

지금까지 작성한 코틀린 파일과 별반 타이가 없다. 차이점이라면 확장자가 kts라는것 뿐이다.
이 코드는 JDK의 java.io 패키지의 File 클래스를 사용한다. 그리고 코틀린이 해당 클래스에 추가한 확장 함수를 사용한다.
현재 디렉토리에 있는 모든 파일중 파일명이 kts로 끝나는 파일만 걸러내서 잡고 해당 파일의 경로를 출력한다.

스크립트 실행을 위해선 kotlinc-jvm 커맨드를 사용한다. -script옵션을 통해서 컴파일 대신 스크립트로써 즉시 실행시킨다.

kotlinc-jvm -script listktsfiles.kts

Unix-Like 시스템을 사용한다면 kotlinc-jvm -script라는 접미어 대신 셔뱅(shebang)을 사용하면된다.

greeting.kts

#!/ust/bin/env kotlin-jvm -script
println("hello")

실행을위해 chmod +x greeting.kts 명령어로 파일에 실행권한을 주고 아래의 커맨드라인을 통해 스크립트를 바로 시킬 수있다.

./greeting.kts

시스템에 따라 /usr/bin/env 대신 kotlinc-jvm이 위치한 전체경로를 써줘야 하는 경우도 있다.

다른 타깃으로 컴파일하기

코틀린은 여러개의 타깃으로 컴피일이 가능한 언어이다.

  • 안드로이드
  • javascript로 트랜스파일
  • 네이티브 타깃(iOS, Linux, MacOS, Windows 등 네이티브 타겟)
  • WebAssembly

어떤 옵션을 선택해야할까?

코틀린은 실행시킬때 특정 옵션 설정을 강제하지 않기때문에 개발자의 요구사항과 선호도에 따라 실행옵션을 선택하면된다.
아래는 옵션 선택시 고려해야할 사항이다.

  • JVM에서 실행시키거나 Java또는 다른 언어와 함께사용하는경우 --> kotlinc-jvm을 이용한다.
  • 여러개의 코틀린 파일을 통합해 하나의 코틀린 프로그램으로 실행시켜야한다 -> kotlin툴을 이용한다.
  • 시스템레벨 / 백엔드 태스크 수형해야한다 -> 스크립트

정리

코틀린의 특징에 대해 알아보았고, 간단한 코드를 작성해보았다. 다음번엔 코틀린의 특징을 좀더 자세하게 알아보고 좀더 많은 코드를 작성해본다.

 

영진닷컴 - 다재다능 코틀린 프로그래밍 - 스프링 분철선택

COUPANG

www.coupang.com

쿠팡 파트너스 활동을 통해 일정액의 수수료를 제공받을 수 있습니다.

반응형

'웹프로그래밍 > Kotlin' 카테고리의 다른 글

[Kotlin] data class와 주의사항  (0) 2024.12.02
[KOTLIN] CLASS  (0) 2023.02.25
[코틀린KOTLIN 정리]0. 들어가며  (0) 2021.06.02

앞으로 코틀린에 대한 정리 글을 좀 올려보려합니다. 
정리는 영진닷컴에서 출판한 다재다능 코틀린 프로그래밍 서적을 기반으로 제가 이해한 내용을 정리합니다. 

 

 

 

 

영진닷컴 - 다재다능 코틀린 프로그래밍 - 스프링 분철선택

COUPANG

www.coupang.com

쿠팡 파트너스 활동을 통해 일정액의 수수료를 제공받을 수 있습니다.

반응형

'웹프로그래밍 > Kotlin' 카테고리의 다른 글

[Kotlin] data class와 주의사항  (0) 2024.12.02
[KOTLIN] CLASS  (0) 2023.02.25
[코틀린 KOTLIN 정리]01.코틀린 시작하기  (0) 2021.06.02

[도서리뷰]스파크를 활용한 실시간 처리(Stream Processing with Apache Spark)

스파크를 활용한 실시간 처리

오늘 리뷰할 도서는 스파크를 활용한 실시간 처리(Stream Processing with Apache Spark)입니다. 이 리뷰는 한빛 미디어로부터 도서를 제공받아 독서 후 작성되었음을 알려드립니다.

들어가며

웹개발자들 중에 실시간 처리가 필요 없는 개발자는 없을것이다. 비록 스파크를 직접 사용해본 적은 없더라도 서비스를(혹은 플랫폼)을 함께 만드는 다른 팀에서는 실시간 처리를 위해서 스파크를 사용하고 있을 가능성이크다(필자의 경우가 그랬다.) 우리 서비스에서 스파크가 실시간 처리를 담당해준다는 사실도 알고있었고, 여러 컨퍼런스에서 스파크를 이용한 실시간 처리에 관한 세션도 들어본적이 있지만, 공부를 하지않았다. 매번 해야한다는 생각만하고 당장 처리해야할 일이 너무 많아서 하지않았던거같다. 하지만 좋은 기회에 한빛미디어가 도서를 제공해주었고 덕분에 미루어둔 공부를 할 수 있게되었다.

먼저 목차부터 살펴보도록하자.

더보기

Part 1 아파치 스파크를 사용한 스트림 처리의 기본


CHAPTER 1 스트림 처리 소개

    1.1 스트림 처리란
    1.2 스트림 처리 예제
    1.3 데이터 처리의 확장
    1.4 분산 스트림 처리
    1.5 아파치 스파크 소개
    1.6 다음엔 무엇을 배울까

CHAPTER 2 스트림 처리 모델

    2.1 소스와 싱크
    2.2 서로 정의된 불변의 스트림
    2.3 변환과 집계
    2.4 윈도우 집계
    2.5 비상태 및 상태 기반 처리
    2.6 상태 기반 스트림
    2.7 예제: 스칼라에서 로컬 상태 기반 연산
    2.8 비상태 또는 상태 기반 스트리밍
    2.9 시간의 영향
    2.10 요약

CHAPTER 3 스트리밍 아키텍처

    3.1 데이터 플랫폼의 구성 요소
    3.2 아키텍처
    3.3 스트리밍 애플리케이션에서 배치 처리 구성 요소의 사용
    3.4 참조 스트리밍 아키텍처
    3.5 스트리밍과 배치 알고리즘
    3.6 요약

CHAPTER 4 스트림 처리 엔진으로서의 아파치 스파크

    4.1 두 API 이야기
    4.2 스파크의 메모리 사용
    4.3 지연 시간에 대한 이해
    4.4 처리량 지향 처리
    4.5 스파크의 폴리글랏 API
    4.6 데이터 분석의 빠른 구현
    4.7 스파크에 대해 더 알아보기
    4.8 요약

CHAPTER 5 스파크의 분산 처리 모델

    5.1 클러스터 매니저를 활용한 아파치 스파크 실행
    5.2 스파크 자체 클러스터 매니저
    5.3 분산 시스템에서의 복원력과 내결함성 이해
    5.4 데이터 전송 의미론
    5.5 마이크로배칭과 한 번에 한 요소
    5.6 마이크로배치와 한 번에 한 레코드 처리 방식을 더욱 가깝게 만들기
    5.7 동적 배치 간격
    5.8 구조적 스트리밍 처리 모델

CHAPTER 6 스파크의 복원력 모델

    6.1 스파크의 탄력적인 분산 데이터셋
    6.2 스파크 컴포넌트
    6.3 스파크의 내결함성 보장
    6.4 요약


Part 2 구조적 스트리밍


CHAPTER 7 구조적 스트리밍 소개

    7.1 구조적 스트리밍의 첫걸음
    7.2 배치 분석
    7.3 스트리밍 분석
    7.4 요약

CHAPTER 8 구조적 스트리밍 프로그래밍 모델

    8.1 스파크 초기화
    8.2 소스: 스트리밍 데이터 수집
    8.3 스트리밍 데이터 변환
    8.4 싱크: 결과 데이터 출력
    8.5 요약

CHAPTER 9 구조적 스트리밍 작동

    9.1 스트리밍 소스 소비하기
    9.2 애플리케이션 로직
    9.3 스트리밍 싱크에 쓰기
    9.4 요약

CHAPTER 10 구조적 스트리밍 소스

    10.1 소스의 이해
    10.2 사용 가능한 소스
    10.3 파일 소스
    10.4 카프카 소스
    10.5 소켓 소스
    10.6 레이트 소스

CHAPTER 11 구조적 스트리밍 싱크

    11.1 싱크의 이해
    11.2 사용 가능한 싱크
    11.3 파일 싱크
    11.4 카프카 싱크
    11.5 메모리 싱크
    11.6 콘솔 싱크
    11.7 foreach 싱크

CHAPTER 12 이벤트 시간 기반 스트림 처리

    12.1 구조적 스트리밍에서의 이벤트 시간에 대한 이해
    12.2 이벤트 시간의 사용
    12.3 처리 시간
    12.4 워터마크
    12.5 시간 기반 윈도우 집계
    12.6 레코드 중복 제거
    12.7 요약

CHAPTER 13 고급 상태 기반 작업

    13.1 예제: 차량 유지 보수 관리
    13.2 상태 작동을 통한 그룹의 이해
    13.3 MapGroupsWithState의 사용
    13.4 FlatMapGroupsWithState 사용
    13.5 요약

CHAPTER 14 구조적 스트리밍 애플리케이션 모니터링

    14.1 스파크 메트릭 하위시스템
    14.2 StreamingQuery 인스턴스
    14.3 StreamingQueryListener 인터페이스

CHAPTER 15 실험 영역: 연속형 처리와 머신러닝

    15.1 연속형 처리
    15.2 머신러닝


Part 3 스파크 스트리밍


CHAPTER 16 스파크 스트리밍 소개

    16.1 DStream 추상화
    16.2 스파크 스트리밍 애플리케이션의 구조
    16.3 요약

CHAPTER 17 스파크 스트리밍 프로그래밍 모델

    17.1 DStream의 기본 추상화로서의 RDD
    17.2 DStream 변환의 이해
    17.3 요소 중심의 DStream 변환
    17.4 RDD 중심의 DStream 변환
    17.5 계산 변환
    17.6 구조 변경 변환
    17.7 요약

CHAPTER 18 스파크 스트리밍 실행 모델

    18.1 대량 동기화 아키텍처
    18.2 리시버 모델
    18.3 리시버가 없는 모델 또는 직접 모델
    18.4 요약

CHAPTER 19 스파크 스트리밍 소스

    19.1 소스의 유형
    19.2 일반적으로 사용되는 소스
    19.3 파일 소스
    19.4 큐 소스
    19.5 소켓 소스
    19.6 카프카 소스
    19.7 더 많은 소스를 찾을 수 있는 곳

CHAPTER 20 스파크 스트리밍 싱크

    20.1 출력 연산
    20.2 내장형 출력 연산
    20.3 프로그래밍 가능한 싱크로서 foreachRDD 사용하기
    20.4 서드파티 출력 연산

CHAPTER 21 시간 기반 스트림 처리

    21.1 윈도우 집계
    21.2 텀블링 윈도우
    21.3 슬라이딩 윈도우
    21.4 윈도우 사용과 더 긴 배치 간격 사용
    21.5 윈도우 기반 감소
    21.6 가역 윈도우 집계
    21.7 슬라이싱 스트림
    21.8 요약

CHAPTER 22 임의 상태 기반 스트리밍 연산

    22.1 스트림 규모의 상태 기반
    22.2 updateStateByKey
    22.3 updateStateByKey의 한계
    22.4 mapwithState를 사용한 상태 기반 연산 소개
    22.5 mapWithState 사용하기
    22.6 mapWithState를 사용한 이벤트 시간 스트림 계산

CHAPTER 23 스파크 SQL로 작업하기

    23.1 스파크 SQL
    23.2 스파크 스트리밍에서 스파크 SQL 함수에 접근하기
    23.3 유휴 데이터 처리
    23.4 조인 최적화
    23.5 스트리밍 애플리케이션에서 참조 데이터셋 업데이트하기
    23.6 요약

CHAPTER 24 체크포인팅

    24.1 체크포인트 사용법의 이해
    24.2 DStream 체크포인팅
    24.3 체크포인트에서 복구
    24.4 체크포인팅 비용
    24.5 체크포인트 튜닝

CHAPTER 25 스파크 스트리밍 모니터링

    25.1 스트리밍 UI
    25.2 스트리밍 UI를 이용하여 잡 성능 이해하기
    25.3 REST API 모니터링
    25.4 지표 하위시스템
    25.5 내부 이벤트 버스
    25.6 요약

CHAPTER 26 성능 튜닝

    26.1 스파크 스트리밍의 성능 밸런스
    26.2 잡의 성능에 영향을 미치는 외부 요소
    26.3 성능을 향상시킬 수 있는 방법
    26.4 배치 간격 조정하기
    26.5 고정 속도 스로틀링을 통한 데이터 수신 제한
    26.6 백프레셔
    26.7 동적 스로틀링
    26.8 캐싱
    26.9 추측적 실행


Part 4 고급 스파크 스트리밍 기술

CHAPTER 27 스트리밍 근사 및 샘플링 알고리즘

    27.1 정확성, 실시간 그리고 빅데이터
    27.2 정확성, 실시간 그리고 빅데이터 삼각형
    27.3 근사 알고리즘
    27.4 해싱과 스케칭: 소개
    27.5 고유 요소 계산: HyperLogLog
    27.6 카운팅 요소 빈도: 최소 스케치 카운트
    27.7 순위와 분위수: T-다이제스트
    27.8 요소 수 줄이기: 샘플링

CHAPTER 28 실시간 머신러닝

    28.1 나이브 베이즈를 이용한 스트리밍 분류
    28.2 의사 결정 트리 소개
    28.3 Hoeffding 트리
    28.4 온라인 K-평균을 사용한 스트리밍 클러스터링


Part 5 아파치 스파크를 넘어


CHAPTER 29 기타 분산 실시간 스트림 처리 시스템

    29.1 아파치 스톰
    29.2 아파치 플링크
    29.3 카프카 스트림
    29.4 클라우드에서

CHAPTER 30 미리 살펴보기

    30.1 연결 상태 유지
    30.2 밋업에 참석하기
    30.3 아파치 스파크 프로젝트에 기여하기

목차에 나와있다시피 기초부터 시작하여 사례, 적용 법까지 다양한 내용을 다루고있다.
실시간처리, 스트리밍, 스파크 이런 키워드들에 대해 설명하라고하면 막연한 설명밖에 못하는분들이 보기 좋은책. 이 책은 스파크를 활용한 실시간 처리를 설명하기에 앞서 실시간 처리를 논할때 사용되는 용어 및 개념들에대해 설명하는것부터 시작한다. 즉, 별다른 선행 지식이 필요 없다는 이야기이다. 덕분에 필자도 수월하게 책의 내용을 이해할 수 있었다.

"한빛미디어 <나는 리뷰어다> 활동을 위해서 책을 제공받아 작성된 서평입니다."

반응형

모든 내용을 번역하기는 좀 시간이 부족해서 어노테이션 설명의 첫문단만 번역함.

원문.

docs.spring.io/spring-framework/docs/current/reference/html/testing.html#integration-testing

 

Testing

The classes in this example show the use of named hierarchy levels in order to merge the configuration for specific levels in a context hierarchy. BaseTests defines two levels in the hierarchy, parent and child. ExtendedTests extends BaseTests and instruct

docs.spring.io

 

3.4.1. Spring Testing Annotations

The Spring Framework provides the following set of Spring-specific annotations that you can use in your unit and integration tests in conjunction with the TestContext framework. See the corresponding javadoc for further information, including default attribute values, attribute aliases, and other details.

스프링 프레임워크는 다음와 같은 스프링 특화 어노테이션을 제공한다. 이 어노테이션들은 유닛테스트 혹은 통합테스트를 할때 테스트 프레임워크(TestContext framework)와의 연결을 위해서 사용된다. 디폴트값, 속성, 등 더많은 정보를 위해서는 대응되는 javadoc을 보도록 하라.

 

Spring’s testing annotations include the following:

스프링의 테스팅 어노테이션은 아래를 포함한다.

 

@BootstrapWith

@BootstrapWith is a class-level annotation that you can use to configure how the Spring TestContext Framework is bootstrapped. Specifically, you can use @BootstrapWith to specify a custom TestContextBootstrapper. See the section on bootstrapping the TestContext framework for further details.

@BootstrapWith는 클래스 레벨 어노테이션이다. 어떻게 스프링 테스트 프레이워크가 부트스트랩 되는지를 정의한다. 특히, @BootstrapWith를 사용하면 커스텀 테스트 컨텍스트 부트스트랩퍼를 지정할 수 있다. 더 많은 정보를 위해서 bootstrapping the TestContext framework  를 참조하도록 하라.

 

@ContextConfiguration

@ContextConfiguration defines class-level metadata that is used to determine how to load and configure an ApplicationContext for integration tests. Specifically, @ContextConfiguration declares the application context resource locations or the component classes used to load the context.

@ContextConfiguration은 클래스 레벨 메타데이터를 정의한다. 메타데이터는 통합 테스트를 위한 어플리케이션 컨텍스트를 어떻게 구성 하고, 로드 하는지를 정의한다. 특히, @ContextConfiguration은 어플리케이션 컨텍스트 리소스의 위치(location) 혹은 컨텍스트를 로드할때 사용되는 클래스의 컴포넌트를 선언한다.

 

@WebAppConfiguration

@WebAppConfiguration is a class-level annotation that you can use to declare that the ApplicationContext loaded for an integration test should be a WebApplicationContext. The mere presence of @WebAppConfiguration on a test class ensures that a WebApplicationContext is loaded for the test, using the default value of "file:src/main/webapp" for the path to the root of the web application (that is, the resource base path). The resource base path is used behind the scenes to create a MockServletContext, which serves as the ServletContext for the test’s WebApplicationContext.

@WebAppConfiguration은 클래스 레벨 어노테이션이다. @WebAppConfiguration은 통합 테스트를 위한 어플리케이션 컨텍스트가 WebApplicationContext여야 하는 경우 사용된다. @WebAppConfiguration가 사용되는 유일한 이유는 테스트를 할때WebApplicationContext가 로드되었다는것을 보장해주고, 웹 어플리케이션의 루트 패스인 "file:src/main/webapp"를 디폴트 값으로 사용하는것을 보장하는 것이다. 리소스의 베이스 패스는 Mock서블렛 컨텍스트를 생성하기위해서 사용되며 Mock서블렛 컨텍스트는 WebApplicationContext의 테스트에 사용되는 서블렛 컨텍스트 역할을 수행한다.

 

@ContextHierarchy

@ContextHierarchy is a class-level annotation that is used to define a hierarchy of ApplicationContext instances for integration tests. @ContextHierarchy should be declared with a list of one or more @ContextConfiguration instances, each of which defines a level in the context hierarchy. 

@ContextHierachy는 클래스레벨 어노테이션이다. @ContextHierarchy는 통합 테스트시 어플리케이션 컨텍스트의 인스턴스의 계층을 정의하기위해 사용된다. @ContextHierachy는 하나 이상의 @ContextConfiguration인스턴스와 함께 정의 되어야한다. 이때 사용되는 각 @ContextConfiguration가 컨텍스트 계층 레벨을 정의한다. 

 

@ActiveProfiles

@ActiveProfiles is a class-level annotation that is used to declare which bean definition profiles should be active when loading an ApplicationContext for an integration test.

@ActiveProfiles는 클래스 레벨 어노테이션이다. @ActiveProfiles는 통합 테스트시 어플리케이션 컨텍스를 로딩할때 어떤 빈 정의 프로파일이 활성화 되어야하는지를 정의한다. 

 

@TestPropertySource

@TestPropertySource is a class-level annotation that you can use to configure the locations of properties files and inlined properties to be added to the set of PropertySources in the Environment for an ApplicationContext loaded for an integration test.

 

 

 

반응형

[도서리뷰] 처음 배우는 리액트 네이티브

처음배우는 리액트 네이티브

안녕하세요 앵글로퍼입니다. 아주 오랫만에 도서리뷰를 합니다. 오늘 리뷰할 도서는 처음배우는 리액트 네이티브 라는 도서입니다. 약 2주전 한빛미디어로부터 책을 받았고, 약 1주일에 걸처서 독서를 완료한 후 리뷰를 합니다. :)

TLDR;

처음배우는 리액트 네이티브 라는 책 제목에 걸맞게 리액트 네이티브를 하나도 모르는 개발자가 보기에 좋은 책입니다. 물론 개발에 대해서 아무것도 모르는 사람이 보기에 적절한 책은아닙니다. 기본적인 자바스크립트 지식은 반드시 필요합니다. 없어도 상관없지만 있으면 더 좋을만한 배경지식으로는 웹서비스 혹은 클라이언트 - 서버 프로그래밍에 대한 지식이 있다면 더 좋을거같습니다. 하나이상의 프로젝트 경험이 있다면 책에 내용을 쉽게 이해할 수 있을것입니다.
저같은 경우는 얼마전부터 토이프로젝트로 서비스를 만들 생각으로 리액트를 공부하고있었고, 어플리케이션도 만들 생각으로 리액트 네이티브와 플러터 사이에서 고민을 하고있었는데 한빛미디어가 좋은 책을 보내주셔서 많은 도움이 되었습니다. 저처럼 리액트로 예제 프로잭트정도만 실행해본 사람이라면 이책을 통해서 리액트 자체에 대한 이해도 깊어지게 될 것입니다. 저처럼 크로스플랫폼 어플리케이션을 만들어보고싶은 웹개발자에게 매우 좋은 책입니다. 일반적으로 튜토리얼 문서나 인터넷에 있는 강좌 등에서는 잘 다루지 않아서 오히려 고급 기술보다 정보를 찾기 어려운 매우 기초적인 부분들부터 시작하기때문에 반나절 정도 카페에 앉아서 한번 읽어보시면 큰 도움이 될 것이라는 생각이 듭니다.

본문

먼저 목차부터 살펴보기로합니다.

목차(클릭하여 펼치기)

1장. 리액트 네이티브란?

1.1 리액트 네이티브의 장점과 단점

1.2 리액트 네이티브의 동작 방식

1.3 마치며

- 리액트를 공부한 후 시작해야 하나요?

*2장. 리액트 네이티브 시작하기 *

2.1 개발 환경 준비하기

2.2 리액트 네이티브 프로젝트 만들기

2.3 마치며

- 리액트 네이티브 멀티 플랫폼 개발

3장. 컴포넌트

3.1 JSX

3.2 컴포넌트

3.3 props와 state

3.4 이벤트

3.5 마치며

- 타입 확인

4장. 스타일링

4.1 스타일링

4.2 리액트 네이티브 스타일

4.3 스타일드 컴포넌트

4.4 마치며

- Prettier

5장. 할 일 관리 애플리케이션

5.1 프로젝트 준비하기

5.2 타이틀 만들기

5.3 Input 컴포넌트 만들기

5.4 할 일 목록 만들기

5.5 기능 구현하기

5.6 부가 기능

5.7 마치며

- 디자인 도구

6장. Hooks

6.1 useState

6.2 useEffect

6.3 useRef

6.4 useMemo

6.5 커스텀 Hooks 만들기

6.6 마치며

- 클래스형 컴포넌트를 공부해야 하나요?

*7장. Context API *

7.1 전역 상태 관리

7.2 Context API

7.3 useContext

7.4 마치며

- 커뮤니티

8장. 내비게이션

8.1 리액트 내비게이션

8.2 스택 내비게이션

8.3 탭 내비게이션

8.4 마치며

- 나의 첫 번째 리액트 네이티브 프로젝트

9장. 채팅 애플리케이션

9.1 프로젝트 준비

9.2 파이어베이스

9.3 앱 아이콘과 로딩 화면

9.4 인증 화면

9.5 메인 화면

9.6 마치며

- 애플 개발자 계정 생성

10장. 배포하기

10.1 프로젝트 빌드

10.2 iOS 배포

10.3 안드로이드 배포

10.4 버전 업그레이드

10.5 마치며

- 이 책 이후에

기본적인 설치 및 개발환경 구성부터 어플리케이션의 배포까지를 다루고있다. 저자는 집필중 프로그램의 버전 업때문에 추가되거나 변경된 기능까지 노트를 통해서 알려주고있기때문에 최신번전과 약간 다른부분도 최대한 커버해주려고 노력하고있는점이 인상적이다. 앞서 언급한것처럼 핵심이되는 기능이나 이해하기 어려운 기능보다 아무것도아닌 가장 기초적인 기능에대한 자료를 찾기가 어려움 경우가 많은데, 이 책의 경우는 아주 기초적인 부분들부터 짚어주는점이 특히 마음에 들었다.
기본적인 사용방법부터 화면을 구성하는방법으로 시작해서 할일관리 앱으로 작은 앱을 하나 만들어보고 firebase를 활용한 채팅앱을 만드는 과정에서 아마도 이 책을 선택한 사람들이 당장 필요로하는 기능을 구현할 수 있는 방법은 모두 설명해주고 있다는 생각이든다(나의 경우는 그랬다.) 초보자를 위한 책이기 때문에 기초부터 시작하여 작은 어플리케이션 2개를 만들면서 막연하기만 했던 앱 개발에대한 자신감을 심어주고, 본인의 구상을 구체화 할 수 있는 방법을 알려준다.

결론

크로스플랫폼 어플리케이션 개발에 관심이 있는 개발자라면 리액트 네이티브를 처음 시작하기 매우 좋은 책이다.

반응형

[도서리뷰] JavaScript Everywhere

JavaScript Everywhere 한빛미디어

안녕하세요 앵글로퍼입니다. 아주 오랫만에 도서리뷰를 합니다. 오늘 리뷰할 도서는 자바스크립트는 모든 곳에 존재한다(JavaScript Everywhere)라는 도서입니다. 약 2주전 한빛미디어로부터 책을 받았고, 약 1주일에 걸처서 독서를 완료한 후 리뷰를 합니다. :)

 

TLDR;

자바스크립트는 모든 곳에 존재한다( JavaScript Everywherer) 책의 제목만보면 자바스크립트는 모든곳에 있다는 의미인가? 여러 분야에서 활용되는 자바스크립트에대한 책인가? 할 수 있지만 자바스크립트로 모든것을 만드는 이야기이다. 자바스크립트를 이용해서 서버 / 웹 프론트엔드 / 데스크탑용 클라이언트 / 어플리케이션 모드것을 만드는 방법을 다룬다. 책의 설명과 예제코드를 따라가면 웹 / 모바일 / 데스크탑에서 모두 사용할 수 있는 노트 서비스를 만들게된다. 이 과정에서 자바스크립트를 이용해서 서비스를 구축하는 경험을 하게되고, 자세히는 아니지만 각 기능을 만들때 필요한 기술에대한 공부를 할 수 있고 흥미있는 분야를 더 깊게 공부를 시작할때 필요한 키워드들을 알려준다. 아주 깊은 내용을 다루지는 않기때문에 개발 경험이 있는 사람이라이  멀티플렛폼에서의 서비스 구축을 고려한다면 가볍게 읽기 좋은 책이다. 

 

본문

먼저 목차부터 보기로하자. 

더보기

CHAPTER 1 개발 환경

1.1 텍스트 편집기

1.2 터미널

1.3 커맨드 라인 도구와 홈브루(맥에만 해당)

1.4 Node.js와 NPM

1.5 몽고DB

1.6 깃

1.7 엑스포

1.8 프리티어

1.9 ESLint

1.10 미관 꾸미기

1.11 결론

 

CHAPTER 2 API 소개

2.1 무엇을 만들 것인가

2.2 어떻게 만들 것인가

2.3 시작하기

2.4 결론

 

CHAPTER 3 노드와 익스프레스로 웹 애플리케이션 만들기

3.1 Hello World

3.2 Nodemon

3.3 포트 확장 옵션

3.4 결론

 

CHAPTER 4 그래프QL API 첫걸음

4.1 서버를 API로

4.2 그래프QL 기초

4.3 API 적용하기

4.4 결론

 

CHAPTER 5 데이터베이스

5.1 몽고DB 시작하기

5.2 몽고DB와 애플리케이션 연동하기

5.3 애플리케이션에서 데이터 읽고 쓰기

5.4 결론

 

CHAPTER 6 CRUD 동작

6.1 그래프QL의 스키마와 리졸버 분리하기

6.2 그래프QL CRUD 스키마 작성

6.3 CRUD 리졸버

6.4 날짜와 시간

6.5 결론

 

CHAPTER 7 사용자 계정과 인증

7.1 애플리케이션 인증 흐름

7.2 암호화와 토큰

7.3 API에 인증 통합하기

7.4 리졸버 콘텍스트에 사용자 추가하기

7.5 결론

 

 

CHAPTER 8 사용자 액션

8.1 시작하기 전에

8.2 사용자를 새 노트에 연결하기

8.3 업데이트와 삭제 권한

8.4 사용자 쿼리

8.5 즐겨찾기 노트 설정

8.6 중첩 쿼리

8.7 결론

 

CHAPTER 9 디테일

9.1 웹 애플리케이션과 익스프레스의 모범 사례

9.2 페이지네이션

9.3 데이터 제한

9.4 기타 고려 사항

9.5 결론

 

CHAPTER 10 API 배포하기

10.1 데이터베이스 호스팅

10.2 애플리케이션 배포

10.3 결론

 

CHAPTER 11 사용자 인터페이스와 리액트

11.1 자바스크립트와 UI

11.2 자바스크립트와 선언적 인터페이스

11.3 새 리액트 애플리케이션

11.4 결론

 

CHAPTER 12 리액트로 웹 클라이언트 만들기

12.1 무엇을 만들 것인가

12.2 어떻게 만들 것인가

12.3 시작하기

12.4 웹 애플리케이션 만들기

12.5 라우팅

12.6 UI 컴포넌트

12.7 결론

 

 

CHAPTER 13 애플리케이션에 스타일 입히기

13.1 레이아웃 컴포넌트 생성하기

13.2 CSS

13.3 결론

 

CHAPTER 14 아폴로 클라이언트로 작업하기

14.1 아폴로 클라이언트 셋업

14.2 API에 쿼리하기

14.3 동적 쿼리

14.4 페이지네이션

14.5 결론

 

CHAPTER 15 웹 인증과 상태

15.1 회원가입 양식 만들기

15.2 리디렉션

15.3 요청에 헤더 붙이기

15.4 로컬 상태 관리

15.5 로그아웃하기

15.6 로그인 양식 만들기

15.7 경로 보호하기

15.8 결론

 

CHAPTER 16 생성, 읽기, 업데이트, 삭제 작업

16.1 새 노트 생성

16.2 노트 읽기

16.3 노트 업데이트

16.4 노트 삭제

16.5 즐겨찾기 추가/제거

16.6 결론

 

CHAPTER 17 애플리케이션 배포하기

17.1 정적 웹 사이트

17.2 배포 파이프라인

17.3 결론

 

CHAPTER 18 일렉트론으로 데스크톱 애플리케이션 개발하기

18.1 무엇을 만들 것인가

18.2 어떻게 만들 것인가

18.3 시작하기

18.4 첫 일렉트론 앱

18.5 맥OS 애플리케이션 창

18.6 개발자 도구

18.7 일렉트론 API

18.8 결론

 

CHAPTER 19 기존의 웹 애플리케이션과 일렉트론 통합하기

19.1 웹 애플리케이션 통합

19.2 설정

19.3 콘텐츠 보안 정책

19.4 결론

 

CHAPTER 20 일렉트론 배포

20.1 일렉트론 빌더

20.2 현재 플랫폼 빌드하기

20.3 앱 아이콘

20.4 다중 플랫폼용 빌드

20.5 코드 서명

20.6 결론

 

CHAPTER 21 리액트 네이티브로 모바일 앱 만들기

21.1 무엇을 만들 것인가

21.2 어떻게 만들 것인가

21.3 시작하기

21.4 결론

 

CHAPTER 22 모바일 앱 셸

22.1 리액트 네이티브의 빌딩 블록

22.2 스타일과 스타일드 컴포넌트

22.3 라우팅

22.4 아이콘

22.5 결론

 

CHAPTER 23 그래프QL과 리액트 네이티브

23.1 리스트와 스크롤 콘텐츠 뷰 만들기

23.2 아폴로 클라이언트와 그래프QL

23.3 로딩 인디케이터 추가하기

23.4 결론

 

CHAPTER 24 모바일 앱 인증

24.1 인증의 흐름

24.2 로그인 양식 만들기

24.3 그래프QL 뮤테이션으로 인증하기

24.4 그래프QL 쿼리

24.5 회원가입 양식 추가하기

24.6 결론

 

CHAPTER 25 모바일 앱 배포하기

25.1 설정

25.2 아이콘과 앱 로딩 화면

25.3 엑스포에서 퍼블리시하기

25.4 네이티브 빌드 생성하기

25.5 앱 스토어에 배포하기

25.6 결론

 

부록 A 로컬에서 API 실행하기 

부록 B 로컬에서 웹 앱 실행하기

목차를 보면 알겠지만 개발환경구성부터 그래프QL, 몽고디비에대한 설명도 나오며 서버 / 웹 프론트엔드 / 데스크톱 클라이언트 / 모바일 어플리케이션까지 멀티플랫폼 서비스를 위한 다양한 내용이 나와있다. 

다만 아쉬운점은 책에서 저자가 직접 언급하기도했지만 테스트에 대한 내용이 없는것은 아쉬운점이다.

책의 구성에서 좋은점은 굳이 맨앞부터 읽을 필요가 없다는점이다. 만일 나는 이미 노드와 express에대해서는 잘 알고있기때문에 데스크톱 클라이언트나 모바일 어플리케이션을 만드는부분만 읽고싶다면 책의 부록에 나와있는 방법을 이용하면 앞부분을 건너뛰고 책의 예제와 설명을 보는데 전혀 지장이 없다. 저자 혹은 편집자의 세심한 배려가 눈에 띄는 부분이다. 

그리고 필자의 경우 항상 혼자 공부를 하다보면 인증 / 배포에관한 좋은 자료를 찾기가 어려운데 이 책에선 그런부분을 세심하게 알려주는 점이 매우 좋았다.

필자가 책을 읽어본후 느낀점이 이 책은 지식보다는 정보의 전달에 초점을 맞추고 있다는 점이다. 모든 개발자들이 당연히 node.js를 이용하면 웹 / 데스크톱 / 모바일 에서 구동되는 프로그램을 만들 수 있다는 사실은 이미 알고있을것이다. 중요한것은 어떻게? 이다. 저자가 머릿말에서 말한것처럼 node.js / express / react / react-native 등 node.js의 프래임워크들을 각각 소개한 자료는 너무나도 많지만 모든것을 통합한 자료는 찾기 힘들다. 그말의 뜻은 어디서부터 시작해야할지 모른다는 의미이다. 책을 읽고난 후 독자는 '아무것도 모르는 상태' 에서 '내가 뭘 모르는지를 알고있는 상태'가 된다. 저자의 설명을 따라가면서 하나의 멀티플렛폼 서비스를 만드는 경험을 하고나면 내가 부족한점을 알게되고, 궁금한점을 알게된다. 이제 내가 뭘 모르는지 알게되었으니 그부분을 공부하면된다. 

여러 개발자들은 본인의 분야에서는 뛰어나지만 다른 분야에 대해서는 지식의 깊이가 깊어지기가 어렵다. 토이프로젝트를 해보려는 서버개발자의 첫번째 난관이 이것일거같다. '프론트는 어떻게하지? 요즘 서비스를 모바일 없이 하는게 말이되나? 안드로이드랑 스위프트를 공부해야하나?' 이런 고민이드는 개발자라면 가볍게 이 책을 읽기를 권한다.

책에서 깊은 내용을 다루고있지는 않지만 저자가 친절하게 더 자세한 내용을 공부하고싶은 사람들을 위해서 좋은 레퍼런스가 있는 url을 알려준다. 한번읽으면서 표시해두었다가 본격적으로 공부를 할때 찾아보면 도움이 될것이다. 

결론 

소스코드에 익숙한 개발자들이 토이프로젝트를 진행하기전에 한번 읽어보길 추천한다. 저자가 소개해주는 정보를 보고 예제를 따라하면 대략적으로 본인의 토이프로젝트를 어떻게 구성하면좋을지에대한 좋은 이사이트를 얻을 수 있다. 

본격적인 개발 경험이 없는 초보개발자에게도 추천한다. 저자는 책의 내용을 실습위주로 풀어내고있다. 저자의 설명을 들으면서 예제코드를 따라 치다보면 하나의 큰 서비스를 만드는 경험을 하게되고 초보개발자에게 이런 경험은 매우 중요하다. 

마치며

좋은 책을 리뷰할 기회를 준 한빛미디어 관계자분들께 감사의 인사를 드린다. 그리고 옆에서 날 항상 응원해주는 안랙술에게도 감사의 인사를 전하고싶다.

반응형

크루세이더 킹스 2 가 무료라는 소식을 듣고 다운을 받았다. 스팀에서 다운을 받았는데 화면이 이상하다... 해상도가 맛이 가서 클릭이안된다.

조금 찾아보니 남들도 좀 겪는 문제더라. 한글자료로는 못찾아서 영어로 찾았더니 나와서 여기에 공유한다.

스팀을 통해서 맥에 크루세이더 킹스 2 를 설치하고 한번 실행을하면 Document(문서)/Paradox Interactive/Crusader Kings II 폴더 아래에 setting.txt 라는 파일이 생성되면서 세팅이 저장된다.

해당 파일을 열고

graphics=  
{  
    size=  
    {  
        x=1680  
        y=1050  
    }  

    gui\_scale=1.000000  
    gui\_scale\_min=1.000000  
    gui\_scale\_max=3.000000  
    gui\_scale\_font\_replacement=1.010000  
    refreshRate=0  
    fullScreen=no  
    borderless=yes  
    shadows=no  
    shadowSize=2048  
    multi\_sampling=0  
    anisotropic\_filtering=0  
    gamma=50.000000  
    vsync=yes  
    override\_resolution\_safety=no  
}

graphics 부분을 수정해주면된다.

반응형

Iterator

컬렉션에 저장된 요소를 읽어오는 방법을 표준화한것.
다음의 메소드를 포함하고있다.

  • hasNext() : 읽어올 다음 요소가 있는지 확인하는메소드. 다음 요소가 있다면 true, 없다면 false를 반환
  • next(): 다음 데이터를 리턴
  • remove() : next()로 읽어온 요소를 제거.
반응형

Interface VS Abstract

Abstract class(추상 클래스)

  • 클래스 구현 내부에 추상 메서드가 하나 이상 포함되거나 abstract로 정의된 경우.
  • Abstract class의 특징
    • new 연산자를 사용하여 객체르 생성할 수 없다.
      • 단일 상속만이 가능하다.
      • Abstract 클래스는 동일한 부모를 가지는 클래스를 묶는 개념으로 상속을 통하여 기능을 확장시키는것이 목적이다.

Interface

  • 모든 메소드가 추상 메소드이다.
  • Java 8 이후에서는 default 키워드를 이용하면 메소드를 구현할 수 도 있다.
  • static final필드만 가질 수 있다.
  • new 연산자를 사용하여 객체를 생성할 수 없다.
  • 다중상속이 가능하다.
  • 구현 객체가 같은 동작을 한다는것을 보장하려는 목적으로 사용된다.

Abstract class와 Interface의 공통점

  • 선먼만 있고 구현 내용은 없는 클래스이다.
  • 인스턴스화가 불가능하다.
  • 상속 / 구현한 클래스를 이용해서 객체를 생성해야한다.

Abstract class와 Interface의 차이점

  • Abstract class - 단일상송 / Interface - 다중 상속
  • Abstract 의 목적은 상속을 이용하여 기능을 확장시키는 것이다.
  • Interface의 목적은 메소드가 구현됨을 보장하는것이다.
반응형

'프로그래밍 > 면접대비문제' 카테고리의 다른 글

스프링 부트 어플리케이션이 실행되면 어떤 일들이 일어나는가.  (0) 2024.11.30
이터레이터(Iterator)  (0) 2021.01.11
WAS의 동작방식  (0) 2021.01.11
DB정규화  (0) 2021.01.11
MVC란?  (0) 2021.01.11

+ Recent posts