Share
Den første PHP 5,5 alpha har blitt offentliggjort. Etter å ha tid til å teste og eksperimentere med det, kan vi nå gi oss en grundig oversikt over hva vi skal se fram til!
Hvis du vil følge med denne artikkelen, må du installere PHP 5.5 for deg selv. Du finner koblingen til kildebuntet her. I tillegg, hvis du trenger Windows binærfil, kan du ta den fra samme side.
Når du har hentet kildekoden, pakker du alt inn i en mappe og navigerer til det med ditt favoritt Terminal-program. Du kan installere PHP til hvor du vil, men for enkelhets skyld skal jeg lage en katalog i roten til stasjonen min, kalt PHP5.5. Hvis du vil opprette en ny mappe og deretter gjøre brukeren din til eieren av mappen, skriver du inn følgende i din terminal:
sudo mkdir / php5.5 sudo chown brukernavn /PHP5.5
Deretter må du bestemme hvilke utvidelser og funksjoner du vil installere med din kopi av PHP. Siden dette er en Alpha-versjon, kun ment for testing, kommer jeg ikke til å bekymre meg for å gjøre det fullt utstyrt. For denne opplæringen skal jeg bare installere cURL, men det kan være andre ting du vil legge til, for eksempel MySQL eller zip-støtte. For å se en fullstendig liste over konfigurasjonsalternativer, kjør:
./ configure -h
I tillegg til muligheten til å installere cURL, er det to andre egenskaper som vi må sette: prefiks og med-oppsettsfila-bane alternativ. Disse to egenskapene angir plasseringen av PHP-installasjonen og .Inn jeg fil, henholdsvis. Så i terminalen skriver du:
./ configure --prefix = / PHP5.5 - med-config-file-path = / PHP5.5 - med-curl = ext / curl gjør gjør installasjon
Den første linjen konfigurerer PHP med cURL, og setter plasseringen til mappen vi laget tidligere. De neste to linjene bygger PHP og flytter filene til den angitte katalogen. Det neste trinnet er å kopiere prøven php.ini fil til PHP-mappen. For å gjøre dette, kjør:
cp php.ini-utvikling /PHP5.5/php.ini
Du bør nå ha alt installert riktig. Den enkleste måten å teste denne nye versjonen ut, er å kjøre den innebygde webserveren. Naviger til bin mappe inne i PHP5.5 katalog (cd /PHP5.5/bin), og skriv inn ./ php -t / Path / To / Directory -S 0.0.0.0:4444.
Accentsconagua
-t alternativet angir serverens rotkatalog (dvs. plasseringen der du plasserer PHP-filene dine) -S eiendom setter IP-adressen og portnummeret der serveren skal binde seg til. Ved hjelp av 0.0.0.0 for IP-adressen forteller serveren å lytte på alle IP-adresser (for eksempel localhost, 127.0.0.1, 192.168.0.100, etc.). Hvis alt går bra, bør du bli møtt med en melding som forteller deg at serveren lytter på den angitte IP / porten, og den vil fortelle deg dokumentroten der den tjener fra. Vi kan nå begynne å leke med de nye funksjonene!
Generatorer lar deg lage tilpassede funksjoner, som beholder tilstanden mellom løpene.
Det største tillegget til PHP 5.5 må være generatorer. Generatorer lar deg lage tilpassede funksjoner, som beholder tilstanden mellom løpene. Det fungerer av et nytt søkeord, kalt utbytte, som kan brukes i en funksjon for både innlasting og utmatning av data.
I hovedsak når funksjonen kommer til en linje som inneholder utbyttekommandoen, vil PHP fryse funksjonens utførelse og gå tilbake til å kjøre resten av programmet. Når du ber om at funksjonen skal fortsette - enten ved å fortelle det å gå videre eller ved å sende den data - vil PHP gå tilbake til funksjonen og plukke opp hvor den sluttet, og bevare verdiene til lokale variabler som ble definert opp til der.
Dette kan høres litt kult først, men hvis du gir det litt trodde, åpner dette dørene for mange interessante designalternativer. For det første simulerer det virkningen av andre programmeringsspråk som har "Lazy Evaluation", som Haskell. Dette alene lar deg definere uendelige datasett og modellmatematiske funksjoner etter deres faktiske definisjon. Dessuten trenger du ikke å opprette så mange globale variabler; hvis en variabel bare er ment for en bestemt funksjon, kan du inkludere den i en generator, og ting som tellere skjer automatisk av generatoren selv i form av det returnerte objektets nøkkel.
Vel det er nok teori for nå; la oss ta en titt på en generator i aksjon. For å starte, naviger til dokumentroten du definerte når du kjører PHP-serveren, og opprett en fil, kalt "index.php". Nå åpner du filen og skriver inn følgende:
funksjon fibonacci () $ a = 0; $ b = 1; mens (sant) $ a = $ a + $ b; $ b = $ a - $ b; gi $ a;
Dette er "Hello World" -funksjonen til uendelige datasett. Det er en funksjon som vil utgjøre alle fibonacci-tall. For å bruke generatoren, er alt du trenger å gjøre, å skrive:
$ fib = fibonacci (); $ Fib-> strøm (); $ Fib-> next (); $ Fib-> strøm (); // ...
Hva skjer her er det vi lager $ fib et generatorobjekt, og da har du tilgang til de underliggende kommandoene, som nåværende() og neste (). De nåværende() funksjonen returnerer gjeldende verdi av generatoren; Dette er verdien av det du har gitt i funksjonen - i vårt tilfelle, $ a. Du kan ringe denne funksjonen flere ganger, og du vil alltid få samme verdi, fordi nåværende() funksjonen forteller ikke at generatoren fortsetter å evaluere sin kode. Det er der neste () funksjonen kommer inn neste () brukes til å frigjøre iteratoren og fortsette med funksjonen. Siden vår funksjon er inne i en uendelig samtidig som loop, det vil bare fryse igjen ved neste utbytte kommando, og vi kan få den neste verdien med en annen samtale til nåværende().
Fordelen med generatorer er at de lokale variablene er vedvarende.
Hvis du trengte å gjøre noe slikt i det siste, måtte du sette en slags til loop som forhåndsberegner verdiene i en matrise, og stopper etter et visst antall iterasjoner (for eksempel 100), for ikke å overbelaste PHP. Fordelen med generatorer er at de lokale variablene er vedvarende, og du kan bare skrive hva funksjonen skal gjøre, som forklarer hvordan det skal gjøre det. Hva jeg mener med dette er at du bare skriver oppgaven og ikke bekymre deg for globale variabler, og hvor mange iterasjoner skal utføres.
Den andre veien utbytte kan brukes til å motta data. Det fungerer på samme måte som før: når funksjonen kommer til en linje med utbytte søkeord, det stopper, men i stedet for å lese data med nåværende(), Vi vil gi det data med sende() funksjon. Her er et eksempel på dette i aksjon:
funksjon Logger () $ log_num = 1; mens (sann) $ f = utbytte; ekko "Log #". $ log_num ++. ":". $ F; $ logger = Logger (); for ($ i = 0; $ i<10; $i++) $logger->sende ($ i * 2);
Dette er en enkel generator for å vise en loggmelding. Alle generatorer starter i pausetilstand; et anrop til sende (eller nåværende) starter generatoren og fortsetter til den treffer a utbytte kommando. De sende kommandoen vil da angi de sendte dataene og fortsette å behandle funksjonen til den kommer til neste utbytte. Hver etterfølgende samtale til sende vil behandle en sløyfe; den vil legge inn de sendte dataene inn i $ f, og fortsett til det løper tilbake til det neste utbytte.
Så hvorfor ikke bare sette dette inn i en vanlig funksjon? Vel, det kan du, men da ville du enten trenge en separat global variabel for å holde oversikt over loggnummeret, eller du må opprette en tilpasset klasse.
Ikke tenk på generatorer som en måte å gjøre noe på som aldri var mulig, men som et verktøy for å gjøre ting raskere og mer effektivt.
Selv uendelige sett var mulig, men det ville måtte oppdatere listen fra begynnelsen hver gang (dvs. gå gjennom matematikken til den kommer til gjeldende indeks), eller lagre all dens data i globale variabler. Med generatorer er koden mye renere og mer presis.
for hver uttalelserDen neste oppdateringen som jeg syntes å være ganske nyttig, er evnen til å bryte en nestet array i en lokal variabel i en for hver uttalelse. De liste konstruksjon har eksistert en stund (siden PHP4); det kartlegger en liste over variabler i en matrise. Så, i stedet for å skrive noe som:
$ data = array ("John", "Smith", "032-234-4923"); $ fName = $ data [0]; $ lName = $ data [1]; $ celle = $ data [2]; Du kan bare skrive:
$ data = array ("John", "Smith", "032-234-4923"); liste ($ fName, $ lName, $ cell) = $ data; Det eneste problemet var at hvis du hadde en rekke arrays (en nestet array) med info du ønsket å kartlegge, var du ikke i stand til å sykle gjennom dem med en for hver sløyfe. I stedet måtte du tilordne for hver føre til en lokal variabel, og kart deretter den med a liste konstruer bare inne i løkken.
Fra versjon 5.5 kan du kutte ut mellommannen og rydde opp koden din. Her er et eksempel på den gamle måten, mot den nye:
// - Old Method - // foreach ($ parentArr som $ childArr) list ($ one, $ two) = $ childArr; // Fortsett med loop // - Ny metode - // foreach ($ parentArr som liste ($ one, $ two)) // Fortsett med loop
Den gamle måten kan ikke virke som for mye trøbbel, men det er rotete og gjør koden mindre lesbar.
På min Mac er innebygd grafikkort, kunne jeg gå gjennom over 200 millioner hashene per sekund!
Nå krever denne litt kunnskap om hash og kryptering for å fullt ut sette pris på.
Den enkleste måten å hash et passord i PHP har vært å bruke noe som MD5 eller en SHA-algoritme. Problemet med hashfunksjoner som disse er at de er utrolig enkle å beregne. De er ikke nyttige lenger for sikkerhet. I dag bør de bare brukes til å verifisere filens integritet. Jeg installerte en GPU-hasher på datamaskinen min for å teste dette kravet. På min Mac er innebygd grafikkort, var jeg i stand til å gå gjennom over 200 millioner hashes per sekund! Hvis du var dedikert, og investert i en topp av multi-grafikkortoppsettet, kan du potensielt gå gjennom milliarder av hashene en sekund.
Teknologien for disse metodene var ikke ment å vare.
Så hvordan løser du dette problemet? Svaret er at du utgjør en justerbar byrde på algoritmen. Det jeg mener med dette er at du gjør det vanskelig å behandle. Ikke at det skulle ta et par sekunder per hash, da det ville ødelegge brukerens opplevelse. Men tenk at du gjorde det ta et halvt sekund å generere. Deretter vil en bruker sannsynligvis ikke engang innse forsinkelsen, men noen som prøver å bruteforce, må det løpe gjennom millioner av forsøk - om ikke mer - og alle halv sekunder vil legge opp til tiår og århundre. Hva med problemet med at datamaskiner blir raskere over tid? Det er her den "justerbare" delen kommer inn: hver så ofte vil du øke kompleksiteten for å generere en hash. På denne måten kan du sikre at det alltid tar samme tid. Dette er hva utviklerne av PHP prøver å oppmuntre folk til å gjøre.
Det nye PHP-biblioteket er en hashing-arbeidsflyt, der folk enkelt kan kryptere, verifisere og oppgradere hash og deres respektive kompleksiteter over tid. Det sendes for øyeblikket bare med bcrypt-algoritmen, men PHP-teamet har lagt til et alternativ, som heter standard, som du kan bruke. Det vil automatisk oppdatere din hashes til den sikreste algoritmen når de legger til nye.
Slik fungerer bcrypt, det kjører ditt passord gjennom blowfish-kryptering x antall ganger, men i stedet for å bruke blowfish med en nøkkel, slik at du kan reversere den senere, går den forrige runde som nøkkelen til neste iterasjon. Ifølge Wikipedia kjører det passordet ditt gjennom 2 til x beløp. Det er den delen du kan justere. Si nå, du vil bruke et kostnadsnivå på 5: bcrypt kjører din hash 2 til 5, eller 32 ganger. Dette kan virke som et lavt antall, men siden kostnadsparameteren justerer funksjonen eksponentielt, hvis du endret den til 15, vil funksjonen kjøre den gjennom 32768 ganger. Standardkostnadsnivået er 10, men dette kan konfigureres i kildekoden.
Med teorien ut av veien, la oss ta en titt på et komplett eksempel.
$ pass = "Secret_Password"; $ hash = password_hash ($ pass, PASSWORD_BCRYPT, array ('cost' => 12, 'salt' => "twenty.two.letter.salt")); hvis password_verify ($ pass, $ hash)) if (password_needs_rehash ($ hash, PASSWORD_DEFAULT, array ('cost' => 15))) $ hash = password_hash ($ pass, PASSWORD_DEFAULT, array 15)); // Gjør noe med hash her. De password_hash funksjonen aksepterer tre parametere: ordet til hash, en konstant for hashing-algoritmen, og en valgfri liste over innstillinger, som inkluderer salt og kostnad. Den neste funksjonen, password_verify, sørger for at en streng matcher hash etter kryptering, og til slutt password_needs_rehash funksjonen sørger for at en hash følger parametrene som er gitt. For eksempel, i vårt tilfelle, setter vi hashprisen til tolv, men her spesifiserer vi femten, så funksjonen kommer tilbake ekte, noe som betyr at den må rehashed.
Du har kanskje lagt merke til det, i password_verify og password_needs_rehash Funksjoner, du trenger ikke å spesifisere hashingmetoden som brukes, saltet eller kostnaden. Dette skyldes at disse detaljene er prepended til hash-strengen.
Salter brukes til å forhindre hashes fra å bli forkalkulert til regnbuebord.
Grunnen til at det er greit å pakke kostnaden og saltet sammen med hash og ikke holde det hemmelig, er på grunn av hvordan systemet setter sine sterke sider sammen. Kostnaden trenger ikke å være en hemmelighet, fordi det er ment å være et nummer som gir en stor nok byrde på serveren. Hva jeg mener med dette er at selv om noen får din hash og bestemmer at kostnadsnivået ditt trenger 1/2 sekund til å beregne, vil han vite hvilket nivå han skal bruteforce på, men det vil ta ham for lenge til å sprekke (f.eks. Årtier ).
Salter brukes til å forhindre hashes fra å bli forkalkulert inn i et regnbuebord.
Et regnbuebord er i utgangspunktet en nøkkelverdibutikk med en ordbok med ord med tilhørende hash som sine nøkler.
Alt du trenger å gjøre er å forklare nok vanlige ord - eller verre, alle strengmuligheter - og så kan de slå opp ordet for en gitt hash umiddelbart. Her er et eksempel på hvordan salter kan være til hjelp: la oss si at passordet ditt er ordet "passord". Normalt er dette et ganske vanlig ord; det ville trolig være i deres regnbuebord. Hva et salt gjør er det legger til en tilfeldig streng til passordet ditt; så i stedet for hashing "passord" er det virkelig hashing "passwordRandomSalt524% # $ &." Dette er betydelig mindre sannsynlig å være pre-beregnet.
Så hvorfor er salter vanligvis ansett som privat informasjon? Tradisjonelt, med ting som MD5 og de som liker, når noen vet ditt salt, kan de gå tilbake til å utføre sine bruteforce teknikker, bortsett fra at de vil legge saltet til slutten. Dette betyr, i stedet for å bruteforcere din tilfeldige passordstreng, de bruteforcing et mye kortere standardpassord og bare legger til saltet. Men heldigvis, siden vi har kostnadsfaktoroppsettet, vil det ta for lang tid å beregne hver hash over med det nye saltet.
Å omhille: salter sikrer at forkomprimering av en hash ikke kan brukes igjen på en annen hash, og kostnadsparameteren sørger for at det ikke er mulig å beregne hver hash fra grunnen av. Begge er nødvendige, men ingen av dem må være hemmelige.
Det er derfor funksjonen fester dem til hash.
Husk at det ikke betyr noe hva saltet ditt er, så lenge det er unikt.
Nå, hvis du forsto hva saltet gjør, bør du vite at det er bedre å la funksjonen tilfeldig generere en, enn å skrive inn ditt eget ord. Selv om denne funksjonen er gitt, vil du ikke at alle hashene skal ha det samme saltet. Hvis de gjør det, så, hvis noen klarte å bryte inn i databasen, var det bare å beregne bordet en gang. Siden de vil ha salt- og kostnadsnivået, kan det ta litt tid, men med nok datamaskiner, når de behandler det, vil de ha låst opp alle dine hashes. Som sådan er det mye bedre å ikke tildele en og i stedet la PHP tilfeldig generere en.
Frem til nå var det ingen enkel måte å sende e-post via SMTP.
cURL er et annet område, hvor PHP-teamet har lagt til noen spennende nye tillegg og oppdateringer. Fra versjon 5.5 har vi nå støtte for FTP-direktiver, direktiver for å angi informasjonskapsler, direktiver for SSL og kontoer, og direktiver for SMTP og RTSP-protokollene, blant annet. Det vil ta for lang tid å diskutere dem alle, men for å se hele listen kan du se på NYHETER-siden.
Jeg vil imidlertid snakke om ett sett spesielt som interesserte meg mest: SMTP-settet av direktiver. Frem til nå var det ingen enkel måte å sende e-post via SMTP. Du må enten endre serverens sendmail-program for å sende meldinger via en SMTP-server, eller du må laste ned et tredjepartsbibliotek, og det er heller ikke det beste alternativet. Med de nye CURL-direktivene kan du snakke direkte med en SMTP-server, for eksempel Gmail, på bare noen få korte linjer.
For bedre å forstå hvordan koden fungerer, er det verdt å lære litt om SMTP-protokollen. Hva skjer, kobles skriptet til e-postserveren, e-postserveren anerkjenner tilkoblingen din og returnerer deg informasjonen (for eksempel domene, programvare). Du må da svare på serveren med adressen din. Å være en chattig (men høflig) protokoll, vil SMTP hilse på deg slik at du vet at den ble mottatt.
På dette punktet er du klar til å sende kommandoer. Kommandoene som trengs, er Post fra og RCPT TO; disse kartene direkte til cURL-direktiver, CURLOPT_MAIL_FROM og CURLOPT_MAIL_RCPT, henholdsvis. Du har bare en fra adresse, men du kan spesifisere flere til adresser. Når dette er gjort, kan du bare ringe kommandoen, DATA, og begynn å sende de faktiske meldingene og meldingshodene. For å avslutte overføringen må du sende en tom linje, etterfulgt av en periode, etterfulgt av en annen tom linje. Disse to siste delene (dvs. DATA-kommandoen og sluttsekvensen) blir tatt vare på av cURL, så vi trenger ikke å bekymre oss for det.
Så, i PHP, alt vi trenger å gjøre er å spesifisere posten fra og til direktiver, og send deretter den faktiske meldingen - alt innen cURL. For å gjøre ting veldig enkelt, skal jeg lage en klasse, kalt Gmail, som vil akseptere et brukernavn / passord og meldingsdetaljer, og det vil sende e-postmeldinger via Gmail-kontoen din.
Jeg limer inn hele klassen under, og så går vi gjennom det linje for linje, da det meste er kjeleplade.
klassen Gmail privat $ mail; privat $ email; privat $ pass; offentlig funksjon __construct ($ email, $ pass) $ this-> email = $ email; $ dette-> pass = $ pass; privatfunksjon mailGen () $ from = yield; $ til = utbytte; $ subject = yield; $ body = yield; gi "FRA: <" . $from . ">\ n "; gi" Til: <" . $to . ">\ n "; gi" Dato: "dato (" r ")." \ n "; gi" Emne: ". $ emne." \ n "; gi" \ n "; gi $ body; yield" "; offentlig funksjon getLine () $ resp = $ this-> post-> nåværende (); $ denne-> post-> neste (); return $ resp; offentlig funksjon sende ($ til, $ emne, $ kropp) $ this-> mail = $ this-> mailGen (); $ this-> mail-> send ($ this-> email); $ this-> mail-> send ($ til); $ this-> mail- > send ($ emne); $ this-> mail-> send ($ body); $ ch = curl_init ("smtps: //smtp.gmail.com: 465"); curl_setopt ($ ch, CURLOPT_MAIL_FROM, "<" . $this->e-post. ">"); curl_setopt ($ ch, CURLOPT_MAIL_RCPT, array ("<" . $to . ">curl_setopt ($ ch, CURLOPT_USERNAME, $ this-> email); curl_setopt ($ ch, CURLOPT_PASSWORD, $ dette-> pass); curl_setopt ($ ch, CURLOPT_USE_SSL, CURLUSESSL_ALL); // curl_setopt ($ ch, CURLOPT_VERBOSE , sant), valgfritt hvis du vil se transaksjonen curl_setopt ($ ch, CURLOPT_READFUNCTION, array ($ dette, "getLine")), returner curl_exec ($ ch); Forhåpentligvis var din reaksjon på denne koden noe i tråd med "Wow, det er kort for en komplett SMTP-implementering!" Bare hvis det virker komplisert, går vi over det. Vi begynner med å definere tre private variabler: en for meldingsgeneratoren, en for å lagre brukerens e-post og en til å lagre passordet hans. Deretter har vi konstruktøren, som lagrer e-post og passord til senere; Dette er slik at vi kan sende flere e-postmeldinger uten å komme inn på nytt hver gang. De mailGen funksjonen er en PHP 5.5 generator, som brukes til å sende meldingen i henhold til e-postprotokollen rett inn i cURL. Grunnen til at dette er nødvendig er fordi kommandoen som brukes i cURL for å skrive inn dataene er ment for å lese fra en fil, linje for linje. Så, i stedet for å ha en ekstra variabel for å huske hvilken linje vi hadde, brukte jeg en generator som sparer sin posisjon.
Den neste funksjonen brukes til å sykle gjennom generatoren. Vi kan ikke gå inn i generatoren direkte inn i cURL; Vi trenger en mellommann. cURL fortsetter å kalle denne funksjonen, til den kommer til en tom linje. Det er derfor den siste linjen i generatoren returnerer en blank streng.
Den siste funksjonen i klassen er den som knytter det hele sammen. Vi initialiserer først generatoren til den private variabelen som er definert tidligere. Deretter sender vi generatoren all nødvendig informasjon, og oppretter en ny cURL-variabel. Vi har allerede diskutert CURLOPT_MAIL_FROM og CURLOPT_MAIL_RCPT; De kartlegger tilsvarende SMTP-kommandoer. CURLOPT_MAIL_RCPT er en matrise slik at du kan legge inn flere adresser. Deretter må vi legge til legitimasjonene for å logge inn på Gmail. Jeg forlot det verbose alternativet der; Uansett om du vil se hele SMTP-transaksjonen. De to siste linjene angir bare funksjonen der CURL skal få dataene fra for meldingen, og så returnerer vi resultatene.
Det er et godt par linjer, men ingenting altfor komplisert. For å bruke denne funksjonen, opprett en ny forekomst av denne klassen, og ring sendingsfunksjonen. Her er et eksempel på å sende to e-poster med dette:
$ gmail = ny Gmail ("[email protected]", "passord"); $ gmail-> send ("[email protected]", "Subject of email", "Hello Guy, \ n Hva skjer."); $ gmail-> send ("[email protected]", "Ulike emne", "Viktig melding."); For å fullføre denne artikkelen, vil jeg gå over noen av de mindre oppdateringene til PHP 5.5.
En ganske kul ting er den ekstra støtten til konstant streng / streng dereferencing. Hva dette betyr er at du får tilgang til individuelle tegn i en statisk streng, som om strengen var en rekke tegn. Et raskt eksempel på dette er følgende:
ekko "Hello World" [1]; // denne linjen vil ekko ut 'e' echo ["one", "two", "three"] [2]; // dette ekkoet "tre"
Deretter har vi endelig søkeord. Dette er vedlagt til slutten av en prøve / fangst blokk; hva det gjør er å instruere PHP at, uansett om forsøket eller fangsten ble kalt, vil du behandle endelig seksjon. Dette er bra for situasjoner, når du vil håndtere utfallet av en prøve / fangstoppgave. I stedet for å gjenta kode i begge, kan du bare sette den "risikable" delen i prøve / fangstblokken, og all behandling i sluttblokken.
En annen bruk som ble foreslått av skaperen som en god praksis, er å sette all oppryddingskoden i den endelige blokken. Dette vil sikre at du for eksempel ikke prøver å lukke den samme strømmen flere ganger (for eksempel koden din krasjet og gikk inn i fangstblokken etter lukking allerede, og du prøver å lukke den igjen).
Det siste som er verdt å nevne, er hvordan MySQL-utvidelsen vil bli avskrevet i denne nye utgivelsen. Du bør konvertere koden til enten mysqli eller PUD utvidelser i stedet. Selv om det lenge siden er ansett som et antimønster, er det fint for PHP-teamet å offisielt depresere det.
Mens det er sikkert flere oppdateringer å grave inn, representerer elementene i denne artikkelen det jeg synes er det viktigste og spennende.
Takk for at du leste; Jeg håper du har lært litt! Som alltid, hvis du har noen kommentarer eller spørsmål, hoppe inn i samtalen under, og la oss snakke!
