heapq를 사용하여 풀면 간단하게 풀 수 있었다. scoville 배열을 heapq로 만들어주고 scoville배열의 맨 첫 번쨰 즉, 가장 작은 수가 K보다 작으면 계속 배열을 돌고 크거나 같다면 탈출하는 방식이다.이때 one에서 첫번째 0을 pop한 후 새로 he

문제 풀이 첫 번쨰 풀이 첫 번쨰 풀이는 생각보다 오래 걸리지 않았다. 우선 사전적으로 phone_book을 정렬해준 뒤 이중 for문을 돌며 모든 두 쌍을 비교하는 방법이다. 이떄 startswith함수를 사용하여 접두사가 겹치는지 확인하고 겹치면 False,

그래도 이번 문제는 크게 어려움은 없었다. 물론 15분 정도 걸렸지만...아이디어 자체는 어려움이 없었고 예외처리를 생각하지 못해 시간이 오래걸렸던 것 같다.풀이는 간단하다. 공백으로 문자열을 쪼개어 배열로 분할해주고 맨 앞이 숫자이면 전부 소문자로 배열에 추가한다.

오랜만에 코테 복귀를 하려니 꽤나 막막했다. 쉬워보이는 문제도 고민을 해야할 정도로 실력이 형편없다는 것을 느꼈다 흑흑. 문제를 다 읽고 나서 가장 먼저 든 생각은 문자열의 n번째 알파벳으로 정렬하기 위해서는 일단 앞으로 뺴내자였고 그 다음 '사전순'은 그냥 정렬하면

사용하지 않는 메서드에 의존하도록 코드를 강제해서는 안된다.이름에서 알 수 있듯이 인터페이스와 관련이 있으며, 기본적으로 함수와 클래스는 명시적으로 사용하는 인터페이스만 구현해야 한다는 뜻이다. 이는 인터페이스를 깔끔하게 유지하고 클래스가 여러 메서드를 포함하는 하나의

Hook/컴포넌트가 일부 props를 받아들이는 경우, 해당 훅/컴포넌트를 확장하는 모든 Hook과 컴포넌트는 확장하는 Hook/컴포넌트가 받아들이는 모든 props를 받아들여야 한다.위의 훅을 사용하면 useLocalAndRemoteStorage는 useLocalSt

개방/폐쇄 원칙(OCP - Open/Closed Principle) > 소프트웨어 엔티티(클래스, 모듈, 함수 등)는 확장에는 개방적이어야 하지만, 수정에는 폐쇄적이어야 한다. 즉 다시 건들지 않을 수 있도록 Hook과 컴포넌트를 작성하고, 다른 Hook과 컴포넌트에

우선 React Hook 작성에 앞서 Solid 원칙이 무엇인지 간단하게 알아보고 가도록 한다.SOLID원칙이란 객체 지향 설계에서 지켜줘야 할 5개의 소프트웨어 개발 원칙을 말한다.SRP(Single Responsibility Principle) - 단일 책임 원칙O

우선 제목과 같이 간단하게 CSR과 SSR에 대한 개념을 먼저 살펴보자.CSR의 동작과정을 살펴보자면 다음과 같다.1\. 유저가 웹 사이트에 방문하면, 브라우저가 서버에 콘텐츠를 요청한다.2\. 이에 서버는 빈 뼈대만 있는 HTML을 응답으로 보내준다.3\. 브라우저가

소개팅 웹 앱을 개발하던 도중 로그인 처리를 어떤 방식으로 해야할지 고민이었다. 다른 소개팅 앱의 레퍼런스를 확인하던 중 대부분의 서비스들이 핸드폰 번호를 사용한 SMS로그인 형식을 사용하고 있었다. 사용자가 번호를 입력하면 인증번호를 보내주어 이를 PW처럼 사용하는

한번 작성된 공통 컴포넌트나 스타일, 함수 등이 여러 페이지나 프로젝트에서 재사용 될 수 있는 능력을 의미.서비스의 기능, 화면에 새로운 요구사항을 반영하거나 수정을 쉽고 효율적으로 이루어지는 정도를 의미서비스가 지속적으로 성장하면서 자연스레 규모가 커진다.매번 새로운

프로젝트에 있어서 가장 중요한 것개발자의 임무 : 요구사항을 만족하는 소프트웨어를 개발하는 것요구사항은 여러 가지 이유로 프로젝트 수행 도중 변경될 수 있음요구사항 변경에 따라 세부 구현 사항, 때로는 전체 구조에 변경이 생기는 경우도 있음테스트 케이스의 작성은 요구사

MyList 베타서비스 배포 전 QA 및 피드백을 받아본 결과 공통적으로 나온 결론은 "신규 유저가 사용하기 어렵다!"였다. 분명 내가 만질 때는 쉬웠는데... 이러한 점이 배포된 서비스와 개인 포트폴리오와의 큰 차이점이 아닌가한다. 내 눈에 예쁘고, 편한데... 이게

플레이리스트의 방명록을 만드려면 이러한 UI의 방명록이 필요했다. 헤더를 고정할 필요는 없지만 사용자가 스크롤을 내리지않고 항상 댓글을 입력해야하므로, Footer는 항상 고정해야했다. 댓글이 보여지는 부분은 무한스크롤을 구현하여 처리하고 Footer는 항상 고정해야

프로젝트를 진행하며 alert창을 써야할 일이 많아졌다. 토큰이 없어 권한이 없다거나 삭제를 해야할때 경고창 등 사용해야할 경우가 늘어남에 따라 JS에서 지원하는 기본 alert창을 쓰기가 싫어졌다.너무나 투박하다. ㅠㅠ여기서 우리는 Sweetalert를 사용해보자.

GraphQL은 FaceBook에서 개발된 오픈소스 기술로 데이터 질의(Query + Schema)언어이다.클라이언트는 GraphQL 서버로 쿼리를 전송하고, 서버는 해당 쿼리를 해석하고 데이터를 반환한다.이 때, 클라이언트가 요청한 필드만 반환되므로 over fetc

프로젝트를 진행하면서 Youtube영상을 Embed로 띄워줘야하는 상황이 있어 YoutubeAPI를 사용하여 영상의 썸네일, 타이틀, ID값들을 가져와야했다.우선 프로젝트 선택에서 새로운 프로젝트를 생성해준다. 원하는 API들을 가져다 쓸 수 있다!나는 YouTube

1월은 정말 정신 없이 흘러갔다. 백엔드 개발과 DB 및 ERD생성은 처음 해보았기 때문에 강의를 따라가는데 많은 어려움이 있었다. 또한 개인적인 객기로 모두 typescript로 마이그레이션한 결과 더더욱 강의를 따라가기가 벅찼다. 그러나 JS문법을 기존에 알고있었고

프론트엔드 개발자로서 프로젝트 개발을 하면서 커뮤니케이션을 잘한다는 것이 무엇일까? ,디자이너와 어떻게 소통해야 상호이해가 잘 될수 있을까? 등에 관한 문제를 항상 고민하고 궁금했었다. 우연히 인프콘에서 이를 명확하게 설명해주는 송범근 개발자님의 컨퍼런스를 찾게되었고

React에서 State는 컴포넌트 안에서 관리된다. 자식 컴포넌트 간의 다이렉트 데이터 전달이 불가능한데, 이 떄 부모 컴포넌트를 통해 전달 받을 수 있다.자식 컴포넌트가 많아질수록 상태관리가 매우 복잡해지는데 이를 해결하기 위해 Redux 등의 상태관리 라이브러리들