
경화는 과수원에서 귤을 수확했습니다. 경화는 수확한 귤 중 'k'개를 골라 상자 하나에 담아 판매하려고 합니다. 그런데 수확한 귤의 크기가 일정하지 않아 보기에 좋지 않다고 생각한 경화는 귤을 크기별로 분류했을 때 서로 다른 종류의 수를 최소화하고 싶습니다.
예를 들어, 경화가 수확한 귤 8개의 크기가 [1, 3, 2, 5, 4, 5, 2, 3] 이라고 합시다. 경화가 귤 6개를 판매하고 싶다면, 크기가 1, 4인 귤을 제외한 여섯 개의 귤을 상자에 담으면, 귤의 크기의 종류가 2, 3, 5로 총 3가지가 되며 이때가 서로 다른 종류가 최소일 때입니다.
경화가 한 상자에 담으려는 귤의 개수 k와 귤의 크기를 담은 배열 tangerine이 매개변수로 주어집니다. 경화가 귤 k개를 고를 때 크기가 서로 다른 종류의 수의 최솟값을 return 하도록 solution 함수를 작성해주세요.
1 ≤ k ≤ tangerine의 길이 ≤ 100,000
1 ≤ tangerine의 원소 ≤ 10,000,000
function solution(k, tangerine) {
var answer = 0;
const Dict = {};
tangerine.forEach((t) => { Dict[t] = (Dict[t] || 0) + 1});
const Arr = Object.values(Dict).sort((a, b) => b - a);
for(const t of Arr){
answer++
if(k > t){
k -= t;
}else{
break;
}
}
return answer;
}
객체 dict를 사용해 배열의 중복 개수를 각각 세어 저장하고 중복된 개수에 따라 내림차순으로 정렬한다. 정렬된 값에서 개수를 더해서 k와 같거나 커지면 카운트해준 값을 반환한다.
git, github 사용이유 - 협업을 위해서
원본파일을 그대로두고 수정하고싶을때 - 복사
but, 큰 용량을 가진 프로젝트도 그렇게 할것인가? - 용량 문제때문에 쉽지 않음.
=> 전체가 아닌 원본의 바뀐부분만 보여줌. === 브랜치
☆ 브랜치를 생성한 곳이 브랜치의 원본이 되기 때문에 잘 확인하고 브랜치를 생성해야함.(ex) main 에서 브랜치를 생성하면 이후 merge를 하면 main에 합쳐짐. but, develop에서 생성한 브랜치를 merge한다고 main에 작업한 코드가 옮겨지지않음.)
git branch - 브랜치목록을 보여줌.
git branch 브랜치이름 - 브랜치이름을 가진 브랜치를 생성
git checkout 브랜치이름 / git switch 브랜치이름 - 해당 브랜치로 이동
git checkout -b 브랜치이름 / git switch -c 브랜치이름 - 브랜치를 생성하면서 바로 이동.
브랜치에서 원본으로 이동했을때 수정한 코드가 있는가? - x. 작업을 브랜치에서 진행한거지 해당 작업을 원본으로 옮겨주는 작업을 하지 않았기 때문에.
main에 합쳐야 하는 이유 - 보통 main은 모두가 공유하는 최종 브랜치. 프로젝트 작업 중 여러 브랜치를 만들어서 사용할 것 인데 해당 기능들을 합쳐서 최종적인 브랜치가 되야 할 것이므로.
local에서 main으로 바로 밀어넣을수 없게 보호해주는 것. => pull request를 활용해 밀어넣어야함.
github에서 pull request를 해주고 merge 하면 github 서버 자체에서는 업데이트 되서 올라가있지만 내 로컬환경에는 바로 업데이트되지않는다. - git pull 명령어 사용.
main 브랜치 === 보통 배포용
develop 브랜치 - 테스트용
기능 브랜치(login, gamestart등...) - 기능 개발용.
=> 기능 브랜치내용을 delvelop 브랜치에서 받아서 테스트를 하고 문제가 없으면 main브랜치로 보내서 배포. main = 라이브 환경. 바로 넣지않기.
당연히 이전에 작성한 부분에는 문제가 없을거라고 생각하고 packetParser와 loadProto부분이 문제가 있을것 같아 그쪽만 확인했었다.. 하지만
프로토 파일 자체에서는 typeName을 InitialPayload라고 만들어줫고, 그 값을 가져오는 packetNames에서는 typeName을 InitialPacket이라고 작성했었다....이러니까 당연히 정의되지않은 객체가 되지..좀 더 찾아보고 튜터님께 찾아갔어도 됬을텐데..
준비를 꼼꼼하게 잘 해온거 같다고 말씀하셨다.
살짝 모자른 부분이 있었는데,
- 연결 지향형 통신, 비연결형 통신이 무엇인가?
- IP의 한계에서 프로그램 구분 불가능이라는 한계가 존재한다고 했는데 그럼 프로그램 구분을 가능하게 해주는 것은 무엇인가?
- 혼란제어
- 로드 밸런싱의 개념.
위의 3개는 답변을 못했지만 로드 밸런싱개념에 대해서는 잘못알고있다고 하셨다. 해당 개념들은 내일 다시 정리해봐야겠다.