보관물

Archive for the ‘Terms’ Category

Single Source Of Truth

3월 11, 2016 댓글 남기기

대강 번역을 하자면 “현존하는 단일 자료” 정도로 봐줄 수 있을 것 같다.
Single Source Of Truth는 정보시스템에서 사용되는 이론(설계)인데
같은 자료가 여러군데 존재하는 경우에 발생되는 자료의 중복, 비정합성 등의 문제를 해결하고자 하는 방식이다.

개념을 이해하기 위해 DB를 예로 들어보자.
개인 정보를 저장하는 PERSON table에는 user_id, email column이 있고
게시글을 저장하는 POST table에는 post_id, title, user_id, email column이 있다고 하자.
(일반적으로는 POST table의 user_id를 통해 PERSON table과 join하여 email을 추출하기 때문에 이렇게 작성하지 않지만 개념을 설명하기위해 일부러 작성했다.)

[PERSON]
user_id       email
—————————————————-
chris            chris@email.com
jane              jane@email.com

[POST]
post_id       title              user_id       email
——————————————————————————————
1                   blahblah      chris            chris@email.com
2                  hahaha         jane              jane@email.com

만약 chris의  email이 chris@email.com에서 funnychris@email.com으로 변경되었다고 하면 PERSON table과 POST table의 email column을 모두 UPDATE해야 한다.

하지만 POST와 같은 table이 하나가 아니라 여러개라면 해당되는 모든 table을 찾아 UPDATE해야하고 만약 하나라도 빠뜨리게되면 어떤 화면에서는 chris@email.com으로 표시되고 어떤 화면에서는 funnychris@email.com으로 표시되는 경우가 발생될 것이다.

이를 해결하기 위해 email정보는 PERSON table에서만 유지하고 POST table에서는 user_id를 활용하여 PERSON table을  참조하도록 정규화하면 되는데 이 개념이 하나의 자료는 한 곳에만 저장한다는 single source of truth개념이다.

다른 예를 들자면 file 공유 서비스를 들 수 있다.
chris라는 사용자가 captain_america_cast_list.txt라는 file을 저장하였고
jane이라는 사용자가 이 file을 자신의 folder에 담았다고 하자.
만약 single source of truth를 따르지 않는다면 jane이 folder에 담는 과정에서 해당 file은 copy가 될 것이다.
그렇게 되면 chris가 이후 captain_america_cast_list.txt를 수정하여 저장하여도 jane이 가진 file에는 반영되지 않을 것이다.
이를 해결하기 위해서는 jane이 folder에 담는 과정에서 해당 file을 copy하는 것이 아닌 참조를 하도록 처리한다면 나중에 chris가 수정한 내용도 jane에게 똑같이 반영될 것이다.

angularJS의 data binding역시 single source of truth로써 model을 사용하고 있다.

카테고리:Terms

CORS – Cross-Origin Resource Sharing

12월 24, 2015 댓글 남기기

web application의 중요한 보안을 위해 Same-origin policy가 기본적으로 적용이 되어있다.

요즘은 서로 다른 서버의 API를 활용하여 web application을 구현하게 되는데 이 경우 Same-origin policy문제로 data를 받아오지 못하는 문제가 생긴다.

이를 해결하기 위해 W3C에서 서로 다른 서버로 부터의 자원을 사용할 수 있도록 하는 규약을 만들었는데 이것이 CORS이다.

CORS는 client의 요청을 수용할지를 HTTP Header를 이용해  server에서 정의하게 된다.

몇가지 Header를 소개하자면 다음과 같다.

  • Access-Control-Allow-Origin : origin에 따라 허용
  • Access-Control-Allow-Methods : HTTP 요청 방식에 따라 허용

지원되는 browser는 다음과 같다.

  • IE 10+
  • IE 8~9 (XMLHttpRequest대신 XDomainRequest 사용시 가능)
  • Chrome 28+
  • Opera15+
  • FireFox 3.5+
  • Safari 4+

그 외 지원가능 browser는 wiki를 참고.

좀 더 자세한 사항은 관련 링크를 참조.

카테고리:Terms

Browserify

12월 23, 2015 댓글 남기기

Browserify는 Browser에서 Node.js의 CommonJS module 방식을 실행 할 수 있도록 compile해주는 tool이다.

예를 들면 일반적인  browser는 require가 정의되어 있지 않아 require(‘modules’) 형태를 사용할 수 없다.

Node.js와 같은 방식으로 require를 사용하여 구현 한 것을 Browserify로 compile을 하면 browser에서 실행 할 수 있게 된다.

이 방식으로 인해 수많은 NPM의 module을 browser에서도 사용할 수 있게 된다.

 

좀 더 자세한 사항은 관련 링크를 참조.

카테고리:Terms

SASS – Syntactically Awesome StyleSheets

12월 23, 2015 댓글 남기기

Sass는 강력하고 우아함을 더한 CSS의 확장판이다.

Features

  • CSS 완벽 호환.
  • 변수, 중첩, mixins 같은 언어 확장을 제공.
  • color, value 처리 등을 위한 수많은 유용한 function 제공. – 관련 링크
  • if, while, include등의 control directives를 제공. – 관련 링크
  • well-formmated, 사용자화 가능한 출력을 제공.

Syntax

  • SCSS

CSS 문법의 확장판으로 대부분의 CSS hack과 특정 vendor 문법도 지원. 확장자는 .scss를 사용.

  • The indented Syntax

기존에 지원하던 문법으로 SCSS보다 가독성이 좋고 빠른 작성이 가능. 확장자는 .sass를 사용.

위의 두 가지 문법 중 SCSS를 지원하면서 The indented Syntax방식은 예전 방식이라 deprecated될 거란 우려가 있자 SASS측에서 이런 글을 올려 우려를 종식시켰다.

둘 중 어떤게 좋은가에 대한 것은 이런 글을 참고.

좀 더 자세한 사항은 관련 링크를 참고.

카테고리:Terms