lou@blog $ _

The Settings File 새 Gradle 프로젝트를 만드려면 프로젝트에 settings.gradle.kts를 추가해야한다. rootProject.name으로 프로젝트에 이름을 지정한다. rootProject.name = "my-project" dependencyResolutionManagement 에서 프로젝트의 모든 하위 프로젝트들에서 이용되는 Repository와 종속성을 구성한다. dependencyResolutionManagement { repositories { mavenCentral() ... } includeBuild("../my-other-project") } pluginManagement로 플러그인을 찾을 수 있는 위치를 지정한다. pluginManagement { reposito..

오류 분석 빌드가 project/build.gradle에 선언된 repository보다 settings.gradle에 선언된 repositories를 선호하도록 설정되어 있으나, 프로젝트단에서 "maven"이라는 repositories를 선언해버렸다는 의미이다. 오류 원인 내 settings.gradle.kts 파일에는 RepositoriesMode가 FAIL_ON_PROJECT_REPOS로 설정되어 있다. 이 RepositoriesMode는 3가지 종류가 있다. RepositoriesMode.PREFER_PROJECT: 기본 값, settings.gradle에 선언된 repositories를 무시하고, project단의 repositories를 참조한다. RepositoriesMode.FAIL_ON_P..

What’s Gradle? Gradle은 오픈소스 빌드 자동화 도구다. 그래서…풀네임은 “Gradle Build Tool”이다. 현재 JVM용으로 가장 널리 사용되는 빌드 시스템이며, Groovy라는 빌드 스크립트 언어를 제공한다. Gradle이 널리 쓰이기 이전엔 Maven이라는 빌드 도구가 있으나 확장성이나 성능적 측면에서 앞섰기 때문에 지금은 Gradle이 많이 채택되고 있다. Gradle의 이점을 공식 웹에서 조금 가져와 봤다. 풍부한 커뮤니티 플러그인 생태계 고도로 추상화된, 선언적이면서 읽고 쓰기 쉬운 빌드 로직 증분 빌드(Incremental Build), 빌드 캐싱, 병렬 실행을 통한 빌드 속도 향상 나도 build.gradle 파일만 열면 뭐가 뭔지 몰라서 복붙만하면서 빌드가 잘 되길 기..

오류발생 The request for this plugin could not be satisfied because the plugin is already on the classpath with an unknown version version catalog를 이용한 plugin 적용중에 "The request for this plugin could not be satisfied because the plugin is already on the classpath with an unknown version"라는 오류가 떴다. 당시 나의 plugins 블록은 다음과 같다. kapt를 추가하면서 문제가 발생했다. plugins { alias(libs.plugins.kotlin.android) alias(libs...

요구사항 앱 내 액션에 필요한 다이얼로그가 떠야해요. 하지만 유저가 클릭하지 않아도 서버가 푸시하면 앱의 어디서든, 언제든지 다이얼로그가 뜰 수 있어요. 튜토리얼을 할때는 튜토리얼용 다이얼로그를 제외한 모든 다이얼로그가 뜨지 않아야해요. 그리고 이 모든 다이얼로그들이 서로 꼬이지 않아야 해요. 다이얼로그를 한 두개 띄울때는 아무런 문제가 없었다. 하지만 요구사항에 따라 다이얼로그 추가되고, 이내 범벅이 되면서 다이얼로그 위에 다이얼로그가 떠버리거나 순서가 꼬여버려 좋지 않은 UX를 제공하게되는 결과를 야기했다. 아이디어 이것은 고등학교 급식 문제와 같다. 12시 종이 땡 치면 전교생이 우르르 급식을 먹으러오는 상황이다. 하지만 배식 라인(View)은 단 하나뿐! 3학년은 점심시간 중 자습시간이 있어 빨리..

docker 빌드 도중에 open /Users//.docker/buildx/current: permission denied 오류 메세지를 뱉으며 진행이 되지 않을 경우, Terminal에서 아래 Command를 실행하여 .docker 파일의 소유자를 현재 유저로 변경하면 된다. sudo chown -R $(whoami) ~/.docker

나도 확실하게 잘 다루는 서버 Framework를 하나 가지고 싶은데, 뭐로 할까 고민하다가 대중적이면서도 내가 현재 개발할때 익숙한 Java/Kotlin을 지원하는 Spring을 배워보자는 마음을 먹었다. "kotlin spring boot"이라고 검색하면 말은 느리지만 손은 빠른 아저씨의 유튜브 강의 시리즈가 나오는데, 이걸 보고 공부하고 있다. 이제...10강!까지들었다. 아직 찍먹한지 겨우 이틀되었지만 까먹기 전에, Spring에 관해 알아낸 것들을 간략히 정리 해 보겠다. Spring Framework vs Spring Boot https://spring.io/projects 에 가면 여러가지 Spring "프로젝트"라고 불리는 것들이 보인다. 이것은 Spring이라는 Framework에 속하거..

들어가며 이 글은 https://www.gabrielgambetta.com/lag-compensation.html의 글을 공부하면서 옮긴 것으로, 번역과 의역이 섞여있습니다. 이전 3편에 걸친 글에서 다룬 클라이언트 - 서버 아키텍쳐에대한 설명은 다음과 같이 요약할 수 있습니다. 서버는 모든 클라이언트에서 타임스탬프와 함께 입력을 받습니다. 서버는 입력을 처리하고 월드 상태를 업데이트 합니다. 서버는 모든 클라이언트에게 정기적으로 월드 스냅샷을 전송합니다. 클라이언트는 입력을 전송하고 로컬에서 그것을 시뮬레이션 합니다. 클라이언트는 월드를 업데이트 받고 로컬에서 예측한 상태를 서버에서 받은 상태와 동기화 합니다. 다른 엔티티의 과거 상태를 보간합니다. 플레이어의 관점에서 이것은 2가지 중요한 결과를 가져..

들어가며 이 글은 https://www.gabrielgambetta.com/entity-interpolation.html의 글을 공부하면서 옮긴 것으로, 번역과 의역이 섞여있습니다. 이번에는 동일한 서버에서 다른 플레이어가 컨트롤하는 캐릭터에 대해서 탐구해보겠습니다. 서버 타임 스텝(Server time step) 이전 글에서 서버의 동작은 비교적 간단했습니다. 클라이언트가 주는 입력을 받아서 게임 상태를 업데이트하고 다시 돌려주면 되었죠. 하지만 여러 클라이언트가 연결된 경우, 메인 서버 루프는 다소 달라집니다. 이 시나리오에서는 여러 클라이언트가 동시에, 그리고 빠른 속도로 연이어 입력을 보낼 수 있습니다. 모든 클라이언트에서 입력이 수신될 때마다 게임 월드를 업데이트하고 게임 상태를 브로드캐스트 하..

들어가며 이 글은 https://www.gabrielgambetta.com/client-side-prediction-server-reconciliation.html 글을 공부하면서 옮긴 것으로, 번역과 의역이 섞여있습니다. 이전 글에서는 권위 있는 서버와 입력만 서버로 보내고 서버가 업데이트된 게임 상태를 보낼 때까지 렌더링하는 멍청한 클라이언트를 가진 클라이언트-서버 모델을 알아보았습니다. 그러나 이런 시스템을 그냥 구현하게 되면 사용자 입력과 화면 변경 사이에 지연이 발생하게 됩니다. 예를 들어, 플레이어가 오른쪽 화살표 키를 누르면 캐릭터가 움직이기 시작하기 전에 0.5초 정도의 시간이 걸립니다. 이는 클라이언트 입력이 먼저 서버로 이동하고, 서버가 입력을 처리하고 새로운 상태를 계산하며, 업데이트..