주말에 집구석에 혼자 오래있을 일이 있어서, 생각난 김에 블로그를 개편했습니다. 이 전에는 hexo 기반으로 만들어진 블로그를 작업했는데, hexo 생태계가 관리가 잘 안되고 있는 건지 플러그인이나 기능들이 제대로 동작을 안하더군요.
wordpress -> ??? -> github pages -> hexo -> gatsby 까지 벌써 개편만 한 다섯번 쯤 한거 같네요. 이제 그만 하겠습니다.
정적 사이트 생성기로 괜찮은게 뭐가 있나 알아보던 차에, 회사에서도 Gatsby를 쓰고 있길래 gatsby로 변경해보았습니다.
변경과정의 난관
front-matter를 관리하는게 묘하게 달라서 파이썬 스크립트로 통일 작업을 좀 해야 했다.
태그들에 svg 아이콘이 달려 있는게 이뻐서 테마를 선택했는데, 몇몇 아이콘들은 직접 svg를 편집해서 작업해야 했는데 이게 정말 귀찮았다. 그리고 이번 기회에 svg에 대해서 공부하게 되었는데, 몇몇 아이콘들은 간지 때문에 그 크기가 너무 크다. 향후에 최적화가 필요한 부분
기존 md 파일 몇개가 렌더링이 안되었는데, 이것도 따로 확인을 해봐야 했다. 그러나 리액트 기반이라 수정하는데 어렵지는 않았다.
장점
여러가지 다양한 플러그인들이 많고 관리도 잘되고 있다.
리액트로 쓰여져 있어서 스스로 관리가 용이하고, 확장성도 더 늘어났다.
이전 보다 블로그 디자인이 마음에 든다.
단점
dev에서 파일하나만 수정하는데, 그 파일만 수정하는게 아니라 query 전체가 돌고 있는 느낌이다. 이건 내가 발적화를 때문일까
info changed file at /Users/jayg/work/private/yceffort-blog/content/blog/2019/12/30/renewal-blog.md
success createPages - 0.204s
success createPages - 0.159s
success write out requires - 0.008s
success run queries - 5.169s - 125/125 24.18/s
success run queries - 0.058s - 3/3 51.45/s
success run queries - 0.023s - 1/1 44.27/s
[==]0.724 s 9/88 10% run queries
빌드 타임이 늘어났고, 빌드 후 결과 물도 사이즈가 커졌다. (90mb -> 352mb) 이것도 내 발적화 때문인 것으로 추정해본다
hot reloading 이 되었다 안되었다 한다. 이건 내가 뭘 설정을 잘못 건든걸까?
이제 왠만한 기능은 다 구현했고, 몇가지만 더 작업하면 된다.
앞으로 남은 과제
about 페이지 작성
구 blog github archive 처리 및 README.md 작성
aloglia 기반 검색 component 개발
code highlighter prismjs 의 media query 처리 (현재 pc화면에서 코드가 길어지면 사이드바가 찌그러진다.)
폰트 수정
gitment 기반 댓글 component 개발
github action으로 배포 연동
관련 글
#javascript#animation#web-animations-api
number-flow를 구형 브라우저로 이식하기: 다섯 가지 결정과 두 가지 번복
number-flow가 애니메이션을 켜는 최소 버전은 Chrome 125, Safari 17.2다. 이 하한을 Chrome 66과 WebKit 16.4까지 내리는 포크를 만들면서 내린 결정들과, 뒤집게 된 판단 두 가지, 그리고 자동 강등을 포기한 Safari 버그 조사의 기록.
·44분
#typescript#oxc#eslint
typescript@7을 설치하면 벌어지는 일들: 블로그 모노레포 마이그레이션 기록
pnpm lint가 12분 32초 걸리던 모노레포에 typescript 7.0.2를 넣어봤다. 타입체크는 조용히 지나갔는데 next build가 깨졌고, lint는 크래시했다. eslint와 prettier를 oxlint와 oxfmt로 갈아탄 하루의 연쇄 반응과 전후 실측 기록. 미리 말해두면, 빌드는 빨라지지 않았다.
·17분
◆ 프론트엔드 개발자가 알아야 할 쿠버네티스
#kubernetes#autoscaling#nextjs
오토스케일링은 자동이지만 즉시가 아니다: HPA의 시간을 구간별로 실측한 기록
트래픽을 12배로 올리고 새 파드가 첫 요청을 받기까지 31.5초. 그 31.5초의 내역서를 스톱워치로 뽑았다. 감지 창이 지배하는 구조, 배포 직후 5분 창에서 오토스케일러가 눈을 잃는 조건, 안정화 창의 계단, 메모리 HPA가 Node에서 불발되는 이유, KEDA의 선제 확장까지. 프론트엔드 개발자를 위한 쿠버네티스 시리즈의 다섯 번째 편이다.
·39분
◆ 프론트엔드 개발자가 알아야 할 쿠버네티스
#kubernetes#nextjs#nodejs
파드는 어떻게 종료되는가: 배포 중 에러의 원인과 해결을 실측한 기록
코드를 한 줄도 바꾸지 않은 배포에서도 에러는 샌다. 롤링 배포 중 새는 실패를 유형과 시각까지 태깅해 원인 네 가지를 부검하고, 처방을 한 층씩 얹어 0으로 만들기까지의 실측 기록이다. Next.js의 종료 코드 원문과 인질 드레인, CrashLoopBackOff의 실제 시간표까지. 프론트엔드 개발자를 위한 쿠버네티스 시리즈의 네 번째 편이다.