0%

나는 이 블로그를 Hexo라는 프레임워크를 이용해 작년 8월에 만들었었고 나름대로 계속해서 포스팅을 하고 있었다. 그러다 1월 말에 원래 사용하던 Windows 갤럭시북에서 MacOs의 맥북 M1으로 갈아타게 되었는데 깃허브에서 repository를 clone하고 hexo 명령어를 입력해도 작동하지 않는 문제가 생겼다.

처음부터 블로그를 다시 세팅해야하나 아니면 다른 플랫폼으로 이사를 갈까 고민하며 해결방법을 찾던 중 다음 글을 발견했다. Transfer Hexo Blog to New Device

위 블로그 게시글의 내용을 따라 수행하니 맥북에서도 다시 블로그 포스팅을 진행할 수 있게 되었고, 혹시라도 다음에 또 컴퓨터를 바꿀 수 있으니 방법을 정리해두어야겠다고 마음먹었다.

새로운 branch 만들기

  • hexo blog repository를 git clone 한다.
  • clone한 repositroy에서 git checkout -b branch명로 새로운 branch를 만든다.
  • 새로운 branch에서 .git 폴더를 제외한 모든 파일들을 삭제한다.
  • 원래 사용하던 기기의 hexo blog 폴더를 복사해온다.
  • 이전 기기의 .git 관련 폴더들은 삭제한다.
  • 새로운 branch를 Github에 push한다.

새 기기에 Hexo 설치하기

  • npm install hexo --save로 Hexo를 설치한다.
  • npm install hexo-deployer-git --save로 git deployer plugin를 설치한다.

블로그 Deploy하기

  • 새로 만든 branch에 .gitigonre 파일을 추가한다.
  • .gitignore 파일에 .deploy_git/*public/*을 추가한다
  • hexo clean을 통해 이전 웹페이지를 삭제한다.
  • hexo generatehexo deploy로 새로운 웹페이지를 만들 수 있다.

무엇이 문제였을까?

hexo deploy시 만들어진 정적 웹페이지가 자동으로 Github의 default branch에 push되었던 것이지 hexo를 설치했던 기존 폴더 자체를 Github에 push한것은 아니었기 때문에 git clone을 해도 hexo 명령어가 작동하지 않았다.
따라서 새로운 branch에 원본 기기의 폴더를 복사해옴으써 문제를 해결할 수 있었다.

들어가며

약 2주동안의 프로젝트가 종료되었다. 벌써 4개월간의 커넥to 과정이 끝났다는게 믿기지 않을 정도로 시간이 너무 빨리 흘러간 것 같다. 프로젝트를 시작하면서 갑자기 허리디스크가 생겨서 프로젝트에 집중하기가 어려웠는데, 그래도 좋은 팀원들 덕분에 잘 마무리한 것 같다. 이번 프로젝트 역시 배운점도 많았고 아쉬운점도 많았는데 회고를 하며 정리해보려고 한다.


프로젝트 DUI

이번 프로젝트는 주어진 조건이 몇가지가 존재했다.

  1. 바닐라 JS를 사용해 구현한 SPA(Single Page Application)일 것.
  2. CRUD를 구현할 것.
  3. Routing 기능을 구현할 것.
  4. JWT를 사용해 로그인 기능을 구현할 것.

이 조건들을 만족시킬 프로젝트 주제가 무엇인지 고민하다가, 다른 팀원분이 블로그를 구현하는 것이 어떻겠냐고 제안하셨고 다들 적절하다고 생각해 Draw yoUr Idea 의 줄임말인 DUI라는 이름으로 프로젝트를 진행하게 되었다.

개발 기간은 2022-12-12 ~ 2022-12-23로 약 2주 동안 진행되었고, 팀원은 총 3명이었다.

좀 더 자세한 사항은 https://github.com/rjsej12/public-DUI 에서 확인 가능하다.


KPT

Keep

  • 이번에도 프로젝트를 시작하기 전에 환경설정을 중요시 여기고 이 부분에 대해 많이 논의 했는데 그 결과 폴더구조가 깔끔하게 구성된것 같아서 만족스러웠다.

  • 저번 프로젝트를 진행하면서 다음번엔 꼭 문서화를 잘 해보자 생각했었는데, 만족스러울 만큼은 아니지만 저번보다는 결과물이 좋게 나왔다고 생각되었다.

Problem

  • 프로젝트 시작때부터 갑자기 허리 디스크가 생겨서 프로젝트에 집중하기 어려웠다.

  • 이번 프로젝트에서는 History API를 이용해 Routing 기능을 구현했는데, History API를 보완한 Navigation API를 사용해보고 싶다.

  • 정확하게 코딩 컨벤션을 설정하고 시작하지 않아 처음에 서로의 코드 구조가 일치하지 않았던게 아쉬웠다.

Try

  • 소통하자! - 프로젝트를 시작하기 전 각자가 사용하길 원하는 기술 스택을 상의하면서 팀원 중 한 분이 tailwind의 편의성을 설명하였고, 빠른 적용에 모두 동의하여 프로젝트의 스타일 프레임워크로 Tailwind CSS를 사용하기로 결정했다. 또한 적극적인 class 이름을 활용해 작은 컴포넌트 단위의 완성된 스타일을 대표하기를 원하셨는데 그 분을 제외한 우리 둘은 정확한 이해를 하지 못했었고 이게 맞는지 고민하며 작업을 수행했고 결과물은 역시 원하는 바와 달랐다. 이전 우아할 프로젝트때는 이해가 안되는 부분이 존재할 때 계속해서 소통하며 이해가 될 때까지 넘어가지 않았었는데, 이번에는 건강 문제를 핑계로 소통에 소홀했던 것 같다. 협업에서 가장 중요한 것이 다른 사람의 생각을 이해하는 것이니 만큼 소통하는데에 있어서 적극적이어야할 필요를 다시 한 번 느꼈다.

마치며

이번 프로젝트를 끝으로 약 4개월간의 긴(?) 과정이 종료되었다. 커넥to 과정을 시작할때와 비교해보면 스스로 정말 많이 성장했음을 느끼는것 같다. 단순히 새로운 지식을 배웠기 때문이 아니라, 모르는 부분이 생겼을때 그것을 찾아 나가는 방법과 더 나은 코드를 위해 어떠한 고민을 해야 하는지 또 다른 사람과 협업을 할 때 어떻게 커뮤니케이션 해야 할 지 등 앞으로 개발자로 살아가면서 가져야 할 마인드, 태도가 달라졌다고 느끼기 때문이다. 아직 많이 부족하지만, 이렇게 지속해서 공부해 나간다면 그래도 좋은 개발자가 될 수 있지 않을까 하는 일말의 자신감도 생긴것 같다.

사실 개발자로의 취직을 준비하면서 가장 걱정되었던 부분은 (많이 고민하고 결정하기는 했지만) ‘내가 지속해서 공부를 잘 할수 있을까?’ 였다. 어릴 때 부터 흥미를 못 느끼는 일에는 집중을 잘 하지 못하던 터라 겉핥기만 했을때는 재미있다 느꼈지만 깊게 공부하게 되었을때도 재미가 유지될지에 대해 의심이 존재했다. 하지만 4개월 동안 느낀 것은 ‘재밌다’였다. 뭐 아직도 깊게 파고든것은 아니라고 할 수 있겠지만, 문제를 만나고 해결하고 결과물을 실제로 볼 수 있는등 여러 부분들이 오랜만에 ‘공부를 해야해서 하는게 아니라 재밌어서 하는 경우도 있었지’라고 생각하게 했다.

여전히 부족함을 느끼는 만큼, 또 프로젝트를 하면서 vanilla js의 불편함을 느꼈어서 얼른 react와 같은 프레임워크도 공부하고 싶고 vue는 또 뭐가 다를지 등등 배움에 대한 욕구가 생기는 것 같다. 과정이 끝나더라도 열심히 해서 지속적으로 성장할 수 있는 기반을 쌓아야겠다.

🤔What is Problem?

페어 프로그래밍을 진행하면서 수직으로 스크롤한 거리에 따라 숨겨진 버튼을 활성화 하고, 스크롤 버튼을 클릭했을 때 맨 위로 스크롤하는 예제를 해결해야했다.

이를 위해 수직으로 스크롤한 거리를 측정하는 방법과 스크롤을 시키는 방법이 필요해 이에 대해 알아보았는데, 같은 기능을 하는 프로퍼티와 메서드가 중복으로 존재해 어떤것을 사용해야하는지 고민이 되었다.

Window.pageYOffset vs Window.scrollY

먼저 수직으로 스크롤한 거리를 측정하는 방법에는 Window.pageYOffset와 Window.scrollY가 존재했다. MDN에서는 pageYOffset이 scrollY의 다른이름이라고 했지만, 두 프로퍼티에는 브라우저 호환성의 차이가 존재했다.

일부 오래된 브라우저는 scrollY 대신 pageYOffset만 지원했고 노후 환경을 신경쓰지 않아도 된다면 둘 중 아무거나 사용해도 괜찮지만, 별다른 요구조건이 없다면 하위호환성을 위해 pageYOffset을 사용하는 것이 더 좋은 코드라고 판단했다.

Window.scroll() vs Window.scrollTo()

다음으로 맨 위로 스크롤하기 위해서는 Window.scroll() 이나 Window.scrollTo() 메서드를 사용할 수 있었다. 이 두 메서드는 차이 없이 동일해 둘 중 아무거나 사용해도 괜찮았다. 다만 scroll 메서드가 더 먼저 나왔기 때문에 실제로 사용된 코드도 많고 혹여나 버그등이 발생해 검색을 해야한다면 검색 결과도 많아 scroll을 사용하는것이 더 좋을 것이라고 판단했다.

또 단순히 메서드의 인자로 x-좌표와 y-좌표를 주는것 이외에도 options를 통해 top, left, behavior를 줄 수 있다는 것을 알았다. 특히 behavior: smooth를 사용해 애니메이션을 따로 만들지 않더라도 부드럽게 이동할 수 있는점이 유용해 꼭 기억하자 생각했다.

참고