LEEO TIL Dev Log

좀 더 잘 보이는 노션링크 입니다 개발자와 개발 멘토는 엄연히 다른 직업이라는 것을 개발 멘토가된지 6개월이나 지난 시점에 어렴풋이 알게 되었습니다. 그리고 개발 강사와 개발 멘토 또한 다른 직업이며, 멘토가 가진 다양한 역할에 따라 스스로가 헷갈리지 않게 행동하기 위해서 정리 해두고 있습니다. 6개월 동안에 깨닫게 된 점이나, 그 사이에 맞이한 변화를 기록해두고 그 이후의 변화를 스스로 살펴보고자 기록합니다. 앞에서는 실패 하라고 하고 뒤에서는 취업해라 멘토가 되어서, 스스로 혼란을 느낀것이 바로 방향성 이었습니다. 멘토링의 대부분은 멘티 스스로에게 도움이 되는 방향과 방법을 찾아보자라고 많이 했습니다. 그 과정에서 “실패할 수도 있고 실패를 통해 성장하면 된다.” 라는 말들을 많이 했습니다. 듣기에는 달콤하고 당연한 이야기지만, 결국에는 현실에서는 목표로 향하는 속도가 문제입니다. 실패도 하고 성장도 하지만 결국 우리는 직업을 가지는 방향으로 기술을 공부합니다. 트렌드는 빠르게 변하고 해야할 것은 많은데 마냥 공부하라고 하고 실패하라는 것은 너무나 무책임해 보입니다. 그리고 마지막에 가서는 “자 이제 다 배웠으니 취업하자” 라는 말은 앞 뒤가 너무나 달라보였습니다. 마지막에 취업을 하지 못할 것 같아 보였으면, 그 전에 채찍질을 하거나 초반부터 느리게 달리는 것에 대한 따끔한 피드백을 했어야 할텐데 말이죠. 이러한 아이러니 속에서 사실은 결이 맞는 이야기를 하고 있다는 것을 깨달았습니다. 무조건 빨리 달리라는 것이 아닙니다. 우리는 목표를 향해 달려가는 중 입니다. 그리고 목표를 달성하기 위해서는 많은 배움 그리고 많은 실패도 필요합니다. 이러한 과정들이 괜찮은 것이지 자신만의 속도로 가라는 것이 천천히 가라는 뜻은 아니었습니다. 언제나 자신의 한계에 도달하면 괴롭고 힘이듭니다. 그러니 힘든일을 하지 말라는 것이 아니라, 어디까지가 스스로의 한계치이고 또 어디가 나의 목표점인지 알게 도와주는 것이 멘토의 역할이라는 것을 깨달았습니다.

좀 더 보기 편한 노션링크 입니다 학습을 시작할 때, 내가 알고있는 영역과 앞으로 학습해야 할 영역을 알고싶어했던 기억이납니다. 아마도 잘 하고싶은 마음 때문이었겠죠. 그리고 내가 지금 어디쯤 와있는지 알고 있는 것은 생각보다 괴로운 시간을 견디는데 큰 도움이 되어줍니다. 마치 아주 높은 산에 올라갈 때, 정상까지 얼마나 남았는지 그리고 어느정도 올랐는지 알면 앞으로 남은 체력을 안배하고 견디기 쉬운 것 처럼 말이죠. 그런데 개발은 유독 어디서 부터 시작해서 무엇을 해야할기가 참 어려운 것 같습니다. 매년 새로운 것들이 쏟아져 나오는데, 나는 그 중에 얼마나 알아야 하는 걸까요? 그리고 내가 알지 못하는 미지의 영역을 얼마나 깊게 들어가서 공부해야하나요? 조금만 파고들어가도 손가락 마디두께의 전공 서적이나 논문이 한 무더기가 나옵니다. 어쩌면 30년 전의 역사부터 시작해야하나 하는 생각도 듭니다. 어떤 분야의 고수나 전문가가 된다기 보다는 여행을 떠난다는 느낌으로 경험을 쌓는 것은 어떨까요? 여행에 도움이 될 지도 여행에는 정답이 없습니다. 그래서 우리는 즐길 수 있는지도 모릅니다. 순위를 매길 필요도 없고 내가 가고싶은 곳을 가고 새로운 것을 경험하면 되기 때문이죠. 개발도 이렇게 즐기면서 갈 수 있었으면 했습니다. 책 단위로 하면 왜 힘들어요? 저는 책을 지표로 삼아서 공부했습니다. Swift 문법을 배우기 위해서 문법을 공부했습니다. 다 공부한다음에는 iOS 실전편 책을 보면서 코드를 짰습니다. SwiftUI를 배울 때도 예제로 배우는 책을 따라서 공부했습니다. 물론 장 단점이 있지만 가장 큰 힘듦은 모든 책의 뒷 부분을 공부할 때 너무 힘들었습니다. 나는 초보라, 아직 실력이 모자라서 기본 부터 공부하고 싶은데, 왠지 책을 끝까지 끝내야만 다른 분야를 공부할 힘을 기술을 얻는다고 생각했었습니다. 물론 책에서도 순서대로 익히면 좋은 지식들을 잘 나열해 주었습니다. 마치 이렇게 말이죠. 이렇게 나열해 놓고 보면 개발 레벨 1인

좀더 편하게 보시려면 노션링크 를 눌러주세요! 앱을 개발하다보면, 버튼의 이미지를 찾아 헤메이던 시간이 꼭 존재했습니다. 홈 버튼, 설정 버튼에 들어갈 이미지들을 찾는 것이죠. 하지만 지금은 그렇게 시작하지 않습니다. 왜냐하면 SF Symbols를 사용하고 있기 때문입니다. SF Symbols은 wwdc 2019에 소개 되었습니다. 딱 SwiftUI가 소개되던 해이기도 합니다. 그 말은 즉 SF Symbol을 사용하려면, 프로젝트가 iOS 13+ 을 지원해야한다는 뜻 입니다. 물론, 하위 버젼을 분기처리하고 진행하는 방법도 있긴 하지만, 통일성을 위해서 iOS 13 이상의 버젼에서 사용하는 것을 추천 드립니다. 그러면 이 SF Symbol로 무엇을 할 수 있을까요? 심볼 고르기 우리가 사용할 수 있는 심볼은 SF Symbols 라는 앱을 통해서 확인할 수 있습니다. 카테고리 별로 확인이 가능하고, 이름, 그리고 색상을 적용하면 어떻게 바뀌는지도 확인할 수 있습니다. 심볼 그리기 Image (systemName: "mic.and.signal.meter" ) SwiftUI에서는 위와 같은 방법으로 간편하게 심볼을 사용할 수 있습니다. 이미지이기 때문에, .resizable(), .aspectRatio(contentMode: .fit), frame(width:, height:) 를 활용하면 아름다운 심볼을 아주 간편하게 그릴 수 있습니다. 심볼 색칠하기 wwdc2021 에서 심볼에 색을 넣을 수 있는 기능이 추가되었습니다. 이에 더해 SF symbols 4에서는 다중 레이어에 대한 설명이 wwdc2022에 잘 설명 되어있습니다. 그래서 각 레이어 마다 다르게 색상을 적용할 수 있습니다. Monochrome 한가지 색으로 심볼을 적용하는 렌더링 모드입니다. 가장 단순한 방식으로 사용하며, 다른 색상을 적용해도 첫 번째 색상만 적용됩니다. Image ( systemName : " mic .and .si

보기 좋은 노션링크 입니다. 개발을 하다보면 특히 iOS 개발을 하면 누군가에게 배우는 환경이 쉽지는 않아, 결국에는 독학을 하게 됩니다. 독학을 하다보니 이렇게 하지말껄, 다음에는 이렇게 하면 더 좋겠다 할 만한 내용들을 적어두었습니다. 왜 개발자? 매년 연초에 개발회사 전직원 연봉상승 뉴스는 개발자들 사이에서도 흥미로운 기사입니다. 뿐만 아니라 네카라쿠배당토, 주문같은 단어들도 생겨났습니다. 그래서 그런지 개발자가 되고싶은, 그리고 개발을 배우고 싶은 사람들이 많이 보입니다. 왜 개발자가 되고싶은지 살펴보면 크게 3가지 이유로 보입니다. 높은 연봉 좋은 복지 차오르는 뽕 물론 이런 것을 추구하는게 나쁘다고 생각하지 않습니다. 일을 하면서 돈을 많이 벌고 싶은 것은 너무나 당연한 것이고 좋은 복지와 남에게 자랑할 수 있는 직업을 가지는 것은 기분 좋은 일 일테니까요. 하지만 이렇게 좋은 모습에는 이면이 있습니다. 공부 할 것들이 엄청 많음 빠르게 변하는 기술 매우 큰 스트레스 컴퓨터 공학과의 의미를 담은 전공이 있고 대학에서 4년동안 공부할 만큼의 많은 지식이 필요합니다. 당장 개발 강의에서는 6개월만 공부하면 당신도 개발자! 라는 글을 자주 접하지만 실제 공부를 시작해보면 6개월만에 개발자가 되는 것은 맞지만, 개발자가 된 뒤에도 해야할 공부가 대학 4년치보다 많은 것은 변함없는 사실입니다. 그리고 애플 생태계에서는 매년 WWDC에서 공개되는 수백개의 영상이 있습니다. 매년 새로운 기술, 빠르게 변하는 트렌드는 늘 공부해도 뒤쳐지는 느낌이 듭니다. 눈에 보이지 않는 작업을 머릿속으로 해야하기도 하고, 마감 기한을 맞추기 위해 밤을 새야 하는 일도 자주 일어날 수 있습니다. 또한 업무 시간 이외에도 공부에 많은 시간을 쏟아 붓는 것은 스트레스가 심한 일이죠. 어디로 가야하죠? 막상 개발을 시작했더라도 강의를 하나 정도 다 듣고나면 여러 의문이 생깁니다. 지금 내가 무엇을 해야하지? 이 것을 안하면 어떻게 되지?

활용방법 #if문 의 state문 중 하나입니다. canImport() 안에 는 모듈이름이 들어가고, import 할 수 있으면 true를 반환합니다. 특정 코드에서 사용하는 모듈들이 조금씩 다를 때 분기를 해줍니다. 예를 들면 iOS에서는 UIKit을 사용하고, macoS에서는 AppKit을 사용한다면 분기를 해주어야겠죠? 사용에제는 아래와 같습니다. # if canImport(UIKit) import UIKit # endif # if canImport(AppKit) import AppKit # endif

개발을 하면서 개발자가 가장 많은 시간을 쓰는게 변수 명을 짓는 것 이라는 이야기가 있습니다. 이게 그냥 우스갯소리로 나온 것이 아니라, 제 개인적인 경험만 돌아봐도 개발시간의 많은 부분을 변수를 짓고 변수를 어떻게 지어야 하나 고민했습니다. 그 이유는 변수 명에 따라 그 이후의 개발 속도가 달라지기 때문입니다. 그래서 지금 짓는 변수에 많은 고민을 하고 시간을 소요하게 되었습니다. 글로는 알기 어려우니 예를 들어서 코드로 설명해 보겠습니다. 불명확한 이름이 가져오는 참사 틀리지는 않았지만 불명확한 이름이 가져오는 참사는 다음과 같습니다. let numbers = [ 1 , 2 , 3 , 4 , 7 ] let number = getSomeNumber( with : numbers) 함수의 이름이 getSomeNumber 이라서 어떤 숫자가 반환될지 알기가 어렵습니다. 그래서 우리는 이 함수가 어떻게 생겼는지 알아보러 가야합니다. let numbers = [ 1 , 2 , 3 , 4 , 7 ] let number = getSomeNumber(with: numbers) func getSomeNumber (with numbers: [Int]) -> Int ? { // ..... some code return numbers.first } 이렇게 보았을 때, 함수가 어떻게 동작하는지 내가 분석을 하고 반환값을 보고 나서야 변수 이름을 지을 수 있습니다. let numbers = [ 1 , 2 , 3 , 4 , 7 ] let firstNumber = getSomeNumber(with: numbers) func getSomeNumber (with numbers: [Int]) -> Int ? { // ..... some code return numbers.first } 영어 문법에 맞는 이름 변수 이름을 영어로 짓기 때문에, 문법에 맞지 않는 이름은 의미가 불명확하게 전달 될 수 있습니다. 그렇기 때문

관련주제 : Swift 난이도 : 하 디버깅 디버깅 모드에서 내 코드가 정상동작하는지 확인하기 위한 함수 입니다. 예를 들면, average = total / count 가 있을 때 count 가 0이 될 수 있다면 문제가 발생합니다. 그 상황을 디버깅 하기 위해서 물론 출력을 해도 됩니다. if count == 0 { print("0이 되었습니다") } 하지만 너무나 불편하기 때문에, assert(count != 0, "0이 되었습니다") 로 좀 더 의도를 명확히 할 수 있습니다. assert 함수를 어떻게 쓸 수 있는지는 공식 문서 를 참고하는 편이 명확합니다. 간단히 설명드리면 assert(조건, "조건문이 false 일 때 출력할 메시지") 입니다.