반응형

Jetbrain Blog의 번역 글입니다. 원본은 아래 주소에 접속하여 확인 해 주세요 
https://blog.jetbrains.com/kotlin/2023/11/kotlin-multiplatform-development-roadmap-for-2024/ 

 

Kotlin Multiplatform Development Roadmap for 2024 | The Kotlin Blog

To equip you with the best cross-platform development experience, JetBrains aims to deliver a host of further improvements to the core Kotlin Multiplatform technology, Compose Multiplatform, KMP tooling, and KMP libraries in 2024.

blog.jetbrains.com


Kotlin Multiplatform Development Roadmap for 2024

더보기

With the recently achieved stability of Kotlin Multiplatform, development teams worldwide can now seamlessly and confidently adopt it in production. However, this is just the beginning for KMP and its ecosystem. To equip you with the best cross-platform development experience, JetBrains aims to deliver a host of further improvements to the core Kotlin Multiplatform technology, Compose Multiplatform, KMP tooling, and KMP libraries in 2024. Read on to learn what we’re planning and our priorities in these areas.

최근 완성된 코틀린 멀티플랫폼의 안정성 덕분에, 세계의 많은 개발팀들은 이제 장애물 없이 코플린 멀티 플랫폼을 프로덕션에 자신있게 적용할 수 있게 되었다.  하지만 이는 단지 KMP(Kotlin Multiplatform)과 에코시스템을 시작하는것일 뿐이다. 최고의 크로스 플랫폼 개발을 경험을 갖추게 하기 위해서, 2024년에 JetBrains는 핵심 코틀린 펄티플랫폼기술, 컴포즈 멀티 플랫폼, KMP도구와 라이브러리 같은 미래의 발전을 주도할것이다. 이 분야에서 무엇을 배워야하고, 어떤 순서로 배뭐야할지 알아보자. 

Compose Multiplatform

더보기

We’re dedicated to making Compose Multiplatform a framework that allows creating beautiful and performant applications that look the same way on all supported platforms. Right now, our main focus is to get Compose for iOS to Beta, but we’re also working on other things. Here’s what we plan to do:

  • Make all Jetpack Compose core APIs and components multiplatform.
  • Improve rendering performance on iOS.
  • Make scrolling and text editing in Compose for iOS apps behave the same as in iOS native apps.
  • Implement a common API for sharing all types of resources.
  • Integrate with iOS and Desktop accessibility APIs.
  • Provide a solution for multiplatform navigation.

Many of the aforementioned improvements benefit Compose for Desktop, as well. In addition, we’re working on improving its stability and evolving it according to the feedback from those who use it in production.

We’ll also continue to explore what’s possible with Compose for Web, specifically with Wasm. Our nearest goal is to promote it to Alpha, which includes:

  • Allowing you to port your existing apps and reuse all of your common code.
  • Supporting different screen sizes, orientations, and densities.
  • Supporting input from a mouse, touchscreen, physical keyboard, or onscreen keyboard.
  • Improving performance and binary size.

 

우리는 컴포즈 멀티플랫폼을 만들기 위해 헌신했다. 컴포즈 멀티플랫폼은 우리가 지원하는 모든 플랫폼에서 어플리케이션이 동일하게 동작하고 동일하게 보이도록지원해주는 아름답고 효율적인 프레임워크이다. 지금 당장 우리가 집중하고 있는것은 iOS를 위한 컴포즈 Beta 버전이다. 하지만 우리는 다른것들도 진행하고있다. 아래는 우리의계획이다. 

  • 모든 Jetpack Compose 코어API와 멀티플랫폼 컴포넌트 제작
  • iOS에서의 랜더링 퍼포먼스 향상
  • iOS 앱용 컴포즈에서의 스크롤링, 문자 수정(text edting) 동작을 iOS네이티브 앱과 동일하게 만들기
  • 모든 타입의 리소스를 공유할 수 있는 공통API 구현
  • iOS와 데스크탑의 접근성 API 통합
  • 멀티플렛폼 네비게이션을 위한 소루션 제공

앞서 말한 많은 개선사항은 컴포즈 for 데스크탑에도 역시 도움이 된다. 더욱이, 우리는 제품 사용자들의 피드백을 통해서 안정성 향상과 새로운 기능 향상 작업도 진행하고있다.

우리는 또한 컴포즈 for Web, 특히 Wasm에 대한 작업도 지속하고있다. 우리의 가장 가까운 목표는 컴포트 for Web을 알파 버전으로 만드는 것이다. 알파버전엔 다음이 포함된다. 

  • 이미 존재하는 앱들의 포팅기능, 공통코드의 재사용 기능.
  • 다양한 화면 사이즈(size, orientation, densitie) 지원,
  • 마우스, 터치스크린, 키보드, 스크린 키보드 지원
  • 퍼포먼스와 용량 향상.
  •  

Tooling

We’re committed to providing a great IDE experience for Kotlin Multiplatform. That means not only investing in the core platform and, for example, migrating Kotlin IDE plugin to K2 compiler frontend, but also providing a single tool (Fleet) for all Kotlin Multiplatform targets and codebases where you integrate it, eliminating the need to constantly switch between different IDEs.

We plan to quickly iterate over your feedback about using Fleet for Kotlin Multiplatform development  to make sure that we have everything you need for your development experience to be great. Among other things, we’re going to deliver in the following areas:

  • Enhanced support for Compose Multiplatform, including live preview for common code and visual debugging tools.
  • The IDE helping you with project configuration.
  • Unified and enhanced debugging experience for all parts of your Multiplatform project.

우리는 Kotlin Multiplatform을 위한 훌륭한 IDE 환경을 제공하기 위해 최선을 다하고 있습니다. 이는 Kotlin IDE plugin을 K2 compiler frontend 마이그레이팅 하는것 같은 코어 플랫폼 뿐만 아니라 개발자들이 통합하게 될 모든 Kotlin Multiplatform 타겟과 코드베이스를 위한 싱글툴(Fleet)을 제공하여 끊임없는 IDE변경을 제거한다는 의미입니다. 

우리는 Fleet for Kotlin Multiplatform development의 사용성에 대한 피드백을 빠르고 반복적으로 처리하여 개발자들에게 훌륭한 개발 경험을 제공하려고 합니다. 이런 행위들 사이에서 우리는 아래와 같은것들을 제공할 것 입니다.

  • 공통 코드를 위한 라이브 프리뷰와 시각적 디버깅 툴을 포함한 컴포즈 멀티플랫폼 서포트 증가
  • IDE의 프로젝트 configuration 도움
  • 멀티플랫폼 프로젝트의 모든 부분에서 통합되고 향상된 디버깅 경험 제공.

Multiplatform core

더보기

One of the popular Kotlin Multiplatform scenarios is sharing code with the iOS target. We want to focus on the development experience of iOS developers who work with Kotlin Multiplatform frameworks in their codebases.

The main initiative in this area is a direct Kotlin-to-Swift export. It will eliminate the Objective-C bottleneck, allowing for broader Swift language support and more natural exporting of APIs. Additionally, we are creating tools specifically for Kotlin library authors. These tools are designed to improve the compatibility and user-friendliness of Kotlin APIs when exported to Swift. We’re also paying close attention to tooling. The IDE and build systems are essential parts of the developer experience, and our goal is to ensure that the Swift Export integrates smoothly.

Our other initiatives include speeding up Kotlin/Native compilation, enhancing CocoaPods integration, and introducing support for exporting your framework with SwiftPM.

We also plan to continue exploring ways to improve the build setup of Kotlin Multiplatform applications. With Kotlin 1.9.20, we released huge improvements in the Gradle Multiplatform DSL, making it easier to read and write. We will continue to gradually improve it. In addition, we’re experimenting with Amper, a new project configuration tool focused on usability, onboarding, and IDE support.

Kotlin Multiplatform의 가장 유명한 시나리오 중 하나는 iOS 타겟괴 코드를 쉐어 하는 것 이다. 코드 베이스에서 코틀린 멀티플랫폼 프레임워크를 사용하는 iOS개발자의 경험에 중점을 두고 있다. 

이 분야에서의 주요 계획은 Kotlin-to-Swift의 직접 번역(direct export)이다.  이를 통해 Object-C 보틀렉을 제거와 광범위한 Swift언어 지원, 자연스러운 API exporting이 가능해진다. 더욱이, 우리는 코틀린 라이브러리 개발자들을 위한 도구(tool)들을 만들었다. 이 도구들은 Swift로 export될 때  Kotlin API의 호환성과 사용자친화성을 개선하도록 디자인 되다. 우리는 툴링(tooling)에도 세심한 주의를 기울이고 있다. IDE와 빌드 시스템은 개발자 경험의 중요한 부분입니다. 우리의 목표는 Swift Export를 부드럽게 만드는 것 이다. 

우리의 또 다른 우선순위는 Kotlin/Native 컴파일의 속도 증가, CocoaPods의 강화, SwiftPM을 사용한프레임워크 exporting 서포트 소개 를 포함하고 있다. 

우리는 또한 코틀린 멀티 플랫폼 어플리케이션의 빌드 셋업 향상을 위한 방법도 지속적으로 탐험할 계획이다. Kotlin1.9.20애서 우리는 Gradle Multiplatform DSL의 거대한 향상을 릴리즈하여 읽고, 쓰기 쉽게 만들었다. 우리는 계속적으로 향상시킬 예정이다. 더욱이 우리는 Amper라는 실험을 하고있다. Amper는 사용성, 온보딩, IDE서포트에 초점을 맞춘 새로운 프로젝트 configuration tool이다. 

Library ecosystem

더보기

As the Kotlin Multiplatform ecosystem is growing fast, the backward compatibility of the libraries becomes crucial. To ensure it, the JetBrains team and library creators must work together. Here’s our plan:

  • Improve the klib format so library creators can leverage their knowledge of building JVM libraries.
  • Implement the same code-inlining behavior in Kotlin Multiplatform libraries as for the JVM.
  • Provide a tool that ensures that your multiplatform library public API hasn’t changed in an incompatible way.

We’re also going to improve the publishing process for KMP libraries. Specifically, we plan to:

  • Make it possible to build and publish a KMP library without having a Mac machine.
  • Provide templates and extensive guidelines for creating and publishing a KMP library.

Even though Kotlin Multiplatform is now stable, we’re planning significant updates. But don’t worry: Libraries built with the current format will still work with newer Kotlin versions.

코틀린 멀티플랫폼의 에코시스템이 빠르게 성장함에 따라 라이브러리들의 이전 버전과의 호환성이 중요해졌다. 호환성을 위해서 JetBrains 팀과 라이브러리 제작자들은 함께 일해야만한다. 아래는 우리의 계획이다. 

  • klib format 발전으로 라이브러리 크리에이터들이 그들의 JVM라이브러리 빌드 지식을 향상시킬 수 있다.
  • 코틀린 멀티플랫폼의 code-inlining 행동이 JVM에서의 행동과 동일하도록 구현한다. 
  • 멀티플랫폼 라이브러리의 퍼블릭 API들이 호환되지 않는 방향으로 변경되지 않게 하는 도구를 제공한다. 

우리는 또한 KMP라이브러리의 퍼플리싱 프로세스 향상할 것이다. 특히, 아래와 같은 계획이다. 

  • Mac 없이 KMP라이브러리를 빌드하고 배포할 수 있게 만든다.
  • KMP라이브러리를 생성하고, 배포하기 위한 템플릿과 광범위한 가이드라인을 제공한다. 

Read more

반응형
반응형

https://www.clien.net/service/board/cm_keyboard/15249685

 

이런 조건을 만족하는 블루투스 키보드 있을까요? : 클리앙

안녕하십니까, 데스크톱에는 리얼포스 R2 45g를 사용 중입니다. 키보드에 이돈을 쓰는게 맞나 고민 많이 했는데 키감도 너무 좋고 생긴것도 고급스럽고 (청색-회색 키캡) 거진 2년 가까이 타이핑

www.clien.net

 

위글의 댓글에 추천된 키보드들의 사양을 정리해본다. (내기준에서 중요하다고 생각하는 사양이다.)

제조사 이름 인터넷최저가 무게 키보드 방식 런타임 멀티페어링 비고
키크론 K3 124000 396g 적축 34h 3 모양이좀
newPhy f1 118500 350 적축 안나옴 안나옴 키배열구림
filco 마제스터치2 컨버터블 텐키리스 165000   적축   4 건전지써야함
한성 GK893B Sports  145000 830 무접점 100h 3  
앱코 KN01 BT 119000 840 무접점   3  
               
               

 

결국 무게때문에 키크론을 사야할듯하다.

반응형
반응형

심심해서 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으로 보내게된다.

반응형
반응형

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

원문.

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.

 

 

 

반응형
반응형

Iterator

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

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

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

Interface VS Abstract  (0) 2021.01.11
WAS의 동작방식  (0) 2021.01.11
JVM의 메모리 영역  (0) 2021.01.11
DB정규화  (0) 2021.01.11
MVC란?  (0) 2021.01.11
반응형

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의 목적은 메소드가 구현됨을 보장하는것이다.
반응형

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

이터레이터(Iterator)  (0) 2021.01.11
WAS의 동작방식  (0) 2021.01.11
JVM의 메모리 영역  (0) 2021.01.11
DB정규화  (0) 2021.01.11
MVC란?  (0) 2021.01.11
반응형

WAS의 동작방식

  • WAS

    • Web Server와는 다르게 DB조회 등 다양한 로직 처리를 요구하는 동적인 컨텐츠를 담당.
    • 웹 컨테이너, 혹은 서블릿 컨티에너라고 불림.
    • 분산 트랜잭션, 보안, 메시징, 스레드 처리 등의 기능을 처리하는 분산환경에서 사용
    • Tomcat, JBoss 등이 대표직인 WAS이다.
  • 동작 방식

    1. Web Server 의 클라이언트의 요청에 맞는 Servlet을 메모리에 올린다.
    2. web.xml에을 참조해 해당 Servlet에 대한 Thread를 생성한다.
    3. HttpServletRequest와 HttpServletResponse 객체를 생성하고 그에 맞는 doGet 또는 doPost 메소드를 호출해 생성된 동적 페이지를 Response 객체에 담아 WAS에 전달한다. ex) doGet(HttpServletRequest request, HttpServletResponse response)가 리턴하는 Response 객체를 WAS에 전달.
    4. WAS는 HttpResponse 형태로 바꾸어 WebServer에 전달하고 생성된 스레드와 HttpServletRequest, HttpServletResponse 객체를 제거한다.

    참고자료 : https://new-be.tistory.com/3

반응형

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

이터레이터(Iterator)  (0) 2021.01.11
Interface VS Abstract  (0) 2021.01.11
JVM의 메모리 영역  (0) 2021.01.11
DB정규화  (0) 2021.01.11
MVC란?  (0) 2021.01.11
반응형

JVM(Java)의 메모리 구조

JVM의 메모리 구조는 힙 메모리 / 비 힙메모리 / 기타 세가지로 나뉜다.

힙 메모리(Heap memory)

  • 힙영역은 자바 클래스의 인스턴스와 배열이 할당되는 영역
  • Run Time시 데이터를 저장.
  • JVM이 시작될때 생성되어 어플리케이션 실행동안 크기가 변동된다.
  • 힙영역의 크기는 -Xms VM option 으로 지정된다.
  • 힙영역의 크기는 가비지 컬렉션의 전략에따라 고정 / 변동 적으로 설정이 가능하다.
  • 힙영역의 퇴대크기는 Xms option으로 설정한다. 디폴트는 64MB이다.
  • 힙영역은 물리적으로 nursery(young space / young generation) 파트와 old space(old generation) 두 부분으로 나뉜다.
    • nursery : 새로운 객체 할당을 위해 확보된 공간. 이곳이 가득차면 young collection을 실행하여 가비지를 수집한다. young collection은 nursery에 어느정도 모문 객체를 old space로 이동시켜서 nursery에 더 많은 객체를 할당할 수 있도록 한다. 이런 가비지 컬렉션을 Minor GC라고한다.

비 힙 메모리(Non-Heap memory)

  • Heap과 마찬가지로 JVM시작시 생성된다.
  • 런타임 상수 풀, 필드 및 메소드 데이터같은 크래스별 구조와 메소드 및 생성자에 대한 코드, 나부 문자열이 저장된다.
  • 디폴트 크기는 64M, XX:MaxPermSize VM Option을 이용해서 변경 가능

기타 메모리

  • JVM 자체의 코드와 내부 구조, 로드된 프로피일러 에이전트 코드와 데이터 등을 저장하기 위해 사용.

침고 : https://shinjekim.github.io/java/2020/01/06/%EC%9E%90%EB%B0%94%EC%9D%98-%EB%A9%94%EB%AA%A8%EB%A6%AC-%EA%B5%AC%EC%A1%B0/

반응형

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

Interface VS Abstract  (0) 2021.01.11
WAS의 동작방식  (0) 2021.01.11
DB정규화  (0) 2021.01.11
MVC란?  (0) 2021.01.11
Java Collection framework interface의 특징  (0) 2021.01.11
반응형

DB 정규화

정규화란: 데이터를 저장할때 불필요한 데이터를 제거하고, CRUD시 발생할 수 있는 각종 사이드이팩틀르 방지한다.

1차 정규화 : 도메인 원자성을 확보 ( 한 컬럼이 하나의 값만을 가진다.)
2차 정규화 : 부분적 함수 종속 제거(즉, 완전 함수적 종속으로 만든다.)
3차 정규화 : 이행적 함수종속 제거 (즉, 키 이외의 다른 값이 다른 컬럼을 결정할 수 없다.)
BCNF: 모든 결정자가 후보키 집합에 속하게 만든다.

반응형

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

WAS의 동작방식  (0) 2021.01.11
JVM의 메모리 영역  (0) 2021.01.11
MVC란?  (0) 2021.01.11
Java Collection framework interface의 특징  (0) 2021.01.11
Error와 Exception  (0) 2021.01.10
반응형

MVC란?

MVC : Model, View, Controller

  • 어릎리케이션 / 프로젝트를 구성할때 구성요소를 모델 / 뷰 / 컨트롤러 세가지로 구분한 패턴.

    Model : 어플리케이션의 정보, 데이터를 나타냄. DATA / 정보의 가공을 책임지는 컴포넌트.

  • Model이 지켜야하는 규칙

    1. 사용자가 편집하길 원하는 모든 데이터를 가지고있어야한다.
    2. 뷰나 컨트롤러에 대해서 어떤 정보도 알 필요가없다.
    3. 변경이 일어나면 변경 통지에 대한 처리방법을 구현해야한다.

    View : 사용자와의 인터페이스를 담당하는 컴포넌트.

  • View가 지켜야하는 규칙

    1. 모델이 가진 정보를 따로 저장해서는 안된다.
    2. 모델이나 컨트롤러와 같이 다른 구성요소들을 알 필요가 없다.
    3. 변경이 일어나면 변경 통지에 대한 처리방법을 구현해야한다.

Controller: 모델과 뷰를 연결해주는 컨트롤러 역할

  • Controller가 지켜야하는 규칙
    1. 모델 / 뷰에 대해 알고있어야한다.
    2. 모델 / 뷰의 변경을 모니터링해야한다.

MVC 패턴의 장점

  • 각각의 역할을 정한 컴포넌트를 만들어 각각의 역할에 집중할 수 있도록한다.
  • 각각의 역할에 집중하고있기때문에 유지보수성 / 확장성 / 유연성이 증가한다.
반응형

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

JVM의 메모리 영역  (0) 2021.01.11
DB정규화  (0) 2021.01.11
Java Collection framework interface의 특징  (0) 2021.01.11
Error와 Exception  (0) 2021.01.10
REST API에 대해서  (0) 2021.01.10

+ Recent posts