LEEO TIL Dev Log

[swift] swift 기본 문법 스터디 8주차 상속 서브클래싱 상속 받아 새로운 클래스를 만드는 것 상속 받은 클래스의 프로퍼티와 메소드는 다 가진채로 추가 구현을 해줌 상속은 1개만 가능, 나머지는 프로토콜 중복의 문제 오버라이딩 덮어쓰기 상속받은 메소드와 프로퍼티를 재정의(덮어쓰기 가능) 메소드는 인자와 반환타입까지 일치 프로퍼티는 연산형으로 get, set 구현 타입 캐스팅 상속을 받으면 타입이 달라지는데, 이를위해 타입을 변환할 수 있다. 타입 비교 연산 is로 비교하고, 같은 타입이거나, 상위 타입이면 true를 반환 그 외에는 모두 false를 반환 타입 캐스팅 연산 as 를 이용해서 캐스팅 다운 캐스팅과 업캐스팅 가능 업 캐스팅은 보통 문제없음 (as) 다운 캐스팅은 문제가 생길 수 있음 (as?, as!) Any, AnyObject 모든 클래스와, 타입의 부모 어떤 캐스팅도 가능하다 제공 메소드, 프로퍼티가 없음 초기화 구문 init 초기화 메소드 init 이라는 이름의 메소드는 초기화에 사용됨 인스턴스를 생성할 때는 이름을 호출하지 않아도 가능 인스턴스 생성시 간접 호출 여러개의 초기화 구문작성 가능 (오버로딩 지원) 초기화 구문의 오버라이딩 상속받아 초기화를 하면 부모의 프로퍼티가 초기화가 되지 않음 super.init()으로 초기화 가능

iOS 개발자가 되어버린 데이터 분석가의 2020년 개인적으로 많은 변화들과 도전들이 있었던 한 해 였습니다. 많은 시행착오를 통해 나가아갸 할 방향을 정하는데 있었던 일들을 정리 해 두도록 하겠습니다. 저와 같은 커리어를 고민하시는 분들에게 도움이 되었으면 좋겠고, 또한 무지한 저를 깨우쳐 주시거나 가르쳐 주실 댓글도 환영입니다 ㅎ _ㅎ. 커리어 전환 첫 회사에서 데이터분석가로 일을한지 3년차가 되면서, 많은 한계를 느꼈습니다. 더 이상 흥미가 느껴지지 않기도 하고, 한 가지 이유보다는 여러가지 복합적인 이유와 iOS개발자로 커리어 전환할 수 있는 계기가 생겨서 도전하게 되었습니다. 물론 여태까지 쌓았던 커리어를 포기하는 것은 아깝지만 스스로 이 일을 하고 싶지 않다 라는 결론에 도달하며 미련없이 전환 했습니다. 아무 기반지식이 없었고, 오히려 개발자로서 역량이 부족했기에 좀 더 두려워 하면서 전환했으면 좋았을 텐데라는 아쉬움이 남았습니다. 예를 들면 기본적인 협업도구의 사용방법, 배포 전략에 대한 이해, 업무 분담의 방법, 테스트 및 QA 진행방법에 대한 지식이 부족한 상태에서의 커리어 전환은 너무나 큰 리스크 였지만 그 당시에는 알지 못했기에 하마터면 어쩔 뻔 했나 라는 생각에 지금도 등골이 서늘합니다. 관련 링크 개발자로 랜딩하기 가장 먼제 apple 생태계를 이해하는 것 부터 난관이었습니다. 인증서관리, 개발도구, 라이브러리 관리 등, 생각지 못한 부분들을 공부하는 것에도 시간을 많이 쏟았습니다. 가장 중요한 기초체력인 개발 언어를 한 번은 빠르게 다 공부하고 계속 이해하도록 시간을 쏟았어야 하는데 그러지 못하고 SDK 및 API에 너무 많은 시간을 할애 한 부분이 아쉬웠습니다. 지금이라도 한 언어를 깊게파 기초 체력을 다지는 중 입니다. 그 다음은 많이 만들어 보는 것 이었습니다. 개발자가 된다는 것은 말 그대로 개발을 하는 것 이었습니다. 많은 앱들을 보고 어떻게 구현했을까 고민하고 전체가

[swift] swift 기본 문법 스터디 7주차 일급 객체로서의 함수 특성 런타임에서 생성가능 인자값으로 객체 전달가능 반환값으로 객체를 사용할 수 있어야 함 변수, 데이터 구조 안에 저장 고유한 구별이 가능 변수나 상수에 함수를 대입할 수 있음 함수의 결과값을 변수나, 상수에 대입하는 것이 아는 그 자체를 변수나 상수에 대입할 수 있습니다. func printAddFive(base: Int) -> String { return "결과 값은 \(base)입니다." } let fnc1 = printAddFive(base: 4) // 결과 값은 9입니다. 위의 예제는 함수를 선언하고, 그 함수의 결과값을 변수에 저장하는 예제 입니다. let fnc2 = printAddFive fun2(5) // 결과 값은 10입니다. 이렇게 함수 자체를 대입하고, 인자를 넣어서 호출 할 수 있습니다. 하지만 왜 _ 이렇게 라벨을 없애지 않았는데 없어진 걸까요? 변수를 대입하는데에 타입이 필요하고, 같은 타입에 연산이 가능 하듯이 함수도 마찬가지 입니다. 함수도 함수 타입이 있습니다. (인자타입1, 인자타입2) -> 반환타입 우리가 위에서 만든 printAddFive 함수의 타입을 적어보면, (Int) -> String 이 되겠군요. 함수의 반환타입으로 함수를 사용할 수 있음 함수의 반환에는 자료형이나, 클래스, 구조체 뿐만 아니라 함수도 반환할 수 있습니다. 그러면 어떻게 생겼을까요? func desc() -> String { return "desc 함수입니다." } func pass() -> () -> String { return desc } let p = pass() p() // desc 함수입니다. 위의 예제 코드를 보면, pass 함수는, () -> String 이라는 함수를 반환 합니다. 그리고 그

[Xcode] Breakpoint를 이용한 디버깅 툴 응용 문제를 해결하기 위해서는 디버깅을 해야하는데, 좋은 디버깅 도구가 있음에도 프린트 문을 쓰거나 po 명령어만 쓰고 있는 자신을 발견하여, 좀 더 좋은 도구의 사용법을 익히고자 정리 해 둡니다. signal SIGABRT break point 프로그래밍을 하다 보면, 어디서 왜 죽었는지도 알기 전에 Thread 1: signal SIGABRT 빨간 라벨이 나와서 매우 분노한 일이 많았습니다. 이럴 때 어디서 죽는 건지 브레이크 포인트도 걸 수 없는데 어떻게 해야할까요? 브레이크 포인터 네비게이터로 간 후, 왼쪽 하단에 Exception Breakpoint를 누른 후 아무 곳이나 클릭 한 후 다시 실행 시켜 줍니다. 이번에는 Exception이 발생한 지점에서 멈춰있는 것을 알 수 있습니다. 브레이크 포인트를 걸지도 않았는데 말이죠. 그 다음은 브레이크 포인트가 걸려있는 지점을 살펴 보아야겠죠? 브레이크 포인트로 로그 남기기 원하는 곳에 브레이크 포인트를 걸고 값을 출력 해 본 적있으신가요? 예를 들면, 스크롤뷰에서 화면내 이미지의 마지막 순간 값을 출력 해 보려고 했던 경험 저는 많은데요. 스크롤 할 때마다 계속 브레이크 포인트에서 걸려 매우 난감했던 순간이었습니다. 이럴 때는 원하는 곳에 브레이크 포인트르 지정하고, 브레이크 포인트를 우클릭 합니다. edit breakpoint 를 누르면 이름과 조건을 설정할 수 있습니다. 하지만 우리가 필요한 기능은 Action이 Debbuger Command 입력란에 우리가 항상 브레이크 포인트가 걸리면, 입력해주는 lldb 명령어를 입력해줍니다. 예를 들면, po self.contentsOffset 과 같이 말입니다. 그리고 Automatically continue…를 체크 해주면, 이제 멈추지 않고 커맨드창에 출력됩니다. 더 나아가서, Action에 값을 Debbuger Command이 아닌 Log M

[iOS] GCD와 Operation Queue GCD를 공부하던 중 정리가 잘 되지 않아 정리 해 보려고 합니다. 그리고 같이 공부할 키워드로 떠오른 Operation Queue와는 어떤점이 다른지 정리 하려고 합니다. GCD(Grand Central Dispatch)는 멀티 코어 하드웨어에서 코드 동시 실행을 지원합니다. 코드의 동시실행을 이해하려면, 실행의 단위를 잘 알아야 합니다. 코드를 작성하면, 어떠한 기능을 하는 파일이 됩니다. 이를 프로그램 이라고 합니다. 이 프로그램은 운영체제의 메모리에 올라가며, 프로그램의 인스턴스를 생성합니다. 이를 프로세스 라고 합니다. 프로세스는 운영체제로 부터 독립된 자원을 할당 받습니다. 그리고 그 프로세스에서 여러가지의 일을 실행하는 단위를 쓰레드 라고 합니다. 쓰레드는 프로세스가 할당 받은 자원 중 독립적으로 스택만 새로 할당 받고, 나머지 자원들은 쓰레드끼리 공유합니다. 정래 해보면 코드로 프로그램을 실행하고, 그 프로그램이 하나 실행되면 하나의 프로세스가 생성됩니다. 그리고 그 프로세스 안에서 흐름의 단위가 쓰레드 입니다. 멀티 프로세스 와 멀티 쓰레드 이름으로 부터 의미를 유추 해 보도록 하겠습니다. 멀티 프로세스란 하나의 프로그램 안에 어려가의 프로세스가 동작할 수 있도록 하는 것 이겠군요. 그렇다면 하나의 프로그램 안에서 각각의 독립적인 자원을 할당받은 프로세스들이 기능을 할테니, 프로세스끼리 영향을 주지 않아 독립적으로 사용할 수 있어서 좋겠습니다. 하지만 반대로 공유하는 자원이 없어서, 데이터를 전송하고 받아야겠네요. 멀티 쓰레드란 하나의 프로세스에서 여러개의 쓰레드를 사용하는 방법 일 것 입니다. 멀티 프로세싱의 방법과 반대로, 공유하는 자원이 있으며, 데이터를 전달하는 방법이 간단할 것 같습니다. 하지만 공유하는 자원이 있따는 것은 잘 못 관리하면 의도하지 않았던 데이터의 왜곡이 일어나서 버그를 만들기 쉽겠습니다. 동시성 과

[app review] 앱 살펴보기 - Share the meal App store best of the 2020 앱 중 하나로 선정된 ShareTheMeal 을 살펴 보았습니다. 앱의 구조 4개의 탭으로 이루어진 앱 입니다. 각각의 탭 메뉴를 선택 했을 때는 아이콘의 색이 변하면서 화면 전환이 일어납니다. 크게 복잡하거나 화려하지 않은 심플한 구조 입니다. 기부하다 페이지 카드 스와이핑 페이지 입니다. 비슷한 라이브러리는 SwipingCarousel 라는 것이 닮아 보였습니다. 꽉찬 화면이 아닌, 이쁜 테두리로, 굉장히 아름다워 보입니다. 미묘하게 가운데 카드는 크고 양 옆 카드들은 크기가 작아지는 것도 재미있네요. 꼭 한번 구현 해 보겠습니다! 와이파이의 환경에서는 메인 이미지를 썸네일로 한 동영상이 자동 재생됩니다. 연결된 네트워크를 탐지해서, 동영상을 컨트롤 하는 방법에 대해서도 정리 해 보도록하겠습니다. 상세 페이지로 들어가면, 이미지와 프로그레스바, 그리고 내용들이 나옵니다. 하단에는 후원하기 버튼이 있고요. 이미지 갤러리의 경우에는 콜렉션 뷰로 되어있고 하단의 콜렉션뷰와 연동되어 클릭하면, 해당 이미지가 나옵니다. 애플지도를 쓰는 것도 처음봐서 신기했습니다. 복사는 웹페이지의 링크가 되고, 누르면 해당 앱으로 떨어집니다. 바로 앱으로 떨어지는 다이나믹링크를 쓰면 좋았을 것 같네요. 기부 등록 이 페이지는 정기 후원을 위한 페이지로, 콜렉션 뷰로 설명을 해주고 후원하기 버튼을 누르면 후원 페이지로 이동합니다. 후원 페이지는 카드를 스와이핑 하면서 메뉴를 고를 수 있는 페이지 입니다. 커뮤니티 그룹을 만들거나 참여할 수 있습니다. 마찬가지로 컬렉션 뷰로 추천팀을 고를 수 있으며, 이 탭은 상단에 또 작은 탭바가 한 번 더 들어가 있습니다. 탭바는 클릭 했을 때 부드럽게 그림자가 이동하는 걸 볼 수 있었습니다. 프로필 나의 정보가 나오고, 정기

[dev] 구글의 코드 리뷰 기술 블로그에 약간 지침을 느끼고, 하나씩 배운 것들을 정리하고자 최근에 읽었던 글 중 기억에 남는 부분 위주로 번역하겠습니다. Code Reviews at Google are lightweight and fast 라는 글 입니다. 구글에서 코드리뷰는 엔지니어의 중요한 역할 중 하나 입니다. 엔지니어들은 코드를 깔끔하게 관리하고자 하기 때문이죠. 마이크로 소프트의 코드리뷰와 비슷할 수 있으나, 구글만의 특징이 있습니다. 그래서 구글에서의 코드리뷰 방법을 소개하도록 하겠습니다. Code Review Study at Google study to understand Google’s internal code review processes 논문에 기술한 방법으로 코드리뷰를 합니다. Preparing code for review 코드를 수정하면 마크가 생기고, 변경사항이 머지되고 나면 코드리뷰가 시작됩니다. 구글은 내부 코드리뷰 도구인 Critique 로 변경사항을 먼저 체크합니다. 코드리뷰를 보내기 전에는 정적 분석도구를 통해 코드를 실행합니다. 내부에서 사용되는, Tricorder를 실행하고 결과를 검토합니. 그리고 최소 한명 이상의 리뷰자를 선정해 리뷰를 요청합니다. Reviewers give feedback 리뷰어는 코드를 살펴보고 문제가 있거나 설명이 필요한 경우 코멘트를 남깁니다. 그 다음 요청자는 코멘트를 회신하여 코멘트를 처리합니다. 코드가 수정되었을 경우에는 새 버젼을 올려 변경사항을 확인할 수 있게 합니다. 리뷰어가 만족하면 LGTM(Look good to me) 를 표시하여 승인 합니다. Code Reviews at Google 모든 변경된 코드는 리뷰 되어야 합니다. 75% 이상의 코드는 한명의 리뷰어가 승인했습니다. 승인한 리뷰어 또한 코드에 오너쉽을 가지며, 가독성에 대한 보장을 해야합니다. 작은 리뷰는 1시간 이내에, 커도 4시간 안에는 리