ApplicationContext 초기화 중에 CommandLineRunner와 ApplicationRunner 인터페이스를 구현한 빈들이 등록됨
이 빈들은 애플리캐이션 초기화가 완료된 후 추가 작업을 실행할 수 있음.
6.자동설정(Auto Configuration)
Spring Boot는 @EnableAutoConfiguration을 통해 여러 자동 설정 클래스(AutoConfiguration)을 활성화함.
자동 설정은 클래스 패스 및 환경 변수를 기반으로 애플리케이션에 필요한 빈을 자동으로 구성함.
Ex) DB Connection 설정, Web server 설정, Spring Security 설정 등
7.빈(Bean) 등록 및 DI(의존성 주입)
스프링 애플리캐이션 컨텍스트 내에서 모등 @Component, @Service. @Repository, @Controller 등의 빈을 스캔하여 등록
등록된 빈들 간의 의존성을 주입(생성자, 세터, 필드 기반)
프로파일 조건에 따라 특정 빈만 활성화될 수도 있음.
8.내장 웹서버 시작(Optional)
웹 어플리케이션인 경우, Spring Boot는 내장된 톰캣, 제티, 언더토우 등을 통해 HTTP서버를 시작
HTTP 포트, SSL설정 등이 적용됨.
서블릿 컨테이너가 초기화 되고 DispatcherSErvlet이 설정됨.
9.Spring MVC 또는 WebFlux 설정(웹 애플리케이션인경우)
DispatcherServlet을 통해 요청을 처리하는 기본 매핑을 설정
HandlerMapping,HandlerAdapter,ViewReolver등을 초기화 하여 웹 요청에 필요한 구성요소를 준비
10.이밴트 발행 및 리스너 실행
Spring Boot는 애플리케이션 실행 과정에서 여러 이벤트를 발행함.
ApplicationStartingEvent
ApplicationEnvironmentPreparedEvent
ApplicationPreparedEvent
ApplicationStartedEvent
ApplicationReadyEvent
위 이벤트를 통해 특정 시점에 사용자 정의 작업을 실행할 수 있음.
11.애플리케이션 준비 완료
애플리케이션 컨택스트 초기화가 완료되고, 모든 빈이 생성되고 초기화됨
CommandLineRunner 및 ApplicationRunner구현체가 실행됨.
ApplicationReadyEvent 가 발행되며 애플리케이션이 요청을 처리할 준비가 완료됨
12.애플리케이션 실행 상태 유지
Spring Boot는 실행 상태를 유지하며 HTTP요청을 대기하거나 비웹 애플리케이션에서는 작업을 지속함.
내부적으로 애플리케이션 컨택스트는 필요에 따라 라이프 사이클을 관리함.
13.애플리케이션 종료
애플리캐이션 종료시 Spring Boot는 ApplicationContext를 닫으며 빈의 destroy() 메서드 호출 및 리소스 정리를 수행
ApplicationFailedEvent 가 발행될 경우 애플리케이션 시패를 기록
Spring Boot Application으 LifeCycle에 대해 간략하게 정리 해 보았다. Spring 기반의 서비스를 운영 / 개발 하는 회사라면 자주 나오는 질문이니 숙지하고 있으면 좋다. 세부 내용까지는 힘들더라도 1~12번 넘버링 되어있는 순서만이라도 기억하면 좋다.
With the recently achievedstability 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도구와 라이브러리 같은 미래의 발전을 주도할것이다. 이 분야에서 무엇을 배워야하고, 어떤 순서로 배뭐야할지 알아보자.
We’re dedicated to makingCompose Multiplatforma framework that allows creating beautiful and performant applications that look the same way on all supported platforms. Right now, our main focus is to getCompose 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 aboutusing 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변경을 제거한다는 의미입니다.
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 adirect 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 releasedhuge improvementsin the Gradle Multiplatform DSL, making it easier to read and write. We will continue to gradually improve it. In addition, we’re experimenting withAmper, 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이다.
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라이브러리의 퍼플리싱 프로세스 향상할 것이다. 특히, 아래와 같은 계획이다.
문서화, 모든 개발자의 숙제이다. 필요한 이유는 알고있지만 하기 싫고 귀찮은 작업 중하나이다. 소프트웨어 개발 산출물 중 하나이기도 하고 다른 개발자 혹은 미래의 자신을 위해서 필요한 작업이기도하다.
필요성을 인지하고 있기때문에 모두 작성을 하려고하긴 하지만 어떻게 작성해야하는지를 잘 모른다. 책의 서두에도 나오는 '지식의 저주' 때문에 '이런것은 이미 알고있겠지' 혹은 '이렇게 자세히 쓰면 아무도 안읽을거야' 같은 생각을 하게된다.
사실 이책의 내용의 대부분은 이미 알고 있는 이야기였다. 그럼에도 이 책은 나에게 도움이 되었다. 왜냐면 "왜?"에 대한 답을 주기 때문이다. 문서화를 하다가 동료팀원에게 보완점을 이야기 했을때 "왜 그렇게 해야하죠?" 라는 말에 대답을 못하는 경우가 있다. 왜냐면 내 기준에선 당연한 이야기 이기 때문이다. 물론 '당연히 그렇게 해야죠'라는 말을 하면 싸움밖에 안날것이기때문에 당황하는 경우가 있었는데 이 책은 왜 그렇게 해야하는지에대해 알려주기 때문에 속이 시원해지는 경험을 했다.
이미 알고는 있지만 왜인지 몰랐던 문서에 대한 이야기들은 큰 도움이 되었다. 물론 내가 몰랐던 이야기들도 있었고, 문서화 방향에 대한 가이드이기 때문에 큰 도움이 되었다.
내용이 어렵지도 않고 술술 잘 읽히니 시간이 날때 카페에서 커피 한잔과 함께 가볍게 읽어보면 좋은 책이다.
AWS가 처음 나왔을때를 생각 해 본다. 온프레미스 서버의 연장선이다. 아니다, 이건 혁신이다. 이렇게 두가지로 이야기가 나뉘었던거같다. 훅자의 의견을 가진 개발자들은 앞다투어 AWS를 공부했고, 활용했다. AWS는 혁신이었다. 그들이 제공해주는 서비스는 개발에만 집중 할 수 있게 만들어 주었고, 버튼 몇번으로 인스턴스가 늘어나고, 프로토타이핑한 코드를 바로 운영서버에 적용시켜보고, 등등 여러가지 일을 할 수 있게 해줬다. 아이러니하게도 이런 AWS의 유용한 기능 덕분에 개발자는 AWS를 공부 할 필요가 없어지게 되었다. 너무 유용하고 다양한 기능을 제공해 주었고, 그 다양하고 유용한 기능들을 잘 활용하기 위해서는 전문가가 필요해졌기 때문이다. 개발자는 더이상 AWS를 공부 할 필요가 없어졌고, AWS는 DEVOPS 엔지니어, 인프라스트럭처 엔지니어같은 전문가들의 영역이 되었다.
그런데 정말 개발자는 더이상 AWS를 공부 할 필요가 없어졌을까? 아니다. 개발자는 AWS가 제공해주는 서비스를 어떻게 설정하는지, 정책을 어떻게 잡아야하는지 등의 세부사항은 알 필요가 없어졌지만 그래도 어떤기능을 제공하는지, 어떤 정책을 적용할 수 있는지 는 여전히 알고 있어야한다. 결국 시스템을 설계하고 운영하는것은 개발자의 일이기 때문이다. 내가 만들서비스의 특성에 따라 AWS가 제공해주는 기능을 효율적으로 사용하려면 결국 어떤 기능을 제공 해 주는지, 그 한계는 무엇인지 정도는 명확히 알고 있어야한다. 물론 설정은 전문가가 해주겠지만 말이다. 그런 점에서 업무에 바로 쓰는 AWS 입문은 개발자가 AWS를 공부할때 매우 적절한 도서이다. AWS가 제공 해 주는 기능들에 대한 설명도 충분히 들어있고, 직접 사용 해 보면서 장/단점에 대해서도 알려준다. 일단 이 책을 읽어보게된다면 AWS를 사용하는 시스템을 설계할 때 효율적이고, 수월하게 설계를 할 수 있을것이다.
국내에는 많은 AWS관련 서적이 나와있다. 대부분 내용은 대동소이하며 꼭 필요하고 중요한 내용으로 가득 차있다. 솔직한 말로 서점에서 AWS로 검색한 후 아무 책이나 보더라도 AWS를 공부하는 내용에서는 큰 차이가 없을것이다. 그럼에도 불구하고 '업무에 바로 쓰는 AWS입문'을 추천하는 이유가 있다. AWS는 매우 빠른 배포주기를 가지고 많은 업데이트가 일어나는 서비스이다. 때문에 이왕 공부하기 위해선 가급적 최근에 출판된 책을 이용하는것이 유리하다. 또한, 대부분 AWS책은 실습을 도와주기 위한 service UI 캡처 화면이 제공되는데 이 UI도 제법 자주 변경되기 때문에 실습을 따라하는 입장에서 최근에 출판된 도서가 훨씬 편하다.
Kotlin에서 Class는 객체지향 프로그래밍의 기본 요소입니다. Class는 데이터와 이를 다루는 함수들을 묶어서 캡슐화하고, 관련 있는 메서드와 속성을 함께 묶어서 구성합니다. 또한, Class를 통해 생성된 객체는 인스턴스라고 하며, 객체는 독립적인 메모리 공간을 가지고 있어서 서로 영향을 주지 않습니다.
Kotlin에서 Class를 선언할 때는 "class" 키워드를 사용합니다. 아래는 Kotlin에서 Class를 선언하는 예시입니다.
class Person {
var name: String = ""
var age: Int = 0
fun sayHello() {
println("Hello, my name is $name and I'm $age years old.")
}
}
위 예시에서는 "Person"이라는 Class를 선언했으며, Class 내부에는 "name"과 "age"라는 변수와 "sayHello()"라는 함수가 포함되어 있습니다.
Class를 사용하면 코드의 재사용성이 높아지고, 유지보수가 용이해집니다. 또한, 객체지향 프로그래밍에서는 상속을 통해 기존 Class를 확장할 수 있으므로 코드의 재활용성이 더욱 높아집니다.
Kotlin에서는 Class를 선언할 때 추가적으로 상속을 지정할 수 있습니다. 상속을 위해서는 콜론 ":"을 사용하며, 상속할 부모 Class를 지정합니다. 예를 들어, 아래와 같이 Person Class를 상속받는 Student Class를 선언할 수 있습니다.
class Student : Person() {
var grade: Int = 0
var major: String = ""
fun introduce() {
println("I'm a student, my grade is $grade and my major is $major.")
}
}
위 예시에서는 Person Class를 상속받는 Student Class를 선언했습니다. Student Class 내부에는 "grade"와 "major"라는 변수와 "introduce()"라는 함수가 추가되어 있습니다.
최근 개발 기초 공부를 다시 하려던 와중에 눈에 띈 책이었습니다. 특히 코딩테스트 연습을 하면 '아는건데 기억이안난다' 라던가 ' 이걸 해결해주는 알고리즘이 있었는데 뭐였더라?' 하는 경우가 많았는데 이책을 통해서 극복 해 볼 수 있을까 해서 책을 선택하게 되었습니다.
결론부터 말하자면 어느정도 극복 되었습니다. 보통 알고리즘이라고 하면 떠오르는 정렬 부터 시작해서 콜렉션, 트리, 그래프 등 알고리즘들으 잘 아루르면서 설명 해 주고 있습니다. 다만 책의 대상독자에게도 말하듯이 처음 알고리즘을 접하시는 분들보단 CS지식이 어느정도 있고 자료구조에서 알고리즘 맛보기정도는 해보신 분들에게 추천드립니다.
알고리즘을 설명하면서 거기에 필요한 자료구조도 어느정도 알려주고 있어서 책을 읽을때 굳이 다른 자료를 찾아볼 필요가 없던것도 장점이었습니다.
책의 예제코드가 파이썬으로 되어있는데, 파이썬에 익숙하지 않은 저로서는 조금 어려울 뻔 했으나 라인바이라인으로 설명을 잘 해주고있어서 무리 없이 넘어갈 수 있었습니다. 다만 파이썬 코드에 익숙하신 분들이라면 훨씬 더 이해가 쉬웠을거라는 생각이 드네요.
코팅테스트 준비 혹은 저처럼 기본 공부를 한번 더 해야겠다는 생각을 하신 분들에게 추천드릴만한 책입니다.
TLDR; 구관이 명관이다. 디자인 패턴 책 중에 이 책이 최고인지는 모르겠지만 상위권에 속하는 책임을 확신한다.
헤드퍼스트 디자인패턴. 개발자(혹은 개발자를 지망하는사람)치고 이 책을 모르는 사람이 있을까 싶다. 나 역시 '디자인패턴' 이라는 키워드를 안 이후에 여러 검색과정을 거처서 '헤드퍼스트 디자인패턴'을 구매하고 읽었다. 그게 벌서 10년전 정도이다. 한빛미디어의 나는 리뷰어다 도서중 헤드퍼스트 디자인패턴 개정판이 나왔을때 나는 망설임 없이 바로 신청했다.
안그래도 디자인패턴 복습을 좀 하고싶었는데 개정판이 나왔다니. 선택을 안할 수 없었다. 내용은 워낙 탄탄하니 말할것도 없긴 하지만 도서 리뷰이다보니 잠시 언급 해 보자면 가장 기본적이고 단순한 패턴부터 시작해서 실무에서 많이 사용하는 패턴으로 점진적으로 나아가는 방식이다. 개발을 좀 해봤다면 초반부분의 패턴들의 예제에서 이상함(비효율성)을 느끼게 되는데 그부분들은 후반에 나오는 패턴에서 개선 할 것이라는 언급이 있기때문에 독자로 하여금 불안함을 생기지 않도록 해 준다.
이번에 책을 다시 읽으면서 가장 좋았던점은 이전 버전의 단점이 보완되었단 점이다. 이전 버전의 경우 책의 구성이 좀 번잡하다는 생각이 들어서 집중하기 약간 어렵단 생각이 들었었다. 물론, 대화형 으로 풀어나간다던가 내용에 나오는 화살표 설명(?) 들이 설명에 많은 도움이 되긴 하지만 당시엔 너무 번잡하다는 생각을 지울 수 없었다. 하지만 이번 개정판에서는 훨씬 정갈하고, 분리된상태로 편집이 되어 있어서 책을 읽는데 집중을 하기가 좋았다. 헤드퍼스트 특유의 설명방식을 잘 살리면서 깔끕하게 정리를 해 준 덕분에 내용상의 차이는 크게 없지만, 훨씬 읽기 좋고 이해하기 좋은 책이 되었다.
디자인 패턴을 처음 공부하기 위한사람이나, 나처럼 복습하기위한 사람 모두에게 아주 추천할만한 책이다.
