[JSP]JSTL 비교 연산자..

뜻하지 않게 업무가 바뻐졌다.. 모바일쪽은 원래 하던 일도 아닌데 모바일 웹도 개발 범위로 넘어왔다.. 그나마 App 이 아니라서 다행이라는 생각도 들긴한다..

오랫만에 내 포스팅인데 JSTL[자바서버 페이지 표준 태그 라이브러리(JavaServer Pages Standard Tag Library, 약칭 JSTL)]의 비교연산자를 간단히 정리 하려고 한다..

JSTL 테그를 그렇게 많이 안쓰기도 하고, 대부분 if ~ else, for 에 해당하는 <c:if test=""></if> 내지는 <c:forEach>정도만 쓰게 되는데 오늘 소스에서 비교연산자 eq 가 자주 출몰해서 검색을 좀 해봤더니 평소 안보던 것도 몇 개가 있더라..

참..!! 원래는 카테고리를 [JSTL] 로 만들까 했었다.. 근데 결국에는 JSP 내에서 주로 쓰는 것이고, 파생된 개념이기 때문에 JSP 카테고리 내에 쓰기로 마음 먹었다.. 그렇게 되면, AJAX 나 jQuery 카테고리도 좀 그럴 수도 있지만 패수하자.. ㅋㅋ.. 너무 복잡해지자낫..

우선 우리가 보통 사용하는 것이 ==, !=, <, >, <=, >= 이정도인데.. 이것이 JSTL 로 가면 아래처럼 바뀐다..

• == is JSTL eq 
• !=  is JSTL ne
• <   is JSTL lt
• >   is JSTL gt
• <= is JSTL le
• >= is JSTL ge

오른쪽 부분이 JSTL 로 변경 된 것.. 나도 그렇지만 모르는 사람들은 대부분 위처럼만 얘기하면 분명히 이해가 안간다.. 계속 쓰던 사람이라면 모를까.. 그래서 간략하게 쓰임새를 보자.. 단, 주로 쓰고 대표적인 eq 와 ne 로 예제를 올린다.. 

eq..

1 2 3 4

//eq == <c:if test="${null eq testData}">내용</c:if> // null <c:if test="${0 eq testData}">내용</c:if> // 숫자 <c:if test="${'0' eq testData}">내용</c:if> // 문자

ne..

1 2 3 4

//ne != <c:if test="${null ne testData}">내용</c:if> // null <c:if test="${0 ne testData}">내용</c:if> // 숫자 <c:if test="${'0' ne testData}">내용</c:if> // 문자

상당히 간단하다고 생각 든다.. 물론 나만 그럴 수도 있긴하지만, 그래도 어려운 로직이 아니고 단순한 패턴이기 때문에 조금이라도 개발을 하시던 분이거나 이제 입문하셨다고 해도 충분히 "아~~~" 이럴 것이라고 생각된다..

다음에는 기회가 되면, 기타 연산도 포스팅 할까 싶기도 한데 우선은 내가 쓰다가 올리면 좋겠다는 것을 위주로 포스팅 하기 때문에.. 기약없는 나중을.. 후후..

[JS]JavaScript.next에 대해서..

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

그 전에도 수시로 논의가 오갔지만 5월 초에 JSConf.us 2011이후로 JavaScript.next()에 대한 논의가 해외 프론트앤드 개발자 사이에서 엄청나게 활발해 졌습니다. 여기서 JS.next()라는 것은 차세대 자바스크립트를 의미합니다. 이 논의의 발단은 JSConf에서 Brendan Eich의 발표가 그 시작점이었던것 같습니다. 물론 대부분의 논의는 JavaScript가 어떤 언어가 되어야 하고 어떤 문법을 추가해야 하는가에 대한 구체적인 논의이지만 이 순간이 JavaScript가 크게 변화는 시작점에 포함되어 있다는 판단하에 앞으로의 상황추이를 좀 쉽게 보기 위해서 현재의 상황을 좀 이해하고 넘어가야 할 것 같아서 관련 정보들을 찾아보았습니다.

JavaScript의 역사
JS.next에 대해서 이야기 하기전에 자바스크립트의 역사를 좀 집고 넘어가야할 필요가 있을 듯 합니다. JavaScript는 Netscape에서 Brendan Eich(Mozilla의 공동설립자로 현재는 CTO로 있습니다.)가 90년대 초에 웹페이지를 다이나믹하게 하기 위해서 만들었으며 처음에는 Mocha라고 불렀으며 그 뒤에는 LiveScript라고 명명되었습니다. 이후 Netscape Navigator에 자바기술을 넣기 위해서 Sun Microsystem와 함께 하면서 1995년에 JavaScript라는 이름으로 최종 확정됩니다.

Netscape가 JavaScript를 Ecma International에 제출하게 되고 1996년 11월에 ECMA-262를 위한 스펙을 제정하는 작업에 들어갔으며 1997년 7월에 첫번째 에디션이 받아들여졌습니다. 1996년 Netscape 3.0에서 1.1이 적용된 뒤 1997년 Netscape 4.0에서 1.2가 릴리즈되었습니다. 이때 Microsoft는 1996년에 Internet Explorer 3.0를 발표하면서 JavaScript에 기반을 두었지만 트레이드마크를 피하기 위해서 JScript라고 이름을 지어서 같이 발표했습니다. JScript는 JavaScript의 방언정도이고 이후로 ECMAScript가 표준화 되면서 JavaScript도 ECMAScript의 Netscape 방언이 되었으며 그 외방언으로는 ActionScript가 있습니다.

이후 Netscape와 Internet Explorer의 브라우저 전쟁이 나면서 지금에서는 이상하게 들리겠지만 Microsoft는 당시에 JavaScript가 인기를 얻을 수 있도록 하기 위해서 JScript를 JavaScript와 최대로 호환성을 이룰수 있도록 노력하였습니다. 이 브라우저 전쟁의 중심에는 DOM 개발이 있었고 DOM Level 0은 Netscape에서 개발했으며 그 유용성이 좀 의심스럽기는 하지만 현대적 브라우저가 모두 지원하고 있는데 Microsoft도 이를 카피해서 Internet Explorer 3에 적용했습니다. document.images[0]같이 사용하는 것인 DOM Level 0입니다

W3C는 1994년에 설립되었고 ECMAScript를 통해서 JavaScript의 표준화를 돕고 있었으며 1998년 DOM Level 1을 위한 recommendation이 발표되고 2000년에 DOM Level 2가 발표되어 지금의 getElementById()와 이벤트 모델을 가지게 되었습니다. 하지만 이는 너무 늦은 시기였습니다. Microsoft가 브라우저 전쟁에서 이긴 후에 비호환성 정책을 취하게 되고 IE6이 지배적인 브라우저가 되면서 웹의 혁신은 끝이 나게 됩니다. 이는 웹 2.0의 시대가 올 때 까지 계속 됩니다.

또한 SpiderMonkey는 Netscape에서 Brendan Eich가 C로 구현한 JavaScript의 첫번째 인터프리터였으며 지금도 파이어폭스와 Adobe의 제품들에서 사용되고 있습니다. 1999년 말에 ECMA-262 Edition 3가 발표되면서 정규표현식과 try/catch를 통한 예외처리등이 추가되었고 현재의 대부분의 브라우저는 이 Edition 3를 지원하고 있습니다.

하지만 이 시점 이후로 ECMAScript의 개발인 이상한 짓을 하기 시작합니다. 임베디드 장비를 위한 컴팩트 버전도 발표하고 XML을 위한 ECMAScript로 E4X도 발표하게 됩니다. Edition 3출시 이후 ECMAScript 4에 대한 작업도 바로 시작되었는데 2003년에 중간보고서를 발표하면서 ActionScript, JScript.NET이 이 당시의 일부를 구현하고 있습니다. 2005년 ES4에 대한 작업이 다시 시작하며 2008년에 완료를 목표로 하고 있었지만 클래스기반의 객체지향, 다중메서드, 오퍼레이터 오버로딩, 타입 애노테이션, Strict 모드, 제너레이터등 작성해야할 피쳐리스트들이 2007년에도 2페이지가 넘었습니다.

이때 Douglas Crockford는 Ajax Experience 컨퍼런스에서 ES4 제안의 복잡성에 대해서 지적을 하기도 했으며 2007년 말 ES4가 완성될 수 없는 작업이라는 것이 명백해지기 시작했습니다. 그렇게 기대되던 ECMAScript 4와 JavaScript 2는 그렇게 그 생명을 다하게 됩니다. 이 과정에서 ECMAScript Edition 3의 마이너 패치를 위한 ECMAScript 3.1을 위한 워킹그룹도 진행이 되었으며 ECMAScript 4를 작업하는 워킹그룹과 별도로 진행이 되었지만 두 그룹의 분쟁은 어쩔 수 없는 것이었습니다. 

결국 협의 끝에 이 두그룹의 작업을 합치는 것으로 결정을 하게 되고 2008년 가을에 Brendan Eich는 Harmony 프로젝트를 발표하게 됩니다. 이 프로젝트는 파벌들을 다시 합시고 새로운 ECMAScript 표준을 계속 개발하는 작업을 돕기 위한 프로젝트입니다. 비록 ES4가 많은 부분에서 잘못되었지만 이미 많은 개발자들이 오픈소스 라이브러리를 ES4기반으로 만들었기 때문에 ES4를 완전히 버릴 수는 없었습니다.(물론 한때 열심히 전파되던 ES4의 특징들은 다 잊어버려도 됩니다.)

2009년에 "차후 ECMAScript 에디션에 대한 작업은 이전에 발표했던 ECMAScript Harmony 프로젝트의 일부로써 계속 됩니다.(Work on future ECMAScript editions continues as part of the previously announced ECMAScript Harmony project.)"라는 말과 함께 ECMA-262의 5번째 Edition이 승인되었습니다. ES5는 ES4처럼 급진적이고 혁신적이지 않았습니다. 배열메서드, Native JSON, String.trim, Date등이 추가되었으면 언어에 Function.prototype.bind, Updated object model, Strict mode, Constants, Getters/Setters등이 추가되었습니다.

Brendan Eich의 발표
이것이 현재까지의 상황이고 이 상황에 기반해서 Brendan Eich가 발표가 있었습니다. CoffeeScript를 만든 Jeremy Ashkenas와 Brendan이 JSConf에서 만나서 의기투합이 되어 Jeremy가 자신의 세션인 "CoffeeScript as a JS/next"에 첫 15분을 Brendan Eich를 위해서 양보해서 발표가 이루어지게 됩니다. Brendan의 발표자료는 Slideshare에 올려져 있고 자신의 블로그를 통해서 발표한 내용해 대해서 자세히 코멘트를 달았습니다.

Brendan의 얘기로는 JavaScript 개발자들이 미래를 두려워 하는 것처럼 보이게 된 것이 웹브라우더 벤더사들과 Ecma TC39(ECMAScript 3.1과 ECMAScript 4에 대한 커밋 책임을 가진 곳입니다.)가 그렇게 만들어 놨다는 것입니다. 그래서 JSConf를 통해서 JS 개발자들이 그들이 할 수 있는 가장 좋은 일을 할 수 있도록 독려하고자 했으며 그것은 모질라의 ES토론에 글을 쓰고 CoffeeScript를 사용하는 것과 같이 직접 행동하는 것입니다.

웹브라우져 경쟁이 뜨거워졌고 벤더사들은 개발자들이 팬이면서 지원자가 되기를 바랬지만 결과적으로 JS 해커들에게 커다란 힘을 안겨주었습니다. TC39의 멤버들이 커미터로써의 입장에서만 귀를 기울이면서 JS 커뮤니티보다는 업체들을 더 존중했기 때문에 이제 JS 개발자들이 목소리를 낼 수 있게 된 것은 아주 중요합니다.  물론 커뮤니티는 한 목소리를 낼 수 없지만 각 커뮤니티들은 자신들만의 방법으로 Prototype.js나 JQuery같은 결과물을 만들어냈습니다.

커뮤니티가 중요한 이유는 커뮤니티들은 JavaScript가 가진 가혹한 테스트에 직면해 있기 때문에 경쟁적이고 시간압받을 받으며 작업하는 커미터들보다 나은 장점을 가지고 있습니다. Andrew Dupont(prototype.js의 메인 커미터중 하나입니다.)이 JSConf에서 현재 어떻게 JavaScript 표준이 커뮤니티-프로젝트 라이브러리 방법을 통해서 시작되었는지를 얘기했다고 합니다. 이러한 사실상(de facto)의 표준은 러프(rough)하지만 진짜이고 JS가 그렇게 했습니다. 개발자들은 이길 때까지 사용자 테스트를 하고 이터레이션을 돌 것입니다. Harmony의 목표는 사실상의(de facto) 표준을 문서화 하는 것에 대해서 얘기하고 있습니다. 여기서 Harmony의 프로세스는 구현자들(implementors)이 어떻게 HTML5와 Web API 표준을 만드가를 돕는 것입니다.

TC39는 기존을 것을 사용해서 발전시킬수 있는 것(pave the cowpaths - 소의 통로를 포장한다.)대신에 새로 발명하는 것을 피해야 합니다. TC39는 발명을 더욱 더 하고자 하는 유혹에 빠졌습니다. 이 작업은 아마 완료되지 않을 것입니다.  TC39의 개발자들과 구현자들은 다른 것에서 좀더 배우고 어느정도 타협을 해야합니다.
Harmony의 목표는 좋지만 개발자들은 스스로 라이브러리 코드에서 무엇을 할수 있는지를 보여주거나 CoffeeScript같은 JS에 기반한 다른 언어 도달했습니다.

Harmony는 JavaScript가 더 나은 JavaScript가 되는 것을 도와주려고 하고 JS.next로써 표준화 될수 있도록 하기 위해서 입니다. 이것은 중요하고 큰 작업입니다. 이미 스펙으로써 하나의 오픈소스 언어(Single-open-source-as-spec)가 시작되었습니다.

JS.Next, ES.next
Brendan은 이 발표해서 현재 이슈되고 있는 가장 중요한 주제로 Tranpiler(Transcompiler)를 얘기했습니다. Tranpiler는 프로그리밍 언어의 소스코드를 다른 언어의 소스코드로 바꾸어주는 특수한 컴파일러를 의미하고 CoffeeScript가 그 중 하나인데 마침 이 JSConf에서 구글의  Allex Russel과 Peter Hallam은 Traceur을 발표했습니다. Traceur은 Hormony스러운 Tranpiler입니다.(Tracuer에 대한 더 자세한 내용은 Rhio.kim님의 자바스크립트. 그 다음 구글 Traceur에서 보실 수 있습니다.)

표준제정에 대한 관계가 복잡해서 완전히 다 파악할 수는 없었지만 분위기 상으로는 Brendan도 TC39나 ECMAScript 4와 무관하다고 할 수 없을텐데 JavaScript의 창시자가 직접 JavaScript의 표준은 커뮤니티가 주도해야 하며 지금보다 더욱 적극적으로 참여하라고 말한 것입니다. 현업 개발자들이 가장 좋은 안을 제시하고 만들어 내면 Harmony에서 그걸 표준문서화 해내겠다라는 의미정도로 받아들여집니다.그 때문에 엄청나게 많은 논의가 시작된 것입니다.

이 논의에는 프로토타입기반의 JavaScript에 OO의 특성이 어느정도 수준으로 들어와야 하냐부터 CoffeeScript나 Traceur같은 Tranpiler들이 JS.next이냐에 대한 다양한 논의부터 function이 너무 길어서 fn으로 하자는 중요도가 낮은 문제들까지 아주 다양합니다. 이 상황에서 JavaScript의 지존과도 같은 Douglas Crockford도 ES-discuss에서 현업개발자들이 아닌 언어 디자이너와 비평가들은 언어를 개선하기 위한 시도도 하지 말라라고 하면서 이 분위기를 더욱 고조시킵니다.

개인적으로는 어떻게 흘러갈지 모르기 때문에 뭔가 불투명한 것 같지만 이런 흐름의 미래는 아주 흥분되고 기대되는 일입니다. 최근 1,2년 사이에 JavaScript에 정말 많은 변화가 이루졌다고 생각하고 있는데 본격적인건 이제부터 시작인것 같습니다.

그런 면에서 Jeremy Ashkenas는 말은 아주 의미심장합니다.

"JavaScript는 전문가들에게 맡겨두기에는 너무나도 중요합니다."
"JavaScript is too important to be left to the experts."

[참고링크]
- Wikipedia
- History of JavaScript: Part 1
- History of JavaScript: Part 2
- History of JavaScript: Part 3
- History of JavaScript: Part 7
- ECMAScript Harmony

[Tool]Eclipse에서 메서드 정의로 이동시 인터페이스(Interface)가 아닌 구상(Implementation) 클래스의 정의로 이동하기..

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

이클립스에서 메서드의 정의롤 보기 위해서 해당 메서드에서 F3을 누르거나 Ctrl + 클릭을 하면 해당 메서드가 정의된 곳으로 이동하게 됩니다.(소스를 읽을때 꼭 필요한 편리한 기능입니다.) 하지만 일반적으로 클래스를 정의할때 커플링을 줄이고 테스트용도로 DI를 하기 위해서 Interface를 쓰게 되는데 이럴경우 Interface로 선언이 되어 있기 때문에 정의로 이동해도 인터페이스의 정의로 이동합니다. 로직을 보려고 정의(Declaration)로 이동한 것인데 인터페이스에는 로직이 없기 때문에 프로젝트뷰에서 다시 구상(Implementaion) 클래스를 열어서 봐야합니다.

이런 불편함은 아래와 같은 방법으로 해결할 수 있습니다.

이클립스 버전이 3.6 Helios이상이라면 Ctrl + 클릭으로 이동할 때 바로 클릭하지 않고 메서드위에 마우스를 올리면 위와 같은 튤팁메뉴가 나와서 인터페이스의 선언부로 이동할 것인지 구상클래스의 선언으로 이동할 것인지를 선택할 수 있습니다.(이전 버전에 위처럼 사용할 수 있는 플러그인이 따로 있는것 같습니다.)

메서드 위에서 Ctrl + T를 클릭하면 위 화면처럼 해당 인터페이스를 구현한 클래스의 계층 구조를 모두 볼 수 있고 여기서 원하는 구상클래스를 선택해 주면 됩니다. 앞에서 설명한 방법도 구상클래스가 1개일때는 바로 이동하지만 구상클래스가 여러개일때는 Ctrl + T를 누른 튤팁과 동일한 튤팁이 나오고 여기서는 필터링 기능도 있기 때문에 많은 클래스 내에서도 쉽게 찾을 수 있습니다.(오랜만에 본격적 자바코딩을 하니 몰랐던게 많군요 ㅎ)

[Tool]Eclipse에서 계속해서 오류날때 워크스페이스 Clean하기..

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

이클립스를 사용해서 개발을 하던 도중 파일을 저장할때마다 오류를 뿜어내며(저장은 되었지만) 기타 다른 동작을 할때도 크래쉬 오류가 계속 나왔습니다.(그냥 뭔가 액션만 취했다 하면 오류얼럿이 튀어나왔습니다. ㅠㅠ) 한참 검색을 하다보니 워크스페이스를 클린하면 된다는 정보를 얻었습니다.(오류로그(워크스페이스내 .metadata/.log)를 보아도 일반적인 java오류와 비슷한 메시지였기 때문에 검색하기도 쉽지 않더군요.)

결론부터 말하자면 이클립스는 파일저장이나 플러그인 추가등의 관련 모든 정보를 workspace내에 저장하는데 워크스페이스를 clean해주면 되고 이클립스를 실행할 때 -clean 파라미터를 붙혀서 워크스페이스를 정리할 수 있습니다. 이클립스 문서를 보면 다음과 같이 나와 있습니다.

Cleans cached data used by the OSGi framework and Eclipse runtime. Try to run Eclipse once with this option if you observe startup errors after install, update, or using a shared configuration.

-clean 옵션을 사용시 한번만 동작하며(이클립스를 킨 이후에 계속 유지할 필요는 없다는 의미입니다.) 아래와 같은 2가지 방법으로 사용할 수 있습니다.

• 이클립스 설치 디렉토리에 있는 eclipse.ini 파일의 최상단에 다음과 같이 -clean을 추가합니다.
  -clean
  -startup
  plugins/org.eclipse.equinox.launcher_1.1.1.R36x_v20101122_1400.jar

  
  
• Eclipse 바로가기를 수정해서 eclipse.exe -clean 같은 형태로 실행시 옵션을 주도록 수정합니다.

하지만 저의 경우 이렇게 하고나니 약간 괜찮은것 같더니만 다시금 비슷한 오류가 나는 상황이 되어버렸습니다.(대부분 clean만으로 해결이 된다는데 저는 안되더군요 ㅡㅡ;) 이런 경우에는 Workspace를 완전히 새로 생성합니다.

간단한 개발환경이라면 새로구성하면 되고 그렇지 않다면 이클립스의 설정파일 내보내기(File > Export > Preferences > "To preference file"을 통해서 백업한 뒤에 다시 가져옵니다. 필요하다면 프로젝트도 임포트하면 됩니다. 이렇게 하면 워크스페이스를 새로 구성한 것이기 때문에 완전하게 clean이 됩니다.(좀더 두고봐야겠지만 괜찮아진 듯 하군요. ㅎ)

[Book] 똑바로 일하라(REWORK) - 성과는 일벌레를 좋아하지 않는다..

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

똑바로 일하라 - 제이슨 프라이드 & 데이비드 하이네마이어 핸슨 지음 정성묵 옮김 21세기북스(북이십일)

원서의 제목인 REWORK으로 더 잘 알고 있던 책을 번역서가 나와서 이번에 읽었습니다. 이 책은 37signals를 설립한 Jason Fried와 37Signals에서 일하고 있는 David Heinemeier Hansson가 지은 책입니다. 국내에서는 37signals가 많이 알려져 있는 편은 아닌듯 하지만 제가 개인적으로 좋아하는 회사이기도 하고  프로젝트 관리를 위한 Basecamp, 협업을 위한 그룹챗 Campfire, 조직내 커뮤니케이션을 위한 Backpack, 정보관리도구인 Highrise등을 판매하며 많은 돈을 벌고 있는 대표적은 웹2.0 회사중 하나입니다. 책에 나온대로 규모는 10~20명정도인듯 합니다.

물론 37signals에는 회사보다 더 유명한 Rails를 만들어서 Ruby on Rails라는 새로운 세계를 만든 David Heinemeier Hansson(이 책의 저자이기도 하고 보통은 DHH라는 닉을 사용합니다)가 있고 prototype.js를 만들어서 JavaScript 프레임워크의 시작점과 같은 역할을 한 Sam Stephenson이 근무하고 있으며 그외 Ruby on Rails쪽 커미터들이 포진하고 있는 회사입니다. 비록 숫자는 큰 기업에서 일개 팀정도의 규모이지만 개개인을 보면 포스가 후덜덜할 정도입니다. 왠지 관리도 필요없이 내비두면 금새 서비스하나씩 만들어올 것 같은 느낌이랄까요? ㅎ

REWORK이나 똑바로 일하라 라는 제목대로 일하는 방식에 대해서 조언을 해주는 형태의 책이라고 할 수 있고 스타트업 회사들을 타겟으로 하고 있습니다. 벤처나 이제 막 시작한 스타트업들이 어떻게 회사를 운영하고 일을 해야하는지에 대해서 자신들의 노하우를 공유해주는 것입니다. 많은 열정있는 개발자들이 꼭 회사는 아니더라도 자신만의 서비스 혹은 애플리케이션을 꿈꾸고 그러면서도 어떤 조직내에서 생활을 하면서 REWORK이 말하고 있는 것들은 충분히 꼽씹어 볼만한 내용들이 많이 있습니다.

물론 평소에 이런 부분에 관심이 있었다면 REWORK이 말하고 있는 것중에 깜짝 놀랄만한 새로운 것이나 그동안 전혀 몰랐던 것 같은 것은 많지 않습니다. 그럼에도 이 책은 각 챕터에서 얘기하고자 하는 핵심을 삽화처럼 만들어 놓았기 때문에 핵심이 쉽게 각인이 되면서 글이 많지 않아서 금방 읽을 수 있었고 애자일스러운 회사답게 기존의 관습이나 관료주의류의 형식들은 깨고 실리적이고 효율적으로 움직일 수 있도록 조언해 주고 있으며 장황하게 설명하기 않고 간단한 예시와 함께 핵심만 전달하고 있어서 아주 명쾌합니다. 실제 37signals로 성공사례를 몸소 보여준 입장에서 하는 말이기 때문에 더 와닿는 것 같습니다.

개인적으로 회사에 속해서 업무를 하면서 부딪히는 것들이나 제가 생각하는 부분과 REWORK에서 말하고 있는 것들이 상당히 일맥상통하는 데다가 혼자 막연히 생각하던 것을 명쾌하게 정리해 주니까 속이 다 시원하게 느껴지는 것 같습니다. 단순히 동의를 얻어서 좋은 것이 아니라 핵심을 찌르는 부분들이 많기 때문에 글을 간결하지만 많은 생각을 할 수 있게 합니다. 관료주의가 팽배한 국내 회사들이 꼭 들어보아야 할 얘기들이 많이 있다고 생각합니다.(물론 이 책 한권보고 생각이 바뀔정도라면 애초에 걱정도 안했겠지만요. ㅎ)

이 책에서 인상 깊게 느낀 부분들은 약간 정리해 보았습니다.(책 발췌)

일중독자들은 늦게까지 남아 일하지 않는 사람들에게 위에서 시키는 일만 하는 사람이라고 비난하며 죄책감을 심어주고 사기를 떨어뜨린다. 그 결과 의자에 엉덩이만 붙이고 보자는 태도가 만연해진다.

사업가 말고 스타터라고 부르자.... 그저 괜찮은 아이디어 하나, 한 줄기 자신감, 그리고 뭔가를 시작할 추진력만 있으면 된다.

가상 쉽고도 단순한 방법은 '자기자신이 사용하고 싶은 것을 만드는 것이다. 하나의 제품이나 서비스를 만들려면 매일 수백가지의 세세한 결정을 내려야 한다. 그런데 그 제품이나 서비스가 남이 사용할 것이라면 모든 결정을 암흑속에서 내려야 한다.

중요한 것은 생각이나 말이 아니라 행동이다
핵심을 찾아내라.

한번 내린 결정을 영원히 이어갈 필요는 없다! 문제가 있으면 나중에 바로잡으면 된다.

사업의 핵심은 변하지 않는 것들이다. 사람들이 오늘도 원하고 앞으로 10년 후에도 변함없이 원할 것들, 바로 이런 것에 투자해야 한다.

대게는 흡족한 마음이 들기 훨씬 전에 내놓는게 안전하다. 제품에 꼭 필요한 기능을 장착했으면 주저하지 말고 출시하라

야근을 하는건 해야할 일이 많기 때문이 아니다. 평소에 일을 제대로 하지 못하기 때문이다. 그 원인은 바로 방해다. 최악의 방해요소는 바로 회의다.

'아이팟 킬러'나 '차세대 포켓몬'을 겨냥한다면 이미 진 것이다. 경쟁자에게 리드를 허용하는 셈이다. 애플의 비전으로 애플을 이길 수는 없다.... 나의 판을 짜야 한다.

열정이 생긴다고 해서 반드기 그 아이디어가 정말로 가치 있는 아이디어인 것은 아니다.

문화는 창출하는 것이 아니다. 그냥 생기는 것이다.

우리에게 정말 필요한 것은 일의 양이 아니라 질이다.

소신을 지켜서 성공사례를 만들어 내었다는 것은 상당히 고무적인 일이라고 생각합니다. 물론 REWORK은 단순히 이렇게 하면 성공할 수 있다 같은 수준의 내용이 아니라 "이렇게 일해야 한다"가 더 핵심이라고 생각하고 있습니다. 그 성공은 이런 것들이 막연히 이상적인 말들이 아닌 실제로 그렇다는 것을 보여준 증거라고 생각합니다. 개인적으로는 책에 내용과 부합되게 심플한 느낌으로 인상적인 원서의 임팩트가 번역서의 표지나 제목에서 느껴지지 않는것 같아 약간 아쉬워하고 있습니다만 간만에 좋은 영감을 주는 책을 읽은 것 같습니다.

[Talk]Three hundredth article..

어느 덧 300번째 글이구나.. 200번째 글을 올리게 됬을 때보단 그래도 나만의 포스팅을 조금 더 올릴 수 있었다.. 항상 그럴수는 없겠지만 해보니 아예 안되는건 아니라는 것을 느끼게 되었다..

또한, 나의 카테고리도 조금 더 늘게 되었다.. 추가적으로 올려볼만한 것이 생기게 된 것이기도 하다.. 단, 개발쪽이 아닌것도 있긴하지만.. ㅋㅋㅋ.. 그리고 포스팅을 갖고 올 때도 조금 더 구분을 하게 되었다.. 기준도 나름 생기게 되는 것 같고 말이지..

포스팅을 갖고 오거나 포스팅을 하거나 할 때 처음에 중구난방으로 하던 것에서 어느정도 패턴이 잡혀가고 있는 듯하다.. 글씨 크기도 바꾸고, 중요한 내용을 표시하는 패턴, 소스코드 삽입 방법 등등.. 무엇보다 내가 항상 글을 쓰다보면 .. 을 잘 넣고 자주 넣곤 한다.. 그런데 이제는 어느정도의 글이 마무리가 되었을 때 넣는다..

왜냐면, 예전 습관처럼 너무 자주 넣으니까 이건 머 글의 흐름이 깨지는듯한 느낌을 받아서 의도적으로 좀 바꿔봤다.. 그렇게 하다보니 과거 글을 쓸 때 느낌보단 훨씬 깔끔하다고 해야될까..?? 무튼 더 좋다.. ㅋㅋㅋ..

이젠 햄의 글도 목록 기준으로 보면 500 번대를 읽고 있는데 과거처럼 무조건 다 읽지는 않는다.. 예를 들면, 스칼라 같은 내용들은 걍 스킵한다.. 내가 관심있거나 봤거나 한 것도 전혀 아니고 해서 그런 부분은 과감하게 스킵하는데 글 번호가 앞으로 갈수록 드는 생각은 나중에 다 읽고나면 과연 나 스스로 포스팅을 잘 할까 싶은 것이다..

열심히 그리고 꾸준히 하고자 블로그를 시작한것이긴 하지만 걱정은 되긴 한다.. 햄처럼 관심사가 많거나 개발이란 것을 엄청 좋아하거나 그런것이 아니다보니 아무래도 쓸것이 많지는 않을 것 같다.. 그래도 나름의 관심 혹은 꾸준함을 이어가기 위해서 노력해봐야지..

나 스스로 항상 생각하는게 있는데 머리가 명석하지 않거나 특별한 재능을 갖고 있는게 아니라면, 꾸준하기라도 해야된다는 것이다.. 그래서 내가 하고 있는 헬스, 공인중개사 등등 모든 것을 엄청 특출나지는 않더라도 꾸준하게 하고 있다.. 설령 집중력이 흐트러지더라도 꾸준히 하는데 왜냐면, 티끌 모아 태산 이라고 믿기 때문이다.. 남들보다 조금 늦을 뿐 할 수 있다고 믿기 때문이다.. 그러니 블로그도 꾸준히 하자.. 400번째 글을 향해서..

GoGo !!!

[CSS]Blueprint - 쉽게 Grid 레이아웃을 잡을수 있는 CSS Framework..

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

순전히 제 기준으로 봤을때 작년 후반부부터해서 CSS Framework라는 얘기를 많이 듣고 있습니다. JavaScript는 물론이도 프로그래밍 언어에는 모두 프레임워크시대가 도래했는데 프로그래밍은 아니지만 이젠 CSS에도 프레임워크가 도입되기 시작하고 있습니다.

이번에 처음 CSS Framework를 찾아봤는데 아직 그 역사가 짧아서인지 구분이 좀 명확하지 않은 듯한 느낌이지만 이것저것 찾아보니 크게 미리 정의된 스타일에 맞게 class만 지정해서 사용하는 방식과 심플한 문법으로 CSS를 작성하면 컴파일을 통해서 완전한 CSS가 나오는 형태 2가지로 분류할 수 있는 것 같습니다.

전자에 해당하는 프레임워크들에는 Blueprint, 960 Grid System, YAML, Elastic, Less Framework 4등이 있습니다. 프레임워크별로 특성들이 있겠지만(저도 종류별로 만져본 것은 아니라서...) 대표적으로 제공하는 Grid같은 경우 프레임워크에서 제공하는 CSS파일을 받아서 페이지에 적용하고 가이드대로 class만 적용하면 복잡한 레이아웃도 간단하게 잡을 수 있도록 제공하고 있습니다. 후자같은 경우는 Sass나 LESS가 대표적입니다.(여기서 LESS는 앞의 Less Framework 4와는 다릅니다.) Sass나 LESS는 변수를 사용한다거나 공통적인 부분을 함수로 분리해서 재사용하는 등 약간의 프로그래밍적인 요소들이 추가되어 쉽게 작성할 수 있게 해주고 이를 컴파일해서 일반적인 CSS파일로 만들어주는 방식을 취합니다. 그런면에서 프레임워크라는 용어는 솔직히 적합하지 않은 면이 있다고 생각합니다.

Blueprint 설정하기
이번에 개인적으로 웹사이트를 만들면서 CSS로 레이아웃을 잡는게 힘들어서 Blueprint를 적용해보고 있습니다. Blueprint의 소스는 Github에서 관리되고 있어서 개발중인 소스도 받을 수 있으면 공식사이트에서도 다운로드받을 수 있습니다. 현재 최신 버전은 1.0입니다. Blueprint가 제공하는 간단한 샘플페이지가 제공되고 있으며 간단한 Quick Start Tutorial을 제공되고 있고 nettuts+의 포스팅정도가 제공하는 문서의 전부입니다. 처음 Blueprint를 만져보았을 때는 문서가 꽤 부실한 느낌이라 약간 헤메기는 했는데 약간 사용해보면 사용하기는 꽤 간단한 편입니다. 간단히 문서로 사용방법만 익히고는 Cheat Sheet를 참고하는게 더 사용하기 편한 것 같습니다.

Blueprint를 사용하려면 기본적으로 아래 3개의 CSS파일을 인클루드해야 합니다.

Html

1 2 3 4 5

<link rel="stylesheet" href="css/blueprint/screen.css" type="text/css" media="screen, projection"> <link rel="stylesheet" href="css/blueprint/print.css" type="text/css" media="print"> <!--[if lt IE 8]> <link rel="stylesheet" href="css/blueprint/ie.css" type="text/css" media="screen, projection"> <![endif]-->

screen.css는 일반적인 스크린화면용 스타일이고 print.css는 프린트를 위한 스타일이며 ie.css는 IE호환성을 맞추기 위한 스타일입니다. Blueprint는 3가지 레이어를 제공하고 있는데 CSS Reset, Typography, Grid입니다. CSS Reset은 각 브라우저의 차이점을 맞춰주기 위한 부분이고 Typography는 글자에 대한 사이즈나 색을 조정하고 Grid는 그리드 레이아웃을 맞추기 위한 레이어입니다.

Blueprint 사용하기

Html

1 2 3 4 5 6

<div class="container"> <header class="span-24 success">Header</header> <article class="span-16 ">Article</article> <aside class="span-6 prepend-2 last ">Sidebar</aside> <footer class="span-24 error">Footer</footer> </div>

위와같이 각 엘리먼트에 class를 지정해주는 것 만으로 아래와 같은 레이아웃을 구성할 수 있습니다.

사용하는 각 클래스는 Quick Start Tutorial이나 Cheat Sheet를 참고하면 됩니다. Blueprint는 기본적으로 1024x768해상도에 맞춰진 950px로 최대폭이 맞춰져 있습니다.(다른 사이즈가 필요하면 커스터마이징을 해야 합니다.) 950px를 기준으로 30px짜리 폭에 10px의 마진을 가진 24개의 컬럼으로 한 로우가 기본적으로 구성됩니다. 그리고 Grid를 사용하는 곳을 감짜는 엘리먼트가 container로 클래스가 지정되어야 사용이 가능합니다. 각 로우는 sapn-x라는 클래스로 x의 위치에 숫자를 넣어서 폭만큼의 칸을 지정하면 되고 각 로우의 마지막 컬럼에는 last라는 클래스를 지정합니다. append-x는 현재 컬럼의 앞에 prepend-2는 현재컬럼의 뒤에 추가해줄 컬럼갯수를 지정해 주면 됩니다. 24개의 컬럼을 기준으로 필요한만큼 폭을 정해주면 다양한 레이아웃을 간단하게 만들수 있습니다.

showgrid라는 클래스를 주면 위와같이 Grid를 보여주어서 레이아웃을 잡을때 참고하기가 좋습니다. 그외의 클래스들은 문서를 참고해 보면 쉽게 그 내용을 파악할 수 있습니다.

그외 Blueprint를 커스터마이징하기 위한 Blueprint나 BLUECALC등의 도구들도 제공되고 있어서 필요한 크기의 그리드를 만들어서 사용할 수 도 있습니다.

Conclusion
사실 프레임워크라는 용어를 부르기 민망할 정도이고 미리 정의된 스타일셋 정도의 수준에 가깝습니다. 다양한 스타일이 정의되어 있기 때문에 성능이나 디테일한 면에서는 직접 스타일을 잡아서 정의한 것에 비하면 부족한 것이 사실이지만 생산성면에서는 훨씬 뛰어날 꺼라고 생각되고 전문적으로 마크업과 CSS를 잡아주는 사람이 따로 없다면 상당한 수준의 레이아웃을 쉽게 구성할 수 있기 때문에 괜찮은 선택이라고 생각됩니다.

기본적인 레이아웃을 잡은 뒤에 CSS는 얼마든지 재정의할 수 있기 때문에 다루기도 쉽고 개인적으로 만드는 사이트에 적용해보고 있는데 꽤 만족하고 있는 편입니다. CSS는 브라우저별의 차이도 많고 CSS의 특성이나 경험을 많이 해보지 않으면 다양한 레이아웃에서 원하는 스타일을 적용하기가 쉽지 않고 상당히 피곤합니다. 저같은 경우는 마크업과 CSS에 관심은 있지만 주업무롤은 아니기 때문에 한계도 있는데 Blueprint를 사용하니까 쾌적하고 좋더군요. ㅎ

My Comment..
퍼블리셔가 아닌 관계로 CSS 프레임워크를 쓸일이 있을듯하지는 않지만, 글을 갖고 왔는데.. CSS 에 프레임워크가 있다는 것이 신기해서 읽어보고 가져왔다.. CSS 를 만진다고 해봐야 퍼블리셔가 준것에서 정말 소소한 것 몇 개만 수정하는 정도인데 신기 신기.. CSS 에도 프레임워크란 것이 있다니.. +_+..

[Book] 자바 세상의 빌드를 이끄는 메이븐..

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

자바 세상의 빌드를 이끄는 메이븐 - 박재성 지음 한빛미디어

앞에서 포스팅[개인 후기여서 가져오지 않았던 포스팅..] 했던 대로 저는 이 책의 베타리더로 작년에 초안을 미리 읽었었습니다. 저자만큼은 아니겠지만 베타리딩을 하면 왠지 더 책에 정감이 가게 되는것 같습니다. 베타리딩을 한 것을 초안이었기 때문에 책을 받고 다시 읽어보았습니다. 전체적으로 흐름도 깔끔하고 내용도 명확하게 잘 정리되어 있다는 느낌입니다.

메이븐은 현재 국내에서도 많이 보급이 되고 있다는 느낌이 있기는 하지만 전체적으로 보면 아직은 도입시기로 기술을 선도하거나 새로운 기술을 잘 받아들이는 조직위주로 많이 쓰이고 있다고 생각하고 있습니다.(메이븐이 최고다라는 의미는 아닙니다.) 하지만 대부분의 오픈소스 프로젝트를 받아서 사용하려고 보면 상당수가 메이븐을 사용하고 있기 때문에 자신의 프로젝트에서 메이븐을 쓰지 않는다고 하여도 메이븐에 대해서 익혀볼 가치는 충분하다고 생각됩니다.

이 책의 전개는 메이븐의 사용법을 열거한 레퍼런스 타입은 아니고 박재성님이 위키북이라는 프로젝트를 진행하면서 메이븐을 사용하기로 결정하고 프로젝트를 진행하면서 단계별로 메이븐을 테스트하고 작용하면서 확장해 나가는 단계를 프로젝트 진행 타임라인대로 설명해 놓은 책입니다. 단순히 메이븐에 대한 사용법뿐만 아니라 프로젝트를 진행중 메이븐을 도입하면서 고민했던 부분이나 프로젝트에서 발생한 이슈들을 메이븐으로 어떻게 풀어나갔는지에 대한 고민이 그대로 담겨져 있습니다. 이러한 부분들은 다른 프로젝트에서도 충분히 공통적으로 발생할 수 있는 이슈들이기 때문에(사실 일반적으론 이정도도 고민을 하지 않죠. ㅎ) 현재 프로젝트에 메이븐을 적용하려고 한다면 정말 많은 도움이 될 수 있을 꺼라고 생각합니다.

메이븐에 대한 설명은 터미널에서 명령어로 사용하는 것을 위주로 되어 있습니다. 메이븐을 쓸 때 이클립스에서 많이 쓰는 m2eclipse에 대해서는 한 챕터정도만 설명이 되어 있을 뿐이고 중간중간 약간의 가이드만 되어 있을 뿐이고 대부분은 직접 터미널에 명령어를 입력해서 사용하는 것으로 설명하고 있습니다. 저를 포함해서 대부분의 개발자들이 GUI툴에 익숙하고 거의 GUI툴만 쓰기 때문에 이런 부분은 직접 와닿지 않고 약간 돌아가는 느낌이 있을수 있지만 개념을 잡기에는 터미널을 위주로 설명하는 것이 훨씬 좋다고 생각합니다.

저도 최근에는 터미널을 많이 사용하지만 메이븐은 거의 m2eclipse로만 사용하고 있었습니다. 사실 m2eclipse는 그리 안정적인 플러그인이 아니라서(써보신 분들은 아실듯...) 문제가 생기면 해결하기 위해서 터미널로 가서 mvn eclipse:eclipse를 입력하곤 했지만 이 명령어가 무슨 의미인지도 잘 모르고 사용했습니다. GUI툴은 사용하기는 편리하지만 개념을 잘 잡고 있지 못하고 쓸때는 문제가 생기면 정말 해결하기가 어려운 편인데 이 책에서 명령어로 일일이 설명해 주고 있기 때문에 설사 m2eclipse를 쓰고 있다고 하더라도 메이븐의 동작 개념을 잡기가 정말 좋습니다.(물론 연습도 터미널로 하면 이해하기가 훨씬 좋겠죠. ㅎ) 저도 앞으로는 이 책을 참고삼아 터미널 위주로 사용을 하려고 하고 있습니다.

저는 Ant도 제대로 써본적이 없어서 잘 모르지만 Maven은 많은 부분이 자동화되어 있어서 처음에 동작원리를 배우기가 어려운 부분이 있습니다. 하라는대로 하니까 프로젝트 설정이 되기는 했는데 어떻게 된건지 잘 모르는 상황인거죠. 하지만 어느정도 사용하다보면 리아브러리 디펜던시관리나 프로젝트 설정관리등이 너무 편하고 공유하기에도 좋아서 금새 빠져들게 됩니다. 처음 메이븐을 접했을 때는 자료도 많지 않고 공부하기가 어려웠었는데 현재 국내에는 번역서인 Maven : Sonatype이 만든 Maven 핵심 가이드 다음으로 나온 두번째 메이븐에 대한 책입니다. 먼저 나온 책을 아직 보지는 않았지만 이 책에서는 단순히 메이븐에 대한 사용법이 아닌 메이븐의 개념을 알려주려고 하는 노력이 많이 느껴지기 때문에 그 개념을 제대로 공부한다면 차후에 메이븐을 더 다양하게 활용할 수 있을것이라고 생각됩니다. 

My Comment..
메이븐이라는 것은 과거부터 얘기만 들었지 내가 써본적은 없다.. 그래서 해당 글은 좀 고민을 하다가 갖고 왔다.. 글에 언급된 Ant 는 직접적으로 관여해서 썼다기보다는 누군가 해둔 것을 잠시 활용만 해봤던 적은 있다.. 그러다보니 개념은 안드로메다에 있는 실정이고.. ㅎㅎ..

[Book] 실전 jQuery 쿡북..

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

실전 jQuery 쿡북 - jQuery 코어 커뮤니티 지음 김경균.최지훈 옮김 김태영 감수 비제이퍼블릭

Amazon에서도 꽤 많이 팔린걸로 알고 있는 제이쿼리 쿡북입니다. 사실 jQuery의 인기의 비해서 국내에는 책이 그다지 많지 않은데 괜찮은 책들도 있기는 하지만 버전이 1.3 이하버전을 기반으로만 되어 있어 아쉬움이 있었는데 작년에 이 책이 나왔습니다. 사실 예판할때 바로 지르긴 했는데 계속 미루고 못보고 있다가. 이책도 원서는 1.3 기반인데 번역서가 1.4로 증보하였는데 jQuery는 이미 1.5.2대로 들어섰고 1.6얘기도 나오고 있는 관계로 더 늦으면 아예 이책도 안보겠다 싶어서 집어들었습니다.

쿡북이라는 이름대로 이 책은 레시피소개 방식으로 쓰인 책입니다. 모든 챕터의 구성이 많이 필요할 만한 상황을 주고 그부분은 jQuery로 어떻게 작성하는지에 대해서 보여준 다음 코드에 대한 설명이 이어붙습니다. 이런 레시피 방식이기 때문에 나중에 필요한 기능이 생겼을때 참고해 보기에 좋은 편이고 각 상황에 대한 구성도 많이 쓰일만한 패턴을 위주로 잘 설명하고 있다는 느낌입니다. 그리고 원 저자가 jQuery의 코어개발자들이 작성한 것이기 때문에 기본적으로 소스에 대한 신뢰도 할 수 있습니다.

저도 jQuery를 상당히 좋아하고 jQeury같은 프레임웍자체를 안쓰는걸 좀 답답해 하는 편이기는 하지만 한편으로는 jQuery덕분에 개발자들이 JavaScript를 너무 쉽게 생각하고 크로스브라우징 같은 이슈를 고려조차 하지 않는 것에 대해 불만을 가지고 있는 사람중 하나인데 이 책은 당연히 jQuery책이니 jQuery를 설명하고 있기는 하지만 초반에 이 책은 JavaScript책은 아니니 JavaScript에 대한 공부는 미리 따로 하기를 권하는 점이나 전체적으로 jQuery의 좋은 사용법을 강조하기는 하지만 순수 JavaScript의 사용의 고려를 강조하는 것은 상당히 좋게 느껴집니다. jQuery는 jQuery일 뿐이니까요 ㅎ

현재 jQuery버전이 1.5.2이기는 하지만 이 번역서가 나올 당시 1.4.x가 릴리즈되었기 때문에 첫장에 taeyo님의 jQuery 1.4의 새로운 기능에 대해서 설명하고 있기 때문에 1.4이상버전을 쓰는 사람에게도 유용하리라 생각이 됩니다. 1.5.x에서는 ajax리팩토링이 주요 이슈이기에 사용하는 개발자 입장에서는 성능이 이점이 있을 뿐 공부하는데는 이정도로도 충분하다고 생각됩니다. .sub()의 추가가 있기는 한데 이런 부분은 따로 찾아서 보면 되기 때문에 한참 동안은 이책을 참고해서 jQuery를 공부하기에 문제가 없다고 생각합니다.

저한테는 상당히 좋은 느낌의 책이고 초심자가 보기에도 괜찮다고 생각은 하지만 레시피방식이기 때문에 정확히 초심자가 어떻게 느낄지는 잘 모르겠습니다. 기본적인 DOM이나 CSS 셀렉터같은 지식은 가지고 있고 어느정도는 jQuery를 쓰고 있었기 때문에 다양한 jQuery의 사용법과 코드작성법, 컨벤션등에 대해서 자세히 가이드하고 있는 부분은 아주 유용하게 느껴지고 jQuery의 특징인(머 다른 JavaScript라이브러리도 그렇지만요) 체인방식이나 셀렉터를 활용하는 부분에 대해서 친절하게 잘 설명해주고 있다는 느낌입니다. 아주 간단한 DOM 핸들링부터 다루고 있기 때문에 초심자가 jQuery를 익히기에도 무리는 없겠지만 좀더 제대로 익히고 싶다면 DOM등의 기본적인 JavaScript지식은 따로 공부해 두는 것이 더 좋다고 생각됩니다.

후반부에는 jQuery 플러그인들에서도 많이 다루고 있습니다. jQeury를 쓰다보면 플러그인 도배가 되는 느낌이 없잖아 있어서 꼭 좋다고 해야할지는 잘 모르겠지만 jQuery코어팀이 추천하는 유용한 플러그인들을 참고할 필요는 있다고 생각되고 jQuery UI에 대해서도 2-3장을 할애해서 설명해 주고 있습니다.(jQuery UI에 대해서는 CSS를 커스터마이징하는 부분이나 자신만의 디자인을 적용하는 부분에 대해서도 많이 나와있어서 읽을때는 좀 지루하긴 한데 나중에 참고할때는 유용할 듯 합니다. ㅎ)

저는 Ajax를 다룬 부분이(요즘은 Ajax의 사용빈도를 생각할때) 다른 장에 비해서 좀 빈약하지 않나 생각을 하고 있습니다. 내용이 부실하다거나 그런것은 아니고 유용한 내용이 있고 하지만 좀더 다양한 레시피를 제공해 주었었다면 더 좋았겠다하는 느낌은 있습니다. 그리고 마지막장의 QUnit까지 다뤄주고 있어서 jQuery에 대한 모든 것을 다뤄주고 있다고 생각합니다. 개인적으로는 17장인 대형프로젝트에서 jQuery 사용하기는 굳이 왜 들어간걸까 하는 생각은 좀 있습니다. 앞부분은 HTML5에 대한 얘기인데 HTML5에 대한 설명도 빈약하고 플러그인과 내용을 섞어놔서 이해하기가 좀 어렵게 되어 있으며 다른 플러그인들은 꼭 다루지 않아도 될만한 플러그인이라고 생각이 들었습니다. 일단 장의 이름인 대형프로젝트하고 무슨 상관이 있나 싶기도.. ㅎ

jQuery는 어느정도 익히고 나면 레퍼런스문서가 잘되어 있어서 레퍼런스 문서를 보는게 더 좋다고는 생각하지만 이책과 병행해서 보면 jQuery작성의 수준을 많이 높일 수 있을 듯합니다.

[Book] 토비의 스프링 3..

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

토비의 스프링 3 - 이일민 지음 에이콘출판

드디어 다 봤습니다. 사실 드디어라고 하기에는 너무 오랫동안 봤습니다 .동시에 여러가지를 하기도 하고 봄싹에서 하는 스터디의 교재로 하다보니 스터디 진도에 맞추면서 보다보니 6개월동안이나 책을 봐버렸네요. 1400페이지나 되니 책이 좀 두껍기는 하죠. 원래 계획은 한번 먼져 보고 스터디 진도는 계속 따라가는 거였는데 그렇게 되지는 못했습니다.

어쨌든 책은 정말 최고입니다. 아니 최고라는 말로도 부족할 정도입니다. 그 이전에 스프링 책을 웹 개발자를 위한 스프링 2.5 프로그래밍와 프로 스프링 2.5를 보았었는데 스프링에 대해서 감이 잘 안왔었습니다. 물론 이부분은 제가 스프링을 업무에서 만지고 있지 않았던 데다가 그냥 책만 보았지 따로 코딩하면서 연습해볼 기회가 없었던 부분도 더 크기는 했지만 보통은 책을 보면 어느정도 감이 오는데 스프링을 공부할 때는 계속 XML설정 얘기만 있는것 처럼 느껴지고 책을 다 보았는데도 어떻게 개발해야되는지도 감도 잘 안오고 했습니다만 이 "토비의 스프링 3"는 달랐습니다. 스프링이 가진 철학상 다양한 선택권을 주다보니 공부하는 입장에서는 더 헷갈릴 수 밖에 없었던 것이었는데(물로 그 사이에 공부하면서 어느정도 깨닫기는 했지만) 이 책에서 아주 명확하게 알려주고 있습니다.

이 책에서 토비님이 알려주려고 하는 것은 제가 느끼기에는 2가지인것 같습니다. 스프링이 구현하고 있는 자바에 대한 것과 그 철학을 바탕으로한 스프링의 사용법입니다. 그 부분에 따라 1부와 2부로 나누어져 있습니다.

1부는 스프링이 구현하고 있는 기술들에 대한 설명들이지만 결국은 자바에 대한 얘기이고 스프링이 다양한 부분에서 자바기술에서 가장 괜찮은 구현을 해내고 있다는 면에서 봤을때 현재 자바라는 기술을 어떻게 사용하면 잘 사용할 수 있는지에 대해서 설명하고 있습니다.(물론 당연히 스프링에 대한 설명부분도 있습니다.)그래서 시작은 아주 간단하게 DAO 클래스부터 해서 OOP에 원칙에 근거해서 어떻게 분리하고 왜 인터페이스를 도입해야 하고 IoC나 DI를 어떤 원리로 구현하고 어떤 이점이 있는지 찬찬히 설명해 주고 있습니다. 아주 이해하기 쉽게 일일이 코드로 예를 들어주면서 AOP라는 기술이 어떤 원리로 적용되고 예외처리는 어떻게 해야하며 서비스 추상화는 어떻게 해야하는지 일일이 설명해 주고 있습니다. 개인적으로 스프링을 사용하지 않는 개발자라고 하더라도 자바개발자라면 최소한 이 책의 1부를 읽고 학습한다면 크게 도움이 될 것이라고 생각합니다.

2부는 실제 스프링을 어떻게 사양하는지에 대한 레퍼런스 격인 성격을 가지고 있습니다. 다른 책을 볼때는 XML설정에 대한 나열이라 지루한 면도 있었는데(물론 그사이에 스프링이 애노테이션을 더 강화시킨 부분도 있지만요) 1부에서 각 기술이 뒤에서 어떻게 돌아가고 왜 그렇게 하는지를 설명했기 때문인지 레퍼런스라고 하더라도 지루하지 않고 갈 설정이나 사용법을 설명하는 중간에도 경험에서 우러나온 셜명들이 함께 있기 때문에 비교적 이해하기 쉽다고 느껴집니다.(비교적입니다.. 한번 읽었다고 스프링을 이해할리는 없죠 ㅎ)

이 책에서 가장 좋은 점은 아주 친절하다는 것입니다. 저는 아는 거랑 가르치는 것은 약간 다르다고 생각하는 편이고 잘 아는 사람이 잘 모르는 사람을 위해서 설명해 준다는 것은 쉽지 않다고 생각하는데 리차드 파인만이 "쉽게 설명할 수 없다면 그에 대한 지식이 모자라다는 것"이라고 말한 것을 증명이라도 하듯이 토비님은 스프링의 구현기술들을 완전히 이해하고 있다는 것이 느껴질 정도로 쉽고 친절하게 가르쳐 주고 있습니다. 그래서 스프링에 대한 공부는 이 책 한권이면 되겠다고 느껴질 정도라서 이 책에서 말하는 것만 연습해서 제대로 자신의 것으로 만들기만 해도 실력이 크게 향상 될 것 같습니다. 사실 이런 수준의 노하우를 5만원 정도에 얻을 수 있다는 건 거의 공짜가 아닌가 싶습니다. 책을 3년정도 쓰신 것으로 알고 있는데 이정도의 책이 나오려면 그만큼에 노력이 드는거구나 하는 생각이 듭니다.(기술에 대한 얘기는 아니지만 토비님의 "토비의 스프링 3이 나오기까지"시리즈를 읽어보시는 것도 재미있습니다.)

또한 단순히 기술을 가르치는 것 이상으로 개발자의 방향을 제시하시고자 하는 부분도 상당히 맘에 들고 있습니다. 스프링의 기술들을 설명하면서 책에서 전체적으로 강조하고 있는 것 중 하나가 Test입니다. 새로운 것을 배우기 위해서 하는 Learning test부터 개발에서 테스트가 얼마나 중요한지... 그리고 단순히 스프링의 API만 사용하는 개발자가 아니라 스프링의 철학을 이해하고 구현코드도 스프링의 철학을 담아서 개발하는 것이 왜 중요한지를 책 내내 강조해서 이 책을 통해서 공부하는 개발자들이 그냥 스프링만을 배우는 것이 아닌 개발자로써 배워야 하는 부분까지 포함하려고 했다는 부분에서 책을 읽는 내내 많은 생각이 들었습니다.

그전까지는 스프링은 왠지 막막하게 느껴졌었는데 그래도 한번 보고 나니까 스프링이 추구하고자 하는 철학을 상당부분 이해할 수 있게 되어 앞으로 학습의 방향을 잡는데 많은 도움이 되었습니다. 기술 서적들을 보면서 한번더 보면 좋겠다하는 책들이 좀 있기는 한데 이 책은 그것 이상으로 느껴집니다. 개인적으로 올해 반드시 한번 이 상은 더 보면서 직접 코딩해보면서 제것으로 만들어야 겠습니다. 

[EP]OKJSP 10주년 기념 세미나 후기..

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

지난 3월 26일에 OKJSP 10주년 기념 세미나가 정보통신산업진흥원 5층에서 열렸습니다. 신입시절에는 하루에서 수차례 들락거리면서 글을 보고 세미나에 참가하고 그랬던 OKJSP였는데 어느새 10년이나 되었습니다.(지금은 하루에 한번정도만 가는것 같습니다. 워낙 읽을 글이나 돌아볼 사이트가 많은 지경이라서요. ㅎ) Kenu님하고의 친분(친한척!!)도 이당시에 세미나를 왔다갔다 하면서 자주 뵙게 되어 쌓게 되었습니다. 회사도 10년을 운영하기가 쉽지 않은데 커뮤니티를 10년동안 운영한다는 것은 정말 보통일이 아닌것 같습니다.(요즘은 기술에 대한 논의 보다는 개발자의 삶을 나누는 커뮤니티라는 느낌이 더 강하기는 한데 그런 점이 저는 종종 안락함을 주기도 합니다. ㅎ) 

사실 오전에도 봄싹 스웨거가 있어서 시간이 약간 겹치기는 했는데 Kenu님과의 친분도 있고 해서 참가를 했습니다. 약간 늦어서 키노트세션인 OKJSP 커뮤니티 이야기는 듣지 못했네요 ㅎ java 커뮤니티이기는 하지만 최근에 Kenu님이 모바일쪽에 집중하셔서인지 발표세션도 대부분 모바일쪽이 치중되어서 이루어졌고 대부분 키노트를 사용한 화려한 플라이드가 인상적이었습니다. 발표자료는 여기에 올라와 있습니다. 대부분의 세션이 20~30분 정도였기 때문에 기술적으로 깊게 들어가지는 않았습니다.

MobileWeb(SenchaTouch, jQueryMobile) - 안광운
모바일웹에 대한 세션이었고 안광운님이 발표 처음에 말씀하신 것 처럼 모바일얘기가 요즘은 너무 많아서 좀 지겨운 주제일수도 있기는 한데 그만큼 모바일이 중요해 지고 있다는 의미이기도 하다는데는 동감을 합니다. 전체적으로는 MobileWeb에 대한 간략한 개요정도였습니다.

HTML5는 HTML, CSS, JavaScript의 기술 모음이고 어렵게 생각할 필요 없이 현재 사용중인 HTML의 발전된 형태이고 개발자들이 보통 CSS를 많이 어려워하는데 공부해 두면 좋다고 하셨습니다. 과거에는 iUi나 jQTouch를 많이 썼지만 이젠 모두 개발이 중단되었고 jQueryMobile이나 Sencha Touch를 주로 사용하는 분위기이고 삼성의 Bada플랫폼에 최적화된 Rijj-js도 있습니다.

jQueryMobile같은 경우는 아주 쉬워서 누구나 일주일정도만 만지면 괜찮은 퀄리티로 만들어낼 수 있을 정도이고 지원하지 않는 브라우저에서는 기능을 줄여서 제공하는 점진적 향상, 단계적 기능 축소가 인상적인 기능이었습니다. JQM으로 만들어진 페이지들은 jQuery Mobile Gallery에서 보실 수 있습니다. Sencah Touch로 만들어진 잡지데모가 인상적이었는데 어떤 데모인지는 못찾겠네요 ㅎ

SVG with Raphael - 김종광
제가 알기로는 지난달 WebDevMobile에서도 발표된 내용으로 알고 있는데 그때 못봐서 아쉬웠는데 이번기회에 듣게 되어 좋았습니다. Raphael은 SVG(Scalable Vector Graphics)를 위한 라이브러리이고 SVG는 익히 알려진대로 벡터(Vector)그래픽입니다. 비트맵 그래픽은 2D는 Canvas라고 부르고 3D는 WebGL이라고 부르고 있습니다. 벡터그래픽은 VML과 PGML인 98년에 만들어지고 SVG는 2001년에 만들어졌습니다. 그뒤 PGML은 SVG로 대체되었지만 VML은 IE 6,7,8에 남아있는 상황입니다.

 

벡터그래픽이기 때문에 아무리 확대를 해도 그 모양이 깨지지 않으면 Raphael 사이트도 모든 이미지를 SVG로 그려주고 있으며 Raphael은 VML과 SVG와 JavaScript를 합친 라이브러리이기 때문에  IE6까지 폭넓게 지원해주고 있습니다. 이번 세미나에서 가장 인상적인 세션이었고 Raphael은 이름만 알고 있었는데 사용법도 아주 간단하게 느껴져서 조만간 좀 써봐야겠다고 생각하고 있습니다.

하이브리드 앱 - 강화영

발표자료를 JQM으로 만든 부분이 흥미로웠는데 모바일웹과 네이티브앱의 이점을 둘다 살려서 최근에 발전하고 있는 하이브리드앱에 대한 내용있었습니다. 가장 많이 알려진 PhoneGap과 Titanium과 함께 Rhodes와 KTH에서 개발해서 얼마전에 런칭한 Appspresso에 대해서 소개했습니다. 기술적인 내용을 다뤘다기 보다는 각 플랫폼에 소개와 간단한 특징비교정도였습니다.

프로그래머가 되는 방법 - Kenny(강윤신)
시간표에는 착하게 살자라는 제목으로 나왔지만 이 세션은 "How to be a Programmer"라는 글에 대한 내용이었습니다. (유명한 글이라더군요. 저도 날잡아서 읽어봐야겠습니다. 다행히도 KLDP에서 번역해놓은 문서가 있습니다.) 아주 예전에 몇번 본적은 있었는데 상당히 어조가 강한 세션이라서 듣는데 개인적으로 약간 거북함이 있었습니다. 세션 초반에 미리 자기 스타일로 그냥 얘기하겠다고 얘기하시기도 했기에 어느정도 예상은 했지만 약간 윗사람이 아랫사람한테 뭐라 하듯이 하는 어조라서 좀 거북함이 있었고 말하는 부분에서 개발자의 현실이 틀린말은 아니라는 부분에서 다시 거북해졌습니다. (개인적으로는 개발자는 약간의 까칠함정도는 있어야 한다고 생각하는 편인데 제가 가지지 못한 부분이라서 약간은 부럽(?)기도 했습니다.)

전체적인 내용은 문서를 읽어보는게 나을것 같기 간략이 보면 아래와 같습니다.

• 디버그 배우기 - 디버그 못하면 프로그래머라고 하지 말자
• 요즘 개발자 너무 착하다. 원래 좀 까칠해야 한다.
• 디바이드앤 퀀커 - 문제공간을 나눠서 디버그하는 방법이고 알고리즘을 직접 구현할 필요는 없다 일반적으로 라이브러리를 쓰는게 낫지만 디바이드앤퀀커를 하려고 알고리즘을 공부하는 것이다.
• 오류를 제거하는 방법
• 로그를 이용해서 디버그하는 방법
• 성능문제를 이해하는 방법
• 가끔씩 생기는 버그를 다루는 방법
• 문자열!(그리고 정규식) - java면  java.lang.String, commons.String을 달달 알고 js는 문자열관련을 외워라
• 프로그래밍 시간을 추정하는 방법
• 정보를 찾는 방법
• 사람들을 정보의 원천으로 사용하는 방법 - 아는 사람들에게 물어보는게 제일 빠르다
• 막힐때는 잠깐 쉬어라
• 집에 갈 시간을 인지하는 방법
• 게으름! - 약간의 게으름은 필요하다

안드로이드 프로그래밍 - 진성주
안드로이드 프로그래밍의 저자이면서 OKJSP의 안드로이드 프로젝트를 진행하신 진성주님의 세션이었습니다.(발표듣다보니 이미 저랑 트위터 팔로우 관계.. ㅎ) 사실 저는 작년에 잠깐 안드로이드를 만져보고 그뒤로는 안드로이드 개발을 하고 있지는 않고 오히려 관심이 있다면 iOS쪽으로 관심이 넘어간 상태입니다. 이 세션은 그냥 안드로이드 개발에 대한 설명이라기 보다는 안드로이드개발을 공부하기 위해서 Reverse Engineering을 택해서 하는 방법에 대한 설명이었습니다. 이부분은 공개된 소스가 상대적으로 부족한 iOS에 비해서 오픈소스가 주류를 이루고 있는 안드로이드의 특징을 잘 이용한 방법으로 실제 개발을 하려면 책으로 공부한 예제외에도 정말 많은 부분이 필요한데 그부분을 Reverse Engineering으로 접근한 점은 저는 생각지 못했던 부분이라 상당히 인상적이었습니다.

Google code나 Google code search를 이용해서 소스를 검색할 수 있고 apk로 패키징이 되어 있는 앱의 경우 ApkTook을 이용해서 apk파일을 dex(Java의 jar와 같은)와 리소스로 분리해내고 dex2jar를 이용해서 dex를 jar로 바꾼 다음에 자바 디컴파일러인 JD로 .class파일을 .java로 디컴파일해서 소스를 확인해서 필요한 기능을 어떻게 구현하는지 확인해 봄으로써 아주 퀄리티 좋은 예제의 소스를 참고해서 공부를 할 수 있습니다.

epilogue
OKJSP의 10년이라는 세월처럼 그동안 Kenu님이 얼마나 폭넓게 활동을 하셨는지가 많이 느껴지는 세미나였다고 생각합니다. 왠만한 상업적 컨퍼런스에 부족하지 않을 정도의 장소와 경품등이 지원되었던것 같습니다.(그 많은 경품중에 단 한개도 안걸리다니. ㅡㅡ;;;) 기술적으로 많은걸 배울수 있었던 세미나라기 보다는 많은 사람들을 만나고 10주년을 축하하는 즐거운 자리였던것 같습니다. ㅎ OKJSP의 10주년을 축하합니다. 20주년 세미나를 기대하겠습니다. ㅎ

세미나 사은품으로 나눠준 마이크로소프트웨어 잡지랑 OKJSP 파우치와 메탈스티커입니다. ㅎㅎㅎ 나름 레어네요 ㅎㅎ

[Book] 자바 개발자도 쉽고 즐겁게 배우는 테스팅 이야기..

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

자바 개발자도 쉽고 즐겁게 배우는 테스팅 이야기 - 이상민 지음 한빛미디어

사실 이 책의 제목만 보았을 때는 책의 내용이 잘 감이 오지 않았습니다. 테스팅이라는 것 자체의 개념이 워낙 넓은 데다가 개발자가 보는 테스트와 QA가 보는 테스트의 관점이 상당히 틀리고 제가 있는 곳에도 QA가 있지만 업무보면서 느낀 QA의 테스트 범위와 다른 외부에서 만난 QA들의 테스트의 범위도 상당히 다르고 접근하는 지식의 범위도 크게 달랐습니다. 이렇게 테스트라는 것 자체의 범주가 너무 크긴 합니다.

제목만 보고 어떤 테스팅인가 하는 궁금증이 있었는데 막상 책을 보고 나니 이 책에서 얘기하는 테스팅은 개발자관점에서 알아야 할 모든 테스트에 대해서 얘기해주고 있었습니다.(제목이 얘기하는 그대로라고 할 수 있습니다.) QA관점에서의 테스트와도 겹치기는 할텐데 QA관점의 테스트가 어떤건지 저로서는 잘 모르겠지만 개발자에게 필요한 모든 테스트는 여기에 다 담겨있다고 할 수 있습니다.

테스트라는 것을 전체적으로 보면 개발자가 개발을 하면서 JUnit으로 단위테스트를 하고 그렇게 만들어진 웹페이지를 Selenium을 통해서 UI테스트를 하고 HttpUnit을 통해서 웹리퀘스트를 테스트하고 PMD나 FindBugs같은 툴을 이용해서 코드를 분석합니다. 그리고 Hudson을 가지고 개발한 소스를 지속적으로 통합하고 성능및 보안테스트를 거친 다음에 FitNess를 이용해서 인수테스트를 거칩니다. 이 모든 과정은 개발자가 개발을 한 뒤에 프로젝트를 완료해서 고객에게 넘길 때까지 필요한 모든 테스트과정(제가 아는 범위내에서는)이 다 담겨있다고 할 수 있습니다.

사실 이런 테스트들은 하나하나가 책 주제로 될 정도로 많은 내용이기 때문에 이 책 한권에서 전체적인 사용법을 모두 알려주길 기대하는 것은 좀 무리가 있다고 생각됩니다. 대신에 이 책은 개발과정중에서 테스트가 이뤄지는 전체 흐름을 잡기에 아주 좋다고 생각됩니다. 유닛테스트나 회귀테스트등 개발을 공부하면서 많은 테스트들에 대해서 듣게 되지만 전체적인 개념을 잡는데는 어려움이 있었는데 이 책을 통해서 어느 테스트가 언제 왜 필요한지를 설명해 주기 때문에 이해하기도 쉽고 프로젝트가 일반적으로 개발되는 흐름에 따라 설명해 주고 있기 때문에 굳이 외우려고 하지 않아도 받아들이는데 어려움이 없는 것 같습니다. 각각의 테스팅에 대해서 구체적인 사용법을 알려주는 것 보다는 전체적인 테스팅에 대한 개념을 알려주는 책이라고 생각하고 있고 전체적인 흐름에 대한 개념을 이해할 수 있어서 각 세부테스팅에 대해서 공부할때도 이해하는데 도움이 될 것 같습니다.

단순히 개념만 설명하는 것은 아니고 간단하지만 설치와 설정을 통해서 사용해 볼 수 있도록 구체적인 설명도 어느정도 해주고 있어서 쉽게 따라해 볼수 있습니다. 물론 실제 업무에 적용해서 어려가지를 해보려면 추가적으로 많은 공부를 해야겠지만요. 저는 뭔가 공부할 때 전체 개념을 잡고 들어가야 이해가 빠르게 되는 편이라 그렇게 느낀것일 수도 있기는 한데 약간은 어려울 수도 있는 테스팅에 대해서 쉽게 설명해 주고 있어서 개념을 잡는데 많이 도움이 된 책이었습니다.

[EP]P-camp와 대안언어축제 2011, "다시 돌아온 대안언어축제!" 후기..

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

지난 12일과 13일 사이에 3년만에 열린 P-camp와 대안언어축제 2011, "다시 돌아온 대안언어축제!"를 갔다가 왔습니다. 한번도 안가본 행사라 행사에 대해서는 자세히 몰랐지만 작년에 대언언어축제와 약간 얽힌 사연[글은 읽었지만 지극히 개인적인 글이라 안가져왔었음..]이 있는 관계로 대기자에서 올라가자마자 바로 신청해서 참가했습니다. 개인적으로는 행사 바로 전날 몇 년만에 올까말까한 정신적 타격을 입었던 관계로 사실 참석자체를 포기할까도 당일 아침에 생각했었지만 지친 몸을 이끌고 참석은 했는데 좀 멍한 상태라 많은 집중과 적극도는 떨어진 상태였습니다. 이 후기도 개인적인 느낌이기에 그런 부분에 대한 영향이 꽤 있다고 할 수 있습니다.

아이스 브레이킹 "3Keywords" - 박준표
사실 낯가림이 심한 저는 아이스 브레이킹이라는 행사를 그다지 좋아하는 편은 아닙니다. 3Keywords라는 방식으로 진행된 이번 아이스 브레이킹은 꼭 개발과는 관계가 없더라도 "가장 좋아하는 것", "최근에 새로운 것을 시도한 것", "올해 이루고 픈 목표"라는 3가지에 대한 키워드를 종이에 적고 3분간 앞에 사람과 얘기하면서 키워드에 대한 부가정도를 상대카드에 적어주는 방식입니다. 3분이 지나면 옆으로 이동해서 다른 사람과 얘기를 하게 됩니다. 너무 길지 않은 짧은 시간인 데다가 얘기할 키워드도 있기 때문에 상당히 즐겁게 얘기할 수 있었던 시간이었습니다.

 

10명 이상 얘기하고 나니 좀 힘들기는 했지만 시간이 짧아서 낯가리고 뭐할 틈도 없었던데다가 무얼 얘기해야할지에 대한 고민이 없다보니 아이스 브레이킹으로는 괜찮은 방식이라는 생각이 들었습니다. 어설프게 아이스 브레이킹이라며 같은 테이블에 있는 사람과 얘기해 보라는 등의 방식보다는 훨씬 분위기가 좋아지는 것 같았습니다.

대안언어배우기
오후의 세션은 4개의 트랙으로 진행이 되었는데 4시간 전체로 진행되는 대안언어배우기라는 트랙과 프로그래밍 입문하기1, 프로그래밍 입문하기2, SW공학 둘러보기 트랙으로 진행이 되었습니다. 다른 트랙에 엄청 듣고 싶은 세션이 없기도 했고 대안언어축제에 참가한 목적중에 하나가 대안언어를 좀 배워보려는 것이었기 때문에 대안언어배우기 트랙을 선택했습니다.

     

대안언어배우기 트랙에는 LISP, Smaltalk, Haskell, Objective-C, Orca, Erlang, Lua, Ruby, R/Netlogo등의 언어가 있었고 여기서도 선택을 해야 했습니다. ㅠㅠ 시작할때 각 언어별로 발표자가 나와서 5분정도씩 언어 및 세션에 대해서 설명하는 시간이 있었고 그전에 어떤 언어를 들어야 할지 맘의 결정을 하지 못한 저로써는 이시간에 정해야 했었습니다.

   

Lua vs JavaScript - 아샬
시작할 때 발표하는 것을 보고 확 맘을 정해서 선택을 했었지만 개인적으로는 별로 만족스럽지 못했습니다. 객체에 대한 부분과 Duck Typing에 대한 얘기를 하셨었고 처음에 보여주었던 Lua의 코드가 JavaScript와 너무나 유사한 점이 흥미로워서 들었습니다만 기대했던 진화하는 객체에 대해서 좀 알아보려는 것과는 다르게 프로토타입기반 언어의 기초적인 내용정도에 그쳤었습니다. 처음 보고 흥미로웠던 Lua의 코드도 몇번 보다보니 그냥 JavaScript와 거의 동일하게 동작하는구나의 이해정도로 관심이 멈춰버렸고 JavaScript는 그래도 많이 만져봤기에 기초적인 내용에 대한 설명은 제가 기대한 것과는 난이도가 맞지 않았습니다. 앞에서 언어에 대해서 설명할때 객체에 대해서 객체가 어떻게 진화되어 가는지에 대한 설명을 한다고 하셔서 저는 그런 부분에 대해서 기대했습니다만 실제로는 프로토타입기반 언어의 기본적인 특성에 대해서 설명이 되었기 때문에 JavaScript를 오랫동안 저로써는 관심도가 꽤 떨어질 수 밖에 없었습니다.(발표가 안좋았다기 보다는 제가 난이도 기대를 잘못한 것에 더 가까웠습니다. 프로토타입 기반언어를 처음 보신 분들은 꽤 흥미로워 하시더군요.)

Haskell
Lua vs JavaScript는 2시간으로 끝났기 때문에 함수형 언어인 Haskell로 이사를 갔습니다.(언젠가 스칼라를 보면서 헤매고 있을때 함수형 언어를 이해하려면 하스켈을 봐라라는 글을 본 기억때문에 한번 구경해 보고 싶었습니다.) 2시간으로 끝났던 Lua vs JavaScript에 비해서 하스켈은 총 4시간을 이어서 진행했는데 초반 2시간을 빼먹고 후반 2시간만 듣게 된 저로써는 처음에 문법이 좀 생소해서 이해하기가 어려웠습니다. 그래도 작년에 Scala를 한 덕인지 이런 저런 특성을 보다보니 Scala에도 저런거 있는데 하면서 어느정도 이해를 할 수는 있었지만 아무래도 처음의 기초적인 설명을 빼고 듣다보니 이해하는데 한계가 있었습니다.

한꺼번에 여러 세션이 진행된 행사이다 보니 당연하겠지만 듣지 못한 세션에 대해서 아쉬움이 남을 수밖에 없었습니다.(물론 반대의 선택을 했을때도 마찬가지의 결과일수도 있겠지만요.) 축제 전에는 사실 LISP까지 관심을 가지게 되면 너무 많은 곳에 관심을 가지는 결과가 오게 될까봐 약간 의도적으로 LISP는 빼고 생각했는데 결과적으로 이도저도 안된 결과가 나오다 보니 LISP나 4시간 동안 진득하니 듣거나 하스켈만 들을걸 하는 생각이 들었습니다. 옆에서 보니 커먼리습과 클로저를 가지고 잘 설명하고 있는것 같았고요.

Integrated Large Group Method를 이용한 unconference - 미디어아티스트 최승준
LETS, OST, WORLD CAFE로 진행이 되었습니다. LETS에 대해서는 LETS에 대한 소개동영상을 보시면 이하하기가 쉬울 겁니다. 좀더 구체적으로 말하면 행사장 뒷편에 붙어 있는 판에 포스트잇을 이용해서 "알려주고 싶은 것/알려 줄 수 있는 것"에 대해서 적고 자신이 누군지 연락할 트위터 정보등을 적어서 붙히고 또 다른 판에는 "배우고 싶은 것/누가 알려줬으면 좋겠는 것"에 대해서 적습니다. 이 정보를 통해서 서로 연락을 취해서 성사되면 "약속이 성사된 배움들"로 종이를 이동하고 몇시에 어느곳에서(이날은 테이블에 번호를 매겨서 번호를 표시) 할 것인지를 적고 정보를 공유하는 자리를 만들어서 진행이 되었습니다. OST는 배움은 아니지만 이야기해보고 픈 주제들에서 적고 사람들이 모이면 진행이 되고 World Cafe는 좀더 심도있는 토론에 대해서 진행하기 위해서 열립니다.

     

사실 이런 방식의 행사자체가 처음이라 잘 이해가 되지 않았었습니다. 시간표에 unconference라고 나와있었지만 어떤 형식의 행사인지도 몰랐고 최승준님이 나와서 오전에 한번 설명하고 저녁먹기 전에 다시 설명을 했지만 2번 설명을 들으면서도 저걸 왜 설명하는지 제대로 감을 잡지 못했고 막상 unconference가 시작되었을때도 정확히 어떻게 배움이 성사가 되는거고 진행된다는 것인지 잘 몰랐습니다. 이런 식의 행사가 제대로 되려나 싶은 걱정도 좀 있기는 했지만 처음에는 다들 망설이고 고민하고 있었지만 시간이 좀 흐르자 다양한 자리에서 다양한 주제에 대한 자리들이 열렸고 상당히 자유롭고 활발한 모임이 구성되었습니다.

   

저는 "Github로 오픈소스 프로젝트에 참여하기"를 듣고 대충 여기저기 기웃거리면서 구경다니다가 펭귄너구리님의 적극적인 권유로 1월에 봄싹에서 발표하려고 준비했던 자료를 가지고 node.js에 대해서 LETS를 진행했습니다. 초반에는 몇명이서 시작했는데 곧이어 많은 사람들이 모여서 긴장하기도 했습니다. 막상 이런 자리를 열고 나니 참으로 다양한 관심사(개발뿐만 아니라 화성학이나 그림그리기 같은 다양한 주제에 대한 LETS가 진행되었습니다.)에 대해서 잘 아는 사람들이 많구나 싶기도 했고 초반에 LETS를 아주 어렵게 생각했는데 나도 나눌수 있는 거리가 약간은 있구나 싶은 생각이 들었습니다.

이번 대안언어축제에서 저로써는 가장 인상적인 행사였고 즐거운 자리였지만 2시간정도 진행된 이후에야 맨앞에 스크린을 통해서 어떤 자리에서 어떤 행사가 진행되고 있는지를 표시했는데 이런 부분이 초반부터 진행되었다면 진행이 더 순조로왔을꺼라는 생각이 들었습니다. 사실 관심이 있던 주제들도 시작시간을 못 맞춰서 또는 이미 끝난뒤에 그런 주제가 있었다는 것을 알게 되었던 경우가 좀 있었습니다. 이런 자리가 처음인 사람들에게는 초반에 어떤 행사인지를 파악하는데 시간이 좀 걸리기도 했고요.

재미있는 튜토리얼

클린코드 - 이준하
하룻밤을 보내고 둘째날 오전은 재미있는 튜토리얼이라는 행사로 진행이 되었습니다. 여러가지 행사가 있었지만 저는 클린코드를 들었는데 제가 기대난이도를 너무 높게 잡았는지 기대만은 못한 자리였고 더군다나 세션진행자체가 듣기에 편한 환경이 아니라서 더욱 그랬습니다. 아마도 제 예상으로는 발표하는 환경에 대한 정보가 발표자에게 정확히 공유가 되지 않아서인 것으로 생각되는데 프로젝터같은 것이 아닌 일반 PC모니터로 프리젠테이션을 진행했는데 한 20여명정도가 모이다 보니 뒷쪽에 앉아있던 저로써는 화면의 글씨가 제대로 보이지 않았고 말도 아주 집중하지 않으면 잘 들리지 않았던 탓이 상당히 있었습니다.(물론 이부분은 제 개인적 사정으로 지속적인 집중을 하지 못했던 이유도 있습니다.) 거기에 작년에 스터디했던 엉클밥의 클린코드에 나온 내용정도로 느껴졌습니다.

둘째날 오후에는 Ignite 프리젠테이션 스타일로 20장의 슬라이드를 15초씩 진행하는 방식으로 자유주제로 각 참가자가 발표하는 자리가 있었지만 체력적 고갈로 인하여 점심이후에 집으로 귀가를 했습니다.

Epilogue
행사에 대한 전체적인 느낌은 많은 세미나나 컨퍼런스등을 참여해봤지만 기존에 참여하던 것과는 성격이 많이 다르다는 느낌이었습니다. 대안언어축제라는 이름에서 축제라는 단어가 들어있듯이 개발자 혹은 개발에 관심이 있는 사람들이 모인 축제에 가깝다는 생각이 들었고 주제가 기술에만 한정되지 않아서 더욱 그렇게 느껴졌습니다. 사실 저는 대부분의 관심사가 기술에만 집중되어 있었고 그렇기에 이번 행사에서도 기술에 대해서 배우고 익히는데만 관심을 가지고 있었는데 좀 다양한 주제에 관심을 가지고 즐겼더라면 훨씬 즐거운 시간을 보냈을꺼라는 생각이 들었습니다.

너무 기술에 대해서만 들으려고 하다보니 오히려 대안언어축제의 성격에 맞추지 못해서 우왕좌왕하게 된 느낌이 있었습니다. 그리고 기술에 대한 세션에 대해서도 발표자라는 입장에서 보면 이런 식의 불특정다수를 대상으로 하는(특히 기술의 대한 관심사도 제각각인)  기술 세션에 대해서는 당연히 세션의 난이도를 초심자를 대상으로 할 수 밖에 없는데 제가 느끼기에는 대안언어라는 행사 자체를 약간은 Geek스럽고 수준이 높은 행사라고 무심코 느끼고 있었기 때문인지 그런 부분은 간과해서 세션에 대한 난이도 예상을 제대로 하지 못했던 것 같습니다.

     

이번 행사에서는 행사장 뒷편에 TEST와 FEEDBACK이라는 판이 붙어있어습니다. TEST는 세션을 듣기 전에 어떤 내용을 기대하는지 어떤 것을 배우기 원하는지를 적어서 발표자 혹은 진행자가 참고할 수 있게 하는 TEST CASE같은 역할을 하고 FEEDBACK은 행사후에 소감을 적어서 발표자에게 피드백을 주는 공간입니다. 이 방식은 전에는 보지 못했던 지라 꽤 인상적인 부분이었는데 초반에 한번 설명한 뒤에는 지속적으로 이부분에 대해서 적극적인 홍보가 좀 부족해서 시간이 갈수록 참여가 좀 적어지지 않았나 하는 생각을 하고 있습니다.

작년에 행사가 무산되었을때는 정말 많은 실망을 하기는 했고 그뒤에도 여러번 연기되는 것을 계속 보고 있기는 했었지만 행사에 대한 진행은 상당히 만족스러운 수준이었습니다. 불만하나 없을 정도로 완벽한 진행이었다는 얘기는 아지만 이정도 규모에 행사를 프로들이 진행한 것도 아닌 것을 감안하면 적당히 아마추어 냄새가 나면서(좋다는 얘기입니다.) 전체적으로 큰 문제 없는 원활한 진행을 보여주었다고 생각됩니다. 이번에 3년만에 열린거라 언제 또 열릴지는 모르겠지만 다음 대안언어축제가 열리면 좀 좋은 컨디션으로 다시 참여해 보고 싶습니다.

행사가 끝나고 와서 온라인으로 펭귄너구리님이 행사에 대한 후기를 채팅으로 공유해 보자는 제안을 하셔서 약간은 어색한(?) 인터뷰같은 성격으로 온라인상에서 진행이 되었습니다. 이 내용은 펭귄너구리님의 블로그에 올라와 있습니다.

[Book] 스매싱 북..

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

스매싱 북 - 스매싱 미디어 지음, 웹액츄얼리코리아 옮김/웹액츄얼리코리아(주)

스매싱 북은 웹디자인관련 정보를 전하는 유명한 사이트인 Smashing Magazine에서 여러 저자들이 다양한 주제들에 대해서 집필한 책입니다. 스매싱 매거진이 웹디자인과 웹개발을 모두 표방한다고 얘기하고 있기는 하지만 웹디자인(퍼블리싱 포함)쪽에 많이 치중되어 있다고 생각하는데 그런 부분은 책에서도 동일합니다. 그런 면에서는 개발자보다는 웹디자이너에게 좀더 유용한 책이 될 듯 합니다. 개인적으로 국내에서는 웹디자이너들이 웹에 대한 마인드가 좀 부족하다고 생각하고 있습니다.(개인적인 느낌이니 디자이너분들이 흥분하시는 일은 없었으면 좋겠습니다.) 웹디자인과 일반 디자인은 약간 다른 면이 있는데 보통 디자이너들은 웹도 출판물과 동일하게 보는 느낌이 꽤 있는데 그런 면에서 스매싱북은 웹디자인이라는 면을 잘 설명해주고 있기에 개념을 잡기에 좋다고 생각합니다.

"최신 웹어플리케이션에서의 사용자 인터페이스 디자인" 챕터는 웹사이트에서 UI를 어떻게 구성하고 디자인해야 하는지 설명해 주고 있고 "CSS 레이아웃의 예술과 과학"에서는 CSS로 레이아웃을 구성하는 방법을 설명해 주고 있는데 여러가지의 레이아웃형태에 대한 설명은 참고할 만 하지만 기존의 CSS에 대해서 많이 모른다면 이겨서 설명해 주는 CSS기법만으로는 좀 부족하다고 생각합니다. "웹 타이포그래피"챕터는 국내에서는 아직 타이포그래피가 많이 발전하지 않았기 때문인지 몰란던 내용도 많았고 꽤 흥미로왔습니다. 사실 국내에서 여기서 말하는 수준의 고민을 하면서 타이포그래피까지 결정하는 곳이 얼마나 있을지는 모르겠지만 한번 알아두면 좋을 만한 내용들로 되어 있습니다.

"최신 웹사이트를 위한 사용성 원칙" 챕터는 UX에 대한 사용자가 어떤 식으로 웹사이트를 사용하고 그래서 웹사이트의 메뉴나 폼등의 웹사이트 구성을 어떻게 해야하는지 설명해 주고 있습니다. "컬러 사용을 위한 가이드" 챕터는 책을 어떻게 조합하고 사용해야 하는지에 대해서 말해주고 있는데 다양한 예시들과 방법들이 있기는 하지만 내용이 그리 깊게 느껴지지는 않았습니다. "웹사이트 성능 최적화" 챕터는 많이 알려진 웹사이트 최적화 기법들을 설명해주고 있는데 내용자체는 그리 깊지 못하기 때문에 이부분에 대해서 알고 싶다면 웹사이트 최적화 기법 - UI 개발자를 위한 필수 지침서나 초고속 웹사이트 구축같은 책을 보는 것이 더 나을것 같았습니다. 또한 스매싱북같은 주제의 책에서 Apache 설정에 대한 부분은 이해를 하겠는데 PHP설정이나 MySQL에 대한 설정부분까지 짧게 다룬 건은 오히려 내용을 더 깊지 못하게 한것 같은 느낌이 있습니다.

"판매를 위한 디자인" 챕터는 웹사이트에서 물건이나 서비스를 판매할때에 대한 전력을 설명하는 부분으로 AIDA(주의: Attention, 흥미:Interest, 욕구:Desire, 행위:Action)원칙과 여러가지를 설명해주고 있는데 이런 전략에 대해서는 잘 모르기도 했고 달리 알고 있지 못했기 때문에 흥미로운 부분이 있었습니다. "주목받는 웹사이트 만드는 비법" 챕터는 어떻게 하면 웹사이트를 주목받게 할 수 있게 하는지에 대한 부분인데 중요한 내용들이기는 하지만 어떤 부분에서는 좀 뻔한 일반론이라 보는 사람에 따라 차이가 있을듯 합니다. "인터뷰 전문가에게 배우는 통찰력" 챕터는 웹디자인데 대한 여러가지 질문에 대해서 여러면의 디자이너들의 대답들을 모아놓은 챕터인데 제가 디자이너가 아니라 그런지 그냥 한번 읽어볼 정도의 내용입니다.

내용은 알찬 내용과 일반론이 좀 섞여있는 느낌이고 전문적인 내용보다는 약간 개념적인 부분에 대한 설명이 많기 때문에 어렵지 않게 읽을 수 있습니다. 큰 임팩트가 있는 느낌은 없고 너무 디자인쪽에 쏠려 있어서 인지 스매싱 매거진이라는 평소의 권리를 생각했을때는 기대보다는 좀 못한 부분도 있습니다. 왠지 처음 발간되었을때는 반드시 사야할 책정도로 생각했는데 사실 그정도까진 아닌것 같습니다.

저는 오히려 마지막 "무대 뒤: 스매싱 매거진 이야기"라는 제목으로 스매싱 매거진이 생겨난 이야기를 하는 부분이 가장 인상적이었습니다. 47살의 스벤 렌나르츠와 24살의 비탈리 프리드먼이 온라인에서 만나서 스매싱 매거진을 가볍운 마음으로 만들었고 여러가지 사건을 통해서 점점 키워나가서 지금의 스매싱 매거진까지 나오는 부분은 개인적으로 꽤 인상적이었습니다.

[Book] Head First Design Patterns - 스토리가 있는 패턴학습법..

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

Head First Design Patterns - 에릭 프리먼 외 지음 서환수 옮김 한빛미디어

언젠가부터 꽤나 많은 신뢰를 갖게 된 헤드퍼스트 시리즈로 이 디자인 패턴 책은 워낙 유명한 책이긴 합니다. 이제 읽었다는게 민망할 정도로 유명한 책이죠. 사실 이 책은 제가 대학교 3학년때인가 교재였습니다. 그때 들은 디자인패턴(정확히 수업명은 잘...) 강의해서 강사로 오신분이 이 책을 교재로 선정해서 구입했었습니다. 그때는 개발도 잘 몰랐고 디자인 패턴은 더더욱 몰랐기에 이건 뭔가 하면서 대충 봤었었는데 지금 생각하면 강사도 꽤 괜찮았고 열심히 봐둘걸 생각하며 이제야 봤습니다.

다른 헤드퍼스트 시리즈처럼 이 책도 이해하기 쉽게 설명을 잘 해주고 있습니다.  옵저버패턴, 데코레이터패턴, 팩토리패턴, 싱글턴패턴, 커맨드패턴, 어댑터패턴, 퍼사드패턴등 여러가지 패턴을 간단한 것부터 경우의 케이스를 다 만들어서 발전시켜나가면서 이해하기 쉽게 하도록 구성되어 있습니다. 헤드퍼스트시리지의 좋은 점이라면 역시 스토리를 가지고 하나를 설명하면서 사람들이 궁금해 할만한 점이나 확장해서 활용할 만한 것을 적절할 타이밍에 설명해 준다는 점인것 같습니다.

저는 패턴에 익숙한 편은 아니고 패턴 매니아도 아니지만 패턴의 중요성을 점점 느껴가고 있습니다. GoF로부터 시작해서 오랫동안 쌓인 개발의 노하우들이 패턴이라는 형태로 만들어졌기 때문에 모든 걸 패턴으로 해결해 보고자 하지는 않더라도 패턴을 이해하는 것은 OOP를 이해하는 것의 연장선에 있다고 생각하고 있습니다. 그리고 이 책에서 강조하는 것처럼 패턴을 이해하면 다른 개발자하고 의사소통을 훨씬 간단히 할 수 있다는 점도 중요한 부분이라고 생각합니다.

패턴은 OOP개발을 하면서 오랫동안 쌓인 노하우로 만들어진 것이기 때문에 간단한 팁처럼 한번 보고 이해할 수는 없는것 같지만 개념과 구조를 이해해주고 개발을 하거나 프레임워크등의 소스를 읽을때 적용해 보려고 한다면 크게 도움이 될 듯합니다. 한번에 다 이해를 할 수 있으면 좋겠지만 OOP에 대한 경험이 그리 많지 않은 저로써는 잘 이해가 안되는 부분도 있고 한꺼번에 여러가지 패턴을 이어서 보니까 잘 외워지지 않기도 했기 때문에 틈이 날때마다 참고해 보면서 봐야할 것 같습니다. 사례와 클래스에 대한 구조도 잘 나와있는 편이라 참고해 보기도 좋을듯 합니다.

[Book] 프리젠테이션 젠 디자인..

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

프리젠테이션 젠 디자인 - 가르 레이놀즈 지음 정순욱 옮김 에이콘출판

가르 레이놀즈의 지난 번 책인 프리젠테이션 젠 - 생각을 바꾸는 프리젠테이션 디자인의 두번째 책입니다. 지난 번 책이 발표자료는 어떻게 해야 하는지에 대해서 설명하는 책이었다면 이번 책은 이름에서도 알수 있듯이 좀더 구체적으로 프리젠테이션 젠에서 설명한 발표자료를 어떻게 디자인 해야하는지 구체적으로 설명해주는 책이라고 할 수 있습니다.

프리젠테이션 젠을 읽을때는 제가 발표라는 것을 할일이 전혀 없었지만 그사이에 시간이 좀 흐르다보니 발표라는 것을 할일이 슬슬 생기고 있는데 생각과 달리 어떻게 만들어야 할 지 잘 감이 안오는 터라 좀더 제대로 발표자료를 만들기 위해서 이 책을 읽었습니다.

그전에는 그렇게 까지 정확히 생각해 보지는 않았지만 프리젠티이션이라는 것을 디자인이라고 보고 있고(전혀 몰랐던 것은 아니지만 좀더 컨텐츠라는 면으로 바라보고 있었습니다.) 그때문에 이 책에서도 디자인에 대한 얘기를 하고 있기는 한데 꽤 구체적으로 가이드라인을 주고 있기 때문에 이해하기는 어렵지 않았습니다. 다만 디자인이라는 것이 획일적인 가이드라인으로 통해서 만들어지는 것은 아니기 때문에 그 실천을 통해서 좀 더 괜찮은 결과물이 나오기 까지는 많은 시간이 필요할 것으로 생각됩니다. 가르 레이놀즈도 마지막 장에서 지속적인 개선에 대해서 강조하고 있습니다.

프리젠테이션에서 중요한 부분중 하나인 글꼴부분에 대해서 글꼴에는 어떤 종류가 있고 보통 어떤 것들을 많이 사용하고 자신은 어떤 폰트를 선호하는지 설명해주고 있고 사진은 어떻게 배치해야 하는지 색상은 어떻게 선정해야 하는지(제가 디자인쪽은 문외한이라 색에 대한 설명은 저에겐 더 인상적이었습니다.) 아주 구체적인 테크닉을 알려주고 있어서 기본내용을 참고하는 것만으로도 프리젠테이션을 만드는데 큰 도움이 될 것이라고 생각하고 있습니다. 책 내내 여러가지 프리젠테이션을 예시로 보여주고 있기 때문에 프리젠테이션을 참고해보는 것만으로도 디자인을 할때 도움이 될 것 같습니다.(1편처럼 마지막에 우수 프리젠테이션에 대한 예제들도 실려있습니다.) 어떻게 디자인을 해야 사람들이 내용에 집중하고 전달을 잘 할 수 있는지도 구체적으로 설명해주고 있습니다.

다만 타이포그래피라는 것인 한글에 비해서는 영문이 훨씬 발전되어 있다고 생각하고 있는데 아무래도 번역서이기 때문에 한글폰트에 대한 추가적인 설명같은 것이 없다는 점은 좀 아쉬운 점이고 예제로 나오는 프리젠테이션의 상당부분도 한글로 번역되어서 제공되는데 프리젠테이션을 디자인이라고 생각했을때 한글로 된 타이포그래피는 (제 눈에는) 그다지 이뻐보이지 않았기 때문에 원본의 타이포그래피가 어떠했는지 비교해보지 못했지만 디자인과 타이포그래피를 참고할 때 좀 아쉬운 부분이었습니다. 원본그대로였다면 디자인의 조화로움정도를 참고할 때 비슷한 느낌의 타이포그래피를 재현할 수 있었을 텐데요.

보통 회사에서 프리젠테이션은 글자가 빽빽하거나 디자인이라고는 배경정도에만 들어가있는 정도가 거의 대부분인 것 같습니다. 별로 좋아보이지 않는 글자가 빽빽한 디자인은 만드는 사람들도 그렇지만 사실 가르 레이놀즈가 말하는 프리젠테이션의 방식을 회사내에서 했을때도 먹힐지는 잘 모르겠지만(만드는 사람들의 문제도 있겠지만 받아들이는 사람들도 그런타입의 PT를 좋아하는것 같아서요.) 일반인을 대상으로한 외부에서는 꽤 효과가 있을 것이라고 생각하기에 프리젠테이션에 대해서 고민하는 사람들은 참고해 볼만한 책이라고 생각합니다.

My Comment..
과거에는 그나마 공공사업을 하면서 PPT 통한 제안서[갑에게 사업에 대한 전략을 설명 및 제안하는 파워포인트 문서] 작업을 많이 해왔다.. 그러다보니 자연스럽게 PT 작업도 하게 되었는데 지금은 완전 그런 문서를 본지가 엄청 오래됬다.. 그나마 와이프가[웹 디자이너] 집에서 작업을 한다고, 가지고오면 그 때 어깨넘어로 보는 정도라고 해야될까.. 무튼 당장은 아니더라도 조금 더 나이가 들어서 발표를 하려면 봐두면 좋을 성 싶다.. 다만, 책을 보진 않았지만, 책에서 말하는 PT 의 개념과 공공사업 및 갑 앞에서 발표하는 PT 의 개념은 상당히 틀릴 듯 하다.. 우리 나라는 보여지는 것에 너무 민감하기 때문에..