JIGGAG

4월 한달동안 로그

2021년 5월 1일

4/26 ~ 4/30

벌써 5월?

  • 스터디만 하다가 한달이 가버렸다
  • 4월을 시작하면서 목표한 태스크를 달성하지 못했다
  • 자연스럽게 5월로 넘어가면 되긴하는데
  • podfile 버전 충돌 때문에 의지를 잃었나!
  • 하고 싶은건 많다고!
  • 실행만 하면 된다

네이티브

  • 안드로이드 네이티브 컴포넌트 사이즈를 변경하려고 했는데
  • 다 깊은 뜻이 있었던 사이즈
  • 네이티브 컴포넌트? 뭐였더라
  • OS마다 다르게 적용되는 UI
  • 그냥 RN으로 그린 화면만 작업하다가 OS마다 다르게 적용되는 네이티브 레이아웃을 보니 아예 다르구나
  • 복잡해도 하면 안되는건가!
  • 너무 두둥 다른대...
  • 하고 싶으면 배워서 알아가서 슬쩍 적용해보는 소박하고 거창한 꿈
  • 프레임워크를 알아야하겠다

안드로이드 앱 빌드

  • 빌드 시간 절약을 위해 좋은 사양 + 빌드 캐시 + gradle android build cache plugin
  • gradle cache server로 로컬 캐시뿐이 아니라 동료가 빌드한 캐시를 remote로 이용할 수 있다
  • 빌드 환경 최적화 (다양한 환경에서...)
  • 라인개발실록: 안드로이드 앱 빌드

4/19 ~ 4/26

안드로이드 앱 관리

  • 앱 번들 사이즈를 모니터링해서 어떤 코드를 적용하면서 변화가 있었는지...
  • 개인적으로는 APK 사이즈를 매번 확인하기는 했지만 따로 모니터링 시스템 없이 플레이스토어에 올라간 그래프를 보기만 했다
  • 그렇게 되면 이미 커져버린 사이즈가 배포가 되버린 이후
  • 안드로이드 번들 사이즈 감소
  • DFM 이후 Dynamic Delevary을 해야하는데 네트워크가 느린 곳에서 단점
  • onDemand로 다운로드하는동안 기다려야하는데 네트워크가 느리면 노답...
  • RN 개발하면서 최근에 CodePush를 도입했는데 패치버전이 있는 경우 무조건 다운받아야만 앱이 실행되도록?
  • 스플래시 화면에서 다운받아서 새로운 버전으로 실행되게끔 작성해두었었다
  • 근데 이런 네트워크 온디맨드 이야기를 보니 코드푸시 다운로드 조차도 강제로 받게 해둔 경우 스플래시 화면에서 로~~오~딩 하는 모습이 있을듯하다
  • 그렇다면 코드푸시의 기본? 모습인 패치가 있으면 다운받고 다음 실행부터 적용되도록 해야할까..?
  • 그렇지만 지금 당장 필요한 패치버전이니깐 코드푸시한건대...
  • 스플래시에 로딩중임을 잘 알려주면 괜찮을까?
  • 라인개발실록: 안드로이드 앱 관리

RN lint

  • 매번 프로젝트마다 lint, prettier 룰 설정하면 하루가 다 지난다
  • 쓰던 룰 매번 복사해 넣는것도 귀찮기도 하고 나도 하나 갖고 있으면 좋을것 같아서
  • 만들어보기
  • 참고: eslint 설정 공유하기
  • 처음에는 jiggag/lint로 만들었더니 이상하게 eslist.config.js에서 해당 config를 찾지 못했다
  • 결국 블로그 참고해서 eslint-config-*형태로 만들어주니깐 되는데... 왜못찾는거지

리뷰

  • 원했던것 많은 리뷰
  • 그러나 스스로 반성을 @.@
  • 조급하게 생각하지 말고

공변성, 반공변성

  • 처음 마주한 것은 typescript를 보던 중 이였다
  • 함수를 props로 전달하는 방법에는 property와 shorthand 방법이 있다
  • 참고: 공변성이란?
  • 당시에 공변성과 반공변성이라는 단어를 처음 보았을때 도저히 이해할 수 없었고 메서드를 전달하는 방법에 차이가 있음을 인지하는 것에 중점을 두었다
  • 그리고 꼭 다시 돌아온다고 코틀린 스터디 과정에 돌아왔다
  • 이번에는 제네릭 타입 내용에 나타났는데 다시 찾고 찾고 알아보던 중 알듯 말듯 알듯 하는 지금 얼릉 정리해본다
  • 스터디를 준비하는 과정에서 이해하고자 했던 방법으로 공변성은 읽기전용이고 반공변성은 쓰기전용이라고 생각했다
  • 공변성이 특정 타입 T가 들어오리라 예상된 곳에 T의 확장 타입인 자식 객체가 들어오는 것을 허용하는 것이다
  • 읽기전용이기에 원래 기대했던 T보다 더 확장된 개념의 R (= extend T)가 들어와도 이미 존재하는 메서드를 호출만 해주면 되는 것이기에 정상적으로 동작한다
  • 반대로 반공변성은 특정 타입 T가 들어오리라 예상되는 곳에 T의 상위 타입인 부모 객체가 들어오는 것을 허용하는 것이다
  • 쓰기를 하는데 하위 개념의 타입이 이미 들어가 있다면 하위 개념이 하위개념을 갖고 있는 괴이한 상황이 발생할 수 있다... (과일이라는 상위 개념에 쓰려고 했는데 사과가 이미 들어가있었고 포도를 쓰기를 했더니 사과와 포도가 충돌나는 상황)
  • 이건 나의 의식의 흐름대로 짜맞춰가는 개념의 흐름...
  • 다음에 다시 만나면 조금 더 알아갈 수 있겠지?

4/12 ~ 4/18

css in js

hermes

  • RN 0.64에 추가된 iOS도 hermes!
  • 나오자마자 바로 적용해보긴 했는데 체감이 그렇게 오지 않았었다
  • 그렇게 잊고 있던 중
  • callstack에 아티클이 올라왔다
  • 그렇게 시작된 JIT, AOT, JavasSriptCore
  • 다음에 올라올 글도 기다리는 중
  • 체감이 맞았네!

swift

  • 그래 너는 문제가 아니지 내가 문제야

CocoaPods CDN

  • 갑자기 CDN 다운로드 실패했다고 오류를 뱉어낸다
  • CDN: trunk Repo update failed
  • CDN: trunk URL couldn't be downloaded: https://cdn.jsdelivr.net/cocoa/~~~
  • 검색하면 잘 나와있어서 그렇게 시도한 방법
  • Podfile에 source 'https://github.com/CocoaPods/Specs.git'로 코코아팟 받아오기
  • 근데 아무런 반응이 없길래 이것도 안되는건가? 하고 있었더니
  • 그냥 너무 커서 느려서 오래 걸려서 반응이 없었던 것
  • pod repo remove trunk 으로 기존에 다운받아둔 pod trunk를 싹 다 지워버리고 git repo에서 직접 전부 받아온 것을 사용한다
  • 덕분에 CDN에서 다운 받아오지 못하는 이슈는 해결됬지만 너무 느림
  • CDN으로 필요한 코코아팟만 캐시된거 딱 받아오면 되는데 이걸 못하니깐 전부 직접 받아와서 해당 파일 찾아서 그걸 다시 쓰려니 너무 느리다
  • 다 하고 났더니 이젠 CDN 오류가 안나길래 Podfile에 코코아팟 다 받아오기 코드는 다시 지웠다
  • CocoaPods CDN

RN Bridge

  • RN과 Native가 서로 오갈 수 있는 연결고리
  • kotlin, swift 각각 브릿지 작업을 필요로한다
  • @ReactMethod를 호출뿐만이 아니라 브릿지 이벤트 리스너를 만들고 이벤트를 보내야한다
  • 기존 코드들을 참고하여 이것저것 붙이다 보니 RN에서 받지도 않고 있는 이벤트를 굳이 보내고 있기도 하였다
  • 재밋는데?

Podfile

  • 현재 사용하고 있는 라이브러리 두개의 Podfile platform 버전이 11.0과 9.0으로 다르다
  • 문제는 11.0이 최소 버전으로 요구하고 있어서 11.0으로 빌드를 하게 되면 9.0 라이브러리를 설치하지 못해 오류가 발생한다...
  • Podfile에 서로 다른 두 버전을 명시할 수 있을까?

4/5 ~ 4/11

프로젝트 다시 쌓기

  • 이런저런 버전 충돌에 피곤해서 새로 다시 만들었다
  • 다시 옮겨 가는게 더 빠르겠다!
  • 그리고 여러가지 써보겠다는 생각으로 에러 트래킹 툴을 업무에서 써보지 않은 sentry를 붙여놨는데
  • 이것도 그냥 bugsnag로 옮겨가는중
  • 근데 그냥 느낌은 sentry가 더 아름답게는 보이는데
  • 복습하는 차원으로 써보고 싶은 것들이 있어서 통합해야지 하며 위안

여전히 같은 오류

  • nvm install node로 해결했다고 생각했는데...
  • 이번엔 다른 프로젝트에서 같은 오류가 나타나기 시작했다
  • ㅏㅏㅏㅏㅏ
  • 왜 도대체... 이 경로가 문제인걸까
  • 그래서 나도 이렇게 해두고 있다: 깃헙 이슈
  • 결국엔 patch-package
  • 예전에도 무언가 라이브러리 버전이 안맞아서 일부 코드만 patch-package로 수정해서 사용하는 것을 지켜만 보았었다
  • 이렇게 하게 될 줄이야
  • 무언가 복잡하게 보였지만 그런건 아니였고 패치를 계속 해준다

4/1 ~ 4/4

brew nvm node

  • RN 0.64 업데이트한 프로젝트가 커맨드에서 빌드가 되지 않았다
  • 일주일 넘게 해결하지 못했는데 드디어 해결되었다!!!
  • 처음에는 RN 업데이트를 잘못한건가 싶어서 리셋하고 다시 시도했지만 여전히 빌드를 실패했다
  • 혹시나 싶어서 xcode로 빌드했더니 성공하기에 헐?
  • 오류를 하나하나 따라 읽다보니 보이는 
    nvm is not compatible with the "PREFIX" environment variable: currently set to "/usr/local"
Run `unset PREFIX` to unset it.
  • RN 0.64 업데이트 후 비슷한 내용의 이슈가 깃헙에 있었지만...
  • 결국 해결할 수 있었던 단어는 brew 재설치
  • 다른 맥북에서는 정상 빌드된 것이 큰 힌트였다
  • 무언가 설정에 차이가 있고 그게 brew nvm node였다니
  • 그런데 ??? 자고 일어났더니 읽게된 brew로 node를 설치하지 않기를 권한다
  • 내가 시도한 것은 brew를 다시 설치하고 nvm과 node를 brew로 설치하는 것이다
  • 그러나 위 글에서 참고한 이 글의 내용을 보니 brew로 설치하게 되면 OS에 종속?된듯 node 버전이 관리가 꼬일 수 있다
  • nvm이 node의 여러 버전을 설치하고 필요에 따라 버전을 바꿔서 대응을 해주는데 이를 brew로 설치하게되면 나와 같은 불상사가 발생
  • 그래서 다시 brew uninstall node하고 nvm을 설치 후 nvm install node!!
©Jiggag, Built with Gatsby