1월 한달동안
- 벌써 1월이 지나가고 한달동안 루틴을 지키려 노력했다
- 아쉬운점
- 건강관리를 제대로 하지 않은 것이 가장 아쉬운 부분이다
- 하루 24시간 중 8시간을 누워있다고 한다면 남은 16시간을 의자에 앉아있었다
- 최근 허리가 안좋아지는 것을 느끼고 있는데, 이게 가장 큰 원인으로 생각된다
- 작년 연말 당근전략으로 의자에서 일어나 운동하러 다녀오는 것을 시작했는데, 이번달 중반(이라쓰지만 초반 같다) 미세먼지라는 핑계로 잠시 끊어진 루틴이 문제였다
- 잘한점
- 아쉬운점에서 언급한 건강관리(실외)는 지키지 못했지만, 반대로 실내에서 할 수 있는 루틴은 지키고 있다는 점이다
- 루틴은 실패했지만 루틴은 성공했다
- 하루를 구성하는 커다란 루틴을 한달동안 유지하는 것에 성공했다
- 이걸 한달 더 유지하는 것이 다음 목표이다
- 개선할점
- 아쉬운점이 발생했던 원인을 개선해보고자 한다
- 핑계를 시작으로 마음가짐을 합리화 해버렸기 때문에 다시 돌아오는데 오래 걸렸다고 생각한다
- 한번 놓아버렸을때 다시 잡는 회복력을 높이는 것인데, 합리화를 안하는게 좋으려나 생각해본다
퍼포먼스를 끌어올려라
- Performance Regression Testing for React Native
When a component re-renders, a serialized message is sent through the bridge from the JavaScript thread to the native platform. The native platform unserializes the message and creates a new native view, which is then rendered on the screen. If the render result is the same as the previous result, it may not result in native view changes; however, the time it takes to re-render a portion of the element tree might block the JS thread.
But more importantly, performance problems that fail to be recognized by any test or QA process can occur.
- 콜스택의 reassure 소개글 같지만 도움이 될 것 같으니 측정해본다
- 퍼포먼스 개선을 Flipper DevTools만으로는 한계가 있으니 CI의 도움을 받아보겠다는 마음으로
RN 0.71
- 결국 적정선에서 타협을...
- 안드는 hermes를 껐다
- react-native-safe-context에서 발생하는 오류는 임시 대응을 해두었는데
- 언젠가... 해결되기를 기도한다
- iOS도 hermes만 키면 hermes framework 스크립트에서 오류가 발생하는데
- 이건
PLATFORM_NAME
이 잘못된건지 찾을 수 없는지 모르겠다/Users/jiggag/Projects/react-native-starter/ios/Pods/hermes-engine/destroot/Library/Frameworks/iphonesimulator/hermes.framework does not exist.
- 🙈
- 이건
- 결국 모두 fabric은 활성화 시켰지만 hermes를 비활성화 했다
- 이게 어떤 효과가 있을까나....
- 이정도면 hermes랑 안맞는건가
- React Native 0.71
- hermes 퍼포먼스가 향상되었다는데...
- 위에서 hermes를 전부 비활성화 했으니 갑자기 섬뜩... 이럴 수 없다
- hermes는 기본인데 말이죠...
- hermes 퍼포먼스가 향상되었다는데...
- 디버그 툴 하이라이트 대박!
- 갑자기 하나하나 뎁스 내려가면서 찾았던 것이 떠올라... 🥺
- 특히 LogBox 관련된 변경사항도 눈에 들어왔는데
- 변경사항 관련된 PR 코멘트
- 시뮬에 뜨는 로그 != 커맨드에 남는 로그
- 로그는 무시하는 대상이 아니라 수정해야하는 대상으로 인식을 가져가야한다
- 추가로 metro도 버전이 업데이트 되었다 (v0.74.0)
- RN이 점점 더 빨라질거라는 기대감
- (추가)
- react-native-safe-area-context 이슈를 구독하다가 수정되었다는 소식을 듣고 바로 반영해보았다
- 겸사겸사 hermes도 활성화 시켰다
- react-native-screens에서 잠시 빌드가 터졌지만 이것도 0.71 이슈 후속 대응한 버전으로 올렸다
- 빌드가 끝이 아님을... 왜 죽는거죠
-
java.lang.UnsatisfiedLinkError: couldn't find DSO to load: libhermes.so SoSource 0: com.facebook.soloader.ApkSoSource[root = ...
- 무언가 잘못됨을 느끼고 RN 템플릿을 직접 kotlin 변환해서 돌려보니 잘된다 === 이건 나의 프로젝트가 문제임이 확실하다
- 차이점이라곤 gradle-wrapper.properties 의 버전뿐
- 그렇지만 이게 원인이 아니였다
- 하나하나 뜯어가보니... 의외의 지점에서 문제가 있었다
- hermes 조건을
===
로 비교하고 있었다 - 이건 kotlin인데...... 🙈🙈🙈
- 빌드는 되지만 앱 실행만 하면 크래시 발생하는 이유가 딱 들어맞았다
- hermes로 쓰겠다고 하면서 jsc로 읽으려하니 뭐가 될리 없다...
- iOS에서 hermes 빌드하면 에러발생하는 것은 여전하다
gRPC
- 몇년전 우연히
gRPC를 써봤다
는 말을 들어봤는데 찾아보지는 않았던 것이 기억났다 - 그리고 우연히 [번역] Node.js에서 gRPC 사용하기 아티클이 공유 되었고 보게 되었다
Google의 Remote Procedure Call
라는 것에서 느낌이 왔다 🤔
- 그리고 REST와 비교되는 내용들을 보고나니 GraphQL을 떠올리게 했다
- JSON 대신 프로토콜 버퍼 형태로 통신하며 서버는 클라이언트와 함수를 공유한다
- 여기서 프로토콜 버퍼를 어떻게 사용하는건지 예제를 보니
정말 독자적인 형태
를 갖고 있다는 느낌을 받았다-
enum LoginCode { SUCCESS = 0; FAIL = 1; }; message LoginResult { LoginCode loginCode = 1; optional string token = 2; } message LoginRequest { string username = 1; string password = 2; }
- 마치 enum에 고유 번호를 모두 지정해둔 느낌인데
- 이 고유번호를 서버와 클라이언트가 통신하는 식별자로 사용하기 때문에 한번 사용되고 나면 변경할 수 없다는 것이 놀라웠다
- 클라이언트가 서버의 함수를 알고 있고 직접 호출해야하기 때문에 이 식별자가 중요한 역할인 것 같다
- 하지만... 절대 바꿀 수 없다니...
-
- 참고: [네이버클라우드 기술&경험] 시대의 흐름, gRPC 깊게 파고들기 #1
- 구글이 개발한
구조화된 데이터를 직렬화하는 기법
으로 기존에JSON 형태로 주고 받는 것에 비해 적은 바이트로 변환
할 수 있었다 - 최소화를 위해 직렬화된 데이터를 식별하는데 위에서 독자적으로 구조화한 고유번호를 사용할 수 밖에 없는 느낌
- 구글이 개발한
- 클라이언트가 서버의 것을 알고 있고 직접 사용한다는 것이 GraphQL과 많이 유사하다고 느껴지는 부분이다
- REST API를 대체하기 위해 빠르고 작은 포맷이 GraphQL처럼 클라이언트에서 적절히 사용하는 것 또는 gRPC처럼 응답 포로토콜 자체를 축소시킨 것
- 어떻게 되었든
주고 받는 것을 최소화
한다는 목적은 같으니 진행방향은 같은 것으로~
갑자기 useMemo가 위험해 보이는 이유
- 리액트 공식 문서: useMemo
useMemo는 성능 최적화를 위해 사용할 수는 있지만 의미상으로 보장이 있다고 생각하지는 마세요. 가까운 미래에 React에서는, 이전 메모이제이션된 값들의 일부를 “잊어버리고” 다음 렌더링 시에 그것들을 재계산하는 방향을 택할지도 모르겠습니다. 예를 들면, 오프스크린 컴포넌트의 메모리를 해제하는 등이 있을 수 있습니다. useMemo를 사용하지 않고도 동작할 수 있도록 코드를 작성하고 그것을 추가하여 성능을 최적화하세요.
- 한번 더 베타 공식 문서
- 잠깐만 오프스크린에 해제하면 좋은데...?
- 메모리 터지는 이슈는 없겠다
타입스크립트
- (번역)더 좋은 타입스크립트 프로그래머로 만드는 11가지 팁
- assertion 보다 satisfies
- 추론된 타입이 좀 더 명확하도록
- 특히 이 부분
- typechallenge 하면서 썼던 기분인데
- 실제 적용하려는 순간에 떠오르지 않는다
- 다시 보니 오! 하는 포인트
-
type ContentFactory<Config extends Record<ContentTypes, boolean>> = { [k in string & keyof Config as Config[k] extends true ? `create${Capitalize<k>}` : never]: () => Content; };
- 특정 타입의 키를 한정하는
MappedType
를 추론하도록 하고 싶은데 자꾸 string으로 확장되어 문제를 겪고 있었는데 👍
블로그 사이트맵
- 연말, 연초라서 회고를 올리는 블로그를 많이 접할 수 있었다
- 되돌아보는 내용 중 블로그의 성장 지표?를 이야기하는 것을 많이 보았는데
- 겸사겸사 나도 한번 확인해보니
- 뚝 하고 절벽 그래프였다
- 그 시점은 깃헙에서 개츠비로 변경한 시점이였고 (이건 알고 있었다...)
- 지난번 sitemap, robots 대응하면서 해결되지 않을까 기대하며 시간을 좀 오래 방치해두었다
- 하지만 무언가 개선되지 않았음을 깨달았다!
- 가장 큰 원인은 검색할만한 보람찬, 유의미한 내용이 없기 때문이지만
- 다른 곳에서 원인을 찾아보려 애쓰는 중 ㅋㅋㅋ
- 우선 사이트맵을 업데이트! (참고)
- 그리고 Google Search Console에서 확인해보는데
- 크롤링은 되었는데 색인이 생성되지 않은 URL이 많았다
- 무려 80프로 이상
URL이 Google에 등록되어 있지 않음
- 왜!
- 개츠비로 변경하면서 색인에 문제가 생긴걸까
- (추가) 나중에 확인해보니 url 자체가 변경되었기 때문에 404 페이지가 워낙 많았다
- SEO를 중요하게 생각한건 아니지만 (거의 일기 수준)
- 절벽 그래프를 보고 있으니 신경이 쓰이기 때문이다...
- 그리고 한참 뒤...
- GA 관련해서 패키지를 정리하고 있었는데 (참고)
- 갑자기 마주친
error gatsby-plugin-google-gtag@5.4.0: The engine "node" is incompatible with this module. Expected version ">=18.0.0". Got "16.10.0"
- 나는 왜 아직
node v16.10.0
을 쓰고 있었을까... ❌
2023
- 놀랍게도 2023이 되면서 라즈베리 서버가 죽었다
- ㅠㅠㅠㅠ
- 새해라고 이것저것 정리하다가 선이 빠졌나? 고민해봤지만 그건 pm2에 의해 잘 살아났을 것이다... (무한 신뢰)
- 지난 3월 라즈베리 죽었을때 보다는 훨씬 빠르게 알아챘는데
- 대응은 그러고 3일은 더 지나서 한 것 같다
- 아마도... 사용자가 혼자라서 그런건 비밀이다
- 예상되는 원인은 딱 하나였다
- 공유기에 붙어서 살고 있다보니 IP가 변경되면 치명적이다
- 두번째 같은 문제를 겪다보니 귀찮았다
- 어떤거 먼저 해야하더라? 하는 고민도 귀찮아서
- 다음에 또 문제가 생길 것이 분명하니 철저하게 문서를 남겨두었다
- 미래의 나 자신을 위한 현재의 내가 쓰는 일기?편지?주절주절이다
- 어디 공개하려는 내용이 아니라고 쓰다보니 의식의 흐름이 가장 잘 담겨있었다
- 다 쓰고 다시 읽어보니 모든 글은 항상 같은 흐름이였던것 같다
- 이건 비밀이였는데
- 라즈베리가 죽었다는 사실을 알고 나서 가장 먼저 한 일은 라즈베리 케이스 탐색이였다
- 무언가 안정적인 집에 넣어주고 싶었지만 마음에 쏙 드는건 아직...
- 다 정리하고 나서 한참 뒤에 다시 그동안 받은 센트리 에러 메일을 돌아보니 힌트가 이미 다 있었는데
- 주절주절 문서도 다시 읽어보니 이것만 쓰면 될 것 같다
Error: connect EHOSTUNREACH :::::3306
- 3306 포트를 왜 찾지 못했을까
- 외부 IP가 변경되었을 가능성 <<< 포트포워드 설정해둔 내부 IP 변경되었을 가능성