근래 배운 몇 가지 패턴 정리: Provider, Builder, Delegation

Provider

정확히 말하면 디자인 패턴은 아니라고 한다. 자세한 설명은 [1]에 있다. Factory 패턴과 유사하나 외부 설정에 따라 다른 객체를 생성하는 패턴을 칭한다. 나쁜 패턴이라며 [1]과 함께 Constructor Injection 같은 방법을 써야 한다는 주장이 있지만, 실제로 잘 작성된 오픈소스 프로젝트들에서도 이러한 구현을 꽤 많이 볼 수 있다.

Builder

생성자에 전달되어야 할 파라메터가 다양해서 골치 아픈 경우 Builder 패턴이 좋은 해결책이 된다. 방법은 Builder 객체를 만들고 setter 를 통해 필요한 파라메터를 설정 한 후에 build() 메소드 호출을 통해 실제 객체를 생성한다.

Delegation

처음 Delegation 패턴을 봤을 때는 Interface의 구현과 차이점을 잘 발견하지 못했었다. 위키 피디아에도 설명이 있지만 언제 써야 하는지가 설명되어 있지 않았다. [3] 에서 이유를 찾았는데. 요약을 해보면,

  • 원래 있는 객체의 동작을 그대로 유지하면서 동작의 앞뒤에 처리를 추가하고 싶을 때
  • 호환되지 않는 인터페이스를 위한 Proxy 를 구현할 때
  • 실제 구현 사용 시 복잡도가 높은 콜 루틴을 단순하게 제공하려고 할 때

경우에 따라 서브클래싱과 함께 쓸 수 있을 것 같으며 데코레이터 패턴에서 주로 나타나는 패턴인 것 같다.

See Also

[1] Provider Model Design Pattern and Specification, Part 1
[2] Provider is not a pattern
[3] http://stackoverflow.com/questions/7168714/what-is-the-purpose-of-a-delegation-pattern/7168737#7168737


Jni Native를 통한 Rust 함수 호출

회사 허락을 맡아 홀로 프로젝트를 하나 시작했다. 큰 그림은 일부 컴포넌트를 Rust로 구현하고 컴포넌트간 연결은 rpc로 하는 것인데 아직 Rust 로 rpc 구현을 하기에 시간이 더 필요하다. 임시적인 수단으로 JNI를 통해 기존 컴포넌트에 연결을 하려고 한다.

그 외 프로젝트에 자세한 이야기는 나중에 설명하고 위 목적으로 Stackoverflow 에서 참고하고 https://github.com/Monnoroch/RustJni 를 참고해서 JNI를 테스트를 해봤다.

C 바인딩이 쉬운것은 Rust의 장점 중 하나인데 JNI 바인딩 역시 순조로웠다. 방법은 우선 아래와 같이 native 함수 인터페이스를 작성하고

아래와 같이 Rust 코드를 작성하면 된다.

이게 전부다. 위에서 사용된 chars_to_str와 str_to_jstring 는 아래 github repository에 있다.

https://github.com/hyunsik/jni-rs/blob/master/src/helper.rs

위 repository 는 https://github.com/Monnoroch/RustJni를 fork 해서 JNI 뿐 아니라 JNI 프로그램 작성 중에 반복되는 코드들에 대한 유틸리티 함수들을 추가할 계획이다.

그리고 아래는 JNI Native + Rust 를 위한 템플릿 프로젝트이다.

https://github.com/hyunsik/rust-jni-template


‘개발자가 보는 소프트웨어 교육의 오해와 진실, 그리고 미래’ 글에 대한 이견

개발자가 보는 소프트웨어 교육의 오해와 진실, 그리고 미래

링크한 글에 부분적으로 공감이 가기는 하지만 저는 꽤 다른 생각을 가지고 있습니다.

요약을 하면 링크의 글에서는 ‘직접적인 SW 개발을 위한 지식 습득’이 SW교육의 핵심이라고 주장하고 있습니다. 제 의견은 초중등 SW 교육에서 직접적인 SW 개발을 다루는 것은 불필요하다고 생각합니다. 덧붙이면 제가 생각하는 초중 SW 교육의 참의는 논리적인 사고나 알고리즘적 사고를 잘 가르치는 수단으로 SW가 활용되는 것이지 SW 개발에 목적이 있다고 생각하지 않습니다.

그 이유를 다음과 같습니다.

SW 개발을 위한 지식은 쉬이 변합니다
SW 개발 자체는 도메인 지식, SW 개발 방법론, 협업 도구, 프로그래밍 언어와 같은 응용의 말단 지식 (원론에서 먼)을 다수 요구하고 있으며 이러한 지식들은 10년 이상 단위로 보면 쉬이 변하는 영역입니다. 또한 SW 개발은 지식의 양적인 요구가 많거나 엔지니어링적인 요소가 많습니다. 이를 실제 현업에 종사하려면 10년 이상 걸리는 초중등 학생들이 배울 필요는 없습니다. 직접적인 SW 개발에 관심이 있는 친구들은 (글의 저자 설명과 같이) 인터넷 등 다른 수단을 통해 그때 그때 유망한 프로그래밍 언어나 방법론, 개발 도구들을 배우면 됩니다.

초중등 SW 교육이 SW 개발자를 만들기 위한 것이 아닙니다.
저자 분이 ‘모두 개발자가 될 필요는 없다’고 언급한 것 처럼 당연히 초중등 SW 교육이 SW 개발자를 만들기 위한 것이 아닙니다. 따라서 직접 결과물을 내기 위해 배워야 하는 SW 개발 지식(글에서 언급된 방법론, 협업 도구, 현업에서 쓰이는 언어) 에 시간을 들이는 것은 대다수의 초중등 학생들에게 사실 시간 낭비일 것이라고 생각합니다. 어린 학생들일 수록 가능성 많고 잠재력이 크기 때문에 (다른 말로 하면 미래에 어떤 분야에 종사하게 될지 모르기 때문에) 학생들 전체에게 좋은 영향을 줄 지식인 논리력, 알고리즘적 사고력을 키우는게 본질이 되어야 합니다. SW 통해 생각의 방법을 배우게 되면 예술, 인문, 철학, 과학, 공학 분야에 다양하게 적용될 수 있습니다.


대학 SW 교육에 대한 유감

대학 SW교육 확 바뀐다…전문인력 5천500명 양성

미국 같은 경우 SW 산업이 상당히 발달하고 인력 수요가 높다. 그래서 지금 SW 산업 발달 속도와 수요 증가로 보아 몇 년도 까지 얼마나 많은 SW 인력이 부족하다는 데이터를 바탕으로 인력 양성에 노력을 하고 있다. 다시 말해 공급이 부족하니 정책을 펼쳐 늘리는 것이다. 너무도 당연하다.

우리나라는 SW 산업이 발전하고 있지 않다. 실질적 수요가 증가하는지도 잘 모르겠다. SW 기업이 몇 개나 있는지… 거의 없는 것 같다. 기업이나 정부가 SW를 제 돈 내고 사서 쓰는 것은 보기 힘들고 유수 대기업들 조차도 여전히 인건비 기반으로 비용 지불을 하려고 한다. 이런 상태로 볼 때 지금도 앞으로도 SW 기업이 더 크지도 새로 생길 가능성도 상당히 낮은 것 같다. 앞으로도 좋아질 징조는 보이지 않는다. 다시 말해 수요 증가에 대해 의문이 든다.

또한 산업계에서 진짜 원하는 것은 전문인력인데 전문인력은 산업 발달로 길러지는 것이지 제도적으로 인위적으로 키울 수 있는 것은 아니다. 이런 정책으로 실질적 수요를 해소하기는 쉽지 않아 보인다.

다소 비관적으로 본다면, 이런 정책으로 인위적으로 많이 양성된 인력들을 흡수할 곳은 없을 것으로 보인다. 운이 좋으면 외국으로 가서라도 일을 하게 되겠지만, 많은 사람들은 배운 것을 써먹지도 못하는 자리에서 일하게 되거나 헐값에 일을 하게 될 지도 모른다.

SW 산업의 진짜 발전을 위해서는 인위적인 인력 양성보다는 (너무 당연해서 심심한 이야기지만) SW 생태계 자체에 좋은 순환이 만드는 방법이 함께 혹은 먼저 고민되어야 할 것 같다.


Oracle이 고려 중인 Java 9의 Unsafe API 제거 계획

성능이 중요한 꽤 많은 자바 프로젝트 (하둡 등 데이터 처리 프로젝트들 역시)이 Java Unsafe API에 의존하고 있다. Unsafe API는 JVM에서 공식적으로 제공하는 API가 아닌 Oracle JDK에서 내부적인 사용을 목적으로 제공하는 API이다. JNI와 다른 기술이며 콜 오버헤드 없이 직접 native 코드로 실행된기 때문에 빠르고, C 와 같이 메모리를 동적할당할 수 있으며 bounding check 없는 배열 접근 등 다소 위험하지만 성능 좋은 API를 100여가지 제공한다.

붙인 링크는 Oracle에서 JVM9 에서 Java Unsafe API 정말 제거하려는 계획과 지워질 경우 일어날 재앙에 대해서 언급한다. 아직까지는 계획일 뿐이고 계획을 직접 훑어보니 어느 정도의 대체 API도 고려하는 것 같기는 하다. 그럼에도 불구하고 그런일이 실제로 일어난다면 많은 자바 프로젝트들은 큰 변화를 겪어야 할 수 도 있다. 어쩌면 자바로 작성한 것이 의미가 없어질 정도로.. 어떤 프로젝트들은 헤비한 JNI 사용을 해야 할 것 이며 어떤 프로젝트들은 C++이나 기타 시스템 프로그래밍 언어로 이동을 해야 할지도 모르겠다.


오픈소스 홍보를 위한 사이트 정리

오픈소스의 핵심은 커뮤니티와 사용자이기 때문에 홍보를 꾸준히 그리고 잘 해야 할 필요가 있다. 개발자 커뮤니티나 오픈소스 커뮤니티 사이트에서 홍보를 많이 하는데 매 릴리즈나 주요 로드맵 공개 때 마다 꾸준히 하는 것이 효과적이다. 추후 참고하기 위해 목록을 정리 한다.

글 또는 링크 포스트를 통한 홍보 사이트

등록을 통한 홍보 사이트


해쉬 함수 구현 (hash function implementation) 링크 정리

이것도 한 3-4년전에 정리했다가 가끔 업데이트 한 것 같은데… 나름 괜찮은 링크가 몇 개 있어 공유한다. 이것도 앞으로는 이 페이지에서 업데이트를 하겠다. 오래 지나다보니 인터넷에 있는 정보라도 링크가 깨진 것들이 많아 지웠는데 아쉽다. 다행히 이 페이지는 web archive에서 찾을 수 있어 다행이다 싶다.


General

SW-based Implementations

HW-based Implementations


Follow

Get every new post delivered to your Inbox.