Partkeepr: عملية تطوير النسخة الجديدة

تم إنشاؤها على ٢٥ يناير ٢٠١٩  ·  20تعليقات  ·  مصدر: partkeepr/PartKeepr

"ETA" للإصدار الجديد من partkeepr :)؟ يعرف شخص ما شيئًا عنه أو أن المشروع مغلق بالفعل. أنا مجرد فضول

التعليق الأكثر فائدة

مرحبا فيليسيا ،

شكرا للرد. لقد قمت ببرمجة الكثير من الأشياء ، حتى تكنولوجيا الويب في أيامها الأولى. لكن هذا يفتقر تمامًا إلى ما يتعلق بفهم بنية PartKeepr. كما يصعب فهم التقنيات المختلفة المستخدمة كمطور Windows. كما قيل لي ، فإن منحنى التعلم شديد الانحدار. لكن السؤال الأساسي يمكن أن يظل صالحًا. ما هي أهداف التنمية ، وهل يمكن الوصول إليها بالتقنيات المستخدمة. بغض النظر عن كيف يتم استدعاؤها.

أسباب استخدام إطار العمل ، خاصةً إطار العمل المستخدم على نطاق واسع والمعتمد والمحافظة عليه مثل Symfony2:

  • تجنب تكرار الكود
  • زيادة الموثوقية
  • لا تعيد اختراع العجلة
  • زيادة قابلية الصيانة
  • تقليل العمل

حتى PartKeepr 0.1.9 ، لم يستخدم إطار عمل بعيدًا عن Doctrine للاستمرار (لم يكن Symfony2 موجودًا في ذلك الوقت). كانت الصيانة كابوسا.

السبب في عدم وجود حقن SQL في PartKeepr هو العقيدة. كان السبب وراء وجود العديد من الميزات الجديدة بعد 0.1.9 في فترة زمنية قصيرة هو Symfony2 ومنصة واجهة برمجة التطبيقات نظرًا لانخفاض تكاليف التطوير. السبب وراء عمل PartKeepr خلف وكيل عكسي بدون كتابة كود صفري لدعمه: Symfony2. سبب عمل PartKeepr على nginx بدون أي تعديل في الكود: Symfony2.

إذا كنت تواجه مشكلة في فهم كيفية عمل Symfony2 ، فلا مشكلة: هناك الكثير من الموارد على الويب لمساعدتك.

إذا استخدم PartKeepr إطار العمل الخاص به ، فستكون بمفردك كثيرًا ، حتى بالنسبة للوظائف الأساسية. ألقيت مؤخرًا نظرة على The Bug Genie باعتباره أداة تعقب المشكلات ، ولا يستخدم إطارًا على الإطلاق - كل شيء مكتوب ذاتيًا. لقد قدمت ما لا يقل عن 8 طلبات سحب لإصلاح الأخطاء التي واجهتها أثناء الاستخدام العادي. بعد مواجهة نصف دزينة من الأخطاء (وأنا لم أستخدم البرنامج إلا لمدة 30 دقيقة تقريبًا على مدار شهر) ، توقفت عن استخدامه.

أعتقد أنك ربما تكون أفضل شخص يعطي إجابة عن سبب قلة دعم هذا المشروع للتنمية. وإذا كانت قابلة للإصلاح.

لا يسعني إلا أن أخمن: قاعدة مستخدمين صغيرة نسبيًا وقد استوفيت العديد من طلبات الميزات. لقد نجح الأمر خارج الصندوق بالنسبة لغالبية المستخدمين ، فلماذا يبدأ هؤلاء المستخدمون في المساهمة بكود؟

الأسئلة التي أطرحها على نفسي هي: هل سأستمتع بالمشاركة في مشروع مشترك؟ هل ستستفيد من تجربتي؟ هل يشارك المزيد من الناس أهدافي؟ كيف ستبدو التفاعلات بين المطورين.

ما لم تكن على استعداد لتعلم كيفية عمل مشروع برمجي والتقنيات الأساسية ، ليس كثيرًا. يعتبر التصعيد والشكوى من اختيار إطار العمل خطوة أولى سيئة للغاية.

لن أشارك في أي مشروع أو تنسيق تطوير في هذا المشروع.

ال 20 كومينتر

لم يتم تقديم أي التزامات منذ 20 يوليو 2018. لذلك أعتقد أننا لا نناقش ETA للإصدار التالي ولكن ETA لمطور رئيسي جديد. حتى يكون لدينا واحد ، لن يكون لدينا أي إصدارات بالتأكيد. ومع ذلك ، سأكون فضوليًا ، ما هو الوضع الحالي.

أحدث معلومات المشروع هنا: https://www.patreon.com/posts/its-end-for-me-22527966
وبصورة أساسية ، لم يعد للمشروع مشرف بعد الآن ، ولكن إذا أراد أي شخص جاد أن يأخذها ، يبدو ذلك ممكنًا.

إذن christianlupus محق ، إنها في الواقع ETA حتى مشرف جديد.

.

من المحتمل أن يكون وجود 5 مطورين عديم الفائدة بدون إدارة مشروع قوية (وربما تمويل في هذه المرحلة) ، يمكن أن يستمر المشروع بواحد أو اثنين ، وقد تكون المشكلة الوحيدة الناتجة هي وقت التطوير.

إحدى القضايا التي أشارت إليها واضحة جدًا: إدارة المشكلات والتعامل مع الأشخاص ذوي السلوك السيئ.

يمكن أن يعيش المشروع بسعادة مع اثنين من المطورين ، حتى مع وجود مشكلة صحية ، طالما أن هناك أشخاصًا يقومون بفرز المشكلات وإدارة المجتمع بحيث يمكن للمطورين التركيز على مهمة دون الحاجة إلى القلق بشأن الأشياء الأخرى.

.

كان من الممكن أن يستخدم PartKeepr إطار عمل آخر ستطبق نفس الحجة ، Symphony ليس في الحقيقة إطار عمل متخصص.

نعم ، إنها بحاجة إلى شخص يعرفها أو يرغب في تعلمها ، مثل أي إطار عمل آخر.

ونعم ، قد يكون تطبيقًا متخصصًا ، ولكن يجب أن يأخذ السياق بعين الاعتبار ، إذا كنت تعرف السيمفونية ، فهل سيكون لديك الدافع للانضمام إلى مشروع ميت؟ على الاغلب لا.

.

هل تحتاج حقًا إلى إطار عمل متقدم خارج الرف؟

إنه ليس أكثر تقدمًا من الآخر ، إنه مجرد إطار عمل ، نعم يمكنك استخدام إطار خفيف جدًا ، لكن في نهاية اليوم ستكون قد أضفت الكثير من الإضافات أو صنعتها من الصفر لنفس النتيجة ، وحتى أسوأ لأنه لن يتم توثيقه واختباره مثل "إطار عمل متقدم خارج الرف".

لكن إصلاح هذه الحلول بطريقة لطيفة سيحتاج إلى الكثير من إعادة التصميم ، وربما لا يكون ذلك ممكنًا مع إطار عمل Symphony ، أو أي إطار آخر جاهز.

نحن لا نتحدث عن تطبيقات Win32 هنا ، وما لم يكن لديك POC لإثبات أنه لا يمكن تنفيذه مع إطار العمل الحالي ، فهو BS.
قد تنجح إعادة اختراع العجلة في بعض الأحيان ولكن هذا ليس حلاً يعمل في كل مرة.

إذا قلت أن "منحنى تعلم السمفونية شديد الانحدار" فكيف من المفترض أن يكون الشيء المصنوع حسب الطلب أفضل؟

الآن الصراخ بأن "السمفونية سيئة وأن المشروع محكوم عليه بالفشل ما لم نعيد كتابة كل شيء" لن يجعل المشروع يتحرك أبعد من ذلك ، والعمل على العلاقات العامة ومع المساهمين.

.

على سبيل المثال ، إذا كنت أرغب في الحصول على فئات بمواصفات متتالية ، والتي تتتالي أيضًا إلى مكونات ضمن هذه الفئة (مع إمكانية تجاوزها). وبدلًا من إظهار وصف منسق بشكل جيد لجميع المواصفات المجمعة اعتمادًا على نوع المكون. هل من شيء يجب أن أتوقع أن أعمل في Symfony؟

لا ، لا يوجد إطار عمل يقوم بذلك. أعتقد أن لديك سوء فهم لما هو إطار العمل. يعد تنفيذ الفئات شيئًا خاصًا بالتطبيق ، ولن يتعامل أي إطار عام مع ذلك مطلقًا.

لا أعتقد أن Symphony أو أطر أخرى سيئة. ولكن في حالة كيف أود أن يبدو نظام إدارة المخزون ، فمن غير المرجح أن يقوموا بالتخفيض. هذا لا يتحدث BS ، ولكن فهم جيد للتعقيد الذي ينطوي عليه الأمر.

ما هيك لديه إطار عمل لعمل تطبيق معين؟ لا يفهم أي إطار عمل كيفية عمل التطبيق. يوفر مخططًا وفلسفة ونموذجًا للبناء عليه.

ملاحظة إضافية: نعم ، لا يزال يتعين علي تمرير حقوق الوصول إلى المستودع إلى شخص ما ، ولسوء الحظ أنا مشغول جدًا بتصفية PartKeepr UG. آمل أن أحصل على ذلك قريبًا

.

مرحبا فيليسيا ،

إن فهمي لـ Symphony كإطار عمل محدود - كما قيل. ولكن على سبيل المثال ، إذا كانت تقوم بإنشاء طرق عرض لواجهة المستخدم من خلال القراءة مباشرة من الجداول والاستعلامات ، فمن الصعب جدًا إظهار المعلومات المرتبطة بطريقة متقدمة ببعضها البعض.

في هذه الحالة ، قد يكون من الأفضل قراءة ما تقدمه Symfony وما لا تقدمه ، بدلاً من وضع افتراضات خاطئة. لا توجد طرق عرض لواجهة المستخدم تم إنشاؤها بواسطة Symfony ، على الأقل ليس في PartKeepr.

يصعب الاستعلام عن المعلومات المتتالية والموروثة المقترحة ، وبالتالي يصعب معالجتها بشكل مناسب من خلال إطار عمل (مدفوع بالجدول) ، أم أنني أسأت فهم الأشياء؟

نعم ، أنت تسيء فهم الأشياء. لا يوفر Symfony مثل هذه الأشياء ، ربما عبر بعض حزم الجهات الخارجية ، ولكن مرة أخرى ، لا يستخدم PartKeepr مثل هذه الحزمة. تُستخدم Symfony بشكل أساسي لهندسة وحدة التحكم ، وميزات التسلسل (والتي تستخدم ، جنبًا إلى جنب ، منصة API لإنشاء JSON-LD والتي يمكن قراءتها بعد ذلك بواسطة الواجهة الأمامية) والمبدأ لجميع العناصر المتعلقة بقاعدة البيانات.

انظر https://wiki.partkeepr.org/wiki/Developers/Architecture

.

مرحبا فيليسيا ،

شكرا للرد. لقد قمت ببرمجة الكثير من الأشياء ، حتى تكنولوجيا الويب في أيامها الأولى. لكن هذا يفتقر تمامًا إلى ما يتعلق بفهم بنية PartKeepr. كما يصعب فهم التقنيات المختلفة المستخدمة كمطور Windows. كما قيل لي ، فإن منحنى التعلم شديد الانحدار. لكن السؤال الأساسي يمكن أن يظل صالحًا. ما هي أهداف التنمية ، وهل يمكن الوصول إليها بالتقنيات المستخدمة. بغض النظر عن كيف يتم استدعاؤها.

أسباب استخدام إطار العمل ، خاصةً إطار العمل المستخدم على نطاق واسع والمعتمد والمحافظة عليه مثل Symfony2:

  • تجنب تكرار الكود
  • زيادة الموثوقية
  • لا تعيد اختراع العجلة
  • زيادة قابلية الصيانة
  • تقليل العمل

حتى PartKeepr 0.1.9 ، لم يستخدم إطار عمل بعيدًا عن Doctrine للاستمرار (لم يكن Symfony2 موجودًا في ذلك الوقت). كانت الصيانة كابوسا.

السبب في عدم وجود حقن SQL في PartKeepr هو العقيدة. كان السبب وراء وجود العديد من الميزات الجديدة بعد 0.1.9 في فترة زمنية قصيرة هو Symfony2 ومنصة واجهة برمجة التطبيقات نظرًا لانخفاض تكاليف التطوير. السبب وراء عمل PartKeepr خلف وكيل عكسي بدون كتابة كود صفري لدعمه: Symfony2. سبب عمل PartKeepr على nginx بدون أي تعديل في الكود: Symfony2.

إذا كنت تواجه مشكلة في فهم كيفية عمل Symfony2 ، فلا مشكلة: هناك الكثير من الموارد على الويب لمساعدتك.

إذا استخدم PartKeepr إطار العمل الخاص به ، فستكون بمفردك كثيرًا ، حتى بالنسبة للوظائف الأساسية. ألقيت مؤخرًا نظرة على The Bug Genie باعتباره أداة تعقب المشكلات ، ولا يستخدم إطارًا على الإطلاق - كل شيء مكتوب ذاتيًا. لقد قدمت ما لا يقل عن 8 طلبات سحب لإصلاح الأخطاء التي واجهتها أثناء الاستخدام العادي. بعد مواجهة نصف دزينة من الأخطاء (وأنا لم أستخدم البرنامج إلا لمدة 30 دقيقة تقريبًا على مدار شهر) ، توقفت عن استخدامه.

أعتقد أنك ربما تكون أفضل شخص يعطي إجابة عن سبب قلة دعم هذا المشروع للتنمية. وإذا كانت قابلة للإصلاح.

لا يسعني إلا أن أخمن: قاعدة مستخدمين صغيرة نسبيًا وقد استوفيت العديد من طلبات الميزات. لقد نجح الأمر خارج الصندوق بالنسبة لغالبية المستخدمين ، فلماذا يبدأ هؤلاء المستخدمون في المساهمة بكود؟

الأسئلة التي أطرحها على نفسي هي: هل سأستمتع بالمشاركة في مشروع مشترك؟ هل ستستفيد من تجربتي؟ هل يشارك المزيد من الناس أهدافي؟ كيف ستبدو التفاعلات بين المطورين.

ما لم تكن على استعداد لتعلم كيفية عمل مشروع برمجي والتقنيات الأساسية ، ليس كثيرًا. يعتبر التصعيد والشكوى من اختيار إطار العمل خطوة أولى سيئة للغاية.

لن أشارك في أي مشروع أو تنسيق تطوير في هذا المشروع.

أحاول حاليًا التحديث إلى symfony 3.4. إذا أحرزت بعض التقدم ، فسأقدم تحديثًا

مرحباJelleDijkhuizen
هل لديك أي أخبار عن ترحيل symfony 3.x؟ إذا كنت قد أنجزت أي عمل في هذا الشأن ، هل يمكنك السماح لي بمعرفة أين يمكنني العثور على الشوكة الخاصة بك؟ شكرا لك مقدما!

martonmiklos ، يبدو أن adlerweb يحاول ترقية PartKeepr إلى Symphony 4 في فرع مخصص من مفترقه ... :-)

ZupoLlask شكرا على

أعتقد أن هذه المناقشة كانت مطولة وتم توضيح القضية الرئيسية. انظر # 1059. لذا ، سأغلق هذا الآن.

هل كانت هذه الصفحة مفيدة؟
0 / 5 - 0 التقييمات