일단 원본 영상부터, Introducing Combine 본 글은 해당 영상을 본 후 간단히 요약한 글로 블로그 주인장의 영어 실력이 좋은 편은 아니라 잘못 번역된 부분이 있을 수 있음 Why? UI 처리부터 시작해서, Ad-hoc, URLSession 등 정말 많은 비동기 처리를 하고 있다. 사용 사례들이 정말 많고 관리하는 방식이 각기 다름, 이는 사용성 및 생산성 저하로 이어지는 만큼 이를 해결하고자 하였다. Apple Foundation 팀에서는 비동기 처리 후 나오는 값들을 시간이 지남에 따라 변하는 값으로 정의하였고, 이를 처리하기 위한 통합 선언형 API, Combine을 만들었음 Combine Pub-Sub 형태의 비동기 처리 API로 Publisher와 Subscriber, Operato..
일단 원본 영상부터, Meet async/await in Swift 본 글은 해당 영상을 본 후 간단히 요약한 글로 블로그 주인장의 영어 실력이 좋은 편은 아니라 잘못 번역된 부분이 있을 수 있음 Why? 전통적인 Swift 코드에서는 비동기 동작에 대해 completionHandler를 이용하였음, 이는 다음과 같은 문제가 있었는데 해당 패턴에서는 중첩 클로저가 많아지고 이로 인해, 클로저들의 error를 관리하기 어려울 뿐 아니라 이로 인해 추적도 어려워짐 뿐만 아니라, 비동기 시스템의 종료를 명확하게 판단 할 수 없는 상태가 됨 이를 개선하는 목적으로 등장한게 async - await, 그래서 전통적인 비동기 처리 방식 대비, 훨씬 간결한 코드를 가지게 됨 비동기 처리를 한 라인에서 한 번만 발생시..
보호되어 있는 글입니다.
최근에 개인 프로젝트를 하면서, workflow를 작성할 일이 있어 정리한 내용들을 가지고 왔다. 공식 문서를 보면서 작업을 했지만 문서 내에 있는 내용들을 전부 블로그에 옮기는 것보다 우선적으로 많이 사용하는, 실제로 사용했던 필드들을 기준으로 가지고 왔다. 한 번 세팅해 두면, 생산성뿐 아니라 여러모로 편리한 만큼 많은 Git을 사용하는 거의 모든 회사들이 Github Action을 사용하고 있지 않나 싶다. Github Action을 사용할 때 작성하게 되는 workflow 파일들에 대해서, 오늘은 좀 다뤄보고자 한다. 그중에서도, workflow에서 자주 사용하거나 필수적으로 작성해야 하는 필드들을 먼저 가지고 왔다. Workflow? 서론에서도 살짝 다뤘듯, Github Action에서 일어나는..
Structures and classes are general-purpose, flexible constructs that become the building blocks of your program’s code. You define properties and methods to add functionality to your structures and classes using the same syntax you use to define constants, variables, and functions. Struct와 Class를 통해 요소를 유연하게 구성할 수 있다. 클래스 안에 method와 property들을 일반적인 상수, 변수, 메소드 정의하듯 정의하여 사용 할 수 있다고 한다. struct와 cl..
보호되어 있는 글입니다.
일요일 하루는 여유롭게 보내고, 새로 시작하는 마음으로 들고온 금주의 첫 주제는 OOP와 POP 그리고 AP이다. iOS 개발자라고 했지만, 부끄럽게도 POP라는 단어를 안지 얼마 되지 않았다. 무려 WWDC2015에서 언급된 단어인데! 몰랐던 건 몰랐던 대로 앞으로 알아가면 되지 않을까? 하며 본격적으로 오늘의 글을 시작한다. OOP? 많은 시간 동안 프로그래밍 패러다임이었던 객체 지향 프로그래밍을 의미한다. C 중심의 절차지향 프로그래밍에서 유지보수성과 과도하게 늘어나는 명령어들을 효율적으로 처리하기 위해 등장한 방식인데, 처음 등장했을때는 하드웨어 성능 등의 이유로 주목받지는 못했었으나, GUI가 본격적으로 등장하면서 주목을 받았다고 한다. 객체를 중심으로 하는 프로그래밍인데, 비슷한 것들을 모아 ..
오늘은 토요일인 만큼 조금 가벼운 주제로 써볼까 한다. 이번 주에는 동시에 진행하는게 너무 많아서 사실 좀 힘든 한 주였다. 3시 언저리에 잠들어서, 6시 50분 알람을 듣고 7시 즈음 일어나는 한 주 당연히 빨래도 밀리고 청소도 제대로 못하고 심지어는 잠 부채가 쌓여서 오늘 아침에는 늦잠을 잤다! 그치만 기분은 좋았다. 청소를 하는데, 문득 리팩토링 생각이 났다. 급하다고 미뤄두다 보면 조금씩 쌓이는 먼지와 머리카락처럼 급하다고 구분 없이 막 짜기 시작하면, 어마어마한 부채가 되어 다가오는 소스코드들.. 빨래가 밀리기 시작하면, 정작 급할 때 필요한 양말과 속옷들을 찾기 어려워지는 것 처럼 빠르게 간다는 이유로 기본적인 구분부터 안하기 시작하면, 정작 다음에 급할 때는 오히려 앞선 작업들이 발목을 잡는..
보호되어 있는 글입니다.
- Total
- Today
- Yesterday
- 코드리뷰
- techincal
- combine
- IOS
- flutter
- 개발자
- viewcontroller
- writing helpful error message
- Provider
- lifecycle
- WWDC
- UIKit
- 기술블로그
- Async
- github
- 테크니컬라이팅
- guri's dev
- 개발문화
- document
- getx
- Equatable
- 주저리주저리
- struct
- protocol
- POP
- 리팩토링
- message
- Swift
- OOP
- await
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | ||||||
2 | 3 | 4 | 5 | 6 | 7 | 8 |
9 | 10 | 11 | 12 | 13 | 14 | 15 |
16 | 17 | 18 | 19 | 20 | 21 | 22 |
23 | 24 | 25 | 26 | 27 | 28 |