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