최근 자바 개발에서 코틀린으로 넘어오시는 분들을 많이 볼 수 있습니다. 저 역시도 19년 첫 회사에 취업하여 자바로 안드로이드를 개발하다 20년부터는 코틀린으로 개발을 시작하였습니다. 이 글을 읽는 여러분들은 자바에서 코틀린으로 마이그레이션을 고민 중 이시거나 혹은 코틀린에 대한 공부를 원하시는 분들이라 생각됩니다. 그런 분들을 위한 도서. 자바에서 코틀린으로: 코틀린으로 리팩터링하기 도서를 읽고 리뷰를 해보도록 하겠습니다. 본 도서는 한빛미디어 활동을 위해서 책을 제공받아 작성된 서평입니다. 시작하기 앞서 코틀린은 먼 미래가 아닙니다. 코틀린은 Stack Overflow 2022 survey 기준으로 가장 인기 있는 언어(Most popuplar technogoies) 15위, 가장 사랑/원하는 언어(..

Compose Web에 Skiko를 입히니 기존 Compose 로직 그대로 Web에서도 UI를 그릴 수 있네요. Canvas에 그려지는 형태이기에 SEO는 불가능할 것 같아 아쉽지만 차후 Flutter SEO 라이브러리처럼 구현된다면... 이번 발견(?)으로 이제 정말 Flutter처럼 Compose 단일 UI 코드로 AOS, iOS, Desktop(Windows, Linux), Web 모두 구현이 가능할 것 같습니다. 물론 아직 Web에서 몇 가지 테스트를 해보니 몇몇 인터렉션이 작동되지 않기에 수 작업으로 연결이 필요하는 등 stable 한 것 같지는 않기에 정식 product 사용은 어려워 보이긴 하지만 언젠가 정말 stable 하게 출시된다면 Compose로 세계 대통합을 할 수 있지 않을까.....

multi-module 방식으로 대대적인 리팩토링을 진행하였습니다. 물론 로직 자체는 방대하지 않기에 대대적이라고 표현할 정도는 아니긴 하지만, 결과적으로는 패키지를 모두 뜯어 고쳤습니다. 기존 고안은 Ktor server, client에서 사용되는 공통 request, response 모델을 common-data 패키지에 두고 이를 server, plugin에서 사용하는 방식으로 구상하였습니다. 이를 통해 모델이 중복 생성되는 일종의 보일러플레이트를 방지할 것이라 생각하였습니다. 안드로이드 개발하면서 멀티모듈로 분리하는 것은 매번 하던 것이기에 별다른 걱정을 하지 않았으나 각 플랫폼에서 타 모듈을 인식하지 못하는 이슈가 발생하여 끙끙 고생하다 알게 된 사실은, 기존 백엔드와 플러그인 프로젝트를 생성할 ..

개발하다 보니 자주 사용하는 네이밍과 사용자 수 같은 통계 및 Exception 발생 시 해결을 위해 로깅을 하면 좋겠다는 생각에 DB를 함께 구축하고 있습니다. 간단하게 2, 3일 개발하고 출시하려고 하였는데 점점 욕심이 생겨 무언가 추가되는 것 같네요. DB 관련하여 Ktorm과 Exposed 둘 중 어떤 것을 사용할지 많이 고민하였습니다. 사실 두 라이브러리 모두 유사한 구조(?)를 지니고 있기에 차후 라이브러리를 바꾼다하더라도 러닝커브가 크지 않을 것 같기도 하고, libhunt 기준 Exposed가 Ktorm 보다 많은 인기를 지니고 있기에 Exposed를 택하였습니다. (물론 그 외의 이유들도 있지만, 밥이 다 되었기에 자세한 설명은 생략하고 차후 기회가 된다면 풀어보겠습니다.) 사실 해커톤 ..

개발자의 최대 난제 변수/함수 이름 짓는 플러그인을 만들고 있습니다. Ktor server를 통해 백엔드를 구축하고 Ktor client를 통해 플러그인 내에서 백엔드와의 통신을 진행, 즉 클라이언트/서버 모두 Ktor로 구현되었습니다. 이전부터 IDE 플러그인을 만들어보고 싶었는데 문득 떠올라 재밌게 만들고 있네요. 안정성을 보완하고 바로 JetBrains Marketplace에 업로드 및 VS Code로도 구현할 예정입니다.