파이썬이 인기 있는 교육적인 언어인 5가지 이유

제공 : 한빛 네트워크
저자 : Nicholas Tollervey
역자 : 한일 / corone@naver.com
원문 : 5 reasons why Python is a popular teaching language

파이썬의 심플함은 배우는 사람들과 가르치는 사람들이 모두 파이썬을 쉽게 이해할 수 있도록 해준다.

나는 매우 간단한 질문에 답변을 하려고 한다: 파이썬 언어 자체의 어떤 특징이 파이썬을 교육에 적합하게 만드는 것일까? 이 내용은 파이썬을 조금 배우면서 약간의 코드를 읽는 것이 포함된다. 그러나 코딩 경험이 없더라도 걱정하지 마라! 이번 챕터는 희망적으로 파이썬을 배우는 것이 얼마나 쉬운지 눈을 뜨게 해줄 것이다. (따라서, 파이썬이 교육적인 언어로써 인기가 있는 이유이다.)

코드 가독성

메모지에 To-Do 리스트를 적는다면, 다음과 같을 것이다: 

Shopping (쇼핑하기)

Fix broken gutter (망가진 지붕 물받이 수리하기)

Mow the lawn (잔디 깎기)

이것은 명료한 리스트다. 만약에 이 리스트를 좀 더 세분화 시킨다면 다음과 같이 쓸 것이다:

Shopping (쇼핑하기):

    Eggs (달걀)

    Bacon (베이컨)

    Tomatoes (토마토)

Fix broken gutter (망가진 지붕 물받이 수리하기):

    Borrow ladder from next door (이웃집에서 사다리 빌리기)

    Find hammer and nails (망치와 못 찾기)

    Return ladder! (사다리 돌려주기!)

Mow the lawn: (잔디 깎기)

    Check lawn around pond for frog(연못 주위의 잔디에 개구리가 있는지 확인하기)

    Check mower fuel level (잔디 깎는 기계의 연료량 확인하기)

하위 항목들이 관련된 주제 아래로 들여쓰기 되어 우리는 직관적으로 주제가 하위 항목들로 세분화된 것을 이해할 수 있다. 이것은 그 항목들이 서로 어떤 관련이 있는 지 한 눈에 보기가 쉽다.

이것을 스코핑(scoping)이라고 한다.

또한, 이런 식으로 들여쓰기 하는 것은 파이썬이 파이썬 프로그램에 정의된 다양한 작업들을 조직화하는 방법이다. 예를 들어, 다음의 코드는 사용자에게 이름 입력을 요청하는 say_hello 라는 함수를 간단히 보여준다. 그리고, 예상한 대로 다정한 인사를 출력한다:

def say_hello():

    name = input('What is your name? ')

    print('Hello, ' + name)

   

이 코드의 실행 결과는 다음과 같다. (사용자 입력 포함):

What is your name? Nicholas

Hello, Nicholas  

  

say_hello 함수를 구현하고 있는 코드 라인들이 앞의 To-Do 리스트와 같이 들여쓰기 된 것을 주목해라. 뿐만 아니라 코드에 있는 각각의 지시가 그 라인 내에 들어있다. 그 코드는 읽기 쉽고 이해하기 쉽다: 그 코드가 들여쓰기 된 방식을 보는 것만으로 어떤 코드 라인들이 서로 관련이 있는지 명료하다.

대부분의 다른 컴퓨터 언어들은 범위를 나타내기 위해 들여쓰기 보다는 구문론적 기호를 사용한다. 예를 들면, 자바, 자바스크립트, 그리고 C와 같은 많은 언어들이 이런 목적으로 중괄호와 세미콜론을 사용한다.

이것이 왜 중요한가?

만약에 나처럼 영어가 모국어가 아닌 학생들을 가르치거나 난독 장애와 같이 특별한 교육이 필요한 학생들을 가르친 적이 있다면 파이썬의 직관적인 들여쓰기는 (그들의 언어 배경과 상관 없이) 전세계 모든 사람들이 이해한다는 것을 알게 될 것이다. 또한 코드 주위에 산재되어 있는 ‘{’, ‘}’ 그리고 ‘;’ 와 같은 혼란스러운 기호들이 적은 것은 파이썬 코드를 훨씬 더 읽기 쉽게 해준다. 게다가 그런 들여쓰기 규칙은 코드를 작성할 때 그 코드가 어떻게 보여지도록 작성해야 하는 지를 가이드 한다. 학생들은 직관적으로 그들의 작업을 보여주는 방법을 이해한다.

대부분의 다른 언어들과 비교하여 파이썬의 문법(코드를 작성하는 방법)은 간단하고 이해하기 쉽다. 예를 들어, 펄 프로그래밍 언어를 사용하여 작성된 다음의 코드는 텍스트 문서에서 동일한 단어를 찾을 것이다:

print "$.: doubled $_" while / (w+) s+ 1 /gi

펄이 이것을 어떻게 실행하는지 이해할 수 있는가?

(펄의 변론으로, 펄은 파이썬과는 다른 목표와 목적을 가진 놀랄 만큼 파워풀한 프로그래밍 언어이다. 그것이 바로 포인트다. 제임스 조이스의 율리시스가 20세기 최고의 영어 소설 중 하나로 널리 평가 받고 있다고 해도 율리시스를 가지고 책 읽는 방법을 가르치려고 하지는 않을 것이다.)

간단히 말해서, 파이썬 코드를 읽고 쓰는 방법에 많은 시간을 할애할 필요가 없기 때문에 그것을 실제로 이해하는 일에 더 많은 노력을 들일 수 있다. 교육적인 맥락에서는 프로그래밍하기 위해 요구되는 수고를 줄이는 것이 좋은 것이다. (실제로, 어떤 사람들은 모든 맥락에서 그렇다고 주장하기도 한다.)

간단 명료함

파이썬 코드를 작성하기 위해 요구되는 간단한 핵심 개념과 지식은 많은 이점을 준다. 배우기 쉽고, 사용하기 쉽고, 기억하기 쉬운 것은 파이썬의 또 하나의 장점이다. 더욱이, 파이썬은 명료한 프로그래밍 언어이다. 그것은 예상한 대로 동작하고 프로그래머가 명백히 잘못된 것을 실행하려고 하면 불평할 것이다. 파이썬은 다른 의미로도 명료하다. 그것은 일반적으로 이해할 수 있는 영어 단어를 사용하여 다양한 개념들을 명명한다.

다음의 두 예시를 살펴보자:

어떤 언어들에서는 리스트를 만들려면 배열, 배열리스트, 벡터와 콜렉션 등과 같이 다양하게 이름 붙여진 구조를 사용해야 한다. 파이썬에서는 리스트라고 불리는 구조를 사용한다. 여기에 파이썬으로 작성한 앞에서 나온 To-Do 리스트가 있다: 

todo_list = ['Shopping', 'Fix broken gutter', 'Mow the lawn']

이 코드는 (나의 To-Do 리스트에 있는 할 일들을 서술하는 단어들로 구성된 문자열) 값들을 가진 리스트를 (이 특정한 리스트를 참조하여 나중에 재사용할 수 있는) todo_list라는 이름의 객체에 할당한다.

어떤 언어들에서는 지정된 값들(기본 키/값 저장소)을 저장하고 검색할 수 있는 데이터 딕셔너리를 만들려면, 해쉬테이블, 연관 배열, 맵 혹은 테이블이라고 불리는 구조를 사용할 것이다. 파이썬에서는 딕셔너리라고 불리는 구조를 사용한다. 여기에 임의의 수도들을 모아놓은 데이터 딕셔너리가 있다: 

capital_cities = {

    'China': 'Beijing'

    'Germany': 'Berlin',

    'Greece': 'Athens',

    'Russia': 'Moscow',

    'United Kingdom': 'London',

}  

나는 단순히 capital_cities 객체에 딕셔너리를 할당했다. 내가 어떤 나라의 수도를 찾고 싶으면 capital_cities 라는 이름의 객체 다음에 오는 대괄호 안에 그 나라의 이름을 참조하면 된다:

capital_cities['China']

'Beijing'

많은 프로그래밍 언어들이 파이썬의 리스트나 딕셔너리와 같이 동작하는 자료구조를 갖고 있다. 그들 중 일부는 명료하게 동작하며 그런 구조체들을 리스트와 딕셔너리라고 부른다. 다른 일부 언어들은 그런 구조체들을 (많은 언어들이 그렇지 않음에도 불구하고) 파이썬만큼 쉽고 명료하게 사용할 수 있도록 한다. 파이썬의 이점은 이 세가지를 모두 지원한다는 것이다. 파이썬은 그 언어의 핵심부에 유용한 자료 구조들을 갖고 있다. 그것들은 이름도 명료하고 사용하기도 매우 쉽다. 그런 유용함, 간단함, 그리고 명료함이 프로그래밍에 대한 진입장벽을 없애는 또 하나의 근거이다.

앞에서 언급했듯이, 파이썬은 예상한 대로 동작한다. 예를 들어, 비어 있는 딕셔너리와 비어 있는 리스트를 합하려고 하면 (내가 하려고 하는 것을 내가 이해하지 못했다는 것을 증거로 그것은 명백히 잘못된 것이다.) 파이썬은 다음과 같이 불평할 것이다: 

>>> {} + []

Traceback (most recent call last):

  File "<stdin>", line 1, in <module>

TypeError: unsupported operand type(s) for +: 'dict' and 'list' 

이것은 간단히 딕셔너리와 리스트를 합하려면 “+” 연산자를 사용할 수 없다는 것을 알려준다. 이것은 예상했던 것이고 훨씬 명료하고 훨씬 도움이 된다.

그럼에도 불구하고, 다른 언어들은 덜 엄격하고 프로그래머에게 더 관대하다. 이것이 좋은 아이디어와 같이 보이지만, 위에서 시도했던 것과 같은 잘못된 코드가 어떤 에러도 없이 실행되고 예측할 수 없는 결과를 야기할 것이라는 것을 의미한다. (어째든, 딕셔너리와 리스트를 합한 답은 무엇일까?) 여기에 그에 대응되는 자료 구조를 합하려고 할 때 흔히 볼 수 있는 자바스크립트의 실행 결과가 있다. (자바스크립트 문법에서, 객체 ‘{}’ 와 배열 ‘[]’):

> {} + []

0 

그 답이 명백하게 0인가!?!

이번에는 자바스크립트에서 비어 있는 배열에 객체를 더하면 어떻게 될 지 추측해보라. (합의 항을 서로 바꾸어 보자.) 

> [] + {}

"[object Object]"

동일한 결과를 기대했을 것이 틀림없다!

(다시 한번, 파이썬과는 다른 목표와 목적을 가진 자바스크립트의 조건 상황이 여기에 적용될 것이다.)

배움은 본질적으로 실수를 만들고 만든 실수를 깨닫는 것을 포함한다. 그런 다음에야 비로소 행동이 적응되고 실력이 향상되는 것이다. 만약에 (명백한 에러에 대해 불평하는 것보다는 의도한 것을 최대한 추측해서 실행하는) 자바스크립트와 같은 언어를 사용하여 프로그래밍을 배우고 있다면, 모든 종류의 실수를 알아채지 못하고 그냥 지나칠 것이다. 대신에, 프로그래밍 세계의 잘못된 견해를 계속 갖고 있게 되거나 아니면 차라리{} + []은 0과 같고 [] + {}은 "[object Object]" 와 같다는 자바스크립트의 복잡한 규칙들을 이해해야 할 것이다. (그것 자체가, 어려운 교육적인 성과를 이루는 것이다.)

파이썬의 심플함과 명료함은 파이썬을 배우고 있는 사람들과 전문 개발자들이 모두 이해하기 쉬운 코드를 작성하도록 이끈다. 이해하기 쉬운 코드는 유지관리하기 더 쉽고 버그를 포함할 가능성이 더 적다. (왜냐하면 많은 버그들이 생각했던 동작과 비교하여 실제 동작을 잘못 이해해서 발생하기 때문이다.) 자신의 생각을 쉽게 코드로 작성할 수 있는 것은 매우 파워풀하고 힘이 되는 능력이다.

예를 들면, 오래된 텍스트 어드벤처 게임을 생각해보라. 플레이어는 그 장소가 상세히 묘사되어 있으며 다른 장소로 이동할 수 있는 출구가 있는 세계를 돌아다닌다. 아래의 프로그램은 매우 명료하고 간단하게 그것을 정확히 구현한다.

프로그램의 대부분은 그것이 어떻게 동작하는지 설명하는 코멘트들과 게임 세상을 묘사하는 데이터 딕셔너리로 구성되어 있다. 실제 게임의 동작이 정의된 부분은 오직 코드의 마지막 블록이다. 프로그래머가 아닐지라도 게임이 어떻게 동작하는지 요지는 알 수 있을 것이다.

"""

A very simple adventure game written in Python 3.

The "world" is a data structure that describes the game

world we want to explore. It's made up of key/value fields

that describe locations. Each location has a description

and one or more exits to other locations. Such records are

implemented as dictionaries.

The code at the very end creates a game "loop" that causes

multiple turns to take place in the game. Each turn displays

the user's location, available exits, asks the user where

to go next and then responds appropriately to the user's

input.

"""

world = {

    'cave': {

        'description': 'You are in a mysterious cave.',

        'exits': {

            'up': 'courtyard',

        },

    },

    'tower': {

        'description': 'You are at the top of a tall tower.',

        'exits': {

            'down': 'gatehouse',

        },

    },

    'courtyard': {

        'description': 'You are in the castle courtyard.',

        'exits': {

            'south': 'gatehouse',

            'down': 'cave'

        },

    },

    'gatehouse': {

        'description': 'You are at the gates of a castle.',

        'exits': {

            'south': 'forest',

            'up': 'tower',

            'north': 'courtyard',

        },

    },

    'forest': {

        'description': 'You are in a forest glade.',

        'exits': {

            'north': 'gatehouse',

        },

    },

}

# Set a default starting point.

place = 'cave'

# Start the game "loop" that will keep making new turns.

while True:

    # Get the current location from the world.

    location = world[place]

    # Print the location's description and exits.

    print(location['description'])

    print('Exits:')

    print(', '.join(location['exits'].keys()))

    # Get user input.

    direction = input('Where now? ').strip().lower()

    # Parse the user input...

    if direction == 'quit':

        print('Bye!')

        break  # Break out of the game loop and end.

    elif direction in location['exits']:

        # Set new place in world.

        place = location['exits'][direction]

    else:

        # That exit doesn't exist!

        print("I don't understand!")

보통 “게임”은 다음과 같을 것이다. (사용자 입력 포함):

$ python adventure.py

You are in a mysterious cave.

Exits:

up

Where now? up

You are in the castle courtyard.

Exits:

south, down

Where now? south

You are at the gates of a castle.

Exits:

south, north, up

Where now? hello

I don't understand!

You are at the gates of a castle.

Exits:

south, north, up

Where now? quit

Bye!

더욱이, 교육적인 관점에서, 이 간단한 어드벤처 게임은 파이썬을 배우는 사람들에 의해 많은 흥미롭고 명료한 방법으로 변경될 수 있다: world에 객체들을 추가하고, 퍼즐을 만들고, 더 고급 명령들을 추가하고, 기타 여러 가지를 할 수 있다. 사실, 다른 과목과 접목된 교육 과정의 기회도 있다. 이와 같은 게임을 플레이 하는 것은 양방향 대화식 소설의 한 형태이다. 아마도 영어학과에서는 학생들이 원문에서 빈약하게 서술된 내용보다 더 많은 내용을 추가하도록 할 수도 있을 것이다.

공개적 확장성

프로그래밍 언어 핵심부의 파워풀한 심플함에도 불구하고, 프로그래머들은 일반적인 작업을 하기 위해 기존에 있는 라이브러리 모듈들을 종종 재사용할 필요가 있다. 라이브러리 모듈은 어떤 관련된 작업들을 수행하기 위한 설명이 있는 레시피 북과 같다. 그것은 프로그래머가 일반적인 문제에 부딪힐 때마다 처음부터 새로 시작하거나 이미 존재하는 것을 다시 만드느라 쓸데없이 시간을 낭비할 필요가 없다는 것을 의미한다.

대부분의 프로그래밍 언어가 라이브러리를 만들고 재사용하는 메커니즘을 갖고 있는 반면에, 파이썬은 번성한 써드 파티 모듈의 생태계를 갖고 있을 뿐만 아니라 (핵심부에 내장된) 많은 양의 광범위한 표준 라이브러리를 갖고 있는 특별한 축복을 받았다.

예를 들어, 웹사이트로부터 데이터를 검색하는 것은 흔한 작업이다. 우리는 파이썬을 사용하여 웹 페이지를 다운로드하기 위해 requests 써드 파티 모듈을 사용할 수 있다:

>>> import requests

>>> response = requests.get('http://python.org/')

>>> response.ok

True

>>> response.text[:42]

'<!doctype html><!--[if lt IE 7]>   <html '

(이 코드는 우리가 requests 라이브러리를 사용하여 파이썬 홈페이지에서 HTML 문서를 가져오고, 성공했는지 응답을 확인하고, HTML 문서를 앞에서부터 42개의 문자까지 보여주기를 파이썬에 요청한다.)

requests와 같은 일부 모듈들은 하나의 일을 하며 그 일을 특별히 잘해낸다. 다른 모듈들은 일반적인 애플리케이션을 만들 때 필요한 많은 반복적인 작업들을 처리해주는 애플리케이션 프레임워크를 만들기 위해 큰 라이브러리 안에 구성되어 있다.

예를 들면, Django는 (모질라, 가디언, 내셔널 지오그래픽, NASA, 그리고 인스타그램과 그 외 다른 곳들에서 사용되는) 웹 애플리케이션을 만들기 위한 애플리케이션 프레임워크이다. Django는 데이터 모델링, 데이터베이스 연동, 웹 페이지, 보안, 확장성을 위한 템플릿 작성, 비즈니스 로직 결정, 그리고 기타 등등의 일반적인 작업들을 관리한다. 이런 작업들은 이미 Django에 의해 관리되고 있기 때문에 개발자들은 웹사이트를 디자인하고 비즈니스 로직을 구현하는 중요한 작업에 집중할 수 있다.

많은 프로그래밍 언어들이 많은 양의 라이브러리와 애플리케이션 프레임워크를 갖고 있다. 그러나 파이썬의 강점은 그것의 폭넓은 범위이다. SciPy와 NumPy는 과학자들과 수학자들에 의해 사용되고, NLTK (the Natural Language Tool Kit)는 텍스트를 분석하는 언어학자들에 의해 사용되고, Pandas는 통계학자들에 의해 광범위하게 사용되고, 그리고 OpenStack은 클라우드 기반의 컴퓨팅 리소스를 조직적으로 관리하고 제어하기 위해 사용된다. 이 리스트는 계속 늘어나고 있다. 

이런 폭넓은 실용성을 가진 프로그래밍 언어를 가르치는 것은 분명한 이점이 있다: 배우는 사람들이 실제 경제적인 가치를 가진 프로그래밍 언어로 기술을 배우는 것이다.

파이썬이 공개적으로 확장될 수 있는 또 하나의 측면은 파이썬이 오픈 소스 프로젝트라는 것이다. (귀도 반 로섬이 직접 이끌고 있는) 핵심 개발자들에게 버그 리포트나 패치를 보내는 것으로 누구나 파이썬 개발에 참여할 수 있다. 또한 파이썬의 어떤 새로운 기능이 제안되고 구현되었는지 이해하기 쉬운 간단한 과정이 있다: Python Enhancement Proposals (PEPs). 이런 방식으로, 커뮤니티가 앞으로의 개발을 알리고 이끌어 갈 수 있는 기회를 갖고 있으며 파이썬을 사용하는 커뮤니티 모두가 보는 앞에서 개발되고 있다. 이런 과정은 PEP 1에 아주 자세히 설명되어 있다.

플랫폼 비종속성

파이썬은 플랫폼에 비종속적인 언어이다: Microsoft 윈도우, Mac OS X, 리눅스, 그리고 다른 많은 운영체제와 기기에서 실행된다. 심지어 Python Anywhere와 같은 웹사이트들을 통하여 파이썬을 서비스할 수도 있다.

이것은 교육적인 맥락에서 중요하다. 왜냐하면 파이썬이 학교에 있는 컴퓨터에서도 실행된다는 것이기 때문이다. 또한 학생들은 제품과 모델에 관계없이 그들의 집에 있는 컴퓨터에서도 파이썬을 사용할 수 있다. 더욱이, 웹사이트를 통하여 제공되는 파이썬 서비스는 선생님들에게 학교 PC에 Microsoft 오피스 이외에는 다른 어떤 것도 설치하지 못하게 하는 악명 높은 트롤 같은 학교 시스템 관리자들의 문제에 대한 훌륭한 해결책이다. 사용자들은 간단히 웹사이트에 접속한다. 그러면 어떠한 추가적인 소프트웨어 설치 없이도 완전한 기능을 갖춘 파이썬 개발 환경이 나타난다.

이상과 같이, 파이썬은 라즈베리 파이와 같은 소형기기에서도 실행된다. 심지어 임베디드 기기, 가정용 기기, 원격 조종기, 그리고 (무엇보다도) 장난감 등의 내부에 들어있는 소형 저전력 칩인 마이크로 컨트롤러에서도 실행된다.

MicroPython project는 그런 기기들을 위해 최적화된 파이썬 3의 축소 버전을 개발했다. 그리고 파이썬의 그런 축소 버전이 실행되는 소형 전자 회로 보드를 제공한다:

마이크로파이썬 보드 (대략 우표와 비슷한 크기)

이 매우 간단한 파이썬 기반의 운영체제는 모든 종류의 흥미롭고 재미있는 전자 프로젝트의 기반으로 사용될 수 있다. 보드의 부가품으로 LCD 디스플레이 스크린, 스피커와 마이크, 그리고 모터가 포함되어 있다. 그런 기기로 간단한 로봇을 만드는 것은 비교적 쉬운 작업이다.

더 최근에는, BBC가 아이들을 위해 배터리로 동작하는 프로그램 가능한 소형 기기를 개발하는 MicroBit project를 발표했다. 2015년 9월 새 학년이 시작할 때 영국에 있는 11살 아이들에게 100만개의 기기를 나눠줄 것이다. 그것은 또한 일반에게도 판매될 것이다.

마이크로비트는 옷에 고정시킬 수 있으며 2개의 버튼을 갖고 있고 스크롤 되는 텍스트와 이미지를 표시할 수 있는 LED 매트릭스가 있다. 라즈베리 파이와 마이크로파이썬 보드처럼 I/O 커넥션을 통하여 다른 기기들과 통신할 수도 있다.

파이썬은 마이크로비트에서 지원되는 세 가지 프로그래밍 언어 중에 하나이다.

아이들을 위한 프로그램 가능한 기기인 BBC 마이크로비트의 프로토타입

교육적인 중요한 이점은 지속성이다.

파이썬을 배움으로써, 학생들은 그들에게 익숙한 툴과 코드를 사용하여 탐구할 수 있는 모든 종류의 재미있고 흥미로운 플랫폼을 접한다. 파이썬은 많은 플랫폼에서 실행되기 때문에 하나의 디바이스에서 작성한 코드는 그것이 디바이스에 종속적인 코드를 사용하지 않고 하드웨어 제약적이지 않다고 가정하면 다른 많은 플랫폼에서도 실행된다.

인간미

프로그래밍 언어의 엄격한 특성이 아니긴 하지만 파이썬의 커뮤니티, 역사, 그리고 철학은 종종 파이썬으로 작성된 코드를 통하여 빛난다.

이상한 몬티 파이썬 레퍼런스 (써드 파티 파이썬 모듈을 제공하는 웹사이트는 치즈 없는 치즈 가게에 관한 콩트에서 따와 Cheese Shop이라고 불린다.), 장난스런 유머감각 (예를 들어, “PyPy 프로젝트”는 파이썬으로 작성된 파이썬의 고성능 버전이기 때문에 그렇게 이름 붙여졌다.), 그리고 다른 분명히 별난 점들은 파이썬이 접근성 높고 흥미 있는 프로그래밍 언어라는 것을 보여준다. 그것은 신비철학의 추상적인 툴보다는 훨씬 더 명백히 인간에 의해 인간을 위해서 사용되는 것이다.

파이썬 커뮤니티는 친근하고 다양하다. 다음 챕터에서는 개발자들, 교사들, 그리고 학생들의 커뮤니티에 대해 다루려고 한다.

간단히 말하면, 파이썬 커뮤니티는 파이썬 성공의 비밀무기이다.

오픈솔라리스: 드라이버 논쟁

제공 : 한빛 네트워크
저자 : Chris Josephes
역자 : 한일 / corone@empal.com
원문 : OpenSolaris: Driver Wrangling

나는 랩탑, 가상 머신, 그리고 테스트 서버 환경에서 지금까지 약 6주 동안 오픈솔라리스 2008.11을 사용해왔다. 나는 그 환경들에서 모든 것이 얼마나 잘 작동하는 지와 그 차이점에 관한 기사를 쓰겠다고 예전에 다짐했었다.

세 환경 중에서 랩탑이 설치 후에 가장 많은 작업을 필요로 했다. 내 랩탑은 Gateway MX6450이다. 그것은 AMD Turion 64 프로세서를 장착하고 있다. 이 모델은 적어도 2년은 된 모델이고, 발열과 배터리 전력에서 좋지 않은 평을 받고 있다. 그것은 또한 Vista가 정식 지원되지 않는 64비트 싱글 코어 시스템이다. 그래서 내가 지금 그것에 관하여 불평을 해도 Gateway에서 크게 신경을 써줄 거라고 생각하지는 않는다.

처음의 부팅과 설치 과정은 흠잡을 데 없이 잘 진행되었다. 그 일은 다른 리뷰어들이 언급했던 것과 같이 우분투 식으로 간단했다. 나는 Live CD를 실행하고 있는 동안에도, 그리고 하드 디스크로부터 부팅한 후에도, 모두 Device Driver Utility를 실행할 수 있었다. 두 경우 모두, 네 개의 동일한 에러를 보고했다.

네트워킹이 되지 않았다. 그러나 적어도 DVD 드라이브와 디스플레이는 작동되었다. 그리고 오디오 드라이버가 설치되었음에도 불구하고 작동되지는 않았다. 나는 설치를 계속 진행했다. 그래서 나는 하드 드라이브로부터 부팅할 수 있었다. 나는 작동되지 않는 것들을 대체할 수 있는 드라이버를 찾기 위해 구글링을 했다.

Yukon 드라이버 문제는 Marvell 웹사이트에서 간단한 다운로드로 해결됐다. 내가 해야 했던 것은 하나의 패키지 설치와 리부팅이 전부였다. 시스템이 리부팅되었을 때, DHCP 서버에 접속되어 어떤 수동 설정도 없이 IP주소를 할당 받았다. 나는 유용하게도 How To Fix The Audio Driver Problem In OpenSolaris라는 제목의 이 기사문의 지시에 따르는 것에 의해 오디오 드라이버를 해결했다. 나는 다시 설치 지시에 따랐고 시스템을 리부팅했다. 그리고 오디오가 작동되는 것으로 보상받았다.

여기까지, 내가 필요한 모든 것이 64비트 오픈솔라리스 설치에서 작동되었다. 불운하게도, Broadcom BCM4318 chipset을 위한 자체적인 지원은 없다. 무선 통신을 하려면 드라이버를 빌드해야 하고 오직 32비트 모드로 설정해야 할 것이다.

네트워크 드라이버를 사용할 수 없을 때, 드라이버에 의존하는 사용자들은 윈도우 드라이버를 가져와서 솔라리스 전용 드라이버로 빌드하기 위해 이 ndiswrapper 프레임워크를 사용하고 있다. 윈도우 드라이버를 복사하고 두 개의 프로그램을 컴파일 한 다음, 완료된 드라이버를 제 위치에 설치해라. 32비트 모드를 사용하기 위해서, 나는 GRUB 설정을 편집해야 했다. 나는 시스템을 리부팅 했고 몇몇의 Wi-Fi 무선랜전용지역에서 드라이버를 성공적으로 테스트했다.

나는 100% 완벽함을 기대하지는 않았다, 그래서 이것만으로도 충분히 만족한다. 내 랩탑은 오래된 모델이고 당신은 윈도우가 랩탑에서 가장 잘 지원되는 유일한 운영체제라는 것을 알게 될 것이다. 내가 사용할 중요한 애플리케이션은 파이어폭스, 썬더버드, 그리고 터미널뿐일 것이다.

만약에 당신의 컴퓨터에 오픈솔라리스를 설치해보려고 한다면 하드웨어 호환성 리스트 Hardware Compatibility List를 확인해라. 그것은 당신이 유저 리포트와 드라이버 유효성에서 찾게 될 최고의 자원이다.

구글 네이티브 클라이언트: 판도변화 아니면 실패작?

제공 : 한빛 네트워크
저자 : Richard Monson-Haefel
역자 : 한일 / corone@empal.com
원문 : Google Native Client: A Game Changer or an Also-Ran?

지난 12월에 구글은 “구글 네이티브 클라이언트” (Google Native Client, NaCl)라고 하는 새로운 RIA 플랫폼을 발표했다. NaCl은 브라우저를 통하지 않고 x86 프로세서에서 C/C++ 애플리케이션을 직접 실행시키는 브라우저 플러그인을 제공한다. 구글은 개발 초기부터 이것을 오픈소스(BSD-style 라이센스)로 릴리스하고 있다. (“release early, release often!”)

구글 NaCl은 다른 많은 RIA 기술로부터 구조적인 관점에서 확실히 두드러진 발전이다. Silverlight, Flex, JavaFX 그리고 Ajax는 모두 네이티브 C/C++ 코드보다 느린 관리형 환경(Managed Environment)에서 실행되지만 다양한 운영 체제와 CPU에 더 잘 이식된다. 그러나, 가장 일반적인 3가지 데스크탑 운영 체제(윈도우, 맥 그리고 리눅스)가 모두 x86 CPU 구조에서 실행된다는 사실에서, CPU 이식성은 5년 전보다는 훨씬 덜 중요할 것이다. (물론, 그 코드를 스마트폰과 같은 다른 디바이스에서 실행시키기를 원하는 것이 아니라면.)

연구 프로젝트로조차 NaCl은 익사이팅한 동시에 무섭다. NaCl은 훨씬 더 좋은 성능을 보장하기 때문에 익사이팅하다. 이것은 그래픽이 강조된 게임, 3D, 그리고 데이터 시각화가 전보다 더 많은 잠재력을 갖는다는 것을 의미한다. 그러나 NaCl은 우리에게 지금까지 웹에 소개된 가장 보안이 보장되지 않는 기술 중 하나인 ActiveX를 상기시키기 때문에 무섭다. 그렇지만 ActiveX와의 비교가 공평할까? 구글에 따르면 NaCl은 ActiveX와 매우 다른 보안 구조를 사용한다. ActiveX는 다운로드된 애플리케이션이 운영체제를 자유롭게 통제하는 것을 허용한다, (ActiveX 컨트롤이 설치되기 위해 오직 당신의 동의만 필요하고 네이티브 애플리케이션이 할 수 있는 모든 것을 할 수 있다.) 반면에, NaCl은 해커에 의해 이용될 수도 있는 연산을 실행하기 위해서는 현재 존재하는 신뢰성 있는 라이브러리에 의존한다. NaCl의 이 초기 릴리스는 특히 최소한의 보안 문제들을 가장 쉽게 찾을 수 있는 보안 전문가들의 타겟이 되었다.

그래서 만약에 NaCl이 구글에서 말하는 것만큼 안전하고 또한 네이티브 런타임 성능도 제공한다면, 그것은 아마도 다른 많은 RIA 기술의 훌륭한 대안이 될 것이다. 그러나 성능은 대중 소비자 시장에서 개발자가 기술을 채택하는 중요한 요소가 아니다. 대중 소비자 RIA 애플리케이션의 개발자들에게 있어서 문제는 개발의 용이성이다. 그것은 사용하기 쉬운 개발 환경, 배우기 쉬운 언어, 미리 만들어 놓은 많은 컴포넌트들, 그리고 번영하고 있는 개발 생태계를 의미한다. 이 중에 어떤 것도 NaCl에 해당하는 것이 없다. NaCl 애플리케이션이 C/C++ 언어로 개발된다는 사실은(대부분의 RIA 개발자와 디자이너가 선택하는 언어는 아니다.) 개발자들에게 채택되는데 거대한 장애물이다. C/C++ 언어는 대부분의 RIA 개발자들에게 익숙하지 않을 뿐만 아니라 가파른 학습 곡선을 가진 까다로운 플랫폼이다.

물론 구글의 NaCl이 네이티브 혹은 네이티브에 가까운 런타임 성능을 위한 유일한 선택은 아니다. Curl은(주: 글쓴이는 Curl에 관한 일을 한다.) 10년 동안 네이티브 컴필레이션에 그 구조를 기초로 하였고 Windows, 맥, 그리고 리눅스에 모두 이식된다. 게다가 구글 크롬은 자바 스크립트 코드를 네이티브 코드에 컴파일한다. 자바 스크립트로 프로그래밍하는 것이 C/C++보다 훨씬 더 매력이 있다.

구글은 성능의 이점이 기업에서는 중요한 반면에 대중 소비자 애플리케이션에서는 시장 가치가 거의 없다는 것을 곧 알게 될 것이다. 대부분의 개발자는 그들이 현재의 RIA 기술을 갖고 벽에 부딪히기 전까지는 자체 성능에 관심을 갖지 않고 그 이후에는 테크놀로지 플랫폼을 바꾸기에 너무 많은 비용이 들 것이다. 대중 소비자 시장에서 NaCl이 채택되기에 큰 장애물이 될 것이 확실한 또 하나의 문제가 있다. NaCl 런타임 환경의 용량이 터무니 없이 큰 22MB이다. Mac에서 NaCl 이전에 RIA 기술에서 가장 큰 런타임 환경이 Java (15MB), Adobe AIR (12MB), Curl (9MB)이다. Flex의 plug-ins (5.5MB)와 Silverlight 2 (7.1MB)는 심지어 더 작다. Ajax는 거의 0에 가까운 용량으로 설치되는 기술이다.

NaCl은 성능의 이점이라는 매력적인 요소를 제공하는 반면에 NaCl이 경쟁력 있게 될 것이라거나 심지어 최종 릴리스에 다다를 것이라는 보장이 없다. 다른 더 잘 정착된 제품들이 대중 시장에 이미 포화상태이고 기업 개발자들은 “실험적”이라고 할 수 있는 기술을 채택하기가 어렵다. 그래서 NaCl은 흥미는 있지만 판도변화로써의 shoe-in은 아니다. 그렇지만 구글은 기대할 만한 힘이 있고 NaCl이 쉽게 사라지지는 않을 것이다.

팀 브레이와의 인터뷰: Atom, JRuby, 그리고 the Ecumenical Sun

제공 : 한빛 네트워크
저자 : Timothy M. O'Brien
역자 : 한일 / corone@empal.com
원문 : Interview with Tim Bray: Atom, JRuby, and the Ecumenical Sun

만약에 당신이 XML을 분석하거나 생성하는 어떤 시스템을 쓴 적이 있다면, 당신은 팀 브레이에게 어떤 빚을 진 것이다. 그는 1998년에 출시된 XML 1.0의 초기 설계서를 공동 집필했다. 그리고, 그것은 XML이 소개된 후 거의 10년간, 모든 프로그래머들과 많은 비프로그래머들에게도 친근한 개념이었다. 이런 성공을 했다면 사람들은 이미 얻은 명예에 만족할 지도 모른다. 그러나 브레이와의 대화에서 당신은 그가 XML에 대한 공헌으로 가장 알려져 있는 반면에, 이상하게 그가 다음 세대의 참여 기술 개발에 초점을 맞추고 있다는 느낌을 받을 것이다. 브레이는 Atom publishing protocol에 초점을 맞추고 있고. 오픈 소스에 공헌하고 있으며 웹 개발에 더 “에큐메니컬”한 접근을 향하여 Sun에 강요하고 있다. 가장 중요하게, 당신은 브레이가 더 투명한 인터넷을 창조하는 기술을 사용하려고 노력하고 있다는 느낌을 받을 것이다.

Sun을 더 투명하게

2004년에, Sun에서 발달된 블로깅을 만드는 데 도움이 된 것은 다른 임원들(핍스와 슈워츠)과 제휴한 브레이의 노력이었다. 여기 2004년 “Sun의 정책 결정”이라는 제목의 브레이의 블로그 글로부터의 발췌록이 있다, 그 글 안에서 그는 Sun의 더 자유로운 블로그 정책으로 가는 결정을 만드는 과정을 논한다.

소리 높여 이야기하기를 좋아하고 그것이 무장 공격일지도 모른다고 생각하는 많은 사람들이 거기에 있다는 것이 분명해졌다. 관리와 법적인 동의 없이 공공연히 소리 높여 이야기하는 것이 무장 공격이라고 말하면서 Sun이 지나간 해로부터 적소에 공식적인 정책을 가지고 있다는 것이 밝혀졌다. 이에 대한 조나단의 반응은 쓸 수 없었다.

그 때에 브레이는 더 투명해지기 위해서 그리고 커뮤니티에 대답하기 위해서 Sun을 격려하려고 노력하고 있었다. Java 플랫폼은 부적절함과 부진의 느낌으로 곤란을 겪고 있었다. 2004년 10월에, 오라일리 네트워크는 “Java의 상태”에 관한 특집 기사를 게재했다. 그 기사에서 많은 여러 편집자들이 Java가 어떻게 “시시하게” 되었는지 그리고 Java가 어떻게 “새로운 COBOL”이 되었는지에 관한 비평에 동의했다. 확실히, Java는 3년 전에 어떤 본질적인 위기를 갖고 있었다.

시간이 지나고 오늘날에 이르러 Java의 명성이 회복되고 있다. 그 플랫폼에 대해서는 여전히 고집스럽게 비방하는 사람들이 있고 항상 계속되는 논쟁이 있다. 그러나 그보다 적은 사람들이 그 플랫폼을 COBOL에 비교하고 있다. 우리는 JRuby같은 프로젝트나 F3같은 자고 있는 프로젝트가 Java, 플랫폼, Java의 한계 이상, 그 언어를 확장하기 시작했을 때를 창조력의 새로운 르네상스 시기로 보고 있다. 그리고 Java는 그 커뮤니티와 맞서기 위해 과거보다 더 많이 내부 직원들을 격려하고 있다.

최근에 브레이는 Three blogs.sun.com Years에서 3년의 Sun의 블로깅 정책에 대해 곰곰이 생각할 기회를 가졌다.:

그것은 Sun의 이미지를 개선하는 것을 도왔다. 3년 전에 우리는 크고 얼굴도 없고 변호사에 속박된 돌기둥처럼 보였다.; 지금 세계는 이들을 다루기 힘든 종족의 사람들이고, 많은 사람들이 영리하고, 광적으로 IT 기술과 사업에 빠져 있다고 본다.

슈워츠가 CEO로 임명된 이래로 Sun의 재정 실적은 “보통”으로 평가할 수 있다. 그리고, Sun은 핵심 서버 시장에서 쇠락하는 판매의 형태로 많은 도전과 HP와 IBM의 경쟁에 직면해 있다. Sun은 Solaris와 JDK의 소스 공개로 인해 변화하는 개발자의 전망에서 승리한 적이 있다. Java를 플랫폼으로 부활시키는 데 대해 브레이에게 유일한 공을 돌리는 것은 부적당할 것이다. 그러나, 명백히, 브레이의 투명성에 대한 헌신과 커뮤니티 참석을 위한 분발 요구는 인식을 바꾸는 데 중요한 역할을 했다. 시간은 인식에서의 이 변화가 Sun의 서비스 부분을 지지하는 것을 돕는지 말해줄 것이다, 그리고 기업의 사회 공헌이 그 최종 결과에 영향을 미치는지 말해줄 것이다.

인터뷰

팀 브레이는 최근에 Atom protocol에 대한 현재의 그의 일, JRuby에 대한 그의 전망, 그리고 Sun의 점진적으로 발전하는 웹 전략에 관하여 O'Reilly Network에게 이야기하기 위해 그의 바쁜 스케줄을 벗어나 얼마 동안의 시간을 가졌다. 그 내용은 다음과 같다.

팀 오브라이언: Sun Microsystems의 디렉터로써의 당신의 역할 중에, 당신은 어디에 초점을 두고 있는가? 당신의 그날그날의 책임은 무엇인가?

팀 브레이: 나는 종합적인 일을 하는 사람이다. 나는 운영체제에서부터 웹 분야를 넘어, 응용 계층까지 모든 것에 흥미가 있다. 실제로 Sun에는 종합적인 일을 하는 사람들이 아마도 조금밖에 없는 것 같다. 분명히 우리는 자바와 운영체제, 그리고 그런 분야들에서 세계 수준의 전문가를 갖고 있다. 그러나 나는 더 다양한 계층에 익숙한 사람이다.

그래서, 나는 내가 관심을 갖는 것 내에서는 자유재량을 가지고 있다. 분명히, 그것은 밖에서 사람들이 이야기하는 것을 듣는데 시간을 보내는 것도 포함한다. 나는 많은 회의에 참석한다. 나는 본사의 몇몇 내부 회의에도 꽤 참석한다. 많은 부분에서, 나는 의사를 나누는 사람이다. 나는 항상 소프트웨어를 다루고 있고, 보통 몇몇 종류의 진행중인 개발 프로젝트를 가지고 있다.

오브라이언: JRuby 프로젝트에 집중하면서 나는 당신으로부터 Jira 버그 보고서가 있었다는 것을 알게 됐다. 당신은 당신이 의사를 나누는 사람이라고 말했는데 당신은 특별한 프로젝트에서 얼마나 활동적인가? 당신은 Glassfish같은 프로젝트나 JRuby같은 프로젝트에 참가한 사람들을 감독하고 있는가?

브레이: 나는 어떠한 직접적인 보고서도 가지고 있지 않으며 사람들을 전혀 감독하지도 않는다. 나는 JRuby를 사용한다, 그리고 그것이 아직 시험적인 것이기 때문에 내가 버그들을 찾은 것이다. 당신은 또한 가끔 NetBeans에서 내가 버그를 보고한 것을 알 것이다. 나는 그것들이 내가 지난해에 실제로 버그를 보고했던 오직 두 개의 프로젝트일 것이라고 생각한다. 아니다. 나는 또한 어떤 핵심 Ruby 버그를 보고했다. 그 외에 무엇이 있는지 생각해 보자. 나는 Ruby on Rails에 각별히 신경을 쓴다. 그리고 그것들은 내가 정말로 각별히 주목하고 있는 유일한 것일 것이다.

잠깐, 아니다. 내가 각별히 주목하는 두 개의 내부 프로젝트가 있다. 그것들은 아직 발표되지 않았다. JavaOne에 관하여 알아보라.

오브라이언: 현재 진행중인 APE 같은 소프트웨어 프로젝트들에 관련이 있다. APE가 무엇인가?

브레이: 나는 IETF Atom Working Group의 공동 의장을 맡는다. 그리고 현재 그 Atom Working Group을 거의 끝낸 것이 Atom Protocol이다. 그리고 나는 표준에 따라 일하는 과정에서, 당신이 표준을 쓸 때, 그것이 동시에 표준을 따르려고 하는 것을 정말로 돕게 된다는 것을 발견한 적이 있다. 왜냐하면 그때 당신은 무엇이 일을 하고 무엇이 일을 하지 않는지를 배우게 된다. APE는 Atom Protocol Exerciser을 나타낸다. 그것은 Atom protocol 클라이언트가 할 모든 것들을 모방하는 프로그램이다. 그것은 Atom protocol을 이행하는지 테스트하기 위해 사용된다.

나는 내 스스로 그것을 썼다. 그리고 우리는 이번 주에 실제로 Google에서 Atom protocol 상호이행 행사를 가졌다. 그리고 그것은 정말로 성공적이었다.

오브라이언: 나는 Wiki에서 호환성 차트를 봤다. 그것은 흥미로워 보였다.

브레이: 그것은 아주 재미있는 행사였다.

오브라이언: Atom protocol로, 당신이 이번 주에 당신의 블로그에 “그 클럽은 얼마나 큰가?”라는 글을 썼다. 이 글에서 당신은 많은 사람들이 정말로 그것이 무엇인지 이해한 것이 아니라는 것을 보여주기 위해서 어떤 회의의 연설과 Twitter 블로그 글을 언급한다. Atom을 쓰면서 그런 적이 있었는가? 당신은 Atom 지지자가 얼마나 크다고 생각하는가? 누가 Atom에 정말로 관심을 갖는가?

브레이: 그 순간에 Atom에 관심을 갖고 있는 유일한 사람들은 프로그래머와 표준을 따르는 사람들이다. 무엇보다도 신디케이션 공간에서, 그리고 다음으로는 일반 웹 테크놀로지 공간에서 그렇다. 그것은 훌륭하다. 비슷하게도 우리가 10년 전에 XML을 개발하고 있었을 때 관심을 갖고 있었던 유일한 사람들은 표준을 따르는 사람들이었다는 것을 지적하고 싶다.

Atom은 XML처럼 일반 사용자에게 보여지는 것이 아니다. 다시 말해서, 만약에 그것의 애플리케이션에 대한 우리의 꿈과 희망이 실현되었다면 그것은 웹의 일반 사용자의 경험에 정말로 극적인 충격을 받을 것이다. 그러나 마지막에는 사람들이 경험하게 될 것들을 가능하게 한다.

오브라이언: 대부분의 사람들은 Atom을 RSS 같이 생각한다. 그것은 “단지 신디케이션 포맷”이라는..

브레이: ...글쎄, Atom은 두 가지가 있다. 첫 번째는 물론 신디케이션 포맷이다. 그래서 Atom 데이터 포맷은 RSS가 개발되었던 해에 우리가 배운 것에 기초하는 본질적으로 단지 RSS의 돈벌이이다. 그리고 그 일은 RFC4287로 이미 완성되었다; 그것은 이미 완성되었고 꽤 널리 사용되어 보급되었다.

Atom의 다른 반쪽은 우리가 전에 얘기했던 Atom publishing protocol이다...

오브라이언: Atom publishing protocol은 웹을 어떻게 변화시킬 것인가? 대부분의 사람들은 그것을 신디케이션 포맷으로써만 알고 있다. Publishing protocol에 대해서 말해 달라.

브레이: 당신은 MetaWeblog API라는 것을 들어본 적이 있을지도 모른다. 그것은 어떤 블로깅 시스템이 퍼블리싱을 지원하기 위해 사용하는 것이다. 그것을 하기 위해 노력하고 있다.

여기 꿈이 있다; 모든 것이 퍼블리시 버튼을 가지고 있어야 한다. 모든 스프레드 시트, 모든 휴대폰, 모든 카메라, 모든 뉴스 리더, 모든 메일 리더, 모든 워드 프로세서가 퍼블리시 버튼을 가지고 있어야 한다. 당신이 스크린에서 당신이 좋아하는 것을 보자마자 당신이 퍼블리시 버튼을 누를 수 있고 웹에서 그것을 가질 수 있어야 한다. 그리고 웹에서 퍼블리시 할 수 있는 다른 많은 곳이 있다는 사실을 준다. 내 말은, 아마도 당신이 Blogspot에 있든지, 아마도 당신이 Facebook에 있든지, 아마도 당신이 LiveJournal에 있다면... 무엇이든지; 더 많은 것이 올 것이다. 확실히, 당신은 퍼블리시 버튼을 가진 어떤 것이 퍼블리시하는 것과 의사소통을 사용할 수 있는 uniform protocol의 어떤 종류가 필요하다.

Atom은 그 꿈을 가능하게 디자인하는 최상의 HTTP 계층인 매우 가벼운 protocol이다. 우리가 이번 주에 구글에 있는 방에서 보았던 것에 기초하여 나는 우리가 그 꿈을 실현시켜 주는 일을 잘 한다고 생각한다.

오브라이언: 가상으로, 당신이 뉴욕 타임즈나 BBC같은 곳에서 일한다. 그리고 이미지에서부터 뉴스 스토리까지 모든 것을 찾아내는 Content Management System (CMS)가 있다. 당신은 Atom을 모든 콘텐트 타입에 대해 확장할 수 있는 것으로 보는가? 그것이 당신이 Atom을 가지고 하려고 하는 일인가? 아니면, 그것이 단지 블로그에 대한 것인가, 단지 포토스트림에 대한 것인가, 단지 스프레드시트에 대한 것인가? 당신은 일반 콘텐트 저장소에 대한 기초를 세우려고 노력하고 있는가? 기업 콘텐트 관리 시스템에서 사용될 수 있는 것인가?

브레이: 글쎄, 나는 내가 개발을 도운 일반 목적 기술의 애플리케이션에 대한 매우 잘못된 연속적인 예견을 했다. XML이 무엇에 사용될 지에 대한 나의 예견은 명백히 틀렸다. Atom protocol의 디자인 센터는 확실히 블로깅이었다. 다시 말해서, 우리는 이미 블로그가 아닌 애플리케이션을 알고 있었다. 예를 들어, 오라일리에서 당신의 동료 두 명이 interop event에 왔고 블로깅을 할 수 없는 Atom 서버 이행을 했다.; 사실 APE는 그것들과 서로 영향을 끼치지 않는다. 왜냐하면 그것들이 업로드할 수 있는 유일한 것은 DocBook XML이다. 우리가 하려고 하는 것은 블로그 공간을 위해 유용하고 생산적인 정말로 좋은 일을 하는 것이다.

나의 예견은 내가 예견하기에는 내가 정말로 충분히 머리가 좋지 않고 나를 놀라게 할 많은 애플리케이션이 나올 것이라는 것뿐이다.

오브라이언: 그러면, 그것이 Atom의 한 부분인 확장 메커니즘을 거치는가?

브레이: 그렇다, 그러나 그것은 우리 컴퓨터 프로그래머들이 CRUD 동작이라고 하는 생성(Create)-수정(Retrieve)-갱신(Update)-삭제(Delete)를 하는 아주 단순한 방법을 갖춘 단지 기본적인 기능이다. 웹에 자료를 올리는데 표준을 이행하는 간단한 마음가짐을 위한 일반 목적의 단순한 기능이다. 그것들이 거기에 있는 즉시 그들을 업데이트하고 당신이 그것들을 더 이상 원하지 않으면 지운다. 그것은 단지 그것 자신에 의해 많은 흥미로운 애플리케이션을 가질 것이다.

오브라이언: 우리의 RSS 제공은 그만두게 될 것인가?

브레이: 당신은 왜 그렇게 생각하는가? 미안하지만, 이해할 수 없다. RSS는 세계에서 가장 성공적인 XML의 애플리케이션이다, 그리고 그것은 정말로 수백만의 사람들에 의해 사용되고 있다. 나는 무언가를 놓치고 있다...

오브라이언: 내 말은, Atom에 있어 전반적으로 전환할 것인가? 그것이 우리의 RSS 제공을 그만두게 될 것인가?

브레이: 아, 당신이 무슨 말을 하는지 알겠다. 글쎄, RSS는 단지 기본적인 개인 대 개인의 블로그에 대해서만 잘 동작하는 것처럼 보인다. 나는 그 선택을 받은 표준을 따르는 사람들 대부분이 차라리 Atom을 가지고 일을 하고 싶어 할 거라고 생각한다. 왜냐하면, 그것은 RSS에서 짜증나는 사소한 결함들을 해결해 준다. 만약에 당신이 컨텐츠 제공을 하기 위한 설비를 쓰고 있다면, 당신은 RSS와 Atom을 둘 다 사용해야 할 것이다. 그리고 그것이 더 나쁘다면 당신은 RSS의 다중 버전을 사용해야 할 것이다. 왜냐하면 그것은 그런 식이다. 다시 말해서, 만약에 당신이 컨텐츠를 제공하는 새로운 것을 사용하고 있다면, 당신은 Atom을 생성하는 것이 좋을 지도 모른다. 왜냐하면, 그것이 훨씬 더 깨끗하고 그 이외에 당신을 괴롭힐 지도 모르는 어떤 버그들을 벗어날 것이다. 컨텐츠 제공을 읽는 그 외의 모든 소프트웨어도 지금 Atom을 읽을 수 있다.

오브라이언: 당신은 Atom 앞에서 RSS가 사라질 것이라고 보는가? 아니면 사람들이 둘 사이에 상호 작용을 가질 것이라고 보는가?

브레이: 나는 프로덕션에 가져오는 새로운 컨텐츠 제공이 점점 Atom에서 있을 거라고 생각한다. 우리는 이미 그것을 알고 있다. 그러나 인터넷에 있는 기술들은 사라지지 않는 경향이 있다. 당신은 그 외에 HTML에서 여전히 블링크 요소를 사용하는 그 밖에 많은 것들이 있다는 것을 안다. 그래서, 나는 앞으로 RSS가 대량의 넷에 공급하게 될 거라고 확신한다.

오브라이언: 당신은 사람들이 Atom에 관하여 놓치고 있다고 생각하는 것이 있는가? 아니면 당신은 그것이 커버되었다고 생각하는가?

브레이: 나는 아직 많은 사람들이 Atom Publishing Protocol을 알지 못한다고 생각한다. 지금 우리의 interop event의 tune에 의한 판단으로는 아는 사람들 또한 많다, 그러나 나는 지금으로부터 2년 내에 Atom Publishing Protocol이 정말로 대단한 것이 될 지는 의심스럽다.

나는 짧은 순간에 그것이 내 묘비의 XML을 닦을 기회를 가졌다고 말한다.

내가 이해시키려고 하고 있는 키 포인트는: 모든 것이 퍼블리시 버튼(Publish button)을 가져야 한다는 것이다. 왜냐하면 넷에서 우리가 더 많은 제공자를 가질수록 넷이 더 좋아지기 때문이다. 넷으로 더 많은 정보 자료들이 갈 수 있도록 마찰을 줄이기 위해 우리가 기술적으로 할 수 있는 것은 어떤 것이라도 좋은 것이다. 그리고 그것은 Atom이 하려는 것이다. 중요한 것은 사람들이 단지 읽는 것만이 아니라 제공하게 하는 것이다.

오브라이언: 당신은 Canonical과의 제휴에 관하여 알고 있었나?

브레이: 글쎄, 그것은 거의 비밀이 아니었다. 마크 셔틀워스는 지난 해 JavaOne에 참석했고 그와 조나단 [슈워츠]이 무대에서 입을 맞췄다. 그래서 Sun과 Canonical이 동료라는 것은 거의 비밀이 아니다.

오브라이언: 그때에 JaveOne에서 마크 플레리 또한 무대에 있었다, Red Hat과는 비슷한 제휴가 없었나? Red Hat과의 제휴 비용에서 당신이 Ubuntu의 편을 들고 있다는 추측이 사실인가?

브레이: 글쎄, 지난 주까지는, 우리가 JDK, NetBeans, EE, 그리고 이런 모든 다른 것들에 허가에 대한 문제를 가지고 있었기 때문에 당신은 어떠한 Linux 배포판 안에도 좋은 방법으로는 그것들을 넣을 수 없었다. 우리는 1년 전에 이런 것들의 소스를 공개하기로 정책 결정을 했다. 그러나, 아마도 당신이 아는 것처럼, 허가 권리와 그 밖에 여러 가지를 얻기 위해 돌아다닐 많은 법적인 메커닉이 있다. 그리고, 그것은 거대한 양의 일을 가져왔다. 나는 발표 얼마 전에도 그 일을 하고 있었다는 것을 알게 되었다.; 점을 찍기 위한 많은 i와 십자 줄을 긋기 위한 많은 t가 있었다. 지금 그것은 끝마쳤다. 어떤 리눅스 배포판에서도 Java를 설치하고 사용하는 것이 매우 매우 쉽다는 것은 매우 그럴듯하다.

Canonical은 올라서서 Ubuntu를 가지고 그것을 한 첫 번째 회사이다. 그러나 나는 그것을 하지 않는 어떠한 메인 리눅스 배포판도 상상할 수 없다.

당신이 왜 Java 설치하는 것을 쉽게 만들지 않겠나?

오브라이언: 자유 소프트웨어 커뮤니티에서 사람들로부터의 논쟁은 저작권 허가에 의해 방해 받는 코드의 부분이 여전히 있다는 것이다. 당신은 어떤 대답을 갖고 있는가?

브레이: 그것은 사실이다. 여전히 방해 받는 부분이 있다. 우리는 그것에 관하여 완전히 공개했다. 그 중에서도 나는 그것이 낮은 레벨의 Java SE 그것 자신에 있다고 생각한다. 몇몇의 예는 2D 그래픽과 폰트 렌더링이다. 우리는 그것을 계속 수정하면서 일하고 있고, 게다가 그것으로 커뮤니티를 위해 도울 희망을 가지고 있다. 전형적으로, 상업적인 제품이 공개되는 것은 언제든지 일어나는 일이다. 그것은 당신이 0에서부터 모든 것을 할 수 있는 이원 스위치가 아니다.

그렇게 말하는 반면에, 우리는 Canonical과 일을 하고 변호사를 고용하면서 ...그 안에 있는 방법을 생각해 낼 수 있었다.

오브라이언: ...다중우주...

브레이: 그렇다, 그것은 다중우주에 있다. 나는 Ubuntu의 권위자가 아니다. 나는 Red Hat에서 대응되는 것이 무엇인지 확실히 모른다. 그러나 그들은 그것이 Ubuntu에서 일어나게 만드는 방법을 발견했다. 그래서, 나는 어떠한 다른 리눅스 배포판에 대해서도 그것을 하는 것이 불가능할 것이라고는 상상할 수 없다.

오브라이언: 거기에 적의는 없는가?

브레이: 내가 아는 것이 아니다.

그것은 확실히 개발자 커뮤니티에서 바로 지금인 경우이다. Ubuntu는 “강한 마법”을 가졌다. Ubuntu는 많은 비율의 개발자의 주목과 애정을 정말로 약속하고 있다. 그리고 나는 Sun의 밖에서만큼 Sun 안에 Ubuntu를 향한 큰 애정이 있는 많은 사람들이 있다고 생각한다. 당신이 디지털 카메라에 연결하고 그것이 단지 작동하고 그 같은 여러 가지의 일을 한다.

오브라이언: JaveOne에서 나올 예정인 발표를 추측할 수 없다. 우리는 JRuby가 마무리되는 것을 기대할 수 있는가? JRuby 주위에 활동의 혼란이 있다는 것이 나타났다.

브레이: 활동의 혼란이 있다는 것은 너무도 명백하다.

오브라이언: 우리는 무엇에서 새로운 소식을 기대할 수 있는가? JRuby와 NetBeans? JRuby와 Glassfish certification?

브레이: 나는 예고에 대해서는 의견을 말할 수 없다.

하나만 말하겠다. 나의 견해는 JRuby에서 힘든 일을 실제로 가장 잘 다루는 사람이 Rails를 잘 작동시킨다는 것이다. 모든 Rails를 갖추는 것이 테스트를 통과하고 실제의 큰 Rails 애플리케이션을 매끄럽게 실행시킨다. 나는 그것이 Glassfish보다 아주 조금 더 많은 일을 하게 한다고 생각한다.

오브라이언: 나는 두 시간마다 이메일을 사용하고 그것들이 더 가까워지고 있는 것 같이 보인다. 찰스는 Rails가 지지 받을 때까지 JRuby를 고려하지 않을 거라고 말한 적이 있다. 그는 또한 Java에서 웹 개발의 어려움에 관하여 대중 연설을 한 적이 있다. JRuby와 Rails의 받아들임은 JavaServer Faces의 대안이 필요하다고 인정한 것인가?

브레이: 어떻게 설명할 수 있을까? 글쎄, 나는 우리에게 얼마나 많은 대안 프레임워크가 필요한 지 확실히 알지 못한다. 만약에 당신이 경험에 의존해서 그 시장을 본다면 많은 다른 프레임워크를 사용하는 개발자들과 다양한 웹 프레임워크를 사용하는 사람들이 있을 것이다, 둘 다 Spring과 Hibernate와 같은 공식적인 EE와 단순한 것들이다.

사람들은 PHP를 사용하고 있다, 정말 많은 사람들이 PHP를 사용하고 있다. Rails는 엄청난 성장 곡선을 그리고 있다. Python 커뮤니티로부터 사람들이 Django만큼 가까운 주의를 기울이지 않는 다른 것들이 있다. 나는 Sun이 그것처럼 세상에 존재할 필요가 있다고 생각한다. 그리고 그것처럼 세상에, 다른 많은 웹 프레임워크가 있고 모든 이런 웹 프레임워크가 실행하기 위한 iron과 그것들을 지원하기 위한 운영 체제가 필요한 애플리케이션을 만드는데 익숙해지고 있다. 나는 Sun이 우리가 할 수 있는 최고로 그들 모두를 사랑하려고 하지 않아야 하는 어떤 이유도 알지 못한다.

오브라이언: 그렇다면, JRuby on Rails가 JavaServer Faces와 경쟁을 하는 것이 아니다. 당신은 여전히 둘을 하나로 보는가?

브레이: 이것들 중 어떤 것도 사라지지 않을 것이다.

내가 갖고 있는 한가지 관심사는 Sun이 지난해 내내 Ruby on Rails와 기타 여러 가지에 관하여 매우 열정적이었다는 것이다. 그것은 PHP와 Django같은 것들을 무시할 수 있는 여유가 있다는 의미가 아니다. 나는 우리가 이런 모든 것에서 좋은 호스트가 될 필요가 있다고 생각한다. 그렇게 말하는 반면에, 나는 Rails가 매우 중요한 두 가지 조건의 시기(판매와 유지보수)에 웹 프레임워크에서 충격의 중심을 치고 있다는 것은 단지 Sun내에서만이 아니라 매우 널리 알려진 견해라고 생각한다.

오브라이언: 당신은 당신의 블로그에서 Seaside를 언급했다. 당신은 Seaside에 주목하고 있는가? Seaside에 관해 무엇이 당신의 흥미를 끄는가?

브레이: Seaside가 다른 모든 웹 프레임워크와 구조적으로 아주 다르다는 것은 분명하다. 당신은 여기를 경계해야 한다, 왜냐하면 내가 DabbleDB의 한 투자자로써 흥미 있는 분쟁을 하고 있기 때문이다. 그래서, 나는 거기에 진짜 돈을 가지고 있다. 그렇게 말하는 반면에, 내가 그 소프트웨어에 그렇게 깊은 감명을 받은 이유는 그것이 어떻게 만들어졌는지가 아니라 그것이 하는 일이다. DabbleDB는 완전히 훌륭한 사용자 인터페이스를 가지고 있고 나에게는 그것이 굉장히 유용한 어떤 것을 하는 것처럼 보인다. 나는 그것이 Seaside에서 만들어졌다는 것을 알았을 때 깜짝 놀랐다. 그러나, 분명히 그것의 존재는 Seaside가 유용하다는 매우 설득력 있는 증거다.

오브라이언: 그래서 Seaside는 주목을 받을 만한 것인가?

브레이: 나는 DabbleDB가 주목을 받을 만한 것이라고 생각한다. 그건 단지 그것을 만든 두 사람이 다른 프레임워크를 사용하는 것 같이 어떤 무언가를 생산할 수 있는 그런 훌륭한 디자이너인 경우에만 일지도 모른다. 그것은 적어도 Seaside가 흥미로운 것들을 만드는 데 익숙해 질 수 있다는 증거의 존재이다.

오브라이언: 나는 단지 당신에게 JRuby, 그리고 다른 웹 프레임워크에 관하여 일련의 질문들을 물었다. 그리고, Sun이 스크립팅을 받아들인 것에 관하여 더 복잡하고 더 적극적이 되고 있다는 것을 알 수 있었다. 그밖에 하고 싶은 말이 더 있는가?

브레이: 나는 Sun이 조금 변하려고 노력하고 있다고 생각한다. 지난 해까지는, Sun의 기본적인 위치가 “글쎄, 그 대답은 Java인데, 그 질문은 무엇이었는가?”였다. 그리고, 내가 우리가 더 에큐메니컬하게 되려고 노력하고 개발자들을 그들이 있는 곳에서 지지하려고 노력한다고 생각하기는 하지만, 그것이 우리가 어떤 견해도 가지고 있지 않다는 의미는 아니다. 분명히, 우리는 Java가 넓은 영역의 애플리케이션으로 아주 알맞다고 생각한다. 오늘날 우리가 Ruby 드럼을 두드리고 있다는 것을 알아 챘다면 그것은 올바르다. 그러나 그것이 당신이 PHP를 쓴다고 우리가 당신을 사랑하지 않는다는 뜻은 아니다.

우리는 더 에큐메니컬하게 될 필요가 있고 개발자들에게 그들이 어디에 있던지 접촉할 필요가 있다.

오브라이언: 당신은 JavaOne의 이름을 (JavaRubyPHPPython)One으로 바꿀 어떤 계획을 가지고 있는가?

브레이: 나는 그것에 대해 어떤 의결권도 갖고 있지 않다.