RSS구독하기:SUBSCRIBE TO RSS FEED
즐겨찾기추가:ADD FAVORITE
글쓰기:POST
관리자:ADMINISTRATOR

Java 7 전망

Dolphin은 2007년에는 릴리스 되지 않을 것이다. 내년에 릴리스 될 가망성은 있다. 작업은 진행 중이고, 일부 기능들은 일찌감치 표준 확장으로서 데뷔를 마쳤고, 적어도 베타 버전으로 릴리스 되었다.

언어에 특성을 추가하는 것이 제거하는 것 보다 훨씬 더 쉽다는 것은 불행한 일이다. 시간이 흐를수록 언어가 점점 더 복잡해진다는 것은 피할 수 없는 일이다. 심지어 독립적인 상태로 좋은 기능들 조차도 서로서로 엮이면서 문제가 많은 기능이 되어버린다.

불행히도, 자바 커뮤니티는 아직 이러한 교훈을 터득하지 못한 것 같다. 이것은 매우 일반적인 사실인데도 말이다. 어떤 실질적 문제도 해결해주지 못하는데도 불구하고, 언어 디자이너들에겐 감당하기 힘들만큼 참신하고 흥분되는 신텍스들이 있을 수 있다. 따라서 클로저(closure), 다중 상속, 연산자 오버로딩(operator overloading)을 포함한 Java 7의 새로운 기능들에 대해 언급하고 있는 듯 하다.

실현 가능성이 반반 이겠지만, 올해 안에 Java 7 베타 버전에 클로저가 도입될 것이고, 연산자 오버로딩도 잘하면 볼 수 있을 것이다. 하지만 다중 상속은 불가능 할 것이다. 자바 대부분이 단일 상속 계층에 기반하고 있다. 다중 상속을 이 언어에 도입할 수 있는 그럴듯한 방법이 없다.

현재, 많은 신택스들이 있고, 이중 일부는 합당하지만, 어떤 것은 그렇지 못하다. 많은 제안들이 getFoo() 같은 메소드를 -> 연산자로 대체하는데 초점을 맞추고 있다.

List

집합체에 접근하는 첫 번째 가능한 방법은 배열관련 신텍스를 사용하는 것이다. 예를 들어, 다음과 같이 작성하는 대신,

List content = new LinkedList(10);
content.add(0, "Fred");
content.add(1, "Barney");
String name = content.get(0);

아래와 같이 작성한다:

List content = new LinkedList(10);
content[0] = "Fred";
content[1] = "Barney";
String name = content[0];

또 다른 방법으론 리스트에 대한 배열 초기화 문법을 사용할 수 있다:

LinkedList content = {"Fred", "Barney", "Wilma", "Betty"}

이 두 가지 제안 모두 가상 머신(VM)을 수정하지 않고 작은 컴파일러 조작으로도 구현될 수 있었다. 기존의 어떤 소스 코드도 무효로 하지 않았으며 재정의 하지 않았고, 심지어는 새로운 신택스에 보다 중요한 이슈가 되었다.

개발자의 생산성에서 차이를 만들어내는 한 가지 언어 특징은 XML과 SQL로 작업할 때 다루게 되는 테이블, 트리, 맵을 관리하는 내장된 원시타입이다. JavaScript의 E4X와 Microsoft의 Cω와 Linq 프로젝트는 내장된 원시타입을 이용한 개발 향상성에 기여하지만, 자바 플랫폼은 이러한 측면에 대구책이 아직은 없는 듯 하다.

프로퍼티

프로퍼티 액세스용 신택스를 보자. 한 가지 제안은 getFoo setFoo 를 호출할 때 간단히 ->를 사용하는 것이다. 따라서, 다음과 같이 쓰는 대신,

Point p = new Point();
p.setX(56);
p.setY(87);
int z = p.getX();

아래와 같이 작성한다.

Point p = new Point();
p->X = 56;
p->Y = 87;
int z = p->X;

.#을 포함한 기타 심볼 역시 ->의 대안으로 제시되었다.

앞으로는, Point 클래스의 프로퍼티로서 관련 필드를 구분하거나, 구분하지 않을 수도 있다.

public class Point {

  public int property x;
  public int property y;

}

개인적으로, 전혀 흥미롭지 않다. 나는 자바 플랫폼이 보다 퍼블릭 필드를 실제로 사용할 때 Eiffel 계열의 방식을 채택하기를 바란다. 하지만, getter와 setter는 필드와 같은 이름으로 정의되면, 필드의 읽기와 쓰기는 자동으로 이 메소드로 보내진다. 더 적은 신택스를 사용하고 더 유연하다.

임의 정밀도 연산(Arbitrary precision arithmetic)

연산자 오버로딩

표준 수학 기호를 사용하는 것은 연산자 오버로딩과 같은 것이 아니다. 적어도 C++에서 문제를 일으키는 그러한 종류는 아닌 것이다. '+' 부호와 기타 연산자는 여전히 어떤 프로그램에서든 뚜렷한 의미를 갖고 있다. 이들은 의미를 프로그램마다 수정하지 않는다. 비슷한 연산에 같은 신택스를 사용한다면 코드는 더욱 읽기 쉬워진다. 따라서, 신택스 재정의는 다른 프로그램에서는 다른 것을 의미할 수 있기 때문에 코드 읽기가 더 어려워 질 수 있다.

메소드를 연산자로 대체하는 또 다른 제안은 BigDecimalBigInteger에도 해당된다. 예를 들어, 현재 무한 정밀도 연산(unlimited precision arithmetic)을 코딩 해야 한다면,

BigInteger low  = BigInteger.ONE;
BigInteger high = BigInteger.ONE;
for (int i = 0; i < 500; i++) {
  System.out.print(low);
  BigInteger temp = high;
  high = high.add(low);
  low = temp;
};

이것은 다음과 같이 명확히 작성될 수 있다.

BigInteger low  = 1;
BigInteger high = 1;
for (int i = 0; i < 500; i++) {
  System.out.print(low);
  BigInteger temp = high;
  high = high + low;
  low = temp;
};

클래스들의 남용과 이에 따른 퍼포먼스 저하가 있을 수 있지만 이 제안은 그렇게 거슬리지 않는다.

JAR에서 JAM 취하기

Java 7은 오랫동안 자바 개발자들을 짜증나게 했던 다양한 클래스 로더들(class loader)과 클래스 패스와 관련된 문제를 해결했다. Sun은 Java Module System을 사용하여 이러한 문제를 해결하고 있다. .jar 파일 대신, 데이터는 .jam 파일로 저장된다. 이것은 모든 코드와 메타데이터를 포함하고 있는 일종의 "superjar"라고 할 수 있다. 가장 중요한 것은, Java Module System은 처음으로 버전 관리를 지원하기 때문에, 해당 프로그램은 Xerces 2.6이 아니라 2.7.1버전을 필요로 한다고 지정할 수 있게 된다. 또한 종속 관계를 지정할 수 있다. 예를 들어, JAM의 프로그램은 JDOM을 필요로 한다고 지정할 수 있다. 모듈 전체를 로딩하지 않고 하나의 모듈을 로딩할 수도 있다. 마지막으로, 다수의 서로 다른 JAM들에 대한 다양한 버전들을 제공하는 중앙 집중화된 레파지토리로의 역할을 제공해 줄 것이고, 애플리케이션은 여기에서 제공하는 것들 중 필요한 것들을 선별할 수 있다. JMS가 작동하면 jre/lib/ext로의 지정 해야할 일련의 과정은 과거로 사라질 것이다.

패키지 액세스

Java 7은 아마도 액세스 제한을 조금 완화할 것이다. 이는 하위 패키지가 상위패키지에 있는 클래스들의 패키지상 보호되어있던 필드들과 메소드들에 접근할 수 있게 해줄 것이다. 또한, 하위 패키지가 상위 패키지의 페키지상 보호되었던 멤버들 중 명시적으로 접근 가능하도록 정의된 멤버들을 접근 할 수 있도록 해줄 것이다. 두 방법 모두, 애플리케이션을 여러 패키지들로 나누어서 보다 단순하고 테스트 성능도 향상시킨다. 단위 테스트가 하위 패키지에 있다면, 이들을 테스트 할 수 있도록 메소드를 공개할 필요도 없다.

파일시스템 액세스

파일시스템 액세스는 1995년부터 자바 플랫폼의 주요한 문제였다. 10년이 넘었지만, 파일을 복사하거나 이동하는 것 같은 기본적인 작동을 수행하는 신뢰성 있는 크로스 플랫폼 방식이 없다. 이러한 문제를 해결하는 것이 지난 세 개의 JDK 버전들(1.4, 5, 6)의 공공연한 이슈였다. 슬프게도 파일을 옮기거나 복사하는 지루하지만 필요한 API들이 메모리 매핑 I/O 같은 덜 일반적이지만 매력적인 연산에 밀려났다. 아마도 JSR 203은 이 문제를 해결할 것이고 우리에게 실현 가능한 크로스 플랫폼 파일 시스템 API를 제공할 것이다. 작업 그룹은 진정한 비동기식 I/O 문제에 대해 많은 관심을 쏟을 것이다. 내년 이맘때쯤 결과가 나올 것이다.

실험

어떤 변화가 일어나든 오픈 소스 세계에서 가장 먼저 구현된다면 더욱 좋을 것이다. 그래야지만 우리가 얼마나 많은 또는 얼마나 적은 차이를 만들어 냈는지를 볼 수 있기 때문이다. Sun의 Peter Ahe는 java.net에서 Kitchen Sink Project를 시작했다. 목표는 javac 컴파일러를 반복적으로 분기하여 다른 많은 아이디어를 테스트 하는 것이다.




위로


클라이언트 GUI

비록 많은 사람들이 알아채지는 못했지만, 자바 플랫폼은 4~5년 동안 데스크탑에 실제로 존재했다. RSSOwl, Limewire, Azureus, Eclipse, NetBeans, CyberDuck 등을 포함한 일부 양질의 데스크탑 애플리케이션들은 자바 코드로 작성되었다. 이러한 애플리케이션은 Swing, AWT, SWT 같은 거의 모든 GUI 툴킷과 심지어 Mac OS X의 Cocoa 같은 플랫폼 툴킷에 의해 작성된다. 이러한 툴킷 중에서 어떤 것이 더 낫다고 단정지을 수는 없지만, Swing은 원래의 느낌을 갖고 있는 애플리케이션을 생성하는데 다른 것 보다 더 나은 기능을 갖출 것이다.

Swing은 여전히 개발하기에는 도전이 되지만, Swing Application Framework의 출현으로 내년에는 상황이 더 나아질 것으로 보인다. 이 프레임웍은 현재 Java Community Process에서 JSR 296으로 개발 중이다. 다음은 JSR에 대한 설명이다.

잘 작성된 Swing 애플리케이션들은 시작시키고 종료시키는 작업과 리소스, 동작, 세션의 상태들을 관리하는데 있어 동일한 핵심요소들을 가지는 경향이 있다. 새로운 애플리케이션들은 이 모든 핵심 엘리먼트들을 처음부터 만들어낸다. Java SE는 어플리케이션들을 구성하는데 어떠한 지원도 제공해 주지 않고 있고, 바로 이것 때문에 개발자들은 SE 문서에서 설명하는 예제 그 이상으로 확장된 애플리케이션을 구현할 때 당황하게 된다.

Swing 애플리케이션의 기본 구조를 정의함으로써 그러한 허점을 채우기 위하여 정의된 사양서를 제공할 것이다. 이는 대부분의 데스크탑 애플리케이션의 일반적인 인프라스트럭처를 정의하는 확장성 있는 클래스 세트나 "프레임웍"을 정의할 것이다.

Swing Application Framework은 대부분의 전형적인 애플리케이션을 지원하면서, 개발자들로 하여금 시작과 종료와 같은 몇몇 커스터마이징 부분을 추가해 넣을 수 있도록 해줄 것이다. 이는 어플리케이션 시작과 종료 와중에 윈도우나 다른 부분들에 대한 저장과 복구를 다룰 수 있게 해줄 것이다. 마지막으로, 개발자들은 Swing 이벤트 디스패치 쓰레드 외부에서 실행되는 비동기식 액션을 작성할 수 있게 된다.

JavaBeans와 Swing을 향상시키고자 하는 노력이 진행 중이다. JSR 295는 빈들을 바인딩 하는 표준 방식을 정의하여, 하나의 빈이 업데이트 되면 이것이 자동으로 다른 빈에 반영될 수 있도록 한다. 예를 들어, GUI 그리드 빈은 연관된 데이터베이스 빈이 변경되면 자동으로 업데이트 된다.

마지막으로 JSR 303은 XML 기반 밸리데이션(validation) 언어 관련 작업을 진행하여 주어진 빈이 취할 값을 지정한다. int 프로퍼티는 1과 10 사이에 있어야 한다거나, String 프로퍼티에는 합법적인 이메일 주소가 포함되어야 한다는 등을 지정할 수 있다. 올해 말에는 베타 버전으로 이러한 기능을 사용할 수 있을 것이고 내년 이맘때쯤 Java 7에 대한 작업이 끝날 것이다.




위로


데스크탑 언어로서 자바 플랫폼

일부 프로그래머들은 자신들이 선호하는 언어이기 때문에 자바 코드로 데스크탑 애플리케이션을 작성하지만, 대부분은 멀티 플랫폼을 수용하기 위해서이다. 데스크탑 언어로서 자바 플랫폼에 대한 관심은 비 Microsoft 계열 데스크탑의 수와 연관되어있다. 세 가지 주요 데스크탑에서의 자바 프로그래밍에 대해 알아보자.

Windows

Swing은 특히 오픈 소스 개발로의 전향과 아울러 여전히 내년까지도 Windows 룩앤필을 향상시킬 것이다. 결국, LimeWire 같은 순수 자바 프로그램들은 Windows 보다 자연스러운 모습을 보이게 될 것이다. 하지만, 원래의 Windows 애플리케이션 개발 언어는 C#(일부 C 와 C++ 포함)이다. 그리고 프레임웍은 .NET이 될 것이다. 자바 코드는 Windows 생태계에 깊이 관여하지는 않을 것이다.

Macintosh

Microsoft와 마찬가지로 Apple Inc.도 자바 코드를 거의 포기했다. Apple은 Objective C 와Cocoa를 선호하지만 그의 결과 또한 같다. Mac 전용 개발자들은 Apple의 주력 언어와 환경에서 자바 코드를 제거하려는 시도를 계속해서 하고 있다.

긍정적인 측면은, Apple은 QuickTime과 Cocoa 같은 상용 API에 대해 자바 코드를 더 이상 지원하지 않지만 Apple VM은 그 어느 때보다도 훨씬 더 나아졌다. Apple의 Java 6 포트가 곧 릴리스 될 것이다. (Sun의 JDK와는 달리) 오픈 소스는 아니지만, 오픈 소스 프로그래머들이 버그를 픽스할 것이다.

Linux

GPL 라이센스로 자바 코드를 가장 순수한 오픈 소스 리눅스로 함께 묶을 수 있는데, 이로써 자바 플랫폼은 매력적인 리눅스 개발용 언어로서 한층 더 다가갈 수 있다. 이러한 상황이 5전 전에만 일어났다면, 리눅스 커뮤니티는 C 때문에 고생을 하지 않아도 되었을 것이고, Mono도 불필요했을 것이다.

Gnome과 KDE용 자바 바인딩은 내년에는 더욱 많은 관심을 끌 것이다. C, C++, 또는 C#이 아닌 자바 코드를 사용하여 리눅스 GUI 프로그램을 개발하는 적어도 한 개 이상의 주요 프로젝트가 시작될 것으로 보인다.




위로


Ruby가 경쟁에서 이기다!

Bloatware

JavaScript는 이미 JDK 6에 번들되었다. 추가 언어는 JDK 7에 추가될 것이다. 너무 부풀려지는 느낌이다. Sun이를 멈출 수 있는 방법이 없다. BeanShell을 선택하면 Groovy쪽 사람들도 개입하고 싶어할 것이다. Groovy가 들어오면, Ruby 사용자들도 들어오려고 할 것이다. Ruby가 개입되면 Python은 가만히 있을까? 표준 JDK는 이미 너무 방대해졌다. 여러 스크립팅 언어를 지원하는 것도 큰 일인데, 번들링까지는 무리이다. 해결책으로 이들 모두를 지원은 하겠지만, 어떤 것도 번들하지는 않을 것이다.

긍정적인 측면은, Sun은 초기의 다운로드 사이즈와 애플리케이션 시작 시간을 줄이는 방안을 모색하고 있다. 특히 애플릿과 Java Web Start 애플리케이션에 대해 그렇게 하고 있다. 거대한 클래스 라이브러리가 서버에 남겨지고, 필요한 부분만 다운로드 될 것이다.

우리가 단 하나의 언어로만 대화한다면 이 세상은 매우 지루할 것이다. 자바 플랫폼은 애플리케이션 개발에 있어서 최상의 선택이지만, 작은 프로그램이나 매크로에는 절대로 맞지 않는다. Java 6은 이를 인식하고 BeanShell, Python, Perl, Ruby, ECMAScript, Groovy 같은 스크립팅 언어와 통합하기 위해 javax.script 패키지를 추가하고, invokedynamic 가상 머신 명령을 Java VM에 추가하여 Java VM이 직접 동적으로 기술된 언어들을 컴파일 할 수 있도록 했다.

비록 내가 개인적으로 선호하는 것이 아니지만, 2007년에 나는 Ruby에 돈을 투자할 것이다. Python 코드는 훨씬 더 깨끗해진 것 같고, Ruby 코드보다 이해하기가 더 쉽다. 아마도 이 부분에 대해서는 대부분의 자바 프로그래머들도 동의할 것이다. Python은 시기를 잘못 타고 태어났다. 많은 개발자들은 Python을 배우는 것과 자바 코드를 배우는 것 중 선택해야 했고, 대부분이 자바 코드를 선택했다. 그들이 자바 신택스를 다 이해하고 다른 언어를 받아들일 준비가 되었을 때는 과거의 언어가 아닌 미래의 언어를 택하기 마련이고, 그것이 Ruby일 듯 하다. 가장 중요한 것은 Ruby는 Ruby on Rails의 절대적인 킬러 애플리케이션을 갖고 있다. 이것의 단순함은 현실적인 Java Enterprise Edition (JEE) 개발자들에게는 매우 매력적으로 비춰진다.

Rails 이상으로, JRuby 프로젝트는 다른 스크립팅 언어들 보다 기존 자바 코드와 라이브러리와 더 나은 통합을 시도한다. 사실, JRuby는 표준 Ruby를 누르고 Ruby를 사용하는 자바 프로그래머들뿐만 아니라 Ruby 프로그래머들도 선호하는 플랫폼이 되었다. 좋은 일이다. Ruby는 막강하나 Python은 그렇지 못하다는 것은, 슬프지만 진실이다.

다른 스크립팅 언어들은 점점 더 쇠락해 갈 것이다. Perl은 너무 구식이고 현대적인 애플리케이션과 잘 맞지 않는다. Groovy는 뚜렷한 비전이 없이 유용성이나 친숙성을 떠나 컴퓨터-과학 분야의 전문언어로 채택되는 경향이 있다. BeanShell, Jelly, 그리고 일부 언어들도 관리가 되고 있지 않다. Ruby가 자바 프로그래머의 스크립팅 언어가 될 것인지는 내년까지 승부가 갈릴 것이다.




위로


IDE가 점점 나아지고 있다.

2006년은 IDE에게 있어서 최악이었다. 이클립스에 당황한 Sun은 그들의 에너지와 리소스를 NetBeans에 쏟아 부었고, 결국엔 막강한 경쟁자가 되었다. 어떤 면에서, NetBeans는 2006년 말에는 이클립스를 능가하는 것처럼 보였다. 훨씬 더 나은 룩앤필과 GUI를 디자인 하는 훨씬 더 나은 툴을 갖고 있었다. 반면, NetBeans가 갖지 못한 것은 이클립스와 같이 커뮤니티가 활성화 되지 못했다는 것이다. 훨씬 더 많은 플러그인과 서드 파티 제품들이 NetBeans 보다는 이클립스에 기반하고 있다. 이러한 추세는 점점 더 가속화 될 전망이다.

이클립스는 3.3 버전을 위해 힘들게 작업 중이고, 2007년에는 릴리스 될 것이다. Sun은 올해 NetBeans 6를 출시할 것이다. 두 개 모두 메이저 릴리스가 될 것 같지는 않다. 단순히 여기 저기에 작은 기능들을 추가하고, 버그를 픽스하고, 사용자 인터페이스를 정리한 정도이다.

NetBeans는 계속해서 Eclipse의 영역에서 시장 점유율을 높여갈 것이며, 그의 성장 가능성또한 아주 많다. Sun의 집요한 JDK 다운로드에 NetBeans 끼워 넣기는 무리 없어 보인다. 올해 말까지 두 개의 IDE는 시장을 양분할 것이다.

한편, IntelliJ IDEA 사용자들은 이러한 모든 상황에 개의치 않고 자신들이 최상의 Java IDE를 사용하고 있다고 자부하고 있다. 하지만, 대부분의 사용자들은 $500이 넘는 가격을 부담스러워 할 것이고 시장 점유율은 5%에 그칠 것이다.




위로


Java Enterprise Edition

자바 프로그래밍의 어떤 부분도 JEE 만큼 성공적이면서도 욕을 먹은 부분은 없다. 이것은 모든 사람들이 애증을 갖고 있는 기술이다. 복잡하고, 혼란스럽고, 무겁다. 자바 프로그래밍의 어떤 부분도 이를 대체하기 위해 그렇게 많은 노력을 들인 적이 없다. Spring, Hibernate, Restlet, aspects, Struts ...등 끝이 없다. 그럼에도 불구하고, 거의 모든 자바 프로그래머들은 JEE를 찾고 있기 때문에 Sun은 이 부분을 신경을 써야 할 것이다.

엔터프라이즈 세계에서 내가 목격한 경향 중 하나는 단순함에 대한 열망이다. 많은 프레임웍들이 나와 있으며, 그 안에서 작고 단순함을 선호하는 추세다. 점점 더 많은 고객들은 JEE 스택의 큰 부분을 거부하고 있고 이러한 추세는 지속될 전망이다. 대신 고객들은 Spring 같은 단순한 프레임웍으로 전향하거나 Ruby on Rails를 사용하는 추세이다. 더 단순하고, 보다 이해하기 쉬운 시스템에 대한 열망은 서비스 지향 아키텍처(SOA)와 Representational State Transfer (REST)에 대한 관심을 증폭시키고 있다.

2007년에도 단순함에 대한 추세는 지속될 것이다. Rails에 탄력을 받은 많은 사람들은 Python (Turbo Gears), Groovy (Grails), Java (Sails) 같은 다른 언어에서도 성공하기 바란다. 이들 중 하나는 성공하겠지만, 그렇지 않을 경우 더 이상의 새로운 것은 없다. 결국, 비즈니스는 그들이 이미 갖고 있는 SOA, REST, Rails를 계속 사용할 것이다.




위로


Java Micro Edition

단순하고 작은 것에 대한 열망이 임베디드 분야에도 적용될 수 있을까? 지난해 동안 자바 플랫폼은 작은 장치에 있어서 큰 성공을 거두었고 2007년에도 그러한 동력을 계속 이어갈 전망이다. 우선, Mobile Information Device Profile (MIDP)의 버전 3이 기대된다. 특히, 여러 MIDlet을 하나의 VM에서 실행할 수 있게 될 것이고, 백그라운드 에서는 한 개 이상을 실행할 수 있다. 또한 암호화된 레코드 관리 시스템(RMS) 스토어와 IPv6 지원도 기대된다.

현재 개발 중인 Java ME용 Scalable 2D Vector Graphics API 2.0은 많은 장치에서 사용할 수 있는 애니메이션 기능을 확대하고 있다. SVG 애니메이션 외에도 오디오 및 비디오 스트리밍도 실행한다. 모바일 네트워크가 열리면, 정말로 중요해진다. 셀폰의 YouTube를 생각해 보라. (물론, 네트워크가 연결되지 않으면, 이것은 어떤 누구도 보고 싶지 않은 2인치 짜리 기업 광고일 뿐이다. 미국에서 이것이 실현될지 의문이지만, 유럽에서는 가능하리라고 본다.)

모바일 개발자들은 Java ME용 XML API를 지원하는 원년이 될 것이다. 이 API는 전화기의 제한된 메모리 환경에 맞도록 설계된 SAX, DOM, StAX, JAXP의 하위 세트이다. 많은 사람들은 순수한 XML은 전화기에는 맞지 않는다고 생각한다. 올해에는 이것이 옳은지, 그른지 판가름 날 것이다.

모든 좋은 소식에도 불구하고 Apple의 iPhone은 여전히 모바일 폰 개발 플랫폼으로서 자바 플랫폼에 위협적인 존재가 될 것이다. iPhone은 출시된 지 여섯 달 만에 최고의 주목을 받고 있다. 문제는 폐쇄 플랫폼이라는 것이고, 셀폰 네트워크 표준에 의해서도 자바 코드를 실행할 것 같지 않다. 이는 모바일 폰, PDA, 개인용 커뮤니케이터용 서드 파티 애플리케이션을 판매하려는 사람들에게 끔찍한 소식이 아닐 수 없다.




위로


요약

JDK의 오픈 소스 전향 덕택에, 2007년은 자바 프로그래밍 역사 이래 최고로 흥미로운 한 해가 될 것이다. 지금까지, 자바 플랫폼은 Sun의 목표나 투자로만 제한되었지만, 이러한 현상도 곧 바뀔 전망이다. 개발자 커뮤니티의 막강한 힘으로 자바 프로그래밍은 어디든 항해할 수 있다. 개발자들은 전보다 더 자바 코드로 더 많은 일들을 할 수 있다. 데스크탑, 서버, 임베디드 이 모든 것들이 가속화 될 것이다. 하지만 이러한 엔진들도 일시적으로 멈출 때가 있을 것이다. 좋은 것은 살아남고, 그렇지 않은 것은 사장될 것이다. 자바 플랫폼에서 좋아하지 않는 부분이나 여러분을 괴롭혔던 것이 있다면 여러분의 IDE를 띄워 해킹을 시작해 보는 것도 좋다.

여러분이 갖고 있는 컴파일러를 지금 시작해 보기 바란다.

소셜 북마크

mar.gar.in mar.gar.in
digg Digg
del.icio.us del.icio.us
Slashdot Slashdot

기사의 원문보기

2007/11/29 11:43 2007/11/29 11:43
이 글에는 트랙백을 보낼 수 없습니다
기타  2007/11/25 21:50

http://crack.ms/  -  가장 대표적인 crack 사이트

http://astalavista.box.sk - 대표 크랙 사이트

http://www.cerials.net
http://www.gamecopyworld.com - 각종 crack 및 정보사이트
http://www.astalavista.com
http://lockinfo.ivyro.net/ =>히포님 홈페이지죠..게임락정보
http://bestanime.co.kr/newAniData/list.php?viewType=title =>애니메이션 검색
http://www.cracks.am/main.html =>크랙 사이트(접속시 야릇한 홈페이지가 뜨네요..)
http://www.deluxserials.com/ =>시리얼 검색사이트(업데이트가 좀 늦은편..)
http://gameguru.box.sk/ =>게임 트레이너 치트 검색사이트
http://megagames.com/ =>게임 크랙.트레이너.치트 검색사이트
http://www.serials.ws/ =>시리얼 검색사이트
http://www.dll-files.com/ =>OS 에 필요한 DLL 파일 검색사이트
http://gamefix.free.fr/ =>노시디 크랙,키젠,트레이너 같은 DOX전문
http://www.gameburnworld.com/ =>마찬가지
http://www.makeabackup.com/ =>크랙,락정보,레코딩플그램,BWA파일들
http://www.keygen.us/ =>키젠전문(업뎃 구림)
http://lockinfo.ivyro.net/ =>히포님 홈페이지죠..게임락정보
http://bestanime.co.kr/newAniData/list.php?viewType=title =>애니메이션 검색
http://www.cracks.am/main.html =>크랙 사이트
http://www.deluxserials.com/ =>시리얼 검색사이트(업데이트가 좀 늦은편..)
http://gameguru.box.sk/ =>게임 트레이너 치트 검색사이트
http://megagames.com/ =>게임 크랙.트레이너.치트 검색사이트
http://www.serials.ws/ =>시리얼 검색사이트
http://www.dll-files.com/ =>OS 에 필요한 DLL 파일 검색사이트
http://gamefix.free.fr/ =>크랙,키젠,트레이너 같은 DOX전문http://www.gameburnworld.co
m/ =>마찬가지
http://www.makeabackup.com/ =>크랙,락정보,레코딩플그램,BWA파일들
http://www.keygen.us/ =>키젠전문(업뎃느림)
http://www.gamezone.com/hints/hin1000.htm
http://www.gamewinners.com/

http://toptools.serwis.pl/

http://www.bestcracks.com

http://www.wtcracks.com/

http://cracks.am

http://www.thecrack.net:8080/


이외에도 난 최고의 크랙사이트를 보유하고있지 !!!
켜켜켜 최고의 해커 sim 및 그외 찌그러기들 ㅋㅋㅋㅋㅋ

2007/11/25 21:50 2007/11/25 21:50
이 글에는 트랙백을 보낼 수 없습니다

환경설정파일받기, ImTOO MP4 Video Converter V 3.1.29.0419b받기, 바닥인코딩설정 파일받기

3.1.10 키젠/ImTOO all keygen

사용자 삽입 이미지

등록번호


K3G(W100)V3 - MPEG-4 Video.pf : 인코딩 환경설정 파일
Korean.lang : 한글 언어 파일

한글언어파일은 기본 경로를 기준으로 C:\Program Files\ImTOO\MP4 Video Converter\lang 에 넣으시면 됩니다.
인코딩 환경설정 파일은 기본 경로를 기준으로 C:\Program Files\ImTOO\MP4 Video Converter\profile 에 넣으시면 됩니다.
 
인코딩 설정 파일은 위 그림 오른쪽에 나온 값이 디폴트 값 입니다. 디폴트 값을 변경하고자 하시면 K3G(W100) - MPEG-4 Video.pf 을 텍스트 에디터로 여신후 아래 내용의 파란색으로 된 부분을 변경하고 저장하시면 됩니다.
 
[Main]
Name= 바닥(.avi) to EV-W100(k3g)
SName=EV-W100
Format=mp4
ExtName=k3g
IsSysProfile = yes
[Parameter]
t=0, "", ""
ss=0, "", ""
vcodec=READONLY, "", "mpeg4", {"mpeg4"}
s = 0, 0, 320x240, { "320x240 (Qvga)", "176x144 (Qcif)", "128x96 (sqcif)"}
b = 0, "", 300, { 40, 60, 80, 120, 192, 216, 250, 256, 300, 512, 768, 1000, 1200, 1500 }
r=0, "", "15", {10, 15, 24, 30}
acodec=READONLY, "", "mpeg4aac", {"mpeg4aac", "aac"}
ab=0, "", "128", {"32", "48", "64", "96", "128", "160"}
ar=0, "", "24000", {"8000", "9600", "11025", "16000", "22050", "24000", "32000", "38400", "44100", "48000"}
ac=0, "", "2", {"1 (Mono)", "2 (Stereo)"}
an=0, "", ""

K3G 인코딩 설정은 EV-W100을 기준으로 설정되어 있습니다.

인코딩 샘플 화면



원본 화면 720 x 304 700MB


바닥 인코딩 화면 (PDA용)

바닥 인코딩 화면 320 x 240 328MB

ImTOO 인코딩 화면 (K3G)

ImTOO 인코딩 화면 320 x 240 176MB




곰은 상단에 잠깐 나오는 광고가 싫고, 3GP는 퀵타임을 깔아야 되서 귀찮고 해서
바닥은 자막을 입히기 위해 사용하고, 핵심작업은 ImTOO가 되겠습니다.
EV-W100은 자체 .smi 자막을 지원합니다.

2007/11/25 13:20 2007/11/25 13:20
이 글에는 트랙백을 보낼 수 없습니다
앞절에서 이미 언급한 부분입니다. Scope에 관한거죠. 못읽어 보신분이라면 언능가서 먼저 읽으시길 바랍니다. 이 강좌를 하면서 Scope의 개념이 없이는 절대 안되는 부분이거든요. 물론 깊게 설명하지는 않았습니다만,
이번 강좌를 이해하는데 많은 도움이 되리라 생각합니다.

//중첩함수
function A(){
var a = "1";
  function B(){
    var b = "2";
  }
}


이러한 함수가 정의되어 있다고 가정합시다. 함수 A는 a라는 지역변수를 가지고 있고 함수 B는 함수 A안에서
존재하고 b라는 지역변수도 가지고 있습니다.
깜짝 질문, 함수 B에서 a라는 변수를 참조할 수 있을까요? 없을까요? 앞장에서 했던 강좌를 유심히 보신분
이라면 쉽게 알 수 있을 겁니다. 답은 "참조할 수 있다" 입니다. 답은 앞장의 강좌를 다시 읽어서 확인하시기 바랍니다.

참고로 위의 구문은 "중첩함수"라고 부르며 Javascript에서의 private을 만들때 사용하는 방법중에 하나입니다. 실제로 해보시면 아시겠지만, 함수 B는 함수 A안에서밖에 호출할 수 없으며 밖에서 함수 A를 가지고 함수 B를 참조하려 해도 안되는걸 아실 수 있습니다. A.B() <- 이런식으로 절대 호출 할 수 없습니다.

그럼 다음 함수를 보시죠.

<html>
<script>
 function OutFunc(){
   var out = "i'm a out"
   function InFunc(){
     var inner = "i'm a in "+"-----"+ out;
     return inner;
   }
   return InFunc;
 }

 var test_1 = OutFunc();
 var test_2 = test_1();
 alert(test_2);
</script>
<body></body>
</html>

이 스크립트의 결과가 어찌 될거라고 예상이 됩니까? 사실 이 함수 자체를 이해 못하시는 분도 있으리라
생각합니다. 절대 무시하는게 아닙니다. 다만 우리는 알게모르게 쉬운 스크립트만을 접하고 이렇게 구조적으로 파헤친적이 없기때문에 어려울 수 밖에 없었던겁니다. 처음부터 Java 나 C#처럼 배웠다면 이렇게 Javascript가 우리를 힘들게 하지 않았을거라고 전 생각합니다. 일단 실행부터 시켜보세요. 어떻습니까? 여러분이 예상했던 답하고 일치합니까? 일치하다면 자신있게 설명을 하실 수 있습니까? 없다면 아래를 봐주세요 ^^ㅋ

먼저 정리부터 해보죠.
1. Javascript에서의 단위는 함수이다.
2. 함수의 지역변수는 함수밖에서는 절대 호출 할 수 없고, 함수내부에서는 전역변수보다 지역변수가 우선한다.
3. 변수는 각각의 Scope를 가지며 자신의 Scope를 벗어날 수 없다.


이제 소스를 해석해보겠습니다. 다들 청심환 하나씩 드세요. ^^
OutFunc는 자신의 지역변수 out을 가지고 있고 중첩함수인 InFunc를 가지고 있습니다. InFunc는 자신의
지역변수인 inner를 가지고 있고 중첩된 함수(nested function이라고 표현합니다) InFunc는 지역변수 inner를 리턴하는군요. OutFunc는 중첩함수인 InFunc를 리턴하구요. 여기까지 이해하셨죠?

그리고 OutFunc를 실행하고 test_1에 담습니다..여기엔 뭐가 담길까요? 그렇습니다. 함수 InFunc가 담깁니다. 그리고 test_2에는 test_1에 담긴 함수를 실행하고 그결과를 담습니다.

그럼 답을 발표하겠습니다. 답은 "i'm a in -------- i'm a out" 입니다.

제가 묻겠습니다. 변수 inner는 어디에 속해이어야 하는 거죠? 네. 함수 InFunc에 속해서 그 Scope안에서만
존재 해야하며 그함수가 종료되었을때, 같이 사라져야할 변수입니다. 그런데 지금의 모습은 어떻습니까?
alert()을 통해서 inner의 값을 찍고 있습니다. 도대체 어떻게 된 것일까요? 위에 정리한 1,2,3은 도대체
어쩌라고 이렇게 결과가 나오는 겁니까?

눈치가 빠르신분은 이미 알고 계셨을 겁니다. 그렇습니다. 이것이 바로 "클로져(Closure)" 입니다.
클로져의 정의는 "다른 함수내에서 내부객체로 생성된 함수 리터럴을 반환하여 호출 프로그램에서 이를 변수로 배정한 것" 이라고 정의하고 있으며 부연설명으로는 "함수가 동작하는데 필요한 데이터 영역 확장"이라고 하고 있습니다.[o'relly - Javascript for web 2.0 5장]

제가 더 덧붙여 설명하면 첫번째  OutFunc()를 실행함으로써 InFunc()함수를 OutFunc()의 안에서 바깥쪽으로
끄집어내어 영역을 변경(확장)하고 두번째 test_1()을 다시 한번 실행함으로써 inner의 값을 직접 호출 할 수 있도록 호출 프로그램으로 영역을 변경(확장)한 것입니다. 이로써 inner라는 변수는 더이상 OutFunc의
InFunc안에 갇혀있지 않고 어디서든지 호출 될 수 있는 전역변수화가 되어버린 것이죠.
여기까지 이해하셨다면 당신은 이미 중급의 문턱까지 온것입니다.
사실 클로져란것을 정확하게 알고 있는 사람은 드물뿐 아니라 "의도하지 않은 클로져의 생성"으로 고통받고
있는 개발자들도 많습니다. 그만큼 어렵고 이해하기 힘든 개념인 것입니다.

결과적으로만 보면 상당히 훌륭해보이고 멋져 보이지만, 사실 내면엔 "메모리 누수"라는 문제점을 안고
있습니다. 메모리 누수에 대해서는 다음 강좌인 "함수-3"에서 자세히 다뤄보도록 합시다.
오늘은 이만 접어야 겠네요..ㅋ 퇴근시간이 가까워 져서리..ㅋㅋ
그럼 다음 강좌까지 다들 건강조심세요.. 더위가 심하네요..


오늘은 저번 강좌에 이어 클로져에 대해서 이어가겠습니다. 클로져에 대해서 개념이 안잡히신 분들을 위해
간략하게 정리하겠습니다.

함수안에 존재하는 지역변수는 지역변수로써 살아야하며, 함수가 죽으면 따라죽을 운명인데, 클로져는 죽어
마땅한 함수의 지역변수를 밖으로 끄집어내어 영역을 변경(확장)하는 것
을 의미합니다. 물론 이한줄이 클로져를 전부 나타낼 수는 없습니다. 하지만 전 이렇게 설명하려 합니다. 다르게 설명해봤자 서로 헛깔릴게 분명
하거든요 ^^ 사람이든 변수이든 자기의 영역에서 벗어나면 안되나 봅니다..ㅎㅎ 왜냐구요? 클로져도 문제가
좀 심각하거든요... 이름하여 "Memory leak(메모리 누수)" 현상 때문입니다.

메모리 누수의 전체적 그림은 중급강좌정도에 보실 수 있겠네요. 여기서는 클로져에 의한 메모리 누수에
대해서만 다루겠습니다. 메모리 누수 모델이 몇가지 있는데 그걸 다 다루자면 제목에서 보듯이 [기초강좌]에서 범위가 벗어납니다. 우리가 좀전에 뭘 배웠습니까? 영역을 벗어나면 문제가 된다고 했지요 ㅎㅎㅎㅎ

자 다시 본론으로 가서, 클로져는 한 내부함수의 지역변수를 함수 리터럴을 통하여 밖으로 꺼내오는 것을
의미한다 했습니다. 그럼 제가 질문을 해보겠습니다. 그 한 내부함수가 종료되면 클로져에 의해 밖으로
튀어나온 변수는 어떻게 될까요? 그렇습니다... 계속 살아 있습니다. 계속 살아있으므로 부모함수가 죽었는데도 불구하고 계속 호출되어 사용됩니다. 나중에 다시 이야기 되겠지만 이것이 "IE에서의 메모리 누수 모델 1"
입니다. 보통 FireFox나 오페라 같은 브라우저는 클로져가 생성되어도 참조값이 0이면 브라우저메모리에서
GC에의해 소멸되게 됩니다. 허나, IE는 그렇지 못하여 문제가 되는거죠. 전 강좌를 열심히 보신분이라면 쉽게 이해하시리라 봅니다. 클로저의 메모리 누수는 이쯤으로 마치겠습니다. 사실 메모리 누수에 대해서는 할말이
무지 많습니다. 허나, 역시 범위를 넘기면 문제가 ㅎㅎㅎㅎ



posted by blankus

--------------------- 펌글 ---------------------


음냥 초보자들이 알기 딱좋네 !!

나두 넘 좋아 나도 초보거등 ~~~ ㅋㅋㅋ
2007/11/21 12:54 2007/11/21 12:54
이 글에는 트랙백을 보낼 수 없습니다
오늘도 무쟈게 덥군요 ^^; 좀전에 회사 사람들하고 잠시 밖에나가 잡담을 하며 바람좀 쐬고왔습니다.
역시 사무실에 일할때보단 밖에서 놀때가 더 좋군여..ㅎ

오늘은 By value와 By reference에 대해서 알아보겠습니다. 날도 덥고하니 조금은 짧게 이야기해봅시다.
사실 이부분은 제가 C를 공부할때 알게되었습니다만, Javascript에서는 크게 신경안쓰고 작업했던 부분입니다. C를 공부하신 분은 아시겠지만, C에는 포인터란 개념이 있습니다. 물론 Javascript에서는 없습니다.
하지만 표면적으로 C처럼 포인터를 핸들링 하지 않는것 뿐이지, 개념은 필요한 부분입니다.

포인터.. 그놈은 이런놈입니다. 보통 우리가 변수를 선언하고 무언가를 그 변수에 담을때, 그때 그 무언가는
메모리에 저장되게 됩니다. 메모리에 저장될때, "나는 메모리의 어디에 위치해있다."라고 알려주는데 그게 바로 "포인터" 입니다. 말그대로 무언가를 가리키는거죠. 그래서 C에선 일반변수와 포인터 변수를 구분해서
사용하는데, Javascript에서 사용하는 변수는 C에서의 일반 변수가 되겠습니다. 포인터 변수는 뭔가 저장된놈의
메모리 주소를 가지고 있는거구요. 일반 변수는 by value가 되고, 포인터 변수는 넓은 의미에서 by reference가 됩니다. 물론 Javascript에 100% 적용되는 설명은 아닙니다.
여기까지는 쉽게 이해가 가실거라 생각됩니다. 아직 부족하다구요? 그럼 더 쉽게 --;

by value의 참조는 변수에 값을 직접할당하는 방식이며 (변수를 박스라고 생각하시면) 박스안에 내용물이
중요한 놈이죠.
by reference의 참조는 변수에 값을 직접 할당하지 않고,(변수를 박스라고 생각하시면) 박스의 위치에
관심이 있는 놈입니다.
내용물에 뭐가 담겨져있고, 그 내용물이 어찌되던간에 그 박스의 위치만 잘 가지고 있으면 되는 놈이죠.
나중에 변수를 call하면 by reference의 참조는 "값을 가져오라고? 그래. 난 박스주소를 알고있으니까, 그박스에 뭐가있는지는 잘모르지만 내용물을 넘겨줄께"라고 행동하게 됩니다.

그럼 Javascript에서는 위의 개념을 어떻게 가지고 있을까요? 이제 소스를 보면서 이야기해보죠.

<html>
<script>
   //첫번째 구문
   var ref_1 = "string...";
   var test_1 = ref_1;
   ref_1 = "none";

   //두번째 구문
   var ref_2 = new String("hello world");
   var test_2 = ref_2;
   ref_2 = new String("world");

   //세번째 구문
   var ref_3 = new Array("one", "two", "three");
   var test_3 = ref_3;
   ref_3[0] = "1";

</script>
<body>
</body>
</html>


우선 '첫번째 구문'에 대해서 살펴보죠. 아주 쉽습니다. 단순히 문자열을 변수에 담고있고, 그것을 다시 다른 변수에 담았습니다.
그리고 원래 변수의 값을 변경했군요.

'두번째 구문'은 결과적으로 '첫번째 구문'과 동일하지만 다른점이 하나 있습니다. 바로 new String이란 것을 사용해서 변수에 담고있습니다.
'첫번째 구문'에서 ref_1의 타입은 Stirng이지만, '두번째 구문'에서 ref_2의 타입은 Object입니다. 역시 마지막에선 다른 String Object로
값을 변경하고 있네요.

'세번째 구문'은 많이 사용하는 배열입니다. 배열은 자체가 Object인건 아시죠? 역시 이것도 test_3이라는 변수를 만들고 ref_3을 담았습니다.

이상 소스설명은 드렸습니다. 여기까지 이해가 가시나요? 혹시 안가신다면 제게 질문을 하시거나, 구글링을통해 학습이 필요합니다.
이제 제가 질문을 드리겠습니다.

1. alert(test_1)를 실행하면 값이 어떻게 나올까요?
2. alert(test_2)를 실행하면 값이 어떻게 나올까요?
3. alert(test_3)를 실행하면 값이 어떻게 나올까요?

3개의 답을 모두 자신있게 말씀하셨다면, 거기에 답까지 맞으셨다면 축하합니다 ^^*

1번의 답은 "String..."이 출력됩니다. 이유는 String타입의 값들은 by value에 의해서 참조가 됩니다.
다시말해서, test_1은 ref_1의 주소값을 가지고 있는게 아니라 "String..." 자체의 값 즉, value를 가지고 있는겁니다. 그러므로 아무리 ref_1의 값을 변경해도 값에의한 참조(by value)를 한 test_1은 영향을 받지
않는거죠.

2번의 답은 3번을 설명하고 다시 이야기하겠습니다.
3번의 답은 "1, two, three"가 되겠습니다. 왜일까요? 그렇습니다. 둘중에 하나니까 그렇습니다 --;
위에서 값에의한 참조였으니, 이번엔 그반대의 경우겠지요 ^^; 물론 맞는 답입니다만, 정확한 설명을 드리면, ref_3은 Object를 담고있습니다. 그리고 test_3는 ref_3을 참조하지요. 그리고 Object는 by reference에 의해서 참조가 됩니다. 위에서 제가 말씀드린게 by reference가 되면 값을 가지고 있는게 아니라 참조되는 놈의 주소를 가진다고 말씀드렸습니다. 이해가 되시는지요?
만약 값에 의한 참조가 되었다면 test_3는 값이 변경되기전의 ref_3을 참조했기때문에 test_3는 ref_3의 값의 변동에 상관없이 동일한 값을 가지고 있어야함에도 불구하고, 결과는 변경된 값을 가지고 있습니다. 바로 by value가 아닌 by reference에 의해 참조가 되기 때문이지요. by reference로 참조된 변수는 그안에 값이 어떻게 바뀌든지 상관없이 주소값만을 가지고 있으므로 나중에 주소안에 들어있는 값만을 내뱉어 줍니다.
위에 설명 드렸던 부분입니다.

그럼 2번은 결과가 어떻게 될까요? 참으로 애매한 부분입니다. 답은 "hello world"가 출력됩니다
new String으로 생성했으므로 분명 Object입니다, 그럼 by reference에 의해서 참조가 일어나야 정상이지만
결과적으로 그렇지 못합니다 --;
왜그럴까요? 여기에도 무언가가 있기 때문입니다.

바로 Wrapper Object가 범인입니다. Wrapper를 잘모르시는 분을 위해서 잠깐 설명을 드리겠습니다.
Wrapper는 보통 타입을 변경하기위해 사용합니다. String으로 사용하지만 나중의 변환을 위해 new String으로 생성하여 Object로 만들어 내는것입니다. 물론 Javascript에서는 자동 형변환에 의해 크게 사용되지는
않습니다.
다시 본론으로 돌아가서, Wrapper Object는 Object이지만서도 by value에 의해 작동됩니다.
[O'reilly의 Javascript The Definitive Guide 5/E 3장 참고]
(Javascript에서의 Wrapper Object는 String, Number, Boolen이 있습니다. )
그러므로 예상대로 "world"가 출력되지 않고 "hello world"가 출력되는 것입니다.

오늘은 조금 짧게 써보려고 했는데, 말이 길어졌군요 ㅎㅎ 오늘의 주제는 "참조"였는데 만족할 만한
주제였는지 모르겠습니다.
기초강좌라서 약간은 부담이 되는게 사실입니다 ^^; 최대한  쉽게 풀어서 설명하고 싶은데 생각처럼 그렇게
쉽지만은 않군요ㅋ 포스팅을 하다보니 벌써 저녁먹을 시간이네요.. 오늘도 야근모드인
개발자의 비애ㅋ

자 기초강좌가 언제까지 연재 될지 모르겠지만 가끔은 중급강좌도 쓰도록 하겠습니다.
즐거운 저녁식사 되세요~~

posted by blankus


---------------- 트래백 http://www.blankus.net/trackback/5 ----------

위글을 봐서도 알겠지만 ㅡㅡ 뻔히 아는애기 왜하냐고 하면 ㅡㅡ

답이 없지만 서도 ;; 초보자들이 개념만충 하기엔 딱좋은 글이다.

그래서 퍼왔다 !
2007/11/21 12:51 2007/11/21 12:51
이 글에는 트랙백을 보낼 수 없습니다
http://mckoss.com/jscript/object.htm

위의곳을 참조하여보아라

JS 의 참맛을 알게 될것이니 ....

난 지금 js _ abstruct 를 만드는 중인데 .. 참고할만 하다.
2007/11/20 00:57 2007/11/20 00:57
이 글에는 트랙백을 보낼 수 없습니다

사용자 삽입 이미지
 


이 만화에는 놀라운 철학이 들어 있었뜸미다


엄청 단순하고 못그리려고 노력한 그림임에도 불구

눈의 크기와 코의 크기같은 사람의 얼굴 부위별 형태가 모두 다름으로써 서로간의 개성을 어필

비록 단순한 눈으로 보더라도 똑같다고 부를수 있는 사람은 결코 없음을 내포하고 있으며

그들의 대화는 한층 더 놀라운 탄성을 지르게 합니다.


 "너는 씨發 jot찐따" 부분에서 얼굴에 감정을 들어내지 않은채 말하는것으로 보아

상대방에 대한 견제와 그 인격을 알아보기위한 여러의미의 공격수단으로 사용하였으며

그 어려운 공격을 "헐 나 삐져뜸ㅋ"이라는 화난건지 아니면 이해하고

개그로 받아치는(얼굴색 변화 하나 없이)건지  알수 없는 저 반응은 서로 견재하는 상태에 놓여있음을

뜻하고 있습니다.


  이에 공격자는 그에 대응하여 수준이 지나친 사과의 자세와 그 지나친 사과의 자세와는 맞지 않는

"미안"이라는 간단한 말을 함으로써 상대방의 상태를 한번더 떠보는 행동을 하게 됩니다.


  서로 견재함을 뜻하는 만화답게 이에 대응해 수비자도 또 반격을 시작합니다

분명 자신을 공격을 받고 자신을 공격을 받아 좋지 않음을 전달했을 뿐임에도 수비자는

"내가 더 미안"이라는 말을 합니다.

고작 나 삐져뜸ㅋ라는 말 만으로도 자신이 "내가 더 미안"이라고 사과해야 할 수준이니

너의 "미안"이라는 말은 나에게 사과하기엔 매우 부족한 표현이다 라는 뜻을 가지고 있으며

수비자의 행동도 같은 뜻을 의미하고 있습니다.

고개를 90도를 더 넘게 숙임으로서 "이정도가 미안의 의미다"라는 말을 간접적으로 전달하고 있으며

고개를 숙인 상태로 공격자의 얼굴을 주시하고 있으므로 상대방이 얼굴로 미안해 하는정도를 확인하고 있는 것입니다. 


 이에 드디어 견재로 이어지던 서로간의 행동이 본격적인 공격성을 갖기 시작합니다.

간접적이 아닌 직접적으로 말이죠

공격자의 "질 수 없음"이라는 말은 자신이 분명 상대를 견재하기위해 상대방에게 그런 행동과

말을 했음을 감출수 없어 나타나게 되어버린 행동이며

수비자는 이 공격자의 뜻을 알고 있었다는듯 "질 수 없음"이라는 말을 합니다.

서로간의 견재는 이제 필요없고 본론으로 들어가 싸우고 싶다는뜻을 알리는 말이죠

이는 사회에 서로 자신을 알리고 싶어하면서 정작 자신의 생김새나 거의 모든것들을 감춘채

살아가는 인간들의 서로의 감춘 내면을 떠보려 하는 현대인의 본능적 행위를 묘사한 것입니다.


  그러나 이 만화의 주제는 서로간을 떠보려고 하는 그런 인간의 모습을 묘사하려는것

그것만은 아닙니다

이 만화의 진정한 주제가 드러나는 부분은

마지막 제 3자가 나타나 "우왕ㅋ굳ㅋ"의 대사가 진정한 이 만화의 주제를 드러내고 있습니다.

서로 견재를 하다 마침내 자신이 피해입는건 고려하지 않고 서로를 떠보려고 하는 두 인간들...

하지만 그 행위는 이미 자신이 드러내고 싶지 않은 추태를 보이고 마는 것으로써

제 3자는 별 노력없이 그 두명의 약점을 잡게 되었습니다.

시야를 넓게 가지지 않고 조그만 일에서 자아와 삶의 목적을 상실하게 되면

결국 피해를 입게되는건 자신뿐이라는 의미를 가지고 있으며

제3자의 "우왕ㅋ굳ㅋ"은 우리에게 충격의 메세지를 전하고 있습니다.


  일단 우왕ㅋ굳ㅋ은 만화로써 많은 감정상태를 우리에게 전달해 주고 있습니다.

'우왕ㅋ'와 '굳ㅋ'가 서로 분리되어 다른 말풍선에 들어있습니다.

보통 쓸 공간이 넉넉한데 말풍선을 다시 만들어 글을 쓰는 경우는

그 두 나눠진 글이 서로 같은 내용이 아니거나 같은 감정상태가 아닌 경우입니다.

우왕ㅋ와 굳ㅋ의 분리

우왕ㅋ는 좁은 말풍선에 꽉찬 글자가 들어 있습니다.

이는 잠잠하던 사이 갑자기 이 사건을 발견하였으며 여유없이 놀란 상태임을 의미하고

굳ㅋ의 말풍선은  매우 공간이 넉넉하며 말풍선다운 형태를 갖지 못하고 있습니다.

이것은 현재 자신이 매우 여유로우며 흥미있고 이득이 되는 상황에 이르렀음을 깨달았다는

의미를 가지고 있습니다.



  이 두 말풍선이 지닌 우리에게 줄 메세지

그것은 이미 여러분의 가슴속에 새겨지지 않았을련지요….



-2007 11월 10일 바이트드림-


2007/11/18 18:31 2007/11/18 18:31
이 글에는 트랙백을 보낼 수 없습니다
그동안 Prototype 자바스크립트 프레임웍의 사용법을 익히느라 필요이상으로 무리하게 사용해 왔습니다. 간단하게 크로스 브라우징이 보장되며 코드를 아름답게(?) 만들 수 있다는 장점 때문이였는데요. 개발하기 편하여 생산성 높은 환경을 제공하는 반면 원시코드에 비해 9배이상의 시스템 성능저하가 나타나기도 합니다. 아래와 같은 테스트용 루프 함수를 만들고 결과는 동일하면서 모든 브라우저에서 통용되며 상습적으로 사용되는 Prototype함수와 자바스크립트 메서드를 벤치마킹해 보았습니다. 테스트에 사용된 Prototype 프레임웍 라이브러리의 버전은 Scriptaculous1.6.1에 포함된 1.5.0_rc0이며, 브라우저는 파이어폭스2.0b, 시스템사양은 Pentium4, 3.00GHz입니다.

// 타임체크 함수
function timeChecker() {
    var befor, loops, after, tpo, tet, result
    before = new Date()
    loops = 500 //루프 수
    for (var i=0; i < loops; i++) {
        Element.update('element', '내용')// 태스트함수
    }
    after = new Date()
    tpo = Math.round(1000*(after-before)/loops)
    tet = (after-before)/1000
    result = 'Time per operation: '+tpo+', Total excuted time: '+tet; //결과값
    throw(result)
    //return result
}
timeChecker();


1. DOM 엘리먼트 스타일 설정:
프로토 타입에서는 여러가지 형태로 DOM을 주무를수 있게 해 주는데요. 1만회에 걸쳐 객체를  width:'300px', height:'100px'으로 변경하는 테스트입니다. 아래의 결과를 살펴봅시다.

1. document.getElementById('엘리먼트').style.스타일 = '값' // (원시코드, 2라인) -->  1.14초
2. $('엘리먼트').style.스타일 = '값' // (2라인) -->  1.656초
3. Element.setStyle('엘리먼트', {'스타일:값의 배열x2'})  // --> 1.985초 
4. $('엘리먼트').setStyle({'스타일:값의 배열x2'}) // --> 3.047초

동일한 결과값을 가지는 위 4가지 코드는 처리에 필요한 시간이 서로 다릅니다. 4번은 원시코드와 2배이상 차이가 벌어지는 재미있는 결과를 보여줍니다. 반복성이 짙은 경우, 즉 엘리먼트를 실시간으로 업데이트하거나 모션에 사용할 코드는 4번의 형태는 가급적 피하는 것이 좋습니다. 당연히 1.번이나 2번의 형태가 좋겠죠?

2. DOM 엘리먼트 스타일 값 구하기:
DOM의 위치또는 모양을 확인하기 위해 prototype은 getStyle, getDimensions 메서드를 제공하고 있으며, 엘리먼트의 높이 값만을 구하기 위한 getHeight와 같은 메서드도 있습니다.(그나저나 getWidht는 왜 없는걸까요?) 엘리먼트의 높이값(height)을 알기위한 가장 빠른 방법은 무엇인지 살펴 봅시다.

1. document.getElementById('엘리먼트').offsetHeight  // (원시코드) -->  Number 0.391초
2. $('엘리먼트').offsetHeight //Number --> 0.625초
3. Element.getHeight('엘리먼트') //Number --> 0.641초
4. document.getElementById('엘리먼트').getHeight() //Number --> 1.328초
5. $('엘리먼트').getHeight() //Number --> 1.563초
6. Element.getStyle('엘리먼트', '스타일')  //String  --> 2.812초 
7. $('엘리먼트').getStyle('스타일') //String  --> 3.843초

높이 값이 '123px'와 같은 스트링으로 반환된 6, 7번은 'px' 문자열을 없애기 위해 parseInt()하거나 '스트링.substring(0,스트링.length-2)'을 사용해야 합니다. 6, 7번은 쓸일이 없을 것 같은데 왜 집어넣었냐구요? 하지만 아래와 같은 경우(다중 이미지 비율계산)에는 벤치마크 결과와는 정 반대로 6, 7번이 훨씬 빠른 성능을 내기도 합니다.(슬라이드를 움직여 프레임을 비교해보세요.)

// Realtime image Ratio
function setRatio(v) {
    var x,y,h
    var w=Math.round(v)
    $$('array').each(function(e){
        x=Element.getStyle(e, 'width'); y=Element.getStyle(e, 'height')
        h=Math.round(v*y.substring(0,y.length-2)/x.substring(0,x.length-2));
        e.style.width=w+'px'
        e.style.height=h+'px'
        e.style.margin=(w-h)/10+'px'
    })
}


Element.getHeight('엘리먼트')
Width: 75px

Element.getStylet('엘리먼트', 'height')
Width: 75px

3. DOM 엘리먼트.Show/Hide:
1. document.getElementById('엘리먼트').style.display = 'block' // -->  0.547초
2. $('엘리먼트').style.display = 'block' // -->  0.812초
3. Element.show('엘리먼트')  // --> 1.312초
4. $('엘리먼트').show()  // --> 2.609초

또한 가장 많이 사용하는 것 중의 하나인 엘리먼트 Show/Hide를 봅시다. 1만회를 루프로 돌린 결과입니다. 스타일의 결과와 비슷하지요? 역시 원시코드가 가장빠릅니다. 하지만 이것은 결과값이 브라우저에 따라 서로 다르게 나타나기도 합니다. IE에서는 $('element').style.display = 'block', 파이어폭스에서는 Element.show('element')가 잘 돌아간다는 느낌입니다.

4. DOM 엘리먼트.InnerHTML:
1. document.getElementById('엘리먼트').innerHTML // -->  0.672초
2. $('엘리먼트').innerHTML = '내용' // -->  0.766초
3. Element.update('엘리먼트', '내용') // -->  2.39초

이것은 3천회 루프의 결과입니다. 이 또한  원시코드를 사용하는 것이 3배 빠르군요. 눈치 채셨겠지만 "오브젝트.메서드"의 결합과 "메서드(오브젝트)"에도 결과는 같지만 소요시간이 다릅니다. DOM 스타일링에는 메서드(오브젝트)와 같은 형태가 좋습니다. 뭐 결과적으로는 원시코드를 적절히 혼용하면 시스템 퍼포먼스를 크게 끌어올릴 수 있다는 것이지만요.

5. 정수 구하기:
1. Math.round(넘버) // -->  1.453초
2. (넘버).toFixed(0) // -->  3.859초

소수점 이하의 수를 반올림하는 경우 100만회 루프 결과 toFixed(0) 보다 Math.round()가 2배이상 빠릅니다.

6. 브라우저별 색상처리:
좀 다른 얘기지만, getStyle로 색상 값에 따른 이벤트를 처리하는 경우 브라우저 마다 가져오는 색상 값이 틀립니다. 스타일스트(CSS)에 '#f80'으로 설정되었을 경우 브라우저별로 가지고 온 결과는 아래와 같습니다.
오페라 = '#ff8800'
파이어폭스 = 'rgb(255, 136, 0)'
익스플로러 = '#f80'


7. 홀수 짝수 구하기:
홀수나 짝수를 루프에서 처리할 때 'n%2'를 쓰거나 'n&1'을 쓰는 두가지 방법이 있습니다. 이럴땐 'n&1'이 미약하게 나마 약간 더 빠릅니다.
for (var n=0; n < 100;n++) if(n%2==1)$('element').innerHTML = 'test';
for (var n=0; n < 100;n++) if(n&1==1)$('element').innerHTML = 'test';


추가. 문자열비교 : match 보다 test가 빠르고 indexOf가 두배 빠름(50만회)
var testing = 'test test test';
testing.match(/test/); // -->  0.702초
/test/.test(testing); // -->  0.643초
testing .indexOf('test ') != -1; // -->  0.395초


추가. if문과 단순 조건문 속도차이 없음.(500만회)
var boo = true; 
boo = boo? 'true' : 'false'; // -->  0.736초
if(boo){ boo = 'true'; } else { boo = 'false'; } // -->  0.726초


추가. DOM Selecter(500회)
$$('#taglist .row');// -->  1.496초
$$('.row');// -->  tset failed
document.getElementsByClassName('row', 'taglist');// -->  0.193초
document.getElementsByClassName('row');// -->  3.321초

2007/11/09 12:29 2007/11/09 12:29
이 글에는 트랙백을 보낼 수 없습니다
웅쓰:웅자의 상상플러스
웅자의 상상플러스
전체 (379)
게임 (5)
영화 (2)
기타 (23)
맛집 (5)
영어 (2)
대수학 (3)
형태소 (5)
Hacking (9)
Linux (112)
HTML (48)
Application_developing (48)
Web_developing (102)
Window (11)
«   2007/11   »
        1 2 3
4 5 6 7 8 9 10
11 12 13 14 15 16 17
18 19 20 21 22 23 24
25 26 27 28 29 30  
  1. 2016/01 (1)
  2. 2015/12 (3)
  3. 2015/10 (3)
  4. 2015/03 (2)
  5. 2015/01 (4)