Reactive Extensions, to write async, event-based programs with observables

Hello World in Reactive way

Reactive Programming is “a programming paradigm oriented around data flows and the propagation of change” (wikipedia)

With Reactive Extensions (Rx), you can write asynchronous and event-based programs using observable sequences. Rx let you represent asynchronous data streams with Observables, (push-based notifications) and query asynchronous data streams using LINQ, Simply put “Rx = Observables + LINQ + Schedulers”.

You can install the package via nuget.

pm> Install-Package Rx-Main

Channel9 has a concise introduction video: Rx Workshop Introduction. The simplest “Hello, World” can be done in this way.

class Program
    static void Main(string[] args)
        var streamOfChars = "Hello, World".ToObservable();
        streamOfChars.Subscribe(c => Console.WriteLine(c));

Another simple example is to enumerate from 1 to 10 and subscribe to it.

IObservable<int> source = Observable.Range(1, 10);
IDisposable subscription = source.Subscribe(
   x => Console.WriteLine("OnNext: {0}", x),
   ex => Console.WriteLine("OnError: {0}", ex.Message),
   () => Console.WriteLine("OnCompleted"));

Console.WriteLine("Press ENTER to unsubscribe...");

Cold vs. Hot Observables

Cold observables start running on subscription, that is, it starts pushing values to the observables when Subscribe is called. This doesn’t fit in the real-world case, like stock tickers, which should be producing values even before a subscription is active. The observer that subscribes to a hot observable sequence, get the current value in the stream.

Console.WriteLine("Current Time: " + DateTime.Now);
var source = Observable.Interval(TimeSpan.FromSeconds(1));
//creates a sequence

IConnectableObservable<long> hot = Observable.Publish<long>(source);  
// convert the sequence into a hot sequence

IDisposable subscription1 = hot.Subscribe(                        
    x => Console.WriteLine("Observer 1: OnNext: {0}", x),
    ex => Console.WriteLine("Observer 1: OnError: {0}", ex.Message),
    () => Console.WriteLine("Observer 1: OnCompleted"));
Console.WriteLine("Current Time after 1st subscription: " + DateTime.Now);
Thread.Sleep(3000);  //idle for 3 seconds
// hot is connected to source and starts pushing value to subscribers 

Console.WriteLine("Current Time after Connect: " + DateTime.Now);
Thread.Sleep(3000);  //idle for 3 seconds
Console.WriteLine("Current Time just before 2nd subscription: " + DateTime.Now);

// value will immediately be pushed to 2nd subscription
IDisposable subscription2 = hot.Subscribe(     
    x => Console.WriteLine("Observer 2: OnNext: {0}", x),
    ex => Console.WriteLine("Observer 2: OnError: {0}", ex.Message),
    () => Console.WriteLine("Observer 2: OnCompleted"));

An example from MSDN.

Reactive Extensions, to write async, event-based programs with observables

git cherry-pick

Git commit’s id is a hash of its contents and its history, and becomes a unique id for a specific commit. Even if it contains the same change, as the parent would be different, it’ll have a different id.

“git cherry-pick” takes a commit from somewhere else, and “play it back” where you are right now. Git will build a new commit with a different hash, as the parents are different, though the contents are the same. One thing to note is that git hash is branch agnostic. in Git, an branch is simply “a lightweight movable pointer to one of these commits” (from git branching)

The other day, I rebuilt a release branch for release (of course!). I had to fix one issue, so committed the fix to the release branch. I made a few other changes and revoked the change, as they were not really necessary. Now I wanted to cheery-pick the commit for the fix.

I did git log.

C:\Users\andrew.chaa\Documents\Projects\PopOpen [release]> git log
commit 36bfde24c821f36f84c6ec88c796ae6edac17286
Author: andrewchaa <>
Date: Wed May 13 15:45:34 2015 +0100
the version is updated to 0.8.6

commit 8c803f203a03b9bd11faca7a754e0f1f4c8ab1b3
Author: andrewchaa <>
Date: Tue May 5 11:23:34 2015 +0100
Added Logging. No more fixed time looping. Use MainWindowTitle and check if the found window has the same fil

I know the commit hash, 8c803f203a03b9bd11faca7a754e0f1f4c8ab1b3.

git checkout master
git cherry-pick 8c803f203a03b9bd11faca7a754e0f1f4c8ab1b3

Then the change is on top of the last commit on the master branch. I can push the change to the server.

git cherry-pick

HATEOAS RESTful service

HATEOAS stands for Hypermedia as the Engine of Application State. It’s a concept I encountered about 5 years ago, in an after work technical talk that was held in the old ThoughtWorks London office near Holborn.

HATEOAS is one of REST application architecture constraints that a client should interacts with a network application entirely through hypermedia provided dynamically by application servers.

cf). REST has the following 4 constraints.

  • Identification of Resource (typically by using a URI)
  • Manipulation of Resources through Representation
  • Self-descriptive message
  • Hypermedia as the engine of the Application STate

This an example of HATEOAS-based response.

    "name": "Mad Max",
    "links": [ {
        "rel": "self",
        "href": "http://localhost:8080/customer/1"
    } ]

A REST client needs no prior knowledge about how to interact with any particular application or server beyond a generic understanding of hypermedia. By contrast, in a service-oriented architecture (SOA), clients and servers interact through a fixed interface shared through documentation or an interface description language(IDL).

  • rel means relationship. In this case, it’s a self-referencing hyperlink.
  • href is a complete URL that uniquely defines the resource.

Although the example shown is in JSON, XML is also a standard response format. HATEOAS doesn’t impose the requirement of either format. The hypermedia links are the focus.

Let’s look at more complex relationships. (from Spring Data Book)

    "content": [ {
        "price": 499.00,
        "description": "Apple tablet device",
        "name": "iPad",
        "links": [ {
            "rel": "self",
            "href": "http://localhost:8080/product/1"
        } ],
        "attributes": {
            "connector": "socket"
    }, {
        "price": 49.00,
        "description": "Dock for iPhone/iPad",
        "name": "Dock",
        "links": [ {
            "rel": "self",
            "href": "http://localhost:8080/product/3"
        } ],
        "attributes": {
            "connector": "plug"
    } ],
    "links": [ {
        "rel": "",
        "href": "http://localhost:8080/product/search"
    } ]

Richardson Maturity Model states that HATEOAS is Level 3, the final level of REST

HATEOAS RESTful service

이민, 새로운 기회와 도전

“당신의 미국 이민이 망하는 다섯 가지 이유” 제목의 슬로우 뉴스 기사를 트위터를 통해 접하고는 잠깐 “광분” 했었다. 그럴꺼 까지는 없었는데. 문든 옛 생각이 났다. 대학원 가기 전, 준비를 위해 석사 1년차이던 선배에게 조언을 구했던 일이. 선배의 답변에 너무 놀랬었다. “야 넌 이길로 오지 마라. 사람이 할 짓이 아니다” 왜 그 선배는, 적어도 내가 보기에는, 석사 과정을 잘 하고 있었으면서도, 후배의 기를 팍 죽이는 말들을 내뱉었던걸까? 그후, 사회생활을 통해, 여러 부류의 사람들을 만나면서 좀 더 이해하게 되었다. 걔 중에는 자신이 가고 있는 길이 얼마나 힘들고 어려운지를 강조함으로써 자신을 높이려는 사람들이 있다는 것을.

좀 흥분이 가라앉은 후, 곰곰히 생각해 봤다. 왜 내가 저 글을 싫어하는지.

첫째는 그 선배 기억이 나서였고, 둘째, 내 경우, 이민을 통해 망하기보다 흥한 경우인데, 저 글이 이를 부정하고 있기 때문이었다.

외국 이민은 국내에서 접할 수 없는 새로운 기회와 경험을 가져다 준다. 전에 Barclays의 Pricing team에서 다른 Quant 들과 일할 때 였다. 나야 Quant팀에 Quant가 아니라 개발자로, 뒷문으로 들어간 격이기 때문에 별 생각이 없었는데, 한국에 방문했을때, 내 직장을 얘기하면 갑자기 나를 쳐다보는 사람들의 눈빛이 달라지는 것을 느꼈다. 그 유명한 Barclays라니. 그 것도 Quant 팀이라니 등등.

런던에 개발자로 일하면서 이곳의 금융기관에서 일하는게 그렇게 어려운 일은 아니다. HSBC도 있고 Credit Suisse도 있고, Barclays, Santander, 등등. 하지만, 만약 내가 한국에 있덨다면, 한국의 개발자 였다면… 정말 실력있는 개발자들 한국에 많지만, 내가 그만큼의 실력이 없어도, 단지 런던에서 개발자로 경력을 쌓아가고 있다는 이유만으로 그런 곳에서 일할 수 있는 기회가 주어진다.

어제 Sam Newman이 Microservice에 얘기하는 강연에 갔다왔다. 궁굼한 것 질문도 해볼 수 있었고.

Embedded image permalink

내가 학부시절 공부했던 Programming Windows with MFC, 2nd edition을 썼던 Jeff Prosise도 런던에서 만났다. 함께 사진도 찍었다. Uni시절에 당신 책으로 공부했었다면서.

이런 기회는 내가 열심히 하냐 안하냐의 노력으로 주어지는게 아니라, 그냥 런던에 살기 때문에 주어지는 기회이다. Sam Newman이 한국가서 강연할 기회가 얼마나 있겠나.

런던의 개발자들, 한국의 개발자에 비하면 2배 이상 받는 느낌이다. 물론 물가도 두배정도 비싸지만. 런던의 버스 기사가 인도의 버스 기사랑 역랑이 비슷하더라도 월급은 몇 배이상 받는 것처럼, 단순히 런던에서 일하기 때문에, 나 역시 나보다 훨씬 실력있는 한국의 개발자들 보다 더 많은 월급을 받고 있다. 6시면 퇴근이고, 요즘 2주간은 아이들 학교 데려다 주느라 10시까지 출근한다. 이 역시 나의 노력여부에 따른 보상이 아니라, 내가 그냥 런던에서 일하기 때문이다.

사람들이 모이는 곳에 기회가 있다. 그래서 한국에 살면 다들 서울로 가려고 하는 것처럼, 세계를 대상으로 보면, 그 가운데, 마치 세계의 수도처럼 사람들이 모이는 곳이 있다. New York이라든지, 개발자라면 실리콘 밸리라든지. 그런곳에 가면, 물론 어려운 점들도 있지만, 가지 않았을 경우, 꿈도 꾸기 어려운 기회들이 너무나도 쉽게 접하게 된다.

그런점에서 난 이민을 적극 추천한다. 특히 한국처럼 기회가 없는 사회에서 기회에 목말라 하며, 저임금, 불안한 일자리에 매여 있는 청년들에게 외국 생활은 새로운 돌파구가 될 수 있다.

“당신의 미국 이민이 망하는 다섯가지 이유” 내게는 “당신이 서울로 이사가면 망하는 다섯가지 이유”처럼 들린다.

이민, 새로운 기회와 도전

NuGet restore

NuGet is a package manager like NPM for node.js or Gem for Ruby, and it is a dominant one in .NET.

You can handle dependency packages in two ways. You download them from NuGet server but also store them in your source control. Or, you just remember what packages you use in your project, and restore them on build. Node and Ruby guys always go for the 2nd option. .NET people used to do the first one, but now prefer the 2nd option. I agree to the 2nd option, restoring packages on build, rather than storing them in git repository. Git is for source code, NuGet repository is for packages.

The Visual Studio on my work machine isn’t set up for NuGet restore. “Restore” option is disabled, and when I download and build an open-source project, it can’t restore the packages and can’t build the solution.

I’ve checked if there’s work-around. It seems that the latest NuGet.exe can restore packages in command-line, regardless of your VS settings, which makes sense to me, as NuGet shouldn’t depend on the settings of your IDE. So update NuGet.exe to the latest.

exec { .\Tools\NuGet\NuGet.exe update -self }

Create an environmental variable, EnableNuGetPackageRestore, to true, but just for Process, not for Machine, not to impact other projects.

[Environment]::SetEnvironmentVariable("EnableNuGetPackageRestore", "true", "Process")

Then, you can safely restore your packages in command-line.

exec { .\Tools\NuGet\NuGet.exe restore ".\Src\$name.sln" | Out-Default } "Error restoring $name"

So, all the code in one place

Write-Host "Restoring"
[Environment]::SetEnvironmentVariable("EnableNuGetPackageRestore", "true", "Process")
exec { .\Tools\NuGet\NuGet.exe update -self }
exec { .\Tools\NuGet\NuGet.exe restore ".\Src\$name.sln" | Out-Default } "Error restoring $name"
NuGet restore

Posh Git shows the current branch and the state of files in powershell prompt

It’s a set of PowerShell scripts that gives Git integration in PowerShell prompt.

The first thing you notice once you install it, is that it can show the current branch and the state of files, additions, modifications, and deletions within.

Another nice feature is tab completion.

For example,

git ch<tab> --> git checkout

You can install it via PsGet

Install-Module posh-git
Posh Git shows the current branch and the state of files in powershell prompt

Node.js의 힘, npm

Node.js, 이제는 모르는 사람이 없는 서버쪽 자바 스크립트 프로그래밍 언어 및 환경.

작년부터 Node.js를 개인 프로젝트에 조금씩 써보다가 이제는 거기에 꽂혀서 모든 개인 프로젝트를 Node.js로 하고 있다. 그런데 계속 쓰다보니, 이 npm이란 놈이 여간 기특하지 않은거다. Node Package Manager, 말 그대로 Node 관련 모든 패키지들이 모인 곳인데, 그야말로 무궁무진한 패키지들이 있다. 전에 Ruby 개발자들과 만나서 얘기할 때, 그 친구들이 농담식으로 “코드짜다는 일의 대부분이 패키지를 찾아서 설치하고 그걸 이용하는 것” 이라고 말하는 걸 들었는데, Node를 쓰면서 정말 실감이 난다. 웹 프로그래밍을 하려면 Express.js를 찾아 설치하고, 각종 미들웨어들을 설치한다. 로깅이 필요하면, bunyan이나 winston을 설치하고, azure-table storage를 설치해서 데이터를 저장하고 (회사 MSDN 계정에서 매달 Azure를 공짜로 쓸 수 있는 금액을 충전해줘서) 등등.

그런데 계속해서 npm에서 이것 저것 찾아서 쓰다보니, 점점 내가 만드느 코드들도 패키지 비슷하게 되어간다. C#에서는 그냥 Helper나 Util 등의 폴더에 넣어 쓰고말 코드를 패키지처럼 만들게 되고, 또 만들다 보면, 이걸 npm에 올려 공유하고 싶어진다. 함수가 어느정도 복잡해지면, 이제 이를 패키지로 만들고 싶어진다. 패키지가 일반적인 추상화 (Abstraction)의 패턴이 된다. 이는 C#으로 코딩할 때는 깨닫지 못하던 패턴이다.

RubyGems와 Ruby가 한 몸 이듯이 npm이 없다면 Node.js 역시 없다는 생각이 든다

Node.js의 힘, npm