Grace's Tech Blog

2주차 때는 모든 팀원이 본격적으로 알람을 등록하는 주 기능을 구현하는데 집중했다. 알람 등록시에는 버튼을 통해 위 사진과 같은 순서로 약 등록이 진행되며, 여기에 약 이미지 인식 및 분류를 위한 딥러닝 모델이 탑재된다. 앞으로 보완해야 할 점이 참 많지만, 전체 프로세스를 모두 경험해보고 실제 모바일 앱 서비스에 탑재했다는 것 자체만으로 전반적인 개념과 더 필요한 것들은 무엇인지 정리할 수 있었던 귀중한 시간이었다. 데이터가 젤 중요!!!!!!!!!!!!!!!! 이 기능을 구현하기 위해 어떤 과정을 진행했는지에 대해 적어보고자 한다. 1. Data Download & Sampling 먼저 데이터 다운로드 및 샘플링 과정이다. 우선 알약 데이터가 필요하다. 이러한 데이터를 얻을 수 있을 것 같은 여러 공..

※ 모든 내용은 reference 옆에 첨부한 원본에 있습니다. reference1. 알약 자동 인식을 위한 딥러닝 모델간 비교 및 검증 1. 필요성 약사는 이렇게 회수된 수백 종류의 알약을 재분류하는 작업을 하고 있다. 재분류 작업은 약사가 육안으로 직접 확인하여 수작 업으로 이루어진다. 이는 약사들의 노동 손실뿐만 아 니라, 분류 과정에서 실수가 발생할 가능성도 높다. 최근에는 이와 같은 문제점을 해결하기 위해 영상 처리 기술을 통해 알약 분류를 자동화하기 위한 연구 들이 다수 보고되고 있다. 2. 접근 방법 본 논문에서는 별도의 영상처리 기술을 거치 지 않고, 검출과 분류를 동시에 수행하는데 특화된 딥러닝 모델을 사용하여 알약을 자동으로 검출 및 분류하고자 하였다. 또한 YOLO, Faster R-..

이번에 Full Stack 포지션을 맡게 되면서 Server와 Client의 작업을 동시 진행하였다. 프로젝트를 진행하면서 개발적인 역량을 키울 수 있었던 것도 정말 큰 성장이지만 무엇보다1. 필요한 기능이 무엇인지 정확하게 파악하고(문제 정의 능력),2. 그 기능을 구현하기 위해 정확하고 효율적인 질문/검색을 하고,3. 찾은 해답을 어떻게 내 상황에 맞게 적용하는 능력을 기를 수 있어서 정말 값진 시간이었다는 것이다. Milestone 기준 본격적인 기능구현 1주차에 Server와 Client side에서 한 일을 적어보고자 한다. 1. Server side로그인 완료 후 처음 앱에 들어가자마자 보이는 Home 페이지와 약올림 서비스의 핵심 페이지라 할 수 있는 Calendar 페이지에 필요한 API를..

직접 배포를 하기 전에 Heroku에 대해 간단한 사용방법을 공부하고 정리해두었었다. 그런데 역시나.. 직접 해보기 전까지는 절대 모른다 ㅎㅎㅎ HJ님이 도와주시지 않으셨다면 속이 터져 엉엉 울어버렸을 것이다. 서버 배포와 RDS 사용을 해본 것을 정리해보려 한다. 1. 준비 Heroku CLI설치 (Mac용) #터미널 brew install heroku/brew/heroku 코드상에서 배포환경으로 변경해주어야 할 것은 변경하기 예를 들어 app = create_app(os.getenv('BOILERPLATE_ENV') or 'prod') #'dev'를 'prod'로 2. 서버 배포 - Flask로 구현된 사이트를 Heroku를 통해 배포하기 위한 준비단계 ① 원래 사용하던 가상환경이나 아니면 배포만을 ..

딥러닝을 활용한 이미지 처리기능이 있는 앱 서비스를 개발하기로 하고, DB스키마와 API들을 구성하니 우리 팀이 flask로 구현해야할 데이터베이스 모델은 약 5-6개, API는 27개 이다.. 이렇게 많은 API를 만들어야하고 모델도 파일을 분리하여 구현해야겠다고 생각하니 데이터베이스 모델을 한 파일이 아닌 여러 파일에 나누어서 짜되 다른 migrate = Migrate(app, db)시에는 db에 모두 불러올 수 있도록 하는 것 최대한 mvc 폴더 구성을 따라보려고 한 것 을 목표로 두고 방법을 찾아보았다. 나는 일단 MVC 패턴을 최대한 구현하여 각 요청에 대한 응답까지 받아서 잘 작동하는지 확인하고 싶었다. 그래서 복잡한 우리 프로젝트 스키마 전에 계속 예시(14. Python ORM - Flas..

우리 프로젝트의 DB스키마는 위의 그림과 같다. (※ 현재 2020/12/13일, 프로젝트를 진행하면서 DB구조가 약간 수정되었다. 수정된 DB 스키마는 아래 를 클릭하면 볼 수 있다. ) 더보기 1. 각 테이블 설명 schedules_date: 각 알람 하나하나의 정보를 담고있는 테이블 scedules_common: 한 주기를 가지고 있는 알람 정보 테이블 users: 사용자 정보 테이블 (login 필드는 'social'이면 소셜회원가입을 한 것, 'basic'은 일반 회원가입으로 가입한 것을가 다 나타낸다.) medicines: 약 정보가 담긴 테이블 2. Relationship user 1 - schedule_date n (schedules_udate) user 1 - schedule_common..

이번 프로젝트 역시 프로젝트 진척도 관리, 이슈 관리, 코드 작업, 코드 리뷰 모두 Github을 통해 이루어진다. 그래서 전체적인 방식은 첫번째 프로젝트와 동일하며, 이에 Github 활용과 Gitflow에 대한 내용은 1. [Basic] 프로젝트 Intro, 첫 번째 미팅 2. [Basic] 프로젝트 준비 - 프로젝트 협업을 위한 Gitflow 에 정리해 둔 바 있다. 1. Project관리를 위한 Issue카드 생성 및 마일스톤 정하기 다만 이번에는 마일스톤을 더 촘촘하게 짜고, 최대한 마일스톤 마감기한을 맞출 것을 팀 내 약속으로 정하였다. 그리고 이번에 SH님께서 front, HI님께서 Back, HJ님과 내가 Full stack을 맡게 되면서 기능 구현량이 많은 이슈카드에는 assinee에 미..

프론트엔드와 백엔드가 소통하는 엔드포인트, RESTful API 꼭 정독해보자!!!! 아래는 약 4달전에 commonJS와 RESTful API에 대해 처음 배웠을 때 정리한 글이다. 21. Server & Node - CommonJS/RESTful API REST API를 쓴다고 정해놓고 RESTful 하게 디자인하는 것의 중요성을 많이 들어왔음에도 불구하고 솔직히 말하면 'RESTful'한게 대체 뭔지도 모르고 그냥 '써왔다.' 그러다가 어제 office hour시간에 아니나 다를까 API디자인에 대해 많은 피드백을 받았다. 우선 1. 한 API에 기능이 2개가 겹쳐있다는 것이었고 (예를 들어, 검색/삭제 기능이 순차적으로 이루어져야 할 때, 검색을 위한 API, 삭제를 위한 API로 나눈 것이 아니..

첫번째 프로젝트인 SAFU를 끝내면서 Final 프로젝트때에는 처음부터 이것들을 꼭 지켜봐야지 라고 생각하며 정리해 둔 글(아래 링크)이 있었다. 10. Final Project 때는... 이렇게 더 보충해 봐야지 그 중 첫 번째 프로젝트때 가장 손 가는 부분이 많았으며 커뮤니케이션이 가장 많이 이루어진 부분이 DB schema와 API이었고, 이 둘은 정말 프로젝트 진행 중에도 몇 번이나 수정된다는 것을 알고 있었기에 이번에는 처음부터 훨씬 더 꼼꼼하게 짜야겠다는 생각이 있었다. 이 글은 시기에 해당하는 주에 짠 DB schema, API 기획과 이후 피드백 및 프로젝트 진행 중 깨달은 점을 바탕으로 수정된 사항들을 포함하고 있다. 1. 기능 플로우 초기 기획된 기능 플로우는 를 클릭하면 볼 수 있다...

첫 번째 미팅을 마치면서 다시 한번 구현할 서비스(약올림)의 기능들을 정리하고, 필요한 기술 스택을 '명확한 이유'와 함께 선정하는 시간을 가졌다. 우선 기본적으로 1st Project에서 해본 것들을 제외하고 새롭게 구현해야할 것들과 이를 위해 필요한 것들은 - 어플 서비스임을 감안하여 배포, 컴파일 방법 공부 - 데이터 베이스 세팅 - 크롤링 - 의약품(영양제(건강 보조식품)도 있으면 좋지만 우선 의약품을 우선 하기로 함) 관련 정보 API - 알약 이미지를 통해 품명을 잘 예측 할 수 있도록 이미지 처리 기계학습 - 배포 - 모바일 하드웨어 접근(카메라, 알람, 위젯) - 지도 API 사용법 등이 있다. 그 후 정해진 기술 스택들은 아래와 같다. ※ 아직 학습 중인 우리들이라 각 기술들의 심오한 배..