LEEO TIL Dev Log

[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시간 안에는 리

블로킹 논블로킹 싱크, 어싱크, 블로킹, 논블로킹을 정확하게 모르는 사람은 바로 저 입니다. Synchronous VS Asynchronous 한국어로 동기와 비동기입니다. 동기는 2개의 작업이 있을 때, 첫 번째 작업의 종료시점과 두 번째 작업의 시작시점이 닿아있으면 sync 입니다. 보통 함수를 연달아 호출했을 때 순차적으로 출력이 된다면 Synchronous한 작업입니다. 비동기는 동기와 반대로 작업의 시간을 맞추지 않는 것 이죠. blocking VS non-blocking 기술 적으로 구분이 되며 함수의 호출을 생각하면 이해가 빠르기 때문에 함수호출로 설명하겠습니다. 볼로킹은 어떤 함수가 호출되고 작업이 끝날 때까지 반환값을 넘겨주지 않는 것을 블로킹 되었다고합니다. 논블로킹은 어떤 함수가 호출되고 작업이 요청된다음 반환값을 넘겨주면 논 블로킹 되었고합니다. 블로킹/동기, 블로킹/비동기, 논블로킹/동기, 논블로킹/비동기 이렇게 4개의 조합이 있을 수 있습니다. 언제쓰이고 어떻게 써야하는지 정리해보겠습니다. 블로킹/동기 예를 들어보겠습니다. 카페에서 손님이 줄을 서 있습니다. 1번, 2번, 3번. 캐셔가 주문을 받습니다. 1번손님 아메리카노 4잔. 캐셔가 주문을 받고 커피를 내립니다. 1번손님을 포함한 모든 손님은 기다립니다.(블로킹상태) 캐셔는 작업이 완료되면 1번손님에게 커피를 전달합니다. 1번 손님은 커피를 받아 카페에서 일을 시작합니다.(동기) 2번손님, 3번손님 순서대로 주문을 받아 전달을 합니다. 2번, 3번은 1번의 음료를 만들 때 아무것도 하지 못하고 기다리고 있습니다. 음료는 순서대로 나옵니다. 블로킹/비동기 예를 들어보겠습니다. 카페에서 손님이 줄을 서 있습니다. 1번, 2번, 3번. 캐셔(B작업)가 주문을 받습니다. 1번손님(A작업) 아메리카노 4잔. 캐서는 1번손님에게 자리에 앉아 일하고 계시면 불러주겠다고 합니다. 1번

[dev] 오픈소스 기행문 - 문서번역 오픈소스 기행문 - 문서번역 만화로보는 https 동작원리 오픈소스에 어떻게 기여하면 좋을지 계속 고민하던 중 처음 기여하기 좋다는 번역을 할 기회가 생겼다. 읽어보면 좋을만한 문서라고 소개받았는데, 원서였다. 읽어봤을 때 내용이 굉장히 마음에 들었다. 한글로 된 자료가 있으면 좋을텐데라는 생각을하다가 내가 번역을 하면 되겠지라는 생각이들었다. git에 바로 기여할 수 있는 형태가 아니라 관리자에게 번역문의를 했고, 흔쾌히 수락 해주었다. 문서는 만화였고, 생각보다 길었다. 번역작업을 하는 중 돈도 안받고 번역을 하는 이유는 정말 공익을 위해서구나 라는 생각을 많이 했다. 나도 한글로 된 문서를 많이 읽었으니, 누군가를 위해 한글로 된 자료를 남기고 싶다 라는생각이 많이 들었다. 나의 번역에 대해 어떻게 검증을 하는지는 잘 모르겠으나, 보내준대로 게시해주었다. 엄청 부끄럽고 창피하기도 했으나, 많은 사람들이 공유하는 것을 보고 내 생각보다 더 의미있는 일을 했다는 생각에 뿌듯했다. 또한 게시 후에 티셔츠와 작은 선물을 보내줄테니 주소를 달라는 요청을 받았다. 코로나 때문에 언제 올지는 모르지만 오면 착샷이라도 남겨야겠다. 처음 기여를 해보니 오픈소스에 기여하는 재미와 이유가 좀 더 명확해졌다. 조금 더 찾아보고 다음에는 버그픽스 정도의 기여를 할 수 있기를 바라본다.

Opensource에 기여하기 오픈소스에 기여해보는 첫 발을 내디딘기념 오픈소스를 시작하게 된 동기 개발자로 성장하면서 계속 가지고있던 갈증 중 하나는 협업 이라는 키워드였다. 결국 좋은 개발자란, 다양한 사람들과 다양한 일을 할 수 있는 개발자 일테니 말이다. 회사에서 하는 일도 성장에 도움이 되지만 자신이 생긱하기에 재미있어 보이는 프로젝트에 좋아하는 만큼 기여해보고 싶다라는 막연함으로 오픈소스를 찾게되었다. 하지만 이번이 첫 도전은 아니다. Github을 처음 알았을 때도, 오픈소스에 관련된 세미나를 들었을 때도 항상 꼭 컨트리뷰터가 되어야지 마음만 먹고 프로젝트만 뒤적뒤적거리다가 접은적이 한 두번이 아니었다. 그래서 이번에는 어떤 프로젝트에 기여하면 좋을지에 대한 검색 방법에 대해 찾아보았다. 이전에 받았던 조언들은, 너가 평소에 쓰는 서비스에서 불편한 점을 개선해 보아라, 오탈자 수정, 문서화작업을 해 보아라 라고 받았지만 와 닿지가 않았다. 그래서 이번에 선택한 방법이 내가 사용하고 있는 언어로 기여할 수 있는 프로젝트 찾기 와 Open source alternative 라는 키워드였다. 결국 처음에 받은 조언과 같은 맥락이다. 하지만 느끼는 시각을 다르게 해 주었다. 내가 돈내고 쓰고있는 어플리케이션에 대해 알아보는 시간과 어떻게 구현되었을까에 대한 호기심이 소스코드를 들여다보게 만드는 원동력이 되어주었다. 검색경로 hacktoberfest 오픈소스를 프로젝트 찾기를 검색하다보면 가장 먼제 눈에 띄는 페이지 중 하나가 핵토버페스트 이다. Details 페이지에 접속해보면, 친절하게 PR을 날리는 방법 어디서 어떻게 날리면 좋은지도 알려준다. ● Up For Grabs ● Issuehub.io ● First Timers Only ● Your First PR ● Awesome for Beginners ● This is another great guide Github Issue

[dev] 이펙티브 엔지니어 원문 : https://gist.github.com/rondy/af1dee1d28c02e9a225ae55da2674a6f 읽기전에 : 저는 여기에 제시된 내용(에드몬드 라우의 책의 개요)을 제작하지 않았습니다. 인터넷 어딘가에서 복사하여 붙여 넣었지만 원본 소스가 정확히 무엇인지 기억나지 않습니다. 또한 저자의 이름을 찾을 수 없었기 때문에 적절한 크레딧을 줄 수 없습니다. 이펙티브 엔지니어 에드먼드 라우 매우 추천 👍 http://www.theeffectiveengineer.com/ 이펙티브 엔지니어란? 이펙티브 엔지니어란 일을 제대로 끝내는 사람들입니다. 그들은 결과를 산출합니다. 올바른 사고 방식 채택 큰 영향을 미치는 일에 집중하라 레버리지 = 생성된 임팩트 / 투자한 시간 레버리지을 효율성의 척도로 사용하세요. 임팩트의 80%는 작업의 20%에서 발생합니다. 쉬운 승리 만이 아니라 높은 레버리지에 집중하십시오. 학습을위한 최적화 필요한 경우 작업을 변경하십시오. 학습 최적화는 높은 레버리지를 가져옵니다. 성장을 위한 사고 방식을 채택하십시오. 사람들과 대화하세요. 스토리 텔링에 능숙해지세요. 시간을 들일수록 나아집니다. 성장을 위한 사고 방식을 가진 사람들은 노력을 통해 지식과 기술을 습득하고 발전시킬 수 있다고 생각합니다. 당신의 이야기를 만드세요. 학습 속도에 투자 다양한 분야를 학습하세요. 다양한 분야에 대한 학습은 기하 급수적인 성장으로 이어집니다. 학습은 빨리 시작 될수록 좋습니다. 쉬운 작업을 수행하는 것은 엄청난 기회 비용입니다. 복합 학습의 기회를 놓칠 수 있습니다. 수익성보다는 학습을 우선시하십시오. 학습속도가 가장 높은 활동에 시간을 투자하십시오. 학습에 도움이되는 작업 환경을 찾으십시오. 빠른 성장을 할 수 있는 회사 (# 문제 수 >> # 자원). 해결했을 떄 영향력이 큰 문제를 선택할 수

[dev] 구글링 할 때의 팁 코딩을 하다가 에러메시지를 마주 했을 때 나에게 맞는 해결방법을 검색하는 방법의 팁에 대해 정리한다. * 사용하기 검색은 에러를 마주하면서 시작된다. 하지만 에러메시지를 그대로 복사 붙여넣기 해서는 나에게 필요한 질문과 답을 찾을 수 없다. 예를들면 could not cast value of type 'Test.Home ViewController' to 'Test.List ListController' 라는 에러메시지를 보고 해결하려고 전체를 복사 붙여넣기를 하면 이상한 결과가 나올 수 있다. 나의 코드에만 존재하는 키워드들이 들어있기 때문이다. Test.Home 나 ListController 와 같은 것들이다. 그럴 때는 * 를 활용해서 wildcard를 넣을 수 있다. 다음과 같은 검색어가 된다. could not cast value of type * to * . 이렇게 하면 나의 코드에만 있는 부분을 포함해서 검색할 수 있다. 특정 도메인의 활용 코드에서 발생한 대부분의 에러에 대한 질문과 답변을 stack overflow와 같은 곳에서 검색하고 싶다면, site : [domain] 과 같은 키워드를 사용해보자. site : stackoverflow.com could not cast value of type * to * 이전 검색어가 다양한 곳에서의 질의 응답 결과를 보여줬다면, 이번 검색 결과는 stackoverflow의 검색 결과만 보여준다. “swift” 같은 추가적인 키워드 활용 stackoverflow에 있는 질의 응답 중에서도 “swift” 질문들만 보고 싶을 수 있다. 이럴 키워드를 하나 추가해주자. site : stackoverflow.com swift could not cast value of type * to * 나에게 필요한 키워드 들을 추가함으로써 검색의 정확도를 올릴 수 있다. stackoverflow와 같은

[dev] Github issue labels Github에서 프로젝트의 문제점을 알리거나 기여를 할 때 이 issue label을 달거나 읽어야 할 일이 생긴다. 해당 이슈에 알맞은 라벨을 선택하고, 의미를 파악하기 위해 알아두자. keyword 의미 bug 예기치 않은 문제 또는 의도하지 않은 동작(버그)을 나타냅니다. documentation 문서를 개선하거나 추가 할 필요가 있음을 나타냅니다. duplicate 해당이슈 또는 PR이 기존에 있음을 나타냅니다. enhancement 새로운 기능 요청을 나타냅니다. good first issue 처음 기여해볼 사람에게 좋은 문제를 나타냅니다. help wanted 관리자가 문제 또는 PR 요청에 대한 도움을 원함을 나타냅니다. invalid 이슈 또는 PR 요청이 더 이상 관련이 없음을 나타냅니다. question 이슈 또는 풀 요청에 추가 정보가 필요함을 나타냅니다. wontfix 문제 나 PR 요청에서 작업이 계속되지 않음을 나타냅니다. 참고 : https://help.github.com/en/github/managing-your-work-on-github/about-labels

Google Blogger 검색 노출 방법 블로그를 한참동안아니 했는데, 방문자수가 너무 적어서 시들해지고 있을 무렵 글을 작성하는 것 만으로 사람들에게 노출되는 것이 아니라는 것을 알았다. 구글 서치 콘솔 에서 내 블로그의 URL을 크롤링 해 갈 수 있게 설정 해주어야 한다. 왼쪽 상단 아래 화실표를 클릭해서 속성 추가를 눌러준다. 일단 블로그의 주소를 등록해 주어야 한다. 속성이 추가 되었으면, Sitemaps를 등록해 홈페이지의 구조를 알려주어야 한다. 새 사이트 뱁 추가 입력란에 sitemap.xml feeds/posts/default?alt=rss 이 두개를 입력해 제출한다. 정상적으로 성공했다면. 상태에 성공이 표시된다.

[dev] 터미널 사용 입문 개발자를 위한 터미널 입문 개발을 하다보면 원치않아도 터미널을 사용해야하는 경우를 마주하게 된다. Git이나 PackageManager를 다룰 때에도 터미널이 필요하다. 터미널을 쓰는 것에 두려움을 느끼지 말고 익혀두자. 터미널을 잘 다루는 것은 개발효율성을 높이는 방법중에 하나이다. 터미널에서 할 수 있는 것 터미널은 텍스트 기반이며 명령어를 입력할 수 있는 CLI(command-line interface)역할을 한다. 깃(GUI)버젼을 사용해본 사용자라면 왜 터미널을 사용해야 하는가에 의문을 가질 수 있다. GUI는 명령어를 버튼과 같은 시각적인 도구로 입력하는 방법이다. 그렇기 때문 모든 명령어를 구현하지 않는다. 터미널을 사용해 명령어를 입력할 수 있다면, 원하는 결과를 이끌어 내기 위한 입력을 할 수 있다. 터미널 실행하기 Mac OS는 Spotlight ( ⌘ + Space )를 불러 “Terminal”을 찾아 실행할 수 있다. Linux는 “terminal” 을 찾아 실행하면 된다. 단축기 Ctrl + Alt + T 를 이용해 실행할 수 있다. Windows 10은, PowerShell 이라는 터미널을 실행한다. 기본 명령어 터미널의 기본 명령어는 다음과 같다. ls # 파일 list 나열 cat # 파일의 내용을 보여주기 cd # 디렉토리 변경 mv # 파일, 디렉토리 이동과 이름변경 cp # 파일, 디렉토리 복사 mkdir # 디렉토리 생성 rm # 파일, 디렉토리 제거 pwd # 현재 디렉토리 경로 위 명령어들의 사용 방법은 다양하다. 사용방법 중 인자들을 입력해야 하기도 하다. cp 명령어를 입력해보자. LT1066ui-MacBook-Pro:test hyunho.lee$ cp usage: cp [-R [-H | -L | -P]] [-fi | -n] [-apvXc]

오픈소스 라이선스 정리 오픈소스 라이선스 정리 소프트웨어를 개발하다 보면, 오픈소스는 자연스럽게 접하게 된다. 처음에는 마냥 무료인 줄 알고 가져다 쓰던 오픈소스애도 여러종류가 있고 지켜야 하는 부분에 대해 법적인 책임을 지지 않기 위해 남겨둔다. 오픈소스 라이선스 고려사항 오픈소스 라이선스 비교 표를 보면서 어떠한 해당사항과 주의해야 하는 사항이 있는지 참고한다. 참고 : 오픈소스 라이선스 비교 표 복제, 배포, 수정의 권한허용 해당 소스코드를 복제하고 배포하고 수정할 수 있다. 배포시 라이선스 사본첨부 라이선스의 소스코드를 배포한다면 라이선스 사본을 배포하여 해야 한다. 저작권 고지사항 또는 Attribution 고지사항 유지 코드의 상단에 삽입되어 있는 원작자의 저작권 고지사항을 지우면 안된다. 다만, 네트워크를 이용한 서비스의 경우 배포로 보지 않기 때문에 의무사항 자체가 발생하지 않는다. 배포시 소스코드 제공의무와 범위 해당라이선스의 소스를 사용하여 개발할 경우, 개발 된 소스코드를 사용자에게 제공해야 하는지에 대한 의무와 범위이다. Work Based on the Code 제공의무: 원 저작물의 소스코드를 원본 그대로, 혹은 수정하여 새로운 SW에 포함하였을 경우 제공범위: 원 저작물의 소스코드가 포함되어, 파생 저작물로 인정되는 범위내의 모든 소스코드 GNU GPL, GNU AGPL 등 Derivative Work 제공의무: 원 저작물의 소스코드를 수정하여 사용한 경우 제공의무가 존재하며, 수정 없이 그대로 사용하였을 경우에는 소스코드를 제공하지 않아도 됨 제공범위: 원 저작물을 사용함에 있어 수정을 거쳤다면, 원 저작물의 소스코드에서부터 존재하던 파일을 모두 공개해야 하며, 파생 저작물의 저작자가 추가적으로 생성한 부분에 대해서는 공개하지 않아도 됨 GNU LGPL, NASA Open Source Agreement, Simple Public License 등