Search results for 'javascript'

우리가 일하는 방법

2015.07.01 00:47

우리 팀은 JavaScript를 사용하여 웹 서비스나 회사 내부의 도구를 만드는 팀이다. 회사에 JavaScript를 전문적으로 사용하는 조직이 처음 만들어진 것이라 과거의 유산을 받을 필요 없이 팀의 개발 방법을 처음부터 하나하나 만들 수 있었다. 이 글에서는 팀을 만들면서 우리가 만들었던 개발 방법을  간단하게 정리한다.


처음 팀이 만들어졌을 때 우리 앞에는 과거 2~3년간 같이 업무를 같이 했다는 경험과 Github이 있었다. 경험은 각자가 가진 생각의 이질감을 줄이는데 도움이 됐고 과거의 경험으로부터 가져올 것과 버릴 것을 결정할 때도 도움이 됐다. Github은 그 자체로써 멋진 도구라는 공감대를 갖고 있었고 이전 회사에서도 SVN 대신 Git으로 이전하기 위한 논의를 진행한 적이 있기에 이견 없이 Github을 사용하기로 결정했다.


그리고 나서 가장 처음 시작한 작업은 Coding Conventions를 정하는 일이었다. 이전 회사에서 사용하던 conventions도 머릿속에 있었고 손에도 익었지만 그만큼 단점도 알고 있었기에 새로운 우리만의 conventions을 만들기로 결정했다. Conventions을 만들 때는 Google의 JavaScript Style Guide 를 기본으로 삼았다. 다양한 내용이 잘 정리되어 있다는 점에 모두의 의견이 일치했기 때문이다. 하지만 우리의 경험이나 선호도에 비춰 생각했을 때 우리와 맞지 않다고 생각하는 요소는 적절히 수정했다. Conventions를 어느 정도 만든 후에는 Github에 팀 전용의 계정을 만들고 conventions를 저장할 독립적인 저장소를 만들었다. 그리고 conventions을 markdown 형식의 문서로 만들고 저장하여 해당 저장소에 접근하기만 하면 언제든 내용을 확인할 수 있도록 했다.


업무에 사용할 에디터를 결정하고 열심히 만든 conventions를 지킬 수 있는 보조 도구를 에디터에 추가하는 것도 잊지 않았다. JavaScript를 개발하기에 좋은 에디터는 상당히 많지만 팀에서 권장하는 에디터는 Sublime Text 에디터다. 가볍기도 하거니와 확장성이 좋으며 개인이 구매해도 기업에서 사용할 수 있는 유연한 라이선스 정책을 갖고 있기 때문이다. (반대의 경우는 불가능하다.) 그리고 단축키로 conventions를 한 번에 정리할 수 있도록 플러그인을 만들었다. 또한 Jslint를 사용하여 자동으로 lint의 결과가 에디터에 반영되도록 했다. JavaScript를 사용한 개발 과정에 컴파일과 같은 과정은 없지만 lint 과정을 추가함으로써 오류가 발생할 수 있는 가능성을 낮출 수 있도록 했다.


Github의 경우 업무에서 사용해본 경험은 없지만 모두들 개인적으로 사용해본 경험이 있기에 일반적인 사용법은 크게 문제되지 않았다. 브랜치의 사용을 장려하는 Git의 특성상 브랜치의 관리 방법에 대해 논의를 했는데 생각보다 쉽게 결론이 내려졌다. 바로 GitFlow에서 사용하는 방식을 적용하는 것이었다. - 구체적인 방법에 대해서는 A successful Git branching model를 참고하기 바란다. - 우리의 경우 develop 브랜치를 중심으로 구현해야 할 기능별로 브랜치를 따고 개발한 후 develop에 머지하고 develop 브랜치에서 master 브랜치로 옮긴 후 배포를 진행하는 것을 핵심적인 방법으로 결정했다. 이 과정에서 GitFlow를 직접 사용할지 여부는 개발자가 결정하도록 했다.


Github을 사용하는 방법을 고민할 때 가장 고민을 많이 했던 부분은 코드 리뷰를 업무 과정에 녹이는 방법이었다. 각 개발자가 업무나 강의를 통해서 코드 리뷰가 가지는 장점에 대해 너무 잘 이해하고 있었기에 코드 리뷰를 업무 과정 중에 자연스럽고도 강제적으로 진행되도록 업무 과정을 짜고 싶었다. 처음 고민했던 것은 팀 저장소를 각 개인의 저장소에 포크하여 개발한 뒤 팀 저장소로 Pull Request (이하 PR)을 보내는 방식이었다. 그리고 PR을 받은 리뷰어들이 코드를 리뷰한 후 모두 동의하면 코드를 머지하는 방법이었다. 그런데 이런 방법을 택할 경우 저장소간 소스의 이동이 매우 번거롭다는 문제에 부딛혔다. 또한 로컬 컴퓨터로 체크아웃 하는 과정 자체가 포크와 유사한데 개인 저장소가 중간에 끼게 된다면 불필요하게 저장소를 복제하는 과정이 추가된다는 점도 쉽게 받아들이지 못한 이유였다. 여러 테스트 끝에 서로 다른 브랜치 사이에서 PR를 보낼 수 있다는 사실을 발견했다. - 지금 생각하면 당연한 이야기지만 다들 Github을 개인적으로만 사용했고 여러명이 사용한 경험이 없었기에 한참 돌아갈 수 밖에 없었다. - 그리고 이 방법이 불필요한 저장소의 생성을 막고 자연스럽게 리뷰할 수 있는 좋은 방법이라는데 다들 동의했다. 특히 Github의 PR 기능은 코드 리뷰를 하고 의견을 주고 받기에 매우 편리했다. 브랜치의 이름을 따는 방법에 대해서도 많은 이야기를 했는데 최종적으로 기능을 개발할 때는 'feature/기능명' 정도로만 브랜치의 이름을 정하는 수준으로 정리했다.


이런 방법에 따라 업무를 진행하면 다음과 같은 순서가 된다.

  1. 서로가 개발해야 하는 기능을 나누고 develop 브랜치에서 각 기능별 브랜치를 만든다. 반드시 develop을 기본 브랜치로 삼아야 하는 것은 아니다.
  2. 기능을 구현한다.
  3. 기능 구현이 완료되면 소스 코드를 팀 저장소의 기능별 브랜치로 push하고 develop 브랜치로 PR을 날린다.
  4. 해당 기능을 구현하지 않은 사람이 코드를 리뷰하며 코멘트를 단다. 해당 기능을 구현한 사람은 코멘트에 따라 코드를 수정하거나 본인이 작성한 코드가 더 나은 코드임을 리뷰어에게 설명하고 설득한다. 이 과정에서 온라인으로 진행이 어렵다고 판단하거나 직접 설명하는 것이 효과적이라고 생각하는 경우 직접 이야기를 하기도 한다.
  5. 리뷰 과정에서 리뷰어 사이에 의견이 나뉠 경우 서로 설득한다. 옳고 그름의 문제가 아니라 호불호의 문제인 경우 다수결을 따르기도 한다.
  6. 코드의 리뷰를 완료한 리뷰어는 리뷰를 완료했다는 사실을 표시하고 마지막으로 코드의 리뷰를 완료한 사람이 코드를 머지하고 브랜치를 삭제한다. 이 때 사전 협의 없이는 PR을 날린 사람이 자신이 작성한 코드를 머지하지 않는다.
  7. 리뷰 과정에서 문제가 발생하거나 코드를 머지하기에 충분하지 않다고 판단하는 경우 PR을 닫고 수정 과정을 거친 후 다시 PR을 날린다.
  8. 리뷰 과정 중 머지를 해서는 안되는 경우에는 PR을 닫거나 라벨을 이용하여 머지하면 안되는 PR임을 표시한다.


리뷰를 업무 과정의 필수인 방식으로 업무를 진행하면서 발생한 문제점도 있다. 예를 들어 리뷰어가 짝수이면서 의견의 충돌이 발생했을 때 의견의 조율이 어려운 경우가 있다. 그리고 리뷰를 하는데 생각보다 많은 시간이 걸린다는 점이다.


리뷰어가 짝수여서 의견 조율이 어려운 문제는 리뷰어를 홀수로 바꾸면서 자연스럽게 해결했다. 물론 하나의 소스 코드를 다수의 리뷰어가 보면 그만큼 리뷰에 걸리는 총 시간이 늘어나므로 무조건 많은 리뷰어를 배정하는 것이 좋은 것은 아니다. 하나의 PR을 리뷰하는데 적당한 인원은 3명이라고 생각한다. 물론 이 숫자는 리뷰어의 숙련도 등 여러 조건에 의해 변경할 수 있을 것이다.


리뷰에 시간이 많이 걸리는 점은 특별한 해결법이 없다는 생각을 하고 있다. 경험상 하나의 PR을 리뷰할 때 걸리는 시간은 리뷰어당 코드 작성 시간의 30% 정도이다. 따라서 3명이 리뷰를 하게 되면 리뷰에 걸리는 총 시간은 코드 작성 시간과 맞먹는 셈이 된다. 이 시간은 코드의 리뷰 후 수정된 코드를 다시 리뷰하는 과정에 필요한 시간까지 포함된 시간으로 머지까지 소요되는 총 시간이라고 할 수 있다. 시간적인 여유가 있을 때는 별다른 문제가 되지 않으나 업무 막바지와 같이 시간에 쫓기는 상황에서는 상당한 부담으로 다가올 수 있다. 이 시간을 줄이기 위해 코드를 작성한 사람이 리뷰 받을 대상 파일을 직접 지정하는 방법으로 신규 파일이나 로직의 변경이 있는 파일을 지정하기도 했다. 그러나 이미 전체 파일을 리뷰하는데 익숙하다는 점과 리뷰어도 리뷰를 통해 리뷰에 걸리는 시간을 점점 줄이게 되는 이유로 자연스럽게 이 방법은 사용하지 않게 됐다.


리뷰 과정을 통해 각 구성원들이 짜는 코드의 형태가 유사해지면서 다른 사람이 작성한 코드를 볼 때도 이질감을 없앨 수 있었다. 그리고 좋은 코드를 서로 칭찬하고 자신의 코드에 반영함으로써 각자의 실력이 향상되는 결과를 얻을 수 있었다. 반대로 수정 요청을 하는 경우 초기에는 코드 작성자의 감정이 조금씩 상하는 일도 있었으나 한, 두달의 리뷰가 계속되면서 감정이 상하는 일은 사라지고 서로 토론하고 더 좋은 방법을 찾는 분위기가 정착된 상태이다.


그러나 이 방법은 처음 팀에 합류하는 사람에게는 매우 큰 스트레스가 된다. 첫째, 리뷰라는 익숙하지 않은 업무 습관에 익숙해져야 한다. 많은 개발자들이 코드 리뷰를 시도하지만 여러 이유로 실패하곤 한다. 따라서 코드 리뷰라는 익숙하지 않은 개발 방법과 리뷰로 인해 필요한 일정 문제로 많이 힘들어하고는 한다. 둘째, 리뷰하는 과정에서 코드와 자신을 분리하는데 시간이 필요하다. 초기에는 대체로 코드 리뷰를 통해 코드가 아닌 개발자를 공격하는 듯한 인상을 받는다. 특히 초기에 기존 코드에 익숙하지 않기 때문에 리뷰를 통해 다른 개발자들에 비해 상대적으로 많은 이야기를 듣게 되는데 이 과정을 지나는 일이 쉽지많은 않다. 셋째, Coding conventions과 프로그래밍 패턴에 익숙해지는 것이 쉽지 않다. 신입 개발자가 아닌 이상 기존에 본인이 사용하던 스타일이 있고 그 스타일에 익숙해져 있는 상태인데 리뷰를 통해 기존의 스타일이 부정당하는 경우가 많다. 이것을 극복하면서 팀의 패턴을 받아들이고 개선할 부분에 대해 의견을 개진하는 일은 항상 쉽지 않다.


초기에 팀이 소규모일 때 이런 방법을 만들고 팀이 성장하면서 일반적인 규모의 팀 내에서는 잘 동작하는 것을 확인할 수 있었다. 이렇게 일하는 방법을 주변에 이야기하면 대규모 팀 혹은 여러 팀으로 이루어진 조직에서는 잘 적용되기 어렵지 않느냐는 질문을 받는다. 냉정하게 이야기하면 적용해본 경험이 없으므로 무조건 잘 된다고도, 실패할 수 밖에 없다고도 이야기하기 어렵다. 쉽지는 않겠지만 일단 시도해보는 것이 중요하다고 생각하며, 편의에 따라 예외상황을 만들지 않고, 개발자들끼리 많은 이야기를 하는 것이 이 방법으로 대규모로 적용하는데 중요한 요소가 되리라 생각한다.


생각해보건데 지금의 팀을 처음 만들면서 다행이었던 점은 처음 팀이 일하는 방법을 만드는데 충분한 시간을 쓸 수 있었다는 것이다. 그리고 그 시간동안 서로가 생각하는 다양한 방법을 이야기하고 시도해볼 수 있었다. 아마 이런 경험은 과거에도 없었고 앞으로도 높은 확률로 얻기 힘든 경험이 아닐까 하는 생각을 해본다. 다른 개발자에게도 이 방법이 도움이 되면 좋겠다.


nundefined ETC git, gitflow, Github, javascript, 개발방법, 자바스크립트, 코드리뷰, 코딩컨벤션

  1. Blog Icon
    정남훈

    좋은 글 잘 읽고 갑니다.

  2. 고맙습니다~ :)

  3. 코드리뷰를 할 때 참고할만한 기사
    http://www.bloter.net/archives/238819

fluent 2013에서 관심 있는 세션

2013.03.01 12:09

JavaScript와 HTML5를 주제로 하는 Fluent 컨퍼런스가 5월 28일부터 30일까지 샌프란시스코에서 열린다. 한 번쯤 가보고 싶은 컨퍼런스지만 이래저래 연이 닿고 있지 않은 컨퍼런스다. 트위터를 돌아다니다가 누가 이 컨퍼런스에 대해 이야기했길래 가볍게 스케쥴을 살펴보다가 관심이 생기는 세션 몇 개를 정리해본다.


Secrets of Awesome JavaScript API Design

혼자만 사용할 기능을 만드는 것이 아니라면 항상 고민하게 되는 주제이다. 설명 중 APIs are developer UX.라는 표현이 와닿는다.


Who Killed My Battery: Analyzing Mobile Browser Energy Consumption

모바일 브라우저와 배터리 소모량의 관계라니. 삼성전자와 같은 곳에서는 이에 대한 정보가 있겠지만 그 누구도 이야기해주지는 않는다. 웹서비스 회사에서는 관심도 없고 측정하려 하지도 않고. 좋은 정보를 얻을 수 있을 것 같다.


Web Components: A tectonic Shift for the Web Platform

아직 널리 퍼지진 않았지만.. 조금 더 보기 좋은 웹을 만드는데 도움이 될 것이라고 생각한다.


How To (Semi-)Automate JavaScript Refactoring

Refactoring에서 한 번 낚이고, Automate에서 두 번째로 낚이고, (Semi-)에서 빵 터졌다. 보다 좋은 코드를 만드는데 도움이 될 것 같다.


Break Out of The Browser With HTML5

구글 패키지드 앱이 주제로 보이는데.. 들어본 적이 있는 것 같기도 하고 아닌 것 같기도 하고 가물가물하다. 구글 확장 프로그램을 볼 때 봤던가.. 각설하고, Google Packaged Apps가 업데이트 됐다보다. 이에 대한 세션. 브라우저 바깥에서도 의미있는 HTML5를 만드는 좋은 도구가 될 듯.


Improving JavaScript Code Quality: Strategies and Tools

코드의 퀄리티가 생산성이나 총 운영비용의 감소로 이어진다는 이야기는 개발자 사이에서 많이들 하는 이야기고 -내가 모르는 어느 곳엔가- 이에 대한 연구 결과도 있을 것으로 예상된다. 하지만 최근의 내 주위에서는 동작만 하면 장땡이라는 사업가들이 너무 많아서 뭐가 옳은지 혼란스럽다. 어쨌든.. 2~3년 전에 시도했다가 지금은 싸그리 없애버린 JavaScript Code의 품질에 대한 세션. 아마 계속 했으면 이런 것도 가능했을라나.


An Overview of ECMAScript6

다음 버전의 자바스크립트 표준인 ECMAScript6에 대한 세션. 올해 말까지 표준 제정이 끝나고 나면 내년부터는 이 표준을 사용할 수 있는 브라우저들이 훨씬 많아질 것이다. 전공 필수 과목같은 느낌으로 들어야 할듯.


Scraping the World with JavaScript

Node.js로 만드는 크롤러와 스크랩퍼라니.. 재미있을 것 같다. 만들어보고 싶은 것이 있어서 Python 공부를 좀 해봤는데 그냥 때려치고 Node.js로 가버릴까..;;



세션들을 살펴보다가 들은 생각은 클라우드로 백엔드 하나쯤은 구성할 수 있어야 한다는거랑 WebRTC가 있는데 소개만 봐서는 며칠 전에 한 Getting Started with WebRTC와 큰 차이가 없어보인다는 것.


Fluent는 작년의 경우 컨퍼런스 참석자들에게 모든 세션의 동영상을 제공해줬는데 올해도 그럴지 궁금하다. 주변에 컨퍼런스 가는 사람이 없을지 잘 찾아봐야겠다.







nundefined HTML5_JS_CSS code quality, ECMAScript, ecmascript6, fluent, fluent conf, html5, javascript, node.js, refactoring, web components, webrtc

자바스크립트를 배우는 좋은 방법

2013.02.16 01:10

자바스크립트를 배우는 좋은 방법이라는 글이 올라왔는데 상당히 수긍할 수 있는 내용이라 간단히 요약하고 의견을 추가해본다. 원문은 http://net.tutsplus.com/tutorials/javascript-ajax/the-best-way-to-learn-javascript/ 이다.


0번째: 어떤 것이 자바스크립트인지 이해하기

자바스크립트가 정확히 무엇을 의미하는지를 이해해야 한다는 요지이다. 그리고 라이브러리를 사용하기 전에 자바스크립트를 먼저 익히라고 조언해준다.


첫번째: 코드카데미(Codecademy.com)에서 자바스크립트 코스 수강하기

최근 코드카데미에서 파이썬을 공부했었는데 여기서도 첫번째로 코드카데미를 추천한다. 내용이 일반인을 대상으로 하고 있기 때문에 매우 쉽게 공부할 수 있다. 


두번째: appendTo의 스크린캐스트 보기

동영상으로 자바스크립트에 대한 강의를 듣는다. 영어의 압박이 있으므로 영어에 익숙하지 않다면 한국어로 된 생활코딩을 활용해보는 것을 추천한다. http://opentutorials.org/course/49


세번째: 좋은 자바스크립트 개론서 읽기

코드카데미만 잘 들어도 어느 정도 이해가 되겠지만 좀 더 잘 알아보기 위해서 좋은 개론서를 읽으면 더 도움이 될 것이다. 사이트에서 언급한 내용은 다음과 같다.


1. A Re-Introduction to JavaScript

모질라 개발자 네트워크에 올라와 있는 글로 안타깝게도 한글로 번역된 내용은 없다. 다른 글 일부가 한글로 번역되어 있으므로 필요한 경우 https://developer.mozilla.org/ko/docs/JavaScript 를 확인하기 바란다.

2. Eloquent JavaScript

이 책은 책으로도 팔지만 온라인에 무료로 공개되어 있기도 하다. http://eloquentjavascript.net/ 기억이 맞다면 온라인에 공개된 것보다 판매되고 있는 책이 더 최신판이므로 책을 구매한다고 해서 나쁜 선택은 아닐 것이다. 다행히 이 책은 자바스크립트 개론이라는 제목으로 번역서가 출간되어 있다. http://acornpub.co.kr/book/eloquent-javascript

3. Getting Good with JavaScript

이 책은 이 글을 쓴 사람의 책이다. 위에서 설명한 두 가지와는 다르게 빠르게 익힐 수 있도록 구성했다고 하며 6시간이 넘는 분량의 스크린캐스트를 제공한다고 한다. 책을 보지 않고 속단하는 것이지만 스크린캐스트를 언급하는 것을 보니 그냥 책 팔려고 끼워넣은 것이 아닐까 하는 생각이 든다.


네번째: 파이어버그(또는 개발자 도구)를 설치하고 공부하

이 두 가지 도구 모두 자바스크립트 개발에는 빠져서는 안될 중요한 도구다. 많은 개발자들이 크롬, 사파리, 파이어폭스에서 이들 도구를 사용하여 개발한 후 IE에서 보정하는 형태로 개발을 진행하고는 한다. 개인적으로는 파이어폭스 + 파이어버그 조합보다는 크롬 + 개발자 도구 조합을 추천한다. 페이지에 방문하면 몇 가지 글에 대한 링크가 걸려 있으니 살펴보기 바란다. 참고로 상반기 내에 한국어로 된(!!!) 자바스크립트 디버깅과 테스트에 대한 책이 출간될 예정이니 이 책을 기다려 보는 것도 좋을 것이다.


다섯번째: 책 읽기

네번째까지 했다면 대략 기초적인 것을 살펴본 것이다. 이제 더 깊은 수준의 내용을 다루는 책을 볼 차례다. 추천하는 책은 다음과 같다.

1. Professional JavaScript for Web Developers

2. JavaScript 24-hour Trainer

3. JavaScript Patterns

4. JavaScript: The Good Parts

1, 2번은 일반적인 내용을 깊게 파들어간 책이고 국내에 역서는 없다. 3, 4번은 자바스크립트를 이해하고 잘 사용하는데 도움이 되는 책이다. 그리고 국내에 번역서도 출간되어 있다.


여섯번째: 직접 만들기

책에 포함되어 있는 예제를 가지고 이리 저리 바꿔보거나 실제로 뭔가 만들어보는 것이 좋다. 이 글에서 추천하는 프로그램은 포토갤러리, To-do 리스트, 애니메이팅 박스이다. 


일곱번째: 자바스크립트 라이브러리 배우기

자바스크립트를 많이 익혔으니 이제 슬슬 자바스크립트 라이브러리를 배울 때가 됐다. jQuery를 비롯하여 다섯 가지 정도의 라이브러리를 추천하고 있다. 아무래도 전세계적으로 - 그리고 국내에서도 - jQuery가 최고의 인기이므로 jQuery를 선택하는 편이 도움이 될 것이다. 혹시나 특이한 것을 좋아하거나 남들과는 다른 것을 해보고 싶은 분이라면 JindoJS라는 국내에서 만든 라이브러리를 써보는 것도 괜찮으리라 생각한다.


여덟번째: 자바스크립트를 잘 하는 사람과 가깝게 지내기

자바스크립트를 잘하는 사람이 많으므로 이 사람들의 블로그도 보고 트위터도 보라고 추천하고 있다. 콕 찝어서 33명의 개발자를 추천하고 있으니 참고하기 바란다. 이 외에 팟캐스트인 JavaScript Show나 이메일 뉴스레터인 JavaScript Weekly도 추천하고 있다. 


이 글에서 언급하고 있는 정도를 공부하고 계속해서 뭔가를 만들어본다면 자바스크립트 실력이 상당히 늘어날 것이다. 주로 해외의 자료가 대부분이지만 몇몇 책들은 국내에 번역서가 나와 있고 라이브러리에 관련된 책은 워낙 많이 출간되어 있으므로 실제 공부를 하는데 큰 지장은 없을 것이다. 가장 중요한 것은 많이 만들면서 다양한 경험을 쌓는 것이다.


자바스크립트를 공부하기 위해 무엇부터 시작해야 할지 고민 중이라면 이 글에서 추천하는 방식을 따라보면 어떨까?


nundefined HTML5_JS_CSS javascript, javascript patterns, javascript show, javascript weekly, JavaScript: The Good Parts, jindo, jindojs, JQuery, 공부, 더글라스 크락포드의 자바스크립트 핵심 가이드, 자바스크립트, 자바스크립트 개론, 자바스크립트 코딩 기법과 핵심 패턴, 코드카데미

  1. 크롬 확장프로그램 같은것도 자바스크립트로 만드는건가요

  2. html, javascript, css와 같이 일반적으로 웹페이지를 만드는 것과 동일한 기술을 가지고 만들 수 있습니다.

Codecademy 이용 후기

2013.01.29 00:23

며칠동안 파이썬 공부를 시도해봤다. 몇 년 전에 책을 사서 보기도 했고, 업무에 간단히 적용해본 기억도 있지만 워낙 오랫동안 관심 밖에 있던 언어라 다시 봐도 새로웠다. 무엇보다도 파이썬을 선택한 이유는 널리 사용되기 때문이다. 국내에서는 PHP보다 사용자가 적은 느낌이기는 하지만 해외에서는 많은 스타트업에서 파이썬을 선택한다. 심지어 구글도 처음 시작했을 때는 파이썬을 사용했다. PHP를 잘 한다고 하기에는 무리가 있지만 무엇보다도 새로운 - 그러면서도 쓸만한 - 언어를 배운다는 것에 더 무게중심을 두고 파이썬을 선택했다.


이번에 파이썬을 공부하면서는 책을 보지 않았다. 대신 Codecademy (코드카데미)를 이용했다. 일단 두꺼운 책을 들고 다니면서 살펴보는 것도 부담스러웠지만 언젠가부터 책으로 공부하는 프로그래밍은 그다지 머리에 들어오지 않기에 새로운 방법을 시도해봤다.


결론을 먼저 말하면 상당히 괜찮다. 기본적으로 실제로 코드를 작성하고 테스트를 하면서 언어를 익히도록 되어 있어 상대적으로 기억에 많이 남는다. 또한 진척률을 표시해주기 때문에 얼마만큼 왔는지 얼마나 더 가야 하는지를 쉽게 알 수 있다.


하지만 단점도 있다. 한가지는 테스트용 콘솔이 정상적인 코드를 입력했음에도 불구하고 오류를 뱉어낸다는 점이다. 성공하지 못할 경우 진척률 표시가 안되기 때문에 어떻게든 오류를 없애려고 시도하는데 사실 이런 부분은 살짝 아쉽다. 대부분의 경우 Q&A를 찾아보면 회피 방법이 있기 때문에 오류를 피하는 것은 어렵지 않다. 또한 나만 그런 것이 아니구나.. 하는 위안을 얻게 되는 것은 덤이다. 


난이도가 너무 쉬워 프로그래밍을 해본 경험이 있는 사람에게는 파이썬 언어만의 새로운 내용을 배우는 것이 아니라면 쉽게 느껴진다. 아무래도 일반인 혹은 시작하는 사람들을 위한 서비스다보니 단점이라고 할 수는 없을 것 같다. 개인적으로 아쉬운 수준. 


파이썬 외에도 자바스크립트, 웹 기초, 루비, jQuery 등등의 프로젝트가 있다. 아마 여기 있는 강의들만 모두 살펴봐도 초보자에게는 많은 도움이 되리라 생각한다. 물론, 영어의 압박은 논외의 대상이다.


파이썬의 기본적인 문법을 파악했으니 코드카데미에서 파이썬 강좌를 몇 개 더 살펴보고 Django(장고)를 살펴볼 예정이다. 학습 후에 만들고자 하는 것이 있기 때문에 장고가 큰 도움이 될 것으로 생각한다.


nundefined ETC codecademy, django, javascript, JQuery, PHP, Python, Ruby, 루비, 자바스크립트, 장고, 코드카데미, 파이썬

jsconf 2011

2011.05.11 01:00

5월 2일 ~ 3일에 걸쳐 열린 jsconf 2011가 열렸습니다. 자바스크립트 관련 행사로는 꽤 큰 행사인데요. 여기서 발표된 뉴스 중에 jQuery 제작자인 John Resig이 모질라를 떠나 칸 아카데미로 이직한다는 이야기가 있었죠. 칸 아카데미가 어떤 곳인지는 TED를 참고하시기 바랍니다. (라고 Resig이 이야기 했습니다. ^_^)

여기에서는 발표된 자료를 모아봤습니다. 아직 내용을 다 살펴보지는 못했습니다. 휴일에 잠깐 시간을 내서 보기에는 양이 많네요. 그리고 아직 컨퍼런스를 녹화한 비디오가 올라오지 않았습니다. 트위터를 살펴보니 컨퍼런스 비디오는 한 달 후 쯤 올라온다고 합니다. 살짝 묵혀뒀다가 비디오가 올라오면 같이 보는 것도 좋은 방법이 될 듯 합니다.

5월 2일
Bytes and Blobs슬라이드
Conference WIFI Redux - 슬라이드
Run your JS everywhere, with Jellyfish슬라이드
Fighting Crime and Kicking Apps with Batman.js - batmanjs.org
Hello, Jo! - 슬라이드
Bespin, Skywriter, Ace - The Past, Present and Future of online Code Editing - 슬라이드
JavaScript Powered TVs?! - 슬라이드
How quick can we be? Current data visualization techniques for front-end engineers - 슬라이드
JS for Mobile: The Enyo Framework - 슬라이드
Everything is Permitted: Extending Built-ins - 슬라이드
Artificial Intelligence, collision detection and falling in love in Pistol Slut, a 2D platform shooter. - 슬라이드

5월 3일
App vs Web - Lessons from Zappos.com
Simple, Powerful Modules for JS.Next
Telephony and Communication Apps with Node.js - 슬라이드
Pimp Your JS Library - 슬라이드
Heaven and Hell: JavaScript Everywhere - 슬라이드 (키노트)
Introducing Waterbear
Nano? Pico? Femto? Atto? Zepto! - 슬라이드
Notes on a High-performance JSON Protocol
How 2011-era JS engines compile your scripts (and why it matters) - 슬라이드
CoffeeScript as a JS/Next
Performance of feature detection

트랙 A에 대한 목록만 정리해 봤습니다. 트랙 B에 대한 정보는 다음의 링크에서 확인해보기 바랍니다. 
(트랙 A에 대한 추가 정보도 있습니다.)
https://gist.github.com/957600

그리고 5월 5일에는 node.js의 컨퍼런스가 열렸습니다. (http://nodeconf.com/) 아직 국내에서는 잘 모르겠는데 해외에서는 node.js에 대한 관심이 커보입니다.


nundefined HTML5_JS_CSS conference, javascript, jsconf, 자바스크립트, 컨퍼런스