IT/Web Dev | Posted by 철규님(최규철) 2011. 2. 10. 00:55

웹 어플리케이션 프레임워크 - Sencha Touch


요즘은 OS/플랫폼의 춘추전국시대라 해도 과언이 아닐 정도다. 모바일 플랫폼만 해도 안드로이드, iOS, Windows Mobile, Bada, SLP(LiMo)등이 사용되고 있고, 윈도의 영향력이 막강한 PC OS에도 Chrome OS가 도전장을 내밀고 있는 형국이다.

사용 환경이 늘어나고 경쟁을 통해 많은 발전을 이뤄내고 있어 사용자들에게는 좋은 소식일지는 모르나, 어플리케이션 제작자 입장에서는 모든 OS/플랫폼을 지원해야되는 또는 일부만 지원하고 나머지는 포기해야하는 부담이 생기게 마련이다. 당연히 한번의 개발로 모든 플랫폼/OS에서 사용할 수 있는 어플리케이션 제작에 대한 욕구가 나타나는데 웹 어플리케이션이 한 가지의 답이 될 수 있을 것 같다.

하지만 아직 웹 어플리케이션 프레임워크 시장은 활성화되지 않아 주도권을 잡은 프레임워크는 없는 상태이고 몇개의 프레임워크가 주도권 다툼을 하고 있는 상태이다. 하지만 기본적으로 대부분 HTML5, Javascript 등을 기반으로 하고 있기 때문에 어플리케이션이 기존처럼 특정 환경에서만 동작하는 문제는 없을 것 같다.

대표적인 웹 어플리케이션 프레임워크인 Sencha Touch에 대해서 간략히 정리해볼까 한다.


Sencha Touch

일본산 녹차의 이름인 Sencha는 ExtJS를 기반으로 jQTouch, Raphael이 결합된 프레임워크이다. 아직 모든 플랫폼을 지원하지는 않고 iOS와 안드로이드만을 지원하는데, 플랫폼 간의 이식이 어렵지 않으므로 관련 시장만 활성화된다면 다른 플랫폼들도 지원할 것으로 예상된다.

Sencha Touch 프레임워크에 포함된 요소들을 간단하게 알아보면 다음과 같다.

  • ExtJS는 대화명 웹 어플리케이션 제작을 위한 자바스크립트 라이브러리로 AJAX, DHTML, DOM 등을 사용한다. 
  • jQTouch는 오픈 소스 jQuery 플러그인의 하나로 HTML, CSS, Javascript 등을 사용하여 Touch UI를 강화하는 기능을 한다.
  • Raphael은 SVG(Scalable Vector Graphic, 2D 벡터 그래픽 지원을 위한 XML 기반의 파일 형식)를 지원한다.


자료를 주고 받는 방식으로는 key와 Value 구조를 가진 JSON(JavaScript Object Notation)을 사용하는데 다음 예제를 보면 쉽게 이해할 수 있다.


var person = { name : 홍길동, tel : { office : 02-123-4567, mobile : 010-1234-5678 } }
alert( person .name ); // 홍길동 출력
alert( person .tel.mobile ); // 010-1234-5678 출력

Sencha Touch를 사용하기 위해서는 아래 URL에서 관련 파일을 다운로드 받는다.
http://www.sencha.com/products/touch/download/
다운로드 받은 파일의 압축을 풀고 HTML 파일을 만들어 sencha-touch-debug.js 파일과 sencha-touch-debug.css 파일을 포함 시키는 것으로 개발준비는 끝난다.

'Hello world!'를 출력시키는 예제는 다음과 같다.

helloworld.html

<!DOCUMENT TYPE=html>
<HTML>
<TITLE>Sencha Touch - Hello World!</TITLE>
<META CHARSET='utf-8'>
<META NAME='viewport' CONTENT='width=device-width, initial-scale=1.0'>
<LINK REL='stylesheet' HREF='/sencha-touch-1.0.1a/sencha-touch-debug.css' TYPE='text/css'>
<SCRIPT SRC='/sencha-touch-1.0.1a/sencha-touch-debug.js' TYPE="text/javascript"></SCRIPT>
<SCRIPT TYPE='text/javascript'>
Ext.setup({
   onReady: function() {
      new Ext.Panel({
         fullscreen: true,
         layout: 'fit',
         items: [
            { html: "Hello world!"}
         ]
      });
   }
});
</SCRIPT>
</HEAD>
<BODY>
</BODY>
</HTML>

결과 보러 가기 <IE8에서는 정상적으로 보이지 않음.>

결과 화면




 

관련 페이지

Sencha Touch - http://www.sencha.com
jQTouch - http://www.jqtouch.com
Raphael - http://www.raphaeljs.com



 

댓글을 달아 주세요

  1.  댓글주소  수정/삭제  댓글쓰기 Cynthia. 2011.05.12 15:53 신고

    정말 감사합니다.
    한번 궁금해서 시도해보고 있었는데 저같은 아무것도 모르는 사람한태 꼭 필요한 글인거 같네요.

IT/Tech Notes | Posted by 철규님(최규철) 2011. 2. 9. 22:10

[용어] Cloud computing



Cloud computing
<출처 : Wikiepedia / http://en.wikipedia.org/wiki/Cloud_computing >

아래는 Wikiepedia 검색 결과의 abstract 부분을 번역한 내용이다.


Cloud computing is location-independent computing, whereby shared servers provide resources, software, and data to computers and other devices on demand, as with the electricity grid.
클라우드 컴퓨팅은 위치 독립적인 컴퓨팅 방식으로, 이를 통해 공유된 서버는 컴퓨터나 다른 장치의 요구에 따라 리소스, 소프트웨어, 데이터 등을 제공한다.

Cloud computing is a natural evolution of the widespread adoption of virtualization, service-oriented architecture and utility computing.
클라우드 컴퓨팅은 가상화 기술의 광범위한 적용, 서비스 기반 아키텍처, 유틸리티 컴퓨팅의 자연스러운 진화이다.

Details are abstracted from consumers, who no longer have need for expertise in, or control over, the technology infrastructure "in the cloud" that supports them.
상세한 사항은 그들이 사용하는 "클라우드"라는 기술적 기반에 전문성이 없거나 그것을 제어할 수 없는 사용자들로부터 모아졌다.

Cloud computing describes a new supplement, consumption, and delivery model for IT services based on the Internet, and it typically involves over-the-Internet provision of dynamically scalable and often virtualized resources.
클라우드 컴퓨팅은 인터넷 기반의 IT 서비스에 있어서 새로운 공급과 수요, 전달 방식을 설명한다. 그리고 일반적으로 동적인 규모로 때론 가상화된 리소스의 인터넷 상 제공을 포함하기도 한다.

It is a byproduct and consequence of the ease-of-access to remote computing sites provided by the Internet.
그것은 인터넷에 의해서 제공되는 원격 컴퓨팅에 손쉽게 접할 수 있게 하는 방법의 부산물이자 결과이다.

This frequently takes the form of web-based tools or applications that users can access and use through a web browser as if it were a program installed locally on their own computer.
이것은 주로 컴퓨터에 프로그램이 설치만 되어 있다면 웹 브라우저를 통해 사용자가 쉽게 접근하고 사용할 수 있는 웹 기반 툴 또는 어플리케이션의 형태를 가진다.

The National Institute of Standards and Technology (NIST) provides a somewhat more objective and specific definition here.
미국 국립 표준 기술원(NIST)은 이제 좀 더 명확하고  구체적인 정의를 제공한다.

The term "cloud" is used as a metaphor for the Internet, based on the cloud drawing used in the past to represent the telephone network, and later to depict the Internet in computer network diagrams as an abstraction of the underlying infrastructure it represents.
"클라우드"라는 용어는 과거 전화망을 나타낼 때 사용되어오다 이후에 인터넷이 나타내는 하부 구조의 추상화를 나타내는 컴퓨터 네트웍 다이어그램을 묘사하는데 사용된 "cloud drawing"이라는 단어에서 나온 인터넷을 은유하는 것으로 사용된다.

Typical cloud computing providers deliver common business applications online that are accessed from another Web service or software like a Web browser, while the software and data are stored on servers.
일반적인 클라우드 컴퓨팅 제공자는 소프트웨어와 데이터는 서버에 저장되지만, 브라우저와 같은 웹 서비스나 소프트웨어를 통해 접근이 가능한 일반적인 온라인 비지니스 어플리케이션을 제공한다.

Most cloud computing infrastructures consist of services delivered through common centers and built on servers.
대부분의 클라우드 컴퓨팅 인프라들은 공용 센터와 기반 서버로 부터 제공되는 서비스들로 구성되어 있다.

Clouds often appear as single points of access for consumers' computing needs.
클라우드는 때로 사용자의 컴퓨팅 필요에 의해 단일 접근 포인트 형태가 되기도 하다.

Commercial offerings are generally expected to meet quality of service (QoS) requirements of customers, and typically include service level agreements (SLAs).
상업적으로 제공되는 것들은 일반적으로 사용자의 QoS 요구 사항을 만족시켜야하고, 보통 서비스 수준의 계약(SLAs)을 포함한다.

 

댓글을 달아 주세요

IT/Web Dev | Posted by 철규님(최규철) 2011. 2. 8. 22:25

[HTML5/CSS3] HTML5란?



인터넷이 일상화되고 사용자의 요구가 증가함에 따라 웹 문서에 텍스트, 표, 이미지 등을 삽입하는 기능만 가진 HTML4는 기능적 한계를 보이게 되었고, 늘어나는 사용자의 요구를 충족시키기 위해 각종 Plug-in 형태의 프로그램, AJAX 프로그래밍 등이 도입된다.

물론 HTML4가 1999년 표준이 제정된 이후, HTML4의 한계를 극복하기 위한 노력이 없었던 것은 아니다. W3C에서는 XML과 HTML을 결합하여 XHTML 규약을 만들었지만, XHTML은 늘어나는 사용자 욕구를 충족시키지 못하고 사장되어 버렸다.

Plug-in과 AJAX 등의 도입으로 인터넷 환경은 단순한 정보를 표시하던 '웹'의 수준에서 특정 기능을 수행하는 '웹 어플리케이션'의 수준으로 발전하게 되지만, 이를 위해 사용자는 추가의 플러그인 프로그램(ActiveX, Flash 등)을 설치하는 불편함을 감수하여야만 했고, 이러한 플러그인 프로그램이 지원되지 않는 플랫폼, 브라우저 등에서는 해당 웹페이지를 볼 수 없거나 웹 어플리케이션을 사용할 수 없는 문제가 생겼다.
이에 일부 브라우저 업체들이 모여 새로운 HTML 표준안을 만들기 시작했고, 이것이 W3C에 흡수되어 HTML5에 대한 정식 표준안이 만들어지게 된다.

HTML5가 아직 정식으로 완성된 표준 규약이 아니지만 현재 관심을 받고 있는 이유 또한 그 필요성을 절실히 느낀 브라우저 업체들로 부터 시작된 표준안이라는 점이다. 때문에 아직 표준안이 완성되지 않았음에도 불구하고 많은 브라우저에서 HTML5를 지원하고 있다. 현재 HTML5를 지원하는 브라우저로는 IE9 Beta, ChromeFirefox, Opera, Safari 등이 있어, 일반 사용자가 사용하고 있는 대부분의 브라우저에서 지원이 가능하다.

플러그인 프로그램이 없는 웹 환경을 목표로 한 까닭에 HTML5는 기존의 텍스트, 표, 이미지 등을 표시하는 기능에 동영상을 재생하는 태그가 정의되어 있고, 웹 어플리케이션 작성을 위한 API까지 포함하고 있다.

HTML5에서는 HTML4와 비교하여 많은 변화가 일어났는데 대락적인 변화는 아래와 같다.

  • 새로운 태그의 정의
  • 기존 태그에 새로운 속성 정의
  • 태그의 의미 변경
  • 태그의 사용 중단
  • 일부 태그의 미사용 권고
  • 사용이 중단된 속성
  • 웹 어플리케이션 제작을 위한 API

태그나 속성에 대한 변경 사항은 아래 링크를 참조하면 정확한 정보를 얻을 수 있다.

HTML5: The Markup Language Reference
Unofficial Editor’s Draft 21 January 2011

변경의 주된 흐름을 살펴보면 HTML 문서를 구성하는 태그 자체가 그 의미를 가져서 사용자에게 보여지는 화면 뿐만 아니라 HTML 코드 자체도 논리적 의미를 가지게 되었다. 예를 들어 기존의 HTML 문서에서는 문서 구분을 위해 주로 <DIV></DIV>태그를 사용하고 각 태그에 ID를 할당하여 논리적 의미를 부여하였다면, HTML5에서는 헤더에 사용되는 <HEADER></HEADER> 태그, 본문 글에 사용되는 <ARTICLE></ARTICLE> 태그, 푸터에 사용되는 <FOOTER></FOOTER>태그 등이 사용된다.

또한 눈 여겨 볼 부분이 '웹 어플리케이션 제작을 위한 API 제공'인데 아래 API들은 눈여겨 볼만하다고 생각된다.

  • Canvas 2D: 웹 브라우저에서 드로잉 기능을 제공하는 API
  • Web SQL DB: 웹 브라우저 내장 DB를 제공하는 API
  • Web storage: 웹의 내용을 사용자 컴퓨터에 저장하는 기능을 제공하는 API

HTML5의 도입으로 기존의 웹 환경은 단순히 정보를 보여주기만 하던 단계에서 사용자와의 상호 작용을 가능하게 하고, 모든 환경에서 일관적인 웹 사용 환경을 제공하는 단계로 발전하게 될 것이다. 

댓글을 달아 주세요

IT/Tech Notes | Posted by 철규님(최규철) 2011. 2. 8. 02:10

[용어] Parallel programming / Concurrent programming

Wikipedia에서 'parallel computing'을 검색하면 'parallel computing'의 검색 결과로 redirect된다. 아직 기초 지식이 없어서 두 용어의 의미가 동일한 것인지는 모르겠지만, 구할 수 있는 정보가 이것뿐이니, 일단은 확인하고 넘어가자.


Parallel computing
<출처 : Wikiepedia / http://en.wikipedia.org/wiki/Parallel_programming >

아래는 Wikiepedia 검색 결과의 abstract 부분을 번역한 내용이다.


Parallel computing is a form of computation in which many calculations are carried out simultaneously, operating on the principle that large problems can often be divided into smaller ones, which are then solved concurrently ("in parallel").
병렬 컴퓨팅은 대규모의 프로그램은 대게 작은 단위로 구분되고, 이것들이 동시에("병렬적으로") 수행될 수 있다는 원리에 기반하여, 대규모의 연산이 동시에 실행되도록 하는 형태를 가진 컴퓨팅 방식이다.

There are several different forms of parallel computing: bit-level, instruction level, data, and task parallelism.
병렬 컴퓨팅에는 비트레벨, 명령어레벨, 데이터와 태스크 병렬화 등의 몇 가지 방법이 있다.

Parallelism has been employed for many years, mainly in high-performance computing, but interest in it has grown lately due to the physical constraints preventing frequency scaling.
병렬화는 오랫동안 고성능 컴퓨팅을 중심으로 도입되어 왔지만, 주파수 제어를 저해하는 물리적 제약으로 인해 최근 관심이 증가하고 있다.
(역주: 원문의 'physical constraints preventing frequency scaling'은 물리적 제약으로 인해서 CPU의 clock frequency가 무한히 증가할 수 없는 것을 의미하는 듯 하다. CPU clock은 기술적으로는 향상시킬 여지가 충분히 있으나, 소비전력 증가와 이로 인한 발열로 인해 실용성에는 한계에 부딪혔다.)

As power consumption (and consequently heat generation) by computers has become a concern in recent years, parallel computing has become the dominant paradigm in computer architecture, mainly in the form of multicore processors.
컴퓨터의 소비 전력 문제(와 동시에 발열 문제)이 최근 들어 관심받고 있음에 따라, 병렬 컴퓨팅은 특히 멀티코어 프로세스의 형태에 있어서 중요한 패러다임이 되고 있다.

Parallel computers can be roughly classified according to the level at which the hardware supports parallelism—with multi-core and multi-processor computers having multiple processing elements within a single machine, while clusters, MPPs, and grids use multiple computers to work on the same task.
병렬 컴퓨터는 하드웨어가 병렬화를 지원하는 레벨에 따라 대략 다음과 같이 분류 될 수 있다. 한 대의 기계에 다수의 프로세서를 가진 멀티코어/멀티프로세서 컴퓨터, 클러스터, MPP, 동일한 task를 수행하는 다수의 컴퓨터를 이용하는 그리드.

Specialized parallel computer architectures are sometimes used alongside traditional processors, for accelerating specific tasks.
특정 task를 빠르게 수행하기 위해서 일반적인 프로세서를 이용한 특별한 병렬 컴퓨터 구조가 사용되기도 한다.

Parallel computer programs are more difficult to write than sequential ones, because concurrency introduces several new classes of potential software bugs, of which race conditions are the most common. 
동시성에 의해서 잠재적인 S/W 버그가 새로 나타나기 때문에 병렬 컴퓨터 프로그램은 일반적인 프로그램보다 작성하기가 더 어렵다. 대표적으로는 race condition을 들 수 있다. 

Communication and synchronization between the different subtasks are typically one of the greatest obstacles to getting good parallel program performance.
서로 다른 subtask간의 커뮤니케이션과 동기화는 좋은 병렬 프로그램 성능의 가장 큰 장애물 중에 하나이다.

The speed-up of a program as a result of parallelization is observed as Amdahl's law.
병렬화에 의한 프로그램 성능 향상의 결과는 Amdahl's law로 확인할 수 있다.



'Parallel programming'을 보다보면 'Concurrent programming'이라는 단어도 심심치 않게 볼 수 있는데, 이 단어 또한 Wikipedia에서는 'Concurrent computing'으로 결과가 redirect 된다.


Concurrent computing
<출처 : Wikiepedia http://en.wikipedia.org/wiki/Concurrent_programming >

아래는 Wikiepedia 검색 결과의 abstract 부분을 번역한 내용이다.


Concurrent computing is a form of computing in which programs are designed as collections of interacting computational processes that may be executed in parallel.
병행 컴퓨팅은 병렬 수행이 가능한 프로세스간의 상호 연산 집합체의 형식으로 구현된 프로그램에 의해서 수행되는 컴퓨팅 형태를 말한다.

Concurrent programs can be executed sequentially on a single processor by interleaving the execution steps of each computational process, or executed in parallel by assigning each computational process to one of a set of processors that may be close or distributed across a network.
병행 프로그램은 싱글 프로세서 상에서 각 프로세스의 수행 순서를 교차는 방식, 또는 각 프로세스를 제한된 또는 네트워크 상에 분산된 프로세서 셋 중의 하나에 할당하는 방식으로 실행될 수 있다.

The main challenges in designing concurrent programs are ensuring the correct sequencing of the interactions or communications between different computational processes, and coordinating access to resources that are shared among processes.
병행 프로그램을 설계함에 있어서의 가장 큰 과제는 다른 프로세스간의 상호작용이나 커뮤니케이션의 순서의 정확성을 보장하고, 프로세스 간에 공유되는 리소스에 대한 접근을 관리하는 것이다.

A number of different methods can be used to implement concurrent programs, such as implementing each computational process as an operating system process, or implementing the computational processes as a set of threads within a single operating system process.
병행 프로그램을 구현하기 위해서는 몇가지 다른 방법이 사용되는데, 각각의 프로세스를 OS 프로세스로 구현하는 방법, 각각의 프로세스를 단일 OS 프로세스내의 thread 셋으로 구현하는 방법이 있다.

Pioneers in the field of concurrent computing include Edsger Dijkstra, Per Brinch Hansen, and C.A.R. Hoare.
병행 프로그래밍 분야의 선구자로는  Edsger Dijkstra, Per Brinch Hansen, C.A.R. Hoare가 있다.


Wikipedia의 결과만으로는 (그것도 abstract 부분만으로는) parallel computing과 concurrent computing이 동일한 의미인지, 전혀 다른 의미인지 정확하게 파악할 수는 없지만, 일단 살펴본 바로는 유사한 의미를 가지지만 구현에 있어서는 약간의 차이점을 가진 개념으로 생각된다.

 

댓글을 달아 주세요

IT/Computing | Posted by 철규님(최규철) 2011. 1. 30. 17:40

[펌/번역] How Facebook Ships Code


How Facebook ships code

Facebook이 코드를 작성/적용하는 방법

원문 : http://framethink.wordpress.com/2011/01/17/how-facebook-ships-code/ 
        by
yeeguy on January 17th, 2011


I’m fascinated by the way Facebook operates.  It’s a very unique environment, not easily replicated (nor would their system work for all companies, even if they tried).  These are notes gathered from talking with many friends at Facebook about how the company develops and releases software.
나는 페이스북의 운영 방식에 매료되어있다. 그것은 매우 독특한 환경으로, 쉽게 따라할 수 있는 것이 아니다.(물론 따라한다고 하더라도 모든 회사에 그들의 시스템이 적용될 수 있는 것도 아니다.) 다음은 페이스북에 근무하는 많은 친구들과의 대화를 통해 모아진 내용으로, 페이스북이 어떻게 그들의 소프트웨어를 개발하고 릴리즈하는지에 대한 내용들이다.
 

Seems like others are also interested in Facebook…   The company’s developer-driven culture is coming under greater public scrutiny and other companies are grappling with if/how to implement developer-driven culture. 
많은 사람들이 페이스북에 관심을 가지고 있는 것 처럼 보인다. 그 회사의 개발자 주도 문화는 더 많은 공공의 관심 속에 놓였고, 다른 회사들은 그런 개발자 주도 문화를 어떻게 구현할지, 또는 구현 가능할지를 고민하고 있다.
 The company is pretty secretive about its internal processes, though.  Facebook’s Engineering team releases public Notes on new features and some internal systems, but these are mostly “what” kinds of articles, not “how”…  So it’s not easy for outsiders to see how Facebook is able to innovate and optimize their service so much more effectively than other companies.  
그런데 페이스북은 그 내부 프로세스에 대해서는 꽤 비밀스러운 편이다. 페이스북의 Engineering팀은 새로운 feature나 일부 내부 시스템에 대한 public note를 내놓지만, 이들은 대부분 "무엇"에 대한 것이지 "어떻게"에 대한 것은 아니다. 그래서 페이스북이 어떻게 다른 회사보다 더 효율적으로 그들의 서비스를 최적화하고 개선해 나가는 것이 가능한지를 외부의 사람들이 알아보기란 쉬운 일이 아니다.
In my own attempt as an outsider to understand more about how Facebook operates, I assembled these observations over a period of months.  Out of respect for the privacy of my sources, I’ve removed all names and mention of specific features/products. And I’ve also waited for over six months to publish these notes, so they’re surely a bit out-of-date.  
나 또한 한명의 외부인으로써 페이스북이 어떻게 운영되는지를 더 이해하기 위해,  나는 한달여의 기간동안 이런 관찰 자료들을 모았다. 나의 소스 제공자 개개인의 프라이버시를 위해서 그들의 이름을 지웠으며, 특정 feature나 제품에 대한 언급 또한 삭제하였다. 그리고 이 자료들이 어느 정도 시간이 지난 것이 되도록 하기 위해 이 노트를 알리기 전까지 6개월을 더 기다렸다. 
 I hope that releasing these notes will help shed some light on how Facebook has managed to push decision-making “down” in its organization without descending into chaos…  It’s hard to argue with Facebook’s results or the coherence of Facebook’s product offerings.  I think and hope that many consumer internet companies can learn from Facebook’s example.

이 노트가 페이스북이 어떻게 의사결정 사항을 그들의 조직 하부에까지, 그들을 카오스 상태에 빠뜨리지 않고 전달하는지를 어느 정도 알게해 줄 수 있기를 바란다. 페이스북의 결과물이나 그들 제품의 일관성을 놓고 논쟁하기는 힘들 것 같다. 나는 많은 소비자 인터넷 회사들이 페이스북을 예제로 배울 수 있을 거라 생각하고, 그러길 바란다.

HUGE thanks to the many folks who helped put together this view inside of Facebook.   Thanks are also due to folks like epriest and fryfrog who have written up corrections and edits.
페이스북의 내부를 볼수 있도록 도와준 많은 가족들에게 무한한 감사를 드린다. 더불어 epriest나 fryfrog와 같이 오류 정정에 도움을 준 분들에게도 감사드린다.

Notes:

  • as of June 2010, the company has nearly 2000 employees, up from roughly 1100 employees 10 months ago.  Nearly doubling staff in under a year!
    2010년 6월 기준으로 페이스북에는 약 2천여명의 직원이 있는데, 이는 약 10개월 전보다 1100여명이 늘어난 수치다. 1년만에 직원이 거의 두배가 되었다.
  • the two largest teams are Engineering and Ops, with roughly 400-500 team members each.  Between the two they make up about 50% of the company.
    가장 큰 두개의 팀은 엔지니어링팀과 운영팀인데, 각각 약 400-500명 정도의 팀원을 아지고 있다. 그 두 팀이 전체회사의 약 50%를 차지한다.
  • product manager to engineer ratio is roughly 1-to-7 or 1-to-10
    프로젝트 메니저와 엔지니어의 비율은 약 1:7 또는 1:10 정도이다.
  • all engineers go through 4 to 6 week “Boot Camp” training where they learn the Facebook system by fixing bugs and listening to lectures given by more senior/tenured engineers.  estimate 10% of each boot camp’s trainee class don’t make it and are counseled out of the organization.
    모든 엔지니어들은 4-6주 간의 부트 캠프 훈련 과정을 거치는데, 이곳에서 그들은 버그를 고치거나 선배들로부터 강연을 들음으로써 페이스북의 시스템을 배워나간다. 부트 캠프 참가자 중 약 10% 정도가 과정을 수료하지 못하고 퇴사를 권고받는다.
  • after boot camp, all engineers get access to live DB (comes with standard lecture about “with great power comes great responsibility” and a clear list of “fire-able offenses”, e.g., sharing private user data)
    부트 캠프 이후, 모든 엔지니어들은 실제 DB에 대한 접근 권한을 가진다. (물론 "큰 권력은 큰 책임과 함꼐한다"와 같은 강연도 받고, 개인 정보 공유 등과 같은 해고 사유 목록도 같이 제공된다)
  • [EDIT thx fryfrog] “There are also very good safe guards in place to prevent anyone at the company from doing the horrible sorts of things you can imagine people have the power to do being on the inside. If you have to “become” someone who is asking for support, this is logged along with a reason and closely reviewed. Straying here is not tolerated, period.”
    "사람들이 권한을 가지면 저지를 수 있는 많은 끔찍한 것들을들을 예방하기 위한 매우 좋은 안전 장치 또한 있다. 만약 당신이 어떤 지원을 요청한다면, 이것은 사유와 함꼐 기록되고 면밀히 검토된다. 이곳에서 어떤 길을 벗어난다는 것은 허용되지 않는다."
  • any engineer can modify any part of FB’s code base and check-in at-will
    모든 엔지니어는 FB code base의 어느 부분이든 수정할 수 있고, 원한다면 check-in도 가능하다
  • very engineering driven culture.  ”product managers are essentially useless here.” is a quote from an engineer.  engineers can modify specs mid-process, re-order work projects, and inject new feature ideas anytime.  [EDITORIAL] The author of this blog post is a product manager, so this sentiment really caught my attention.  As you’ll see in the rest of these notes, though, it’s apparent that Facebook’s culture has really embraced product management practices so it’s not as though the role of product management is somehow ignored or omitted.  Rather, the culture of the company seems to be set so that *everyone* feels responsibility for the product.
    매우 개발자 주도적인 문화다. "Product Manager는 기본적으로 여기서는 무용지물이다."라는 것이 엔지니어들로 부터 나온 말이다. 엔지니어들은 프로세스 중간에서 스펙을 변경할 수도 있고, 프로젝트를 재조정할 수도 있다.
    [편집자주] 이 블로그 포스팅의 저자 또한 Product Manager이다. 그래서 이러한 감성(개념)이 나의 관심을 끌었다. 하지만 앞으로 당신들이 남은 부분에서 볼수 있겠지만, 페이스북의 문화는 실제적인 제품 관리를 중요시하며, 제품 관리가 무시된다거나 생략될 정도의 비중을 차지하는 것처럼 보이는 것은 절대 아니다.
  • during monthly cross-team meetings, the engineers are the ones who present progress reports.  product marketing and product management attend these meetings, but if they are particularly outspoken, there is actually feedback to the leadership that “product spoke too much at the last meeting.”  they really want engineers to publicly own products and be the main point of contact for the things they built.
    월간 cross-team 회의에서, 엔지니어들은 진행 사항을 알리는 사람이 된다. 제품 마케팅과 제품 관리에서도 이 미팅에 참여한다. 하지만 만약에 그들이 특별나게 노골적이라면, "제품쪽에서 지난 번 미팅에 지나치게 말이 많던데"라는 피드백이 팀장에세 전달된다. 그들은 진심으로 엔지니어들이 공식적으로 그 제품의 주인이기를 바라고, 그들이 하고 있는 일의 주 접덤이길 바란다.
  • resourcing for projects is purely voluntary.
    프로젝트를 위한 인력 조달은 순수하게 지원에 의해서 이루어 진다.
    • a PM lobbies group of engineers, tries to get them excited about their ideas.
      PM은 엔지니어 그룹들이 그들의 생각에 흥미를 가질 수 있도록 노력한다.
    • Engineers decide which ones sound interesting to work on.
      엔지니어들은 어떤 일이 흥미로운지 결정한다.
    • Engineer talks to their manager, says “I’d like to work on these 5 things this week.”
      엔지니어들은 그들의 관리자에게, "이번주에는 이 다섯가지 일을 하려고 해요"라고 알린다.
    • Engineering Manager mostly leaves engineers’ preferences alone, may sometimes ask that certain tasks get done first.
      엔지니어 매니저는 대부분 엔지니어의 선택을 인정한다. 가끔씩 특성 task가 먼저 완료되어야 한다고 말하기는 한다.
    • Engineers handle entire feature themselves — front end javascript, backend database code, and everything in between.  If they want help from a Designer (there are a limited staff of dedicated designers available), they need to get a Designer interested enough in their project to take it on.  Same for Architect help.  But in general, expectation is that engineers will handle everything they need themselves.
      엔지니어들은 frontend의 Javascript부터 backend의 database code, 그리고 그 사이에 있는 모든 featrue를 스스로 관리한다. 만약 그들이 디자이너로부터 도움을 받길 원한다면, 그 디자이너들이 그들의 프로젝트에 관심을 가지도록 해야한다. 기술적 도움도 마찬가지다. 하지만 일반적으로 엔지니어들은 그들이 필요한 모든 것을 스스로 핸들할 수 있도록 요구된다.
  • arguments about whether or not a feature idea is worth doing or not generally get resolved by just spending a week implementing it and then testing it on a sample of users, e.g., 1% of Nevada users.
    어떤 특정 아이디어가 가치가 있는지 아닌지에 대한 논쟁은 그 아이디어를 실제로 구현하고 그것을 사용자 샘플에게 테스트를 함으로써 해결된다. 이 과정에 약 1주일 정도가 소요된다.
  • engineers generally want to work on infrastructure, scalability and “hard problems” — that’s where all the prestige is.  can be hard to get engineers excited about working on front-end projects and user interfaces.  this is the opposite of what you find in some consumer businesses where everyone wants to work on stuff that customers touch so you can point to a particular user experience and say “I built that.”  At facebook, the back-end stuff like news feed algorithms, ad-targeting algorithms, memcache optimizations, etc. are the juicy projects that engineers want.
  • commits that affect certain high-priority features (e.g., news feed) get code reviewed before merge. News Feed is important enough that Zuckerberg reviews any changes to it, but that’s an exceptional case.
    어떤 높은 중요도를 가진 기능에 대한 commit 사항들은 merger전에 code review를 받는다. 뉴스피드에 대한 것은 주크버그가 모든 수정 사항을 리뷰할 정도로 중요하지만, 매우 특별한 경우이다.
  • [CORRECTION -- thx epriest] “There is mandatory code review for all changes (i.e., by one or more engineers). I think the article is just saying that Zuck doesn’t look at every change personally.”
    "모든 수정 사항에 대한 코드 리뷰는 필수 사항이다. 내 생각에 이 문장은 주크버그가 모든 수정 사항을 일일이 확인하지 않는 다는 것을 말하고자하는 것 같다"
  • [CORRECTION thx fryfrog] “All changes are reviewed by at least one person, and the system is easy for anyone else to look at and review your code even if you don’t invite them to. It would take intentionally malicious behavior to get un-reviewed code in.”
    "모든 수정 사항은 최소 1명 이상으로부터 검토받는다. 시스템은 누구든 당신의 코드를 쉽게 리뷰할 수 있도록 되어 있다. 심지어 당신이 그들에게 요청을 하지 않아도. 이것은 검토되지 않은 코드가 포함될 수 있는 악의적인 행동을 감지한다.
  • no QA at all, zero.  engineers responsible for testing, bug fixes, and post-launch maintenance of their own work.  there are some unit-testing and integration-testing frameworks available, but only sporadically used.
    QA팀이 전혀 없다. 엔지니어들은 그들의 일에 대해서 테스트, 버그 수정, 사후 관리까지 모두 책임이 있다. 일부 unit-testing이나 integration-testing이 가능하지만, 드물게 사용 된다.
  • [CORRECTION thx fryfrog] “I would also add that we do have QA, just not an official QA group. Every employee at an office or connected via VPN is using a version of the site that includes all the changes that are next in line to go out. This version is updated frequently and is usually 1-12 hours ahead of what the world sees. All employees are strongly encouraged to report any bugs they see and these are very quickly actioned upon.”
    "우리도 QA팀을 가지고 있다. 단지 공식적인 QA 그룹이 아닐 뿐이다. 사무실에 있는 또는 VPN으로 연결된 모든 직원은 다음 번 출시를 위한 모든 수정사항을 포함한 버전의 사이트를 사용한다. 이 버전의 사이트는 매우 자주 업데이트 되며 세상에 공개되는 것보다 약 1-2시간 앞서있다. 모든 직원은 그들이 발견한 모든 버그를 보고하도록 매우 강력하게 요구되어 있으며, 이러한 것은은 매우 빨리 행동으로 옮겨진다."
  • re: surprise at lack of QA or automated unit tests — “most engineers are capable of writing bug-free code.  it’s just that they don’t have an incentive to do so at most companies.  when there’s a QA department, it’s easy to just throw it over to them to find the errors.”  [EDIT: please note that this was subjective opinion, I chose to include it in this post because of the stark contrast that this draws with standard development practice at other companies]
    re : QA팀이나 자동화 Unit Test가 없다는 것은 놀랍다. - "대부분의 엔지니어들은 버그가 없는 코드를 작성할 수 있다. 단지 대부분의 회사에서는 그렇게 할 동기를 가지지 못하는 것뿐이다. QA부서가 있으면, 코드를 단순히 그들에서 넘겨서 오류를 찾는것이 쉬운일이다." [역주: 주관적인 의견임을 참고 바란다. 이러한 설명이 다른 일반적인 회사의 개발 실무와의 적나라한 차이를 잘 나타내고 있어서 포함하였다. ]
  • [CORRECTION thx epriest] “We have automated testing, including “push-blocking” tests which must pass before the release goes out. We absolutely do not believe “most engineers are capable of writing bug-free code”, much less that this is a reasonable notion to base a business upon.”
    "우리는 릴리즈가 되기전에 반드시 패스해야 되는 "push-blocking" 테스트를 포함한 자동화 테스트를 갖추고 있다. 우리는 절대 "대부분의 개발자는 버그 없는 코드를 작성할 수 있다"라는 것을 믿지 않는다. 이것은 사업에 있어서는 말할 것도 없이 적절한 표현이 아니다."
  • re: surprise at lack of PM influence/control — product managers have a lot of independence and freedom.  The key to being influential is to have really good relationships with engineering managers.  Need to be technical enough not to suggest stupid ideas.  Aside from that, there’s no need to ask for any permission or pass any reviews when establishing roadmaps/backlogs.  There are relatively few PMs, but they all feel like they have responsibility for a really important and personally-interesting area of the company.
    re : PM의 영향이나 제약이 없다는 것도 놀랍다. - product manager는 독립성과 자유를 가지다. 영향력을 갖추기 위한 중요한 방법은 엔지니어 매지너들과 좋은 관계를 유지하는 것이다. 멍청한 아이디어를 제안하지 않도록 기술적으로도 충분해야한다. 더불어, 로드맵이나 backlog 작성을 할때 어떠한 허락이나 리뷰 또한 요구되지 않는다. 몇몇 관련된 PM이 있는데, 그들은 회사에서 메우 중요하고 개인적으로도 흥미 있는 영역에 대해서 책임을 지고 있다고 느끼고 있다.
  • by default all code commits get packaged into weekly releases (tuesdays)
    기본적으로 모든 commit된 소스는 화요일의 주간 릴리즈에 포함된다.
  • with extra effort, changes can go out same day
    추가적인 노력을 통해 수정사항은 다른 날에 나갈 수도 있다.
  • tuesday code releases require all engineers who committed code in that week’s release candidate to be on-site
    그 주에 코드를 commit한 모든 엔지니어들은 화요일 코드 릴리즈때 자리를 지키고 있어야 한다.  
  • engineers must be present in a specific IRC channel for “roll call” before the release begins or else suffer a public “shaming”
    엔지니어들은 릴리즈가 시작되기 전까지 특정 IRC channel을 통해 출석을 체크해야 하며, 그렇지 않으면 공개적인 망신을 당할수도 있다. 
  • ops team runs code releases by gradually rolling code out
    운영팀은 코드 릴리즈를 점진적으로 진행한다.
    • facebook has around 60,000 servers
      페이스북은 약 6만개의 서버를 가지고 있다.
    • there are 9 concentric levels for rolling out new code
      9단계의 중앙집중식 코드 발행 단계가 있다.
    • [CORRECTION thx epriest] “The nine push phases are not concentric. There are three concentric phases (p1 = internal release, p2 = small external release, p3 = full external release). The other six phases are auxiliary tiers like our internal tools, video upload hosts, etc.”
      "9계의 발행 단계가 모두 중앙집중식은 아니다. 세 개의 중앙집중식 단계가 있다. (P1=내부발행, P2=소규모 외부발행, P3=전체 외부 발행). 다른 6 단계는 내부툴, 비디오 업로드 호스트 등 보조적인 단계이다.)
    • the smallest level is only 6 servers
      최소 레벨은 6개의 서버다.
    • e.g., new tuesday release is rolled out to 6 servers (level 1), ops team then observes those 6 servers and make sure that they are behaving correctly before rolling forward to the next level.
      예를 들어 화요일의 새 릴리즈가 6개의 서버로 전달되면(레벨1), 운영팀은 그 6개의 서버가 다음 단계로 전달되기 전까지 정상적으로 동작하는 지를 확인 한다.
    • if a release is causing any issues (e.g., throwing errors, etc.) then push is halted.  the engineer who committed the offending changeset is paged to fix the problem.  and then the release starts over again at level 1.
      만약에 릴리즈아 어떠한 문제를 일으시키면(에러 발생 등) 발생은 중지된다. 그 문제가 있는 수정 사항을 적용한 엔지니어는 그 문제를 수정하도록 요구 받는다. 그리고는 레벨1부터 릴리즈가 다시 시작된다.
    • so a release may go thru levels repeatedly:  1-2-3-fix. back to 1. 1-2-3-4-5-fix.  back to 1.  1-2-3-4-5-6-7-8-9.
      그래서 릴리즈는 단계들을 반복해서 거치게 된다 : 1-2-3-수정. 다시 1. 1-2-3-4-5-수정. 다시 1. 1-2-3-4-5-6-7-8-9.
  • ops team is really well-trained, well-respected, and very business-aware.  their server metrics go beyond the usual error logs, load & memory utilization stats — also include user behavior.  E.g., if a new release changes the percentage of users who engage with Facebook features, the ops team will see that in their metrics and may stop a release for that reason so they can investigate.
    운영팀은 정말 잘 훈련되어 있고, 존경받고 있으며, 매우 업무에 해박하다. 그들의 서버들은 일반적인 에러 로그, 로드&메모리 활용통계를 벗어나기도 한다. 물론 사용자의 행동 또한 마찬가지다. 예를 들면 만약 새로운 릴리즈가 페이스북 기능을 사용하고 있는 사용자의 비율에 변화를 준다면, 운영침은 그들의 통계자료를 보고 추가적인 조사를 위해서 릴리즈를 중단하기도 한다.
  • during the release process, ops team uses an IRC-based paging system that can ping individual engineers via Facebook, email, IRC, IM, and SMS if needed to get their attention.  not responding to ops team results in public shaming.
    릴리즈 과정 중에, 운영팀은 각각의 엔지니어들에게 필요한 경우 그들에게 알리기 위해 Facevook, email, IRC, IM, SMS 등을 통해 개인을 호출할 수 있는 IRC 기반 paging system을 사용한다. 운영팀에 응답하지 않을 경우, 공개적 망신을 당한다.
  • once code has rolled out to level 9 and is stable, then done with weekly push.
    일단 코드가 9단계까지 전달되고 안정적이면, 주간 발행은 종료된다.
  • if a feature doesn’t get coded in time for a particular weekly push, it’s not that big a deal (unless there are hard external dependencies) — features will just generally get shipped whenever they’re completed.
    한 주의 발행 시간 전까지 코딩이 완료되지 않는다고 해도, 큰 문제는 아니다.(크게 외부적인 의존성만 없다면) - 특이 사항들은 완전히 완료되었을때 포함된다.
  • getting svn-blamed, publicly shamed, or slipping projects too often will result in an engineer getting fired.  ”it’s a very high performance culture”.  people that aren’t productive or aren’t super talented really stick out.  Managers will literally take poor performers aside within 6 months of hiring and say “this just isn’t working out, you’re not a good culture fit”.  this actually applies at every level of the company, even C-level and VP-level hires have been quickly dismissed if they aren’t super productive.
    SVN 상에 문제를 일으키거나, 공개적으로 책임을 추궁당하거나, 프로젝트에서 너무 자주 제외되면 엔지니어 해고의 사유가 된다. "매우 높은 효율을 가진 문화이다." 생산적이지 않거나 매우 특별나지 않은 사람은 쉽게 잘려나간다. 관리자들은 고용후 6개월은 낮은 효율성도 감수하지만, 이후에는 "안되겠어. 당신은 이 문화에 적합하지 않다"라고 말한다. 이러한 것은 실제로 회사의 모든 레벨에 적용이된다. 심지어 C-레벨과 VP-레벨 고용자들고 능력이 특출나지 않으면 곧 해고된 적도 있다.
  • [CORRECTION, thx epriest]  “People do not get called out for introducing bugs. They only get called out if they ask for changes to go out with the release but aren’t around to support them in case something goes wrong (and haven’t found someone to cover for you).”
    "사람들은 버그를 설명하라는 요구를 받지는 않는다. 그들은 단지 릴리즈에 수정하상이 포함될 것을 요구받을 뿐이다. 하지만 어떤 것이 잘못되고 있어도 지원을 해주지는 않는다. (당신을 보호해주지도 않는다.)"
  • [CORRECTION, thx epriest] “Getting blamed will NOT get you fired. We are extremely forgiving in this respect, and most of the senior engineers have pushed at least one horrible thing, myself included. As far as I know, no one has ever been fired for making mistakes of this nature.”
    "단지 비난을 받는다고 해서 당장 해고되는 것은 아니다. 우리는 이러한 점에 있어서는 최대한 용서한다. 그리고 대부분의 시니어 엔지니어들은 최소 한가지의 어려운일을 요구한다. 내가 하는 한, 실수를 저질렀다고 해고된 사람은 없다. "
  • [CORRECTION, thx fryfrog] “I also don’t know of anyone who has been fired for making mistakes like are mentioned in the article. I know of people who have inadvertently taken down the site. They work hard to fix what ever caused the problem and everyone learns from it. The public shaming is far more effective than fear of being fired, in my opinion.”
    "나 또한 위에 언급된 사항으로 해고된 사람을 보지는 못했다. 실수로 사이트를 다운 시킨 한 사람을 알고 있는데, 그들은 이유가 무엇이든 그것을 고치기 위해서 열심히 일했고 모두가 그것으로 부터 배웠다. 내 생각에는 공개적으로 책임을 추궁당하는 것이 해고에 대한 불안감보다는 보다 효율적이다.

It’ll be super interesting to see how Facebook’s development culture evolves over time — and especially to see if the culture can continue scaling as the company grows into the thousands-of-employees.
페이스북의 개발 문화가 앞으로 어떻게 발전해 나갈지, 특히 회사가 수천명의 직원을 가진 회사로 커가면서 그 문화가 어떻게 지속되는지는 보는 것은 매우 흥미로운 일일 것이다.


What do you think?  Would “developer-driven culture” work at your company?

어떻게 생각하는가?  "개발자 주도 문화"가 여러분의 회사에서도 가능할까?

 


댓글을 달아 주세요