서비의 다락방

주말 오후, 심심함을 떨치고자  서비의 포토 갤러리의 스타일 시트를 손봤습니다.
처음엔 간단히 색상만 바꾸고 그만두려고했는데 하다보니 이것저것 손이 가게되더군요.

사진 상단에 위치하던 광고도 내리고 색상을 예전보다 더 어두운 톤으로 바꾸고 전체적인
폰트크기와 색상도 손봤습니다.

아직 테마까지 바꾸고 싶은 생각이은 없습니다. Gallery2 특징으로 자유로운 테마의 변경이
가능하지만 테마를 바꾸면 그 테마의 분위기에 맞춰 사진 출력 설정을 손봐야하는게 많은
까닭도 있습니다.


일단, 어두운 톤으로 바꾼 전체적인 분위기는 예전보다 마음에 드네요, ^.^

"너랑 술 먹는 거 정말 오랜만이다.. 요즘 공부하기 힘들지?"

"아버지"

"응?"

   . . . . .

"자식 싱겁긴.. 말해봐."

"저, 공부 그만둘까 해요."

"너 후회하지 않을 자신 있어?
옛날에 말이다. 레드 제플린하고 비틀즈에 푹 빠진 사람이 있었어.
어느 날 그 사람 손에 드럼 스틱이 쥐어져 있는 거야. 그날 이후 그 사람 꿈은 최고의 드러머가 되는 거였어.
세월이 지나 우연히 그 사람을 만나게 되었는데 말쑥한 양복차림에 커다란 서류가방을 들고 땀을 뻘뻘 흘리며
뛰어가고 있었어.
결혼을 하고 자신을 쏙 빼닮은 아이도 태어났고.. 서둘러 가려는 그 사람을 붙잡고 후회하지 않냐고 묻자
그러는 거야. '더 큰 꿈이 생겼다'고. 바뀐 그 꿈이 그 사람한테는 새로운 희망을 가져다 준거야.

아들아, 더 나은 꿈을 찾지 못했다면 지금 포기하지 마. 난 내 아들이 세상에 당당히 맞서 줬으면 좋겠다."

약간 성인풍 일본 꽁트입니다..  좀 야한듯하지만 상황 전개가 자연스러워 의외로 재미있네요.. ㅎ~

지난 목요일 회사 신년회가 있었습니다.
지난 신년회에 비해 올해는 새 얼굴들이 많이 늘었는데요..
새로운 2008년, 다시 한번 기합을 넣고 달려봐야 겠어요.

Java 6가 릴리즈 된지 꽤 시간이 흘렀지만, 아직까지 어디가 어떻게 변경되고, 향상되었는지 찾아보지 못하고 있었다.
아래 두 링크의 기사는 java 6의 새로운 기능화, 어떤부분이 개선되었는지 잘 나타내고 있으므로 시간을 내어 꼭 한번
읽어두도록하자.

What's New in Java SE 6
Features and Enhancements

주말을 이용해 업무에 쓸만한 어플리케이션을 하나 만들고 있는데
그냥 마음내키는대로 시작한 일인지라.. 90%정도 진행해 놓곤 땃짓만 하고 있네요.

지금은... 이런 뻘짓을 하고 있습니다. ^^

자바 세상에는 서로 다른 버추얼머신 상에서 작동하고 있는 객체 간의 통신을 위해 RMI(Remote Method Invocation)라는
기술을 이용할 수 있습니다. (물론 이 RMI도 근본적으로는 소켓통신을 하게 되지만 입출력 스트림의 마샬링과 언마샬링을 같은
복잡하고 지루한 작업을 하지 않아도 되죠.)

RMI라는것은 간단히 말해 다른 버추얼머신상에 존재하는 객체의 메소드를 마치 자신의 메소드인 것처럼 사용할 필요가 있을 때
이용할 수 있는 기법입니다.
예를 들면, 서버 A는 제품정보를 이용해 복잡한 연산을 거쳐 유사한 제품, 혹은 입력한 제품이 속할 분류를 추론해 내는 서비스를
한다고 가정합시다. 서버 B는 관리자가 제품정보를 등록하고 관리하는 역할을 수행합니다. 이때 서버 B에서 관리자가 제품정보를
등록하기 전 등록하고자 하는 제품의 유사한 제품을 확인하고 싶어합니다.
이런 때, 어떻게 할 수 있을까요?  
우선은 서버 A의 기능을 서버 B에도 구현하는 방법이 있겠군요. 하지만 이 방법은 서버와 개발 리소스의 낭비라고 판단됩니다.
혹은, A서버 기능을 B서버에 구현하지 못하는 상황이 생길 수도 있겠죠.
이럴 경우 RMI는 적절한 구원자가 될 수 있습니다. RMI를 이용하면 A서버에서 수행하는 복잡한 연산은 겉으로 드러내지 않으면서
A서버의 특정 기능을 B서버에서 마치 자신의 기능인양 사용할 수 있도록 해 줄 수 있습니다. (객체의 마샬링과 언마샬링에는
상당한 네트웍, CPU자원이 필요한 건 사실입니다만, 이로써 두 시스템의 자연스런 통합이 가능해 집니다.)

서두가 길어졌네요.

이번 포스팅에는 RMI처럼 원격 메소드를 호출하는 다른 방법에 대해 알아보고자 합니다.
이름하여 XML-RPC.
RPC( Remote Procedure Call)은 RMI라는 단어가 있기 전부터 쓰이던 용어로, 분산환경에서 이기종 프로세스를 네트워크를 통해
호출할 수 있도록 하는 기술입니다. XML-RPC는 RPC프로토콜을 XML로 구현한 것이며, HTTP프로토콜상에서 XML데이터를
인코딩해서 전송합니다.

여기서는 자바 어플리케이션에서 Apache XML-RPC구체를 이용하여 원격 메소드를 호출하는 방법을 알아보겠습니다.
( 이하의 글은 붉은늑대 님의 블로그에서 발췌하였습니다. )

1. XML-RPC의 동작방식
XML-RPC는 HTTP 기반의 클라이언트/서버 방식으로 동작한다. 따라서 특정 어플리케이션이 XML-RPC 서비스를 하기 위해서는
반드시 XML-RPC 서버가 필요하다. XML-RPC 서버는 클라이언트로부터 특정 객체의 메소드 호출 요청을 받고 그 메소드를 실행하는
역할을 한다. XML-RPC API(http://ws.apache.org/xmlrpc/apidocs/)를 보면, WebServer 클래스를 찾아볼 수 있는데 이 클래스가
XML-RPC 서버 역할을 한다.

2. XML-RPC 서버 만들기
XML-RPC 서버는 WebServer 클래스 또는 XmlRpcServer 클래스를 이용해 작성할 수 있다. XML-RPC 서버에 등록되고 관리되는 객체를
Handler라고 하며, XML-RPC 서버 클래스의 addHandler 메소드를 사용해 Client가 접근할 객체를 등록할 수 있다.

예제코드) XML-RPC 서버
[code]
import java.util.Hashtable;
import org.apache.xmlrpc.*;
   
public class JavaServer {
 
    public JavaServer () {
        // Our handler is a regular Java object. It can have a
        // constructor and member variables in the ordinary fashion.
        // Public methods will be exposed to XML-RPC clients.
    }
  
    public Hashtable sumAndDifference (int x, int y) {
        Hashtable result = new Hashtable();
        result.put("sum", new Integer(x + y));
        result.put("difference", new Integer(x - y));
        return result;
    }
   
    public static void main (String [] args) {
        try {
               
            // Invoke me as <http://localhost:8080>.
            WebServer server = new WebServer(8080);
            server.addHandler("sample", new JavaServer());
            server.start();
   
        } catch (Exception exception) {
            System.err.println("JavaServer: " + exception.toString());
        }
    }
}
[/code]
* 위 소스에서는 편의상 JavaServer 객체를 Handler로 등록하였다.


3. XML-RPC 클라이언트 만들기
XML-RPC 클라이언트도 서버와 마찬가지로 매우 간단하게 작성할 수 있는데, XmlRpcClient 클래스를 이용하여 다른 시스템의
객체에 접근할 수 있다. 특정 객체의 메소드 호출은 XmlRpcClient의 execute 메소드를 사용하면 되는데 호출할 객체의 메소드는
dot expression으로 표현되며, 호출할 메소드에 전달할 파라미터는 Vector에 담아서 넘기면 된다. 이 때 메소드의 호출 결과는
Hashtable로 리턴되며 메소드 호출에 실패했을 경우엔 XmlRpcException을 발생시킨다.

예제코드) XML-RPC 클라이언트
[code]
import java.util.Vector;
import java.util.Hashtable;
import org.apache.xmlrpc.*;

public class JavaClient {
  
    // The location of our server.
    private final static String server_url = "http://localhost:8080";
  
    public static void main (String [] args) {
        try {
   
            // Create an object to represent our server.
            XmlRpcClient server = new XmlRpcClient(server_url);
   
            // Build our parameter list.
            Vector params = new Vector();
            params.addElement(new Integer(5));
            params.addElement(new Integer(3));
   
            // Call the server, and get our result.
            Hashtable result =
            (Hashtable) server.execute("sample.sumAndDifference", params);
            int sum = ((Integer) result.get("sum")).intValue();
            int difference = ((Integer) result.get("difference")).intValue();
   
            // Print out our result.
            System.out.println("Sum: " + Integer.toString(sum) +
                               ", Difference: " +
                               Integer.toString(difference));
   
        } catch (XmlRpcException exception) {
            System.err.println("JavaClient: XML-RPC Fault #" +
                               Integer.toString(exception.code) + ": " +
                               exception.toString());
        } catch (Exception exception) {
            System.err.println("JavaClient: " + exception.toString());
        }
    }
}
[/code]
* 위 코드에서는 서버에 sample이라는 이름으로 등록된 객체의 sumAndDifference 메소드를 호출하고 있다.

4. XML-RPC 서버 서블릿 만들기
XML-RPC 서버를 작성하면 별도의 서버 프로세스를 실행해야 한다. 만약 WAS 상에서 동작하는 웹어플리케이션의 경우 웹어플리케이션의
특정 객체에 접근하고 싶은 경우엔 (웹어플리케이션이 동작중인 JVM과 XML-RPC 서버가 동작중인 JVM이 서로 다르기 때문에) 위와 같이
별도의 서버를 작성하여 실행할 수 없다. 이와 같은 경우엔 XML-RPC 서버를 서블릿으로 작성하여 웹어플리케이션에 포함시키면 된다.
이렇게 하면 클라이언트에서 서블릿의 특정 URL로 접근하여 원격으로 메소드를 호출할 수 있다.

예제코드) XML-RPC 서버 서블릿
[code]
import java.io.*;
import javax.servlet.*;
import javax.servlet.http.*;
import org.apache.xmlrpc.*;

public class XmlRpcServlet extends HttpServlet {

    protected XmlRpcServer xmlrpc;
   
    public void init(ServletConfig config) throws ServletException {
        XmlRpc.setEncoding("euc-kr");
        XmlRpc.setKeepAlive(true);
        xmlrpc = new XmlRpcServer();
        xmlrpc.addHandler("hello", new HelloHandler());
        XmlRpc.setDebug(false);
    }

    // doPost , doGet
    public void doPost(HttpServletRequest request, HttpServletResponse response)
        throws ServletException, IOException {
        //maintenance of public security
        //String auth = request.getHeader( "Authorization" );
        byte[] result = xmlrpc.execute( request.getInputStream() );
        response.setContentType( "text/xml" );
        response.setContentLength( result.length );
        OutputStream output = response.getOutputStream();
        output.write( result );
        output.flush();
    }
}
[/code]

5. XML-RPC Tips
XML-RPC는 HTTP 상에서 동작하며 전달되는 데이터는 XML로 인코딩된다. 즉, 어플리케이션에서 원격 메소드 호출시 전달할
파라미터나 메소드가 리턴하는 객체의 타입은 반드시 Serializable한 객체여야 한다.



덧 붙임 : 유사한 코드로 PHP에서 xmlrpc의 구현이 궁금 하다면 여기를 방문 해 보자.

하루 일과가 끝나가는 즈음에 가끔 들러보는 이웃블로그를 찾아갔더랬습니다.
저를 반기는 것은 그분만의 감성으로 늘 읽는 재미를 전하던 페이지가 아닌 블로그를 닫는다는
황량한 내용의 페이지였습니다.

제가 관계하지 않았던 사이트야 사라져도 '그러나 보다..' 하겠지만, 비록 오며 가며 안부인사 정도를
나눴을 뿐이지만, 삶의 소소한 교류가 있던 곳이 갑자기 사라지니 곁에두던 친구와 헤어진 것 같은 허전한
기분이 듭니다.

이런 경험은 누구나 한 두 번쯤은 있으리라 생각되네요.
기억 속에서 아스라이 사라져버린 줄 알았던 사이트를 우연한 기회로 다시 방문했을 때 묵묵히 그 자리를
지키고 있는 사이트를 마주했을 때의 작은 감동.

이곳은 누군가를 위해 유지하고 있는 곳이 아닙니다.
하지만, 비록 찾는 사람도 적고 인간적인 교류도 없는 서비만의 다락방이지만, 혹시 모를 그 누군가를 위해
또, 저를 위해 우직하게 살아있는 사이트로 유지해야겠다는 생각을 해봤습니다.

그리고 사이트 유지를 그만두신 이웃님, 어떤 이유에서인지는 알 길이 없지만, 다른 공간에서 뵐 수 있을 거라
믿고 있어요. 그날이 빨리오길 고대하고 있을게요.

이 글을 읽고 있는 당신이 소프트웨어 개발자 혹은 기획자라면 오픈소스와 라이센스에 대해 고민을 하신
경험이 이있을것이라 생각합니다.

'쓸만한 소스를 구했는데... MPL라이센스네.. 이거 우리 프로젝트에 써도 되는거야?'
'뭐.. 오픈소스? 그럼 우리 코드도 다 공개해야 하는거 아냐?'

이런 생각을 해 보신적이 있다면 첨부한 문서를 읽어보시길 권합니다.
문서에는 오픈소스에대한 정의와 몇가지 유명한 라이센스에대한 권한과 제한사항을 다루고 있습니다.

프로그램을 개발하거나 운영하는데 있어 로깅만큼 중요한 기능도 없을것이다. 시스템이나 어플리케이션에서 발생한 문제 해결의 출발점이
'에러의 재현' 과 '로그 분석'이기 때문이다.

Java 진영에서는, 이미 오픈소스에서 발전해 온, Log4J라는 막강한 로깅 프레임웍이 사실상의 표준(de facto standard)으로 존재하고 있다.
( Commons Logging 도 있지만 Log4J의 Wrapper 정도라고 생각하면 된다. )
그럼, MS진영에는 어떤 로깅 프레임웍이 있을까?
지금 회사에서 진행중인 프로젝트가 .Net 기반의 윈도우즈 어플리케이션이라 MS계열에서 널리쓰이고 있을것 같은(?) 로깅툴을 찾아볼 필요가 있었다.

그런데 아니나 다를까.. 이미 이쪽 진영에까지 Log4J의 영향력이 미치고 있을줄이야..
이미 Log4J를 닷넷용으로 포팅한 Log4Net이 있는 것이다.

Log4J를 사용해 봤다면 Log4Net역시 어렵지 않게 사용 할 수 있다.
이번 포스팅에서는 Log4Net을 활용하여 .Net 어플리케이션을 로깅하는 방법을 살펴보자.

Log4Net 공식 사이트 : http://logging.apache.org/log4net/index.html
라이센스 : Apache License, Ver 2.0 ( 상용어플리케이션에 이용할 수 있다!! )
지원하는 프레임워크 : 2008년 1월 현재
                               MS .Net Framework 1.0 , MS .Net Framework 1.1 , MS .Net Framework 2.0 ,
                               MS .Net Compact Framework 1.0 , Mono 1.2.3, MS Shared Source CLI 1.0, CLI 1.0 Compatible
                               6개의 프레임워크를 지원.
Appenders 일람

Log4Net은 최종으로 로그가 기록될 장소( 파일, DB, 메일 등..)를 Appender를 이용하여 구분하고 있다.
사용할 Appender를 Log4Net 설정파일에 기술하면 Log4Net이 해당 Appender를 사용하여 로그를 기록하게 된다.  

사용방법은 이렇다.

1. 어플리케이션 소스 코드를 작성한다.

소스코드 보기..

2. 다운로드 받은 Log4Net을 압축해제하여 나온 디렉토리중 개발을 진행하고 있는 닷넷 프레임워크 버전에 해당하는
   log4net.dll을 Reference 한다.
3. Log4Net 설정하기
    - 설정파일을 작성하여 어플리케이션이 빌드되는 디렉토리에 배치한다.

log4net.xml 보기..

4. 어플리케이션을 빌드후 구동하여 로그가 잘 남는것을 확인한다. ^^

첨부한 프로젝트는 WPF 어플리케이션으로 작성 되었습니다. 비주얼 스튜디오 2008이라면 바로 빌드가 가능하겠지만 VS2005인 경우 실행을 위해서는 http://www.yunsobi.com/blog/280 포스트를 참조하여 WPF개발 환경을 구축 한 후 실행 하셔야 합니다.


좀 더 들여다 볼까요?.

퍼포먼스 ( Perfomance )
로깅에서 퍼포먼스를 이야기할 때 다음 세가지 이슈사항을 고려할 수 있습니다.

1. Logging을 하지 않을 경우( turned off ) 로깅코드에 의한 퍼포먼스
로깅레벨을 OFF 로 설정한 경우라면 메소드 호출 비용이 듭니다. 하지만 메소드 생성에는 파라메터 생성에따르는 숨겨진 비용도 포함되어 있음을 잊지 마세요. 예를들어 다음과 같은 코드
log.Debug("Entry number: " + i + " is " + entry[i].ToString()); 
에서 i 와 entry[i] 를 string으로 치환하는 비용과 각 string을 더하는 비용이 소모됩니다. 파라메터를 생성하는 비용은 파라메터의 갯수와 생성되는 횟수에 큰 영향을 받습니다.

파라메터 생성 비용을 없애고 싶다면 아래와 같은 코드를 작성 하세요.
if(log.IsDebugEnabled)
{
    log.Debug("Entry number: " + i + " is " + entry[i].ToString());
}

디버깅 모드가 꺼져 있다면 위 코드는 파라메터 생성에드는 비용은 0이 될것입니다. 반면에 디버그기능이 켜져 있다면 두배의 비교 시간이 필요합니다. '디버그기능이 켜져있는지(log.IsDebugEnabled)'와 '로거가 디버그 모드인지(log.Debug())' . 하지만 이를 비교하는데 필요한시간은 매우 미미해서 실제 로그를 기록하는데 드는 비용의 1%정도에 해당합니다.
어떤 개발자들은 전처리나 컴파일타임의 테크닉등을 이용하여 로깅에대한 모든 상태를 조절하기도합니다.이는 퍼포먼스 측면에서 보면 완벽하다고 할 수 있겠지만, 로그레벨을 변경하기가 매우 까다로워 집니다. 이렇게 하는것에 대해 많은 사람들이 작은 성능향상을 위해 너무 많은것을 잃고 있다고 조언 합니다.

2. 로깅기능이 켜져 있을 경우 로그레벨에 의한 '로그작성'과 '로그작성 않기'의 판단에 따른 퍼포먼스
이는 기본적으로 로거 Hierarchy의 동작 성능에 따릅니다. 로깅이 켜져(turn on)있다면 log4net은 로그레벨과 로거의레벨을 비교하는 작업이 필요합니다. 하지만 로거 자체에는 레벨이 할당되어 있지 않습니다. 로그레벨은 로거 Hierarch로부터 상속받게 됩니다. 로그레벨을 상속받기 이전에 로거는 상위클래스를 확인 할 필요가 있겠지요.

여기에는 가능하면 짧은시간으로 동작케하기위한 노력이 담겨있습니다. 예를들어, 자식 로거들은 그들의 부모하고만 연결이 됩니다. 이전에 살펴본 BasicConfigurator의 예에서, Com.Foo.Bar 라는 이름의 로거는 루트로거와 직접 연결됩니다. 이것으로 존재하지 않을 Com 이나 Com.Foo 로거를 찾는 수고를 피할 수 있습니다. 이것으로 산재한 (sparse) hierarchies 속에서 상당한 속도향상을 얻을 수 있습니다.

로그레벨 의한 로깅 여부 판단은, IsXXXEnable 프로퍼티를 조사하는것에비해 약 3배정도 느리다고 볼 수 있습니다.

3. 로그메세지를 실제 기록하기
이는 로그메세지를 포메팅하는것과 목표에 실제로 내보내는 비용이 발생합니다. 여기에는 포메터와 Appender가 가능한 빨리 동작하도록 노력을 기울이는 수밖에 없겠지요.


어찌돼었든, log4net의 많은 기능들은 '속도'의 관점에서 디자인되었습니다. 몇몇 log4net 컴포넌트들은 성능향상을 위해 몇번이고 재작성 되었으며, 여전히 옵티마이즈되고 있으며 자주 갱신되고 있습니다. 이것만은 알아주세요.
SimpleLayout의 퍼포먼스 테스트에서 log4net은 System.Console.WriteLine 만큼의 성능을 보여주고 있다는 것을. 


PatterLayout 수정하기
log4net의 출력형식을 조정하기위해서는 PatternLayout과  Conversion Character를 이용할 수 있습니다.
예를들어 log4net.xml에 아래와 같은 패턴을 정의하여 남긴 로그를 보면
[code]
   <appender name="RollingFile" type="log4net.Appender.RollingFileAppender">
       <file value="C:\Window1.log" />
       <appendToFile value="true" />
       <datePattern value="-yyyy-MM-dd" />
       <rollingStyle value="Date" />
       <layout type="log4net.Layout.PatternLayout"> <!-- 레이아웃으로 패턴레이아웃을 지정했습니다.  -->
           <conversionPattern value="%d [%t] %-5p %c - %m%n" /> <!-- conversion 캐릭터를 기술했습니다. -->
       </layout>
   </appender>
[/code]
아래와 같은 형식으로 남습니다.
[code]
2008-01-08 13:30:18,938 [10] DEBUG Log4NetSample.Window1 - Log4NetSample.Window1인스턴스 생성 됨
2008-01-08 13:30:24,792 [10] DEBUG Log4NetSample.Window1 - OnButtonMouseDown 이벤트 발생!!
2008-01-08 13:30:24,856 [10] ERROR Log4NetSample.Window1 - 에러 발생!!!
System.FormatException: 입력 문자열의 형식이 잘못되었습니다.
   위치: System.Number.StringToNumber(String str, NumberStyles options, NumberBuffer& number,
 NumberFormatInfo info, Boolean parseDecimal)
   위치: System.Number.ParseInt32(String s, NumberStyles style, NumberFormatInfo info)
   위치: System.Int32.Parse(String s)
   위치: Log4NetSample.Window1.button_Click(Object sender, RoutedEventArgs e) 파일 D:\Project2007
\emodioroot\Samples\Log4NetSample\Log4NetSample\Window1.xaml.cs:줄 68
[/code]

출력 결과물 형식을 변경하기위해선 Conversion Character를 변경할 필요가 있는데요.
이용가능한 Conversion Character 일람은 아래와 같습니다.

Conversion Character	Effect
a	Used to output the frienly name of the AppDomain where the logging event was generated.
c	Used to output the logger of the logging event. The logger conversion specifier can be optionally followed by precision specifier, that is a decimal constant in brackets. If a precision specifier is given, then only the corresponding number of right most components of the logger name will be printed. By default the logger name is printed in full. For example, for the logger name "a.b.c" the pattern %c{2} will output "b.c".
C	Used to output the fully qualified class name of the caller issuing the logging request. This conversion specifier can be optionally followed by precision specifier, that is a decimal constant in brackets. If a precision specifier is given, then only the corresponding number of right most components of the class name will be printed. By default the class name is output in fully qualified form. For example, for the class name "log4net.Layout.PatternLayout", the pattern %C{1} will output "PatternLayout". WARNING Generating the caller class information is slow. Thus, it's use should be avoided unless execution speed is not an issue.
d	Used to output the date of the logging event. The date conversion specifier may be followed by a date format specifier enclosed between braces. For example, %d{HH:mm:ss,fff} or %d{dd MMM yyyy HH:mm:ss,fff}. If no date format specifier is given then ISO8601 format is assumed (ISO8601DateFormatter). The date format specifier admits the same syntax as the time pattern string of the ToString. For better results it is recommended to use the log4net date formatters. These can be specified using one of the strings "ABSOLUTE", "DATE" and "ISO8601" for specifying AbsoluteTimeDateFormatter, and respectively ISO8601DateFormatter. For example, %d{ISO8601} or %d{ABSOLUTE}. These dedicated date formatters perform significantly better than ToString.
F	Used to output the file name where the logging request was issued. WARNING Generating caller location information is extremely slow. It's use should be avoided unless execution speed is not an issue.
l	Used to output location information of the caller which generated the logging event. The location information depends on the CLI implementation but usually consists of the fully qualified name of the calling method followed by the callers source the file name and line number between parentheses. The location information can be very useful. However, it's generation is extremely slow. It's use should be avoided unless execution speed is not an issue.
L	Used to output the line number from where the logging request was issued. WARNING Generating caller location information is extremely slow. It's use should be avoided unless execution speed is not an issue.
m	Used to output the application supplied message associated with the logging event.
M	Used to output the method name where the logging request was issued. WARNING Generating caller location information is extremely slow. It's use should be avoided unless execution speed is not an issue.
n	Outputs the platform dependent line separator character or characters. This conversion character offers practically the same performance as using non-portable line separator strings such as "\n", or "\r\n". Thus, it is the preferred way of specifying a line separator.
p	Used to output the level of the logging event.
P	Used to output the an event specific property. The key to lookup must be specified within braces and directly following the pattern specifier, e.g. %X{user} would include the value from the property that is keyed by the string 'user'. Each property value that is to be included in the log must be specified separately. Properties are added to events by loggers or appenders. By default no properties are defined.
r	Used to output the number of milliseconds elapsed since the start of the application until the creation of the logging event.
t	Used to output the name of the thread that generated the logging event. Uses the thread number if no name is available.
u	Used to output the user name for the currently active user (Principal.Identity.Name). WARNING Generating caller information is extremely slow. It's use should be avoided unless execution speed is not an issue.
W	Used to output the WindowsIdentity for the currently active user. WARNING Generating caller WindowsIdentity information is extremely slow. It's use should be avoided unless execution speed is not an issue.
x	Used to output the NDC (nested diagnostic context) associated with the thread that generated the logging event.
X	Used to output the MDC (mapped diagnostic context) associated with the thread that generated the logging event. The key to lookup must be specified within braces and directly following the pattern specifier, e.g. %X{user} would include the value from the MDC that is keyed by the string 'user'. Each MDC value that is to be included in the log must be specified separately.
%	The sequence %% outputs a single percent sign.

 

파비콘(favicon)은 웹서핑 중에 자주 보셨을 텐데요.. 아래 이미지와 같이 주소표시줄 앞에 나타나는 작은 아이콘을 지칭합니다.

파비콘은 즐겨찾기와 URL표시줄에 작은(16X16) 사이즈의 아이콘으로 사이트의 로고를 나타내는 기능을 하며
마이크로소프트 Internet Explorer 5.0 부터 추가되어 현재 대부분의 브라우저에서 이 기능을 지원하고 있습니다.

사이트에 파비콘을 넣는 방법은 간단하지만, 아이콘(ico)파일을 만들기가 귀찮아 적용하지 않는 경우도 많을 거라 생각합니다.
오늘 우연히 러시아 사이트 중에 이 파비콘을 웹상에서 만들어 주는 곳을 찾게 되어 소개 하고자 합니다.

http://favicon.ru/en으로 접속하시면 영문으로 구성된 파비콘 제작 페이지를 보실 수 있습니다.
이메일 주소를 이미지로 만들어 주는 사이트와 비슷하다고 생각하시면 되는데요. 이 사이트만의 독특하고 신기한 기능이 있습니다.
만들어진 파비콘을 웹상에서 픽셀단위로 수정하여 다시 다운로드 받을 수 있다는 겁니다.

순서는 여타 이미지 제작 웹페이지와 크게 다르지 않습니다.

  1. 이미지를 업로드 하고,
  2. 제작된 파비콘을 다운로드 받거나,
  3. 수정하여 다운로드 받습니다.











아래 사이트에서 파비콘에 대한 더 많은 정보를 얻으실 수 있습니다.
http://www.thesitewizard.com/archive/favicon.shtml

예상치 못한 사고 (공지 참조)로 인해 서비의 다락방 주소가 바뀌었습니다.
도메인은 유지되고 하위 주소줄이 변경 되었습니다.

기존 : http://www.yunsobi.com/tt/subby 에서
현재 : http://www.yunsobi.com/blog 로 수정하였습니다.

앞으로도 잘 부탁드립니다. ^^

일본의 프로그래머에 대한 우스갯소리가 있어 데려왔습니다...
(출처 : 전파만세 - 리라하우스 제3별관 )
과장된 감이 없잖아 있습니다. 그냥 우스갯 소리로 읽고 넘기시면 됩니다. 하지만
다른 직업군이라고 다르지 않겠지만 프로그래머의 자조적인 목소리는 우리나라랑 별반 다를 게 없군요. ^^

참고. 아래 글에 등장하는 SE(시스템 엔지니어)는 우리나라의 PM(프로젝트 매니저)에 해당합니다.

1. "오늘까지"라는 말은 "내일 아침까지"라는 말이다.

2. 프로그램은 내가 원하는대로 움직이지 않는다. 타이핑대로 움직인다.

3. 요구 사양은 프로그램을 완성한 후에 추가된다.
   기본 사양은 완성품을 고객이 보고 나서 결정된다.
   상세 사양은 사용자가 프로그램을 사용해 본 이후에 결정된다.

4. 소프트웨어 설계에는 두 개의 방법이 있다.

    하나는 결함이 있을 수 없을 정도로 단순하게 만드는 방법이다.
    다른 하나는, 분명한 결함을 눈치채기 어려울 정도로 복잡하게 만드는 방법이다.

5. 코드는 개발 현장에서 사용하는 것이 아니라 납품처에서 사용하는 것이다.
    디버그는 납기일까지 하는 것이 아니라, 납품된 이후에 하는 것이다.

6. 프로그래머를 죽이기 위해서는 칼이 필요없다. 프로그램의 요구조건을 3번만 바꾸면 된다.

7. 다른 사람을 믿으라. 그 사람이 해결해줄지도 모른다.
    주의사항 - 먼저 자신을 의심해라.

8. 개발에 마지막은 없다. 출시만이 있을 뿐이다.

9. 클라이언트의 요구사항이 제 아무리 뒤늦게 추가되어도 납기일은 변하지 않는다.
    이것을「납기 불변의 법칙」이라고 한다.

10. 우리의 고객들은 물과 기능추가를 공짜라고 생각하고 있다.

11. 주머니가 짠 고객일수록 잔소리가 많다.

12. 개발 스케줄은 산수를 무시하며 짜여진다. 영업과는 1＋1=2를 이해하지 못하는 사람의 모임이다.

13. 한 명이 쓰러지면 모두가 쓰러진다.

14. 버그가 너무 심하다? 걱정마라. 어느 순간 그것은 기본 사양이 될 것이다.

15. 좋은 설계는 한 명의 천재보다 세 명의 범재를 요구한다.
     나쁜 설계는 백명의 범재보다 한 명의 천재를 요구한다.

16. 고객에게 시스템 엔지니어는 부하이며, 프로그래머는 가축이다.
     시스템 엔지니어에게 고객은 돈이다.
     프로그래머에게 고객은 보이지 않는 악성 바이러스다.

17. 돈과 시간만 있으면, 그 어떤 시스템이라도 만들 수 있다고 생각하는가?
      웃어라. 그 기회는 영원히 주어지지 않는다.

18. 품질은 사양 변경의 수와 규모에 의해, 얼마나 열화될지 결정된다.

19. 영업과는 공상이 실현된다고 생각하는 몽상가이다.
      시스템 엔지니어는 넘을 수 없는 벽이 없다고 믿는 모험가이다.
      프로그래머와는 몽상가와 모험가에 의해 칠흑의 바다에 내던져진 표류자이다.

20. 유능한 프로그래머가 프로그램 설계개념도를 받아들고 최초로 하는 일은, 프로그램의
     목적을 이해하는 것이다. 그리고 그 다음으로 하는 일은, 지정된 방법과 시간 안에는
     도저히 그 목적을 완수할 수 없다는 사실을 시스템 엔지니어에게 이해시키는 일이다.

21. 프로그램이란, 운과 감에 의해서 작성되는 기적이다.
      운과 감이 없다면, 그 기간 내에 그러한 목표를 실현될 수 있을 리 없다.
      따라서 사양 변경은 기적에 트집을 잡는 건방진 행위이며, 사양 추가는 기적이 두 번
      일어날 것으로 믿는 무모한 행위이다.

22. 시스템 엔지니어는 지구력, 프로그래머는 순발력.

23. 정시에 퇴근하면, 일이 늘어난다.

24. 완벽한 프로그램은 완벽한 시간과 돈을 필요로 한다.
      미국의 국가 예산을 무제한으로 사용하는 NASA마저도, 아직 시간과 돈이 부족하다고 한다.

25. 눈으로 훑어볼 틈이 있다면 움직여라. 뇌세포보다 CPU가 더 해석이 빠르다. 그리고, 그 사이,
      쉴 수 있다.

26. 불편함을 버그라고 부를 것인가, 사양 상의 제한 사항이라고 부를 것인가는 남겨진 개발일자와
     납기일에 의해 결정된다.

27. 정장 대신 캐쥬얼을 입고 출근하는 "캐쥬얼 데이"를 세간에서는 휴일이나 공휴일이라고 부르는
      것 같다.

28. 프로그램은 머리로 기억하지 않는다. 몸으로 기억한다.

29. 내일 쉴 수 있다면 오늘 죽어도 괜찮다.

30. 고객은 거짓말을 한다.
      영업은 꿈을 말한다.
      시스템 엔지니어는 공상을 이야기한다.
      프로그래머는 과묵해진다. (혼잣말은 많아진다)

31.「네, 할 수 있습니다」라고 말하기 전에 10초만 곰곰히 다시 생각해보라.

32. 프로그래머는 1분 생각하고 1일을 코딩에 소비한다.
      1시간 생각하고 1시간 코딩하는 대신에 말이다.

33. 납품 이후의 디버그는 버그를 부른다.

34. 세 개의 디버그는 하나의 버그를 낳는다. 이것을 버그의 엔드리스 루프라고 한다.

35. 안 좋은 예감은 반드시 적중한다. 그러나 프로그래머는 그 안 좋은 예감에 반응하지
      않는다. 그것은 시스템 엔지니어의 일이다.

36. 아수라장을 해결할 수 있는 방법은 오직, 고객이 돈을 지불하는 것 뿐이다.

37. 아마추어는 버그발견의 천재이다.

38. 아, 그건 마이크로소프트에서만 가능한 주문입니다.

39. 프로그래머가 불만이라고 생각하는 부분은 고객도 반드시 불만이라고 생각한다.

40. 건강하기 때문에, 건강을 해친다.

41. 그건, 당신이 말한 요구조건입니다만.

42. 아, 개발실의 창문은 안 열립니다. 그 이유는 옛날에 한 프로그래머가 그 창문에서···

43. 고객은 최악의 사태를 믿지 않으며, 그 사태에 대한 준비를 악질적인 비용청구라고 생각한다.
      시스템 엔지니어는 최악의 사태를 대비하고 준비하려 한다.
      프로그래머는 최악의 사태를 누구보다 잘 예상하지만, 무시한다.

44. 만약 다른 직업을 갖게 된다면, 정시퇴근을「도망」이라고 부르지 않는 직업이 좋을 것 같다.

45. 시스템 엔지니어가 프로그래머에게 말하는「상식」은 3시간마다 변한다.

46. 최소한 자기가 쓴 시방서는 읽어주세요.

47. 고객이 시스템 엔지니어에게 사랑받는 방법은, 시스템 개발에는 시간이 곧 돈이라는 사실을
      깨닫고 빨리 최종요구조건을 확정하는 것이다.
 
     SE가 고객에게  사랑받는 방법은, 프로그래머에게 미움받는 것이다.

48. 납기일이란, 작업현장이 우리 회사에서 고객의 회사로 바뀌는 날을 의미한다.

49. 가끔 일어나는 버그는 버그가 아니다. 스펙이다.

50. 개발비의 30%는 프로그램의 요구조건을 확정하는데 사용된다.
     개발비의 30%는 프로그램의 요구조건을 변경하는데 사용된다.
     개발비의 30%는 프로그램의 버그를 잡는데 사용된다.
     개발비의 10%만이 프로그램의 개발에 사용된다.

자바 어플리케이션도 실행 jar ( Executable JAR ) 파일로 작성 하면, jar파일을 더블클릭하여 실행하는 것이 가능합니다만..

정말?

자바어플리케이션을 실행할 PC에 자바구동환경( 자바런타임 JRE )이 미리 설치 되어 있지어야 한다는 약점이 있습니다.
이 때문에 자바 Swing/AWT등으로 작성된 GUI어플리케이션의 경우 어플리케이션 작성 후 Executable JAR파일을
윈도우용 실행 파일(exe)로 감싸는(Wrapping)하는 단계를 거치게 됩니다.

Executable JAR 파일을  exe파일로 감싸데는 몇 가지 방법이 있지만 이번 포스팅에서는 launch4j를 이용해 자바 어플리케이션을
exe형태의 파일로 변환하는 방법을 소개토록 하겠습니다.

잠깐 launch4j를 소개하자면 sourceforge.net 에 등록된 프로젝트로 Cross-platform Java executable wrapper를 구현하고 있습니다.
사용법의 간편함과 다양한 옵션이 존재하는 장점 외에도, 라이센스에서 이 프로그램을 이용해서 상업적인( commercial ) 어플리케이션을
작성해도 된다고 밝히고 있습니다.

  준비물 :
    launch4j ( 다운로드페이지 열기 )
    exe 파일을 만들 자바 어플리케이션.

 

우선, 자바 어플리케이션을 작성하여 Executable JAR로 만들어 둔다.
( 이전 포스팅 참조 하며, 본 예제를 실행해 보기 원한다면 위에 링크한 자바 어플리케이션을 사용하시면 됩니다.)

그 다음, launch4j 실행하셔서 아래 화면을 참조 하셔서 wrapping환경을 세팅합니다.


1 번 항목에 jar파일을 어떤 디렉토리에 어떤 파일명의 exe로 떨굴지를 기술합니다.
2 번 항목에서 exe로 wrapping할 Executable jar파일을 선택 합니다.
3 번 항목에 기술한 URL은 변환된 자바 exe파일을 실행할 PC에 자바런타임 환경이 없을경우 안내문구와 이동할 웹사이트를 기술합니다.



4 번 항목에서 main 클래스를 기술합니다. Executable jar를 만들어 뒀다면 파일선택에서 jar파일을 선택하는것
만으로도 jar의 MANIFEST.MF 을 분석해서 main 함수와 lib 를 자동으로 세팅해 줍니다.



GUI 어플리케이션인지 Console 어플리케이션인지 세팅 해 줍니다.



5 번 항목은 exe파일과 jre를 함께 배포할 경우 jre패스가 어떻게 되는지 상대 경로 혹은 절대경로를 기술해 줍니다.
6 번 항목에 자바어플리케이션이 실행되기위한 최소버전의 JRE를 기술해 줍니다.



Add Version infomation을 체크하면 exe파일의 속성정보에 나타낼 정보를 기술합니다.



Add Custom Message를 체크하면 각 상황에따라 출력할 메세지를 기술할 수 있습니다.
현재 버전까지는 한글 메세지는 지원하지 않더군요. ^^

위와 같은 내용을 기술 해 준 후 launch4j 상단 아이콘 중 톱니바퀴를 클릭하면 지정한 exe파일이 생성 됩니다.