0725
조 정하고 주제 정하던 날!
주제 선정은 중고거래+리셀 사이트 vs 부동산 실거래가 조회 사이트 중 하나로 선정하기로 했다.
둘 다 해보고싶던 기능이 많기때문에 고민되는 결정...
중고거래 + 리셀 사이트의 경우에는 크림 을 참고했다. 예전부터 스트릿 관련 의류 제품들에는 큰 관심이 있었고, 경제적 여유만 되었으면 신발이든 뭐든 더 사고싶은 만큼 흥미있는 주제였다. 중고거래 사이트와 리셀 사이트는 각각 있지만, 스트릿 제품들을 전문으로 하면서 두 기능을 다 가진 사이트는 없었기에 만들어보고 싶은 생각이 들었다. 그리고 세미 프로젝트 때 부터 게시판 관련 필터를 상세하게 만들어보고 싶었는데, 그런 기능을 마음껏 해볼 수 있는 주제라 생각한다. 그리고 인스타 형식으로 사진 게시판이 있는데, 되게 보기에 세련되고 해시태그를 이용한 필터를 만들 수 있어보여 관심이 간다.
장점은 교육 과정 내내 주로 만들어왔던 기능들이기에 좀 익숙하고 참고할 수 있는 사이트가 확실하다는 것이다. 그리고 대부분 게시판 관련 기능을 해봤기에 전체적인 사이트를 더 깔끔하고 세련되게 만들 수 있다. 물론 중요한 건 내부적인 기능과 코드지만, 일단 이쁘면 좋잖아? 라는 생각. 그리고 프로젝트 외부적으로도 교육과정을 슬슬 마무리하는 시점이고, 이력서니 포트폴리오니 작성하고 면접을 준비해야할 시기다 보니 취준과 병행하기 좀 더 쉽다?(후자와 비교해서) 라는 장점이 있다.
단점으로는 역시 굉장히 무난한 주제이고 기능이라는 점? 그래도 무난하다는 의미는 그만큼 많이 사용하고 필요하다는 의미여서 무조건 단점으로만 생각할 수는 없다.
두 번째 주제인 부동산 실거래가 조회 + 행복/임대주택 조회 사이트는 네이버 부동산 과 행복주택 을 참고했다. 내가 원래 하고싶었던 주제는 행복주택 정보 조회 사이트였다. 약 2018년부터 최근까지 LH, SH 등의 행복주택, 역세권 청년주택, 임대주택 등 다양한 청약을 신청하고, 지금도 행복주택에 살고 있는(><) 나는 항상 청약을 신청할 때 많은 불편함을 느꼈다. 대부분의 청약 공고문에서 주택의 주소는 공고문 PDF 안이나, 엑셀 파일로 첨부되어 올라온다. 그러면 청약자는 대략의 주소를 보고 자신이 원하는 위치의 주택을 찾기 위해 일일히 지도 앱을 통해 검색해야 한다. 이 과정이... 정말 정말 불편하다. 그러던 와중 김재민님이 올려주신 저 사이트를 사용해보고 굉장히 편리함을 느꼈고, 나도 만들어보고 싶었다. 마침 조장님도 부동산 실거래가 조회 사이트에 관심이 있으셔서 비슷한 지도 관련 사이트라 두 가지 기능을 다 가진 사이트를 한 가지의 주제로 삼았다.
장점은 흔하지 않은 주제와 기능이라는 것, 그리고 내가 확실하게 관심을 가진 주제이고 말할 수 있는 이야기거리가 많은 주제라는 것이다. 아직 API를 사용하는 경험이 없는데 이런 주제를 통해서 경험을 쌓을 수 있다.
단점은 아직 해보지 않은 기능이기에 시간이 얼마나 소요될 지 모른다는 점이다. 앞에서 적었듯 API를 사용해보지 않았고... 지도와 관련된 기능도 시도해본 적이 없어 어떤 어려움을 겪을지 예상하기가 힘들다. 그리고 팀원과의 분배가 어렵다는 점이 굉장히 크게 느껴졌다. 6인 1조로 진행하는 프로젝트에서 부동산 실거래가 조회, 행복주택 정보 조회 기능을 각각 1명씩 맡는다고 하면 다른 4명은 다른 기능들을 맡게 된다. 근데 이런 사이트 특성 상 주요 포커스는 지도와 관련된 기능들에게 갈 수 밖에 없고, 그러면 주요 기능을 맡은 두 명만 흥미있는 프로젝트가 될 수도 있겠다는 생각이 들었다. 그리고 실제로는 지도와 주택 정보만 열람하는 기능만 있으면 충분하지만, 프로젝트를 위해서 로그인 / 회원가입 기능, 게시판 기능 등 추가적으로 기능들을 추가해야 하는 점이 마음에 걸렸다. 그런 생각들을 하다보니 차라리 나중에 나 혼자 주택 정보를 가지고 있는 지도를 만들어보는게 낫겠다는 생각이 들어서 리셀 / 중고거래 사이트가 프로젝트에 적합하다고 생각했다.
조 이름도 정했다. 조원들 중 가장 어린 팀원분이 팀장을 하고 싶다고 하셔서 팀장으로 선정했고, 그 분이 가장 어리다보니 막내 ON TOP 이라는 조 이름을 정했다! 팀장님 화이팅!
0727
앞서 생각한 내용들을 토대로 내 생각을 팀원들에게 전달했고, 의견 교환을 통해 리셀 + 중고거래 사이트를 파이널 프로젝트의 주제로 선정했다. 오늘은 리셀 제품 거래 사이트인 크림을 토대로 주요 기능들을 대략적으로 선정했다. 크게 메인 페이지 / 마이 페이지 / 관리자 페이지 / 리셀 / 중고 거래 / 스타일 (리뷰) 로 구분했고, 추후에 더 상세하게 기능을 정하기로 했다. 오늘은 회의 시간이 그렇게 길지 않아 이 정도로 회의를 마무리하고, 중요한 사이트 이름을 정했다. 나도 멋지고 센스 있는 이름으로 후보를 내고 싶었지만.... 워낙 이런 이름 짓는 재능이 없어서.... 여러 개의 후보를 통해 ":LIM :IT" 으로 정했다! :L 와 :I이 각각의 표정처럼 보여서 너무 귀엽다. 인상깊은 후보에는 리중딱(리셀과 중고거래를 딱?)이 기억에 남는다... 임팩트 최강!
0728
AJAX 수업을 마무리하고 약간의 회의 시간을 가질 수 있었다. 어제 정했던 메인 기능들을 토대로 ERDCloud의 틀을 잡았다. 세미 프로젝트 때 했던 경험이 다들 있다보니 확실히 전체적인 시간이 적게 걸린다고 느껴졌다. 그래도 역시 의견이 많이 나왔던 지점은 리셀 기능이었다. 크림의 경우 다른 사이트와는 다르게 리셀 페이지가 독특하게 구성되어 있다. 마치 주식 사이트와 같이 구매자 / 판매자가 각각 구매 가격 / 판매 가격을 지정하여 상품을 등록하고, 해당 가격에 맞으면 거래가 이루어지는 시스템과 함께 해당 상품의 시세 그래프를 제공하고 있다. 그렇다보니 DB를 만들 때도 조금 다르게 생각하게 되는 부분들이 있었다. 시세 그래프 / 검색 자동 완성 / 1:1 채팅 / 포털 연계 로그인, 결제 기능이 우리가 배운 내용으로 구현할 수 있을지 궁금했는데, 검색 자동 완성과 1:1 채팅, 포털(카카오, 네이버 등) 결제 기능은 비교적 쉽게 구현할 수 있지만, 시세 그래프와 포털 연계 로그인 기능이 어렵다는 답변을 받았다. 오히려 포털 결제 기능이 어렵지 않을까 생각했는데, 로그인 기능이 더 어렵다고 해서 의외였다. 그리고 시세 그래프는 조금 어려울 수 있지만, 크림의 소스 코드를 참고하여 만들어보기로 했다. 과연... 할 수 있을까! 해보고싶다!!
0801
오늘은 ERD CLOUD를 완성하고 DB를 작성했다. ERD CLOUD를 조금 수정했고, 기반하여 DB를 작성했다. 확실히 세미 때는 오타도 많고, 외래 키나 서브쿼리를 고려하다 보니 DB 작성에 많은 시간이 걸렸었는데, 경험이 있다고 훨씬 적은 시간이 소요됐다. 물론 기능을 만들다 보면 수정할 일은 생기겠지만, 그 과정도 예전보다 익숙하게 처리할 수 있을 것 같다. DB를 작성하고 드디어.. 어떤 기능을 맡을 지를 정했다. 내가 가장 하고 싶던 기능은 스타일(리뷰) 기능, 그 다음으로 리셀 페이지, 중고 거래 페이지를 하고 싶었다. 세미 프로젝트 때 마이 페이지를 했기 때문에 비슷한 마이 페이지, 관리자 페이지를 제외하고 다른 기능을 겪어보고 싶었다. 그리고 사이트의 주요 기능이라는 점이 나에게 좀 더 책임감을 줄 것 같기도 했다. 팀원들이 각자 원하는 기능을 말하고 조율하는 과정을 거쳐서 내가 리셀 페이지를 맡기로 했다. 우리가 가장 많이 참고하는 페이지가 크림이다 보니 리셀 페이지를 더 잘 만들고 싶다는 생각이 든다. 물론 어렵겠지만.. 그래도 해내고 나면 훨씬 뿌듯하지 않을까!
+) 번외로 세미 프로젝트 때와는 다르게 파이널 프로젝트 기간과 겹치는 일들이 많아서 더 신경쓸 부분이 많다는 점은 힘든 것 같다. 크게 이력서 / 입사지원서를 작성해서 제출해야 하고, 서류제출 대상자로 당첨된 행복주택 서류를 작성해서 제출해야 하고, 또 다른 잡다한 일들도 몰려버렸다. 일단 중요한 일부터 처리하겠지만 가장 중요한 프로젝트와 여러 개가 겹치니 조금 힘든 부분도 있다. (ㅠㅠ) 그래도 실제 업무를 하면서도 이런 상황을 겪을 수 있으니 지금 정신 똑바로 차리고 하나하나 처리해보겠다!! (해야한다!!)
0802
약간의 DB 수정과 함께 카카오 오븐으로 전체적인 화면 구현을 했다. 크림을 참고하기로 했기 때문에 아예 제로 베이스에서 했던 세미 때보다는 훨씬 쉽게 진행했다. 근데 진행하며 느낀게 완벽하게 크림을 따라하기에는 내 HTML / CSS 실력이 부족할 수 있겠다고 느꼈다. 내일부터 전반적인 헤더와 푸터를 구현해 볼 생각인데, 일단 해보면서 내 실력에 맞게 적당히 맞춰야겠다.
중고 거래 페이지를 만드는 팀원분과 검색 필터와 관련해서 얘기를 했다. 기본적으로 리셀 페이지에서 상품을 등록할 때 사용하는 카테고리 / 브랜드들을 같이 사용하기로 했는데, 검색 필터에 브랜드별 / 카테고리별 / 컬렉션별로 나누는 과정이 있었다. 처음 나는 상품들의 이름에서 큰 컬렉션 분류 ( Jordan 1 Retro High OG Black Mocha이 제품명이라면 Jordan 1을 컬렉션으로)를 sql문에서 LIKE를 사용하여 검색하는 하드 코딩을 실행하고자 했다. 하지만 팀원분의 말을 들어보니 그러한 컬렉션의 수가 굉장히 많고, 일일히 하드 코딩을 진행하는 것 보다 테이블을 추가하여 검색 필터 기능을 만드는 것이 더 깔끔하겠다는 생각이 들어 테이블을 하나 추가했다!
내가 미처 생각하지 못했던 부분이 리셀 페이지를 내가 만들기 때문에 결제 기능까지 처리한다는 점이다. 이걸 어케 까먹지?? 바보다. 그래도 화면 구현하면서 다시 떠올리고 화면을 만들었고... 개인적인 목표는 신용/체크카드 결제, 네이버페이, 카카오페이, 토스 등 여러가지 API를 이용한 결제를 만드는 것이다. 그래도 강사님이 연계 로그인보다 연계 결제가 쉽다고 하셨으니 어떻게든 되지 않을까!
채팅 기능의 구현을 위한 웹 소켓 강의가 잠깐 있었다. 아주 간단한 강의긴 했지만 하나의 탭과 다른 시크릿 탭을 띄워둔 채로 메시지를 입력했을 때 다른 탭에서 새로고침없이 바로바로 출력되는게 굉장히 신기했다. 원래 우리도 1:1 채팅 기능을 넣을 수 있다면 넣고 싶었는데, 리셀 페이지에는 채팅 기능을 이용하지 않아서... 아쉽다. 뭔가 1:1 운영자 상담 채팅같은 기능을 언젠가 구현해보고 싶다.
0803
왜 DB는 매일매일 고쳐야 할 점이 새로 보일까? 어제는 보이지 않았던 고칠점들이 무수히 발견되어서 전반적으로 다시 DB를 수정해줬다. 그리고 오후에는 대망의 깃 작업을 했다. 팀장님이 전반적인 패키지 경로를 전부 설정하고, 각종 설정을 오후에 걸쳐서 거친 다음에 레퍼지토리를 등록했다. 그리고 역시나 문제가 우수수 발생했다. 일단은 복사한 레퍼지토리에 있어서는 안되는 WebContent가 있었고, gitignore에 입력한 명령어들이 제대로 적용되지 않았다. 서버에 프로젝트가 add가 되지 않는 것을 보면 복사해온 레퍼지토리를 프로젝트로 인식을 제대로 못하는 것으로 보인다. 하필이면 오류가 수업 끝나기 20분 전에 발생하는 바람에 다들 급하게 대처한다고 제대로 해결하지 못했다. 수업이 끝나고도 다같이 토론해봤지만, 명확한 해결법은 찾지 못하고 내일 여쭤보기로 했다. Dynamic Web Module이 4.0같은 택도 없는 버전으로 설정되는걸 보면 확실히 스프링 프로젝트로 인식을 하지 못하는 것 같다. 그래서 해결 그거 어떻게 하는건데 ㅠ
0804
오전에 평가를 보고, 어제 해결하지 못한 깃 문제를 해결하는 시간을 가졌다. 일단 gitignore 내용을 좀 삭제하고, 프로젝트를 제대로 인식하게 하는 과정을 거쳤다. 수동으로 프로젝트의 메이븐 업데이트를 해서 인식하게 한 뒤, setting의 project.facet의 dynamic web module의 버전을 2.5로 수정해주었다. 어제도 이 버전을 수동으로 수정하긴 했지만, 저장만하고 STS를 재실행하지 않았는데 이런 부분도 영향이 있었을 것 같다.
아 그리고 progress에서 어떤 과정이 진행되고 있는데 급한 마음에 서버를 삭제했다가 연결했다가 하는 바람에도 제대로 실행이 안 된 것 같다.
그래도 다행히 팀원 모두가 연결했는데, 커밋과 풀 오리진의 순서를 헷갈려 큰 일이 날 뻔 했다. 푸쉬 / 풀이 제대로 되는지 확인하려는 과정에서 기능을 만들던 팀원분이 커밋을 하지 않은 채 PULL을 해버린거다. 그 바람에 조금 만들었던 기능이 통으로 날라갔고.. 그래도 이런 사건덕에 무조건 커밋을 먼저 하고 PULL을 해야하는 중요성을 다같이 깨달았다. 나도 깃과 깃허브에 익숙치 않아 이런 문제가 발생할 수 있다. 항상 조심해야겠다. 오늘도 설정하는 과정이 길었다보니 제대로 된 시작은 하지 못했다. 내일부터 우선 게시판의 큰 틀을 잡고 더미데이터를 넣으면서 시작하려한다.
내가 개인적으로 쓰는 이 프로젝트 기록과는 별개로 간략한 회의록을 계속해서 다같이 작성하고 싶은데, 따로 노션이나 툴을 이용하는 것이 아니라 워드 파일로 작성하고 있다. 안그래도 JIRA를 사용해보면 좋다는 얘기를 들어 회의록부터 JIRA로 옮겨보고 싶은데 사용법이 익숙치 않아 좀 힘들다. 그래도 하나하나 조금씩 사용해보고 싶다. 세미 프로젝트때는 현재 본인이 어떤 기능을 구현하고 있는지 공유하는 노션 템플릿도 사용했는데, 도움이 되었던 기억이 있다. JIRA도 익숙해지면 그런 탬플릿의 역할도 할 수 있을거라 생각한다. 내가 잘 쓰냐 못 쓰냐의 문제겠지만. 여튼 해보자!!
0805
리셀 상품 게시판의 필터를 만들었다. 필터를 만들 때 하드코딩으로 일일히 다 작성할지, 혹은 DB에서 값을 가져와서 SHOP을 누를 때마다 가져올 지 고민하다가 일단은 DB에서 가져오게끔 했다. 브랜드와 컬렉션이 각각 수십개는 되었고, 그러다보니 DB에서 가져오는게 낫지않을까? 하는 생각이었다. 근데 갑자기 효율성에 대한 생각이 들었다. 하드코딩으로 진행하면 물론 처음 작성할 때는 일일히 넣는 수작업이 귀찮고 오래걸리겠지만, 오히려 유지보수는 DB에서 가져오나 하드코딩으로 작성하나 크게 차이가 없을 것 같았다. 그리고 DB에서 가져오는 방식이라면 게시판을 단순히 둘러볼 때마다 계속해서 게시글을 DB에서 조회해오면서도 필터까지 계속해서 조회하게 된다. 게시글은 다른 내용을 계속해서 조회하기라도 하지만 필터같은 경우는 어지간하면 바뀌지 않는 값인데 그 값을 계속계속 반복해서 조회하는 것이다. 그래서 궁금증이 생겨 팀원들과 잡담 겸 얘기를 해봤다.
"이러이러해서 DB에서 값들을 계속 가져오게 했는데 효율을 따지면 직접 넣기 / DB에서 가져오기 어떤 게 나을까요?" 하는 질문이었다.
의견은 약간 갈렸다. DB에서 가져오는 게 좋아보인다는 분들은 나중에 수정하거나 추가할 때 더 편할 것 같다는 의견이었고, 하드코딩의 경우에는 계속해서 조회하는게 좀 쓸모없고 서버에 좋지 않을 것 같다는 의견이었다. 두 가지 의견이 다 공감되어서 어느 쪽이 더 합리적인지 판단하기 어려웠다. (딱히 정답이 있는 결정은 아닌 것 같았다. 그저 차이가 있을 뿐) 근데 처음에는 DB로 조회한 나였지만, 막상 만들어보니 하드코딩이어도 수정할 때 크게 힘들지 않을 것 같아서 하드코딩이 더 나은 것 같았다. 필터 부분의 JSP를 따로 만들어서 INCLUDE했기 때문에 유지보수면에서도 크게 힘들지 않을 것 같았고..
마침 강사님이 오셔서 여쭤볼 수 있었고, 결론적으로 DB에서 조회하는 것이 아닌 하드코딩으로 작업하는 게 일반적이라는 얘기를 들었다. 우리가 생각했던 것 만큼 하드코딩이 수정이나 추가할 때 힘들지 않고, 굳이 DB에서 조회해올 이유가 없다고 하셨다.
이런 얘기를 들었지만, 일단은 필터를 계속해서 DB에서 조회해오기로 했다. 물론 효율을 따져서 작업을 할 수도 있지만, 이 프로젝트를 하면서 좀 더 많은 DB QUERY문을 다루는 경험을 해보고 싶어 그대로 남겨두기로 했다. 필터같은 경우는 단순히 한 컬럼만 조회하는 쿼리문인데, 각각의 필터들을 조회하는 컬럼을 어떻게 합치거나 하는 식으로 쿼리문의 효율을 더 좋게 만드는 과정을 고민해서 만들어보고 싶다. 강사님도 그런 부분의 고민도 좋지만 쿼리문의 개선에 대해서 고민해보라고 하셨다. 우리가 상상하는 것 이상으로 SELECT문을 많이 쓴다고 하는데, 얼마나 많이 쓰는걸까?? 근데 검색엔진들을 생각해보면... 어마어마할 것 같긴 하다.
0808
이메일 인증 관련 수업이 있어 프로젝트 코딩은 많이 하지 못했다. 게시판의 틀을 좀 잡고 DB좀 만지작거리고... 속도가 좀 안붙는다. 세미때도 프로필 사진이랑 관련해서 고생을 좀 했는데 이번에도 썸네일에다가 사진 게시글이 딱 보이니까 갑자기 몸이 멈춘다. (ㅋㅋㅋㅋㅋ ㅠㅠ) 해내고만다... 해내고만다... 저녁에 강사님과 동기들을 만나는 자리가 있어서 갈 예정! 저번에 가지 못해서 이번이 나는 처음이다. 죙일 비대면으로 수강해서 한 달도 안남은 이 시점에서 대면으로 만난다. ㅎㅎㅎ.. 내일부터는 속도를 좀 팍팍 내야겠다!! (그나저나 비 레전드)
회식 후기 : 레전드(현재 새벽 1시 45분)
0809
숙취가... 머리가...
리셀 리스트 조회 페이지 기능을 완성했다. 아직 css가 완벽하지는 않은데 그건 천천히 수정해도 되니까 나중에 하기로~ 이게.. 생각이상으로 더미데이터 넣는게 굉장히 귀찮다 ㅋㅋㅋㅋㅋㅋ 페이지 특성 상 리셀 상품 등록은 관리자 페이지에서 맡기로 해서 내가 일일히 sql로 넣어야하는데 컬럼 수가 워낙 많아서 굉장히 귀찮다. 그래도 뭐 어쩌겠어 하나씩 열심히 넣어야지.
0810
조회 리스트의 css를 팀원의 도움으로 약간 수정하고, 전반적인 더미데이터를 넣었다. 상품, 사진, 등록 상품 테이블을 각각 나누었기 때문에 넣을 데이터도 여러가지였다. 그리고 상세 페이지로 이동하는 기능까지 딱 하고 끝났다. 상세 페이지에서 보여줄 사진과 상품 정보 데이터들은 가져왔기 때문에 상세 페이지를 내일 만들고 정리하면 될 것 같다. 클릭했을 때 해당 상품의 번호로 상세 페이지로 이동하는 함수에서, 아이디로 선택하여 값을 받으려 했지만 안됐다. 왜 안되는지 긴가민가하고 있었는데, this의 존재를 잊고 있었다. 제이쿼리에서 this의 역할을 다시 좀 새겨야할 것 같다.
0811
상품 상세 페이지의 뷰를 만들었다. 크림은 세로 줄을 가운데 두고 왼편을 사진, 오른편에 상세 정보를 표시했다. 이 세로 줄을 ::before을 이용해서 만든걸로 봤는데, 어떻게 사용하는지 이해를 잘 못해서... 나는 왼쪽 오른쪽 div를 각각 만들고 왼쪽 div에 border-right를 줘서 세로 줄을 나타냈다. 크게 중요한 건 아니니까.. 그리고 해당 상품의 상세 사진들을 반복문을 이용해서 세로 정렬으로 불러왔다. 이 부분은 팀원분이 슬라이드 사진을 구현한 코드를 참조하면서 나중에 바꿀 생각이다. 상품 상세 페이지에서 해당 상품의 스타일도 4개정도 불러올 생각인데, 아직 스타일을 맡으신 팀원분이 db에 완벽하게 연결이 안됐다고 하셔서 미뤄뒀다. 그리고 구매 버튼을 누르면 해당 상품에 등록되어있는 매물들을 사이즈별로 보여주는 기능을 구현하려다가 선택자 지정이 뭔가 헷갈려서 끝냈다.
0812
구매 버튼에 클래스를 추가로 주고 그 클래스로 선택자를 지정했다. 그리고 넘어갈 때 상품 번호를 가져가고 싶어서 input:hidden으로 같이 넘겨주었다. 상품 번호로 해당 상품의 매물들을 가져왔다. 사이즈를 최소 오름차순 정렬해서 작은 단위부터 매물들을 전부 보여줬는데, 내가 원하는건 사이즈를 오름차순으로 정렬하면서, 해당 사이즈에서 가장 낮은 가격의 컬럼만 조회하는 거다. 그런데 내가 짠 select문으로는 해당 사이즈의 모든 매물이 튀어나왔고,,, 이걸 어떻게 하나 고민을 좀 하다 팀원들에게 물어봤다. 그리고 다른 팀원분이 쿼리문을 짜서 한 번 해보시라고 주셨는데 놀랍게도 됐다. 처음 생각으로는 '아,, 뭔가 가능할 거 같은데 내가 방법을 모르는 거 같은디,,' 이런 느낌으로 select문이 그렇게 길게 필요할 줄 몰랐는데, 팀원분이 짜주신 쿼리문을 보니 생각 이상으로 굉장히 긴 쿼리문이었다. 생각보다 어려웠다...
집이 침수된 팀원분이 돌아오셨다. 정말 고생... 최대한 열심히 도와드려야겠다. 일단 판매 등록 페이지는 순위를 좀 뒤로하고, 관심 등록 기능을 만들려 했다. 관심 등록 버튼을 누를 때 해당 유저 번호와 상품 번호를 둘 다 넘겨줘야하는데 어떻게 할까 고민하다가 끝났다... 근데 진짜 어케하지? 흠...
0813~0815
관심 등록 기능과 판매 등록 기능을 쳐냈다. 판매 등록 기능은 의외로 큰 품이 들어가지 않았다. 일단 임시로 사이즈 / 가격 모두 사용자가 입력하게 했는데, 상품 등록 시 사이즈들을 정하는 기능이 추가되면 판매 등록때 해당 제품의 사이즈만 주르륵 출력할 예정이다. 그리고 관심 등록 기능이 의외로 생각보다 복잡했다. 복잡한 이유는 관심 테이블과 프로덕트 테이블이 따로 있기 때문이었다. 관심 등록을 하게 되면 관심 테이블에 insert하지만, 리스트나 상세 페이지에서 보여주는 상품의 좋아요 수는 프로덕트 테이블에 있는 데이터를 보여줘야 했다. 그렇기 때문에 관심 등록할 때 sql문을 두 번, 또 취소할 때도 두 번 처리해야했다. 각각 처리한 값을 int로 받아 곱해서 0이상이면 성공했다고 보고 기능을 처리했다. 처음에는 테이블이 따로따로 있어서 순간 생각이 멈췄지만, 침착하게 생각해보니 그냥 따로 처리해버리면 되는 거였다! 역시 사람이 침착해야한다.
0816
오전에 시세 그래프를 만들었다. chart.js를 이용하여 ajax를 통한 통신으로 데이터를 가져왔다. 처음에는 이게... 무슨 소리지...? 싶은 심정으로 할 수 있을까 싶었지만, 따라 쓰고, 예전에 만들었던 ajax랑 비교해보고, chart.js 문서 조금 읽어보고 하다보니 이해가 조금은 되는 느낌이다. 그리고 의외로 그래프가 깔끔하고 쉽게 만들어져서 너무 좋았다. 뭔가 해낸 느낌~~~ 처음에는 최근 7일의 거래 내역을 조회해서 보여줬고, 버튼에 따라 7일, 한 달, 1년의 거래 내역을 조회하게끔 하려했다. sql문을 작성하는 건 크게 문제가 없었는데, 의외로 문제가 있었던 부분이 버튼을 누를 때 마다 그래프가 바뀌게끔 하는 기능이었다. chart.js는 빈 canvas를 만들고 ajax를 통해 그 canvas에 데이터를 넣는다. 처음 생각으로는 버튼을 누를 때 각각의 그래프를 실행하는 ajax를 연결하면 그래프가 딱 딱 바뀔줄 알았다. 근데 처음 캔버스를 채우고나서 다른 그래프 버튼을 눌러도 실행되지 않았다. 아마 캔버스의 값을 비워주고 다시 데이터를 넣어줘야 할 것 같았는데, 캔버스를 지우는게 아닌 값을 비우는 과정이 생각보다 까다로웠다. 그래서 어쩔 수 없이 remove로 아예 지운 뒤, append로 빈 캔버스를 추가하는 과정을 각각의 그래프를 부르기 전에 추가했다. 더 깔끔하게 할 수 있는 방법이 있을 것 같은데 생각이 안난다... 애매하게 될 것 같아서 더 아쉬웠다.
그리고 카카오페이 api를 이용할 차례가 왔다. 핵심 기능 중 하나인 구매 기능을 만들어야 해서 좀 찾아봤는데, 오... 뭔가 여태까지 처리했던 기능들과 느낌? 형식? 이 달라서 이해하기가 어려웠다. 그렇게 여러가지를 찾아다니던 중 유튜브에 전체적인 과정을 설명해주신 분이 계셔서 그걸 보고 좀 이해할 수 있었다. 일단 오늘은 전체적으로 따라하고 데이터를 내가 지정한 임의의 값으로 보내면서 결제 qr을 불러오는 것 까지는 성공했다. (qr나올 때 약간 감동받음 눈물흘림) 내일부터 해야할 기능은,
1. 구매하기 위해 선택한 제품들의 정보를 컨트롤러에 넘겨주기.
2. 구매 결정 버튼을 누르는 뷰 화면(주소 입력, 결제 방법 선택 등 주문 정보를 입력하는 화면) 만들기.
3. 그리고 결제 관련 정보를 저장하기 위한 DB 추가로 만들기.
4. 결제 시에 결제한 제품의 상태를 변경하고, 거래 내역에 해당 거래를 추가하는 등 여러 가지 SQL문을 작성하고 컨트롤러에 연결하기.
5. 그리고 혹시혹시 가능하다면 다른 결제 기능도 추가하기.
어우 구매 기능이 역시 할 일이 굉장히 많다. 아직 다른 기능도 해야할 일이 있기 때문에, 열심히 해야 프로젝트 마감을 깔끔하게 하고 발표를 할 수 있을 것 같다. 최근에는 강사님한테 질문을 적게 했는데, 내일부터는 좀 많이많이 하면서 팍팍 처리해야한다. 가보자고~
0817
어제는 qr만 출력했고, 오늘은 구매하려는 제품의 정보와 구매자의 정보를 입력받는 뷰를 만들었다. 그렇게 받은 정보를 통해 결제를 진행하고, 결제와 관련된 DB TABLE을 UPDATE하려고 했다. 카카오페이 결제가 크게 결제 준비 - 결제 승인 요청 - 결제 결과 정도로 크게 나눠지는데, 나는 이번에 결제 준비까지만 구현하려고 했었다. 근데 결제 준비 컨트롤러에 쿼리문을 수행하는 서비스를 연결시켜 놓으면, qr이 띄워지면서 결제 성공 결과와는 상관없이 DB에 갔다오면서 데이터들이 수정되게 된다. 일단 이렇게만 만들어두고 다른 기능들을 처리한 뒤에 추가할지... 아니면 무리해서 결제 승인 요청 - 결과 까지 구현해볼지가 고민이다. 네이버 페이의 경우도 잠깐 살펴보았는데, 카카오페이를 다루는 방법과 약간 달라서 네이버 페이는 아예 미뤄둘 예정이다. 고민이다 고민.. 고 민 고 민
0818
결국 결제는 qr 띄워주는 기능까지만 구현하면서 바로 db로 쿼리문을 보내기로 했다. 기능을 전부 다했으면 지금부터 노력해보겠는데, 아직은 할 일이 남아서.. 미뤄두려한다. 근데 같은 코드인데도 결제 qr이 떴다가 안떴다가 할 때가 있다. 팝업까지는 뜨는데 에러 코드 없이 빈 팝업인 경우가 있어서 이게 왜 그런가... 하고 강사님한테 쫄래쫄래 가져갔는데 갑자기 돼서 어이없었다. 지금 생각나는 가능성은 1. 내 인터넷 문제 2. 카카오 서버 문제 3. db로 가져가는 데이터 문제 이다.
3번의 경우가 내가 오라클에서 상품 데이터에 임의로 넣은 값과 페이지에서 상품 등록을 통해 입력한 데이터가 뭔가 다른 가능성이 있다고 생각이 들었다. 물론 자세히 어떻게 다른지는 모르겠다...
일단 지금은 되고있어서 내일 다시 확인해보려 한다. 그리고 상품 리스트에서 상품 번호 순 / 조회수 순 / 좋아요 순 / 판매량 순 / 발매일자 순으로 정렬하는 옵션을 만들었다. select태그의 값을 넘겨서 조건문으로 다른 쿼리문에 보내도록 만들었다. 아직은 더미 데이터가 적어서 겉으로 엄청 티나게 보이지는 않지만 정상적으로 작동하는 걸 확인했다. 내일은 상품 카테고리 / 브랜드 / 컬렉션 / 사이즈 별로 분류하는 필터를 만들어봐야겠다. 그리고 페이징 바 처리와 무한 스크롤 중에 하나를 정해서 페이지를 처리하겠다고 하고 까먹고 있었다.. 내일 카테고리 분류를 마치고 다시 고민해서 처리해야겠다. 이제 크게 남은 기능은 페이징 / 카테고리 분류 / 스타일 가져오기 이다.
주말안에 다 끝내봐야징~ 면접준비도 해야해~
0819
스타일을 담당하는 팀원분과 함께 스타일 가져오기 기능을 만들었다! 깔끔하게 잘 만들어져서 굉장히 만족됐다. 히히. 그리고 중고 거래 게시판을 담당한 팀원분의 도움을 받아 상품 카테고리 / 브랜드 / 컬렉션 별로 분류하는 필터도 만들 수 있었다. 내 생각보다 더 어려운 작업이어서 까다로웠다. 쿼리문이 굉장히 복잡했고, 내가 아직 매퍼 xml 파일에서 태그립 지시어를 사용하는 쿼리문을 작성하는 것에 익숙치 않는데, 이 쿼리문이 태그립 지시어를 굉장히 잘 사용한 쿼리문이라 도움이 많이 되었다.
0824
오늘은 학원 평가와 발표 준비가 있었다. 발표는 간단한 시연과 함께 외부 API를 사용한 부분들 위주로 진행할 예정이다. 대부분 비슷한 기능을 만들었기 때문에, 세미 프로젝트 발표 때도 갈수록 사람들의 집중력이 떨어지는 걸 느꼈다. 그래서 흥미를 가질만한 기능 위주로 간단히 발표할 예정이다. chart.js를 이용한 그래프 그리기와 카카오 페이 결제를 준비하고 요청하는 기능을 발표할 예정이다. DB를 다같이 통일하고 다시 스크립트를 만들어 데이터를 넣었는데 이 과정에서 CSS와 페이징 처리가 약간 깨지는 현상이 있어서 내일 마지막으로 수정하고 발표 내용을 작성하면... 진짜 마무리다.. 세상에!
