돈나뉴의 기술블로그

오늘 Spring  Boot 에 Logback 설정을 하다가 profile 에 따라 분리의 필요성을 느껴 찾아보고 적용하였습니다.

우선 logback.xml 파일은 spring extention 을 사용할 수 있게 logback-spring.xml 로 이름을 짓습니다.

그리고 2가지 경우로 나누어 설정해 보았습니다.

첫번째로 미리 appender 를 선언하고 호출하여 쓰는 경우.

<property name="LOG_PATH" value=""/>
<property name="LOG_FILE_NAME" value=""/>

<appender name="CONSOLE" class="ch.qos.logback.core.ConsoleAppender">
<encoder>
<pattern>
%-5level %d{HH:mm:ss.SSS} [%thread %F:%L] %method - %msg%n
</pattern>
</encoder>
</appender>

<appender name="ROLLING_FILE" class="ch.qos.logback.core.rolling.RollingFileAppender">
<file>${LOG_PATH}/${LOG_FILE_NAME}.log</file>
<encoder>
<pattern>%-5level %d{HH:mm:ss.SSS} [%thread %F:%L] %method - %msg%n</pattern>
</encoder>
<rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
<fileNamePattern>${LOG_PATH}/${LOG_FILE_NAME}.%d{yyyy-MM-dd}_%i.log.gz</fileNamePattern>
<timeBasedFileNamingAndTriggeringPolicy class="ch.qos.logback.core.rolling.SizeAndTimeBasedFNATP">
<maxFileSize>100MB</maxFileSize>
</timeBasedFileNamingAndTriggeringPolicy>
<maxHistory>60</maxHistory>
</rollingPolicy>
</appender>

<springProfile name="dev | stage">
<root level="DEBUG">
<appender-ref ref="CONSOLE"/>

<appender-ref ref="ROLLING_FILE"/>

</root>
</springProfile>

이렇게 쓸경우 springProfile 에 따라 appender 가 중복되지 않고 호출만 하여 사용하면 되어 편리합니다.

하지만 로그 파일의 위치가 권한이 필요한 곳이라면 미리 appender 를 선언하고 해당 설정을 읽을때 파일에 접근, 생성하기 때문에 따로 권한을 줘야합니다. (제 경우에는 앱 실행당시 바로 access denied 가 떴었습니다.)

두번째로 springProfile 별로 선언하고 쓰는 경우.

<springProfile name="dev | stage">

<property name="LOG_PATH" value=""/>
<property name="LOG_FILE_NAME" value=""/>

<appender name="CONSOLE" class="ch.qos.logback.core.ConsoleAppender">
<encoder>
<pattern>
%-5level %d{HH:mm:ss.SSS} [%thread %F:%L] %method - %msg%n
</pattern>
</encoder>
</appender>

<appender name="ROLLING_FILE" class="ch.qos.logback.core.rolling.RollingFileAppender">
<file>${LOG_PATH}/${LOG_FILE_NAME}.log</file>
<encoder>
<pattern>%-5level %d{HH:mm:ss.SSS} [%thread %F:%L] %method - %msg%n</pattern>
</encoder>
<rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
<fileNamePattern>${LOG_PATH}/${LOG_FILE_NAME}.%d{yyyy-MM-dd}_%i.log.gz</fileNamePattern>
<timeBasedFileNamingAndTriggeringPolicy class="ch.qos.logback.core.rolling.SizeAndTimeBasedFNATP">
<maxFileSize>100MB</maxFileSize>
</timeBasedFileNamingAndTriggeringPolicy>
<maxHistory>60</maxHistory>
</rollingPolicy>
</appender>

<root level="DEBUG">
<appender-ref ref="CONSOLE"/>
<appender-ref ref="ROLLING_FILE"/>
</root>
</springProfile>

이렇게 쓸경우 중복은 되지만 환경에 따라 세부적인 설정을 변경하기도 좋고 파일 생성이 필요없는 환경에서는 쓸데없이 파일을 만드는 appender 에 접근하지 않아 파일을 만들지 않아서 좋았습니다.

어느날 코딩을 하던 도중 List 에 add() 를 하였는데 에러가 발생하였다.

익셉션은 UnsupportedOperationException.

원인을 찾던 도중 해결에 결정적인 역활을 하는 글과 재밌는 것을 발견하였다.

우선 글은

https://stackoverflow.com/questions/5755477/java-list-add-unsupportedoperationexception

인데 내용을 번역해보자면

모든 List 는 add() 메서드를 구현, 지원하지 않으며 가장 일반적인 예로 Arrays.asList(); 같은 경우 고정된 사이즈의 Array 를 리턴한다.
그렇기에 사이즈를 수정할 수 없다.

이다.

나같은 경우 Arrays.asList(); 를 통해 만들어진 ArrayList 에 add 를 하고 있었다.

그래서 궁금한 마음에 Arrays  클래스를 확인해본 결과 우리가 흔히 사용하는 ArrayList 를 반환하는게 아니라 

Arrays 클래스 내부에 inner Class 로 구현해놓은 ArrayList 를 반환하고 있었다.

당연하게도 Arrays 클래스의 inner Class 인 ArrayList 에는 사이즈 측정 및 조절을 위한 size 와 DEFAULT_CAPACITY 변수가 존재하지 않는다.

그리고 AbstractList 클래스를 상속받고 있어 상속받은 AbstractList 클래스의 add() 메서드는 존재하고 사용할 수는 있지만 

해당 AbstractList 클래스의 add() 메서드를  Override 하여 사용하지 않으면 해당 add() 메서드는  

throw new UnsupportedOperationException(); 하도록 구현되어있기 때문에 UnsupportedOperationException 에러가 나게 된다.

3장. 함수 에 대한 의견 교환

이 글은 로버트C. 마틴이 지은 클린코드를 읽고 각 챕터에 대한 의견 교환 및 토론을 한 내용 입니다.

댓글로 의견 교환 및 토론은 환영합니다.

오늘은 함께 스터디하는 4명 중 2명이 일과 건강 문제로 스터디에 빠져서 나를 포함해 2명이서 스터디를 진행하였다.

허: 

• 더러운 함수는 이해가 잘 안간다.
• 함수를 작게 만들라는게 마음에 든다.
• 함수를 한가지 일만 해야한다고 하는게 뇌리에 박힌다.
• Switch 문을 사용할때 클린코드 규칙이 깨진다고 하는게 가장 중요한 이야기인것 같고 Switch 뿐만 아니라 if 문을 여러번 사용할때도 같다고 생각된다.
• 나머지는 와닿지 않는다.
• 예) 함수인수 갯수, boolean 타입을 넘기는것 등..
• 아직 경험이 별로 없어서 잘 와닿지 않고 enum 도 크게 와닿진 않는다.

나: 

• enum 의 오류 코드를 사용하는 것이 의존성 자석이고 그렇게 쓰지말라고 한 것 같은 경우는 기존의 exception 클래스를 상속받아서 새롭게 해당 예외만 생성하고 사용하면 된다는 말 같다.
• Enum 을 사용할때 타입 같은 것을 정의하고 그 값을 DB에 저장하면 좋다고 생각한다.
• string 이라는게 에러가 생길수 있는 구석이 많음, 예를 넘겨주거나 받을때 String 이면 kakaopay 인데 kakpay 같이 될수 있는데 이를 방지할수 있다.
• 함수 챕터에서 로버트C. 마틴이 함수인수의 갯수에 대해 이야기한 것이 중요하다고 생각되는 이유는 함수 인수가 많으면 설계와 정의를 잘 못한거라고 생각한다.
• 알고리즘 문제를 풀더라도 객체지향적으로 설계하고 정의하면 함수 인수가 많아질 일은 없다고 생각한다.
• 예를 들어 이진수 변환 문제가 나오면 나는 하나의 이진수 를 클래스로 만들어 이진수를 저장하는 것을 멤버변수로 만들고 변환하는 과정을 매서드로 만들 것이다.
• 이 챕터에서 가장 중요한 말은 ‘우리가 함수를 만드는 이유는 큰 개념을 다음 추상화 수준에서 여러단계로 나눠 수행하기 위해서가 아니던가’ 인듯하다.
• 이 말에 객체지향의 목표가 다 있다고 생각든다.
• 예를 들어 함수에서 다음 함수로 넘어가거나 쪼갤때 단순히 줄을 나눠서 쪼개거나 그냥 인수를 그대로 넘기면 절차지향과 다름없다.
• 한 함수를 쪼갤 때, 혹은 구현 혹은 리팩토링할 때 각 함수를 잘 추상화하고 함수에서 호출하는 다음 함수의 레벨(깊이, 레이어)을 잘 나눠줘야 한다고 생각한다.
• 이는 단순히 함수뿐만 아니라 다른곳에도 적용된다고 생각한다.
• 예를 들면 DDD 에서 도메인 레이어에서 인프라 레이어로 넘어가는데 이때에도 적용되는 말이라고 생각한다. 
• 그래서 인프라 레이어에서의 변경이 일어나도 도메인 레이어에는 영향이 없도록 인프라 레이어를 사용, 호출하는 도메인 레이어에서는 인프라 레이어를 잘 추상화(인터페이스화) 하는 것이 중요하다고 생각한다.

3.17. Parallel Execution

3.17. Parallel Execution

[React Native] this.state.list.map is not a function

개인 프로젝트로 React Native 를 개발하던 도중 this.state.list.map is not a function 이라는 에러를 만났다.

금방 고칠 수 있었는데 .map() 은 Array 를 위한 함수로 그 외에 String 이나 다른 값이 들어가게 되면 에러를 내게 된다.

map() 메서드는 배열 내의 모든 요소 각각에 대하여 주어진 함수를 호출한 결과를 모아 새로운 배열을 반환합니다.

라고 한다.

그래서 this.state.list 에 주입할 Array 를 만드는 부분을 보니 데이터를 받아오는 url 주소가 잘못 되어있었다.

3.16. Dynamic Tests

3.16. 다이나믹 테스트들

Annotations 에 설명 된 JUnit Jupiter의 표준 @Test annotation은 JUnit 4의 @Test annotation과 매우 유사합니다. 둘 다 테스트 케이스를 구현하는 메소드를 설명합니다. 이 테스트 케이스들은 컴파일 타임에 완전히 지정된다는 점에서 정적이며 런타임시 발생하는 모든 사항에 의해 그 동작이 변경 될 수 없습니다. Assumptions 은 동적 행동의 기본 형태를 제공하지만 표현의 한계가있다.

이러한 표준 테스트 외에도 완전히 새로운 종류의 테스트 프로그래밍 모델이 JUnit Jupiter에 도입되었습니다. 이 새로운 종류의 테스트는 @TestFactory 로 주석 처리 된 팩토리 메서드에 의해 런타임에 생성되는 동적 테스트입니다. @TestFactory 메소드는 @Test 메소드와는 달리 테스트 케이스가 아니라 테스트 케이스의 팩토리입니다. 따라서 동적 테스트는 팩토리의 제품입니다. 기술적으로 말해서 @TestFactory 메소드는 Stream, Collection, Iterable, Iterator 또는 DynamicNode 인스턴스의 배열을 반환해야합니다. DynamicNode 의 인스턴스화 가능한 서브 클래스는 DynamicContainer 와 DynamicTest 입니다. DynamicContainer 인스턴스는 표시 이름과 동적 하위 노드 목록으로 구성되어 임의로 중첩 된 동적 노드 계층을 만들 수 있습니다. DynamicTest 인스턴스가 느리게 실행되므로 동적이고, 비 결정적인 테스트 케이스 생성이 가능합니다.

@TestFactory 에 의해 리턴 된 모든 스트림은 stream.close() 를 호출하여 적절히 닫히게되므로 Files.lines() 와 같은 리소스를 사용하는 것이 안전합니다.

@Test 메서드와 마찬가지로 @TestFactory 메서드는 private 또는 static이 아니어야하며 ParameterResolvers에서 확인할 매개 변수를 선택적으로 선언 할 수 있습니다.

DynamicTest는 런타임에 생성되는 테스트 케이스입니다. 그것은 표시 이름과 Executable로 구성됩니다. Executable은 @FunctionalInterface입니다. 즉, 동적 테스트의 구현을 람다 식 또는 메서드 참조로 제공 할 수 있습니다.

3.15. Test Templates

A @TestTemplate method is not a regular test case but rather a template for test cases. As such, it is designed to be invoked multiple times depending on the number of invocation contexts returned by the registered providers. Thus, it must be used in conjunction with a registered TestTemplateInvocationContextProvider extension. Each invocation of a test template method behaves like the execution of a regular @Test method with full support for the same lifecycle callbacks and extensions. Please refer to Providing Invocation Contexts for Test Templates for usage examples.

3.15. 테스트 템플릿츠

@TestTemplate 매서드는 정기적인, 규칙적인 테스트 케이스가 아니고 정확히 말하자면 테스트 케이스들을 위한 템플릿 입니다. 그 때문에, 그것은 등록 프로 바이더가 돌려주는 호출 문맥의 수에 응해, 여러번 호출하도록 설계되고 있습니다. 따라서 그것은 반드시 등록된 TestTemplateInvocationContextProvider 의 확장과 함께 사용해야 합니다. 테스트 템플릿 메소드를 호출 할 때마다 동일한 라이프 사이클 콜백 및 확장을 완벽하게 지원하는 일반 @Test 메소드를 실행하는 것처럼 동작합니다. 사용 예제는 Providing Invocation Contexts for Test Templates 을 참조하십시오.

[Node.js] Express에서 기본 Jade 템플릿 형식을 Html로 바꾸기

(Change the template system from Jade to HTML with Express)

 처음 express 를 통해 프로젝트 디렉토리를 만들경우 기본 템플릿 형식입니다.

Jade 를 처음 접하거나 쓰기 어려워하는 분들은 HTML 을 사용하고자 하는데 간단하게 기본 템플릿 형식을 바꾸는 방법이 있습니다.

출처 : https://ademirgabardo.wordpress.com/2016/03/04/how-to-change-the-template-system-from-jade-to-html-with-express/

This quick post is just to remember how to change the template engine on Express from Jade to HTML.

1. Install the ejs view engine with the NPM:

   npm install ejs

2. Set your template engine in app.js (or in your custom .js app file) as ejs

   app.engine('html', require('ejs').renderFile);
   app.set('view engine', 'html');

3. In the route file ./routes/index.js  assign template variables like this

   exports.index = function(req, res){
   res.render('index', { title: 'Page title' });};

4. Create the HTML files in the view folder /views.

2번 항목에서 app.js 파일을 보면 아래와 같이 기본 템플릿이 Jade 로 설정되어 있는 것을 볼 수 있습니다.

app.set('view engine', 'jade');

이를 지우거나 주석처리를 하고 2번을 진행하시면 됩니다.

profiles 를 활용하여 설정 값 변경하기.

스프링 개발을 하다보면 환경, 앱을 돌리고자 하는 목적에 따라 설정 값을 환경에 맞춰 변경해줘야 하는 경우가 생깁니다.

이럴 때 일일이 바꿀 필요 없이 편하게 설정 값을 변경하는 방법이 있습니다.

profiles 를 활용하는 방법입니다.

우선 환경에 따라 다른 설정 값을 가진 설정 파일을 여러개 만듭니다.

(저는 yml 을 사용했지만 properties를 사용하셔도 됩니다. )

그 후 위와 같이 Edit Configurations... 를 클릭합니다.

그 후 위 사진처럼 VM options 입력란에 -Dspring.profiles.active=적용하고자하는 환경 을 입력하고 앱을 run 시키면 설정한 환경의 설정 값을 가지고 있는 설정파일을 바탕으로 돌고 있는 것을 확인할 수 있습니다.

또는 터미널에서 실행시키고 싶다면 shell script 혹은 직접 위와같이 직접 쳐서 환경 설정 파일을 바꾸어 실행할 수 있습니다.