멋진 테스트 코드를 작성하도록 돕는 AssertJ 라이브러리에 대해서 알아봅시다.

AssertJ의 장점

  • 메소드 체이닝을 지원하기 때문에 좀 더 깔끔하고 읽기 쉬운 테스트 코드를 작성할 수 있습니다.
  • 개발자가 테스트를 하면서 필요하다고 상상할 수 있는 거의 모든 메소드를 제공합니다.

라이브러리 의존성 설정

Java8 이상 기반 프로젝트는 3.x 버전을, Java7 이하 기반 프로젝트는 2.x 버전을 사용하셔야 합니다.

Gradle

  • Java8
    testCompile 'org.assertj:assertj-core:3.6.2'
  • Java7
    testCompile 'org.assertj:assertj-core:2.6.0'
    

Maven

<dependency>
  <groupId>org.assertj</groupId>
  <artifactId>assertj-core</artifactId>
  <!-- use 2.6.0 for Java 7 projects -->
  <version>3.6.2</version>
  <scope>test</scope>
</dependency>

AssertJ 메소드 임포트

다음과 같이 정적 임포트를 하면 AssertJ의 다양한 API를 클래스 이름없이 바로 사용할 수 있습니다.

import static org.assertj.core.api.Assertions.*;

테스트 대상 지정하기

모든 테스트 …

Read More

출처 : http://www.daleseo.com/lombok-popular-annotations/

Lombok 라이브러리에서 제공하는 어노테이션 중에서 자주 사용되는 어노테이션 위주로 살펴보도록 하겠습니다.

접근자/설정자 자동 생성

제일 먼저 살펴볼 어노테이션은 @Getter와 @Setter 입니다.
아마 Lombok에서 가장 많이 사용되는 어노테이션일 텐데요.
예를 들어, xxx라는 필드에 선언하면 자동으로 getXxx()(boolean 타입인 경우, isXxx())와 setXxx() 메소드를 생성해줍니다.

@Getter @Setter
private String name;

위와 같이 특정 필드에 어노테이션을 붙여주면, 다음과 같이 자동으로 생성된 접근자와 설정자 메소드를 사용할 수 있어서 매우 편리합니다.

user.setName("홍길동");
String userName = user.getName();

또한, 필드 레벨이 아닌 클래스 레벨에 @Getter 또는 @Setter를 선언해줄 경우, 모든 필드에 접근자와 설정자가 자동으로 생성됩니다.

VO 클래스를 작성할 때 마다, 접근자와 …

Read More

출처 : http://www.bsidesoft.com/?p=3526&

UTF16 인코딩의 개요

1회차에서 유니코드 기본 개념을 살펴보고 2회차에서는 UTF8을 공부했습니다.

이번 포스팅에는 대부분의 응용프로그램 내부에서 사용되는 UTF16을 알아봅니다.

UTF8만으로는 안되는 걸까…
UTF8은 전송 시에 유리하지만 UTF16은 프로그램 실행 시 유리하니까.
그렇긴 하지만.

UTF16의 감을 잡기 위해 브라우저의 자바스크립트가 작동하는 절차에 대해 생각해볼까요.

  1. 우리가 작성한 xxx.js 파일은 UTF8로 저장합니다. W3C권장사항이고 최근에는 UTF8이 대세입니다.
  2. 브라우저에서는 우선 xxx.js를 읽어들여 UTF8기준으로 디코딩하여 코드포인트를 해석합니다.
  3. 해석된 코드포인트를 자바스크립트 엔진에게 전달하면 엔진은 코드포인트를 UTF16으로 인코딩하여 메모리에 적재합니다.

“파일용 인코딩”과 “프로그램 내부에 사용하는 인코딩”은 다를 수 있습니다.

  1. 파일을 디코딩하고 메모리용으로 다시 인코딩하는 작업이 중복되어 초기 작동 시에는 부담이 되지만,
  2. 프로그램이 실행될
Read More

출처 : http://www.bsidesoft.com/?p=3496&

심화된 인코딩 탐구

저번 포스팅에서는 유니코드에 대한 개요와 인코딩이란 무엇인가에 대한 기초개념을 살펴봤습니다.
다음과 같은 내용이 나왔죠.

  • 코드포인트 – 문자에 할당된 고유한 숫자값
  • 평면 – 코드포인트를 관리하기 위한 그룹범위
  • 코드유닛 – 일정한 크기를 하나의 문자로 바라보는 단위
  • 인코딩 – 코드유닛과 코드포인트의 크기 차이를 처리하기

이번 시간에서는 여러가지 인코딩방식에 따라 실질적인 인코딩을 처리해가면서 구체적인 내용을 살펴볼 예정입니다.

약간만 더 복잡해질거야.
…말도 안..

유니코드 인코딩의 종류

유니코드에서 사용하는 인코딩은 표준으로 지정되어있습니다. UTF8, UTF16, UTF32 라는 세 가지로 각각 뒤에 붙은 숫자는 코드유닛의 비트 크기입니다.

  1. UTF8 : 8비트 = 1바이트를 코드유닛으로 사용하는 인코딩. 인터넷에 교환되는 대부분의 파일에 사용됨.
  2. UTF16
Read More

출처 : http://www.bsidesoft.com/?p=3435

개요

본래 우리가 작성한 문서에 있는 문자들은 그대로 저장될 수는 없습니다. 반드시 숫자로 바뀐 후 저장되죠. 따라서 문자를 숫자로 바꿔주는 표가 꼭 필요합니다.
이러한 문자를 숫자로 바꿔주는 표 중에 가장 유명한 건 아스키표입니다. 아스키표를 사용하면 영어, 숫자, 기초적인 기호들에 대해 고유한 숫자 값을 부여해 변환할 수 있습니다.
하지만 한국어나 일본어, 중국어 등 아스키표에 포함되지 않은 문자들은 각 나라마다 별도의 변환표를 만들어서 표준으로 지정했습니다.

보통 이러한 개별 표들은 아스키와 호환되면서 자기 나라 말이 잘 표현될 수 있도록 정의됩니다. 따라서 ‘영어 + 한국어’, ‘영어 + 일본어’는 잘 표현되지만, ‘영어 + 한국어 + 아랍어’는 깨지기 마련입니다. 한국에서 정의한 표에 아랍어를 …

Read More

출처 : http://sweeper.egloos.com/3059940

1. shared_ptr
shared_ptr의 내용은 다음 링크를 참고하기 바라며, 특히 3-9 Circular reference 챕터를 자세히 읽어보기 바란다.
(위 링크엔 shared_ptr의 circular reference에 대한 예제가 포함되어 있다)
2. weak_ptr
shared_ptr은 자신이 참조하고 있는 객체(메모리 주소)에 대해 reference counting을 함으로써, 객체의 수명에 직접적으로 관여한다.
shared_ptr 객체 하나가 소멸되더라도, 동일한 메모리 주소를 참조하고 있는 다른 shared_ptr 객체가 있으면 참조하고 있던 메모리 주소의 객체는 소멸되지 않는다.
하지만, weak_ptr은 shared_ptr을 관리하기 위한 reference count에 포함되지 않는다.
즉, shared_ptr의 객체만 참조할 뿐, shared_ptr의 reference count를 올리지 않는 것이다.
사실 weak_ptr이 shared_ptr을 참조할 때 shared_ptr의 weak reference count는 증가
Read More
출처 : http://egloos.zum.com/sweeper/v/2826435
 
1. auto_ptr
TR1이 발표되기 전까지 std::auto_ptr이 C++ Standara library의 유일한 스마트 포인터였다.
스마트 포인터의 기본적인 특성인 자신이 소멸될 때 가리키고 있는 대상에 대해 자동으로 delete 해줘 메모리 누수 걱정은 없게 작성이 되어 있다.
하지만, auto_ptr은 유일 소유권 개념이 있어서, 객체가 복사되는 순간(복사생성 또는 대입연산) 원래의 auto_ptr은 바로 NULL 처리가 되어 버린다.
class AAA;
 
// RAII 방식으로... AAA 객체 생성
std::auto_ptr<AAA> AAAObject(new AAA());
 
// 복사가 되는 순간, AAAObject는 NULL이 되고, 이제 BBBObject 만이 객체를 가리킨다.
std::auto_ptr<AAA> BBBObject(AAAObject);
 
// 역시 대입이 되는 순간, BBB는 NULL, 이제 AAA가 객체를 가리킴.
AAAObject = BBBObject;
이렇듯 괴상망측한 복사 동작으로
Read More

출처 : http://kdarkdev.tistory.com/37

이클립스의 기본 Properties Editor는 한글로 바로 표현이 안되고 유니코드로 표현되므로 유니코드를 한글로 인식시킬수있는 플러그인이 필요합니다.

테스트는 이클립스 3.7.2에서 했으며 이전에 사용하던 3.4, 3.5에서도 이상없이 동작 했습니다.

*** 이클립스 3.5 이하

1. 이클립스 메뉴의 Help->Install New Software 클릭

2. 상단의 Add버튼 클릭후 Name에는 아무이름이나 정하고 Location에는

http://propedit.sourceforge.jp/eclipse/updates 입력하고 OK 클릭

3. 목록에 Pending이라는 글이 뜨고 잠시 기다리면 저장소에서 검색된 목록이 뜨는데

목록중 가장하단의 PropertiesEditor에 체크하고 next누르고 다음단계에서도 Next누르면서 설치.

*** 이클립스 3.6 이상

만약 이클립스 3.6이상을 사용중이라면 이클립스 marketplace를 이용하면 더 편하게 설치 할 수 있는데

방법은 이 블로그의 http://kdarkdev.tistory.com/36에서 find항목의 검색어만 변경하면 되고 검색어는 properties editor

Read More

출처 : http://blog.remotty.com/blog/2014/01/28/lets-study-rest/

이 글에서는 REST(Representational State Transfer)에 대해서 알아보겠습니다.

목차

머리말

바로 위에서 REST에 대해서 알아본다고 하였지만, REST의 정의와 같은 것은 생략할 예정입니다. 진짜로 이글에서 다룰 것은 실제 RESTFul한 API를 작성할 때 도움될만한 것들을 공부합니다. 또한 여러가지 규칙이 있지만 어느 규칙이 진짜이고, 표준화 된것이 없기때문에(이런것으로 알고있습니다.) 실제 많은 사이트들이 약간씩은 다른 형태로 REST API를

Read More