예를 들어 분석을 위해 새로운 사용자가 와서 비트코인 스레드를 열면 해당 주제를 삭제할 것입니까?그 사용자는 mql5에 머물 것입니까?
중재자가 새 섹션을 만들 수 없다는 것을 이해하지만 이해합니다. 하지만 여기에는 이중 잣대가 있는 것 같습니다.
따라서 이더리움 차트를 열고 asctrend 시스템이 좋은 설정을 찾았다면 "이더리움 예측 및 분석"을 열지 않을 것이지만 GBP에서 열리면 기존 스레드 중 하나를 사용하게 됩니다. 왜냐하면 그것은 존재합니까?
이더리움이 아니라 터키 리라(forex), EUR/TRY에 대해 동일한 것을 게시하고 싶다면 새 주제를 만들지 않고 다른 주제가 없으므로 다음 위치에 게시하지 않습니다. 모두 ?
스팸을 피하는 것보다 다른 사람들이 게시하지 않는 것이 더 중요하다는 느낌을 받는 이유는 무엇입니까?
예, 새 스레드를 삭제하고 여러 번 삭제합니다. 그리고 나는 새 스레드를 열지 않을 것입니다(EUR/TRY가 있는 게시물은 EUR의 스레드로 이동합니다).
그래서 포럼은 요즘 활동으로 가득 차 있고 우리는 분석에 대해 논의할 필요가 없습니까?
포럼은 서비스 데스크 대신 사용되며 다음과 관련된 활동입니다.
"버그를 찾았어요..."
"도와주세요 ..."
등등.
얼마나 많은 사용자가 소스 코드로 스레드에 업로드된 EA와 함께 포럼에서 직접 거래 시스템을 생성했으며 설정을 최적화/백테스트하고 설정을 수정하고 거래 시스템을 개선하는 방법에 대한 아이디어를 얻기 위해 데모 계정에서 거래했습니다( 모든 것이 스레드에 직접 있음) ? 나는 단지 그것을했습니다 ... 그리고 저는 코더가 아닙니다 ... 그러한 스레드를 만들고 유지 관리하는 것이 얼마나 어려운지 상상할 수 있습니다 (예를 들어 ASCTREND SYSTEM 요약 ).
지난 5년 동안 여기에서 몇 명의 사용자가 프로모션 없이 기술 분석 게시물을 작성했습니까? 했을뿐..
그래서 논의할 것이 없다.. 나는 포럼에서 이 "기술적 분석 이야기"를 시작했고, 포스트를 작성했고(지난 몇 년 동안 나를 제외하고는 아무도 하지 않았다), 일부 스레드를 삭제하여 하루 만에 끝낼 수 있는 권리가 있습니다.
주의를 환기시키기 위해 게시물 #26 을 복사합니다(포스트는 주로 시장과 관련이 있지만 다른 상황에서는 유용합니다) -
----------------
가능한 기술적인 버그 또는 기술적인 방식으로 작업을 수행할 수 없는 경우 - 제 개인적인 발표입니다. 그것을 해결하기 위해):
이것은 MQ의 공식 답변입니다.
버그를 보고하는 공개 프로세스를 갖는 것은 좋은 일이며 좋은 기술 보고서를 요청하는 것이 맞습니다. 그러나 Metaquotes가 수행한 방식은 좋지 않으며 대부분의 사람들이 버그를 보고하지 않도록 합니다. 이유는 다음과 같습니다.
견고하고 문서화되고 재현 가능한 버그 보고서를 준비하는 것은 시간이 많이 걸리며 때로는 매우 시간이 많이 걸립니다. 그러나 이미 그것을 하고 있는 사람이 없다는 것을 어떻게 알 수 있습니까? 모든 포럼을 읽어야 합니까? 중심적으로 볼 곳이 없기 때문입니다.
피드백을 받으면 여전히 할 준비가 되어 있지만 거의 그렇지 않습니다. 버그가 발생하면 대부분 MT5 또는 mql5에서 제공하는 일부 기능이나 기술을 사용해야 하기 때문입니다. 버그가 있을 때 해결 방법을 찾아야 할 수도 있습니다. 버그가 곧 수정될 것이라는 것을 알았다면 미룰 수 있었습니다.
그래서 지금 일어나고 있는 일은 가장 유능한 코더들이 다른 선택의 여지가 없을 때만 버그를 보고한다는 것입니다. 우리는 MT5, mql5를 좋아하고 mql5.com을 사용하는 모든 이점에 감사합니다. 하지만 낭비할 시간이 없고 베타 테스터에게 급여를 받지도 않습니다. 따라서 Metaquotes, 특히 Renat의 일부 고려는 환영받을 것입니다 . 주로 버그 보고서를 더 잘 구성해야 합니다. 이를 관리하기 위해 무료로 공개적으로 사용할 수 있는 소프트웨어가 있습니다. Metaquote가 공개적으로 보고된 버그를 관리하기 위한 좋은 솔루션을 구현하는 것이 왜 그렇게 어려운가요?!
Sergey, 가능하면 Renat에게 보고해 주십시오. 매우 합리적이고 건설적인 제안입니다.
나는 Alain이 말하는 것을 두 번째로 생각합니다. MT4와 MT5 모두에서 버그 수를 잃었습니다. 자세한 버그 보고서를 작성하면 기껏해야 매우 모호한 결과와 함께 10배 더 많은 시간과 리소스를 소비할 것이기 때문에 몇 가지 대체 코딩 솔루션으로 우회했습니다. 버그가 이미 보고되었는지, 개발자가 이미 알고 있는지 확인할 방법이 없을 때, 버그 보고서를 제출할 때 피드백이 거의 또는 전혀 없을 때, 일부 버그를 수정하는 데 몇 년이 걸리는 경우 MQL 개발자에게는 실제로 인센티브가 없습니다. 최후의 수단이 아닌 한 보고서를 제출합니다. MetaQuotes가 좋은 보고서를 얻고 전반적인 개발자 경험 수준을 개선하는 데 관심이 있는 경우 버그 추적 시스템을 통합하면 여기에서 많은 도움이 될 것입니다. 감사해요!
Andriy Moraru : 나는 Alain이 말하는 것을 두 번째로 생각합니다. MT4와 MT5 모두에서 버그 수를 잃었습니다. 자세한 버그 보고서를 작성하면 기껏해야 매우 모호한 결과와 함께 10배 더 많은 시간과 리소스를 소비할 것이기 때문에 몇 가지 대체 코딩 솔루션으로 우회했습니다. 버그가 이미 보고되었는지, 개발자가 이미 알고 있는지 확인할 방법이 없을 때, 버그 보고서를 제출할 때 피드백이 거의 또는 전혀 없을 때, 일부 버그를 수정하는 데 몇 년이 걸리는 경우 MQL 개발자에게는 실제로 인센티브가 없습니다. 최후의 수단이 아닌 한 보고서를 제출합니다. MetaQuotes가 좋은 보고서를 얻고 전반적인 개발자 경험 수준을 개선하는 데 관심이 있다면 버그 추적 시스템을 통합하는 것이 여기에서 많은 도움이 될 것입니다. 감사해요!
버그를 보고하는 공개 프로세스를 갖는 것은 좋은 일이며 좋은 기술 보고서를 요청하는 것이 맞습니다. 그러나 Metaquotes가 수행한 방식은 좋지 않으며 대부분의 사람들이 버그를 보고하지 않도록 합니다...
포럼에 마지막으로 게시물을 올린 지 꽤 되었지만 100% 동의합니다. 웹에서 내가 아는 다른 모든 소프트웨어 개발 팀이 수십 년 전에 이를 구현 했는데 Metaquotes 가 왜 이 작업을 수행하지 않았는지 이해할 수 없습니다.
MetaQuotes가 그렇게 하지 않는 것에 대해 제가 생각할 수 있는 유일한 이유는 완전한 무능력 및/또는 단순히 자신과 주요 이익을 받는 중개인을 위해 사용자 기반을 조작하기를 원하기 때문입니다. 즉, 관련된 모든 당사자의 전반적인 이익과 만족에 대해 보다 전체적인 관점을 취하는 대신 "탐욕" 으로 알려진 단순하고 일방적인 관점입니다!
그렇기 때문에 MetaQuotes 는 우리가 몇 번이고 불평을 해도 그러한 시스템을 구현하지 않을 것이라고 진심으로 믿습니다.
버그를 보고하는 공개 프로세스를 갖는 것은 좋은 일이며 좋은 기술 보고서를 요청하는 것이 맞습니다. 그러나 Metaquotes가 수행한 방식은 좋지 않으며 대부분의 사람들이 버그를 보고하지 않도록 합니다. 이유는 다음과 같습니다.
견고하고 문서화되고 재현 가능한 버그 보고서를 준비하는 것은 시간이 많이 걸리며 때로는 매우 시간이 많이 걸립니다. 그러나 이미 그것을 하고 있는 사람이 없다는 것을 어떻게 알 수 있습니까? 모든 포럼을 읽어야 합니까? 중심적으로 볼 곳이 없기 때문입니다.
피드백을 받으면 여전히 할 준비가 되어 있지만 거의 그렇지 않습니다. 버그가 발생하면 대부분 MT5 또는 mql5에서 제공하는 일부 기능이나 기술을 사용해야 하기 때문입니다. 버그가 있을 때 해결 방법을 찾아야 할 수도 있습니다. 버그가 곧 수정될 것이라는 것을 알았다면 미룰 수 있었습니다.
그래서 지금 일어나고 있는 일은 가장 유능한 코더들이 다른 선택의 여지가 없을 때만 버그를 보고한다는 것입니다. 우리는 MT5, mql5를 좋아하고 mql5.com을 사용하는 모든 이점에 감사합니다. 하지만 낭비할 시간이 없고 베타 테스터에게 급여를 받지도 않습니다. 따라서 Metaquotes, 특히 Renat의 일부 고려는 환영받을 것입니다 . 주로 버그 보고서를 더 잘 구성해야 합니다. 이를 관리하기 위해 무료로 공개적으로 사용할 수 있는 소프트웨어가 있습니다. Metaquote가 공개적으로 보고된 버그를 관리하기 위한 좋은 솔루션을 구현하는 것이 왜 그렇게 어려운가요?!
Sergey, 가능하면 Renat에게 보고해 주십시오. 매우 합리적이고 건설적인 제안입니다.
기술/기본 분석은 포럼에서 거의 주제에서 벗어났습니다. 해당 스레드는 몇 년 전 포럼에서 활동이 매우 적었을 때 포럼을 새로고침하여 좋은 일을 했습니다.
그리고 해당 스레드 중 일부(또는 대부분)가 하루 안에 삭제된다면 포럼에는 아무 일도 일어나지 않을 것입니다.
그래서 포럼은 요즘 활동으로 가득 차 있고 우리는 분석에 대해 논의할 필요가 없습니까?
예를 들어 분석을 위해 새로운 사용자가 와서 비트코인 스레드를 열면 해당 주제를 삭제할 것입니까? 그 사용자는 mql5에 머물 것입니까?
중재자가 새 섹션을 만들 수 없다는 것을 이해하지만 이해합니다. 하지만 여기에는 이중 잣대가 있는 것 같습니다.
따라서 이더리움 차트를 열고 asctrend 시스템이 좋은 설정을 찾았다면 "이더리움 예측 및 분석"을 열지 않을 것이지만 GBP에서 열리면 기존 스레드 중 하나를 사용하게 됩니다. 왜냐하면 그것은 존재합니까?
이더리움이 아닌 터키 리라(forex), EUR/TRY에 대해 동일한 것을 게시하려는 경우 단순화할 수 있습니다. 새 주제를 생성하지 않고 다른 주제가 없으므로 에 게시하지 않습니다. 모두 ?
스팸을 피하는 것보다 다른 사람들이 게시하지 않는 것이 더 중요하다는 느낌을 받는 이유는 무엇입니까?
그래서 포럼은 요즘 활동으로 가득 차 있고 우리는 분석에 대해 논의할 필요가 없습니까?
예를 들어 분석을 위해 새로운 사용자가 와서 비트코인 스레드를 열면 해당 주제를 삭제할 것입니까? 그 사용자는 mql5에 머물 것입니까?
중재자가 새 섹션을 만들 수 없다는 것을 이해하지만 이해합니다. 하지만 여기에는 이중 잣대가 있는 것 같습니다.
따라서 이더리움 차트를 열고 asctrend 시스템이 좋은 설정을 찾았다면 "이더리움 예측 및 분석"을 열지 않을 것이지만 GBP에서 열리면 기존 스레드 중 하나를 사용하게 됩니다. 왜냐하면 그것은 존재합니까?
이더리움이 아니라 터키 리라(forex), EUR/TRY에 대해 동일한 것을 게시하고 싶다면 새 주제를 만들지 않고 다른 주제가 없으므로 다음 위치에 게시하지 않습니다. 모두 ?
스팸을 피하는 것보다 다른 사람들이 게시하지 않는 것이 더 중요하다는 느낌을 받는 이유는 무엇입니까?
예, 새 스레드를 삭제하고 여러 번 삭제합니다.
그리고 나는 새 스레드를 열지 않을 것입니다(EUR/TRY가 있는 게시물은 EUR의 스레드로 이동합니다).
그래서 포럼은 요즘 활동으로 가득 차 있고 우리는 분석에 대해 논의할 필요가 없습니까?
포럼은 서비스 데스크 대신 사용되며 다음과 관련된 활동입니다.
얼마나 많은 사용자가 소스 코드로 스레드에 업로드된 EA와 함께 포럼에서 직접 거래 시스템을 생성했으며 설정을 최적화/백테스트하고 설정을 수정하고 거래 시스템을 개선하는 방법에 대한 아이디어를 얻기 위해 데모 계정에서 거래했습니다( 모든 것이 스레드에 직접 있음) ?
나는 단지 그것을했습니다 ... 그리고 저는 코더가 아닙니다 ... 그러한 스레드를 만들고 유지 관리하는 것이 얼마나 어려운지 상상할 수 있습니다 (예를 들어 ASCTREND SYSTEM 요약 ).
지난 5년 동안 여기에서 몇 명의 사용자가 프로모션 없이 기술 분석 게시물을 작성했습니까?
했을뿐..
그래서 논의할 것이 없다..
나는 포럼에서 이 "기술적 분석 이야기"를 시작했고, 포스트를 작성했고(지난 몇 년 동안 나를 제외하고는 아무도 하지 않았다), 일부 스레드를 삭제하여 하루 만에 끝낼 수 있는 권리가 있습니다.
주의를 환기시키기 위해 게시물 #26 을 복사합니다(포스트는 주로 시장과 관련이 있지만 다른 상황에서는 유용합니다) -
----------------
가능한 기술적인 버그 또는 기술적인 방식으로 작업을 수행할 수 없는 경우 - 제 개인적인 발표입니다. 그것을 해결하기 위해):
거래, 자동 거래 시스템 및 거래 전략 테스트에 관한 포럼
DAY 2 ...mt4 마켓 탭에 구매한 제품이 표시되지 않습니다....DAY 2
세르게이 골루베프 , 2020.09.22 08:59
모든 포럼 지원이 어떻게 진행되고 있는지(그리고 앞으로도 계속 될 것입니다):
내 생각에는 - 사용자가 자신이 한 일에 대한 증명/스크린샷 및 기술 정보에 대한 스크린샷을 제공하지 않은 경우(제공하지 않은 경우) 지원을 중단할 것입니다.
정확한 증거(스크린샷, 로그 파일)를 제공하는 것은 사용자의 책임입니다.
증거 없음 = 포럼 지원 없음(그리고 서비스 데스크는 증거가 없는 경우 도움을 주지 않습니다).
거래, 자동 거래 시스템 및 거래 전략 테스트에 관한 포럼
표시기 설치 문제
세르게이 골루베프 , 2020.05.18 18:54
증거는 스크린샷입니다.
거래, 자동 거래 시스템 및 거래 전략 테스트에 관한 포럼
MQL5 디버거의 새 버전이 준비 중입니다.
레나트 팻쿨린 , 2020.12.22 17:56
기술적으로 불완전하게 작성된 모든 내용은 무시합니다.주의를 환기시키기 위해 게시물 #26 을 복사합니다(포스트는 주로 시장과 관련이 있지만 다른 상황에서는 유용합니다) -
----------------
가능한 기술적인 버그 또는 기술적인 방식으로 작업을 수행할 수 없는 경우 - 제 개인적인 발표입니다. 그것을 해결하기 위해):
이것은 MQ의 공식 답변입니다.버그를 보고하는 공개 프로세스를 갖는 것은 좋은 일이며 좋은 기술 보고서를 요청하는 것이 맞습니다. 그러나 Metaquotes가 수행한 방식은 좋지 않으며 대부분의 사람들이 버그를 보고하지 않도록 합니다. 이유는 다음과 같습니다.
견고하고 문서화되고 재현 가능한 버그 보고서를 준비하는 것은 시간이 많이 걸리며 때로는 매우 시간이 많이 걸립니다. 그러나 이미 그것을 하고 있는 사람이 없다는 것을 어떻게 알 수 있습니까? 모든 포럼을 읽어야 합니까? 중심적으로 볼 곳이 없기 때문입니다.
피드백을 받으면 여전히 할 준비가 되어 있지만 거의 그렇지 않습니다. 버그가 발생하면 대부분 MT5 또는 mql5에서 제공하는 일부 기능이나 기술을 사용해야 하기 때문입니다. 버그가 있을 때 해결 방법을 찾아야 할 수도 있습니다. 버그가 곧 수정될 것이라는 것을 알았다면 미룰 수 있었습니다.
그래서 지금 일어나고 있는 일은 가장 유능한 코더들이 다른 선택의 여지가 없을 때만 버그를 보고한다는 것입니다. 우리는 MT5, mql5를 좋아하고 mql5.com을 사용하는 모든 이점에 감사합니다. 하지만 낭비할 시간이 없고 베타 테스터에게 급여를 받지도 않습니다. 따라서 Metaquotes, 특히 Renat의 일부 고려는 환영받을 것입니다 . 주로 버그 보고서를 더 잘 구성해야 합니다. 이를 관리하기 위해 무료로 공개적으로 사용할 수 있는 소프트웨어가 있습니다. Metaquote가 공개적으로 보고된 버그를 관리하기 위한 좋은 솔루션을 구현하는 것이 왜 그렇게 어려운가요?!
Sergey, 가능하면 Renat에게 보고해 주십시오. 매우 합리적이고 건설적인 제안입니다.
나는 Alain이 말하는 것을 두 번째로 생각합니다. MT4와 MT5 모두에서 버그 수를 잃었습니다. 자세한 버그 보고서를 작성하면 기껏해야 매우 모호한 결과와 함께 10배 더 많은 시간과 리소스를 소비할 것이기 때문에 몇 가지 대체 코딩 솔루션으로 우회했습니다. 버그가 이미 보고되었는지, 개발자가 이미 알고 있는지 확인할 방법이 없을 때, 버그 보고서를 제출할 때 피드백이 거의 또는 전혀 없을 때, 일부 버그를 수정하는 데 몇 년이 걸리는 경우 MQL 개발자에게는 실제로 인센티브가 없습니다. 최후의 수단이 아닌 한 보고서를 제출합니다. MetaQuotes가 좋은 보고서를 얻고 전반적인 개발자 경험 수준을 개선하는 데 관심이 있다면 버그 추적 시스템을 통합하는 것이 여기에서 많은 도움이 될 것입니다. 감사해요!
버그를 보고하는 공개 프로세스를 갖는 것은 좋은 일이며 좋은 기술 보고서를 요청하는 것이 맞습니다. 그러나 Metaquotes가 수행한 방식은 좋지 않으며 대부분의 사람들이 버그를 보고하지 않도록 합니다...
포럼에 마지막으로 게시물을 올린 지 꽤 되었지만 100% 동의합니다. 웹에서 내가 아는 다른 모든 소프트웨어 개발 팀이 수십 년 전에 이를 구현 했는데 Metaquotes 가 왜 이 작업을 수행하지 않았는지 이해할 수 없습니다.
MetaQuotes가 그렇게 하지 않는 것에 대해 제가 생각할 수 있는 유일한 이유는 완전한 무능력 및/또는 단순히 자신과 주요 이익을 받는 중개인을 위해 사용자 기반을 조작하기를 원하기 때문입니다. 즉, 관련된 모든 당사자의 전반적인 이익과 만족에 대해 보다 전체적인 관점을 취하는 대신 "탐욕" 으로 알려진 단순하고 일방적인 관점입니다!
그렇기 때문에 MetaQuotes 는 우리가 몇 번이고 불평을 해도 그러한 시스템을 구현하지 않을 것이라고 진심으로 믿습니다.
버그를 보고하는 공개 프로세스를 갖는 것은 좋은 일이며 좋은 기술 보고서를 요청하는 것이 맞습니다. 그러나 Metaquotes가 수행한 방식은 좋지 않으며 대부분의 사람들이 버그를 보고하지 않도록 합니다. 이유는 다음과 같습니다.
견고하고 문서화되고 재현 가능한 버그 보고서를 준비하는 것은 시간이 많이 걸리며 때로는 매우 시간이 많이 걸립니다. 그러나 이미 그것을 하고 있는 사람이 없다는 것을 어떻게 알 수 있습니까? 모든 포럼을 읽어야 합니까? 중심적으로 볼 곳이 없기 때문입니다.
피드백을 받으면 여전히 할 준비가 되어 있지만 거의 그렇지 않습니다. 버그가 발생하면 대부분 MT5 또는 mql5에서 제공하는 일부 기능이나 기술을 사용해야 하기 때문입니다. 버그가 있을 때 해결 방법을 찾아야 할 수도 있습니다. 버그가 곧 수정될 것이라는 것을 알았다면 미룰 수 있었습니다.
그래서 지금 일어나고 있는 일은 가장 유능한 코더들이 다른 선택의 여지가 없을 때만 버그를 보고한다는 것입니다. 우리는 MT5, mql5를 좋아하고 mql5.com을 사용하는 모든 이점에 감사합니다. 하지만 낭비할 시간이 없고 베타 테스터에게 급여를 받지도 않습니다. 따라서 Metaquotes, 특히 Renat의 일부 고려는 환영받을 것입니다 . 주로 버그 보고서를 더 잘 구성해야 합니다. 이를 관리하기 위해 무료로 공개적으로 사용할 수 있는 소프트웨어가 있습니다. Metaquote가 공개적으로 보고된 버그를 관리하기 위한 좋은 솔루션을 구현하는 것이 왜 그렇게 어려운가요?!
Sergey, 가능하면 Renat에게 보고해 주십시오. 매우 합리적이고 건설적인 제안입니다.
그리고 QuantConnect는 MT4/MT5가 자유 거래 플랫폼이기 때문에 Metatrader 4(MT4) 및 Metatrader 5(MT5)와 비교할 수 없습니다(MT4/MT5는 클라우드 기반 플랫폼이 아님).
----------------
이 스레드를 삭제하겠습니다.