vert.x는 현재 가장 뜨겁게 부상하고 있는 서버 프레임워크입니다. 모든 서버 프레임워크가 그렇듯이 고성능과 다양한 프로토콜 지원을 장점으로 내세우고 있습니다. vert.x는 여기서 한 발 더 나아가 서버 네트워크 환경을 구축하고 운영하는 환경까지도 고려하고 있습니다. 즉, vert.x는 하나의 ‘서버 프로세스 데몬’을 제작하는 것뿐만 아니라, 클러스터링 환경에서 동작하는 여러 서버 프로세스 데몬을 제작하는 방법에 대한 고민까지 담고 있습니다.

그렇기 때문에 vert.x가 어떤 방식으로 고성능을 내고 있는지, 어떤 네트워크 환경을 고려하고 있는지 충분히 시간을 들여 알아볼 가치가 있다고 할 수 있습니다.

vert.x의 철학

vert.x는 Node.js로부터 영향을 받은 프로젝트다. vert.x는 Node.js처럼 Event-based 프로그래밍 모델을 제공하는 서버 프레임워크다. 그렇기 때문에 vert.x의 API는 Node.js와 매우 유사하다. 둘 모두 비동기 형태의 API를 제공한다.

Node.js는 JavaScript로 만들어졌지만, vert.x는 Java로 제작되었다. 하지만 vert.x를 Node.js의 Java 버전이라고 이해하기에는 무리가 있다. vert.x가 Node.js로부터 영향을 받은 것은 사실이지만, vert.x는 Node.js와 다른 고유한 철학을 가지고 있기 때문이다.

대표적인 vert.x의 설계 철학을 정리하면 다음과 같다.

Polyglot – 여러 언어 지원
vert.x 자체는 Java로 작성되었지만, vert.x를 사용하기 위해 반드시 Java를 사용할 필요는 없다. Java나 Groovy 같이 JVM 동작을 전제로 한 언어 뿐만 아니라 Ruby나 Python, 심지어 JavaScript로도 vert.x를 이용할 수 있다. JavaScript로 꼭 서버 애플리케이션을 만들어야 한다면, Node.js만이 유일한 대안이 아니게 되는 것이다. 향후 Scala와 Closure도 지원할 계획이다.
Super Simple Concurrency model
vert.x로 서버 애플리케이션을 작성할 때, 사용자는 싱글 스레드 애플리케이션을 작성하듯 코드를 작성해도 괜찮다. vert.x는 사용자가 작성한 코드가 동일한 스레드에서만 실행됨을 보장해서 더 이상 synchronized나 volatile 같은 동기화를 위한 locking 처리를 신경 쓰지 않아도 된다.
Node.js에서는 JavaScript 실행 엔진 자체가 멀티 스레드를 지원하지 않으므로 모든 CPU 코어를 활용하려면 같은 JavaScript 프로그램을 여러 개 실행해야 했다. 하지만 vert.x에서는 하나의 프로세스만 가동해도 CPU 코어 개수에 맞춰 멀티 스레드가 생성될 수 있다. 멀티 스레드와 관련된 작업은 vert.x가 하고, 사용자는 비즈니스 로직 구현에 집중할 수 있게 한 것이다.
Event Bus 제공
도입 부분에서 설명했듯이 vert.x의 목표는 ‘하나의 서버 프로세스 데몬’을 만드는 것에 그치지 않는다. vert.x로 만든 여러 서버 프로그램이 서로 원활하게 통신하게 하는 것까지도 목표에 두고 있다. 이를 위해 vert.x는 Event Bus를 제공한다. Point to Point나 Pub/Sub 같은 MQ 기능을 사용할 수 있다(Event Bus 기능을 제공하기 위해 vert.x는 Hazelcast라는 IMDG를 사용한다). 이런 Event Bus가 있기 때문에 서로 다른 언어로 작성된 서버 애플리케이션이 용이하게 통신할 수 있다.
Module System & Public Module Repository
vert.x에는 모듈 시스템이라는 것이 있다. 모듈 시스템은 일종의 컴포넌트로 이해할 수 있다. vert.x로 만든 서버 애플리케이션 프로젝트 자체를 모듈화한 것이다. 이런 방식으로 재사용성을 도모한다. 이렇게 만들어진 모듈은 Public Module Repository에 등록할 수 있다. Public Module Repository를 통해 모듈을 공유할 수 있는 것이다.

참고) Netty와 vert.x의 관계

vert.x의 성능을 논하기 전에 Netty와 vert.x의 관계를 정리할 필요가 있다. vert.x는 Netty를 사용한다. 즉, 다중 I/O 처리에 Netty를 사용한다. 그렇기 때문에 vert.x와 Netty의 성능 차이를 확인하는 것은 무의미하다.
vert.x는 Netty와는 다른 독자적인 API와 기능을 제공하는 다른 목적의 서버 프레임워크다. Netty는 로우레벨 수준의 I/O를 다룰 수 있는 프레임워크고, vert.x는 그보다는 하이레벨 영역을 다룬다.

Node.js와의 성능 비교

vert.x가 제공하는 기능이 Node.js와는 다르더라도 둘 사이의 성능을 비교하는 것은 충분히 의미 있는 일이다. 그림1과 그림2는 vert.x(Java, Ruby, Groovy)와 Node.js의 성능을 비교한 자료다(출처:http://vertxproject.wordpress.com/2012/05/09/vert-x-vs-node-js-simple-http-benchmarks/).

그림 1은 HTTP 서버를 만들고 200/OK 응답만을 주었을 때의 성능을 비교한 결과다. 그림 2는 72 바이트 크기의 정적 HTML 파일을 응답 결과로 제공하는 경우에 성능을 비교한 결과다. vert.x 제작자가 밝힌 성능이고 스스로도 엄격한 환경에서 실시한 테스트가 아니므로 상대적인 성능 격차에만 주목하는 것이 좋을 것으로 보인다.

그림 1 200/OK 응답만 주었을 때의 성능 비교

그림 2 72바이트 크기의 정적 파일 제공 성능 비교

주목할만한 점은 Node.js보다 vert.x-JavaScript의 성능이 좋다는 것이다. 이 성능 비교 결과가 신뢰성이 매우 높다고 하더라도, 단순히 Node.js에 비해 vert.x가 낫다고 말하기는 어려울 수 있다. Node.js는 Socket.io와 같은 훌륭한 모델을 제공하고 있을 뿐만 아니라, 많은 레퍼런스를 확보하고 있기 때문이다.

vert.x 용어들

vert.x는 vert.x만의 고유 용어를 정의하거나, 일반적인 용어를 vert.x에서 다시 정의해서 사용하기도 한다. vert.x를 잘 이해하려면 vert.x가 정의한 용어를 잘 이해해야 한다. vert.x에서 사용하는 대표적인 용어를 정리해 보았다.

Verticle

vert.x에서 배치(deploy)의 기본 단위다. Java의 경우라면 main 메서드가 있는 클래스가 된다. Verticle은 또한 main 메서드에서 참조되는 다른 스크립트를 포함할 수 있다. .jar 파일이나 리소스를 포함할 수 있다. 애플리케이션은 하나의 Verticle로 이루어질 수도 있고, event bus를 통해 서로 통신하는 여러 개의 Verticle로 이루어질 수도 있다. Java로 생각하면 독립적으로 실행 가능한 Class 또는 .jar 파일로 이해할 수 있겠다.

vert.x 인스턴스

Verticle은 vert.x 인스턴스 안에서 실행되고, vert.x 인스턴스는 자신의 JVM 인스턴스 안에서 실행된다. 단일 vert.x 인스턴스 안에서는 동시에 실행되는 많은 Verticle이 존재할 수 있다. 각각의 Verticle은 고유의 클래스 로더를 가질 수 있다. 이로 인해 Verticle 간에 스태틱 멤버, 글로벌 변수 등을 통한 직접적인 상호작용을 막을 수 있다. 네트워크상의 여러 호스트에서 동시에 많은 vert.x 인스턴스가 실행될 수 있고 event bus를 형성해서 vert.x 인스턴스 간에 클러스터링되도록 설정할 수 있다.

동시성(concurrency)

Verticle 인스턴스는 항상 동일한 스레드에서 실행됨이 보장된다. 모든 코드를 단일 스레드 동작 형태로 개발할 수 있기 때문에, vert.x를 사용하는 개발자에게 개발하기 편한 환경을 제공하는 것이라 할 수 있다. 게다가 레이스 컨디션이나 데드락이 발생하지 않게 할 수도 있다.

Event-based Programming Model

vert.x는 Node.js 프레임워크와 비슷하게 Event-based 프로그래밍 모델을 제공한다. vert.x로 서버 프로그래밍을 할 때 개발해야 하는 코드의 대부분은 이벤트 핸들러에 관한 것이다. 예를 들어, TCP 소켓으로부터 데이터를 수신하기 위해 핸들러를 설정하는 것이나 데이터가 도착할 때 호출될 핸들러를 제작하는 것이다. 이외에도 ‘Event bus에서 메시지를 수신할 때’, ‘HTTP 메시지를 수신할 때’, ‘커넥션이 종료되었을 때’, ‘타이머가 종료 되었을 때’ 알림을 받기 원한다면 핸들러를 작성하면 된다.

Event Loops

vert.x 인스턴스는 내부적으로 스레드 풀을 관리한다. vert.x는 가급적 스레드 풀의 개수를 CPU 코어 수와 일치할 수 있게 한다.

그리고 이 각각의 스레드에서는 Event Loop를 실행한다. Event Loop란 확인해야 할 이벤트를 루프(loop)를 돌면서 확인하는 것이다. 가령 소켓에 읽을 데이터가 있거나, 어떤 타이머에 이벤트가 발생했는지 확인하는 것과 같은 것들이다. 루프를 돌다가 처리해야 할 이벤트가 있다면, 해당 핸들러를 호출하는 방식으로 vert.x가 동작한다(물론 이때 핸들러 처리 시간이 길다거나 블로킹 I/O가 있다거나 할 때는 별도의 작업이 필요하다. 다음 게시글에서 소개할 예정이다.).

Message Passing

Verticle 간의 통신은 Event Bus를 이용한다. Verticle을 actor라고 생각하면, Message Passing은 Erlang 프로그래밍 언어에서 유명해진 actor 모델과 유사하다. vert.x 서버에서는 많은 Verticle 인스턴스 생성 및 이들 간의 message passing을 통해 Verticle 코드에 대한 멀티 스레드 실행이 없이도 사용 가능한 코어에 맞게 시스템 확장이 가능하다.

Shared data

Message passing이 매우 유용하긴 하지만 모든 종류의 애플리케이션 동시성 상황에서 최고의 접근 방법은 아니다. 캐시가 대표적인 예다. 어떤 캐시를 어느 하나의 Verticle만 가지고 있다면 매우 비효율적이 된다. 이 캐시가 다른 Verticle에도 필요한 내용이라면 Verticle이 각각 같은 내용의 캐시 데이터를 관리하여야 하기 때문이다.

그렇기 때문에 vert.x는 전역에서 접근할 수 있는 방법을 제공한다. 바로 Shared Map이다. 그리고 Verticle 사이에서는 오직 불변(immutable) 데이터만 공유되게 하고 있다.

vert.x Core

이름 그대로 vert.x의 핵심 기능이다. Verticle에서 직접적으로 호출될 수 있는 기능은 모두 이 Core에 담겨있다. 당연하게 이 Core는 vert.x가 지원하는 프로그래밍 언어 API에서 접근할 수 있다.

vert.x 아키텍처

vert.x의 대략적인 아키텍처는 다음 그림과 같다.

그림 3 vert.x 아키텍처(원본 출처: http://www.javacodegeeks.com/2012/07/osgi-case-study-modular-vertx.html)

vert.x의 기본 실행 단위는 Verticle이고 동시에 여러 Verticle이 하나의 vert.x 인스턴스에서 실행될 수 있다. Verticle은 Event-Loop 스레드에서 실행된다. 하나의 호스트는 물론 네트워크상의 다른 여러 호스트에서 여러 vert.x 인스턴스가 실행될 수 있는데, 이때 Verticle이나 Module 간에는 Event Bus를 통해 통신할 수 있다.

요약하면, vert.x 애플리케이션은 Verticle 또는 Module 의 조합으로 이루어지며 이들 간의 통신은 Event Bus를 사용한다.

vert.x 프로젝트 구조

다음 그림은 github의 vert.x 페이지에서 소스 코드를 복제(clone)해 Eclipse에서 본 vert.x 프로젝트 구조다.

그림 4 vert.x 소스 트리

전체적인 구성을 살펴보면 다음과 같다.

핵심 library인 vertx-core
배포 및 라이프사이클을 관리하는 vertx-platform
Core Java API를 다른 언어로 노출하는 vert-lang

프로젝트 빌드(build) 시스템으로는 Ant와 Maven의 장점을 갖췄다는 Gradle를 사용한다.

vert.x 설치 및 간단한 예제 실행

vert.x를 사용하려면 반드시 JDK7이 필요하다. vert.x는 JDK7에 있는 invokeDynamic을 사용하기 때문이다.

vert.x는 매우 간단하게 설치할 수 있다. https://github.com/purplefox/vert.x/downloads에서 압축된 설치 파일을 원하는 위치에 다운로드해 압축을 푼 다음, bin 디렉터리를 PATH 환경 변수에 추가하면 설치를 완료할 수 있다. 커맨드 창에서 vertx version을 실행해 버전 정보가 제대로 나오면 설치가 성공한 것이다.

이제는 “Hello World!”를 출력하는 간단한 웹 서버를 JavaScript로 작성하고 실행해 보자. 다음과 같이 코드를 작성한 후 server.js로 저장한다. Node.js 코드와 거의 흡사한 형식이다.

load('vertx.js');

vertx.createHttpServer().requestHandler(function(req) {

req.response.end("Hello World!");

}).listen(8080, 'localhost');

생성한 server.js 애플리케이션을 다음과 같이 vert.x 명령어로 실행한다.

1	`%> vertx run server.js`

브라우저를 열고 http://localhost:8080에 접속해 “Hello World!” 메시지를 볼 수 있으면 성공이다.

다른 언어로 작성 된 예제를 살펴보자. 다음은 Java로 작성한 예제다. 정적 파일을 읽어 HTTP 응답으로 제공하는 웹 서버를 작성해 본 것이다.

Vertx vertx = Vertx.newVertx();

vertx.createHttpServer().requestHandler(new Handler<httpserverrequest>() {

public void handle(HttpServerRequest req) {

String file = req.path.equals("/") ? "index.html" : req.path;

req.response.sendFile("webroot/" + file);

}

}).listen(8080);

</httpserverrequest>

다음은 Groovy로 작성한 코드로 앞의 Java로 작성한 예제와 같은 기능을 한다.

def vertx = Vertx.newVertx()

vertx.createHttpServer().requestHandler { req ->

def file = req.uri == "/" ? "index.html" : req.uri

req.response.sendFile "webroot/$file"

}.listen(8080)

NHN과 vert.x

NHN의 플랫폼 개발 부서에는 vert.x가 정식으로 릴리스되기 전부터 개발 과정을 지켜보고 있었다. vert.x의 가능성을 높이 샀기 때문이다. 그리고 2012년 6월부터 메인 개발자인 Tim Fox와 교류하여 vert.x를 발전시켜 나갈 수 있도록 논의를 진행하고 있다. 예를 들어, Socket.io는 Node.js에서만 사용할 수 있었는데, 이를 vert.x에서도 Java로 사용할 수 있게 포팅 작업을 진행했고 현재 개발이 완료된 상태다. 다음은 github의 vert.x 레파지토리에 있는 pull request 요청 링크다.

https://github.com/vert-x/vert.x/pull/320

산출물인 socket.io vert.x 모듈은 현재 개발 중인 RTCS 2.0 버전(vert.x + Socket.io)에 사용될 예정이다.

Node.js가 지금처럼 활성화된 것은 Socket.io 덕분이었는데, vert.x에서 Socket.io를 사용할 수 있다면 vert.x 또한 많은 사용 사례가 생길 것으로 예상한다. 또한 이 socket.io vertx 모듈을 임베디드 라이브러리 형태로 사용하면 Java 기반의 애플리케이션에서도 socket.io를 사용할 수 있게 된다는 점에서 의미가 있다 하겠다.

참고) RTCS 란?

RTCS(Real Time Communication System)는 NHN의 Real Time Web 개발 플랫폼으로, 브라우저와 서버 간에 실시간으로 메시지를 전달할 수 있게 도와주는 플랫폼이다. RTCS는 현재 야구9단, 미투데이 채팅, 밴드(BAND) 채팅에 적용되어 있다.

마치며

vert.x는 2012년 5월에 첫 버전이 나왔다. 2009년에 첫 버전이 나온 Node.js에 비하면 역사가 매우 짧다고 할 수 있다. 그렇기 때문에 아직 레퍼런스가 많지 않다. 하지만 vert.x는 VMware의 든든한 후원을 받고 있고 Cloud Foundry에서 구동할 수 있기 때문에, 앞으로 많은 레퍼런스가 확보될 것으로 보인다.

참고 자료

“Main Manual” http://vertx.io/manual.html
“Installation Guide” http://vertx.io/install.html
“The C10K problem” http://www.kegel.com/c10k.html
김성박, 송지훈 “자바 I/O & NIO 네트워크 프로그래밍”, 한빛미디어 2004

Categories: 개발 | Permalink

by gemong on 2013/06/27

[요약] 세컨드 스크린 서비스는 현재 양방향성 기능에 초점을 맞추고 있지만, 프로그램 연동 정보와 광고 등을 자동 노출하는 ‘정보 스트림’의 스크린으로서 더 가능성이 있다고 봄. ✍

최근 TV의 부가 서비스 스크린으로서 아이패드 등 모바일 단말기를 세컨드 스크린으로 활용하는 서비스가 많이 등장하고 있습니다. 지박스(Zeebox), 샤잠(Shazam), 넥스트가이드(NextGuide), 코넥티비(ConnecTV), 와치위드(Watchwith) 등 여러 서비스가 활발한 사업을 전개하고 있고, 심지어 ’세컨드 스크린 소사이어티(2nd Screen Society)‘라는 단체까지 만들어져 있습니다.

보통 이런 서비스들은 한국에서 제대로 사용해 볼 기회가 거의 없기 때문에 뉴스 기사를 통한 간접 경험에 의존하여 대략적인 경향을 살펴보면 이렇습니다. 오디오 인식 등으로 현재 방송 프로그램(또는 광고) 위치를 자동으로 정확하게 파악하여 프로그램과 연동된 관련 정보를 서비스하고, 반응, 소셜 등 참여를 적극 유도하는 양방향 서비스를 강조하고 있습니다. 특히 마케터들에겐 TV에 효과적으로 양방향 광고를 진행할 수 있는 솔루션으로 큰 기대를 하고 있습니다.

세컨드 스크린의 가장 큰 문제점은 비디오 스트림의 단절

세컨드 스크린의 잠재력은 메인 스크린의 비디오 영역을 방해하지 않고 부가적인 디스플레이가 가능하도록 스크린이 분리되었다는 점과 TV의 가장 큰 애로사항인 양방향 인터페이스의 문제를 비교적 쉽게 해결할 수 있다는 데 있습니다. 하지만 그 두 가지 문제가 정말 해결된 것일까요. 첫 번째 문제에서 메인 스크린 시청 방해는 세컨드 스크린에서도 마찬가지로 일어날 수 있습니다. 이번엔 화면을 방해하는 것이 아니라, 시선을 방해합니다. 아래 그림을 보시죠.

Second Screen

세컨드 스크린을 보기 위해서는 TV에서 시선을 떼야 합니다. TV에서 시선을 고정하기 위해 엄청난 노력을 하는 현재의 방송 포맷은 세컨드 스크린과 궁합이 그리 잘 맞지 않는다고 생각합니다. 특히 상대적으로 몰입형인 드라마 같은 경우라면, 세컨드 스크린으로의 시선 단절, 즉 비디오 스트림의 단절은 용납되지 않을 것입니다. 이것은 고스란히 두 번째 문제에 영향을 줍니다. 세컨드 스크린의 양방향 인터페이스가 아무리 잘 갖춰진들, 주목되지 않으면 무슨 소용이 있겠습니까.

물론 잠깐 언급했듯이, 현재의 방송 포맷이 세컨드 스크린을 전혀 고려하지 않기 때문에 그렇습니다. 이걸 바꿔 말하면, 미래 방송 포맷이 세컨드 스크린을 고려하여 제작될 수 있다면, 시선 분배의 타이밍과 양방향의 컨텐트 제공이 유기적으로 이루어질 수도 있을 것입니다. 컴캐스트와 지박스의 예 같은 방송사와 세컨드 스크린의 제휴가 앞으로 더욱 심화하여, 프로그램 제작 단계에까지 긴밀한 협조를 하게 된다면 가능한 얘깁니다.

정보 스트림으로서의 가능성

그렇게 프로그램과 완벽히 연동되는 세컨드 스크린을 가정해 봅시다. 그럼 비디오 스트림의 단절과 양방향성의 극대화가 자연스럽게 일어날까요. 일부 장르의 프로그램에서는 이게 효과적으로 작용할 수도 있습니다. 예를 들어 시청자의 실시간 참여로 이뤄지는 퀴즈 프로그램을 상상해보면, 사회자가 “자, 지금 답을 눌러주세요!”라는 구령에 맞춰 시청자들이 세컨드 스크린을 일제히 터치하는 게임에 참여할 수 있을 것입니다. 하지만 대다수의 방송은 여전히 일방적인 비디오 스트림의 포맷을 벗어나지 않을 것입니다. 시청자가 TV에 기대하는 바가 그렇기 때문입니다. 사람들의 시청 행태가 어느 날 갑자기 린-백(lean-back)에서 린-포워드(lean-forward)가 될 것이라는 순진무구한 전망에 대한 신빙성 있는 근거는 어디에도 없습니다.

TV에서의 소비는 양방향이 아니라 컨텐트 스트림의 수동적 시청이라는 더 자연스러운 본능적 소비에 초점을 맞춰야 합니다. 그런 의미에서, 세컨드 스크린의 서비스도 ‘정보 스트림’이라는 컨셉으로 접근해 보는 것은 어떨까 생각해 봅니다. 세컨드 스크린은 TV의 보조 스크린 개념으로, TV 앞 탁자 정도에 세워져 TV 스크린에 방해되지 않게 적절히 시선을 분배하는 위치에 있고, 거기에 사용자가 굳이 (양방향으로) 무슨 명령을 내리지 않아도 프로그램과 완벽히 연동된 관련 정보가 방송 위치에 싱크되어 자동으로 흐르는 것입니다.

Aux Screen

이 정보 스트림은 프로그램과 관련된 정보를 간략한 형태로, 예를 들면 키워드나 헤드라인 수준의-큰 폰트로 표현된 정보를 가독성 있게 보여줍니다. 특정 배우가 나오는 장면에선 최근 그 배우의 뉴스 헤드라인이, 특정 상품이 나오는 장면에선 해당 상품의 브랜드와 가격이, 광고 시간에는 크로스 스크린-TV 스크린과 세컨드 스크린 양쪽을 유기적으로 활용한- 광고 캠페인을 진행합니다. 물론 열애설 헤드라인에 깜짝 놀라 태블릿을 터치해 자세한 뉴스를 볼 수도 있겠죠. 양방향성이 배제된 것이 아니라 억지로 드러내지 않을 뿐입니다. 또한, 새로운 광고 인벤토리가 창출되는 효과도 있습니다. 정보 스트림의 빈 슬롯에 광고가 채워질 수 있다는 얘깁니다.

조금 더 진도를 나가 봅시다. ‘정보 스트림’을 위한 TV의 보조 스크린으로서 세컨드 스크린을 사용하는 대신에, TV 자체의 폼팩터가 보조 스크린을 수용하는 방향으로 발전하면 어떨까 상상해 봅니다. 이런 식으로요.

Dual Screen

TV 스크린의 옆에 보조 스크린을 장착하는 겁니다. 시선의 단절감이 훨씬 적고, 화면도 크기 때문에 더 많은 정보를 표현할 수 있는 장점이 있습니다. TV 옆으로 확장하는 것이라 잘 안 보일 수도 있으니 각도를 꺾을 수 있게 만들면 더 좋겠죠?

여러분의 생각은 어떠신가요?

출처:http://digxtal.com/idea/20130627/second-screen-info-stream/

Categories: EDA STUDY, 디자인 | Permalink

제21회오픈세미나_HCI KOREA 2014 Report (1)
- 1: 1
제22회오픈세미나_Marketing Square Conference 정보공유 (3)
- 1: 1
- 나기상: SQUARE에 A가 빠졌네욥! Squre
- cho eun jung: 안녕하세요. 질문좀 드릴것이 있어서 답글 남깁니다. Digital IQ -Digital Impression Quality -- 인가요? Digital IQ의 정확한 개념이란 든가? ...
Flat – The New Design Trend for 2013 (1)
- Diploma of Telecommunication Engineering Telkom University: what do you think about design trends in the future?

Monthly Archives: 7월 2013

성광제약 비딩수주!

Hyundai life EDA의 ESS를 탐하다!

모든 것이 마음의 작용

vert.x는 무엇이 좋은가?

vert.x의 철학

Node.js와의 성능 비교