Çalışma bölümündeki kurallar - sayfa 4
Ticaret fırsatlarını kaçırıyorsunuz:
- Ücretsiz ticaret uygulamaları
- İşlem kopyalama için 8.000'den fazla sinyal
- Finansal piyasaları keşfetmek için ekonomik haberler
Kayıt
Giriş yap
Gizlilik ve Veri Koruma Politikasını ve MQL5.com Kullanım Şartlarını kabul edersiniz
Hesabınız yoksa, lütfen kaydolun
... Sonra eklediler: "Nasıl doğru bilmiyorum ama ben şahsen TK'nin ikincil olduğunu ve sadece sözleşmenin (uygulamanın) bir eki olduğunu düşünüyorum". Hangisine yorum yaptım, yorum yapılan ifadelerin vurgulanmasıyla . Yorumun özü: belirli koşullar karşılanırsa, TK kendi kendine yeterli hale gelebilir (terminolojinizde birincil). Eh, bu arada, sonuçta anlaşmazlık için bir konu yok :)
Yani gerçek hayatta, bir anlaşma / sözleşme gerçekten birincildir, anlaşmasız bir TK ile hiç tanışmadım (aynı zamanda, genellikle TK'de sadece teknik bilgi vardır ve anlaşmada yasal ilişkilerin ana özü vardır). partiler).
Şahsen ben bu diziye alışkınım:
1. işin ifasına ilişkin sözleşme/sözleşme (müşterinin, yüklenicinin, yapılan işin esasının, işin yapılması için son tarihlerin, müşterinin yükleniciye ödediği tutarın, yüklenicinin sorumluluğunda olduğu). taraflar ve gerekirse ek bilgiler) belirtilir;
2. Görevin kendisini daha ayrıntılı olarak açıklayan ve gerçekleştirilen işin belirli özelliklerini sağlayan TOR (aynı zamanda müşteri, TOR'da nelerin bulunduğunu tam olarak anlamak zorunda değildir);
3. Bitirme belgesi;
4. İş veya aşaması için ödeme.
Aşağıdakilere dayanarak, normal şartlar altında, sözleşmenin (uygulamayı okuyun) TOR'dan daha yüksek bir statüye sahip olduğuna inanıyorum (TOR, işin ayrıntılı detayları veya belirli bir aşama ile sözleşme temelinde oluşturulur).
Bizim durumumuzda geliştiricilerin (hizmet düzenleyicileri olarak) uygulamanın içeriğine daha ayrıntılı yaklaşmaları ve onu gerçek bir sözleşmeye yaklaştırmaları gerektiğini düşünüyorum.
Yüklenicinin Görev Tanımını bağımsız olarak hazırlaması ve müşterinin de kabul etmesi durumunda, Yüklenicinin belirli bir miktarı (tam olarak veya siparişin yüzdesi olarak belirtilir) almasına izin vererek Görev Tanımı oluşturma sürecini vurgulamak da faydalı olabilir.
pronych :
А вообще, проще всего не мудрить с правилами, а просто, при вводе заявки добавить "снятую" галку, типа "хочу исходники" и отражать это в списке заданий. кому надо, тот отметит флажок. небольшой апдейт, а как приятно. и всем всё сразу понятно будет.
Bu, sorunun bir kısmını çözmenin teknik yönüdür. Aslında, Başvuruyu doldurma aşamasında Müşterilerin "nihai dosyanın türüne karar vermeleri" için bir gereklilik ortaya koydunuz. Buna göre, Müşteriler için böyle bir gereklilik (resmi bir bakış açısından) Kurallara yansıtılmalıdır. Müşterilerin kendilerinden ne istendiğini anlamaları için.
Ayrıca, Yüklenici (kendi çıkarları doğrultusunda) Başvuruyu görünce sakinleşmemeli, bu konuda doğrudan İş Tanımı'nda anlaşmaya varmalıdır.
Genel olarak, en kolay yol, kurallar konusunda akıllı olmak değil, sadece bir uygulamaya girerken, "Kaynak kodları istiyorum" gibi bir "kaldırıldı" onay kutusu eklemek ve bunu görev listesine yansıtmaktır. ihtiyacı olan kişi kutuyu işaretleyecektir. küçük bir güncelleme ama ne güzel. ve her şey hemen herkes için netleşecek.
Benim düşünceme göre, "uygulamanın" kendisinin daha ayrıntılı olarak elden geçirilmesi gerekiyor. Sadece olması değil, çok daha fazlası olmalı. Örneğin, sanatçının gelecekte algoritma ve program kodu kullanmasına izin veren / yasaklayan koşulları da işaretleyebilirsiniz.
Her ne kadar böyle şeyleri kontrol etmenin çok zor olduğunu anlasam da.
not
Mesele şu ki, anladığım kadarıyla, MAĞAZA'nın aksine, hiç kimse müşteriyi işi kopyalamak için rahatsız etmiyor (özellikle bir kaynak kodu varsa) ve sanatçı onu mağazaya kolayca koyabilir veya başka bir müşteriye yeniden satabilir.
Bu, sorunun bir kısmını çözmenin teknik yönüdür. Aslında, Başvuruyu doldurma aşamasında Müşterilerin "nihai dosyanın türüne karar vermeleri" için bir gereklilik ortaya koydunuz. Buna göre, Müşteriler için böyle bir gereklilik (resmi bir bakış açısından) Kurallara yansıtılmalıdır. Kendilerinden ne istendiğini anlamaları için.
Ayrıca, Yüklenici (kendi çıkarları doğrultusunda) Başvuruyu görünce sakinleşmemeli, bu konuda doğrudan İş Tanımı'nda anlaşmaya varmalıdır.
Kesin olmak gerekirse, burada belirli bir seçim uzlaşımı yapmak oldukça gereklidir. Müşteri kesinlikle kaynak koduna ihtiyaç duyuyorsa, bu konuda hiçbir şey yapılamaz, aksi takdirde sanatçının bir seçeneği olacaktır.
Aynı zamanda müşteri, kaynak kodunun ve çalışmanın (varsa) münhasırlığının ekstra paraya mal olacağını anlamalıdır.
Dikkatli düşününce öyle düşünüyorum. Bir programcı müşterinin özelliklerine göre bir şey yazarsa, kaynak kodunu da kendisine aktarması gerekir. İlk olarak, geliştiricilerin hiçbir yeni yapının yeniden derleme gerektirmeyeceğini söylemeleri pek olası değildir. İkincisi, tartışmalı konuların çözülmesi gerekiyor. TOR'un yanlış formüle edilmiş olması, yanlış anlaşılması veya programcının basitçe bir hata yapması mümkündür. İlk durumda, müşteri yeni TOR üzerindeki çalışma için tekrar ödeme yapmalı veya programcıyı yalnız bırakmalıdır. İkinci ve üçüncü - programcı pervazlarını ücretsiz olarak tamir etmelidir. Kaynak kodu olmadan kimin haklı olduğu nasıl anlaşılır?
Müşteriye aktarılamayan kaynak kodda gerçekte ne var? İyi bir ticaret fikri, yani teknik özellikler, bazı programlama sırlarından çok daha değerlidir.
Kendi fikirlerinize göre yazılmış bir yazılım satıyorsanız, kaynak kodunu aktarmanız söz konusu değildir.
Aşağıdakilere dayanarak, normal şartlar altında sözleşmenin (uygulamayı okuyun) ...
Burada temel bir hata var. Sözleşme, iki veya daha fazla kişi arasında yapılan bir anlaşmadır. Bir başvuru, tek başına bir sözleşme olarak kabul edilemeyen, yalnızca bir tarafın teklifidir. Tartışılan Kuralların özüne dayanarak, sözleşmeye dayalı ilişkilerin ortaya çıkması (bir sözleşmenin imzalanması) ancak İş Tanımı'nın uygulanmasından sonra değerlendirilebilir. Her iki tarafça mutabık kalınan işin tüm detaylarını yansıtması amaçlanan İş Tanımı'dır.
... Sözleşme-TK bağlantısına tanımladığınız yaklaşıma klasik bir yaklaşım denilebilir; bu, ortaya çıkan sözleşme ilişkilerinin çözülmesinin diğer eşit biçimlerinin varlığını hiçbir şekilde iptal etmez. Mecazi olarak, Rusya Federasyonu Medeni Kanunu'nun 36. Bölümü "Sözleşme", genel ve korunan üyeleri, sanal işlevleri olan bir üst sınıftır ve İş Tanımı, olası alt sınıflardan biridir. :)
Interesting :
Bu, sorunun bir kısmını çözmenin teknik yönüdür. Aslında, Başvuruyu doldurma aşamasında Müşterilerin "nihai dosyanın türüne karar vermeleri" için bir gereklilik ortaya koydunuz. Buna göre, Müşteriler için böyle bir gereklilik (resmi bir bakış açısından) Kurallara yansıtılmalıdır. Müşterilerin kendilerinden ne istendiğini anlamaları için.
Ayrıca, Yüklenici (kendi çıkarları doğrultusunda) Başvuruyu görünce sakinleşmemeli, bu konuda doğrudan İş Tanımı'nda anlaşmaya varmalıdır.
Kesin olmak gerekirse, burada belirli bir seçim uzlaşımı yapmak oldukça gereklidir. Müşteri kesinlikle kaynak koduna ihtiyaç duyuyorsa, bu konuda hiçbir şey yapılamaz, aksi takdirde sanatçının bir seçeneği olacaktır.
Aynı zamanda müşteri, kaynak kodunun ve çalışmanın (varsa) münhasırlığının ekstra paraya mal olacağını anlamalıdır.
Dikkatli düşününce öyle düşünüyorum. Bir programcı müşterinin özelliklerine göre bir şey yazarsa, kaynak kodunu da kendisine aktarması gerekir.
Müşteriye aktarılamayan kaynak kodda gerçekte ne var? İyi bir ticaret fikri, yani teknik özellikler, bazı programlama sırlarından çok daha değerlidir.
Kendi fikirlerinize göre yazılmış bir yazılım satıyorsanız, kaynak kodunu aktarmanız söz konusu değildir.
Kaynak kodu, bir dizi ek özellik, sınıf vb. ile iyi tasarlanmış bir şablon olabilir. Bir grup bloktan oluşabilir (örneğin içerir) ve yalnızca içindeki bazı koşullar farklılık gösterebilir. Sadece sinyal modülünün farklı olduğu bir sistemin (birbirleriyle etkileşim anlamında sistemler) bir düzine farklı dosyadan kaynak kodlarında yarım yıllık (basit bir durumda) çalışma süresi vermeye hazır mısınız ( bir sınıf (dosya))?
Damaların kesişimini kesmek için standart yöntemler kullanabileceğinizi anlıyorum ve bu üzücü değil. Ve eğer şablona muazzam bir iş yatırılırsa, o zaman nasıl? Hayır, hazır mısın?
Dikkatli düşününce öyle düşünüyorum. Bir programcı müşterinin özelliklerine göre bir şey yazarsa, kaynak kodunu da kendisine aktarması gerekir. İlk olarak, geliştiricilerin hiçbir yeni yapının yeniden derleme gerektirmeyeceğini söylemeleri pek olası değildir. İkincisi, tartışmalı konuların çözülmesi gerekiyor. TOR'un yanlış formüle edilmiş olması, yanlış anlaşılması veya programcının basitçe bir hata yapması mümkündür. İlk durumda, müşteri yeni TOR üzerindeki çalışma için tekrar ödeme yapmalı veya programcıyı yalnız bırakmalıdır. İkinci ve üçüncü - programcı pervazlarını ücretsiz olarak tamir etmelidir. Kaynak kodu olmadan kimin haklı olduğu nasıl anlaşılır?
Müşteriye aktarılamayan kaynak kodda gerçekte ne var? İyi bir ticaret fikri, yani teknik özellikler, bazı programlama sırlarından çok daha değerlidir.
Kendi fikirlerinize göre yazılmış bir yazılım satıyorsanız, kaynak kodunu aktarmanız söz konusu değildir.
1. Kaynak kodlarının zorunlu aktarımı, yalnızca yapılan iş özel ise uygundur, anladığınız gibi fiyat farklı olacaktır (belki de birçok kez daha).
Yeniden derleme sorunu da en baştan çözülebilir.
2. TK Hakkında
Şey, Forex'te "iyi" bir yazılım uygulamasından daha pahalıya mal olacak "iyi" fikirler görmedim.
Soruyu şu şekilde cevaplayacağım - Kaynak kodda, müşterinin telif hakkı sahibi olduğunu iddia etmesine ve kodla her şeyi yapabilmesine (örneğin satmasına) izin veren bir olasılık var.
Bu nedenle, büyük olasılıkla yapılan çalışmanın münhasırlığından bahsediyoruz (ve burada kaynak kodunu dağıtmak istemeyen programcıları destekliyorum).