슭의 개발 블로그

자고 일어나보니 친구들이 https://morsecode.me/ 라는 사이트에서 놀았던 로그가 있었다. 뭐하는 사이트인가 보니 키보드 혹은 마우스로 morse code 를 입력하는 사이트였다. 하.... 이 마니악한 인간들이라는 생각이 먼저 들었는데 조금 놀다 보니까 이게 은근히 꿀잼이다. 옛날에 들었던 논리설계실험이라는 수업에서 프로젝트 과제로 모스 기계 만들던 생각도 나고.... 모스기계의 원리는 간단하다. 어떤 임의의 unit time이 있고, one unit만큼의 signal은 short mark (기호상으로는 . , 발음은 dot 혹은 dit) , 그 시간의 3배의 시간 동안 signal은 long mark (기호로는 - , 발음은 dash 혹은 dah) 라고 한다. unit time만큼 입력을 쉬고 있는 것을 short gap, 3 unit times만큼 쉬는 것을 long gap이라고 하여, short gap으로 이어진 mark는 같은 character로 인식하고, character가 달라지면 medium gap이라고 부른다. word가 달라지는 건 long gap(unit time의 7배)으로 구분한다. 원리는 간단하지만, 모스부호를 외우는 게 장난이 아니고, 외웠다고 하더라도 실수 없이 치는 게 쉬운 일이 아니다. 그래서 translator를 만들면 조금 더 쉽게 작업할 수 있지 않을까 하여 F12를 눌러 콘솔 창을 열었다. 처음에는 사이트가 jQuery로 짜여 있는 것을 보고 jQuery의 event trigger를 이용하면 되지 않을까 해서 시도해봤는데 trigger가 안된다. 왜지? 라고 생각하면서 코드를 봤는데, 모스부호를 입력하는데 가장 중요한 object인 Morser의 instance인 me가 그대로 노출되어 있었다. 그래서 만들어진 스크립트는 다음과 같다. 근데 아무리 고생스러워도 이런 건 직접 입력하면서 노는 게 더 재밌다. 스크립트 이용해서 하니까 갑자기 재미없어진다. p.s. 코드에 다음과 같은 주석이 있는

Rhino 는 mozilla에서 개발한 Java 로 구현된 JavaScript engine이다. 과거 Netscape 에서 Java로 구현된 navigator를 구현하려는 시도를 한 적이 있는데, 이때 사용했던 JavaScript engine이 Rhino engine의 전신이 된다. Javagator라고 불리던 이 프로젝트는 JavaScript를 Java byte code로 컴파일하여 실행하기 때문에 당시에 있던 다른 브라우저보다 빠른 성능을 낼 수 있을것을 기대했지만, JVM 자체의 성능 이슈와 다른 여러가지 상황때문에 중간에 중단되었지만, 일부 회사들의 지원으로 JavaScript framework은 분리되어 Rhino가 되었다. Rhino의 가장 큰 특징은 내부적으로 Reflection 을 이용하여 JavaScript 코드에서 Java class를 그대로 가져다 쓸 수 있다는 것이다. 또한 Java구현체를 그대로 사용할 수 있기 때문에, JavaScript engine 중에서는 특이하게 multi thread support가 된다는 특징을 가진다. JVM이 꾸준히 성장하여 많은 성능 개선을 이루었지만, WebKit 이 사용하는 JSC(JavaScript Core) 나 Google이 개발한 v8 engine 도 내부적으로 JavaScript를 compile하기 때문에 Rhino가 가지는 성능상의 이점은 없다. 사실상 v8이나 jsc보다 느리다. 성능상에 이점은 없지만, 반드시 Java를 사용해야 하거나 multi-core support가 필요한 일부 환경에서는 Rhino engine을 사용하는 경우가 있다. 하지만 이 중에 이름만 들어서 알만한 유명한 프로젝트는 없다. Rhino를 사용하는 가장 유명한 구현체는 RingoJS 로 보인다.

요새 재미삼아 만들고 있는 웹 프로그램이 있다. JavaScript를 약간 하드하게 사용하여야 하므로, pure한 JavaScript를 사용하지 않고, CoffeeScript를 이용하여 개발을 진행하고 있다. CoffeeScript 자체를 실행시키는 interpreter가 존재하지 않고, 언제나 JavaScript로 compile한 뒤 실행되어야 해서, 빠르게 코드 수정 내용을 테스트할 수 있다는 장점이 사라진다. 변환되는 과정에서 어떤 경우는 JavaScript로 직접 작성한 코드보다 비효율적인 코드가 나오기도 한다. 게다가 CoffeeScript는 기본적으로 모든 JavaScript 코드는 CoffeeScript 코드로, CoffeeScript 코드는 JavaScript 코드로 1:1로 변환 가능하게 해주는 것을 목표로 삼고 있기 때문에, JavaScript보다 더 powerful한 것도 아니다. 그럼에도 새 프로젝트에 JavaScript를 사용하지 않고 CoffeeScript를 사용하는 것은 다음의 두 가지 이유 때문이다. 우선 내가 c-style의 코드보다 ruby-style의 코드를 더 좋아한다. 별거 아니지만 오랜 시간 아무런 이득도 없이(쉽게 말해서 돈 받는 게 아니면서) 혼자서 쓸쓸히 작업하려면 내가 좋아하는 방식으로 작업하는 게 최고다. 다음으로 compile과정을 거치기 때문에 실수를 한번 걸러줄 수 있다. compile 과정에서 엄격한 정적 분석을 거치는 것은 아니지만, 기본적인 실수를 막아주는 역할 정도는 할 수 있다. CoffeeScript가 undefined 를 void 0 로 compile하는 이유도 여기에 있다. 위와 같이 undefined 를 사용하는 CoffeeScript 코드를 컴파일하면, 아래와 같이 undefined 를 void 0 로 변환한 JavaScript 코드를 돌려준다. void 함수는 분명히 언제나 undefined 를 return 하기는 하지만 굳이 멀쩡한 undefined 를 놔두고 v