Keep the Experience Natural, Easy, Light

#1 알고리즘#1-1 탐색 문제누가봐도 탐색 문제처럼 생겼다. 그렇다면 어떤 탐색을 수행할 것인가? #1-2 탐색 목표RRRBBGGBBBBBBRRBBRRRRRRRR나는 위 테스트 케이스에서 각 알파벳 하나씩을 순회하며, 1113322333333443344444444∴ 색맹 아닌 기준으로 구역의 수는 총 4개와 같은 식으로 변경할 것이다. '인접한 같은 색'끼리는 같은 숫자를 공유하고, '인접한 다른 색'은 서로 다른 숫자를 지닌다. 이렇게 만들려면, 인접한 다른 색으로 가기 전에 먼저 인접한 같은 색에 서로 같은 숫자를 마킹하는 로직이 필요하다. #1-3 Deque 활용 Double-ended queue - WikipediaFrom Wikipedia, the free encyclopedia Abstrac..

#1 개요프로젝트의 데이터베이스(Room) 부분에서 작성했던 DAO 함수의 논리적 오류를 해결한다. #2 논리적 오류 - ORDER BY#2-1 문제 코드...@Daointerface MainDAO {    ...    @Query("SELECT * FROM DayMealView")    suspend fun getAllDayMeals(): List    @Query("SELECT * FROM DayMealView LIMIT :limit")    suspend fun getAllDayMeals(limit: Int): List    @Query("""    SELECT * FROM DayMealView     WHERE day_date     @Query("SELECT * FROM DayMealView W..

#1 알고리즘#1-1 직관적인 풀이와 그 한계#3-1에 있는 50점 짜리 코드는 누구나 생각할만한 직관적인 풀이다. 문제는, L이 큰 경우다. L이 큰 경우는 나머지 연산을 연산 중간 중간에 끼워서 수가 너무 커지지 않게 조절해야 한다. 하지만, 예를 들어 L이 30이라면 3130라는 엄청나게 큰 수를 계산해야하는데 이건 말이 안 된다. 따라서 이 문제는 #3-1에 있는 직관적인 풀이가 아닌 새로운 방식으로 풀어야 한다는 분위기를 풍긴다. 다행히, 문제의 힌트에서 무언가가 보인다. #1-2 힌트abcde의 해시 값은 1 × 310 + 2 × 311 + 3 × 312 + 4 × 313 + 5 × 314 = 1 + 62 + 2883 + 119164 + 4617605 = 4739715이다.반복되는 숫자가 눈에..

#1 문제#1-1 문제 상황정렬된 아이템이기에, 각 아이템의 시각은 위에서 아래로 갈수록 작아져야한다. 그러나, mealId 41인 아이템과 mealId 50인 아이템을 보면 이상한 점이 보인다. 바로 mealId 50인 아이템의 시각은 18:01:14...로, 17:09:03...인 mealId 50보다 큰 것이다. #1-2 문제 코드...@Composablefun NutrientScreen( ...) { LaunchedEffect(key1 = true) { ... } LaunchedEffect(key1 = true) { ... } LaunchedEffect(key1 = viewModel.isInitialized.value) { if..

#1 개요이전 게시글의 Commit은 앱 실행이 안되는 버그가 있다. 해당 버그를 발생시킨 근본적인 부분을 찾아간다. 특히, 세번째 에러는 Room의 무결성과 관련된 에러로 해결까지 꽤 시간이 소요됐으며, 동시에 Room 구현에 있어 DAO를 경솔히 작성해서는 안된다는 교훈을 내게 주었다. #2 코드 - 첫번째 에러#2-1 NoSuchElementExceptionFATAL EXCEPTION: main (Ask Gemini)Process: com.example.nutri_capture_new, PID: 7679java.util.NoSuchElementException: List is empty. at kotlin.collections.CollectionsKt___CollectionsKt.last(_C..

#1 개요이전 게시글에서 채팅 UI 도입을 위해 가상 테이블 DayMealView를 만들었다. 백엔드 작업이 끝났으므로, Day 테이블 및 Meal 테이블을 참조하던 프론트가 이제는 DayMealView 테이블을 참조하도록 만들어야 한다. #2 코드 - 백엔드 깨알 변경 사항#2-1 DAO에서 getAllDayMeals(limit: Int) 선언...@Daointerface MainDAO { ... @Query("SELECT * FROM DayMealView LIMIT :limit") suspend fun getAllDayMeals(limit: Int): List ...}존재하는 모든 레코드를 가져오는 getAllDayMeals()의 메소드 오버로딩이다. getAllDayMeals(..

#1 알고리즘#1-1 '최단 거리'의 의미이 문제에서 '최단 거리'란, '목표 지점(2)으로부터 한번 움직일 때마다 +1한 값'이다. 1차원에서는 간단하다. 검은색 선의 길이와 '최단 거리'가 비례하기 때문이다 (이미 방문한 지역은 다시 방문하지 않는다). 2차원이라면 문제가 복잡해진다. 선의 길이와 '최단 거리'가 비례하지 않는다. 2에서 1로 가는 빨간색 선은 '최단 거리'면서 동시에 '목표 지점(2)으로부터 한번 움직일 때마다 +1한 값'이다. 초록색 선은 '최단 거리'는 아니지만, 빨간색 선과 마찬가지로 '목표 지점(2)으로부터 한번 움직일 때마다 +1한 값'이다. 정리하면, 2차원에서 '최단 거리'는 반드시 '목표 지점(2)으로부터 한번 움직일 때마다 +1한 값'이지만, 역으로 '목표 지점(2)..

#1 개요#1-1 우아함이전 게시글에서 만든, 가상 테이블을 참조하는 DAO 함수는 가상 테이블의 모든 레코드를 통째로 가져오는 방식이었다. 하지만 이는 우아함과는 거리가 있는 방식이다. 처음에는 화면을 가득 채울 정도의 레코드만 가져오고, 무한 스크롤을 통해서 필요한 만큼만 또 가져오는 방식을 구현할 것이다. "View가 보유한 마지막 레코드가 무엇인지 알고, 해당 레코드를 기반으로 (테이블 위치 상) 더 뒤에 있는 레코드들을 뽑아오면 될 것이다."라고 처음에는 간단하게만 생각했다. 그러나 시행착오를 겪으며 시간이 오래 걸렸다 (고작 DAO 함수하나 만드는 건데 이전 게시글과 별도의 게시글로 분리할 이유기도 하다). #1-2 첫 시도: Cursor Room DAO를 사용하여 데이터 액세스  |  And..

#1 알고리즘#1-1 그리디 알고리즘을 적용할 수 있는가? 그리디 알고리즘 (Greedy Algorithm)#1 알고리즘#1-1 개요while(정답 도출) { 현 시점 가장 좋아 보이는 선택}눈 앞의 이익만 추구(= Greedy(탐욕스러운, 욕심 많은))하는 방식의 접근법을 말한다. 위 코드의 형식을 갖추기만 하면 그리디kenel.tistory.com위와 같은 그리디 알고리즘을 구현하면 일단 (정답인지 아닌진 몰라도) 일단 풀리긴할 것 같이 생긴 문제다. 하지만, 그리디 알고리즘을 적용할 수 있는 지에 대한 확신이 들지 않는다. 이 문제가 그리디 알고리즘임을 증명할 수 있다면, 마음 편히 그리디 알고리즘을 적용해 풀 수 있을테다. 따라서, 이 문제에서 최선의 선택이 곧 최적해가 되는 지의 여부를 증명해보..

#1 개요#1-1 채팅 UI 구현을 위한 첫 걸음'채팅 UI'에서 표시할 데이터를 하나의 레코드로서 가지는 가상 테이블을 선언한다. #1-2 가상 테이블 (SQLite)SELECT day_table.day_id AS day_id, meal_table.meal_id AS meal_id, day_table.day_date AS day_date, meal_table.meal_time AS meal_time, meal_table.meal_name AS meal_name, /* NutritionInfo의 Column 시작 */ meal_table.overeating_excess AS overeating_excess, meal_table...