마리코프 체인는 다음 상태를 결정하기 위해 현재 상태만 의존하는 상태 전이에 대한 통계 모델 방법으로서 

마르코프 체인은 다음 상태를 알기 위해 현재의 상태만 의존한다. 

상태를 따로 저장하지 않기 때문에 메모리가 없어도 된다. 

* 이해를 높일 수 있는 괜찮은 동영상

공부에 도움 되는 자료

* http://electronicsdo.tistory.com/entry/Markov-chain-%EB%A7%88%EC%BD%94%ED%94%84-%EC%B2%B4%EC%9D%B8

* R 로 설명한 마르코프 체인 코드 

http://blog.revolutionanalytics.com/2016/01/getting-started-with-markov-chains.html

참고 : http://www.artima.com/articles/dci_vision.html

객체는 폴리모피즘, 커플링, 응집도가 아니라, 사람들과 사람들의 멘탈 모델에 대한 내용이다. 

MVC는 멘탈 모델이지 관찰자 패턴이 아니다.

참고 http://dm-academy.github.io/aitm/aitm-instructor.html

In this situation, each person has their own “mental model” of what needs to be done, and their own tracking mechanism. We don’t know how the work is being transmitted: emails, phone calls, hallway conversations (”Say Sara, there is an issue with Customer X’s bill, can you please look into it?”)

참고 : http://designbyforest.tistory.com/entry/UX%EB%AA%A8%EB%93%A0-%EA%B8%B0%ED%9A%8D%EC%9E%90%EC%99%80-%EB%94%94%EC%9E%90%EC%9D%B4%EB%84%88%EA%B0%80-%EC%95%8C%EC%95%84%EC%95%BC-%ED%95%A0-%EC%82%AC%EB%9E%8C%EC%97%90-%EB%8C%80%ED%95%9C-100%EA%B0%80%EC%A7%80%EC%82%AC%EC%8B%A4

03 사람들은 패턴 인식을 통해 사물을 인식한다.
-사람은 자동적으로 패턴을 찾음. 분류와 공백을 이용 패턴을 만들어 내는것이 좋음.
-아이콘 요소는 인지하게 만드는게 쉽고, 빠르게 인지하게 함.
-평면보다는 입체를 더 잘 인지. 단, 화면상에  표현된 입체 요소를 인지하고 이해하는 속도는 평면 요소에 비해 느릴수도 있음.

멘탈모델이란?
실세계의 특정 대상물이 어떻게 작동하는지에 대한 사람의 사고 과정에 대한 설명.
디자인 모델 - 디자이너의 개념모델을 말함.
사용자 모델 - 사용자가가 시스템과 상호 작용하는 과정에서 만들어낸 멘탈모델을 말함.

28 특정 유형의 인지 처리 과정은 더욱 까다롭다.
- 디자인할 때 사용자가 많이 생각하거나 기억하지 않아도 되게 한다. 이 두 가지는 인지 부하를 일으켜 많은 정신적 자원을 필요로 한다.
- 기회 비용에 대해 고민하라. 예를 들어 시각 부하나 운동 부하를 높여 인지 부하를 줄일 수 있는 곳이 있다.
- 사람이 선택하는 항목을 충분히 키워서 쉽게 도달할 수 있게 만든다.

참고 : http://egloos.zum.com/hisprite/v/3810333

멘탈모델은 
일. 서비스나 제품 기획에 지침이 될 수 있고
이. 사용자와 사업을 위해서 좋은의사결정을 내리도록 도와주며
삼. 장기적인 비전과 기회를 제시해 준다.

참고 : http://blog.naver.com/PostView.nhn?blogId=vinylx&logNo=220171087380&redirect=Dlog&widgetTypeCall=true

정의 및 가치

멘탈 모델의 활용 가치는 발생할 수 있는 문제점을 미리 파악하고, 통합적인 서비스 이해를 바탕으로 해결 방안을 도출할 수 있다는 데 있습니다. 이 모델은 이전 포스트에서 소개된 ‘친화도 맵’이라고도 불리는 ‘어피니티 다이어그램(Affinity Diagram) - 사용자의 공통된 행동자료를 의미상 가까운 것끼리 모아 놓은 다이어그램’과도 밀접한 관련이 있습니다. 즉, 다른 사람의 행동 동기, 사고 과정을 비롯한 감성적, 철학적 배경을 이해하기 위하여 그들과 대화하고, 행동 패턴을 도출하여 정리한 것이 ‘멘탈 모델’ 입니다. 여기서는 ‘행동(task)’이라는 단어는 행위, 생각, 기분, 철학 그리고 동기에 이르기까지 사람이 무언가를 이루거나, 무언가를 움직이거나, 특정한 상태에 이를 때 나타나는 모든 것을 포괄하는 의미로 정의하도록 하겠습니다.

lazy evaluation이 왜 빠른지 궁금할 때 보면 좋을 만한 자료가 있다.

참조

http://filimanjaro.com/blog/2014/introducing-lazy-evaluation/

strict evaluation(eagerly evalution)의 방법은 한 단계씩 차례차례 진행한다고 할 수 있다.

lazy evaluation은 한 번에 처리를 한다는 개념(마치 chunk 배치) 으로 보면 된다.

따라서 대부분의 경우는 이렇게 성능이 좋다.!!

전체적으로 lazy 방식이 성능이 좋다. 

하지만, 항상(무조건) 빠르다고 보장할 수는 없다. 대충 비슷할 수도 있기 때문에 테스트가 필요하다.

또한, 코드는 복잡해지기 때문에 유지보수성이 떨어질 수 있는 단점이 있다. 

view를 이용해 lazy와 eager 계산법으로 만든 예시를 소개한다.

val list = List(0, 1, 2, 3, 4, 5)
// eager evaluation : 조급한 계산법 (위키)
val evens = list.map(i => {
  println(s"$i")
  i + 10
}).filter(i => {
  i % 2 == 0
}).take(2).foreach(println)

println("-------")

// view를 이용한 lazy evaluation : 느긋한 계산법 (위키)
val evensView = list.view.map(i => {
  println(s"$i")
  i + 30
}).filter(i => {
  i % 2 == 0
}).take(2).foreach(println)

첫 번째 stream(eager)에 대한 결과는 다음과 같다.

두 번째 stream(view를 사용한 lazy) 결과는 다음과 같다.

첫 번째 stream은 list의 모든 엘리먼트를 조사하고 결과를 내지만,

두 번째 stream은 정확하게 필요한 내용만 조사하기 때문에 속도가 빠르다. 

deview 2016 발표자가 되었다면 풍부하고 실제적인 자료를 전달할 수 있을 터인데, 아깝게 채택되지 못했다.

새로운 것만이 좋은 주제가 아니라, 우리 개발자들이 잘 하고 있는 일을 더욱 개선하는 작업도 좋은 사례로 남기고 싶었다.

이 내용은 나 혼자한 것은 아니고 동료들과 함께 진행한 내용이며,  해당 내용을 간단하게 글로 정리한다. 

(Docker, Jenkins, Rspec에 대한 팁은 내 블로그에서 검색할 수 있을 것이다.)

Spec by Example이라 했지만, (자세한 내용은 https://en.wikipedia.org/wiki/Specification_by_example를 참고한다)

Acceptance Test(인수 테스트)라고 좋고, Integration Test, Functional Test도 괜찮다. 

격리된 환경에서 서비스를 예제로 테스트하는 테스트 환경(Spec by Example)을 Docker로 빠르게 처리하는 방법을 진행했고, 이를 간단히 소개한다.

나는 그동안 직장 생활을 하면서 애플리케이션(또는 플랫폼)을 Spec by Example를 진행한 서비스/플랫폼을 거의 본적이 없다. (간단한 test unit이나 ui 속도 체크, js 속도 체크 정도는 있었지만, 그 이상의 통합 테스트가 없었다)

그리고, 나는 테스트의 의미를 깊이 생각하지 못했다. 개발하기도 바쁜데, 어떻게 테스트 코드까지 짜야하나 하는 불편함이 가지고 있었다. SKP에서 SI업체에서 만든 코드(정리 안된 코드, 테스트 없는 코드)를 받으면서, 정말 어이가 없는 환경에 대한 깊은 고민이 있었다. 테스트 코드에 대한 중요성을 생각하게 되었고, ansible을 공부하게 되었다.(deview 2014 발표)

<거대한 공룡과 싸우기 위해 

필요한 다양한 방패와 무기가 있어야 한다는 그림인데,

여전히 그 때나 지금이나 현실은 조금도 변함이 없는 것 같다. 나에게는 언제나 개발을 대할 때는 이런 것 같다. 
특히 대용량 서비스는 더 장난 아니다.>

개발, 테스트와 관련된 용어이다. 

경계 조건은 영어로 edge case로서, 하나의 매개변수 값이 극단적인 최대값 또는 최소값이어서 로직에 문제가 발생할 수 있는 경우를 말한다. 

더 상세히 말하면..알고리즘에 처리하는 데 있어서 입력 매개변수의 유효 범위는 정해진다. 입력 범위가 다양해 질 수 있다. 따라서 테스트를 사용해서 입력 범위를 확인(validate)할 수 있다. 

예측이 될 수도 있고, 예측이 안될 수도 있지만, 문제를 어떻게든 해결할 수 있다.

복합 경계 조건은 영어로 corner case로서, 변수와 환경적인 요소로 인해서 로직에 문제가 발생할 있는 경우를 의미한다. 코드가 변경되지 않았는데, 테스트가 잘 성공하다가 실패할 때, 어떤 요인 때문에 발생할 수 있다.  랜선이 문제가 많거나 습도가 높은 컴퓨팅 환경 때문에 영향을 받을 수도 있다. 

재현, 테스트가 무척 어렵다.

Mesos 가 예제가 많길래 가장 영향력이 있는 줄 알았는데.

2016.9월.. docker cluster management할 수 있는 툴을 조사해봤다. 

구글의 Kubernetes, Docker Swarm, Apache Mesos, Hashicorp nomand, Coreos Fleet 정도가 있는 것 같다.

mesos가 많이 알려져 있어서 1등 인줄 알았건만, 현실은 역시 구글의 Kubernetes,

 2 등은 Docker swarm 이다. 

일반적인 HTTP 성능 테스트를 진행할 때,

일반적인 벤치마크는 웹 서버에서 요청을 처리한 시간을 먼저 저장하고, 클라이언트로 전달되기 직전 시간(응답 시간) 사이의 경과된 시간을 측정한다. 하지만, 웹 서버는 서버에서의 지연 시간(전문용어 latency)만을 측정하지 그 이후는 측정되지 않는다. 

바로 이 문제를 조율된 누락 문제(coordinated omission)라 한다. 성능 벤치마크시 많이 간과하기도 한다. 백분위수가 높거나 TPS가 어이 없이 높다면 의심할 필요가 있다. 

괜찮은 벤치마크일수록 요청을 보낸 순간과 클라이언트에서 응답을 실제로 받는 순간 사이의 시간을 명확히 측정한다. 즉 좋은 HTTP 성능 벤치마크라면, 클라이언트에서 HTTP 요청의 응답을 제대로 받은 순간까지의 시간을 측정할 수 있을 것이다. 

(그래서 Load Runner가 대단한 툴이라 생각하고 있다..)

참고로 더 자세한 내용을 보기 원하면, 두 개의 링크를 참조한다.

https://www.quora.com/In-Java-what-is-Coordinated-Omission

특히 아래 링크는 공부하기 좋은 자료가 있다.

https://groups.google.com/forum/#!msg/mechanical-sympathy/icNZJejUHfE/BfDekfBEs_sJ

참고로,  조율된 누락 문제를 언급한 툴로 elasticsearch rally에 있었다. rally의 현재 이슈에 대해서 elasticsearch 블로그에서 잘 설명되어 있어서, 관련 내용을 살펴보는 것도 좋을 것 같다.

https://www.elastic.co/kr/blog/announcing-rally-benchmarking-for-elasticsearch

아래 이슈에서 열심히 토론 중이다.

https://github.com/elastic/rally/issues/64

네이트 실버의 <신호와 소음>이라는 책 뒷 부분에 아래 글이 있어서 참 좋았다. (오래만에 본 정말 최고의 책이었다.)

이 책에서 인용한 글의 원문은 Serenity Prayer이었다.

기도문에 있는 라인홀트 리버라는 신학자가 설교에 쓴 기도문이라고 한다.

참조

http://www.aahistory.com/prayer.html

BBC에서 BBC 홈페이지를 어떻게 만들었는지 간단하게 소개한 내용이 있다.

http://www.bbc.co.uk/blogs/internet/entries/47a96d23-ae04-444e-808f-678e6809765d

여기에서 주목할 내용은 Continuous Delivery를 위해 Acceptance test 용으로 mocha라는 툴을 썼다고 나온다.

http://mochajs.org/

https://github.com/mochajs/mocha

star가 10,000개가 넘을 정도로 인기가 좋다. 기회가 된다면 써봐야지..

describe('Array', function() {
  describe('#indexOf()', function() {
    it('should return -1 when the value is not present', function() {
      [1,2,3].indexOf(5).should.equal(-1);
      [1,2,3].indexOf(0).should.equal(-1);
    });
  }); 

카산드라(Cassadra)라는 Nosql을 사실상 주도하는 DataStax가 2015년 아우렐리우스(https://github.com/thinkaurelius/titan)사의 그래프 DB(정확히 말하면 Titan)를 샀었다. 더 이상 아우렐리우스 그래프 DB를 관리하지 않고, 그 인력을 바탕으로 이번(2016.4)에 새로나온 Cassandra 엔터프라이즈 버전에 그래프 엔진을 추가했다.

가장 큰 특징은 그래프 DB 표준을 기반으로 한 것이라 한다.

https://tctechcrunch2011.files.wordpress.com/2016/04/datastax-studio.jpg?w=1316&h=782

http://www.datastax.com/products/datastax-enterprise-graph
http://techcrunch.com/2016/04/12/datastax-adds-graph-databases-to-enterprise-cassandra-product-set/
http://www.ciokorea.com/print/29328