Fundamental

알고리즘 스터디를 위해 파이썬에서 코딩테스트를 위해 자주 쓰이는 연산자와 내장함수 관련 내용을 간략하게 정리해봤다. 파이썬에서 나누기는 /와 //가 있다. 전자는 소수점을 표시하고 후자는 정수만을 생성한다. 파이썬의 제곱 연산자는

위와 같이 미디어 타입으로 언급된 것은 다음과 같은 고민이 있기 때문이다. 미디어와 글을 같은 타입으로 볼 것인가 → 전통적인 CMS와 다르게 모든 글을 가지고 올 때 개별 사진을 같이 가지고 왔으면 좋겠다. 즉, 글이 주가되는 CMS가 아니라 사진이 주를 이루는 CMS. 미디어에 캡션을 얼마나 부착할 것인가 → 가령 한장의 사진이나 유투브 영상에 담긴 스토리에 대한 reference 결론적으로 미디어도 하나의 글(객체)이면 좋겠다. 아래와 같이 고쳐본다 아래와 같이 linkedDocument로 따로 관리한다. 왠만하면 마크다운을

이 부분은 1회차 지만 신경써서 머릿속에 넣어본다. 실제로 설계하거나 구현 할 때 적절한 모델링(추상화)와 인터페이스의 분리에 신경쓸 필요가 있겠다. 그러나 SRP-ISP와 OCP-DIP 관계의 뉘앙스 차이는 아직 잘 모르겠다. SRP; 단일 책임 원칙 OCP; 개방 폐쇄 원칙 LSP; 리스코프 치환 원칙 ISP; 인터페이스 분리 원칙 DIP; 의존 역전 원칙 모델링, 즉 적절한 추상화와 상속을 통해 구현이 바뀌어도 인터페이스를 통해 사용에 영향을 주지 않는다. 상속의 원칙에 만족하는가? → LSP를 만족한다. is a kind o

MongoDB에서는 속성의 네이밍을 최대한 줄인다. (성능이슈) install MongoDB 기본 db path는 /usr/local/var/mongodb다. 꼭 설치하지 않아도 기본 쿼리 몇가지는 웹에서 날려볼 수 있다. 스키마가 없다. 그래서 하나의 collection(즉, 테이블) 안에 다양한 구조의 document(즉, 데이터)를 밀어넣을 수 있다. 데이터는 구조로 표시된다. 중첩구조가 가능하다 (value, dictionary, list…) EAV패턴은 짧게 정리하면 데이터 구조의 변화 없이 속성(attribute)을 확장

CMS에 저장되는 사진의 DB 모델링 백엔드에서 구현 할 때 인터페이스화 하는 것이 좋을것같음 → 백엔드가 어떤 형태(URL, 직접저장, 퍼블릭클라우드) 인지 몰라도 가져오는데 지장이 없게끔 (OCP) 사진, 동영상, 글, 기타 메테데이터를 관리할 방법은? ex) 사진의 형태여도 백엔드가 외부 URL이거나 직접 store된거거나.. 미디어 모델링 UUID 또는 ID 미디어 : 미디어 형태: 사진|동영상|글 ← 왠지 이걸 분기하는 과정에서 오버헤드가.. 미디어 URL (또는 Reference) 메타데이터 reference 사진 메타데

1) 일반적으로 배열을 사용하여 데이털르 순차적으로 저장하고, 나열할 수 있다. 2) 배열을 사용하는 경우 메모리 공간이 불필요하게 낭비 될 수 있다. 배열로 만들었으므로 특정 위치 원소에 즉시 접근 가능하다. 데이터가 들어갈 공간을 미리 메모리에 할당해야 하는 단점이 있다. 원하는 위치로 삽입이나 삭제가 비효율적이다. -> 주소를 당기고 밀어야하기 때문에. 연결 리스트는 구조체와 포인터를 함께 사용하여 구현한다. 연결 리스트는 리스트의 중간 지점에 노드를 추가하거나 삭제할 수 있어야 한다. 필요할 때마다 메모리 공간을 할당 받는다

객체 사용에 해당되지 않는 세부 정보는 다른 모든 객체로부터 숨겨야 한다. 캡슐화는 객체에 속성과 행위가 같이 포함된다는 사실로 정의된다. 데이터 은닉은 캡슐화의 중요한 일부이다. 예를들어, 어떤 숫자의 제곱을 계산하는 객체가 결과를 얻기 위한 인터페이스를 제공해야 한다고 하자. 그러나 요청하는 객체에서 제곱을 계산하기 위해 사용하는 내부 속성 및 알고리즘을 사용하게 할 필요는 없다. 캡슐화를 염두에 두고 설계해야 클래스가 견고하다. 인터페이스는 객체간 의사소통하는 근본적인 방법을 정의한다. 클래스를 설계할 때마다 객체를 올바른 인

간단히 말해서 클래스는 객체에 대한 처사진이다 객체의 인스턴스를 만들 때 객체를 구성하는 기초로 클래스를 사용한다. 클래스와 객체를 설명하려고 하는 일은 닭이 먼저냐 계란이 먼저냐 같은 딜레마이다. 객체란 용어를 사용하지 않고 클래스를 설명하기 어렵고 그 반대도 마찬가지이다. 예를 들어, 어느 개인의 자전거는 객체이다. 그러나 누군가 자전거를 만들기 위한 청사진 (즉, 클래스)을 만들어야만 했다. 닭이 먼저냐 계한이 먼저냐는 딜레마와 달리 OO 소프트웨어에서 무엇이 먼저인지는 알고 있는데, 그것은 클래스이다. 클래스가 없이는 객체의