왕.. 거의 2달만에 블로그에 글을 쓴다. 그간.. 마지막 활동인 팀 프로젝트를 진행한다고 정신이 없었기에.. ^^.. 앞으로 다시 열심히 써야징 ~.~오늘은 지난 회고에 이은 나머지 기간의 회고와 네부캠 9기를 진짜. 완전. 찐. 수료한 소감 및 앞으로의 계획을 비루하게나마 작성해보려한다. 기억은 진짜 빠르게 휘발되기 때문에 학습정리는 아주 살짝 미뤄두고 회고부터.. (절대 학습정리 하기 싫어서 미루는 거 아님 ~ )저번 회고를 어디까지 썼는지 기억이 안나서 한 번 읽고 왔는데 그래도 학습스프린트까지는 회고를 다 끝냈네 ~ 대단한걸 ~ ? 그런 의미로 그냥 바로 팀 프로젝트 회고부터 고고띠예 ~위에서 말했듯 10월 말부터 6주간 팀 프로젝트를 진행했다. 팀은 부캠에서 랜덤으로 정해줬는데, 정말.. 스프..

아침에 9시부터 일어나서 바로 학습정리 중이다..레전드 갓생.. 하지만 블로그 글이 올라가는 시간은 12시.....껄껄 ~오늘은 Task에 대해서 알아볼 예정이다.ᐟ.ᐟ 왜냐 ~ 그냥 ~Apple 공식문서에 따르면 Task는 비동기 작업의 단위를 의미한다.모든 비동기 코드는 task의 한 부분으로서 실행된다.Task는 한 번에 하나만 실행될 수 있는데, Task를 여러 개 만듦으로써 Swift가 여러 개의 Task를 동시에 실행시킬 수 있도록 스케줄링할 수 있다.init(priority: TaskPriority?, operation: sending () async -> Success), init(priority: TaskPriority?, operation: sending () async throws -..

오늘은 WWDC21 - Protect mutable state with Swift actors를 보며 Actor에 대해 파헤쳐 볼 것이다 !아직 Concurrency도 잘 못다루는 나이기에 .. 조금 두렵지만 ... 레쭈고 ~Actor의 탄생 배경Data race는 동시성 프로그래밍을 하는데 가장 신경쓰기 어려운 오류 중 하나이다. Data race는 보통 두 개의 서로다른 스레드가 동시에 mutable한 데이터에 접근하는 과정에서 발생한다.이러한 Data race는 발생하기는 꽤나 쉽지만 개발자가 디버깅을 하기에는 굉장히 까다로운데, 보통 Data race를 유발하는 데이터 접근이 프로그램의 서로 다른 부분에서 이루어질 확률이 높고 이 때문에 개발자가 디버깅을 하기 위해서는 비지역적 추론이 필요하기 때..

끝나지 않을 것만 같았던 학습 스프린트 8주가 마무리되었다.ᐟ.ᐟ 물론.. 아직 완전 수료한 것도 아니고 이제 그룹 프로젝트라는 큰 산이 하나 남았지만.. 그래도 일단 한 스탭 마무리하는 느낌으로 회고를 해보려한다 !(실은 매주 회고를 작성하려했는데.. 너무 자주 회고를 하니까 반복되는 피드백 + 그렇게 의미있는 회고가 아닌 느낌 + 주인장의 게으름 이슈로 오랜만에 회고 글을 쓰는 것이다.)3주차 이후로 멤버쉽 회고를 오랜만에 쓰는 것인데 여태 어떻게 뭐하고 지냈냐 ! 하면.. 일단 오프라인 신청을 해서 직접 나가서 활동도 하고 캠퍼분들도 직접 뵀었다. 오프라인을 하면서 캠퍼분들과 같이 코딩을 하니까 뭔가.. 혼자 집에서 할 때보다 원동력을 더 얻는 것 같은 느낌을 받았다. 바로 옆에 같이 미션을 하는 ..

다음주에 코디네이터 패턴을 활용할 일이 생길 예정인데 내가 너무 코디네이터 패턴에 대해 무지한 것 같아서 이렇게 정리해보는 글을 써보며 예습하는 시간을 가져보려한다.코디네이터 패턴의 시작코디네이터 패턴은 Soroush Khanlou 라는 분의 한 아티클에서 시작했다고 한다.Khanlou 선생님..ㅎㅎ해당 글을 읽어보면 알 수 있는데, 간단하게 요약해보자면 다음과 같다.UIViewController도 하나의 View 객체이다.이러한 View 객체가 사용자의 흐름(다음 화면으로 화면전환을 하는 일)을 처리하는 것은 View의 역할 범위를 넘어섰다 !따라서 ViewController 자체를 하나의 고수준 객체(coordinators or directors)로 보고 이를 총괄하는 하나의 객체를 가지면 역할 분리..

허허.. 오랜만에 블로그 글을 쓰러 왔다...최근에 회고도.. 잘 안썼는디.. 회고를 일주일 단위로 하려니 뭔가 눈에띄는 성과가 없는듯 하여.. 스프린트 단위로 회고를 하면 좋을 것 같다는 생각으로 안하게된... (맞습니다 이건 그냥 핑계일뿐.. 그냥 미룬겁니다 ^_^)무튼 오늘 써볼 이야기는 Property wrapper에 관한 이야기이다.장대한건 아니고 멤버쉽에 들어와 동료분들이 Property wrapper를 사용하시는걸 보고 나도 사용해보고싶다는 생각으로 찾아보게 되었다.Property wrapper는 Swift5.1에서 처음 나온 문법(?)이다.이걸 사용하면 프로퍼티에서 get{}, set{} 설정하는 부분을 struct 혹은 class 로 만들어두고 프로퍼티의 속성을 미리 정해둘 수 있기 때문..

저번 글에 언급해둔바와 같이 이번엔 UIResponder에 대해 알아볼 것이다.공식문서를 한 번 확인해보자 !이벤트 응답 및 처리를 위한 추상 인터페이스라고 한다.이 UIResponder 인스턴스가 바로 저번 글에서 주구장창 나오던 responder 객체이다.이벤트가 발생하면 저번 글에서 봤듯이 UIKit이 지정한(혹은 개발자가 직접 지정한) responder 객체로 이벤트를 보내서 처리하게된다.이 responder 객체가 이벤트를 처리하기위해서는 적절한 메소드들을 오버라이딩하여 처리해줘야한다. 예를 들어 Touch 이벤트가 일어나면 touchesBegan(_:with:), touchesMoved(_:with:), touchesEnded(_:with:), touchesCancelled(_:with:) ..

원래는 UIResponder에 대해 알아보려했는데, UIResponder를 알아보기 전 아이폰에 이벤트가 발생하면 어떤 식으로 처리되는지를 먼저 알아보면 좋을 것 같아 Using responders and the responder chain to handle events라는 아티클을 읽고 이해해보는 시간을 선행해서 가져보려고 한다.Handle events앱은 responder 객체를 사용해서 앱에서 이벤트를 받거나 처리한다.이 responder 객체란 UIResponder 클래스 인스턴스 혹은 UIView, UIViewController, UIApplication을 포함한 여러 UIResponder의 서브클래스들을 말한다.이 responder들은 이벤트를 받으면 그걸 그 자리에서 처리하거나 다른 resp..