
1. 개요mobile 에서는 CI-CD 로 TeamCity 를 사용하고 있었음. TeamCity 는 EC2에 띄워져 있고 로컬 빌드머신에서 커맨드를 수행하고 있었고, fastlane 으로 빌드/배포 작업이 진행되었음.그런데 가끔 TeamCity 가 고장날때가 있었는데.. 히스토리 인프라쪽을 건드려야 하기 때문에 서버팀의 도움을 받아 고쳤었는데, 가끔 이렇게 유지보수에 신경 써야하기도 하고, mobile 팀에서 자체적으로 유지보수가 어렵다는 점에서 다른 방안이 필요하다고 팀원들과 공감대를 형성해왔고 그 대안은 Github Action 이 유력했음!iOS, Android 모두 Github 을 잘 활용하고 있었음관련 자료들도 많음EC2 필요없음그런데 Github Action 은 기본적으로 원격에서 돌아가는데,..

1. 개요예전에 TCA 를 사용해본적이 있는데 내가 느끼기에 장단점이 뚜렷하다고 생각이 들었다.장점단방향 플로우로 디버깅과 사이드 이펙트 처리가 편했음MVVM 이나 MVP 같은 패턴은 사용하는 사람이나 회사 따라 사실상 구조가 다 다른데 TCA 는 모두가 비슷한 구조의 코드를 강제(?)할 수 있음단점러닝커브가 있음외부 라이브러리에 의존해야 함컴파일러가 일을 잘 못하는 포인트가 있는듯새로운 바닐라 프로젝트에서 시작했기 때문에 적용에 크게 애를 먹지는 않았고, 개발할때의 경험도 나쁘지 않았다. 특히 단방향 플로우의 아키텍쳐를 처음 경험해봐서 그런지 모르겠지만, 유저의 액션을 통합해 관리하고 결과 혹은 사이드이펙트로 처리하는 플로우가 잘 읽힌다고 느꼇었다.하지만 아키텍쳐를 외부 라이브러리에 의존해야 한다는 부..
1. 개요사이드프로젝트에서 채팅을 구현했었다. 양방향 통신, 즉 웹소켓은 처음 사용해봐서 구현하기 전에 설렛던 기능이다. 어려울줄 알았는데, STOMP 프로토콜을 사용해서 어렵지 않게 구현할 수 있었다.2. STOMP 란?WebSocket 이 양방향 통신을 열어주고, 각 프레임이 전송된다고 했을 때, STOMP 는 그 프레임에 대한 프로토콜이다. 마치 Http 통신과 그 위에 있는 REST 의 개념이랄까.WebSocket 만을 사용한다면, 어떤 메시지를 누구에게 보내고 어떻게 구독할지? 서버-클라이언트간의 프로토콜을 직접 만들어 소통해야 되는데, STOMP 는 메시징을 위해 약속을 미리 정해주었고, 그 약속에 맞춰 서버와 클라이언트가 통신을 하도록 되어있다.특별히 Connect, Subscribe, Me..
- Total
- Today
- Yesterday
- audiokit
- IOS
- open-api-generator
- ios채팅
- 맥북에어 m4
- audio kit
- SwiftUI
- swiftui 제스처
- ios 다국어
- flo
- swiftui 탭
- 애플워치 데이터 전송
- string catalog
- onTapGesture
- DateFormatter
- AVFoundation
- Swift
- easy cue
- avplayer
- swift audio
- Xcode15
- openapi-generator
- keyboardtype
- ios웹소켓
- highprioritygesture
- Github action
- watch connectivity
- swift날짜
- self-hosted-runner
- demical
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
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 | 29 | 30 | 31 |