2020년에도 많은 사이드 프로젝트를 진행했다. 대다수의 사이드 프로젝트는 웹 애플리케이션으로 제작했고, 서버와 프론트 데이터베이스를 구축했어야 했고, 이것들을 어떻게 구축했는지, 그리고 어떤 것을 느꼈는지 간단하게 요약하고자 한다.

## 개발환경

- nextjs
- react
- typescript (급할 땐 javascript도 함)
- firestore
- cloud functions
- github
- vercel
- styled component

### nextjs

nextjs는 Server Side React 환경을 구축하는데 있어서 필수적인 라이브러리로 자리잡은 것 같다. 비단 SSR 때문 만이 아니더라도, 라우팅을 하는데 있어서도 편하게 적용할 수 있었다. `/pages` 폴더 하단에 디렉토리 구조로 만 설정해두면, 알아서 라우팅을 구성하기 때문에 굉장히 좋았다.

다만 이 방법의 한계는 당연하게도 라우팅이 복잡해 질수록 디렉토리 관리가 어려워 진다는 것이다. 가령 path param으로 `/id`를 가져오기 위해서 `[id].js`를 만들어 두면, 이 파일을 찾는 것도 피곤하고 관리하기도 어려웠다.

![next-path](./images/next-path.png)

> `[id].js` 라는 파일이 많아지면,, 이제 감당할 수 없는 미래...

그래서 `api`에서는 귀찮아지니까 그냥 다 query param으로 가져오는 방식으로 변경해버렸다.

혹은 불가피 하게 라우팅이 복잡해지면, `koa`를 별도 서버를 둬서 페이지 분기를 여기에서 처리하도록 만들었다. 이는 이전 회사에서 즐겨 쓰던 방식으로, 굳이 복잡하게 디렉토리 구조를 만들지 않아도 되서 유용했다. (감사합니다.)

하지만 대부분의 사이드 프로젝트가 라우팅이 복잡했던 것은 아니므로, 이 방법은 많이 쓰지 않았다.

### react

jquery 부터 웹 개발을 해오면서, 이제는 react가 어느정도 front 개발의 표준으로 자리잡은 것 같다. 물론 이러한 react에 대한 아쉬움 내지는 성토의 글도 있었지만, 많은 수의 프로젝트들이 react로 쓰여지면서 커뮤니티가 커지고, 그에 따른 많은 편의성을 얻은 것도 사실이다. 나 또한 모든 사이드 프로젝트에서 웹 애플리케이션이 필요할 때 마다 리액트를 선택했고, 이는 탁월한 선택이었다. 이에 관해 흥미로운 글이 있었는데 한번 읽어보면 좋을 것 같다.

https://jake.nyc/words/no-one-ever-got-fired-for-choosing-react/

누구도, 리액트를 고른다고 해서 해고되는 것은 아니다.

> I have heard from many developers who have told me that they accepted the argument that vanilla JavaScript or microlibraries would let them write leaner, meaner, faster apps. After a year or two, however, what they found themselves with was a slower, bigger, less documented and unmaintained in-house framework with no community. As apps grow, you tend to need the abstractions that a framework offers. Either you or the community write the code.

### typescript

사실 타입스크립트가 협업을 하는 경우에 한해서 좋다고 생각해서, 초창기 사이드 프로젝트를 진행할 때에는 자바스크립트로 진행을 했었다. 물론 어느 정도 타입과 이런저런 제약에 벗어나서 정말 편리했고, 일정수준 프로젝트가 커지지 않는다면 생산성도 향상됐다.

문제는 내 스스로가 만든 데이터 구조가 복잡해지면서 내 머리로 조차 기억하지 못하고 급기야 버그를 만들기 시작했다는 것이었다. (오오 33살,,,) 그렇게 타입과 갖가지 버그로 인해 혼란을 겪고 나니, 이럴거면 초창기에 타입을 잘 선언해두고 프로젝트를 꾸몄다면 이런 혼선을 줄일 수 있었을 거라는 아쉬움이 남았다.

그래서 앞으로는 그냥 혼자 하든, 둘이 하든 지간에 타입스크립트로 진행하고자 마음먹었다. 잘 선언해둔 타입으로 프로젝트를 꾸미게 되면, 이후에 데이터 구조를 가져다 쓸 때도, 리팩토링을 할 때도 많은 도움을 얻을 것 같다.

### firestore

부끄럽고 미련하게도 초창기에는 SQL을 node와 연결해서 썼었다. 그러나 스키마 구성, 트랜잭션 관리, 테이블 관리 등을 겪고 나니 배보다 배꼽이 더 큰 느낌이었고, 빠르게 가져다 쓸 수 있는 NoSQL을 찾던 와중에 Firebase의 firestore 을 쓰기 시작했다. SQL 데이터 베이스를 구성하는데 걸린 시간을 제로에 가깝게 줄일 수 있었고, 데이터 관리 또한 JSON 형태로 아주 편하게 가져다 쓸 수 있었다.

다만 join 이나 or, in 과 같은 식의 복합쿼리는 안되기 때문에 어느 정도의 불편함을 감수해야 했다.

https://firebase.google.com/docs/firestore/query-data/queries?hl=ko

> Cloud Firestore는 다음 유형의 쿼리를 지원하지 않습니다.

> - 이전 섹션에서 설명한 것과 같이 여러 필드에 범위 필터가 있는 쿼리
> - 논리적 OR 쿼리: 이 경우 각 OR 조건에 해당하는 별도의 쿼리를 만들고 앱에서 쿼리 결과를 병합해야 합니다.
> - != 절을 사용하는 쿼리: 이 경우 쿼리를 초과 및 미만 쿼리로 분할해야 합니다. 예를 들어 where("age", "!=", "30") 쿼리 절은 지원되지 않지만 where("age", "<", "30") 절이 있는 쿼리 하나와 where("age", ">", 30) 절이 있는 쿼리 하나를 결합하면 동일한 결과 집합을 얻을 수 있습니다.

예컨데 장바구니와 같은 데이터 베이스를 꾸밀일이 있었는데, 이를 조회하기 위해서 불가피하게 2n 회로 데이터 조회를 요청할 수 밖에 없었다.

![firestore](./images/firestore-quota.png)

그러다 보니 개발 단계에서 마저도 읽기 횟수가 눈에 띄게 튀기 시작했다. 아직 눈에 띄게 document가 있지 않은 상태라 무료 수준에서 커버를 치고 있지만, document가 늘어 나면 이제 모든 쿼리를 쓰는데 신중에 신중을 기하게 될 것이다. (한번 읽기 마다 `0.06$`)

https://firebase.google.com/docs/firestore/pricing

없는 살림에 GCP를 이것저것 쓰고 있기 때문에 굉장히 덜덜덜 하고 있는데,, 부디 나에게 예산 알림이 오는날이 없었으면 한다. 그리고 그날이 온다면, mock을 잘만들어서, 쿼리를 잘만들어서 대처해보는 걸로...

### Cloud functions

cloud function은 slack, survey monkey, jandi 등의 웹 훅 용으로 유용하게 썼다. 함수 하나만 클라우드에 올려서 서버 없이 쓸 수 있기 때문에 굉장히 유용했다. firestore에 비해서 가격도 비교적 저렴해서 (그리고 애초에 많이 호출되는 함수도 아니었지만) 안심하고 여러 함수를 서버없이 잘 사용했다. 예전에 이거 하자고 인스턴스 따고 보안규칙 따고 생쇼를 했던 과거에 비하면, 너무나도 편리하다.

![cloud functions](./images/cloud-functions.png)

[최근에는 블로그 썸네일 생성기로도 사용하기도 했다.](https://yceffort.kr/2020/12/generate-serverless-thumbnail) 감사합니다. 다음엔 꼭 픽셀 폰 싸서 보답하겠습니다.

### vercel

heroku의 시대가 가고, 이제는 vercel 의 시대가 온 것 같다. 웹 애플리케이션을 프로덕션에 올리는 용도로는 망설임없이 vercel을 썼다. heroku에 비해 기능은 rich 하지 않지만 필요한 기능만 들어있고, (heroku는 너무 이것저것 많은 기분이다) 배포도 용이하며, 무엇보다 github 에 integration 할 수 있다는 점이 매력적이다.

https://github.com/yceffort/yceffort-blog-v2/pull/222#issuecomment-740369078

또한 가격도 heroku 보다 저렴했다. 웹 애플리케이션 당 가격이 아니고 한 member 당 가격을 책정하기 때문에 20달러에 프로 계정으로 나 혼자 잘 먹고 잘 쓰고 있다. (프로 계정은 최대 10명의 멤버, 50 도메인, 1000gb의 bandwidth 제한이 있다.)

![vercel1](./images/vercel1.png)

![vercel2](./images/vercel2.png)

### github

마이크로소프트에 인수된 뒤로 나날이 발전하고 있는 github 도 빼 놓을 수 없다. github action 덕분에 CI, CD 등도 편리하게 수행할 수 있었고, 각종 bot을 통해서 다양한 작업을 할 수 있었다. 또한 cron job 도 편리하게 이용할 수 없었다. 기존에는 클라우드에 인스턴스 띄워서 크론 설정하고, https://healthchecks.io/ 로 healthcheck 까지 확인했다면, 이제는 github action 하나면 충분하다.

또한 유용하게 썼던 것 중 하나는 github code spaces 다. 개발 환경이 불안정했던 외부에서도 인터넷만 연결되어 있다면, codespaces로 편리하게 개발을 할 수가 있었다.

pro 계정을 활용하면서 private repository도 자유롭게 꾸민 것이 개인적으로 많은 도움도 되었다. 내 작업물 대다수가 private 으로 되어 있어서 많은 코드를 세상과 공유(?) 하지 못했지만, 그래도 덕분에 각종 예민한 private key를 편하게 관리할 수 있었다.

올해에는 dark 모드 까지 지원되었는데, 앞으로도 github에서 더욱 rich한 기능을 지원해 줬으면 좋겠다.

### styled-component 그리고 css

css-in-js 에 대해서는 이제는 하나의 흐름이라고 개인적으로 생각했다.

- Global namespace
- Dependencies
- Dead Code Elimination
- Minification
- Sharing Constants
- Non-deterministic Resolution

하지만 지나가다가 본 글이 있는데, 보면서 이런저런 생각을 하게 됐다.

- https://blueshw.github.io/2020/09/27/css-in-js-vs-css-modules/
- https://blueshw.github.io/2020/09/14/why-css-in-css/

각자의 장단이 있는 것 같고, 글쓴이의 의도에도 적극 공감한다.

그러나 이와 별개로 문제는 내가 css에 대한 이해와 디자인 감각이 현저히 떨어진다는 것이다.🤪 내년에는 정녕 css를 공부해야 하는 것일까. 이쁘게는 못하더라도 (이미 디자인에 감각이 없다는 것을 블로그가 증명하고 있다), 기본적인 css에 대한 이해도 아직은 조금 부족하고, 더 공부해야 겠다는 생각이 든다.

## 마치며

일하는 회사에서 이것저것 새로운 최신의 기술, 내가 배웠던 다른 코드들을 모두 적용해 볼 수 있으면 정말 좋다. 돈도 받고, 공부도 하고, 개인적으로 성장도 할 수 있고 회사 연말 평가에 반영할 수도 있다.

그러나 아쉽게도 회사 업무에서 펼칠 수 있는 상상의 나래는 한정적이다. 기존에 쓰고 있는 기술은 한정적이고 뒤쳐져 있으며, 설득해야 하는 사람은 많고 새로운 것에 대한 반론 또한 존재한다. 이미 잘되고 있는 레거시가 있는데 굳이 왜? 그렇다고 내가 모든 책임을 다 안고 시도하기엔, 일단 나부터가 쫄린다. 로컬에선 잘됐는데? 알파에선 잘됐는데? 라는 변명으로 막을 것인가? 또한 개발자만 있는게 아니다. 기획자 분들도, 테스터 분들도, 그리고 높으신 양반들도 있다. 개발자 입장에서는 아무런 변화가 없는 코드라고 자신할 수 있지만, 그들의 눈에서는 테스트해야할 골칫거리가 하나 더 생기는 것 뿐일지도 모른다.

![sorry](./images/sorry.png)

> 미안합니다,,,

이런 저런 이유로 미루어, 사이드프로젝트는 개발자로서의 성장, 그리고 킬링타임을 위해 필수인 것 같다. 비록 아무도 안보는 블로그지만, 그게 오히려 좋다. CSR을 SSR 바꾸고, 새로운 기술을 적용해보고 공부해 볼 수도 있고 트렌드에 뒤쳐지지 않을 수도 있다. 버그로 프로젝트가 망가져도 트래픽은 잃을 지언정 아무도 뭐라고 하지 않으며, 부담없이 새로운일을 해볼 수 있다. 개발자가 된 이후로 몇년만에 처음으로, 각종 컨퍼런스의 타이틀을 보고 '다 아는 기술이구만' 이라며 고개를 끄덕여 봤다.

새로운 기술, 코드가 있는데 회사에서 시도할 수가 없다? 회사에서 잘 만들어 놓은 사내 서비스 보다 AWS, GCP를 써보고 싶다? 체크카드를 꺼내서 payment를 등록하고 지금 당장 나만의 프로젝트를 만들어서 공부해보자. 기술은 많고, 내가 써본 것은 손에 꼽는다. 이대로 회사일만 하기엔, 밖에는 재밌는게 너무 많다.


2020년 사이드 프로젝트 회고

블로그를 업데이트 했다. 업데이트를 하게 되면서 배운 점과 개선해 나가야할 점들에 대해서 간단히 요약해 본다.

## Table of Contents

## 시작

원래는 https://developer-diary.netlify.app/ 이 블로그를 커스터마이징해서 쓰고 있었다. 고를 때만 해도 꽤 괜찮아서 잘 쓰고 있었는데, 걔속 사용하다 보니 몇가지가 걸렸다. 제목과 부제목 사이의 간격이라던가, Tech Topics 아이콘 수집, 그리고 사이드 바의 간격 등... 몇가지를 계속해서 커스터마이징 하다보니 땜질식의 처방이 되고 있었고, 더 이상 무엇을 더 이쁘게 만들어야 할지 모르겠다는 생각에 까지 이르게 되자, 결국에는 모든 것을 갈아 엎고 새로 만들자는 생각에 이르게 되었다.

## 시작

### 1. 테마 선택

1. 최대한 깔끔해서 더 이상 손댈 것이 없을 것
2. 페이징을 지원할 것
3. SEO를 어느정도 지원할 것

그래서 선택한 블로그는 https://lumen-v2.netlify.app/ 다.

### 2. Github repository 이사

사실상 markdown 블로그 내용을 제외하고는 모든 것이 바뀌기 때문에, 기존 Repository를 archived 시키고, 새로운 Repository로 이동했다.

- 기존: https://github.com/yceffort/yceffort-blog
- 신규: https://github.com/yceffort/yceffort-blog-v2

### 3. FrontMatter 일괄 업데이트

frontmatter는 특정 페이지에만 쓰이는 변수를 최상단에 선언해 둔 것을 의미한다.

https://github.com/yceffort/yceffort-blog-v2/blob/master/content/posts/articles/2020/08/mobx-study-4.md

```yaml
---
title: MobX를 공부하자 (4) - React와 Mobx의 10분 요약 글
tags:
  - javascript
  - MobX
published: true
date: 2020-08-30 19:27:22
description: 'React와 MobX에 대한 10분 설명'
category: MobX
template: post
---
```

위의 내용이 frontmatter를 의미한다. 기존에는 frontmatter가 몇개 쓰이는 것 없이 깔끔했는데, 이 테마에는 제법 쓰이는 것이 많았다. 아래는 frontmatter에 대한 변경사항이다.

- tags, category등은 기존의 tags를 기준으로 사용하게 두었다.
- published: true 는 draft: false 와 동일하게 동작하도록 수정했다.
- slug는 기존 주소와 호환성을 위해 `/:year/:month/:file-name` 을 유지하도록 했다. slug가 없을 경우 디렉토리 구조에 따라서 파일명을 이전과 같이 설정한다.

frontmatter 에디팅을 위해서 nodejs로 .md 파일을 모두 읽어서 사용했으며, `fs`외에는 별도의 라이브러리를 사용하지 않았습니다. 파일을 line by line 으로 읽어서 `---` 내부의 내용을 읽어 왔다.

### 4. 이미지 경로 업데이트

과거 이미지들의 경우 이상하게 path설정을 해두거나, `static` 폴더에 두는 등 일관적이지 못한 문제가 있었는데, 이러한 문제를 수정했다. `![](.jpg|.png.jpeg)` 로 되어 있는 모든 파일을 읽어와서, 적절한 경로로 이미지로 이동하고, path를 수정했다.

### 5. 기타 블로그 커스터 마이징

블로그의 내용 일부를 커스터마이징했다. (리트윗 기능 제거, 일부 string 변경 등)

### 6. github action으로 CI 단계 추가

CI단계를 추가해서 배포전에 기본적인 코드 검사를 할 수 있도록 했다. https://github.com/yceffort/yceffort-blog-v2/blob/master/.github/workflows/ci.yaml 기본적인 빌드 뿐만 아니라, 다음 포스팅에서 언급할 `eslint-config-yceffort`를 활용해서 `lint`와 `prettier`도 동시에 체크한다.

### 7. heroku에서 vercel로

과거 블로그 서빙을 위해서 heroku를 사용했다. 사이트가 점차 비대해지면서 무료 버전으로 감당이 안되기 시작했고, 이에 `production` 버전으로 업그레이드 해서 매달 25달러 씩 주고 유지했다. https://www.heroku.com/pricing

최근 vercel을 눈여겨보면서 (nextjs 덕분!) vercel로 갈아타기로 결심 했고, 이 기회에 [vercel](https://vercel.com/)로 이주했다.

![vercel](./images/vercel.png)

#### 장점

- netlify처럼 CD 기능 지원이 뛰어나다. 매 PR 마다 배포를 자동으로 해줘서 ([이런 느낌](https://yceffort-blog-v2-4llxkkbh3.vercel.app/)) https://github.com/yceffort/yceffort-blog-v2/pull/27 실제 머지 전에 상태를 확인할 수 있다.
- 개인 유저는 무조건 공짜다. 팀 단위 프로젝트 관리를 위해서는 돈을 지불해야 하는데, 어차피 개인 블로그 이므로 해당이 없다.
- 인터페이스가 깔끔하다.
- 기능에 군더더기가 없다. (장점일 수도 단점일 수도. heroku는 DB 등 다양한 addons을 붙일 수 있다.)

무엇보다도 다크모드를 지원한다는 점(...?)과 인터페이스가 깔끔하다는 것이 마음에 들었다. 도메인 설정도 아래 그림처럼 깔끔하게 할 수 있었다.

![vercel-domains](./images/vercel-domains.png)

## 결과

미니멀한 블로그를 만든 결과, 굉장히 만족 스러웠고, 당연하게도 google page speed insights 에서도 좋은 점수를 받을 수 있었다.

https://developers.google.com/speed/pagespeed/insights/?hl=ko&url=yceffort.kr

![desktop](./images/yceffort-blog-speed-insight-desktop.png)

![mobile](./images/yceffort-blog-speed-insight-mobile.png)

그리고 모바일에서 사용성이 굉장히 좋아졌다. 검색 등 이것저것 기능이 붙어있어서 좀 어지러운 감이 있었는데, 이전보다 훨씬 깔끔해졌다.

## 아쉬웠던 점

### 굉장히 느린 빌드 타임

빌드가 굉장히 느려졌다.

![vercel-build](./images/vercel-build.png)

기본적으로 블로그 글이 많은 것도 있지만, 빌드 하면서 gatsby에서 이것저것 수행하는 것이 많아졌다. `mathjax`지원을 위한 처리, 이미지 preview 생성 등 기본적으로 마크다운을 html로 바꾸는 과정에서 처리하는 작업 외에도 거치는 작업이 너무 많아졌다. 또한 추가/수정한 글만 생성하는 것이 아니라, 모든 글을 새로 다시 만들기 때문에 굉장히 느려질 수 밖에 없다. 빌드가 느려졌다는 것은 곧 dev로 개발하는 것도 엄청나게 느려졌다는 것을 의미하며, 내 맥북 에어에서 dev로 개발하기 위해서는 10분 넘게 빌드를 돌려야 한다. (ㅠㅠ) 이는 visual studio codespace를 사용하는 계기가 되기도 했다.

이를 해결할 수 있는 방법이 몇가지 떠오르긴 하지만, 다시 이직하게 되다면 그 때 처리하도록 하겠다. (....)

### Prettier 미적용

markdown에 pretter를 적용하고 싶었는데, mathjax 를 위해 사용한 문법 `$$...$$` , 즉 `$`를 모두 `\$`로 바꾸는, 이스케이프 처리해버리는 문제가 발생했다. 당연히 mathjax가 죄다 박살나 버렸고, 얼른 revert했다.

### mathjax error 에러

```
14:11:12.944  	error CHTML - Unknown character: U+BE14 in MathJax_Main,MathJax_Size1,MathJax_AMS
14:11:12.945  	error CHTML - Unknown character: U+B85D in MathJax_Main,MathJax_Size1,MathJax_AMS
14:11:12.946  	error CHTML - Unknown character: U+B2F9 in MathJax_Main,MathJax_Size1,MathJax_AMS
14:11:12.947  	error CHTML - Unknown character: U+C791 in MathJax_Main,MathJax_Size1,MathJax_AMS
14:11:12.948  	error CHTML - Unknown character: U+C5C5 in MathJax_Main,MathJax_Size1,MathJax_AMS
14:11:12.948  	error CHTML - Unknown character: U+C99D in MathJax_Main,MathJax_Size1,MathJax_AMS
```

`$$...$$`로 대변되는 mathjax syntax안에 내가 한글을 넣어놨나보다. 이 한글을 찾아내서 모두 없애야 빌드 타임에 비명을 지르지 않을텐데, 귀찮아서 아직 수정하지 못하고 있다. (ㅠㅠ)

### 리다이렉트 누락

내 글을 블로그에서 검색하면, https://www.yceffort.kr 로 대부분이 검색이 되는데, https://yceffort.kr만 설정해두고, https://www.yceffort.kr를 https://yceffort.kr로 리다이렉트 해주는 처리를 누락해서 2주간 구글 검색 실적이 박살났다. (...) 다행히 2주뒤에 복구 해두었지만, 박살난 실적이 되돌아 오려면 꽤 오랜 시간이 걸릴 것 같다.

### yceffort.github.io

몇몇 블로그나 위키에 yceffort.github.io 로 걸린 포스팅이 보이는데, 이 주소는 현재 동작하고 있지 않다 ㅠㅠ 따라서 yceffort.github.io 블로그를 다시 살려서 현재 동작하는 웹페이지로 리다이렉트 시키는 작업을 검토 중이다.

## 결론

일주일에 걸쳐 블로그 이사작업을 마쳤고, 심각한 버그 없이 대부분의 작업을 완료 했다. 아직 몇몇 작업들이 남아있고 이들을 [이슈업](https://github.com/yceffort/yceffort-blog-v2/issues)해서 차근차근 관리하도록 하겠다. 그리고 앞으로 이런식의 대형 작업은 더 이상 없었으면 좋겠다................


백수가 될 때마다 블로그를 갈아엎는 습관

블로그 업데이트에 대한 회고

## 블로그의 성장

2018년 5월 1일에 블로그를 시작한 이례로 헛소리를 지껄이는 블로그에서, 제법 이사람 저사람 찾아오는 블로그로 성장했다.

![history1](./images/history1.png)

![history2](./images/history2.png)

꾸준한 블로그 뻘 글과 회사에서 일하는 것 덕분에 github contribution에 초록색 불도 많이 들어오고 있다.

![contribution1](./images/contribution1.png)

[github contribution은 2013년에 생긴 이래로](https://github.blog/2013-01-07-introducing-contributions/) 개발자의 daily 성과 지표를 알려주는데 도움을 주고 있다.

## contribution의 기준

```
What counts as a contribution
On your profile page, certain actions count as contributions:

Committing to a repository's default branch or gh-pages branch
Opening an issue
Proposing a pull request
Submitting a pull request review
```

- default branch (master)나 gh-pages (github page 브랜치)에 기여하는 것
- 이슈를 만드는 것
- PR을 만드는것
- PR 리뷰를 제출하는 것

![contribution2](./images/contribution2.png)

## 매일매일 Contribution 해보기

학교가 끝나서 심심해졌겠다, 2020년에 daily로 contribution을 해봐야 겠다. 달력에 모두 초록불이 들어오도록


## 블로그의 성장 2018년 5월 1일에 블로그를 시작한 이례로 헛소리를 지껄이는 블로그에서, 제법 이사람 저사람 찾아오는 블로그로 성장했다.  ![history1](./images/history1.png)  ![history2](./images/history2.png)  꾸준한 블로그 뻘 글과 회사에서 일하는 것 덕분에 github contributi...

2020년, 매일 github에 contribution 하기

주말에 집구석에 혼자 오래있을 일이 있어서, 생각난 김에 블로그를 개편했습니다. 이 전에는 hexo 기반으로 만들어진 블로그를 작업했는데, hexo 생태계가 관리가 잘 안되고 있는 건지 플러그인이나 기능들이 제대로 동작을 안하더군요.

wordpress -> ??? -> github pages -> hexo -> gatsby 까지 벌써 개편만 한 다섯번 쯤 한거 같네요. 이제 그만 하겠습니다.

정적 사이트 생성기로 괜찮은게 뭐가 있나 알아보던 차에, 회사에서도 Gatsby를 쓰고 있길래 gatsby로 변경해보았습니다.

## 변경과정의 난관

- front-matter를 관리하는게 묘하게 달라서 파이썬 스크립트로 통일 작업을 좀 해야 했다.
- 태그들에 svg 아이콘이 달려 있는게 이뻐서 테마를 선택했는데, 몇몇 아이콘들은 직접 svg를 편집해서 작업해야 했는데 이게 정말 귀찮았다. 그리고 이번 기회에 svg에 대해서 공부하게 되었는데, 몇몇 아이콘들은 간지 때문에 그 크기가 너무 크다. 향후에 최적화가 필요한 부분
- 기존 md 파일 몇개가 렌더링이 안되었는데, 이것도 따로 확인을 해봐야 했다. 그러나 리액트 기반이라 수정하는데 어렵지는 않았다.

## 장점

- 여러가지 다양한 플러그인들이 많고 관리도 잘되고 있다.
- 리액트로 쓰여져 있어서 스스로 관리가 용이하고, 확장성도 더 늘어났다.
- 이전 보다 블로그 디자인이 마음에 든다.

## 단점

- dev에서 파일하나만 수정하는데, 그 파일만 수정하는게 아니라 query 전체가 돌고 있는 느낌이다. 이건 내가 발적화를 때문일까

```shell
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으로 배포 연동


주말에 집구석에 혼자 오래있을 일이 있어서, 생각난 김에 블로그를 개편했습니다. 이 전에는 hexo 기반으로 만들어진 블로그를 작업했는데, hexo 생태계가 관리가 잘 안되고 있는 건지 플러그인이나 기능들이 제대로 동작을 안하더군요. wordpress -> ??? -> github pages -> hexo -> gatsby 까지 벌써 개편만 한 다섯번 쯤...

블로그 개편했습니다. 😎

Don't do anything boring

## Tensorflow JS

중요도: ★★★★★
난이도: ★★★★★

AI가 하고 싶어요 선생님... tensorflowjs 를 튜토리얼부터 따라하면서 배워보자.

## 알고리즘 강의

[백준강의](https://code.plus/bundle/8)

이제 알고리즘 정복할 때가 되었다. 자바스크립트와 파이썬으로 진행해볼 예정.

중요도: ★★★★
난이도: ★★

## Preference 패키지

terminal과 친숙해지기 위해 alias설정, git 설정 등을 모아 놓은 private repository를 만들어보고자 한다.

https://blog.appkr.dev/work-n-play/dotfiles/
https://github.com/inbeom/dotfiles
https://github.com/boxersb/dotfiles

요런 거를 참고해보자. `dotfiles` 보다는 광범위한 영역을 커버해보고 싶다.

중요도: ★
난이도: ★★

## Resume 작성

마크다운 문서로 Resume를 준비해두자. 그리고 꼭 이직은 아니더라도 한 두군데 이따금씩 넣어보면서 업계에서의 내 위치(?) 를 고민해보자.

중요도: ★★★★
난이도: ★

## Kindle

이제 이 좁은 집에 더 이상 책 둘 곳도 없다. 이제 그냥 킨들로 읽자. 작년까지는 무식하게 많이 읽자 주의 였다면, 이제는 좀 한권씩 정독할 생각이다.

중요도: ★★★
난이도: ★★★★★

## 영어 Speaking

영어 면접 대비인데... 당장 일하러갈일이 없어서 이건 안 할 수도 있겠다.

중요도: ★★★
난이도: ★

## 앱 런칭

`flutter` 나 `react-native-app`으로 새롭게 앱 하나 만들어 보고 싶다. 근데 마땅히 뭘 만들어야 할지 아무생각이 없다.

중요도: ★
난이도: ★★★★


Don't do anything boring ## Tensorflow JS  중요도: ★★★★★ 난이도: ★★★★★  AI가 하고 싶어요 선생님... tensorflowjs 를 튜토리얼부터 따라하면서 배워보자.  ## 알고리즘 강의  [백준강의](https://code.plus/bundle/8)  이제 알고리즘 정복할 때가 되었다. 자바스크립트와 파이썬으...

Diary 1

2020년 사이드 프로젝트 회고

블로그 업데이트에 대한 회고

2020년, 매일 github에 contribution 하기

블로그 개편했습니다. 😎

2020년 목표