소프트웨어 설계 중 Agile (애자일) 방법론이란? 정의, 예시, type

소프트웨어 개발방법론 중 Agile(애자일) 방법론이라는 개념에 대해 알아보자.

Agile은 영어로 "민첩한" 이라는 의미를 가지고 있다.

이를 생각하면 애자일 방법론의 개념에 대해서도 쉽게 이해할 수 있는데,

Agile 방법론이란 개발과 함께 즉시 피드백을 받아서 유동적으로 개발하는 방법을 뜻한다. 

Agile 방법론 개념도

애자일 방법론은 위와 같은 개념도로 나타낼 수 있다. 

 

애자일 방법론은 크게 두 가지의 배경과 함께 등장했다.

첫 번째로 소프트웨어 개발 환경이 변화하는 상황 속에서 등장했다.

모바일 환경으로 소프트웨어 개발 트렌드가 변화하면서 시장 적시성 뿐 아니라 잦은 배포가 중요해졌다.

이와 함께 두번째 배경으로는 기존 개발방법론의 한계를 들 수 있다.

기존 개발 방법론은 문서와 절차 위주의 개발 방법을 활용했기 때문에 첫 번째 배경처럼 빠르게 변화하는 환경에서의 대응이 어려워졌다.

이에 따라 빠르게 적용하고 효율적으로 개발할 수 있는 방법론의 필요성이 대두되었다. 

 

애자일 방법론의 특징은 다음과 같다.

이는 2020년에도 정보처리기사 기출문제로 출제된 바가 있기 때문에 주의깊게 살펴보자. 

• 고객과의 피드백 중시
• 소프트웨어가 잘 실행되는 데 가치를 둠 (전통적 개발방법에서 문서나 절차가 중요했던 것과 상반되는 특징)
• 절차와 도구보다는 개인과 소통을 중요시함
• 작업 계획을 짧게 세워 요구 변화에 유연하고 신속하게 대응할 수 있음
• 프로젝트의 요구 사항은 기능 중심으로 정의

---

이러한 애자일 방법론에는 크게 세 가지 유형 (XP, Lean, Scrum)이 존재한다. 

 

1. XP (eXtreme Programming)

XP란 extreme programming을 줄인 단어로,

의사소통 개선과 즉각적 피드백으로 소프트웨어 품질을 높이기 위한 방법론이다.

기존의 방법론에 비해 '실용성'을 강조했으며 1~3주의 반복 개발 주기를 가진다.

XP가 중요시하는 가치는 Courage, Simplicity, Communication, Feedback, Respect 이렇게 총 5가지가 있다.

용기를 가지고 자신감 있게 개발하되, 필요한 것만 하고 그 이상의 것들은 하지 않으며,

원활한 소통, 피드백, 그리고 소통 과정 중 서로에 대한 존중을 중요시하는 것을 알 수 있다. 

XP에는 또한 12가지의 기본원리가 존재한다.

정보처리기사를 위해서는 일일히 암기할 필요는 없어 보이는데 나름 흥미로운 내용들이다. 

• Pair programming: 개발자 둘이서 짝으로 코딩
• Continuous Integration (CI) : 기존 CI의 개념과 동일. 매일 여러 번씩 소프트웨어의 통합과 빌드가 필요
• Collective Ownership: 시스템에 있는 코드는 누구든, 언제라도 수정 가능
• Planning Process: 고객의 요구 가치 정의, 개발자의 요구사항, 그리고 어떠한 부분에서 지연될 수 있는지를 알려주어야 함
• Small Release: 짧은 단위로 배포, 업데이트를 해야 함
• Metaphor: 공통적인 이름 체계와 시스템 서술서를 통해 고객과 개발자 간 의사소통을 원활하게 함
• Test Driven Develop (TDD) : TDD 또한 개발하는 사람이라면 한 번쯤은 들어보았을 것 같은 이름이다. 작성해야 하는 프로그램에 대한 테스트를 먼저 수행하고 해당 테스트를 통과할 수 있도록 코드를 작성해야 함
• Simple Design: 현재 요구사항에 적합한 가장 단순한 시스템을 설계해야 함. XP의 5가지 가치 중 Simplicity와 일맥상통한 원리임
• Refactoring: 프로그램의 기능을 바꾸지 않으면서 중복제거, 단순화를 위해 시스템을 재구성해야 함
• 40-Hour Work: 개인적으로 가장 흥미로웠던 원리. 개발자의 피곤으로 인한 실수를 방지하기 위해 일주일에 40시간 이상을 일하지 않아야 한다는 원리
• On Site Customer (고객 상주) : 개발자들의 질문에 즉각 대답해 줄 수 있는 고객을 프로젝트에 풀타임으로 상주시켜야 한다는 원리
• Coding Standard: 모든 코드에 대한 코딩 표준을 정의해야 함

---

2. Lean (린)

린 방식은 도요타의 린 시스템 품질기법을 소프트웨어 개발 프로세스에 적용해서 낭비 요소를 제거하여 품질을 향상시킨 방법론이다.

Just In Time, Kanban 보드를 사용하며 낭비 제거, 품질 내재화, 지식 창출, 늦은 확정, 빠른 인도, 사람 존중, 전체 최적화 등의 원칙을 가지고 있다.

---

3. Scrum (스크럼) 

스크럼은 매일 정해진 시간, 장소에서 짧은 시간의 개발을 하는 팀을 위한 프로젝트 관리 중심 방법론이다.

실제로 많은 IT 기업에서는 매일 특정 시간에 Scrum 회의를 실시하며 진행과정을 공유한다. 

 

위와 같이 XP, Lean, Scrum이 Agile 방법론의 가장 대표적인 유형이지만 이외에도 Crystal, ASD, FDD 방법론이 존재한다. 간단하게만 살펴보겠다.

---

4. Crystal (크리스탈)

크리스탈은 일반적인 프로세스나 도구보다는 '사람'에게 더 많은 중점을 두는 방법론이다.

생명이 중요하지 않은 시스템에서 작업하는 최대 6명/8명의 공동 배치 소프트웨어 개발자 팀에 적용하는 방식이다.

---

5. ASD (Adaptive Software Development)

이는 확실하지 않은 것, 혼란을 개발로 규정하고 그러한 혼란에서도 그에 적응할 수 있는 소프트웨어 방법을 제시하기 위해 만들어진 q방법론이다.

---

6. FDD (Feature Driven Development)

앞서 XP의 원리 중 우리는 TDD (test driven development)를 살펴보았다.

이와 반대로 FDD는 신규 기능 단위로 하는 개발 방법론을 의미한다. 

 

 

지금까지 애자일 (Agile) 방법론에 대해서 살펴보았다.

확실히 전통적 방법론에 비해 빠르게 변화하는 시대에 적합한 방법론을 제시한 것 같다.

[Java] cannot resolve symbol servlet 해결법, Servlet Interface 구현해보기

 Java에서 

이런 식으로 Servlet implements가 불가능하며 

빨간 줄에 커서를 대고 

'cannot resolve symbole servlet' 이라는 에러 메세지가 뜬다면 dependency의 문제일 확률이 높다.

build.gradle 파일에 가서 수정을 해주면 되는데,

implementation 'org.apache.tomcat.embed:tomcat-embed-core:8.5.42'
implementation 'org.apache.tomcat.embed:tomcat-embed-jasper:8.5.42'

나는 이 두 줄을 추가하고 build 하니 해당 에러 메세지를 해결 할 수 있었다. 

참고로 Servlet Interface를 implement할 경우 method를 모두 다 override 해주어야 하므로 

모든 추상 메서드에 대한 override method가 설정이 되어야 비로소 빨간 줄이 모두 없어진다. 

import javax.servlet.*;
import java.io.IOException;

public class ExampleServlet implements Servlet {

    @Override
    public void init(ServletConfig servletConfig) throws ServletException {

    }

    @Override
    public ServletConfig getServletConfig() {
        return null;
    }

    @Override
    public void service(ServletRequest servletRequest, ServletResponse servletResponse) throws ServletException, IOException {

    }

    @Override
    public String getServletInfo() {
        return null;
    }

    @Override
    public void destroy() {

    }
}

Servlet Interface를 구현한 예시 Servlet class이니 참고하면 될 것 같다. 

Java HTTP Request 사용법 (.http) + String으로 readLine해보기

우리가 흔히 사용하는 HTTP protocol의 요청이 어떻게 들어오는지를 위해 Java Spring을 사용하여 간단 코드를 작성해보았다. 

public void start() throws IOException {
    try (ServerSocket serverSocket = new ServerSocket(port)) {
        logger.info("1. Custom WAS started {} port.", port);

        Socket clientSocket;
        logger.info("2. Custom WAS waiting for the client.");

        while ((clientSocket = serverSocket.accept()) != null) {
            logger.info("3. Custom WAS client connected.");


            try (InputStream in = clientSocket.getInputStream(); OutputStream out = clientSocket.getOutputStream()) {
                BufferedReader br = new BufferedReader(new InputStreamReader(in, StandardCharsets.UTF_8));
                DataOutputStream dataOutputStream = new DataOutputStream(out);

                String line;
                while ((line = br.readLine()) != "") {
                    System.out.println(line);
                }
            }
        }
    }
}

그 다음으로는 Java project 최상단 우클릭 => New => HTTP Request를 클릭하여 

.http 확장자의 파일을 하나 만들어준다. 이렇게 .http를 사용하면 우리가 흔히 요청을 날릴 때 사용하는 Postman을 대체할 수 있고, Intellij에서 지원을 해주기 때문에 git으로도 버전 관리가 가능하다는 장점이 있다. 

그런 다음에  이렇게 8080 포트로 get 요청을 하나 보내준다. 

테스트 하기 위해서는 Java main class를 먼저 실행해 준 뒤, 생성한 .http 파일을 이후에 클릭해주면 자연스레 get 요청을 보내주는 것이다.

이렇게 하면 

client를 기다리다가 http 요청이 들어가 이후 client가 connected 되었다는 것을 알 수 있다. 

그 다음 들어오는 http request header를 읽기 위해서 BufferedReader를 사용하였고, 

BufferedReader를 통해 string으로 readLine() 을 할 수 있다. 

그 결과로 다음과 같은 String이 출력되는 것을 알 수 있다. 

GET 으로 HTTP/1.1 요청이 들어갔고 

Host 정보, Connection 정보, User-Agent, Accept-Encoding 정보가 Request 정보에 담겨있다는 것을 알 수 있다. 

이런 식으로 HTTP 정보를 읽어보았으니 이를 custom하여 

customized Tomcat을 구현해볼 수 있다. 

JUnit @ParameterizedTest를 활용하여 Test code 간략하게 작성하기

 JUnit의 @ParameterizedTest를 사용하여 TestCode를 간략하게 작성할 수 있는 방법에 대해 알아보겠다. 

1. Dependency 추가

먼저 Gradle에 다음과 같은 Dependency를 추가해준다. 

testImplementation 'org.junit.jupiter:junit-jupiter-params:5.4.2'

2. @ParameterizedTest 사용법

2.1 @ParameterizedTest 사용이유

Test 코드를 사용하다 보면 test 인자로 들어오는 값이 무엇이냐에 따라 Test 결과값이 바뀐다. 특히 예를 들어 몇 자리에서 몇자리까지 validation으로 들어오는 경우에는 그 경계값에 해당되는 숫자를 test 코드에 넣고 일일히 테스트해야 하기 때문에 소스의 중복이 많아진다. 

테스트 코드의 중복을 줄이고 모든 경계값에 대한 테스트를 진행할 때 @ParameterizedTest를 사용하면 아주 유용하다. 

@ParameterizedTest는 다양한 annotation과 함께 사용할 수 있다. 

2.2 @ValueSource annotation 사용

@ValueSource는 literal 값의 단일 배열을 지정할 수 있고, 테스트 시마다 단일 인자를 제공할 경우 사용할 수 있다. 

short, byte, int, long, float, double, char, boolean 뿐 아니라 java.lang.String, java.lang.Class에 대해서도 지원이 가능하다. 

@ValueSource 뒤에 (strings = { } ) 이런 식으로 원하는 타입을 적은 뒤 그 뒤에 literal을 넣어주면 된다. string 인자일 경우 strings = { } , int 인자일 경우 ints = {} 이런식으로 적을 수 있다.  

@DisplayName("비밀번호가 7자 미만 또는 13자 초과하는 경우 IllegalArgumentException 예외를 발생시킨다.")
@ParameterizedTest
@ValueSource(strings = {"aabbcc", "abcdefdeeffeeg"})
void validatePasswordTest(String password) {
    assertThatCode(()->PasswordValidator.validate(password))
            .isInstanceOf(IllegalArgumentException.class)
            .hasMessage("비밀번호는 최소 7자 이상 13자 이하로 설정되어야 한다.");
}

여기서는 password가 단일인자 string의 형태로 들어왔으므로 strings = { } 의 형태로 @ValueSource를 설정해줄 수 있는 것이다. 

만약 @ParameterizedTest를 하지 않았다면 6글자의 password, 14자리의 password를 가지는 Test method를 각각 하나씩 적었어야 할 것이다. 

동일 기능을 수행하고 있는 Test Code의 여러 test case를 @ParameterizedTest와 @ValueSource를 사용하여 간략하게 작성할 수 있다. 

2.3 @MethodSource

위의 @ValueSource의 경우 parameter를 하나만 넘겨주기 때문에 인자가 여러 개인 경우는 테스트가 어렵다. 

@MethodSource annotation을 사용하면 우리가 사용하고자 하는 method를 새롭게 만들고 그 메서드의 복합인자를 가져와 test에 사용할 수 있어서 다각도로 테스트가 가능하다. 

import java.util.stream.Stream;
import org.junit.jupiter.api.DisplayName;
import org.junit.jupiter.api.Test;
import org.junit.jupiter.params.ParameterizedTest;
import org.junit.jupiter.params.provider.Arguments;
import org.junit.jupiter.params.provider.MethodSource;

@DisplayName("사칙 연산 (+, -, *, /) 을 수행한다.")
@ParameterizedTest
@MethodSource("formulaCalculation")

void calculateTest(int operand1, String operator, int operand2, int result) {
    int formulaResult = Calculator.calculate(operand1, operator, operand2);
    assertThat(formulaResult).isEqualTo(result);
}

private static Stream<Arguments> formulaCalculation(){
    return Stream.of(
            arguments(3, "+", 4, 7),
            arguments(5, "-", 2, 3),
            arguments(2, "*", 2, 4),
            arguments(8, "/", 2, 4)
    );
}

이런 식으로 적어주면 formulaCalulation() 이라고 우리가 따로 정의한 static method의 인자를 넣어줄 수 있다. 

이런 식으로 사용하면 인자가 여러개 일 때도 손쉽게 테스트 할 수 있다. 

[JUnit5] 테스트코드 단축기, @DisplayName 테스트 이름 표시하는 방법

 JUnit은 Java의 단위 테스트 Framework이다. 

하나의 jar 파일로 관리되고 있어서 java에서 사용하기에도 매우 편리하다. 

Intellij에서 JUnit을 사용해서 Test Method를 작성하기 위해서는 

Windows 기반 : alt + insert 를 누르고

Mac 기반: command + N을 누르면 

아래와 같이 Generate 아래 Test Method가 뜬다. 

위 Test Method를 클릭하면 

@Test라는 annotation을 단 Test method가 생성이 된다. 

여기서 해당 단위 테스트의 이름을 표시하기 위해서는 

@DisplayName이라는 annotation을 추가로 활용할 수 있다. 

@DisplayName은 한글, 이모지, 공백 등 테스트케이스 이름을 제약 없이 자유롭게 설정할 수 있다. 즉 내가 해당 테스트 메서드를 작성하면서 이 테스트의 의도가 있었을 텐데 그 의도를 @DisplayName에 적어주면서 코드의 가독성을 높일 수 있는 것이다. 

@DisplayName("ID에 영문, 특수문자, 대문자가 모두 포함되면 ID validation이 통과한다")
@Test

이런 식으로 작성하고 method를 작성하면서 그 테스트 케이스의 의도, 또는 부연설명을 자연스럽게 적을 수 있다. 

@DisplayName("ID에 영문, 특수문자, 대문자가 없으면 ID validation이 통과하지 않는다")
@Test

반면 위와 같이 작성하여 요구사항을 충족하지 않을 경우의 테스트 케이스도 작성할 수 있다. 

이렇게 하고 Test를 Run하면 이렇게 @DisplayName에 작성한 설명이 뜨면서 

어떤 TestCase가 통과했는지 손쉽게 확인할 수 있다. 

TDD (Test Driven Development), BDD (Behavior Driven Development) 란?

 프로그래밍 개발 프로세스 중 TDD, BDD 라는 말을 들어보았을 것이다. 

간단히 말해서 TDD는 Test Driven Development의 약자, BDD는 Behavior Driven Development의 약자이다.  

오늘은 각각의 정의와 특징에 대하여 알아보도록 하겠다. 

1. TDD (Test Driven Development)

Full name이 의미하는 것처럼 TDD는 테스트 주도 개발이다. 코드를 작성하기 전 테스트를 먼저 작성해야 한다. TDD는 아주 짧은 개발 서클의 반복에 의존한다고 볼 수 있다. 

TDD에서 개발자는 요구되는 기능에 대한 테스트 케이스를 작성하고 해당 테스트 케이스를 통과하는 짧으면서도 가독성 좋은 코드를 작성하는 것이다. 즉 테스트를 먼저 작성하고 그 테스트를 통과하기 위한 코드를 이후에 작성하는 것이다. 코드를 작성한 뒤에 필요에 따라 리팩토링(Refactoring) 하는 과정을 거칠 수 있다. 

* Test Code 작성 => Production Code 작성 => 리팩토링

[TDD 장점]

위 프로세스처럼 코드를 작성하면 깔끔하게 코드를 작성할 수 있고 리팩토링을 통해서 코드의 퀄리티를 높일 수 있다. 

[TDD 단점] 

하지만 단점도 존재한다. 

일단 테스트코드를 작성하면서 절대적인 코드량이 늘어나고 테스트케이스에 대한 고민이 있을 수 있다. 어디서부터 어디까지 테스트를 해야 할지, 어디부터 테스트를 해야 할지에 대한 고민이 필요하다. 일정이 빡빡한 프로젝트에서는 적용하기 어려울 수 있는 개발 프로세스이다. 

2. BDD (Behavior Driven Development)

BDD는 TDD와 완전 다른 개념은 아니고 TDD를 base로 하여 파생된 프로그래밍 개발 프로세스이다. TDD에서는 테스트 통과를 위한 코드를 작성했다면, BDD에서는 그 개념에서 더 나아가 테스트 케이스 자체가 코드의 요구사항이 되도록 하는 방식이라고 생각하면 된다.

TDD에서 각 테스트 케이스에 대한 유닛테스트를 진행했다면, BDD에서는 통합 테스트와 시나리오 테스트까지 확장해서 진행한다. 

즉 BDD를 사용하면 TDD에서 논의된 단점을 커버할 수 있다. 

어디서부터 테스트를 진행할지, 어떤 기능은 테스트하고 어떤 것은 하지 않을지 등의 고민을 해결할 수 있다. 

Spring MyBatis 사용하는 법, DQM DEM.xml 주석 작성법

 Spring에서 MyBatis를 사용하는 경우 

<![CDATA[]]>

이 태그를 본 사람들이 있을 것이다 .

간단히 말해서 CDATA란 character data, 한 마디로 문자열을 뜻한다. 

즉 , <![CDATA[]]> 

이라고 쓰고 해당 태그 안에 코드를 쓰면  [ ] 안에 있는 문자는 파싱되지 않고 그대로 문자열로 출력된다는 의미이다. 

DQM 이나 DEM에서 select 쿼리를 쓸 때 <,  >, = 등의 기호를 쓸 때가 많은데 파싱 중에 태그로 인식될 확률이 있어 CDATA안에 넣어서 사용하는 것이다. 

특히 xml 안에서 주석을 사용하고 싶을 때 사용하는 

<!-- --> 의 경우에도 

 CDATA 안에서 사용하면 xml의 주석이 아닌, literally string으로 인식하기 때문에 CDATA 태그 안에 사용하면 무조건 에러가 난다. 

CDATA 안 쿼리에 직접 주석을 작성하고 싶다면 /* */ 주석을 사용해야 한다. 

예시로 

<resultMap>

    <result property="" column=""/> 

</resultMap>

<select id = "" parameterType="" resultMap="" >

    <![CDATA[

        쿼리

    ]]> 

</select>

이런식의 구조로 DEM과 DQM을 작성하면 된다. 그리고 주석을 사용하고 싶다면 반드시 CDATA 밖에 

<resultMap>

    <result property="" column=""/> 

</resultMap>

<!-- 주석 --> 

<select id = "" parameterType="" resultMap="" >

    <![CDATA[

        쿼리

    ]]> 

</select>

이런식으로 작성하거나, 

CDATA 태그 안에 작성하려면 

<resultMap>

    <result property="" column=""/> 

</resultMap>

<select id = "" parameterType="" resultMap="" >

    <![CDATA[

        쿼리 /* 주석입니다 */

    ]]> 

</select>

이런식으로 실제 쿼리에서 인식할 수 있도록 작성해주어야 한다. 

Tomcat 구동 시 webapps 폴더가 생기지 않을 경우

 Tomcat을 실행할 때 Intellij webapps 경로로 설정을 했으나 실행 시 자동으로 폴더가 생기지 않을 경우 Intellij에서 설정할 수 있는 방법들에 대해 알아보겠다. 

1. 가장 먼저 Gradle의 빌드 Settings 를 수정한다. 

Change the settings of Intellij Gradle Build 

Intellij IDEA => Preferences => Build, Execution, Deployment => Build Tools => Gradle 

=> Build and Run Using: 에서

Intellij IDEA를 적용한다. 

2. Output Path 설정 

Set the Output path as below (project path/webapps/WEB-INF/classes)

Project Settings => Modules => Paths 탭 클릭 => 

Compiler Output에서 "Use module compile output path" 클릭 후 

output path에 

"프로젝트 경로/webapps/WEB-INF/classes" 설정

3. 1번과 2번의 설정을 적용하여 빌드 및 재실행

위 세 단계를 거치면 톰캣이 구동되면서 webapps 폴더가 자동으로 생성되는 것을 확인할 수 있을 것이다. 

Java 현재시각 조회 및 저장, current_timestamp 형식으로 저장하는 방법

 오늘은 java 단에서 저장 시 특정 칼럼에 현재 시간을 써주고 싶을 때 필요한 코드에 대해서 알아보겠다. 

Biz 단에서 시간을 세팅해주면 되는데

만약에 currentTime이라는 instance가 있고

setter로 setCurrentTime이라는 것을 만들었다고 가정해보자. 그러면 

Dvo.setCurrentTime(new Timestamp(System.currentTimeMillis())); 

라고 적어주면 된다. 

여기서 핵심은 System.currentTimeMillis()인데 

이는 현재 시간을 밀리세컨드 단위로 반환해준다. 

그래서 해당 메서드를 사용하여 Timestamp() 라는 객체를 만들어줬고 그러면 postgre의 timestamp 형태에 잘 들어가게 dvo에 세팅이 가능하다. 

즉 특정 프로그램 시작 전과 시작 후에 각각 System.currentTimeMillis() 를 적어서 프로그램 수행시간을 측정할 수도 있다. 

이와 유사하게 System.nanoTime()도 있는데 이 메서드는 JDK 1.5부터 추가된 메서드이다. 또한 현재 시간과는 관련이 없고 작동중인 JVM의 시간 소스의 현재 값을 long 타입으로 즉 nanoseconds를 반환한다는 점에서 유의해서 사용하여야 한다. 

FullCalendar 전체 달력의 background image 설정하는 방법

지난 포스팅에서 FullCalendar API를 사용하는 방법에 대하여 포스팅했다. 

여기에 FullCalendar에서 전체 달력의 background를 원하는 사진으로 설정하고 싶다면 어떻게 하면 될까?

간단히 css만 적용을 해주면 되는데, 원하는 파일을 프로젝트 경로 어딘가에 넣어두고 css에서 url만 잘 끌어다가 쓰면 된다. 

나는 이쁜 snowman 배경화면을 구글에서 다운받고, 12월 배경화면으로 설정하려고 했다. 

  #calendar1 {

    max-width: 1100px;

    margin: 0 auto;

  }

  #calendar1 .fc-view-harness-active>.fc-view{

    background: url("image/snowman.jpg") no-repeat;

    background-size: contain;

}

어렵지 않게 위와 같이 설정할 수 있다. 

background url은 현재 소스 파일에 대한 경로로 설정하면 된다. 

그리고 no-repeat으로 하면 사진 사이즈를 배경에 딱 맞출 수 있어 매우 유용하니 무조건 넣어주기! 넣지 않아주면 사진이 짤릴 가능성이 높다.

위 소스처럼 설정을 해주면 

이런식으로 전체 달력에 배경을 꽉 맞추어 사진을 넣어줄 수 있다. 

각 날짜별로 사진을 넣는 것은 또 다른 포스팅으로 올려보도록 하겠다. 

FullCalendar API 사용방법

 오늘은 FullCalendar API로 달력을 띄워보는 프로젝트를 실시해보겠다. 

https://fullcalendar.io/docs/initialize-globals

너무나도 달력 API로 잘 알려진 Full Calendar

설치 방법과 사용 방법도 매우 간단하다. 

일단 

npm install @fullcalendar/core @fullcalendar/interaction @fullcalendar/daygrid

위 명령어로 full calendar를 설치하자. 

만약 여기서 bash terminal에서 npm 명령어가 듣지 않는다면 node.js 부터 설치하고 시스템 경로를 추가해준 뒤 시행해주면 된다. 

그런 다음에 index.html 파일에

<!DOCTYPE html>

<html lang='en'>

  <head>

    <meta charset='utf-8' />

    <script src='https://cdn.jsdelivr.net/npm/fullcalendar@6.1.10/index.global.min.js'></script>

    <script>

      document.addEventListener('DOMContentLoaded', function() {

        var calendarEl = document.getElementById('calendar');

        var calendar = new FullCalendar.Calendar(calendarEl, {

          initialView: 'dayGridMonth'

        });

        calendar.render();

      });

    </script>

  </head>

  <body>

    <div id='calendar'></div>

  </body>

</html>

위와 같이 Full Calendar API를 불러오는 소스를 작성해주면 끝!

역시 잘 만들어진 API를 활용하면 금방 원하는 결과를 산출할 수 있다. 

로컬에서 서버를 띄워주면

이런식으로 달력 완성! 

여기에 원하는 기능을 더 추가하여 나만의 달력을 만들 수 있다. 

VS Code gradle build 시 "JAVA_HOME is not set and no 'java' command could be found in your PATH" 에러

 VS Code에서 gradle build 시

 ERROR: JAVA_HOME is not set and no 'java' command could be found in your PATH 

에러가 뜬다면 어떻게 해결해야 할까?

말 그래도 VS Code에 java_home path가 인식되지 않아서 그런데

일단 먼저 

1. 제어판 시스템 환경변수에 JAVA_HOME 이 설정되었는지 확인한다. JAVA 설치 시 하는 것이므로 대부분 되어 있을 것

2. VS Code path를 확인한다. 

VS Code에서 control "," 를 누르고

"java.home"이라고 검색을 하면 위와 같이 Java_home 경로를 설정할 수 있다. 

거기에 현재 컴퓨터에 설치되어 있는 JAVA jdk 의 경로를 적어주면 된다. 

혹은 아래 있는 "Edit in settings.json"을 클릭하여 json 파일에서 setting을 바꾸어주어도 된다. 

변경을 한 다음 vs code를 닫고 다시 실행시켜주면 이제 vs code가 java_home의 path를 인식하는 것을 알 수 있다. 

Visual Studio Code 라이브 서버 설치방법, 언제 사용하는가 (Go Live)

 오늘은 VS Code에서 web proejct를 생성할 때 유용하게 사용하는 라이브 서버 익스텐션 설치 방법에 대해 알아보겠다. 

VS Code는 다양한 extension 지원으로 코딩을 훨씬 더 편리하게 해주는데, 그 중 하나가 live server이다. 

먼저 설치는 VS Code extension 칸에 들어가서 live server라고 검색하면 아주 간단히 할 수 있다. 

live server라고 검색 시 가장 먼저 나오는 것에서 Install 버튼을 클릭한다. 

그러면 위와 같이 설치 중이라는 메세지가 뜨다가 몇 초 이내로 설치가 완료된다. 

설치가 완료되면 

오른쪽 하단에 Go Live라는 버튼이 보이는데 

html 코드를 작성하고 Go Live를 클릭하면 로컬 서버에서 테스트 하는 용도로 활용이 가능하다. 

혹은 편집창에서 마우스 우클릭을 하여 Open With Live Server를 클릭해도 테스트가 가능하다. 

Liver Server 설치 하나로 로컬에서 웹 테스트가 가능하니 이처럼 편한 기능을 잘 활용해보자. 

Java doubleValue(), byteValue() primitive type 변환 메소드, 유의점

 Java에서는 primitive type 간 변환을 도와주는 여러 메소드들이 있다.

doubleValue()나 byteValue()와 같은 메소드들을 소스 상에서 여러 번 보았을 텐데, 이들은 해당 primitive type을 다른 타입으로 변환해준다.

java
public class TypeConversionExample { 
public static void main(String[] args) { 
// doubleValue() 예제 
int intValue = 15; 
double doubleValue = (double) intValue; // int를 double로 변환 
 System.out.println("int를 double로 변환: " + doubleValue);  // int를 double로 변환:  15.0
// byteValue() 예제 
Double myDouble = 200.75;
 // byteValue()를 이용해 byte로 변환
 byte myByte = myDouble.byteValue();
  // 결과 출력
    System.out.println("Double 값: " + myDouble); // Double 값: 200.75
    System.out.println("Byte로 변환된 값: " + myByte); // Byte로 변환된 값: -56 

즉, doubleValue() 는 값을 double로 변환할 때 사용, byte는 형태를 byte 형태로 변환할 때 사용한다.

여기서 doubleValue()는 일반적으로 int, float, long 등의 값을 double로 변환할 때 사용되기 때문에 데이터 유실에 크게 주의가 필요하지는 않다. (더 큰 형태로 변환하는 것이기 때문)

반면, byteValue()는 반대로 큰 데이터 타입인 double, int, float 등을 작은 byte 타입으로 변환할 때 쓰이기 때문에 주의가 필요하다. 변환 과정에서 데이터 손실이 발생할 수 있으므로 범위를 벗어나는 값은 의도하지 않은 결과를 초래할 수 있다. 예시에서 보듯이 double value 200.75는 byte로 변환되면서 -56이라는 의도하지 않은 값을 출력하게 된다.

이런 메소드들은 데이터 유실 없이 안전하게 변환이 필요한 경우에 사용해야 한다. 만약 데이터의 손실 없이 변환하고 싶을 때는 wrapper 클래스인 Integer, Double 등의 메소드를 사용하는 것이 좋다.