Partkeepr: processo de desenvolvimento de nova versão

Nenhum commit foi feito desde 20 de julho de 2018. Portanto, acho que não estamos discutindo o ETA para o próximo lançamento, mas o ETA para um novo desenvolvedor principal. Até termos um, não teremos nenhum lançamento com certeza. No entanto, eu ficaria curioso, qual é o estado atual.

As últimas informações do projeto estão aqui: https://www.patreon.com/posts/its-end-for-me-22527966
E basicamente o projeto não tem mais mantenedor, mas se alguém sério quiser levá-lo, parece possível.

Então @christianlupus está certo, é na verdade o ETA até o novo mantenedor.

.

Ter 5 desenvolvedores é provavelmente mais do que inútil sem um gerenciamento de projeto sólido (e provavelmente financiamento neste estágio), o projeto pode sobreviver com um ou dois, e o único problema resultante pode ser o tempo de desenvolvimento.

Um problema que ela apontou é bastante claro: gerenciamento de problemas e tratamento de pessoas com mau comportamento.

O projeto pode viver felizmente com dois desenvolvedores, mesmo com problemas de saúde, desde que haja pessoas para fazer a triagem de problemas e gerenciamento de comunidade para que os desenvolvedores possam se concentrar em uma tarefa sem ter que se preocupar com outras coisas.

.

PartKeepr teria usado outra estrutura, o mesmo argumento se aplicaria, o Symphony não é realmente uma estrutura de nicho.

Sim, é preciso alguém que conheça ou esteja disposto a aprender, como qualquer outro framework.

E sim, pode ser um aplicativo de nicho, mas o contexto deve levar em consideração, se você conhecesse o Symphony, estaria motivado para ingressar em um projeto aparentemente morto? provavelmente não.

.

Ele realmente precisa de uma estrutura avançada pronta para uso?

Não é mais avançado do que outro, é apenas um framework, sim você pode usar um bem leve, mas no final do dia você terá adicionado toneladas de extensões ou feito do zero para o mesmo resultado, e até pior, já que não será tão documentado e testado como o "framework de prateleira avançado".

Mas consertar essas soluções alternativas de uma maneira agradável precisaria de muito redesenho, provavelmente não é possível com o framework Symphony, ou qualquer outro disponível no mercado.

Não estamos falando sobre aplicativos Win32 aqui, e a menos que você tenha um POC para provar que não é viável com o framework atual, então é BS.
Reinventar a roda pode funcionar às vezes, mas essa não é uma solução que funciona sempre.

Se você disser que "a curva de aprendizado do Symphony é muito íngreme", como uma coisa feita sob medida deveria ser melhor?

Agora, reclamar que "a sinfonia é ruim e o projeto está condenado a menos que reescrevamos tudo" não vai fazer o projeto avançar, trabalhar nos PRs e com os contribuidores sim.

.

Se, por exemplo, eu gostaria de ter categorias com especificações em cascata, que também se propagam para componentes dentro de tal categoria (com a possibilidade de substituí-los). E do que mostrar uma boa descrição formatada de todas as especificações combinadas dependendo do tipo de componente. É algo que devo esperar que funcione no Symfony?

Não. Nenhuma estrutura fará isso. Acho que você não entendeu bem o que é uma estrutura. A implementação de categorias é algo específico do aplicativo, e nenhum framework genérico vai lidar com isso.

Não acho que Symphony ou outros frameworks sejam ruins. Mas no caso de como eu gostaria que um Sistema de Gerenciamento de Estoque se parecesse, é muito improvável que eles façam o corte. Isso não é falar de BS, mas um bom entendimento da complexidade envolvida.

O que diabos uma estrutura tem a ver com um aplicativo específico funciona? Qualquer estrutura não entende como um aplicativo funciona. Ele fornece um esquema, filosofia e modelo para construir.

Observação adicional: Sim, ainda preciso passar os direitos de acesso ao repositório para alguém, infelizmente estou muito ocupado com a liquidação da PartKeepr UG. Espero chegar a isso logo

.

Oi felicia,

Minha compreensão do Symphony como uma estrutura -como disse- é limitada. Mas, por exemplo, se estiver criando visualizações de IU lendo diretamente de tabelas, consultas, é muito difícil mostrar informações que estão vinculadas de forma avançada entre si.

Nesse caso, pode ser melhor ler o que o Symfony oferece e quais não, em vez de fazer suposições falsas. Não há visualizações de UI geradas pelo Symfony, pelo menos não no PartKeepr.

A cascata proposta e as informações herdadas são difíceis de consultar e, portanto, provavelmente de processar por uma estrutura (orientada por tabela), ou estou entendendo mal as coisas?

Sim, você está entendendo mal as coisas. Symfony não fornece tais coisas, talvez através de algum pacote de terceiros, mas novamente, PartKeepr não usa tal pacote. Symfony é usado principalmente para a arquitetura do controlador, os recursos de serialização (que, em conjunto, usam a plataforma API para gerar JSON-LD que pode ser lido pelo frontend) e o Doctrine para todas as coisas relacionadas ao banco de dados.

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

.

Oi felicia,

Obrigado por responder. Eu programei muitas coisas, até mesmo tecnologia da web em seus primeiros dias. Mas isso é uma questão de compreensão da arquitetura do PartKeepr. Além disso, as diferentes tecnologias usadas são difíceis de entender como um desenvolvedor do Windows. Como disse para mim, a curva de aprendizado é muito íngreme. Mas a questão subjacente ainda pode ser válida. Quais são os objetivos de desenvolvimento e podem ser alcançados com as tecnologias utilizadas. Independentemente de como eles são chamados.

Razões para usar um framework, especialmente um framework amplamente usado, adotado e mantido como Symfony2:

• Evite a duplicação de código
• Aumente a confiabilidade
• Não reinvente a roda
• Aumentar a capacidade de manutenção
• Reduza o trabalho

Até o PartKeepr 0.1.9, ele não usava um framework diferente do Doctrine para persistência (Symfony2 não existia naquela época). A manutenção era um pesadelo.

A razão pela qual não há injeções de SQL no PartKeepr é por causa do Doctrine. A razão pela qual havia tantos novos recursos após o 0.1.9 em um curto espaço de tempo era o Symfony2 e a plataforma API por causa da sobrecarga de desenvolvimento extremamente baixa. A razão pela qual o PartKeepr funciona atrás de um proxy reverso sem que eu escreva código zero para suportá-lo: Symfony2. A razão pela qual PartKeepr funciona no nginx sem nenhuma modificação de código: Symfony2.

Se você tiver problemas para entender como o Symfony2 funciona, sem problemas: há muitos recursos na web para ajudá-lo.

Se PartKeepr usasse sua própria estrutura, você estaria por conta própria, mesmo para as funcionalidades mais básicas. Recentemente, dei uma olhada no Bug Genie como um rastreador de problemas, e ele não usa uma estrutura - tudo é escrito por ele mesmo. Enviei pelo menos 8 solicitações de pull para corrigir bugs que encontrei durante o uso normal. Depois de encontrar mais meia dúzia de bugs (e só usei o software por cerca de 30 minutos em um período de um mês), parei de usá-lo.

Acho que você é provavelmente a melhor pessoa para responder por que este projeto teve tão pouco suporte de desenvolvimento. E se for corrigível.

Só posso imaginar: base de usuários relativamente pequena e atendi a muitas solicitações de recursos. Ele funcionou imediatamente para a maioria dos usuários, então por que esses usuários começaram a contribuir com código?

As perguntas que estou me perguntando são: eu gostaria de participar de um projeto compartilhado? Isso se beneficiaria com minha experiência? Mais pessoas compartilham meus objetivos? Como seriam as interações entre os desenvolvedores.

A menos que você esteja disposto a aprender como um projeto de software e as tecnologias subjacentes funcionam, não muito. Intensificar-se e reclamar da escolha da estrutura é um péssimo primeiro passo.

Não participarei de nenhum projeto ou coordenação de desenvolvimento neste projeto.

Atualmente, estou tentando atualizar para o symfony 3.4. se eu fizer algum progresso eu darei uma atualização

Olá @JelleDijkhuizen
Você tem alguma notícia sobre a migração do symfony 3.x? Se você fez algum trabalho nisso, poderia me dizer onde posso encontrar o seu garfo? Desde já, obrigado!

@martonmiklos , parece que @adlerweb está tentando atualizar o PartKeepr para o Symphony 4 em um branch dedicado de seu fork ... :-)

@ZupoLlask, obrigado pelo

Acho que essa discussão foi longa e o problema principal foi esclarecido. Consulte # 1059. Então, vou encerrar isso por enquanto.