오늘 한 일
- 프로그래머스
- 거스름돈 (Level 3)
- 실내 운동
문제 풀이
거스름돈 (Level 3)
입력된 금액을 제시된 동전만으로 돌려줄수 있는 방법의 가지수를 돌려주기
풀이 완료
낮은 값의 방법의 수를 바탕으로 높은 수의 방법의 수를 구한다는 것은 이번 문제를 보면서부터 생각 해온 방법중에 하나지만 그 방법을 바탕으로 문제를 풀이하는 방법을 고안하지는 못하였다.
그리고 질문하기에 언급된 방법을 바탕으로 언급된 방식으로의 풀이법을 구현할수 있었다. 그러니까
거스름돈이 5일때의 방법의 수는 (동전인 1, 2, 5일때) 거스름돈 4, 3, 0일때의 방법의 합이라는것이다. 얼핏 생각해서는 거스름돈이 3일때의 방법의 수로부터 나오는 값으로 인해 거스름돈 4일때의 방법의 수가 중복되어 예상이상의 결과가 나올것 으로 생각된다.
사실 이 이전에서 해당 방식으로의 방법을 진행하지 못한 이유중에 하나가 그것이다. 하지만 질문하기에서의 방법은 다음과 같다. (동일하게 1, 2, 5가 동전이고 5의 거스름돈으로 돌려줄때) 거스름돈 0 - 5까지의 배열(길이 6)을 구성하고, 거스름돈 0일때의 방법의수를 1로 정의한다.(거스름돈이 0일때의 방법은 1이다. 어떤것도 내지 않는 유일한방법)
동전 1 일때
하위단계에서 차례로 올라가면,
- 거스름돈 1일때의 방법의 수 0에 0일때의 방법의 수 1을 더해 1을 가진다.
- 2일때도 1,
- 3일때도 1
- 4일때도 1
- 5일때도 1이 된다.
거스름돈 2를 사용하는 경우를 생각하면,
- 거스름돈이 1일때는 사용할이유가 없고
- 2일때는 사용가능하므로 2일때의 방법의수 1 에 0일때의 방법의 수1을 2가 된다.
- 3일때는 3일때의 방법의 수에 1일때의 방법의 수 를 더하여 2
- 4일때는 4일때의 수 1 과 2일때의 수 2를 더하여 3이되고
- 5일때도 3이된다.
마지막 거스름돈 5일때의 경우,
- 거스름돈 5일때만 사용가능하며 방법의수는 4가 된다.
따라서 거스름돈이 5일때 만들수 잇는 총 방법의 수는 4가 된다. 이와같은 방식을 바탕으로 코드를 구현하면 이전에비해 깔끔하면서 모든 예문을 통과하는 풀이가 된다. 하지만 이는 질문하기의 방법을 통해 풀어낸 결과이기에 개인적으로는 스스로의 방식을 통해 풀어볼 기회를 따로 가져보아야 겠다.
프로그래머스 과제관
2021 카카오 신입공채 2차 온라인 테스트
풀스택 태그가 붙어있어 백엔드 프론트엔드 작업을 진행하는 그런 문제일거라 생각했다. 그리고 그건 내스스로의 편견이라고밖에 생각할수 없었다. 해당 문제는 주어진 API 문서를 바탕으로 문제를 푸는 그런 문제였다. 문제설면에 나타난것 처럼 전자 자전거 대여서비스에 관련된 대여되고 반납된 자전자의 수송을 통해 요청 거절되는 사용자의 요청을 최소화하는 문제이다.
하지만 문제풀이의 방향을 착각 했듯 전혀 방향성 다른 생각을 하고 있던 나는 해당 문제를 처음 접했을때 혼란에 빠졌다. API 문서만 주고 풀어라 하는 부분에서 내가 뭘해야하는거지 라는 생각에빠져 버렸다.
차근차근 문서를 읽어가면 겨우구현한건 요청을 하고 자료를 받고 모의실험을 하고 점수를 확인하는 그런 과정 뿐이었으며 실제적인 문제풀이에는 손을 대지 못하였다. 아니 혼란스러워서 조기종료를 진행하였다.
그리고 나서 차근차근 되집어보면서 생각을 조금이나마 정리할수 있었다. 하지만 접한 당시 1시간가량 소모하면서도 문제 풀이에 대한 방향을 잡지 못했던 나이기에 나머지 시간을 진행하였더라도 얼마나 할수 있엇을까라는 생각이 크다. 요컨데 문제를 제공하는 측에서 요구하는 것은 문제풀이가 기반이다라는 점에 더신경을 써야 겠다.
생각이 정리되었다 생각했는데 그냥 막아둔것만 같다. 아직도 혼란스러운지도 모르겠다. 이전의 프로그램 언어 검색의 경우 이상으로 충격을 받는 기회였던 것 같다. 시간 보다 문제 이해력자체가 부족하다는 것을 느끼는 경우였달까.
차근차근 생각을 정리하고 이러한 문제는 어떻게 접근해야할지 고민해봐야겠다.
길게 생각해볼것
코딩 문제 풀이 잘못된 폴더 선택 문제
- 커밋기록 유지한채로 폴더 옮기는 법 찾는 중
개인프로젝트
홈페이지 만들기
- 클라이언트와 연결된 서버 서버와 서버서버를 통괄하는 메인서버로 구성할 예정
- 서버스택은 node.js, express, typescript를 사용할 예정
- 데이터 베이스는 mysql 를 바탕으로 typeorm을 사용할 예정
- 배포는 aws를 사용 할 예정.(새로 생성한 계정을 이용)
- 제작 기간은 딱히 정하진 않음 - 생각하고 정리되면 그에 맞춰 행동할 예정
- 클라이언트 부분중 생각했엇던 기능:
- 홈페이지는 그동안 연습하거나 했던 것들을 담아둘 공간으로서 제작하려고 햇기에 해당 영역을 기능으로 구현해야한다. 이후 개별프로젝트나 새로운 언어 기능을 학습할때의 결과도 같이 올려둘 예정.
- 가능하다면 벨로그에 작성중인 블로그를 같이 게시할수 있었으면 한다. 해서 해당 부분을 고민해볼 것.
- 그 외 연습하고자 하는 기능들을 추가해볼 영역이 별도로 필요로 할듯하다.
- 클라이언트 외형(메인페이지)
- 상단에 얇은 바를 구성 위에 언급한 기능으로 가는 메뉴를 나열 시킴
- 사이드 페이지
- 메인페이지에서 구성된 바는 공통으로 나타나게하고 좌측에 사이드 바를 구성 별개의 세부 메뉴를 나타나게 구성함. (세부적인 크기 위치는 확정 되지 않음. )
pathfinder(미로 길찾기 게임)
- 기본적인 스택은 위 홈페이지와 유사할것으로 생각.
- 3개의 난이도 구분을 가정
- 미로 구성은 랜덤성을 포함함 예정
- 전장의 안개처럼 가지않은곳의 시야을 막아둘예정
- 움직이는 캐릭터의 성장은 갖게되는 무기의 성장으로 대변할 예정
- 피로도 개념 추가
- 회복약, 스테니머 회복은 하나의 아이템으로 전용
- 기타등등 정의되지 않은 생각이 있음.
프론트 엔드 구성
- 메인 페이지(로그인)
- 게스트 입장 가능
- 가입 방식 추가 고려(카카오톡, 구글, 네이버 등등...)
- 상단에 타이틀 하단에 로그인 모달 구성
- 배경은 울창한 숲 사이에 난 길을 배경으로 하고 싶지만 찾지못함.
- 난이도 선택 부터 나머지 페이지 우측에는 사이드 바 를 구성
- 난이도 선택 페이지
- 자동저장시 현재페이지가 메인페이지 바로 뒤에 오게됨
- 선택페이지를 3분할(A|B|C 형태로)하여 각각의 난이도로 정의
- 해당 난이도의 최근 결과 혹은 최고 결과를 보여줌
- 자동 저장 사용 시 진행중인 단계에 표시할 무언가를 생각할 것
- 자동저장 사용시 진행중인 이야기를 제거하고 새 이야기를 시작할수 있게 구성할 것
- 외부 맵 페이지
- 영역으로 구성된 맵을 보여주는 페이지
- 이지단계는 입구 1개 크기 3x3 을 생각하고 있음.
- 이후 단계의 규모는 5x5, 7x7을 가정하고 있다.
- 현재 위치로 지정된 sector의 경우 녹색 계열에 반짝이는 효과를 구현한다.
- 현재 위치로 지정된 sector와 연결된 구역은 구분가능한 계열의 색으로 칠한다.(색미정)
- 그외 지역중 방문한 영역은 회색 혹은 하얀색으로 미방문지역은 검은색으로 표현한다.
- 현재 위치로 지정된 sector와 연결되었지만 플레이어가 해당 통로에 방문하지 않은 경우를 표현하는 색을 정의해야한다.
- 내부 맵 페이지
- 실제 미로 영역
- 미로의 크기는 아직 미정
- 미로 구성은 랜덤성을 바탕으로 구성됨 영역간의 입구는 우선은 전부 연결되는 형태를 가정
- 움직이면서 몹과 싸우기도 하고 보물을 발견하기도 하는 형태로 구성예정.
- 움직이지 않은 영역은 보이지 않게 구성할 예정
- 피로도 시스템을 고려하려고 하지만 어떤 방식으로 할지는 생각중
- 우측 사이드 바
- 캐릭터의 장비 나 인벤토리 버튼 구성
- 기록을 열람할수 있는 통계 버튼 구성?
- 아직 세부적인 정리가 진행되지 않음
- 맵 상단의 작은 바
- 피로도를 보여줄 장소
- 세부적인 구성은 아직 생각 중
미로 생성, 미로 탐색
- 알고리즘을 직접 구현해서 사용하려하였으나. 시간이 오래걸리고 좋은 퀄리티가 나올 것같지않아 이미 많이 알려진 알고리즘에서 골라 사용하기로 결정
- 참조하기로한 미로 생성 알고리즘을 재현 완료. 제작 중인 코드에 적용 완료.
서버 구성
/Map
- /map/:level/ 형태의 path 로 고정
- 구분자 map의 위치를 수정
/Sector
- /sector/:level/:sid/ 형태의 path 로 고정
- 구분자 sector의 위치를 수정
/User
- api path만 구성중 사용 방식은 고민중
/Record
- api path만 구성중 사용 방식은 고민중
DB Entity 구성
Map
- id, level createdAt, updatedAt 을 칼럼으로 보유
- User 와 M:1 관계를 가짐
- User 와 Cascase 관계 설정
Maptile
- tid 를 칼럼으로 보유
- Map 와 M:1 관계를 가짐
- Sector 와 1:M 관계를 가짐
- Map 과 Cascase 관계 설정
Sector
- sid 를 칼럼으로 보유
- MapTile 와 M:1 관계를 가짐
- MapTile 과 Cascase 관계 설정
Save
- id, level, time, updatedAt 을 칼럼으로 보유
- Map 과 1:M 관계를 가짐
- User 와 Cascase 관계 설정
Tile
- id, pass, here, visit, invite, createdAt, updatedAt 을 칼럼으로 보유
- MapTile 과 Secter 에 상속 됨.
User
- id, username, password, email, createdAt, updatedAt 을 칼럼으로 보유
- Map, Save, Record 와 1:M 관계를 가짐
Record
- id, level, time, updatedAt 을 칼럼으로 보유
- User 와 M:1 관계를 가짐
오늘은...
과제관 시도
시도 실패 이전에 문제 이해 실패.
