[EP]ANYFRAME JAVA SEMINAR 2010..

출처 : Outsider's Dev Story https://blog.outsider.ne.kr/

10일에 삼성SDS주최로 진행된 ANYFRAME JAVA SEMINAR에 갔다가 왔습니다. Anyframe은 삼성에서 만들어서 오픈소스로 공개한 자바 프레임워크로 이름 정도만 알고 있었는데 최근에 들으니 스프링 기반으로 되어 있는듯 합니다.(이걸 기반이라고 해야하는건지는 잘 모르겠지만요.)

Spring 3.0
첫번째 세션은 스프링에 대한 설명이었습니다. 스프링이 2.0에서 3.0으로 넘어오면서 3.0이 가진 Feature들을 중심으로 간략한 설명들과 간단한 데모를 통해서 어떻게 사용하는 부분인지에 대해 설명해 주었습니다.

• Spring Expression Language가 추가되어 #{expr}을 통해서 특정 객체의 접근 및 조작이 가능하면 코드내에서는 @Value와 함게 사용하여야 합니다. <spring:eval>을 제공하여 JSP에서도 사용가능합니다.
• 모델 밸리테이션 : 이전에는 Javascript로 하거나 스프링이 가이드한 밸리데이터를 만들어야 했으나 3.0부터는 JSR-303을 지원하여 밸리데이션 규약을 제공하고 있습니다. 밸리데이션 방법으로는 파라미터에 @Valid 애노테이션을 선언하는 선언적 방법으로 BindingResult에 밸리데이션의 결과가 자동으로 담기게 되고 @Autowired로 밸리데이터를 직접 인젝트하는 프로그램적 방법이 있습니다.
  타입 컨버전 : 이전 버전에서는 프로퍼티에디터를 주로 사용하였으나 프로퍼티에디터의 단점을 해결하고 범용적으로 사용할 수 있도록 타입컨버전을 3.0에서 추가하였습니다. 포맷이 필요한 컨버전에서는 Formatter를 사용합니다.
• MVC 네임스페이스: mvc:annotation-driven을 통해서 컨버터, 밸리데이터, 포매터등을 자동으로 등록되도록 선언할수 있습니다.
• REST지원 : REST는 모든 리소스에 대해 URI가 생기기 때문에 이에 대한 관리를 지원하게 되었으며  HiddenHttpMethodFilter는 웹브라우저가 GET, POST만 지원하는 한계를 해결하기 위해 DELETE, PUT을 지원하도록 하였습니다. ContentNegotingViewResolver를 통해서 URI의 확장자에 따라서 포매팅을 다르게 해줄 수 있습니다.

저는 스프링에 대해서 아직 많이 몰라서 그냥 들었습니다만 스프링을 좀 아는 사람들에게는 기초적인 내용으로 보였습니다. 3.0에 추가된 기능들 위주로 설명이 진행되었기 때문에 내용을 정리하기가 쉽지 않지만 그냥 기억나는 부분위주로만 로그성으로 적어두었습니다.(일부 잘못되거나 누락된 내용이 있을 수 있습니다.) 3.0특징에 대해 알려면 인터넷에 정리된 문서를 참고하는게 더 낫지 않을까 합니다.

웹 개발 단순화 방안
일반적으로 하는 요청에 대해서 디스패처서블릿이 컨트롤을 찾고 로직을 탄뒤 페이지에 전달하는 프리젠테이션 레이어를 개발하는 것은 항상 하는 반복적 작업이므로 이걸 공통화 한 부분에 대한 설명이었습니다. Controller에 대한 공통화로 모든 곳에서 확장포인트를 제공하고 있다고 하였으며, Controller를 공통화하여 페이지의 header, left, footer를 공통으로 하고 비동기로 body만 바꿀수 있도록 한 Anyframe의 기능에 대한 설명이었습니다.

Taglibrary를 이용하여 프로트엔트에서 많이 사용하는 부분을 공통화하여 더블서브빛 방지나 메뉴 클릭시 body부분을 어떤 페이지로 바꿀지, form태그에 달력기능을 추가하는 등의 기능들을 View페이지에서 태그라이브러리를 사용하여 개발할 수 있도록 한 구조였습니다. 이렇게 함으로써 프리젠테이션 레이어의 개발을 빠르게 하고 콘트롤러는 공통을 그대로 사용한채 비즈니스로직과 모델만을 개발할 수 있다고 하였습니다.

앞의 설명에 확장포인트를 제공하고 있다고 하였지만 아무래도 프레임워크가 UI기능을 제공하기 때문에 종속적이 신경쓰였습니다. 시연에서는 tiles와 jquery가 사용되었었는데 달력등의 기능은 어떤 라이브러리에 대한 종속성을 가지지 않고는 해결할 수 없는 기능이었기 때문에 굳이 프레임워크에서 제공해야하는 기능인지는 잘 모르겠다는 생각이었습니다. 특정 환경에서는 저런식으로 다 만들어 놓으면 개발은 어느정도 편리할것 같기는 했습니다. 세미나듣다가 예리한 arawn이 말한대로 저렇게 호출부가 뷰페이지에 퍼져있으면 변경사항 생겼을때 컨트롤러만 바꾸면 될일을 사용한 곳 모두를 찾아가면서 수정해야 된다는 단점을 지적해주더군요. 제가 잘 몰라서 그런건지 크게 인상적이지 않게 느껴졌는데 발표는 상당히 큰 기능처럼 하셔서 보는데 약간의 당황스러움이 느껴지더군요.

인증 및 권한 관리
기존의 권한관리가 가지고 있던 한계를 스프링 세큐리티가 대부분 해결가능해 졌습니다. 스프링 세큐리티의 장점은 웹영역뿐만 아니라 전체 애플리케이션 영역에 대한 검증된 권한 관리가 가능하고 다양한 인증 표준규격을 지원하며 컨테이녀별 이식성 및 호환성을 확보하였고 재사용의 기반을 제공하고 있다는 것입니다만 한국상황에서는 DB기반이 아닌 XML기반이라 고객이 직접 수정하기가 어렵다거나 환경설정에 대한 UI를 제공하지 않고 권한정보 변경시 서버의 재기동이 필요하다는 담점이 존재하고 있습니다.

그래서 이런 단점을 보완하여 만든 Anyframe IAM을 소개하였습니다. XML을 DB로 관리할 수 있도록 변경하고 IAM Admin Console을 통해서 GUI환경설정기능을 제공하고 있었습니다.

스프링 세큐리티와 어드민 부분은 최근에 관심을 가지고 있는(가져야 되는) 부분이라서 그래도 나름 흥미롭게 봤던것 같습니다. 이것저것 최근에 봄싹사람들하고 의논했던 부분들에 대해서 비슷한 내용들이 나와서 더욱 그랬던것 같습니다. 정확한 메카니즘까지는 모르겠지만 관리화면에서 권한변경이 서버의 재기동없이 바로 적용되는 시연까지 보여준 것이 꽤 인상적이었습니다.

첫세션을 제외하고는 애니프레임에 대한 소개가 주를 이룬 듯한 느낌이고 전체적으로는 간단에 그리 인상적이지 않은 세미나였습니다. 세미나 갔다올때마다 항상 많은 것을 얻어오는 느낌을 받고는 하는데 괜히갔다왔다정도는 아니었습니다만 그리 흥미롭지도 않았던 세미나였던것 같습니다. (왠지 안좋은 얘기만 하는것 같네요. 그렇게 시니컬하진 않은데요. ^^)

[Book] 더글라스 크락포드의 자바스크립트 핵심 가이드..

출처 : Outsider's Dev Story https://blog.outsider.ne.kr/

더글라스 크락포드의 자바스크립트 핵심 가이드 - 더글라스 크락포드 지음, 김명신 옮김/한빛미디어

자바스크립트계의 요다스승이라 불릴정도로(해외에선 어떻게 부르는지 모르겠지만 자바스크립트 완벽가이드에서 그런 언급이 나온뒤로는 저는 그렇게 부릅니다.) 자바스크립트의 거성이라고 할 수 있는 Yahoo!에서 자바스크립트 아키텍쳐로 일하는 더글라스 크록포드의 책입니다. 더글라스 크록포드는 JSON을 만들고 private멤버를 사용하는 방법을 공개하는등 자바스크립트의 발전에 많은 공헌을 하였습니다.

이 책은 다른 자바스크립트책과는 좀 다른 내용을 다루고 있습니다. 아주 기본적인 자바스크립트를 사용할 때의 특징들에 대해서 다루고 있습니다. 어떤 특징들이 있고 어떻게 동작을 하고 어떤것이 좋고 어떤 것이 나쁜지 등등....

봄싹스터디에서 최근 스터디 교재로 사용을 하면서 공부를 했는데 그 내용은 아주 좋습니다. 기본적인 내용임에도 아주 자바스크립트 초보라면 보기는 좀 어려울듯 합니다. 자바스크립트를 어느정도 공부를 하고 중급으로 넘어가기 위해서 기초를 다지기 위해서 한번쯤 봐두기에 딱 좋은 책이라고 생각합니다. 이런 기초적(?)인 내용들을 다 알지 못해도 보통 어느 정도의 자바스크립트는 할 수 있기 때문에 자바스크립트를 어느정도 공부하다가 한번쯤 이 책을 보면 자바스크립트라는 언어에 대한 이해도를 많이 높일수 있고 왜 그런식으로 동작했는지 이해하기 좋은 것 같습니다.

이 책은 크록포드의 자기주장이 아주 강하게 들어 있습니다.(사실 아주 친절하게 설명해 주지는 않고 대신 논지는 아주 명확한 편입니다.) JS에는 이런것들이 있는데 A는 좋고 B는 이래서 안좋기 때문에 B는 쓸필요 없고 A만 쓰면 된다!라는 식입니다. 자바스크립트의 문법들, 객체에 대한 설명등, 프로토타입, 함수의 사용과 호출에 따른 콘텍스트 바인딩, 클로저, 상속을 어떻게 하는지, 배열은 어떤 특징을 가지고 있는지 전혀 모르고 있던 내용도 가득합니다.

나름 자바스크립트 책은 많이 보았지만(책만 많이 봤습니다.) 이 책만큼 클로저에 대해서 명확하게 설명하고 있는 책은 없었던 것 같습니다. 사실 클로서는 이해가 될듯 말듯 했었는데 이 책은 쓸데없는 부분 다 빼고 클로저의 특성을 이용해서 어떤 식으로 사용하면 되는지 아주 명확하게 설명해 주고 있습니다. 클로저에 대해서 이해할 수 있는 것 만으로도 이 책의 가치는 충분한 듯 합니다.

[JS]함수호출 방식에 따른 this의 바인딩에 대해서..

출처 : Outsider's Dev Story https://blog.outsider.ne.kr/

더글라스 크락포드의 자바스크립트 핵심 가이드를 공부하면서 Javascript에는 4가지 함수호출 패턴이 있다는 것을 알게 되었고 이 패턴에 따라서 함수내의 this의 값은 달라지게 됩니다. Javascript에서 this와 객체의 바인딩은 호출시에 일어납니다.

• 메서드 호출패턴
• 함수 호출패턴
• 생성자 호출패턴
• apply 호출패턴

Javascript에서 this의 바인딩은 다룰때마가 헷갈리는 문제이므로 기본이 되는 내용을 공부한 김에 정리해 둡니다.

메서드 호출 패턴
여기서 메서드는 함수가 객체의 속성(멤버함수)로 저장되어 있는 경우에 이 함수를 메서드라고 부르고 메서드를 호출할때 this는 객체에 바인딩 됩니다.

JavaScript

1 2 3 4 5 6 7 8

var test = { x: 100, showX: function() { alert(this.x); } } test.showX(); // 100

함수 호출 패턴

함수가 객체의 속성이 아닌 경우입니다. 이렇게 호출했을때 this는 전역객체(window객체를 의미합니다.)에 바인딩됩니다.

JavaScript

1 2 3 4 5 6

var x = 100; var test = function() { alert(this.x); } test(); // 100

더글라스 크록포드는 이런 특성이 자바스크립트라는 언어 설계상의 오류라고 지적합니다. 왜냐하면 내부함수를 호출했을때 this는 외부함수의 this변수에 바인딩되어야 하지만 그렇지 않고 전역객체로 바인딩 됩니다.

JavaScript

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

var x = 1; var test = { x: 100, showX: function() { alert(this.x); }, whatisX: function() { var show = function() { alert(this.x); } show(); } } test.whatisX(); // 1

이 코드를 실행했을때 whatisX의 show()는 함수호출되었기 때문에 this.x가 test.x가 아닌 window.x가 되어서 100대신에 1이 찍히게 됩니다. test.x를 가르키게 하려면 this변수를 다른 변수에 할당해 놓고 사용하여야 합니다.

생성자 호출 패턴
여기서 생성자가 의미하는 것은 new를 써서 인스턴스를 만들어서 쓰는 함수를 의미합니다. 일반적인 함수는 new를 쓸수도 있고 안쓸수도 있지만 prototype으로 확장을 함으로써 new를 써서 사용하도록 하고 파스칼형태로 첫글자를 대문자로 써줌으로써 생성자함수라는 것을 나타내줍니다.

JavaScript

1 2 3 4 5 6 7 8 9 10

var Test = function(x) { this.temp = x } Test.prototype.getTemp = function() { alert(this.temp); } var t = new Test(100); t.getTemp(); // 100

이렇게 사용하면 new로 만든 객체에 대해서 this가 바인딩 됩니다.

apply 호출 패턴
apply함수는 첫번째 파라미터가 this에 바인딩될 객체이고 두번째 파라미터에 배열로 함수에 넘겨줄 파라미터를 지정합니다. 첫번재 파라미터가 null이나 undefined이면 전역객체에 바인딩 됩니다.

JavaScript

1 2 3 4 5 6 7 8 9

var x = 1; var test = { x: 100, showX: function() { alert(this.x); } } test.showX.apply(null); // 1

메서드 호출패턴에 사용했던 소스에 apply를 적용했습니다. 첫번째 파라미터로 null을 넘겨주었으므로  this가 전역객체에 바인딩되어서 100이 아닌 1이 찍힙니다.

[Book] 손에 잡히는 정규표현식..

출처 : Outsider's Dev Story https://blog.outsider.ne.kr/

손에 잡히는 정규표현식 - 벤 포터 지음, 김경수 옮김/인사이트

개발을 할 때 정규표현식(Regular Expression)의 유용함은 따로 설명하지 않아도 충분할 것 같습니다. 간단한 것은 그냥도 처리가 가능하지만 조금만 복잡해지면 정규표현식의 강력함이 드러나게 되고 나중에는 정규식만 잘 써도 왠만한 텍스트처리는 자유자재로 다룰 수 있습니다.

그럼에도 정규표현식은 따로 공부를 잘 안하게 되는 경향을 띄게 됩니다.(저만 그런지 모르겠지만요...) 개발자로써 공부해야 될 기술들이 산더미같은 마당에 정규표현식에 많은 투자를 잘 안하게 되고 간단한 학습후에는 소위 구글링으로 필요한 정규표현식의 상당수는 얻어낼 수 있기 때문에 한번 공부해야지 하면서도 잘 안되게 되는 것 중 하나입니다.

그런 면에서 이 "손에 잡히는 정규표현식"은 딱 적당한 책입니다. 국내에는 정규표현식에 대한 책이 이책 외에 "정규표현식 완전 해부와 실습"이라는 책이 있습니다만 이 책은 600페이지나 되기 때문에 정규표현식의 도사가 될것도 아닌데 학습하기에 좀 부담스러운 면이 있는데 "손에 잡히는 정규표현식"은150여 페이지 정도로 " Regular Expressions in 10 minutes"라는 제목처럼 부담없는 책입니다. 제목처럼 10분안에 공부할 수는 없겠지만 좀 집중해서 보면 몇시간 정도면 다 볼만한 분량의 책입니다.

그럼에도 내용이 가볍지 않고 문자 찾기부터 시작해서 메타문자 사용하기, 반복찾기, 위치찾기, 하위표현식등 아주 기초적인 내용부터해서 일일이 예제를 보여주면서 설명하고 있으며 가끔 정규표현식을 쓰면서도 전혀 몰랐던 전방/후방 탐색이라든지 조건달기같은 고급까지 모두 설명해 주고 있습니다. 이 책에 나온대로 정규표현식에는 정답이 없고 문법을 알았고 설명이 명확해서 각 기능을 이해하는데 어렵지 않기 때문에 그 이상으로는 각자 연습하면서 익히면 충분할 것으로 보입니다.

부록으로 대표적인 정규식을 예시로 보여주고 있고(미국판이라 저희는 좀 필요없는 것들도 있지만요.) 언어별로의 정규표현식의 차이도 설명해 주고 있어서 정규표현식에 대해서 공부는 하고 싶지만 많은 노력을 들이는 것은 좀 부담스러운 사람들에게 딱 적당한 책인듯 합니다.

My Comment..
정규식을 알고는 있지만, 아니 안다라기보다 인지는 하고 있지만 쓰기시작한건 얼마 안된다.. 다른 곳보다 특히 비밀번호 정책에 적용할 때 정규식만한게 없는 듯하다.. 이리 돌리고 저리 돌리고 할 소스가 정규식 한줄로 끝나기 때문이다..[물론 그에 수반되는 코딩은 추가 될지언정.. 일반 코딩보다는 줄어든다..] 그런점에서는 햄 말대로 공부하긴 해야되지만, 대부분 naver 누님이나 google 에서 찾아서 약간식 변형을 해서 쓰게 되는듯하다.. ㅎㅎ..

[EP]자바 커뮤니티 공동 세미나 "자바 개발자를 위한 ‘共感(공감)’을 찾아서" #2..

출처 : Outsider's Dev Story https://blog.outsider.ne.kr/

앱스토어 효과 - 유주완(블로그)
World of devlopers의 시대가 왔습니다.
개발은 초등학생때부터 했으며 2009년 10월에 아이폰 출시가 가시화되면서 맥을 구입해서 개발을 시작했습니다. 언론에서는 엄청난 고민 끝에 나온 아이디어인 것처럼 나왔지만 실제로는 5분정도도 안걸렸다고 합니다. 그냥 밤에 누가 막차끝났다고 해서 1시간여의 거리를 걸어가던 중에 막차가 지나가버리는 경험도 있고 해서 누구나 할수 있는 쉬운생각으로 만들기 시작했다고 합니다. 10월 20일 서울버스 베타테스터를 모집해서 진행하고 11월 15일에 업로드를 시작했답니다. 인터페이스 빌더가 있었기 때문에 쉽게 개발을 하였다고 합니다. 11월 21일 사용하다가 초선검색의 부재를 인식하게 되고 22일날 kontacts를 만들어서 업로드를 합니다.

배운 점과 느낀 점은 혼자하기에는 다소 벅차고 가장 많이 올때는 하루에 60개정도까지 매일이 오기 때문에 읽고 처리하는데만도 하루가 다 간다고 합니다. 아이폰과 아이팟 터치라는 2개의 기기의 차이점이 있기 때문에 QA의 중요성을 느꼈으면 UX의 중요성도 깨닫게 되었답니다.

서울버스를 공개하고 경기도에서 무단 사용에 대한 연락이 와서 겁먹고 앱을 내렸으나 아버지께서 왜 내리냐고 하셔서 다시 올렸는데 실제로 내려간 시간은 30분 정도였고 그 뒤로는 다 아시는대로 경기도권에서 버스정보가 차단되면서 여론을 타게 되었습니다. 관련해서 국회토론회도 불려갔다 왔다더군요.

그 뒤에는 Q&A시간도 진행되었는데 오브벡티브C를 공부하면서 Seoul Bus를 개발하는데 한달정도가 걸렸답니다. 그 이전에 대부분의 언어는 거의 모두 사용해 보았기 때문에 시간이 그리 오래걸리지 않았으며 UX는 따로 연구하거나 하지는 않고 아이폰에 기본적으로 들어있는 어플들을 보면서 어떤식의 UX를 가지고 있는지를 보면서 만들었지 따로 UX를 기획하거나 하지는 않았답니다.

아이폰 앱인 "Seoul Bus"로 일약 스타로 떠오른 유주완님의 세션입니다. 어도비에서 특별세션을 준비하면서 어떤 분을 초청할까 고민하면서 여러군데에 물어보니 유주완님의 얘기를 듣고 싶다는 얘기가 가장 많아서 초청했다고 합니다. 대단하시더군요 어렸을때부터 개발을 해서 개발습득 능력은 확실히 뛰어나신것 같고(나이에 상관없이 이런점이 개발의 흥미로운 점이지요. ㅎ) 나이답지 않게(얼굴얘기아니고요 ㅎㅎ) 그 많은 사람들 앞에서 떨지않고 발표를 정말 잘하시더군요. 여러가지로 자극도 많이 받고 요즘 이슈되고 있는 주제중의 하나이기도 하기 때문에 상당히 흥미롭게 들었습니다.

뒷풀이도 같이 가서 전화번호도 땄(?)내요. ㅎㅎㅎ

아이폰에서 잘 보이는 모바일 웹 페이지 만들기 - OKJSP 허광남(블로그)
모바일 브라우저에 대해서는 아픈 기억들이 있습니다. 핸드폰에 있던 Show, June같은 버튼들은 돈이 많이 나가는 버튼이라는 이미지였습니다. 과거 모바일 유저가 400만 정도 된다는 얘기가 있었는데 그중에서 200만은 실수로 눌러서 들어간 유저라는 얘기가 있습니다. 이제 패킷요금은 현실화 되었습니다. 계산해보니 08년도에 1메가에 921원정도, 1기가의 94만 3천원정도였지만 2010년에는 1기가의 3만원 정도입니다.

모바일에는 현재 국내에 4가지 플랫폼이 있다고 할 수 있습니다.

• 아이폰/아이팟 터치
• 안드로이드
• 윈도우 모바일
• 모바일웹

최근에 알게된 PhoneGap도 있지만 여기서는 iUI (iPhone User Interface Framework)를 보겠습니다. 각자의 습득정도에 따라 차이가 있겠지만 아주 간단한 주소록을 앱으로는 2일이 걸린 것은 모바일앱으로는 1시간 정도밖에 걸리지 않았습니다. iui의 css와 javascript를 임포트하고 웹페이지 개발하듯이 개발하면 됩니다.

iUI는 매우 쉽고 또 웹페이지 제작시 사파리의 비표준 태그를 이용해서 키보드타이핑시 첫글자 자동대문자가 되지 않게 한다던지 input의 type에 tel, number, email등의 값을 넣어주면 자동으로 type에 맞는 키보드가 호출되도록 할 수 있습니다. 강의자료는 여기에 있습니다.

오랜만에 뵌 kenu님은 머리가 많이 기르셨더군요. 최근 모바일웹에 관심을 좀 가지고 있는데 여건상 거의 찾아보지는 못하고 있었는데 아주 디테일한 내용은 아니고 대략적인 내용이었지만 몰랐던 부분도 꽤 있어서 좋았습니다. 더군다나 모두가 앱에만 관심가지고 있는 상황에 저는 거의 앱과 모바일웹을 같은 비중으로 바라보고 있기 때문에 이런 주제를 다루주신 것도 좋았습니다. 앱을 개발하시느라고 모바일웹에 대해서는 아직 디테일하게 만지고 계신것 같지는 않았는데 앱에 비해서 모바일웹의 장점이라든지 디테일한 노하우가 좀더 공유되었으면 하는 아쉬움이 약간 있기도 했습니다.

Spring Roo와 함께하는 쾌속 웹개발 - KSUG 정상혁(블로그)
스프링 루는 벤 알렉스(Ben Alex)가 만들었으며(어제 날짜로 1.0.2가 릴리즈 되었군요.) 자바를 위한 Text Based RAD(Rapid Application Development) 툴입니다. Roo는 호주사람들이 좋아하는 캥거루를 의미하기도 하며 Real Object Oriented의 첫글자를 딴 것이기도 합니다. Spring, Maven, JUnit등을 바탕으로 코드를 자동생성합니다. 생산성을 빠르게 해준다던지 이것을 사용하면 개발속도가 빨라진다는 건 이제 오랫동안 사기(?)를 당해서 이젠 Rapid라고 해도 시큰둥한 것도 사실입니다. 하지만 Roo는 의존성이 거의 없는 특징도 가지고 있습니다.

발표를 하시면서 동시에 콘솔창을 띄워서 Ruby on Rails가 처음 나왔을 때 15분만에 블로그만들기처럼 간단한 주류판매페이지를 Roo로 개발하는 시연을 보여주셨습니다. 자바코딩을 하나도 안하는데 콘솔에서 Roo의 명령어만을 이용해서 자바소스를 생성하고 디비를 연결해서 테이블까지 생성하고 UI까지 만들어내는 예제였는데 Roo를 어필하기에는 아주 적합한 예제였다고 생각합니다.

Roo를 사용할 때는 Hint와 Help만을 기억하면 됩니다. 명령어가 생각안날때는 tab을 2번 누르면 어떤 명령어가 있는지가 나오고 지금 어떤 단계를 실행해야 하는지에 대해서 아주 자세하게 나옵니다.(이거 아주 매력적이더군요.) ~는 탑레벨을 의미하고 셀레니움테스트까지 자동화에 포함되어있어서 자동으로 파이어폭스가 실행되면서 UI테스트가 진행되는 시연도 보여주셨습니다. 이렇게 만든 소스를 마지막에 perform eclipse 명령어를 실행하면 이클립스 프로젝트로 개발하기 위한 관련 파일들을 자동으로 생성해 주었습니다.

똑똑한 Shell을 제공하고 있기 때문에 개발하기가 편하며 모든 명령수행은 Transactional하기 때문에 전체가 실행되거나 말거나 뿐입니다. 자동생성된 파일에서 개발자는 .java와 .xml파일만을 다루도록 하고 Roo는 AspectJ파일인 .aj만 다루기 때문에 개발자는 java, xml만 신경쓰면 됩니다. 쉘이 파일을 모니터링하고 있어서 소스를 수정하면 자동으로 aj에 반영해주고 한계가 약간 있을수 있는 UI자동생성은 옵션으로 제공되고 있습니다.

Entity소스상에 getter/setter가 전혀 없으며 이는 Mixin으로 Roo가 자동삽입해 줍니다. 이렇게 뻔한 것은 개발자가 안해도 된다는 것이고 Assert로직도 Mixin으로 넣어줍니다. Shell에서 backup을 입력하면 자동으로 시간기록된 파일로 백업을 해주고 Roo Shell에서 입력한 명령어가 자동으로 Log파일에 남게되고 이 파일을 이용해서 다시 프로젝트를 생성시킬 수 있습니다.

Spring Roo는 Full Stack으로 모든 레이어의 기술을 다 제공하며 Seam이나 Ruby on Rails처럼 강한 주장을 가지고 있는 프레임웍이며 베스트 프렉티스를 컨벤션으로 삼아서 CoC를 지향합니다. DAO를 버리고 Entity와 Controller의 단순한 2단구조이며 엑티브 레코드 패턴도 적용하였습니다. ORM에 대해서 성능에 대한 걱정들이 있지만 현재 생성성이라는 말이 들어가는 많은 곳에서 ORM이 적용되고 있으며 여러가지 기술로 성능에 대한 걱정은 하지 않아도 됩니다.

최근에 많은 인기를 얻고 있는 Dynamic typing언어 진영의 발전에 대하 Java진영의 대답으로 볼 수 있습니다.

발표자료는 여기에 있습니다.

이번 세미나에서 본 내용중 가장 인상적이 세션이었습니다. Spring Roo에 대해서 들은 적은 있었지만 정상혁님 말씀대로 RAD에 대해서 크게 매력을 느껴지지 않을만큼 무뎌지기도 했고 그래서 큰 관심까지는 안가지고 있었는데(난 기초를 더 다져야돼 하는 생각도 있었고요.) 작년 후반기 쯤에 0.9얘기를 들었던 것 같은데 그사이에 Spring Roo가 이렇게 그럴듯한 도구로 발전했는지 전혀 몰랐습니다.

제가 가장 매력적으로 느낀 것은 대부분의 RAD들은(경혐은 별로 없지만 그냥 인상으로만...) 속도의 향상을 위해서 많은 것을 따라야 하는 부분이 있기에 당연히 감수해야하는 제한적 부분도 있는데 Roo는 자동화할 부분을 자동화하는 것과 함께 개발자가 개발할 수 있는 것들은 개발자가 할 수 있게 내어준 것 같은 느낌입니다. 세세한 것은 만져봐야 알겠지만 Roo의 자동화를 잘 활용하면 Java개발을 상당히 편리하게 할 수 있을것 같은 생각이 들었습니다. arawn도 요즘 Roo에 빠져서 조만간 Roo공부를 좀 해야겠군요.(전 Spring도 잘 모르는데요 ㅠ..ㅠ)

신청은 했지만 많은 기대감을 가지고 갔던 세미나는 아니었지만 아주 많은 것을 얻어올 수 있었던 세미나였습니다. 너무 테크니컬하지도 않으면서 너무 추상적이지도 않은 아주 적절한 세션들로 구성되어 있었던것 같습니다. 이날은 뒷풀이도 5시간가까이 진행되면서 많은 생각도 하게 된 날이었습니다.

뒷풀이에 정말 많은 얘기들이 오갔지만 가장 맘에 남는 말은 "개발자가 너무 개발자끼리만 어울리는 것은 좋지 않은것 같다. 개발외에 많은 것을 봐야한다."는 것이었습니다. 개인적으로 노력도 하고 있고 적극 동감은 하고 있지만 개발쪽은 공부해야할께 너무나도 많다는 말이지요 ㅠ..ㅠ

[EP]자바 커뮤니티 공동 세미나 "자바 개발자를 위한 ‘共感(공감)’을 찾아서" #1..

출처 : Outsider's Dev Story https://blog.outsider.ne.kr/

Adobe에서 진행한 "자바 개발자를 위한 ‘共感(공감)’을 찾아서"세미나에 갔다가 왔습니다. 세미나 주제들이 괜찮아 보여서 바로 신청하기는 했었지만 약간은 의외의 컨셉의 세미나였습니다. 이번행사는 OKJSP, JBoss User Group, KSUG가 공동주최하고 Adobe에서 후원하였는데 처음 세미나 공지를 보았을때 "왜? 어도비가 자바세미나를?"이라는 생각이 들더군요. BlazeDS때문인가 싶기도 했는데 딱히 그런 언급은 없었습니다. 머 의도야 어쨌든 이렇게 좋은 세미나를 무료로 진행해 주니 감사한 마음에 갔다가 왔습니다.

자바와 Flex의 만남 - Adobe Community Champion 엄진영(블로그)
부재로는 "스프링과 연동한 BlazeDS 활용"이라는 이름이 붙어 있었습니다만 실제로는 Blaze에 대한 언급은 거의 없었습니다. 개발의 기술발전의 히스토리들(주로는 엄진영님이 접하게 된 시점위주로)을 설명하면서 RIA가 플래시가 왜 필요한가에 내용이었습니다.

Flex는 이제 Flash라는 이름으로 통일이 되고 있습니다. 그동안은 Flex라는 개념의 혼동때문에 Flash와 Flex의구분을 고객들에게 설명하기 위해서 어려움들이 있었지만 이젠 모두 Flash로 통일되고 있고 Flex builder도 Flash Builder 4로 변경이 되었습니다. 서버사이드는 보통 자바가 많이 쓰이고 기술과 트랜드는 계속 바뀌고 있습니다. 과거 프로그램을 자주 변경해야 되는 상황이 생기면서 그동안 사용하던 C언어보다는 스크립트 언어를 선호하게 되었지만 곧 만들어야 하는 프로그램의 크기가 커지면서 스크립트 언어로써의 한계에 부딪히게 됩니다. 스펙을 정해놓고 사용하게 되는 엔터프라이즈로 넘어가게 되었는데 실제 개발은 서버보다는 UI를 많드는데 훨씬 많은 시간이 소비되게 되었습니다.

그래서 프로세스의 혁신이 필요해지게 됩니다. 프로세스의 혁신이란 것은 야근등으로 개발자의 능력치를 최대한 끌어냈으나(엄진영님은 "이미 쪽쪽 빨아서"라고 표현을ㅎㅎ) 더이상 끌어낼수 없을때 필요해 지는 것입니다. 초보개발자도(싸니까) 만들수 없을까? 하는 고민을 하면서 프레임워크로 초점이 넘어가고 그후에는 퍼시스턴스에 관심을 가지게 됩니다. 2007년부터 UI에 대한 고민을 시작하게 되고 그전에는 브라우저전쟁에서 승리한 IE에 맞춰서 개발하다가 브라우져마다 약간씩 다르기 때문에 다른 브라우저에 맞추는 추가적인 작업을 하게 됩니다. 국내시장에서는 깔끔하게 IE외의 브라우져는 포기해버렸습니다.

이 상황에 Ajax도 등장하여 서버에 직접 접근하게 되고 엔터프라이즈급 UI를 Javascript만으로 하는 것이 개발자에게 너무 힘든 일이 되어버립니다. 그래서 Needs에 따라 쓰는 방식은 그대로 유지하면서 Flash를 위한 Flex가 등장하게 됩니다.

RIA의 장점은 플랫폼이 독립적이고(자바도 목적은 그랬지만 현실적으로 그러지 못했습니다.) 기존 기술과 유사하여 배우기가 용이하면서 대규모 시스템 개발이 가능하다는 것이었습니다. 그리고 가장 중요한 것은 UI부분이 서버와 투명하게 분리가 가능하게 된 것이었습니다. Ajax덕분에 클라이언트가 서버에 직접 접속하게 되면서 서버에 종속적으로 묶여버렸습니다. 플래시앱(.swf)는 서버와 HTTP 원격객체호출을 할수 있고 HTTP 서비스, 메시징 서비스, 웹서비스를 할수 있으며 Ajax에 비해 binary 데이터를 주고 받을 수 있다는 큰 장점도 있습니다.

히스토리야 어느정도 알고 있는 내용이니 공감은 하고 있었지만 Flash Platform에 대한 당위성에 대한 공감은 좀 약하지 않았나 싶습니다. 여러 연구들과 프레임워크들의 등장으로 인하여 UI가 서버에 종속된다는 것은 공감이 잘 안되기도 했고 (기술적이든 사용상의 문제이든 간에)실제 플래시를 사용하는데에 대한 trade off가 존재하는 것은 사실이라고 생각하고 있습니다. Flash가 등장한 이래 가장 큰 위기감을 최근 느끼고 있다고 생각하는데 Flash가 통짜로 올라가면 화려하긴 진짜 화려하긴 하지만 무겁기도 하고 그렇게 화려할 필요가 있는가에 대한 고민도 하게 되죠.

Apache Hadoop으로 구현하는 상품추천서비스 - JBoss User Group 김병곤
추천검색은 은근히 여기저기 많이 쓰이고 있습니다. 메론, Amazon, 네이버 인물 검색등 알게 모르게 추천검색이 다 적용되어 있습니다. 실제로 추천검색을 적용해 보면 30%정도가 구입을 하는데 이는 엄청난 적중률입니다. 추천시스템을 구현하는 방법에는 사용자로부터 얻은 기호정보를 토대로 예측하는 협업필터링(Collaborating Filtering), 상품간의 연관성을 분석하여 다른 사용자에게 구매하지 않은 상품을 추천하는 연관규칙(Association Rule), 비슷한 대상들끼리 묶은 군집을 이용하는 클러스터링(Clustering)등이 있습니다. 

웹2.0의 많은 서비스들이 추천시스템을 사용하고 있고 우리가 하는 모든 행동은 로그가 남고 있고 우리는 엄청난 데이터 속에서 살고 있으며 이 엄청난 데이터는 Hadoop이 아니면 다룰 수가 없습니다. 데이터가 너무 엄청나기 때문에 데이터베이스로 다룰려면 데이터를 데이터베이스롤 올리는데 시간이 다 가버릴 정도입니다.

패러다임의 전환이 필요합니다.

로직이 데이터에 접근하지 말고 데이터가 있는 곳으로 로직을 옮겨라!

데이터가 쪼개지고 로직도 각 데이터로 분산된 다음에 합칩니다.

왜 데이터베이스가 적합하지 않은가 하면 대용량 파일은 Import하는 것도 어렵고 리소스소비가 심하여 온라인 작업과 배치작업을 분리해야 하는 문제가 있습니다. 그리고 비싼 장비와 SW비용이 필요합니다. 대신 대용량에 Apache Hadoop가 적합한 이유는 로그정보가 수십Tera에 이를 정도로 매우 크고 I/O집중적이면서 CPU도 많이 사용하는 작업입니다. 또한 장비를 증가시킬수록 성능은 향상되고 Intel Core머신은 가격이 아주 쌉니다. 인텔컴퓨터 하나 사서 추가하면 용량이 늘어나기 때문에 개발자는 관리가 힘들어지더라도 운영자입장에서는 당연히 하둡을 선택하게 됩니다. 이런 것을 보면서 이제 데이터베이스는 사라지는 것이 아니냐고도 하는데 Hadoop은 데이터베이스를 대체할 기술이 아니라 공존할 기술입니다.

Hadoop은 "파일을 올리는 것"과 "처리하는 것" 딱 이 2가지가 전부입니다. 즉 File System(HDFS:Hadoop Distributed File System)과 프로그래밍모델(MapReduce)입니다. HDFS는 파일을 64M단위로 나누어 장비에 저장하는 방식이고 사용자에게는 하나의 파일로 보이지만 실제로는 나누어져 있습니다. MapReduce는 HDFS의 파일을 이용하여 처리하는 방법을 제공합니다.

나누어서 처리할 때의 가장 큰 문제는 합치는 것이고 대표적인 것이 소팅입니다. 맵과 리듀스의 개념을 이해하는 것이 코딩보다도 더 중요합니다. Hadoop은 무조건 Key - Value의 데이터 구조 이 한가지 밖에 없습니다. 이 Key - Value로 된 데이터들이 합쳐지면서 같은 Key의 Value는 배열로 묶어줍니다.

연관 규칙(Association Rule)의 예로 간단한 마켓의 상품으로 추천시스템을 적용하는 예를 보여주셨습니다. 연관규칙에는 트랜잭션, 지지도, 신뢰도, 향상도가 있습니다.(이건 좀 통계적인 개념) 몇개의 상품별로 각 값들을 계산하고 이를 Hadoop으로 어떻게 Map과 Reduce가 진행되는 지에 대한 보여주었습니다. 추천시스템의 상품조합은 많으질수록 성능이 급격히 저하되므로 보통 2개의 조합만 사용하며 이 예에서는 맵과 리듀스를 단 2번만 실행하였는데 Hadoop에 대한 개념은 다 들어가 있으면서 한눈에 이해될 정도의 간단한 예제였습니다.

그럼 Hadoop는 언제 써야 하는가 하면 통계에 아주 좋습니다. 또한 데이터에서 필요없는 부분을 제거하는 ETL(Extract, Transform, Load)이나 데이터 마이닝, 로그파일분석, 인공지능에 적용하기가 좋습니다. 하지만 Hadoop은 무식한 배치성 작업이 아주 강하고 인터렉티브하지 않기 때문에 최종적으로는 RDBMS가 필요합니다. Hadoop으로 추출된 최종데이터만 RDBMS로 올리면 됩니다. 이전에는 이것을 디비가 했지만 이제는 개발자가 해야하는 시대가 되었습니다.

처음에 시작할때 초등학생도 이해할 수 있는 수준이라고 말씀하셨는데 사실 Hadoop은 개념이 약간 어려워서 그닥 믿지 않았는데 진짜 여태들은 설명중 최고로 명쾌한 설명이었습니다. 어떻게 하둡을 이렇게 간결하게 설명할 수 있을까 하는 생각이 들 정도였습니다. Hadoop에 대해서 급 관심이 갔으며 막상하면 여러가지 어려움이 있겠지만 오히려 너무 쉽게 설명을 해주셔서 해보면 금방 하겠는데 하는 착각(?)이 들 정도였습니다. ㅎㅎㅎ Hadoop을 어느정도 이해한 것만으로도 아주 큰 수확중의 하나라고 할 수 있겠네요.

[JS]undefined는 Reserved Word가 아닙니다..

출처 : Outsider's Dev Story https://blog.outsider.ne.kr/

요즘 봄싹스터디에서 더글라스 크락포드의 자바스크립트 핵심가이드로 Javascript를 공부중에 있는데 2장의 명명규칙을 설명하던 중 예약어(Reserved Word)를 표시해준 아래에 아래와 같은 말이 써 있었습니다.

이 목록에는 예약어에 꼭 포함할 것 같은 undefined, NaN, Infinity 등은 없습니다.

이 3개가 Reserved Word가 아니라는군요. 스터디에서 여러가지 테스트를 좀 했었지만 궁금해서 좀 더 찾아봤습니다. 일단 가장 확실한 현재 Javascript의 스펙인 ECMA-262를 보았습니다. ECMA-262에는 Identifier로 사용될 수 없는 Reserved Word가  Keyword, Future Reserved Word, NullLiteral, BooleanLiteral 4가지 종류로 정의되어 있습니다. 아래가 그 목록입니다.

Keyword
break    case    catch    continue    debugger    default    delete    do    else    finaly    for    function    if    in    instanceof    new    return    switch    this    throw    try    typeof    var    void    while    with

Future Reserved Word
class    enum    extends    super    const    export    import implements    interface    let    package    private    protected    public    static    yield

NullLiteral
null

BooleanLiteral
true     false

정말 undefined, NaN, Infinity는 없군요.

JavaScript

1 2 3

if (undefined) { console.log("Can't you see this message?"); // don't print }

민망한 소스입니다. ㅋㅋ 당연히 저 메시지는 찍히지 않습니다.

JavaScript

1 2 3 4

var undefined = true; if (undefined) { console.log("Can't you see this message?"); // it's printed }

이렇게 바꿔봤습니다. undefined라는 변수를 만들어서 true로 설정해 주었습니다. 당황스럽게도 이 메시지는 찍힙니다. ㅡ..ㅡ 간단한 테스트로는 FF3.6, Chrome 4, IE8에서 모두 동일한 결과가 나타납니다. undefined가 Reserved Word가 아닌 이유가 궁금할 정도로 당혹스러운 결과입니다. 이것은 temp == undefined 같은 비교가 소스에 있을 경우 전역변수로 undefined를 다른 값으로 정의해 버리면 전체 코드를 깨뜨려 버릴수 있다는 말과 동일합니다.

물론 undefined를 변수명으로 쓸 사람이 있겠냐 싶기는 합니다만 가능하기 때문에 꼭 없다고 할 수만도 없을 일이지요. 여러사람이 작성한 코드에서 누가 undefined를 재정의한다면 디버깅한다는게 정말 끔찍하네요. 좀 더 자세한 내용을 찾아보려고 검색해봤더니 해당 내용에 대해서 정확히 짚어낸 "undefined is not a reserved word"라는 글을 찾을 수 있었습니다. 위 블로그에서 Ash는 비교할때 undefined를 사용하지 말라고 권하고 있습니다. row == undefined같은 형태로 비교하지 말고 row == null로 비교할 것을 권하고 있으며 ==비교에서는 null과 undefined가 완전히 동일하게 취급하기 때문에 Reserved Word인 null을 권하고 있는 것입니다.(타입까지 비교하는 ===에서는 당연히 같지 않습니다.)

댓글을 통해서 Tim Down라는 사람과 위 문제에 대해서 좀 얘기가 있었는데 Ash가 null을 쓰라는 것은 다음과 같은 이유입니다.

1. 코딩할때 교과서적인 권장사항에서 if문의 비교에서 리터럴을 왼쪽에 쓰라는 것이 있습니다. (index == 3) 대신에 (3 == index)로 쓰라는 것이지요.(알지만 잘 안되는 것중 하나입니다.) 이 것은 실수로 ==를 =로 했을때 후자로 작성하면 Syntax오류가 나타나고 전자는 무조건 True로 떨어지지 때문입니다. 이 권장사항을 따랐을때 (undefined == index) 라고 작성하였을 때 실수로 ==대신 =를 작성한다면 undefined의 값을 변경해 버리는 실수를 해버릴 여지가 있다는 것입니다.(고의로 undefined를 재정의할 가능성보다는 이 경우가 훨씬 가능성 있어보이는군요.)
2. 자신이 보기엔 null이 더 논리적으로 보이고 undefined가 수행하는 것을 모두 수행할수 있답니다.
3. Function의 파라미터가 넘어왔는지를 검사할 용도에서는 undefined를 넘길 수도 있기 때문에 파라미터 검사용도로 undefined를 사용하는 것은 좋지 않습니다.

그래도 그냥 생각해도 그렇듯이 흔치는 않은 경우로 생각되므로 크리티컬한 이슈가 안되었는지 검색해도 많은 내용은 나오지 않았습니다. 대부분의 경우에는 undefined의 사용으로 문제가 없다고 봐도 무방하긴 하지만 알면서도 같은 결과라면 null비교를 사용하는 것이 더 나아보이는군요.

[DEV]HTML5, Flash에 대한 생각들..

출처 : Outsider's Dev Story https://blog.outsider.ne.kr/

요몇일사이에 블로고스피어에 HTML5 얘기가 들끓고 있습니다. 이 일의 발단은 Apple의 Steve Jobs의 발언때문입니다. iPhone과 iPad에 Flash가 안들어간 것에 대한 질문에 대답하면서 잡스옹이 "Adobe is Lazy"라며 강력하게 비판을 했습니다.(그외 Google에 대해서도 쓴소리를 했죠.)  Adobe가 게을러서 Flash가 엉망이라 애플은 Flash를 받아들이지 않을 것이며 HTML5가 그 대안이 될 것이라고 하였습니다.


Flash 이야기
저는 플래시를 별로 좋아하지는 않습니다. 개인적인 취향이긴 합니다만 실용성보다는 화려함에 더 치중된 UI에 그다지 매력을 느끼지 못하는데 사실 이미지를 많이 쓴 것도 좋아하지 않는 편입니다. 배경으로만 깔고 Text를 이용해서 CSS로 표현하는 것이 최고지요! 개발자의 감성(?)이랄까요. 플래시를 좋아하지 않는 이유는 일단 좀 무겁기도 하고 쓸데없이 애니메이션이 많이 들어가서 메뉴를 접근할때 꽤나 귀찮게 하기 때문입니다. 그리고 플래시에 대해서는 자세히 몰라서 정확히 말하기 어렵지만 웹접근성이 아주 안좋다고 생각하고 있습니다. 웹접근성을 가지게 만들수 있는데 일반적으로 그렇게 하지 않은 플래시들이 많아서 인지는 모르겠지만 플래시가 없으면 웹접근성이 현저히 떨어집니다.(아이폰이 대표적이죠.)

한때 플래시를 크로스브라우징의 대안으로 생각했던 적도 있었습니다. 꽤나 아름다운 UI를 제공할 수 있으면서 JS와 CSS를 이용해서 크로스브라우징을 위한 삽질을 수없이 하다가 보면 그 피곤함에 크로스브라우징이 웹개발의 발전에 커다란 방해가 되고 있다는 생각이 들게되고 모든 웹브라우저와 플랫폼에서 동일하게 돌아갈 수 있는 플래시가 앞으로 더 이점이 클수도 있겠다 하는 생각이었습니다. 크로스브라우징을 맞추는 것은 아직도 피곤한 일이지만 이제는 웹표준쪽에 더 기대를 하고 있기 때문에 이런 생각은 어느정도 접었습니다.

물론 기술이 나쁜 기술은 거의 없다고 생각하는 편입니다. 운이 없어서 주목을 못 받고 잊혀지던가 아니면 쓰는 행태가 나쁜것이지요. 사실 머 동작자체만 보면 ActiveX나 Flash나 거기서 거기입니다. 런타임위에서 돌아가는 브라우져바깥의 기술을 이용해서 브라우져에서 하지 못하는 추가적인 기능을 구현하는 것이지요. 작은 차이는 아니지만 ActiveX와는 다르게 비Windows플랫폼에서도 동작가능하다는 점과 플래시만 깔면 추가적으로 사이트마다 깔아주진 않아도 된다는 점 정도인데 사실 이런 문제 보다는 온갖 ActiveX로 사이트를 떡칠해놔서 ActiveX아니면 아예 못하게 해놓고 이젠 어쩌지도 못하는 된 사용행태가 더 나쁘다고 할 수 있습니다. 사실 웹사이트의 이런 저런 요구사항에서 플래시가 할 수 있는 영역에 대한 것을 무시할 수는 없습니다.

하지만 우리들의 위대하신 갑들께서는 항상 웹의 샌드박스를 띄어넘는 자원을 사용하기를 원하시는데다가 수년간의 ActiveX로 배운 UX로 인하여 사용자의 로컬자원을 맘대로 사용하는 것을 아주 자연스럽게 생각하시는 덕분에 "웹표준을 하면 유지비용도 줄고 더 빨리 많들수 있고 접근성도 향상하고 렌더링도 빨라지면서 다양한 브라우저에서 접근성이 어쩌고 저쩌고.... 하지만 기존처럼 로컬파일 드래그앤드롭하던지 캡쳐화면 찍어서 내려주던지 하는 것 같은 것은 더이상 지원할 수 없습니다. 이게 웹의 본연의 기능이에요."라고 하는 말은 씨알도 안먹히는 상황이 되었다고 할 수 있습니다.  그런 상황에서 웹의 기본적인 샌드박스를 뛰어넘을 수 있는건 사실 Flash밖에 없었기에 Flash의 성장은 당연하다고 할 수 있습니다. (지금은 Silverlight나 JavaFX도 있긴 합니만 Flash얘기를 하는 중이었고 가장 많은 장악력을 가지고 있어서 플래시만 언급했습니다. 다른 개발자분들은 섭섭해 하지 마시길... ㅎ)


HTML5 이야기
여기에 최근 새로운 흐름이 가세합니다. HTML5와 CSS3가 그 주인공인데 지금 사용하고 있는 HTML 4와 XHTML의 다음 버전이라고 할 수 있습니다. 기존의 XHTML의 다음버전으로 만들던 XHTML 2는 중지되고 모든 자원이 HTML5로 모아지게 되었습니다. 현재 HTML5는 working draft중이고 사실 표준확정도 되지 않은 상태입니다. 현재의 웹표준까지의 엔드유저까지의 도입도 험난했기 때문에 2020년이나 되어야 적용하게 될 기술로 생각하고 있었습니다. (webmonkey에서도 비슷한 얘기가 있었던 걸 보면 저만 그런것 같지는 않습니다.)

그냥 그렇게 생각하고 있었는데 HTML5가 급속도로 눈앞으로 다가왔습니다. 그동안 너무 오래된 HTML 4를 가지고 하기에 너무 지쳤던 것인지 웹개발자들이 적극적으로 HTML5도입에 나섰습니다. HTML과 CSS만 가지고 어떤 것을 할 수 있는지 열심히 만들어서 보급하기 시작했는데 생각보다 그 속도가 빨랐고 올해 넘어오면서부터는 대표적인 웹2.0서비스들이 베타이긴 하더라도 HTML5를 적극적으로 서비스의 도입하기 시작했습니다. 이부분은 현재 HTML5를 지원하고 있는 Safari와 Chrome의 몫도 크다고 할 수 있겠습니다.(정확히는 Webkit이겠지요.)

CSS3만으로 애니메이션을 만들고(Matrix, Pulse) 로컬파일을 Drag&Drop하고 동영상플레이어를 만드는 등 아직다 확정되지도 않았는데 많은 가능성들을 보여주고 있습니다. 차후에는 WebSocket도 도입되면 진정한 리얼타임도 등장하리라고 생각합니다. 그동안 한계를 가진 개발자들만 좋아하는 웹표준에 비해서 이젠 진짜 괜찮은 새로운 웹표준이 오고 있는 것입니다. 지금 생각으로는 3~5년이내에 실제 서비스에 써먹을 수 있겠다 싶습니다.


아이폰 이야기
이제서야 아이폰 얘기를 다시 꺼내는군요. 새롭게 등장한 HTML5와 기존의 강자의 역할이었던 Flash와의 싸움은 꽤 오래 끌고 갈것이라고 생각하고 있었는데 세계를 강타해버린 아이폰이 플래시를 버린 덕분(?)에 의외로 HTML5에 힘이 크게 실리고 있는 느낌입니다. 항상 세미나 가면 전세계 PC에 99프로정도 설치되어 있다고 자랑하던 Adobe였는데(플랫폼장악력에서 엄청나다고 할 수 있죠.) 아이폰이 플래시를 거부한 덕에 모바일시장에서는 맥을 못추고 있는데다가 스마트폰에서 엄청난 퍼센티지를 자랑하는 아이폰덕에 모바일용 사이트들도 플래시 사용을 꺼리고 있기 때문에 급격히 힘을 잃어가는 듯한 느낌입니다. 엄청난 몸값과 장미빛 미래를 가지고 있던 플래시개발자들도 아직은 판단은 이르지만 애플이라는 하나의 회사덕에 좀 뿌옇게 된 분위기입니다.

Image by oskay via Flickr

플래시개발자들에게는 죄송하지만 저는 이 분위기를 상당히 반기고 있습니다. 왜냐하면 그동안 웹접근성이나 웹표준은 거들떠도 안보던 갑들께서(SI의 갑만 갑은 아니지요.) 탐나는 모바일시장에는 진출하고 싶다보니 자연스럽게 웹표준이나 HTML5에 신경을 쓰는 분위기가 되었다는 거죠. 이건 비단 플래시만의 문제는 아니지만 기존의 IE용으로만 만들어놓은 사이트들이 모바일에서 보니 엉망인 경우가 많으니까 어쩔수 없이 받아들이게 된 현실인거지요. 사실 원래 잘 만들어놨으면 아주 간단히 해결할 수 있을 문제였고 원래 사이트를 손대기 어려우니 대부분은 그냥 모바일용 별도구축으로 방향을 잡고 있는듯 하지만 어찌되었든 상당히 반길만한 분위기라고 생각합니다.


Epilogue
사실 애플이 플래시를 거부한 것은 아름다운 웹표준을 위해서라거나 더 좋은 HTML5를 위해서라기 보다는 밥그릇 싸움때문이라는 인상이 더 강합니다. 그렇지 않다면 사용자에게 선택권을 주면서 HTML5를 더 강력히 지지하면 될 일이지요. 이유야 어찌되었든 여태까지는 이런 애플의 행보가 웹개발자로써는 반길만한 상황으로 이끌고 있는 듯 합니다.(이 상황과는 다르게 Video코덱으로 H.264가 아닌 파이어폭스와 오페라가 지지하는 OGG Theora를 지지합니다.)

아직 워킹드래프트상태임에도 HTML5가 보여주고 있는 미래는 아주 강력하다 못해 아름다울 정도입니다. 더 늦기전에 올해부터는 HTML5와 CSS3를 본격적으로 맘먹고 공부하면서 준비해야 할 듯 합니다. 아직도 W3C내에서 만은 논쟁이 일어나고 있는데 서로 밥그릇싸움 하지 않고 가장 범용적인 형태로 좋은 Final 스펙이 나오기를 바랄 뿐입니다. 앞으로 찬찬히 두고 봐야죠.

트위터에서(누군지는 영 생각이 안나네요.) 클라이언트사이드쪽 구루들이 얘기했던 대화가 생각납니다.
A: I like HTML5.
B: @A who doesn't.
누군들 않좋아하겠습니까? ^^



HTML 관련 읽을만한 글들
HTML5가 개발자에게 ‘기회의 땅’인 이유
HTML5의 모든 것
HTML5 video and H.264 ? what history tells us and why we’re standing with the web


ps. 몇일 지났다고 생각했는데 글을 쓰고 나서도 블로고 스피어에 스티브 잡스의 이번 발언에 대한 많은 얘기들이 나오고 있었습니다. 그런 글을 읽다가 약간 제가 작성한 글의 오해의 여지가 있는것 같아 추가글을 남깁니다.

제가 언급한 부분은 웹표준이 현실에 크게 반영되지 못하던 상황에서 이유야 어찌되었던 HTML5로의 전환이 급속도로 전환되는 상황에 대한 반가움에 대한 내용을 적은 것이지 플래시는 사라져야 하는 기술이라는 의미는 아니었습니다. 최종적으로는 이런 부분은 사용자 혹은 중간에서 기술(웹이나 앱이나)을 제공하는 곳에서 선택적으로 할 일이지 벤더가 차단할 문제는 아니라고 생각합니다. HTML5의 시대가 도래하더라도 HTML5이상의 요구사항이 당연히 필요해질 것입니다. W3C가 표준이지만 표준인만큼 발전은 느린점이 있기 때문에 모든 요구사항을 받아들여질 수 없기에 차후 플래시든 어떤 기술이든 필요해질 것은 당연한 수순이라고 생각합니다.

어떤 기술이냐보다 어떻게 쓰느냐가 더 중요하겠지요. ㅎ

My Comment..
해당 글엔 대한 논란이 생기거나 그런 시점은 이미 한참 지났다.. 글 자체가 2010년 글이기 때문이기도 한데.. 보통 글을 가져올 때 시대적으로 지난 글을 가져올 때는 거의 대부분 이러한 코멘트를 달게 되는 듯 하다.. HTML5 다 Flash 다 하는 논쟁이 최고조에 달하기 시작했을 때의 글인듯하다.. 스티프잡스가 현존하지는 않지만..[아까운 인재인듯한 생각이..] 물론 난 저 때의 분위기를 모른다.. 기술에 관심도 없었기 때문에.. 하지만, 이러한 논쟁이 있었고 이러한 부분들이 그 시대에 논쟁거리였다는 것을 조금이라도 알기 위해서 가져왔다.. 난 머했나 싶은.. 자책 아닌 자책도 하면서 말이지..

[Talk]문득 생각이 나는 것이 있어서 적어본다..

흠.. [Talk] 라고 해서 내 글을 적은지는 좀 오래 된 듯 하군.. 무작정 주절주절 적으려고 한다면, 더 많은 수가 있었을지도 모르겠다.. 하지만, 그래도 이왕이면, 개발에 대한 내용을 적으려고 노력 하는데 그러다보니 자유 수다를 올리는 횟수는 자연스럽게 줄어든 듯 하기도 하다.. [기술적인 부분이 아니더라도 개발에 관련된 내용으로 적으려고노력 중이다..ㅎㅎ]

오늘은 일을 하다가 문득 생각이 나서 적어본다.. 몇 번 언급했었지만, 난 지금 SM[System Maintanance, System Management] 업무를 하고 있다.. 그러다보니 당연히 소스 수정이 좀 빈번하게 일어난다.. 물론 개발도 있긴 하지만, 수정도 그만큼 많이 있다.. 크게 수정도 하고, 작게 수정도하고, Text 단순 바꾸기도 하고 말이다..

그런데 SVN 에서 어떤 소스를 보는데 과거에 내가 바꾼 소스 중 똑같은 위치를 다른 사람이 바꿨더라.. 머 내거를 바꾼게 문제는 아닌데.. 난 보통 소스를 수정하면, 소소하게 수정할 때는 소스 끝에.. 좀 크게 수정할 때는 진입부에 "//20160310 수정.." 또는 "//20160310 추가.." 라고 명시를 한다.. 만약 로직에 대한 설명 내지는 해당 로직을 바꾸게 된 사유가 필요하면, "해당 소스는 누구누구의 요청으로 이 부분을 더 추가함.." 머 이렇게 말이다..

하지만, 가만히 생각해보면 같은 프로젝트 상의 소스를 4~5명이 같이 붙어서 작업을 하게 되는데 나 말고는 대부분 주석을 안달고 있단 말이지.. 내가 구태여 내가 수정을 했다고 알려줘야 되는건가 싶은 생각이 문득 든다..

과거 개발이란 것을 처음 접할 때부터 소스에는 주석이 많아야지만, 추후 관리가 편하고, 다음 사람에게 인수인계 및 누군가 내 소스를 가지고 유지보수를 하려면 손쉽게 가능하다고 들어왔기에 지금 껏 그래오고 있긴하지만 왠지 그만할까 싶은 생각이 든다..

지금 하는 말은 괜한 내 생각일지도 모르지만, 내가 내 소스를 봐도.. 몇 개월 내지는 몇 년 지난 소스들.. 그런거 보고 있으면, 내가 왜 저렇게 했지?? 내가 한거 맞나?? 주석과 코딩 스타일을 보면 내것이 맞는데도 그런 생각이 든다 ㅡㅡ..

하물며 내가 그런 생각을 하는데 나름 개발을 잘하는 혹은 신입중에 잘하는 사람이 내 소스를 보면, "이 사람은 개발을 오래했다는 사람이.. 나이도 좀 있는 사람이.. 이렇게 개발을 하냐;;" 라는 말을 하는게 아닐까 하는 생각이 들었다.. 아흠 머가 맞는 것인지 모르겠다..

날짜는 빼고, 로직에 대한 수정사항이 있는것에 대해서만 설명을 할까 싶기도 하고, 무엇이 정답인지.. 거참.. 나름 2007년 부터 IT에 발을 들였으니 9년차정도 되는데 뒤늦게 너무 쓰잘데기 없는 고민, 생각을 하는건가..;;;; 악!!! 괜시리 머리만 아펏.. 당분간 로직에 대한 설명만 적어봐야겠다.. 내가 이해하고 코딩한것을 써머리 형식으로 정리한다고 생각하고..