Partkeepr: процесс разработки новой версии

Никаких коммитов не было сделано с 20 июля 2018 года. Поэтому я думаю, что мы обсуждаем не ETA до следующего релиза, а ETA новому основному разработчику. Пока он у нас не будет, у нас точно не будет никаких релизов. Однако мне было бы любопытно, каково текущее состояние.

Последняя информация о проекте здесь: https://www.patreon.com/posts/its-end-for-me-22527966
И в основном у проекта больше нет сопровождающего, но если кто-то серьезно захочет этим заняться, это кажется возможным.

Итак, @christianlupus прав, на самом деле это ETA до нового сопровождающего.

.

Наличие 5 разработчиков, вероятно, более чем бесполезно без надежного управления проектом (и, вероятно, финансирования на данном этапе), проект может выжить с одним или двумя, и единственной возникающей проблемой может быть время разработки.

Одна проблема, на которую она указала, довольно ясна: управление проблемами и обращение с людьми с плохим поведением.

Проект может счастливо жить с двумя разработчиками, даже если есть проблемы со здоровьем, пока есть люди, которые занимаются сортировкой проблем и управлением сообществом, чтобы разработчики могли сосредоточиться на задаче, не беспокоясь о других вещах.

.

PartKeepr использовал бы еще один фреймворк, как и тот же аргумент, Symphony на самом деле не является какой-то нишевой фреймворком.

Да, ему нужен кто-то, кто знает или готов изучить его, как и любой другой фреймворк.

И да, это может быть нишевое приложение, но следует учитывать контекст: если бы вы знали симфонию, были бы вы мотивированы присоединиться к кажущемуся мертвым проекту? возможно нет.

.

Неужели ему действительно нужна продвинутая готовая структура?

Он не более продвинутый, чем другой, это просто фреймворк, да, вы можете использовать очень легкий, но в конце концов вы добавите тонны расширений или сделаете их с нуля для того же результата, и даже хуже, потому что он не будет так документирован и протестирован, как «продвинутый готовый фреймворк».

Но исправление этих обходных путей потребует значительного изменения дизайна, что, вероятно, невозможно с помощью фреймворка Symphony или любых других готовых решений.

Мы не говорим здесь о приложениях Win32, и если у вас нет POC, чтобы доказать, что это не работает с текущей структурой, тогда это BS.
Иногда может сработать изобретение колеса, но это решение работает не всегда.

Если вы скажете, что «кривая обучения симфонии слишком крутая», то чем же должна быть сделанная на заказ вещь лучше?

Теперь разглагольствования о том, что «симфония - это плохо, и проект обречен, если мы все не перепишем», не заставят проект двигаться дальше, в отличие от работы с PR и участниками.

.

Если, например, я хотел бы иметь категории с каскадными спецификациями, которые также каскадируются к компонентам в такой категории (с возможностью их переопределения). И чем показать красивое отформатированное описание всех объединенных спецификаций в зависимости от типа компонента. Должен ли я ожидать, что что-то будет работать в Symfony?

Нет. Никакой фреймворк этого не сделает. Я думаю, вы неправильно понимаете, что такое фреймворк. Реализация категорий зависит от конкретного приложения, и никакая универсальная структура никогда с этим не справится.

Я не думаю, что Symphony или другие фреймворки плохие. Но в том случае, если бы я хотел, чтобы система управления запасами выглядела, они вряд ли смогут помочь. Это не чушь, а хорошее понимание всей сложности.

Какого черта имеет фреймворк для работы конкретного приложения? Ни один фреймворк не понимает, как работает приложение. Он предоставляет схему, философию и модель, на которых можно опираться.

Дополнительное примечание: Да, мне все еще нужно передать кому-то права доступа к репозиторию, к сожалению, я очень занят ликвидацией PartKeepr UG. Я надеюсь, что скоро доберусь до этого

.

Привет Фелиция,

Как уже было сказано, мое понимание симфонии как основы ограничено. Но, например, если он создает представления пользовательского интерфейса путем чтения непосредственно из таблиц, запросов, довольно сложно показать информацию, которая связана между собой расширенным способом.

В этом случае на самом деле может быть лучше прочитать, что предоставляет Symfony, а что нет, вместо того, чтобы делать ложные предположения. В Symfony нет пользовательских представлений, по крайней мере, в PartKeepr.

Предлагаемую каскадную и унаследованную информацию сложно запросить и, следовательно, вероятно, трудно обработать (управляемой таблицами) фреймворком, или я что-то неправильно понимаю?

Да, вы чего-то не понимаете. Symfony не предоставляет таких вещей, возможно, через какой-то сторонний пакет, но, опять же, PartKeepr не использует такой пакет. Symfony в основном используется для архитектуры контроллера, функций сериализации (которые, вместе с тем, используют платформу API для генерации JSON-LD, который затем может быть прочитан внешним интерфейсом) и Doctrine для всего, что связано с базами данных.

См. Https://wiki.partkeepr.org/wiki/Developers/Architecture.

.

Привет Фелиция,

Спасибо за ответ. Я программировал много всего, даже веб-технологии на заре их существования. Но этого совершенно не хватает для понимания архитектуры PartKeepr. Кроме того, разработчику Windows трудно понять различные используемые технологии. Как я уже сказал, кривая обучения слишком крута. Но основной вопрос все еще остается в силе. Каковы цели развития и можно ли их достичь с помощью используемых технологий. Независимо от того, как они называются.

Причины использования фреймворка, особенно широко используемого, принятого и поддерживаемого фреймворка, такого как Symfony2:

• Избегайте дублирования кода
• Повышение надежности
• Не изобретайте велосипед
• Повышение ремонтопригодности
• Сократить работу

Вплоть до PartKeepr 0.1.9 он не использовал фреймворк, кроме Doctrine для сохранения (Symfony2 тогда не существовал). Техническое обслуживание было кошмаром.

Причина, по которой в PartKeepr нет SQL-инъекций, связана с Doctrine. Причина, по которой после 0.1.9 появилось так много новых функций за короткое время, - это Symfony2 и платформа API из-за чрезвычайно низких накладных расходов на разработку. Причина, по которой 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. Итак, я сейчас закрою это.