데구리 블로그

블로그를 관리하다 보면 좀 불편한 구석이 몇 개 있다. 물론 굉장히 잘 만들어진 스킨이라 제작자분에게 정말 감사하지만.. 카테고리별 글 수가 안 나오는 게 자꾸 눈에 걸렸다. 우측 상단의 카테고리 바를 누르면 이렇게 리스트로 나타난다. 1차 카테고리로 들어가면 그 카테고리에 직접 쓴 글과 하위 카테고리에 쓴 글을 모두 볼 수 있다. 근데 뭐랄까 좀 명확하지 않다. 블로그에 온 사람이 저런 카테고리를 보면 하위 카테고리로만 들어갈 것 같은 느낌? 상위 카테고리는 그저 분류만 해놓은 느낌?? 이게 항상 아쉬웠다. 실제로 방문 통계의 기타 유입을 확인해보면 하위 카테고리가 있는 카테고리 중 1차 카테고리로 접근한 페이지가 별로 없다. 이런 이유 때문에 카테고리별 글 수를 표시하기로 했다. 예전에 블로그 스킨을..

레포지토리 링크 github.com/degurii/fake-talk 요즘 몸이 별로 안 좋아 코딩을 많이 하진 못했다. 건강도 잘 챙겨야겠다. 1) User 객체를 직접 사용하는 대부분의 코드에 대해 User ID를 이용하도록 변경했다. 간단히 끝날 줄 알고 무작정 수정을 시작했는데, 중간중간 너무 헷갈려 컴포넌트 구조를 몇 번씩 확인하고 User가 어디서 사용되는지 메모장에 써가며 해결했다. 다음부터 이런 류의 수정은 더 체계적으로 시작해야 할 듯하다. 2) 시간 표시 기능을 조금 손봤다. 실제 카카오톡에선 채팅 중 시간이 바뀌면 타임스탬프가 한번 더 표시된다. 지금 내 코드에선 같은 유저가 연달아 채팅하는 경우 가장 마지막 톡에서만 타임스탬프를 표시하고 있다. ChatItem 컴포넌트에 first, ..

오늘은 메시지 수정, 삭제, 유저 이름 수정 기능을 구현했다. 1) 처음엔 수정할 chatItem의 id를 찾아 item.message만 변경해줬는데 수정된 내용이 렌더링 되지 않았다. 생각해보니 리액트가 state를 이전 상태와 비교할 때 객체는 변경되지 않고 안의 내용물만 변경되었으니 다시 렌더링 하지 않았던 상황이었다. 이를 새로운 객체로 대체해주어 해결했다. 2) 분명히 컴포넌트가 7개밖에 안 되는 작은 프로젝트인데도 state 관리하기가 너무 귀찮았다. 부모 컴포넌트에 2~3개의 자식 컴포넌트가 들어가고, 그 컴포넌트 안에서도 2~3개씩 자식 컴포넌트가 존재한다. 근데 자식 컴포넌트 사이에서 state를 공유해야 할 일이 생기니 공통 부모 컴포넌트마다 state가 생기고, 그에 따른 state ..

이번엔 git rebase를 성공했다!! 깃(Git) 리베이스 사용하기 - 스타트업 엔지니어링 이 글이 정말 많은 도움이 되었다. feature브랜치에서 디벨롭 브랜치와 rebase하고, 디벨롭에서 피쳐를 머지하니 성공적으로 커밋이 합쳐졌다. 설명을 보면서 느낀 점은, 아직 HEAD가 뭔지도 잘 모르고 있었다는 거다. 프로젝트가 끝나면 꼭 깃 북을 정독해야겠다는 생각이 들었다. 오늘 한 일 메시지가 처음인지, 끝인지를 판단해 아바타, 이름과 시간을 상황에 맞게 출력하도록 했다. 시간 설정 기능을 추가 채팅 입력창과 메시지 출력창을 mock up 데이터말고 실제 데이터를 사용하도록 변경했따 남은 일 메시지 수정, 삭제 기능 이미지 파일 업로드(채팅, 아바타) 자잘한 css 수정, css 안입힌거 구현 텍스..

이번 프로젝트부터 git flow와 칸반 보드를 적용하게 되었다. 칸반 보드는 여러 협업 툴이나 깃허브 자체에서도 지원해주는 프로젝트 관리 툴이다. 이런 식으로 issue를 통해 해야 할 일을 추가하고, 칸반 보드에서 진행 상황을 쉽게 관리할 수 있다. 각 이슈 번호에 대해 커밋을 날리니 어떤 일을 언제, 어떻게 한 건지 알아보기 편해서 좋다 ㅎㅎ git flow는 여러 브랜치를 나눠서 작업하는 전략인데, 나는 master, develop, feature만 사용할 예정이다. 음.. 처음이다 보니 실수로 feature 브랜치에서 바로 master 브랜치로 풀리퀘를 때려버렸다. 잠시 멍때리다 develop에다가 풀리퀘를 때렸다. 사실 뭔지도 모르고 일단 해본 거다.. 그랬더니 레포지토리에 revert-fea..