Search results for '자바스크립트'

우리가 일하는 방법

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

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

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, 자바스크립트, 컨퍼런스

일주일간 모은 링크 #6

2011.04.25 11:43
Google URL Shortener gets an API
구글의 단축 URL서비스인 goo.gl의 API가 드디어 오픈되었습니다. 이미 bit.ly등 단축 URL 서비스를 제공하는 다른 곳에서도 제공하고 있기 때문에 빠른 시간 내에 오픈될 것으로 기대하던 참입니다. bit.ly같은 경우 이미 많은 서비스에서 사용하고 있기 때문에 굳이 구글을 기다릴 필요는 없었지만 구글이라면 뭔가 다르지 않을까 하는 기대가 있었나 봅니다. 아직 랩에 등록된 API이므로 예고 없이 변경될 수 있다는 부분이 아쉽다면 아쉬운 부분이네요. 

JavaScript에서 네임스페이스를 이용하여 구조적으로 JavaScript를 짤 수 있는 방법에 대해 설명하고 있습니다. 네임스페이스를 사용하면 코드를 다른 코드의 영향을 받지 않도록 작성할 수 있습니다. 또한 전역 변수를 사용할 경우 변수명을 모호하게 지정하거나 변수명이 충돌할 수도 있는데 이런 문제를 근본적으로 해결할 수 있습니다. (전역 변수를 사용할 경우 variable scope으로 인해 실행 속도에 영향을 주기도 합니다.) JavaScript로 복잡한 프로그램을 작성해야 한다면 이 글을 읽고 한 번 적용해보면 어떨까요?

오래된 스타일의 JavaScript에 대한 이야기입니다. 동작하는 데는 문제가 없지만 더이상 추천받지 못하는 코드를 소개하고 있습니다. 유지보수하기 어려운 코드라거나 성능상 문제가 있는 코드 등 몇 가지 피하면 좋을 코드 패턴을 정리해두고 있습니다. 복잡한 공부를 하지 않고도 이 글을 읽고 적용해보는 것만으로도 두고두고 도움이 될 코드를 만들 수 있을 것으로 생각합니다.

작년 Velocity 2010 워스샵에서 Maximiliano Firtman이 발표한 발표자료입니다. High performance라는 제목을 달고 있지만 앞부분에는 모바일 웹 환경에 대한 이야기를 포함하고 있으므로 모바일 웹 환경에 대한 기본적인 이해를 하기에도 적당한 자료입니다. 여기서 소개하고 있는 블로그의 경우 모바일 웹에 대한 좋은 자료가 많이 올라오고 있으므로 모바일 웹에 관심있는 분이라면 이 블로그를 관심있게 살펴보셔도 좋을 것으로 생각합니다.

자바스크립트 코드의 품질을 측정하는 툴로써 유명한 Douglas Crockford의 JSLint가 업데이트 되었습니다. 자바스크립트 코드의 품질을 측정하는 툴이 몇 가지가 더 있는 것으로 알고 있습니다만 JSLint 만한 것이 없죠. 여러분이 작성한 자바스크립트 코드가 얼마나 건강한지 궁금하다면 jslint.com을 방문하여 여러분의 코드를 확인해보기 바랍니다. 단, JSLint를 실행시키고 난 후에는 여러분의 기분이 상할 수 있으니 주의하기 바랍니다. 

정규 표현식을 편집할 수 있는 도구입니다. 정규 표현식과 테스트 대상 코드를 넣으면 실시간으로 선택결과를 표시해줍니다. 페이지에는 간단한 레퍼런스도 제공하고 있으니 정규 표현식에 익숙하지 않은 경우 이 페이지에서 표현식을 수정해가며 원하는 정규 표현식을 만들 수 있을 것입니다.

간단한 북마크 형태로 제공되는 JavaScript performance 도구입니다. 페이지의 DOM과 다른 부분들을 분석하여 어떤 부분을 개선하면 좋을지 안내해줍니다. 여기서 안내해주는 모든 가이드를 적용할 것인지는 각자의 몫이지만 한 번씩 검토해보면 좋을 내용들을 안내해주고 있습니다. 개인적으로는 엘리먼트의 갯수나 노드의 갯수를 알려주는 프로그램이 필요했는데 이 프로그램으로 간단하게 해결할 수 있게 되어 좋네요.

nundefined HTML5_JS_CSS API, bit.ly, dom monster, douglas crockford, goo.gl, Google, javascript, jslint, Mobile Web, Namespace, Performance, regex, Regular Expression, rejex, URL Shortener, variable scope, 자바스크립트