Partkeepr: proses pengembangan versi baru

Tidak ada komitmen yang dibuat sejak 20 Juli 2018. Jadi saya pikir kami tidak membahas ETA untuk rilis berikutnya tetapi ETA untuk pengembang utama baru. Sampai kami memilikinya, kami tidak akan memiliki rilis pasti. Namun saya akan penasaran, seperti apa kondisinya saat ini.

Info proyek terbaru ada di sini: https://www.patreon.com/posts/its-end-for-me-22527966
Dan pada dasarnya proyek tidak memiliki pengelola lagi, tetapi jika ada yang serius ingin mengambilnya, sepertinya mungkin.

Jadi @christianlupus benar, itu sebenarnya ETA sampai pengelola baru.

.

Memiliki 5 pengembang mungkin lebih dari tidak berguna tanpa manajemen proyek yang solid (dan mungkin pendanaan pada tahap ini), proyek dapat bertahan dengan satu atau dua, dan satu-satunya masalah yang dihasilkan mungkin waktu pengembangan.

Satu masalah yang dia tunjukkan cukup jelas: manajemen masalah, dan penanganan orang dengan perilaku buruk.

Proyek ini dapat hidup bahagia dengan dua pengembang, bahkan dengan masalah kesehatan, selama ada orang yang melakukan triase masalah dan manajemen komunitas sehingga pengembang dapat fokus pada tugas tanpa harus khawatir tentang hal-hal lain.

.

PartKeepr akan menggunakan kerangka kerja lain yang argumen yang sama akan berlaku, Symphony sebenarnya bukan kerangka kerja khusus.

Ya itu membutuhkan seseorang yang tahu atau mau mempelajarinya, seperti kerangka kerja lainnya.

Dan ya itu mungkin aplikasi khusus, tetapi konteksnya adalah untuk memperhitungkan, jika Anda tahu simfoni, apakah Anda akan termotivasi untuk bergabung dengan proyek yang tampak mati? mungkin tidak.

.

Apakah itu benar-benar membutuhkan kerangka kerja yang canggih?

Ini tidak lebih maju dari yang lain, itu hanya kerangka kerja, ya Anda dapat menggunakan yang sangat ringan, tetapi pada akhirnya Anda akan menambahkan banyak ekstensi atau membuatnya dari awal untuk hasil yang sama, dan bahkan lebih buruk karena tidak akan didokumentasikan dan diuji sebagai "kerangka kerja lanjutan".

Tetapi memperbaiki solusi tersebut dengan cara yang baik akan membutuhkan banyak desain ulang, mungkin tidak dapat dilakukan dengan kerangka kerja Symphony, atau yang lainnya.

Kami tidak berbicara tentang aplikasi Win32 di sini, dan kecuali Anda memiliki POC untuk membuktikan bahwa itu tidak dapat dilakukan dengan kerangka kerja saat ini, maka itu adalah BS.
Menemukan kembali roda kadang-kadang mungkin berhasil, tetapi itu bukan solusi yang berhasil setiap saat.

Jika Anda mengatakan bahwa "kurva pembelajaran simfoni terlalu curam" bagaimana sesuatu yang dibuat khusus seharusnya lebih baik?

Sekarang mengomel bahwa "simfoni itu buruk dan proyek akan hancur kecuali kita menulis ulang semuanya" tidak akan membuat proyek bergerak lebih jauh, mengerjakan PR dan dengan kontributornya.

.

Jika misalnya saya ingin memiliki kategori dengan spesifikasi kaskade, yang juga mengalir ke komponen dalam kategori tersebut (dengan kemungkinan menimpanya). Dan daripada menunjukkan deskripsi yang diformat dengan baik dari semua spesifikasi gabungan tergantung pada jenis komponen. Apakah sesuatu yang saya harapkan untuk bekerja di Symfony?

Tidak. Tidak ada kerangka kerja yang akan melakukan itu. Saya pikir Anda memiliki kesalahpahaman tentang apa itu kerangka kerja. Implementasi Kategori adalah sesuatu yang khusus untuk aplikasi, dan tidak ada kerangka kerja umum yang akan menanganinya.

Saya tidak berpikir Symphony atau kerangka kerja lainnya buruk. Tetapi dalam kasus bagaimana saya ingin Sistem Manajemen Inventaris terlihat, mereka sangat tidak mungkin untuk melakukan pemotongan. Itu tidak berbicara tentang BS, tetapi pemahaman yang baik tentang kompleksitas yang terlibat.

Apa sih hubungannya dengan kerangka kerja dengan aplikasi tertentu bekerja? Kerangka kerja apa pun tidak memiliki pemahaman tentang cara kerja aplikasi. Ini memberikan skema, filosofi, dan model untuk dibangun.

Catatan tambahan: Ya, saya masih harus memberikan hak akses repositori kepada seseorang, sayangnya saya cukup sibuk dengan likuidasi PartKeepr UG. Saya harap saya segera mengatasinya

.

Hai Felicia,

Pemahaman saya tentang Symphony sebagai kerangka kerja -seperti yang dikatakan- terbatas. Tetapi misalnya jika membuat tampilan UI dengan membaca langsung dari tabel, kueri, cukup sulit untuk menampilkan informasi yang ditautkan dengan cara lanjutan satu sama lain.

Dalam hal ini, mungkin lebih baik membaca apa yang disediakan Symfony dan apa yang tidak, daripada membuat asumsi yang salah. Tidak ada tampilan UI yang dihasilkan oleh Symfony, setidaknya tidak di PartKeepr.

Kaskade dan informasi yang diwarisi yang diusulkan sulit untuk ditanyakan dan karenanya sulit untuk diproses oleh kerangka kerja (didorong tabel), atau apakah saya salah paham?

Ya, Anda salah paham. Symfony tidak menyediakan hal-hal seperti itu, mungkin melalui beberapa bundel pihak ke-3, tetapi sekali lagi, PartKeepr tidak menggunakan bundel seperti itu. Symfony terutama digunakan untuk arsitektur pengontrol, fitur serialisasi (yang, bersama, menggunakan platform API untuk menghasilkan JSON-LD yang kemudian dapat dibaca oleh frontend) dan Doctrine untuk semua hal terkait database.

Lihat https://wiki.partkeepr.org/wiki/Developers/Architecture

.

Hai Felicia,

Terima kasih telah menanggapi. Saya telah memprogram banyak hal, bahkan teknologi web di masa-masa awalnya. Tapi itu sangat kurang dalam memahami arsitektur PartKeepr. Juga berbagai teknologi yang digunakan sulit dipahami sebagai pengembang Windows. Seperti yang saya katakan, kurva belajarnya terlalu curam. Tapi pertanyaan mendasarnya masih bisa valid. Apa tujuan pengembangan, dan dapatkah itu dicapai dengan teknologi yang digunakan. Terlepas dari bagaimana mereka dipanggil.

Alasan untuk menggunakan kerangka kerja, terutama kerangka kerja yang banyak digunakan, diadopsi, dan dipelihara seperti Symfony2:

• Hindari duplikasi kode
• Tingkatkan keandalan
• Jangan menemukan kembali roda
• Tingkatkan rawatan
• Kurangi pekerjaan

Hingga PartKeepr 0.1.9, tidak menggunakan kerangka kerja selain Doctrine untuk ketekunan (Symfony2 tidak ada saat itu). Pemeliharaan adalah mimpi buruk.

Alasan mengapa tidak ada injeksi SQL di PartKeepr adalah karena Doctrine. Alasan mengapa ada begitu banyak fitur baru setelah 0.1.9 dalam waktu singkat adalah Symfony2 dan platform API karena overhead pengembangan yang sangat rendah. Alasan mengapa PartKeepr bekerja di belakang proxy terbalik tanpa saya menulis kode nol untuk mendukungnya: Symfony2. Alasan mengapa PartKeepr bekerja di nginx tanpa modifikasi kode apa pun: Symfony2.

Jika Anda kesulitan memahami cara kerja Symfony2, tidak masalah: Ada banyak sumber daya di web untuk membantu Anda.

Jika PartKeepr memang menggunakan kerangkanya sendiri, Anda akan sangat mandiri, bahkan untuk fungsionalitas paling dasar. Baru-baru ini saya melihat The Bug Genie sebagai pelacak masalah, dan itu tidak menggunakan kerangka kerja sama sekali - semuanya ditulis sendiri. Saya mengirimkan tidak kurang dari 8 permintaan tarik untuk memperbaiki bug yang saya temui selama penggunaan normal. Setelah menemukan setengah lusin bug lagi (dan saya hanya menggunakan perangkat lunak selama mungkin 30 menit selama sebulan), saya berhenti menggunakannya.

Saya pikir Anda mungkin orang terbaik untuk memberikan jawaban mengapa proyek ini hanya memiliki sedikit dukungan pengembangan. Dan jika itu bisa diperbaiki.

Saya hanya bisa menebak: Basis pengguna yang relatif kecil dan saya memenuhi terlalu banyak permintaan fitur. Itu berhasil di luar kotak untuk sebagian besar pengguna, jadi mengapa pengguna ini mulai berkontribusi kode?

Pertanyaan yang saya ajukan pada diri sendiri adalah: apakah saya akan senang berpartisipasi dalam proyek bersama? Apakah itu akan mendapat manfaat dari pengalaman saya? Apakah lebih banyak orang berbagi tujuan saya? Bagaimana interaksi antara pengembang terlihat.

Kecuali jika Anda bersedia mempelajari cara kerja proyek perangkat lunak dan teknologi yang mendasarinya, tidak banyak. Melangkah dan mengeluh tentang pilihan kerangka kerja adalah langkah pertama yang sangat buruk.

Saya tidak akan berpartisipasi dalam proyek atau koordinasi pengembangan apa pun dalam proyek ini.

saat ini saya mencoba memperbarui ke symfony 3.4. jika saya membuat beberapa kemajuan, saya akan memberikan pembaruan

Hai @JelleDijkhuizen
Apakah Anda memiliki berita tentang migrasi symfony 3.x? Jika Anda telah melakukan pekerjaan ini, bisakah Anda memberi tahu saya di mana saya dapat menemukan garpu Anda? Terima kasih sebelumnya!

@martonmiklos , sepertinya @adlerweb mencoba memutakhirkan PartKeepr ke Symphony 4 di cabang khusus garpunya... :-)

@ZupoLlask terima kasih atas perhatiannya!

Saya pikir diskusi ini panjang dan masalah utama sudah selesai. Lihat #1059. Jadi, saya akan menutup ini untuk saat ini.