Beerway orienterad programmering i F # [2]

Introduktion

I denna bloggpost fortsätter vi där vi slutade från föregående bloggpost. Vi strävar efter att göra följande:

  1. Konfigurera Literals så att ingen av de överdrivna hårdkodade mumbo-jumboen fortsätter. Vi sparar våra konfigurationer som kommer att laddas vid start av processen från MongoDb via MLab. Det enda hårdkodade värdet är det för anslutningssträngen som ansluts till Mongo-servern.
  2. Generalisera schemaläggaren för att köra pipeline för flera bryggerier.
  3. Planera processen att köras i tid.
  4. Persisting Scrapes via MongoDb.

Vi kommer att gå igenom tester med Expecto och lägga till loggning via Logary i den tredje blogginlägget i den här serien.

förberedelser

Jag fick en bra pekare om hantering av NoDifference-fallet från Atle Rudshaug; vi bör behandla NoDifference-fallet som en framgång, dvs om ingen skillnad hittas, skicka inte en text.

Vår ändrade felmodul ser nu ut:

Jämför funktion som nu enkelt rör skillnaden mellan den nuvarande och den tidigare skrapningen.

Alarmfunktionen har nu en uppgift att urskilja om man ska skicka en text baserad på kardinaliteten i skillnadsuppsättningen.

Dessutom lägger vi till en ny medlem av typsträngen till vår post som heter "Namn" för att gå mot en riktning för att generalisera rörledningen som kommer att markeras senare.

Våra BeerInfo.fs, med den uppdaterade posttypen och Chiron-relaterade statiska medlemmar ser nu ut:

Konfiguration och generalisering

Låt oss bli av med alla hårkodade bokstäver och generalisera pipeline över en lista med bryggerier snarare än bara Tired Hands. Hittills har vi gjort ett bra jobb med att separera de gemensamma komponenterna; vi kan göra bättre! Låt oss flytta alla konfigurationer till molnet och generalisera linjen.

Konfiguration

Vi använder MLabs gratis nivå för att behålla alla konfigurationsdetaljer. Vi börjar med att skapa en databas som heter "beerwayorientedprogramming" och lägger till konfigurationssamlingen; detta bör vara ganska rak framåt. Användargränssnittet för MLab är fantastiskt! Vänligen kontakta mig om du har några problem.

Konfigurationssamlingen, för tillfället, bör innehålla ett dokument med våra Twilio-detaljer. Vi kan senare besluta om vi vill lägga till andra fält här.

När konfigurationssamlingen, när den har bestått, kommer att likna följande:

{
    "_id": {
        "$ oid": "5976bcc1734d1d6202aa1556"
    },
    "MyPhoneNumber": "ditt telefonnummer",
    "AccountSID": "ditt twilio-konto sid",
    "AuthToken": "ditt twilio authent-token",
    "SendingPhoneNumber": "ditt twilio sänder telefonnummer"
}

Kommunikera med databasen

Därefter lägger vi till mongocsharpdriver och MongoDB.FSharp-referens via PAKET. Om du är osäker på hur du gör detta hänvisar du till det föregående inlägget som innehåller information om hur du använder PAKET och dubbelkontrollera om beroendena har framgångsrikt hänvisats.

Vi skapar en ny modul som heter Db i filen Common.fs före felmodulen som kommer att innehålla all vår databasrelaterad funktionalitet. Dessutom tar vi bort all kod för att deserialisera / serialisera JSON-filen vi tidigare arbetat med i jämför modulen.

Det enda bokstavliga som är hårdkodat är anslutningssträngen [om du vill vara kreativ kan du behålla detta i en konfigurationsfil med FSharp.Configuration-biblioteket].

Sammantaget ser Db-modulen ut:

Mer information om Mongo + F # CRUD-operationer finns i min tidigare bloggpost som kan hittas här. Och den ändrade varningsmodulen med konfiguration ser nu ut:

Generalisering

Den enda bryggerispecifika koden kommer att leva i bryggerispecifik tolkare och filen som innehåller huvudfunktionen som kommer att innehålla pipeline för bryggeriet. Vi måste ändra jämför modulen för att skapa Json-filen baserat på bryggeriets namn.

Den ändrade BeerwayOrientedProgramming-modulen ser nu ut:

Och den ändrade jämför-funktionen i jämför modul ser nu ut:

Schemaläggare

Nästa steg är att installera en schemaläggare för att köra bryggeripipelinjerna på en timer. För detta kommer vi att ladda ner Quartz.NET för schemaläggningen via PAKET.

Efter detta F # -stycke kan vi enkelt konfigurera en schemalagd process för att gå igenom alla bryggerier och analysera varannan sekund för evigt.

Vi tänker inte med vårt ölförvärv, vi gör processen att öl på företagsnivå får bazooka.

Bestående skrapor

Slutligen, låt oss lägga till förmågan att fortsätta våra skrapor till samma MongoDb-databas med "ölorienterad programmering".

Med samma anda av att generalisera vår process för att enkelt lägga till andra bryggeripartare kommer vi att namnge samlingarna i databasen på grundval av namnet på bryggeriet efter att vi har släppt JSON-serien och deserialisering till och från en fil.

Vi börjar med att släppa alla gamla JSON-serier och deserialiseringskomponenter genom att gå igenom vår BeerInfo-posttyp och lägga till MongoDb-id som är av typen BsonObjectId efter att ha tagit bort våra Chiron-baserade statiska medlemmar.

Den nya BeerInfo-modulen ser ut:

Om du märker det, ändrade vi typen av 'Beers' från en FSharp-lista till en till System.Generic.Collections en för att överensstämma med C # MongoDb-drivrutinen som F # one byggdes ovanpå.

Vi tar nu bort referensen till Chiron eftersom vi inte behöver den längre. Detta görs genom att öppna Command Pallet [Cmd + Shift + P] och navigera till PAKETs ta bort referens på följande sätt efter att ha öppnat fsproj-filen:

När hänvisningen till Chiron har tagits bort, lägger vi till några metoder i vår Db-modul som är relevant för att skapa nya Ids-skivor samt att få den tidigare skrapen.

Om det finns ett undantag när vi försöker få samlingen med namnet på bryggeriet försöker vi återskapa den i med-blocket.

Vi har tagit bort komplexiteten med att kvarstå skraporna från Jämför modulen till Db där vi tar den sista skrapan. Vi kontrollerar om det sista skrotet är noll [efter att ha kastat det i ett objekt för att kontrollera om det finns nollbarhet eftersom vi använder FirstOrDefault ()].

Vår uppdaterade TiredHandsScraper.scrape-funktion kommer nu att se ut:

med getBeerNamesFromTiredHands-funktionen som ser ut:

Dessutom kommer vår Jämför-modul att förenklas betydligt:

Det är fantastiskt att få våra skrot kvarstår som kan bekräftas genom att kolla in våra dokument i TiredHands-samlingen:

Slutsats

Vi har definitivt kommit långt genom att lägga till konfiguration, generalisera, schemalägga och fortsätta. Som nämnts tidigare kommer nästa och sista inlägg i den här serien att innehålla några tester och loggningar för att fullt ut förstärka denna en gång enkla applikation till en helt utvecklad.

Som alltid uppskattar jag din feedback!