1/24 ~ 1/31

iOS 사진 접근

• 특정 경로에 있는 사진 파일들을 접근하여 앱 내에 리스트화 해주는 것을 안드로이드로만 개발해두었다
• 왜냐하면 iOS 개발자 계정이 없어서 릴리즈하지 않았기 때문에!
• 그러나 어제 개발자 계정을 구입하였다
• 그러니 그동안 미뤄둔 앱들을 등록하려고 했더니 미뤄둔 작업 + 수정이 필요한 것들이 눈덩이가 눈사람이 되었다
• 그 중 아직 해본적 없었던 + 안드로이드 조차도 커스텀해서 사용한 사진 라이브러리를 먼저 작업하려고 한다
• PHImageRequestOptions, PHFetchOptions 설정을 만지다보니 내가 접근하고자 하는 스크린샷의 사진 파일을 가져오는데 성공했다
• 예상과는 다르게 이미지 파일을 어떻게 가져와서 반환해주어야 하는지 아직 찾지 못했다...
• 경험이 이렇게 중요하구나 생각이 드는 시점이다
• 그동안 안드로이드만 사용하고 사이드 프로젝트도 안드로이드로만 치우쳐있다보니 iOS는 모르겠다 ㅠㅠ

iOS

• 개발자 계정 등록했다
• 그리고 테스트폰으로 아이폰6를 거래하고 돌아오는 길
• 케이블을 샀는데 2.2m인줄 알았는데 22cm였다
• 도저히 22cm로는 사용하기 불편할 것 같아서 라즈베리파이 연결해두던 케이블이랑 교체 작업
• 라즈베리 웹이랑 노드 서버 다시 띄워야하네...

리디셀렉트

• 한달 무료 구독을 시작했다
• 아티클이 관심이 가는데
• 가장 개인적인게 창의적이다
• 예술은 모방에서 시작한다
• 누구에게 어떤 목적으로 어떤 형식으로 말할까

RN 라이브러리

• 네이티브 모듈을 만들고 싶었고 그동안 기존에 작은 라이브러리 형태를 보고 따라만들었었는데 cli가 있었다!
• create-react-native-module
• Framework가 모듈을 설치하면 같이 포함되면 좋겠는데... 했더니 podspec에 추가하니 되는구나

SWR

• 계속 신기하고 새로운걸 시도하는 건 참 어렵고 재미난 일이다
• 그동안 API response를 redux에 가공해서 담아두고 사용했는데 SWR로 캐싱된 데이터를 바로 가져온다
• 이번에 redux랑 saga 둘 다 사용하지 않고 graphql + swr만을 사용해보는 토이플젝을 진행 중
• 이걸 다시 redux로 바꿔버려하는 굴뚝 같은 마음 부여잡고 문서, 블로그, 이것 저것 찾아가며 진행...
• 기능이 아주 단순한 것 같았으나 기본이 가장 중요하고 어려운 것임을 깨닫는 CRUD
• 전체 사용자가 올린 에피소드 리스트 호출하고 저장한 에피소드, 내가 올린 에피소드를 보여주기만 하면 되는데 하다보니 이거 페이징은?????
• 겪어보는데 의의를 두자는 마음 붙잡고 페이징은 없는 상태로 v1은 완료했는데 느리다
• 처음 리스트 가져와서 렌더링까지 너무 느리다!
• 왜...?
• 느릴 이유가 없지 않나?
• 라즈베리 서버가 느린걸까

C의 유전자

• 우연히 이 책을 읽고 계신 분을 보게 되었고 주제가 흥미로워 읽게 되었다

1/17 ~ 1/23

Code Push

• 수정, 빌드 그리고 심사 그리고 다시 수정
• 문구나 링크 변경 또는 버그 수정처럼 사소하거나 긴급한 작업이 이뤄져야하는 경우
• 앱 심사, 검토, 출시까지 너무 길게 느껴질만큼 업데이트가 필요한 경우가 있다
• RN 번들파일을 교체하여 앱 심사를 거치지 않고 업데이트가 가능한 Code Push를 적용하고자 한다
• JS 번들파일을 appcenter에 올려두고 이 파일을 바라보도록 앱 빌드
• 빌드된 앱에서 바라보고 있는 번들파일을 교체해주는 작업으로 앱 심사 없이 수정 작업이 가능해진다
• 단, JS 번들에 속하지 않는 코드 변경은 앱 빌드가 되어야함
• 개발, 운영 테스트 빌드해보고 반영되는 것을 확인해보니 정말 유용할 것 같다
• 걱정되는 점으로 관리포인트가 오히려 늘어나는 것 같아 운영 구조를 잘 잡아야할 것 같다

렌더링이 문제라고 생각했는데

• 메인화면에서 바라보고 있는 상태가 엄청 많다
• 많고 많고 많아서 정리해야겠다고 생각하는데
• 메인화면에서 터치가 잘 되지 않는 현상이 발생하였고
• 이것 때문에 렌더링이 너무 많이 발생하는건 아닐까 하고 생각했다
• 근데 렌더링은 필요한 만큼 딱 잘되고 있는것으로 확인되는데... 왜 터치가 안되는걸까?
• 혹시 TouchableOpacity에 오류가?????
• ㅋㅋㅋ 그럴리없다 다른 곳에서는 정상 동작하고 있다
• 그렇다면 이유가 무엇일까
• 하는 와중에 동일 화면 다른 컴포넌트에서도 터치가 잘 되지 않는 현상이 나타났다
• 대체 이유가 뭐지 하면서 이곳저곳 모서리, 가운데, 텍스트 모든 곳을 눌러보았고
• 우연하게 찾을 수 있었던 원인...
• 위에 있는 컴포넌트의 padding과 아래 컴포넌트의 margin...
• StickyComponent 내부 컴포넌트로 postion absolute로 설정되어있다
• 이에 헤더 컴포넌트 padding에 가려지고 아래에 위치한 컴포넌트가 덮는 현상이 발생
• 터치 영역이 아주 소소하게 자리잡게 되었다
• 기존에 발생했던 터치가 잘 되지 않는 이유도 이런 비슷한 이유...
• 터치가 하다보면 가능하다는 이유만으로 단순하게 렌더링이 너무 많이 되서 한참 후에 동작하나?라고 생각했었다
• 섣부른 잘못된 판단을 바로 잡아 다행이네

Redux + Context

• 지난번 Redux와 Context에 대해 생각을 하게된 계기가 되었던 글이 있었다
• 그리고 그 스레드에서 여러 의견들이 오고 갔고 블로그 링크가 공유되었다
• Context는 상태 관리를 위한 것이 아니다
• 그리고 그것에 대한 블로그

react-native-config

• iOS 스키마 Build 시 pre-action을 설정했다
• 그런데 .env는 읽는데 .env.production은 읽지 못한다
• 분명 릴리즈 빌드가 되고는 있으나 Config 설정으로 명시된 값들이 여전히 .env파일의 값이다

1/10 ~ 1/16

SWR + GraphQL

• query는 가져왔다
• mutation은 어떻게 하지?
• 특정 이벤트 발생 시 mutation해주려고하는데 SWR 자체가 훅이라서 훅스 안에서 사용이 안된다
• 결국 mutation을 위한 액션을 따로 만들어서 사용하였다
• 하나의 문제를 해결하고 나면 다음 문제가 기다리고 있다
• 그리고 나서 만나게된 다음 문제
• 기존에는 mutation 하면 리덕스에서 관리하고 있던 상태를 변경해주었다
• SWR은 어떻게 해야하는걸까?
• 단순하게 refresh option을 줘서 새로운 API 호출을 해야하는 것일까
• 그럼 결국 네트워크 통신을 계속 해야하는 것인데
• 불필요한 네트워크 비용을 줄이기 위해서 필요한 시점에 데이터를 불러오는 것
• Redux를 사용하지 않는 조건의 프로젝트 도전이 난관에 도착하였다
• mutate ?!!?! 이건 뭐지
• mutation 하고 나서 변경 요청 된 데이터만 업데이트
• mutate 참고 블로그

oh my zsh

• 왜 갑자기 꽂혀서...
• 그동안 기본 터미널 잘 사용하다가 문득 그냥!
• 참고: Oh My ZSH+ iTerm2로 터미널을 더 강력하게
• 근데 왜 ssh 연결이 안되는걸까 ssh: connect to host port 22: Connection refused???
• 기본 터미널에서 사용하던 단축어로 접근이 되지 않아 기억을 더듬어 주소까지 찾아서 했는데도 접속이 되지 않는다....
• 다시 원복해야하나 생각이 드는데.. 라즈베리에 젠킨스 띄워놔서 다행이다 이유를 좀 더 찾아봐야지

이벤트 버블링

• e.target, e.currentTarget 차이
• 이벤트 버블링: 특정 노드에서 이벤트가 발생하면 상위 노드에도 해당 이벤트가 발생
• 이벤트 리스너에 전달된 event.target과 event.currentTarget의 차이는 이벤트 버블링에 의해 나타난다
• event.target: 실제 이벤트 핸들러가 발생한 노드
• event.currentTarget: 이벤트 리스너가 가져온 현재 노드

Facebook SDK

• 광고로 앱 설치 유도
• 페이스북 앱 설치 광고란 무엇일까
• 이 광고 자체에 트래킹되는 것이 따로 있을까
• 어떻게 이 앱 광고를 누른 사람이 이벤트를 호출했다라는 퍼널이 어떻게 연결 되는 걸까
• iOS 14 추적 제한

코어 자바스크립트

• 작년에 읽었던 책 중 읽고 또 읽어도 항상 도움이 되는 책
• 처음 볼 때 > 다시 보고 > 다시 보며 몰랐던 것도 이해할 수 있게 되고 알고 있던 내용도 다시 깊게 생각할 수 있도록
• 아는 줄 알았지만 다시 읽다보면 모르고 있음을 깨닫는다
• 실행컨텍스트: 실행되는 그 순간의 환경 정보
• 스코프: 어디서 선언되었는지 영역을 구분
• this: 어디서 호출하였는지
• 비슷하지만 전혀 다른 그리고 시작되는 클로저

1/3 ~ 1/9

redux? context?

• 우연히 들어와 읽게된 redux와 context
• context는 상태 관리를 위한 것이 아니다
• context는 공유를 위한 것이다
• redux 대신 context를 사용하는 곳이 있어서 관심있게 읽게 되었다
• 여기서 사용하고 있는 context가 무엇을 위한 것인가요?라는 질문에 대한 대답을 생각본적이 없었다
• 누군가 물어봤다면 그것은 context를 통해 가져오고 있고 그것이 redux와 비슷하다고 대답했을것이다
• 전역으로 관리해야하는 상태는 아니지만 상위 컴포넌트에서 하위 컴포넌트로 전달을 위해 props -> props -> props 대신 아름답게 도와주는 무언가라고 생각했다
• 그리고 이 글들을 읽으며 생각하게 된 것은
• root의 state를 context를 통해 하위 컴포넌트에 전달하고 있는 것이다
• 상태 관리는 상태를 저장하고 가져오고 변경해야하는데 context는 그렇지 않다
• 상태는 root에 존재하고 context는 관리가 아닌 전달을 하고 있다

이벤트루프

• 찾아볼수록 어려워지고 혼돈만 깊어진다

클래스 컴포넌트

• hooks를 사용한 이후로 클래스 컴포넌트를 사용하지 않게 된지 오래
• 클래스 컴포넌트로 작성하라는 제약조건이 걸린 상태에서 개발은 생각보다 어려웠다
• 그동안 사용하던 라이브러리나 구조가 전부 함수형, 훅스 기반이라 그럴까
• 혹은 본질에 대해 잊고 있었나
• 프로젝트를 진행하고는 있지만 반성하고 돌아보게 되는 클래스 컴포넌트로 개발하기

나는 모른다

• 누군가에게 설명해주지 못한다는 것은 내가 그것을 모르고 있다는 것이다
• 알고 있다고 생각했지만 막상 설명하려고 하면 정리되지 않은 횡설수설
• 다른 사람에게 알려주기 위해 자료를 준비하는 기분으로 정리해보는 것이 필요하다
• 두리뭉실 알고 있다고 생각하는 것은 설명하다가 막히고 질문에 막히고

git main branch

• 기본 브랜치 변경을 위해 git 버전업
• git 기본 브랜치 변경

12/27 ~ 1/2

마지막 불꼿 사이드

• express + graphql + swr
• 전역 상태 관리에 대한 단상을 읽고 바로 뛰어들었다
• 생각했던 방향으로 초기 구조를 잡았는데 다른 구조는 어떻게 잡을 수 있을까
• Redux 사용 안하기 너무나 황당한 제약조건을 스스로에게 걸었다