F#でのBeerway指向プログラミング[2]

前書き

このブログ投稿では、前回のブログ投稿の続きから続けます。次のことを目指しています。

  1. 過度にハードコーディングされたmumbo-jumboが継続しないようにリテラルを構成します。 MongoDbからMLabを介してプロセスの起動時に読み込まれる構成を保存します。ハードコードされた値は、Mongoサーバーに接続するための接続文字列の値のみです。
  2. スケジューラを一般化して、複数の醸造所のパイプラインを実行します。
  3. タイムリーに実行するためのプロセスのスケジューリング。
  4. MongoDbを使用したスクラップの永続化。

Expectoを使用したテストと、このシリーズの3番目のブログ投稿でLogaryを使用したロギングの追加について説明します。

予選

私はAtle RudshaugからNoDifferenceケースの処理に関する素晴らしい指針を受け取りました。 NoDifferenceケースを成功として扱う必要があります。違いが見つからない場合は、テキストを送信しないでください。

変更されたエラーモジュールは次のようになります。

現在のスクレイプと以前のスクレイプの違いを単純にパイプする比較機能。

Alert Functionには、差分セットのカーディナリティに基づいてテキストを送信するかどうかを判断する責任があります。

さらに、文字列タイプの新しいメンバーを「名前」というレコードに追加して、後で強調するパイプラインを一般化する方向に進みます。

更新されたレコードタイプとChiron関連の静的メンバーを含むBeerInfo.fsは次のようになります。

構成と一般化

ハードコーディングされたすべてのリテラルを取り除き、疲れた手だけではなく、醸造所のリスト全体でパイプラインを一般化しましょう。これまでは、共通コンポーネントを分離するのに良い仕事をしました。私たちはもっとうまくやれる!すべての構成をクラウドに移動して、パイプラインを一般化します。

設定

MLabの無料利用枠を使用して、すべての構成の詳細を保持します。 「beerwayorientedprogramming」と呼ばれるデータベースを作成し、構成コレクションを追加することから始めます。これは非常に単純なプロセスです。 MLabのUIは素晴らしいです!問題があれば私に連絡してください。

構成コレクションには、今のところ、Twilioの詳細を含むドキュメントが含まれている必要があります。ここで他のフィールドを追加するかどうかは後で決めることができます。

構成コレクションは、永続化されると、次のようになります。

{
    「_id」:{
        「$ oid」:「5976bcc1734d1d6202aa1556」
    }、
    「MyPhoneNumber」:「あなたの電話番号」、
    「AccountSID」:「ご使用のtwilioアカウントsid」、
    「AuthToken」:「twilio認証トークン」、
    "SendingPhoneNumber": "twilio送信電話番号"
}

データベースとの通信

次に、PAKETを介してmongocsharpdriverおよびMongoDB.FSharpリファレンスを追加します。これを行う方法がわからない場合は、PAKETの使用方法に関する情報を含む以前の投稿を参照し、依存関係が正常に参照されたかどうかを再確認してください。

データベースに関連するすべての機能を含むエラーモジュールの前に、Common.fsファイルにDbという新しいモジュールを作成します。さらに、以前に比較モジュールで作業したJSONファイルを逆シリアル化/シリアル化するためのすべてのコードを出力します。

ハードコーディングされる唯一のリテラルは、接続文字列の文字列です[創造的になりたい場合は、FSharp.Configurationライブラリを使用してこれを構成ファイルに保持できます]。

全体として、Dbモジュールは次のようになります。

Mongo + F#CRUD操作の詳細については、こちらの以前のブログ投稿をご覧ください。そして、構成が変更されたAlertモジュールは次のようになります。

一般化

醸造所固有の唯一のコードは、醸造所固有のパーサーと、醸造所のパイプラインを含むメイン関数を含むファイルに存在します。醸造所の名前に基づいてJsonファイルを作成するには、比較モジュールを変更する必要があります。

変更されたBeerwayOrientedProgrammingモジュールは次のようになります。

比較モジュールの変更された比較関数は次のようになりました。

スケジューラー

次のステップは、タイマーでbreweryPipelinesを実行するスケジューラーをセットアップすることです。このため、PAKETを介したスケジューリングのためにQuartz.NETをダウンロードします。

このF#スニペットに従って、すべての醸造所を通過するスケジュールされたプロセスを簡単に設定し、2秒ごとに詳細を永久に解析できます。

私たちはビールを手に入れるのではなく、企業レベルのビールをバズーカにするプロセスを作ります。

永続的なスクラップ

最後に、同じMongoDbの「ビール指向プログラミング」データベースにスクラップを保持する機能を追加しましょう。

プロセスを一般化して他の醸造所パーサーを簡単に追加するという同じ精神で、JSONのシリアル化と逆シリアル化をファイルとの間でやり取りした後、醸造所の名前に基づいてデータベースのコレクションに名前を付けます。

Chierベースの静的メンバーを削除した後、BeerInfoレコードタイプを再検討し、タイプBsonObjectIdのMongoDb Idを追加して、すべての古いJSONシリアル化および逆シリアル化コンポーネントを削除することから始めます。

新しいBeerInfoモジュールは次のようになります。

気づいたら、「ビール」の種類をFSharpリストからSystem.Generic.Collectionsに変更しました。これは、F#が作成されたC#MongoDbドライバーに準拠するためです。

Chironへの参照は不要になったため、削除します。これを行うには、コマンドパレット[Cmd + Shift + P]を開き、fsprojファイルを開いた後、次の方法でPAKETのremove参照に移動します。

Chironへの参照が削除されたら、新しいIDの作成と以前のスクレイプの取得に関連するDbモジュールにいくつかのメソッドを追加します。

醸造所の名前でコレクションを取得しようとして例外が発生した場合、withブロックでコレクションを再作成しようとします。

比較モジュールから、最後のスクレイプを取得するDbにスクレイプを保持する複雑さを取り除きました。 FirstOrDefault()を使用しているため、最後のスクレイプがnullかどうかをチェックします[null可能性をチェックするためにオブジェクトにキャストした後]。

更新されたTiredHandsScraper.scrape関数は次のようになります。

getBeerNamesFromTiredHands関数は次のようになります。

さらに、比較モジュールは大幅に簡素化されます。

TiredHandsコレクションのドキュメントを確認することで確認できるスクレイプを永続化するのは素晴らしいことです。

結論

構成の追加、一般化、スケジューリング、および永続化により、間違いなくこれまでに到達しました。前に述べたように、このシリーズの次と最後の投稿には、このかつての単純なアプリケーションを完全に進化させたアプリケーションに完全に強化するためのテストとロギングが含まれます。

いつものように、私はあなたのフィードバックに感謝します!