http://www.w3.org/WAI/eval/selectingtools
w3c.org에 등록 되어있는 웹접근성 툴 리스트

[원본] : https://www.sulinux.net/bbs/board.php?bo_table=success_2&wr_id=168

1.    PHP 경로 확인
php, pear, pecl 등의 실행파일이 /usr/bin/ 아래에 존재하거나 링크되어 있는지 확인해야 합니다. 
Apache+PHP 를 RPM 으로 설치했다면 해당 위치에 존재하지만 컴파일로 설치했을 경우 다음처럼 /usr/bin/ 아래로 링크를 걸어주어야 합니다.

[원본 주소] : http://navyism.com/main/memo.php?bd=apm_tip&no=20
Apache 인증모듈이란 특정 디렉토리에 대한 접근을 apache가 통재하는 것입니다. 관리자페이지가 있는 디렉토리에 설정을 해두면 좋습니다. 본 사항을 적용 후 접속을 하면 브라우저에서 FTP를 접속 할 때와 같은 로그인 창이 뜨게됩니다.
아래글은 tozigy.com에서 가져온 글을입니다._>>


Pbi12라는 분이 linux.co.kr에 올리신 글인데 꼼꼼하게 잘 설명한듯 보여서 올립니다. 저도 도움을 받았고요. 훗;

*전제 조건이 있습니다.  
ROOT 즉 절대 권한을 가진 서버관리자가 셋팅을 해줘야 한다는 것입니다.  
root가 없다면 서버 관리자에게 httpd.conf부분만  
이렇게 해달라고 요청하셔야 합니다.  


1. httpd.conf를 수정한다.  

먼저 /usr/local/apache/conf/httpd.conf에서  
디렉터리에 대한 옵션 부분에 보시면  
AllowOverride None으로 되어 있으면 AllowOverride All로 바꾸줍니다.  
# AccessFileName .htaccess줄이 주석줄로 되어 있으면 주석도 풀어줍니다.  


2. .htaccess파일을 만든다.  

인증을 받고 싶은 디렉토리로 가서 vi로 아래와 같은 파일을 만들어야 합니다.  

======================================================  
AuthType Basic  
AuthName pbi12  
AuthUserFile /home/pbi12/public_html/pds/.htpasswd  
require user pbi12  
======================================================  
이 내용을 .htaccess로 저장해줍니다.  
여기서 name과 아래 3번에서 생성할 .htpasswd 파일의 경로를  
자신의 환경대로 바꾸어 줍니다.  
그리고 마지막에 중요한게 require 인데,  
여기서는 유저 한명씩 할때 처리 방법입니다.  
user 인 pbi12 한명을 넣은 것이죠.  
아래 나오는 부분에서 유저를 생성하게 되는데 그 유저를 여기다가 넣어서  
쓸 수 있는 것입니다. 더 추가 할 때에는 pbi12 다음에 한칸 띄고 나서  
다른 유저 이름을 적으시면 됩니다.  


3. .htpasswd파일을 만든다.  

암호파일(.htpasswd)은 암호화되어서 저장이 되므로 그냥 텍스트로 입력해서는 안되구요,  
/usr/local/apache/bin에 있는 htpasswd라는 프로그램을 이용해서 만드는데,  

shell# /usr/local/apache/bin/htpasswd -c /home/pbi12/public_html/pds/.htpasswd pbi12  

이것은 htpasswd 를 해서 -c 새파일을 만드는데, pbi12의 디렉터리에 .htpasswd로 생성하며,  
pbi12라는 유저를 추가한다는 것입니다.  
이렇게 형식으로 치면 암호를 넣으라고 나오는데 여기에 암호를 적어 넣으면 성공입니다^^;  
(이때 -c 옵션은 처음 넣을때만 하면되며 그 다음 부터 추가할때는 필요가 없습니다.  
그 다음에도 -c 옵션을 추가하면 이전 것(.htpasswd)은 지워버리고 새로 작성되므로 추가 하실때에는 그냥 -c 옵션 없이 다른 유저를 추가하시면 됩니다.)  

그러면 .htpasswd의 파일이 아래와 같이 생성되어진다.  
pbi12:NoWPewwtesgrTR  


4. 아파치를 재시작합니다.  

# /usr/local/apache/bin/apachectl restart  


5. 종료!  

이렇게 되면 자신이 .htaccess 를 넣은 곳을 웹에서 접속하게 되면 아파치 인증창이 뜨게  
됩니다. 자신이 만든 유저 정보를 치고 들어가면 접속이 되는 것이구요~  


보통 사용하실 분들은 여기까지만 보셔두 상관없습니다.  

아래에는 그룹으로 지정하고 싶으신 분을 위한 코너입니다^^;  


ADD1. 그룹으로 아파치 인증을 만들때에...  

유저를 추가하는 것과 크게 다른 점은 없습니다.  
하지만, .htaccess파일을 만들때에  

======================================================  
AuthType Basic  
AuthName pbi12  
AuthUserFile /home/pbi12/public_html/pds/.htpasswd  
AuthGroupFile /home/pbi12/public_html/pds/.group  
require group admin  
======================================================  

이렇게 바뀌어야 합니다.  
그룹을 참조할 파일을 추가 해주는 것입니다.  
그리고 require에서는 group 을 admin 그룹으로 할때 저런식으로 해주는 것입니다.  
admin 그룹을 만드는 법을 알아보겠습니다.  


ADD2. 그룹 참조 파일 생성하기...  

이 부분은 별로 어렵지 않습니다.  
유저를 생성하고 나면 그 내용을 참조해서 그룹으로 묶어 주는 것이기 때문입니다.  
.group 파일안에다가  

===================  
admin: pbi12 pds  
===================  

위의 가운데 한줄입니다.  
저렇게 넣어주면 admin 이라는 그룹안에 pbi12 라는 유저와 pds 라는 유저를 묶으겠다는 말이 됩니다. 그러면 admin 그룹을 사용할 수 있는 것이죠.  

마지막으로 말씀 드리고 싶은 것은 .htpasswd 라는 파일과 .group 파일의 이름은 여러분 마음대로 바꾸셔도 상관없다는 점 말하고 끝내겠습니다.  
아참! .htaccess 파일은 사용하고자 하는 위치에 저 이름 그대로 사용하셔야 하는 점 혼동 마시구요 ~  
그럼 아파치 인증을 마치겠습니다.  

명함

mysql 4.x 버전에서 mysql 5.x 버전으로  db를 이전 할 경우
charset문제로 한글이 깨지는 경우가 발생

mysql4 버전에서 phpmyadmin을 이용하여 db backup 함..
백업시 완전한 insert  체크 박스에 체크를 한 후
데이터 베이스 타입을 mysql 4로 선택 한 후 파일로 저장 한다.

저장된 파일을 Edit 플러스로 열어서
파일 -> 새로운 이름으로 저장을 클릭 한다.

새로운 이름으로 저장할 때 인코딩 타입을 ANSI로 선택 하고 저장 한다.

ANSI 포멧으로 저장된 파일을 mysql5 에 mysql 명령어를 이용하여 콘솔상에서 넣어 주면
됨.

Informational 1xx 
100 Continue
101 Switching Protocols


Successful 2xx 
200 OK
201 Created
202 Accepted
203 Non-Authoritative Information
204 No Content
205 Reset Content
206 Partial Content


Redirection 3xx 
300 Multiple Choices
301 Moved Permanently
302 Moved Temporarily
303 See Other
304 Not Modified
305 Use Proxy

 
Client Error 4xx 
400 Bad Request
401 Unauthorized
402 Payment Required
403 Forbidden
404 Not Found
405 Method Not Allowed
406 Not Acceptable
407 Proxy Authentication Required
408 Request Timeout
409 Conflict
410 Gone
411 Length Required
412 Precondition Failed
413 Request Entity Too Large
414 Request-URI Too Long
415 Unsupported Media Type


Server Error 5xx 
500 Internal Server Error
501 Not Implemented
502 Bad Gateway
503 Service Unavailable
504 Gateway Timeout
505 HTTP Version Not Supported 

\r\n  <-- TextBox에 글쓸 경우 엔터 누름

http://actionscript.org 
flash action script 관련 예제 자료들이 많이 있음

스콤 (Scorm) : 교육정보 표준화 규격

 작성자 : 조용상 (한국교육학술정보원 선임연구원 :  zzosang@keris.or.kr

 

 출처 : 현장특수교육 2005년 7-8월호

e-러닝에 있어 가장 중요한 문제로 대두되는 것이 상이한 환경에서 만들어진 콘텐츠가 상이한 컴퓨터 환경에서도 무리 없이 잘 작동되어야 한다는 것이다. 이같은 문제점을 해결하기 위해 만들어진 것이 바로 스콤(SCORM)이다. 교육정보 표준화 규격으로 원활한 e-러닝을 위해 도입된 스콤에 대해 알아본다.

e-러닝 표준화 규격인 스콤(SCORM : Sharable Content Object Reference Model)을 논하기에 앞서 최근 교육 분야에서 자주 논의되고 있는 ‘e-러닝’이라는 개념을 먼저 생각해보는 것이 이해를 돕는 데 도움이 될 것 같다.
e-러닝에 대한 정의를 각종 보고서에서 유사하게 정의하고 있는데, 이 글에서는 ‘인터넷과 첨단 전자매체를 활용하여 누구나, 언제, 어디서나 원하는 교육정보 서비스를 제공받을 수 있고, 자기주도적인 학습과 상호작용 활동을 통해 다양한 학습경험을 수행할 수 있도록 하는 교수-학습체제’(임병노, 2004)로 정의를 내리고 진행하고자 한다. 이러한 정의의 의미로서 2004년 교육인적자원부, 16개 시·도교육청, 한국교육학술정보원이 공동으로 추진했던 ‘사이버가정학습체제’는 초·중등 교육 분야에 시도된 대표적인 e-러닝 사례라 할 수 있다.

서비스 환경에 영향 받지 않기 위해 규정된 표준화 규격

‘사이버가정학습체제’와 같이 여러 기관이 각각 콘텐츠를 만들고 다양한 컴퓨터 환경(가정 및 학교의 다양한 PC 등)에서 학습을 할 때 발생할 수 있는 문제점들을 생각해보자. 먼저 여러 기관에서 개발된 콘텐츠가 오류 없이 동일하게 서비스될 수 있는지에 대한 문제와 학습자의 학습활동에 대한 기록을 각기 다른 데이터베이스를 운영하고 있는 기관에서 동일하게 기록할 수 있을지에 대한 의문이 가장 먼저 들게 된다.
이러한 문제점들을 해결하고자 ‘사이버가정학습체제’에서는 스콤이라는 표준화 규격을 적용하여, 어떤 교육청에서 개발된 어떤 콘텐츠라도 서비스 환경에 영향 받지 않고 운영될 수 있도록, 그리고 어떤 학습자가 어떤 콘텐츠를 학습하더라도 학습이력을 기록할 수 있도록 표준화 규격을 적용하였다.
스콤에 대한 좀더 세부적인 내용을 살펴보기로 하자. 아래 그림은 스콤 규격에 대한 종합적인 구성을 설명하고 있다.
스콤의 규격은 크게 ‘콘텐츠 집합 모델’, ‘시퀀싱 & 내비게이션 규칙’, ‘콘텐츠 실행 환경’ 등 3가지 구성요소로 이루어져 있다.
먼저 ‘콘텐츠 집합 모델’은 카세트테이프에 비유할 수 있는 규격이다. 카세트테이프에 담겨질 내용이 영어회화이든 음악이든 상관없이 재생하기 위해 정해진 크기의 테이프에 담겨지기만 하면 되듯이, 콘텐츠도 내용과 제작된 파일형태에 상관없이 콘텐츠 집합모델에 정의된 규격대로 패키징(포장)만 하면 어느 서비스기관에 가져가더라도 콘텐츠가 서비스될 수 있는 것이다. 보통 콘텐츠가 패키징된 상태는 zip파일과 같은 압축파일 형태를 띄고 있다.
두 번째 ‘시퀀싱 & 네비게이션 규칙’은 콘텐츠가 하나의 파일이 아니라 여러 개로 객체화되었다는 가정에서 출발한다. 예를 들면, 하나의 차시를 구성하는 콘텐츠가 ‘안내-본학습-평가-심화 또는 보충’과 같은 단계로 구성되었다면, 각 단계를 학습객체로 볼 수 있다. 지금 예를 든 것과 같이 각 학습단계를 콘텐츠 내부에서 정의하는 것이 아니라, 콘텐츠 파일 외부에 xml 파일 형태로 ‘안내 다음은 본학습, 그 다음은 평가, 그 다음은 평가점수에 따라 심화 또는 보충단계로 구분해서 진행한다’ 등과 같은 순서화 규칙을 정의하도록 하는 규격이 시퀀싱 & 내비게이션 규격이다.
세 번째 ‘콘텐츠 실행 환경’은 보통 서비스 기관의 학습관리시스템(LMS : Learning Manage-ment System)이 NT, LINUX, UNIX 등 다양한 운영체제와 ASP, JSP 등 다양한 프로그램언어로 개발되었기 때문에, 어떠한 서비스 환경에서라도 앞서 언급한 콘텐츠가 오류 없이 학습자에게 전달되고 또한 학습자의 학습이력을 동일하게 기록할 수 있도록 정의한 규격이다. 이 규격은 대부분 함수(콘텐츠 불러오기, 학습자 이름 불러오기 등)와 데이터형식(학습자 이름은 문자, 평가점수는 숫자 등)에 대한 정의를 설명하고 있다.
짧은 설명으로 독자들에게 충분한 이해를 부탁하는 것이 무리일 것으로 생각되지만, 위안이 되는 점은 스콤과 같은 표준화 규격이 정부, 학계 및 산업계에서 충분히 논의가 되고 있다는 점과 최종사용자(end user)인 교사, 학습자, 학부모들에게는 깊이 있는 이해를 요구하지 않는다는 것이다.
스콤과 같은 표준화 규격은 서비스기관의 기획 및 관리자, 콘텐츠 및 시스템 개발자들을 대상으로 하는 일종의 강한 지침과 같은 것이어서, 콘텐츠 재사용 등을 통한 개발 예산의 절감 및 우수한 콘텐츠 공동 활용 등을 주목적으로 하고 있다고 이해하는 것이 바람직할 것 같다.
스콤과 같은 표준화 규격은 서두에서 언급한 e-러닝에 대한 정의를 구체적으로 실현하기 위한 구체적인 실행방법 중 하나로 다루어지고 있으며, 콘텐츠와 시스템에 시범적으로 적용되고 있는 단계를 우리는 경험하고 있다.
끝으로 특수교육분야에서도 기대효과를 낼 수 있는 수단으로 표준화 규격이 활용되기를 기대한다.

기고자 : Mike Rustici
출처 : http://www.adlkorea.org
=============================================================================

Sharable Content Object Reference Model(SCORM)을 사용하면 업체에서 제공한 학습 컨텐츠를 SCORM에 부합하는 Learning Management System(LMS)과 함께 사용할 수 있다.

SCORM은 정부, 학계, 업계 공동으로 개발되었으며 AICC, IMS, ARIADNE, IEEE LTSC의 작업을 하나의 참조 모델로 통합한다.

SCORM Version 1.2에는 두 종류가 있다. 이는 Run-Time Environment(RTE)와 Content Aggregation Model(CAM)이다.

RTE는 LMS로 시작하는 경우 컨텐츠가 어떻게 작동해야 하는지 설명한다.

CAM은 컨텐츠를 하나로 묶어 이를 LMS에 옮기는 방법을 설명한다. 이 과정에는 LMS가 컨텐츠 내용을 이해하기 위해 필요한 즉, 읽고 학습할 수 있는 형태의 XML 파일 생성 작업이 포함된다.

Run-Time Environment 요약

SCORM표준을 따르는 LMS는 컨텐츠와 LMS의 커뮤니케이션을 가능하게 하는 8가지 함수(전체 규격에 관해서는 3.3항의 SCORM Run-Time Environment 문서 참조)로 구성된 API를 구현하는데 필요하다.

LMSInitialize()
LMSFinish()

LMSGetValue()
LMSSetValue()
LMSCommit()

LMSGetLastError()
LMSGetErrorString()
LMSGetDiagnostic()

API는 SCORM이 API 어댑터에 호출하는 내용에 의해 구현된다. API 어댑터는 컨텐츠를 포함하는 오프너 윈도우(현재창을 열어준 윈도우)나 윈도우의 상위 프레임에 있어야 한다. 즉 LMS가 새로운 윈도우나 프레임세트에서 컨텐츠를 실행해야 한다는 것이다. API 어댑터는 DOM을 통해 접근이 가능한 API인 ECMAScript(JavaScript) 객체여야 한다. 어댑터는 위의 8가지 함수를 구현해야 한다.

컨텐츠와 LMS 사이의 모든 커뮤니케이션은 어댑터가 처리한다. 따라서 컨텐츠 작성자는 서버와 커뮤니케이션을 걱정하지 않아도 되며 API 어댑터를 찾아서 적절한 JavaScript 호출을 만들면 된다. 고객과 서버를 분리하는 것은 SCORM에서 매우 중요한데 이를 통해 표준 플랫폼(웹 브라우저)에서 컨텐츠를 작동하여 컨텐츠의 이동성을 확보할 수 있다. 컨텐츠는 JavaScript API 어댑터를 통해서만 LMS와 커뮤니케니션이 가능하다. 컨텐츠가 웹 서비스나 HTTP 요청과 같은 다른 방법을 통해 LMS와 커뮤니케이션 하는 SCORM 표준을 따르는 방법은 없다.

SCORM에 최소한 부합하기 위해 컨텐츠에 필요한 것은 시작할 때 LMSInitialize()를 호출하고 종료할 때 LMSFinish()를 호출하는 것이다.

그러나 실제로는 훨씬 깊이 있는 상호작용이 요구된다. 시험 결과를 보고하고, 시간을 추적하고 마지막 위치를 표시하는 등의 작업이 가능해야 한다. 이는 다음 3개 함수가 제 역할을 발휘하는 부분이다.

SCORM은 컨텐츠가 읽고 쓸 수 있는 데이터 모델 요소로 구성된 데이터 모델을 정의하여 이와 같은 기능(데이터 모델 요소 전체 리스트는 3.4항의 SCORM Run-Time Environment 문서 참조)을 용이하게 한다. LMSGetValue()는 LMS로부터 데이터 모델 요소의 값을 가져오고 LMSSetValue()는 LMS에 데이터 모델 요소 값을 쓰며, 값을 설정한 후 데이터가 지속될 수 있도록 LMSCommit()을 호출한다.

예를 들어,

cmi.core.lesson_location은 컨텐츠에서 사용자의 위치를 설명하는 데이터 요소이다.
컨텐츠가 시작되면(LMSInitialize(); 호출 후) 호출을 실행하여 사용자가 그만둔 부분을 찾아내서 그 지점으로 돌아갈 수 있게 한다.

strLastLocation = objAPI.LMSGetValue("cmi.core.lesson_location");

컨텐츠가 다른 부분으로 옮겨가면 사용자의 위치를 저장하기 위해 호출을 실행한다.

blnSuccess = objAPI.LMSSetValue("cmi.core.lesson_location", "page3"); blnSuccess = objAPI.LMSCommit("");

다른 3개 함수로 컨텐츠를 트랩하여 지능적으로 오류를 처리할 수 있다.

이처럼 LMS에서 API 어댑터를 구현하는 작업은 컨텐츠에서 사용하는 것보다 다소 복잡하다. API 어댑터는 API 함수를 모두 구현하고 대부분의 SCORM 데이터 모델을 지원해야 한다. SCORM 표준에 부합하는 LMS를 구현하는데 가장 어려운 문제는 브라우저와 서버 사이의 커뮤니케이션을 처리하는 방법이다. 많은 사람들이 Java 애플릿을 이용해 이 문제를 해결하지만 플래시, AcitveX 컨트롤, 순수 JavaScript를 사용하는 경우에도 결과는 성공적이었다.

                       Content Aggregation Model 요약

Content Aggregation 모델은 Content Model, Meta-data, Content Packaging의 세 부분으로 구분된다.
Content Model은 전달중인 컨텐츠를 기술한다. 컨텐츠가 한 개 이상의 모듈을 포함하는 경우, Content Model은 이들 모듈 사이의 관계(Aggregations라고 함)를 설명한다. 컨텐츠 모듈은 컨탠츠의 물리적 구조(필요한 파일 등)를 설명한다.

Content Model은 컨텐츠 재사용을 위해 컨텐츠를 임의의 크기 단위로 분해하는 강력한 모델을 설명한다. 이러한 단위를 Sharable Content Objects(SCO) 및 Asset이라고 한다. Asset은 “미디어, 텍스트, 이미지, 사운드, 웹 페이지, 평가 객체, 기타 데이터를 전자적으로 표현”하는 것이다. 예를 들면, Asset은 이미지, 사운드 클립, 플래시 무비 등이다. SCO는 학습의 논리 단위를 나타내는 한 개 이상의 Asset의 집합이다.

SCO의 정의가 상당히 모호하기 때문에 SCO는 하나의 웹 페이지가 될 수도 있고 수 백 개의 이미지와 Asset을 담은 방대하고 복잡한 웹 기반 교육 모듈이 될 수도 있다. SCO는 LMS가 추적할 수 있는 가장 작은 학습 단위로서 SCO를 표시하는 지침에 따라 컨텐츠 저작자가 정의하게 된다. SCO는 재사용될 수 있어야 한다. 재사용을 위해 SCO는 문맥에 의존적(Context Sensitive)이거나 다른 SCO를 참조하거나 다른 SOC와 링크되지 않아야 한다. SCO의 크기를 결정할 때 반드시 이러한 사안을 고려하도록 한다. 자세한 내용은 SCORM 2004 규격의 2.1항을 참조한다. 2.3항(Content Packaging)에서도 주요 세부사항을 설명하고 있다.

Meta-data 규격은 이미 정의된 공통 어휘를 사용하는 컨텐츠를 설명하는 메커니즘이다. 이러한 어휘는 다음과 같이 9개 종류로 구분된다.

   1. General 카테고리는 전체 자원을 설명하는 일반적인 정보로 구성된다.

   2. Lifecycle 카테고리는 자원의 기록이나 현재 상태와 관련한 내용이나 자원의 발전 중 영향을 준 내용으로 구성된다.

   3. Meta-metadata 카테고리는 Meta-data 기록 자체에 대한 정보이다(기록이 설명하는 자원이 아님).

   4. Technical 카테고리는 자원의 요건과 특징으로 구성된다.

   5. Educational 카테고리는 자원의 교육 및 교수학적 특징으로 구성된다.

   6. Rights 카테고리는 자원의 지적재산권과 사용조건으로 구성된다.

   7. Relation 카테고리는 해당 자원과 다른 목표 자원 사이의 관계를 설명하는 내용으로 구성된다.

   8. Annotation 카테고리는 자원의 교육적 사용에 대한 의견이나 이러한 의견이 언제 누구에 의해서 형성되었는지에 대한 정보를 제공한다.

   9. Classification 카테고리는 자원이 특정 분류 시스템의 어느 부분에 해당하는지 설명한다.

       Meta-data 규격은 매우 다양한 데이터 모델을 정의하지만 SCORM표준에 부합하기 위해서는 소수
       의 데이터 요소만이 필요하다. Meta-data 전체 규격은 SCORM Content Aggregation Model의 2.2
       항에서 볼 수 있다.

Content Packaging 규격은 Content Model과 Meta-data를 설명하고 패키지하는 방법을 정의한다. 시스템 사이의 호환성을 증대하기 위해서는 모든 컨텐츠를 유사한 방식으로 패키지한다.

Content Packaging 규격은 모든 컨텐츠가 하나의 패키지로 전이되도록 요구한다. 이러한 패키지는 Package Interchange File(PIF)이라는 하나의 파일로 묶을 수 있다. 패키지의 루트에는 "imsmanifest.xml"이라는 XML 파일이 있어야 하는데, 이는 지침과 꼭 있어야 하는 것은 아니지만 여러 학습을 구성하는 정적인 방법을 포괄하는 학습 재료(Content Model components)를 설명한다.

ADLNet.org에서는 다양한 Content Package의 예를 제공하고 있다.

이제 SCORM이 무엇이고 어떻게 작동하는지에 대해 상당한 수준으로 이해할 수 있을 것이다. 기술적인 관점에서 가장 중요한 두 가지 부분은 컨텐츠와 LMS 사이의 모든 커뮤니케이션은 JavaScript를 통해 이루어진다는 점과 LMS에 대한 컨텐츠 구조와 특성을 정의하는 imsmanifest.xml이라는 XML 파일이 컨텐츠에 포함되어야 한다는 것이다 . SCORM을 완벽하게 구현하기 위해서는 Run-Time Environment와 Content Aggregation Model에 대한 깊은 이해가 필요하다. 자세한 내용은 SCORM 규격의 기술 정보를 참조한다. 이들 정보는 ADLNet.org에서 제공받거나 mike@scorm.com으로 연락하면 된다.

출처 : Tong - JK world님의 컴퓨터 일반(H/W,S/W)통