티스토리 툴바

모바일 개발자 없나요? 스마트폰이 만든 구인난 - 이데일리 : http://www.edaily.co.kr/News/Enterprise/NewsRead.asp?sub_cd=IE11&newsid=01646566592904960&clkcode=&DirCode=00602

처우가 좋아진다고? 글쎄다. 이미 몇번의 이런 "난"을 지켜본 사람으로서, 약간 높은 연봉으로 들어가는 사람들이야 계약직 혹은 단기간 프로젝트용으로 들어가거나 거품이 꺼지고 나선 찬밥신세가 되었다. 회사에서 적절한(말 그대로 '사장님'입장) 연봉보다 높기에 장기적으로 유지하기 힘든 면도 있을 테고 스페셜리스트로 뽑은 만큼 해당 분야에 대한 투자가 사라지면 사람도 사라져야 하기 때문일테다. 또한 특정 분야가 '뜬다' 하면 우후죽순처럼 모여드는 이분야 사람들의 특성상 곧 '레드오션'이 되면서 단가가 싸져버린다.

많은 사람들의 오해. 어떤 분야가 뜨는데 회사에서 그걸 하려면 어떤 방법을 써야 할까에 대한 대답으로, 그 분야 해본 사람 한두명 데려다가 돌리면 되지 않냐라고 한다. 회사에서 어떤 어플리케이션을 개발하는데 그 플랫폼만 알고 있는 사람 데려오면 끝나는 걸까? 그 회사는 대단한것 같다. 개발 프로시져가 매우 잘 정돈되어 누구든지 몇일만에 완전 적응할 수 있나 보다. 더불어 그 회사의 의사결정자들은 신규 분야에 대해 너무나 잘 알고 있어 맨먼스 계산 딱 해서 프로젝트 예측을 바로 해 낸다. 존경스럽다.(물론 개발자들이 피토하는 거겠지만)

몇몇 회사들은 개발센터를 제대로 운영하고 있다는 소식이 종종 들려 이바닥도 많이 개선중이라고 생각이 들지만 다시 이런 식의 뉴스를 접할때면 아직도 가슴이 답답하다.

적절한 개발조직이라면, 새로운 플랫폼으로 개발하는데 3~6개월 정도의 파일롯팅을 가진다면 실제 개발을 진행할 수 있는 모드로 변경이 될 수 있거나 적어도 어떤 부분을 보충해야 하는지 알 수 있을 것이다. 구지 해당 분야의 경험자를 직접 채용하지 않더라도 컨설팅만으로도 해결 할 수 있다고 본다. 어떤 사업에 승부수를 던지기 전에, 몇개월 전에라도 살살 준비만 해도 저런 기사가 나올리 없는 것이다. 혹은 그 사업에 아직은 관심만 있고 큰 욕심은 없는 것인지도 모르겠지만 말이다.

나의 몇번의 이직 경험에서, 새로운 노하우를 습득해 나가는 것 보다는 개발 프로세스를 만들거나 내가 거기에 적응하는 과정이 더욱더 비용이 컷다. 야식 비용이 발생하였을 때 어떤 카드로 결제해야 되고 영수증을 누구에게 내면 언제 월급에 정산되어서 나오는가 같은 "조직 생성 비용"이 가장 크지 않나? 예제가 농담 같지만, 사실 어떤 사안들을 누구와 어떻게 커뮤니케이션해야 되는가 하는 문제는 중요하다고 생각한다.

주먹구구식 급 인재채용보단, 사내 개발 프로세스 잘 만들어 두고, 멍청하지 않은 개발자만 계속 뽑고 유지하고 키우다 보면, 뻥튀기 기계 플랫폼이 갑자기 뜬다 하더라도 대처 할 수 있을 것이다.

덧.
iPhone 개발툴이야 애플에서 웹 회원 등록하고 조금 뭐뭐뭐 하면 개발툴 받을 수 있다. 자신의 폰에 올리려면 10만원/년이 들지만 에뮬레이터만 그냥 올라간다. Android는 돈 안내도 자신의 폰에는 올릴 수 있다.
개발자들이어, 요즘 이분야 뜬단다. 각 부분마다 책 한권 천천히 읽으면 대충 할 수 있다. 매니저에게 연봉 50%쯤 인상해 달라고 해보자. 책한권 = 4만원 언더? 뭐 공개된 개발 메뉴얼도 있는 것 같고... 밤에 오락할 수 있는 시간이나 황금 주말이 당분간 사라질지도 모르지만 해볼만한 투자 아닌가? 단 최대한 빨리 승부를 봐야 한다.
(물론 나의 경우 저짓 했다간, 연봉은 그대로인체 일만 50% 늘어날지도;;;)

덧2.
아... iPhone질 하려면 맥을 사야 하네;;; 돈 몇장을 써야 할 듯 하지만... 기회인거다. 새삥 iMac을 드디어 장만할 수 있다. 아내/남편의 재가가 쉽게 떨어 지지 않을까?
이전에 "대단한 PHP"란 글을 쓴적이 있다. 1년이 넘어선 지금, 우선 한가지 사실을 더 알았다. null이어도 동일하다. 즉 null 혹은 false인 벨류는 어떤 첨자로 엑세스를 하려 해도 null이 나온다.

$a = null; // or false
var_dump($a['anyIndex']);
 최근에 리뷰중 아래와 같은 코드를 봤다.
list($a, $b) = getSomeFunctionThatReturnArrayOrNull(...);
엄격한 검사를 요구하는(특히 세그폴이 잘나는) 언어를 쓰다보니 리턴값이 null일 때 문제가 없느냐고 질문하니 위의 이유로 인해 두 변수 모두 null로 셋팅이 잘 된다는 것이다. 즉 에러 케이스때 둘중 한 변수만 null 검사를 하면 구지 리턴값이 널인지 확인하고 각 변수에 어사인 할 필요 없이 위처럼 바로 쓸 수 있다는 것이다.

아무튼 그사람과는 워닝 한줄도 없이 저런 식의 처리가 가능한게 구려~ 라고 이야기 하다가 나눈 대화(대충 각색).

겐도 : 아닌거 같아요. PHP 언어에서 저 피쳐를 생각한 사람은 정말 대단할걸요?
상대방 : 어떤면에서요?
겐도 : 저 성격을 안다면 저의 많은 코드들이 상당히 간단하게 변경될 수 있겠군요. 함수 리턴이나 로직의 디자인만 잘한다면 쉬운 흐름의 로직을 작성할 수 있어요.
상대방 : 그런 부분이 있군요.
겐도 : 그럼 지금 까지 보아온 험블하다고 생각한 코드들이.. 사실 그 코드를 작성한 사람들은 저런 성질을 잘 알고 작성한 코드였군요!!! 오호.. 대단하여라.
상대방 : 정말 그런지는 며느리도 모르겠죠 :)

사실 위의 특성은 이런 장점보단 대충대충 짜도 에러케이스가 스무스 하게 넘어갈 수 있다는 성질이 있다. 마치 PHP의 magic_quote처럼 코더의 실수를 언어가 커버해 준다. 물론 다른 악영향이 많긴 하지만, 일단 컴파일 제대로 하는데 며칠씩 걸리는 어려운 언어 보다야 초보들이 접근하기 쉽게 한다.

~~~~~~~~~~

자신이 아는 만큼 세상(월드, 계)이 보이는 것이다.
자신의 밥줄로 쓸 만큼 잘 아는 언어라도, 오히려 밥줄이기에 매일 그 부분도 공부다!
"프로그래밍을 학습 하는 후배들에게" from 써니의 一生牛步行
저 글을 읽다가 생각난것(길어서 미투에 못적고 여기에)

어제 후배랑 이야기하다가, 후배가 새로운 영역으로 들어와서 전문가가 되기 위해 여러 분야를 거쳐 보고 싶다는 예기를 했다. 그래서 빠르게, 대충 맛만 보고 다음 영역으로 가겠노라고 이야기 하길래...

어느 영역의 전문적인 능력을 보인다라고 한다면 그 영역의 중심 분야에 대한 지식도 깊어야 겠지만 연관 분야들도 충분한 깊이가 필요할테고 그냥 맛만 보는 것만으로는 이런 영역까지 가지 못할 것이다. 지식의 넓이도 중요하겠지만 각 부분의 깊이도 충분히 필요하다. 그러고 나서야 정말 자신이 원하는 정도의 능력을 가지게 되고 발휘 할 수 있을 것이다.

시간도 없는데 언제 깊이 발을 담그고 삽질해요.. 라고 말할 수 있다. 상황에 따라, 개인에 따라 답이 없는 문제일 수도 있지만 적어도 나의 케이스를 이야기 해 본다.

제일 처음 Basic으로 프로그래밍을 시작했다. 컴퓨터 학원에서 배웠는데 수강 기간을 무려 1년으로 하기 위해서인지 몰라도 IF라는 조건문 조차도 몇주에 걸쳐 다양한 케이스를 가르쳐 준다. 하루에 한가지 케이스에 대해 여러가지 상황을 접하고 문제를 해결한다. 먼저 공책에 코드를 적고 강사에게 검사를 맞고 나서야 컴퓨터를 켤 수 있었고 그런식으로 1년을 하고 나서 문법을 다 배웠다. 그리고 2년은 더 그런식으로 BASIC을 공부하였다. 중 1때부터 C를 시작하였고 C++까지 포함하여 거의 15년을 넘게 공부했다. 물론 어느 순간부터는 문법을 공부한 것은 아니지만 계속 뉴스그룹이나 게시판에서 질문도 하고 남의 질문에 답변은 물론 다른 사람이 한 답변을 찬찬히 읽어 보기도 하였다. 당시로선 거금을 주고 ISO 스탠다드 문서도 사서 보고 책을 본것만 해도 책장 몇개는 나올 것이다.

이렇게 몇번 언어를 습득 하고 나니, 물론 어떤 언어를 잠시 쓴다면 문법 레퍼런스만 보고 바로 쓸 수도 있고, 이전 회사에서는 1~2개월 후에 PHP를 거의 전문적으로 쓸 수 있게 되었으며 지금 회사에선 4시간 동안 책 한번 주루룩 읽고는 막 코드를 생성해 내고 있다. 이것이 전부가 아니다. PHP의 경우 1년이 지나서는 언어의 깊은 곳까지 바로 이해할 수 있었고 나 스스로 전문 분야에 PHP도 포함 시킬 수 있게 되었다. 현재 Java는 아직 경험이 더 필요하긴 하지만 곧 충분한 수준의 전문성을 가질 수 있을 것이라 본다. 어떤 환경, 어떤 언어든지 한달의 시간이 주어지면 바로 고급 개발자로 투입될 자신이 있고 1년이 지나면 전문가 타이틀을 나에게 부여할 자신이 있다.

나는 이것을 "학습의 가속 효과"라 부른다. 어떤 지식에 대해 토대가 세워지고, 비슷한 것에 대해서도 한번더 토대를 세우고 나면 그 두개를 비교해 볼 수 있게 된다. 각 부분마다 각 영역이 어떤 특성이 있는지를 볼 수 있게 된다. 아니 그전에 어떤 부분들이 있는지를 알게 된다. 이런 기반이 쌓이고 나면 비슷하지만 또 새로운 것을 만나게 되면 중요한 부분들을 빨리 찾을 수 있고 기존것과 비교하여 새로운 것을 빨리 분석할 수 있게 된다. 습득 시간이 줄어들게 된다. 물론 또다른 토대가 생겼기에 분석정도는 더욱더 커진다.

"바쁠수록 돌아가라"란 말이 여기에도 적용될지 모른다. 많은 영역들을 공부해야 되어 급하게 보고 넘겨야 될 것 같지만 저런식으로 하나씩 차근차근 보는 것이 후반으로 갈 수록 빨라지고 충분한 시간이 지나고 나면 총 지식양이 급하게 지나간 것 보다 엄청나게 많음은 당연할 것으로 보인다. 그리고 그 지식양의 교차점은 그렇게 긴것 같지도 않다.

뭐 대충 여기까지가 후배에게 해 준 예기이고,
프로그래밍의 기반을 닦고 있는 사람들에게 좀더 세분화 해서 말한다면,

어떤 사람은 인기있는 언어 하나 대충 배워서 시장에 뛰어 들수도 있고, 어떤 사람은 동시에 몇가지 언어책 다 쌓아두고 대충대충 해서 뭐든지 할 수 있어요를 외치며 나갈 수도 있겠지만... 나라면 하나라도 제대로 파고는 본질을 이해해서 어떤 언어가 되든 빨리 적응 할 수 있도록 만들고 나가겠다. 어차피 컴퓨터라는 것이 할 수 있는 것은 정해져 있고 단순히 속도만 빨라지고 있다. 언어라는 것도 같은 일을 하는 것을 효율적으로 빨리 짤 수 있도록 발전하는 것이지 절대 새로운 일을 할 수 있게 되는 것이 아니다. 또한 이런 이유로 인기 언어, 인기 플랫폼은 항상 변하게 되어 있다. 적어도 버전업 되면서 그냥 보기엔 개념이 확확 바뀐다.

"난 AJAX 프로그래밍을 해 봤어요"란 말은 당장 일을 구하는데 도움이 될 지 모르지만 BJAX란 기술이 나온다면 굶어야 한다. 물론 6개월 쉬면서 공부할 수도 있겠지만 그것도 한두번이다. Z까지 갈 필요없이 G쯤에서 이미 도태되고 있을 것이다. "난 컴퓨터로 할 수 있는 일이면 뭐든지 일개월 기간만 있다면 시작할 수 있어요. 물론 그 일개월 동안 요구사항 분석하고 대충 아키텍처 초안까지 만들면서요" 란 말을 할 수 있는 것이 좋다. 그리고 그렇게 되는 방법의 시작은 하나부터 모질게 파는 것이다.


디테일한 기술에 집착하지 마라. 수수께끼 잘 푸는 사람이 좋은 대접 받는 것은 아니다. 결국 돈은 수수께기 잘 만들어 내는 사람이 번다. 본질을 발견해야 한다.
"G-Test Pattern" 이 글은 내 블로그에서 유명한 글 중 하나이자, 종종 오프라인이나 온라인에서 언급이 되기도 한다. 개인적으로는 웹 개발에 있어 기본적인 테스트를 수행할 수 있도록 도와주는 획기적인 "도구"라고 생각한다. 그래서 공개하기로 마음먹었고 몇몇 서비스라도 문제 가능성을 줄어들길 바랬다. 허나 설명이 불충분 했는지 아직도 Version 1인 <gen&doh'">를 통과하지 못하는 서비스가 최신으로 공개되는 것을 보고는 통탄을 금할 수 없다.

G-Test와 관련해서 가장 많이 받는 질문이, 각 스트링 혹은 문자를 어떻게 처리해야 되는가이다. 그리고 나의 항상 대답은 "그때그때 달라요"라는 약간은 불친절한 것이었다. 매우 기본적인 것이라고 생각되어 설사 초보 개발자도 조금의 경험을 거치고 생각을 하고 나면 충분히 해결 가능한 것이라고 보았는데 역시 업계 전반적으로 구루라고 부를 수 있는 경험많은 코더들의 부족으로 답을 찾기가 힘든가 보다. 좀 친절해 보자.

예제로 '&'의 처리에 관한 것이다. 티스토리 글쓰기창(혹은 비슷한 html 편집기)에서 사용자에게 입력받아 최종적으로 RSS로 출력하는 과정의 처리방법을 고민할 것이다. 이 예제는 심지어 본인의 팀원도 잘못 생각해서 잘못 대답했다가 며칠을 구박 받았던 문제이기도 하다.(처음 당하면 매우 어려운 문제일 수도 있지만 당연한, 아니 상식이라고 할 정도의 이야기다. 이 블로그를 방문중인 많은 분들이 왜 이런 쓰잘데기 없는 것을 설명하고 있냐고 할 정도다. 허나 모르는 사람 많더라.)

편집기를 열고 사용자가 '&'를 입력하고 글을 저장한다. (1)"HTML 위지윅 편집기 모듈"에서 입력을 받아 (2)이를 POST로 (HTTP)서버에 전송하고, (3)PHP에서 DB에 저장한다. RSS를 보여줄 때 (4)DB에서 읽어와서, (5)RSS 모듈에 넘겨주면 (6)XML에 기록이 된 다음 (HTTP)RSS리더로 전송되고, (7)HTML을 지원하는 리더의 화면에 '&'로 표시되는 과정을 거친다. 중간에 (HTTP) 과정은 네트웍 레이어라 논의에서 제외하겠다.

이 과정을 막 세상에 나온 개발자에게 시킨다면 '&'는 어떻게 나올지 모른다. 허나 "&gt;"정도 되면 RSS리더가 XML이 깨졌다고 구박할 것이다. 수정하라고 하니 5번 단계에서 RSS 모듈에 넘겨줄때 htmlspecialchars(PHP의 html entity escaping 함수)한번 적어주고는 '>'라는 결과를 볼 것이며 다시 수정할 때 많은 초보 개발자들이 5번 단계에 한번 더 htmlspecialchars 함수를 쓴다. 사실 위의 단계 구분은 머리속에 들어 있지도 않고 (5)단계에서 RSS로 넘겨주는 루틴에 이스케이핑 해 주면 되겠지 하고는 정상적으로 나올 때 까지 함수를 처집어 넣다가 잘 동작한다 싶으면 버그가 수정되었다고 보고한다.

여기서 잠시, 형상관리(SVN등)와 코드 리뷰라던가 디플로이에 대한 글도 요즘 쓰고 싶은데 아직 구상 정리가 덜 된 상태지만.
많은 개발조직이 저런 상태로 넘어간다. 실서버에 버젓이 적용된다. 적어도 TnC에서는 나에게 딱 걸리고는 한두달 잔소리좀 들어야 할 것이다. 아무도 남이 작성한 코드에 관심은 없고, 아니 자신의 일 하기에도 정신없는 상황이다. 인력은 부족하고 시간은 없어서 개발자를 가르치고 발전시켜 주는 노력에 대해 신경을 제대로 쓰는 조직은 드물다. 또한 남의 코드를 가지고 왈가왈부 하는 것은 동료애에 금기시 되거나, 남에게 싫은 소리는 하지 않는 것이 좋다는 한국의 이상한 문화가 서비스를 망하게 만든다.

제대로 된(?) 개발자라면 위의 문제 자체가 무의미 하다.
(1) html entity escaping
(2) POST용 escaping
(3) DB escaping
(4) 그냥 읽어오면 됨
(5) XML모듈에 그대로 전달
(6) XML 모듈 내에서 xml-string escaping
(7) HTML Viewer가 html entity를 역변환

각 단계마다 '&'가 어떤 형태로 나오는지는 각자 알아서.

<gen&doh'">의 각 글자에 대해 어떻게 처리해야 하는지 고민하는 것이 아니라 레이어별로 인풋과 아웃풋에 대해 적절한 처리만 하면 아무런 문제가 없다. 화면에 뭔가 이상하게 출력이 되었다면 막무가내로 처음과 끝을 잡고 고민할 것이 아니라 중간단계에서 자신이 해야 할 일을 제대로 하지 않고 있는 것이니 그것을 검증하면 되는 것이다.

가령 6번 단계를 보자. XML 출력기 모듈은 출력해야 할 스트링이 Plain Text든 JSON이든 상관하지 않는다. 주어진 데이터를 잘 포장해서 다시 XML 파서가 데이터를 뽑아 내었을 때 똑같은 데이터가 나오면 된다. XML의 String Representation(표현방식)에 맞춰서 변환해 줄 필요가 있는 것이다. CDATA를 사용하지 않고 직접 스트링을 적겠다고 판단하였다면 htmlspecialchars 함수를 한번 써 주어야 한다. 반대로 5번 과정에선 DB의 HTML로 저장되어 있는 데이터를 그대로 전송해 주어야 하므로 이스케이핑을 해서는 안된다.

DB에 저장하는 SQL문을 작성하거나, HTML Tag의 Attribute에 스트링을 출력하는 경우 따옴표(")는 적절히 변환(escaping)되어야 한다. 자바 스크립트를 HTML에 기술할 때도 변환되어야 한다. HTML Tag의 Attribute까지 포함한 HTML String을 Writing하는 JS를 HTML에 기술할때는? 익숙한 개발자는 단방에 두번 이스케이핑 하겠지만(물론 급 초보도;;) 이 코드를 작성하는 생각의 과정은 두 레이어가 존재하여 이름은 같을 지언정 목표-결과가 아닌 목적-가 다른 함수를 두번 쓰게 된다.

G-Test에 들어있는 문자들은 웹과 관련된 String Representation에서 Special Charater로 사용되는 것들을 섞고는 gendoh가 제대로 보이는지 확인하는 것에 지나지 않는다. 약간의 조미료로 화면을 깨지게 만들거나 JS가 에러가 나도록 하는 트릭들이 들어 있을 뿐이다. 좀 심각하게 받아 달라고. 그럼에도 전혀 심각하지 않다고 생각하는 사람들이 대부분인듯 하지만.

데이터 처리의 기본은 이것이다. 인풋이 무엇인지, 아웃풋이 무엇인지, 그리고 그것들의 표현방식이 무엇인지 제대로 알고 작성하는 것이다. 표현방식에서 어떤 것들이 특별하게 표현되어야 하는지 확인해야 할 것이며 그렇기에 여러 종류의 Escaping 함수들이 존재한다. 대부분의 C-like 언어들이 따옴표로 스트링을 표현할 때 내부에서 따옴표를 쓰려면 역슬래쉬(\)를 사용해야 하는 것은 알고 있지 않은가. 마치 그것처럼 각각의 레이어들도 그런 것이 필요하다.

이것이 개판이 되면, 몇몇 신문사들의 RSS에서 제목에 <BR>이 보인다거나 가끔 RSS 자체가 깨져버려 그 기사가 사라질 때 까지 정상적인 구독이 불가능한 상황이 발생하는 등의 사고가 일어난다. 레이어마다의 데이터에 대한 설계미스(mistake가 아니라 miss).

제발 좀 "테스트"라는 글자가 잘보인다고 "오예~ 다짰다~"라고 넘겨버리는 짓을 하거나, 테스트 단계에서도 그 글자가 잘보인다고 OK 하는 우를 범하지 말길 바란다. 자신이 처리하는 데이터가 무엇인지 명확히 알고 정확히 처리해야 한다.

테스트라는 것은 성공하는지 검사 하는 것도 있지만 실패 안하는지 확인하는 과정이기도 함을 명심해야 한다.

PS.
이런 것도 모른체 프로그램을 작성하고 앉아 있는 것을 시간이 없어서, 기획이 쪼니까, 일단 만들고 나중에 버그수정~ 식의 말로 변명 할 수는 없다. 졸다가 한두군데 놓친다거나 사이드 이펙트로 생기기도 한다. 하지만 아예 그런 개념이 탑재되지도 않은 채 작성하는 사람도 많다. 그사람만의 문제가 아니라 상사, 동료 즉 그 팀 전체의 문제다.
오늘도 발견한 신기한 PHP의 성질.

우선 static 키워드는 뒤의 변수는 상수만을 어사인 할 수 있고 Expression은 오지 못한다.
http://www.php.net/manual/en/language.variables.scope.php 의 Example 7 참고.

이제 스트링을 어사인 하는 경우를 생각해 보자.

static $a = "a";


이경우는 문제가 없다. 허나

static $a = "$b";


이때는 스트링이 익스프레션으로 간주 되기 때문에 문법 에러가 발생한다. '$b'가 문제.

자 이제 첼린지.

static $a = "$";


$뒤에 문자가 저렇게 되면? 역시나 문법 에러가 발생한다.

Double Quoted String에서 '$'는 '\$'로 이스케이핑 하는 것이 정석이다.

대충
static $pattern = "@^gendoh$@";

에서 망했다 오늘. 코딩경력 20년차에 문법에러라니.. 쪽팔려라 ㅠ.ㅠ
레귤라 익스프레션과 스태틱이 만나면 이런 일도 발생한다.

재미있는 것은 Eclipse의 PDT나 Zend Studio에서는 '$b'는 문법 에러를 보여주지만 '$'나 '$@'만 쓰면 정상적이라고 인식한다. '$'뒤에 '{'나 alpha-numeric 이 오지 않으면 당연히 '$'는 '$' 케릭터로 인식할 수 있지만 파서의 특성 차이로 아마 이런 일이 발생하는 듯. PHP 파서는 '$'만 나타나면 익스프레션으로 파싱하는듯 하다. 그와중에 뿜는 에러명이

PHP Parse error:  syntax error, unexpected '"' in ...


쌍따옴표가 못온다고라고라;;;;;

Double Quoted String에서 '$'를 쓸땐 이스케이핑 해 주는 것이 정석일듯 하다.
사용자 삽입 이미지
자바스크립트 완벽 가이드
ISBN : 9788991268418
강컴 링크, 출판사링크, yes24
책 표지는 강컴에서 무단으로 도용;;;;

가끔씩 주장하지만 난 JS를 잘 모른다. Dojo를 사용해서 Drag-N-Drop을 구현했지만 그것은 샘플보고 따라 한 것에 지나지 않고 기초적인 문법조차 정확히 알지 못한다. 최근에 Call-By-Referance가 JS에서 되나 안되나 한참을 찾아봐야 했던 적도 있다. 아무래도 계속 이러다간 문제가 생길것 같아 막간을 이용해 JS 공부나 좀 해볼겸 이 책을 샀다.

본책 + 별책으로 되어 있고 별책은 코어 자바스크립트 레퍼런스로 구성되어 있다. 본책은 몇번 읽고 책장에 고이 모셔두고, 별책은 화면이 좁아서 헬프 보기 힘들때 찾아보면 될 것 같다. 아마 JS 1년만 제대로 파고나면 둘다 별로 필요 없을 것이다. 아직 JS의 J자도 모르는 난 당분간 봐야 겠지만.

한시간 정도 앞부분을 주욱 보는데, 나처럼 이미 다른 언어들을 경험해 보았고 ECMA-262에 대해 원래 문서 보자니 갑갑하고 해서 번역 + 케이스별 자세한 설명을 주룩주룩 보면서 JS를 빠른 시간안에 익히고 싶다면 괜찮지 않을 까 한다. 비교적 번역 품질도 괜찮고 설명도 자세하다. 허나 JS를 처음 프로그래밍 랭귀지로 선택한 사람에겐 초반은 상당히 힘든 시간이 아닐까?

이 책을 보면서 느낀 것은 언어 입문서로서의 필요한 부분이다. 나야 BASIC, C/C++, Pascal, Delphi(Object-Pascal), Scheme, ML, Prolog, PHP, C# 등등을 해 봐서 기본적인 프로그래밍 개념은 가지고 있고 JS의 언어적 특성과 문법 정도만 머리속에 넣고 나면 새로운 언어도 금방 적응할 수 있겠지만 처음 시작하는 사람에겐 생소한 개념이고-컴퓨터가 아무리 인간의 두뇌를 모델링하려고 했지만 전혀 다른 시스템이 아닌가- 특히 예제가 부족한 점은 두꺼운 책이 주는 부담감과 더불어 포기하거나 제대로 이해하지 못하게 하는 부분이 아닌가 한다. 이 책의 예제들은 나름 자세한 편이고 나야 눈으로 대충 보면 JS 인터프리팅 엔진이 되어 이해가 가지만 완벽히 독립적으로 동작하는 예제가 주어지지 않는 다는 점은 초보자에겐 어려움으로 다가올 것이다.

동작하는 예제의 중요성은 최근 기타를 배우면서 더욱더 느낀다. 5번째 위치에서 손가락 4개 차례대로 짚는 연습을 하고 있는데 가끔씩(--;) 운지에 성공하더라도 그닥 감흥이 없다. 오히려 그전에 잠시 본 C-Am-F-G7의 장난이 오히려 내가 기타를 치고 있긴 하구나라는 느낌을 준다. 처음 BASIC을 배울때도 각 구문마다(가령 if 라던가, for-loop)10~20개씩의 예제를 작성하면서 배운것이 지금껏 많은 도움을 주는듯 하다.

분명 이 책은 입문서라고 보인다. 앞의 상당 부분을 문법 설명에 할애하고 있고 매우 자세하게, 그리고 차근차근 설명해 준다. 허나 단편적인 샘플 코드는 지금 설명하고 있는 부분을 실제로 동작시키기엔 초보자에겐 너무 어렵다. 예전의 둔기형 흉기라 불리고 떨어뜨리면 발가락 사망에 배고자면 목디스크인 그책처럼 너무 과도한 예제는 문제가 되겠지만 이런 언어피쳐부터 설명하는 책이라면 적절한 예제가 중요한 부분이라 생각된다.

책 광고는 못할망정 빈정거림이 되었지만, 아무튼 혹 내가 다음에 언어를 만든다면 그 설명서엔 아름다운 예제를 만들기 위해 노력해야 겠다.


대단한 PHP

개발&Development/프로그래밍 일반 2008/05/06 16:50 posted by 겐도
$temp = false;
var_dump($temp);
var_dump($temp['abc']);

결과는?
bool(false) NULL

결코 FATAL ERROR는 일어나지 않습니다. C에서는 상상도 할 수 없는 일.
(PHP 5.1 기준)

자나깨나 리턴값확인 -ㅅ-

11번가

개발&Development/프로그래밍 일반 2008/02/28 15:37 posted by 겐도
SK에서 시도한 오픈마켓 11번가 (http://www.11st.co.kr)

사실 다른 사람들은 물건 어떤거 있나나 싼거 없나 찾아보는 동안 변태인 겐도는 소스를 보고 있었다. 메인페이지의 HTML을.

DOCTYPE 선언하고는 html 태그 전에 스크립트가 나온다거나
// 즐거운 검색 관련 변수
var _ENJOY_SEARCH_VAR_ = "NONE";
var _ENJOY_SEARCH_KEY_YN_ = "N";
이게 3번 정도 반복된다거나(아마 개별로 작업하다가 합치면서 난리가 난듯) p태그 안에 div가 있다거나.

맥용 사파리 혹은 오페라에서 조차 어느정도 신경을 쓴 듯 잘 보입니다만, 테이블 안쓰고 어렵게 어렵게 CSS로 제어한 측면은 보입니다만, 급했는지 마무리가 좀 ㅋㅋㅋ

이글의 분류가 왜 "프로그래밍 일반"인고 하니, 소스 곳곳에 느껴지는 밤샘의 흔적들 때문입니다. 몇번의 오픈일 연기도 있었지만
function funcPopPreview(prdNo){
// (1)URL을 변경했습니다.
var url = "/browsing/PreviewPop.tmall?method=getPreviewPop&prdNo=" + prdNo;
var win = window.open(url, 'PreView', "width=825, height=560, scrollbars=yes, status=no");
}
얼마나 많은 사람들이 코웍하면서 정신없는 상황이었는지 주석에 업부 보고를..
/**
* (2) 미리보기 팝업에서 부모창으로 이동해야할 필요가 있을 경우를 위해,
* 이 function도 추가를 해주셔야 합니다.
*/
function funcMoveToParent(param) {
location.href=param;
}
공지도 하기 여러운 상황.
// 2008.2.25 추가 시작
var selectedStartPage = getCookie("BROWSING_MAIN_PAGE"); // 시작페이지를 빠른으로 01, 즐거운으로 02

....

}
} catch(e) {
}
}
// 2008.2.25 추가 끝
25일이면.. --?
// 0215 위치이동 되었습니다.
strHead =strHead + '<div id="fs_gnb"></div>';
// __0215 위치이동 되었습니다.
strHead =strHead	+ '<ul id="utilLDMenu">';
strHead =strHead + '<li><a href="javascript:t_street();"><img src="/img/main/3rd/gnb_leftmn_01.gif" alt="가게많은길"></a></li>';
strHead =strHead + '<li><a href="javascript:best();"><img src="/img/main/3rd/gnb_leftmn_02.gif" alt="베스트셀러"></a></li>';
// 2015 나중에 적용 strHead =strHead + '<li><a href="#"><img src="/img/main/3rd/gnb_leftmn_03.gif" alt="해외쇼핑"></a></li>';
strHead =strHead + '<li class="end"><a href="http://www.11st.co.kr/browsing/JointBuyMain.tmall?method=getJointBuyTotalMain"><img src="http://www.11st.co.kr/img/main/3rd/gnb_leftmn_08.gif" alt="공동구매"></a></li>';
strHead =strHead + '</ul>';

원추. 그 바쁜 와중에 일일이 alt 넣어 주느라 고생하셨습니다. 사실 이근처는 JS로 문서만들기를 하고 있습니다. 그냥 html 만들기도 힘든데 JS로 만들기라니;;;
function funcSnwrEnter() {
// ENTER키가 입력 되면 저장한다.
if(event.keyCode == 13) {
funcSaveSnwr();
}
return false;

}



function funcCaptureEnter() {

// ENTER키가 입력 되면 저장한다.
if(event.keyCode == 13) {
funcSaveSnwr();
}
return false;
}
에디터도 혹시 Replace in Files 기능이 되지 않는, 노트패드 상황이었단 말인가?

아무튼 빈영역이나 수많은 주석처리된 코드들을 가진체 대략 4천라인이 되어서야 메인 페이지는 끝이 난다.
아마 1~2월달동안 급박하게 돌아갔을 개발팀 사무실이 상상이 간다. 여기저기서 비명이 들리고 기획자가 변경된 기획서 들고 후다다닥 뛰어 다니고. 사무실내 교통사고도 빈번히 일어났으리라. 이들이 두달동안 핀 담배양이나 섭취한 커피의 양이 얼마나 될까. 위에선 일정 맞추라고 쪼지, 밑에선 커뮤니케이션이 거의 불가능한 상황이었을텐데 말이다.

역시 IT는 3D 업종.

덧. 가입하면 블로그도 생성되고, OpenAPI도 있고, 카테고리별 RSS도 제공된다. 오호... 물론 나같으면 이렇게 안했을건데.
사랑하지 않으면 떠나라 상세보기
차드 파울러 지음 | 인사이트 펴냄
개발자의 자기계발과 경력관리를 위해! 소프트웨어개발자 차드 파울러의 『사랑하지 않으면 떠나라』. 회사, 기술, 경제, 가치 등이 정신없이 바뀌는 오늘, 개발자로서 맞닥뜨리게 될 변화에 적절하게 대처할 수 있도록 인도한다. 이 책은 내일도 제대로 파악할 수 없는 상황을 끝없이 만나게 되는 개발자의 자기계발과 경력관리를 위한 52가지 가르침을 전하고 있다. 가르침마다 '실천하기'를 담아 우리가 일상생활에서 쉽게
처음 배달 되었을때 또 "연예서적"을 산거냐고 다들 물었던 책. 아직 여친도 못만들면서 벌써 헤어지는 법을 공부하냐고 하지만, 이 책은 개발자의 교양 서적정도 될것이다.

저자가 인도 지사에서 일한 경험이 주로 나온다. 허나 서문에 밝히듯이 인도개발자들에 대한 책은 아니다. 오히려 종종 그들에 대한 실망을 이야기한다. 구인공고를 내면 엄청난 이력서가 들어오지만, 비록 먹고살기 위해 최선을 다하고는 있지만, 최상의 개발자는 역시 찾기 힘들다라는 이야기를 한다. 미국쪽의 직원들에 대해서도 조심스럽게 지적을 하는 부분도 있다.

IT 개발직군이라는 것이 1년이 머다하고 새로운 기술들이 쏟아져 나오고 메인스트림 역시 5~10년정도면 변화되는 곳이라 오래 버티는 것이 힘든 직군일 것이다. 책 제목대로 이 일을 정말 사랑하지 않고서는 오래 버티기 힘들다는 것이다. 더구나 한국이라면 과도한 작업량이 주어지기에 공부할 시간은 더욱 부족하다. 지금은 Java의 시대로 보이지만 몇년만 지나면 새로운 언어와 플랫폼이 시장의 메인이 될 것이다. 마치 과거의 Cobol, Fortran, C/C++이 걸어왔던 역사처럼.

삶의 질을 논하자면 낮에는 일을 하고 밤에는 자신, 가족을 챙기고 주말에는 취미와 여가를 챙겨야 겠지만 IT 특성상 개발자는 그럴 여유가 없는 것 같다. 이 일을 단순히 밥벌이로 생각하는 것이 아니라 정말 좋아해서 24/7을 여기에 매달리지 않으면 계속 해 나갈 수 없다. 나의 경우 일 자체도 꿈속에서 조차 아이디어를 만들고 개선방향을 고민하며 출퇴근시간동안 계속 새로운 책을 읽어야 하고 주말에는 새로운 언어/기술을 실험해 본다. 적어도 두달에 한번쯤 사는 책의 양이 10만원은 넘어간다. 누군가 삶의 질을 위해 개인의 생활도 충실하는 것에 대해 비난할 수는 없지만 개발자로서는 부족하다고 지적할 것이다. 다른 직업은 몇년 고생해서 자격증 한번 따면 거의 평생을 보장받지만 이 분야는 끊임없이 공부하지 않으면 불과 1~2년만에 쓸모없는 인력이 될 수도 있다.

책 내용 자체는 그리 감동적인 수준은 아닌것 같다. 허나 자신의 회고적인 생각을 할겸 읽어보는 것도 나쁘진 않을 것이다. 만원정도의 가치는 제공해 줄것이다.

직장인으로서 근무시간 정도에 열심히 일하는 것만으로 충분할 수 있다. 허나 이 빌어먹을 IT 개발직은 계속 잘 나갈려면 끊임없는 자기 희생이 필요하다. 그러기 싫다면 책의 제목대로 떠나야 할지도 모른다(아니면 한국 IT기업의 관리자가 되던지.). 자신을 돌아보자. 아직도 간단한 기능들은 구글에서 검색해 보면 된다고 할것인가? 자신은 Java 개발자이기 때문에 ASP는 절대 하지 않는다라고 주장할 것인가? 학교에서 Java를 배웠기 때문에 더이상 새로운 책을 보거나 기술을 습득할 필요가 없는가? 그렇다면 심각하게 진로를 다시 고민해 보기 바란다.

PS.
한국의 IT산업이 정체되는 것중 하나는 과도한 업무로드 때문에 자기개발을 할 수 없기 때문도 있는거 같다.

PS2.
어제 케이블에서 여러 나라에서의 사무실 환경 개선에 관한 노력들을 봤다. IT개발은 분명 지식노동이다. 그래서 뇌활동을 촉진하기 위한 별 희한한 장치들을 다 봤는데 반면 대부분의 실제 환경은 육체노동으로 보고 질서정렬한 책상에 한명씩 꼽아놓고 있다.

PS3.
역시 이 길은.. 쉬운 길은 아니다. 더구나 연봉은 점점 바닥을 치고 있지 않은가.
밥먹고 나서 발을 책상에 올리고 책좀보다 낮잠좀 잤다간 바로 책상이 사라지는 곳이 아닌가.
그리 Agile분야에 대해 깊은 경험은 없지만 그래고 읽고 보고 생각한 것들의 정리.

전통적인 패키지 소프트웨어의 개발의 경우 한번 릴리징이 되면 패치를 내거나 새 버전을 만드는 것이 어렵다. 요즘 온라인 업데이트를 할 수 있게 되어 많이 쉬워진 편이지만 그래도 적당한 마일스톤을 요구하게 된다. 이러한 릴리징 특성상 릴리징 전의 개발 과정에서 치밀한 계획, 개발, 검증이 필요하며 전통적인 개발방법론이 적용될 것이다. 현재까지의 많은 웹 어플리케이션(서비스)도 이런 전통을 이어 받아 1년에 한두번 정도 대대적인 업데이트를 하게 되며 이는 마치 기존 패키지 소프트웨어의 배포(deploy)와 비슷한 성향을 가지고 있다.

최근에 Agile이 대두되기 시작한 것은 우선 웹어플리케이션의 경우 실시간 적인 반영이 가능하고, 또한 닷컴버블 이후 실체를 빨리 대중에게 보여주어야 하는 요구사항 때문인것 같다. 따라서 원자력 발전소나 화성 탐사선에 들어갈 소프트웨어에는 피해야 할 방법이며 실시간 적인 적용과 피드백이 가능한 상황일 수록 적용도를 높여야 할 것이다. 패키지 소프트웨어라면 전통적인 마일스톤 Release 위에 중간 과정에서 부분부분 Agile적 요소를 가미하는 것이 좋을것이고 웹어플리케이션이라면 극단적인 Agile을 추구하는 것도 방법일 수 있다.

http://www.ringblog.net/1202 : 아이디어를 죽이는 조직 by 링블로그

직접적인 관계가 있지는 않지만, 아무튼 Agile의 가장 큰 적은 조직 그 자체일 것이다. 조직은 태생적으로 자신을 유지하려는 특성을 가지고 있는데(관성?) Agile의 기민하게 움직여야 하는 특성에 장애가 될 것이다. 서비스를 만드는 닷컴기업이 순식간에 붕괴한 이유중 하나는 주식을 공개하면서 주주의 의견을 반영하거나 그들에게 보여주어야 했고 얼토당토하지 않은 아이디어를 시도해 보기보단 실적위주의 시도, 보여주기식 시도를 하게 되거나 구성원들이 책임을 져야 해서 무거워 지거나 회피하는 행동을 하게 된 것이 아닐까 한다.

처음 모인 몇사람들이 회사를 창업하면 한동안은 의기투합해서 마구마구 굴러가지만 조직이 세워지는 순간 경직된다. 전통적인 회사 모델에서는 겪어야 하는 진통중 하나이기도 하다. 전에 다녔던 벤처회사가 상장기업이 되고 그 이후를 겪으면서 느낀 부분이기도 하다. 그리고 벤처에서 시작하였으나 지금 거대 기업이 된 후 변해버린 회사의 특성이 이해가 가게되는 부분이기도 하다.

최근의 서비스들이 원하는 것은 기본적으로는 지속적인 주목일 것이다. 사람들이 끊임없이 바라봐 주길 바란다. 단방에 1위 자리를 차지하기도 힘들고 상위권에 들지 못하면 돈벌기도 힘들다 보니 지속적인 혁신을 통해 이목을 계속 받아 성장해 나가길 바랄것이다. 따라서 6개월 혹은 1년마다의 서비스 변화는 문제가 되고 좀더 간격을 단축시키기 위해 Agile에 열을 올릴 것이다. 작은 개발 조직, 작은 개발 사이클, 지속적인 혁신, 계속되는 피드백, 끊임없는 팬들의 성원.

여기서 유의할 것은 Agile이 개발 기간을 단축하거나 개발 자체의 성공가능성을 올려주는 아니라는 것이다. 효율적이란 단어들이 많이 나오지만 결국은 위와 같은 환경 변화때문에 체질 개선을 한 것이지 새로운 은총알(Silver bullet)이 아니라는 것이다. 닷넷기업(포스트 닷컴기업을 비꼰 말?)들이 세상에 지속적인 이목을 끌어야 하다보니 전에는 상상도 못할 무식한 도박을 하는 것이 Agile이라고도 할 수 있다. 작은 시도등을 통해 직전 릴리즈의 기능은 흔적도 없이 폭파될 수 있는것이 Agile이다. 전통적인 개발에선 있을 수도 없는 일 아닌가(물론 그당시에는 폭파를 시키기 힘들었지만;). 각종 Agile 책에서는 약장사 마냥 빨리 고객의 요구사항을 정확히 찾아낼 수 있다거나 불필요한 노력을 없앨 수 있다고 하지만 그것은 이상적인 상황이다. 결과적으로는 부산에서 서울을 가려는데 일본에 배타고 갔다가 미국 들러서 비행기 타고 올수도 있다.

그럼 Agile의 도박 확률을 높이기 위해선? 높이는 방법은 나도 잘 모른다. 하지만 낮추는 방법은 안다. Agile을 외치면서 조직이나 개인이 기존처럼 움직이는 것이다. Waterfall 모델에서 최초 요구사항 수집 단계를 나중에 다시 피드백 받으면 되지 하면서 대충 해버리게 되면 원사이클에서 아마 흔적도 없이 회사는 폭발할 것이다. 기존의 많은 어플레이케이션들이 시도했던 마구잡이식 기능 추가의 경우 Agile을 잘못 만나면 "일단 넣고봐"가 되는데 이런 경우 다른 프로세스들이 매우 경직되게 되고 전체적인 흐름이 잘 돌지 못하게 되거나 다음 턴에서 Chaos(혼란)에 빠지게 된다.

Agile을 하면서 Analysis를 소흘히 하는 경우가 있는데 절대 안될 말이다. waterfall에서는 초반에 하고 땡이었다지만 Agile은 반대로 항상 분석하고 예측한다. Feedback이 오기 전에 Feedback에 따라 어떤 방향들이 있는지 미리 생각해야 한다. 정확히는 어떤 결정을 위해 지금 이 기능을 시도해 보는지가 필요한 것이다. 단순히 넣어봐서 사용자 증가하면 OK, 줄면 빼는 것이 아니라는 것이다. 기능을 넣고 사용자의 어떤 반응을 분석해서 다음 턴에 반영할 것인지 계획이 서야 한다. 또한 추가되는 기능셋은 가능한 범위내까진 분석이 된 것이다. 전통적인 방법들이 예측하기 힘든 부분까지 결정해야 해서 문제가 되니 최근에는 늦게 결정할 것은 미루자는 것인데 이것이 결코 결정을 대충 하자는 것이 아니라는 점이다. 기존에는 yes or no였다면 이제는 yes or no or "more information" 3가지로 분류하는 것이다. 특히 어떤 inforamtion이 필요한지 명확히 찾아야 한다. (잘 모를때는 그것을 알 수 있게 하는 information이 뭔지)

많은 Agile 책들이 자신의 상황에 맞게 점점 변해보라고 서두에 밝히고 있지만 반대로 말하면 프로젝트 몇개 말아먹을 각오 해라는 게 아닐까 한다. 적어도 Agile은 은총알-모든 고민을 단방에 해결해 줄 만병통치약은 아니라는 것은 확실할 것이다. 그저 세상에 이름을 한번 올릴 수 있는 기회를 줄지도 모를 환상의 단어일 뿐이다. 실제적인것은 실제로 개발 프로세스가 어떻게 되는 가와 운과 미국 주식시장(?)에 달려있다. 할 수 있는것은 모든 것을 버리고, 발가 벗고 뛰는게 아닐까 한다.