[2020 SUMMER let us: Go!] 요약

Updated:

2020 SUMMER let us: Go!

  • 2016년 가을 하이퍼 커넥트에서 진행됐던 비정상 토크 모임
    • 이후 매년 봄, 여름, 가을 행사
    • 올해는 코로나 때문에 웨비나로 진행




Hello, SwiftUI!

  • Speaker: 야곰

Whats’s New in SwiftUI (2020)

  • 아직 실무엔 부족하지만 몇 년 후면 실무 사용 가능할 듯하다
  • UI 컴포넌트 추가하면 자동으로 코드 추가
  • Progress View
  • List
    • Child 메뉴 넣을 수 있음
  • Label
    • 자동으로 테스트, 이미지 보여줌
    • URL
  • Grid - Collection View

Points in SwiftUI

SwiftUI는 선언형 UI

  • 기존 UIKit
    • 버튼을 추가하고 속성을 변경해서 버튼의 모양을 바꾼다
  • 데이터가 바뀌면 자동으로 갱신된다
    • 버튼의 값이 바뀌면 자동으로 버튼 모양이 바뀐다
    • 버튼은 데이터에 따라서 표현이 될 뿐이다

SwiftUI사용하는 앱의 구조

  • APP
    • Scene
      • View
    • Scene
      • View
      • View
    • Scene
      • View
      • View
  • Scene: 기존의 window 개념
  • 하나의 앱이 여러 개의 씬을 가질 수 있다
  • 씬은 여러 개의 뷰로 표현
  • Source of Truth
    • @Published 어노테이션
    • @ObservedObejct
    • @StateObject

언제 배우면 좋을까?

  • 한, 두 번 더 업데이트 거친다면 정말 괜찮을 것 같다
  • UIKit 버그에 지쳤다면
  • 22년 취업 목표로 하고 있다면
  • 토이 프로젝트
  • 그냥
  • 개발자 사이트 튜토리얼 따라 해보자~

Q&A

  • 빅서, Xcode12 부터 가능
  • VStack
    • 기존 스택 뷰
  • RxSwift UIKit보다 SwiftUI가 나은 점
    • 애플 공식 지원
    • 성능상 이점 - RxSwift는 Swift를 랩핑한 것이므로
  • ​SwiftUI를 쓰기 위해서는 기존 AppDelegate/Window/ViewController 구조는 완전히 해체하고 새로 가야 하는지?
    • 아니다. 같이 쓸 수 있지만 추천하진 않는다.
  • SwiftUI를 배우는 것이 UIKit 배우는 것보다 러닝커브가 높나요?
    • 아니다. SwiftUI가 훨씬 직관적
  • 이제 시작할 때 UIKit, SwiftUI 둘다 배워야 할까
    • 당장, 올해 취업한다면 무조건 UIKit 해봐야함
    • 그냥 취미, 내후년 취업 계획이라면 SwiftUI 먼저
    • 가장 좋은건 둘다 하자…




패널토크 : 외국의 개발자 생활은 어떻습니까?

  • Speaker: unnnyong, 노수진, 도길참새
  • 도길참새
  • unnnyong
  • 노수진
    • 싱가폴
    • 오기전엔 네이버웹툰 근무
  • unnnyong
    • 지금은 코로나때문에 한국으로 돌아온 상태

도길참새 - 독일

  • 많은 야근…, 실리콘 밸리 등 가고 싶었음
  • 독일에서도 일할 때 영어 사용 (스타트업, 베를린 등)

unnnyong - 일본, 현재는 한국

  • 일본식 영어 발음, 같은 한자 문화권이지만 전혀 다른 말 붙인 경우 (상속<->계승 등)

노수진 - 싱가폴

  • 원래 해외에서 살고 싶었음
  • 영어가 공용어지만 다국적사회라 영어가 네이티브인 사람이 적다 -> 영어 부담 적다
  • 링크드인 잘 관리 해오던게 도움 됨
    • 독일도 링크드인 활발
    • 일본은 블로그, 트위터…




역전의 명수 (Inversions)

  • Speaker: 곰튀김

인버전이 무엇인가

직접적인 연관관계 사이에 프로토콜을 두어서 의존 역전을 잃으키는 것

왜 쓸까

클래스간 연관관계를 느슨하게 해서 유연한 구조가 된다. 그래서 수정하기 쉽다

Dependency Injection Libraries

Swinject…

Summary

  • Tight coupling
    1. 경직된 인스턴스 연결
    2. 객체의 변경 불가, 유연성 떨어짐
    3. 단독 객체의 독립적 테스트 불가
  • Loose Coupling
    1. 프로토콜을 통한 인스턴스 연결
    2. 프로토콜만 만족하면 객체 변경 가능, 유연함
    3. Mock 객체 주입으로 독립적 테스트 가능
  • Steps
    1. 의존되는 클래스의 프로토콜 작성
    2. 사용하는 객체에서 프로토콜 타입으로 인식
    3. 외부에서 의존성을 주입 (injection)




Cocoa pod, Carthage, SPM 중 무엇을 쓰시나요?

  • Speaker: 이현호

패키지 매니저란?

  • 모든 것을 만들어 쓸 수 없으니 오픈소스를 쓰자
  • 프로젝트에 필요한 패키지를 관리해주는 녀석
  • 패키지 매니저가 없다면? 직접 설치
  • CocoaPods
  • Carthage
  • SPM (Swift Package Manger)

Cocoa Pod

  • 장점
    • 모든 라이브러리를 한곳에서 검색해서 사용 가능
    • 간단하게 추가 가능
      • pod init, pod install
      • xcworkspace 파일을 열어서 사용
    • 어떤 오픈소스를 쓰고있는지 보기 편함
    • 버전의 종속성과 그 종속성을 관리해줌
    • 많은 패키지들이 코코아팟을 지원
  • 단점
    • 프로젝트를 빌드할 때마다 모든 종속 패키지를 다시 빌드하기 때문에 느리다

Carthago

  • 코코아팟의 단점을 보완해서 등장
  • 프레임워크를 추가하는 방식
  • 장점
    • carthage update 명령어 사용 시, 한 번 프레임워크로 빌드 하며, 빌드 속도가 빠름, 이후 내 프로젝트는 프로젝트만 빌드하면 됨
    • 어떤 오픈소스 쓰고 있는지 보기 편함
  • 단점
    • 새로운 패키지를 가져다 쓸 때 프레임워크를 추가해 줘야 하는 번거로움
    • 새로운 프레임워크를 추가할 때 시간이 오래 걸림
    • 오픈소스마다 지원을 하지 않을 수 있다

SPM

  • 장점
    • Apple의 공식 지원
    • Xcode11 부터 사용 가능
    • 그 외 기존 패키지 매니저의 장점
  • 단점
    • 생긴지 얼마 않되 서 지원하지 않는 라이브러리가 많다
    • 아직 버그가 많다

어떤것을 선택할까

  • SPM
    • 바로 사용할수 있고 애플 공식지원

Q&A

  • 일반 개발자들이 SPM을 코코아팟처럼 쉽게 배포할 수 있나?
    • 문서 지원이 잘 돼있어서 쉬울 것
    • 야곰닷넷에 튜토리얼 있음
  • SPM의 빌드 속도 빠를까
    • 코코아팟 방식이지만 코코아팟보다 빠른 듯
    • 아직은 프리 빌드 방식인 카르타고보다는 느린 듯




Apple Pay 개발을 못해도 어떻게 하는지 아는 건 죄가 아니잖아

  • Speaker: unnnyoung

Apple Pay?

  • Wallet App에 결제에 사용할 카드 등록

일본에서 애플페이 활용

  • 오프라인 점포에서 NFC를 이용한 애플페이 결제
  • 교통카드로 사용
  • 앱스토어, 앱 내 결제
  • 사파리에서 결제 수단

iOS App 에서 애플페이 도입 방법

  • 상품 화면에서 Apple Pay 버튼 추가
    • PKPayButton 타입
  • Payment Sheet 만들기
  • 애플 페이 버튼을 다른 결제 수단과 동일하게 선택하게 해도 된다




패널토크 : 신입 개발자, 이런 사람 찾아요.

  • 다양한 기술 스택들 모두 알아야 하나
    • 최소한 지원하는 회사의 기술 스택들에 대해 공부 필요
    • 모두 깊게는 못해도 무엇인지 아는 정도는 필요
  • 코딩테스트
    • 예선이므로 짧게 집중해서 한다면 준비 가능
  • 포트폴리오
    • 거대한 프로젝트가 필요한 게 아님
    • 작은 규모라도 어떤 기능을 어떻게 적용했는지
    • 그 과정에서 무엇을 얻었는지, 문제를 어떻게 해결했는지 잘 정리
  • 이런 이력서를 보면 이 사람은 면접 보고 싶다
    • 내 일을 줄여줄 수 있는 사람
    • 깃허브, 블로그가 꾸준히 잘 관리된 사람
    • 자사 서비스에 관심 있는 사람. 이용해봤는지 어떤 생각이 있는지
  • 이런 이력서는 쓰지 말자
    • 대기업 이력서의 딱딱한 형식
    • 무엇을 할 수 있는지 알 수 없는 이력서
  • CS 지식
    • 알아야 하지만 당장 모른다고 못하진 않는다
    • 연차가 쌓이고 깊게 들어갈 때 벽이 느껴질 것
    • 이때 공부하면 더 열심히 하게 되고 더 잘 이해될 수 있다
    • 뭐부터 해야 할지 모르겠다면 탐색기, 제어판 열어서 각 단어들을 검색해서 알아보고 내가 설명할 수 있는지 생각해 보는 방식도 좋다
  • 신입 면접에 CS물 물어볼지?
    • 경력자에게는 물어보겟지만 신입에게는 iOS에 관련된 것을 물어볼 것
    • 정말 기초는 물어볼듯, 쓰레드 등
  • 주니어와 시니어의 차이는 무엇일까
    • 아키텍쳐, 리팩토리 등 더 깊은 문제를 해결할 수 있는지
    • 이끌어 줄 수 잇는 사람
  • 쥬니어에게 해주고 싶은 말
    • 작은 것부터 동기부여를 찾아서 일을 재밌게
    • 개인 개발도 따로 하며 꾸준히 성취감을 느끼게
    • 코드뿐 아니라 UI, UX, 디자인 등에도 관심을 갖자

Leave a comment