2022의 게시물 표시

2022년 커뮤니티활동에 대한 회고

이미지
더 보기 편한 링크 는 이 곳을 눌러주세요 2022년은 커뮤니티와 함께 보냈다고 해도 과언이 아닌 해였습니다. 커뮤니티의 힘을 알고있기에 그리고 커뮤니티를 통해 많은 성장을 했었기에 커뮤니티 활성화에 많은 시간과 에너지를 쏟았습니다. 무슨 짓(?)을 했었는지 그리고 어떤 변화들이 있었는지 또 그 일들이 어떤 변화를 기대하며 한 일들 이었는지를 정리해 보려고합니다. 발표 가장 쉽게 기여할 수 있는 것이 발표자로 커뮤니티에 기여하는 것 이었습니다. ‘커뮤니티에 기여하는 방법 중 가장쉬운 방법이 발표’ 가 아니라 현재 가장 쉬운 방법이 발표 였습니다. 최근 한국의 iOS 커뮤니티는 이전에 발표했던 발표자와 오랜기간 공부한 것을 정리해서 발표한 것들이 주를 이루었습니다. 물론 컨퍼런스에서는 배울만한 것들이 많아야 하는 것도 맞지만 새로운 사람들이 진입할 수 있도록 하는 것도 중요하다고 생각했습니다. 그래서 제가 할 수 있는 간단한 것들에 대해 발표를 하고 ‘저 정도는 나도 발표할 수 있겠다’ 혹은 나도 다음에 저 정도의 난이도는 공부해서 발표하고 싶다라는 생각이 들 수 있게 발표했습니다. 물론 발표한 내용 모두 누군가에게는 도움이 될 만한 스스로 학습하면서 정리한 내용들 이었습니다. 발표에 정성과 노력이 들어가는 것은 듣는 청중의 시간과 노력에 대한 예의라고 생각합니다. 대충 발표자라는 타이틀 컬렉터가 되고 싶어서 발표를 하는 사람이 많다면 커뮤니티는 가고싶지 않은 곳이 되어버릴 것 입니다. 하지만 발표를 듣는 사람들이 올라올 수 있는 장치들을 만들어 줘야 그 다음, 그 다음 사람들이 같이 성장할 수 있다고 생각했습니다. 저는 iOS를 시작하자마자 3개월만에 발표를 시작했습니다. 그 경험은 저를 엄청나게 성장시켰고, 또 공부하게 만들어 주는 원동력이 되었습니다. 발표에도 문화가 필요하고, 노력하고 최선을 다하지만 그래도 발표한 사람에게 박수를 보낼 수 있는 발표를 할 수 있는 문화를 만들어보고자 한 해동안 열심히 발표했습니다. 오거나이저 다양한 오거...

2022년 테크 멘토 / 코치에 대한 회고

이미지
좀 더 보기 쉬운 링크 를 준비했습니다. 2022년에는 iOS 개발자에서, 테크 멘토 / 코치로 새로운 커리어를 시작했습니다. 처음에는 강사, 교육자라고 생각했던 커리에서 다른 커리어 였다는 것을 깨닫고 난 후에 했던 시행착오와 의문들을 적어보았습니다. 한 해에도 몇 번의 생각이 바뀌었고, 그래서 앞으로도 바뀔 때 마다 적어두어야겠습니다. 선생님과 멘토는 무엇이 다른가요? 선생님과 멘토의 가장 큰 차이점은 정보의 전달이라고 생각했습니다. 어떤 방법이 더 나은 방법이다 라고 말할 수 없기 때문에 차이점에 초점을 맞춰서 답을 찾았습니다. 제가 처음에 가진 마인드는 선생님이었습니다. 질문을 하는 사림(학생)이 더 많은 것을 알도록 내가 아는 것을 전해주고, 그들이 모르는 것을 물어봤을 때 답을 해주는 사람이었습니다. 하지만 2022년을 보내면서 많은 시행착오 끝에 생각의 변화가 있었는데, 가장 처음에 든 생각은 선생님과 멘토는 다른 직군이다 였습니다. 그렇기 때문에 다른 일을 하는것이 자연스럽다고 생각했습니다. 그 다음으로 나아간 생각은 스스로 생각을 할 수 있게 도와주고, 그들이 넘어지고 쓰러졌을 때 응원해서 일어나게 하거나, 일어날 수 있도록 도움을 주는 사람이라고 생각했습니다. 이 것이 현재 많이 쓰이고 있는 멘토라는 용어의 정의와도 닮아 있다고 생각했습니다. 하지만 1년의 여정의 끝을 다 보고나면서 한 번 더 생각이 바뀌었습니다. 결국 (테크) 멘토는 그들의 잠재력을 발휘할 수 있도록 선택지를 높여주고, 그들의 깨달음을 도와주는 사람 이었습니다. 이 과정에서 중요한 것은 멘토의 생각을 주입하지 않는다 였습니다. 멘토의 경험과 생각을 주입하지 않고 그들의 잠재력을 끌어올리는 일은 너무나 어려웠습니다. 결국 멘토의 역할은 크게 2가지로 정리되었습니다. 그들의 선택지를 어떻게 늘려줄 수 있을 것인가? 그들의 깨달음을 어떻게 도와줄 것인가? 좋은 질문을 하는 방법은? 좋은 멘토의 역할은 결국 좋은 질문을 멘티들에게 던져주는 것입니다. 이런...

파이콘에서 첫 (테크)토크 콘서트를 마친 뒤…

이미지
좀 더 편하게 볼 수 있는 노션링크 입니다. 파이콘 한국 2022의 프로그램 중 하나로 토크 콘서트를 준비하게되었습니다. 행사에 대한 제안과 주제를 같이 전달 받아서 실제로 한 것들은 어떤 질문을 해야하는가 였습니다. 실제로 질문을 던지는 사람의 의도와 질문에 답하는 사람은 다른 생각을 할 수 있다고 생각합니다. 그래서 제가 실제로 던졌던 질문의 의도와, 그 리스트를 남겨놓으려고 합니다. 정답은 없는 질문이고, 또 이미 본인의 답을 정리해 주신 분이 계셔서 같이 공유 합니다. 채용과 구인 구직에 대한 궁금증 이런 사람을 채용하고 싶다는 어떤 뜻 이라고 생각하는지 궁금합니다. 새로운 기술에 거부감이 없으신분 새로운 문화를 만들어가실분 프로그램 개발 경험이 있고 동작원리를 이해 커뮤니케이션 및 협업 능력 필요 신입을 채용한다는 것에 대한 의미 왜? 기대하는 바? 취업 시장이 얼어붙을 것 이다라는 것에 대한 생각 채용시 고려해야할 것, 채용시 나만의 강점을 만드는 팁 3년차 개발자는 어떤 사람인가요? 내가 잘하고 있었다라는 신호는 어떻게 알 수 있나요? 개발자의 한계선과 경계선이란 어떻게 생각하시나요? 잡부가 되는것은 아닐까 걱정됩니다 하나의 프레임워크 언어 안에 갇힐까 걱정됩니다 취직 이직에 도움이 되는것들의 본질은 무엇인가요? 무엇을 보여줘야 하나요? 나만의 업무성향 확인 방법이 있을까요? 좋은 개발자와 좋은 개발문화 좋은 개발자란 어떤 개발자라고 생각하나요? 좋은 개발/코드란 어떤 것 이라고 생각하나요? 좋은 코드리뷰문화는 어떤 것 이라고 생각하나요? 오픈소스 참여 왜 오픈소스를 해야하나요? 오픈소스를 하면 나에게는 뭐가 좋아요? 저는 처음인데 무엇부터 해봐야할까요? 오타 찾기 같은것들은 해봤지만 아직 저는 처음이라고 생각됩니다 코드레벨에서 기여를 하는 방법의 벽이 너무 높은데 어떡할까요? 언제 하면 좋은가요? 매일매일 조금씩? 아니면 해커톤 처럼 쭉? 자꾸 까먹어요 덩치가 커서요...

개발 멘토의 커리어 1년차, 6개월 진행 중

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

iOS 여행을 위한 지도 챙겨가세요

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

Hey SwiftUI! SF Symbol4 is Coming!

이미지
좀더 편하게 보시려면 노션링크 를 눌러주세요! 앱을 개발하다보면, 버튼의 이미지를 찾아 헤메이던 시간이 꼭 존재했습니다. 홈 버튼, 설정 버튼에 들어갈 이미지들을 찾는 것이죠. 하지만 지금은 그렇게 시작하지 않습니다. 왜냐하면 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 독학을 시작하기 전에 보면 좋은 이야기

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

[인터뷰질문 024] 컴파일러 조건인 canImport()은 어떤 역할을 하나요?

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

iOS 개발할 때 영어로 변수 이름 잘 짓는 방법

이미지
개발을 하면서 개발자가 가장 많은 시간을 쓰는게 변수 명을 짓는 것 이라는 이야기가 있습니다. 이게 그냥 우스갯소리로 나온 것이 아니라, 제 개인적인 경험만 돌아봐도 개발시간의 많은 부분을 변수를 짓고 변수를 어떻게 지어야 하나 고민했습니다. 그 이유는 변수 명에 따라 그 이후의 개발 속도가 달라지기 때문입니다. 그래서 지금 짓는 변수에 많은 고민을 하고 시간을 소요하게 되었습니다. 글로는 알기 어려우니 예를 들어서 코드로 설명해 보겠습니다. 불명확한 이름이 가져오는 참사 틀리지는 않았지만 불명확한 이름이 가져오는 참사는 다음과 같습니다. 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 } 영어 문법에 맞는 이름 변수 이름을 영어로 짓기 때문에, 문법에 맞지 않는 이름은 의미가 불명확하게 전달 될 수 있습니다. 그렇기 때문...

[인터뷰질문 023] assert() 함수는 무엇을 하나요?

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

[인터뷰질문 022] #if 문은 언제 사용되나요?

이미지
관련주제 : Swift 난이도 : 하 코딩을 하다가 보면 자주 보던 코드인데 언제 쓰는지 정리해 보도록 하겠습니다. #if 는 컴파일 이전에 처리되는 전처리문 입니다. 즉 컴파일되기 전에 참, 거짓을 판별해서 거짓으면 컴파일이 되지 않는다는 뜻이죠. Compiler Control Statements 주로 보던 코드는 #if DEBUG , #if os 와 같은 코드였습니다. 한 번도 찾아본적이 없어서 #if 다음에는 어떤 문구가 들어갈 수 있는지 찾아보았습니다. 링크 Swift 버전이 다른 문법을 하나의 파일에서 처리하거나, 운영체제 버전이 다른 분기를 만들어 사용할 때 주로 사용합니다. 참고 : https://docs.swift.org/swift-book/ReferenceManual/Statements.html#grammar_conditional-compilation-block

[인터뷰질문 021] 컴파일러용 #error 지시문은 어떤 용도인가요?

이미지
관련주제 : Swift 난이도 : 하 개발을 하다가보면, 먼저 구조만 잡아두고 나중에 구현을 해야하는 경우가 종종 있습니다. 이 때 저는 주로 //TODO: 혹은 //FIXME: 를 적어놓습니다. 그러면 Xcode에서 도큐먼트 메뉴에서 시각적으로 확인 할 수 있습니다. 자주사용하던 기능이었는데, 불편한 점이 하나 있어습니다. TODO:는 문자열 찾기로 찾아갈 수는 있는데, 구현을 까먹었을 때 이를 확일할 만한 방법이 없었습니다. 왜냐하면 컴파일에 영향을 주지 않기 때문이죠. 나 자신의 실수를 막기 위해서 사용하는 안전장치가 필요했습니다. MustTODO와 같은 기능이죠. 그래서 그 뒤로는 꼭 다시 돌아와야 하는 경우에는 컴파일러용 지시문을 사용합니다. 컴파일러용 지시문 #warning("message") 와 #error("message") 를 사용합니다. 그러면 컴파일을 했을경우 경고문이나, 에러문구가 Xcode의 왼쪽 네비게이터 중 에러 쪽에서 메시지가 출력됩니다. 아 이 부분을 꼭 구현했어야 했지 처럼 컴파일에 경고를 띄워주거나, 에러를 일부러 발생시킬 필요가 있을 때 사용하면 됩니다.

개발을 시작할 때 git을 꼭 같이 시작했으면 하는 이유

이미지
개발을 시작하면 반드시 접하게되는 단어들이 있습니다. 그 중 하나는 git 입니다. 그렇다면 git을 왜 써야하고, 어느정도까지 써야하는 걸까요? 그에 대한 생각을 간단히 적어보겠습니다. git은 왜 써야 할까요? git은 크게 2가지의 이유로 사용한다고 생각합니다. 버젼관리 협업도구 그래서 우리는 우리의 코드가 잘 못 되었거나 과거의 코드로 되돌릴 때, git을 씁니다. 예를 들면, 내가 작성했던 코드가 문제가 생겼을 때 과거로 돌아갈 수 있다면 얼마나 좋을까요? 하나하나 되돌리기를 하는 것이 아니라 특정의 시점으로 돌아갈 수 있다면 나의 실수를 만회하기에 좋겠죠? 여러분의 실수를 되돌리기 위해 git의 사용방법을 익혀두세요! 다른 개발자와 협업을 해야할 때 협업의 도구로서 git을 사용합니다. 개발을 혼자하는 개발자도 있지만 많은 개발자들이 하나의 프로덕트를 만들기 위해 협업을 하고 있습니다. 서로 일할 범위를 나누고 따로 작업한 다음에 하나로 합친다면, 일을 효율적으로 할 수 있고, 결과물도 더 빠르게 만들 수 있겠죠? 생산성을 높이기 위해 git을 사용하세요! git 어느정도까지 써야하는 걸까요? 왜 써야하는지 알았으니 그러면 얼마나 써야하는지 이야기 해봅시다. 먼저 버전관리를 하기 위해서라면, commit을 꼼꼼히 하고 해당 커밋 때로 돌아가는 방법을 알면 좋을 것 입니다. 아니면 다른 사람이 작업한 내용 중 일부 혹은 내가 과거에 작업한 내용을 살리기 위한 cherry-pick 등과 같은 기능들을 알면 유용하겠죠? 다른 사람들과 협업을 하려면, git-flow는 이헤하고 사용해야 합니다. 나 혼자 git에 commit, push, pull을 한다고 git을 사용할 줄 안다고 생각한다면, 실제 협업을 하면서 많은 어려움이 있을 것 입니다. 어느 브랜치에서 개발을 해야하고, 어느 브랜치로 merge를 해줘야 하는지 알고 있어야 합니다. 더 나은 개발을 위해서 개발자로 시작하면서 git을 왜 해야하는지, 얼마나 해야하는지는 잘 공감...

Leeo Con

이미지
  Welcome to the LeeoCon. world! Just click for Drag & Drop the LeeoCon You can use several LeeoCons

Lullaby Recipe

이미지
  How to use Lullaby Recipe Type your username. 2.  Go to Kitchen tab to create your new recipe. 3.  Select the sound you like and tab ‘Blend’ button. 4.  Name and save your own mix. 5. Listen to your own recipe. If needed, control the volume for each sound.

SwiftUI에서 뷰를 떼어내는 방법

이미지
SwiftUI에서 UI를 그리다 보면, 뷰를 따로 떼어내서 작업을 해야하는 경우들이 발생합니다. 글로 설명해서는 상상하기 어려우니 아래 코드를 보면서 이야기 해보겠습니다. struct ContentView : View { var body : some View { VStack { VStack { Text ( "리이오" ) Rectangle () .fill (Color.red) .frame ( height : 30 ) Text ( "올리비아" ) } .background (.green) Button { print ( "done" ) } label : { Text ( "Button" ) } } } } 우리의 코드는 VStack 안에 또다른 VStack과 Button이 있습니다. 저 사용자 이름이 들어있는 VStack이 복잡해질 경우 따로 떼어내서 작업을 하는 경우가 많습니다. 일단은 body가 길어지면 보기 힘들기 때문이죠. 이 때 사용하는 방법에는 여러가지가 있지만 오늘은 2개를 비교해 보겠습니다. 새로운 Struct를 만든다 새로운 뷰를 그리기 위해서 새로운 struct를 만들어서 그리는 방법이 있습니다. 이전 코드보다 보기가 한결 쉬워졌습니다. 또 ProfileView 부분이 늘어나도 ContentView는 늘어나지 않아서 가독성도 좋습니다. struct ContentView : View { var body : some View { VStack { ...

Self Check In 앱 설명 글

이미지
이 글은 Self Check In 앱의 사용 법을 설명 해 놓은 글 입니다. 1. You can scan QRCode by camera 2. When you scan valid QRCode, You can check data at calendar 3. You can make profile by Sign In with Apple 4. You can create QRCode by create group 5. Also you can join group 6. Enter group code  

[인터뷰질문 020] raw strings 이란 무엇인가요?

이미지
관련주제 : Swift  난이도 : 하 raw strings raw strings 는 swift5에 추가된 자연스러운 String을 쓰는데 도움을 주는 기능입니다. 지연스러운 String은 어떤 걸까요? 아래의 문자열을 비교해 보겠습니다! let naturalString = # "" Hello world! "" # let unNaturalString = "\"Hello world!\"" print(naturalString) // "Hello world!" print(unNaturalString) // "Hello world!" 익숙함에 따라 어떤 문자열이 더 자연스러운지가 다를 수 있을텐데요, 설명을 드리자면 # 기호 사이에 "" 이렇게 문자열을 나타내주는 기호가 있다면, 그 사이에 있는 어떤 특수 문자도 자연스럽게 처리해줍니다. 기존에는 \ 기호를 특수 문자 앞에 붙여서 이 기호가 특수 기호인지 나타낼 필요가 없습니다. 말 그대로 자연스러운 문자열을 만들 수 있는 것입니다. 만약 문장 안에 # 기호를 사용해야 한다면, ## 기호를 문장의 시작과 끝에 붙여주면 됩니다. 활용법 기존에 문자열 사이에 변수를 넣는 방법과 다르니 유의 해주세요! let name = "Leeo" let normalString = "Hello, \(name) !" let rawString = # "Hello, \#(name)!" # let wrongRawString = # "Hello, \(name) !" # print (normalString) // Hello, Leeo! print (rawString) // Hello, Leeo! print (wrongRawString) // Hello, \(name)! 메리트 특정 상황에서 사용했을 때, 메...

[인터뷰질문 019] property observers란 무엇인가요?

이미지
프로퍼티와 옵져버 swift를 쓰다보면, 다양한 프로퍼티들이 있습니다. 쉽게 변수라고 알고있죠. 그리고 옵져버는 관찰자 혹은 감시자 정도로 번역할 수 있는데요. property observers 를 직역해보면 변수 관찰자 정도가 될테고, 그 내용은 프로퍼티의 수정사항을 탐지하는 것 입니다. 즉 프로퍼티(저장 프로퍼티)에 변경사항이 생기면, 옵져버가 알려주고, 특정 코드블럭을 실행할 수 있습니다. 글로만 설명하면 어려우니 코드를 통해 알아보도록 하겠습니다. class PointCounter { var totalPoint: Int = 0 { willSet (newTotalPoint) { print ( "점수의 합을 \(newTotalPoint) 점으로 변경할 예정입니다." ) } didSet (oldTotalPoint) { print ( " \(totalPoint - oldTotalPoint) 점이 변경되었습니다." ) } } } let pointCounter = PointCounter () // 점수의 합을 200점으로 변경할 예정입니다. pointCounter.totalPoint = 200 // 200점이 변경되었습니다. // 점수의 합을 300로 변경할 예정입니다. pointCounter.totalPoint = 300 // 100점이 변경되었습니다. // 점수의 합을 200점으로 변경할 예정입니다. pointCounter.totalPoint = 200 // -100점이 변경되었습니다. willSet didSet 이름부터 매우 직관적이죠? 이름에서 부터 알 수 있듯이 willSet은 프로퍼티가 변경되기 바로 직전에 호출 됩니다. 그리고 예상한 대로 didSet은 프로퍼티가 변경된 직후에 호출 됩니다. 그러니 우리가 pointCounter.totalPoint 를 500으...

2년만에 개발자를 멈춘 iOS 개발자의 2021년 회고

이미지
2020년의 시작과 함께, iOS개발을 시작하게 되었었고, 1년이 지난 시점에 회고를 작성했었습니다. 이제는 3년차 iOS개발자가 되면서 구상하게 된 회고는 작년에 기대했던 내용들과 많이 달라서 스스로도 놀랐습니다. 가능한 순서대로 정리해보도록 하겠습니다. 월간 리이오 (1월 1앱 출시) 2년차 iOS개발자가 되면서 엄청난 자신감과 함께, 호기롭게 세운 1월 1개인앱 프로젝트인 월간 리이오를 시작했습니다. 결과부터 정리하면 망했습니다. 한 달에 한개의 앱을 만들 수는 있지만 3개째를 만들던 때에 그만두게 되었습니다. 그 이유를 천천히 생각해보니 문제점이 몇가지 있었습니다. 1. 똑같은 구조와 기술을 반복해서 쓰는것에 재미를 못느낀다 한 달이라는 기간내에 빨리 만들어야 하다보니까, 이전에 만들었던 구조, 코드들을 계속 쓰고 있는것에 지루함을 느끼게 되었습니다. 물론 같은 것을 반복하면서 익히는 것도 중요하다고 생각합니다. 하지만 개인앱은 내가 공부하고 싶은 것들을 녹여서 개발하는게 지속적인 동기부여의 방법으로 더 적절하다는 결론에 도달했습니다. 또한 어떻게 하면 더 나은 코드를 생산할 수 있을지에 대한 고민도 필요합니다. 2. 새로운 앱을 계속 만드는 것보다는 기존에 만든 앱을 고도화 하는게 낫다 개인적인 취향의 차이 이겠지만, 아주 간단한 기능들을 계속 만드는 것보다는 사용자를 생각하거나 아니면 만들어 보고 싶었던 기능들을 계속 만드는게 좀 더 완성도 있는 앱을 만드는게 아닌가 라는 생각을 했습니다. 갯수에 집작하는 것이 아닌 결과물의 퀄리티에 좀 더 집중할 필요가 있다고 생각했습니다. 마치 1일 1커밋의 연속일수에 집중할 필요가 없다고 느낀것과 같은 맥락입니다. 3. 번아웃을 유발한다 매일 무언가를 만들고 또 기존의 존재하는 문제를 해결하는 즐거움은 개발을 하는 가장 큰 이유라고 생각합니다. 하지만 퇴근 후, 주말에 계속 이 생각들만 하다보니 어느 순간 너무지쳐있는 자신을 발견했습니다. 매월 앱을 만들어 내는 것은 나의 라이프 싸이클과 맞지 않...