도커란?

도커(Docker)는 컨테이너 기반 가상화 플랫폼으로, 소프트웨어 애플리케이션을 패키징하고 배포하는 데 사용됩니다. 도커는 애플리케이션과 그에 필요한 모든 종속성을 포함하는 독립적인 실행 환경을 제공하여 개발, 테스트 및 배포 과정을 간소화합니다. 이를 통해 애플리케이션의 이식성과 확장성을 크게 향상시킬 수 있습니다.

도커를 사용하는 이유

도커는 애플리케이션과 모든 종속성을 독립적인 컨테이너로 패키징합니다. 이렇게 패키징된 컨테이너는 어디에서든 실행될 수 있으며, 개발 환경과 프로덕션 환경 간의 차이를 줄여줍니다. 이식성이 뛰어나므로 다양한 환경에서 애플리케이션을 실행할 수 있습니다. -> 같은 기능으로 가상머신(Virtual Machine)과 비슷하지만 도커를 사용하면 리소스를 분리하여 사용하기 때문에 도커는 각 컨테이너를 격리된 환경에서 실행하므로 서로 영향을 미치지 않고 여러 애플리케이션을 동시에 실행할 수 있습니다. 이를 통해 리소스 사용을 효율적으로 관리하고 보안을 강화할 수 있습니다.

도커 작동

도커는 이미지를 통해 컨테이너를 만들고 이를 통해 격리된 환경 속에서 작업할 수 있게합니다.

도커허브를 통해 가져온 이미지 또는 생성한 이미지 -> 컨테이너 생성

도커 용어

컨테이너: 도커에서 애플리케이션과 해당 환경을 패키지화하는 단위를 컨테이너라고 합니다. 이 컨테이너는 코드, 런타임, 시스템 도구, 시스템 라이브러리 및 설정 파일을 포함하며 모든 종속성을 격리된 환경에서 실행합니다.

이미지: 컨테이너를 만들기 위한 템플릿이며, 애플리케이션과 그 종속성을 정의합니다. 이미지는 읽기 전용이며 변경할 수 없습니다. 이미지는 Docker Hub와 같은 레지스트리에 저장되고 공유할 수 있습니다.

도커 엔진: 도커 컨테이너를 생성, 관리 및 실행하는 핵심 엔진입니다. 도커 엔진은 컨테이너의 라이프사이클 관리, 네트워킹, 스토리지 관리 등을 담당합니다.

도커 컴포즈: 여러 컨테이너를 정의하고 연결하여 복잡한 애플리케이션 스택을 관리하는 도구입니다. 컴포즈 파일을 사용하여 애플리케이션 구성을 정의하고 일괄적으로 배포할 수 있습니다.

도커 스웜: 도커 내장 오케스트레이션 도구로, 여러 호스트에서 컨테이너를 관리하고 스케일링하며 고가용성을 제공합니다.

도커 레지스트리: 도커 이미지를 저장하고 공유하기 위한 중앙 저장소입니다. Docker Hub는 가장 널리 사용되는 레지스트리 중 하나이며, 사용자 정의 레지스트리를 구성할 수도 있습니다.

도커 컴포넌트: 도커는 다양한 구성 요소로 구성되며, 주요 컴포넌트로는 도커 데몬(Docker Daemon), 도커 클라이언트(Docker Client), 도커 이미지, 도커 컨테이너, 도커 레지스트리 등이 있습니다.

인텔리제이서 개발중이나 로컬에서 서버를 배포할때는 mysql을 사용하지만 aws에서 배포할때는 rds사용 예정 -> 서버 설정 분리가 필요

2. 서버 설정 분리 방법

application.yml을 사용한 분리 구상 application.yml -> 일반적으로 사용하는 애플리케이션 실행 환경 application-local.yml -> 로컬 환경에서 사용하는 정보들 application-server.yml -> server 환경에서 사용되는 정보들

application.yml - jpa, sql, logging, server등 설정

spring:
  jpa:
    hibernate:
      ddl-auto: create-drop
    show-sql: true
    properties:
      hibernate:
        format_sql: true
  sql:
    init:
      data-locations: classpath*:db/h2/data.sql
logging:
  level:
    org:
      springframework:
        orm:
          jpa: DEBUG
server:
  servlet:
    encoding:
      force-response: true

# 공통 설정 내용...

application-local.yml - 로컬에서 사용할 mysql설정

spring:
  profiles:
    active: local

# MySQL 데이터베이스 설정
spring:
  datasource:
    url: jdbc:mysql://localhost:3306/{데이터베이스 이름}?useSSL=false&allowPublicKeyRetrieval=true&useLegacyAuth=false
    username: {데이터베이스 유저 이름}
    password: {데이터베이스 비밀번호}
    driver-class-name: com.mysql.cj.jdbc.Driver

  jpa:
    database-platform: org.hibernate.dialect.MySQL8Dialect
    {현재mysql8.0.32버전이기 때문에 MySQL8Dialect시용 mysql 버전에 맞게 변경하기}

# 로컬 전용 설정 내용...

application-server.yml - 서버에서 사용할 aws rds설정

spring:
  profiles:
    active: server

# AWS RDS를 사용하는 MySQL 데이터베이스 설정
spring:
  datasource:
    url: jdbc:mysql://{AWS RDS Endpoint}/{데이터베이스 이름}?useSSL=false&characterEncoding=UTF-8&serverTimezone=UTC
    username: {RDS Mysql Admin id}
    password: {RDS Mysql Admin password}
    driver-class-name: com.mysql.cj.jdbc.Driver

  jpa:
    database-platform: org.hibernate.dialect.MySQL8Dialect

# 서버 전용 설정 내용...

이 세가지 파일로 서버 설정을 분리한다. 이후 아래 3번의 세가지 방법 중 상황에 알맞게 spring.profiles를 설정한다.

3-1. 인텔리제이에서 spring.profiles 설정하기

인텔리제이에서 spring.profiles설정하는 방법

1. Run/Debug configuration 클릭
2. Modify options -> Add VM options 클릭
3. Active Profile 옵션 추가

   -Dspring.profiles.active={프로파일}

3-2. application.yml 설정

위 application.yml에 spring.profiles.active 설정을 추가한다.

spring:
  profiles:
    active: local
# 공통 설정 내용...

3-3. ./gradlew build 명령을 사용하여 spring.profiles.active를 설정하는 방법

Windows: ./gradlew build -Dspring.profiles.active={프로파일} macOS/Linux: ./gradlew build -Dspring.profiles.active={프로파일}

4. 완료!

이후 실행하면 local설정으로 mysql과 연동된다

참고 글 https://velog.io/@be_have98/IntelliJ-Spring-Boot%EC%9D%98-Active-Profile-%EC%84%A4%EC%A0%95

Caused by: java.sql.SQLSyntaxErrorException: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'type=MyISAM' at line 6

오류 이유

MySQL 서버의 버전에 따라 사용 가능한 문법이 다를 수 있다. 현재 사용하는 mysql버전은 8.0.33으로, MySQL 8.0 이상에서는 'type' 키워드 대신 'engine' 키워드를 사용해야 한다.

해결법

application.yml에서 MySQLDialect를 MySQL8Dialect로 수정하였다.

org.hibernate.dialect.MySQLDialect
//-> 수정
database-platform: org.hibernate.dialect.MySQL8Dialect

참고 https://stackoverflow.com/questions/43716068/invalid-syntax-error-type-myisam-in-ddl-generated-by-hibernate

해당 코드는 phone이 object타입으로 반환되어 setPhone()가 실행되지않는다.

이때, 해당 코드의 isPresent를 ifPresent로 수정한다면

Optional.ofNullable(member.getPhone())
                .ifPresent(phone -> findMember.setPhone(phone));

제대로 작동하게된다.

이유. isPresent() 메서드는 Optional 객체에 값이 존재하는지 여부를 확인하기 위해 사용되는 메서드이지만, 해당 메서드의 매개변수는 Consumer 타입을 받아들인다.

그러므로 ifPresent() 메서드로 수정하여 매게변수가 Optional 객체가 값으로 반환하게 한다.

GitHub에서 브랜치란 독립적으로 어떤 작업을 진행하기 위한 개념입니다. 여러 개발자들이 동일한 소스코드를 기반으로 서로 다른 작업을 할 때에는 각각 서로 다른 버전의 코드가 만들어질 수 밖에 없습니다. 이럴 때, 여러 개발자들이 동시에 다양한 작업을 할 수 있게 만들어 주는 기능이 바로 '브랜치'입니다.

git 설정

# 버전 히스토리를 식별할 때 사용할 이름을 설정합니다.
git config --global user.name "[firstname lastname]"

# 각 기록과 연결할 이메일 주소를 설정합니다.
$ git config --global user.email “[valid-email]”

파란박스: 연결된 작성자 노랑박스: 연결된 이메일

브랜치 확인

# 브랜치 목록을 보여줍니다. * 표시로 현재 작업중인 브랜치를 확인할 수 있습니다.
$ git branch

브랜치 생성

# 현재 커밋에서 새로운 브랜치를 생성합니다.
$ git branch [branch-name]

브랜치 전환

# 다른 브랜치로 전환합니다.
$ git switch [branch-name]
$ git checkout [branch-name]

# 새로은 브랜치를 생성하고 해당 브랜치로 전환합니다.
$ git switch -c [branch-name]
$ git checkout -b [branch-name]

브랜치 합병

# 현재 브랜치에 특정 브랜치의 히스토리를 병합합니다.
$ git merge [branch-name]

브랜치 삭제

# 특정 브랜치를 삭제합니다.
$ git branch -d [branch-name]

섹션3가 끝난게 어제같은데 벌써 한달이 지나서 섹션4도 끝났습니다. 아직 스스로 부족하다고 느끼는데 벌써 교육과정 내 있는 학습기간은 끝나고 이제 프로젝트 2달의 일정만 남아 아쉽고 정말 이런 상태로 팀으로 작업해도될까하는 생각이 들기도 합니다. 그래도 마지막으로 솔로프로젝트를 하며 간단한 구현 사항들이어도 어떻게든 시간안에 최소한이긴해도 완료를 해서 그나마 작업에 들어갈 수 있을것 같아 교육과정이 치밀하다고 느꼈습니다. 섹션3 시작 이후부터 계속 멘탈을 잡는게 힘들지만 팀 작업 동안은 정말 혼자 학습할 때보다 마지막까지 힘내보겠습니다.

단기 목표

앞으로의 프로젝트 완성, 이제 교육과정에 포함되어 있던 학습들은 끝났고 프로젝트에 필요한 기초교양이 준비되었다고 생각합니다. 아직 매운 부족한 개발자지만 이 기초에서 더 필요한게 있다면 그걸 추가학습을 통해 적어도 두달간 있을 프로젝트를 완성하고싶습니다.

keep

• aws실습 중 몇가지 오류상황을 만났고 그것에 대해 블로그에 기록하였습니다.

problem

• 저번 회고에서 준비하던 개인프로젝트에 대해 이번 회고에서는 완성할 수 있을거라 생각했지만 완성하지 못했습니다.
• 솔로 프로젝트를 하며 개인프로젝트보다 간단한 구현사항이었지만, 빠르게 구현하지못하여서 아쉬웠고 아직 스스로 부족하다고 느꼇습니다.

try

• 완성하지 못한 개인프로젝트를 주말이라던가 틈틈히 완성해보면 좋을 것 같습니다.
• 솔로프로젝트에 대해 추가로 적용할 사항들도 개인시간에 적용해봐야할 것 같습니다.

다음 사진에서 "Web server failed to start. Port 8080 was already in use." 문구를 찾을 수 있다. 이전에 실행한 프로그램이 작동하며 포트 8080을 이미 사용하고 있는 상태일때 이런 로그창이 뜨게된다.

이때 해결방법으로는 포트를 종료시키는 것이다.

1. 사용되고 있는 프로세스 찾기

• cmd 창에 netstat 명령어를 입력한다

  sudo netstat -tnlp

※sudo를 이용해 root 권한을 획득해야 pid정보가 보여진다. grep 명령어를 이용한 출력결과 필터링

sudo netstat -tnlp | grep 80

2. 프로세스 종료

-이렇게 찾은 pid정보를 사용해 프로세스를 종료 시킨다

sudo kill -9 {pid정보}

애플리케이션 생성시 다음과 같은 오류가 뜰때 문제의 이유는 서울 외 다른 리전에서 진행되었기 때문이다 us-east-1(미국 동부) -> ap-northeast-2(아시아 태평양(서울))

※IAM, S3는 리전에 국한되지 않고 글로벌 환경에서 사용합니다. 그외의 서비스에서는 리전 변경이 가능하다.

연결된 소스에 대한 IAM 권한 부족에 대한 문제로 해결방법으로는 IAM 권한을 재설정과 신뢰관계를 재설정해보는 방법이 있다. 만일 재설정으로도 고쳐지지않는다면 IAM 엑세스 관리 - 정책에서 문제가 되는 객체를 찾은 후 연연결된 객체가 제대로 설정되어 있는지 확인한다.

저의 경우 AWSCodePipelineServiceRole이 연결된 객체가 없어 생기는 문제였습니다.

2. 깃헙 브랜치가 존재하지않음

깃허브 브랜치가 존재하지 않는 오류로 첫번째로 정말 리포지토리에 브랜치가 없는지 확인하는 방법이 첫번째이고, 존재할 경우 리포지토리 이름을 확인해야한다. 저의 경우 리포지토리 이름을 잘못 작성한 문제였기 때문에 파이프라인을 수정하였습니다. 파이프라인 수정 방법은 편집 -> 스테이지 편집 -> 편집하는 스테이지의 버튼 이 방법으로 파이프라인 생성시 작성했던 리포지토리 이름을 수정할 수 있습니다.

인증 처리 순서

1. 사용자는 웹 브라우저에서 Spring Security가 보호하는 리소스에 대한 요청을 보냅니다.

• 사용자는 웹 브라우저에서 Spring Security가 보호하는 리소스에 대한 요청을 보냅니다. 예를 들어 사용자는 Spring Security가 보호하는 웹 페이지를 보려 할 수 있습니다.

2. Spring Security는 요청을 처리하기 위해 필터 체인을 실행합니다.

• Spring Security는 요청을 처리하기 위해 필터 체인을 실행합니다. 필터 체인은 Spring Security가 제공하는 일련의 필터입니다. 각 필터는 요청을 처리하는 특정 작업을 담당합니다.

3. 필터 체인에서 UsernamePasswordAuthenticationFilter가 요청을 처리합니다.

• 필터 체인에서 UsernamePasswordAuthenticationFilter가 요청을 처리합니다. UsernamePasswordAuthenticationFilter는 사용자가 Spring Security가 보호하는 리소스에 액세스하려고 시도하는지 확인합니다.

4. UsernamePasswordAuthenticationFilter는 사용자 이름과 암호를 요청에서 가져옵니다.

• UsernamePasswordAuthenticationFilter는 사용자 이름과 암호를 요청에서 가져옵니다. 사용자 이름과 암호는 HTTP 요청의 본문에 포함될 수도 있고 HTTP 요청의 헤더에 포함될 수도 있습니다.

5. UsernamePasswordAuthenticationFilter는 사용자 이름과 암호를 사용하여 사용자를 인증합니다.

• UsernamePasswordAuthenticationFilter는 사용자 이름과 암호를 사용하여 사용자를 인증합니다. 인증은 사용자 이름과 암호가 데이터베이스에 저장된 사용자의 이름과 암호와 일치하는지 확인하는 프로세스입니다.

6. 인증이 성공하면 Spring Security는 사용자 정보를 SecurityContext에 저장합니다.

• 인증이 성공하면 Spring Security는 사용자 정보를 SecurityContext에 저장합니다. SecurityContext는 현재 요청에 대한 보안 컨텍스트를 저장하는 Spring Security 개체입니다.

7. Spring Security는 요청을 리소스로 전달합니다.

• Spring Security는 요청을 리소스로 전달합니다. 리소스는 SecurityContext에 저장된 사용자 정보에 따라 사용자에게 응답합니다.

8. 리소스는 사용자에게 응답합니다.

• 리소스는 사용자에게 응답합니다. 리소스는 HTML 페이지, 이미지 또는 기타 유형의 데이터일 수 있습니다.

섹션3 동안은 스프링프레임워크에 대해 전체적으로 배우며 간단하게나마 서버를 구현했습니다. 한달이라는 짧은 기간동안 스프링프레임워크에 대해 급하게 학습하다보니 개인적으로 간신히 진도를 나갔습니다. 아직 배운지 얼마 안된 프레임워크라 기능에 대해 잘 알고있지 못해서인것 같습니다. 섹션3 내내 진도를 따라기 벅찼지만 당일진도는 그날안에서 해결하였습니다. 그리고 학습하는 과정에서 지금 스프링에 대한 이해가 부족하여 힘들다는 생각을 하게되어 위키 사이드 프로젝트를 구상하였습니다.

problem

전체적인 흐름에 대한 이해는 어느정도 하게되어 어디가 문제인지를 알게되더라도 프레임워크 사용법에 익숙하지 않아서 그걸 해결하는데 많은 시간을 들이게됩니다. 또한 잘 알지 못한다는 생각에 블로그 작성이 점점 밀려 이번 섹션에서는 작성의 거의 하지 못하였습니다.

keep

스프링프레임워크에 대해 아직 완벽하게 이해하지는 못했지만 중요한 부분 먼저 블로깅을 완성하고, 그동안 잠시 느슨하게 해왔던 알고리즘 문제풀이를 다시 시작해야할 것 같습니다. 그리고 구상한 사이드 프로젝트에 대해 아직 정말 초기 단계이기 때문에 섹션4가 끝날때 어느정도 완성되길 기대해봅니다.

JDBC API를 사용해 개발자는 다양한 벤더(Oracle, MS SQL, MySQL 등)의 데이터베이스와 연동할 수 있다

JDBC API의 사용법을 배워야 할까? 결론: JDBC API를 사용할 가능성은 거의 없다고 봐도 무방하다 다만, Spring Data JDBC나 Spring Data JPA 같은 기술 역시 데이터베이스와 연동하기 위해 내부적으로는 JDBC를 이용하기 때문에 JDBC의 구체적인 API 사용법을 알 필요는 없지만 JDBC의 동작 흐름 정도는 알면 Spring에서 지원하는 데이터 액세스 기술을 사용하는데 도움이 된다.

JDBC의 동작흐름 JDBC는 Java 애플리케이션 내에서 JDBC API를 사용하여 데이터베이스에 액세스하는 단순한 구조이기 때문에 JDBC의 동작 흐름은 매우 심플하다.

Java 애플리케이션에서 JDBC API를 이용해 적절한 데이터베이스 드라이버를 로딩한 후, 데이터베이스와 인터랙션 한다

이처럼 JDBC API를 사용해 데이터베이스와 구체적인 인터랙션을 하기 위해서는 JDBC 드라이버를 먼저 로딩한 후에 데이터베이스와 연결을 해야한다.

• JDBC 드라이버(JDBC Driver) JDBC 드라이버는 데이터베이스와의 통신을 담당하는 인터페이스인데, Oracle이나 MS SQL, MySQL 같은 다양한 벤더에서는 해당 벤더에 맞는 JDBC 드라이버를 구현해서 제공을 하게 되고, 우리는 이 JDBC 드라이버의 구현체를 이용해서 특정 벤더의 데이터베이스에 액세스 할 수 있다.

JDBC API 사용 흐름 JDBC 드라이버 로딩 사용하고자 하는 JDBC 드라이버를 로딩합니다. JDBC 드라이버는 DriverManager라는 클래스를 통해서 로딩됩니다.

Connection 객체 생성 JDBC 드라이버가 정상적으로 로딩되면 DriverManager를 통해 데이터베이스와 연결되는 세션(Session)인 Connection 객체를 생성합니다.

Statement 객체 생성 Statement 객체는 작성된 SQL 쿼리문을 실행하기 위한 객체로써 객체 생성 후에 정적인 SQL 쿼리 문자열을 입력으로 가집니다.

Query 실행 생성된 Statement 객체를 이용해서 입력한 SQL 쿼리를 실행합니다.

ResultSet 객체로부터 데이터 조회 실행된 SQL 쿼리문에 대한 결과 데이터 셋입니다.

ResultSet 객체 Close, Statement 객체 Close, Connection 객체 Close JDBC API를 통해 사용된 객체들은 사용 이후에 사용한 순서의 역순으로 차례로 Close를 해주어야 합니다.

Connection Pool이란? DBC API를 사용해서 데이터베이스와의 연결을 위한 Connection 객체를 생성하는 작업은 비용이 많이 드는 작업 중 하나입니다.

따라서 애플리케이션 로딩 시점에 Connection 객체를 미리 생성해 두고 애플리케이션에서 데이터베이스에 연결이 필요할 경우, Connection 객체를 새로 생성하는 것이 아니라 미리 만들어 둔 Connection 객체를 사용함으로써 애플리케이션의 성능을 향상할 수 있습니다.

이처럼 데이터베이스 Connection을 미리 만들어서 보관하고 애플리케이션이 필요할 때 이 Connection을 제공해 주는 역할을 하는 Connection 관리자를 바로 Connection Pool이라고 합니다.

목표 리마인드

백엔드 개발자로의 취직

회고에 앞서

섹션2의 회고를 요약해 본다면 "너무 어려워서 순식간에 지나갔다"인것 같습니다. 섹션1까지는 이전에 알고있던 지식을 바탕으로 어렵지않게 넘어갔다면, 지금은 spring을 처음 배우면서 좌절하고있는 상태 같습니다.

회고

섹션1을 끝낸지가 어제같은데 벌써 섹션2가 끝났다고 생각하니 시간이 너무 빠르게다고 생각합니다. 섹션2에서는 자료구조와 알고리즘으로 시작하여 아무래도 섹션1에 비해 더 시간이 빠르다고 느껴진것같습니다. 중간에 있던 데이터베이스와 네트워크는 어떻게 할만했던것같지만 그 이후에 나온 spring은 마치 코딩을 처음 배울때처럼 힘들었습니다. 앞으로 스프링에 대한 심화학습을 섹션3에서 하는걸로 알고있는데 벌써부터 걱정이됩니다.

keep

알고리즘 문제 풀이를 매일 도전함 이해되지않거나 부족한 부분에 대해 스스로 찾아서 학습해보았음

problem

spring에 대해 개념은 이해가 가지만 실습에 대해 이해가 가지않는 부분이 많음 알고리즘 심화가 잘 풀어지지않음

try

알고리즘 풀이에 대해 미루지말고 깃헙 커밋하기 스프링에 대한 학습을 더 꾸준히 할 것

Library는 애플리케이션 흐름의 주도권이 개발자에게 있고, Framework은 애플리케이션 흐름의 주도권이 Framework에 있다. 하지만, 애플리케이션 흐름의 주도권이 뒤바뀐 것을 바로 IoC(Inversion of Control)라고 합니다

Java 웹 애플리케이션에서 IoC가 적용되는 예 위 사진은 서블릿 기반의 애플리케이션을 웹에서 실행하기 위한 서블릿 컨테이너의 모습입니다. Java 콘솔 애플리케이션의 경우 main() 메서드가 종료되면 애플리케이션의 실행이 종료됩니다.

하지만 웹에서 동작하는 애플리케이션의 경우 클라이언트가 외부에서 접속해서 사용하는 서비스이기 때문에 main() 메서드가 종료되지 않아야 할 것입니다.

그런데 서블릿 컨테이너에는 서블릿 사양(Specification)에 맞게 작성된 서블릿 클래스만 존재하지 별도의 main() 메서드가 존재하지 않습니다.

main() 메서드처럼 애플리케이션이 시작되는 지점을 엔트리 포인트(Entry point)라고도 부릅니다.

main() 메서드가 없는데 어떻게 애플리케이션이 실행 되는 걸까요?

서블릿 컨테이너의 경우, 클라이언트의 요청이 들어올 때마다 서블릿 컨테이너 내의 컨테이너 로직(service() 메서드)이 서블릿을 직접 실행시켜 주기 때문에 main() 메서드가 필요없습니다.

이 경우에는 서블릿 컨테이너가 서블릿을 제어하고 있기 때문에 애플리케이션의 주도권은 서블릿 컨테이너에 있습니다.

바로 서블릿과 웹 애플리케이션 간에 IoC(제어의 역전)의 개념이 적용되어 있는 것입니다.

POJO 프로그래밍이란? POJO 프로그래밍이란 POJO를 이용해서 프로그래밍 코드를 작성하는 것을 의미합니다. 그런데 단순히 순수 자바 객체만을 사용해서 프로그래밍 코드를 작성한다라고 해서 POJO 프로그래밍이라고 볼 수는 없습니다.

• Java나 Java의 스펙(사양)에 정의된 것 이외에는 다른 기술이나 규약에 얽매이지 않아야 한다.
• 특정 환경에 종속적이지 않아야 한다.

POJO 프로그래밍이 필요한 이유 POJO 프로그래밍이 필요한 이유는 앞에서 설명한 예시에 잘 나와 있습니다.

특정 환경이나 기술에 종속적이지 않으면 재사용 가능하고, 확장 가능한 유연한 코드를 작성할 수 있다. 저수준 레벨의 기술과 환경에 종속적인 코드를 애플리케이션 코드에서 제거 함으로써 코드가 깔끔해진다. 코드가 깔끔해지기 때문에 디버깅하기도 상대적으로 쉽다. 특정 기술이나 환경에 종속적이지 않기 때문에 테스트 역시 단순해진다. 객체지향적인 설계를 제한없이 적용할 수 있다.(가장 중요한 이유)

핵심 포인트 POJO란 순수한 Java 객체를 의미한다. POJO 프로그래밍이란 순수 Java 객체가 다른 기술이나 환경에 종속되지 않도록 하기 위한 프로그래밍 기법이다. POJO 프로그래밍을 효과적으로 적용하기 위해서는 특정 기술에 대한 지식보다는 JDK의 API에 대한 지식과 객체지향적인 사고방식과 설계를 위한 훈련이 우선시 되어야 한다. Spring Framework은 POJO 프로그래밍을 지향하기 위해 IoC/DI, AOP, PSA 라는 기술을 제공한다.

POJO와 Spring Framework의 관계 Spring Framework를 사용하기 전에는 원하는 특정한 기술이 있다면 해당 기술을 직접적으로 사용하는 객체를 만들어 사용했습니다. 다만 프로젝트가 커지고 필요한 기술들이 늘어나며 특정한 기술과 환경에 종속되는 경우가 자주 발생하여 작성된 코드의 유지/보수가 어렵고 특정 클래스를 상속받게 되어 기능의 확장이 어려운 경우도 많이 생겼습니다. 좋은 객체지향 설계를 할 수 있는 Java언어를 사용하면서도 결국 객체지향 설계 본질을 잃어버리는 문제점들을 해결하고자 POJO라는 개념이 등장하게 되었습니다.

Java 언어의 특징중 어떤점이 장점으로 다가올 수 있을까요? 정적 타입 언어로서 변수의 타입, 메서드의 입력과 출력이 어떤 타입을 가져야 하는지를 강제합니다. 이는 곳 여러사람이 함께 작업할 때, 다른 사람의 코드 혹은 이전에 내가 작성했던 코드를 수정, 보완이 용이하고 웹 서버를 구축하는데 있어서 런타임에 발생하는 오류를 사전에 방지할 수 있습니다.

Spring Framework를 사용하는 이유 대부분의 기업들이 기업용 엔터프라이즈 시스템용 애플리케이션 개발에 있어 Framework을 선택할 때, 개발 생산성을 높이고 어떻게 하면 애플리케이션의 유지 보수를 조금 더 용이하게 할 것인가에 많은 초점을 맞추는것이 사실입니다.

기업용 엔터프라이즈 시스템 기업용 엔터프라이즈 시스템이란 기업의 업무(기업 자체 조직의 업무, 고객을 위한 서비스 등)를 처리해주는 시스템을 의미합니다. 기업용 엔터프라이즈 시스템은 대량의 사용자 요청을 처리해야 하기 때문에 서버의 자원 효율성, 보안성, 시스템의 안전성이나 확장성 등을 충분히 고려해서 시스템을 구축하는 것이 일반적입니다.

// dy 배열을 초기화한다.
Arrays.fill(dy, amount + 1);
dy[0] = 0;

// 모든 동전에 대해 dy 배열을 계산한다.
for (int i = 1; i <= amount; i++) {
    for (int j = 0; j < coins.length; j++) {
        if (coins[j] <= i) {
            dy[i] = Math.min(dy[i], dy[i - coins[j]] + 1);
        }
    }
}

return dy[amount] > amount ? -1 : dy[amount];

}```

2월부터 시작한 부트캠프에서의 한달이 지나 벌써 진도상 Section1을 마치게 되었습니다. 처음 부트캠프를 시작하면서 반년을 또 공부해야하는 한다는 현실에 막막하였는데 막상 Section1이 끝나고 보니 한달이 정말 짧게 느꼈졌습니다. Section1을 돌이켜보면 객체지향까지는 과거 하던 게임개발을 떠올리며 그때 이랫더라면 하고 di(의존성 주입)등을 생각해 그렇게 어렵게 느껴지진 않았습니다. 하지만 컬렉션 프레임워크, 자바 심화의 스트림에서부터는 확실히 조금 더 어려워짐을 느끼며 정신을 차려야겠다고 생각하게되었습니다. 사실 부트캠프에 오기 전에는 "6개월 동안 어떻게 개발자가 될수 있지"라는 의문이 있었지만 이런 시간표라면 확실히 6개월 동안 부족했던 부분과 모르던 부분을 배울수 있을거라 확신이 들었습니다.

Section1 KPT 정리

keep 목표를 달성하기 위해 시도했던 것 중 가장 효과적이었던 노력은 무엇인가요? 목표를 달성하기 위해 했던 모든 노력 중 반드시 유지해야 할 것은 무엇인가요?

• 실습 위주의 학습 이론으로 배웠던 코드를 인텔리제이를 통해 다시 작성하며

problem 목표를 달성하기 위해 세웠던 계획 중 가장 유지하기 어려웠던 것은 무엇인가요? 목표를 달성하는데 있어서 가장 큰 장애물은 무엇인가요?

• 매일 블로깅 하기.
  • 코드를 올려야하는지와

try 목표를 달성하기 위해 반드시 제거해야 하는 장애물이 있다면, 어떻게 제거할 수 있을까요? 목표를 달성하기 위해 계속해서 유지해야 할 노력이 있다면 무엇인가요?

우선순위 정하기 가장 시급하면서 가장 빠르게 시도할 수 있는 것 시급하지만 시도하는데 시간이 걸리거나, 빠르게 시도가 가능하지만 시급하지 않은 것 시급하지 않고 시도하는데 시간이 걸리는 것

마무리

Section2부터는 알고리즘과 자료구조 등을 시작하게 될텐데 그부분에 있어서는 많이 부족했고 그랫기 때문에 부프캠프에서 가장 기대하던 부분으로 제발 저 자신이 포기하지 않고 지금보다 더 열심히 학습하길 바랍니다.

이 알고리즘은 최적해를 보장하지는 않지만, 일부 문제에서는 최종적 해답을 구할 수 있는 간단하고 효과적인 방법이 될 수 있습니다.

보통 그리디 알고리즘은 다음과 같은 구성으로 이루어집니다:

• 선택 단계(Selection phase): 현재 상황에서 가장 최선의 선택을 합니다.
• 적절성 검사 단계(Feasibility check phase): 선택한 단계가 해결하고자 하는 문제의 조건을 만족시키는지 확인합니다.
• 해결 단계(Solution phase): 문제의 해를 구하거나 다음 선택 단계로 이동합니다.

그리디 알고리즘을 사용할 수 있는 대표적인 문제로는 다익스트라 알고리즘, 크루스칼 알고리즘, 프림 알고리즘이 있습니다.

탐욕 알고리즘을 적용해 해결하기 위해서는 문제는 다음 2가지 조건을 성립하여야 한다.

• 탐욕적 선택 속성(Greedy Choice Property) : 앞의 선택이 이후의 선택에 영향을 주지 않습니다.
• 최적 부분 구조(Optimal Substructure) : 문제에 대한 최종 해결 방법은 부분 문제에 대한 최적 문제 해결 방법으로 구성됩니다.

탐욕 알고리즘은 항상 최적의 결과를 도출하는 것은 아니지만, 어느 정도 최적에 근사한 값을 빠르게 도출할 수 있는 장점이 있습니다. 이 장점으로 인해 탐욕 알고리즘은 근사 알고리즘으로 사용할 수 있습니다.