api명세 기반으로 DB구상중.
일단 유저, 인증 부터 빠르게 채우는중
유저 가입, 로그인, 인증 완료
내일은
- mongo 타임존 한국 설정 (필요없음)
- 유저 엔티티에 프린터 기기id 컬럼 추가, 유저사진 추가 (완) 해야함.
-
프린트, 스캔 작업 구상(프린트는 프런트에서 할수있을거같은데)
-
클라우드 업로드 구상(굳이 바쁜데 mock말고 제대로 해야할까.. 싶긴 한데 빨리 해놓으면 편하긴할듯) (구현까지 완)
-
text to pdf 구상 (구현까지 완) -> 결국 업로드를 하긴 해야함.
-
한국어 text에서 문장분석 구상
(한국어 문장분석 패키지? or 번역해서 가져올때 문장분석까지?)
-
프런트랑 db설계 같이살펴봐야함.
업로드가, 프런트에서 날아오는 업로드는 유저프로필 사진 밖에 없을듯?
유저프로필사진 -> 프런트에서 날라옴 (구현 미룰듯? 발표에 필요없음)
스캔본 -> 앱손에서 url 날라옴 (아마도, api명세 봤을때는 그런데 교육에서는 다를수도) (스캔 api교육 받고나서 어떻게 구현할지 결정)
교육자료 -> 백에서 pdf만들어서 클라우드에 저장 (완료)
업로드 기능 버그) 해결 완료
업로드시 암호화 userId를 azure 컨테이너랑 디렉터리 이름으로 썼는데
특문, 대문자 때문에 다른걸로 해야함, 뭐로할지 고민중
-> 유저테이블에 uuid추가, uuid로 유저 개인 디렉터리 생성
- artist 정보 테이블
- 랜딩에서 메인에 띄울 artist 정보 + 최근편지 까지 서빙
기본적인 user 컨트롤러 작성중. 아티스트 정보 테이블 추가 완료.
팔로우 기능, 내 최애 등록 기능, 내 팔로우 리스트 가져오기 기능
추가해야함.
팔로우 CRD 구현 완료, 내 최애 등록기능이, 그냥 유저테이블에서 최애 업데이트만 하면 되긴 하는데,
고려할만한 case가 몇개 있다.
- 팔로우 안돼 있는 아티스트를 최애로? -> 팔로우 먼저 해야함
- 이미 최애면? -> 에러처리
아마 프런트에서 이 기능을 구현안할거같아서, 일단 보류하고 기억만 해둔다.
여기까지, 기본 유저관련, 팔로우, 아티스트 관련은 모두 완료.
이제 편지, 학습자료, 등등 관련 구현시작
근데.. 테스트는.. 한번 작성해야하긴 하는데 미친듯이 기능구현하느라 바쁜데..
테스트 작성 완, 오늘은 여기까지
스캔 결과 받아보는 테스트 위한 배포환경 구축,
test용 ec2 구축 완, 배포용 ecs는 계정만 일단 만들었음.
mongo, postgres 클라우드도 생성 완.
api작업은, 편지보내기 api작업 지금부터 시작.
편지보내고, 보낸편지, 받은편지 api 만들었음.
편지보내기에서 1차 db저장 완,
- 프린터에 스캔요청은 프린터 세팅 후 테스트
- 스캔데이터 받아온 후 처리하고 translate 모듈에 요청
- 학습자료 생성 컨트롤러 열고 translate모듈에 요청 후 저장, get api생성까지
일단 내일은 letter 엔티티 validation 그룹지정부터
letter validation 이랑 swagger 완료. letter CR api 완료
06.13 1,2,3 오늘하면 됨. 프린터가 언제될지 모르니까, 내부적으로 모킹 만들어서 traslate 모듈과 연결부터. 아.. 그전에 테스트 작성부터..
테스트 작성하다가 든 생각인데, 뭐 코드 수정, 추가해도 수정안해도 되는 테스트가 좋은 테스트
이런 말이 생각났는데, 너무 이상향 아닌가?
미래에 어떻게 요구사항이 바뀔지 모르는 상황을 예측해서 수정에 열린 견고한 테스트를 짜는 그런 얘기.
우아 nestjs crud에서 답변을 받았다.
READ_MANY가 제대로 안되서 질문했는데, 답변보고 해결헀다.
근데 벌써 손으로 다 작성해버렸다. 나중에 시간된다면 우아 crud로 바꿔보자.
letter 테스트까지 해서 메인에 올렸고,
06.13 1,2,3시작, jwt에 앱손디바이스 추가도 해야함, 디바이스 등록 api도 추가해야함.
스캔을 폐기해서, 파일업로드로 변경.
꽤나 견고한 업로드를 구축했음. 수동테스트를 많이했음.
이제 한국어 형태소 분석 해서 저장하는거를 sendLetter 메서드에 추가해야함.
그리고 나선 키워드 저장 만들면 됨. 키워드 받아서 ai한테 보내고,
만들어진 학습자료 받아서 이미 만들어진 pdf생성 코드로 학습자료 디자인.
일단 내일 제일먼저 할거는 리팩토링부터.
업로드 기능 리팩토링부터 시작
sendLetter 기능 변경해서, letter.service.spec.ts는 다시 작성해야함.
크게 눈에 밟히는 코드는 없어서 바로 키워드 저장, 학습자료 생성 구현 시작
다시, 스캔을 구현 시작. 체크포인트 생성
앱손 api에 문제가 있는걸로 완전히 파악 완료,
스캔은 그냥 폐기
lette 보내기 -> 업로드 -> OCR, 번역 -> 한국어 형태소 분석 -> DB저장 -> objId 리턴
까지 가 letter 보내기 flow.
-
확장자 허용 이미지 png, jpg, webp, jpeg + 문서 pdf 로 가능하게 해야함.
webp는 될지 모르겠는데, 네이버 ocr 공식문서 봐야할듯.
-
문장을 구분할때, 반드시 마침표로 구분으로 바꿀수있나?
왜? 한국어 형태소분석을 할때 마침표를 기준으로 분석을 함.
ex) "originText" : [
"Please, don't see just a boy caught up in dreams and fantasies.",
"Place · see me.",
"Reaching out for someone I can't see.",
"Take my hand let's see where we wake up tomorrow. Best laid plans sometimes are just a one night stand. I'll be damned.",
"Adam Levine - Lost Stars"
],
이건 영어 오리진을 오탈자 체크해서 나온 결과인데, 4번째 원소를 보면, 안에 문장이 세개로 나옴.
아마 ai가 문장이 짧다고 생각되면 여러문장을 하나로 합치는듯?
ai가 한 문장별로 분리할 때 마침표 라는 기준으로 분리 가능?
잘 안된다면 그냥 샘플 편지 작성할 때 문장들을 최대한 '문장의 구조' 를 지키게 해서 작성하면 됨.
- 리팩토링도 해야하는데.. 일단 키워드저장 -> 학습자료 구현부터 빨리한다.
아.. 프로덕션, 디벨롭 나눠서 uploadService를 nest가 서빙하게 해놨는데
dev에서 편지보내기를 테스트 할려면 클라우드 업로드가 필요하다???
왜냐면 OCR이 파일을 받을 수 있는 url을 요구하니까.
OCR이 버퍼를 받아준다면 프로덕션 디벨롭 철저히 나눠서
디벨롭에선 로컬 업로드하게 할 수 있는데... 그래서 임시방편으로 더럽게 짜놨다.
아오..
아니면 내가 translate에서 만든 배열 보고 length를 직접 수정을 해볼까
위 내용 만드는중, 추가로 더 생각한게,
일단 ocr, trans가 뱉는 오리진과 trans의 length도 맞지않는경우가 있음.
ocr, trans측에서도 ai에게 오리진과 trans의 각 원소의 문장이 똑같게(매칭되게) 해달라고 추가로 ai에게 요청해야하고,
그렇게 해서 나온걸 origin.length, trans.length로 체크해야함. -> 이부분은 한국어분석 쪽에서 에러로직 추가해놨음.
그리고 나서 한국어 형태소 분석에서도, 분석결과 리스트를 번역이 건네준 한국어 문장리스트의 각 문장과 똑같게 하는 로직을 추가해야함.
그러니까, 번역이 뱉어준 origin과 trans의 length도 같고, 각 원소의 문장도 매칭되지만, 만약 어떤 원소안에 마침표가 두번찍힌다면 한국어 분석기는 그 원소를 두개의 원소로 만들어버림. -> (분석결과 리스트를 번역이 건네준 한국어 문장리스트의 각 문장과 똑같게 하는 로직) 을 거치면, 한국어 분석기가 두개로 만들어버린 원소를 다시 하나로 합칠수가 있을듯.
그래야 정확도를 높일듯. 근데 그냥 문장구조를 잘 지킨 손편지를 번역ai, 한국어분석 ai가 제대로 결과 뱉어준다면, 지금은 그냥 방어로직 패스하고 다른거 개발하는게 좋을지도.
아직 손편지가 문장구조를 지켰을 때의 정확도를 테스트해보진 못했으니까.. (지금까지는 노래가사로 테스트했음)
어떤 방식으로 하든지, 최대한 에러를 안내기 위해서는 그냥 손편지가 문장구조를 적절히 지키고, 문장마다 마침표를 제대로 찍으면 된다.
암만 방어로직을 세운다고 하더라도, 문장구조가 개판이거나 마침표가 전무한걸 ai가 판별하기에는 무리가 있다.
애초에 그런 문장을 사람도 해석하기 어려우니까.
study CR 구현 완료,
아직 학습자료 ai 구현이 완벽하지 않지만 리턴타입이 정확히 결정나서
pdf생성을 리턴타입에 맞게 구현는거 시작.
이거까지 완성되면 서비스의 기본 요구사항은 전부 완료.
이후는 버그찾기, 리팩토링, 고도화 아니면 일단 ecs 배포부터.
- 내 최애 아티스트 등록 -> 완료
- 아티스트 정보 변경
- 내정보 변경 -> 프로필 이미지 업로드 구현 완, username변경? 굳이 필요한가?
- iframe 다운로드문제 -> 해결완료, 계속 문제면 크롬 다른사용자로 띄우거나, 엣지로 사용
- 학습자료생성 페이지 반으로 나누기 시도
- 업로드인풋 확장자는 jpeg, jpg, png, pdf로 한정 (프런트에 요청)
추가로 한것.
- 업로드 인터페이스 두개로 단순화, 파일 여러개 or 파일 한개.
- 업로드 수정 후 로컬 업로드, 클라우드 업로드 모두 수동테스트까지 완.
- artist를 user에서 분리해서 controll, service, repo 만들고 엔드포인트 swagger 작업 완.
20일에 못한거 마저 하고, 리팩토링 계속.
- letter에서 오리진, trans leng다르면 faild처리하고 폐기
- 번역과정 오류났으면 폐기하고 failed처리
어제는 아예 못해서, 21일 1, 2 마무리.
추가로
- destination 없애고 register 테스트
- letter service 리팩토링
프린트, 스캔방식에 대해
프린트
이미지 -> 파일 한개가 한장임
텍스트(문서) -> 파일하나에 여러장 프린트 가능
스캔
이미지 -> 스캐너 한번 돌릴때 마다 jpg 파일 하나 생성
텍스트(문서) -> 스캐너 한번 돌릴때 마다 pdf의 페이지로 들어가는듯?
위 가정이 맞다면, 프린트는 그냥 잘 작동할텐데
스캔으로 편지보내기 할때 유저가 텍스트로 해놓고 여러장 보내면 문제가 좀 생길듯.
ocr이 pdf여러장을 한꺼번에 처리해줄수 있긴 한데, 결국 앱손이 보내주는 파일은 한개고,
그렇게 letter document의 page 한개에 pdf 여러장의 분량이 들어가서 문제.
결론
스캔으로 편지보내기 할때, 여러장을 보내고 싶으면 이미지 모드로 해라.
근데 이미지 모드로 하면 일정용량 이상 넘어가서 앱손에서 제대로 못보내줌.
음... 일단 챌린지 동안은 무조건 한장씩만 업로드, 한장씩만 스캔으로.
한국어 분석 후 origin과 translate의 length 맞추는 걸 구현하려고
기본 로직을 짜놨는데, 지금 신뢰도가 높아서 일단 주석처리 해놨음.
ocr, trans에서의 length차이 나는지, 분석에서 차이 나는지 log 찍히게 해놨고,
분석에서 오류를 확인하면 바로 주석풀고 구현
-
학습자료 키워드를 3개 이상부터 doc.end가 호출해도, 콜백이 실행이 안됨. 뭐지? pdf.service.ts 에서 수정중 -> 완료
-
느낌표와 물음표도 다른 문장으로 바꿔야함. 지금 마침표만 다음문장으로 넘어가니까 물픔요 느낌표도 추가. -> 해결완
-
배포시에 클라이언트로 보낸 인증쿠키가 클라이언트 페이지에서 새로고침하면 날라가버림. auth.service.ts 에서 쿠키설정 수정중 -> 해결완