스택 오버플로우의 창립자 제프 앳우드가 쓴 [코딩 호러의 이펙티브 프로그래밍]이라는 책에 개발자를 8가지 유형으로 나눠 소개한 부분이 있다. 그 내용을 간략하게 옮겨본다.

1. 죽은 프로그래머

- 최고의 단계

- 나는 죽었지만, 내 코드는 계속 사용됨

- 다익스트라, 도널드 커누스, 앨런 케이

2. 성공적인 프로그래머

- 자신의 코드를 이용해 하나의 비즈니스를 새롭게 창조한 프로그래머

- 대부분의 프로그래머들이 꿈꾸는 단계

- 종종 프로그래밍 기술보다 비즈니스 기술에 의해 좌우됨

- 빌 게이츠, 존 카맥

3. 유명한 프로그래머

- 프로그래밍과 관련된 직업에 한해서 유명함

- 프로그래머가 일하고 있는 회사의 규모와는 상관없이, 다른 프로그래머들이 이름을 들어서 알고 있음

- 자신의 분야에서 긍정적인 영향을 미치는 존재

4. 일하는 프로그래머

- 소프트웨어 개발자로서 성공적인 경력을 보유

- 좋은 직장을 위해 오래 기다릴 필요가 없고, 주변에서 존경받음

- 근무한 회사의 실적이 향상

5. 평균적인 프로그래머

- 자신이 결코 위대한 프로그래머가 아니라는 사실을 알지만, 충분히 좋은 실력을 갖춤

- 비즈니스 능력과 사람을 다루는 기술이 뛰어난 사람이 더 큰 성공을 거두는 경우가 많음

- 프로그래머이면서 근근이 먹고 살아갈 정도라면 자신의 재능이 코딩에 있는 것이 아닐 가능성이 큼

- 자기가 잘하는 것이 무엇인지 깨닫고 그것을 추구하라. 아주 적극적으로.

6. 아마추어 프로그래머

- 코딩을 좋아하는 사람들 : 학생, 인턴, 오픈소스 커미터, 재미로 코딩하는 사람

- 미래의 가능성과 열정을 보여줌

- 빠르게 일하는 프로그래머의 단계로 성장하는 경우가 있음

7. 알려지지 않은 프로그래머

- 전형적인 프로그래머

- 유능하긴 하지만 별다른 특징이 없음

- 그저 직업일 뿐이며 개인적인 삶의 목표와 별로 상관이 없음

- 이 단계가 특별히 잘못된 것도 아님

8. 나쁜 프로그래머

- 프로그래밍 기술이나 능력이 없음

- 다른 동료 프로그래머들에게 고통과 통증을 안겨줌

- 비즈니스 코드를 작성하면 안되지만, 그런 코드를 작성하고 있음

  개발자들에겐 없어서는 안될 사이트인 스택오버플로우의 창립자인 제프 엣우드가 쓴 책이다. 번역은 임백준님께서 하셨다. 스택오버플로우 사이트를 개발하면서 겪은 경험과 개발자가 어떤 방향을 가지고 개발을 해야하는 지를 주로 다뤘다. 그리고 개발뿐만 아니라 UX나 기획, 그리고 개발자 커뮤니티와 커뮤니케이션 같은 부분까지 다루고 있다. 저자의 다방면에서의 내공을 살펴볼 수 있지만, 솔직히 웹 페이지의 UX같은 것은 평소에 생각해보지 않았기 때문에 잘 와 닿았지 않았고 좋은 점이나 나쁜점을 따로 생각해볼 수 없었다.

  책의 초반에 다룬 개발자의 8가지 유형을 흥미롭게 소개한 대목이 있다. 3번째로 높은 순위인 유명한 프로그래머가 되는게 현재 목표이지만, 쉽지 않을 것 같다. 현재 내가 생각하는 나의 단계는 5번 일반적인 프로그래머이다. 코딩을 좋아하긴 하는데, 나에게 재능이 있는 것 같진 않다. 더 잘하고 싶어서 노력을 많이 하고 있지만, 노력을 시작한 시점이 늦어서 그런지 조금 벅차다. 더 나아질 것이라는 기대 하나만으로 개발을 계속 하지만, 당장 직접적으로 나에게 다가오는 성과같은 것들이 없어 짙은 안개 속을 해쳐 나가는 기분이 든다.

  개발자들을 위한 자기개발서에서 꼭 나오는 얘기인, 블로그를 작성하라는 말을 구체적인 이유과 함께 언급하였다. 블로그에 글을 남기면서 자신의 생각을 논리적으로 정리하는 연습을 할 수 있기 때문에, 업무나 일상 생활에도 도움을 줄 수 있다는 장점을 어필한다. 올해 들어서 블로그를 꾸준하게 작성하고 있다. 블로그를 작성하고 있지만, 내 주변 사람들이 이 블로그를 보지 않고, 유명한 블로그도 아니기 때문에 기술적인 논쟁이나 코멘트 또는 피드백이 전혀 없어, 내 블로그에 대한 평가를 전혀 알 수 없다. 주변 사람들에게 억지로 읽게 할 수도 없고, 난감한 상황이다. 연예인에게 악플보다 무플이 좋지 않다는 말이 이 경우에도 통하는 것 같다.

  책을 읽으면서 메모로 기록한 단어 중에 썩은 사과라는 것이 있었는데, 정확히 어느 페이지에서 보았는지 기억이 나지 않아 다시 살펴보지 못했다. 아마도 겸손하지 않고, 자신이 제시하는 기술(기술의 출시 연도와 관걔 없이)이 항상 옳다고 주장하면서, 자신의 의견이 잘 받아들여지지 않을 경우, 프로젝트의 참여하는 태도가 좋지 않은 사람을 뜻하는 것 같다. 요즘 프로젝트를 진행하면서 비교적 신 기술인 JVM의 Scala나 Erlang 의 Beam 머신 위에서 동작하는 Elixir 와 같은 함수형 프로그래밍을 도입하자고 주장을 하고 있었다. 하지만, 기존의 프로젝트에서 막연하게 어떤 점이 좋다고 말하고 있지, 정작 문서나 수치 자료를 통한 근거를 이용하지는 않았다. 나의 주장에 힘을 내기 위해선 코드를 짜는 실력과 함께, 문서를 가지고 다른 사람을 설득하는 능력까지 갖춰야 할 것 같다.

  마지막으로, 책에서 가장 기억에 남는 문장을 적으면서 책에 대한 평을 마무리한다. 정확한 문장은 기억나지 않지만, 내용은 일맥상통한다.

  동료가 작성한 썩은 코드를 싫어해도, 그 동료를 싫어하진 말자!

Functional Program Design in Scala

  Scala 언어를 만든 마틴 오더스키 교수의 Coursera MOOC 2탄이다. 1탄에 대한 소감은 이 링크에 있다. 1탄에서는 Scala와 Functional Programming의 기본 과정을 다뤘다면, 이번 강의는 심화 과정을 다룬다.

  처음에는 1장에서 배웠던 for 구문에 대한 심화 과정을 알려준다. for와 yield를 조합한 코드는  Scala 컴파일러가 map, flatMap 과 같은 Higher-order Function으로 변경시킨 후, 해당 작업을 처리한다. 이러한 변환은 Higher-order Function을 직접 사용하는 것보다 code에 대한 추상화를 더 강력하게 지원한다. 그리고 난수를 생성하는 방법을 함수형 스럽게 지원한다. 가장 작은 기본 단위인 Int형 난수 생성기를 이용해, 단계적으로 아주 큰 범위의 난수까지 생성하는 과정을 보여준다. 이 장의 마지막에는 함수형 프로그래밍의 끝판왕 중 하나인 Monad에 대해 설명하고 있다. Scala에서 Monad는 flatMap() 함수로 나타난다. Monad는 카테고리 이론에서 나온 것으로써, 단어 자체의 어원과는 전혀 상관없는 이론을 나타낸다. Monad에 대해서 이 강의에서는 기본적인 개념만 설명하고 있다. 이 강의를 가지고 Monad를 완벽하게 이해하는 것은 어려운 것 같다. Scalaz 라이브러리나 스칼라로 배우는 함수형 프로그래밍 책, 또는 Haskell 프로그래밍 언어나 Category Theory 책 같은 것을 이용하여 향우에 깊기 파야지 완벽하게 이해할 수 있을 것 같다.

  2장에선는 Lazy Evaluation 에 관한 설명을 한다. Lazy Evaluation을 위한 lazy 키워드나 Stream 클래스를 설명하고, 이를 이용하여 Infinite Sequences를 생성하는 방법을 알려준다. Lazy Evaluation을 이용하면 런타임에서 특정 값을 사용할 때, 필요한 경우에만 값을 계산하여 준비를 한 후 사용하기 때문에, 프로그램의 최적화가 가능하다.

 3장에서는 실무에서 쓰일법 한 프로그래밍인 상태(state)를 주제로 다루고 있다. 논리회로 시간에 배웠던 가산기를 만드는 방법을 Scala 코드로 알려준다. And gate나 Or gate 등을 이용해 Half Adder, Full Adder 등을 조합해서 만드는 방법을 State를 가지고 만든다. 역시 작은 단위부터 큰 단위까지 만들기 위한 점진적인 방법을 사용하는데, 이것이 함수형 프로그래밍의 장점 중 하나인 것 같다.

  마지막 장에서는, 얼마 전에 한참 유행하던 FRP(Functional Reactive Programming)을 우선 다룬다. 기존 Imperative Programming에서 다루던 MVC와 같은 구조는 Muti-Threading 환경에서 동기화 처리를 하기 힘든데, FRP를 사용하면 이런 작업이 아주 편하다는 장점을 알려준다. FRP 의 기본 개념 및 간단한 FRP를 구현하는 방법을 알려준다. 그 뒤에 Future를 중점적으로 다룬다. Future를 설명할 때 에릭 매이어가 오더스키 교수를 대신해 강의를 한다. 마이어는 Microsoft 재직 당시 C#의 RINQ를 만들고, Async이나 Await 같은 동시성 프로그래밍 개념을 만들어 다른 프로그래밍 언어로까지 전파시킨 네임드 개발자이다. 강의가 오더스키 교수 때와는 다르게, 대화를 하는 것 같은 재미있는 상황이 펼쳐졌지만, 오더스키 교수가 구사하던 깔끔한 영어와는 다르기 때문에 약간 알아듣기가 힘들었다. 마이어가 C9에서 Haskell 을 가지고 진행한 함수형 프로그래밍 강의가 있는데, 이 것도 시간이 되면 수강할 예정이다. 강의 마지막에는 Future의 Monad(flatMap) 을 구현하는 방법을 알려주는데, 아직 내공이 부족해서 고개만 끄덕거리고 넘어갔다.

  두 개의 Scala를 이용한 Functional Programming 강의를 들었는데, 책으로 보던 것보다는 내공이 많이 쌓인 것 같다. 좀 더 학문적으로 접근하기 위해 Category Theory는 Functional Programming에서는 필수인 것 같다. 좀 더 내공이 쌓이면 Monad나 Category Theory에 대한 포스팅을 할 예정이다. 또, Functional Programming에 관해 얘기하는 사람들을의 대다수는 SICP에 대해서도 언급을 많이 하고 있다. 봐야할 책과 자료들이 산처럼 쌓이고 있다. 이런 것들을 보다 보면, 좀 더 나은 개발자가 될 수 있다고 믿기 때문에 재미 없을 때까지 계속 산더미를 치워야 겠다.

  2015년에 나온 Scala 언어를 만든 마틴 오더스키의 PT를 녹화한 영상이다.

  PT에서 우선, Scala와 Spark의 구조 관계를 설명한다. 데이터 분석을 위한 Scala 코드는 byte code로 변환되어 Java Runtime이 실행할 수 있는 준비를 한 후, JVM에서 상주하는 Spark Runtime 에서 변환된 byte code를 가져다가 쓰는 형태를 보여주고 있다.

  그리고 Scala와 Spark의 Collection 동작에 대한 차이를 알려준다.  Scala는 collection 동작이 strict하게 실행되지만, Spark 에서는 Action 동작 전까지의 Transformations 동작이 전부 Lazy 하게 동작한다. 이 외에도, Java 8에서 사용하는 Lifted하다는 동작을 소개한다. Lifted의 의미는 기존 collection(예 List)에서  stream() 함수를 호출하여 Collection을 stream 형태로 바꾼 후, 그 뒤에 이뤄지는 동작은 모두 stream 형태로 놔둔다. 그 다음에 collect() 같은 함수를 호출하면 기존에 적용했던 모든 동작들을 처리하고, 다시 기존 Collection으로 복귀한다는 내용이다.

  또, 왜 Spark에서 Python을 사용하지 않고 Scala를 사용하라는 근거를 제시한다. 우선, Python을 위한 wrapping이 많은 자원을 소모한다는 것이다. 그리고, Scala에서의 강한 Type System은 데이터 분석을 할 때, 데이터 타입에 대한 오류를 줄여준다는 것이다. 데이터 사이언티스트가 Python의 동적 타입 시스템을 이해하지 못하거나 Spark의 모든 Collection에 대한 이해가 부족할 경우, Spark를 이용하는데 더 어려움을 겪을 수 있다는 점이다.

  마지막으로, 2015년 당시에 Spark를 이용할 때의 겪을 수 있는 기술적 제약 사항 3가지를 말해준다. Spark에서 Scala Runtime을 재사용하는 것에 대한 문제, Scala 코드에서 Closure를 사용할 때의 문제, 그리고 staging에서의 문제를 언급한다. 현재 Spark 2.0에서 이 부분들이 개선되었는지 문서를 통해 확인해봐야 겠다.

  신 자유주의는 끝났다. 포스트자본주의로(Postcapitalism)의 혁명적인 전환이 현재 진행 중이다. 책을 집필한 폴 메이슨은 영국의 칼럼니스트이다. 이 책은 2015년에 나왔는데, 한국어 번역본은 2017년에 출간되었다. 책이 발표된 후, 보수와 진보, 좌파와 우파 모두에게 극찬을 받았다. 21세기에 마르크스가 다시 나타났다는 견해까지 나왔다.

  책의 1부에서는 기존 자본주의가 왜 실패할 수밖에 없는지에 대한 근거들을 제시하고 있다. 명목화폐의 사용이나 금융 자본주의에 따른 국가 간의 재무 상태 불균형이 심해지는 것을 주요 문제점으로 들었다. 그리고 콘드라티예프의 장기 순환 이론에 따라, 현재 4번째 장기 순환이 이어지고 있는 점을 주장했다. 얼마 전까지는 이 4번째 장기순환이 맞지 않다고 자본주의 경제학자들이 주장했지만, 폴 메이슨은 사회적 무질서 때문에 이 순환 패턴이 늦어지고 있다고 말한다. 저자가 주장한 무질서란 제조업에서 금융업으로의 전환, 노동 계급의 폐배와 파편화, 그리고 금융소득으로 살아가는 최상위 엘리트층이 합쳐진 것이라고 말한다.

  위의 문제점들을 극복하기 위해서 새로운 기술과 경제의 시스템을 만들어야 한다고 2부의 내용을 시작한다. 네트워크, 지식노동, 과학의 응용, 친환경 기술에 대한 집중적인 투자가 포함되어야 한다고 주장한다. 그 예로, 태양열 에너지로 에너지 비용을 무료로 만들고, 3D 프린팅 기술은 제조업의 비용을 무료로 만들며, 오픈소스는 소프트웨어와 관련한 비용을 무료로 만든다는 것이다. 이러한 비용들이 사라지면 기업, 시장, 노동과 임금 등을 중심으로 작동하는 기존 자본주의 시스템이 포스트자본주의로 변화한다는 것이 주 내용이다. 또, 기존의 마르크스나 마르크스에게 영향을 받은 사람들이 주장한 계획경제 시스템이 IT 기술 발전으로 인해 현실적으로 가능하다는 점도 말한다. 재화의 소비나 수요를 예측하고 공급량을 결정하는 시스템을 만들어야 하는데, 기존에는 생산과 공급량을 예측하는데 한 세월이 걸렸지만, 지금은 아주 미세한 부분까지 실시간으로 파악이 가능하여 계획경제 시스템을 만들 수 있다는 근거를 제시한다.

  소프트웨어 개발자로써 오픈소스를 언급한 부분을 자세하게 읽었다. 그 중에 기억에 남는 점은 기업이 저런 변화를 막기 위해 오픈소스 활동을 막을 수도 있다는 것이다. 아니면 오픈소스 활동에 대한 소유권을 기업이 가져갈 수도 있다는 것이다. 최근에 오픈소스는 아니지만, 외부 활동을 금지하여 자신의 활동 범위 축소에 대한 안타까움을 표하는 개발자가 있었다.

  책의 마지막 장인 3부에서는 진짜로 포스트자본주의가 실행될 수 있는지에 대한 의구심을 사라지게 한다. 새로운 전환을 이루기 위한 원동력은 1퍼센트의 엘리트들에 맞선 99퍼센트의 일반 사람들이 뭉쳐야 한다는 것이다. 네트워크를 통한 공유경제를 통해 엘리트들이 아닌 보통 사람들이 이끄는 포스트자본주의가 다가오고 있다고 말한다. 엘리트들의 낙관으로 인해 파괴되는 환경을 보호해야 하는 것도 한 가지 범주에 포함시킨다. 이 외에도 여러 가지 세세한 사항들을 나열하여 저자의 주장을 확고하게 다지고 있지만, 전부 다 기억이 나지 않기 때문에 나머지는 책을 참고했으면 좋겠다.

  작년부터 경제에 관한 책을 읽기 시작했는데, 지금까지 읽었던 책 중에서 계속 두면서 읽어봐야 할 책을 꼽는다면 이 책이라고 말하고 싶다. 4차산업혁명이라고 해서 많은 책들이 나왔는데, 전부 뜬구름 잡는 소리만 하고있는 것 같다. 거시 경제에 관한 책을 좋아하는 사람들은 이 책을 무조건 좋아할 것 같다. 사실 이 책을 읽으면서 막연하게 알고있던 마르크스가 주장한 내용들을 조금 알게 되었다. 자본론 같은 책을 미리 읽었더라면 이 책에서 주장하는 내용들이 얼마나 설득력이 있는지 알 수 있었을텐데 하는 아쉬움이 있다. 자본론을 포함한 경제 책들을 몇 가지 더 읽고난 다음에 이 책을 다시 읽어봐야겠다. 읽어야 할 책은 많은데 시간은 없고, 뭔가 숙제만 더 늘어나서 부담이 생긴다.

  오늘은 대통령 선거 날이다. 문 후보는 사람 중심의 4차 산업혁명을 이루겠다고 주장하고 있다. 문 후보가 포스트자본주의에 관한 내용을 알고 있는지는 모르겠지만, 내일부터 우리 나라가 보통 사람들이 노력하면 원하는 바를 이룰 수 있는 나라가 되도록 만들어주면 좋겠다.

Functional Programming Principles in Scala

  Scala 언어를 만든 마틴 오더스키 교수가 직접 강의하는 MOOC로써, 2012년에 제작된 것으로 추정된다. 강의 하나에 70달러 이상의 가격을 주고 수강을 완료하면 수료증을 받을 수 있다. 이 수료증은 Linked in 에 연동이 가능하다. 수료증이 필요하지 않으면 무료로 강의를 들을 수 있다. 나의 경우에는 돈을 주고 수강을 해야 돈이 아깝다고 생각하여 열심히 공부를 하는 스타일이므로, 이 강의 외에도 패키지로 수강할 수 있는 강의 5개를 한꺼번에 결제하여 10%의 할인을 받았다.

  내가 처음 Scala 언어가 있다는 것을 알고 공부를 시작한게 2016년이니, 참으로 늦게 시작한 것 같다. 함수형 프로그래밍이나 Scala, Haskell 에 대한 것이 있다는 것을 진작부터 알았으면 하는 아쉬움이 있다. 프로그래머로써 어떻게 공부를 해 나가야할 지 몰랐던 나의 미숙한 점도 있지만, 회사에서 프로그래머로써의 실력을 증진시키지 않는 회사 주변의 상사나 동료들 탓도 있는 것 같다. 결정적으로 Tizen Platform App 개발과 현업에서 전혀 사용하지 않는 아주 미세한 부분을 다루는 알고리즘 시험을 채택한 회사 때문에 저런 것들을 늦게 접한 면도 있다.

  이 강의에서는 일반적인 책에서 배울 수 있는 Scala에 대한 내용을 주로 다루고 있다. Currying이나  Higher-Order-Function, 각종 Collection (List, Set, Map 등), Pattern Matching 등이다. 이론을 설명할 때 위에 언급한 것들을 단순히 어떻게 사용하는지만 알려주는 것이 아니라, 구체적인 사례를 들거나 이론에 대한 원리를 알려주는 점이 아주 좋았다.

  이론 강의 수강 외에도 각 주차별 강의에 따른 실습 과제를 해야 이 과정을 이수할 수 있지만, 예전에 다른 강의에서 했던 별도의 시험은 없었다. 실습은 Scala 빌드 도구인 SBT(Simple Build Tool) 프로젝트로 제공한다. 위에서 배운 이론을 토대로, 실제 현업에서 다룰 법한 문제나 커먼하게 알려진 알고리즘(허프만 코딩, 아나그램)을 구현하는게 주 목적이었다.

  과제를 하면서 두 가지 깨닮음(?)을 얻었다. 먼저, Scala의 Pattern Matching이 아주 강력한 기능이라는 점이다. 내가 전에 알고있던 패턴 매팅은 단순히 Int, String 타입과 같은 Primitive 타입을 편하게 다루기 위한 것인데, 이 것은 패턴 매칭의 아주 일부분이었다. 각종 Object나 Tuple, Collection을 패턴매칭과 각종 Recursive 패턴 등을 이용하여 조합해서 사용하면, Java 에서는 찾아볼 수 없는 추상화가 가능하다.

  두 번째로 느낀 점은, 바로 기존의 Object를 다루기 위한 Set(자료구조 Set이 아닌, 특정한 데이터 집합을 다룬다는 의미)과 동일하게 사용할 수 있도록 Functional Set을 다루는 방법과 그 원리를 과제를 통해서 알게 되었다. 이 것이 함수형 프로그래밍의 강력한 추상화에 도움을 주는 것 같다. 말로는 설명하기가 힘드니, 이 강의를 참고하길 바란다.

  이 강의에서는, 함수형 프로그래밍의 깊은 원리에 대해서는 파해치지 않고, 다음 강의인 [Functional Program Design in Scala] 로 떠넘겼다(?). 내가 MOOC를 통해서 정말로 습득하기 원하는 이론인 Monad를 다루고 있다. 지금 이 포스팅에서 설명하고 있는 강의는 Scala나 Functional Programming을 처음 접하는 분들이나 Scala를 책으로 공부하는데 명확하게 이해가 되지 않는 분들에게 추천하고 싶다.

[마이크로서비스의 원칙]

1. 비즈니스 개념에 따른 모델

  인터페이스 안정성 : 비즈니스 경계로 나눔 > 기술적 개념에 맞춤

  시스템이 동작하는 도메인을 모델링 -> 더 안정적인 인터페이스 형성

  비즈니스 프로세스의 변경을 더 쉽게 반영 가능

2. 자동화 문화의 적용

  다루어야 하는 변경되는 부분의 수만으로도 복잡성이 증가

  자동화 테스팅이 매우 중요

  일관된 명령 호출 = 어디에서나 같은 방식으로 배포 + 지속적 배포

  환경 정의, 커스텀 이미지, 불변 서버 등을 사용

3. 내부 세부 구현의 은폐

  경계가 있는 콘텍스트로 모델링 -> 공유되고 은폐되어야 하는 모델에 집중하게 도움

  DB통합과 같은 결합 문제에 빠지지 않도록 데이터페이스도 감추어야 함

  데이터 펌프 or 이벤트 데이터 펌프 -> 리포팅 목적으로 여러 서비스로부터 데이터를 통합

  기술 중립적 API (REST)

4. 모든 것을 분권화

  셀프 서비스 : 요구할 때 언제든 배포, 개발과 테스팅을 가능한 쉽게, 별도의 팀이 이러한 활동을 수행할 필요가 없게

  팀이 변경 및 변경 릴리즈 시점까지도 스스로 결정하게 하여 팀이 그들의 서비스를 소유하도록 보장

  내부 오픈 소스를 이용하면 다른 팀이 소유한 서비스를 변경할 수 있지만 구현이라는 부가적인 일이 생긴다는 점을 기억

  콘웨이의 법칙이 효과가 있도록 팀을 조정

  공유 거버넌스 모델 : 각 팀의 사람들이 시스템의 기술 비전을 진화시킬 책임을 집단으로 공유

  코레오그래피 아키텍처 : 서비스 경계 내에서 로직과 데이터 연관성을 보장하는 영리한 엔드포인트로 응집력을 유지 (오케스트레이션과 멍청한 미들웨어는 사용하지 않음)

오케스트레이션(orchestration)

- 오케스트라 지휘자처럼 프로세스를 아내하고 구동하는 하나의 중앙 두뇌에 의존

- 고객 서비스에 지나치게 많은 중앙 관리 권한이 부여되는 단점

- 매우 취약하고 높은 변경 비용 수반

코레오그래피(choreography)

- 발레 무용수들이 자신의 역할을 알고 주변의 다른 무용수에 반응하는 것처럼 시스템 각 부분에 작업 내용을 알리고 세부 사항을 수행

- 비동기 방식으로 이벤트 발산을 통해 느슨한 결합을 이끔

5. 독립적인 배포

  클라이언트 호환성을 깨는 변경이 필요할 때 시간을 두고 변경할 수 있도록 여러 버전의 엔드 포인트가 공존되도록 해야 함

  RPC 기반의 통합을 한다면 Java RMI와 같은 강력히 결합된 클라이언트/서버 스텁의 생성은 피해야 함

  호스트당 단일 서비스 모델 적용

  청색/녹색 or 카나리아 릴리스 기법 : 잘못된 릴리스의 위험을 줄이며 릴리스와 배포를 분리

  소비자 주도 계약 : 호환성을 깨뜨리는 변경을 미리 발견

6. 장애 격리

  원격 호출을 지역 호출처럼 처리하면 안됨 - 지나치게 추상화한 클라이언트 라이브러리 사용 X

  안티프래질, 타임아웃, 격벽, 회로차단기

  네트워크 파티션이 함축하는 것과 주어진 상황에서 가용성과 일관성 중 어느 것을 희생하는 것이 옳은 판단인지 알아야 함

7. 매우 식별 가능한

  합성(가상) 트랜잭션을 주입함으로써 실사용자의 행위를 모의하는 유의적 모니터링을 사용

  로그와 통계를 수집

  시스템 간 모든 호출을 추적할 수 있도록 상관관계 ID 사용

[언제 마이크로서비스를 사용하지 않아야 하는가?]

1. 해당 분야를 제대로 이해하지 못할 때 : 경계가 있는 콘텍스트를 찾기 힘듦

2. 미개발 분야의 개발 : 모놀리식으로 시작하고 안정화되면 분해!

ref) 마이크로서비스 아키텍처 구축

  Akka project에서 reference.conf를 /resources 디렉토리가 아닌 곳으로 설정할 때 아래 stackoverflow 질문과 같은 Exception을 마주칠 때가 있다.

http://stackoverflow.com/questions/31011243/no-configuration-setting-found-for-key-akka-version

  reference.conf 파일을 각 akka 모듈 안에 있는 reference.conf 파일을 지정하지 못하도록 shadow plugin을 이용해야 한다.  Akka Document에는 Maven에 대한 내용만 아래와 같이 나와있다.

http://doc.akka.io/docs/akka/snapshot/general/configuration.html#When_using_JarJar__OneJar__Assembly_or_any_jar-bundler

  Project Build Tool을 Gradle로 이용하고 있는데, Gradle에서 shadow plugin을 사용한 예제가 구글에서 찾기 힘들어 직접 만들어보고 github에 공유했다.

https://github.com/simjaemun2/akka_gradle_shadow

http://book.naver.com/bookdb/book_detail.nhn?bid=11295275

알고리즘의 바이블로 통하는  [Introduction to Algorithms] (이하 CLRS)의 저자 토머스 코멘이 집필했다.

기존 CLRS 책은 컴퓨터 사이언스 전공자를 위한 책이었다면, 이 책은 다양한 성향을 가진 독자를 생각해서 만든 책이라고 한다.

하지만, 수학에 관심이 없다면 읽기가 아주 힘들 것이다. 대부분의 내용을 CLRS에서 가져왔기 때문에 딱딱하기 때문에 알고리즘 입문자를 위한 책이 아니라고 생각한다.

대학교 때 알고리즘 스터디 때 CLRS 책을 봤었던 기억을 되살리면서 책을 읽기 시작했다. 그래도 CLRS 책보다는 비교적 알고리즘에 관한 사설이 많이 들어가있고, 어려운 알고리즘에 대한 부분도 들어가있지 않다.

중간에 Counting sort, Radix sort에 대한 나오는데, 이 정렬들은 같은 크기의 value 가 정렬될 때, 배열 안에서 등장하는 순서를 유지해주는 Stable sort라고 한다. 이 사실을 미리 알았더라면, 예전에 사내 알고리즘 시험에서 Radix sort를 바로 적용하여 문제를 해결할 수 있었을 것이라는 아쉬운 생각이 들었다.

마지막에 등장하는 NP-complete 알고리즘 관련 부분은 역시나 CLRS 책을 봤을 때와 마찬가지로, 이해하기가 무진장 어렵다. 결국 이 부분은 대충 읽고 넘겼다.

Scala toy project 때문에 당분간 알고리즘 공부는 BOJ 문제 중, 쉬운 문제를 푸는 정도로만 유지할 것이다. 나중에 알고리즘 공부를 심도있게 하기 위해 CLRS 책을 다시 봐야할 것 같다.

BOJ 2186 문자판

https://www.acmicpc.net/problem/2186

https://github.com/simjaemun2/BaekJoon/blob/7cc49b8b63da5b0eb628409949adcfe994425ac0/BOJ2186/BOJ2186.cpp

DP

난이도 : H

단순 DFS인줄 알았으나, DP를 이용하지 않으면 시간초과가 발생