니름은 마이크로서비스를 위한 인터페이스 정의 언어(IDL) 컴파일러이자 원격 프로시저 호출(RPC) 프레임워크입니다. 스포카에서 서비스 지향 설계(SOA)를 적극적으로 도입하면서 쓰기에 적합하도록 구현되었습니다.
제품을 개선하기 위해서는 코드를 고쳐야 합니다. 그런데, 고친 코드가 행여 제품을 망가뜨리는 것이 아닐까 망설이고 고민할 때가 많습니다. 단위 테스트가 있다면 제품을 안전하고 빠르게 개선할 수 있습니다. 하지만 서비스 지향 설계로 제품을 만들다 보면 여러 개의 서비스들이 서로 통신하게 됩니다. 그리고 다른 서비스에 통신하는 기능도 단위 테스트를 작성해야 합니다.
서비스 간 단위 테스트는 까다로운 처리가 많이 필요합니다: 단위 테스트 안에서 요청을 흉내 내기, 실제 서비스를 띄워서 단위 테스트에서 테스트용 서비스에 요청하거나, 또는 요청과 응답을 흉내 내기, 요청한 내용을 역직렬화하고 응답할 내용을 직렬화 하기 등… 니름을 사용하여 서비스를 작성하면 서비스의 인터페이스와 구현을 분리할 수 있습니다.
요청이나 직렬화 등의 작업도 니름이 대신 처리하므로 추상화됩니다. 따라서 단위 테스트를 쉽게 작성할 수 있습니다. 서비스 지향 설계에서 니름을 사용하여 단위 테스트를 작성하면서 느낀 장점과 이것이 기존 방법들과 어떤 차이가 있는지 공유하고 싶습니다.
자바 개발자가 파이썬 개발을 배우면서 실무에 활용하고 집필을 하면서 겪었던 경험담 및 생각을 코드와 함께 풀어본다. 자바에 익숙한 사람이 파이썬을 배우고 있거나, 자바와 파이썬의 사이에서 고민을 했던 사람들에게 비교를 위한 기본 정보를 제공한다. 더 나아가 컴파일 언어와 스크립트 언어의 차이점, 개발 생산성을 측정할때 간과하는 컴파일 시간 및 순수 코딩 시간에 대한 통찰을 이끌 생각이다.
[C++ Korea 2nd Seminar] C++17 Key Features SummaryChris Ohk
C++은 10년 만에 C++11/14를 발표하면서 '모던 C++'이라는 이름으로 발전했습니다. 그만큼 새로운 기능들이 많이 추가되었습니다. 그리고 2017년, C++은 C++17이라는 이름으로 또 한 번의 발전을 준비하고 있습니다. 3년 주기로 빠르게 변화하는 모던 C++에 대비하기 위해, C++17에 추가될 주요 기능들을 살펴보고자 합니다.
http://github.com/ipkn/crow
Crow 프로젝트에서 사용한 C++11 기법들을 실제 구현에 대한 설명을 포함하여 자세히 설명한 발표자료입니다.
C++11 features used in Crow
video:
http://youtu.be/MixS9c3mE6U
https://vimeo.com/119627253
boost라이브러리 중에서 가장 많이 사용하는 기능인 BOOST_FOREACH()와 shared_ptr의 내부 구조를 분석합니다. 그리고 boost의 내부 구현에 사용된 이 기능을 프로그래밍에 응용하는 방법을 제시합니다.
* BOOST_FOREACH 구조 분석 및 응용
* shared_ptr 구조 분석 및 응용
니름은 마이크로서비스를 위한 인터페이스 정의 언어(IDL) 컴파일러이자 원격 프로시저 호출(RPC) 프레임워크입니다. 스포카에서 서비스 지향 설계(SOA)를 적극적으로 도입하면서 쓰기에 적합하도록 구현되었습니다.
제품을 개선하기 위해서는 코드를 고쳐야 합니다. 그런데, 고친 코드가 행여 제품을 망가뜨리는 것이 아닐까 망설이고 고민할 때가 많습니다. 단위 테스트가 있다면 제품을 안전하고 빠르게 개선할 수 있습니다. 하지만 서비스 지향 설계로 제품을 만들다 보면 여러 개의 서비스들이 서로 통신하게 됩니다. 그리고 다른 서비스에 통신하는 기능도 단위 테스트를 작성해야 합니다.
서비스 간 단위 테스트는 까다로운 처리가 많이 필요합니다: 단위 테스트 안에서 요청을 흉내 내기, 실제 서비스를 띄워서 단위 테스트에서 테스트용 서비스에 요청하거나, 또는 요청과 응답을 흉내 내기, 요청한 내용을 역직렬화하고 응답할 내용을 직렬화 하기 등… 니름을 사용하여 서비스를 작성하면 서비스의 인터페이스와 구현을 분리할 수 있습니다.
요청이나 직렬화 등의 작업도 니름이 대신 처리하므로 추상화됩니다. 따라서 단위 테스트를 쉽게 작성할 수 있습니다. 서비스 지향 설계에서 니름을 사용하여 단위 테스트를 작성하면서 느낀 장점과 이것이 기존 방법들과 어떤 차이가 있는지 공유하고 싶습니다.
자바 개발자가 파이썬 개발을 배우면서 실무에 활용하고 집필을 하면서 겪었던 경험담 및 생각을 코드와 함께 풀어본다. 자바에 익숙한 사람이 파이썬을 배우고 있거나, 자바와 파이썬의 사이에서 고민을 했던 사람들에게 비교를 위한 기본 정보를 제공한다. 더 나아가 컴파일 언어와 스크립트 언어의 차이점, 개발 생산성을 측정할때 간과하는 컴파일 시간 및 순수 코딩 시간에 대한 통찰을 이끌 생각이다.
[C++ Korea 2nd Seminar] C++17 Key Features SummaryChris Ohk
C++은 10년 만에 C++11/14를 발표하면서 '모던 C++'이라는 이름으로 발전했습니다. 그만큼 새로운 기능들이 많이 추가되었습니다. 그리고 2017년, C++은 C++17이라는 이름으로 또 한 번의 발전을 준비하고 있습니다. 3년 주기로 빠르게 변화하는 모던 C++에 대비하기 위해, C++17에 추가될 주요 기능들을 살펴보고자 합니다.
http://github.com/ipkn/crow
Crow 프로젝트에서 사용한 C++11 기법들을 실제 구현에 대한 설명을 포함하여 자세히 설명한 발표자료입니다.
C++11 features used in Crow
video:
http://youtu.be/MixS9c3mE6U
https://vimeo.com/119627253
boost라이브러리 중에서 가장 많이 사용하는 기능인 BOOST_FOREACH()와 shared_ptr의 내부 구조를 분석합니다. 그리고 boost의 내부 구현에 사용된 이 기능을 프로그래밍에 응용하는 방법을 제시합니다.
* BOOST_FOREACH 구조 분석 및 응용
* shared_ptr 구조 분석 및 응용
CyberConnect2에서는 2013년부터 DirectX11세대용 멀티플랫폼엔진 개발을 시작하였으며, 제작 시 발생하였던 문제점을 DirectX9와의 차이점을 바탕으로 공유하고자 합니다.
이 세션은 DirectX11의 개발이 처음이거나 관심 있으신 분을 대상으로 합니다. Tessellation 이나 OIT와 같은 최신기술은 다루지 않으므로 주의하시기 바랍니다.
[TechDays Korea 2015] 녹슨 C++ 코드에 모던 C++로 기름칠하기Chris Ohk
기존에 작성해 놓은 C++ 코드에 모던 C++를 적용하기는 쉽지 않습니다. 막상 개선하려고 마음먹었다고 해도, 어디서부터 바꿔야 할 지 막막하기만 합니다. 이 세션에서는 기존 C++ 코드에서 모던 C++를 적용해 프로그램의 구조와 성능을 개선하는 방법에 대해서 설명합니다. 그리고 기존 C++ 코드에 모던 C++를 적용할 때 주의해야 될 점에 대해서도 살펴봅니다.
2010 CodeEngn Conference 04
2010년 5월 22~24일, 세계 최대의 해커들의 축제인 DEFCON 18의 CTF 예선이 열렸습니다. Kaist 보안동아리 GoN 팀으로 참여하면서 느낀 이번 DEFCON CTF 예선에 대한 전반적인 리뷰와 함께, 여러 문제 분야들 중 Binary l33tness, Pwtent pwnables 분야의 문제들의 풀이를 해보고자 한다. (Defcon 18 CTF 예선전 전체 529팀에서 6위로 본선진출)
http://codeengn.com/conference/04
[KGC2014] 두 마리 토끼를 잡기 위한 C++ - C# 혼합 멀티플랫폼 게임 아키텍처 설계Sungkyun Kim
이미 많은 개발자들이 C#의 장점을 누리고 있으나, 본 PT에서는 높은 성능과 생산성을 동시에 달성하기 위해 C/C++로 개발된 native 게임 코드에 스크립트 언어로서 C#을 통합 할 수 있는 방법을 제시한다. 이를 위해 오픈소스 .Net 프레임웍인 Mono의 사용방법과 모바일 플랫폼에서의 특이사항들을 자세히 설명한다.
또한, C/C++언어에 C#을 비롯한 다양한 스크립트 언어를 효율적으로 혼합하여 게임을 구현할 수 있는 아키텍처를 제시한다. clang과 reflection을 이용하여 서로 다른 언어 간 인터페이스 노출을 자동화하고, 게임 내 오브젝트의 생명주기를 자동으로 관리할 수 있는 기법에 대해 설명한다.
전체목차: https://netpple.github.io/docs/make-container-without-docker/
pid namespace는 컨테이너 안에서 독자적인 "process tree" / "process id 체계"를 제공합니다. 어떻게 가능한 것일까요? 이를 이해하기 위하여 proc filesystem과 pid 쳬계에 대해서 얘기합니다. 그리고 프로세스 트리의 최상위인 특별한 프로세스 pid1 에 대하여도 다룹니다
[야생의 땅: 듀랑고]의 식물 생태계를 담당하는 21세기 정원사의 OpenCL 경험담Sumin Byeon
이 발표는 넥슨의 신규 개발 게임인 듀랑고의 생태계에 대한 간략한 소개와 OpenCL 을 이용한 병렬 처리에 관한 전반적인 기술적 내용을 다룹니다. 게임 속의 세계에서 지형과 기후, 지질 조건에 맞게 여러 종류의 식물과 광물들을 알맞은 곳에 배치시키는 것이 생태계 시뮬레이터의 역할인데, 이 시뮬레이터는 방대한 양의 계산을 수행합니다. 초기에 만들어진 프로토타입은 이러한 계산을 수행하는데 30분이 넘게 걸렸지만, 병렬처리, 알고리즘 시간복잡도 개선 등의 여러가지 방법들을 통해 그 시간을 11초까지 단축시켰습니다. 구체적으로 어떤 방법들을 시도했었고, 어떤 방법들이 효과가 있었는지 여러분과 그 경험담을 공유하고자 합니다.
This short document promotes Haiku Deck, a presentation creation tool, and encourages the reader to get started creating their own Haiku Deck presentation on SlideShare. It provides a single prompt stating "Create your own Haiku Deck presentation on SlideShare!" to inspire the reader to take action.
6. compile
class foo {
private int _bar;
private int *_pBar;
private static int _s_bar1=7;
private static int[100000000] _s_bar2;
public int foobar(value bar) {
int local_bar=0;
_pBar = malloc(10000000*sizeof(int));
…
}
public static staticFoobar() {
…
}
}
7. compile
모든 프로그램은
- 자료
- 흐름(의 표현)
컴파일러의 입장에서..
- 이 프로그램을 메모리에 올려야 하겠는데
-> 메모리에 빈 공간이 얼마나 필요할까?
- 어떤 자료는 컴파일 타임에 크기를 앎
- 어떤 자료는 컴파일 타임에 모름
- 흐름은??
8. compile
class foo {
private int _bar;
private int *_pBar;
private static int _s_bar1=7;
private static int[100000000] _s_bar2;
public int foobar(value bar) {
int local_bar=0;
_pBar = malloc(10000000*sizeof(int));
…
}
public static staticFoobar() {
…
}
}
sizeof(int) 는 4bytes 라 가정
compile time 에 결정!!
_s_bar1 는 4bytes
_s_bar2 는 4*100000000bytes
compile time 에 사용할지 안할지 모름!!
프로그램 어딘가에서 x = new foo(); 수행할 때 memory에 할당
10. compile
0000 0000 0000 0000 0000 0000 0000 0000
…
0000 0000 0000 0000 0000 0000 0000 0111
…
…
???? ???? ???? ???? ???? ???? ???? ???? ????
???? ???? ???? ???? ???? ???? ???? ???? ????
???? ???? ???? ???? ???? ???? ???? ???? ????
…
…
???? ???? ???? ???? ???? ???? ???? ???? ????
_s_bar1 4bytes
주소 메모리 공간(에 이렇게 쓰겠다는 약속)
_s_bar2 약 100Mbytes
어떤 값이 올지도 모르는
데 미리 100Mbytes 나 잡
아두는 것이 효율적일까?
0000 00f0
…
0000 00ff
…
…
11. compile
0000 0000 0000 0000 0000 0000 0000 0000
…
0000 0000 0000 0000 0000 0000 0000 0111 _s_bar1 4bytes
주소 메모리 공간(에 이렇게 쓰겠다는 약속)
_s_bar2
실제로는 약 100Mbytes
의 공간을 _s_bar2가 사용
하겠다 라는 기록만 저장
해 둡니다.
???? ???? ???? ???? ???? ???? ???? ???? ????
0000 00f0
…
0000 00ff
…
…
12. compile
0000 0000 0000 0000 0000 0000 0000 0000
…
0000 0000 0000 0000 0000 0000 0000 0111 _s_bar1 4bytes
주소 메모리 공간(에 이렇게 쓰겠다는 약속)
_s_bar2
???? ???? ???? ???? ???? ???? ???? ???? ????
0000 00f0
…
0000 00ff
…
…
foo@foobar(value) …
…
foo@staticFoobar() …
…
class 의 생성, 또는
method call 시 무엇을 어
떻게 해야 한다는 정보가
수록된 영역
13. compile
data section
주소 메모리 공간(에 이렇게 쓰겠다는 약속)
bss section
0000 00f0
…
0000 00ff
…
…
code section
compile 결과물
(= foo.o file )의 내용
15. link
foo.o foo2.o
+ … +
a+ =
executable image
(=
foo.exe 또는
foo.lib 또는
foo.dll)(xx.lib 또는 xx.dll)
16. link
foo.o
foo2.o
• 나중에(프로그램 실행 시점에) offset 값만 결
정되면 프로그램의 모든 영역에 접근 가능
foo.exe 또는 foo.lib 또는 foo.dll
offset (어떤 값이 될지는 모름)
offset + 1
offset + 2
offset + 3
…
17. static link
이 프로그램을 빌드하면 foo.exe 또는 foo.lib
의 사이즈는 약 400Mb 정도 될거임
foo.lib
object file 에서는 공간을
차지하지 않던 bss(초기화
되지 않은 전역변수) 영역
프로그램 생성 시점에는
해당 영역을 실제로 할당
해 두어야 함
19. dynamic link
• foo.dll은 필요할 때에만 load 됨
• 효율적이다. 하지만…
• 드디어 dll 지옥의 시작
foo2.o
+ =
foo2.exe
foo.dll
foo3.o
+ =
foo3.exe
foo.dll
foo.dll
20. runtime
class foo {
private int _bar;
private int *_pBar;
private static int _s_bar1=7;
private static int[100000000] _s_bar2;
public int foobar(value bar) {
int local_bar=0;
_pBar = malloc(10000000*sizeof(int));
…
}
public static staticFoobar() {
…
}
}
sizeof(int) 는 4bytes 라 가정
_pBar 는 동적 할당 변수,
약 400mb 크기의 memory를 할당할 수 있을
지 없을지는 시도해봐야 알 수 있다.
local_bar 는 지역변수, foobar()안에서 잠깐 쓰고 반환
25. dll 지옥
class foo {
private int _bar;
private int *_pBar;
private static int _s_bar1=7;
private static int[777777777] _s_bar2;
public int foobar(value bar) {
int local_bar=0;
_pBar = malloc(777777777*sizeof(int));
…
}
public static staticFoobar() {
…
}
}
_s_bar2 사이즈 변경
_pBar 사이즈 변경
• 변경된 foo.dll 을 v2.0 / 기존 foo.dll 을 v1.0 이라 하자
26. dll 지옥
• foo.dll은 system memory에 한 번만 load 되어 공유
• 현재 memory에 load 된 foo.dll 은 v1.0
• foo.dll v2.0 을 사용하는 foo3.exe는 어떤 동작을 할지 알 수
없다!!!
foo2.exe
foo.dll (v1.0)
foo3.exe
foo.dll (v2.0)
system memory
foo.dll (v1.0)
27. dll 지옥
• system directory 한군데에 모든 dll이 떡져있다
case1 : 윈도우 업데이트로 인한 system library 변경
case2 : 응용 프로그래머가 임의로 system library 변경
과거 MS Windows shared library 저장소
winsock.dll
c:windowssystem
msvcrt.dll
windows.dll
….
28. dll 지옥
• main 영역 / 임시 영역으로 이원화
• library 관리 책임이 사용자에게 있음
-> 사용자가 멋대로 library 업데이트 한다면?
-> 윈도우와 상황이 다르지 않다.
linux shared library 저장소
libc.so
/usr/lib
libpthread.so
glib.so
….
libc.so
/usr/local/lib
libpthread.so
glib.so
….
29. jar 지옥
• 내가 작성한 program 이 어느 jar 를 참조할지 모른다!!
• dll 지옥과 동일한 문제 발생 !!
java class path
/path/A
foo.jar (old)
/path/B
foo.jar (new)
30. dependency 지옥의 원인?
• PEBKAC(http://en.wikipedia.org/wiki/User_error)
• 프로그램은 거짓말을 하지 않아요
• 모든 문제의 원인은 닝겐입니다
31. 해결
• library metadata
– 빌드 날짜 / 크기 / 유니크 키 등을 빌드 시점에 적어둠
• 버전 관리되는 build/package manager
– 모든 종속성 library 의 버전을 관리하는 도구 사용
• virtual environment
– 가상환경에 library를 넣어두면 설령 떡지더라도 가상환경
만 재구성하면 된다