...
not. Şimdiye kadar, iyi haber şu ki, şirket gelişiyor ve Pazarı ve MQL5 ürünlerinin satışını organize ediyor ve destekliyor. Sonuç olarak, kalite için bir mücadele olacak, ancak bunun bedelini itibarı ve rublesi ile kim ödeyecek?
Sorular çok alakalı. Ve bir çözüm bulmalıyız. Zaten bir teklifim var.
Örneğin, bunu yapabilirsiniz. Ticaret terminali için bir sonraki güncellemeyi (oluşturma) kurmak için, kullanıcı onu kurup kurmayacağına karar verir. Yani, yeni yapı hakkında bilgi sahibi olduğundan emin olmalısınız, ancak ne zaman yapılabileceğine kendisi karar verebilir. Uygulama geliştiricilerin daha sonra terminalin iki versiyonunun kurulu olması gerekir. Önceki yapıya sahip bir sürüm ve en son yapıya sahip ikinci sürüm. Ürünü kullanırken yeni yapıda herhangi bir hata bulunmazsa, satıcı Market'te ürünün en son sürümle uyumlu olduğunu not eder. Son derlemedeki ürün "başarısız olmaya" başlarsa, işareti koymayız ve kullanıcı yeni bir yapı kurmak için çok erken olduğunu bilir.
Bir seçenek gibi. Yine de düşünmek gerek...
- 2011.01.05
- MetaQuotes Software Corp.
- www.mql5.com
Aslında bu soru uzun zamandır demleniyor.
Şimdi üç taraf ne yapmalı?
İki. Programcının bununla hiçbir ilgisi yok. Ve Alıcının sadece yeni pazarı indirebilmesi gerekiyor. Mektup, istek, captcha, onay bildirimi vb.
Tabii ki, sadece o demirin üzerinde, zaten durduğu yerde.
Ürünler düzenli sürümlere sahiptir, bu konuda https://www.mql5.com/ru/articles/385 makalesinde okuyabilirsiniz.
Yeni bir sürüm yayınlandığında, programı güncellemek için otomatik bir teklif olacaktır. Bu seçenek, 2.xx gibi küçük sürümleri güncellemek için çok uygundur.
Büyük sürümler, mevcut müşteriler için otomatik ücretsiz yükseltmelerle eski kayıt kapsamında yeni sürümleri yeniden satabilmek veya yayınlamaya devam edebilmek için yeni bir ürünün kaydını gerektirecektir.
- 2012.04.17
- MetaQuotes Software Corp.
- www.mql5.com
Ürünler normal sürümlere sahiptir, bununla ilgili bilgileri https://www.mql5.com/en/articles/385 makalesinde okuyabilirsiniz.
Yeni bir sürüm yayınlandığında, programı güncellemek için otomatik bir teklif olacaktır. Bu seçenek, 2.xx gibi küçük sürümleri güncellemek için çok uygundur.
Büyük sürümler, mevcut müşteriler için otomatik ücretsiz yükseltmelerle eski kayıt kapsamında yeni sürümleri yeniden satabilmek veya yayınlamaya devam edebilmek için yeni bir ürünün kaydını gerektirecektir.
Evet, ürünlerin yeni sürümlerini ilgilendiren şey budur.
Ancak bu, sorunun ne hakkında olduğundan biraz farklı.
Yeni bir terminal yapısı yazılımın normal çalışmasını engellerse ne yapacağınızla ilgileniyor musunuz?
Tahmin ederseniz, yapılar ayda yaklaşık iki kez çıkıyor. Terminali güncelleyerek alıcının ürünü birkaç hafta kullanma fırsatını kaybedeceği ortaya çıktı. İşte bahsettiğimiz şey.
Sadece değil. Programcı mevcut işini bırakmalı ve hatayı yakalamaya başlamalıdır. Ve piyasada birkaç ürünü varsa?
Herkes hemoroid olur.
ama çözüm ne olabilir?
ama çözüm ne olabilir?
çözümü yok.
düzeltmeleri olan yeni bir yapı görünene kadar, ürün boşta kalacak (veya alıcıya bir kayıp veya belki de kar getirecek - kim bilir? - daha sonra terminal hatasını düzelttikten sonra, bir kullanıcı kalabalığı öfkeyle hatayı geri göndermeyi talep edecektir. terminal geri?).
Ürünü kullanırken yeni yapıda herhangi bir hata bulunmazsa, satıcı Market'te ürünün en son sürümle uyumlu olduğunu not eder . Son derlemedeki ürün "başarısız olmaya" başlarsa, işareti koymayız ve kullanıcı yeni bir yapı kurmak için çok erken olduğunu bilir.
Onlar. Satıcının yeni yapılardaki hataları yakalama sorumluluğu hala var mı? Aslında, alıcı ürünü kullanıyor (ve bir hata keşfediyor), sorun MQ'nun hatasından kaynaklanıyor (belirtilen konu dahilinde) ve satıcı suçu üstlenmeli mi?
...
Bir seçenek gibi. Yine de düşünmek gerek...
İdeal olarak, aşağıdaki çözüm görülür (soru, bunun ne kadar uygulanabilir olduğudur):
1- Terminalde güncellemelerin otomatik kurulumu seçeneğinin devre dışı bırakılması, sadece kullanılabilirlik hakkında bir mesaj ve kullanıcının kendisi tarafından karar verilmesi (bu daha önce bir yerde önerildi);
2- terminalde "yapı numarasına geri alma ..." işlevi.
Ardından, yeni bir derlemede bir aksaklıktan kaynaklanan bir EA arızası durumunda, derlemeyle ilgili durum çözülene kadar kolayca geçici önlemler alabilirsiniz. Özellikle dikkatli olanlar, ek bir önlem olarak, güncellemeleri bir izin gününde yükleyebilir ve Uzman Danışmanlarını test cihazında çalıştırabilir. Geçmişi önceki yapıya kıyasla çalışmanın yeterliliği veya yetersizliği konusunda, bir güncelleme-geri alma seçiminde son kararı verin.
Bir danışman geliştirirken (satarken) performansın test edildiği yapı belirtilir.
İdeal olarak, aşağıdaki çözüm görülür (soru, bunun ne kadar uygulanabilir olduğudur):
1- Terminalde güncellemelerin otomatik kurulumu seçeneğinin devre dışı bırakılması, sadece kullanılabilirlik hakkında bir mesaj ve kullanıcının kendisi tarafından karar verilmesi (bu daha önce bir yerde önerildi);
2- terminalde "yapı numarasına geri alma ..." işlevi.
Ardından, yeni bir derlemede bir aksaklıktan kaynaklanan bir EA arızası durumunda, derlemeyle ilgili durum çözülene kadar kolayca geçici önlemler alabilirsiniz. Özellikle dikkatli olanlar, ek bir önlem olarak, güncellemeleri bir izin gününde yükleyebilir ve Uzman Danışmanlarını test cihazında çalıştırabilir. Geçmişi önceki yapıya kıyasla çalışmanın yeterliliği veya yetersizliği konusunda, bir güncelleme-geri alma seçiminde son kararı verin.
Bir danışman geliştirirken (satarken) performansın test edildiği yapı belirtilir.
evet, bana da bu makul bir teklif gibi görünüyor (benzer tol64 tarafından hemen önerildiği gibi).
isteğe bağlı bir yapı kurmak mantıklı bir çıkış yoludur. Satıcıyı ve alıcıyı geliştiricilerden koruyacaktır. :)
Satıcı, ürünü yeni bir yapı üzerinde daha kolay test edebilecek ve gerekirse değişiklikleri ve yeni bir sürümü gönderebilecek.
Platformun geliştiricilerine bir talep - bu konuyu ve özellikle bu teklifi düşünmeleri.
Belki de şirketin sorun ve çözümü hakkında kendi vizyonu vardır?
- Ücretsiz alım-satım uygulamaları
- İşlem kopyalama için 8.000'den fazla sinyal
- Finansal piyasaları keşfetmek için ekonomik haberler
Gizlilik ve Veri Koruma Politikasını ve MQL5.com Kullanım Şartlarını kabul edersiniz
Aslında bu soru uzun zamandır demleniyor.
Durum şu, oldukça gerçek.Yazılımı test eden programcı ve piyasa kontrolü, onu piyasaya sürdü.
Tabii ki bu durumda en can sıkıcı olan şey, şirketten ziyade programcının itibarının zarar görecek olmasıdır. Yapının sorunlarının hala tanımlanması ve kanıtlanması gerektiğinden.Bunun için belirli bir miktar ödeyen alıcı, yeni yapıda bir süre sonra ürünün çalışmayı durdurduğunu keşfeder.
TAMAM. Programcı, sorunun yeni yapıda ortaya çıktığını kontrol etti ve buldu, ancak hatanın bulunduğu yeri belirlemenin ve yerelleştirmenin bir yolu yok.
Şimdi üç taraf ne yapmalı?
Yeni gelişmelere zaten yatırılmış olabilecek alıcıya para iadesi?
Sorunun yapıda olduğunu ve programcının hatası olmadığını söyleyerek alıcıyı terminalin geliştiricilerine gönderin?
Veya başka bir seçenek?
Bu süre zarfında ürün çok sayıda olumsuz yorum alacak ve ürünün raftan kaldırılması gerekebilir.
MQL programcılarının platformun geliştiricilerine bağlı olduğu ortaya çıktı. Ayrıca, yapımdaki herhangi bir hile, itibarlarını henüz tomurcuklanmadan mahvedebilecek veya gelecekteki siparişleri veya diğer planları bozabilecek ölçüde bağımlıdırlar.
Genel olarak, bu durumdan nasıl bir çıkış planlanıyor ve şirket bunu nasıl çözebilir?
not. Şimdiye kadar, iyi haber şu ki, şirket gelişiyor ve Pazarı ve MQL5 ürünlerinin satışını organize ediyor ve destekliyor. Sonuç olarak, kalite için bir mücadele olacak, ancak bunun bedelini itibarı ve rublesi ile kim ödeyecek?