번역근원 Develop	원문
english \| 日本語 \| 한국어 +/-	차이

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 (영어를 모르는 아이들조차 신속히 학습하는) 사용법을 익히도록 돕고, 컴퓨터 프로그램 작성이 어떤 의미인지에 대한 기본 개념을 배우도록 도울 수 있게 합니다.

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

수행 토론

What follows below is a vaguely structure set of notes on how we will likely implement all of the above requirements.

Minimalistic and Intuitive Interface for Writing Activities

Develop needs to abstract away many of the logistical complexities of software development, including collaboration and version control. It needs to Just Work. If we expect the young people to manage their source control systems and bug trackers, they simply won't (this is actually true of most people; unless it is given to them on a silver platter they will simply not bother until it is too late). As the people writing this system, we can impart a little project management wisdom in Turing-complete form.

It is important to note that develop-activity makes a significant departure from traditional IDE design; it will consider a "project" to be little more than a directory. It does not persist any sort of "Project" meta-data between sessions beyond what is stored in the .info file mandated for activity bundles, and the .bzr (or .git) directory of the Bazaar (or GIT) version control system. Develop may, however, persist activity-specific settings in Develop's own configuration directory. It would be best to avoid this as much as possible.

Develop will provide a means for viewing and editing Python packages other than Sugar activities. If Develop does not detect activity metadata on a reopened project, it will simply not provide Sugar specific features. The same goes for version control; if a reopened directory does not contain a bazaar branch (".bzr") or a GIT database, the version control and some collaboration features will not be available either.

Where activities currently under development will be stored has not yet been decided (journal integration?). See the Version Control section for more info.

Version Control

This is a very important component, as this will provide the basis for collaborative work as well as Journaling. We should try to implement this in the spirit of the Journal (and as tightly integrated with the Journal as physically possible).

Most version control actions should be as abstracted away from the user as possible. Develop should take care of all routine aspects of source control; newly created files shall be automatically added, deleted ones removed, etc.

The only VCS features that will be directly exposed to the user will be:

Commit ("Write a journal entry" or similar language might be appropriate)

A history viewer ("View Journal")

The collaboration features. How this will work is as yet unclear as it will require a lot of sugar infrastructure.

Choice of VCS system

Develop will use Bazaar as the engine to provide the distributed version control features. It has a smart server which can be bound to the OLPC communication manager relatively easily, and makes fairly efficient use of precious disk space. It is also written in Python, and therefore it may be read and modified readily by the users.

Although the official OLPC activities are currently tracked with git and not Bazaar, the foreign branch facility of Bazaar should prove sufficient to allow Develop to branch these.

Version Control Collaboration

Mockup of the Community View

Collaboration is of paramount importance, especially when people are working on things that can be as large and complex as computer programs.

Develop will expose the version control branch over the mesh (at the author's option, of course) for branching, even when Develop is not running. The Presence system would permit other Develop instances on the mesh to present users with the option to create branches of their peers' activities. The peer could then push her changes back to the original person she branched from. This way, the tree originator could be prompted with a message asking if they would like to accept a change from a buddy on the mesh. This basically would permit Linux kernel style distributed version control in a very kinetic way for young people, integrated and implemented within the OLPC mesh networking system.

Activity bundles will need to contain a repository pointer (a URI) in the metadata either pointing to a repository hosted on the public Internet or on the mesh. Thus, when a user presses the View Source key for an activity written by someone else, Develop will be able to branch the Activity. This offers up many possibilities, described below. This feature will need to deal with the situation of origin unavailability (either lack of Internet connectivity or unavailable buddy on the mesh) and fail gracefully.

Naturally, a different URI formatting will be required for branches either on or off the mesh. --Orospakr 22:08, 20 January 2007 (EST)

By using the origin information in the branch, Develop 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 Sugar (would this be d-bus magic because Activities are dbus services?) to invoke Develop on the currently active running activity. Develop 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.

Sally starts TamTam and plays with it.
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... ;)
She presses the View Source button on the XO keyboard.
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?

She clicks the second button.
She enables tree sharing so that others may branch her version off her laptop just as she branched it off the original TamTam.
Hack, hack hack.
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.

Maurice wants to write a simple game, entitled "Super Cat Protect!"
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.
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).
Hack, hack, hack.
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.

Develop/lang-ko

Contents

목표