백엔드와 함께하는 첫 프로젝트 기획과 디자인 10월에는 백엔드와 함께하는 최종 프로젝트가 시작되는 달이었다. 백엔드와 소통을 한 번도 해보지 않아서 어떻게 소통을 해야 잘 할 수 있을까 개발 외적으로 고민을 했던 것 같다. 기획자와 디자이너 없이 프론트엔드와 백엔드가 해야해서 막막했다... 그래서 기획도 엎어지고 다시 하는 경험도 하면서 처음 하는 것이기에 당연하지만 쉽지 않았다. 기획과 디자인을 할 수 있는 경험을 가질 수 있다는 생각으로 긍정적으로 임했다. 거기에다가 프론트엔드 팀장을 맡아서 어깨가 좀 무거웠지만 팀의 분위기를 쳐지지 않고 증진시킬 수 있도록 노력을 했다. 다행히 팀원들과 지향점도 일치하고 잘 맞아서 힘들었지만 즐거웠다. 어떻게든 기획도 괜찮게 만들어진 것 같아서 여기서 기능도 기능이..
https://github.com/prgrms-fe-devcourse/FEDC4_Campers_Jaeho 9월은 팀 프로젝트를 하는 달이었다. 인생을 살면서 첫 프로젝트이기도 하고, 팀장도 처음으로 맡아서 하게 되었다. 개발 더 나아가 인생을 살면서 잊지 못하는 순간 중 하나라는 생각이 든다. 다사다난했던 한 달이었기 때문이다. 기술적인 측면보다는 경험적인 측면에서 회고를 해보려고 한다. 개발에 대한 회고 좋았던 점 초기 설정 (husky, prettier, eslint, lint-staged, commitlint, github) axios (auth) auth page 및 회원가입 컴포넌트 공통화, alert-dialog 창, tabs 창 context API (userInfo) 크게 위와 같이 나누어..
데브코스를 시작하고 2달이 흘러버렸다. 지금까지 주요했던 것들을 위주로 회고를 작성해보려 한다. 유효성 검사(validation) 과제 내용들 중 validation을 구현해보라는 내용이 있었다. 평소 코딩을 할 때 유효성 검증에 대한 생각은 한 번도 해본적이 없었고, 실제로 해본적도 없었다. 과제를 하면서 그리고 한 후 유효성 검증을 어떤 식으로 해야하는지 알아보는 좋은 기회가 되었다. 멘토님의 하신 말씀을 정리하여 짧게 정리하고 복기하려고 한다. 유효성 검사, 얼마나, 어떻게 해야하는 것인가? 완벽과 잘 하는 것 유효성 검사를 완벽하게 하면 너무 좋지만 그럴 수 없기에 현실과 타협해서 우선순위를 정하고 하나씩 해결하는 방식을 추구하자 즉 하나씩 잘 해결해나가면서 자연스럽게 완벽을 추구하는 그림을 그리..
새로운 시작 말로만 듣고 온라인으로 github repository를 참고하기만 했던 프론트엔드 데브코스가 시작되어 버렸다... 지금 이 글을 쓰고 있는 지금도 내가 이 과정에 참여하고 있다는 것이 믿겨지지가 않는다. 만남 3기 tooooo1님과의 만남 약 1년 전부터 github 상기로 혼자 알고만 있던 tooooo1님과 프론트엔드 데브코스에서 운영중인 디스코드에서 이야기를 할 수 있는 기회를 가지게 되었다. 마치 연예인을 보는 듯한 기분이랄까...? 이야기를 하다보니 같은 동네에 살게 된다는 것을 알게되었고, 시간은 새벽 1시였지만 만나게 되었다. 그동안 github상으로 궁금한 코드들도 많았고, 평상시에 어떻게 생각하시는지, 막힐 때 어떻게 대처하는지, 어떻게 삽질(?)을 하시는지 물어보고 직접 하..
지원동기 독학을 한다는 것은 쉬운 것이 아니었다. 내가 정한 이 길로 공부를 해야겠다라는 생각을 가지고 패기있게 시작하였으나 혼자서 하다보니 쓸데없는 생각이 많아지기도 하고, “이렇게 해야한다”, “저렇게 해야한다” 는 주변의 유혹도 뿌리치기 힘든 순간들이 많았다. 다시말해 공부를 해야하는 방향에 너무 많은 갈림길들이 내 머리속에 들어와 나를 헤집어놨다. 당연히 javascript에 대한 깊은 이해 없이 바로 어떤 사이트를 강의를 듣고 응용하여 만드려고 하니 막히는 순간이 많았다. 막히는 순간이 올때마다 나에 대한 신뢰가 점점 떨어지고, ‘이 길이 내 길이 아닌것인가?’ 라는 생각이 들어 자신감이 하락하는 와중에 엎친데 덮친격으로 맥북까지 망가져버렸었다. 기본기가 부족해서 그렇다는 것을 지금은 알지만 그..
적용하게 된 계기 Tistory 플랫폼을 이용하면서 markdown 문법을 이용하여 포스팅을 합니다. 하지만 뭔가 필자에겐 tistory 블로그에서 기존에 제공해주는 css가 부자연스럽고 가독성을 해친다는 생각이 들었습니다. 그리하여 수정을 해야겠다는 생각을 하였습니다. 직접 css 파일을 수정할 수 있지만 더 쉽고 간단하게 편하게 적용할 수 있는 방법이 뭐가 있을까 생각을 하였더니 github-markdown-css 프로젝트를 알게 되었습니다. github를 이용하는 필자에게도 매우 친숙한 css 스타일이기에 최종적으로 github-markdown-css 양식을 tistory 블로그에 적용하기로 마음을 먹었습니다. github-markdown-css GitHub 사이트 접속 github-markdown..
수동으로 적용하게 된 계기 포스팅을 하면서 github-markdown.css를 활용하여 작성을 해 오고, syntax highlight는 tistory에서 제공하는 플러그인을 활용하였습니다. 하지만 블로그 테마를 Book Club에서 #1으로 변경하니 syntax highlight의 첫 줄에서 공백이 일어나는 현상이 발생했습니다. 기술 블로그를 운영하는 입장에서 code highlight는 매우 중요한 요소이므로 자동으로 적용이 잘 되지 않는 이 현상을 수동으로 적용시켜 해결하고, 기본적으로 tistory에서 제공하는 것 외에 다양한 syntax highlight을 선택해 적용해야겠다고 생각하였습니다. highlight.js 설정 highlight.org 접속 highlight.org 공식사이트로 이동..
utterances를 적용하게 된 계기 이미지 출처: utterances 여러 개발자들의 기술 블로그들을 보니 댓글창이 저와 다르다는 것을 느꼈습니다. 타 플랫폼의 기술 블로그라면 그려려니 했지만 같은 티스토리 기반의 기술 블로그여도 기본 댓글창을 사용하는 것이 아닌 GitHub와 관련된 어떤 무언가를 쓰는 것 같다고 생각했습니다. 대다수의 기술 블로그 개발자분들이 utterances를 쓴다는 것을 알아냈습니다. 또한 이 utterances가 markdown 형식까지 지원한다고 하여 코멘트를 하더라도 markdown 형식으로 하면 틀에 억압되지 않고 좀 더 편하게 표현하며 소통할 수 있겠다고 생각하여 기존의 티스토리 기본 댓글을 비활성화하고 utterances을 적용하자는 생각을 했습니다. GitHub에..