Calling a Java method with variable number of arguments in JRuby

결론부터 얘기하자면, Java의 variable number of arguments(이하 varargs)를 가진 Java 메서드를 JRuby 코드에서 호출하려면, 여러 argument들을 나열하거나 Ruby Array를 사용하면 안되고, Java array 객체를 생성해주어야한다. Java의 varargs는 Java array와 동일하게 취급되므로 당연히 Java array의 경우에도 마찬가지다. 그렇다면, Ruby Array는 무엇이랑 대응될까? 바로 java.util.List다.

다음은 이러한 동작을 테스트하기 위한 간단한 Java 클래스. 위에서 언급한대로, Java array parameter를 varargs로 보면 되겠다.

import java.lang.String;
import java.util.List;
import java.util.ArrayList;
import java.util.Arrays;

public class Song {

    public enum Category {
       
POP, ROCK, CLASSIC, JAZZ
   
}

    private String title;
   
private List<Category> categories = new ArrayList<Category>();

    public Song(String title) {
       
this.title = title;
   
}

    public void setCategory(Category category) {
       
this.categories.clear();
       
this.categories.add(category);
   
}

    public void setCategoryList(List<Category> categories) {
       
this.categories.clear();
       
this.categories.addAll(categories);
   
}

    public void setCategories(Category[] categories) {
       
this.categories.clear();
       
this.categories.addAll(Arrays.asList(categories));
   
}
   
   
public String toString() {
       
return "Title: " + title + " Categories: " + categories;
   
}
       
}  

다음은 위의 Java 클래스를 사용하는 JRuby 코드.

require 'java'

include_class 'Song'

song = Song.new 'Waiting On The World To Change'
puts song

song.setCategory Song::Category::POP
puts song

categories = Array.new
categories.push Song::Category::POP
categories.push Song::Category::ROCK
puts categories.length
puts categories.size
song.setCategoryList categories
puts song

categories = Song::Category[].new 2
#categories.add Song::Category::POP # not working
categories[0] = Song::Category::POP
categories[1] = Song::Category::CLASSIC
puts categories.length
#puts categories.size # not working
song.setCategories categories
puts song

Calling a Java method with variable number of arguments in JRuby 더 읽기"

Support for epoll in JDK 5.0 Update 10

좀 뒤늦은 소식이지만, Sun의 JDK 5.0 Update 10에 epoll 지원이 들어갔습니다. JDK 6.0에 epoll 지원이 들어가면서 JDK 5.0에도 반영된 것 같습니다. nio가 생길 때 당연히 epoll을 지원하겠거니 생각했는데, 의외로 대단히 늦게 지원하기 시작했군요. 그럼 이전에는 select()나 poll()로 구현되어있었다는 얘기군요. epoll을 사용했을 때의 performance, scalability상의 이점은 Blackdown JVM 1.4.2를 이용한 벤치마크에서도 알 수 있습니다. Sun JDK 6.0의 nio 벤치마크 자료는 모르겠지만, 이희승님의 벤치마크에 의하면 10% 정도 향상이 있었다고 합니다. 어쨌든 희소식입니다. C/C++의 성능 우위를 뒤따라잡기 위해서 Java도 열심히 노력하고 있군요.

Support for epoll

The Linux downloads of this update release include an implementation of java.nio.channels.spi.SelectorProvider that is based on the epoll I/O event notification facility. The epoll facility is available in the Linux 2.6 kernel, and is more scalable than the traditional poll system call. This epoll-based implementation may improve the performance of server applications that use the New I/O API and that register hundreds of channels with a selector. For more information, refer to the epoll(4) and poll(2) man pages.

The epoll-based implementation of SelectorProvider is not selected by default. To select it, specify a property value from the command line as follows:

java -Djava.nio.channels.spi.SelectorProvider=sun.nio.ch.EPollSelectorProvider ...

(Excerpted from JDK 5.0 Release Notes)

Support for epoll in JDK 5.0 Update 10 더 읽기"

Lizardlings are Stupid

Neverwinter Nights 2의 주인공은 West Habor에 살고 있는 촉망받는 젊은이인데, 어느날 갑자기 알 수 없는 이유로 West Habor가 습격당하는 것으로 Act I은 시작됩니다. 습격자들을 물리치는 과정에서 주인공은 그들이 누군가에 의해 조종받고 있으며, 어떤 물건을 찾고 있다는 것을 알게됩니다. 주인공의 양아버지는 그 물건이 바로 자기가 예전에 숨겨둔 Silver Shard 때문일 것이라며 마을을 보호하기 위해서는 그 물건을 Neverwinter 시로 가져가야한다고 합니다. 주인공은 아버지의 명에 따라 Silver Shard를 찾으러 가는데, 그곳은 많은 수의 Lizardlings이 차지하고 있었습니다.

치르고 있던 의식을 방해받은 Lizardlings는 주인공 파티에게 적대적인 태도를 취합니다.

주인공은 여기에 대한 변명을 해야하는데, 제가 만든 주인공의 Charisma attribute가 높아서 그런지 몰라도 Diplomacy와 Bluff가 선택지로 뜹니다.

    1. [Diplomacy] 이 곳이 우리 차지였을 때, 우리 부족이 뭔가를 여기에 두고 갔소.
    2. [Bluff] 석신이 당신들의 기도를 듣고 나를 보낸거요.
    3. 문을 열어 준 것 고맙지만, 이제 죽어줘야겠어.
    4. 막 갈려던 참이었다구요.

일단 1번 답을 선택해봅시다.

성공입니다. 그런데, 자기네 땅에 들어온 건 이해하겠는데, 의식을 방해한 건 이해못하겠답니다. 교주(?)라서 그런지 몰라도 대단히 똑똑한 Lizardling이군요. 여기에 대한 답변으로 4번 선택지에 Lie가 뜨네요.

[Lie] 당신들이 여기에 오기 전부터 우리는 석신을 섬겨왔소. 석신께서는 우리들이 서로 돕기를 원할거요.

주인공의 Alignment가 Chaotic Good니까 Lie를 선택하는 것이 합당해보입니다.

역시 성공했습니다.

그렇다면, 애초에 Bluff를 선택했다면 어떨까요? 다음과 같습니다.

난 석신의 화신이다. 너희들은 나를 두려워하라!

라고 하니까 그대로 넘어가네요.

오늘의 교훈: Lizardling들은 멍청하다.

아래는 Silver Shard를 상자에서 꺼내고 있는 주인공 Elenella Lane (제가 만든 캐릭터)의 모습입니다.

Lizardlings are Stupid 더 읽기"

모든 것은 마이크로소프트 탓

이런 ‘시장 혼란’은 결국 윈도의 독점력에 따른 결과다. 다른 대안이 없는 만큼 윈도 비스타에 맞게 서비스 프로그램을 고쳐야 하는 것이다. 정통부도 ‘꼼꼼히 확인해 구매하라’는 이용자 안내에 그칠 뿐, 뽀족한 대책을 내놓지 못하고 있다.

비스타 출시에 따른 이런 혼란은 한국이 유독 심한 것으로 알려졌다. 액티브-엑스의 사용이 보편화되지 않았고 인터넷 연결이 우리나라만큼 원활하지 않기 때문이다. 익명을 요청한 정보통신부 관계자는 “지난해 3분기부터 엠에스 쪽과 공동작업을 했는데, 우리나라의 경우 응용프로그램이 발달해 손볼 대목이 많았음에도 엠에스가 기술자료 공개를 늦게 하는 바람에 이런 일이 벌어졌다”고 말했다.윈도 비스타 혼란…지금 깔면 손해, 한겨레

그렇습니다. 외국은 인터넷 연결과 같은 인프라도 미비할 뿐만 아니라, 소프트웨어가 별로 발달하지 않아서 ActiveX라는 뛰어난 기술도 아직 보편화되지 않았답니다. 게다가 마이크로소프트는 인터넷과 소프트웨어가 우월한 대한민국의 상황을 따라오지 못하고 늑장대처를 하는 후진국 기업의 행태를 보여주고 있습니다.

모든 것은 마이크로소프트 탓 더 읽기"

Next Release of IBM Lotus Notes and Domino

IBM also said the long-awaited next release of IBM Lotus Notes and Domino, known until now as “Hannover,” will enter the public beta phase of its testing in February and should be generally available mid-year. (From IBM Expands Line of Collaboration Software Tools)

IBM의 그룹웨어 솔루션인 Lotus Notes와 Domino의 차기버전 Hannover가 나온단다. Lotus Notes의 Usability는 그야말로 최악이다. (Lotus Notes Sucks) 그냥 출시안하면 안되겠니?

Next Release of IBM Lotus Notes and Domino 더 읽기"

Detecting Duplicated Code in Eclipse

중복된 코드(Duplciated Code)는 Long Method와 함께 Bad Smell의 대표적인 사례 중 하나다. 사람이 중복된 코드를 찾기 위해서는 모든 코드를 봐야하지만, 컴퓨터는 이를 손쉽게 할 수 있다. 컴퓨터가 쉽게 할 수 있는 일은 컴퓨터에게 맡기자.

Eclipse에서 중복된 코드를 탐지해주는 플러그인은 두가지가 있다. 예전에 한번 언급했던 PMD의 부가적인 기능인 CPD(Copy/Paste Detector)를 사용하거나 SDD (프로젝트 사이트)를 사용할 수 있다.

두 플러그인 모두 중복된 코드를 탐지하는 기능 자체는 잘 동작하나, 완성도가 좀 부족해보인다. CPD의 경우에는 중복된 코드에 대한 리포트를 텍스트 파일로 출력해주고, SDD는 Eclipse의 View를 사용해 바로바로 중복된 코드로 찾아갈 수 있도록 되어있으나, 라인 단위가 아닌 문자 단위라서 조금 불편하다. 두 플러그인 모두 하나의 프로젝트 내에서만 중복 코드 탐지가 가능하기 때문에, 여러 프로젝트 간에 코드를 Copy-and-Paste하는 경우를 탐지할 수 없다.

재미있게도 SDD는 정일영이라는 고려대 컴퓨터교육과 분이 만드셨는데, 이걸로 OOPSLA 2005 포스터 세션에 나가신 모양이다. 왠지 얼굴을 알고 있는 분이라는 생각이…

덧붙여, 코드 분석에 관련된 Eclipse 플러그인에 관심이 많다면 Automation for the people: Improving code with Eclipse plugins 이라는 기사가 도움이 될 것이다. Test coverage를 위한 Coverclipse나 Dependency analysis를 위한 JDepend와 같은 플러그인들은 아직 시도해보지 못했다.

Detecting Duplicated Code in Eclipse 더 읽기"

Metrics

http://metrics.sourceforge.net/

자신의 코드를 리팩토링하는 시점은 여러가지(예를 들면, 새 기능을 추가할 때)가 될 수 있겠지만, 이미 관리하기 힘들 정도로 난잡해진 코드를 리팩토링하기 시작해야할 때는 ‘무엇부터 리팩토링할 것인가‘를 결정해야한다. Martin Fowler는 그의 책 Refactoring에서 리팩토링을 해야하는 나쁜 코드의 증상을 ‘Bad Smell‘이라고 한다. 리팩토링의 우선 순위가 높은 코드는 아마 이러한 ‘Bad Smell’이 강하게 나는 코드일 것이다. ‘Bad Smell’을 맡는 방법은 눈으로 모든 코드를 직접 보는 방법도 있겠지만, 팀 개발을 할 경우, 매일 매일 commit되는 코드를 모두 보기란 쉽지 않은 일이다. 기계가 이 일을 대신해 줄 수는 없을까? Metrics는 바로 그러한 일을 해주는 Eclipse 플러그인으로, 코드의 질을 몇가지 유용한 기준들에 따라 수치화해서 보여주고, 정해진 수준을 넘어설 경우 경고도 해준다.

Metrics가 측정해주는 기준들에는 여러가지가 있지만, 일단 어떤 경우에나 유효하다고 생각되는 기준인 ‘Method Lines of Code‘를 채택해서 리팩토링 작업에 적용해보고 있다. ‘Method Lines of Code’는 말 그대로 메서드의 길이인데, 일반적으로 ‘Long Method‘는 이미 나쁜 코드이거나 나쁜 코드로 발전할 가능성이 상당히 높을 뿐더러, OOP에서는 대략 상식을 벗어나는 코드에 해당한다. 디폴트로 Maximum 값이 설정되어있지 않으므로, Preference에서 일단 이 Maximum 값을 가장 보수적인 수치인 100으로 설정(즉, 100라인 이상의 메서드를 경고)해서 리팩토링 대상을 찾고 있다. 현재 프로젝트에서 1등은 350라인이었다는 놀라운 사실도 발견했다. (다행히도, 내가 짠 코드는 아니었다.) 점차 이 기준을 강화해서 대략 50라인 정도로 만들어야 하지 않을까 싶다.

‘Method Lines of Code’를 해결하고 나면, McCabe Cyclomatic Complexity라는 기준을 적용해보려고 생각하고 있는데, 이 기준은 코드 상에서 얼마나 많은 분기가 존재하는가를 나타내는 것이다. 경험 있는 개발자라면 뼈저리게 느끼듯이, 분기가 많다면 코드는 이해하기 힘들다. 프로그래머가 프로그램을 이해하기 위해서는 프로그램의 특정 부분에서 존재할 수 있는 프로세스의 모든 상태들을 알고 있어야하기 때문이다. (디버깅 세션을 상상해보면 이를 이해하기 쉽다.) OO 프로그래밍의 중요한 강점 중의 하나가 바로 이러한 분기들을 객체의 polymorphism으로 해결하는 것이다. 이는 Procedural 프로그래밍에서도 마찬가지로, 경험 있는 C 프로그래머라면, function pointer를 이용해서 polymorphic behavior를 구현해본 경험이 많을 것이다.

최근에 강문식 군을 통해, 자신들의 프로덕트의 코드 품질을 공개하는 Open Quality (참여하고 있는 프로젝트들의 품질 데이터)라는 개념을 접할 수 있었고 매우 흥미로웠다. 이 곳을 통해 서비스를 받는 것도 가능한 것 같아 보이지만, Metrics의 기능을 Ant task를 사용해서 접근할 수 있기 때문에, 이를 Daily Build에 적용해서, 일단 코드의 품질을 실시간으로 팀내 정도에서 공유해보면 어떨까 생각하고 있는 중이다. 리팩토링을 통한 품질의 개선 정도나, 새 기능의 추가에 따른 품질의 저하 정도 등이 관찰 가능하게 될 것이고, 어쩌면 품질에 대한 다른 접근 방식이 가능하게 될 지도 모른다.

Metrics 더 읽기"

Jolt Awards Finalists

지난 15일에 졸트상의 후보들이 발표되었습니다. 전 Agile Software Development에 한표입니다.

http://www.joltawards.com/2007/

Books (Practical/General Developer Interest)

Agile Software Development: The Cooperative Game (Addison-Wesley) by Alistair Cockburn
Catastrophe Disentanglement (Addison-Wesley) by E. M. Bennatan
Eric Sink on the Business of Software (Apress) by Eric Sink
Practices of an Agile Developer (Pragmatic Bookshelf) by Venkat Subramaniam and Andy Hunt
Software Creativity 2.0 (DeveloperDotStar) by Robert L. Glass
Software Estimation: Demystifying the Black Art (Microsoft Press) by Steve McConnell
Weinberg on Writing: The Fieldstone Method (Dorset House) by Gerald M. Weinberg

Books (Technical)

Code Quality (Addison-Wesley) by Diomidis Spinellis
How to Break Web Software (Addison-Wesley) by M. Andrews, J. Whittaker
Java Concurrency in Practice (Addison-Wesley) by Brian Goetz et al
Rails Recipes (Pragmatic Bookshelf) by Chad Fowler
Refactoring Databases (Addison-Wesley) by Scott W. Ambler and P. J. Sadalage
Head First Object-Oriented Analysis and Design (O’Reilly) by B. McLaughlin, G. Pollice and D. West
Ruby Cookbook (O’Reilly) by Lucas Carlson and Leonard Richardson
CSS: The Missing Manual (O’Reilly) by David Sawyer McFarland

Jolt Awards Finalists 더 읽기"