개발자 강경완

[Google I/O 2024] 확장가능한 Compose API 설계 가이드

루카스강 — Sat, 29 Jun 2024 16:30:05 +0900

이 문서는 Google I/O 2024 에서 발표된 Designing scalable Compose APIs (https://www.youtube.com/watch?v=JvbyGcqdWBA) 의 내용을 정리한 것입니다. 원 내용은 위 링크에서 확인하실 수 있고 아래 내용은 좋은 내용을 더 많은 사람들이 접할 수 있도록 발표 내용을 한국어로 번역하였습니다.

서론

Jetpack Compose의 기본 구성요소는 Composable 함수입니다. UI를 구축할 때 많은 양의 함수를 작성하게 되며, 이 함수들은 다른 함수들을 호출합니다. 따라서 우리는 자연스럽게 API 개발자가 되며, 큰 앱을 개발하든, 외부 라이브러리를 개발하든 고품질 Compose 코드를 작성하기 위한 가이드라인을 설정하는 것이 중요합니다.

이렇게 하면 최소한의 수정으로 발전하기 쉽게 하고, Compose 생태계 전반에서 일관성을 유지하며, 직관적이고 알려진 패턴을 따르며, 다른 사람들을 올바른 설계 방향으로 안내함으로써 더 좋은 설계를 장려할 수 있습니다.

Scalable (확장 가능)
Consistent (일관성 유지)
Guides others (다른 사람을 위한 가이드라인 제공)

전형적인 Compose API를 개발하기 위한 모범 사례와 가이드라인을 다루겠습니다.

Think and Plan (새로운 API를 구상하고 계획하기)

Designing scalable Compose APIs 중

새로운 Composable 함수를 만들때는 해당 API 가 단일 문제를 해결하는지 확인해야 합니다.

예를 들어 사용자가 제한된 선택항목들 사이에서 간결하게 옵션을 선택하도록 하는 컴포넌트가 필요하다고 가정해 봅시다. 이 문제를 해결하기 위해서 FilterChip 컴포넌트를 생각해 볼 수 있습니다.

특정 usecase를 기반으로 API를 작성할 경우 이토록 쉽고 명확하게 문제를 해결할 수 있습니다.

만약 다른 제안이나, 빠른 작업 등 추가적인 기능이 필요하다면, 이러한 기능은 별도의 컴포넌트로 분리하는 것이 좋습니다. 이는 더 많은 사용자 정의 옵션을 제공하며, API를 보다 명확하게 유지할 수 있습니다.

유사한 UI를 가지고 있지만, 다른 용도를 가진 FilterChip 이 필요하다면 어떻게 접근할 수 있을까요?

사용자가 FilterChip을 완전히 변경할 수 있도록 더 많은 사용자 정의 옵션을 만들 수가 있을 것입니다.

또는 이를 완전히 별개의 구성요소로 만들 수 있을 것입니다.

상위 수준의 API와 하위 수준의 API

앱 디자인 설계에 대해서는 의견이 분분하지만, 다소 유사한 구성요소, 변형에 대한 일관된 요구 사항을 가지고 있다면, 새로운 구성 요소를 계층적으로 상위 수준의 API로 구축하는 것이 좋습니다.

상위 수준의 API에서는 더 제한적이고, 특정 동작과 기본값을 제공하고, custom 옵션을 적게 제공합니다.

하위 수준의 API 에서는 모든 계층에 대한 기대치와, common surface를 정의합니다. 또한 사용자 정의에 대해 더 개방적이어야 합니다.

이는 하위 수준 API에서 상위 수준 API로 이동할 때 해당 컴포넌트의 자기주장이 강해지고, 사용자 정의 옵션은 적게 제공하는 것을 의미합니다.

계층화 결정은 설계 요구사항과 밀접하게 연관이 있으므로 현명하게 선택을 해야 합니다.

새로운 컴포넌트 또는 기존 컴포넌트의 결합

ChipGroup 같은 컴포넌트를 생각해 봅시다. ChipGroup 은 가로 또는 세로 방향으로 칩을 재배열하고, 추가 스타일을 적용합니다.

칩을 수직 또는 수평으로 배열하는 것은 기존의 Column 및 Row로 쉽게 달성할 수 있습니다. 스타일링은 Modifier와 데코레이션을 적용하여 처리할 수 있습니다. 따라서 ChipGroup API에서 나오는 맞춤 동작은 없습니다.

이는 새로운 API가 필요하지 않다는 좋은 신호입니다.

새로운 API는 그 존재를 정당화해야 합니다. 새로운 API를 만들고 유지하고, 사용하는 방법을 배우는 데는 작업이 필요합니다. 새로운 컴포넌트를 만드는 것과 기존의 컴포넌트에 위임하는 것 사이에서 적절히 선택하세요.

명명 규칙 (Naming Conventions)

Composable 함수의 명명 규칙

Designing scalable Compose APIs 중 Composable function naming conventions

Composable 함수는 PascalCase로 명명되며, 함수가 단위를 반환하는 경우에는 명사로 명명됩니다.

기본적으로 단위를 반환하기 때문에 클래스 명명규칙을 따릅니다. 이는 요소가 재구성되더라도 일관된 정체성을 유지하도록 돕고, Compose의 선언적 모델을 강화합니다.

값을 반환하는 Composable 함수는 소문자로 시작하는 Kotlin 표준 함수 명명 규칙을 따릅니다. 내부적으로 remember를 사용하여 가변 객체를 반환하는 Composable 함수는 그 특성을 명확히 나타내기 위해 remember로 접두사를 붙여야 합니다.

접두사가 없는 컴포넌트는 기본적으로 장식된 상태로 바로 사용 가능한 기본 컴포넌트를 나타낼 수 있습니다.

Basic 접두사를 통해 더 많은 wrapping 이 가능할 것을, API를 그대로 사용할 것을 예상할 수 있도록 사용해 보세요.

한 수준 위 계층으로는 FilterChip, InputChip과 같은 독창적인 API 로더 많은 스타일 변형이 있음을 나타냅니다.

일반적인 회사 이름이나 모듈이름, 또는 기능을 접두사로 사용하는 것은 지양하세요.

composition 은 특정 컴포넌트 하위 트리에 범위가 지정된 글로벌과 같은 값을 제공합니다.

이를 알리기 위해 설명이 포함된 Local을 접두사로 사용하세요.

매개변수 설계 (Designing Parameters)

명확하고 설명적인 매개변수

API의 매개변수는 명확하고 설명적이어야 합니다. 명확한 매개변수는 API를 쉽게 이해하고 사용할 수 있게 하며, 설명적인 입력은 API를 처음부터 읽기 쉽게 하고 사용자가 한눈에 이해할 수 있게 합니다.

컴포지션 로컬 또는 implicit input (절대적인 인풋), 암시적이고 모호한 입력은 최대한 피해야 합니다. 추적이 어려워집니다.

val LocalChipBorder = compositionLocalOf<...>(...)

@Composable
fun Chip(...) {
   val border = LocalChipBorder.current
}

대신 API를 열고 명시적인 매개변수를 사용하면 사용자가 정의 레이어를 쉽게 추가할 수 있습니다.

@Composable
fun Chip(
   border: BorderStroke,
) {
   // Set border
}

수정자 (Modifiers)

Compose에서 수정자는 중요한 역할을 합니다.

Compose 사용자는 이미 Modifier를 사용하는 방법에 대한 기대치를 가지고 있습니다. 따라서 모든 UI 구성요소는 매개변수로 Modifier 유형을 가져야 합니다.

이는 첫 번째 선택적 매개변수이므로 이름 매개변수 없이 설정할 수 있어야 하며, 일관된 위치를 가져야 합니다. (First optional param)

기본 no-op 값을 가지고 있으므로 사용자가 기존 체인에 추가된 자체 수정자를 제공할 때 기능이 손실되지 않으며, 단일 구성요소에 하나의 Modifier 매개변수를 가져야합니다. (Only Modifier type param)

여러 개의 Modifier가 필요할 경우 API를 다시 설계해야 할 신호일 수 있습니다. 수정자는 컴포넌트의 루트 최외곽 레이아웃에 한 번만 적용되어야 합니다. (Applied once to root)

@Composable
fun Chip(
   modifier: Modifier,
) {
    RootLayout(
        modifier = modifier,
    )
}

명확한 매개변수와 Modifier 활용

Modifier가 컴포저블의 동작과 외관을 설명하는 반면, 명확한 매개변수는 API의 주요 목적을 나타내는 핵심 부분입니다. 모든 API는 그 동작과 UI를 나타내는 핵심 부분을 명확한 매개변수로 설정해야 합니다.

Modifier로 커스터마이징 할 수 없는 동작이나 장식을 추가해야 하는 경우 명확한 매개변수로 설정되어야 합니다. (반면, 핵심이 아닌 경우 Modifier를 통해 수정할 수 있습니다.)

매개변수의 순서

매개변수의 순서를 정할 때는 API의 가독성과 사용 편의성을 위해 신중하게 고려해야 합니다.

다음은 사용자가 API의 목적과 커스터마이제이션 옵션을 이해하는 데 도움이 되는 지침입니다.

1. 필수 매개변수: API의 주요 목적을 나타내며, 기본값이 없고 이름 매개변수 없이 사용할 수 있어야 합니다.

2. Modifier : API를 커스터마이징하고 Compose 기대에 맞춥니다.

3. 선택적 매개변수: 기본값을 가지며, 사용자가 필요에 따라 재정의할 수 있습니다. 의미상 유사한 매개변수는 그룹화하여 함께 둘 수 있습니다.

4. 후행 composable content 람다 : 중첩된 slot content 가 있을 경우 마지막에 위치시킵니다.

@Composable
fun Chip(
   // 필수 매개변수, 기본값이 없음.
   onClick: () -> Unit,
   label: @Composable () -> Unit,
   // Modifier
   modifier: Modifier,
   // 선택적 매개변수, 그룹화 시키기
   enable: Boolean = true,
   icon: @Composable (()->Unit)? = null,
   shape: Shape = ChipDefaults...,
   colors: ChipColors = ChipDefaults...,
   // 후행 Composable lambda
   content: @Composable () -> Unit,
) {
    RootLayout(
        modifier = modifier,
    )
}

기본 매개변수 값과 null 가능성

기본 매개변수 값을 사용하여 빈 값을 알리는 것은 API 설명에 의미를 부여합니다.

Nullbale (null 가능성) : 이 API 기능이 사용 가능하지만, 특정 사용 사례에서는 필요하지 않을 수 있음을 암시 (Feature not required)
Empty (빈 값) : 이 기능은 필수이며, 빈 값으로 사용할 수 있거나, 특정 사용 사례에 따라 더 구체적인 값으로 재정의 할 수 있음을 암시 (Requried but can be empty / overriden)
Default (기본값) : Null 이 아니고, 의미가 있어야 하며, 사용자에게 명확해야 합니다. 공개적으로 사용 가능해야 하며, 구성 요소가 어디에서나 동일한 일관된 결과를 제공해야 합니다.

위 값들의 차이를 이해하고 신중하게 선택하세요.

@Composable
fun Chip(
   // nullable : 없을 수 있음
   icon: @Composable (() -> Unit)? = null,
   // Empty : 필수, 재정의 가능
   content: @Composable () -> Unit = {},
   // Default
   enable: Boolean = true,
   shape: Shape = ChipDefaults.shape,
   colors: ChipColors = ChipDefaults.colors(),
)

스타일링 및 커스터마이제이션

API의 일부 매개변수는 스타일링 및 커스터마이제이션 옵션을 타겟으로 합니다. 이러한 매개변수에는 기본값을 제공하여 API가 독립적이고 그대로 사용할 수 있도록 하는 것이 좋습니다.

기본 스타일링 값이 짧고 예측 가능한 경우, 단순한 인라인 상수로 유지하는 것이 충분할 수 있습니다.

enable: Boolean = true,
elevation: Dp = 8.dp

그러나 칩과 같은 일부 API는 많은 커스터마이제이션 (활성화, 비활성화, 선택상태 등을 포함한), 다른 모양, 색상, 테두리 등을 가질 수 있습니다. 이러한 경우 기본값 객체를 외부에서 단일 장소에 매핑하는 것을 고려하십시오.

이러한 객체는 공개적으로 사용 가능해야 하며, 컴포넌트가 어디서나 사용될 수 있도록 해야 합니다. 스타일링은 선택된 상태에 따라 다른 배경색을 설정하는 칩과 같이 조건부로 설정될 수 있습니다. 이러한 조건을 처리하는 것은 기본값 객체에 위임할 수 있습니다.

shape: Shape = ChipDefaults.shape,
colors: ChipColors = ChipDefaults.colors(),
border: BorderStroke? = ChipDefaults.border(enabled)

// Publicly avaialbe
object ChipDefaults {
  val shape: Shape ...
}

슬롯 매개변수

Compose에서 슬롯 매개변수는 부모 컴포넌트 내부의 열린 공간을 지정하여 자식 컴포넌트로 채우는 composable lambda 매개변수입니다.

예를 들어 Chip 컴포넌트의 경우, 사용자가 텍스트, 이미지, 아이콘 또는 다른 콘텐츠를 삽입할 수 있도록 하고 싶습니다.

slot api를 하나만 가질 경우, 마지막 콘텐츠 매개변수로 배치하여 일관성을 유지하고 후행 람다로 사용할 수 있게 합니다.

여러 slot api가 필요한 경우, 해당 유형의 여러 매개변수를 named param으로 제공할 수 있습니다. (아이콘 또는 라벨)

슬롯을 사용하면 Chip은 전달된 중첩된 content가 무엇인지 상관하지 않습니다. 대신 주된 책임인 선택 처리, 클릭 처리 등에 집중하여 사용자에게 더 많은 유연성을 제공합니다.

상태 관리 (State Management)

컴포넌트는 내부 및 외부에서 발생하는 변경사항을 처리하기 위해 상태가 필요합니다. 예를 들어 Chip 컴포넌트는 활성 및 비활성 상태를 가지며, 이는 자주 변경되며 UI에 영향을 미칩니다.

Composable 함수에서 상태를 관리하는 방법에는 두 가지가 있습니다:

1. 상태를 소유하고 관리하는 방식 (Stateful): 함수가 자신의 상태를 관리하며, remember나 mutableStateOf를 사용합니다.

2. 상태를 외부에서 관리하는 방식 (Stateless): 상태를 외부에서 받아와 사용하며, 함수는 상태를 소유하지 않고 외부에서 전달된 값을 사용합니다.

가능한 한 상태를 소유하지 않고 외부에서 전달받는 Stateless 방식을 선호해야 합니다. 이는 API를 더 재사용 가능하고 테스트 가능하게 만듭니다.

호출자가 변경을 지시하고, 구성요소는 따르기만 하면 됩니다. 이를 state hoisting이라고 부릅니다.

MutableState 또는 Immutable State를 직접 전달하지 마세요.

// Call site
enabled.value = true

@Composable
fun Chip(
   enabled: MutableState<Boolean>,
) { 
   // In the API
   enabled.value = false
}

호출자와 Composable 함수가 모두 상태를 소유하게 되어 제어가 복잡해지고 여기저기서 값을 변경할 수 있으므로 추적이 어려워집니다.

이벤트 처리

Chip 컴포넌트는 이제 API를 통해 외부에서 제어되고 있지만, 여전히 클릭을 처리하고, 이를 적절히 호출자에게 전달할 방법이 필요합니다.

클릭 이벤트와 같은 이벤트는 람다 매개변수로 받아들여 전달할 수 있습니다. 이벤트를 이렇게 추출하면 API를 더 재사용 가능하고 테스트 가능하며 미리 보기 가능하게 만듭니다.

Verifying

시맨틱스 (Semantics)

API가 접근성을 지원하도록 설정해야 합니다. Compose는 시맨틱 속성을 사용하여 접근성 서비스를 통해 정보를 전달합니다. 단순한 컴포넌트는 일반적으로 1~3개의 시맨틱스를 필요로 하며, 더 복잡한 컴포넌트는 더 많은 시맨틱스를 필요로 합니다.

구성 요소가 사용자에게 올바르게 설명될 수 있도록 시맨틱 속성을 추가하는 것이 중요합니다.

예를 들어, Image 컴포넌트는 contentDescription이라는 필수 매개변수를 사용하여 이미지의 내용을 설명합니다.

@Composable
fun Image(
   painter : Painter,
   contentDescription: String?,   // non-optional
   modifier: Modifier = Modifier,
)

Chip 컴포넌트도 예를 들어보겠습니다.

contentDesciprion을 매개변수로 지정하고, modifier semantics를 통해 루트 구성 요소에 적용할 수 있습니다.

하지만 사용자가 자신만의 modifier semantics 를 제공하고 기본 설정을 재정의하려고 할 수도 있다는 점을 염두에 두세요.

API를 설계할 때는 내장할 것과 사용자에게 요청할 것에 대해 정보를 바탕으로 결정을 내려야 합니다.

@Composable
fun Chip(
   contentDescription: String?,	// non-optional
   modifier: Modifier = Modifier
) {
   modifier = Modifier.semantics {
      this.contentDescription = contentDescription
   }
}

// modifier semantics 재정의
Chip(
  modifier = Modifier.semantics {
     this.contentDescription = contentDescription
  }
)

Slot API를 사용한 경우 외부에 시멘틱을 위임할 수 있습니다. 문맥상 적절한 경우, slot 된 content description을 부모에 병합할 수 있습니다. 이를 merged semantics라고 부르며 Modifier.semantics(mergeDescendants = true)를 통해 병합할 수 있습니다. 이는 child 컴포넌트의 데이터를 수집하고, 구성요소에 전달하여 단일 엔터티로 처리되도록 합니다.

테스트 가능성 (Testability)

API가 독립적으로 테스트 가능하도록 설계되어야 합니다. 예를 들어, FilterChip 컴포넌트의 다양한 상태 (선택됨, 선택되지 않음)를 쉽게 테스트할 수 있어야 합니다. 이를 위해 상태를 명시적으로 매개변수로 노출하면 테스트에서 쉽게 변경하고 검증할 수 있습니다.

사용자 상호작용을 테스트할 때는 다양한 상태와 이벤트를 시뮬레이션 할 수 있어야합니다. 이러한 상태를 더 쉽게 테스트 할 수 있도록 ineractionSource를 hoisting 하면 테스트에서 PressInteraction과 같은 상호작용을 검증할 수 있습니다.

Tip : Modifier 매개변수를 사용하면 testTag를 전달할 수 있어 요소를 식별하는데 도움이 됩니다. 이는 테스트에서 특정 요소를 찾기 위한 고유한 태그를 제공하여 테스트의 안정성과 명확성을 높입니다.

@Composable
fun Chip(
    interactionSource: MutableInteractionSource,
    modifier: Modifier = Modifier
)

@Test
fun chip_pressed() {
    val interactionSource = MutableInteractionSource()

    composeTestRule.setContent {
        Chip(...
            interactionSource = interactionSource,
            modifier = Modifier.testTag("Chippy")
        )
    }
    runBlocking {
         interactionSource.emit(
            PressInteraction.Press(...)
         )
    }
}

문서화 (Documentation)

API의 장기적인 안정성과 유지관리를 위해 적절한 문서화를 고려하세요.

문서화는 KTDoc 가이드라인을 따라야 하며, API의 기능과 목적을 명확히 전달하고, 매개변수의 설명과, 사용 예시를 포함해야 합니다.

외부 사용을 위해 하위호환성을 지원하는 것도 중요합니다. 가이드라인을 참고하세요 (goo.gle/kotlin-back-compat)

2019년을 회고합니다

루카스강 — Tue, 31 Dec 2019 22:45:47 +0900

2019년을 회고합니다

2018년도의 다짐

Android 내부 구조에 대한 공부를 해보겠다고 다짐했다.
Kotlin 실습을 계속 하겠다 다짐했다.
글로 뭔가 남기는 습관을 들여야 겠다 다짐했었다. (역시 블로그)
블로그와 마찬가지로 영어 공부하겠다 매년 다짐했다.
기술발표를 이제 슬슬 도전해보고자 했다.
소집해제 후 새로운 목표인 졸업에 대한 다짐을 했다.

2019년도는?

그래서 다짐대로 잘 했는가?

솔찍히 얘기해서 Android 공부에는 소홀했다. 1분기에 Effective Java 스터디를 하긴 했지만 이 회고를 쓰는 시점인 연말에 회고를 하자니 생각이 안난다. 링크드인 경력 기준으로 아직 iOS 개발경력 1년 6개월, Android 개발경력 1년 2개월이다 ㅋㅋㅋㅋ 역전 되기 전에 공부 좀 많이 해야겠다. 그리고 이제 슬슬 커뮤니티 활동으로 발표도 좀 해야할 것 같아서 하려고 하긴 했는데, 기술발표는 여전히 하지 않았다. 내년에는 Android 사이드 프로젝트도 좀 하고 발표도 좀 하고 해야겠다.

Kotlin도 소홀했다. 4분기부터는 배민앱에도 조금씩 코틀린 코드가 들어가기 시작했다. Kotlin in Action 을 다시보며 기본기를 좀 더 다질 필요가 있다. (20년도에 다시 스터디를 모집해볼까)

영어공부 안했다. 내년엔 토익 점수가 필요해서 강제로 하게 될 것 같다. (근데 200문제 푸는건 너무한 것 같다..)

휴가 몰빵으로 가까스로 소집해제 직후 칼복학을 했고, 예정보다 한 학기 일찍 졸업할 수 있게 되었다. (사실… 한 학기 더.. 음 아니다.)

회고합니다

작년보다는 덜 활동적이었다.

4분기에 접어들고서는 회사일이 많이 바빠졌고, 정말 많이 바빠서 정신 없이 지나갔다.

3분기 4분기는 특히 학교를 복학하면서 휴가를 써가며 학교를 다녔는데, 굳이 필요하지 않은 학점을 등록금이 아깝고, 학점 좀 올려보려고 18학점이나 신청해서 들었던 잘못을 저질러서 더 힘들었던 것 같다. 다행히 학점이 떨어질 뻔 했는데 그냥 유지되었다.

역시 1분기가 제일 뭔가 일을 많이 벌인다. 의욕이 활활 넘칠 때 ㅋㅋㅋㅋ 안드로이드 주니어들을 위한 행사를 열었고, (올해도 열 계획이다.) Effective Java 스터디도 꾸준히 진행했다. 발표도 하고 사이드 프로젝트도 시작한다. 그리고 1분기에 끝냈어야 할 프로젝트를 1년동안 하게 된다. (회고합니다)

2분기에는 I/O Viewing Party 를 계속 준비했다. 1년동안 했던 커뮤니티 활동중에서 가장 재미있었던 행사였다. (더불어 가장 힘들었던 행사이기도 했다.) 잠깐의 번아웃이 왔었고, 그동안 휴식을 취했었다.

학교 정말 열심히 다녔고, 다음 학기는 절대 이렇게 열심히 안다닐거다. 애매한 시기에 복학을 해서 아직 안 돌아왔거나, 빨리 온 친구들은 다 취업을 하여 학교를 안나왔기 때문에 수업은 거의 혼자들었지만 (친구가 있었어도 바로 출근해야 해서 시간은 없었지만) 그래도 오며가며 마주치는 동기들 덕분에 한학기 재밌게 보냈다.

4분기에는 시험이다 과제다 야근이다 일파티였고 그 와중에 DevFest Android 행사와 우아톤 준비를 했다. 호호 우아톤 참가도 했었는데, 평상시 접근성에 대해 관심이 많은 현주님과 새로 입사하신 주영님, 호미부대의 맡형 준원님과 접근성 관련된 프로젝트를 해서 3등을 했다. 오랜만에 해커톤을 참가해서 너무 좋았고, 오랜만에 페어 코딩을 해서 기분이 너무 재밌었다.

올해는 정말 기승전결 처럼 흘러갔는데, 12월 후반부로 들어가며 바쁜게 하나둘씩 해제되기 시작했고, 전사적으로 올 한해가 너무 바쁘게 지나갔기에 회사에서 2주 방학을 주었다. 덕분에 그동안 못 만났던 사람들도 몇 분 찾아뵐 수 있었고, 스노우보드도 실컷 타다가 장비도 사게 되고, 아무튼 푹 쉬었다. 오늘이 19년의 마지막 날인데, 이틀 뒤면 오랜만에 출근을 하게 된다. 기대가 만발

나는 올해 무엇을 했는가

1분기 (1월 ~ 3월)

super.init
클린아키텍쳐 블로그 글 기재
Effective Java 스터디 (1월 ~ 4월)
하이톤 멘토 참여
GDG Campus 발표 (델리만주, 주니어 안드로이드 개발자)
iOS 사이드 프로젝트 시작

2분기 (4월 ~ 6월)

GDG Android in Pangyo

(부산에서도 하겠다는 공약을 세웠지만 지키지 못함, 내년에 제주 도전)
Google I/O Viewing Party
비엣남 여행
ㅋㅋ페스티벌
Android Accessibility for Everyone 발표
Google I/O Extended Korea Android 2019

3분기 (7월 ~ 9월)

안드로이드 탐구영역
Android Studio Build Talk
복학
소집해제
수영시작 (꾸준히 안감 ㅋㅋ)

4분기 (10월 ~ 12월)

GDG DevFest Seoul 2019
호미부대
DevFest Android 2019
DevFest Jeju 방문
뭐먹지 오픈
종강
우아톤
스노우보드
전사휴무

내년에는?

사이드프로젝트를 좀 많이 해보면서 최신기술을 좀 다뤄봐야겠다. 특히 안드로이드. 안드로이드 사이드 프로젝트를 한 건도 하지 않았었다.

최근 대학가에서 모바일 개발자를 꿈꾸는 학생을 많이 찾을 수가 없었다. (거의 없었다.) 대부분 머신러닝, 딥러닝을 꿈꾸고 있었다. 내년에는 주니어, 대학생 쪽으로 커뮤니티 활동을 많이 해보고 싶다. 나도 첫 신입으로 개발을 하기 전에는 과연 모바일 개발자를 계속 해야하나에 대한 고민이 많았었는데, 결국에는 할 수 있는 것 중 모바일이 제일 자신이 있어서 이쪽 분야로 오게 되었다. 으흠… 요즘에는 프로젝트를 할 때 클라이언트는 꼭 있어야 할텐데 모바일 한번 쯤은 다들 경험 해보지 않나… IT동아리 모집 공고글만 봐도 많게 생겼는데 희한하게 내 주변에는 모바일 개발자를 꿈꾸는 대학생이 없다. 올해 모바일 개발자를 꿈꾸는 고등학생 멘토링은 좀 했었는데, 우리 숭실대 동아리는 어떻게 된거니!! 내년에는 요기를 한번 파보려고 한다.

졸업해한다. 2020년에서 가장 중요한 일이다. 졸.업.하.기.

2018년을 회고합니다.

루카스강 — Tue, 1 Jan 2019 18:56:21 +0900

2018년의 새로운 것

GDG Korea Android 운영자로 이직(?), 그리고 1년

GDG 안드로이드 챕터로 온지 1년이 되었다. 2018년은 주로 회사일로는 iOS를 하고 지냈기 때문에 Android에 대해 조금 소홀했던 한 해였다. 그래도 까먹지 않기 위해서 Kotlin 스터디도 하고, 커뮤니티 활동도 꾸준히 했다.

무엇을 했는가

GDG Korean Android 2018 Lightning Talk
Kotlin Study (Sunday 사당)
Android Things & Actions on Google Codelab
Women Techmakers 2018 Korea Codelab (Android Things)
GDG Global Summit & 발표!!
Google I/O Extended Seoul 2018 (를 준비하다가 훈련소 행)
Google I/O 2018 Extended Android Overflow
파이콘 GDG 커뮤니티 부스
GDG Northeast Asia Community Summit 2018
DevFest 2018 in Seoul
GDG Korea Community Summit, 2018
Effective Java Study

추가로 몇 번의 스탭 활동과 ML 관련 커뮤니티 세미나 참가등이 있었고, 돌아보면 Android 최신 기술 (AAC 나 JetPack 등) 을 다 따라가기는 벅차서 ML Kit (Android, iOS 클라이언트 단 ML) 이나 ML 쪽으로도 활동을 많이 했던 것 같다. 큰 경험으로는 GDG Global Summit 에서 RSVP에 대한 주제로 발표를 했었고, 이 경험은 정말 둘 도 없는 신선한 도전이었다. 역시 영어 공부를 해야한다. (해야한다고!! 올해는 하자 쫌...!!) 연말이 되어 돌이켜봤을 때 커뮤니티 활동을 소홀히 했던 것처럼 느껴졌는데, 다시 보니 많이 했었다. 하반기에는 DevFest 를 준비를 너무 열심히 한 탓일까 이거 외의 활동을 거의 못했는데, 지역 글로벌 행사에 매진해서 준비하느라 우리 챕터 행사는 정말 하나도 못챙긴게 아쉬웠다.

내년에는?

이제는 Android 공부에 매진을 해서 Android 기술에 관련된 커뮤니티 운영을 할 것이다. 작년에 간간히 커뮤니티 운영에 대한 리뷰를 받으면서 못챙긴 부분도 챙겨야 겠다. 물론 이런 활동을 하면서 나의 성장도 함께 되도록!

배달의민족 Android 개발자가 되었다!

11월 부터 iOS 마지막 프로젝트를 하고 Android 파트로 이동하게 되었다. (사실 같은 팀 내에서 자리만 옮겼다.)

iOS 개발자로써의 느낌?

Android 만 쓸 때는 잘 몰랐다. 처음에는 정말 UX도 하나도 모르고 너무 어려웠다. 가령 스크롤 되는 화면에서 바운스를 넣는다던지? 스크롤도 끝났는데 위로 한 없이 올려다 보는 근처에 있는 유저들을 위해 빈 화면으로 가려놓는 다던지? 하는 것들이 필요했다. UX가 햇갈리면 나 빼고 다 아이폰을 사용하는 단톡방에 물어보고 그랬다. iPhone X의 시리를 동작시키는 방법이라던지, 휴대폰을 끄는 방법은 정말 충격이었다. 그래도 다시 Android 로 돌아왔을 때 또 다른 느낌을 받았으니 그 내용을 적어보자면

iOS 가 더 이쁜 것 같다.

다만 OS를 정말 신뢰할 수가 없었다. (시리 숏컷은 iOS 12 베타 때 있던 버그를 그대로 릴리즈하다니!)

기본 사이즈, 큰 사이즈, X 사이즈, 간혹 작은 사이즈 (누가 아직도 4s 를 쓰는고...) 만 보면 되니 편했다.

스토리보드와 Auto Layout 너무 편하다. (덕분에 Constraint Layout 너무 쉽다.)

Xcode 정말 믿을 수 없고 느리다. (Android Studio 너무 편하고 느리다.)

스위프트 편했다. (근데 막상 다시 자바로 오니 불편함은 없다.)

구조에 대한 고민을 더 하게 되었다. (주변 사람들이 이상한건지, Android 개발자들이 다 그런것인지 정말 열성적이다.)

Android 개발자로써의 다짐

사실 iOS 개발을 할 때 뭔가 부족하달까하는 벽에 막힌 기분이 들었다. 처음 시작할 때는 0에서 시작하는 것이었으니 무언가 성장을 빨리 하는 느낌이 있었는데, 내가 아이폰을 안 써서 그런 것일까, iOS 개발에 대한 열정이 부족했을 까, 도메인 지식이 부족했을까 아무튼 구현을 하고 나서 내부 구조가 어떻게 돌아가는지 등에 대한 고민은 잘 안했던 것 같다.

올해는 Android에 대한 내부 구조를 조금 더 공부를 해보아야겠다.

오랜만에 Kotlin으로 앱을 만들어봤었는데, 안쓰다가 쓰니까 어렵더라.. Kotlin 실습을 계속 이어 해야 겠다.

iOS 개발할 때는 사소한 것 또는 부딪친 이슈를 정리하곤 했었는데 (초반에 하다가 안했지만), 역시 Android 도 글로 남기는 습관을 다시끔 들여 보도록... 해야 겠..

나는 올해 무엇을 했는가

1월 ~ 3월

스위치를 샀서 젤다 공주님을 구하러 (안갔다.)
iOS 연습 삼아 개인 프로젝트를 했다.
새벽 시간을 활용해서 번개모임 등으로 잘 놀러 다녔다.
코틀린 스터디
볼링공을 샀다.
MSP 에서 머신러닝 해보자고 텐서플로우 공부하고 써봤다.
첫 9XD 모임 참가!

4월 ~ 5월

Google I/O 를 다녀옴
GDG Global Summit 에서 발표를 했다!
리틀빅데이터 등 ML 관련 세미나 참석하기

5월 24일 ~ 6월 21일 훈련소

6월 ~ 9월

Google Korea Ai Week
Google I/O Extended Android
- 노쇼에 대한 고민에 빠짐
파이콘 GDG Korea 부스 (파이콘 첫 참가)
DevFest 준비 여념

10월 ~ 12월

Android 개발자로 전향
DevFest
1월 행사 준비
송년회들들
보드를 처음 타봄

정리

블로그.. 열심히 쓰고 싶다.

영어 공부 열심히 하자

Android 커뮤니티 업그레이드, Android 개발자로서의 성장

올해는 기술 발표를 해보자

작년에는 하루 단위 계획 (오늘은 무엇을 한다.) 로 세웠으면 2019년에는 시간 단위 계획 (1시 ~ 3시는 이거 하자) 를 세워봐야겠다.

젤다의 전설 다시 시작해서 끝장을 보고 싶다. (스위치는 계속 자고 있다.)

훈련소 갔다 오느라 한달과 앞뒤 한달 쯤이 통채로 날라갔는데 2019년에는 그런 날이 없겠지!

9월에 소집해제한다. 다른 큰 인생목표인 졸업을 이뤄야한다.

코틀린(Kotlin)의 프로퍼티에 대해 알아보자!

루카스강 — Sun, 4 Mar 2018 11:55:31 +0900

프로퍼티

자바는 보통 클래스를 만들 때 캡슐화를 하기 위해 private 된 멤버변수와 getter, setter로 만든다
자바는 보통 위의 필드와 접근자를 묶어 프로퍼티라고 부른다.
코틀린에서는 필드변수를 만드는 순간 디폴트 프로퍼티가 만들어지므로 접근자만 설정하면 된다.

class ChatData(val nickname: String, var message: String)

클래스 시간에 봤던 것 처럼 val 로 선언하면 getter만, var 로 선언하면 getter, setter 가 자동으로 만들어진다.
자바에서 불러올 때는 getNickname() 처럼 불러올 수 있다.

커스텀 접근자

class ChatData(var nickname: String, var message: String) {
    var name: String = ""
    	get() = if(nickname.length > 0) nickname else "이름없음"
	    set(value) {
        	setStringLowerCase(value)
    	}
}

프로퍼티에 접근 할 때 getter, setter를 새로 지정해 변수를 초기화하거나 다른 일을 할 수도 있다.

val isEmpty get() = this.size == 0

코틀린 1.1 이후로부터는 getter로 부터 타입을 유추할 수 있으면 타입 조차 생략할 수 있습니다.

백킹 필드(Backing Fields)

필드는 Kotlin 클래스에서 직접 선언할 수 없습니다.

var counter = 0
	set(value) {
        if (value >=0) counter = value else 0
	}

와 같이 구성을 했다고 칩시다.

Kotlin에서는 Test.counter = 100 , 자바에서는 Test.setCounter = 100 을 호출할 것입니다.

그래서 setter 함수가 호출될 때 set(value) { if (value > 0) counter = value else 0 } 이 실행되면 재귀 호출이 발생하므로 오류가 납니다.

var counter = 0
	set(value) {
        if (value >=0) field = value
	}

그래서 Kotlin 은 filed 식별자를 제공합니다.

filed 식별자를 이용하면 backing field에 접근할 수 있습니다.

백킹 프로퍼티 (Backing Properties)

백킹 필드를 사용하고 싶지 않으면 백킹 프로퍼티를 사용하세요

private var _table: Map<String, Int>? = null
public val table: Map<String, Int>
    get() {
        if (_table == null) {
            _table = HashMap() // Type parameters are inferred
        }
        return _table ?: throw AssertionError("Set to null by another thread")
    }

2017년을 회고합니다

루카스강 — Thu, 15 Feb 2018 20:51:07 +0900

회고..?

나는 올해 무엇을 하였는가

1월 ~ 2월

GDG Korea Campus 가 생겨나고, 아 지금은 이름이 변경되어서 GDG Campus Korea 입니다. 큰 행사 두 개를 진행했습니다. GDG Korea Campus Dev Challenge 와 GDG Korea Campus 불타는 해커톤 (Firebased Hackation) 이었는데요, 특히 해커톤을 준비하는 과정에서 많은 사람들을 만났습니다. 해커톤에 꽤 많이 참가했었는데, 기존의 해커톤의 문제점을 벗어난 새로운 경험을 주기 위해서 스태프 분들과 많은 준비를 했었습니다.

3월 ~ 4월

휴학생 신분이었기에 가장 자유롭기도 하고 어찌보면 바쁘게 지냈던 두달이었습니다. (지금 생각하면 대체 왜...) 평소에 배워보고 싶었던 코틀린도 GDG에서 코틀린스터디를 하면서 익히고, 안드로이드 컨퍼런스인 Drioid Knight와 코틀린 밋업인 Kotlin Night 도 참가했었네요. 오.. MSP 에반젤리즘을 Azure로 한답시고 Azure Notification Hub에 Chrome App을 붙이는 프로젝트도 했었네요. (서비스워커.. 웹이라니..) 개인적으론 이 기간이 제게 기술적으로 많이 성장한 기간이라고 생각합니다.

2016년도, 그러니까 작년에 소프트웨어 마에스트로 과정 연수를 받으면서 휴학을 할지 말지 많이 고민을 했었는데 휴학을 안하고 학교를 다니면서 연수과정을 들었었습니다. 첫 6개월은 산업기능요원으로 근무하기 위해선 산업기사자격증이 필요하겠다라는 이유였고, 그래서 2학년 2학기를 끝냈습니다. 뒷 6개월은 학과분리가 되면서 나중에 3학년 과정을 원활하게 들을 수 없다는 걱정에 그랬었는데, 지금 생각하면 소마 과정을 들었을 때 왜 휴학을 안했지 하며 후회를 많이 하고 있었습니다. (심지어 4급은 정보처리산업기사자격증이 필요 없다고 함..) 뭐 그때 휴학을 안했으면 지금 2학년이겠지만...

아무튼 휴학을 하고 평소에 배우고 싶은 것 (코틀린, 영어회화 등), 하고 싶었던 것(피아노, 동아리활동, 해커톤 등), 사람 만나기 등등 제한없이 했었습니다. 오히려 지금보다 이맘때의 캘린더가 더 빡빡해요!

그러니 여러분 휴학하세요!!

5월 (Google I/O, 미국 여행)

5월 달은 거의 한달 내내 미국에 있었습니다. Google I/O 17에 참가하기 전에 처음 가보는 미국이기도 해서 비행기 값 뽕뽑아 먹으려고 (~사실 휴학생이라 남는게 시간이라~) 뉴욕도 가보고 로스엔젤레스도 가보고 했었네요.

미국 여행 전에 학교에서 들었던 영어회화 클래스에서 Grace에게 스타벅스맨이라는 별칭으로 불리며 스타벅스 얘기만 했었다. (수업 전에 스타벅스에서 왔거나, 수업 후에 스타벅스를 가거나, 스타벅스 커피를 테이크 아웃 해서 왔거나 했었던 때였다.) 주문하는 법을 열심히 공부해갔지만 정작 미국을 가니 그런거 다 필요 없더라. 영어는 그냥 자신감을 가지고 하면 되지만, 문제는 내 발음을 못 알아 듣는다. 나이트로 콜드브루를 달라고 3번 말했는데 그냥 콜드브루를 주고, 풔켓몬고 푸라푸치노오 를 달라고 했는데 민트 미드나잇 프라푸치노(?) 를 주질않나 (사실 이건 이해가 안됬다) 아무튼 한국에서 하는 영어 (문법) 공부 다 쓰잘데기 없다는 걸 배워왔다.

내가 생각하는 서양인은 두 종류가 있다. 영어를 못하면 무시하고 그냥 가는 사람, 영어를 못해도 알아들으려고 노력해주는 사람. 후자의 경우는 또 상대방이 어려운 영어를 구사하면 대화가 통하지 않는다. 그렇게 우리 GDG Korea 오거나이저 두 명은 GDG Global Summit에서 외국인을 피해 다녔다. 영어를 정말 잘해야 겠다는 생각이 들게했던 날이었다. 그래도 GDG APAC 모임은 재미있었다. 나도 쉬운 영어하고 상대방도 쉬운 영어 한다. 말이 잘 통한다. 낄낄

우연찮게 io17은 안드로이드 신기술 대잔치였다. 행사장에서 오레오 과자를 나눠줬기에 아 이번 안드로이드 O는 오레오구나라는 생각이 들었고, 디자인적으로 변한건 많이 없지만, 아키텍쳐 패턴 등의 내용이 가득가득 했다. MVP, MVVM 등 패턴 공부에 한창 눈을 뜨고 있었기 때문에 개인적으로 매우 재미있었다. 주변에 모두 개발자들이고, 다들 웃으며 즐기고 있었는데 정말 개발자 축제였다. 올해도 가야지

후일담으로 4월 26일에 지금 다니고 있는 우아한형제들에서 1차 기술면접을 봤었는데, 위에 적었다 싶이 저는 3~4월을 코틀린에 푸욱 빠져있었고, 면접에서는 코틀린 얘기밖에 안했었습니다. 아무튼 내용은 코틀린의 장단점, 코틀린의 장점이 자바로도 충분히 구현가능하다는 내용 위주였는데, Google I/O 오프닝에서 잠금화면이 코틀린 모양으로 풀리면서 이젠 코틀린이 안드로이드 공식 언어입니다!! 할 때가 잊혀지지 않네요. (근데 지금 Swift 하고 있는건 함정, iOS 개발하는데 도움 많이 되었습니다. 여러분 코틀린하세요!)

6월

6월은 별거 없었다. 잠깐 쉬어가는 타임(?) 이 아니라 7월에 있을 I/O Extended 준비와, 미국 여행 경비를 갚기 위한 과외 수업.. 그리고 MSP 행사 준비, 5월 한달을 한국에 없었기 때문에 또 오랜만에 보는 얼굴들을 보러 다니면서 보냈다. 아. 6월 초에 우아한형제들 2차 면접을 봤고, 6월 말에 입사를 했다. 입사 전에 노는 시간은 시간이 빨리 간다.

7월 ~ 10월

아이폰 개발자가 되었다. 회사에서는 내가 아이폰을 맡길 원했고, 나는 안드로이드 개발자로써의 커리어를 꿈꾸고 있었기에 고민을 많이 했지만 뭐 나름의 터닝 포인트가 되었고 지금은 만족하고 있다. 새로운 환경에 적응하기 위해 노력을 많이 했었는데, 언어적인 문제보다는 SDK가 너무 달라서 힘들었다. 오토 레이아웃이라던지, sdk가 지향하고 있는 바(?) 라던지. (예를들면 왜 isHidden 처럼 부정으로 시작하는지 모르겠다. 보통은 isVisible 이라고 쓰지 않나..?) 아, 모르는게 투성이라서 Quick이라는 테스트 라이브러리 도큐먼트 번역을 해봐았었다. 번역 나름 재밌었다. 번역한다고 잘하게 되는건 아니지만 아는건 늘어나는...? 이랄까,,, iOS영역에 대한 부분은 아직 현재진행형이므로 이 부분에 대한 회고는 내년에 하는 걸로

I/O Extended 에서 발표를 했다. I/O 기간 내내 붙어다녔던 태환형하고 같이 발표를 했었는데, 뭐 기술적 주제를 가지고 대단한 발표를 한 것은 아니고 I/O 다녀온 썰에 대한 이야기를 했었다. 엇 그러고보니 커뮤니티에서도 발표를 여러번 했었는데, 아직 스스로 부족하다고 생각하기 때문에 기술적인 발표는 한 번도 안한 것 같다. 뭔가 아직은 기술 발표는 꺼려진다. 맨날 약만 팔고 다닌다. 2018년도도 더 성장해야지.

GDG Korea Campus Summer Party를 8월 중순 쯤 했었다. 학생들을 위한 이런 저런 개발 행사가 잘 없다보니 뭔가 많은 것을 전달하기 위해 2일 행사로 준비를 했었는데, 그 과정에서 또 많은 사람들을 만날 수 있었다. 이 때 만났던 사람들은 아직까지 연락을 하고 지낸다. 사실 준비 과정에서 크고 작은 문제가 많았던 것 같은데.. 지금은 다 미화되었군. 조금 더 꼼꼼하게 챙기는 습관이 필요하다. 팀장님이 내가 처음 아이폰 작업을 한 결과물을 들고 갔을 때, 모바일 개발자는 디테일에 신경 써야 한다고 했었는데, (자세히 들여다보면 아이콘이 1:1 크기의 원모양이 아니였다.) 뭔가 아직까지도 가끔 디자인 여러 속성 중 한 개를 빼먹는다거나 (디자이너의 매의 눈에 다 걸린다.) 행사 준비할 때도 몇 번은 시간을 잘못 예약한다거낳ㅎㅎㅎ (이럴 때 정말 멘붕이었다.) 사소한 문제들이 있었었지..ㅋㅋㅋㅋㅋㅋㅋ

11월

11월은 바쁜 하루가 연속이었다. 역시 개발자 행사는 가을이 꽃이지! 첫째주, GDG Korea Campus 1주년 파티가 있었다. 발표도 하고 준비도 했다. 그리고 GDG Korea Campus의 오거나이저를 그만둔다고 선언했다. 뭐 그만둔건 아니고 GDG Korea Android 오거나이저로 이동한거지만.. 아무튼 갑자기 커뮤니티에 대한 회고를 해보면 GDG SSU 때부터 시작하는데, 붙었던 여러 대학 중 Google 커뮤니티도 있고 가깝기도 해서 숭실대로 진학을 했었고, GDG SSU의 일원이 되고 어쩌다보니 GDG SSU의 오거나이저도 맡게 되었었다. 그렇게 또 어쩌다보니 학교 학생들 대상으로 하는 동아리보다는 뭔가 커뮤니티면 한국의 학생들을 대상으로 하는게 맞는 것 같아서 GDG Korea Campus로 바뀌게 되었고 1학년이었던 내가 4학년이 될 때까지 내가 성장하는데 큰 도움이 되었던 사람들을 만나게 해 준 곳이어서 좋다. (의식의 흐름 끝) 아무튼 결론은 커뮤니티 활동 하세요 여러분!

둘째 주, MSP 세미나를 잡아두었었다. Azure ML을 이용한 추천시스템 구축 코드랩이었는데, 소마 활동을 할 때 추천 시스템을 썼던 것을 기억을 끄집어내서 다시 공부했다. 이제 머신러닝은 (사실 Recommendation분야는 머신러닝은 아닌것 같지만..) 개발자라면 알아야되는 교양같은 느낌이랄까.. Azure ML을 이용하면 블록 코딩으로 머신러닝을 쉽게 짤 수 있었다. 그래서 다시 안쓸 것 같다. 뭔가 불편함.

셋째 주, GDG Korea DevFest 2017 in Seoul 행사가 있었다. 참가자 천명 이상의 큰 행사였고, 커뮤니티 트랙을 담당했다.

넷째 주, 10월에 티몬에서 갑자기 9900원에 제주도 티켓을 판다고 해서 일단 샀는데, 일단 가게 되었다. 뭐할까 하다가 유림이가 협재에서 리모트 근무를 했던 게 생각나서 정보를 얻어 협재로 떠났다. 1박 2일밖에 없었지만 바다 앞에서 하루종일 코딩하는 경험은 신선했다.

12월

다섯 째주, 가 아니라 다시 첫째 주, 러시아 여행을 다녀 왔다. 여름에 떠나기로 한 여행 미루고 미루다가 블라디 보스톡톡 트로피카나 영상 찍으러 블라디보스톡가기로 했다. (사실 다른 목적도 있었지만 비밀) 지금 생각하면 미친놈들이었는데, 나름 다녀왔더니 한국이 안춥더라. 가끔 기상청에서 모스크바보다 기온이 낮다며 한국이 러시아 보다 춥다고 보도하는데 블라디보스톡이 한국보다 안추웠던 날은 없었던 것 같다. 우리가 갔을 때는 영하 16도였으니.. 한 두세달에 한번 씩은 해외여행을 갔었는데, 뭔가 산업기능요원이 되고 나서 자제하다가 갔던 첫 여행이었다. 이젠 자주 갈거다.

아 그러고보니 비트코인 이야기를 안적었었네, 3월 쯤 비트코인 채굴하시는 분이 지갑 앱을 만들고 싶다며 안드로이드 과외를 요청하셨는데, 갑자기 어느날 나보고 블록체인 공부해오라고 했었다. 어려워서 안했다. 후회한다.

그 맘 때 쯤 친구가 농담인지 진담인지는 모르겠지만 코인원에 안드로이드 개발자가 없다며 빨리 와서 일 좀하라고 했는데, 여행가야 한다고 안갔다. 후회는 엄...

6월 쯤 샀던 스트라티스, 존버하다가 그냥 팔았다. 사토시 기준으로 3분의 1로 떨어졌기에.. 그리고 10배가 올랐다. 친구를 믿었어야했다. 뭐 근데 지금 생각해보면 12월 말? 중슨 쯤, 아니 1월인가 사실 기억이 잘 안난다. 엄청 올랐을 때가 있었는데, 꽤 큰 돈을 만져보고 개발자로 성공해서 뭐? 라는 생각을 잠깐 했었는데, 가격은 지금 다시 정상 수준으로 돌아왔고 나도 다시 개발자로서의 성장을 쫒아 가고 있다. 잠깐이나마 그런 생각을 한 것은 후회한다.

아무튼 개발자가 관심을 가지면 다 문제가 되는 것 같다. 블록체인이나,,, 실리콘벨리나,,, 아무튼 개발자가 전 세계적으로 민폐다.

Google I/O 에서 우연히 제이크 왓슨 옆자리에 앉게 되어 같이 사진을 찍었다. 그 때 제이크 왓슨 처럼 유우명하고 잘하는 개발자가 되어야지 하고 다짐을 했었다. 2018년도 노력하자! (그리고 그는 구글에 들어갔다. 나..나의 꿈도 구글로 가야.. 하느..)

그리고

사실 이 회고록은 2017년 12월 부터 쓰기 시작했는데... 나의 귀차니즘을 반성하며...

그리고 제가 저의 기억력을 믿지 못하기 때문에 회고록에서 고마웠던 분들 이야기는 다 뺐습니다. 2018년에도 한분한분 만나뵙는걸로! (사실 지금도 2018년!!)

코틀린(Kotlin)의 클래스에 대해 알아보자!

루카스강 — Sat, 24 Jun 2017 18:21:16 +0900

클래스

자바에서 클래스는 보통 생성자와 get, set 메소드, 그리고 추가적인 메소드를 추가해서 만듭니다.

 
class ChatData{
    private String nickname;
    private String message;
  public ChatData(String nickname, String message){
    this.nickname = nickname;
    this.message = message;
  }
  
  public String getMessage(){
    return this.message;
  }
  
  public String getNickName(){
    return this.nickname;
  }
}

하지만 코틀린은 이 모든 것을 다음 한 줄로 함축할 수 있습니다.

 
class ChatData(val nickname: String, val message: String)

일반적으로 자바에서는 데이터 필드 값의 보안자를 private로 두고 get, set 메소드를 통해 접근을 제한하게 됩니다. 코틀린에서는 get, set 메소드를 기본적으로 포함하고 있는데, 위 예제에서는 생성자가 변수를 val 로 받고 있으므로 nickname 과 message는 get 메소드만 가지고, set 메소드는 작동을 하지 않습니다.

 
fun main(args : Array<String>) {
  val data =  ChatData("user1234", "HelloWorld")
  println(data.message)
  //    data.nickName = "aaa" // 불가능
}
class ChatData(val nickName: String, val message: String)
>>> HelloWorld

nickName 값을 수정시키고 싶다면 val 대신 var 를 사용하면 됩니다.

 
fun main(args : Array<String>) {
    val data =  ChatData("user1234", "HelloWorld")
    data.nickName = "aaa"
    println(data.nickName)
}
class ChatData(var nickName: String, val message: String)
>>> aaa

만약 완전히 private 로 선언하고 get 메소드 조차 사용하고 싶지 않다면

 
class ChatData(nickName: String, message: String)

다음과 같이 작성하면 클래스 외부에서 접근이 불가능하게 됩니다.

자바에서는 초기화 코드를 생성자에다가 작성합니다. 하지만 위와 같은 코드들에는 생성자 내부에 코드를 작성할 수 없습니다. 이에 대한 문제는 코틀린에서 다음과 같이 해결합니다.

 
fun main(args : Array<String>) {
    val data =  ChatData("user1234", "Hello World");
}
class ChatData(nickName: String, message: String){
    init{
        println("$nickName said: $message")
    }
}
>>> "user1234 said: Hello World"

또한 생성자가 여러개가 필요할 경우도 있을 겁니다.

코틀린은 기본생성자 와 보조생성자 개념이 있습니다.

 
class ChatData(nickName: String, message: String) {
    var age = 0
    constructor(nickName: String, message: String, age: Int) : this(nickName, message){
        this.age = age
    }
}

생성자가 여러개가 필요한 경우는 보조 생성자를 이용하면 됩니다.

보조생성자는 constructor 키워드가 필요하며, 반드시 this() 인 기본 생성자를 호출해야 합니다.

만약 기본 생성자가 아무 것도 받지 않는다면

 
class ChatData(){
    var age = 0
    constructor(nickName: String, message: String, age: Int) : this() {
        this.age = age
    }
    constructor(message: String, age: Int) : this() {
        this.age = age
    }
}

위와 같이 해결을 하거나

 
class ChatData{
    var age = 0
    var nickName = ""
    constructor(nickName: String, message: String, age: Int) {
        this.nickName = nickName
        this.age = age
    }
    constructor(nickName: String){
        this.nickName = nickName
    }
}

기본 생성자를 여러개로 만들면 됩니다.

위 두 예제의 차이점은 기본생성자가 비어있는 클래스는 ChatData() 로 값을 넘겨주지 않고 인스턴스를 생성을 할 수 있다는 점입니다.

인스턴스를 생성할 때는 다음 두 가지 방법으로 생성할 수 있습니다.

 
    ChatData("user1234", "Hello World", 10)
    ChatData(nickName = "user1234", message = "Hello World", age = 10)
    ChatData(message = "Hello World", age = 10, nickName = "user1234") // 순서는 상관 없음

짧게 작성하려고 했는데 생각보다 너무 길어졌네요.

프로퍼티에 대한 내용도 너무 길어서 나눠서 올리겠습니다.

다음에는 프로퍼티와 백킹필드, 백킹 프로퍼티에 대해 다루어 보겠습니다.

코틀린(Kotlin)의 함수와 변수!

루카스강 — Mon, 19 Jun 2017 23:56:50 +0900

함수와 변수

Hello World

언어를 제일 먼저 시작하면 Hello World 부터 찍어야 겠죠!

다음은 코틀린 언어로 작성된 Hello World! 입니다

 
fun main(args: Array<String>){
  println("Hello, world!")
}

위 예제 코드로 우리는 다음과 같은 포인트를 체크할 수 있습니다.

코틀린은 함수 키워드로 fun 을 사용합니다.
파라미터 타입이 이름 다음에 옵니다.
자바처럼 함수가 클래스를 꼭 둘러쌀 필요가 없습니다. 함수가 가장 먼저와도 상관 없습니다. (와우! C언어 같다!)
Array 는 단지 클래스입니다. 자바와 달리 Array Type을 위한 (ex: ArrayList, LinkedList 등) 별도의 특수구문이 없습니다.
System.out.println 대신 println 을 사용해도 됩니다.
세미콜론이 없습니다

함수

함수라면 당연 반환 값이 있어야 합니다. (위 예제인 Hello World 에서는 void 를 반환했기에 생략이 되었지만)

코틀린에서는 다음과 같이 함수의 반환 타입을 명시합니다.

 
fun sum(a: Int, b: Int): Int {
  return a+b;
}
>>> println(sum(1,2))
3

함수 선언부도 함수의 파라미터를 써줄 때 처럼, 함수의 이름 그리고 리턴 타입을 마지막에 적어줍니다.

그리고 위 함수와 같이 단순한 함수는 다음과 같이 짧게 표현할 수도 있습니다.

 
fun sum(a: Int, b: Int) = a + b

이러한 구조를 expression body 라고 부릅니다. (한줄 함수라고 해도 될 것 같은데..)

코틀린에서는 위와 같은 표현식 처럼 식 형태로 함수를 작성할 수 있습니다.

표현식에서는 위와 같이 return type이 생략되는 경우도 볼 수 있는데, return type을 추론해서 컴파일러가 알아서 지정하기 때문입니다. 실제로 다음과 같은 코드는 이렇게 동작합니다.

 
fun typeCheck(type: String) = when(type){
    "string"-> "ABCD"
    "int" -> 10
    "float" -> 10f
    else -> {
        "Error"
    }
}
>>> println(typeCheck("string"))
ABCD
>>> println(typeCheck("int"))
10
>>> println(typeCheck("float"))
10.0
>>> println(typeCheck("???"))
Error

when 함수는 뭐랄까.. if else 문 같은 함수입니다. 자세히는 다음에 다루고, typeCheck 라는 함수의 return type 이 입력 값에 따라 달리지는 것을 볼 수 있습니다.

단 표현식이 아니라 블록 형태의 함수면 반드시 return type을 명시적으로 표시해야합니다.

변수

코틀린에서는 자바와 달리 변수의 형이 두가지 밖에 없습니다.

val 과 var 입니다.

코틀린은 변수도 추론 형을 사용합니다.

 
val number = 10
val s = "Hello World"

하지만 다음과 같이 명시적으로 변수의 형을 지정해 줄 수도 있습니다.

 
val number : Int = 10

위와 같이 컴파일러가 변수의 타입을 추론해서 지정해줍니다!

다만 변수를 선언과 동시에 초기화를 하지 않는다면 반드시 변수의 형을 지정해주어야 합니다.

변수의 선언이 이루어지지 않았으므로 타입을 추론할 수 없기 때문입니다.

 
val number : Int
number = 10

val 과 var의 차이에 대해 알아봅시다.

val (value) : Java의 final과 비슷합니다. 불변 상수로 한번 초기화된 이후에는 수정할 수 없습니다.
var(variable) : 수정가능한 변수입니다.

var로 선언을 한 이후 처음 초기화 된 순간 이후는 변수의 형을 변경할 수 없습니다. 예를 들면 다음과 같은 코드는 오류가 발생합니다.

 
var number = 10
number = "10"

두가지 밖에 없으므로 코드의 부작용을 막기 위해서는 초기에는 모두 val 로 선언했다가, 수정이 필요할 경우 var로 바꾸는 것을 추천드립니다.

다음 장에서는 Class 와 Propertie 에 대해 알아봅시다!

코틀린(Kotlin) 시작하기!

루카스강 — Sat, 10 Jun 2017 23:50:53 +0900

코틀린 OT

It's a new programming language targeting the Java platform. Kotlin is concise, safe, pragmatic, and focused on interoperability with Java code.

Kotlin In Action 에서 소개하고 있는 Kotlin 에 대한 예제 소스입니다.

data class Person(val name: String, val age: Int? = null)	// Nullable type; defult value

fun main(args: Array<String>){
  	val persons = listOf(Person("Alice"), Person("Bob", age = 29))
  	val oldset = persons.maxBy { it.age ?: 0 }	// Lambda
  	println("The oldest is : $oldset")			// String template
  	// The oldest is : Person(name=Bob, age=29)	- data class 의 auto toString
}

자세한 사항은 뒤에 이어지는 포스팅에서 자세하게 다루도록 하고 코틀린에 대한 내용을 먼저 살펴보죠

Data class
- 기존에 자바에서 쓰던 Model Class 를 이렇게 짧게 바꿀 수 있습니다. set, get 함수는 물론 toString 함수까지 내장되어 있습니다.
- 예제코드를 보듯 코틀린에는 null-safe 하므로 null이 발생할 가능성이 있다면 명시적으로 nullable을 ?로 적어주어야 합니다.
- defult value를 파라미터에서 바로 설정해줄 수 있습니다.
- 위 예제인 Person data class는 name과 age를 가지고 있습니다.
Main function
- 코틀린의 메인함수는 fun main(args: Array<String>) {} 으로 사용합니다.
- 예제와 같이 public type functionName() 이 function funName 도 아닌 fun 으로 짧아졌습니다.
- 파라미터는 name : Type 순서로 사용하면 됩니다.
Value Type
- 코틀린에서는 자바에서처럼 int, long, Class 등의 타입을 명시할 필요 없이, 알아서 추론해줍니다.
- val과 var이 있으며, val 은 선언 후 변경이 되지 않을 때(value), var은 선언 후 변경이 존재할 때 사용합니다.(variable)
Lamda
- 코틀린은 람다식을 기본으로 사용합니다.
- it 은 파라미터의 defualt name 입니다.
- ?: 은 만약 age가 null 일 경우 0으로 대체하기 위해 사용되었습니다. age는 null-safe하지 않기 때문입니다.

이 짧고 간결한 코틀린 코드에 감탄해보세요!

코틀린의 주요 특징

자바가 있는 환경이라면 어디든!
- 코틀린은 서버사이드, 안드로이드, 자바가 돌아가는 곳이면 어디서든지 동작합니다.
- Google I/O 2017 발표 이후 부터는 안드로이드 공식 언어로 코틀린도 사용됩니다.
- 코틀린 Native를 즐겨보세요! Kotlin JS 도 있습니다! (이 글에서는 Kotlin에 대해서만 다룰 예정입니다.)
- 코틀린의 목표는 더 간결하고, 더 생산적이며, 좀 더 안전하게 자바를 대체할 수 있는 것입니다.
동적 타입
- 자바는 statically typed programming language (정적 타입 언어) 이고 코틀린은 dynamically typed programming language (동적 타입 언어) 입니다.
- variable 은 많은 타입 언어를 자동으로 처리할 수 있습니다.
- 예를들면
val x = 1 // int 형으로 처리됩니다.
val s = "Hello World" // String 형으로 처리됩니다.
- 코틀린은 type 추론을 지원하고 있으며, function type 도 지원합니다!
Functional 과 객체 지향
- 자바 개발자라면 객체 지향 언어에는 친숙하겠지만 함수형 언어는 조금 생소할 수도 있습니다.
- 함수형 언어는 다음 세가지 콘셉이 있습니다.
  - First-class functions
    - 함수를 값(value)으로 사용할 수 있습니다. 변수에 저장하거나, 매개변수로 전달하거나, 다른 함수에서 반환할 수 있습니다.
  - Immutability (불변성)
    - 불변 객체로 작성할 경우, 상태를 변경할 수 없습니다.
  - No side effects
    - 동일한 입력에 대해 동일한 결과를 반환하고 다른 객체의 상태를 수정하거나 상호작용하면 안됩니다.
- 함수형 코딩으로서 코드가 좀 더 간결해지고, 쓰레드에서 안전해지고, 테스트가 쉬워집니다.
무료! 그리고 오픈소스!

코틀린 사용하기!

컴파일
- 코틀린 코드는 .kt 형식으로 되어 있으며, 컴파일러는 .class 형식으로 만들어줍니다.
- 자바와 똑같습니다!
- javac 를 사용했던 것 처럼 kotlinc 를 사용하시면 됩니다.
```
kotlinc <source file or directory> -include-runtime -d <jar name>
java -jar <jar name>
```
IntelliJ
- 다음 글을 참고해주세요 (준비중)
Android Studio
- 다음 글을 참고해주세요 (준비중)

[Vert.x] 0. Vert.x 설치하기 [리눅스 편]

루카스강 — Sat, 20 Aug 2016 17:23:35 +0900

사실 이전 포스팅이었던

Vert.x] 1. Vert.x 시작하기 - http 서버 만들기 에서는 인텔리제이 환경에서 Vert.x 를 쉽게 포함하는 방법을 알아보았었는데,

막상 리눅스 서버에서 Vert.x 를 돌리려고 하니 Vert.x 설치방법이 필요해서 급히 0번째 포스팅을 포스팅 한다.

환경은 우분투 서버 환경에서 진행하였다.

1. JDK 를 먼저 설치하자.

$ sudo add-apt-repository ppa:webupd8team/java

$ sudo apt-get update

$ sudo apt-get install oracle-java8-installer

// 버전에 맞는 jdk 를 설치하자. 최신버전인 3.3.2 에서는 jdk 8 이상이 필요하다

2. Vert.x 파일 다운로드

$ wget https://bintray.com/artifact/download/vertx/downloads/vert.x-3.3.2-full.tar.gz

// 홈페이지에서 최신 버전의 링크를 가져오자.

$ tar -zxf vert.x-3.3.2-full.tar.gz

// 다운로드 받은 .tar.gz 파일의 이름을 써주자.

// 압축이 풀리고, ls 를 입력해보면 디렉토리가 나온다.

3. 폴더 옮기기

$ sudo mv vertx /usr/local/share/

4. /usr/bin 으로 연결...

$ sudo ln -s /usr/local/share/vertx/bin/vertx /usr/bin/vertx

[Vert.x] 1. Vert.x 시작하기 - http 서버 만들기

루카스강 — Thu, 28 Apr 2016 17:05:49 +0900

안녕하세요

오늘은 Vert.x 로 간편하게 http 서버를 만들어 보겠습니다.

개발환경은 JetBrain의 인텔리제이 입니다.

먼저 Vert.x를 쉽게 추가 하기 위해서 Gradle 프로젝트를 생성해주세요.

Gradle이 설치되어 있지 않으신 분은 Preferencce - Plugins 에서 gradle 을 검색하면 쉽게 추가하실 수 있습니다.

새 프로젝트 생성을 눌러주시고 Gradle 프로젝트로 생성합니다.

JDK 는 1.7 이상 버전을 사용해주시면 됩니다.

프로젝트를 생성하려고 하면

다음과 같은 창이 나오는데 그냥 체크 하시고 다음으로 넘어가면 됩니다.

auto-import 는 말 그대로 자동으로 프로젝트에 import 를 해주는 것이고,

Create directories for empty content roots automatically 는 src 폴더를 자동으로 잡아주는 것입니다. 체크하시면 편합니다.

프로젝트를 생성하면 구조가 저렇게 생성됩니다.

뭔가 안드로이드 프로젝트와 비슷하게 생겼네요 ㅎㅎ,,

/main/java 에 Test.java 파일을 생성해줍시다.

그냥 자바 파일이 잘 컴파일 되는지 확인해봤습니다....

Vert.x 를 사용하기 위해서는 Gradle로 라이브러리 파일을 추가해주어야 합니다.

Vert.x 공식 홈페이지에 있는 메뉴얼입니다.

compile 'io.vertx:vertx-core:3.2.1'

을 gradle 에 추가해주시면 됩니다.

build.gradle 파일을 열어 다음과 같이 추가해줍시다.

추가해주는 김에 web 도 추가해주었습니다.

우리는 http 서버를 만들 것이기 때문에 web에 있는 기능도 사용할 것입니다.

복사하시기 쉽게 한번 더 보여드릴게요

compile 'io.vertx:vertx-core:3.2.1'
compile 'io.vertx:vertx-web:3.2.1'

dependencies 안에 저 두줄을 추가해주시면 gradle 에서 알아서 라이브러리 파일을 import 해줍니다.

다시 Test.java 로 돌아오겠습니다.

import io.vertx.core.Vertx;

/**
 * Created by lk on 16. 4. 28..
 */
public class Test {

    public static void main(String argp[]){
        Vertx v = Vertx.vertx();
        v.deployVerticle(new HttpServerVertical());
    }
}

Test.java 를 다음과 같이 작성해줍니다.

Vertx 의 시작은 Vertx v = Vertx.vertx(); 로 vertx 를 받아오는 것으로 시작됩니다.

Verticle 에 대해서 조금 소개를 드리자면

Vertx 에서 가장 기본이 되는 구성 요소로, 실행과 배포가 되는 기본 단위라고 할 수 있습니다.

Verticles are chunks of code that get deployed and run by Vert.x. Verticles can be written in any of the languages that Vert.x supports and a single application can include verticles written in multiple languages.

You can think of a verticle as a bit like an actor in the Actor Model.

An application would typically be composed of many verticle instances running in the same Vert.x instance at the same time. The different verticle instances communicate with each other by sending messages on the event bus.

공식 홈페이지에서는 이렇게 설명하고 있군요.

나중에 나오는 Event bus 라는 것으로 서로 메시지를 주고받고 할 수도 있습니다.

지금은 그냥 java 에서의 한 클래스 혹은 메소드라고 생각합시다.

Test 클래스의 main 함수에서는 Vertx 를 불러온 후 HttpServerVerticle 버티클을 deploy 하고 있습니다.

다음은 HttpServerVerticle 소스 입니다.

public class HttpServerVertical extends AbstractVerticle {

    Router router;
    public void start() {
        router = Router.router(vertx);

        StaticHandler sHandler = StaticHandler.create("./www");
        sHandler.setCachingEnabled(false);
        router.route().handler(sHandler);
        vertx.createHttpServer().requestHandler(router::accept).listen(8081);
    }


    public void stop() {
    }
}

HttpServerVertical 이라는 클래스를 만든 후 AbstractVerticle 이라는 클래스를 extends 해주었습니다.

start() 메서드는 버티클이 deploy 되었을 때 실행되는 메서드이고,

stop()은 반대로 버티클이 undeply 되었을 때 실행되는 메서드입니다.

vertx 를 불러온 후 createHttpServer 라는 메소드를 호출해 주었습니다.

request 에 대한 핸들러는 router 에서 accept 하도록 하였고,

8081 포트로 listen 하도록 했습니다.

router 에 대한 핸들링은 StaticHandler 에서 맡아서 하는데,

이 클래스는 Static 으로 라우팅 가능한 html 파일 등을 이용할 때 사용됩니다.

./www 안에 있는 모든 파일들을 라우팅 하도록 하였습니다.

프로젝트로 돌아온 뒤 폴더를 하나 생성해줍니다.

이름은 아까 지정해 두었던 www 로 지정했습니다.

그리고 빌드를 한 후 deploy 를 하고 http://127.0.0.1:8081 로 접속해보면...

아무것도 찾을 수 없다고 하네요.

모든 route 를 accpet 으로 해주어서 그런가 봅니다.

이번에는 www 폴더 안에 index.html 파일을 하나 생성해봅시다.

그리고 다음과 같이 hello World 를 찍어줍니다.

그리고 다시 접속을 하면...

잘 나옵니다.

a.html 이라는 파일을 추가하고, 127.0.0.1/a.html 으로 접속해보았습니다.

역시 잘 나옵니다.

Vert.x 를 이용해서 쉽게 http 서버를 디플로이 해보았습니다.

다음에는 데이터를 핸들링해봅시다.