태그 보관물: .net

Get-AzureWebsite 명령 버그

Azure PowerShell 명령을 사용하다보면 다음 오류를 만날 수 있습니다.

System.ArgumentException: Requested value 'VS2015' was not found.

이것은 Azure Web Apps 혹은 Azure PowerShell의 버그로 보입니다. 이 포스트는 왜 이 오류가 발생하는지와 우회하는 방법을 설명합니다.

계속 읽기

선언적 코드를 사용한 ASP.NET Web API 데이터 검사

일반적으로 선언적(declarative) 코드는 명령형 코드에 비헤 가독성이 높고 테스트하기 쉬우며 코드의 양도 더 적습니다. System.ComponentModel.DataAnnotations 네임스페이스는 데이터를 검사하는 ValidationAttribute 하위 특성(attributes) 집합을 제공하며 이 특성들을 사용하면 데이터의 유효성을 검증하는 코드를 선언적으로 작성할 수 있습니다. ASP.NET Web API 액션 메서드에서도 이 특성들을 사용해 입력 데이터의 유효성을 검사할 수 있습니다.

계속 읽기

Mark and Sweep 가비지 컬렉션과 함수 기반 Mediator 패턴 – II

시작하기

지난 포스트에서 함수의 강한 참조를 사용하는 메신저 구현 방법과 이 방법을 사용할 때 변수에 저장되지 않는 개체가 가비지 컬렉션에서 생존하게 되는 현상을 살펴봤습니다. 이러한 현상이 항상 문제라고 볼 수는 없지만 그것을 기대하지 않은 상황에서는 곤란해질 수 있습니다. 이번 포스트에서는 약한 참조를 사용해 메시지 구독이 가비지 컬렉션에 영향을 주지 않도록 하는 방법을 알아봅니다.

I'm too weak. Don't kill me.

  1. Mark and Sweep 가비지 컬렉션과 함수 기반 Mediator 패턴 – I
  2. Mark and Sweep 가비지 컬렉션과 함수 기반 Mediator 패턴 – II

계속 읽기

Mark and Sweep 가비지 컬렉션과 함수 기반 Mediator 패턴 – I

시작하기

요즘 자주 접할 수 있는 프로그래밍 언어에 대한 키워드 중 하나가 함수형 프로그래밍입니다. 꼭 함수형 언어가 아니라도 많은 언어들이 함수형 프로그래밍 특징들을 스펙에 포함하고 있습니다. 올해 초에는 Java 스펙에도 람다가 추가되었고 C# 2.0에 클로저(closure)가 추가된 것이 벌써 10년전, 저 역시 계속 함수형 프로그래밍을 공부하고 있습니다. 그런데 언어별 함수형 프로그래밍 특징들의 구현 방법에 대해 잘 모르면 낭패를 보는 경우가 가끔 있습니다. 지금부터 다룰 시리즈에서는 JVM이나 CLR 같은 Mark and Sweep 가비지 컬렉션을 사용하는 플랫폼에서 주의해야 할 내용 몇 가지를 Mediator 패턴을 사용해 소개합니다. 언어는 C#을 기준으로 설명하지만 개념적인 내용은 람다를 사용하는 Java 프로그래머들도 꼭 한 번 고민해 볼 내용입니다.

총 3개의 포스트로 진행됩니다. 이번 포스트에서는 강한 참조로 구현되는 메신저에서 발생할 수 있는 문제를 다루고 두번째 포스트는 약한 참조를 사용해 이 문제를 해결하는 방법과 실제로 약한 참조를 사용하는 메신저들을 분석합니다. 마지막 세번째 포스트에서는 약한 참조를 사용한 구현이 가진 문제점을 살펴보고 다시 강한 참조로 돌아가 Rx(Reactive Extensions)를 사용하는 방법을 알아봅니다.

  1. Mark and Sweep 가비지 컬렉션과 함수 기반 Mediator 패턴 – I
  2. Mark and Sweep 가비지 컬렉션과 함수 기반 Mediator 패턴 – II

계속 읽기

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 컨테이너를 조작하면 컨트롤러 이후의 과정을 모의화하는 것도 가능합니다.

계속 읽기