Mac과 Device(iPhone)을 유선상으로 연결 Window > Devices and Simulators 실행 연결한 디바이스의 체크 박스 클릭 유선 연결 제거 Mac과 디바이스 둘 다 Wifi 접속 빌드 진행 (처음에는 연결이 안되었는데, Xcode 재실행 후 동작됨) (느려서 개발할 때는 잘 사용하지 않을 것 같다)

다음의 포스트를 참고하여 작성하였습니다. Velog, Git 협업 가이드, (2022.01.29) Tistory, Github를 이용한 iOS 개발 협업 기초, (2022.01.29) 1. 왜 하려는건가요? 이제 내가 속한 iOS 파트에서 하나의 프로젝트를 2명 이상의 개발자가 함께 협업하기 시작했다. 제대로된 형상관리(Branch, Release), 업데이트 이력 확인(Commit) 등을 하려고 하지만, 아직 경험이 없어서 한 번 생각을 정리해보려고한다. 2. 지금 어떻게 일하고 있나요? 두 명의 개발자(H, K) 같은 Xcode 프로젝트를 동시에 작업 K는 신규 기능 CallKit(iOS에 전화처럼 오게 하는 기능)을 2주간 구현 H는 기존 코드의 BugFix 업무 Github에는 현재 1.2.0 배포 버전의 코드 업로드 branch는 master, develop 2개 case K. 신규 기능 개발 기획자: 신규 기능 기획 디자이너: 신규 기능 디자인 개발자: 기획/디자인 피드…

모바일 앱 개발 방식 요즘 모바일 앱은 비즈니스에서 굉장히 중요해졌다. 모바일 앱은 개발 방식에 따라 크게 3가지로 나눌 수 있다. Native Application 안드로이드와 iOS 각각의 플랫폼에서 요구하는 언어와 프레임워크로 앱 개발 Hybrid Application 모바일 UI를 웹으로 개발 후 iOS/Android 웹뷰로 패키징하여 개발 Cross-Pratform Application 한 가지의 개발 언어와 프레임워크로 iOS/Android 앱 개발 나는 Native 개발자로 커리어를 걸어가는 중이기에, Native가 어떨 때 사용되고 강점이 있는지 알아야 공부에 더욱 도움이 될 것이다. 네이티브앱으로 개발해야하는 경우 일단 가장 큰 장점은 속도가 빠르고, 모바일앱에 대한 사용자 경험에 가장 알맞음 오프라인으로도 앱이 동작되어야하는 경우 카메라, 저장공간, 전화, gps 등의 모바일 기기의 기능 사용하는 경우 고성능 화면이 필요한 경우(게임, 3D, 차트 등)

다음의 포스트를 참고하여 작성하였습니다. 깃(Git) 커밋 가이드, (2022.01.27) 이전에 Git Commit Message Convention 관련하여 다뤄본 적이 있다. 요즘 회사에서 Github(Git)를 제대로 사용하게 되면서 드는 몇가지 생각이 있었다. 커밋은 어떤 단위로 해야할까? Git을 사용하다보면 각자 사용하는 방법이 조금씩 다르다는 것을 느끼게 된다. 나는 그 중 커밋을 언제마다 해야할까에 대해서 고민을 많이 하게 된다. 참고 포스트에서 아래와 같은 문구를 읽게 되었다. “커밋은 논리적으로 구분이 되고, 일관성이 유지되는 단위로 최대한 작게 쪼개서 되어야합니다. (Each commit is a minimal coherent idea)”. 사실 최대한 작게 Commit을 하게되면 일거리가 많이 늘어나게 되어 귀찮아진다. 그래도 이렇게 운영할 경우 코드리뷰를 위해서 볼 때나 버그나 사이드 이펙트를 발견하는 데 큰 도움이 된다. 특히 히스토리를 통해 현재 코드가…

참고 포스트 Apple Developer Document, Markup Overview, (2022.01.24) 퀵헬프를 위한 마크업 코멘트 사용 단축키 : ⌥+⌘+/ Editor > Structure > Add Documentation Example 1 Example 2 Example 1 Example 2

에러 어느 때와 같이 CocoaPod으로 내가 만든 라이브러리를 이용하기 위해 터미널에 을 입력했는데 갑자기 에러가 났다 이라는 에러 문구에 지금 CocoaPods의 버전이 새로운 Xcode의 버전을 못따라가는건가 싶어 Cocoapods을 업데이트 했다. 해결 CocoaPod 업데이트 일단 잘 해결이 되었다. 다음에 또 이 에러에 직면하면 마음 편하게 업데이트를 해야겠다.

내가 자주 쓰지만 아직도 잘 기억 못하는 Git Command들을 정리해봤다. 1. Git 저장소 상태 조회 Git 저장소 상태 조회 Git 저장소 상태 조회 요약 2. Git 옵션 설정 username 설정 3. Git 스테이징 관련 3-1. 스테이징 파일 추가 파일 하나 추가 파일 여러 개 추가 모든 변경 내용 추가 3-2. 스테이징 파일 제거 스테이징 파일 제거 3-3. 스테이징 파일 커밋 커밋 add와 동시에 커밋 커밋 메세지 반영하여 커밋 add와 동시에 커밋 메세지 반영하여 커밋 3-4. 커밋 이력 확인 커밋 이력 확인 (number)개까지의 이력 확인 커밋 이력 이쁘게 확인 4. Git 원격 저장소 관련 4-1. 원격 저장소 변경사항 반영 원격저장소의 변경사항 워킹트리 반영 원격저장소 등록 원격저장소 목록 원격저장소 push 원격저장소 로컬저장소로 복제 1. Git 저장소 상태 조회 2. Git 옵션 설정 3. Git 스테이징 관련 3-1. 스테이징 파일 추가 3-2.…

다음의 포스트를 참고하여 작성하였습니다. How to Write a Good README File for Your GitHub Project, (2021.11.13) 0. README Github를 사용할 경우 다른 사람들이 프로젝트를 잘 이해할 수 있도록 좋은 프로젝트 문서를 작성해야한다. 보통 많은 사람들이 Github를 입문할 때 README파일에 대해 잘 알지 못하고 시작한다. (그냥 뭐 다른 사람들의 프로젝트에 있는 멋진 문서 정도?? 나는 그렇게 생각했다.) 원글에 내용처럼 나도 점차 개발에 대한 열정이 커지면서 다양한 유저들을 팔로우하기 시작했다. 멋있는 개발자들은 모두 아름다운 프로젝트를 가지고 있고, 유명한 오픈소스에 기여했다는 공통점이 있었다 또한 그들의 아름다운 프로젝트에는 자세한 README 파일이 있었다. 나도 README를 잘 써보기로 결심했다. 1. 왜 README를 잘써야하나 README파일은 저장소에 올라와있는 프로젝트에 대한 자세한 안내를 해주는 가…

다음의 포스트를 참고하여 작성하였습니다. Apple Developer, Xcode Markup formatting, (2022.01.21) Velog, Swift 주석 작성법, (2022.01.21) 주석이란? Comment라고도 하며, 간단하게 프로그래밍 내용에 대한 메모라고 보면 된다. 주석은 프로그램을 이해하고 변경에 대한 내용을 제공하기 위해서 사용된다. (주석은 컴파일러 혹은 인터프리터에 의해 무시가 되어 프로그램에 영향을 주지 않는다) 기본 주석 내가 처음 배운 주석은 ’//’ 슬래쉬 2개를 사용한 한 줄 주석이었다. 1) 한 줄 주석 (단축어: ⌘ + / ) 2) 여러줄 주석 3) 중첩 주석 마크업 주석(문서화) Xcode의 Quick Help 기능을 사용하기 위해서는 일반 주석을 사용하면 안된다. (Quick Help : Xcode에서 레퍼런스 문서의 요약된 내용을 보여주는 기능, 단축키 : ⌥ + 오른쪽 마우스 클릭) Quick Help를 통해 객체나 함수를 명세하…

다음의 포스트를 참고하여 작성하였습니다. 티스토리, [GitHub] .DS_Store 파일 개념 및 삭제 방법 (2022.01.20) 어느날 커밋을 하고서 Github 사이트를 확인했는데, 라는 파일이 함께 업로드가 되었다. 무슨 파일인지 궁금하여 검색을 해봤다. .DS_Store 파일? Desktop Services Store의 약자로, 애플에서 정의한 파일 포맷 애플의 맥 OS시스템이 finder로 폴더에 접근할 때 자동으로 생기는 파일로써, 해당 폴더에 대한 메타데이터를 저장하는 파일이다. 분석해보면 해당 디렉토리 크기, 아이콘의 위치, 폴더의 배경에 대한 정보들을 얻을 수 있다. 맥 OS 환경에서만 생성 및 사용되지만, 파일을 공유하는 과정에서 이 파일도 같이 공유되는 경우가 있다. DS_store 파일은 프로젝트와 관련없는 파일이며, git status를 사용했을 때 발견되는 파일이니, github로 넘기지말고 삭제해도 된다. .DS_Store 삭제 방법 저장소 상위 디렉…

다음의 포스트를 참고하여 작성하였습니다. Cocoa Dev Central: Learn Objective-C, (2022.01.22) 1. Basic 1-1. 기본 문법 다른 언어에서 주로 사용하는 를 Objc에서는 대괄호와 스페이스로 호출한다. 입력 파라미터가 있는 경우 를 메소드와 파라미터 사이에 작성한다. 너무 어색하다 1-2. 리턴값이 있는 경우 1-3. 클래스 메소드 사용 근데 여기서 id를 처음 본다. 는 Objective-C의 자료형으로 모든 종류의 객체를 참조할 수 있는 자료형이다. (id형은 *다형성과 *동적 바인딩을 위한 Objective-C의 기능) 잘 모르겠지만, 아무 객체나 참조 가능한 자료형으로 알고 넘어가보려 한다. *다형성 : 하나의 객체가 여러 가지 타입을 가질 수 있는 것(회사원이면서, 남자이면서, 한국인 등) *동적 바인딩 : 런타임 시점에 객체 타입을 기준으로 실행될 함수를 호출하는 것 만약 명확하게 타입이 NSString일 경우, 다음과 같이 작…

다음의 포스트를 참고하여 작성하였습니다. Stackoverflow, Why do Objective-C files use the .m extension?, (2022.01.19) 파일이 나눠져있다 Objective-C는 헤더파일이 있다. Objective-C는 C언어를 확장한 언어라서 C언어와 동일하게 헤더 파일이 존재하고, 이 헤더 안에는 늘 그렇듯 외부에서 사용할 메소드, 변수 등을 선언해둬야 한다. Swift : Objective-C : , (약간 느낌이 Swift에서 넘어가는 것보다는, C에서 넘어가는 방향으로 이해해야할 것 같아 보인다) .h = 헤더파일 Class, Type, 함수와 상수 선언 .m = 소스파일 Objective-C와 C 둘 다 포함할 수 있는 소스파일 확장자. TMI : 왜 확장자가 일까? (헤더는 Header니까 h인데 m은..?) 현재 대부분의 사람들은 이를 Method 파일로서 알고 있다. 하지만 Mark Dalrymple과 ScottKnaste…

다음의 포스트를 참고하여 작성하였습니다. velog, [Objective-C] 시작하기, (2022.01.15) Swift로 iOS개발에 입문한 나는 Objective-C를 건들이지 않을 것이라고 생각했다. (애플에서 스위프트를 밀어주는데 쓸 일이 있겠어?) 마침 나는 스타트업에 다니고 있어 그린필드 프로젝트만 하다보니 더욱 없을 것이라고 생각했다. 절대 그렇지 않았다. iOS 개발자로 전향을 하고, 마침 iOS 개발자 출신이신 개발팀장님께서 이렇게 말씀하셨다. ” iOS 개발자는 크게 4가지의 업무를 한다. 첫번째, Swift 프로젝트 신규개발 두번째, Swift 프로젝트 유지보수 세번째, Objective-C 프로젝트 Swift로 컨버팅 네번째, Objective-C 프로젝트 유지보수 Objective-C 프로젝트 신규개발 ” 그리고 나는 이번에 Objective-C로 된 웨어러블 디바이스 데모앱 프로젝트의 Swift 컨버팅을 시작했다. 왜 아직도 Objective-C를 쓰는가…

다음의 포스트를 참고하여 작성하였습니다. rightpoint, ”Spicing Up Xcode”, (2021.11.06) 나는 단축키를 좋아하고 잘쓰려고 노력하는 편이다. 마우스를 최소한으로 사용하고 최대한 키보드를 이용하여 작업하는 것이 실제로도 능률이 높아지기도 하고, 일단 멋있다. 단축키는 내가 하나하나 노력을 해가면서 사용해야 한다. 처음에는 머리로 생각하면서 사용하지만, 그렇게 하나하나 쌓아가다보면 자연스럽게 단축키를 사용하는 나의 모습을 볼 수 있게 된다. (다른 사이트에서 단축키를 Symbol을 이용해서 정리하길래 나도 한 번 따라해봤다.) Cmd: ⌘ Shift: ⇧ Option: ⌥ Control: ⌃ Caps Lock: ⇪ Fn 써보고 싶은 단축키들을 발견하여 정리해봤다. Balance Delimiter: ⌘⇧ StoryBoard Zoom In/Out: ⌘+, ⌘- Reveal in Project Navigator: ⌘⇧J Open Quickly: ⌘⇧O Capi…

다음의 포스트를 참고하여 작성하였습니다. Github, 모바일 개발자 로드맵, (2022.01.14) IDE Xcode Grammer Functional Programming(Swift) Object-oriented Programming(Objective-C) iOS Human Interface GuideLine iOS Tech App Architect App Life-Cycle View-ViewController AutoLayout Multi-Touch Event Handling Cocoa Design Pattern MVC Singleton Delegate ResponderChain Observer Network RESTful APIs TCP/IP Socket APIs Language Swift Protocol-Oriented Programming Concurrent Programming DispatchQueue Advanced Design Pattern VIPER MVVM Ob…

모바일 어플리케이션 개발을 하다보면 사용자들의 디바이스들이 모두 최신의 OS를 쓰고 있지 않기에 Target Version을 결정하게 된다. 그에 도움이 되도록 Apple Developer 사이트에서 제공해주는 점유율을 확인했다. https://developer.apple.com/kr/support/app-store/ 2022년 1월 11일 App Store 측정 수치 지난 4년 동안 도입된 기기 기준 72%가 iOS15, 26%가 iOS14 즉 98%가 iOS14 이상 전체 기준 63%가 iOS15, 30%가 iOS14 즉 93%가 iOS14 이상 iOS13부터 많은 변화가 있었다. 더 나아가 iOS14에서는 SwiftUI, PIP, Widget 등 다양한 기능들이 생겨났다. iOS13부터의 기능을 사용해야한다면 iOS13을 타겟으로 잡아도 문제가 없어보인다.

UITableView를 기본적으로 생성 후 행을 선택하면 선택한 행을 강조하기 위해 색이 어둡게 변한다. 그런데 손을 떼어도 계속 색이 어둡다. 나는 손을 떼었을 때 색이 다시 돌아왔으면 좋겠다. 사용자가 행을 터치 후 뗐을 때 다시 색이 돌아올 수 있도록 하려면, 의 메소드를 다음과 같이 작성해주면 된다. 메소드는 행이 선택되었을 때 호출되는 메소드로, 위와 같이 함수를 호출하여 선택되자마자 선택이 풀려 색이 돌아올 수 있도록 정의하면 된다.

네비게이션바의 뒤로가기 버튼은 따로 설정을 안할 경우 기본으로 에 뒤로갈 화면의 이름이 표시됩니다. 간단하게 앱을 개발하는데 뒤로갈 화면의 이름이 너무 길어서 UI가 안 이뻐질 경우 저는 제거를 하는 편입니다. (다른 뒤로가기 버튼 아이콘을 넣어서 텍스트를 제거하는 방법도 있습니다) ViewController에서 아래의 코드를 통해 뒤로가기 버튼의 텍스트(타이틀)을 임의로 제거합니다.

Github Repository에 적용할 수 있는 라이선스 종류는 다음과 같다. MIT License MI에서 공학도 지원을 위해 만들어진 이 라이선스는 라이선스 및 저작권 명시만 지키면 되는 프리한 라이선스다. 상업적 이용, 배포 및 수정, 2차 라이선스 모두 가능하며 금지 조건도 없다. 즉, 저장소에 이 라이선스를 적용할 경우 ‘소스를 어디서 퍼왔는지만 명시하면 마음대로 쓰세요’가 된다. Apache License 아파치 소프트웨어 재단 (Apache Software Foundation)에서 개발한 소프트웨어에 적용하기 위해 만들어진 이 라이선스는 라이선스 및 저작권 명시, 변경사항 안내, 상표권 침해 금지 조항이 걸려있는 라이선스이다. 상표권 침해만 하지 않는다면 사업적 이용, 배포 및 수정, 특허 신청과 2차 라이선스 모두 가능하다. GNU General Public (GPL) 자유 소프트웨어 재단 (Free Software Foundation)에서 만든 이 라이선스는, 라…

Swift로 iOS를 입문한 나는 문득 왜 Objective-C를 대신하여 Swift가 나왔을까?에 대하여 의문점을 갖게 되었다. Swift가 출시했음에도 불구하고 Objective-C를 사용하는 기업도 몇몇 있다고 하는데, 간단하게 두 언어의 장단점을 알고 싶었다. (왜 안쓰고 왜 쓰는지는 알면 좋다고 생각한다) 1. 개발 관점 장점 단점 Swift - 헤더파일 및 본문 파일이 별도로 존재하지 않아 파일 정리에 편리- 명확한 타입 선언을 하지 않아도 됨- 애플 자체 컴파일 - Swift만의 문법 존재- Swift버전 업에 따른 API 변동이 큼(현재는 많이 줄어들었다) Objective-C - C개발자의 경우 Swift대비 빠른 습득 가능- 컴파일 버전 업에 따른 API변동이 없음- 안정화된 오픈 소스 사용에 용이 - 헤더파일 및 본문 파일에 따른 파일 수 증가- 포인터 사용에 대한 어려움- 애플 자체 컴파일이 아님 2. 퍼포먼스 관점 장점 단점 Swift - 개발 속도가 빠…

에러 오랜만에 터미널로 커밋을 하려는데 아래와 같은 에러가 났다. 이유 2021년 8월 13일을 기점으로 패스워드 기반의 인증을 지원하지 않는다고 한다. (8월 13일 이후로 처음 만료되본 것 같긴 하다.) 해결 방법 SSH인증 방법과 Git 토큰 방식이 있는데, 나는 이미 발급해놓은 토큰이 있어서 후자로 진행한다. 을 할 때 비밀번호에 비밀번호 대신 token을 입력하면 정상적으로 Git 이용이 가능하다 에러 이유 해결 방법

다음의 포스트를 참고하여 작성하였습니다. iOS Developer Skills Matrix, (2022.01.09) 우리는 우리 자신이나 잠재적인 팀원들을 평가할 때 항상 객관적으로 최선을 다해야 합니다. 불행하게도, 우리는 질문에 더 정확하게 대답하려고 노력할수록 진리에서 더 멀어진다. 이 skill Matrix는 iOS 개발자 후보에 대한 상대적인 요구 사항을 정의하기 위한 시도입니다. 추구하는 점 어느 영역을 개선해야 할지 알 수 있을 정도의 정확함 특정 지식을 정식화하는 것을 피할 수 있을 정도의 모호함 Areas 대부분의 개발자는 매일 이 Skills Matrix의 여러 영역을 건드린다. 우리 대부분은 직장에서 모든 영역을 건드릴 기회가 없기 때문에 어떤 기술은 오랫동안 사각지대로 남아있을 수 있다. 그렇기 때문에 일하면서 하지 않는 것을 이 지표를 통해 공부하면서 나아갈 수 있다. How not to use it 응시자 평가를 위한 전용 도구나 학습 계획으로 사용하지 마…

개요 기술블로그를 시작하면서 다른 기술블로그와 많은 서적, 강의들에서 얻게된 내용을 ‘나의 블로그’로 올리게 되는 것 같다. 그러면서 이 내용을 그대로 올려도 될까?라는 의문과 함께 저작권에 대해 궁금해졌다. 내 스스로의 기준을 확실하게 잡기 위해 저작권과 그에 알맞는 정확한 출처 표기에 대해 알아보았다. 저작권? 저작권 : 창작물을 만든이(저작자)가 자기 저작물에 대해 가지는 법적 권리 사람의 생각이나 감정을 표현한 결과물에 대하여 그 표현한 사람에게 주는 권리라고 쉽게 말할 수 있다. 저작권은 등록/인증을 통해 발생하는 권리가 아니라, 창작물이 만들어지는 순간부터 생겨나는 권리이다. 기술블로그에서의 저작권 TIL을 시작하고 기술블로그를 시작하면서 저작권에 대해 궁금하기 시작했다. 내가 블로그에 글을 작성하면서 유의해야할 상황을 예상해보았다. 도서 리뷰글, 기억하고 싶은 내용 작성 유튜브 영상 정리글, 리뷰글 작성 강의 내용 정리하여 작성 외부 블로그 글을 인용하여 작성 1. 도…

1. Homebrew 설치 2. Cocoapods 설치 3. 설치 확인

1. 레거시 코드? 태도는 큰 차이를 가져올 수 있는 작은 요소다 -윈스턴 처칠(Winston Churchill) 백지상태에서 시작하는 그린 필드 프로젝트를 선호하는 사람이 있냐는 질문에 개발자들의 거의 모두가 손을 든다. 반면 레거시 코드에서 작업해야 하는 프로젝트를 선호하는 사람이 있냐는 질문에는 아무도 손을 들지 않았다. 레거시 없이 백지 상태에서 시작하는 프로젝트는 항상 즐겁다. 자유롭게 기술을 선택하고, 최신의 프레임워크를 사용할 수 있으며 기존 기능을 깨뜨릴 걱정 없이 편하게 코딩할 수 있다. 기존 코드를 이해할 필요 없이 코드를 작성할 수 있다는 점은 대단히 큰 이점이다. 떠나버린 개발자가 남겨놓은 코드 위에서 일하는 상황이라면 개발자가 위축될 수밖에 없다.(옆에 남아있는 개발자에게 잘하자) 아무런 테스트도 없고 문서도 없다면 공황에 빠진다.(테스트 주도 개발과 문서화를 생활화하자) 우리는 레거시 코드를 만나지 않을 가능성이 극히 낮다. 단지 프로젝트에 따라 우리가 빠…

다음의 포스트를 참고햐여 작성하였습니다. 유다시티 깃 스타일 가이드, (2022.01.04) 0. 구조 1. Type feat: 새로운 기능 추가 fix: 버그 수정 docs: 문서 관련 refactor: 코드 리팩토링 test: 테스트 코드 chore: 빌드 업무 수정, 패키지 매니저 수정 등 add: 기능도 아니고 문서도 아니고 애매한 무언가를 추가할 때 delete: 삭제 move: 코드나 파일 이동 modify: 수정 correct: 문법 오류, 타입 변경, 오타 등 2. Subject 제목은 50자를 넘기지 않고, 마침표를 붙이지 않는다. 제목에는 위 커밋 종류를 함께 쓴다. 과거시제를 사용하지 않고 명령조로 작성한다. 제목과 본문은 한 줄 띄워 분리한다. 제목의 첫 글자는 반드시 대문자로 쓴다. 제목이나 본문에 이슈 번호(가 있다면) 붙여야 한다. 3. Body 선택사항이기에 모든 커밋에 본문 내용을 작성할 필요는 없다. 한 줄에 72자를 넘기면 안된다. 어떻게(How)…

아래 인터뷰 영상을 보고 인상 깊었던 내용들 위주로 작성하였습니다. 현직 iOS 개발자 선배의 취업.ssul | 앨런 인터뷰 간단한 프로필 이름 : 앨런 직업 : iOS 개발자 회사 : 동영상 기반 쇼핑 플랫폼 스타트업 6개월 재직 현재 회사 선택 이유 본인이 생각한 기준에 다 부합 지원한 회사 중에 유일하게 아무 것도 베이스가 없는 회사로 스위프트 파일부터 만들어서 하는 회사였다. 주니어때의 프로젝트의 시작부터 하는 경험은 어디서도 얻지 못할 귀한 경험이라고 생각 취업 준비에서 자신만의 원칙 취업시장에서 나는 상품이다. 변명하지 말자 어떻게든 다 되게 되어있다. 개발 실력에 대한 생각 개발 실력에 대한 판단 개발 실력의 정도는 어떻게 보면 회사마다, 팀마다 또 사람마다 너무 일하는 방식이 달라서 ‘누구는 Lv.1이야’라고 나누는 것은 말이 안된다고 생각 iOS 개발자는 총 다섯 단계 정도의 실력이 있다고 생각 iOS 개발을 막 시작한 단계로, Lifecycle, UIKit을 어렴…

기술이 점차 빠르게 발전하며, 개발 분야 직군은 지속적인 학습이 필요. 스스로 최신 개발 지식과 기술을 파악하고 학습할 때 가장 유용한 교재는 바로 IT기업들의 기술 블로그입니다. 기업들의 시행착오, 오픈소스, 실무 기술들을 파악하며 빠르게 발전할 수 있습니다. 국내 IT 기업 기술 블로그 카카오 https://tech.kakao.com/blog/ 쿠팡 https://medium.com/coupang-engineering Watcha https://medium.com/watcha 마켓컬리 https://helloworld.kurly.com/ 우아한 형제들 https://techblog.woowahan.com/ 뱅크샐러드 https://blog.banksalad.com/ NHN https://meetup.toast.com/ 하이퍼커넥트 https://hyperconnect.github.io/ 당근마켓 https://medium.com/daangn 강남언니 https://blog.ga…

0. TIL이 무엇인가요? TIL은 Today I Learn의 약자다. 직역하면 오늘 내가 배운 것을 의미한다. (일일커밋과 같은 성격) 오늘 내가 배운 것을 매일매일 기록하는 것 1. 쓰는 이유는 무엇인가요? 1) 부족한 개발 역량 강화 마이스터고를 졸업하고 의료 IT 스타트업 회사에 취업을 했다. 개발자로 취업을 했지만, 기획적 역량과 다양한 툴을 능숙하게 사용하는 능력을 보며 UX Designer로 직무를 변경했다. 하지만 마이스터고에서부터 달려왔던 개발에 대한 깊은 마음과 ‘내 생각을 코드로 세상에 보여준다’라는 개발의 매력에 다시 개발을 도전했고, iOS를 공부하며 iOS 개발자의 삶을 시작하게 되었다. 다른 직무를 맡으면서 부족해진 개발 역량을 빠르게 강화해야 했다. 2) 스타트업 개발자로서 지속적인 공부 필요 지금 생활하는 회사의 SW팀장님께서는 늘 다음과 같이 말씀하곤 하셨다. “우리 회사가 개발하는 플랫폼은 생각보다 어렵다.” 웨어러블 디바이스 연동(블루투스)부터 …