Erik Gfesser, SPR:n datakäytännön pääarkkitehti – Haastattelusarja

Erik liittyi datakäytäntöön SPREmerging Technology Groupin pääarkkitehtina vuonna 2018.

Erik erikoistui dataan, avoimen lähdekoodin kehittämiseen Javaa käyttäen ja käytännölliseen yritysarkkitehtuuriin, mukaan lukien PoC:iden, prototyyppien ja MVP:iden rakentamiseen.

Mikä alun perin houkutteli sinua koneoppimiseen?

Sen avulla sovellukset voivat oppia jatkuvasti. Olin aloittanut kehitysurani vanhempana data-analyytikkona käyttäen SPSS:ää globaaliksi markkinatutkimusyritykseksi, ja myöhemmin sisällytin Drools-nimisen liiketoimintasääntömoottorin käytön sovelluksiin, jotka rakensin asiakkailleni, mutta kaiken tämän työn tulos oli olennaisesti staattinen.

Myöhemmin kävin läpi prosessinkehityskoulutuksen, jonka aikana ohjaajat osoittivat yksityiskohtaisesti, kuinka he pystyivät tilastojen ja muiden menetelmien avulla parantamaan asiakkaidensa käyttämiä liiketoimintaprosesseja, mutta tässäkin tuotos keskittyi pitkälti ajankohtiin. Kokemukseni työstäni kollegoideni ja minä tänä aikana rakentaman terveydenhuollon tuotteen parantamiseksi on se, mikä osoitti minulle, miksi jatkuva oppiminen on välttämätöntä tällaisissa ponnisteluissa, mutta nyt käytettävissä olevia resursseja ei silloin ollut olemassa.

Mielenkiintoista on, että kiinnostukseni koneoppimiseen on tullut täyteen, kun valmistunut neuvonantajani varoitti minua erikoisuudesta niin sanotussa tekoälyssä silloisen tekoälyn talven vuoksi. Päätän sen sijaan käyttää termejä, kuten ML, koska niillä on vähemmän konnotaatioita ja koska jopa AWS myöntää, että sen tekoälypalvelukerros on todellakin vain korkeamman tason abstraktio, joka on rakennettu sen ML-palvelukerroksen päälle. Vaikka osa ML-hypeistä on epärealistista, se tarjoaa tehokkaita ominaisuuksia kehittäjien näkökulmasta, kunhan nämä samat harjoittajat tunnustavat tosiasian, että ML:n tarjoama arvo on vain yhtä hyvä kuin sen käsittelemä data.

Olet valtava avoimen lähdekoodin puolestapuhuja, voisitko keskustella siitä, miksi avoin lähdekoodi on niin tärkeä?

Yksi avoimen lähdekoodin näkökohta, joka minun on pitänyt selittää johtajille vuosien varrella, on se, että avoimen lähdekoodin ensisijainen hyöty ei ole se, että tällaisten ohjelmistojen käyttö on saatavilla ilman rahallisia kustannuksia, vaan se, että lähdekoodi on vapaasti saatavilla.

Lisäksi tätä lähdekoodia käyttävät kehittäjät voivat muokata sitä omaan käyttöönsä, ja jos ehdotetut muutokset hyväksytään, saattaa nämä muutokset muiden sitä käyttävien kehittäjien saataville. Itse asiassa avoimen lähdekoodin ohjelmistojen taustalla oleva liike alkoi siitä, että kehittäjät odottivat pitkään, että kaupalliset yritykset tekevät muutoksia lisensoimiinsa tuotteisiin, joten kehittäjät ottivat tehtäväkseen kirjoittaa ohjelmistoja, joilla on samat toiminnot, jolloin muut voivat parantaa sitä. kehittäjät.

Kaupallinen avoin lähdekoodi hyödyntää näitä etuja, sillä todellisuus on, että monet nykyaikaiset tuotteet käyttävät avointa lähdekoodia kansien alla, vaikka tällaisten ohjelmistojen kaupalliset versiot tarjoavat yleensä lisäkomponentteja, jotka eivät ole saatavilla tietyn avoimen lähdekoodin julkaisun osana. sekä tukea, jos sitä tarvitaan.

Ensimmäiset kokemukseni avoimesta lähdekoodista tapahtuivat rakentaessani aiemmin mainitsemaani terveydenhuoltotuotetta käyttäen työkaluja, kuten ohjelmistojen rakentamiseen käytettyä Apache Ant -tuotetta ja tuolloin varhaista DevOps-tuotetta nimeltä Hudson (jonka koodipohjaksi tuli myöhemmin Jenkins ). Pääasiallinen syy päätökseemme käyttää näitä avoimen lähdekoodin tuotteita oli se, että ne joko tarjosivat parempia ratkaisuja kaupallisille vaihtoehdoille tai olivat innovatiivisia ratkaisuja, joita kaupalliset tahot eivät edes tarjonneet, puhumattakaan siitä, että joidenkin käyttämiemme tuotteiden kaupallinen lisensointi oli liian rajoittava, mikä johti liialliseen byrokratiaan, kun tuli aika tarvita lisää lisenssejä aiheutuneiden kustannusten vuoksi.

Ajan myötä olen nähnyt avoimen lähdekoodin tarjonnan kehittyvän jatkuvasti tarjoten kipeästi kaivattua innovaatiota. Esimerkiksi monet ongelmat, joiden kanssa kamppailimme kollegoideni kanssa rakentaessamme tätä terveydenhuoltotuotetta, ratkaistiin myöhemmin innovatiivisella avoimen lähdekoodin Java-tuotteella, jonka aloitimme käyttämään nimeltä Spring Framework, joka jatkuu edelleen vahvana yli vuosikymmenen jälkeen, jonka ekosysteemi nyt ulottuu paljon pidemmälle kuin eräät sen alun perin tarjoamat innovaatiot, joita pidetään nykyään yleisinä, kuten riippuvuusruiske.

Olet käyttänyt avointa lähdekoodia PoC:iden, prototyyppien ja MVP:iden rakentamiseen. Voisitko jakaa matkasi joidenkin näiden tuotteiden takana?

Kuten eräässä äskettäiselle asiakkaalle esittämässäni ohjaavassa periaatteessa selitettiin, heille rakentamamme tietoalustan rakennusvaiheet tulisi jatkossakin suorittaa iteratiivisesti tarpeen mukaan ajan mittaan. Tälle alustalle rakennettujen komponenttien ei pitäisi odottaa pysyvän staattisina, koska tarpeet muuttuvat ja uusia komponentteja ja komponenttiominaisuuksia tulee saataville ajan myötä.

Kun rakennat alustan toiminnallisuutta, aloita aina siitä, mikä on mahdollisimman kannattavaa, ennen kuin lisäät tarpeettomia kelloja ja pillejä, joihin joissakin tapauksissa sisältyy jopa konfigurointi. Aloita toimivuudesta, varmista, että ymmärrät sen ja kehitä sitä sitten. Älä tuhlaa aikaa ja rahaa rakentamalla sellaista, jonka käyttö on vähäistä, vaan pyri saavuttamaan tulevaisuuden tarpeet.

Tälle tuotteelle rakentamamme MVP piti nimenomaan rakentaa niin, että sen päälle pystyttiin rakentamaan lisää käyttötapauksia, vaikka se oli pakattu kertakäyttötapauksen kanssa kustannuspoikkeamien havaitsemista varten. Toisin kuin tällä asiakkaalla, aikaisemmalla rakentamallani tuotteella oli historiaa takana ennen saapumistani. Tässä tapauksessa sidosryhmät olivat pohtineet kolmen vuoden ajan (!), kuinka heidän pitäisi lähestyä tuotetta, jota he aikoivat rakentaa. Eräs asiakasjohtaja selitti, että yksi syistä, miksi hän otti minut mukaan, oli auttaa yritystä selviytymään joistakin näistä sisäisistä keskusteluista, varsinkin siksi, että hänen suunnittelemansa tuotteen oli täytettävä mukana olevien organisaatioiden hierarkia.

Huomasin, että nämä turpeen sodat liittyivät suurelta osin asiakkaan, sen tytäryhtiöiden ja ulkopuolisten asiakkaiden omistamiin tietoihin, joten tässä tapauksessa koko tuoteruuhka pyörii sen ympärillä, kuinka nämä tiedot syötetään, säilytetään, suojataan ja kulutetaan. kertakäyttöiseen tapaukseen, joka tuottaa terveydenhuollon tarjoajien lennossa verkostoja kustannusanalyyseja varten.

Aiemmin urallani ymmärsin, että arkkitehtoninen laatu nimeltä "käytettävyys" ei rajoittunut vain loppukäyttäjiin, vaan ohjelmistokehittäjiin itseensä. Syynä tähän on se, että kirjoitetun koodin on oltava käyttökelpoinen, kuten käyttöliittymien on oltava loppukäyttäjien käytettävissä. Jotta tuotteesta tulisi käyttökelpoinen, konseptin todisteita on rakennettava osoittamaan, että kehittäjät pystyvät tekemään sen, mitä he haluavat tehdä, erityisesti silloin, kun se liittyy heidän tekemiinsä teknologiavalintoihin. Mutta konseptin todisteet ovat vasta alkua, sillä tuotteet ovat parhaita, kun niitä kehitetään ajan myötä. Mielestäni perustan MVP:lle pitäisi kuitenkin ihanteellisesti rakentaa prototyypeille, jotka osoittavat jonkin verran vakautta, jotta kehittäjät voivat jatkaa sen kehittämistä.

Vaikka arvostelee kirjaa "Machine Learning at Enterprise Scale" totesitte, että "avoimen lähdekoodin tuotteiden, kehysten ja kielten käyttö yhdessä avoimen lähdekoodin ja kaupallisten komponenttien sekoituksesta koostuvan ketterän arkkitehtuurin kanssa tarjoaa ketteryyttä, jota monet yritykset tarvitsevat, mutta joita eivät heti tajua." Voisitko mennä yksityiskohtiin, miksi uskot, että avoimen lähdekoodin yritykset ovat ketterämpiä?

Monet kaupalliset datatuotteet käyttävät tärkeimpiä avoimen lähdekoodin komponentteja kansien alla ja antavat kehittäjille mahdollisuuden käyttää suosittuja ohjelmointikieliä, kuten Python. Näitä tuotteita rakentavat yritykset tietävät, että avoimen lähdekoodin komponentit, jotka he ovat valinneet sisällytettäväksi, antavat niille hyppykäynnin, kun yhteisö on jo laajalti käytössä.

Avoimen lähdekoodin komponentteja, joissa on vahvoja yhteisöjä, on helpompi myydä, koska ne tuovat pöytään tuttua. Kaupallisesti saatavilla olevat tuotteet, jotka koostuvat pääasiassa suljetusta lähdekoodista tai jopa avoimesta lähdekoodista, jota suurelta osin käyttävät vain tietyt kaupalliset tuotteet, vaativat usein joko näiden valmistajien koulutusta tai lisenssejä ohjelmiston käyttämiseksi.

Lisäksi tällaisten komponenttien dokumentaatiota ei suurelta osin ole julkisesti saatavilla, mikä pakottaa kehittäjät jatkamaan riippuvuutta näistä yrityksistä. Kun laajalti hyväksytyt avoimen lähdekoodin komponentit, kuten Apache Spark, ovat keskeisessä asemassa, kuten Databricks Unified Analytics Platformin kaltaisissa tuotteissa, monet näistä kohteista ovat jo saatavilla yhteisössä, mikä minimoi osuudet, joihin kehitystiimien on oltava riippuvaisia ​​kaupallisista yksiköistä. tekemään työnsä.

Lisäksi koska komponentit, kuten Apache Spark, hyväksytään laajalti de facto alan standardityökaluiksi, koodia voidaan myös helpommin siirtää tällaisten tuotteiden kaupallisten toteutusten välillä. Yritykset ovat aina taipuvaisia ​​ottamaan mukaan asioita, joita he pitävät kilpailun erottajina, mutta monet kehittäjät eivät halua käyttää tuotteita, jotka ovat täysin uusia, koska tämä osoittautuu haastavaksi liikkua yritysten välillä ja pyrkii katkaisemaan siteitään vahvoihin yhteisöihin, joihin he ovat tulleet. odottaa.

Omakohtaisen kokemuksen perusteella olen työskennellyt tällaisten tuotteiden parissa aiemmin, ja osaavan tuen saaminen voi olla haastavaa. Ja tämä on ironista, kun otetaan huomioon, että tällaiset yritykset myyvät tuotteitaan asiakkaiden odottaessa, että tukea tarjotaan ajoissa. Minulla on kokemusta vetopyynnön lähettämisestä avoimen lähdekoodin projektiin, jossa korjaus sisällytettiin koontiversioon samana päivänä, mutta en voi sanoa samaa kaupallisista projekteista, joiden kanssa olen työskennellyt.

Jotain muuta, mitä uskot avoimessa lähdekoodissa, on se, että se johtaa "pääsyyn vahvoihin kehittäjäyhteisöihin". Kuinka suuria jotkut näistä yhteisöistä ovat ja mikä tekee niistä niin tehokkaita?

Tietyn avoimen lähdekoodin tuotteen ympärillä olevat kehittäjäyhteisöt voivat ulottua satoihin tuhansiin. Adoptioluvut eivät välttämättä viittaa yhteisön vahvuuteen, mutta ovat hyvä osoitus siitä, että näin on, koska niillä on taipumus tuottaa hyödyllisiä syklejä. Pidän yhteisöjä vahvoina silloin, kun niistä syntyy tervettä keskustelua ja tehokasta dokumentaatiota ja joissa tapahtuu aktiivista kehitystä.

Kun arkkitehti tai vanhempi kehittäjä työskentelee prosessin läpi valitakseen, mitkä tuotteet sisällytetään rakentamaansa rakennukseen, monet tekijät vaikuttavat tyypillisesti ei vain itse tuotteeseen ja yhteisön ulkonäköön, vaan myös kehitystiimeihin, jotka ottamaan ne käyttöön, sopivatko ne hyvin kehitettäviin ekosysteemiin, miltä tiekartta näyttää ja joissain tapauksissa löytyykö kaupallista tukea, jos sitä tarvitaan. Monet näistä näkökohdista jäävät kuitenkin sivuun vahvojen kehittäjäyhteisöjen puuttuessa.

Olet arvostellut 100 kirjaa verkkosivustollasi, voisitko suositella kolmea lukijoillemme?

Nykyään luen hyvin vähän ohjelmointikirjoja, ja vaikka poikkeuksiakin on, todellisuus on, että ne vanhenevat yleensä hyvin nopeasti, ja kehittäjäyhteisö tarjoaa yleensä parempia vaihtoehtoja keskustelufoorumeiden ja dokumentaation kautta. Monet tällä hetkellä lukemistani kirjoista ovat vapaasti saatavillani joko tilaamieni teknologiauutiskirjeiden, minuun ottavien kirjoittajien ja tiedottajien tai Amazonin minulle lähettämien kirjojen kautta. Esimerkiksi Amazon lähetti minulle julkaisua edeltävän korjaamattoman todisteen "The Lean Startupista" arviotani varten vuonna 2011, ja se esitteli minulle MVP:n käsitteen, ja äskettäin lähetti minulle kopion "Julia aloittelijoille".

(1) Yksi O'Reillyn kirja, jota olen suositellut, on "In Search of Database Nirvana". Kirjoittaja käsittelee yksityiskohtaisesti haasteita, joita tietokyselymoottorilla on toisaalta tukea OLTP:n kirjoa kattavia työkuormia ja toisessa päässä analytiikkaa, ja keskellä on toiminnallista ja liiketoimintatiedon työtaakkaa. Tätä kirjaa voidaan käyttää oppaana arvioitaessa tietokantamoottoria tai kysely- ja tallennuskoneiden yhdistelmää, joka on suunnattu vastaamaan työkuormitusvaatimuksiin, olivatpa ne sitten tapahtumia, analyyttisiä tai näiden kahden yhdistelmää. Lisäksi kirjoittajan viime vuosien "swinging-tietokantaheilurin" kattavuus on erityisen hyvin tehty.

(2) Vaikka dataavaruudessa on paljon muuttunut muutaman viime vuoden aikana, sen jälkeen, kun uusia data-analytiikkatuotteita tuodaan edelleen markkinoille, "Häiritsevä analytiikka" esittelee lähestyttävän, lyhyen historian viimeisten 50 vuoden analytiikan innovaatioista, joita en ole nähnyt muualla, ja käsittelee kahdentyyppisiä häiriöitä: häiritsevää innovaatiota analytiikan arvoketjussa ja teollisuuden häiriötä analytiikan innovaatioiden vuoksi. Startup-yritysten ja analytiikan toimijoiden näkökulmasta menestys mahdollistaa toimialojen hajottaminen, koska analytiikan avulla tuote erottuu, luodaan häiritsevä liiketoimintamalli tai luodaan uusia markkinoita. Organisaatioiden analytiikkateknologiaan investoinnin näkökulmasta odottava lähestymistapa saattaa olla järkevää, koska häiriöriskissä olevat teknologiat ovat riskillisiä investointeja lyhennetyn käyttöiän vuoksi.

(3) Yksi parhaista lukemistani teknologia-alan teksteistä on "Strategian rajatTutkimuslautakunnan (Gartnerin ostama) perustaja on kansainvälinen ajatushautomo, joka tutkii tietojenkäsittelyn kehitystä ja yritysten sopeutumista. Kirjoittaja esittää erittäin yksityiskohtaisia ​​muistiinpanoja monista keskusteluistaan ​​yritysjohtajien kanssa ja tarjoaa oivaltavaa analyysiä hänen kokemuksistaan ​​rakentaessaan (vaimonsa kanssa) asiakasryhmää, suuria yrityksiä, joiden täytyi yhdistää strategiansa tietojenkäsittelyn räjähdysmäiseen maailmaan. Kuten kommentoin arvostelussani, se, mikä erottaa tämän kirjan muista siihen liittyvistä ponnisteluista, on kaksi näennäisesti vastakkaista ominaisuutta: alan laajuinen leveys ja läheisyys, joka on saatavilla vain kasvokkain tapahtuvan vuorovaikutuksen kautta.

Olet SPR:n datakäytännön pääarkkitehti. Voisitko kuvailla mitä SPR tekee?

SPR on Chicagon alueella toimiva digitaalisen teknologian konsulttiyritys, joka toimittaa teknologiaprojekteja useille asiakkaille Fortune 1000 -yrityksistä paikallisiin startup-yrityksiin. Rakennamme kokonaisvaltaisia ​​digitaalisia kokemuksia käyttämällä erilaisia ​​teknologiaominaisuuksia, kaikkea mukautetusta ohjelmistokehityksestä, käyttäjäkokemuksesta, datasta ja pilviinfrastruktuurista DevOps-valmennukseen, ohjelmistotestaukseen ja projektinhallintaan.

Mitä vastuita sinulla on SPR:ssä?

Pääarkkitehtina tärkein vastuuni on ohjata ratkaisujen toimittamista asiakkaille, johtaa arkkitehtuuria ja projektien kehitystä, mikä tarkoittaa usein muiden hattujen, kuten tuotteen omistajan käyttöä, koska kyky suhtautua tuotteiden rakentamiseen käytännön näkökulmasta painaa. työn priorisointiin, varsinkin kun rakennetaan alusta alkaen. Olen myös vetäytynyt keskusteluihin potentiaalisten asiakkaiden kanssa, kun asiantuntemustani tarvitaan, ja yritys pyysi äskettäin aloittamaan jatkuvan istuntosarjan datakäytännön arkkitehtien kanssa keskustellakseni asiakasprojekteista, sivuprojekteista ja siitä, mitä kollegani ovat. pysyäkseni ajan tasalla tekniikasta, kuten olin ajanut aikaisemmassa konsultaatiossa, vaikkakin tämän toisen yrityksen sisäiset tapaamiset sisälsivät heidän koko teknologiakäytäntönsä, ei vain datatyötä.

Suurimman osan urastani olen erikoistunut avoimen lähdekoodin kehittämiseen Javaa käyttämällä ja suorittanut yhä enemmän datatyötä matkan varrella. Näiden kahden erikoisalan lisäksi teen myös sitä, mitä kollegoideni kanssa olemme tottuneet kutsumaan "käytännölliseksi" tai "pragmaattiseksi" yritysarkkitehtuuriksi, mikä tarkoittaa arkkitehtuuritehtävien suorittamista rakennettavan kontekstissa ja sen varsinaista rakentamista. kuin vain puhua siitä tai piirtää kaavioita siitä, ymmärtäen tietysti, että myös nämä muut tehtävät ovat tärkeitä.

Nähdäkseni nämä kolme erikoisalaa menevät päällekkäin eivätkä sulje toisiaan pois. Olen selittänyt johtajille viime vuosina, että teknologiateollisuuden perinteisesti vetämä raja ohjelmistokehityksen ja datatyön välille ei ole enää selkeästi määritelty, osittain siksi, että näiden kahden tilan työkalut ovat lähentyneet, ja osittain siksi, että Tämän lähentymisen seurauksena itse datatyöstä on tullut suurelta osin ohjelmistokehitystyötä. Koska perinteisillä data-alan ammattilaisilla ei kuitenkaan yleensä ole ohjelmistokehityksen taustaa ja päinvastoin, autan korjaamaan tämän aukon.

Mikä on mielenkiintoinen projekti, jonka parissa työskentelet parhaillaan SPR:n kanssa?

Juuri äskettäin julkaisin ensimmäinen postaus moniosaisessa tapaustutkimussarjassa aiemmin mainitusta tietoalustasta, jonka tiimini ja minä otimme käyttöön AWS:ssä alusta alkaen kuluneen vuoden aikana Chicagossa toimivan maailmanlaajuisen konsulttiyrityksen tietohallintojohtajalle. Tämä alusta koostuu dataputkista, datajärvestä, kanonisista tietomalleista, visualisoinneista ja koneoppimismalleista, joita voivat käyttää yrityksen osastot, käytännöt ja asiakkaan loppuasiakkaat. Vaikka ydinalusta oli tarkoitus rakentaa tietohallintojohtajan johtaman IT-organisaation toimesta, tavoitteena oli, että tätä alustaa käyttäisivät myös muut organisaatiot yrityksen IT:n ulkopuolisissa organisaatioissa tietoresurssien ja data-analyysin keskittämiseen koko yritykseen yhteistä arkkitehtuuria käyttäen. rakentamalla sen päälle vastaamaan kunkin organisaation käyttötarpeisiin.

Kuten monissa vakiintuneissa yrityksissä, Microsoft Excelin käyttö oli yleistä, ja laskentataulukoita jaettiin yleisesti organisaatioiden sisällä ja niiden välillä sekä yrityksen ja ulkoisten asiakkaiden välillä. Lisäksi liiketoimintayksiköt ja konsultointikäytännöt olivat siiloissa, joissa kussakin hyödynnettiin erilaisia ​​prosesseja ja työkaluja. Tietovarojen keskittämisen ja data-analyysin lisäksi toinen tavoite oli siis toteuttaa datan omistajuuden käsite ja mahdollistaa tiedon jakaminen organisaatioiden välillä turvallisella ja johdonmukaisella tavalla.

Onko jotain muuta, mitä haluaisit jakaa avoimesta lähdekoodista, SPR:stä tai muusta projektista, jonka parissa työskentelet?  

Toinen projekti (lue siitä tätä ja tätä), jota äskettäin johtiin Databricks Unified Analytics Platformin onnistuneessa käyttöönotossa ja koneoppimismallien suorittamisen siirtämisessä siihen Azure HDInsightista, Hadoop-jakelusta, suuren vakuutusyhtiön tietotekniikan johtajalle.

Kaikkien näiden siirrettyjen mallien tarkoituksena oli ennustaa kuluttajien odotettavissa olevaa käyttöönottoa eri vakuutustuotteissa. Osa niistä on siirretty SAS:sta muutamaa vuotta aikaisemmin, jolloin yritys siirtyi käyttämään HDInsightia. Suurin haaste oli tiedon huono laatu, mutta muita haasteita olivat kattavan versioinnin puute, heimojen tuntemus ja puutteellinen dokumentaatio sekä epäkypsä Databricks-dokumentaatio ja tuki R-käytön suhteen tuolloin (Databricksin Azure-toteutus oli juuri tehty yleisesti saataville muutama kuukausi ennen tätä projektia).

Vastatakseni näihin keskeisiin haasteisiin esitin käyttöönottotyömme jatkotoimena suosituksia, jotka koskevat automaatiota, konfigurointia ja versiointia, tietoon liittyvien huolenaiheiden erottamista, dokumentaatiota ja tarvittavaa yhdenmukaistamista tietojen, alustan ja mallinnusryhmien välillä. Työmme vakuutti alun perin hyvin skeptisen Chief Data Scientistin siitä, että Databricks on oikea tie, jonka lähtömme jälkeinen tavoite on siirtää jäljellä olevat mallit Databricksiin mahdollisimman nopeasti.

Tämä on ollut kiehtova haastattelu, jossa on käsitelty monia aiheita, minusta tuntuu, että olen oppinut paljon avoimesta lähdekoodista. Lukijat, jotka haluavat tietää lisää, voivat käydä osoitteessa SPR yrityksen verkkosivuilla tai Erik Gfesserin verkkosivusto.