🍀 TCP/IP 4계층 모델 1. 계층 구조 TCP/IP 계층은 애플리케이션 계층, 전송 계층, 인터넷 계층, 링크 계층을 가지고 있다. TCP/IP 계층과 달리 OSI 계층은 애플리케이션 계층을 세 개로 쪼개고 링크 계층을 데이터 링크 계층, 물리 계층으로 나눠서 표현하고 인터넷 계층을 네트워크 계층으로 부른다. 이 계층들은 특정 계층이 변경되었을 때 다른 계층이 영향을 받지 않는다. 애플리케이션 계층 애플리케이션(application) 계층은 FTP, HTTP, SSH, SMTP, DNS 등 응용 프로그램이 사용되는 프로토콜 계층이며 웹 서비스, 이메일 등 서비스를 실질적으로 사람들에게 제공하는 층이다. FTP : 장치와 장치 간의 파일을 전송하는 데 사용되는 표준 통신 프로토콜 SSH : 보안되지 않은 네트워크에서 네트워크 서비스를 안전하게 운영하기 위한 암호화 네트워크 프로토콜 HTTP : World Wide Web을 위한 데이터 통신의 기초이자 웹 사이트를 이요하는 데 쓰는 프로토콜 SMTP : 전자 메일 전송을 위한 인터넷 표준 통신 프로토콜 DNS : 도메인 이름과 IP 주소를 매핑해주는 서버 전송 계층 전송(transport) 계층은 송신자와 수신자를 연결하는 통신 서비스를 제공하며 연결 지향 데이터 스트림 지원, 신뢰성, 흐름 제어를 제공할 수 있으며 애플리케이션과 인터넷 계층 사이의 데이터가 전달될 때 중계 역할을 한다. TCP와 UDP가 있다. TCP 패킷 사이의 순서를 보장하고 연결 지향 프로토콜을 사용해 연결을 하여 신뢰성을 구축해서 수신 여부를 확인하며 '가상회선 패킷 교환 방식'을 사용한다. 가상회선 패킷 교환 방식 : 각 패킷에는 가상회선 식별자가 포함되며 모든 패킷을 전송하면 가상회선이 해제되고 패킷들은 전송된 '순서대로' 도착하는 방식이다. UDP 순서를 보장하지 않고 수신 여부를 확인하지 않으며 단순히 데이터만 주는 '데이터그램 패킷 교환 방식'을 사용한다. 데이터그램 패킷 교환 방식 : 패킷이 독립적으로 이동하며 최적의 경…

🍀 네트워크의 기초 네트워크란 노드와 링크가 서로 연결되어 있으며 리소스를 공유하는 집합을 의미한다. 여기서 노드란 서버, 라우터, 스위치 등 네트워크 장치를 의미하며 링크는 유무선을 의미한다. 1. 처리량과 지연 시간 좋은 네트워크란 많은 처리량을 처리할 수 있으며 지연 시간이 짧고 장애 빈도가 적으며 좋은 보안을 갖춘 네트워크를 말한다. 처리량 처리량(throughput)이란 링크를 통해 전달되는 단위 시간당 데이터양을 말한다. 단위로는 bps(bits per second)를 쓴다. 처리량은 사용자들이 많이 접속할 때마다 커지는 트래픽, 네트워크 장치 간의 대역폭, 네트워크 중간에 발생하는 에러, 장치의 하드웨어 스펙에 영향을 받는다. 대역폭 : 주어진 시간 동안 네트워크 연결을 통해 흐를 수 있는 최대 비트 수 지연 시간 지연 시간(latency)이란 요청이 처리되는 시간을 말하며 어떤 메시지가 두 장치 사이를 왕복하는 데 걸린 시간을 말한다. 지연 시간은 매체 타입(무선, 유선), 패킷 크기, 라우터의 패킷 처리 시간에 영향을 받는다. 2. 네트워크 토폴로지와 병목 현상 네트워크 토폴로지 네트워크 토폴로지(network topology)는 노드와 링크가 어떻게 배치되어 있는지에 대한 방식이자 연결 형태를 의미한다. 트리 토폴로지 트리(tree) 토폴로지는 계층형 토폴로지라고 하며 트리 형태로 배치한 네트워크 구성을 말한다. 노드의 추가, 삭제가 쉬우며 특정 노드에 트래픽이 집중될 때 하위 노드에 영향을 끼칠 수 있다. 버스 토폴로지 버스(bus) 토폴로지는 중앙 통신 회선 하나에 여러 개의 노드가 연결되어 공유하는 네트워크 구성을 말하며 근거리 통신망(LAN)에 사용한다. 설치 비용이 적고 신뢰성이 우수하며 중앙 통신 회선에 노드를 추가하거나 삭제하기 쉽다. 그러나 스푸핑이 가능하다. 스푸핑은 LAN 상에서 송신부의 패킷을 송신과 관련 없는 다른 호스트에 가지 않도록 하는 스위칭 기능을 마비시커가 속여서 특정 노드에 해당 패킷이 오도록 처리하는 것을 …

🍀 프로그래밍 패러다임 프로그래밍 패러다임(programming paradigm)은 프로그래머에게 프로그래밍의 관점을 갖게 해주는 역할을 하는 개발 방법론이다. 프로그래밍 패러다임은 크게 선언형, 명령형으로 나누며, 선언형은 함수형이라는 하위 집합을 갖는다. 또한, 명령형은 다시 객체지향, 절차지향으로 나뉜다. 1. 선언형과 함수형 프로그래밍 선언형 프로그래밍(declarative programming)이란 '무엇을' 풀어내는가에 집중하는 패러다임이다. 함수형 프로그래밍(functional programming)은 선언형 패러다임의 일종이다. 함수형 프로그래밍은 작은 순수 함수들을 블록처럼 쌓아 로직을 구현하고 고차함수를 통해 재사용성을 높인 프로그래밍 패러다임이다. 자바스크립트는 단순하고 유연한 언어이며, 함수가 일급 객체이기 때문에 객체지향 프로그래밍보다는 함수형 프로그래밍 방식이 선호된다. 순수 함수 출력이 입력에만 의존하는 것을 의미한다. 고차 함수 고차 함수란 함수가 함수를 값처럼 매개변수로 받아 로직을 생성할 수 있는 것을 말한다. 일급 객체 이때 고차 함수를 쓰기 위해서 해당 언어가 일급 객체라는 특징을 가져야 한다. 변수나 메서드에 함수를 할당할 수 있다. 함수 안에 함수를 매개변수로 담을 수 있다. 함수가 함수를 반환할 수 있다. 2. 객체지향 프로그래밍 객체지향 프로그래밍(OOP, Object-Oriented Programming)은 객체들의 집합으로 프로그램의 상호 작용을 표현하며 데이터를 객체로 취급하여 객체 내부에 선언된 메서드를 활용하는 방식을 말한다. 설계에 많은 시간이 소요되며 처리 속도가 상대적으로 느리다. 객체지향 프로그래밍의 특징 1. 추상화 추상화(abstraction)란 복잡한 시스템으로부터 핵심적인 개념 또는 기능을 간추려내는 것을 의미한다. 사용하는 사람이 필요하지 않은 메서드 등을 노출시키지 않고, 단순한 이름으로 정의하고 코드가 복잡하지 않게 만들고 단순화된 사용으로 변화에 대한 영향을 최소화한다. 2. 캡슐화 캡…

🍀 디자인 패턴 디자인 패턴이란 프로그램을 설계할 때 발생했던 문제점들을 객체 간의 상호 관계 등을 이용하여 해결할 수 있도록 하나의 '규약' 형태로 만들어 놓은 것을 의미한다. 1. 싱글톤 패턴 싱글톤 패턴(singleton pattern)은 하나의 클래스에 오직 하나의 인스턴스만 가지는 패턴이다. 보통 데이터베이스 연결 모듈에 많이 사용한다. 장점 : 인스턴스를 생성할 때 드는 비용이 줄어든다. 단점 : 의존성이 높아진다. 자바스크립트의 싱글톤 패턴 싱글톤 패턴의 단점 싱글톤 패턴은 TDD(Test Driven Development)를 할 때 걸림돌이 된다. TDD를 할 때 단위 테스트를 주로 하는데, 단위 테스트는 테스트가 서로 독립적이어야 하며 테스트를 어떤 순서로든 실행가능해야 한다. 하지만 싱글톤 패턴은 미리 생성된 하나의 인스턴스를 기반으로 구현하는 패턴이기 때문에, 테스트마다 독립적인 인스턴스를 만드는 것은 어렵다. 의존성 주입 싱글톤 패턴은 사용하기 쉽고 굉장히 실용적이지만, 모듈 간의 결합을 강하게 만든다는 단점이 있다. 이때 의존성 주입(DI, Dependency Injection)을 통해 결합을 조금 더 느슨하게 만들 수 있다. 의존성이란 종속성이라고도 하며 A가 B에 의존성이 있다는 것은 B의 변경 사항에 대해 A 또한 변해야 한다는 것을 의미한다. 메인 모듈이 직접 다른 하위 모듈에 대한 의존성을 주기보다, 중간에 의존성 주입자가 이 부분을 가로채 메인 모듈이 간접적으로 의존성을 주입하는 방식을 말한다. 이를 통해 메인 모듈은 하위 모듈에 대한 의존성이 떨어진다. 이를 '디커플링 된다'고도 한다. 의존성 주입의 장점 모듈들을 쉽게 교체할 수 있는 구조가 되어 테스팅과 마이그레이션이 쉽다. 구현할 때 추상화 레이어를 넣고 이를 기반으로 구현체를 넣기 때문에 애플리케이션 의존성 방향이 일관되고 애플리케이션을 쉽게 추론할 수 있으며 모듈 간의 관계들이 명확해진다. 의존성 주입의 단점 모듈들이 더욱더 분리되므로 클래스 수가 늘어나 복잡성이 …

📚 웹 애플리케이션 아키텍처 🍭 클라이언트 - 서버 아키텍처 서버는 영어 단어 그대로 제공하는 주체를 의미한다. 클라이언트 - 서버 아키텍처 어떠한 리소스가 존재하는 곳과 리소스를 사용하는 앱을 분리시킨 것을 2티어 아키텍처, 또는 클라이언트 - 서버 아키텍처라고 부른다. 리소스를 사용하는 앱이 '클라이언트', 리소스를 제공(serve)하는 곳이 '서버'이다. 클라이언트와 서버는 요청과 응답을 주고받는 관계로 요청이 선행되고 그 후에 응답이 온다. 3-Tier 아키텍처 일반적으로 서버는 리소스를 전달해주는 역할을 담당한다. 리소스를 저장하는 공간을 별도로 마련해두는데, 이 공간이 '데이터베이스'이다. 기존 2티어 아키텍처에 데이터베이스가 추가된 형태를 3티어 아키텍처라고 한다. 프론트엔드와 백엔드 클라이언트 앱은 사용자가 눈으로 보고 대면하기에, 프론트엔드 영역이라고 한다. 서버 앱은 사용자 눈에 직접 보이지 않게 뒤에서 작동하므로, 백엔드 영역이라고 한다. 클라이언트와 서버 종류 클라이언트는 보통 플랫폼에 따라 구본된다. 웹사이트 (웹 앱) 스마트폰 / 태블릿용 앱 데스크탑 앱 서버는 무엇을 하느냐에 따라 종류가 달라진다. 웹 서버 : 웹사이트에서 필요로 하는 정보들을 제공 파일 서버 : 파일 제공 메일 서버 : 메일을 주고 받을 수 있도록 도와줌 데이터베이스 : 데이터 제공자로서 일하므로 일종의 서버로 봄 🍭 클라이언트 - 서버 통신과 API 클라이언트와 서버의 통신 클라이언트 - 서버 아키텍처에서는 서버 마음대로 클라이언트에 리소스를 전달하지 않는다. 요청이 있어야 응답이 온다. 프로토콜 (Protocol) 프로토콜은 통신 규약, 즉 약속이다. 웹 애플리케이션 프로토콜: HTTP 웹 애플리케이션 아키텍처에서는 클라이언트와 서버가 서로 HTTP라는 프로토콜을 이용해서 서로 대화를 나눈다. HTTP를 이용해 주고받는 메시지는 "HTT 메시지"라고 불린다. API API(Application Programming Interface)는 서버가 클라이언트에게 리…

📚 비동기 🍭 동기와 비동기 동기 (synchronous) JavaScript의 동기 처리란 '특정 코드의 실행이 완료될 때까지 기다리고 난 후 다음 코드를 수행하는 것'을 의미한다. 비동기 (asynchronous) JavaScript의 비동기 처리는 '특정 코드의 실행이 완료될 때까지 기다리지 않고 다음 코드들을 수행하는 것'을 의미한다. JavaScript의 작동원리 JavaScript는 싱글 스레드 기반으로 동작하는 언어이므로, 동기적으로 작동한다. 그러나 JavaScript가 작동하는 런타임에서 비동기 처리를 도와주기 때문에 특별한 작없없이 비동기 처리를 할 수 있다. 🍭 비동기 JavaScript 타이머 관련 API setTimeout(callback, millisecond) 일정 시간 후에 함수를 실행 매개변수(parameter) callback : 실행할 콜백 함수 millisecond : 콜백 함수 실행 전 기다려야 할 시간 (밀리초) return 값 : 임의의 타이머 ID clearTimeout(timerId) setTimeout 타이머를 종료 매개변수(parameter) timerId : 타이머 ID return 값 : 없음 setInterval(callback, millisecond) 일정 시간의 간격을 가지고 함수를 반복적으로 실행 매개변수(parameter) callback : 실행할 콜백 함수 millisecond : 반복적으로 함수를 실행시키기 위한 시간 간격 (밀리초) return 값 : 임의의 타이머 ID clearInterval(timerId) setInerval 타이머를 종료 매개변수(parameter) timerId : 타이머 ID return 값 : 없음 🍭 Callback 비동기로 작동하는 코드를 제어할 수 있는 방법 중 하나는 Callback함수를 활용하는 것이다. Callback함수로 비동기를 동기화할 수 있다. 그러나 Callback 함수를 통해 비동기 코드의 순서를 제어할 수 있지만, 코드가 길어질 수록 복…

🌱 12주차 과제 🖋 백준 15961 회전초밥 백준 15961 회전초밥 어렵지 않게 생각한 문제! 예제 풀면서 답도 잘 나오고 막히는 부분 딱히 없었는데 계속 시간초과가 났다. 알고리즘 힌트를 봤는데 투포인터와 슬라이딩 윈도우라는데,,, 사실 투포인터로 푸는 건 내가 푼거랑 딱히 크게 다른 점은 없을 것 같았지만 슬라이딩 윈도우는 정말 처음 들어봤다... 첫번째 제출 슬라이딩 윈도우로 풀면 아래와 같은 코드가 나온다. 🖋 백준 14719 빗물 백준 14719 빗물 처음에는 시작인덱스, 끝 인덱스를 투포인트처럼 하려고 했는데 오른쪽에 더 높은 혹은 더 낮은 블록을 예상하는 것이 필요했다. 고민을 하다가 블럭을 좌표처럼 쓰면 될 것 같다는 생각이 들었다. 각 층마다 검증을 하면 되는데, start는 왼쪽에 가로막고 있는 벽이 있는가에 대한 플래그이다. 각층마다 y좌표 0부터 w-1까지 검증한다. 1일 경우에 start가 있다면 지금까지 카운트한 숫자를 전체 카운트에 더해주고 tempCnt는 0으로 초기화한다. start가 없다면 start를 True로 바꿔준다. 왼쪽에 벽이 없었다는 뜻이므로 tempCnt는 더해주지 않는다. 0일 경우에 start가 있다면 tempCnt를 1더해준다. start가 없다면 왼쪽에 벽이 없다는 소리이므로 굳이 칸을 더해주지 않아도 된다. 🖋 백준 11660 구간 합 구하기 5 백준 11660 구간 합 구하기 5 첫번째 제출 사실 이 코드는 제출하면서도 시간초과가 나겠다는 생각을 했다. 역시나 시간초과. 다시 그림을 그려 생각해보니, 한 좌표까지의 누적합과 다른 좌표까지의 누적합을 빼면 그 좌표 두개 사이의 누적합이 나온다는 사실을 깨달았다. 그래서 한 줄 한 줄 씩 위의 원리를 적용해서 구해줬다. 두번째 제출 🖋 백준 14712 넴모넴모 백준 14712 넴모넴모 🖋 백준 9663 N-Queen 백준 9663 N-Queen

🍭 백트래킹(Backtracking) 백트래킹이란 해를 찾는 도중 해가 아니어서 막히면, 되돌아가서 다시 해를 찾아가는 기법을 말한다. DFS를 사용하여 만약 조건에 맞지 않으면 그 즉시 중단하고 이전으로 돌아가여 다시 확인하는 것을 반복하면서 원하는 조건을 찾으면 된다. 🖋 백트래킹 예제 1 - 백준 15649 N과 M(1) 이 문제는 버전이 정말 여러 개가 있었다. 이 문제들은 백트래킹 입문 예제라고 한다. 🌱 11주차 과제 지난 주 과제와 해커톤에서 백트래킹이 너무 어려웠어서 이번 주 미니 과제로 백트래킹 문제 세 가지를 뽑았다. 아직 백트래킹 개념에 대한 감이 잡히지 않아서 백트래킹 예제들을 혼자 몇개 풀어보았다. 물론 대부분이 N과 M 시리즈였지만 확실히 어떤 식으로 푸는지에 대한 감은 잡혔다. 다만 문제는 어떤 문제를 접했을 때 이게 백트래킹으로 해결할 수 있겠다는 감을 잡지는 못할 것 같은 느낌...! 이번 과제들도 백트래킹임을 알았으니 배운 개념을 사용해서 풀었지만, 스터디 초반에 책으로 풀 때 단원명을 알고 풀었을 때랑 같이 그 단원명을 빼면 어려운 느낌...! 이게 훈련을 하면 코드를 짜는 건 어느정도 할 수 있겠는데 문제를 보고 어떤 알고리즘으로 해결해야하느냐를 판단하는 게 가장 중요하고 어려운 것 같다. 이것도 훈련을 통해 기르는 수밖에... 🖋 백준 5568 카드 놓기 백준 5568 카드 놓기 아마 내가 골랐던 실버 4 문제...^^ 백트래킹 개념이 확실히 잡혀있지 않아서 쉬운 문제로 골랐다. 일단 카드이기 때문에 같은 수를 두 번 이상 사용하는 것은 안됨! 하지만 중복되는 카드가 존재할 수 있다. 또 만들어진 수열에서 다른 카드를 사용했지만 숫자로 만들었을 때 같은 결과값을 낼 수 있기 때문에 이는 또 없애줘야한다. 그래서 기본적인 백트래킹으로 구하고, 중복도 제거해주고, 그 다음 이를 다 한 배열에 넣어주고 최종적으로 set로 만들어준 뒤 여기서 갯수를 계산했다. 🖋 백준 10974 모든 순열 백준 10974 모든 순열 위 문제와…

🌱 11주차 해커톤 🖋 2023 KAKAO BLIND RECRUITMENT 개인정보 수집 유효기간 2023 KAKAO BLIND RECRUITMENT 개인정보 수집 유효기간 더할 수 있는 개월 수가 1년을 넘어간다는 사실을 망각하고 처음에는 개월 수를 더하고 12를 넘어가면 12를 빼주고 1년을 더해주는 식으로 해결하려 했다. 테스트케이스는 맞았지만 채점해보니 틀려서, 문제를 다시 읽어봤다. 1년 이상 넘어갈 수 있구나를 깨닫고 다시 짠 코드이다. 사실 좀 길긴 하지만 어떤 방식으로 풀었는지 직관적이긴 하다. 하지만 코드가 가독성이 떨어지는 점이 맘에 안들었는데, 친구가 좋은 아이디어를 줬다. 다 '일수'로 바꿔서 계산하면 된다. 사실 내가 datetime 모듈을 쓰려다 말았는데, 거기서도 결국 날짜를 받으면 숫자로 치환해서 비교를 한 결과를 알려주는 것이기 때문에 일맥상 통한다고 볼 수 있다. 🖋 2023 KAKAO BLIND RECRUITMENT 이모티콘 할인행사 2023 KAKAO BLIND RECRUITMENT 이모티콘 할인행사 다 확인하는 거 이외에는 딱히 생각나는 해결법이 없었다. 그래서 중복순열을 이용해서 각 이모티콘별로 할인율을 배당해주었다. 유저마다 각 이모티콘의 할인율이 유저의 할인율보다 클 때는 sale에 할인된 이모티콘 가격을 더해준다. 모든 이모티콘을 순회하며 이 작업을 해준 뒤, 유저가 원하는 가격보다 구매가격이 클 경우, sale을 0으로 바꿔주고 userCount를 1 더해준다. 여기에는 각 이모티콘 할인율의 조합별로, 이모티콘을 구매하는 유저의 수를 저장해주었다. 또, 구매가격이 크지 않다면 userSale에 sale를 더해주었다. userSale에는 각 이모티콘 할인율의 조합별로, 전체 유저가 구매하는 이모티콘 판매가격을 저장한다. 이렇게 유저별로 모두 순회하고 난 다음, userCount, userSale을 answer에 담아준다. answer를 마지막에 내림차순으로 정렬하면, 자동으로 첫번째, 두번째 요소 기준으로 정렬을 …

🌱 10주차 과제 🖋 9333 돈 갚기 백준 9333 돈 갚기 반복문을 돌리면서 이자와 함께 갚을 돈을 계산해주고, 갚을 수 있는만큼을 빚에서 빼주고 나서 더 갚을 돈이 남아있다면 앞의 작업을 다시 수행하도록 구현했다. 이렇게 구현한 코드는 계속 21퍼센트에서 틀리는 것!!! 도대체 왜...!!!!!! 🖋 22233 가희와 키워드 백준 22233 가희와 키워드 8주차에서 차집합 개념을 써서 풀었던 문제가 있어서 정말 너무너무 쉽게 풀렸다. 메모를 집합으로 냅두고, 거기서 매번 블로그 글을 작성할 때 해당 키워드들을 삭제하고 메모에 남은 키워드의 개수를 세주었다. 한 가지 문제(?)가 있다면, 요즘 부트캠프에서 자바스크립트를 쓰다보니, 파이썬과 자바스크립트 함수 사이에서 혼동이 온다...! 🖋 1699 제곱수의 합 백준 1699 제곱수의 합 첫 제출 왜 틀렸는가... 주어지는 숫자보다 작은 수 중 가장 큰 제곱근을 골라 계속 계속 빼주었다. 근데 풀고 나니 드는 생각인데, 테스트 케이스는 다 맞지만, 큰 숫자일 경우에 더 큰 제곱근을 빼는 것 보다, 작은 제곱근 두개를 빼주는 게 더 효율적이라는 생각이 들면서 아 이거 DP구나, 싶었다. 두번째 제출 이게... 맞나요...? 콩순이컴도 아니고 효율성이 이렇게나 떨어지는데... 이렇게 기다리게 해놓고 오답이면 저주할거야 너 ㅠㅠ 결국은 시간 초과로 틀렸다. 근데 제출하고 나서 보니, 아마도 range에 있는 math함수 두개 때문에 시간초과가 난 것 같다는 생각이 들었다. 세번째 제출 채점할 때 퍼센트 늘어나는 속도부터 달랐다. 알고리즘 짜는 것도 어려운데 복잡도까지 고려하려니까 까다로운 문제가 되어버린다. 이건 그나마 쉽게 풀리는 문제라서 해결할 수 있었지만, 좀 더 복잡한 문제에 복잡도 고려사항이 추가되면 아마도 많이 힘들 것 같다는 생각이 든다. 번외!!! 이것도 정답! range안에 함수가 있으면 for문 돌 때 마다 실행한다고 저번에 스터디할 때 누가 말해준 게 기억이 나서 이걸 밖으로 빼고 채점을 …

완성된 블로그는 아니었긴 하지만, 만들면서 부족한 점이 계속 보여서 리뉴얼하고 있다. 이번에 바꾸려고 생각한 리스트이다. 태그 / 카테고리 별로 필터링 하기 아이콘만 존재하던 게시글 검색 기능 구현하기 포스트 리스트 페이지 네이션 구현하기 벨로그처럼 글 헤더 Anchor 구현하기 About 페이지 가독성 있게 리팩토링하기 필터링이나 검색 기능은 매우 쉬운 작업이지만, Anchor는 어떤 식으로 해야하는지 감도 오지 않고, 될지 안될지 확신도 없다. About 페이지는 노션처럼 만들고 싶어서 구현을 해뒀는데 가독성이 너무 너무 떨어져서 사진도 넣고 좀 더 아기자기하게 꾸며보려 한다. 🥛 필터링 구현하기 기존 포스트 페이지의 모습이다. 최근 작성된 순서대로 필터링없이 전체 포스트를 다 볼 수 있다. 지금은 게시글이 많이 없어서 크게 불편한 점은 없지만, 게시글이 10개, 20개, 30개가 된다면 게시글을 찾는 데에 애를 먹을 것이라는 생각에 'category' 데이터로 필터링을 구현했다. 마크다운 페이지 정보에 category를 추가해주고, config 파일 같은 곳에서도 동일하게 feed내에 category를 추가해준다. 마지막으로 페이지에서 쓸 graphql을 수정해주면 된다. 사실, 애초에 sort와 함께 filter 기능을 이용해서 graphql로 데이터를 가져올 때 부터 원하는 카테고리의 데이터만 뽑아오고 싶었다. 그런데 그렇게 하려면 gatsby-node.js를 수정하는 등의 복잡한 과정이 필요하다고 한다. 깔끔히 포기하고, gatsby 초보자인 나는 js에서 필터링을 하기로 결정했다. 각 포스트 아이템에서 색깔로 되어 있는 뱃지, 즉 카테고리 태그를 누르게 되면, 처럼 쿼리스트링이 달린 url로 넘어간다. 여기서 category값을 추출해 데이터와 비교해 필터링을 걸어주었다. 🍭 검색 구현하기

글로 개발 과정을 쓴다는 게 아직 나에겐 너무너무 어색하고 어렵다. 독서를 정말 싫어하는 나는 일기 쓰는 것도 힘들어하는 사람이기 때문이다. 그럼에도 불구하고 개발 과정을 쓰려는 이유는 포트폴리오를 만들기 위함에도 있지만, 당장 작년에 만든 것만 해도 어떤 기능을 적용했었는지, 어떤 이유에서 적용했었는지, 어떤 라이브러리를 사용했었는지 등등 새롭게 배운 것들이 기억이 나지 않는다. 예를 들어서 카카오톡 지도 API를 KIYO에 적용하기 위해 열심히 문서를 읽었었지만 다시 쓰려고 하니 쉽지 않았다. 그래서 쓰게 된 개발일지이지만, 사실 정석대로라면 있어야할 와이어프레임, 프로토타입 등등은 아무것도 존재하지 않는 초초초소규모 프로젝트이다. 그냥 언니를 위한 선물(?)을 기록해놓고 싶은 마음에 쓰는 개발일기랄까... 🏝 언니네 부부가 제주도에서 숙박업을 하고 있다. 이번에 카페와 함께 리뉴얼을 해서, 기존에 블로그에만 있던 숙소 정보를 사이트에서 관리를 하려고 하는데, 디자이너인 언니가 웹디자인이라고 하긴 민망하고,,, 와이어프레임 정도를 짜서 주기로 했다. 처음에는 내가 그냥 개괄적으로 만들어보기로 해서 여러가지 숙소나 쇼핑 사이트들을 찾아 레퍼런스 삼으려 했는데 어쨌든 클라이언트가 원하는 방향을 만나서 하지 않는 이상 전달받기 힘들었다. 그래서 언니가 구상한 이미지를 주면 내가 바로 퍼블리싱하는 방식으로 작업을 진행하고 있다. (작업이라고 하니까 있어보이지만 정말 퍼블리싱 그 뿐...) 📐 기획 & 디자인 그리고 개발 기획과 디자인이라고 하기에 민망한 수준이긴 하지만, 이번 프로젝트는 '애자일' 그 자체였다고 할 수 있다. 애자일의 끝판왕을 보여주는 디자이너와의 카톡... 수정사항 100만가지지만 덕분에 포트폴리오도 채우고, 요즘 손놓고 있었던 프론트 개발도 할 수 있어서 즐겁게 하는 중이다. 크게 필요한 페이지는 네 페이지이다. Home페이지, About페이지, Room페이지, Reservation페이지. Home페이지는 숙소를 홍보할 예쁜 사진들과 문구…

🙄 2023 알고리즘 스터디 작년 7월부터 시작한 알고리즘 스터디. 다들 바쁘기도 하고, 발등에 불이 떨어지지 않아서 중간중간 흐지부지될 뻔도 하였지만, 새로운 해를 맞이해 의기투합해서 스터디 재정비를 했다. 복잡한 알고리즘에 있는 정 없는 정 다 떨어졌기에 동기부여가 필요했다. 노션 디스코드 대화방에 올리던 과제는 노션에 정리하기로 했다. 참여하지 못해 벌금을 냈던 주차의 과제는 몰아볼 수 있으니 빼먹은 문제를 다시 보충하기 너무 좋았다. 어떤 문제를 풀었었는지 기록을 따로 해놓지 않아도 정리해서 볼 수 있어서 편리했고. TIL 생각보다 잘 되고 있는 TIL. 여행을 다녀오느라 잠깐 또 반성할 일을 만든 나... 이제 더 열심히 해볼랍니다. TIL이라기보단 일기에 가깝게 쓰이고 있다. 이렇게 쓰는 이유는 다른 사람들이 열심히 하지 않은 날에 열심히 산 사람은 뿌듯함을 느낄 수 있고, 나는 놀았는데 남이 열심히 살았다 느낀다면 죄책감과 자괴감에 조금 더 나은 내일을 만들기 위해 노력하리라는 생각때문이었다. 개인적으로 진짜 그렇게 느끼고 있다...! 게더타운 또 하나의 동기부여, 게더타운. 혼자하면 절대 하지 않는 우리. 모여서 하면 좋겠다 해서 만든 게더타운인데 사실 활성화가 되지 않고 있다. 이제 회의도 게더타운 이용해서 하면 좋겠다. 다음 주에 건의해야지. 🌱 8주차 과제 벌써 8주가 지나갔다는 점이 나를 또 슬프게 한다. 중간 2주 정도는 또 여행과 다른 이유로 집중을 하지 못했기 때문에 완벽하게 8주 동안 집중할 수가 없었다. 벌금 5000원이 몇 번을 날아가는건지 알 수 없다. 1주차 과제부터 정리해야 숫자 강박이 있는 내게 불편함을 주지 않겠지만, 할 일도 많은 지금 앞의 7주차 알고리즘을 하나하나 회고하는 것은 어려운 일이기 때문에, 이번 주 과제부터 기록하기로 마음 먹었다. 지난 주 튀르키예 여행을 갔던 터라 친구들이 문제 6개를 골라뒀는데, 난이도를 보고 왜이리 다 쉬운 걸 골랐어~ 했는데 풀어보고 아니란 걸 깨닫게 되었지. 🖋 1251 단어…

📚 개요 재귀는 수학이나 컴퓨터 과학 등에서 자신을 정의할 때 자기 자신을 재창조하는 방법을 뜻한다. 주로 이 방법은 함수에 적용한 재귀함수(Recursion Function)의 형태로 많이 사용된다. 재귀함수란 자기 자신을 다시 호출하는 함수라고 이해하면 된다. 재귀 함수는 DFS, BFS 등 많은 알고리즘 문제를 해결하는 데에 쓰인다. 재귀함수에서는 종료 조건이 필수적으로 필요하다. 함수를 계속 호출하면 스택처럼 앞의 함수 위에 계속 쌓이기 때문에 마지막 함수가 종료되기 전에는 앞의 함수를 종료할 수가 없다. 따라서 종료 조건을 명시하지 않으면 함수가 무한 호출된다. 파이썬에서는 이렇게 무한적으로 함수가 호출될 경우, 아래와 같은 오류 메시지와 함께 종료된다.

본격적으로 개발을 시작했다고 하기에는 누가볼까 부끄럽지만, 개발 공부를 하고있는 사람으로서 개발 블로그 하나 정도 있어야지, 하는 마음은 수백번도 넘게 가졌다. 티스토리, 벨로그, 네이버 블로그 정말 다양하게 모두 시도해봤지만, 완벽하게 내 마음에 딱 드는 디자인이나 조건을 찾지 못했다. 티스토리 스킨을 고쳐볼까하는 생각에 몇 번 시도도 해보았지만, 일단 정해진 틀이 있는 이상 나의 창의력과 상상력을 가로막기 때문에 그 안에서 고치게 되는 경향이 있었다. 그렇기에 마음에 들게 고쳐질 수가 없는 법. 벨로그처럼 깔끔하면서 어떤 부분은 귀엽기도 하고, 특정 기능은 들어갔으면 좋겠는, 그런 욕심에 벼르고 벼르던 개발 블로그를 드디어 만들게 되었다. 취준을 하면서 시간 관리도 제대로 되지 않고, 혼자 공부했기 때문에 부족한 점이 많아 이 점을 채우기 위해 부트캠프를 수강하고 있는데, 아직 초반이라 과제를 일찍 끝내놓고 시간이 많이 남는다. 이 시간을 이용해 동기부여도 할 겸, 개발 블로그를 만들기 시작했다. 엄청 유능하신 분들께서 깃허브 페이지로 만드는 블로그 스킨을 만들어두셔서 이를 수정하는 방향도 생각해봤다. 그런데 또 어떤 것은 썸네일이 없어서 마음에 안들고, 어떤 것은 이게 마음에 안들고 등등... 까다로운 내 입맛을 도대체 만족시켜주는 것을 찾을 수가 없었다. 내가 만든 스킨이 아니다보니 수정하는 것은 더더욱 어려웠다. 스킨이 없이 시작하려니 내가 직접 추가해야할 부분들도 너무 많고 생각해야하는 것도 너무 많은 대규모 프로젝트였지만, 회사 다닐 때 새로운 프로젝트를 시작하던 그 때 생각도 나고 완전히 '내 것'을 만든다는 생각에 이틀만에 뚝딱 만들게 되었다. 아직 수정해야할 부분들이 정말 많지만, 일단은 개발 블로그 틀을 잡는 건 성공했다. 이걸 이제 깃허브에 배포를 하고 깃헙 페이지 자동화까지 하려고 하는데, 세상에 공개하기 전에 일주일 정도 손을 봐야할 부분들이 눈에 정말 많이 들어온다. 리스트화 해놓고, 테스크를 지워나가면서 좀 더 견고한 블로그를 만…