758478_ko-KR

liliconcom

JSL 스크립트 생태계 구축: GIT, 단위 테스트, PPT용 VBA, 충돌 로그 수집 등 (2020-US-45MP-614)

Serkay Ölmez, Seagate Technology 수석 데이터 과학자
Fred Zellinger, Seagate 수석 스태프 엔지니어

사용자와 개발자가 많아짐에 따라 JSL 스크립트를 관리하고 소스 제어하는 것이 매우 중요해졌습니다. 본 강연에서는 소스 제어 및 원격 접근을 위해 JSL 스크립트를 GIT과 통합하는 오픈 소스 시스템을 구축하는 방법을 설명합니다. 이 시스템은 스크립트 사용 현황을 모니터링하고 디버깅을 위한 크래시 로그를 수집할 수 있습니다. PPT 생성, 단위 테스트, 사용자 정의를 위한 VBA 스크립팅 등의 기능도 통합되어 다양한 사용자층을 위한 고품질 JSL 스크립트를 생성할 수 있습니다.

자동 생성된 대본...

스피커	성적 증명서
세르케이 올메즈	안녕하세요, Seagate의 Serkay와 Fred입니다. 오늘은 JSL 스크립트를 관리하기 위해 JSL 생태계를 구축한 방법에 대해 이야기해보겠습니다.
	그래서 저희는 Git을 사용하여 소스 컨트롤과 JSL 스크립트 소스를 관리하고 배포하고 있습니다. 이것이 오늘 강연의 핵심입니다.
	그 외에도 PowerPoint 통합을 위한 VBA, 충돌 로그 수집, 그리고 단위 테스트에 대해서도 말씀드리겠습니다. 바로 개요로 넘어가겠습니다.
	그래서 제가 가장 먼저 말씀드리고 싶은 것은 JSL의 역사에 대한 것입니다. 저는 JSL로 스크립팅을 시작한 지 약 10년 정도 되었습니다.
	저희는 지금의 상황에 매우 만족하지만, 여기까지 오는 데는 상당한 시간이 걸렸습니다. 이 자리에서 저희 경험의 중요한 이정표, 지금까지 한 일, 그리고 그 이유에 대해 말씀드리고 싶습니다.
	그리고 Git에 대해 이야기해 보겠습니다. Git을 통해 JSL 스크립트의 소스 제어를 어떻게 구현했는지, 그리고 Git을 통해 어떻게 추가 기능을 개발할 수 있었는지 알아보겠습니다. 예를 들어, Git을 활성화하면
	스크립트 모니터링과 같은 기능을 추가할 수 있습니다. 이를 통해 개발자는 스크립트가 사용 중인지 확인하고 사용량을 모니터링할 수 있습니다.
	그리고 아마도 더 중요한 것은, 로그를 수집할 수 있다는 것입니다. 스크립트가 충돌하면 개발자는 이를 인지하고 버그를 수정하여 다시 돌아갈 수 있습니다. 그리고 여러분은...
	한 단계 더 나아가 기능을 하나 더 추가할 수 있습니다. 스크립트가 충돌했다는 것을 이미 알고 있는 경우, 자동 버그 티켓을 생성할 수도 있습니다. 그러면 해당 버그 티켓을 자동으로 생성할 수 있습니다. 그리고 JIRA나 Atlassian과 같은 추적 소프트웨어를 사용하여 이러한 티켓을 추적할 수 있습니다.
	그리고 지금까지의 모범 사례와 얻은 교훈을 공유하며 마무리하겠습니다.
	그래서,
	부록에는 제가 설명할 스크립트에 대한 설명서도 있습니다. 파워포인트에 이미지를 푸시할 수 있는 스크립트입니다.
	저는 이에 대해 매우 자세한 매뉴얼을 가지고 있으며, 여기서 제가 언급한 모든 내용, 데이터, 스크립트는 모두 이용 가능하다는 점을 알려드리고자 합니다.
	그리고 이 파일들은 여기 참고 섹션의 공개 저장소에 게시되어 있으니, 원하시면 바로 가서 파일을 가져오실 수 있습니다. 그럼 시작해 볼까요?
	간략한 역사를 말씀드리겠습니다. 10... 저는 JSL에서 약 10년 정도 일해 왔고, 시작은...
	아주 기본적인 내용이었고 JSL 스크립팅에 대해서도 별로 몰랐습니다.
	그리고 일단 시작하면 적절한 소스 제어가 필요하고 스크립트를 적절하게 배포하는 방법이 필요하다는 걸 깨닫게 됩니다.
	JMP 스크립팅의 장점은 진입 장벽이 전혀 없다는 것입니다. 말 그대로 플롯을 직접 작성한 후 스크립트를 다운로드할 수 있습니다. JMP는 여러분을 위해 작성되었습니다.
	또한 JMP.com의 커뮤니티 to JMP를 이용해 질문을 하고 답변을 얻을 수도 있습니다.
	그리고 당신은... 스크립트 작성이 너무 효율적이어서 일을 아주 효율적으로 하고 있고, 사람들은 알아챌 거예요. 사람들이 당신이 어떻게 하는지 묻고 당신은 스크립트가 있다고 말할 거예요. 그리고 그들은
	"그걸 저한테 공유해 줄 수 있나요?"라고 물어보세요. 그리고 갑자기 당신은 개발자가 되지만, 그럴 의도는 없었습니다.
	그리고 대본 배포도 해야 합니다. 가장 먼저 떠오르는 아이디어는 그냥 대본을 첨부하는 것인데, 정말 끔찍한 생각입니다. 저도 꽤 오랫동안 그렇게 해왔거든요.
	그리고 그것이 왜 좋은 생각이 아닌지는 분명합니다. 왜냐하면 스크립트를 첨부한 다음 그것을 보낸 다음 다음 날에 그것을 만들기 때문입니다.
	수정본을 보내면 다시 보내야 하고, 사용자가 다음 버전을 선택할지조차 알 수 없습니다. 그래서 여기서는 요점을 설명하는 것뿐입니다.
	최근에 동료로부터 이메일을 받았는데, 그 사람은 내가 2017년에 만든 스크립트에 대해 언급하고 있었고 나는 이것으로 스크립트에 번호를 매기고 있었습니다.
	버전 번호는 좋은 생각이 아닙니다. 3, 4년 후에 다시 돌아와 보면, 사람들이 여전히 3년 된 스크립트를 사용하고 있다는 것을 알게 됩니다. 업데이트하지 않았기 때문이죠.
	이 문제를 해결하는 한 가지 방법은 공유 드라이브를 사용하고 그 안에 있는 사람들과의 상호 작용을 기반으로 하는 것입니다.
	Discovery Summit은 많은 사람들, 많은 회사들이 이 프로그램을 이용하고 있다는 뜻입니다. 개발자들이 하는 일은
	스크립트를 공유 드라이브에 저장하면 사용자가 공유 드라이브에서 직접 가져오게 되어 배포 문제를 절반 정도 해결할 수 있지만, 소스 제어에는 아무런 도움이 되지 않습니다. 코드에서 변경한 내용을 추적할 수 없기 때문입니다.
	그래서 저희는 실제로 Git으로 전환했습니다. Git은 저희에게 획기적인 변화를 가져왔고 많은 기능을 가능하게 했습니다. 그렇다면 Git을 사용하면 개발자들이 스크립트를 저장소에 푸시하고
	사용자는 Git에서 직접 스크립트를 가져올 수 있습니다. 이는 저희에게 큰 개선이었고, 충돌 로그를 수집할 수 있게 되었습니다.
	스크립트 사용 방법 등에 대해서도 말씀드리겠습니다. 그리고 서밋에서 배운 몇 가지 사항에 대해서도 더 이야기하고 싶습니다. 스크립팅 실력 향상에 매우 도움이 되었고, 2018년에 서밋에 참석했을 때 표현식 등에 대해 많은 것을 배웠습니다.
	사람들은 스크립팅 기술에 도움이 되기 때문에 다시 돌아가서 그 프레젠테이션을 듣고 싶어할 것입니다.
	그리고 저희에게 또 다른 중요한 이정표는 테스트였습니다. 작년 Summit에서 단위 테스트에 대한 강연을 듣고 영감을 받았는데, 스크립트를 게시하기 전에 자동으로 테스트할 수 있는 기능이었습니다.
	오늘은 주로 통합 테스트에 대해 이야기하겠습니다. 단위 테스트는 필수이기는 하지만 충분하지는 않습니다.
	단위 테스트를 통해 모든 모듈을 테스트하고 문제가 없는지 확인할 수 있습니다. 하지만 모듈을 조립하면 작동하지 않습니다. 여기 그림처럼 충돌이 발생합니다. 각 서랍을 테스트했을 가능성이 높지만, 조립하면 작동하지 않습니다.
	개발자에게 많은 도움이 되는 좋은 기능 중 하나는 로그 수집입니다.
	스크립트가 충돌했는지, 그리고 어떻게 충돌했는지 아는 건 정말 큰 도움이 됩니다. 사용자 로그를 수집하고, 스크립트를 수정하고 변경 사항을 푸시하면 사용자는 수정된 스크립트를 바로 사용할 수 있습니다.
	그리고 최근에 출시하는 마지막 기능은 자동 버그 보고 기능입니다. 이미 충돌 보고서가 있으니, 그 정보를 바탕으로 조치를 취해 보는 건 어떨까요? 그래서 저희는 자동화된
	모니터링
	이 시스템은 충돌 로그를 추적하고 버그 보고서를 자동으로 생성하여 개발자가 해당 문제를 해결할 수 있도록 지원합니다. 게다가, 사용자를 감시자로 추가하여 누군가가 문제를 해결하고 있음을 사용자에게 알릴 수도 있습니다. 이렇게 하면 문제가 해결됩니다.
	사용자와 개발자 간의 정보 격차를 해소합니다.
	그래서 이것은 타임라인을 보여주고 나는 그것에 시간을 할애할 것입니다.
	개별 항목에 대해서는 다루지 않겠지만, Git부터 시작해서 빠르게 빌드한 다음 Fred가 이에 대해 설명하도록 하겠습니다.
163084	좋아요.
	그래서,
	Git은 버전 관리 시스템일 뿐이고, 저는 버전 관리라는 단어를 사용하지 않습니다. 사실, Git은 로컬 컴퓨터에서만 사용하더라도 사실상 무제한의 재실행 기능을 제공하여 도움을 준다고 말씀드리고 싶습니다.
	파일의 수정 사항을 추적하고, 지난 몇 주 동안 작업한 내용 중 일부가 잘못되었고 몇 주 전의 작업으로 돌아가고 싶은 경우 이전 파일로 돌아갈 수 있는 기능을 제공합니다.
	Git은 로컬 컴퓨터에 설치하는 소프트웨어일 뿐입니다. Git은 저장소를 생성하고, 이 저장소는 다른 저장소에 게시될 수 있습니다.
	GitLab이나 GitHub 같은 거죠. TortoiseGit은 로컬 컴퓨터에서 사용할 수 있는 GUI 인터페이스로, 작업을 더 쉽게 만들어 줍니다. Serkay, 다음 슬라이드를 열어주시겠어요?
	그래서 제가 개발자들이 사용하도록 하려고 했던 모델은 로컬 컴퓨터에서 진행되었습니다. 로컬 컴퓨터에서 개발자들은 Git 클라이언트를 설치하고 시작해야 합니다.
	로컬 PC에 있는 파일의 버전을 제어할 수 있습니다. 익숙해지면 원격 저장소에 연결할 수 있습니다.
	그리고 Git은 일반적으로 원격 저장소나 SSH 또는 다른 방법에 연결하고 푸시할 수 있습니다.
	Git 데이터베이스 복사본을 원격 저장소에 저장합니다. 원격 저장소에 업로드되면 HTTP 웹 서버에서 JMP로 다시 공유할 수 있습니다.
	그런 다음 URL과 HTTP...HTTP 웹 서버를 가리키고 거기에서 스크립트를 로드할 수 있습니다. 즉, 공유 드라이브를 사용하는 대신 Git 저장소에 푸시하여 생성된 HTTP 웹 서버를 사용하고 있습니다.
	그리고 아래의 요점 항목은 그 이점과 그것이 정확히 어떻게 작동하는지 지적합니다.
	다음 슬라이드로 넘어가겠습니다.
세르케이 올메즈	그럼, 프레드, 여기서 제가 맡아서 보여드리겠습니다... 아주 기본적인 그림 구현을 보여드리고, 스크립트는 참고자료에서 확인하실 수 있습니다.
	그래서,
	아주 기본적인 코드입니다. 제가 보여드리는 코드는 개발자가 개발 중인 코드입니다. 아주 최소한의 코드죠. 그냥 "Hello World"라고 적힌 대화 상자일 뿐입니다.
	개발자가 이 코드를 사용자에게 전달하고 싶어 한다고 가정해 보겠습니다. 그러면 이 코드를 제공하는 대신, 개발자가 전달하는 것은 이 코드입니다.
	저장소 링크입니다. 그러니까 이건 거기에 있는 hello JSL 스크립트의 저장소입니다...
	원격 저장소에 있습니다. 사용자가 하는 일은 그냥 잡아내는 것입니다... 사용자가 잡아내는 것입니다.
	URL에서 스크립트를 가져옵니다. 정적 코드입니다. 변경할 필요가 없으므로 개발자는 언제든지 스크립트를 변경할 수 있지만, 사용자는 아무것도 할 필요가 없습니다. 예를 들어 전체 화면으로 전환하는 방법을 보여드리겠습니다.
	이 기능이 특정 GUI, 즉 GitHub Desktop에서 어떻게 작동하는지 보여드리겠습니다. 설치는 다음과 같습니다.
	컴퓨터에 소프트웨어를 설치하고 로컬 저장소를 만들면 변경 사항을 추적할 수 있습니다. 예를 들어, 이 경우에는 방금 hello JSL 스크립트를 만들었습니다.
	이 소프트웨어는 변경 사항이 있음을 인식하고 자동으로 강조 표시합니다. 먼저 로컬 저장소에 커밋하고,
	로컬 저장소에 푸시하고, 그다음 원격 저장소인 origin 저장소로 푸시합니다. 이제 원격 저장소로 푸시해서 사용자가 사용할 수 있도록 할 겁니다.
	그러면 이제 사용자가 새 코드를 가져올 수 있게 됩니다. 이제 사용자 역할로 다시 전환하겠습니다. 이 스크립트는 사용자가 실행하고, 이렇게 하면 대화 상자가 나타납니다. 저장소에서 가져온 스크립트를 실행하는 것입니다.
	그래서 저는 이것을 좀 더 고급 코드로 설명하겠습니다. 이 코드도 PowerPoint와 관련이 있을 것입니다.
	그래서 사람들은 JMP에서 많은 분석을 수행하지만, 결국 많은 사람들이 결과를 PowerPoint로 푸시하고 싶어합니다. JMP에는 이를 위한 몇 가지 기능이 있다는 것을 알고 있습니다.
	PowerPoint에 이미지를 직접 업로드할 수 있었지만, 우리는 좀 더... 좀 더 정교한 것을 원했습니다.
	PowerPoint 템플릿을 관리합니다. PowerPoint 내에서 몇 가지 작업을 더 하고 싶습니다. 슬라이드당 이미지를 몇 개나 넣을지 등을 정하고 싶습니다. 그리고
	그렇게 하려면 먼저 JMP를 PowerPoint와 연결해야 하며, 실제로 매우 쉽게 연결할 수 있습니다...
	아주 좋은 방법으로, JMP를 떠날 필요도 없습니다. PowerPoint 실행 파일의 위치를 찾으시면 되는데, 일반적으로 Program Files 폴더에 있습니다.
	그런 다음 이 PowerPoint 실행 파일을 트리거하는 배치 파일을 만들면, 실행하려는 PowerPoint 파일을 가져와서 바로 실행합니다. JMP에서 이 모든 작업을 수행할 수 있습니다. 기본적으로 이 기능은 PowerPoint 실행 파일을 검색합니다.
	그리고 해당 파일을 찾으면 이 배치 파일에 묶습니다. 그리고 실행하려는 PowerPoint 경로도 포함됩니다.
	그리고 매크로가 있고, PowerPoint에는 PowerPoint 내에서 관리를 수행하는 매크로가 있습니다. 이렇게 하면
	JMP를 PowerPoint에 연결하려면 JMP 자체도 그렇게 해야 합니다. 하지만 문제는, 이 PowerPoint 파일을 사용자에게 어떻게 제공할 것인가입니다.
	직접 가서 다운로드해 달라고 부탁하는 건 이상적이지 않습니다. 자동으로 관리하고, 동시에 파워포인트 소스 관리까지 해야 하니 말이죠. 따라서 좋은 후보가 되어야 하고, 전체 생태계에 잘 녹아들어야 합니다. 외부에 공개해서는 안 됩니다.
	또 다른 요구 사항은 스크립트가 실행될 때마다 PowerPoint를 다운로드하지 않아야 한다는 것입니다. 즉, 해당 이미지 저장소에서 변경되었거나 PowerPoint에 새로운 내용이 있는 경우에만 PowerPoint를 다운로드해야 합니다.
	그래서, 한 가지 방법은 이 간단한 JMP 스크립트를 사용하는 것입니다. JMP 명령은 생성 날짜를 나타냅니다. 제가 여기서 하는 것은
	로컬 파일의 날짜입니다. 로컬 PowerPoint 파일이 저장소에 있는 파일보다 오래된 파일이라면, 해당 파일을 다운로드하겠습니다.
	HTTP 요청을 사용하여 PowerPoint를 다운로드합니다.
	이렇게 생겼습니다. 로컬 컴퓨터에서 PowerPoint 파일을 확인하면 됩니다. 파일이 없으면 HTTP 요청을 사용하여 저장소에서 파일을 가져올 수 있습니다. 파일이 있으면 날짜를 확인하고, 파일이 오래되었다면
	새 것을 가져오세요. 결론은 PowerPoint를 JMP 환경에 완벽하게 통합하여 표, 이미지를 포함한 결과를 JMP에 푸시할 수 있다는 것입니다. 소스 제어를 손상시키지 않고도 이 모든 작업을 수행할 수 있으며, 여기서 데모를 보여드리겠습니다.
	이 코드는 사용자에게 제공하는 코드와 같습니다. 다시 말하지만, 이 코드는 정적 코드입니다. 스크립트에서 원격 저장소로 연결되는 URL 외에는 아무것도 없습니다. 따라서 이 코드는
	저장소의 JMP 스크립트와 해당 스크립트를 다시 사용할 수 있으며 참조에서 바로 가져올 수 있습니다.
	개발자 입장에서 보면, 이게 실제 스크립트입니다. 개발자가 개발한 스크립트입니다.
	원격 저장소에 푸시합니다. 이 스크립트의 좋은 점은, 몇 가지 기능을 간략하게 소개하고 싶다는 것입니다.
	예를 들어 이것을 보세요. 이것은 독립형 텍스트 스크립트이고 PowerPoint 파일이나 추가 스크립트를 배포할 필요가 없습니다.
	별도로. 스크립트에서 링크를 연결하면 여기 저장소에 링크가 연결됩니다.
	PowerPoint도 포함해서요. 이 스크립트는 모든 배포를 관리합니다. PowerPoint를 가져오는 거죠.
	필요한 경우 다른 추가 파일을 가져옵니다. 모든 것이 스크립트에 통합되어 모든 관리 작업을 자동으로 처리합니다. 간단히 보여드리겠습니다. 나중에 다시 가져오겠습니다.
	그리고 전체 화면으로 전환해 보세요
	명확하게 볼 수 있도록요. PowerPoint를 자동으로 실행하는 방법을 보여드리겠습니다.
	특정 사례에 대한 것입니다. 이 스크립트는 테이블에서 경로를 가져오는데, 이 테이블은 JMP 테이블이며, 여기에는 많은 이미지 경로가 포함되어 있고, 이 경로들은 특정 경로를 참조합니다.
	서버에서 해당 경로를 가져와서 여기에 강조 표시된 경로만 가져와서 PowerPoint로 푸시합니다.
	이 스크립트를 실행해 보겠습니다. 원하시면 사용해 보실 수 있습니다. 완벽하게 기능하는 유용한 스크립트입니다. 자, 이제 이 스크립트를 실행해 보겠습니다.
	여기 스크립트가 있습니다. 다시 말하지만, 이는 저장소를 참조합니다. 즉, 행 스크립트가 없고, 저장소에서 가져올 뿐입니다. 실행하면 코드가 검색되고, 대화상자가 실행됩니다.
	그냥 실행해 보겠습니다. 자세한 내용은 설명하지 않겠습니다. 실행하면 PowerPoint가 자동으로 실행됩니다.
	그러면 PowerPoint가 실행되고... 시작되고... 슬라이드를 만들고 있습니다. 20개의 이미지를 가져오는데 10초에서 20초 정도 걸립니다. 그러면 PowerPoint가 나타납니다.
	완료되었습니다. 이게 바로 여러분이 받으시는 PowerPoint이고, 모든 작업이 자동으로 처리되며, 모든 작업은 저장소에서 가져온 것입니다.
	그럼 다음은 뭘까요? 이 파워포인트를 어떻게 수정해야 할까요? 템플릿을 좀 수정하고 싶으시겠죠? 그리고
	이에 대한 자세한 내용은 부록에서 확인할 수 있지만, 제가 보여드리고 싶은 것은 변경 방법
	PowerPoint에서 스크립트를 실행합니다. 전체 화면으로 전환합니다.
	그냥 실행해 보겠습니다. 우리가 시작할 건 이전 슬라이드에 남은 이미지에서 시작하는 거죠. 바로 이 이미지들이죠.
	제가 하고 싶은 건 템플릿을 사소한 방식으로 바꿔서 요점을 보여주는 겁니다. 그럼...
	매크로로 가서 아래로 스크롤해서 변경할 항목을 찾으세요. 여기서 간단한 변경 작업을 해볼게요. 요점을 강조하기 위해 헤더 색상을 변경할게요. 그럼 이걸 변경하세요.
	그리고
	저장하세요. 그리고 이건 실시간으로 진행됩니다.
	이것을 저장하고 슬라이드를 삭제하면 저장소에 더 빨리 이동할 수 있습니다. 저장소에 푸시하게 되기 때문입니다.
	그런 다음 Git GUI를 사용하여 이를 푸시하면 저장소에 저장됩니다.
	그러면 모든 사용자가 수정 사항을 즉시 사용할 수 있게 됩니다. 따라서 PowerPoint를 업데이트해 달라고 요청할 필요가 없습니다.
	이건 그냥 저장소에 보관하는 거예요.
	그리고 JMP로 돌아가서 사용자 모드로 들어간 다음 스크립트를 다시 실행하면 새로운 PowerPoint가 검색됩니다.
	그리고 다시 실행하면 다음을 거치게 됩니다.
	슬라이드를 만들면 슬라이드가 생성됩니다. 그리고 눈에 띄는 건 헤더 줄의 색상을 변경하는 것과 관련된 변경 사항이 있다는 것입니다.
	그래서,
	그 밖에 뭐가 있나요?
	스크립트 모니터링. 이 기능은 개발자에게 스크립트가 제대로 작동하는지 확인할 수 있는 기능을 제공하기 때문에 우리가 개발한 기능 중 가장 뛰어난 기능 중 하나라고 생각합니다.
	그들의 대본... 그의 대본이 호평을 받든 못 받든. 맞아. 그럼 방영되는 건가요? 누군가 정기적으로 방영하는 건가요?
	그래서 그게 하나의 이점이에요. 다른 이점은 다음과 같습니다.
	로그...충돌 로그 수집. 스크립트가 실패하면 JMP의 로그 캡처 기능을 사용하여 실패를 캡처할 수 있습니다. 즉, 로그 캡처에 서브루틴을 끼워 넣는 것입니다.
	실패하면...실패...실패 로그가 이 로그 반환 텍스트로 반환됩니다. 그리고 나서 당신이 할 일은 다음과 같습니다.
	스크립트가 보고를 수행할 수 있도록 try에 넣어서 보관합니다.
	그리고 비어 있는지 확인합니다. 비어 있으면 충돌이 전혀 발생하지 않았으므로 스크립트가 정상적으로 작동한다는 의미입니다.
	하지만 그렇지 않다면, 즉 비어 있지 않다면 충돌이 발생했고 이를 격리했다는 뜻입니다. 로그를 확보하여 보고할 수 있습니다. 방법은 HTTP를 사용하는 것입니다.
	사용자 ID, 스크립트 이름, 로그 노트, 충돌 여부...
	충돌이든 일반 실행이든, 성능 지표를 확인할 수 있을 겁니다. 결론은 스크립트에 대한 데이터 메타데이터를 개발자에게 다시 전송할 수 있다는 겁니다.
	서버가 하는 일은 로그를 기록하는 것입니다. 서버에 파일 세트가 저장되고 이를 모니터링할 수 있습니다. 저는 단지 샘플을 보여드리는 것뿐입니다.
	이 테이블에서. 날짜 스탬프와 스크립트 이름이 있는 충돌 로그입니다. 따라서 이 스크립트는 해당 날짜에 실패했습니다.
	이 특정 충돌과 관련하여, 개발자에게는 매우 유용합니다. 개발자가 문제를 다시 보고 해결할 수 있기 때문입니다. 이 부분과 이 부분을 접고, 여기서 간단한 데모를 통해 어떻게 하는지 보여드리겠습니다.
	어떻게
	충돌을 포함하고 사용자에게 보고하는 방법을 설명합니다. 따라서 여기서는 서브루틴 충돌을 발생시키는 작업을 수행합니다. 정의되지 않은 매개변수를 생성합니다.
	그러면 JMP에서 불평을 합니다. "이게 정의되지 않았으므로 스크립트가 충돌합니다."라고 합니다. 하지만 저는 이 서브루틴을 호출할 것입니다.
	로그 캡처 기능에서 모든 것이 try 아래에 끼어들게 됩니다. 따라서 스크립트가 서브루틴과 충돌하더라도 전반적으로는 정상적으로 작동하며 보고할 수 있습니다.
	충돌 보고서입니다. 사용자에게 깔끔하고 정돈된 알림을 보내주시겠어요? 스크립트가 이 특정 오류로 인해 충돌이 발생했고, 저희는 로그를 생성하여 작업 중입니다. 이것이 사용자에게 제공하는 알림입니다.
	제가 Summit에서 배운 중요한 것 중 하나는 자동화된 테스트였습니다. 예전에는 테스트를 수동으로 진행했는데, 정말 답답했습니다.
	시간이 많이 걸리고 스크립트의 모든 부분을 완벽하게 구현할 수는 없습니다. 작은 변경을 할 때 몇 시간씩 테스트하는 것은 불가능합니다.
	그래서 자동화 테스트를 시작했는데, 단위 테스트는 정말 중요합니다. 아시다시피, 테스트는 개별 서브루틴을 테스트하는 것을 말합니다. 함수가 있고, 그걸 테스트하고 싶은 거죠.
	전체 시스템에 넣기 전에 여러 번 시도하여 이러한 단위 테스트를 수행할 수 있습니다.
	개별 모듈에는 충분하지만, 충분하지는 않을 겁니다. 몇 가지 예를 보여드릴 수 있습니다.
	예를 들어, NASA는 매우 이상한 오류로 인해 화성 기후 궤도선을 잃었습니다. 그 이유는 유럽에 있는 두 개의 소프트웨어 팀이 있었기 때문입니다.
	하나는 미국에 있고, 하나는 파운드 단위를 사용했고, 다른 하나는 미국에 있었고, 다른 하나는 유럽에 있었습니다.
	뉴턴을 사용하고 있었죠. 그래서 단위 테스트는 확실히 했습니다. 하지만 코드를 짜보니 제대로 작동하지 않았습니다. 하나는 뉴턴을 기대하고 다른 하나는 파운드를 받았기 때문입니다. 그래서 그들은 말 그대로
	오비터는 파운드에서 뉴턴으로 변환하는 걸 깜빡해서 그랬던 거죠. 그리고 최근에는 스타라이너(Starliner)라는 이름으로 보잉이 스타라이너를 분실했는데, 그때 보잉은 만약 그랬다면 오류를 발견할 수 있었을 거라고 인정했습니다.
	엄격한 통합 테스트. 그리고 결국 중요한 것은
	통합 테스트는 스크립트에서 모듈이 단독으로 존재하는 것이 아니라 서로 통신하기 때문에 가능합니다.
	여기 이 문제에 대한 재밌는 예시가 있습니다. 철저하게 테스트된 두 개의 객체가 있다고 가정해 보겠습니다. 창문이라고 하죠. 창문에서 무슨 문제가 생길 수 있을까요?
	하지만 두 개를 함께 설치해도 열리지 않으므로, 두 개가 결합되었는지, 제대로 작동하는지 확인하기 위해 통합 테스트를 수행해야 합니다.
	여기서 제가 자동화 테스트를 시작한 과정을 보여주는 간단한 예를 하나 보여드리고 싶습니다. 이는 특정 사례를 언급하는 것인데,
	솔직히 어려운 케이스입니다. 모달 창을 테스트하는 것이기 때문에 버튼을 클릭하지 않으면 모달 창이 사라지지 않기 때문입니다. 그래서
	버튼을 클릭하는 JMP 스크립트를 만들어서 인간의 행동을 모방하는 것과 같습니다. 여기서 제가 하는 일은 테스터를 주입하는 것입니다.
	여기 모달 창이 있습니다. 이 접근 방식의 좋은 점은 여전히 배포할 수 있다는 것입니다.
	이 스크립트는 사용자에게 제공되지만 사용자는 실제로 테스트 루틴이 들어 있다는 사실조차 깨닫지 못할 것입니다.
	테스터를 위한 후크가 있지만, 이것을 단독으로 실행하면 테스트 모드 매개변수를 찾지만 설정되어 있지 않습니다.
	따라서 이 값을 설정하지 않으면 스크립트가 값을 0으로 설정하여 테이블의 모든 후크를 비활성화합니다. 따라서 이 값을 사용자에게 제공하고 다음과 같이 실행할 수 있습니다.
	하지만 스크립트를 테스트하려면 스크립트 위에 테스터 코드를 작성해야 합니다. 테스터 코드는 테스트 모드를 1로 설정하고 테스터를 생성합니다.
	스크립트에 삽입하려는 테스터 객체입니다. 예를 들어, 이 특정 사례에서는 특정 열을 선택하는 것입니다.
	버튼을 클릭해서 역할을 할당하고 스크립트를 실행하는 거죠. 말 그대로 사람의 행동을 흉내 내는 거죠.
	그러면 실제 스크립트가 로드됩니다. 즉, 테스트하려는 스크립트에 해당 매개변수를 주입하는 것입니다. 이제 스크립트가 자동으로 실행되므로 스크립트가 로드되어 실행되고, 이 버튼과 저 버튼을 클릭하면 UI가 닫힙니다.
	그리고 로그 캡처 기능에서 다시 실행하면 문제가 발생할 경우 실패를 캡처할 수 있습니다.
	그리고 스크립트가 로그를 보고할 수 있도록 enter try에도 넣었습니다. 아무 문제가 없다면 빈 로그가 반환되는데, 이는 스크립트가 실패하지 않았다는 것을 의미합니다.
	뭔가 잘못되면 로그 캡처를 통해 알 수 있죠. 바로 그게 아이디어예요.
	그래서,
	우리는 가지고있다
	스크립트를 모니터링하는 기능. 우리는
	충돌 로그를 캡처합니다. 그래서 왜 충돌 로그를 활용하지 않을까 생각했습니다. 충돌 로그를 보면 무언가 잘못되었다는 것을 알 수 있고, 스크립트로 작성하면... 사용자는 스크립트가 충돌했기 때문에 이미 알고 있고, 개발자는 로그가 있기 때문에 스크립트가 충돌했다는 것을 알고 있습니다.
	서버에 저장됩니다. 따라서 사용자가 조치를 취할 수 있습니다. 하지만 문제는 아직 닫힌 루프가 아니라는 것입니다. 사용자는 개발자가 알고 있다는 사실을 모르기 때문입니다. 자동 티켓을 생성하여 이 루프를 닫을 수 있습니다. 이미 정보가 있으므로
	JIRA Atlassian과 같은 버그 추적 소프트웨어를 사용하면 REST 기능을 사용할 수 있습니다.
	서버에서 정보를 수집하고, 티켓을 생성하고, 개발자에게 할당하고, 사용자를 감시자로 지정할 수도 있습니다. 감시자는 개발자가 어떤 작업을 할 때마다
	버그에 대한 정보를 JIRA에 입력하면 이 정보가 사용자에게 다시 전달되어 사용자는 알림을 받고 누군가가 버그를 수정하고 있다는 사실을 알게 됩니다.
	그리고 여러분이 사용하는 JIRA의 종류에 따라 이를 수행하는 여러 가지 방법이 있으며, 저는 단지 여러분에게 다음과 같은 방법을 제공하고 있습니다.
	기본 코드는 다음과 같습니다. 생성할 수 있는 curl 코드입니다. 충돌 로그에서 수집한 메타데이터를 JSL 파일에 임베드하면 REST를 통해 전송되고
	JIRA는... 추적해 줍니다. 그리고 JIRA가, 제대로 설정했다면, JIRA가 알림을 보냅니다... JIRA가 개발자에게 알림을 보내고, 가능하면
	스크립트가 충돌한 사용자. 이 모든 것이 서로 연결되어 있고, 개발자는 자신이 수정해야 할 버그가 있다는 것을 알게 되고, 사용자는 누군가가 그 버그를 수정하고 있다는 것을 알게 됩니다.
	좋아요. 이제 마무리 말씀드리겠습니다. 이 프레젠테이션에서 얻을 수 있는 핵심 내용만 말씀드리겠습니다.
	Git은 우리 시스템의 초석이었으며 이를 통해 많은 훌륭한 기능을 사용할 수 있었습니다. 기본적인 기능은 언급하지도 않았지만
	이는 당연한 이야기입니다. 협업도 가능하니까요. 여러 사람이 같은 스크립트를 작업하는 경우에도

고급 통계 모델링자동화 및 스크립팅기본 데이터 분석 및 모델링데이터 액세스품질 및 공정 엔지니어링신뢰성 분석