Develop/lang-ko

This is an on-going translation

Develop
[[Image:|center]]
Status:	unknown
Version:	unknown
Base:	unknown
Source:	unknown
l10n:	missing
Contributors
unknown

Develop의 초기 스크린샷

개발 액티비티는 슈가에서 액티비티를 만드는 액티비티입니다. 구성주의 정신 속에서, OLPC는 해커들이 쉽게 액티비티 소프트웨어를 만들거나, 다른 사람들의 소프트웨어를 활용 또는 수정할 수 있는 매커니즘을 위한 협동적이고 탐구적인 매커니즘을 요구합니다.

현대의 기크 용어로, Develop은 여러 가지 멋진 메쉬/인터넷 협업 특성들과 더불어, OLPC를 위한 Python "IDE"입니다.

목표

어린이들이 코드를 읽고 쓸 수 있는 것. Develop은 코드를 향한 창문입니다.

Develop은 대부분의 IDE에 공통적인 탭이 있는 텍스트 에디터, 클래스 브라우저, 그리고 파일 트리 뷰어를 제공합니다. 이 시각적 페러다임은 변경 가능하며 (나는 적어도 최적화 방안을 찾고 있습니다), 나는 이것에 대해 큰 애정이 없습니다. 일부 이맥스 스타일 키보드 명령어도 수행될 수 있으며, 특히, OLPC가 적절한 위치에 CTRL키를 가지고 있다는 점을 고려할 때 그러합니다. Guido Van Rossum과 the Python 커뮤니티 ( Ivan의 PyCon talk에 감사하며)는 Python의 클래스와 메쏘드 리로딩을 개선할 방안을 강구하고 있으며, 향후 Develop이 보다 스몰토크 방식의 접근법을 가질 수 있도록 허용할 것입니다. 액티비티를 메모리에 직접 올릴 수 있고, stop-change-start이 필요치 않을 것입니다. 이는 또한 Develop이 Squeak과 훨씬 비슷해지는데, 한 프로젝트 내의 모든 모듈 내의 모든 Python 클래스와 함수들을 잘게 나누고, 대신하며, 코드 작성자가 무언가를 변경하고, 이를 구동중인 액티비티에서 즉각 반영할 수 있도록 허용함으로써 그러합니다.

액티비티는 가변적이며, Develop은 도리깨

Develop은 새로운 액티비티를 만들거나, 옛것을 개선하는 것입니다.

소스보기 키는 이러한 생각의 확장입니다. 소스보기 키를 누르고, 액티비티를 개선하십시오. 친구들에게 나눠주고, 변화된 모습을 원저자에게 보내기도 하십시오.

No two-tiered system. Develop은 모두를 위한 것입니다

Develop은 기술이 허용하는 한, 공식적인 액티비티를 작성하는 해커들 또는 전통적인 컴퓨터 장비를 이용하는 이들이 사용하는 개발 툴들과 동일한 기능을 제공해야만 합니다. OLPC가 파이선으로 슈가 사용자 경험을 작성한 이유는 쉽고 유연하기 때문입니다. 따라서, Develop은 "toolchains" 또는 "headers"와 같은 추가적인 "개발" 컴포넌트없이도, 완전한 액티비티 개발 환경을 쉽게 제공할 수 있습니다. 이 것은 어린이들이 최고의 개발자들과 동일한 위치에 있음을 의미합니다.

Develop은 그러한 정신으로 작성됩니다.

코드 작성은 흔히 커뮤니티 과정입니다. Develop을 통해, 패치 patches가 흐릅니다.

Develop은 일관적인 협업 시스템 수행을 위해 분산된 소스 컨트롤 매니저를 이용합니다. 이 컴포넌트의 주요한 측면은 어린이들에게:

• 기존 액티비티의 파생품으로 전적으로 새로운 무언가의 창조하고,
• 단일 액티비티를 하나의 그룹으로 생산하기 위해, 각자의 변경 부분을 통함 함으로써 단일 액티비티 상에서 협업 (리눅스 커널 스타일)할 수 있도록 합니다.

XO는 온전히 협업을 위한 도구입니다. Develop은 짝 프로그래밍을 가능하게 합니다.

짝 프로그래밍 Pair Programming은 HIG이 보여주듯, OLPC의 내재적인 협업 특성들을 잘 상속하고 있습니다.

Develop은 내재된 AbiWord 위젯을 이용하여, 텍스트 에디터 버퍼를 제공합니다. AbiWord는 이미 Write 액티비티를 위한 생동감있는 협업을 수행하므로, Develop는 동일한 기능을 마술처럼 흡수하여, 플랫폼에 완전히 일관적으로 작동합니다. XO가 실시간 오디오 챗을 모든 액티비티 참가자들에게 제공하므로, 이것은 진정한 원격 짝 프로그래밍을 제공합니다.

이 특성은 표준 슈가 공유 버튼을 통해 접근할 수 있습니다.

Develop은 록스타 OLPC 해커를 위한 것이기도 합니다..

Develop은 어린이들 뿐 아니라 *모든 이*가 액티비티를 쉽게 작성하도록 합니다. 트리뷰가 있는 탭 텍스트 에디터보다 조금 나은 수준인 현재의 Develop도 XO 해킹이 즐거운 경험이 될 수 있도록 합니다.

Develop은 최선의 관행을 따르도록 합니다.

Develop은 테스트 슈트 test-suite매커니즘, 쉬운 버그 트래커, 그리고 "Agile" 스타일 프로그래밍을 고무하는 오픈 패스웨이 open pathways 와 같은 여러 기능을 제공합니다.

Develop은 여가 놀이이자, 교실 수업용입니다.

OLPC의 다른 부분들과 마찬가지로, Develop은 교사들로 하여금, 학생들이 도구 사용법, APIs (영어를 모르는 아이들조차 신속히 학습하는) 사용법을 익히도록 돕고, 컴퓨터 프로그램 작성이 어떤 의미인지에 대한 기본 개념을 배우도록 도울 수 있게 합니다.

이것은 초급 컴퓨터 과학 강의를 진행하는 교육자나, 단지 놀이 목적으로만 컴퓨터를 만지작거리는 어린이들 모두에게 적합해야 합니다.

수행 토론

아래 내용은 우리가 상기 요구를 수행하는 방법에 관한 대략적인 설명입니다.

라이팅 액티비비를 위한 최소 그리고 직관적인 인터페이스

개발은 협법과 버전 컨트롤을 포함한 소프트웨어 개발과 정의 논리적 복잡성을 상당부분 제거할 필요가 있습니다. 그냥 작동해야 합니다. 어린이들이 소스코드 컨트롤 시스템과 버그 트랙커를 관리할 것으로 기대한다면, 그들은 그냥 안 합니다 (우리들 대부분도 마찬가지입니다.)

개발 액티비티가 기존의 전통적인 IDE 디자인과 상당히 다르다는 것을 주목해야 합니다; 이것은 "프로젝트"를 단순히 디렉토리 정도로 간주합니다. 이것은 activity bundles에 의해 강제되는 .info 파일과 Bazaar (or GIT) 버전 컨트롤 시스템의 .bzr (or .git) 디렉토리 내의 저장 수준을 넘어서는 세션들 간의 프로젝트 메타데이터를 관리하지 않습니다. 가능한 이것을 최대한 회피하는 것이 좋습니다.

개발은 슈가 액티비티 외의 Python 패키지를 보고 편집할 수 있는 수단을 제공합니다. 개발은 다시 연 프로젝트에서 액티비티 메타데이터를 탐지하지 못하면, 그냥 슈가에 고유한 특징들을 제공하지 않습니다. 새로 연 디렉토리가 bazaar 브랜치 (".bzr") 또는 GIT 데이터베이스를 포함하지 않으면, 버전 컨트롤과 일부 협업 속성들이 활성화되지 않습니다.

개발 중인 액티비티들이 어디에 보관될 지는 아직 결정되지 않았습니다 (저널 통합?). 버전 컨트롤을 참조하십시오.

버전 컨트롤

이것은 매우 중요한 컴포넌트로, 저널링은 물론 협업 작업의 기초를 제공하기 때문입니다. 우리는 저널 정신 (그리고, 물리적으로 가능한 저널과 밀접히 통합된 형태로) 속에서 이것을 수행할 것입니다.

대부분의 버전 컨트롤 액션은 가능한 사용자로부터 추상화되어야 합니다. 개발은 소스 컨트롤의 모든 일상적 측면들을 고려해야 합니다; 새로 만들어진 파일들은 일단 옮겨지면 자동적으로 추가 또는 삭제될 것입니다.

사용자에게 직접 노출되는 유일한 VCS 속성은;

• Commit ("Write a journal entry" 또는 비슷한 언어가 적절할 것입니다.)

• 히스토리 뷰어 ("View Journal")

• 협업 속성. 슈가 인프라스트럭쳐의 상당부분을 요구하므로 이것이 어떻게 작동할 지는 아직 불명확합니다.

VCS 시스템의 선택

개발은 Bazaar을 분산된 버전 컨트롤 속성을 제공하는 엔진으로 이용할 것입니다. 이것은 OLPC 커뮤니케이션 매니저와 상대적으로 쉽게 연결될 수 있는 똑똑한 서버를 가지며, 저장 공간을 매우 효율적으로 이용합니다. 이것 역시 파이선으로 작성되며, 사용자가 쉽게 읽고 수정할 수 있을 것입니다.

공식적인 OLPC 액티비티들이 현재 Bazaar가 아니라 git로 트랙되고 있지만, Bazaar 의 foreign branch facility는 개발에 매우 적합합니다.

Version Control Collaboration

커뮤니티 뷰의 모크업

협업은 매우 중요하며, 특히 사람들이 대규모의 복잡한 과제를 수행할 때 그러합니다.

개발은 브랜칭을 위해 (물론, 저자의 옵션으로) 버전 컨트롤 브랜치를 메쉬 상에 노출할 수 있는데, 개발이 동작 중이지 않을 때도 그러합니다. Presence 시스템은 이용자가 메쉬 상의 다른 개발 인스턴스들의 피어 액티비티 브랜치를 만들 수 있는 옵션을 허용합니다. 이 방식으로, tree originator는 메쉬 상의 버디로부터 발생한 변경을 수락할 것인지 묻는 메시지를 받게 될 수 있습니다. 이것은 기본적으로 리눅스 커널 스타일의 분산 버전 컨트롤이 어린이에게 매우 kinetic 방식으로 다가서며, OLPC 메쉬 네트워킹 시스템 내에서 통합되고 수행될 수 있게 허용합니다.

액티비티 번들은 인터넷 또는 메쉬 상의 리포지토리를 가리키는 메타데이터 내의 리보피토리 포인터 (a URI)를 포함할 필요가 있습니다. 따라서, 어떤 사용자가 다른 누군가에 의해 작성된 액티비티에 대한 소스 보기 키를 누를 때, 개발은 해당 액티비티를 브랜치할 수 있게 됩니다. 이것은 많은 가능성을 제공하는 아래 기술되어 있습니다. 이 특성은 원천이 불명확한 (인터넷 접속이 안되거나, 메쉬 상의 가용하지 않은 버디로 인해) 경우나 장애 발생 상황에 대처할 수 있어야 합니다.

당연히, 메쉬 안팎의 브랜치에 상이한 URI 포매팅이 요구될 것입니다.--Orospakr 22:08, 20 January 2007 (EST)

By using the origin information in the branch, 개발 will be able to plot the development hierarchy of the Activity, giving the user a "bird's eye" view of most if not all of the community surrounding that activity's development (see mockup at right). This feature may also query Presence for the existence of any "sister" branches on the mesh.

We can not rely on the Activity's name being a suitable unique identifier given this kind of ecosystem. Activity bundles will need to be identifiable between different people publishing them; for instance, if someone modifies TamTam and shares the bundle on the mesh, the other laptops must be able to distinguish it from the upstream release of TamTam.

The Activity bundle should contain either an author field of some kind, or even a GUID (bleh). --Orospakr 22:08, 20 January 2007 (EST)

This feature is particularly intriguing!

Bug and Task Tracker

A little bug tracker facility would not be amiss either. This too should be integrated into the collaboration features.

The View Source key

Keys

Pressing the View Source key will instruct 슈가r (would this be d-bus magic because Activities are dbus services?) to invoke Develop on the currently active running activity. 개발 will then create a copy for them to change as they like (a "fork", or "branch"). If the branch is not available because the other person's XO is off or the Internet site is down or not accessible, Develop will need some sort of sane fallback.

Activity Bundle Creation and Sharing

Develop will provide a means to allow an activity author to set sugar activity-specific metadata (most of which is persisted in the activity/activity.info file)

Develop will also provide UI for activity bundle creation (only available when the currently open project is actually a Sugar activity, of course), and interaction with both Sugar's activity sharing features and the public repository hosted by the OLPC project. This should almost certainly interact in some way with the Version Control features.

User Stories

These little anecdotes describe what people might do with Develop.

Story #1 (changing an existing activity)

This documents what a user would do to create their own version of an activity, either from laptop.org or someone else on the mesh.

1. Sally starts TamTam and plays with it.
2. She decides (or perhaps as part of a project in programming class) that it would be really awesome if she could make TamTam play instruments backwards (ok, I'm reaching here... ;)
3. She presses the View Source button on the XO keyboard.
4. Develop pops up (I am not sure how this bit of UI should be designed visually yet) and asks something like:

You pressed the View Source button. Would you like to just look at the source code of TamTam, or would you
like to create your own version to change and give to others?

1. She clicks the second button.
2. She enables tree sharing so that others may branch her version off her laptop just as she branched it off the original TamTam.
3. Hack, hack hack.
4. She can then press the Run button to run her modified TamTam (Run will serve as the 'publish' function as well, because when you run an Activity and share it, others can click it in the Sugar mesh view and download it. Pretty intuitive, eh? :D )

Story #2 (creating a new activity)

This documents what a user would do to create their own activity from scratch.

1. Maurice wants to write a simple game, entitled "Super Cat Protect!"
2. He clicks the Develop icon at the bottom of the frame, and Develop asks if he would like to continue working on an existing activity, or if he would like to create a new one. He chooses the latter.
3. Develop creates the new Activity, initialises an empty version control repository, and displays a form to allow Maurice to enter the properties of his new project (Name, Description, Enable Sharing).
4. Hack, hack, hack.
5. Expose the repository for branching over the network if Maurice opted for it.

Story #3 (creating a SoftPhone activity)

This is an example of an activity that a user might want to create along with how they might go about creating it. This is not about how things would get done, it's about what level of activity we are interested in allowing to occur within the develop activity. This is a minor application, something that would be relatively easy to create in a classical IDE, it's trying to ask the question "What happens during 'hack, hack, hack' for a 12 year old with a dream?"

• User wants to create an activity that allows any Sugar user to log into a SIP server (presumably outside the Sugar cloud) and use that server to initiate VoIP calls to the Plain Old Telephone System
• User creates a new activity
• User designs icons in the "draw" activity for the new activity, the various states of the connection, the server to which they are connecting, etceteras
• User creates a "form" of some sort into which the user can enter their configuration
• User connects the form to code snippets that validate the form values
• User connects the form in total to code that validates the whole configuration and stores the settings in some database or similar structure
• User provides a "form" for entering the phone number to call
• User connects the form entry to a code snippet that creates a SIP connection to the server, negotiates the SIP session, then sets up the RTP (voice) connection to the server
• We would presume that the SIP connection mechanism would be provided as a control of some sort, possibly integrated into the presence system
• The user might have to code the gstreamer chain to produce the RTP stream from microphone input, or that might be provided as a prebuilt control
• The user would likely connect images/controls to the SIP connection mechanism to display status and the like
• User creates a "phonebook" entry form, hooks it up to store records in the standard database/datastore
• User creates a "phonebook" view form, this would be a view on the datastore/database
• User creates a control that allows for searching the collection of numbers/addresses, hooks up that form to a function doing a filter of the datastore view

Here the user could publish the "outgoing call only" version of the application. And some other user could pick it up and decide to add an incoming call functionality:

• User creates an "always on" mechanism (think panel applet in a "normal" desktop)
• Has the always on mechanism do a SIP register on logon (maybe via the presence service)
• Has the always on mechanism allow for incoming telephone calls (opens a port in classical terms)

This might be an ambitious project for a 12 year old, but it's likely within their grasp (certainly there are 7 or 8 year olds who write more complex programs).

Story #4 (creating a school radio activity)

In the same vein as the VoIP Phone activity; a user would like to create an activity that allows a group of people to produce 5 minute live "announcements" or "school radio" programs, to be distributed to all of the laptops in the area (remote schooling situation). The program would want to have prompts to let people know that they were up next, up, and running out of time, as well as a mechanism to allow for reading "scripts".

• the user wants to create a single "channel" that will be handed off to multiple sources as controlled by a single person
• creates a radio controller activity
• adds view that allows for "adding" some number of "readers" as clickable icons from the presence service
• creates a "shared model" that simply has the "current reader" and the script (null by default) (I'm over-simplifying here)
• adds view for showing the script (imported from writer, possibly created using collaboration, of course)
• connects up the "reader" icons such that a first click warns the user that they are up and changes the icon (updates the "next reader" in the model) and the second click gives the user the microphone (updates the model to point to the new reader/laptop as current)
• possibly allow all readers to share the controller activity (allowing them to, for instance, deactivate their own "next up" status if they are not ready)
• creates a "service" mechanism that allows others to connect to the laptop running the controller activity in order to get the shared model (something like "share this activity", but in asymmetric mode).

Now, the user creates the second activity, the "radio receiver" activity:

• this activity is used to connect to a radio controller
• it pulls the model off the controller laptop and follows the connections as specified, using the "next up" model changes as signals to set up an RTP connection and the "up" model changes to start up the connection

Human Language and Culture Concerns

Unfortunately, language keywords, identifiers, docstrings and comments are almost exclusively English or based upon English terms. This means that fledgling developers are forced to learn at least some subset of English in order to read and write both code and documentation.

There are no feasible technical solutions to this problem, because attempting to maintain translations of even one aspect (such as docstrings) is a prohibitively expensive endeavour.

There is no evidence that this is unfeasable or prohibitively expensive. Given that modern IDEs do syntax colouring and that a language like Python has a small number of English keywords, it seems very feasable to provide some mapping to native language keywords for display purposes. And since this mapping requires a dictionary to do the mapping, it would seem a fairly small job to extend that mapping to built-in function, class, module and attribute names. The system can always fallback to making the English name visible if no mapping exists. In addition to built-in mappings, this IDE could read additional mappings from specially formatted comments in the source as long as the source is in UTF-8 and arguably, for the OLPC projects, it should always be in UTF-8.

This is not an insurmountable problem. And the mapping is only needed for keywords and for identifiers with fairly clear English names. For instance, it makes sense to translate 'String' which has a fairly transparent English meaning but it does not make sense to translate 'httplib' which is an obscure technical term whose meaning must be learned, even in English.

No. I didn't suggest that in the original of this document because it would break everything. Code snippets, collaboration, everything. The only way one could sort of make this work is via some hacktacular string munging. Naturally, that would earn a stack of about 50 "Considered Harmful" documents. The best way to deal with this issue is just to consider the English-esque keywords simply part of the Python language, not the English language. (actually, as I mentioned before a docstring translation matrix is an idea, but it would be very hard to maintain.) -- Andrew Clunis (Orospakr)

ROTFL, it is indeed a hacktacular idea that would earn 50 "Considered Harmful" documents. User-defined variable and function names could collide with keywords in any of 200 to 500 different languages! That said, something like tooltips might not be insane. It'd have to not be some irritating in-your-face thing that gets in the way of typing though. Perhaps the most recent pointer/carat move to cross over a keyword could cause a 1-line help message on a status bar. Syntax coloring is out though, because you need to run in greyscale mode to get a decent amount of clearly readable text on the screen. In greyscale mode, the 6x13 fixed font should be readable for most kids. (not for YOU maybe; your eyes are old and probably getting farsighted with age) AlbertCahalan 16:33, 25 February 2007 (EST)

Once I get my XO I'll play around with visibility related issues. I have a feeling that I'll be able to keep syntax colourising, because the actual screen resolution does not change, only effective *colour* resolution. luminance resolution remains, afaik. Mary Lou Jepsen says that black text on a white background is the proper way to use the display. --Orospakr 23:22, 2 March 2007 (EST)

Well... the addressable screen pixels do not change. There is a blur being applied though, and then 2/3 of the data gets discarded. Here are your images modified in that way: (view them full-size only) Note that I'm being optimistic; the blur could fail to account for gamma. It should be pretty obvious that a greyscale version of the originals would be more readable. AlbertCahalan 12:43, 3 March 2007 (EST)

Eeeeeeek! --Orospakr 14:52, 3 March 2007 (EST)

BTW, you were only using 800x600. You'll get 1200x900. AlbertCahalan 17:54, 3 March 2007 (EST)

In case you didn't get your XO yet, here it is on a B2 display. AlbertCahalan 15:04, 10 March 2007 (EST)

I want to offer a little bit of personal experience here. I first learned to program when I was 7, I think. I didn't speak a word of English then, but I was quite motivated. I had a book in Dutch about BASIC, and a BASIC interpreter that spoke English. Basically what happened is that somehow, I learned just enough English to use it. It's almost like kids whose parents speak in some foreign language they both know when they don't want the kids to understand them: it's a sure-fire way of teaching your kids a foreign language. I had no idea how to pronounce things, of course, nor what they meant outside the context of BASIC. I knew what "For without next", "While without wend" and "Syntax error" meant, even though I had no idea what "without" was or even that it was a preposition. It helped that the BASIC interpreter only used a limited vocabulary of English messages, which were all documented in the book, but in general, I think that most programming jargon is sufficiently different from regular English, and the similarities sufficiently misleading, that a kid will be able to learn an amazing amount of it without actually having to learn English as a general-purpose human language. To this day, when I see a "goto" statement, I mentally pronounce it as "khoe-toe"...

Get the Code (such as it is)

Although it's very early in the development cycle, you can:

git-clone git://dev.laptop.org/projects/develop-activity

to see how it looks right now.

환영합니다 | Portal | XO Korea | Deployment | Content | Hardware | Software | Mesh Network | Ethics | LOS | XO City | Accreditation | Consortium