Partkeepr: 新しいバージョンの開発プロセス

2018年7月20日以降、コミットは行われていません。したがって、次のリリースまでのETAについては話し合っていませんが、新しいメイン開発者についてはETAについて話し合っていると思います。 私たちがそれを手に入れるまで、私たちは確実にリリースを持っていません。 しかし、私は興味があります、現在の状態は何ですか。

最新のプロジェクト情報はこちらです： https ：
そして、基本的にプロジェクトにはもうメンテナがいませんが、真剣にそれを取りたい人がいれば、それは可能だと思われます。

したがって、 @ christianlupusは正しいです。実際には、新しいメンテナまではETAです。

。

5人の開発者がいることは、しっかりしたプロジェクト管理（そしておそらくこの段階での資金提供）なしではおそらく役に立たないでしょう。プロジェクトは1つか2つで生き残ることができ、結果として生じる唯一の問題は開発時間かもしれません。

彼女が指摘した問題の1つは、非常に明確です。問題の管理と、悪い行動をしている人々への対応です。

プロジェクトは、問題のトリアージとコミュニティ管理を行う人がいる限り、健康上の問題があっても2人の開発者と一緒に幸せに暮らせるので、開発者は他のことを心配することなくタスクに集中できます。

。

PartKeeprはまだ別のフレームワークを使用していましたが、同じ議論が当てはまります。Symphonyは実際にはニッチなフレームワークではありません。

はい、他のフレームワークと同様に、それを知っているか、または進んで学ぶ人が必要です。

はい、それはニッチなアプリケーションかもしれませんが、シンフォニーを知っていれば、死んだプロジェクトに参加するように動機付けられるかどうかを考慮に入れる必要がありますか？ おそらくそうではありません。

。

高度な既製のフレームワークが本当に必要ですか？

それは他のものより高度ではありません、それは単なるフレームワークです、はい、あなたは非常に軽いものを使うことができます、しかし一日の終わりにあなたは同じ結果のためにたくさんの拡張機能を追加するかゼロからそれらを作りました、そして「高度な既成のフレームワーク」ほど文書化およびテストされていないため、さらに悪いことになります。

ただし、これらの回避策を適切に修正するには、多くの再設計が必要になります。おそらく、Symphonyフレームワークやその他の既成のフレームワークでは実行できません。

ここではWin32アプリについて話していません。現在のフレームワークで実行できないことを証明するPOCがない限り、それはBSです。
車輪の再発明は時々うまくいくかもしれませんが、それは毎回うまくいく解決策ではありません。

「交響曲の学習曲線が急すぎる」と言えば、カスタムメイドのものがどのように優れていると思われますか？

今、「交響曲は悪く、すべてを書き直さない限りプロジェクトは運命づけられている」と怒鳴ることは、プロジェクトをさらに前進させることにはならず、PRに取り組み、貢献者と協力します。

。

たとえば、カスケード仕様のカテゴリが必要な場合は、そのカテゴリ内のコンポーネントにもカスケードされます（それらをオーバーライドする可能性があります）。 そして、コンポーネントのタイプに応じて、組み合わされたすべての仕様の適切な形式の説明を表示するよりも。 symfonyで働くことを期待すべきものはありますか？

いいえ。それを行うフレームワークはありません。 フレームワークとは何かについて誤解されていると思います。 カテゴリの実装はアプリケーション固有のものであり、一般的なフレームワークがそれを処理することはありません。

Symphonyや他のフレームワークは悪いとは思いません。 しかし、私が在庫管理システムをどのように見せたいかという場合、彼らが削減する可能性はほとんどありません。 これはBSの話ではありませんが、関連する複雑さをよく理解しています。

特定のアプリケーションが機能するためのフレームワークは一体何を持っていますか？ どのフレームワークも、アプリケーションがどのように機能するかを理解していません。 これは、構築するためのスキーム、哲学、およびモデルを提供します。

追記：はい、まだ誰かにリポジトリアクセス権を渡す必要があります。残念ながら、PartKeeprUGの清算でかなり忙しいです。 私はすぐにそれを回避することを願っています

。

こんにちはフェリシア、

フレームワークとしてのSymphonyの私の理解は-言われたように-限られています。 ただし、たとえば、テーブルやクエリから直接読み取ることでUIビューを作成している場合、高度な方法で相互にリンクされている情報を表示することは非常に困難です。

その場合、誤った仮定をするよりも、Symfonyが提供するものと提供しないものを読む方が実際には良いかもしれません。 少なくともPartKeeprには、Symfonyによって生成されたUIビューはありません。

提案されたカスケードおよび継承された情報は、クエリを実行するのが難しく、したがって（テーブル駆動の）フレームワークで処理するのがおそらく難しいですか、それとも私は物事を誤解していますか？

はい、あなたは物事を誤解しています。 symfonyは、おそらくサードパーティのバンドルを介してそのようなものを提供しませんが、PartKeeprはそのようなバンドルを使用しません。 symfonyは主にコントローラーアーキテクチャー、シリアル化機能（APIプラットフォームを使用してJSON-LDを生成し、フロントエンドで読み取ることができます）、およびデータベース関連のすべてのDoctrineに使用されます。

https://wiki.partkeepr.org/wiki/Developers/Architectureを参照して

。

こんにちはフェリシア、

返信ありがとうございます。 私は、初期のWebテクノロジーでさえ、多くのものをプログラムしました。 しかし、それはPartKeeprのアーキテクチャを理解することに関してはかなり欠けています。 また、使用されているさまざまなテクノロジをWindows開発者として把握するのは困難です。 私が言ったように、学習曲線は急すぎます。 しかし、根底にある質問はまだ有効である可能性があります。 開発の目標は何ですか、そしてそれらは使用された技術で達成することができます。 それらがどのように呼ばれるかに関係なく。

フレームワーク、特にSymfony2のような広く使用され、採用され、維持されているフレームワークを使用する理由：

• コードの重複を避ける
• 信頼性を高める
• 車輪の再発明をしないでください
• 保守性を向上させる
• 作業を減らす

PartKeepr 0.1.9までは、永続化のためにDoctrine以外のフレームワークを使用していませんでした（Symfony2は当時存在していませんでした）。 メンテナンスは悪夢でした。

PartKeeprにSQLインジェクションがない理由は、Doctrineによるものです。 0.1.9以降に短時間で多くの新機能が登場した理由は、開発オーバーヘッドが非常に低いため、Symfony2とAPIプラットフォームでした。 PartKeeprがリバースプロキシの背後で動作する理由は、それをサポートするためのゼロコードを記述せずにSymfony2です。 PartKeeprがコードを変更せずにnginxで動作する理由：Symfony2。

Symfony2がどのように機能するかを理解するのに問題がある場合でも、問題ありません。Webには、役立つリソースがたくさんあります。

PartKeeprが独自のフレームワークを使用した場合、最も基本的な機能であっても、非常に独自のフレームワークになります。 私は最近、The Bug Genieを課題追跡システムとして見ましたが、フレームワークをまったく使用していません。すべてが自作です。 通常の使用中に発生したバグを修正するために、8つ以上のプルリクエストを送信しました。 さらに半ダースのバグに遭遇した後（そして私は1か月の間におそらく30分間だけソフトウェアを使用しました）、私はそれを使用するのをやめました。

このプロジェクトが開発サポートをほとんど受けていない理由を答えるのにおそらくあなたが最高の人だと思います。 そしてそれが修正可能であれば。

私は推測することしかできません：比較的小さなユーザーベースと私はあまりにも多くの機能要求を満たしました。 大多数のユーザーにとっては箱から出してすぐに機能しましたが、なぜこれらのユーザーはコードの提供を開始するのでしょうか。

私が自分自身に問いかけているのは、共有プロジェクトに参加することを楽しんでいただけませんか。 それは私の経験から恩恵を受けるでしょうか？ より多くの人が私の目標を共有していますか？ 開発者間の相互作用はどのようになりますか。

ソフトウェアプロジェクトとその基盤となるテクノロジーがどのように機能するかを学ぶ気がなければ、それほど多くはありません。 フレームワークの選択についてステップアップして不平を言うことは、非常に悪い最初のステップです。

私はこのプロジェクトのいかなるプロジェクトや開発調整にも参加しません。

私は現在symfony3.4にアップデートしようとしています。 進歩があれば更新します

こんにちは@JelleDijkhuizen
symfony 3.xの移行に関するニュースはありますか？ これについて何か作業をしたことがある場合は、フォークをどこで見つけることができるか教えてください。 前もって感謝します！

@ martonmiklos 、 @ adlerwebがフォークの専用ブランチでPartKeeprをSymphony4にアップグレードしようとしているようです... :-)

@ZupoLlask頭を上げてくれてありがとう！

この議論は長く、主要な問題は解決されたと思います。 ＃1059を参照してください。 それで、今はこれを閉じます。