그래서 왜 모든 것을 복잡하게 만들고, 추가 인수에 동의하고, 지불 시스템을 개선합니다. 적용할 때 간단한 "소스" 확인란이 협상 단계 전에도 모든 문제를 해결한다면. 그것은 모든 오해와 시간 낭비를 해결합니다. 그리고 이것이 용납되지 않는 사람은 당신을 방해하지 않을 것입니다. 사실 내 시스템은 별도의 모듈을 배치하기에는 서로 너무 깊숙이 통합되어 있습니다. 문제 없습니다. 물론 신호 모듈(또는 애플리케이션의 모듈)을 ex-file에 첨부할 수 있습니다. 실행의 논리를 이해하기 위해서만.
pronych : 그래서 왜 모든 것을 복잡하게 만들고, 추가 인수에 동의하고, 지불 시스템을 개선합니다. 적용할 때 간단한 "소스" 확인란이 협상 단계 전에도 모든 문제를 해결한다면. 그것은 모든 오해와 시간 낭비를 해결합니다. 그리고 이것이 용납되지 않는 사람은 당신을 방해하지 않을 것입니다. 사실 내 시스템은 별도의 모듈을 배치하기에는 서로 너무 깊숙이 통합되어 있습니다. 문제 없습니다. 물론 신호 모듈(또는 애플리케이션의 모듈)을 ex-file에 첨부할 수 있습니다. 실행의 논리를 이해하기 위해서만.
서비스가 자동으로 코드를 업데이트 하지 않는 한(스토어에 선언된 대로) 이것은 모두 쓰레기입니다.
고객은 다음 빌드 업데이트 전에 작동 중인 프로그램이 아니라 작동 중인 프로그램을 받아야 합니다. 실행자는 모든 실행된 주문이 최신 빌드에서 컴파일되는지 확인하지 않습니다.
pronych : 그래서 왜 모든 것을 복잡하게 만들고, 추가 인수에 동의하고, 지불 시스템을 개선합니다. 적용할 때 간단한 "소스" 확인란이 협상 단계 전에도 모든 문제를 해결한다면. 그것은 모든 오해와 시간 낭비를 해결합니다. 그리고 이것이 용납되지 않는 사람은 당신을 방해하지 않을 것입니다. 사실 내 시스템은 별도의 모듈을 배치하기에는 서로 너무 깊숙이 통합되어 있습니다. 문제 없습니다. 물론 신호 모듈(또는 애플리케이션의 모듈)을 ex-file에 첨부할 수 있습니다. 실행의 논리를 이해하기 위해서만.
그냥 관심에서, 이 갈까마귀를 필요로 하는 고객의 로보토마이즈된 다운을 설명하기 위해 여기에서 시도하십시오.
이것은 시장입니다. 당신이 원하는 것이 중요하지 않습니다. 고객이 원하는 것이 중요하지 않습니다. 중요한 것은 당신이 동의하는 것뿐입니다.
고객의 1%는 기록에 대한 일종의 통계 수집과 같은 일회성 스크립트를 주문하여 이 확인란에 동의합니다.
한 번 왼쪽 또는 오른쪽으로 더 파고이 질문과 스크립트를 잊어 버릴 수있는 질문에 답하기 위해.
주문한 프로그램 의 나머지 부분은 오랫동안 필요할 것이며, 어쨌든 그들은 그렇게 생각할 것입니다.
그런 다음 모든 서비스, 모든 상점은 최소한의 클릭으로 매우 간단하고 시각적이며 편리하고 안정적이어야 합니다.
komposter : Alexey, 이 갈까마귀 가 이미 있다고 생각 하십시오. 모든 주문에.
잘. 감사합니다. 그들은 무언가에 왔습니다.) 그리고 자동 재 컴파일에 대한 주제도 있습니다. 알겠습니다. 포기하겠습니다. 논쟁하지 않겠습니다. 여기 지지자가 별로 없어요. 아마도 나중의 삶은 당신이 이 주제로 돌아가도록 강요할 것입니다. 결국, 고객이 항상 소스 코드를 받는 것은 아닙니다. 특히 이 문제를 mql의 프레임워크 내에서가 아니라 일반적으로 소프트웨어 개발에서 보면...
모든 Ivan Susanin은 실수할 권리가 있고, 모든 공병은 실수할 권리가 있으며, 모든 저격수는 놓칠 권리가 있으며, 모든 조종사 또는 운전자는 충돌할 권리가 있으며, 모든 판매자는 구매자를 과소평가할 권리가 있으며, 모든 전기 기술자는 전압을 측정할 때 실수를 할 권리, 모든 거래자는 공동 마진을 할 권리가 있습니다. 어떻게 보면 옳고 그름은 터무니없어 보입니다 .
강조 표시된 부분에 대한 설명: 이 접근 방식을 사용하면 "모든 판사는 실수할 권리가 있습니다"라는 가정을 반영할 수 있는 좋은 기회가 있습니다. 그리고 이 가정을 당신의 삶의 경험에 적용하십시오.
그리고 우리 각자가 주기적으로 문제를 해결하기 위해 판사의 역할을 한다는 것을 고려하면 "내 경우"(즉, 귀하의 경우)에서이 가정이 터무니없이 보이는지 확인할 수있는 좋은 기회가 있습니다. :) 또는 거의 터무니없는 :)
수백 명의 사람들 이 이해할 수 없는 권리 문제가 해결되지 않을 때까지 혼미에 얼어붙었고, 무엇인지 명확하지 않습니다 . 그리고 봇만이 "작업" 서비스에서 가상 주문과 실행을 생성합니다.
명백한 사실을 인정하는 것이 무슨 잘못입니까?
우리 모두는 이미 명백한 사실을 인정했습니다. 이것은 Mischek 이 공손하게 권리에 의해 "실패"라고 불렸을 때 일어났습니다. 따라서 "...이해할 수 없는 무엇에 대한 이해할 수 없는 권리의 문제"라는 구절은 " 미첵 의 이해할 수 없는 미첵 의 무엇에 대한 이해할 수 없는 권리의 문제"라는 구절로 간주되어야 한다. 실례가 되지 않고 사실만 기재합니다.
나는 항상 소스를 게시했습니다.
그러나이 질문이 너무 귀찮다면 곧 간단한 계획을 사용할 수 있습니다.
근로계약을 체결할 때(각각, 정확한 수주금액을 알 때), 무엇을 구매해야 하는지 명시합니다.
플러그인을 사용하려면 상점에 게시한 모듈이 필요합니다. 그리고 실행된 TOR의 소스 코드를 게시합니다.
따라서 도서관 비용이 할인됩니다.
MQ에 결제 시스템을 마무리 해달라고 요청할 수 있지만 상점에서 주문 금액에서 무언가를 살 수 있습니다(고객이 계약자 또는 고객을 대신하여 계약자의 추천으로 구매한다는 의미입니다). 가장 중요한 것은 고객이 구매한 항목을 업데이트할 수 있다는 것입니다.
그래서 왜 모든 것을 복잡하게 만들고, 추가 인수에 동의하고, 지불 시스템을 개선합니다. 적용할 때 간단한 "소스" 확인란이 협상 단계 전에도 모든 문제를 해결한다면. 그것은 모든 오해와 시간 낭비를 해결합니다. 그리고 이것이 용납되지 않는 사람은 당신을 방해하지 않을 것입니다. 사실 내 시스템은 별도의 모듈을 배치하기에는 서로 너무 깊숙이 통합되어 있습니다. 문제 없습니다. 물론 신호 모듈(또는 애플리케이션의 모듈)을 ex-file에 첨부할 수 있습니다. 실행의 논리를 이해하기 위해서만.
서비스가 자동으로 코드를 업데이트 하지 않는 한(스토어에 선언된 대로) 이것은 모두 쓰레기입니다.
고객은 다음 빌드 업데이트 전에 작동 중인 프로그램이 아니라 작동 중인 프로그램을 받아야 합니다. 실행자는 모든 실행된 주문이 최신 빌드에서 컴파일되는지 확인하지 않습니다.
그래서 왜 모든 것을 복잡하게 만들고, 추가 인수에 동의하고, 지불 시스템을 개선합니까? 적용할 때 간단한 "소스" 확인란이 협상 단계 전에도 모든 문제를 해결한다면.
그래서 왜 모든 것을 복잡하게 만들고, 추가 인수에 동의하고, 지불 시스템을 개선합니다. 적용할 때 간단한 "소스" 확인란이 협상 단계 전에도 모든 문제를 해결한다면. 그것은 모든 오해와 시간 낭비를 해결합니다. 그리고 이것이 용납되지 않는 사람은 당신을 방해하지 않을 것입니다. 사실 내 시스템은 별도의 모듈을 배치하기에는 서로 너무 깊숙이 통합되어 있습니다. 문제 없습니다. 물론 신호 모듈(또는 애플리케이션의 모듈)을 ex-file에 첨부할 수 있습니다. 실행의 논리를 이해하기 위해서만.
그냥 관심에서, 이 갈까마귀를 필요로 하는 고객의 로보토마이즈된 다운을 설명하기 위해 여기에서 시도하십시오.
이것은 시장입니다. 당신이 원하는 것이 중요하지 않습니다. 고객이 원하는 것이 중요하지 않습니다. 중요한 것은 당신이 동의하는 것뿐입니다.
고객의 1%는 기록에 대한 일종의 통계 수집과 같은 일회성 스크립트를 주문하여 이 확인란에 동의합니다.
한 번 왼쪽 또는 오른쪽으로 더 파고이 질문과 스크립트를 잊어 버릴 수있는 질문에 답하기 위해.
주문한 프로그램 의 나머지 부분은 오랫동안 필요할 것이며, 어쨌든 그들은 그렇게 생각할 것입니다.
그런 다음 모든 서비스, 모든 상점은 최소한의 클릭으로 매우 간단하고 시각적이며 편리하고 안정적이어야 합니다.
Alexey, 이 갈까마귀 가 이미 있다고 생각 하십시오. 모든 주문에.
잘. 감사합니다. 그들은 무언가에 왔습니다.) 그리고 자동 재 컴파일에 대한 주제도 있습니다. 알겠습니다. 포기하겠습니다. 논쟁하지 않겠습니다. 여기 지지자가 별로 없어요. 아마도 나중의 삶은 당신이 이 주제로 돌아가도록 강요할 것입니다. 결국, 고객이 항상 소스 코드를 받는 것은 아닙니다. 특히 이 문제를 mql의 프레임워크 내에서가 아니라 일반적으로 소프트웨어 개발에서 보면...
토론해 주셔서 감사합니다.
Integer :
모든 사람은 틀릴 권리가 있습니다. 그 이유는 앞서 밝혔습니다.
모든 Ivan Susanin은 실수할 권리가 있고, 모든 공병은 실수할 권리가 있으며, 모든 저격수는 놓칠 권리가 있으며, 모든 조종사 또는 운전자는 충돌할 권리가 있으며, 모든 판매자는 구매자를 과소평가할 권리가 있으며, 모든 전기 기술자는 전압을 측정할 때 실수를 할 권리, 모든 거래자는 공동 마진을 할 권리가 있습니다. 어떻게 보면 옳고 그름은 터무니없어 보입니다 .
강조 표시된 부분에 대한 설명: 이 접근 방식을 사용하면 "모든 판사는 실수할 권리가 있습니다"라는 가정을 반영할 수 있는 좋은 기회가 있습니다. 그리고 이 가정을 당신의 삶의 경험에 적용하십시오.
그리고 우리 각자가 주기적으로 문제를 해결하기 위해 판사의 역할을 한다는 것을 고려하면 "내 경우"(즉, 귀하의 경우)에서이 가정이 터무니없이 보이는지 확인할 수있는 좋은 기회가 있습니다. :) 또는 거의 터무니없는 :)
수백 명의 사람들 이 이해할 수 없는 권리 문제가 해결되지 않을 때까지 혼미에 얼어붙었고, 무엇인지 명확하지 않습니다 . 그리고 봇만이 "작업" 서비스에서 가상 주문과 실행을 생성합니다.
명백한 사실을 인정하는 것이 무슨 잘못입니까?
여기 지지자가 별로 없어요. 아마도 나중의 삶은 당신이 이 주제로 돌아가도록 강요할 것입니다.
네, 문제는 지지자의 수가 아닙니다. 당신은 만인에 대해 하나가 될 수 있고 여전히 옳습니다.
귀하의 주제에서 제기된 두드러진 요점이 논의됩니다. 상황에서 벗어나는 방법 - 프롬프트됩니다. 그리고 도발 - 얼마나 더 많은 것이 우리의 길에있을 것입니다 ...! :)
토론해 주셔서 감사합니다.
글쎄, 나는 코멘트를 거부할 수 없었다 :)
네, 문제는 지지자의 수가 아닙니다. 당신은 만인에 대해 하나가 될 수 있고 여전히 옳습니다.
귀하의 주제에서 제기된 두드러진 요점이 논의됩니다. 상황을 벗어나는 방법 - 프롬프트. 그리고 도발 - 얼마나 더 많은 것이 우리의 길에있을 것입니다! :)
글쎄, 나는 코멘트를 거부할 수 없었다 :)