大きな問題は、スクリプトを介した「Sisypheanの労働」です。 サイトの表示とそれらのスクリプトは公式の開発者によって定期的に変更されます。新しい小さな機能を実装するには、考え、解決策、デバッグが必要です。 サイトのプレゼンテーションを変更する場合、ユーザースクリプトを作成したすべてのユーザーが突然すべての機能を復元して再テストするために実行する必要があります。 関数が1つで、ブラウザでのテストに1日、夕方、2時間かかる場合は、そうです。 5つのブラウザー、ブラウザーバージョン、ソリューション（スクリプトまたはその一部）が動作するいくつかのタイプのサイトページがあるため、常に小さいとは限りません。 テストケースは乗算され、組み合わせ数は、対象の開発者のヒューリスティックによってのみ減らすことができます。 これがスクリプトのコレクションである場合、コレクションの作成者は、開発者の動きごとに各機能をテストする必要があります（または、サイトとスクリプトのすべての依存関係を知って、何が壊れたかを直感的に推測します）。
2011年10月3日以降に回復したスクリプトの数を見てみましょう。 userscripts.org/scripts/search?q=habrahabr&submit=Searchを検索するだけで、検索する他の単語は「habr」、「habr」です。 指定された日付（6ピース）を超えるすべての場合、スクリプト作成者は破棄後に実行できました。 残りのスクリプトはほとんど動作しません（2011年のみ12個、2010年は16個、初期のものはさらに20個）。もちろん、それぞれを指定された操作とテストで復元できます。 しかし、ほとんどの著者は、明らかに、ソリューションまたはその公開に対処したくないことは明らかです。 理解しやすいこと-スクリプトは、ほとんどの場合、アイデアによるインスピレーションの結果であり、渡された解決策に戻ることは必ずしも面白く、必要ではありません。
ブラウザに依存するスクリプトのコレクションを見ると、同様のわずかに異なる実装済みアイデアのセットが表示されます。これらのアイデアの一部は、2011年3月3日以降に復旧する時間がないか、時間がありませんでした。
体系的な問題を回避するには、体系的な決定を下す必要があります。 どれ？ 「ブレインストーミング」の順にリストします。
*もう1つの「habr」
、著者の記事だけでなく、他のリソースから記事へのリンク、興味深いソリューション、彼の組織、開発チームとの収集。 そのため、Habrによって解決されない問題は、おそらくイノベーションに敏感に反応し、希望に耳を傾け、サイトオートメーションのクラウドソーシング開発を提供する他の人々の管轄下に入ります。
何がありますか？ チームが集まり、しばらくの間、熱意を持って、またはベンチャーファイナンスの助けを借りて何かをすることができるとします。 自給自足または自立に達する間、それは間に合うはずです：
*大衆（コミュニティ）の自立と訪問や表現への関心に十分な数の人々を引き付けるために-訪問者に利益をもたらす環境を作る。 そのようなリソースの経験からわかるように、これは、多くの要件が満たされている場合に可能です：情報の関連性、一部のトピックで権威のある人々の到着、およびユーザーと管理者によるネットワークエチケットのかなりよく知られている原則の実装。
*インターフェースを改善するために-要望や傾向に対応するため。
*さまざまなリソースの利点を組み合わせること-他のリソースの記事を読みやすくし、自宅で議論する。
多くの人は、説明されているスキームReddit.comで、digg.comの混合物、サードパーティサイト（たとえばGoogle Readerなど）のRSSフィードの混合物、および慎重に飲んだ別のリソースを認識しています。 まあ、スキームは実行可能で、愛好家のグループが必要です（録音が発表され、さらに、私がメンバーになるために同様のアイデアのグループで私に近づいてきた人々がすでにHabréにいます。アイデアとリソースを組み合わせて、グループ）。
しかし、この提案のグループはこれに限定されず、この記事はこれについてではなく、より深い本質についてです。 さまざまな著者によるより実行可能なユーザースクリプトサポートを他にどのように実装できますか？
*プラグインと基本機能をサポートするユーザースクリプト
ユーザースクリプトでの作業の不便さと「シフフィズム」を認識しながら、それでも多かれ少なかれ実行可能なデザインスキームを構築しようとします。 活力を維持することの難しさは、親サイトとそのサポートがないことに大きく依存しています。 このような状況では、たとえばプラグインで作業を配布することにより、プロジェクトのライフを競い合ってサポートできます。
すべてのサイトスクリプトで必要となる基本的な機能が記述されており、最小限のトリックで簡単に学習でき、ドキュメントも簡単です。 これは、プラグイン、プラグインの共通設定、バージョン管理に関する合意、スクリプトとスタイルを接続するためのポイントに関する合意を接続する方法です。 さらに、メインスクリプト（より正確には、そのユーティリティ）では、プラグインに関係なく、特定のブラウザーのプロジェクトコレクターを記述できます。 これは、以前に分割されたブロックに基づいてブラウザー拡張機能を自動的に構築するのに役立ち、ユニバーサル* .user.jsスクリプトは基本機能で動作し、最大限の機能低下をサポートします。
簡単に言えば、知識のある人の本質です。 接続の他の場所でのコードセクションのより深い実装により、拡張機能はベーススクリプトと比較して向上しています。 たとえば、base64スタイルでベーススクリプトに画像を設定し、拡張機能で画像を使用できます。 スタイルは、1つのポイント（ページの最後）でのみ接続でき、スクリプトを実行できます。 拡張機能では、いくつかのスクリプトを以前に別の環境で実行できます。 これを使用して、ページ読み込みの品質を改善します。 したがって、メインスクリプトとプラグインの両方のソースコードには、少なくとも4つのセクションがあります。 サイトの機能によっては、HTMLページのグループに応じてセクションの数が増える場合があります。 それにもかかわらず、プラグインの作成者は、サイトの拡張機能を迅速に記述し、特定のブラウザー（将来）に対して単一のスクリプトを作成するまで、さまざまな方法で拡張機能を有効にするスキームを理解します。
既に成果があり、テキストベースのインターフェイスのモデル化に役立つため、このようなパスを通過する試みが行われます。 彼女は誰にも興味がないかもしれないことに注意してください。なぜなら、少数の作家がいて、プラグインよりも独立したスクリプトを書く方が常に簡単だからです。
*もう1つの方法-セマンティックスクリプト
最後に、もう1つの方法が、作品の「シシプス」の性質を弱めることが見られます-準備された親サイトは、最低限、本質的に使用されるべきです。 つまり、すべてのスクリプトのようにコンテンツ+レイアウトではなく、コンテンツのみを使用します。 次に、多くのマイナスを取り除きます。
*）レイアウトに依存しない-大きな安心。 パーサーのみがレイアウトに依存し、どこにも行けませんが、通常は非常に単純です。 次に、レイアウトが変更されると、すべて（または変更されたもの）が最初に折りたたまれますが、パーサーを修復した後、プレゼンテーションを構築するすべてのスクリプトとプラグインは、独自の安定したレイアウト上にあるため動作し続けます。
*）他のコンテンツにはベストプラクティスが使用されます（別のサイトのパーサーを作成するだけです）。結果のデータ構造に対して以前に作成されたすべてのベストプラクティスの作業があります。
*）これはRSSよりも複雑ですが、RSSは代替手段であり、メインのサプライヤ（サイト）を破壊する場合の公式コンテンツプロバイダーです。
*）親ページのスクリプトエラーとは無関係。 現在、JSエラーにより、ページ上でユーザースクリプトがクラッシュします。これは、サーバー上の開発者の問題に対する非常に面白くない依存です。 一部のスクリプトは、親サイトのajax読み込みデータのために複製して実行する必要がありますが、関心のバランスがあります-他の誰かのコンテンツを受信するための独自のシステムを取得するか、配信スクリプトを完全に信頼しますが、スクリプトを破壊するリスクがあります（一般に、そのような問題を回避するためのテクニックがあります。主なことは、たとえ何ヶ月もすべてが安定して動作したとしても、それらを忘れてはならないということです。
欠点は何ですか？
*）すべてのajaxリクエストはスクリプト内で繰り返されるか、データ交換にサイトスクリプトの起動を使用する必要があります。
*）プラグイン開発者はページを操作する必要はありません（これは単純です-Ctrl-Uを見て、すべてが表示されます）。データカテゴリ：メッセージ、作成者、日付、回答、作成者、日付、評価、投票のためのサイト関数、メッセージの送信など.d ..これは（パーサーの作成者にとっても）より複雑ですが、パーサーがある場合、レイアウトからの大きな独立性と重なります。 つまり、2〜3年前に作成されたプラグインは、プレゼンテーションに関するものであれば機能し、プラグインの80〜90％はそのようなものです。 ただし、データを操作するための一部の機能はサイトから切り離すこともできるため、「応答を送信する」操作や評価を送信する操作は実装に依存しません。
*）パーサー開発者は、プラグイン開発者にとってシステムがシンプルなままであるように、システムをよく検討する必要があります。 開発者ベースを拡大する利点が重なります。
これは、3番目のアイデアがより有望と思われるため、出演者とスポンサーのセットも発表しました。
削除されたメッセージや記事、サーバーのクラッシュなど、次のマイナス要因を排除するために、結果のシステムを開発する方法に関する他の考慮事項がありますが、スクリプトの議論を超えています。
まとめると
開発者をサイトに表示するデータの表示品質を向上させるために、3つの異なる方法があります。 これらは、人件費と収益化スキームが異なります-ゼロから非常に完全です。 オタクにとって便利なツールであるだけでなく、実際のデータと個人的な経験に関する柔軟なユーザビリティテストのためのモデルを持つために、単純なスクリプトを1つのプラグインにまとめることは理にかなっています。 他の場所に適用できるいくつかのアイデアの開発用。 この方法は最も費用がかからず、経験の蓄積という形で開発者に間接的な利益をもたらします。
しかし、そのようなシステムはサイトの開発者の意性によって破壊的な影響を受けるため、スクリプトレイヤーのアーキテクチャにレイアウトからデータ構造を分離することは有益です。 この種のプロジェクトは、公開プロジェクトとして開始することもできます。1つのサイトだけでなく、損失から情報をより適切に保護し、開発者がスキルをより深く掘り下げてアクセスできます。 このレベルのプロジェクトの後、開発チームは同じレベルの他の商用プロジェクトに役立つ経験を積む可能性があり、それは良い自己宣伝と経験になるでしょう。
最後に、初期段階と後期の両方で、ベンチャーの商業構造を引き付けて、このテキストに記載されリストされている体系的な問題の解決策を組み合わせた野心的で珍しいプロジェクトを作成することができます。 ただし、最初の2つのレベルには十分に開発された開発戦略がありますが、視聴者の範囲は不明確です。 読者の一部は、オタクの間ではなく、少し異なる面で、この問題のマーケティング面について考えることができるでしょう。これはより有望です。 3番目のレベルでは、分散サーバーシステムの開発が必要です。これは、スクリプトやブラウザーでのデータの表示に関する質問をはるかに超えています。 したがって、人々がこの部分（1つで十分です）に接続することをお勧めします-サーバー部分の設計者。
合計で、3つの分野すべてが関連しており、ソーシャルネットワークでのデータ表示の品質により重点を置いたアプローチを表しています。