분류 전체보기

프로젝트를 진행하던 도중 문제가 발생했다!!! :) 문제는 SwiftData에서 발생했다. 😂 진행 상황아래와 같이 Clean Architecture의 형태로 만들고 있었는데 Entity, Data, UseCase, Store까지 쭈욱 코드를 작성해나가고 있었다. API 호출 관련 부분까지는 문제가 없었는데... 위와 같이 구현하게 된다면, SwiftData를 Entity로 써야 하는데, SwiftData의 ModelContext가 View로부터 분리가 힘들다는 문제점에서 발생했다. SwiftData는 ModelContext를 @Environment(\.modelContext) private var context 처럼 View에서 가져오는 방법밖에 없었다. 그렇게 된다면 Use case는 반드시 Vie..

사용할 API 정리 아래의 공식문서를 참고하여 앱에 필요한 API를 정리했다. @solvedac/unofficial-documentation 이 프로젝트는 solved.ac API를 문서화하는 커뮤니티 프로젝트입니다. 이 저장소는 원작자의 요청에 따라 언제든 지워질 수 있으며, 현재 API와 일치하지 않을 수도 있는 점 양해 부탁드립니다. solvedac.github.io 앱의 MVP 설정 및 기본 플로우 아이디를 입력하면 내 Solved.ac아이디를 기준으로 내 정보를 보여주는 것이 이 앱의 MVP이다. 알고리즘 공부 시간, 친구 추가, 경쟁 등 다양한 기능을 넣어보고 싶었지만 우선 아래와 같은 최소한의 기능만 우선 구현해 보기로 했다. Widget, Watch앱도 간단하게 만들어볼 예정이다. (이 부..

문제 소개 6064번: 카잉 달력입력 데이터는 표준 입력을 사용한다. 입력은 T개의 테스트 데이터로 구성된다. 입력의 첫 번째 줄에는 입력 데이터의 수를 나타내는 정수 T가 주어진다. 각 테스트 데이터는 한 줄로 구성된다.www.acmicpc.net진법과 아주 비슷한 개념인데 진법은 위로 쌓아가지만 위의 카잉 달력은 해당 숫자가 넘으면 다시 1로 시작한다는 차이점이 있다. 풀이 방법m, n, x, y가 주어지는데 아래와 같이 볼 수 있다. 결국 a와 b를 구하라는 뜻인데, 단순하게 a를 0부터 차례로 대입해나가면 된다. 그리고 최대 연도(종말 연도)는 m과 n의 최소공배수로 볼 수 있다.year % m = xyear % n = yyear = ma + xyear = nb + y 내가 작성한 코드는 아래와 ..

시작에 앞서 지난번에 MVC 패턴을 공부하다가 Flux 아키텍처에 대해 알게 되었고, 과연 페이스북은 MVC의 Massive View Controller라는 문제를 어떻게 해결했을까? Flux 공식 홈페이지 Flux에 대한 공식 홈페이지가 있었다! Flux에 대한 대략적인 설명, React를 사용한다면 어떻게 Flux아키텍처를 적용할 수 있는지, Github 레포지토리, 가이드 등이 나와있다. Flux | Flux Application architecture for building user interfaces facebookarchive.github.io Facebook이 찾은 MVC의 문제점 9년 전에 Facebook에서 발표한 Flux소개 영상이다. 이 영상을 요약해 보자면 초기에 MVC는 문제가 없..

이전 상황 이전 상황은 아래와 같았다. API를 사용하여 Solved.ac에 있는 유저정보를 가져오고 데이터 저장은 SwiftData를 활용하여 구현하기로 했다. 그리고 선택한 프로그램 아키텍처는 Clean Architecture이다. (잘 적용할 수 있을지 모르겠다...) 클린 아키텍처 무려 로버트 C. 마틴(엉클밥 또는 밥아저씨라고도 불리는...) 선생님이 2012년에 작성하신 글이다. (10년도 더 된...) 12년된 글을 보면서 현재의 가장 최신 SwiftUI, SwiftData를 사용하면서 적용하는 나라니... 참 작아진다. Clean Coder Blog The Clean Architecture 13 August 2012 Over the last several years we’ve seen a ..

내가 여러 가지 강의도 찾아보고, 많은 글도 읽어본 결과 MVC, MVP, MVVM은 UI를 어떻게 표현할지에 대한 디자인 패턴에 가깝다고 느꼈다. 그 이유는 맨 마지막에 써보도록 하겠다. 많은 곳에서 MVC, MVP, MVVM에 대해 말하는 것이 조금씩 다른데, 공통적으로 말하는 큰 본질 부분을 정리해 보려고 한다. 디자인 패턴은 추상적인 컨셉이나 아이디어에 가깝기 때문에 실제 구현은 일부사항이 달라질 수 있기 때문에 모두가 조금씩 다르게 설명하는 것 같다. 물론 코딩에 대한 경력이 너무너무 적기 때문에, 설명이 부족할수도 있고, 틀릴 수도 있지만 그래도 최대한 이런 글을 작성해보고 싶다는 생각이 들었다. 나중에 이 글을 보게 된다면 그때는 이런 생각을 했구나 알 수도 있고... 우선 시작은 이렇다. ..

프로젝트를 시작하기에 앞서 여러가지 세팅할 것들을 세팅했다. 앱 이름 우선 프로젝트를 시작하려면 프로젝트의 이름을 설정해야 파일도 만들고, Github Repository도 만들수 있어서 앱 이름부터 결정하게 되었다. Solved.ac 와의 연관성과 뜻을 고려하여 Solver 라는 간단한 앱 이름을 우선 설정했다. 앱 디자인 및 기획 앱 디자인의 경우 최대한 기본 컴포넌트를 활용하여 만들것이고, 어떠한 정보를 표시할지, 어떻게 화면에 표시할지는 개인프로젝트의 장점(?)을 살려 프로젝트 생성후 빠르게 기획할 예정이라 우선 프로젝트부터 생성하였다. 커밋 룰 레포지토리는 public으로 할 예정이고, 커밋은 gitmoji를 활용하여 영어로 작성하기로 했다. gitmoji의 경우 아래의 룰을 따르기로 했다. g..

문제 소개포도주 잔을 2잔 연속해서 마실수있고, 주어진 n개의 포도주의 양중에 최대로 마실수 있는 포도주의 양을 출력하는 문제이다. 문제 풀이와인을 마실경우를 O라고 생각하고 마시지 않을 경우를 X라고 생각하면 앞을 고려하지 않는다면 다음과 같은 경우가 최대가 될 것이다.하지만 여기서 문제가 있다. 1번 2번 케이스일 경우 앞에서 어떠한 케이스인지 모르기 때문에 함부로 2번 연속해서 마시거나 1번 마실수가 없다. 이미 앞에서 마셨을수도 있기 때문이다. 그렇다면 1번 2번 케이스의 X의 앞을 살펴보면 가장 최선의 선택을 했을 경우라는 것을 볼 수 있다. 그렇다면 이렇게 생각해보면 어떨까? 내가 생각하기에 다이나믹 프로그래밍은 "내가 계산한 값에 대한 믿음" 이다. 내가 앞에서 계산한 값이 무조건 최선이라고..