서론

자바스크립트에 대한 불안정성의 선입견은 아무래도 다른 VM을 가진 언어보다는 훨씬 오해를 많이 받는다. 그 중에 하나가 바로 Javascript는 브라우저에서만 동작한다는 오해이다. 지금은 개발자들 사이에서 nodejs가 어느정도 인지도가 있기 때문에 더이상 javascript가 브라우저의 자바스크립트 엔진으로 돌아가는 front-end 개발 언어로만 인식되지 않고 있다. nodejs를 이용해서 서버 프로그램을 하고, 임베디드 프로그램까지 개발을 할 수 있는 시대가 왔기 때문이다.

우리 연구소에서는 지금 프로젝트 개발을 하면서 이 Javascript에 대한 오해와 그 오해를 풀기 위한 조사들을 계속 하고 있는 중이다. 그래서 오류없는 Javascript 어플리케이션을 개발하는 것이 우리의 가장 큰 목표이다. 처음 우리가 가진 Javascript의 오해는 바로 브라우저에서만 Javascript를 개발할 수 있다는 것이였는데 일전에 Javascript에서 Callback 구현하기 글에서 Rhino를 소개하면서 Rhino의 쉘에서 Javscript를 디버깅할 수 있다는 것을 포스팅하였다. 이번 포스팅은 브라우저 없이 Javasctipt를 개발하는 연장선으로 Envjs를 소개하려고 한다.

서론

프로그램을 개발하면 설계만큼 중요한 것이 바로 테스트이다. 내가 만든 아주 간단한 프로그램(함수를 포함한 어떠한 프로그램)을 검증하기 위해서 단위 테스트는 개발 프레임워크에서 절대 빠져서는 안되는 중요한 것이다. 하지만 나를 포함한 대부분의 개발자는 개발공수가 부족하다는 이유로 단위 테스트를 가볍게 여기고 간단한 로깅으로 프로그램을 작성하기에 급급해 한다. 이렇게 단위 테스트를 하지 않고 프로그램을 작성하다가 어느날 갑자기 큰 오류가 발견되었는데 그 오류가 과연 어디에서 어떤 부분에서 오래가 발생했는지 알지 못해서 복잡한 코드의 흐럼을 하나하나 다시 스택이나 힙의 내부를 관찰하면서 디버깅을 할 것이다. 하지만 이미 엄창난 양의 코드에서 문제를 발견해내는 것이 쉽지 않다. 그래서 프로그램 단위가 끝나면 단위 테스트를 이행하여 프로그램의 그 프로그램 조작이 논리적으로 이상이 없는지, 문제가 없는 함수인지 또는 클래스나 프로그램인지 학인해서 코드의 복잡성과 별개로 단위별 코드의 품질을 높일 수 있어서 에러를 사전에 예방할 수 있다. 자바에서는 JUnit이라는 단위 테스트 라이브러리가 매우 강력하고 대부분 자바 프로그램에서는 JUnit을 사용하고 있다. 아이폰을 개발하는 Xcode에서도 Unit Test를 지원하기 위한 프레임워크가 내장되어져 있다. 그럼 Javascript에서 프로그램 단위 테스트를 하기 위한 라이브러리가 있을까?하고 찾게 되었는데 커뮤니티에서 QUnit을 많이 언급하고 있어 QUnit으로 단위 테스트를 하기 위해서 이 포스팅을 작성하였다.

서론

자바스크립트(Javascript)를 도입할 때 어떤 개발자는 Javascript의 유연성에 매력을 느끼고 어떤 개발자는 Javascript에서 발생하는 에러 때문에 Javascript에 알레르기를 보이기도 한다. Javascript는 여러가지 특수한 성질 때문에 매우 유연해서 이식성 높은 프로그램을 만들 수 있지만, 그만큼 다른 언어에 비해서 디버깅하기 어렵다. Javascript 언어의 특별한 특징 중에서 오늘은 자바스크립트의 변수에 대해서 이야기를 하려고 한다.

서론

프로그램을 이벤트 기반으로 만들게 되면 한 프로세스로 모든 일이 끝날 때 까지 기다리지 않고 처리된 일이 이벤트를 발생시키거나 다른 일을 비동기적으로 할 수 있다. 이렇게 비동기적으로 일을 처리할 때는 Callback이나 Listener, delegate 등으로 구현할 수 있다. Callback에 대한 소개와 Java로 구현된 코드를 Java에서 Interface를 사용하여 Callback 구현하기 아티클에서 간단히 살펴보았는데, 이 포스팅에서는 Javascript에서 Callback을 구현하는 방법에 대해서 소개한다.

서론

만약 스마트 폰 앱을 개발할 때 세로모드(Portrait)에서는 단순하게 화면을 구성하지만 가로모드(Landscape) 화면 구성을 좀더 다양한 화면으로 구성 하고 싶다면 어떻게 할지 고민할 수 있다. 또는 해상도나 디바이스의 스크린크기, 디바이스 종류에 따라서 보여지는 것들을 다르게 구성하고 싶어할 수도 있다. 안드로이드 개발자들은 이러한 요구사항을 만족시켜줄 수 있는 것을 fragment라는 개념으로 추가하게 되었다. 안드로이드 2.3 이하 버전에서는 한 화면에 보이는 모든 것을 관장하는 것이 Activity라는 개념이였다. 이러한 Activity는 하나의 화면에 여러개 사용할 수 없게 설계가 되어있다. Activity 하나하나 마다 생명주기를 갖고 있기 때문이다. 만약 하나의 화면에 Activity와 비슷한 개념을 가지면서도 여러가지 화면을 넣을 수 있는 방법으로 fragment가 등장하게 되었다. 이 fragment 는 Android 3.0 부터 등장하였지만 Android 3.0은 태블릿을 위한 버전이라 Android 3.0 버전 때의 SDK를 사용하거나 개발하지 못했다. 하지만 Android 4.0 이상 부터는 안드로이드 개발자들이 스마트폰과 태블릿을 동시에 적용할 수 있게 지원하면서 Android 3.0 이상에서 부터 사용할 수 있는 fragment를 사용하여 개발할 수 있게 되면서 자료를 찾아서 실험하게 되었다.