Partkeepr: 새 버전 개발 과정

2018년 7월 20일 이후로 커밋되지 않았습니다. 따라서 다음 릴리스에 대한 ETA가 아니라 새로운 주요 개발자에 대한 ETA에 대해 논의하고 있다고 생각합니다. 우리가 하나를 가질 때까지 우리는 어떤 릴리스도 확실히 얻지 못할 것입니다. 그러나 나는 현재 상태가 어떤지 궁금합니다.

최신 프로젝트 정보는 여기: https://www.patreon.com/posts/its-end-for-me-22527966
그리고 기본적으로 프로젝트에는 더 이상 관리자가 없지만 진지 하게 받아들이고 싶은 사람이 있다면 가능할 것 같습니다.

따라서 @christianlupus 가 옳습니다. 실제로 새 유지 관리자까지 ETA입니다.

.

5명의 개발자를 보유하는 것은 견고한 프로젝트 관리(및 아마도 이 단계에서 자금 지원) 없이는 무용지물일 것입니다. 프로젝트는 한두 명으로 생존할 수 있으며 결과적으로 발생하는 유일한 문제는 개발 시간일 수 있습니다.

그녀가 지적한 한 가지 문제는 문제 관리와 나쁜 행동을 하는 사람들을 다루는 것입니다.

프로젝트는 건강 문제가 있더라도 문제 분류 및 커뮤니티 관리를 수행하여 개발자가 다른 것에 대해 걱정할 필요 없이 작업에 집중할 수 있는 한 두 명의 개발자와 함께 행복하게 살 수 있습니다.

.

PartKeepr은 동일한 주장이 적용되는 또 다른 프레임워크를 사용했을 것입니다. Symphony는 실제로 틈새 프레임워크가 아닙니다.

예, 다른 프레임워크와 마찬가지로 이를 알고 있거나 배우려는 사람이 필요합니다.

그리고 예, 틈새 응용 프로그램일 수 있지만 컨텍스트는 고려하기 위한 것입니다. 교향곡을 알고 있다면 죽은 것처럼 보이는 프로젝트에 참여할 동기가 있습니까? 아마 아닙니다.

.

정말 고급 기성 프레임워크가 필요합니까?

다른 것보다 더 발전된 것은 아니며 단지 프레임워크일 뿐입니다. 예, 매우 가벼운 것을 사용할 수 있지만 하루가 끝나면 동일한 결과를 위해 수많은 확장을 추가하거나 처음부터 만들게 될 것입니다. "고급 프레임 워크"만큼 문서화되고 테스트되지 않았기 때문에 더 나쁩니다.

그러나 이러한 해결 방법을 좋은 방식으로 수정하려면 많은 재설계가 필요하며 아마도 Symphony 프레임워크나 다른 기성품으로는 불가능할 것입니다.

여기서 우리는 Win32 앱에 대해 이야기하는 것이 아니며 현재 프레임워크에서 수행할 수 없다는 것을 증명할 POC가 없는 한 BS입니다.
바퀴를 재발명하면 때때로 효과가 있을 수 있지만 항상 작동하는 솔루션은 아닙니다.

"교향곡 학습 곡선이 너무 가파르다"고 말하면 맞춤 제작이 얼마나 좋을까?

이제 "교향곡은 나쁘고 우리가 모든 것을 다시 쓰지 않으면 프로젝트는 파멸"이라고 외치는 것은 프로젝트를 더 나아가게 하지 않을 것이며, PR과 기여자들과 함께 작업하는 것입니다.

.

예를 들어 계단식 사양이 있는 범주를 갖고 싶습니다. 이러한 범주는 해당 범주 내의 구성 요소에도 계단식으로 적용됩니다(재정의 가능성 포함). 그리고 구성 요소 유형에 따라 결합된 모든 사양에 대한 멋진 형식의 설명을 표시하는 것보다. Symfony에서 작동할 것으로 예상해야 하는 것이 있습니까?

아니요. 어떤 프레임워크도 그렇게 하지 않을 것입니다. 프레임워크가 무엇인지 잘못 이해하고 계신 것 같습니다. 카테고리 구현은 애플리케이션에 따라 다르며 일반 프레임워크는 이를 처리하지 않습니다.

Symphony나 다른 프레임워크가 나쁘다고 생각하지 않습니다. 그러나 재고 관리 시스템이 어떻게 생겼으면 하는 경우에 그들은 삭감될 가능성이 매우 낮습니다. 그것은 BS를 말하는 것이 아니라 관련된 복잡성에 대한 좋은 이해입니다.

특정 응용 프로그램이 작동하는 프레임워크는 도대체 무엇입니까? 어떤 프레임워크도 애플리케이션이 어떻게 작동하는지 이해하지 못합니다. 구축할 계획, 철학 및 모델을 제공합니다.

추가 참고 사항: 예, 여전히 다른 사람에게 저장소 액세스 권한을 전달해야 합니다. 불행히도 PartKeepr UG의 청산으로 꽤 바쁩니다. 나는 곧 그 일을 할 수 있기를 바랍니다.

.

안녕 펠리시아

프레임워크로서의 Symphony에 대한 나의 이해는 -말했듯이- 제한적입니다. 그러나 예를 들어 테이블, 쿼리에서 직접 읽어 UI 뷰를 생성하는 경우 고급 방식으로 서로 연결된 정보를 표시하기가 상당히 어렵습니다.

이 경우 잘못된 가정을 하는 대신 Symfony가 제공하는 것과 제공하지 않는 것을 읽는 것이 실제로 더 나을 수 있습니다. 적어도 PartKeepr에서는 아닌 Symfony에서 생성된 UI 보기가 없습니다.

제안된 계단식 및 상속된 정보는 쿼리하기 어려우므로 (테이블 기반) 프레임워크에서 처리하기가 어렵습니다. 아니면 제가 잘못 이해하고 있습니까?

예, 당신은 물건을 오해하고 있습니다. 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이 자체 프레임워크를 사용했다면 가장 기본적인 기능을 위해서라도 독자적으로 많은 작업을 하게 될 것입니다. 최근에 Bug Genie를 이슈 트래커로 살펴보았는데 프레임워크를 전혀 사용하지 않습니다. 모든 것이 자체 작성되었습니다. 정상적인 사용 중에 발생한 버그를 수정하기 위해 8개 이상의 풀 리퀘스트를 제출했습니다. 6개의 버그가 더 발생한 후(한 달에 30분 정도만 소프트웨어를 사용했습니다) 사용을 중단했습니다.

이 프로젝트가 개발 지원을 거의 받지 못한 이유에 대한 답을 제시할 수 있는 가장 좋은 사람은 아마도 당신일 것입니다. 그리고 고칠 수 있는 경우.

내가 추측할 수 있는 것은: 상대적으로 작은 사용자 기반과 너무 많은 기능 요청을 수행했습니다. 대부분의 사용자에게 기본적으로 작동했는데 왜 이러한 사용자가 코드 기여를 시작할까요?

내가 스스로에게 하고 있는 질문은 다음과 같습니다. 공유 프로젝트에 참여하는 것이 즐거울까요? 내 경험이 도움이 될까요? 더 많은 사람들이 내 목표를 공유합니까? 개발자 간의 상호 작용은 어떻게 생겼습니까?

소프트웨어 프로젝트와 기본 기술이 어떻게 작동하는지 배우고자 하는 의지가 없다면 그다지 많지 않습니다. 프레임워크 선택에 대해 한발 더 나아가 불평하는 것은 매우 나쁜 첫 번째 단계입니다.

나는 이 프로젝트의 어떤 프로젝트나 개발 조정에 참여하지 않을 것입니다.

현재 symfony 3.4로 업데이트하려고 합니다. 내가 약간의 진전을 이루면 나는 업데이트를 줄 것이다

안녕하세요 @JelleDijkhuizen
symfony 3.x 마이그레이션에 대한 소식이 있습니까? 이 작업을 수행한 경우 포크를 어디에서 찾을 수 있는지 알려주실 수 있습니까? 미리 감사드립니다!

@martonmiklos , @adlerweb 이 포크의 전용 분기에서 PartKeepr을 Symphony 4로 업그레이드하려고 하는 것 같습니다... :-)

@ZupoLlask 알려 주셔서 감사합니다!

이 토론이 길었고 주요 문제가 해결되었다고 생각합니다. #1059를 참조하십시오. 그래서 일단 이 글을 닫겠습니다.