월간 보관물: 2014 6월

JavaScript의 privileged 메서드가 끔찍한 이유

예제 코드가 약간의 오해의 소지를 가지고 있어 조금 수정했습니다.
– 2014년 6월 29일 –

요즘 가장 뜨거운 관심을 받고있는 프로그래밍 언어인 JavaScript는 정보 보호(또는 은닉, information hiding)를 언어 스펙 차원에서 지원하지 않습니다. 이는 JavaScript는 진정한 OOPL(object-oriented programming language)이 아니라고 주장하는 사람들의 근거가 되기도 합니다. 여기에 대해 Douglas Crockford는 다음과 같이 변호합니다.

Some argue that JavaScript is not truly object oriented because it does not provide information hiding. That is, objects cannot have private variables and private methods: All members are public. But it turns out that JavaScript objects can have private variables and private methods. Of course, few understand this because JavaScript is the world’s most misunderstood programming language.

JavaScript가 개체의 멤버 접근을 제한할 수 있다며 이것이 잘 알려지지 않은 것을 안타까워합니다.

계속 읽기

Java의 함수형 프로그래밍이 생각보다 위험하지 않은 이유

어제 집에서 빈둥거리던 중 Why Functional Programming in Java is Dangerous란 제목의 글을 읽었습니다. 이글은 다음과 같은 Clojure 코드를 Java로 구현하면 OutOfMemeryError 혹은 StackOverflowError의 재앙이 닥칠 것이라 경고하고 있습니다.

(take 25 (squares-of (integers)))

하지만 이것은 사실이 아닙니다. Java는 분명 함수형 언어가 아니지만 저 글에서 언급한 재앙 없이 위 코드를 충분히 구현할 수 있습니다. Java에게서 억울한 누명을 벗겨주고 싶은 생각에 이 포스트를 작성합니다. 제목도 “Java의 함수형 프로그래밍이 생각보다 위험하지 않은 이유”라고 지어봤습니다. 🙂

계속 읽기

*오류 수정* C++와 C#, Java, 그리고 Node.js 정렬 성능 비교

조종국님께서 댓글에서 지적해주신 절사평균 오류가 수정되어 소스코드와 측정 결과가 업데이트되었습니다. 결과적으로 C# 이외의 언어들에 대한 정렬 성능 평가가 낮아졌습니다.
– 2014년 10월 17일 –

어제(2014년 6월 16일) 추가된 Java 코드가 공정하지 못했습니다. 예상보다 Java 코드가 느려서 검토해본 결과, 기존의 C++, C#, Node.js는 모두 rand() 네이티브 함수를 사용해 난수를 만들었기 때문에 난수 도메인의 크기가 15비트인 반면 Java 코드는 매개변수 없는 버전의 java.util.Random.nextInt() 함수를 사용했습니다. 이 포스트의 관심사는 언어별 정렬 속도가 아닌 최대한 유사한 코드를 이용한 CPU 집약적인 코드의 성능 비교이기 때문에 Java 역시 15비트 난수를 사용하도록 수정했습니다. 결과는 많이 달라졌습니다. 이것과 관련되어 수정된 부분은 별도 표시했습니다.
– 2014년 6월 17일 –

처음엔 귀찮아서 제외했지만 찝찝한 느낌이 사라지지 않아 Java를 추가했습니다.
– 2014년 6월 16일 –

며칠전 Swift의 -Ofast 컴파일러 설정에 대한 글을 접했습니다. 저는 아직 Swift에 대해 잘 모르고 실습 경험도 전혀 없지만 이 글에 의하면 -Ofast 설정은 약간은 도박적으로 코드의 제한을 풀어 성능을 극대화합니다. 결과적으로 정렬 작업에 대해 C 코드보다 약간 높은 성능을 보여준다고 하네요. 안정성을 담보로 하기 때문에 개발자의 주의를 강하게 요구하면서도 최소한의 성능 집약적 코드를 최적화하는 데에 이용 가치가 있을 수도 있겠습니다.

그렇다면 안정적 코드를 제공하는 ‘관리’ 개념을 가진 .NET 코드와 Java 코드는 어느 정도 성능을 보여주는지 C++ 코드와 비교해봤고 기왕 하는김에 성능 미신이 따라다니는 Node.js를 포함해 봤습니다.

계속 읽기

Microsoft.Owin.Testing 패키지를 이용한 인메모리 통합 테스트

단위 테스트 만큼이나 통합 테스트는 필요하며 통합 테스트에 있어서도 자동화는 중요합니다. 단위 테스트를 통과한 모듈도 서로 조합되면 운영 환경에서 오류를 발생시킬 가능성이 존재하며 다양한 이유로 인해 단위 테스트가 어려운 코드도 있죠. GUI를 가진 응용프로그램을 인력 자원을 동원해 하나하나 통합 테스트하거나 그것조차 제대로 하지 않는 것이 국내 사정이지만 CUIT(Code UI Tests)나 Jasmine 등의 E2E(End-to-End) 도구를 사용해 통합 테스트를 자동화하면 테스트 비용과 테스트 오류 가능성을 낮출 수 있습니다.

API 역시 통합 테스트 대상입니다. API는 GUI 기반 응용프로그램과 비교할 때 통합 테스트를 수동으로 진행하기에 귀찮고 어려운 반면 자동화하기는 더 쉽습니다. Jasmine을 이용한 API 통합 테스트 자동화를 고려해 볼 수도 있지만 Visual Studio에 의해 관리되고 있는 기존의 테스트가 있다면 동일한 테스트 도구를 통해 관리하는 것이 훨씬 좋겠죠.

Microsoft.Owin.Testing 패키지를 사용하면 OWIN(Open Web Interface for .NET) 기반 ASP.NET Web API에 대한 통합 테스트를 쉽게 작성할 수 있습니다. 테스트는 메모리를 통해 이루어지기 때문에 네트워크 트래픽이 발생하지 않아 매우 효율적이면서도 ASP.NET Web API의 전체 파이프라인을 관통합니다. 뿐만 아니라 IoC 컨테이너를 조작하면 컨트롤러 이후의 과정을 모의화하는 것도 가능합니다.

계속 읽기