안녕하세요 거진 2주반만에 돌아온 킴스캐슬입니다 글을 쓰려고 보니 저번포스팅을 하고나서 블로그를 좀 오래쉬었네요... 지금 진행하고있는 프로젝트 리팩터링을 하는데에 집중하느라 이런저런 글을 못썼네요 써야할글이 한 3개정도가 있는데 부지런히 써야곘네요 요즘 알고리즘 공
그래서 아마도 지금 제목이 Cancellable이지만 combine에서 실제로 cancel이 어떤 로직으로 작동하는지에 대한 아주아주 깊은 내용이 될겁니다 물론 우리는 combine의 실제 내부코드는 모르기때문에 combine의 요소들을 구현해놓은 open combi
안녕하세요~ combine의 cancellable 두번째 포스팅입니다저번포스팅에서는 cancel의 내부 작동방식에 대해서는 말씀드리지 않았고 그냥 단순이 머릿속에서 떠오르는cancel을 실행하면 publisher와 subscriber의 stream이 끊긴다!정도의 추상
안녕하세요! 오랜만에 또 포스팅 글을 적는 느낌이네요...(쓸건많은데말이죠)이번 포스팅에서는 combine의 operator에 대한 내용을 가져와봤습니다 combine의 operator는 정말 종류가 많습니다 map, filter, zip, scan, reduce...
combine의 flatmap은 뭔가 다른가? 싶더라고요 그래서 이런 궁금증을 풀기위해서 이런 주제로 포스팅을 작성하게 되었습니다 combine의 flatmap은 내가 알고있던 flatmap이랑 다른데? combine의 flatmap을 왜 비동기 처리할때 쓰는거지?
공식문서를 보면 `다른 publisher로 대체하므로써 업스트립 publisher의 error를 handle하는 친구라고 합니다` 이 설명이 조금 어려울수도 있는데 업스트립에서 error가 발생하면 catch가 return해주는 publisher를 downstream과
결국 catch는 catch를 호출한 upstream과 downstream을 연결시켜줄지 아니면 catch의 recovery Publisher와 downstream을 연결시켜줄지를 결정해주는 역할을 하는 operator다 라는 결론을 드디어 내릴수있게되었습니다 ㅎㅎ…
기존 MVC의 프로젝트를 MVVM으로 리팩터링을 준비하는 과정에서 유저의 input에 의해 변화하는 변수를 @Published로 만들어서쓸지 아니면 subject로 쓸지를 고민하게 되었습니다. 처음에 제 머릿속에 들었던 방식은 @Published를 만들어서 쓰는 방식이
본 포스팅은 실제로 Unit test를 한 결과와 방법에 대한 글이 아닌 Unit test를 위한 아키텍처 설계에 관한 생각을 담은 글임을 미리 알려드립니다
안녕하세요closure에서 왜 대체 self를 써야하는가에 대한 고민을 마치고 돌아온 킴스캐슬입니다
안녕하세요!!이번엔 싱글톤에 대한 오해와 사실?이라는 주제를 가지고온 킴스캐슬입니다
오늘은 Dependency Injection을 위한 Container를 구현해보자라는 주제를 가지고 온 킴스캐슬입니다
직전 포스팅의 주제가DI Container를 구현해보자라는 주제였는데요사실 저번 포스팅에서 해결을 못했던 부분(memory leak이 발생하는부분)을 그때당시에는 어쩔수없으니까 swinject를 써야겠다고 생각을 하고 마무리했었는데 요 며칠 계속 찜찜하더라고요
하지만 밑에보면 이런말이있습니다 `Unlike delegation, the strategy pattern uses a family of objects.` delegate와 다르게 strategy는 객체의 famaily를 사용한다. 여기서 약간의 힌트를 얻게되었습니다.
조금 쉽게이야기해보면 "하나의 어플리케이션을 어떤 계층으로 나눌래?" 혹은 "이 계층들을 어떤식으로 조합할래"에 대한 답이 아키텍처라고 말할수도있을거같습니다 MVC라는 아키텍처는 `저는 어플리케이션을 Model, View, Controller라는 계층의 조합으로 설계
누군가가 말하는 MVC가 Massive하다는건 애플의 cocoa MVC 특성상 어쩔수없었던것이었고 애플이 예상못한 부분은 아니었습니다(uiviewcontroller의 역할을 보면 알 수 있죠) 과연 이게 진짜 문제라고 말할수있는걸까요?MVC에 문제가있어서 MVVM이
안녕하세요 킴스캐슬입니다:) 오늘은 memory leak이슈를 해결하다가 지금까지 weak self만 써봤지 unowned self를 써본적이없어서 갑자기 unowned는 왜 있는거지?라는 의문이 들어서 공부한 내용들을 가져와봤습니다 ㅎㅎ 늘 그랬지만 오늘은 내용이 좀
안녕하세요 킴스캐슬입니다:) 오늘은 제가 프로젝트를 진행하는데 있어서 알게된 내용(사실은 흠씬 맞아보고 깨달은 내용)에 대해 아티클을 적어보려합니다 제목은 위에 적은것처럼 async let이 항상 정답은 아니다 입니다 (아니다! 라고 했지만 아닐수도 있다고 생각합니다
안녕하세요 킴스캐슬입니다오늘 날짜는 12월 24일 크리스마스 이브입니다:)모두 메리크리스마스 하시고 오늘은 플러그인패턴이라는 주제로 글을 써보려고 합니다저번달에 Let'swift에 가서 직접 듣지는 못했고 같이 갔던 동료분이 들었던 내용을 요약한 글을 봤는데 살짝만 들
안녕하세요 연말을 맞이하여 열심히 글을 쓰고있는 킴스캐슬입니다 오늘은 tuist 4.x.x을 사용하면서 마주했던 경고메세지를 통해 알게된 제 나름대로의 결론(?)에 대해 적어볼까합니다. 솔직히 노션에 정리해놓은 이 글을 블로그에 써도 될지 고민을 많이 했습니다. 이유
안녕하세요 새해 첫 글로 신입 개발자 시리즈를 적고있는 킴스캐슬입니다 저번글은 저번주에 들어온 신입이 문서화를 하자고 했다 였는데 그때는 정말 저번주에 들어온 신입이었고 오늘 기준으로는 저번달에 들어온 신입이어서 제목을 이렇게 지었습니다 ㅎㅎ... 소제목은 swift