이 문서의 내용 자체도 Google Codelab 으로 구성되어 있으며, 해당 Codelab 페이지에서 확인 가능합니다.

This article has same contents for the codelab, you can check the codelab in this page.

Introduction

This codelab page describe the process that making codelab page in Github pages.

GitHub Pages is a feature offered by GitHub that allows you to host static websites directly from a GitHub repository. It’s commonly used to publish personal projects, portfolios, documentation, or even blogs.

Google Codelab is an online platform provided by Google that offers step-by-step, interactive tutorials designed to teach developers how to use Google technologies and tools effectively. These tutorials cover a wide range of topics, including web development, Android app development, machine learning, cloud computing, and more.

Why Use Google Codelabs?

• Beginner-Friendly: They simplify complex technologies into easy-to-follow steps.
• Hands-On Learning: Practical examples help you understand real-world applications of the technology.
• Frequent Updates: Google keeps adding and updating content to reflect the latest tools and features.
• Global Accessibility: Tutorials are accessible online to developers worldwide.

Pre-requisites

In local machine, brew should be installed.

To install Homebrew on macOS, follow these steps:

Step 1: Open Terminal

1. Press Command(⌘) + Space to open Spotlight Search.
2. Type Terminal and press Enter.

Step 2: Install Xcode Command Line Tools

Before installing Homebrew, ensure that the Xcode Command Line Tools are installed:

1. Run the following command:

   xcode-select --install
   

2. A dialog box will appear. Click Install to proceed.
3. Wait for the installation to complete.

Step 3: Install Homebrew

1. Run the following command in Terminal:

   /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"
   

2. The script will prompt you to confirm the installation and provide your admin password. Enter it when prompted.

Step 4: Add Homebrew to Your PATH (if not automatically added)

Depending on your shell, you may need to update your PATH:

1. For zsh (default in macOS Catalina and later):

   echo 'eval "$(/opt/homebrew/bin/brew shellenv)"' >> ~/.zprofile
   eval "$(/opt/homebrew/bin/brew shellenv)"
   

2. For bash:

   echo 'eval "$(/opt/homebrew/bin/brew shellenv)"' >> ~/.bash_profile
   eval "$(/opt/homebrew/bin/brew shellenv)"
   

Step 5: Verify Installation

1. Run the following command to check if Homebrew is installed correctly:

   brew --version
   

   This will display the installed version of Homebrew.

Step 6: Update Homebrew

To ensure everything is up to date, run:

brew update

You’re now ready to use Homebrew! 🎉

Step 1: Install go and claat

googlecodelab will be deployed and served by(using) claat, and claat can be installed by go lang. So, first of all, install go using brew and then, install claat using go.

Install go:

brew install go

When brew install go lang, it add the go binary to the PATH, but if it does not add binary to the PATH, add it manually.

Add go binary to PATH:

echo 'export PATH=$PATH:~/go/bin' >> ~/.zshrc

Refresh .zshrc file to activate PATH:

source ~/.zshrc

Then, install claat:

go install github.com/googlecodelabs/tools/claat@latest

To check claat installed successfully:

claat --help

Step 2: create a markdown .md file

Duration: 0:05:00

Make a markdown file(sample.md) like:

summary: Title of the Codelab
id: codelab-id
categories: Web, Beginner
status: Published

# Title of the Codelab

## Introduction
Brief introduction of the blog/tutorial.

## Step 1: Do Something
Instructions for step 1.

## Step 2: Do Something Else
Instructions for step 2.

Because this md path can be a web root path, so make the .md file in git repository root path.

Step 3: export the contents and check in local

Export the markdown file by claat

In the same directory with markdown file:

claat export sample.md

claat create a codelab-id directory in the same path. (id based directory.)

When using images in markdown file, those are included in img folder in exported directory.

the codelab-id will be a folder that can represent as a web path /codelab-id. So, if you want to change the web path, you should change the id value in .md file.

Check in local

After export the file, codelab can be check in local:

claat serve

When run this command, the default browser is open. If you type this command in same directory for .md file, you can see as below:

You can check the codelab with clicking the codelab-id path.

Step 4: push to github pages

Copy the codelab-id directory to the github repo’s docs folder.

Then, in the settings in the repository, enable pages as below:

For this codelab, the directory structure is:

Step 5: Check in the browser

Finally, we can check the codelab in:

https://<username>.github.io/<repo>/codelab-id/

Tips and Tricks: Syntax

If you’re using Windows make sure to set your text editor to use UNIX line endings!

Open your markdown file

$ vim <name-of-codelab>.md

Header metadata [Auto generated]

Update the headers metadata in your markdown file and change the values appropriately. Guidelines are available below the sample headers.

author: Author Name
summary: Summary of your codelab that is human readable
id: unique-codelab-identifier
tags: workshop,iguide
categories: Java,Spring
environments: Web
status: Published
feedback link: A link where users can go to provide feedback (e.g. the git repo or issue page)

Metadata consists of key-value pairs of the form “key: value”. Keys cannot contain colons, and separate metadata fields must be separated by blank lines. At present, values must all be on one line. All metadata must come before the title. Any arbitrary keys and values may be used; however, only the following will be understood by the renderer:

• Author: Author name or git username
• Summary: A human-readable summary of the codelab. Defaults to blank
• Id: An identifier composed of lowercase letters ideally describing the content of the codelab. This field should be unique among codelabs. This will be in the URL of the codelab
• Tags: Leave “workshop” if creating a Developer workshop or “iguide” if creating an integration guide. Remove both if neither. Note: this is used for the “Filter by Type” feature on the landing page
• Categories: A comma-separated list of the topics or technologies the codelab covers. Include items such as language(s) and protocol(s) used. The first one is used to create a new “Filter by category” feature on the landing page and the styling of the category. The remaining will be used for the filtering.
  • Note that the list of available categories can be found in the main site repo
  • The current list is (case insensitive): [amqp, boomi, codelab, java, jms, kafka, mqtt, rest, solace, spring, kubernetes, javascript, helm, azure, opentelemetry, mulesoft, rabbitmq, keda, apama, hermesjms, flink, nifi, nagios, jboss, weblogic, websphere, webspherelib, spark, sap, terraform]
• Environments: Leave as “Web”
• Status: The publication status of the codelab. Valid values are:
  • Draft: Codelab is not finished.
  • Published: Codelab is finished and visible.
  • Deprecated: Codelab is considered stale and should not be widely advertised.
  • Hidden: Codelab is not shown in index.
• Feedback Link: A link to send users to if they wish to leave feedback on the codelab. Link to git repo where code for the tutorial will live.

Add the Title

Next add your title using a single ‘#’ character

# Title of codelab

Add Sections & Durations

Then for each section use Header 2 or ‘##’ & specify q duration beneath for time remaining calculations

Duration is in the following time format: hh:mm:ss

Example

## Section 1
Duration: 0:10:00

## Section 2
Duration: 0:05:00

Add Section Content

Now that we have 2 sections to our titled codelab let’s go ahead and add some content to each section. Make up your own or copy & paste the example below:

Copy into section 1 (Below Duration and above Section 2):

### Info Boxes
Plain Text followed by green & yellow info boxes

> aside negative
> This will appear in a yellow info box.
> This is line two of the negative block
> ```
> this is a code block
> with multiple lines
> ```

> aside positive
> This will appear in a green info box.

You created info boxes!

### Bullets
Plain Text followed by bullets
* Hello
* Codelab
* World

You created bullets!

### Numbered List
1. List
1. Using
1. Numbers

You created a numbered list!

Copy into section 2 (Below Duration):

### Add a Link
Add a link!
[Example of a Link](https://www.google.com)

### Add an Image
Add an image!
![image_caption](https://solace.com/wp-content/uploads/2019/09/goodbye_otter_v3.gif)

### Embed an iframe
![https://codepen.io/tzoght/embed/yRNZaP](https://en.wikipedia.org/wiki/File:Example.jpg "Try Me Publisher")

More Markdown Parser examples can be found here.

참고자료 및 출처

• https://codelabs.solace.dev/codelabs/codelab-4-codelab/?index=..%2F..index#0

Spring은 애플리케이션 컨텍스트의 일부에 적용할 사용자 정의 조건을 정의할 수 있는 @Conditional 이라는 annotation을 도입했습니다. Spring Boot는 이를 기반으로 구축되어 일부 사전 정의된 조건을 제공하므로 직접 구현할 필요가 없습니다.

이 튜토리얼에서는 Conditional로 로드된 Bean이 왜 필요한지 설명하는 몇 가지 사용 사례를 살펴보겠습니다. 그런 다음 조건을 적용하는 방법과 Spring Boot가 제공하는 조건을 살펴보겠습니다. 마무리로 사용자 지정 조건도 구현하겠습니다.

참고자료가 되는 원본 출처로 가 보면, 샘플 코드도 제공하고 있으니 참고하세요.

Conditional Bean 이 필요한 이유는 무엇인가요?

Spring 애플리케이션 컨텍스트에는 런타임에 애플리케이션에 필요한 모든 Bean을 구성하는 객체 그래프가 들어 있습니다. Spring의 @Conditionalannotation을 사용하면 특정 Bean이 해당 객체 그래프에 포함되는 조건을 정의할 수 있습니다.

특정 조건 하에서 콩을 포함하거나 제외해야 하는 이유는 무엇입니까?

제 경험상 가장 흔한 사용 사례는 특정 Bean이 테스트 환경에서 작동하지 않는다는 것입니다. 테스트 중에 사용할 수 없는 원격 시스템이나 애플리케이션 서버에 연결해야 할 수도 있습니다. 따라서 테스트 중에 이러한 Bean을 제외하거나 대체하기 위해 테스트를 모듈화 하고자 합니다.

또 다른 사용 사례는 특정 횡단적 관심사를 활성화하거나 비활성화하려는 경우입니다. 보안을 구성하는 모듈을 빌드했다고 가정해 보겠습니다. 개발자 테스트 중에 사용자 이름과 비밀번호를 매번 입력하고 싶지 않으므로 스위치를 뒤집어 로컬 테스트를 위해 전체 보안 모듈을 비활성화합니다.

또한, 우리는 특정 Bean을 작동할 수 없는 외부 리소스가 있는 경우 에만 로드하고 싶을 수 있습니다. 예를 들어, logback.xml클래스 경로에서 파일이 발견된 경우에만 Logback 로거를 구성하고 싶습니다.

다음 토론에서 몇 가지 더 많은 사용 사례를 살펴보겠습니다.

조건에 따른 Bean 선언

Spring Bean을 정의하는 모든 곳에서 선택적으로 조건을 추가할 수 있습니다. 이 조건이 충족되는 경우에만 Bean이 애플리케이션 컨텍스트에 추가됩니다. 조건을 선언하려면 아래에 @Conditional... 설명된 annotation 중 하나를 사용할 수 있습니다.

하지만 먼저, 특정 Spring Bean에 조건을 적용하는 방법부터 살펴보겠습니다.

Conditional @Bean

단일 @Bean정의에 조건을 추가하는 경우 조건이 충족되는 경우에만 이 Bean이 로드됩니다.

@Configuration
class ConditionalBeanConfiguration {

    @Bean
    @Conditional... // <--

    ConditionalBean conditionalBean() {
        return new ConditionalBean();
    }

    ;
}

Conditional @Configuration

Spring에 조건을 추가하면 @Configuration이 구성에 포함된 모든 Bean은 조건이 충족되는 경우에만 로드됩니다.

@Configuration
@Conditional... // <--

class ConditionalConfiguration {

    @Bean
    Bean bean() {
        ...
    }

    ;

}

Conditional @Component

마지막으로 @component, @Service, @Repository, 또는 @Controller 등과 같은 stereotype annotation 중 하나로 선언된 모든 Bean에 조건을 추가할 수 있습니다.

@Component
@Conditional... // <--

class ConditionalComponent {
}

Pre-defined Conditions

Spring Boot는 바로 사용할 수 있는 미리 정의된 @ConditionalOn... annotation을 제공합니다. 각각을 차례로 살펴보겠습니다.

@ConditionalOnProperty

이 @ConditionalOnProperty annotation은 제 경험상 Spring Boot 프로젝트에서 가장 일반적으로 사용되는 Conditional annotation입니다. 특정 환경 속성에 따라 Bean을 Conditional로 로드할 수 있습니다.

@Configuration
@ConditionalOnProperty(
        value = "module.enabled",
        havingValue = "true",
        matchIfMissing = true)
class CrossCuttingConcernModule {
    ...
}

CrossCuttingConcernModule은 module.enabled 값이 있고,true인 경우에만 로드됩니다. 속성이 전혀 설정되지 않은 경우에도 matchIfMissing를 true로 정의했기 때문에 로드됩니다. 이런 식으로, 우리는 달리 결정할 때까지 기본적으로 로드되는 모듈을 만들었습니다.

같은 방식으로 보안이나 스케줄링과 같은 교차적 문제에 대해 다른 모듈을 만들어 특정 (테스트) 환경에서 비활성화할 수도 있습니다.

@ConditionalOnExpression

여러 속성에 기반한 더 복잡한 조건이 있는 경우 @ConditionalOnExpression을 사용할 수 있습니다.

@Configuration
@ConditionalOnExpression(
        "${module.enabled:true} and ${module.submodule.enabled:true}"
)
class SubModule {
    ...
}

SubModule은 module.enable속성과 module.submodule.enabled두 속성 모두에 값이 있는 경우에만 로드됩니다. 속성에 추가하여 속성이 설정되지 않은 경우 기본값으로 사용하라고 Spring에 알립니다. Spring Expression Language 의 전체 확장을 사용할 수 있습니다.

이 방법을 사용하면 부모 모듈이 비활성화되면 비활성화되어야 하는 하위 모듈을 만들 수 있지만, 부모 모듈이 활성화되면 비활성화될 수도 있습니다.

@ConditionalOnBean

때로는 애플리케이션 컨텍스트에서 특정 다른 Bean을 사용할 수 있는 경우에만 Bean을 로드하고 싶을 수 있습니다.

@Configuration
@ConditionalOnBean(OtherModule.class)
class DependantModule {
    ...
}

DependantModule은 애플리케이션 컨텍스트에 OtherModule 클래스의 Bean이 있는 경우에만 로드됩니다. Bean 클래스 대신 Bean 이름을 정의할 수도 있습니다.

이런 식으로, 예를 들어 특정 모듈 간의 종속성을 정의할 수 있습니다. 한 모듈은 다른 모듈의 특정 Bean이 사용 가능한 경우에만 로드됩니다.

@ConditionalOnMissingBean

마찬가지로, 특정 다른 Bean이 애플리케이션 컨텍스트에 없는 경우에만 Bean을 로드하려는 경우 @ConditionalOnMissingBean을 사용할 수 있습니다 .

@Configuration
class OnMissingBeanModule {

    @Bean
    @ConditionalOnMissingBean
    DataSource dataSource() {
        return new InMemoryDataSource();
    }
}

이 예에서 우리는 이미 사용 가능한 데이터 소스가 없는 경우에만 애플리케이션 컨텍스트에 메모리 내 데이터 소스를 주입합니다. 이는 Spring Boot가 테스트 컨텍스트에서 메모리 내 데이터베이스를 제공하기 위해 내부적으로 수행하는 작업과 매우 유사합니다.

@ConditionalOnResource

클래스 경로에서 특정 리소스를 사용할 수 있다는 사실에 따라 Bean을 로드하려는 경우 @ConditionalOnResource을 사용할 수 있습니다.

@Configuration
@ConditionalOnResource(resources = "/logback.xml")
class LogbackModule {
    ...
}

LogbackModule클래스 경로에서 logback configuration 파일이 발견된 경우에만 로드됩니다. 이런 식으로, 해당 구성 파일이 발견된 경우에만 로드되는 유사한 모듈을 만들 수 있습니다.

Other Conditions

위에서 설명한 Conditional annotation은 Spring Boot 애플리케이션에서 사용할 수 있는 일반적인 annotation입니다. Spring Boot는 더 많은 Conditional annotation 을 제공합니다. 그러나 이러한 annotation은 그렇게 일반적이지 않으며 일부는 애플리케이션 개발보다는 프레임워크 개발에 더 적합합니다(Spring Boot는 이러한 annotation 중 일부를 비밀리에 많이 사용합니다). 따라서 여기서는 간략하게 살펴보겠습니다.

@ConditionalOnClass

특정 클래스가 클래스 경로에 있는 경우에만 Bean을 로드합니다.

@Configuration
@ConditionalOnClass(name = "this.clazz.does.not.Exist")
class OnClassModule {
    ...
}

@ConditionalOnMissingClass

특정 클래스가 클래스 경로에 없는 경우에만 Bean을 로드합니다.

@Configuration
@ConditionalOnMissingClass(value = "this.clazz.does.not.Exist")
class OnMissingClassModule {
    ...
}

@ConditionalOnJndi

JNDI를 통해 특정 리소스를 사용할 수 있는 경우에만 Bean을 로드합니다.

@Configuration
@ConditionalOnJndi("java:comp/env/foo")
class OnJndiModule {
    ...
}

@ConditionalOnJava

특정 버전의 Java를 실행하는 경우에만 Bean을 로드합니다.

@Configuration
@ConditionalOnJava(JavaVersion.EIGHT)
class OnJavaModule {
    ...
}

@ConditionalOnSingleCandidate

@ConditionalOnBean과 유사하지만 주어진 Bean 클래스에 대한 단일 후보가 결정된 경우에만 Bean을 로드합니다. auto-congifurations 외부에 사용 사례가 없을 가능성이 큽니다.

@Configuration
@ConditionalOnSingleCandidate(DataSource.class)
class OnSingleCandidateModule {
    ...
}

@ConditionalOnWebApplication

웹 애플리케이션 내부에서 실행하는 경우에만 Bean을 로드합니다.

@Configuration
@ConditionalOnWebApplication
class OnWebApplicationModule {
    ...
}

@ConditionalOnNotWebApplication

웹 애플리케이션 내부에서 실행 하지 않는 경우에만 Bean을 로드합니다 .

@Configuration
@ConditionalOnNotWebApplication
class OnNotWebApplicationModule {
    ...
}

@ConditionalOnCloudPlatform

특정 클라우드 플랫폼에서 실행하는 경우에만 Bean을 로드합니다.

@Configuration
@ConditionalOnCloudPlatform(CloudPlatform.CLOUD_FOUNDRY)
class OnCloudPlatformModule {
    ...
}

Custom Conditions

Conditional annotation 외에도 우리는 우리만의 조건 annotation을 만들고 논리 연산자를 사용해 여러 조건을 결합할 수 있습니다.

Custom Condition의 정의

운영 체제와 네이티브하게 통신하는 Spring Bean이 있다고 가정해 보겠습니다. 이러한 Bean은 해당 운영 체제에서 애플리케이션을 실행하는 경우에만 로드해야 합니다.

코드를 유닉스 머신에서 실행하는 경우에만 Bean을 로드하는 조건을 구현해 보겠습니다. 이를 위해 Spring의 Condition 인터페이스를 구현합니다.

class OnUnixCondition implements Condition {

    @Override
    public boolean matches(
            ConditionContext context,
            AnnotatedTypeMetadata metadata) {
        return SystemUtils.IS_OS_LINUX;
    }
}

우리는 단순히 Apache Commons의 SystemUtils클래스를 사용하여 유닉스 계열 시스템에서 실행 중인지 확인합니다. 필요하다면 현재 애플리케이션 컨텍스트 (ConditionContext) 또는 annotation이 달린 클래스(AnnotatedTypeMetadata)에 대한 정보를 사용하는 보다 정교한 로직을 포함할 수 있습니다.

이제 이 조건을 Spring의 @Conditional annotation과 함께 사용할 준비가 되었습니다.

@Bean
@Conditional(OnUnixCondition.class)
UnixBean unixBean() {
    return new UnixBean();
}

OR로 조건 결합

논리적 “OR” 연산자를 사용하여 여러 조건을 단일 조건으로 결합하려면 AnyNestedCondition을 확장할 수 있습니다.

class OnWindowsOrUnixCondition extends AnyNestedCondition {

    OnWindowsOrUnixCondition() {
        super(ConfigurationPhase.REGISTER_BEAN);
    }
    
    @Conditional(OnWindowsCondition.class)
    static class OnWindows {}
    
    @Conditional(OnUnixCondition.class)
    static class OnUnix {}
}

여기서는 애플리케이션이 Windows나 Unix에서 실행되는지 여부에 관계없이 충족되는 조건을 생성했습니다.

AnyNestedCondition부모 클래스는 메서드에 대한 @Conditionalannotation을 평가하고 OR 연산자를 사용하여 이를 결합합니다.

이 조건은 다른 조건과 마찬가지로 사용할 수 있습니다.

@Bean
@Conditional(OnWindowsOrUnixCondition.class)
WindowsOrUnixBean windowsOrUnixBean() {
    return new WindowsOrUnixBean();
}

AnyNestedCondition 이나 AllNestedConditions가 동작하지 않나요?

super()에 전달된 ConfigurationPhase 매개변수를 확인합니다. 결합된 조건을 @Configuration Bean에 적용하려면 PARSE_CONFIGURATION 값을 사용합니다. 조건을 간단한 Bean에 적용하려면 위의 예시처럼 REGISTER_BEAN을 사용합니다. Spring Boot는 애플리케이션 컨텍스트 시작 시 적절한 시기에 조건을 적용할 수 있도록 이러한 구분을 해야 합니다.

AND를 사용한 조건 결합

조건을 AND 논리와 결합하려면 단일 Bean에 여러 개의 @Conditional... annotation 을 사용하면 됩니다. 이러한 annotation은 논리적 “AND” 연산자와 자동으로 결합되므로 적어도 하나의 조건이 실패하면 Bean이 로드되지 않습니다.

@Bean
@ConditionalOnUnix
@Conditional(OnWindowsCondition.class)
WindowsAndUnixBean windowsAndUnixBean() {
    return new WindowsAndUnixBean();
}

누군가가 내가 모르는 Windows/Unix 하이브리드를 만들지 않는 한, 이 Bean은 반드시 로드되어서는 안 됩니다.

@Conditionalannotation은 단일 메서드나 클래스에서 두 번 이상 사용할 수 없습니다. 따라서 이런 방식으로 여러 annotation을 결합하려면 이러한 제한이 없는 사용자 지정 @ConditionalOn...annotation을 사용해야 합니다. 아래에서 @ConditionalOnUnix annotation을 만드는 방법을 살펴보겠습니다.

또는 AND를 사용하여 조건을 단일 @Conditionalannotation으로 결합하려면 Spring Boot의 AllNestedConditions클래스를 확장할 수 있으며, 이는 위에서 설명한 AnyNestedConditions과 정확히 동일하게 작동합니다.

NOT을 사용한 조건 결합

AnyNestedCondition 및 AllNestedConditions과 유사하게, 결합된 조건이 하나도 일치하지 않는 경우에만 Bean을 로드하도록 NoneNestedCondition을 확장할 수 있습니다.

사용자 정의 @ConditionalOn… annotation 정의

우리는 어떤 조건에 대해서도 custom annotation을 만들 수 있습니다. 우리는 단순히 이 annotation에 다음과 같이 메타 @Conditionalannotation을 달면 됩니다:

@Target({ ElementType.TYPE, ElementType.METHOD })
@Retention(RetentionPolicy.RUNTIME)
@Documented
@Conditional(OnLinuxCondition.class)
public @interface ConditionalOnUnix {}

우리가 새로운 annotation으로 Bean에 annotation을 달 때 Spring은 이 메타 annotation을 평가할 것입니다:

@Bean
@ConditionalOnUnix
LinuxBean linuxBean(){
    return new LinuxBean();
}

결론

@Conditional annotation과 Custom @Conditional... annotation을 생성할 수 있는 기능을 통해, Spring은 이미 우리에게 애플리케이션 컨텍스트의 내용을 제어할 수 있는 많은 기능을 제공합니다.

Spring Boot는 편리한 @ConditionalOn... annotation을 최상단에 추가하여 사용할 수 있게 해 주고, AllNestedConditions, AnyNestedCondition또는 NoneNestedCondition을 사용하여 조건을 결합할 수 있도록 하여 이를 기반 으로 구축됩니다. 이러한 도구를 사용하면 프로덕션 코드와 테스트를 모듈화할 수 있습니다.

하지만 권한에는 책임이 따르므로 조건문으로 애플리케이션 컨텍스트를 가득 채우지 않도록 주의해야 합니다. 그렇지 않으면 언제 무엇이 로드되는지 추적할 수 없게 됩니다.

참고자료 및 출처

• https://reflectoring.io/spring-boot-conditionals/

이 다섯 가지 함수를 배울 때는 두 가지를 기억해야 합니다. 사용법 과 사용 시기입니다. 유사한 성격 때문에 처음에는 약간 중복되는 것처럼 보일 수 있습니다.

이 게시물에서는 먼저 이 다섯 가지 범위 지정 함수의 공통점을 살펴보고, 그 다음 차이점을 살펴보겠습니다. 마지막으로, 언제 이 함수를 사용해야 하는지에 대한 규칙에 대해 알아보겠습니다.

그들은 무엇을 하나요?

이 다섯 가지 함수는 기본적으로 매우 유사한 일을 합니다. receiver parameter와 code block을 받은 다음 제공된 receiver에서 제공된 code block을 실행하는 범위 지정 함수(scoping function)입니다.

먼저 그 함수 중 하나와 어떻게 작동하는지 살펴보겠습니다. with 함수는 기본적으로 다음과 같이 정의됩니다.

inline fun <T, R> with(receiver: T, block: T.() -> R): R {
    return receiver.block()
}

이를 사용하면 코드를 더 간결하게 만들 수 있습니다. 먼저 범위 지정 함수를 사용하지 않는 일반적인 코드를 살펴보겠습니다.

class Person {
    var name: String? = null
    var age: Int? = null
}

val person: Person = getPerson()
print(person.name)
print(person.age)

다음 code snippet은 위의 code snippet과 동일하지만, person 변수 의 중복을 제거하기 위해 with() 범위 함수를 사용합니다.

val person: Person = getPerson()
with(person) {
    print(name)
    print(age)
}

좋아요! 하지만, 그럼 왜 함수가 5개나 필요한 걸까요? 아래를 봅시다!

apply, with, let, also 및 run의 차이점

이러한 함수는 매우 유사한 일을 하지만, 서명(signature)과 구현(implementation)에 중요한 차이점이 있습니다. 이러한 차이점은 어떻게 사용해야 하는지를 지시합니다.

with() 함수를 다른 함수 중 하나인 also() 함수의 서명과 구현과 비교해 보겠습니다. 이 함수는 기본적으로 다음과 같이 정의되어 있습니다.

inline fun <T, R> with(receiver: T, block: T.() -> R): R {
    return receiver.block()
}

inline fun <T> T.also(block: (T) -> Unit): T {
    block(this)
    return this
}

with() 함수 와 also() 함수는 3가지 면에서 다릅니다.

1. with() 의 경우에는 receiver 인수가 명시적 매개변수 T 로 제공되지만, also() 의 경우에는 암시적 receiver T 로 제공됩니다.
2. 블록 인수는 with() 의 경우 암묵적 receiver T를 갖는 함수로 정의되지만, also() 의 경우에는 명시적 인수 T를 갖습니다.
3. with() 함수 는 블록 인수를 실행하여 반환되는 내용을 반환하는 반면, also() 함수는 receiver로 제공된 동일한 객체를 반환합니다.

이러한 3가지 차이점 때문에 also() 함수는 다른 방식으로 사용해야 합니다.

val person: Person = getPerson().also {
    print(it.name) print (it.age)
}

이 코드 snippet은 getPerson() 함수를 사용하여 사람을 검색하고, person 변수에 할당합니다. 그렇게 하기 전에 also() 함수는 검색된 사람의 이름과 나이를 print합니다.

다른 함수인 apply, let, run은 어떨까요? 모두 위에 표시된 3가지 차이점 중 한 가지에 대해서 다릅니다.

• 명시적 receiver parameter vs. 암시적 receiver
• 명시적 parameter vs. 암묵적 receiver로 블록 인수에 제공됨
• receiver를 반환하는 것 vs. 블록이 반환하는 것을 반환하는 것

5가지 함수의 정의는 다음과 같습니다.

inline fun <T, R> with(receiver: T, block: T.() -> R): R {
    return receiver.block()
}
inline fun <T> T.also(block: (T) -> Unit): T {
    block(this)
    return this
}
inline fun <T> T.apply(block: T.() -> Unit): T {
    block()
    return this
}
inline fun <T, R> T.let(블록: (T) -> R): R {
    return block(this)
}
inline fun <T, R> T.run(블록: T.() -> R): R {
    return block()
}

이러한 함수를 배울 때, 함수의 정의를 기억하기 어려울 수 있습니다. Kotlin 표준 범위 함수 스프레드시트는 행렬에서 차이점을 보여줍니다. 필요할 때마다 인쇄하여 참조하는 것이 좋습니다.

apply, with, let, also 또는 run을 사용하는 경우

우리는 이제 이 다섯 가지 함수가 어떻게 다른지 알고 있습니다. 하지만 우리는 여전히 어떤 범위 지정 함수를 언제 사용해야 하는지 모릅니다. 이들은 본질적으로 매우 유사하며 종종 상호 교환이 가능합니다.

공식 Kotlin 문서 에 정의된 이 다섯 가지 함수에 대한 여러 가지 모범 사례와 규칙이 있습니다. 이러한 규칙을 배우면 더 관용적인 코드를 작성할 수 있으며 다른 개발자의 코드 의도를 더 빨리 이해하는 데 도움이 됩니다.

apply 사용에 대한 규칙

블록 내에서 receiver의 어떤 함수에도 접근하지 않고 동일한 receiver를 반환하려는 경우 apply() 함수를 사용합니다. 이는 새 객체를 초기화할 때 가장 자주 발생합니다. 다음 snippet은 예를 보여줍니다.

val peter = Person().apply {
    // only access properties in apply block!
    name = "Peter"
    age = 18
}

apply() 없이 동일한 코드는 다음과 같습니다.

val clark = Person()
clark.name = "Clark"
clark.age = 18

also 사용에 대한 규칙

블록이 receiver 매개변수에 전혀 접근하지 않거나 receiver 매개변수를 변형하지 않는 경우 also() 함수를 사용합니다. 블록이 다른 값을 반환해야 하는 경우 also() 를 사용하지 마세요. 예를 들어, 객체에 대한 일부 부작용을 실행하거나 속성에 할당하기 전에 데이터를 검증할 때 매우 유용합니다.

class Book(val author: Person) {
    val author = author.also {
        requireNotNull(it.age)
        print(it.name)
    }
}

also() 없이 동일한 코드는 다음과 같습니다.

class Book(val author: Person) {
    init {
        requireNotNull(author.age)
        print(author.name)
    }
}

let 사용 규칙

다음의 경우 모두 let() 함수를 사용하세요.

• 주어진 값이 null이 아닌 경우 코드를 실행
• null 허용 객체를 다른 null 허용 객체로 변환
• 단일 로컬 변수의 범위를 제한

getNullablePerson()?.let {
    // only executed when not-null
    promote(it)
}
val driversLicence: Licence? = getNullablePerson()?.let {
    // convert nullable person to nullable driversLicence
    licenceService.getDriversLicence(it)
}
val person: Person = getPerson()
getPersonDao().let { dao ->
    // scope of dao variable is limited to this block
    dao.insert(person)
}

let() 없이 동일한 코드는 다음과 같습니다.

val person: Person? = getPromotablePerson()
if (person != null) {
    promote(person)
}
val driver: Person? = getDriver()
val driversLicence: Licence? = if (driver == null) null else
    licenceService.getDriversLicence(it)
val person: Person = getPerson()
val personDao: PersonDao = getPersonDao()
personDao.insert(person)

with 사용 규칙

with()는 null이 불가능한 receiver에서만 사용하고, 결과가 필요하지 않을 때 사용합니다. 예를 들어:

val person: Person = getPerson()
with(person) {
    print(name)
    print(age)
}

with() 없이 동일한 코드는 다음과 같습니다.

val person: Person = getPerson()
print(person.name)
print(person.age)

run 사용에 대한 규칙

어떤 값을 계산하거나 여러 로컬 변수의 범위를 제한하려면 run() 함수를 사용하세요. 명시적 매개변수를 암묵적 receiver로 변환하려면 run()도 사용하세요.

val inserted: Boolean = run {
    val person: Person = getPerson()
    val personDao: PersonDao = getPersonDao()
    personDao.insert(person)
}
fun printAge(person: Person) = person.run {
    print(age)
}

run()이 없는 동일한 코드는 다음과 같습니다.

val person: Person = getPerson()
val personDao: PersonDao = getPersonDao()
val inserted: Boolean = personDao.insert(person)
fun printAge(person: Person) = {
    print(person.age)
}

여러 범위 기능 결합

이전 섹션에서는 코드 가독성을 개선하기 위해 범위 지정 함수를 격리하여 사용하는 방법을 보여주었습니다. 동일한 코드 블록 내에서 여러 범위 지정 함수를 결합하는 것이 종종 유혹적입니다.

범위 지정 함수가 중첩되면 코드가 빠르게 혼란스러워질 수 있습니다. 원칙적으로 receiver 인수를 람다 블록의 receiver에 바인딩하는 범위 지정 함수(apply, run, with)를 중첩하지 않도록 합니다. 다른 범위 지정 함수(let, also)를 중첩할 때는 람다 블록의 매개변수에 대한 명시적 이름을 제공합니다. 즉, 해당 범위 지정 함수를 중첩할 때 암시적 매개변수 it을 사용하지 마세요.

중첩 외에도 범위 지정 함수는 호출 체인에 결합될 수도 있습니다. 중첩과 달리 이런 방식으로 범위 지정 함수를 결합할 때 가독성 페널티가 없습니다. 오히려 가독성 개선이 훨씬 더 커질 것입니다.

이 글의 마무리로, 호출 체인에서 범위 지정 함수를 결합하는 몇 가지 예를 살펴보겠습니다.

private fun insert(user: User) = SqlBuilder().apply {
    append("INSERT INTO user (email, name, age) VALUES ")
    append("(?", user.email)
    append(",?", user.name)
    append(",?)", user.age)
}.also {
    print("Executing SQL update: $it.")
}.run {
    jdbc.update(this) > 0
}

위의 snippet은 데이터베이스에 사용자를 삽입하기 위한 dao 함수를 보여줍니다. Kotlin의 표현식 본문 구문을 사용하면서도 구현 내에서 우려 사항을 분리합니다. 즉, SQL 준비, SQL 로깅, SQL 실행입니다. 마지막에 이 함수는 삽입의 성공을 나타내는 Boolean을 반환합니다.

참고자료 및 출처

• https://medium.com/@fatihcoskun/kotlin-scoping-functions-apply-vs-with-let-also-run-816e4efb75f5

실질적으로 거의 대부분의 python 프로젝트에서 활용한다고 볼 수 있습니다. 각 프로젝트에서 사용하는 라이브러리의 버전에 따라 충돌이 발생할 수 있기 때문에 호환 가능한 버전 관리 목적이라고 보면 될 것 같습니다. (spring 의 pom.xml, build.gradle등에서 버전 관리하는 것과 유사)

venv의 장점

• 격리된 환경: 다양한 프로젝트에서 서로 다른 패키지나 Python 버전의 충돌 없이 작업할 수 있습니다.
• 버전 관리: 프로젝트별로 필요한 패키지와 그 버전을 쉽게 관리할 수 있습니다.
• 의존성 문제 해결: 각 프로젝트의 의존성을 명확하게 알 수 있으므로 배포나 협업 시 문제를 최소화 할 수 있습니다.

venv의 단점

• 추가적인 공간: 각 가상 환경마다 패키지를 복제하기 때문에 디스크 공간이 추가로 필요합니다.
• 관리: 여러 가상 환경을 사용하면 관리가 복잡해질 수 있습니다.

venv 사용 방법

가상 환경 생성

Windows:

python -m venv [가상환경명]

Linux/Mac:

python3 -m venv [가상환경명]

가상 환경 활성화

Windows:

[가상환경명]\Scripts\activate

Linux/Mac:

source [가상환경명]/bin/activate

가상 환경 비활성화

모든 운영체제에서:

deactivate

패키지 설치

활성화된 가상 환경에서,

pip install [패키지명]

requirements.txt를 활용한 패키지 설치

requirements.txt 파일 내의 패키지를 한번에 모두 설치할 때는,

pip install -r requirements.txt 

가상 환경 내 패키지 리스트 확인 및 requirements.txt 만들기

가상환경 내 패키지 리스트 확인:

pip freeze

가상환경 내 패키지를 requirements.txt 만들기

pip freeze > requirements.txt

가상환경 삭제하기

가상 환경은 결국 폴더 형태로 저장되기 때문에, 해당 폴더를 삭제하면 가상 환경도 함께 삭제된다.

활용 예시

가상 환경 생성 및 활성화

Windows:

python -m venv myenv
myenv\Scripts\activate

Linux/Mac:

python3 -m venv myenv
source myenv/bin/activate

패키지 설치 및 확인

pip install requests
pip freeze

가상 환경 종료

deactivate

추가 Tip

PowerShell에서 가상 환경 활성화 안될 때 활성화 시키기

Windows:

myenv\Scripts\activate.ps1

보안 오류로 가상 환경 활성화가 안될 때

+ .\Scripts\Activate.ps1
+ ~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : 보안 오류: (:) [], PSSecurityException
    + FullyQualifiedErrorId : UnauthorizedAccess

위와 같은 문구가 뜨면서 가상환경 진입이 안될 때는 윈도우 실행정책이 막혀 있는 경우입니다.

Set-ExecutionPolicy -ExecutionPolicy Unrestricted -Scope LocalMachine

cmd창에 위와 같이 입력하여 정책을 변경하면 가상환경이 활성화 되는 것을 확인 할 수 있습니다.

참고자료 및 출처

• https://blog.deeplink.kr/?p=942

Java개발을 하다보면, 리스트를 순회하면서 특정 원소를 삭제하고 싶을 때가 있습니다. 예를 들어, 다음과 같이 알파벳과 숫자가 섞여있는 리스트가 있다고 가정해봅시다.

List<Character> letters = new ArrayList<>();
letters.addAll(Arrays.asList('A', 'B', '1', '2', 'C', 'D', '3', 'E', '4', '5'));

저는 이 리스트에서 숫자만 찾아서 모두 삭제하려고 한다는걸 가정합니다.

ConcurrentModificationException 발생

Collection에서 원소를 지우는 것은 boolean remove(Object o) 메소드를 사용하면 됩니다. Collection 의 각 원소에 대해서 for 루프를 돌면서 해당 원소가 숫자인지 여부를 체크한 후에, 숫자이면 remove 함수를 호출합니다.

for (Character letter : letters) {
    if (Character.isDigit(letter)) {
        letters.remove(letter);
    }
}

하지만 위 코드를 실행해 보면, ConcurrentModificationException을 발생시킵니다.

Exception in thread "main" java.util.ConcurrentModificationException
  at java.util.ArrayList$Itr.checkForComodification(ArrayList.java:901)
  at java.util.ArrayList$Itr.next(ArrayList.java:851)
...

이해를 위해서 개념적으로만 접근하자면, 해당 element 기준으로 for 문을 돌고 있을 때, 해당 엘리먼트를 Collection에서 삭제해 버리면, 아직 for문을 빠져나가기 전이고, 그래서 해당 element를 기준으로 돌고 있는데, 삭제되었다고 생각하여 문제를 일으키게 되는 것입니다.

인덱스 기반 for 문으로 해결 시도

그럼, 위 처럼 element기준으로 for 문을 순환하지 말고, 인덱스를 사용하는 for 문으로 바꿔서 루프를 돌려보겠습니다.

for (int i = 0; i < letters.size(); i++) {
    Character letter = letters.get(i);
    if (Character.isDigit(letter)) {
        letters.remove(i); // 또는 letters.remove(letter);
    }
}

이번에는 Exception은 발생하지 않는데, 리스트를 출력해보면 원하는대로 숫자 원소가 모두 삭제되지 않았음을 확인할 수 있습니다.

System.out.println(letters);

[A, B, 2, C, D, E, 5]

왜 이런 일이 발생하는 걸까요? 원인은 리스트에서 i 번째 원소 삭제되면, i + 1 번째 원소가 그 자리에 오게되고, 리스트의 길이가 1만큼 짧아지는데서 찾을 수 있습니다. 예를 들어, 1이 삭제되면 그 자리에 2가 오게 되므로, for 문은 2를 건너뛰고 바로 C를 체크하게 됩니다.

이런 문제를 해결하기 위해서, 삭제하고 나면 내 자리에 다음 element가 오니까, 아래와 같이 해결하기도 합니다. 하지만 온전히 동작하기엔 조금 이상한 부분은 있습니다. 개념적으로만 이해하세요.

for (int i = 0; i < letters.size(); i++) {
    Character letter = letters.get(i);
    if (Character.isDigit(letter)) {
        letters.remove(i); 
        i--;
    }
}

이터레이터로 해결

자바의 Iterator 인터페이스는 remove 메소드를 제공하고 있습니다. 자바 공식 문서를 보면 이 메소드를 사용하는 것이 컬렉션을 순회하면서 원소를 삭제할 수 있는 유일하게 안전한 방법이라고 가이드하고 있습니다.

Note that Iterator.remove is the only safe way to modify a collection during iteration; the behavior is unspecified if the underlying collection is modified in any other way while the iteration is in progress.

for (Iterator<Character> iter = letters.iterator(); iter.hasNext(); ) {
    Character letter = iter.next();
    if (Character.isDigit(letter)) {
        iter.remove();
    }
}

가이드 대로 위와 같이 이터레이터를 이용하여 코드를 작성하면 원하던 대로 리스트에서 숫자 원소들이 삭제되는 것을 확인할 수 있습니다.

자바8 에서는…

Collection 인터페이스에 removeIf 메소드가 추가 되어 다음과 같이 한 줄의 코드면 충분합니다.

letters.removeIf(Character::isDigit);

추가로 원본 리스트에 변경을 가하지 않고, 숫자 원소가 삭제된 새로운 리스트를 얻고 싶은 경우, 다음과 같이 스트림 API를 사용할 수 있습니다. 하지만 이렇게 하면 하나의 Collection을 재 생성하기 때문에 크게 권장하는 방법은 아닐 수 있습니다. (필요에 따라서 선택!)

List<Character> alphabets = letters.stream()
    .filter(Character::isAlphabetic)
    .collect(Collectors.toList());

참고자료 및 출처

• https://www.daleseo.com/how-to-remove-from-list-in-java/
• https://docs.oracle.com/javase/8/docs/api/java/util/Iterator.html#remove--
• https://docs.oracle.com/javase/8/docs/api/java/util/Collection.html#removeIf-java.util.function.Predicate-

여기서는 이러한 계정들을 다 하나의 PC에 설치해 두고, 서로 전환해 가면서 사용할 수 있는 방법을 살펴보고자 한다. 여기서 계정을 설치한다는 의미는 awscli 상에 로그인 정보를 넣어두는 것을 의미하며, 웹 콘솔에 대한 부분은 아니다.

AWS Configure --profile

처음에 AWS Console 의 IAM에서 생성한 사용자에 대해, access key 를 생성해두면, 로컬 환경에서 다음과 같이 설정하여 configure 할 수 있다.

aws configure

AWS Access Key ID [****************XXXX]:
AWS Secret Access Key [****************XXXX]:
Default region name [ap-northeast-2]:
Default output format [json]:

사실 계정을 전환하려면 위 명령어 aws configure를 한 번 더 입력하고 다시 계정 정보를 입력하면 되지만, 비밀번호도 아닌 access key 를 가지고 하는 저 과정을 매번 전환하면서 하기란 귀찮은 일이다.

이럴때는 --profile옵션을 이용하여 각 configure정보를 profile에 저장한다.

aws configure --profile testUser

AWS Access Key ID [****************XXXX]:
AWS Secret Access Key [****************XXXX]:
Default region name [ap-northeast-2]:
Default output format [json]:

저렇게 profile을 지정해 두면, awscli 명령어 뒤에 --profile과 함께 사용하고자 하는 profile 이름을 입력하여 사용할 수 있다.

aws s3 ls --profile testUser

기본 프로파일 설정하기

위와 같이 설정하면, 프로파일로 동작하긴 하지만, 다른 툴이나 바이너리에서 aws 인증정보를 활용하려고 할 때 여전히 사용하지 못한다. 따라서 아래와 같이 AWS_DEFAULT_PROFILE 값을 지정해 주면 문제없이 사용이 가능하다.

export AWS_DEFAULT_PROFILE=testUser

이제 --profile 옵션 없이 command 실행해도 정상적으로 동작한다.

aws s3 ls 

기본값 활성화하기

만약 profile을 정말 자주 변경해야 한다면, 위와 같이 set 명령어를 이용해서 설정을 매번 바꿔줘야 한다. 하지만 매번 로그인하던 것 보다는 훨씬 편하다.

자주 변경되지는 않으나 종종 변경해야 하고, 기본값이 되었으면 하는 profile이 명확하다면 위 설정 부분을 .zshrc 혹은 .bashrc에 넣는다.

출처 및 참고자료

• https://novemberde.github.io/post/2018/06/20/AWS-config-switching/

별도의 shell 로 작성

뒤쪽에서 설명할 것 처럼, 권한 처리를 shell 파일에 주는 것이 안전하기 때문에 별도의 shell 에서 하고자 하는 작업(sudo 권한 필요)을 하게끔 정의합니다.

#/bin/sh
LOGFILE="/Users/criss/dev/work/crontab-log/mtu-$(date +%F).crontab.log"

/sbin/ifconfig utun4 mtu 1320

CUR_DATE=$(date)
UTUN4_VAL=$(/sbin/ifconfig | grep utun4)
echo "$CUR_DATE > $UTUN4_VAL" >> "$LOGFILE" 2>&1

위 내용에서 ifconfig 명령어가 sudo 권한을 요구한다.

shell을 sudo권한으로 실행해도 password를 묻지 않도록 수정

위 shell 을 crontab 에 등록하기 이전에, sudo 권한으로 실행 시, 비밀번호 입력 없이도 실행이 가능하도록 변경해줘야 한다.

sudo visudo

위 명령어로 sudo 권한을 조정하는 화면을 불러오고,

criss ALL=(ALL) NOPASSWD: /Users/criss/dev/work/mtu.sh

를 맨 마지막줄에 추가하여 해당 파일이 비밀번호 입력 없이 실행 가능하도록 한다.

crontab에 등록

이제 아래 명령어로 crontab 수정화면을 불러오고,

sudo crontab -u criss -e

아래와 같이 crontab 을 등록하면 됩니다.

@reboot sudo /Users/pc00079589/dev/work/mtu.sh
*/1 * * * * sudo /Users/pc00079589/dev/work/mtu.sh

(추가) 로그 파일 주기적으로 삭제

0 0 * * * find /Users/criss/dev/work/crontab-log -name "*.crontab.log" -mtime +7 -exec rm {} \\;

출처 및 참고자료

• Chat GPT

여기서는 간단한 튜토리얼 형태로 어떻게 Join 할 수 있는 지 살펴봅니다.

JPA Specification

Spring Data JPA 에서는 Specification이라는 interface 를 제공합니다.

이것을 활용하면, 재사용 가능한 component 들을 활용하여 dynamic query 를 생성할 수 있습니다.

여기서는 Author와 Book 이라는 class가 있다고 가졍합니다.

@Entity
public class Author {

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

    private String firstName;

    private String lastName;

    @OneToMany(cascade = CascadeType.ALL)
    private List<Book> books;

    // getters and setters
}

Author entity에 대해서 dynamic query 를 작성하기위해, Specification interface를 implements 합니다.

public class AuthorSpecifications {

    public static Specification<Author> hasFirstNameLike(String name) {
        return (root, query, criteriaBuilder) ->
          criteriaBuilder.like(root.<String>get("firstName"), "%" + name + "%");
    }

    public static Specification<Author> hasLastName(String name) {
        return (root, query, cb) ->
          cb.equal(root.<String>get("lastName"), name);
    }
}

마지막으로, AuthorRepository가 JpaSpecificationExecutor 를 상속받도록 구성합니다.

@Repository
public interface AuthorsRepository extends JpaRepository<Author, Long>, JpaSpecificationExecutor<Author> {
}

이러한 방식으로, 두 개의 specification을 chain해서 query 를 생성할 수 있습니다.

@Test
public void whenSearchingByLastNameAndFirstNameLike_thenOneAuthorIsReturned() {
    
    Specification<Author> specification = hasLastName("Martin")
      .and(hasFirstNameLike("Robert"));

    List<Author> authors = repository.findAll(specification);

    assertThat(authors).hasSize(1);
}

JPA Specification을 이용한 Table Join

앞서 살펴보았던 Author entity가 Book entity와 one-to-many (일대다) 관계를 가지고 있음을 알 수 있습니다.

@Entity
public class Book {

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

    private String title;

    // getters and setters
}

Criteria Query API 를 이용해서, Specification를 만들 때, 두 개의 Table을 Join 할 수 있습니다. 이러한 방식으로 Book entity의 특정 field를 우리의 쿼리에 포함할 수 있습니다.

public static Specification<Author> hasBookWithTitle(String bookTitle) {
    return (root, query, criteriaBuilder) -> {
        Join<Book, Author> authorsBook = root.join("books");
        return criteriaBuilder.equal(authorsBook.get("title"), bookTitle);
    };
}

이제, 앞서 만들어두었던 Specification과 병합할 수 있습니다.

@Test
public void whenSearchingByBookTitleAndAuthorName_thenOneAuthorIsReturned() {

    Specification<Author> specification = hasLastName("Martin")
      .and(hasBookWithTitle("Clean Code"));

    List<Author> authors = repository.findAll(specification);

    assertThat(authors).hasSize(1);
}

생성된 쿼리를 확인하면 join이 추가되었음을 알 수 있습니다.

select 
  author0_.id as id1_1_, 
  author0_.first_name as first_na2_1_, 
  author0_.last_name as last_nam3_1_ 
from 
  author author0_ 
  inner join author_books books1_ on author0_.id = books1_.author_id 
  inner join book book2_ on books1_.books_id = book2_.id 
where 
  author0_.last_name = ? 
  and book2_.title = ?

참고자료 및 출처

• https://www.baeldung.com/spring-jpa-joining-tables

이 post에는 sample 이 존재하지 않습니다. 필요 시 나중에 추가하도록 하겠습니다.

dependency 추가

API 를 작성할 것이므로 아래 dependency 를 추가합니다. 아마 대부분의 API서버에 이미 추가되어 있을 것입니다.

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-web</artifactId>
</dependency>

implementation("org.springframework.boot:spring-boot-starter-web")

@ResponseBody 사용하기

가장 간단히 사용할 수 있는 것은 @ResponseBody annotation 을 추가하는 것입니다.

@GetMapping("/get-text")
public @ResponseBody String getText() {
    return "Hello world";
}

이렇게 하면, view 를 찾는 것 대신에 Hello World 라는 문자열 자체를 return 하게 됩니다.

@Controller 대신 @RestController를 사용하는 Controller 를 구현하게 되면, 위 @ResponseBody 가 없어도 view를 찾지 않고 그대로 문자열을 return 합니다.

이미지 return 을 위한 produces 사용하기

이미지나 파일을 return 하는 데 있어서 byte array 를 return 하는 것이 쓰입니다.

@GetMapping(value = "/image")
public @ResponseBody byte[] getImage() throws IOException {
    InputStream in = getClass()
      .getResourceAsStream("/com/baeldung/produceimage/image.jpg");
    return IOUtils.toByteArray(in);
}

이렇게 하면 이미지에 대한 정보가 아무것도 없기 때문에 client 에서는 이미지임을 알 수 없습니다. 이러한 문제를 방지하기 위해서, @GetMapping annotation에 produces 값을 넣어줍니다.

@GetMapping(
  value = "/get-image-with-media-type",
  produces = MediaType.IMAGE_JPEG_VALUE
)
public @ResponseBody byte[] getImageWithMediaType() throws IOException {
    InputStream in = getClass()
      .getResourceAsStream("/com/baeldung/produceimage/image.jpg");
    return IOUtils.toByteArray(in);
}

이렇게 produces 값에 MediaType.IMAGE_JPEG_VALUE를 지정하면 return 되는 값을 이미지로 처리해야 함을 알려줄 수 있습니다.

이제, 브라우저는 이 return 값이 이미지임을 알고 이미지로 올바르게 처리해 줍니다.

Raw file 을 return 하기 위한 produces

produces 는 여러가지 값을 가질 수 있습니다. 전체 목록은 여기에 있습니다. return 하고자 하는 타입에 맞게 적절한 값을 넣어주면 됩니다.

그래서, 만약 우리가 파일 자체를 return 하고 싶다면 APPLICATION_OCTET_STREAM_VALUE 를 사용합면 됩니다.

@GetMapping(
  value = "/get-file",
  produces = MediaType.APPLICATION_OCTET_STREAM_VALUE
)
public @ResponseBody byte[] getFile() throws IOException {
    InputStream in = getClass()
      .getResourceAsStream("/com/baeldung/produceimage/data.txt");
    return IOUtils.toByteArray(in);
}

그렇지 않다면, Byte array 대신에 ByteArrayResource 를 사용해도 됩니다.

@GetMapping(
  value = "/get-file-via-byte-array-resource", 
  produces = MediaType.APPLICATION_OCTET_STREAM_VALUE
)
public @ResponseBody Resource getFileViaByteArrayResource() throws IOException, URISyntaxException {
    Path path = Paths.get(getClass().getResource("/com/baeldung/produceimage/data.txt").toURI());
    ByteArrayResource resource = new ByteArrayResource(Files.readAllBytes(path));
    return resource;
}

Resource 클래스는 Spring이 제공하는 높은 수준의 abstract class입니다. 이 클래스는 다양한 소스로부터 리소스를 다루는 데 도움을 줍니다. InputStream 을 통한 Resource의 사용은 다음과 같은 이점이 있습니다.

• 리소스에 대한 추가적인 메타데이터를 제공한다.
• Spring 의 다른 abstract 들과 유연하게 연결지을 수 있다.
• mock 하기 쉽다.

참고자료 및 출처

• https://www.baeldung.com/spring-controller-return-image-file

많아질수록 가독성이 떨어진다?

하지만 아이콘이 많아져서 dock이 길어지게 되면, 아무리 아이콘의 가독성이 좋다고 하더라도 쉽게 눈에 들어오지 않는 것이 문제입니다.

빠르게 실행하려고 dock 에 넣어놓은 것인데, 이 dock을 한참이나 찾고 있어야되는 상황이 벌어진다는 것이죠.

dock의 구분자?

dock에도 아이콘 사이를 구분하는 일종의 구분자가 있습니다. dock 은 크게

• (고정해 둔) 프로그램 영역
• 최근 실행 항목 영역 (이건 꺼둔 사람은 보이지 않음)
• 폴더와 휴지통 영역

이 세 개의 영역을 spacer혹은 파이프(|) 라고 부를 법한 것이 구분하고 있습니다.

따라서 최근 실행 항목 중, 필요한 것은 고정해 둘 수 있고 (좌측으로 이동), 폴더의 내용을 탐색할 수 있게 되는 것입니다.

구분자를 추가할 수 없다?

문제는 여기서 발생합니다.

위에서 말한 파이프(|) 모양은 사용자가 임의로 추가할 수 없고, 위에서 말한 목적의 구분자로만 사용됩니다.

따라서 고정해둔 앱들 사이에 저 파이프를 넣을 수는 없습니다. 비슷하게 생긴 이미지 파일로 dummy app을 추가하는 등의 방법도 보았지만, 필요 이상으로 번거로운 것이 문제입니다.

spacer 의 추가

이런 문제를 해결하기 위한 방법으로, 정식 방법처럼 종작하는 것이 바로 spacer를 추가하는 것입니다.

위 그림처럼 넓은 것과 좁근 것의 두 가지 종류를 추가할 수 있습니다.

Regular spacer script:

defaults write com.apple.dock persistent-apps -array-add '{"tile-type"="spacer-tile";}'; killall Dock

Small spacer script:

defaults write com.apple.dock persistent-apps -array-add '{"tile-type"="small-spacer-tile";}'; killall Dock

옮기기/삭제는 다른 아이콘과 동일하게

이렇게 추가한 spacer 를 옮기거나 추가/삭제 하는 것은 고정해 둔 다른 앱 아이콘과 동일하게 사용하면 된다.

Reference

• https://chrispennington.blog/blog/add-spacer-in-macos-dock/