Firen's Diary

1. GUI 환경: MinySubtitleConverter.jar 을 더블클릭.
   
2. CLI 환경: java -jar MinySubtitleConverter.jar 을 입력. (하지만 아직 GUI필요)

• Java 6이상 (5는 아직 미확인) [다운로드]
  
  

[다운로드]

MinySubtitleConverter.jar

결국 이렇쿵 저러쿵 해서 제가 짠 프로그램의 테스트용으로 우분투 i386버전을 깔았습니다. 물론 그래픽 드라이버는 안잡고요 ㅎㅎ

그래서 JDK & JRE 1.6과, eclipse를 설치를 해서 돌려보는데 이게 왠걸? 너무 너무 부드럽게 잘 돌아가는 것입니다. 마치 윈도우에서 Visual Studio .NET 돌리는 느낌?
하도 이상해서 예전에 제가 짰던 홀수 마방진 프로그램으로(참고로 J2SE 1.4기준으로 바꿨습니다.) 테스트를 하는데

162ms... ㄷㄷㄷㄷㄷㄷㄷ

32bit 버전 : 189ms

64bit 버전 : 187ms ㄱ-

참고로 테스트 한 컴파일러 버전도 같이 공개합니다~~.

Ubuntu 7.10 + JRE 1.6.0_03 32bit

Windows Vista + JRE 1.6.0_03 32bit

Windows Vista + JRE 1.6.0_03 64bit

실행방법

몇몇 분은 아시겠지만 제가 가장 많이 사용하는 언어는 바로 자바입니다.(작년 여름 이후 C++을 역전) 그래서인지 저의 JDK & JRE 설치 방법이 있습니다. 그래서 그 순서를 한번 올려봅니다.

1. J2RE 1.4.2
음, 아무래도 아직까지 1.4버전을 많이 사용하다 보니 배포할 프로그램은 이 버전 기준으로 작성하고, 컴파일 합니다. 예전에 올렸던 지뢰 찾기 역시 이 버전으로 컴파일 한 것입니다. ㅎㅎ

주의할 점은 여기서 이걸 체크를 해서 모든 언어를 사용하는 것 정도?

그리고 이것, 최신버전을 사용할 것이기 때문에 끈다.

2. JRE 6
아무래도 인터넷에서 Applet을 사용하기 위해서는 이게 필요합니다. ㅎㅎ
주위 할 점은 위랑 같습니다 ^^

주의할 점이라면 아래 그림처럼 고급 옵션 패널 표시를 체크해야 전부 설치할 수 있다는것 정도?

3. JDK 6 x64
제 컴퓨터에 64비트 운영체제를 설치를 해서 개발 킷은 x64버전을 사용합니다. 몇가지 보면 i386버전과 차이가 있을 것 같지만 사용하는데 크게 지장이 없어서 그냥 사용합니다 ㅎㅎ

4. JRE 6 x64
보통 JDK i386버전을 설치하면 JRE도 같이 설치되는데 x64는 그런 거 없더군요 -_-; 그래서 따로 설치합니다. ㅎㅎ 그런데 왜 32비트를 같이 설치하냐 위에 써 놓은 것처럼 인터넷에서 Applet을 보려면 32비트 버전이 필요합니다. x64라도 Internet Explorer는 보통 32비트 버전을 많이 쓰거든요 ^^

이 작업을 모두 마치면 Path설정을 하는데요, 뭐, 아시는 분은 알겠지만 커맨드 창에서 컴파일 하거나, 자바 파일을 실행할 것이 아니면 안 해줘도 상관없습니다. (의외로 많은 분들이 윈도우 환경에서도 꼭 해줘야 하는 줄 알더군요 물론 리눅스는 꼭 해줘야 하겠지만요 ㅎㅎ)
이건 제가 자주 사용하는 방법이니까. 꼭 저처럼 따라 하실 필요는 없습니다.

우선 JRE와, JDK의 경로를 시스템 환경 변수에 등록해 줍니다.

마지막으로 CLASSPATH는 설정하지 않습니다. 왜냐하면, 최신버전의 Java는 윈도우의 환경변수를 무조건 무시하더군요 -_-;;; 그리고 5.0과 달리, 6는 Path를 자동 설정하지 않아서 이 같은 작업 해 줘야 커맨드 창에서 편하게 작업합니다. 5.0은 Path마저 자기 맘대로 설정합니다 -_-;;

그럼 끝~ 그럼 이제 자바의 세계에 빠져 볼까요? ㅋㅋ
*다음번엔 윈도우용 GCC 설치에 대해 올릴께요~ ^^

고등학교시절 C++을 알게 되면서 객체지향 프로그래밍(Object Oriented Programming, 줄여서 OOP) 에 대해 궁금증을 가지게 되었습니다.

도대체 이런 게 왜 필요하지? -_-??

일의 순서에 따라 작업을 처리하는 절차 지향적 프로그래밍 언어를 공부했던 저는 그래도 C의 신 버전이라는 착각 속에 공부를 시작했지만, 이놈에 Class에서 막히는 것이었습니다.

막힌 이유는 바로

대체 이걸 왜 써?

머리에 완벽히 절차지향으로 고정이 되어 버려서 필요성을 못 느꼈고, 게다가 엄청나게 늘어나 버리는 코딩 량의 압박에 좌절했습니다. (얼마나 늘어나는지 앞으로 보게 될 것 입니다. ㅎㅎ)

어째튼 그 뒤로 Rukxer형과 함께 일했을 때, HTML의 폼의 구조와 이것을 접근하는 JavaScript의 방식을 보고 조금씩 객체지향의 구조와 필요성을 알게 모르게 느껴가고 있었고, 대학에 들어가 Java를 배우니 왜 이것이 필요한지를 느끼게 되었고, 이제 나름대로 사용할 수 있게 되었습니다. (물론 잘 하는 건 아니지만 ^^;)

뭐 객체지향에 대해 설명하라면 제가 직접 하는 것 보다 책에 써 있는 것이 더 잘 표현되어있기 때문에 생략하고~

그럼 구체적으로 어떤 식으로 작성해야 객체지향 프로그래밍이 될까요? 들어가기 전에 절차지향적으로 작성된 프로그램의 예제를 가지고 설명해 보겠습니다.

Triangle.c

제가 자주 써먹는 (아주 우려 먹어라 -_-;;) 삼각형 예제를 가장 널리 쓰이고 있는 절차지향 언어인 C로 작성했습니다. 정말 간단하죠? 그럼 이것을 객체 지향 언어로 구현하면 어떻게 될까요?

Triangle.cpp

이렇게 될까요? 아니죠~ 객체지향 언어 가지고 절차지향으로 작성한 것 밖에 안됩니다. -_-+
그래서~ 준비했습니다. 객체지향 언어인 자바로 작하였고, 객체지향적으로 설계한 삼각형입니다.

.java

… 쿨럭!! -_-;;

C로 작성한 삼각형이 24라인으로 콘솔 모드로도 한 화면에 다 표시할 수 있는 것에 비해 자바로 작성한 삼각형은 모두 다 합쳐 무려 192라인으로 무려 8배나 되는 라인 수를 자랑합니다 -_-;;

그럼 간단히 해설에 들어가면
삼각형의 정의는 [삼각형(三角形)은 세 점을 선분으로 이어 만든 도형이다. 삼각형의 세 점을 꼭지점이라 하고, 선분을 변이라고 한다.] 라고 되어있습니다. (출처 : 위키)
간단히 이야기해 3개의 점에 선이 달린 것이 삼각형이랍니다 -_-;;

그런데 중간에 도형이라는 단어가 눈에 뜨이죠? 그래서 찾아봤습니다.
도형의 정의는 [기하학에서 도형(圖形)은 점•선•면의 집합이다.] (출처 : 위키)
결국은 삼각형은 도형중 하나인 것입니다. ㅎㅎ

그런데 또다시 눈에 띄는 것 중에 하나가 선이라는 것이 있습니다. 그럼 선은 무엇일까요?
선의 정의는 [선은 줄을 말한다] 랍니다. 장난하냐? (출처 : 역시 위키 -_-;;)
음음, 그럼 다른 곳을 찾아보려다 그냥 기억 속에 있는 것을 꺼내겠습니다.
언제인지는 모르겠는데, 하여간 수학시간에 이런 말을 들은 것 같습니다. [수많은 점들이 일열로 빈틈없이 늘어서면 선이 된다.] 하여간 이거만 믿고 갑니다 ㅋㅋ

다음 점에 대한 정의로 [점(點)은 수학에서 크기를 갖지 않고 공간을 점유하지 않지만 위치 등을 지정할 수 있는 가상적인 개체이다.] (출처 : 위키)
결국 이게 마지막인 것 같네요. 개체까지 내려왔으니까요 ㅎㅎ (프로그래밍에서 개체는 곧 객체가 됩니다.)

결국 필요한 것은 점, 선, 도형, 삼각형 이렇게 4개가 되겠습니다. 그리고 그것을 구체화 시킨 것이 바로 제가 작성한 삼각형이 되겠습니다. (1개 더 추가한 것은 선과, 도형 둘 모두 점을 필요로 해서 점을 저장해 두는 개체를 만들어 둘에게 상속받게 만들었습니다. 코드 양을 줄이기 위해 -_-;;)

어째튼 객체지향을 이해하신 분들이라면 소스를 보면 대충 이해는 하실 겁니다. 납득은 못하실 것 같지만 -_-;;
그렇다고 결국 객체지향은 나쁘다! 라고 이야기 하는 것은 절대 아닙니다. 객체지향적으로 작성할 경우 처음에는 좀 길어질 수 있지만 잘 만든 객체 하나 덕에 나중에 더욱 편하게 프로그래밍 작업을 할 수 있는 것이 바로 이 객체지향 프로그래밍이거든요. 요즘 졸업작품을 만드는 중인데 객제지향 프로그래밍에 대해 새삼 놀라움을 느낍니다. 정말 잘 만들어둔 객체 덕에 편하게 작업하고 있거든요 ^^ (구체적으로 다향성 덕에) 어째튼 여러분들도 심심하면 한번 도전해 보세요. 절차지향적인 프로그램을 객체지향으로 바꾸는 것을요 ^^

참고]
테스트에 사용한 컴파일러 : gcc 3.4.2, g++ 3.4.2, javac 1.6.0_02

문제될만한 부분이나, 버그를 알려주시면 감사하겠습니다 ^^

덧]
웃자고 만들기 시작했는데 정신을 차려보니 경각심을 불러일으킬 소지를 지는 글로 변했다는... 쿨럭!

요즘 객체지향 프로그래밍을 공부를 하고 있는데 문득 “같은 목적의 프로그램이지만 라인과 코딩숫자가 다를 경우의 속도차이는 어떠할까?”라는 궁금 점이 들더군요.
그래서 최근 배우고 있는 Java를 이용해서 홀수 마방진 프로그램을 만들었습니다.

첫 번째 알고리즘은 보통 사람들이 많이 구현하고, 제가 고등학교 때 구현했던 알고리즘입니다.

소스

int x=size>>1, y=0, s=1, square=size*size;

while (s<=square)

{

	mat[y][x]=s++;

	if(--y<0)y=size-1;

	x=(x+1)%size;

	if(mat[y][x]!=0)

	{

		y=(y+2)%size;

		if(--x<0)x=size-1;

	}

}

두 번째 알고리즘은 첫 번째 알고리즘의 기초가 되는 알고리즘인데 제가 오늘 안 돌아가는 머리 굴려가며 구현한 알고리즘입니다.

소스

int i, j, s=0, center=size>>1;

for (i=0; i<size; i++)

	for (j=0; j<size; j++)

		mat[(size+i+j-center)%size][(size+j-i+center)%size]=++s;

두 알고리즘의 결과는 약간 다르지만 두 개 모두 같은 목적을 가진 알고리즘입니다.

각 알고리즘별 출력 결과

속도 측정은 999 * 999짜리 마방진을 100번 만들어내는 속도로 측정을 했습니다.

첫 번째 결과

두 번째 결과

그럼 컴파일 시 용량이 어떻게 되는지 알아보겠습니다.

알고리즘 선택에 따라 이렇게 미묘한 차이가 있을 수 있다는 것을 이번 실험에서 알아낼 수 있었습니다. 하지만 이 미묘한 차이가 쌓이고 쌓이면 엄청나한 차이가 있을 수 있다는 사실을 잊어서는 안될 것 같습니다.

여기서 보너스~

두 번째 알고리즘을 구현하기 위해 머리를 싸맸던 흔적을 공개하겠습니다 >.<

단 한줄 때문에 이런 삽질을...