Notion TASK to Git💡현재 git issue state는 issue open → notion table 동기화로 되어있음 여기에 추가적으로, 스프린트(개발 그룹)이 시작된 task에 한하여 issue를 자동으로 만들어주는 스크립트를 작성하고자 함 스택jsnotion clientgithub rest apioctokit 요구사항상태가 진행 중인 task를 가져갈 것플랫폼이 android 인 task를 가져갈 것task에서 뽑아낼 내용은 task id + task title → issue title같은 id를 가진 issue 는 skip. 만들지 않을 것문서, 회의 등을 제외시킬것이슈 대응 및 신규 개발로 구분된 task만 등록할것 개발내용초기 세팅루트의 .env 파일에 아래 속성 추가NOTION..

Ktlint란?코틀린 표준 코드 스타일을 따르는 린터 Detekt란?code smell, 잠재적 성능 저하와 버그를 잡아주는 코드 정적 분석 도구 editorConfig 파일 수정 → 코드 스타일 작성시에 강제하도록 git-hooks 파일 완성 action yml 파일 완성(브라우저) master에서 develop따오기 develop에 이번 branch 합치기 .git/hooks/precommit 으로 추가 (*확장자 없어야됨)#!/bin/bash # Stash the current index to be used in the event of failure git stash -q --keep-index echo "Running Ktlint before git commit is committed" ./gra..

Commit Message 사전동명사보다 명사를 사용합니다.동사를 명사화시키기 보다는 그 의미를 잘 표현하는 명사를 찾아서 사용합니다. 이렇게하면 문장이 장황하지 않고 간결해집니다. 아무래도 영어에 약한 사람들에게 가장 어려운 미션 중 하나가 아닐까 생각됩니다.관사는 사용하지 않습니다.꼭 필요한 경우가 아니면 a, an, the는 사용하지 않습니다.부정문 Don't를 사용합니다.커밋 메시지를 명령문 형태로 써야 한다는 것은 모두들 알고 있지만, 부정 명령문을 사용하는 것은 잘 모릅니다. ‘A를 사용해’라고 명령했으니 반대를 이야기 할 때는 ‘A를 사용하지마’로 표현해야 합니다. Not use가 아니라 Don’t use 입니다.Don't use spdy on node >= v10.0.0 Don't writ..

https://medium.com/prnd/mvvm의-viewmodel에서-이벤트를-처리하는-방법-6가지-31bb183a88ce 뷰모델의 문제점 뷰모델은 뷰가 변경되면 가장 최근 값들로 .observe를 해주는데 , 중요한건 이게 값이 바뀌지 않아도 최근 값을 걍 들고오기때문에….. 토스트를 띄운 후 나갔다가 다시 fragment 갱신 → 토스트 재생성과 같은 중복 이슈가 발생하게 된다. 해결 방안 사실 이 문제는 아주 흔한 것이라서 구글에서 이미 해결책을 내놨다. 나는 SharedFlow + Sealed class + Lifecycle 를 사용했다. SharedFlow private val _eventflow = MutableSharedFlow() val eventflow: MutableSharedFl..

원인 firebase crashlytics에서 qa 버전, release 버전이 혼용되어 사용중임… 보기 불편.. qa만 따로 모아서 보고싶음 해결 방안 firebase 콘솔에서 앱 추가해줌 패키지명 설정 (나중에 빌드시에 이걸로 되는거 감안해서 크게 다르지 않은걸로 설정) service-json받음 -> 나는 원래 파일이 .app내에 있어서 거기 위치시켜줌 .env 업데이트 (패키지명 변경으로 앱 아이디도 변경됨) RELEASE_APP_ID = "릴리즈앱의 아이디(in fb project)" QA_APP_ID = "QA앱의 아이디(in fb project)" FIREBASE_TOKEN = "FB토큰" GOOGLE_DRIVE_FOLDER_ID = "업로드할 구글 드라이브 폴더의 id" SIGNING_KE..

Delegate Pattern 어떤 객체가 기능을 수행할 때, 해당 기능을 다른 객체에게 위임하는 패턴 상속과의 차이 객체 안에 새로운 기능 / 객체를 구성하는 composition을 사용 프로세스 1과 2는 dependency 관계 , 2와 3은 implement관계. 2에는 1이 필요한 부분을 정의함. 3은 2를 구현함 kotlin에서 by를 사용하면 쉽게 가능 // 부동산과 관련된 권한들 interface Authority { fun stampSeal() // 도장 찍기 ... // 기타 등등 } // 부동산에 대해서 내가 행사할 수 있는 권리가 있어! class Customer(private val name: String) : Authority { // Authority 인터페이스 구현 overr..