stack — 최근 글

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

본격적으로 스프링에서 사용되는 코드 패턴과 개념에 대해서 파고 들어간다. 제어의 역전 객체를 직접 생성하지 않고 외부에서 구현체를 넣어줌으로써 제어권을 거꾸로 가지고 가는 현상 IoC는 즉, 설계의 패턴이다. 실체에 의존할 것인가 추상화에 의존할 것인가 의존성 주입 외부에서 의존성을 받는 행동. 즉, 외부에서 new로 생성된 객체를 받는다. DI는 즉, 동작 그 자체다. 의존성을 어떻게 가질 것인가? 관계를 짧고 쉽게 정리하자면 → DI를 하면 IoC가 일어난다. 객체의 생성, 소멸, 작동의 주도권(즉, 제어권)이 객체 자신에게 있

이 부분은 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 사진 메타데

객체지향의 4대 특성에 대해서 알아본다. 이미 알고있는 내용이지만, 책에서는 T메모리 도식을 직접 보여줌으로써 추상화, 다형성, 상속, 캡술화가 각 메모리 영역에 어떤 작용을 하는지 알 수 있었다.

서점에서 최신 트랜드?가 반영된 OOP를 찾다가 이 책에서 그것을 언급하고있고, 또한 자바 문법의 전반적인 경험을 맛본 나로써 알맞은 난이도의 책이라고 생각했다

자바를 개발하기 위한 SDK다. JRE; 자바 런타임을 포함하고 있다. 13,14를 깔아도 하위버전을 지원한다. Maven과 Gradle의 차이 ( 메이븐은 ) ( 아티팩트에 대한 설명 ) ( 그레이들은 ) 기본 코드 스타일 이외에 임의의 사용자 환경을 지정할 수 있다. 지정된 코드 스타일을 소스 저장시 자동으로 포매팅 해준다. 블록의 열리고 닫히는 단위를 임의의 색깔로 표시해준다.