스크립팅 : 일반적인 호환성거의 모든 릴리스 (7 년 이후) 고객이 새 버전에서 스크립트가 더 이상 작동하지 않는다는 전화를 받았습니다. 비슷한 전화를 받습니까?
사용자 정의 스크립트 (내장 생성 스크립트가 아닌이 검사를 기대하는)에 대한 상위 호환성 검사를 더 잘 수행 할 수 있는지 궁금합니다. 분명히 소프트웨어가 자연스럽게 발전함에 따라 하위 기능 (일명 JMP 15 스크립트가 JMP 13에서 실행되지 않음)에 대해서는 이야기하지 않습니다. 그러나 소비자 / 사용자는 JMP 14로 작성한 스크립트가 여전히 JMP 15에서 실행될 것이라고 기대합니다.
얼리 어답터 (E 얼리 어답터)는이를 조기에 파악하고 문제를 전자 메일 목록으로 보내는 방법 중 하나입니다. 그러나 큰 문제가 있습니다. 사용자는 일반적으로 얼리 어답터에서 호환성 검사를 수행 할 시간이 없습니다 (특히 7-9 버전이있는 경우). 이것은 소프트웨어 공급 업체 측에서 수행해야합니다. 그것은 또한 대부분의 고객들이 불평하는 것이기도합니다. "그것은 그들의 직업이 아니다"a d 나는 내가 그것에 부분적으로 동의한다는 것을 인정해야한다 (대부분의 경우).
고객과 비슷한 불만이 있습니까? 상위 호환성을 확인하는 현재 프로세스는 무엇입니까? 여기에 몇 가지 사례와 제안 사항을 모아서 좋을 것입니다. (또한 해당 개발자와의 킥오프 세션에서이 문제에 대해 논의 할 수도 있습니다. 저는이 문제를 해결할 수있는 본회의에서 Q & A를 기억하지만 마지막 것은 3 년 전에 믿었습니다. 2020 년에는 SE를위한 것일까 요? ).
감사,
남자 이름
추신 : 제가 이것을 100 개 이상의 라이센스를 가진 저명한 제조 고객으로 만드는 이유는 JMP에서 다른 솔루션, 오픈 소스로의 전환에 대해 생각하고 수년 동안 실제로 JMP 친화적이라고 생각한 이후 몇 년 동안 화가 났기 때문입니다.
Re : 스크립팅 : 일반적인 호환성안녕 마틴,
FWIW, 내 경험에 따르면 순방향 호환성 부족은 거의 항상 보고서에서 항목을 가져 와서 더 조작하는 것과 관련이 있습니다. 당신은 소프트웨어가 자연스럽게 진화하는 것을 기대하는 것이 합리적이라고 말하지만, 보고서 구조의 변화는 이러한 욕구의 피할 수없는 결과입니다. 우리는 항상 스크립팅을 많이 사용하는 고객에게 이것을 지적하기 위해 항상 고통을 겪어야합니다.
아시다시피, '생산'에 사용되는 소프트웨어의 경우 업그레이드 된 소프트웨어를 '실시간'으로 만들기 전에 철저한 테스트를 거치는 준비 영역을 갖는 것이 매우 일반적입니다. 이 원칙은 JMP가 '단순한'데스크톱 소프트웨어라는 사실과 상충되는 것으로 보이지만 (메시지가 설명하는 것처럼) 실제로 위험이 있으므로 사용 패턴이 필요할 때 이러한 방식으로 JMP를 볼 수 있도록 사용자를 도와야합니다.
요컨대, 이러한 긴장은 JMP가 매우 기능적이라는 사실의 부작용입니다. 훌륭한 JSL 코드 기반에 우수한 산업 소프트웨어 엔지니어링 사례를 지원하지 않을 경우 발생하는 위험과 결과에 대해 고객에게보다 잘 알리는 것이 가능해야한다고 생각합니다. R & D는 보고서에 독립적 인 방법으로 필요한 모든 값을 얻을 수있는 방법을 제공 할 수 있지만, 이것이 제가 알고있는 로드맵에는 없으며, JSL 프로그래머가 중요하게 생각하는 유연성을 일부 제거 할 수 있습니다. 고도로.
당신과 마찬가지로, 나는 우리가 이것에 대해 문제를 일으킨 다른 예에 대해 듣고 싶습니다. . .
건배,
이안
Re : 스크립팅 : 일반적인 호환성안녕 마틴!
TL; DR :
포인트 1 : 사람들이 JSL 모범 사례와 스크립팅을 방어 적으로 따르지 않기 때문에 버전 간 코드 분리는 일반적으로 발생합니다. 포인트 2 : 버전간에 소프트웨어 성능 (자체 또는 기타)을 검증하는 것은 항상 고객의 책임입니다. 그들은 다른 제조 도구와 마찬가지로 처리해야합니다.이 도구는 모두 프로덕션에 출시되기 전에 심사를 거칩니다.
긴 버전 :
댓글에 답하기 ian 만든 – 버전 사이의 대부분의 코드 중단은 JSL 모범 사례를 따르지 않는 사람들이 있기 때문입니다. 작동하지만 잘 생각되지 않는 코드를 깨는 것이 훨씬 쉽습니다. Mark Bailey는이를“방어적인 스크립팅”이라고 부릅니다. 기존 보고서에서 가져온 사람들의 이안 (Ian)의 사례는 특히 전체 디스플레이 트리를 첨자 화하는 경우의 전형적인 사례입니다. 가장 좋은 방법은 개요 상자 이름을 로컬 랜드 마크로 사용한 다음 아래 첨자 (자주 변경되지 않기 때문에)입니다.
또한 사람들 (자체 포함)이 버전 사이에서 정밀 검사를받는 기능에 의존하는 JSL을 빌드하는 몇 가지 인스턴스를 경험했습니다. 나를 위해 JMP 14에서 나온 Recode의 변경 사항으로 인해 내가 유지 관리하는 추가 기능의 일부가 손상되었습니다. 이 경우 코드를 작동시키기 위해 무언가를했고 화상을 입었습니다. 다른 (고객) 예는 누군가 데이터베이스에서 비 ODBC 호환 이름을 사용하고있는 곳입니다. 버전간에 ODBC를 적용하면 스크립트가 중단되었습니다. 여기 누군가가 표준을 따르지 않았고 화상을 입었습니다. 테이크 아웃은 고객이 JSL 작성을위한 모범 사례를 따르는 코드를 만들면 문제가 발생할 가능성이 적다는 것입니다. 그들이 그렇게하면 JSL이 버전을 버리는 경우는 거의 없습니다. 내가 방어 스크립팅에 대한 사고 방식으로 작성한 것들의 대부분은 매우 강력하지만 여전히 모든 것이 작동하고 있는지 확인합니다. 나는 일반적으로 테스트를 위해 마지막 얼리 어답터 릴리스의 마지막 몇 개가 나올 때까지 기다립니다 (JMP 로의 변경은 일반적으로 그 시점에서 꽤 안정적입니다).
Ian은 버전 간 이동에 대해 정말 좋은 지적을했습니다. 미국에는 엄격한 규제를받는 특정 산업 (약품, 생명 공학, 금융 및 군사 또는 국가 안보 응용 분야의 일부 제조업)이 있습니다. 이러한 산업에는 새로운 소프트웨어 또는 새로운 버전의 소프트웨어에 대한 검증 요구 사항이 있으며, 사용자 기반에서 소프트웨어가 작동하는지 확인하고 문서간에 일관된 결과를 제공하도록 문서화해야합니다. 다른 고객은 버전 간 코드를 확인해야한다는 것을 알고 있습니다. 그래서 나는 그것이 실제로 그 고객 (또는 적어도 거기에서 JSL을 생성하는 사람들)의 회사 문화에서 성숙과 규율의 문제라고 생각합니다. Ian이 언급 한 테스트 워크 플로 (스테이징 후 릴리스에서 프로덕션으로)는 내가 함께 일했던 모든 산업 (미국, EU 또는 아시아)에서 표준 실습입니다. 가정하는 것보다 잘 알고 있어야합니다.
따라서 요약하자면 – JSL이 미션 크리티컬 한 경우 다른 프로덕션 소프트웨어처럼 취급하고 프로덕션에 출시하기 전에 JMP 버전 (미션 크리티컬 JSL 포함)의 유효성을 검사해야합니다. 귀하의 불만은 주로 엔지니어링 커뮤니티의 일부에서 비롯되며 그 작동 방식을 이해하지 못합니다. 해당 툴의 성능을 철저히 테스트하고 다른 부품과 일치시키기 전에 생산에 새로운 장비를 출시 할 것인지 물어볼 수 있습니다.“아니요”라고 대답 할 수 있습니다.이 시점에서 소프트웨어는 툴이며 동일하게 취급되었습니다.
후속 생각
사람들이 JSL 모범 사례를 따르는 경우 (함수 및 표현식, 범위 지정, 네임 스페이스, 그들의 코드를 많이 언급 등) 문제가 발생하면 디버깅하기가 더 쉽습니다. 따라서 문제의 고객이 시간이 지남에 따라 유기적으로 성장한 잘못된 형태의 취성 JSL을 가지고있는 것처럼 들립니다. 아마도 끔찍한 논평이 있었으며 그것을 쓴 사람은 계속 움직 였거나 고칠 방법을 모릅니다 (이 프랑켄 스크립트라고 부릅니다) ... 이 경우 JSL을 아는 사람을 SAS Ed JSL 과정으로 보내서 모범 사례를 다시 찾은 다음 느슨하게 설정하여 문제의 코드를 현대화하고 문제의 JSL을 추가하기 위해 SOP를 배치하는 것이 좋습니다. 소프트웨어 검증 테스트 계획에
Re : 스크립팅 : 일반적인 호환성나는 지금까지 모든 의견에 동의합니다. 끔찍한 '생산'코드를 항상 봅니다. 나는 그것이 현재 버전에서 작동한다고 믿을 수 없으며, 미래에 대한 희망이 훨씬 적습니다. 이 사용자는 JMP를 스크립팅하는 방법을 배우지 않았습니다. 일반적인 컴퓨터 프로그래밍과는 다릅니다. 단지 구문이 아닙니다. 그들은 단지 해킹합니다. (나는 '해커'라는 용어를 복수와 함께 사용합니다. 이 활동은 다릅니다.) 그들은 무엇을하고 있는지 모릅니다.
보고서 계층에 대한 액세스를 방해하는 JMP UI의 변경 사항에 대한 의견은 많은 사용자가 안전한 코딩을 연습하지 않습니다. 이러한 문제를 최소화하거나 제거 할 수있는 방법이 있지만 그 방법으로 취성 코드가 생성됩니다.
Re : 스크립팅 : 일반적인 호환성의견을 보내 주셔서 감사합니다. 프로덕션 및 저장 / 방어 코딩을 시작하기 전에 테스트와 관련된 모든 사항에 동의합니다 (사용자는 아마 그것을 좋아하지는 않지만;)). 이는 어떤 언어로든 스크립트를 사용하는 사용자와 회사의 책임입니다.
그러나 더 중요한 관점으로 토론을 진행하고 싶습니다 (결국 우리는 고객에게 공통적 인 메시지를 전달하고 고객에게 판매하는 더 강력한 자동화 프로세스를 원합니다).
툴이 구축 된 프로그래밍 언어에 의존하는 소프트웨어 회사에서 나온 JSL의 버전이 얼마나 자주 바뀌는 지 알고 놀랍습니다. 과거에는 문서화되지 않은 기능과 기능에만 문제가 있었지만 개체 테마 나 개체 트리의 색상 테마 및 기타 항목과 같은 설정 및 옵션에는 문제가 없었습니다. 또한 모든 기능은 사용 가능한 입력 및 출력,이 옵션 / 입력 / 출력의 설명 및 정의 등 전체 범위로 문서화되었습니다. 스크립팅 안내서와 색인은 모두 그런 종류가 아닙니다. 더 많은 것은 이것이 기본 전화이고 당신이 스스로 알아낼 수있는 다른 모든 옵션입니다.
문서화되지 않은 모든 부분이 변경 될 수 있다고 말할 수 있습니다. 쉬운 답변이 될 것입니다. 그러나 나는 그렇게 쉬운 일이 아니라고 생각합니다. 대부분의 경우 우리는 최소한 "내장 기능보다 한 수준 아래"를 약간 변경해야합니다. 우리는 "당신이 할 수있는 일"과 "다른 모든 것은 지원되지 않는다"는 구체적인 문서를 제공하지 않습니다.
프로그래밍 언어는 그러한 프레임 워크를 가져야합니다. 또는 JSL은 그러한 프로그래밍 언어가 아니며 현재 재현 가능한 코드를 작성하기 쉽지만 더 신뢰할 수있는 애플리케이션을 만드는 더 많은 사용자에게 다가 가기 위해 애플리케이션을 만드는 현재 프로모션에 더주의를 기울여야합니다. 향후 버전을 위해.
나는 다른 사람들이 이것에 대해 어떻게 느끼는지 듣고 싶습니다. (나는이 주제에 대해 다이버 토론을 장려하기 위해 더 많은 목적으로 비판적 견해를 인정합니다.) 데이베이스.
Re : 스크립팅 : 일반적인 호환성JSL은 엄청나게 강력하지만, 핵심은 "프로그래밍 언어"가 아니라 스크립팅 또는 매크로 언어입니다. 객체 지향 프로그래밍과 유사한 구조를 가지고 있으며 어느 정도는 그 방식으로 사용될 수 있지만 JMP를 기반으로 구축되었으며 항상 GUI에서 작업을 자동화하거나 GUI를 확장하기 위해 고안되었습니다. 많은 사람들이 제품에서 변경 될 때를 잊어 버리는 것을 잊어 버립니다. 특히 JSL에서 문제가 발생할 수 있습니다 (특히 코드를 제대로 작성하지 않으면). 우리는 JSL에 대해 우리가 C ++을하는 방식에 대해 이야기해서는 안됩니다. 엄밀히 말하면, 파이썬과 R조차도 JSL보다 더 밀접하게 관련된 프로그래밍 언어입니다. Excel Macros 및 VBA로 선이 흐려져 일부 사람들이 혼란스러워 할 수 있습니다. 그러나 요점은 JSL은 프로그래밍 언어와는 다른 스크립팅 언어라는 것입니다.
베스트,
엠
Re : 스크립팅 : 일반적인 호환성안녕 마이크,
동의합니다, 그것은 스크립팅 언어이므로 밟아야합니다. 이 dicscussion은 프로세스 자동화 또는 스크립팅을 시작할 때 사람들이 항상 생각해야 할 몇 가지 추가 측면을 강조하기 때문에 귀중한 것으로 나타났습니다. JMP JSL 교육 과정 외에 "방어"스크립팅에 대한 다른 JMP 관련 참조가 있습니까?
웹에서 발견되는 대부분의 참조는 다른 언어에 대한 것이며 JMP와 관련이 없습니다 (물론 사용할 수도 있지만). Mastering JMP 웹 캐스트는 좋은 프로그래밍 / 스크립트 스타일을 다루지 않습니다. 발견 프레젠테이션에도 흥미로운 주제가 될 수 있습니까?
Re : 스크립팅 : 일반적인 호환성그것은 우리가 개선 할 수있는 영역 중 하나입니다. 커뮤니티, 스태프의 두뇌, 책, 문서에는 많은 정보가 있지만 실제로 알고있는 "모범 사례"문서는 없습니다. 있어야합니다. 나는 당신이 현장에서 겪고있는 많은 충격을이 한 지점까지 초크 할 수 있다고 생각합니다.
ian – 아마도 이것은 기술 커뮤니티가 시작하는 동안 사이드 바로 할 수있는 일일 것입니다.
베스트,
엠
Re : 스크립팅 : 일반적인 호환성내 대답이 암시했듯이, 나는 이것이 우리가 더 잘 할 수있는 영역이라고 생각합니다. 특히 우리는 일반적으로 '토지 및 확장 전략'의 '확장'부분의 구성 요소로 응용 프로그램을 구축하도록 권장하기 때문에.
FWIW, 개인적 견해는 모든 SE가 JSL에 능숙하지는 않다는 것입니다. 그러나 나는 모든 SE가 가능한 것이 무엇인지, 그리고 이것과 함께, 좋은 습관이 어떻게 생겼는지, 이것에 고착하지 않는 함정을 알아야한다고 믿는다.
불행히도 2020 킥오프는 약간 압축되었지만 기술 트랙은 이미 구성되어 있습니다. 그래서 우리는 이것을 처리하는 다른 방법을 찾을 것입니다. 더 늦게.
Re : 스크립팅 : 일반적인 호환성우리는 여러 판 전에 스크립팅 과정에서 "모범 사례"제안을 추가하기 시작했습니다. 우리는 개정 할 때마다 이러한 제안을 계속 확장하고 개선합니다. 우리는 학생들로부터 긍정적 인 피드백을받습니다. 적어도 서두르지 않은 학생들은 해킹 당할 것입니다.
