[ 백준 ] 2512 예산 - JavaScript
·
알고리즘
문제국가의 역할 중 하나는 여러 지방의 예산요청을 심사하여 국가의 예산을 분배하는 것이다. 국가예산의 총액은 미리 정해져 있어서 모든 예산요청을 배정해 주기는 어려울 수도 있다. 그래서 정해진 총액 이하에서 가능한 한 최대의 총 예산을 다음과 같은 방법으로 배정한다. 모든 요청이 배정될 수 있는 경우에는 요청한 금액을 그대로 배정한다.모든 요청이 배정될 수 없는 경우에는 특정한 정수 상한액을 계산하여 그 이상인 예산요청에는 모두 상한액을 배정한다. 상한액 이하의 예산요청에 대해서는 요청한 금액을 그대로 배정한다. 예를 들어, 전체 국가예산이 485이고 4개 지방의 예산요청이 각각 120, 110, 140, 150이라고 하자. 이 경우, 상한액을 127로 잡으면, 위의 요청들에 대해서 각각 120, 110..
[ 백준 ] 2961 도영이가 만든 맛있는 음식 - JavaScript
·
알고리즘
문제도영이는 짜파구리 요리사로 명성을 날렸었다. 이번에는 이전에 없었던 새로운 요리에 도전을 해보려고 한다. 지금 도영이의 앞에는 재료가 N개 있다. 도영이는 각 재료의 신맛 S와 쓴맛 B를 알고 있다. 여러 재료를 이용해서 요리할 때, 그 음식의 신맛은 사용한 재료의 신맛의 곱이고, 쓴맛은 합이다. 시거나 쓴 음식을 좋아하는 사람은 많지 않다. 도영이는 재료를 적절히 섞어서 요리의 신맛과 쓴맛의 차이를 작게 만들려고 한다. 또, 물을 요리라고 할 수는 없기 때문에, 재료는 적어도 하나 사용해야 한다. 재료의 신맛과 쓴맛이 주어졌을 때, 신맛과 쓴맛의 차이가 가장 작은 요리를 만드는 프로그램을 작성하시오. 입력첫째 줄에 재료의 개수 N(1 ≤ N ≤ 10)이 주어진다. 다음 N개 줄에는 그 재료의 신맛과..
[ 백준 ] 1260 DFS와 BFS - JavaScript
·
알고리즘
문제그래프를 DFS로 탐색한 결과와 BFS로 탐색한 결과를 출력하는 프로그램을 작성하시오. 단, 방문할 수 있는 정점이 여러 개인 경우에는 정점 번호가 작은 것을 먼저 방문하고, 더 이상 방문할 수 있는 점이 없는 경우 종료한다. 정점 번호는 1번부터 N번까지이다. 입력첫째 줄에 정점의 개수 N(1 ≤ N ≤ 1,000), 간선의 개수 M(1 ≤ M ≤ 10,000), 탐색을 시작할 정점의 번호 V가 주어진다. 다음 M개의 줄에는 간선이 연결하는 두 정점의 번호가 주어진다. 어떤 두 정점 사이에 여러 개의 간선이 있을 수 있다. 입력으로 주어지는 간선은 양방향이다.출력첫째 줄에 DFS를 수행한 결과를, 그 다음 줄에는 BFS를 수행한 결과를 출력한다. V부터 방문된 점을 순서대로 출력하면 된다. 입출력 ..
[ 프로그래머스 ] 단속카메라 - JavaScript
·
알고리즘
문제고속도로를 이동하는 모든 차량이 고속도로를 이용하면서 단속용 카메라를 한 번은 만나도록 카메라를 설치하려고 합니다.고속도로를 이동하는 차량의 경로 routes가 매개변수로 주어질 때, 모든 차량이 한 번은 단속용 카메라를 만나도록 하려면 최소 몇 대의 카메라를 설치해야 하는지를 return 하도록 solution 함수를 완성하세요. 제한사항차량의 대수는 1대 이상 10,000대 이하입니다.routes에는 차량의 이동 경로가 포함되어 있으며 routes[i][0]에는 i번째 차량이 고속도로에 진입한 지점, routes[i][1]에는 i번째 차량이 고속도로에서 나간 지점이 적혀 있습니다.차량의 진입/진출 지점에 카메라가 설치되어 있어도 카메라를 만난것으로 간주합니다.차량의 진입 지점, 진출 지점은 -30..
[ 백준 ] 11660 구간 합 구하기 5 - JavaScript
·
알고리즘
문제N×N개의 수가 N×N 크기의 표에 채워져 있다. (x1, y1)부터 (x2, y2)까지 합을 구하는 프로그램을 작성하시오. (x, y)는 x행 y열을 의미한다. 예를 들어, N = 4이고, 표가 아래와 같이 채워져 있는 경우를 살펴보자.1234234534564567여기서 (2, 2)부터 (3, 4)까지 합을 구하면 3+4+5+4+5+6 = 27이고, (4, 4)부터 (4, 4)까지 합을 구하면 7이다. 표에 채워져 있는 수와 합을 구하는 연산이 주어졌을 때, 이를 처리하는 프로그램을 작성하시오. 입력첫째 줄에 표의 크기 N과 합을 구해야 하는 횟수 M이 주어진다. (1 ≤ N ≤ 1024, 1 ≤ M ≤ 100,000) 둘째 줄부터 N개의 줄에는 표에 채워져 있는 수가 1행부터 차례대로 주어진다. ..
[ COCOMU ] 왜 이제서야 Storybook을 도입했냐고요?
·
COCOMU
MVP 개발 당시, 저희 팀은 컴포넌트를 구현할 때 임시 페이지를 하나 비워두고 해당 컴포넌트를 렌더링한 화면을 보며 작업했습니다.또한 각 기능이 잘 동작하는지 확인하려면, props를 직접 수정해가며 상태를 하나씩 확인해야 했습니다. 하지만 이런 과정을 매번 반복하는 건 매우 번거로웠고, 자연스럽게 이런 생각이 들었습니다.“컴포넌트를 따로 떼서 테스트하고 문서화할 수 있으면 좋지 않을까?”“다른 팀원에게 보여줄 때도, 상태별로 정리된 화면이 있으면 편할 텐데…” 그러다 다시 떠오른 도구, Storybook사실 Storybook은 전부터 알고 있던 도구였습니다. 하지만 당시에는 MVP 개발 제한 기간이 짧았고, 기능 구현 속도가 최우선이었죠. 저희는 프로젝트의 요구사항과 우선순위에 따라 테스트 코드는 작..
[ COCOMU ] 코드 스플리팅으로 사용자 경험 살리기
·
COCOMU
왜 코드 스플리팅이 필요했을까?cocomu는 React 기반의 SPA(Single Page Application)로 개발되었습니다.SPA는 페이지 전환 시 새로고침 없이 콘텐츠를 렌더링할 수 있다는 장점이 있지만, 그만큼 초기 진입 시점에 필요한 모든 JavaScript 파일을 한 번에 불러오는 구조적인 특성을 가지고 있습니다. 이 구조는 프로젝트가 작을 땐 문제가 되지 않지만, 페이지 수가 많아지고 컴포넌트가 복잡해질수록 초기 번들 크기가 비대해지며, 첫 화면 렌더링 속도에 직접적인 영향을 주기 시작합니다.특히 모든 페이지와 컴포넌트를 import로 정적으로 불러오는 경우, 사용자가 방문하지도 않은 페이지의 코드까지 함께 로드되기 때문에, 초기 로딩 시간이 길어지고 사용자 경험이 저하되는 문제가 발생했..
[ COCOMU ] 컴포넌트 재사용성과 확장성, Atomic Design으로 해결하기
·
COCOMU
Atomic Design을 도입하기 전, 우리가 겪었던 문제들cocomu 프로젝트 이전, 저희 팀은 작은 규모의 프로젝트를 진행하면서 컴포넌트 설계에 대한 기준 부족으로 인해 여러 가지 문제를 겪었습니다. 디자인 시스템이나 명확한 UI 설계 기준도 없이, 개발자마다 개인적인 기준에 따라 컴포넌트를 나누고 작성하는 방식으로 진행되었습니다.1. 명확한 컴포넌트 설계 기준의 부재컴포넌트를 어떻게 나눌 것인지에 대한 팀 내 공통된 기준이 없었습니다.각자가 생각하는 ‘재사용 가능한 단위’, ‘하나의 책임’, ‘역할에 따른 분리’ 등의 해석이 모두 달랐기 때문에 다음과 같은 문제가 반복적으로 발생했습니다:관심사가 여러 개 섞여 있는 복잡한 컴포넌트유연하지 않은 컴포넌트 구조로 인해 재사용이 어려움상황에 따라 구현 ..
[ COCOMU ] 웹 폰트 최적화, 작지만 체감되는 속도 개선
·
COCOMU
왜 웹폰트 최적화를 해야 했을까?SPA(Single Page Application)는 새로고침 없이 자바스크립트로 콘텐츠를 동적으로 로드하는 구조이기 때문에, 초기 진입 시점에 많은 리소스를 한 번에 불러오는 경향이 있습니다. 이는 초기 로딩 속도에 병목이 생기기 쉬운 구조입니다. 특히 웹폰트는 사용자에게는 보이지 않지만, 렌더링 지연의 주요 원인 중 하나입니다. 웹폰트가 늦게 로드되면 텍스트가 기본 폰트로 먼저 렌더링됐다가 나중에 바뀌는 FOUT(Flash of Unstyled Text) 현상이 발생하거나, 텍스트 자체가 아예 보이지 않다가 늦게 표시되는 FOIT(Flash of Invisible Text) 현상으로 이어질 수 있습니다.이러한 현상은 사용자에게 페이지가 느리게 뜨거나 덜 완성된 느낌을 ..
[ COCOMU ] Styled-components vs Emotion vs Tailwind, 우리의 스타일 전쟁기
·
COCOMU
프로젝트를 시작할 때, 팀 내에서 가장 뜨거운 논쟁 중 하나는 "스타일링은 무엇으로 할 것인가?"였습니다. 선택지는 Styled-components, Emotion, 그리고 Tailwind CSS 세가지 였습니다 실제로 프로젝트 초기 기술 스택을 결정할 때, 사진에서 보이는 것처럼 디스코드 채널을 통해 가장 많은 비교가 이루어졌습니다. 그렇기에, 다시 한 번 각 기술의 장단점을 정리해보고, 저희가 어떤 고민과 과정을 거쳐 최종적으로 Emotion을 선택하게 되었는지를 공유해보고자 합니다.  각 기술의 장단점 비교해보기Styled-components장점컴포넌트 단위로 스타일을 정의할 수 있어, React와의 결합도가 높고 코드 구조가 직관적입니다.CSS-in-JS 방식이라 JavaScript 변수, 로직과..