전체 224

[백준 python 1966] 프린터 큐

[Silver III] 프린터 큐 - 1966문제 링크성능 요약메모리: 31120 KB, 시간: 60 ms분류자료 구조, 구현, 큐, 시뮬레이션제출 일자2024년 10월 10일 16:41:16문제 설명여러분도 알다시피 여러분의 프린터 기기는 여러분이 인쇄하고자 하는 문서를 인쇄 명령을 받은 ‘순서대로’, 즉 먼저 요청된 것을 먼저 인쇄한다. 여러 개의 문서가 쌓인다면 Queue 자료구조에 쌓여서 FIFO - First In First Out - 에 따라 인쇄가 되게 된다. 하지만 상근이는 새로운 프린터기 내부 소프트웨어를 개발하였는데, 이 프린터기는 다음과 같은 조건에 따라 인쇄를 하게 된다.현재 Queue의 가장 앞에 있는 문서의 ‘중요도’를 확인한다.나머지 문서들 중 현재 문서보다 중요도가 높은 문서..

[백준 python 18110] solved.ac

[Silver IV] solved.ac - 18110문제 링크성능 요약메모리: 35868 KB, 시간: 180 ms분류구현, 수학, 정렬제출 일자2024년 10월 10일 12:35:12문제 설명solved.ac는 Sogang ICPC Team 학회원들의 알고리즘 공부에 도움을 주고자 만든 서비스이다. 지금은 서강대뿐만 아니라 수많은 사람들이 solved.ac의 도움을 받아 알고리즘 공부를 하고 있다.ICPC Team은 백준 온라인 저지에서 문제풀이를 연습하는데, 백준 온라인 저지의 문제들에는 난이도 표기가 없어서, 지금까지는 다양한 문제를 풀어 보고 싶더라도 난이도를 가늠하기 어려워 무슨 문제를 풀어야 할지 판단하기 곤란했기 때문에 solved.ac가 만들어졌다. solved.ac가 생긴 이후 전국에서 ..

[백준 python 28702] FizzBuzz

[Bronze I] FizzBuzz - 28702문제 링크성능 요약메모리: 31120 KB, 시간: 40 ms분류수학, 문자열제출 일자2024년 10월 9일 17:31:37문제 설명FizzBuzz 문제는 i=1,2,⋯$i = 1, 2, \cdots$ 에 대해 다음 규칙에 따라 문자열을 한 줄에 하나씩 출력하는 문제입니다. i$i$가 3$3$의 배수이면서 5$5$의 배수이면 “FizzBuzz”를 출력합니다. i$i$가 3$3$의 배수이지만 5$5$의 배수가 아니면 “Fizz”를 출력합니다. i$i$가 3$3$의 배수가 아니지만 5$5$의 배수이면 “Buzz”를 출력합니다. i$i$가 3$3$의 배수도 아니고 5$5$의 배수도 아닌 경우 i$i$를 그대로 출력합니다.FizzBuzz 문제에서 연속으로 출력된 ..

Spring Boot 3.x.x Swagger API 명세서

Dependency 추가Spring Boot 2.x대 에서는 SpringFox를 사용했다고 하는데 업데이트가 되지 않는게 오래 되어서 이제는 SpringDoc를 사용한다고 한다.SpringDoc는 스프링부트 2점대와 3점대가 의존성을 추가하는 방법이 다르다고 하니 버전에 맞게 잘 사용하면 될 것 같다.이번 프로젝트에서 사용한 버전은 3.3.3이므로 아래와 같이 의존성을 추가해줬다.implementation 'org.springdoc:springdoc-openapi-starter-webmvc-ui:2.6.0'사용법다른 블로그를 보면 환경변수를 설정하거나 Config 설정을 하는것으로 나와 있는데나는 따로 설정을 하지 않고 기본적으로 설정되어 있는데로 사용하였다.대신에 Spring Security를 사용하기..

기타/개발일기 2024.09.18

좋은 코드란 무엇일까?

좋은 코드란 무엇일까?좋은 코드라는 것이 뭘까? 어려운 문제를 엄청 간단하고 짧은 한줄의 코드로 해결하는 것이 좋은 코드인가?UpZen 대표 한기용님이 말씀하시는 좋은 코드는 가독성이 높은 코드이다.그래서 내가 나중에 코드를 봤을 때 쉽게 다시 기억을 되살릴 수가 있을 것이고, 다른 사람들이 쉽게 이해할 수 있기 때문에 내가 그만두거나 다른 일로 넘어갔을 때 유지보수가 쉬워진다. 단 코드를 작성할 때 본인이 맡은 업무를 명확히 이해하는 것이 중요하다 ("문제 정의"). 그래야 맡은 일에서 정말 중요한 것들 중심으로 구현할 수 있기 때문이다. 문제의 복잡도와 이를 해결하기 위해 들어가는 시간에는 보통 2080법칙(아마 팔레토법칙을 말씀하시는 것 같음)이 적용된다. 마지막 20%를 해결하는데 보통 80%의 ..

기타/개발일기 2024.08.31

대용량 트래픽을 처리하는 방법

대용량 트래픽을 처리하는 방법이전에 진행했던 티켓 예매 프로젝트를 통해 대용량 트래픽을 처리하는 방법을 알아봤다.티켓 예매 서비스 특성상, 콘서트를 예매할 시기에 트래픽이 과도하게 몰릴 것이고 원활한 서비스를 제공하기 위해서 대용량 트래픽을 감당할 수 있어야 했다.대용량 트래픽 처리를 위해 할 수 있는 방법은 크게 애플리케이션 관점과 하드웨어 관점으로 나눌 수 있을 것 같다.애플리케이션 관점시간 복잡도 최적화애플리케이션 관점에서 가장 먼저 고민해야 할 부분인 것 같다. 애플리케이션의 비즈니스 로직이 원활하게 동작할 수 있도록 시간 복잡도를 최적화를 시켜줘야 한다.만약 100만개의 데이터가 들어오는데 시간 복잡도가 O($n^{2}$)라면 10조가 나오게 되지만, O($n$)라면 100만이 나오기 때문에 훨..

기타/개발일기 2024.06.09

MySQL에서 MongoDB로 마이그레이션

변경 이유MySQL은 RDBMS이고, MongoDB는 NoSQL이다.NoSQL은 대규모 데이터 및 트래픽 증가에 따라 쉽게 서버를 추가하여 성능을 향상시킬 수 있다. 이는 URL 단축 서비스와 같은 읽기 및 쓰기 요청이 빈번한 애플리케이션에서 매우 유리하다.그리고 추후에 여러가지 기능을 붙일 것이기 때문에 데이터베이스 스키마가 유연한 것이 좋을 것 같다고 생각하여 변경하게 되었다.Spring Boot + MongoDBimplementation 'org.springframework.boot:spring-boot-starter-data-mongodb'먼저 MongoDB 의존성을 추가해준다.spring.data.mongodb.host=spring.data.mongodb.port=spring.data.mongo..

URL 단축 서비스 개발 기획서

개발 계기간단한 프로젝트를 해보고 싶었다. 무엇을 해볼지 고민하던 중에 URL 단축 서비스가 생각이 났다.현재 나와있는 URL 단축 서비스는 영어 대소문자를 통해서 원본 URL을 단축시켜준다.하지만 영어 알파벳은 총 26개이면서 대소문자를 포함하면 총 52개가 된다.그러면 영어 한자리로 52개의 사이트가 단축이 되고, 5자리라고 했을 때 52 * 5로 260개의 사이트를 단축이 가능하다.사용자가 많아지면 단축된 URL의 길이가 엄청 길어지기 때문에 URL을 단축시킨다는 의미가 없어진다고 생각한다.그래서 생각해 본 것이 한글로 URL을 단축시킨다는 것이다.한글은 한 글자로 총 초성 19개, 중성 21개, 종성 28개로 총 19 * 21 * 28로 11172개의 사이트를 단축할 수 있다.그렇다면 5자리라고 ..

Spring에서 SQL Injection을 어떻게 방어할까?

SQL Injection우선 SQL Injection이 무엇인지 간단하게 알아보자.SQL Injection은 해석 그대로 SQL 쿼리를 삽입하는 공격 방법이다.이 공격 방법을 예로 설명하자면 로그인을 할 때 틀린 비밀번호를 이용해 인증하여 인가 권한을 받을 수 있을 것이다.4년 주기로 웹 애플리케이션 보안 취약점 Top 10을 OWASP에서 올려주는데 이전 2017년보다 2021년에 Injection 공격이 낮아지기는 하였으나 꾸준히 올라오는 위험한 취약점이다.SQL Injection 대응방안SQL Injection을 대응하는 방법에는 크게 2가지로 분류할 수 있다.첫 번째로는 Stored Procedure나 Prepared Statement를 사용하는 것이고, 두 번째로는 특정 문자를 필터링해주는 것이..

Language/Java 2024.05.23

ngrinder를 통한 부하테스트로 API 터지는 현상 해결

개요먼저 프로젝트로 진행한 콘서트 전체조회 API에 대해 설명하자면, 해당 API는 프론트에서 메인 페이지에 데이터를 뿌려주기 위한 API로 전체 사용자가 콘서트에 대한 정보들을 확인할 수 있다.이 API에 대한 테스트로 1000명의 사용자가 접속한다는 가정하에 ngrinder를 통해 부하테스트를 진행하였다.문제점ngrinder를 통해 1000명의 사용자가 각 한 번씩 API를 호출하였을 때의 시나리오를 구성하였다.이렇게 설정을 하고 테스트를 진행하였는데 API가 터지는 현상을 확인하였다.그래서 해당 테스트를 다시 한 번 더 진행해봤는데 이번에는 성공하는 것을 확인할 수 있었다. 위의 테스트가 처음 돌렸을 때의 경우인데, TPS 28.1, 평균 테스트 시간 7849.2, 에러율 15.2%로 나오고아래의 ..