ALL

# 최대 부분 배열 합이란? 개념은 아주 간단합니다. 주어진 수 배열에서 연속된 부분 배열 중 합이 최대인 부분 배열을 찾는 알고리즘입니다. 이 문제는 완전 탐색, 부분합 수열, 분할 정복, DP 를 활용하여 풀 수 있지만 각각 시간 복잡도가 O(2^n), O(n^2), O(nlogn), O(n) 로 다르기 때문에 가장 효율적인 DP로 푸는것이 가장 바람직합니다. # 예제 코드 def getSum(arr): dp = sequence[0]# 현재까지의 최대합 cur = 0# 실시간 최대합 for x in arr: cur = max(x, cur + x)# 특정 구간까지의 합 + 현재 값 vs 현재 값 dp = max(dp, cur)# cur이 현재까지 최대합보다 크다면 갱신 return dp # 알고리즘의 ..

API를 설계한다고 하면 대부분 RESTful API를 떠올리게 됩니다. 간결하고 직관적인 설계 때문에 굉장히 많이 사용되고 있는 API 방식입니다. 하지만 우리는 그저 "다른 사람들이 다 하니까" RESTful API 방식을 채택하고 있지는 않은지 생각해 볼 필요가 있다고 생각합니다. 따라서 이 포스트에서는 RESTful API가 무엇이며, 왜 널리 대중적으로 사용되고 있는지 알아보고 다음 포스트에서는 다른 방식은 어떤 것들이 있는지 살펴보고, 무지성으로 RESTful API를 사용하는것이 아닌 어떤 서비스에 어떤 방식이 적절할지 고민해보도록 하겠습니다. REST API, RESTful API를 보통 혼용해서 사용하며 두가지 모두 REST 원칙을 준수하는 API로 의미는 같습니다. REST API를 알..

DDD에 대한것들을 공부하다가 관리, 운영, 배포에 관한 글을 읽고 배운것이 많아 글로 남기게 되었습니다. 기술에 대한 자세한 내용은 없고 철학이나 각각의 역할에 대해서만 서술하겠습니다. # 시대 변화 시대는 하루가 빠르게 변화하고 있습니다. 특히 이공계쪽은 미래가 상상이 가지 않을정도 입니다. 결국 사용자에게 '서비스'를 제공하는 개발자라는 사람들은 알 수 없는 미래에 빠르게 대응해야 하는 상황입니다. '성능(속도)'과 '확장성'이 굉장히 중요해졌습니다. 서비스라는 것도 결국 돈에 의해 만들어지고 운영되는 것이기 때문에 2가지 특성을 가지고 가면서 비용을 최소화하려고 노력하였습니다. # 어떻게 변하고 있는가 1. 대규모 silo 조직 -> 다기능 소규모 squad 조직 2. 서버 단위가 작아지고 있습니..

# DB를 잘 설계해야하는 이유 어플리케이션을 하나 만들기 위해서는 굉장히 많은 양의 데이터를 처리해야 합니다. 우리는 보통 이 문제를 DBMS를 사용하여 무수한 데이터를 저장하고 원할때마다 알맞게 꺼내씁니다. 하지만 실생활에도 그렇듯이 어떤 방식으로 정리하고 관리하느냐에 따라 사용할때의 속도(성능)이 달라집니다. 여러 데이터베이스 종류가 있지만 그 중에 RDB를 사용할때 조금 더 효율적인 DB를 설계할 수 있는 방법에 대해 알아보겠습니다. 효율적인 DB의 가장 궁극적인 형태는 '시간'과 '돈'을 최대한 아낄 수 있는 형태입니다. 서비스도 결국 '비용'으로 운영되고 관리되기 때문입니다. 예외적으로 다른 선택지를 택해야 할때도 있지만 비로소 이렇게 해야 나중에 발생할 '비용'도 최대한 줄일 수 있습니다. ..

# 네트워크 Net + Work의 합성어로서 '컴퓨터들이 통신 기술을 이용하여 그물망처럼 연결된 통신 이용 형태'이다. 쉽게 말해, 정보공유를 목적으로 컴퓨터와 컴퓨터가 연결되어 형성된 망을 의미한다. # 중요 용어 ip 주소 : 통신을 위해 인터넷 프로토콜을 사용하는 네트워크에 연결된 모든 디바이스에 할당된 고유 번호. 노드 : 데이터를 송신, 수신, 작성, 저장할 수 있는 네트워크 내의 연결 지점. ex) 컴퓨터, 프린터, 모뎀, 브릿지 및 스위치 라우터 : 네트워크 간에 데이터 패킷에 포함된 정보를 전송하는 물리적 또는 가상 디바이스. 패킷교환기 라우팅 : 라우터가 패킷을 네트워크에서 목적지까지 보내는 최적의 경로를 선택하는 과정 스위치 : 다른 디바이스를 연결하고 노드 간 통신을 관리하여 데이터 ..

# 등장배경 서드파티 어플리케이션이 사용자 대신 페북에 영향을 주거나 정보를 가져오려고 한다고 가정해 봅시다. 가장 기본적인 방법은 서드파티가 id, pw를 사용자로부터 입력 받아서 서드파티가 다른 서비스에 대신 로그인해서 접근하는 방식입니다. 하지만 이 방법에 치명적인 단점이 있는데 페북 id, pw를 서드파티가 관리할만큼 믿을만 한가에 대한 의문입니다. 즉, 서드파티의 보안수준이 페북의 보안수준이 되어버리는 문제가 발생합니다. 이를 해결하기 위해 서비스별로 여러가지 auth방식이 나왔는데 이를 OAuth로 통일시키기로했습니다. # OAuth란 다양한 플랫폼의 특정한 사용자 데이터에 접근하기 위해 제3자 클라이언트(우리의 서비스)가 사용자의 접근 권한을 위임(Delegated Authorization)..

무지성 박치기로 로그인을 구현하려했다가 몇주를 헤맸던지... 만약 처음으로 로그인을 구현하려 한다면 documentation부터 차근차근 보는것을 추천합니다. 깃헙 뒤지고 아무리 구글링해도 내가 딱 원하는 나만의 로그인을 구현하다보면 생각외로 굉장히 많은 생소한 에러를 발견합니다. 1. SecurityContextHolder SecurityContextHolder는 SecurityContext를 가지고 있고 이를 통해 인증을 증명할 수 있습니다. 일반적으로 thread-local을 사용해서 정보를 저장하기 때문에 동일한 스레드라면 항상 SecurityContext에 접근 가능합니다. 다른 방식을 원하면 따로 설정 가능합니다. 2. SecurityContext Authentication 객체를 가지고 있습..

# Spring Security란? Spring Security는 Java 기반의 응용 프로그램에서 보안을 구현하기 위한 강력하고 널리 사용되는 프레임워크입니다. 인증, 권한 부여, 세션 관리 및 일반적인 보안 위협으로부터의 보호 등 다양한 보안 관련 문제를 해결하기 위한 기능을 제공합니다. 결론은 개발자가 좀 더 간편하게 보안을 구현할 수 있도록 도와주는 프레임워크입니다. # 구조 아주 간단하게 말해서 등록된 수많은 filter들을 통과한 요청을 안전한 요청으로 처리하는 식입니다. DelegatingFilterProxy 보통 서블릿 필터는 web.xml 파일에 직접 등록되어 사용됩니다. 반면, spring에서는 web.xml보다 JavaConfig 설정 파일을 사용합니다. delegatingFilter..