そのため、私たちは長い間、古いパーサーと一緒に暮らし、オープンソースプロジェクトからフォークの形で横から撮影しました。 はい、彼は良かったし、100で彼の仕事をしようとしました（最初の記事のどこかでリンクしました-興味があるなら、見てください）。 また、要件が平均を超えていない場合は、使用することをお勧めします-確実に処理できます。
しかし、時間が経つにつれて、ますますさまざまな制限に遭遇し始めました。 私たちは皆、あらゆる種類のサイトがあることを知っていますが、特別な基準がなかった2000年代のひどい遺産にまだ出くわしています。 一般的に、ここではライブラリがクラッシュし、だれか他のコードにどんどん登り、「自分自身のために」編集する必要がありました。 時間が経つにつれて、主な不満はおそらくライブラリがスイスのナイフのように良いということでしたが、私はすべて自分でやりました：URLでドキュメントをダウンロードし、リダイレクトを追跡し、さまざまな短縮を解読する方法を知っていて、明示的に設定されていなくてもエンコードを決定しようとしました文書、画像の特定、さらには記事が公開された日付の把握を試みました。 一般に、図書館ではなく、おとぎ話...本当です。何かを修正したり、少し変更したりする必要があるまでは。 また、多くの場合、コードを直接編集するか、ドキュメントを処理した後、元のパーサーから何らかのロジックを自然に複製する別の独自のコードを実行するという選択に直面しました。 そして、この決定は容易ではありませんでした。この非常にオープンソースのライブラリの作成者は明らかにテストのファンではなかったので、触れられてコードに大きな変更を加えない限り、すべてが正確に機能しました。
記事を解析して取得するプロセスは、これに遭遇したことのない人にとっては、明確な基準ではなく統計に完全に依存していることを考えると、適用された統計モデルの重みをわずかに変更するだけで十分であり、すぐにリスクを冒しました、サイトの一部のクラスは単に正しく処理されなくなります。 結局のところ、一般的なフォーマットはありません-記事全体は単なる大きなHTMLであり、その中のどこかに必要なテキストのいくつかの段落があります。 時間が経てば、すでに処理され、一見既に準備ができているように見える記事が再び実行されましたが、独自のアンダーパーサーを介して、パラレルワールドが得られました。
このオープンソースライブラリがマルチスレッドモードでどのように機能するかは、別の非常に悲しい歌でした。 そして、最初は大量の輸入で、法案が数万個のしおりが処理のために同時に並んでいたとき、私たちの王国のすべてがただ凍結しました。
そして、これは私たちにとってレッスン番号1でした。 システムを構築するとき、独立したコンポーネント、つまりレンガを使用してください。 そして、あなたから必要なものを集めるのは彼らからです。 何かがうまくいかない場合、または仕事をより良くする新しい興味深いプロジェクトが表示された場合、システムを壊すことなく、いつでも古いプロジェクトをオフにして新しいプロジェクトを試すことができます。 そして、ここで、私たちの経験を信じてください。数字の世界で何かがうまくいかない場合、それはほぼ間違いなく間違います。
結局、私たちは決定しました-それで十分です、私たちの要件に応じて、満足できる品質で、私たち自身の手にコントロールを取り、私たちのものを書く時です。 そして、新しいコンポーネントがアーキテクチャ図-GAE 2.0に登場しました。
まず第一に、私はそれを独立したコンポーネントの束の形で構築したかったのです。 一部の手順では、原則に応じて並列処理が必要でしたが、より良い、単一のスレッドで処理できる場所、並列処理を高速化したい場所がありましたが、同時に処理される要素の数には重大な制限がありました。
その結果、一種のコンベヤーまたはパイプラインが出現し、各ブックマークが本格的な記事に変わり、各ステップがユーザー関連データで満たされました。
それでは、すでにユーザーに表示できるリンクから本格的な記事を作成するには、どのような手順を踏む必要がありますか？
熟考した後、責任の領域は次のように判明しました。実際にはURLフェッチャー自身。 Urlが提供する記事を直接ダウンロードします。 あらゆる種類のリダイレクトを理解し、SSLおよびリンク短縮サービスを介して作業できるようにする必要があります。 また、サーバーからの応答を待機するのに何年ものコンピューター時間がかかり、それに対処する必要があるため、並列化する必要があります。 しかし、戦略は大きくなればなるほど良くなり、ここでもうまくいきません。同じサイトをリクエストで攻撃し、単純に平凡になります。 ですから、私たちとあなたの両方と呼ばれる、ある種の最適なものが必要です。
結果のエラーをチェックする必要があります。また、GrabDuckに既に存在する記事の複製である場合もあります。この既存の記事に新しいユーザーを添付するだけで十分です。
そして、これがデータを抽出し、最終記事を準備する時が来た後、それをユーザーに見せます。 ここに含まれるものは何ですか？ メタ情報の受信。これらは、見出し、画像、タグの計算、ドキュメントの言語です。 もちろん、全文検索にはコンテンツ自体が必要です。また、ドキュメント自体を簡潔に表すテキストスニペットを生成する必要もあります。
その後、ドキュメントはすぐに使用でき、GrabDuckで検索できます。
これで、新しいパーサーの準備が整い、すべての新しいブックマークがこのパーサーを通過し、最終的には必要なものが得られます。 しかし、読者が抱える大きな疑問は、既存のブックマークに何が起こるかということです。 結局のところ、それらはすでに処理されており、システムにすでに保存されています！ 彼らは本当に手つかずのままですか？ そして、私たちの答えはノーです！ まず第一に、ユーザーは常にブックマークを選択して強制的に更新する機会があります。 これを行うには、コンテキストメニューから適切な項目を選択するだけです。 こんな感じです。
まあ、またはちょっと待ってください。 GrabDuckの優れた機能の1つは、すべてのブックマークを定期的にチェックすることです。すべてが正常である、サイトがまだ生きている、ページに新しいコメントが表示されるなどです。 遅かれ早かれ、ブックマークは更新され、GAE 2.0を通過します。
今日は私たちがあなたに伝えたかったすべてです。 コメントを残してすぐに会いましょう。