Ottaa mukaan: Isäntä Eric Kavanagh keskusteli tietokannan virheenkorjaamisesta ja profiloinnista tohtori Robin Bloorin, Dez Blanchfieldin ja IDERAn Bert Scalzon kanssa.
Et ole tällä hetkellä kirjautunut sisään. Kirjaudu sisään tai kirjaudu sisään nähdäksesi videon.
Eric Kavanagh: Okei, hyvät parlamentin jäsenet, on keskiviikkona kello 4:00 itäaikaa, ja tietysti se tarkoittaa.
Robin Bloor: Et voi kuulla sinua, Eric.
Eric Kavanagh: Olin siellä päivää sitten, joten et ole yksin. Mutta joten tänään aihe on todella mielenkiintoista. Se on sellainen asia, jonka haluat varmistaa, että tapahtuu yrityksesi taustalla, ellet ole henkilö, joka tekee sitä. Tällöin haluat varmistaa, että teet sen oikein. Koska puhuivat virheenkorjauksesta. Kukaan ei pidä virheistä, kukaan ei halua, kun ohjelmisto lakkaa toimimasta - ihmiset järkyttyvät, käyttäjät tulevat epäystävällisiksi. Tuo ei ole hyvä. Joten, he aikovat puhua aiheesta "Nopea vastaus: Tietokannan virheenkorjaus ja pelastustoimien profilointi".
Theres kohta sinusta todella, lyö minut, @eric_kavanagh tietenkin.
Tämä vuosi on kuuma. Ja virheenkorjaus tulee olemaan kuuma, ei väliä mitä. Se todella tulee olemaan yksi näistä ongelmista, jotka eivät koskaan katoa, riippumatta siitä, kuinka hyvä meillä on tämä asia, theres tulee aina olemaan ongelmia, joten tärkeintä on, kuinka pääset sinne, missä voit ratkaista nämä ongelmat nopeasti? Ihannetapauksessa sinulla on hyviä ohjelmoijia, loistavat ympäristöt, joissa ei liikaa menee pieleen, mutta kuten vanha sanonta kuuluu: ”Onnettomuuksia tapahtuu perheiden parhaimmissa tapauksissa.” Ja sama pätee organisaatioihin. Joten, tätä tavaraa tapahtuu, se tapahtuu, kysymys on mikä on ratkaisusi käsittelemään sitä ja ratkaisemaan näitä ongelmia?
Kuule hyvin Dr. Robin Bloorilta, sitten omalta Dez Blanchfieldiltä alhaalta ja tietysti hyvältä ystävältämme, Bert Scalzon, IDERalta. Ja itse asiassa, aion luovuttaa avaimet Robin Bloorille, ottaa sen pois. Lattia on sinun.
Robin Bloor: OK. Tämä on mielenkiintoinen aihe. Ajattelin, että koska Dez jatkaa todennäköisesti tekniikoita ja sotatarinoita virheenkorjauksesta, ajattelin tehdä vain taustakeskustelun, jotta meidän pitäisi saada täysin pyöristetty kuva mitä tapahtuu. Tein tämän pitkään, ja minulla oli tapana olla koodaaja, niin kuin se oli, ja minulla oli melkein houkutus tämän esityksen kanssa aloittaa lyyrisen ajatuksen avoimen lähdekoodin ideasta, mutta luulin, että jätän sen jollekin muulle.
Tässä on luettelo kuuluisista virheistä, ja suurin osa niistä pääsee anybodien kärkiluetteloon, pohjimmiltaan kaikki, paitsi kaksi viimeistä, maksavat vähintään 100 miljoonaa dollaria. Ensimmäinen niistä oli Mars Climate Orbiter, eksyi avaruuteen ja johtui koodausongelmasta, jossa ihmiset sekoittivat metrijärjestelmän yksiköt (nauraa) jalkoihin ja tuumiin. Ariane Five Flight 501 -sovelluksessa oli epäsuhta asennetun moottorin ja tietokoneiden välillä, joiden piti ajaa rakettia, kun se käynnistettiin. Useita tietokonehäiriöitä, räjähtävä raketti, otsikkouutisia. Neuvostoliiton kaasuputken vuonna 1982 sanottiin olevan suurin räjähdys planeetan historiassa; En ole varma, onko se. Venäläiset varastivat joitain automatisoituja ohjausohjelmistoja, ja CIA huomasi aikovansa tehdä sen ja asettamaan virheitä, ja neuvosto toteutti sen ilman testausta. Joten puhalsi putkistoa ajatellen, että se oli hauskaa.
Morris-mato oli koodauskoe, josta tuli yhtäkkiä rapaattinen mato, joka kulki ikivihreiden ympäri - se ilmeisesti aiheutti 100 miljoonan dollarin arvosta vahinkoa; thats arvio tietenkin. Intel teki kuuluisan virheen matematiikkapiirillä - matematiikkaohjeet Pentium-sirulla vuonna 1993 -, jonka piti maksaa yli 100 miljoonaa dollaria. Apples Maps -ohjelma on mahdollisesti kaikkien aikojen pahin ja tuhoisin julkaisu, jota Apple on koskaan tehnyt. Ihmiset, jotka yrittivät sitä käyttää, olivat tarkoita, että joku ajoi pitkin 101: tä, ja huomasi Apple Mapin sanovan olevansa keskellä San Francisco-lahti. Joten ihmiset alkoivat viitata Apple Maps -sovellukseen nimellä iLost. - Pisin seisokkimme vuonna 1990 - se on vain mielenkiintoinen jotain sellaisen kustannusten kannalta - AT&T oli poissa noin yhdeksän tuntia ja se maksoi noin 60 miljoonaa dollaria kaukopuheluista.
Ja olin Yhdistyneessä kuningaskunnassa vakuutusyhtiössä, ja tietokanta, he ottivat käyttöön uuden version tietokannasta ja alkoivat pyyhkiä tietoja. Ja muistan sen erittäin hyvin, koska sen jälkeen minut kutsuttiin sisään osallistumaan jonkinlaiseen tietokantavalintaan. Ja oli erittäin mielenkiintoista, että he olivat ottaneet uuden version tietokannasta, ja heillä oli runsaasti testejä, jotka he tekivät tietokannan uusille versioille, että se läpäisi kaikki testit. Se löysi todella hämärtävän tavan tietojen pyyhkimiseen.
Joten joka tapauksessa, se. Ajattelin puhua impedanssien epäsuhtaista ja annetusta SQL: stä. On mielenkiintoista, että relaatiotietokannat tallentavat tietoja taulukoihin ja kooderit pyrkivät manipuloimaan dataa objektirakenteissa, jotka eivät todellakaan sovi taulukoihin. Ja sen takia saat mitä kutsutaan impedanssien epäsuhtaksi, ja jonkun on käsiteltävä sitä jollain tavalla. Mutta mitä todella tapahtuu, koska yhtä mallia, koodereiden mallia ja tietokannan toista mallia, ei ole erityisen yhdenmukaistettu. Saat virheitä, joita ei vain tapahdu, jos teollisuus olisi rakentanut yhdessä toimivia asioita, jotka ovat mielestäni hauskoja. Joten pohjimmiltaan, kooderien puolella, kun saat hierarkioita, se voi olla tyyppiä, se voi johtaa joukkoihin, se voi olla huono API-kyky, se voi olla paljon asioita, jotka vain heittävät asiat ulos tietokannan vuorovaikutuksessa. Mutta asia on minulle eniten, todella mielenkiintoinen; aina hämmästynyt minusta, että sinulla on tämä SQL-este, joka on myös eräänlainen impedanssi tavalla, että kooderit ja tietokanta toimivat keskenään. Joten, SQL: llä on tietojen tunnistaminen, mikä on hienoa, ja sillä on DML valintaa, projektia ja liittymistä varten, mikä on hienoa. Voit heittää paljon valmiuksia saada tietoja pois tietokannasta. Mutta sillä on hyvin vähän matemaattista kieltä asioiden tekemiseen. Siinä on vähän tätä ja toista, ja siinä on hyvin vähän aikaperusteisia juttuja. Ja siksi, SQL on puutteellinen tapa, jos haluat, tapa saada tietoja. Joten tietokantakaverit rakensivat tallennettuja menettelytapoja tietokantaan asumiseksi, ja syy siihen tallennetuille menettelyille oli se, että et todella halua heittää tietoja edestakaisin ohjelmaan.
Jotkin toiminnallisuuksista olivat erittäin tietospesifisiä, joten niiden ei tarvinnut vain viitata koskemattomuuteen ja asteittaisia poistoja ja vastaavia asioita, tietokanta hoiti kaiken äkillisen toiminnallisuuden lisäämisen tietokantaan, mikä tarkoitti tietysti, että sovellus voitaisiin jakaa kooderin ja itse tietokannan välillä. Ja se teki jonkinlaisten toimintojen toteuttamisen todella vaikeaksi ja siten alttiimmaksi virheille. Joten se on tietokantapelin toinen puoli, koska se tarkoittaa, että sinulla on ollut esimerkiksi paljon toteutuksia, että olen ollut mukana relaatiotietokannoissa, ja siinä on todella hirvittävä joukko koodeja, jotka istuvat tallennetuissa menettelyissä ja joita käsitellään erillään koodista, joka istuu sovelluksissa. Ja se tuntuu erittäin omituiselta joutumiselta, jonka pitäisi olla melko fiksu suorittamaan erilaisia asioita.
Ajattelin puhua myös tietokannan suorituskyvystä, koska suoritusvirheitä pidetään usein virheinä, mutta periaatteessa sinulla voi olla pullonkaula CPU: lla, muistissa, levyllä, verkossa ja sinulla voi olla suorituskykyongelmia lukituksen takia. Ajatuksena olisi, että kooderin ei todellakaan tarvinnut olla huolissaan suorituskyvystä ja tietokanta toimisi itse asiassa kohtuullisen hyvin. Sen pitäisi olla suunniteltu siten, että kooderin ei tarvitse tietää. Saat kuitenkin huonoa tietokantasuunnittelua, huonoa ohjelmasuunnittelua, saat samanaikaista työmäärän sekoittamista, mikä voi myös johtaa suorituskykyongelmiin. Saat kuormituksen tasapainotuksen, kapasiteetin suunnittelun, tiedon kasvun - mikä voi aiheuttaa tietokannan pysähtymisen tai hidastamisen. Mielenkiintoinen asia, kun tietokannat ovat lähes täynnä, ne hidastuvat. Ja voit saada tietokerrokset lisääntymään ja replikointitarpeeseen sekä varmuuskopiointiin ja palautukseen liittyvissä kysymyksissä. Joka tapauksessa, se on yleiskatsaus.
Ainoa asia, jonka haluaisin sanoa, on se, että tietokannan virheenkorjaus voi olla vain yhtä vaivalloista ja ei-triviaalia - ja sanon, että koska olen tehnyt paljon siitä - ja huomaat usein sen, kuten kaikki virheenkorjauksen tilanteet, joita olen koskaan kokenut. on, on ensimmäinen asia, jonka koskaan näet, on sotku. Ja sinun on yritettävä siirtyä sotkusta selvittämään, miten sotku tapahtui. Ja usein kun tarkastelet tietokantaongelmaa, kaikki tarkastelemasi tiedot ovat vioittuneita ja ajattelet: "Kuinka helvetti niin tapahtui?"
Joka tapauksessa aion siirtää Dezille, joka todennäköisesti sanoo enemmän viisauden sanoja kuin tulin. En tiedä miten välittää pallo sinulle, Dez.
Eric Kavanagh: Läpäin sen, odota, pidä kiinni.
Automaattinen ääni: Osallistujan linjat mykistetty.
Eric Kavanagh: Hyvä on, ripusta sekunnissa, anna minun antaa Dezille pallon.
Dez Blanchfield: Kiitos, Eric. Kyllä, tohtori Robin Bloor, olet todellakin oikeassa: tämä on aihe, elinikäinen bugbear, jos anteeksi pun, anteeksi, et voinut auttaa itseäni siinä. Toivottavasti näet ensimmäisen näytöni siellä, pahoittelut fontin kokoongelmasta yläosassa. Virheiden aihe on päivittäinen luento, monissa tapauksissa kokemukseni mukaan. Sen aihe on niin laaja ja laaja, joten keskityn kahteen avainalueeseen, erityisesti käsitteeseen, jota pidämme niin paljon virpana, mutta ohjelmointikysymyksenä. Uskon, että nykyään virheen käyttöönotto sinänsä tapahtuu yleensä integroiduissa kehitysympäristöissä, vaikka ne saattavat olla pitkäaikaisia virheitä. Mutta usein se on enemmän profilointikoodin tapausta ja mahdollista kirjoittaa toimiva koodi, jonka pitäisi olla virhe. Joten, otsikkani dia täällä, minulla oli tosiasiallisesti jäljennös tästä erittäin korkearesoluutiolla A3, mutta valitettavasti se tuhoutui talon muuton yhteydessä. Mutta tämä on käsinkirjoitettu muistiinpano ohjelmalomakkeelle noin vuodelta 1945, jossa väitetysti jotkut ihmiset Harvardin yliopistossa Yhdysvalloissa tekivät toisen koneen nimeltä Mark II. He vikasivat jotain ongelmaa yhteisellä kielellä, mutta yrittivät löytää vikaa, ja osoittautui, että mukana tuli jotain hiukan erilaista kuin mikä oli laitteisto ja oletettavasti ohjelmisto-ongelma.
Joten kaupunkimyytti on noin 9. syyskuutath, 1945, Harvardin yliopiston joukkue veti koneet erilleen, he tapasivat jotain, jota he kutsuivat “seitsemänkymmeneksi releeksi” - noina päivinä ohjelmointi tehtiin fyysisessä mielessä, te haavoititte koodin taulun ympärille, ja näin ohjelmoit tehokkaasti kone - ja he löysivät tämän välitysnumeron seitsemänkymmentä, siinä oli jotain vikaa, ja osoittautuu, että varsinainen termi "vika" syntyi, koska se oli kirjaimellisesti koi - väitetysti jonkin kuparilankapalan väliin oli koili kiilattu paikasta toiseen. Ja tarinan mukaan legendaarinen Grace Hopper otsikkoni otsikkona, ”ensimmäinen todellinen tapaus vian löytämisestä”, oli otsikko lainauksena.
Mutta kuten Robin korosti aikaisemmin ensimmäisessä diassaan, virheen käsite menee taaksepäin, koska voimme kuvitella ihmisten tekevän laskentaa, käsitteitä kuin korjaustiedosto. Termi “laastari” tuli tosiasiallisesta nauhapalasta, joka nauhataan reikäkortin reiän yli. Mutta kaiken asia tässä on, että termi “virheenkorjaus” tuli esiin tästä käsitteestä löytää vika fyysisestä koneesta.Ja siitä lähtien olemme käyttäneet tätä terminologiaa yrittäessään käsitellä ongelmia, joko ei niinkään koodauskysymyksinä ohjelmassa, joka ei käänny, vaan ohjelmassa, joka ei toimi hyvin. Ja nimenomaan sitä, ettei sitä ole profiloitu, löydä vain asioita, kuten loputtomat silmukit, jotka eivät mene minnekään.
Mutta meillä on myös skenaario, ja ajattelin asettaa pari hauskaa diaa ennen kuin pääsin yksityiskohtiin. Tässä on klassinen sarjakuva, nimeltään XKCD verkossa, ja sarjakuvapiirtäjällä on melko hauskoja näkymiä maailmasta. Ja nämä lapsesta nimeltä “Little Bobby Tables” ja hänen vanhempiensa nimittäin nimitti tämän nuoren pojan Robertiksi); Drop-taulukko Opiskelijat; - ja sen nimeltään, ja eräänlainen ”Hei, tässä on poikasi koulussa, jolla on joitain tietokonehäiriöitä”, ja vanhempi vastaa: “Voi rakas, rikkoiko hän jotain?” Ja opettaja sanoo: “No, tietyllä tavalla ”, ja opettaja kysyy,” nimititkö todella poikasi Robertiksi); DROP-PÖYTÄ Opiskelijat; -? ”Ja vanhempi sanoo:” Voi kyllä, pikku Bobby-taulukot, joita kutsumme hänelle. ”Joka tapauksessa he jatkavat sanovansa, että ovat menettäneet vuosien opiskelijarekisterit, toivottavasti olet onnellinen. Ja vastaus on: "No, sinun pitäisi puhdistaa ja puhdistaa tietokannan syötteet." Ja käytän sitä monta kertaa puhuaksemme joihinkin ongelmiin, joita meillä on asioiden löytämisessä koodilla, että usein koodi ei myöskään katso tietoja .
Toinen hauska, en tiedä onko tämä totta vai ei - epäilen sen väärentämistä - mutta taas se koskettaa myös hauskaa luustani. Joku vaihtaa auton etuosan rekisterikilven vastaavaan lausuntoon, joka aiheuttaa tietokantojen pudottamisen nopeuskameroissa ja niin edelleen, että vangitaan autojen rekisterikilvet. Ja viittaan siihen aina niin, että epäilen mitään ohjelmoijia ennakoivan heidän koodinsa osuutta ja suoritusta todellisella moottoriajoneuvolla, mutta en koskaan aliarvioi sitä - vihaisen geekin voimaa.
(Naurua)
Mutta tämä johtaa minut avainkohtaani, luulen, että se on, että voisimme kerran löytää virheen ja profiilikoodin pelkkinä kuolevaisina. Mutta olen erittäin sitä mieltä, että tuo aika on kulunut, ja kokemuksellisesti anekdoottisesti ensimmäisenäni - ja ikään ikään kauheasti, olen varma; Robin on tervetullut lyömään minua tästä hauskanpidolla - mutta historiallisesti Ive on peräisin taustasta 14-vuotiaana, joka vaeltaa kaupungin lopussa ja koputtaa Uudessa-Seelannissa sijaitsevan ”Data Com” -nimisen tietokeskuksen ovelle ja kysyä Voisin ansaita taskurahaa koulussa saamalla myöhässä linja-autolla kotiin, noin 25 km työmatkalle päivittäin, panemalla paperia ers: iin ja nauhoja nauha-asemiin ja olemalla vain yleinen järjestelmänvalvoja. Ja kummallista kyllä, he antoivat minulle työn. Mutta ajan myötä onnistuin pääsemään henkilöstöön ja löytämään ohjelmoijat ja tajusin, että rakastin koodausta ja kävin läpi skriptien ja erätyöiden suorittamisen prosessin, joka päivän päätteeksi on edelleen koodi. Sinun on kirjoitettava skriptit ja erätyöt, jotka näyttävät miniohjelmilta, ja sitten käydä läpi koko prosessi istua 3270-terminaalissa käsin.
Itse asiassa ensimmäinen kokemukseni oli teletyyppisellä päätelaitteella, joka oli oikeastaan 132 sarakkeen fyysinen er. Ajattele pohjimmiltaan kuin hyvin vanhaa kirjoituskoneet, joissa on paperia, joka vieritti sen läpi, koska heillä ei ollut CRT-putkea. Ja koodin virheenkorjaus siinä oli erittäin ei-triviaali asia, joten taipumus kirjoittaa kaikki koodisi käsin ja toimia sitten konekirjoittajana tekemällä parhaasi, ettei virheitä hiipiä, koska sen on erittäin turhauttavaa joutua sanomaan yhden rivin toimittaja mennä tiettyyn riviin ja sitten rivi ja kirjoita se sitten takaisin sisään. Mutta kerran kirjoitimme koodin ja thats kuinka me virheenkorjasimme, ja saimme siitä erittäin, erittäin hyvää. Ja itse asiassa se pakotti meitä olemaan erittäin hyviä ohjelmointitekniikoita, koska sen korjaaminen oli todellinen vaivaa. Mutta matka meni sitten läpi - ja he olivat kaikki tuttuja - se siirtyi maailmani 3270-terminaalikokemuksesta Digital Equipment VT220: een, jossa voit nähdä asioita ruudulla, mutta taas teet vain samaa asiaa kuin sinäkin paperinauhalle erään tyyppisessä ed-muodossa vain CRT: llä, mutta pystyit poistamaan helpommin ja sinulla ei ollut sitä ”ääni” -momenttia.
Ja sitten tiedät, Wyse-päätelaitteet - kuten Wyse 150, todennäköisesti kaikkien aikojen suosikkiliittymäni tietokoneeseen - ja sitten tietokone ja sitten Mac, ja sitten nykyään modernit web-pohjaiset käyttöliittymät ja tunnukset. Ja valikoima ohjelmia sen kautta, ohjelmointi yhdellä ja kokoonpanijalla sekä PILOT ja Logo ja Lisp ja ja Fortran ja Pascal sekä kielet, jotka saattavat saada ihmiset kuristamaan. Mutta nämä ovat kielet, jotka pakottivat sinua kirjoittamaan hyvän koodin; he eivät antaneet sinun päästä eroon huonoista käytännöistä. C, C ++, Java, Ruby, Python - ja nousemme kauempana siitä ohjelmointivaiheesta, saamme enemmän komentosarjan kaltaisia, pääsemme lähemmäksi jäsenneltyä kyselykieltä ja kieliä kuten PHP, joita tosiasiassa käytetään kutsumaan SQL: tä. Tarkoituksena on kertoa teille, että lähtöisin taustastani, ja olen itseopiskellut monin tavoin, ja ne, jotka auttoivat minua oppimaan, opettivat minulle erittäin hyviä ohjelmointikäytäntöjä ja erittäin hyviä käytäntöjä suunnittelun ja prosessien suhteen varmistaakseni, että en ottanut käyttöön bugista koodi.
Ohjelmointimenetelmiä ovat nykyään esimerkiksi strukturoitu kyselykieli, SQL, erittäin tehokas ja yksinkertainen kyselykieli. Mutta olemme muuttaneet sen ohjelmointikieleksi, enkä todellakaan usko, että SQL oli koskaan suunniteltu nykyaikaiseksi ohjelmointikieleksi, mutta olemme väärässä siitä, että siitä tulee se. Ja se tuo käyttöön kokonaisen joukon kysymyksiä, jotka aiheutuvat ajatellessamme kahta näkökulmaa: koodauksen ja DBA: n näkökulmasta. Se on erittäin helppo tulla mukaan ja esitellä virheitä esimerkiksi huonoista ohjelmointitekniikoista, laiskoista ponnisteluista koodin kirjoittamisessa, kokemuksen puuttuminen, klassinen lemmikkikakkuna, joka olen esimerkiksi SQL-ihmisten kanssa hyppäämässä Googlessa ja etsimässä jotain ja etsimällä verkkosivustoa sai esimerkin ja kopioi ja liitä olemassa oleva koodi. Ja sitten replikoida huono koodaus, väärinkäytökset ja saattaa se tuotantoon, koska se sattuu vain antamaan heille haluamansa tulokset. Sinulla on muita haasteita, esimerkiksi näinä päivinä kaikki kiirehtiä kohti tätä, jota kutsumme kilpailuksi nollaan: yritetään tehdä kaikki niin halvalla ja niin nopeasti, että meillä on skenaario, jossa emme palkkaa matalapalkkaisia työntekijöitä. En tarkoita sitä epämääräisellä tavalla, mutta en palkannut asiantuntijoita kaikkiin mahdollisiin töihin. Aika aikoina mitään tekemistä tietokoneiden kanssa oli rakettitiede; se oli mukana asioissa, jotka menivät räjähtävästi ja olivat erittäin kovia tai menivät avaruuteen tai insinöörit olivat erittäin päteviä miehiä ja naisia, jotka olivat suorittaneet tutkintoja ja joilla oli tiukat koulutukset, jotka estävät heitä tekemästä hulluja asioita.
Nykyään siellä on paljon kehitystyöhön ja suunnitteluun ja tietokantaan liittyviä ihmisiä, joilla ei ole ollut vuosien kokemusta, joilla ei ole välttämättä ole samaa koulutusta tai tukea. Ja niin päätät skenaariosta, jossa vain perinteinen amatööri vastaan asiantuntija. Ja siellä kuuluisa linja, en todellakaan muista, kuka lainasi tarjouksen, linja kuuluu: ”Jos luulet, että asiantuntijan palkkaaminen on kallista, odota, kunnes palkkaat pari amatööriä, jotka aiheuttavat ongelman, ja sinun on puhdista se. ”Ja niin SQL: llä on asia, ja se on erittäin helppo oppia ja erittäin helppo käyttää. Mutta se ei mielestäni ole täydellinen ohjelmointikieli. Sen avulla on erittäin helppo tehdä asioita, kuten tehdä valittu tähti mistä tahansa ja vetää kaikki ohjelmointikielelle, joka on mukavampaa, kuten PHP, Ruby tai Python, ja käyttää tietojen manipulointiin alun perin tuttua ohjelmointikieltä. sen sijaan, että suorittaa monimutkaisempi kysely SQL: ssä. Ja näemme tämän paljon, ja sitten ihmiset ihmettelevät, miksi tietokanta toimii hitaasti; sen takia, että miljoona ihmistä yrittää ostaa lipun online-lippujärjestelmästä, jossa se valitsee tähden mistä tahansa.
Nyt tämä on todella äärimmäinen esimerkki, mutta saat kaiken tämän esiin. Joten, jotta pystymme oikein lyömään tämän pisteen kotiin, tässä on esimerkki, jota kannan paljon. Olen suuri matematiikan fani, rakastan kaaoksen teoriaa, rakastan Mandelbrot-sarjoja. Oikealla puolella on Mandelbrot-sarjan luovutus, jonka varmasti kaikki tunsivat. Ja vasemmalla puolella Theres SQL, joka tosiasiallisesti tuottaa sen. Nyt joka kerta, kun laitan tämän näytölle jonnekin, kuulen tämän: "Voi luoja, joku antoi Mandelbrot-sarjan SQL: llä, oletko tosissasi? Se on hullua! ”No, kaiken asia on havainnollistaa mitä juuri hahmottelin siellä, ja se on kyllä, itse asiassa voit nyt ohjelmoida melkein mitä tahansa SQL: ssä; sen erittäin vahvasti kehitetty, tehokas, moderni ohjelmointikieli. Alun perin se oli kyselykieli, ja sen tarkoituksena oli vain saada tietoja ylöspäin. Joten nyt meillä on erittäin monimutkaisia rakenteita ja meillä on tallennettuja menettelytapoja, ohjelmointimenetelmiä on sovellettu kielelle ja niin, että se on erittäin helppoa huonoille ohjelmointikäytännöille, kokemuksen puutteelle, leikkaa ja liitä -koodille, matalapalkkaisille työntekijöille, jotka yrittävät olla korkeasti palkattua henkilöstöä, ihmiset teeskentelevät tietävänsä, mutta heidän on opittava työssä.
Koko joukko asioita, joissa koodin profilointi ja jota kutsumme virheenkorjaukseksi, joka ei ole niinkään virheiden löytämistä, jotka estävät ohjelmien toimimasta, mutta virheitä, jotka vain vahingoittavat järjestelmää, ja huonosti rakennettua koodia. Kun katselet tätä näyttöä nyt ja luulet, että se on juuri sellaista söpöä ja ajattelet: "Vau, mikä loistava grafiikka, haluaisin ajaa sen." Mutta kuvittele, että juoksu jollain liiketoimintalogiikalla. Se näyttää melko siistiltä, mutta puhuu matemaattisesti graafisesti muodostettua kaaosteoriaa, mutta kun mietit, mihin sitä voitaisiin käyttää jossain liiketoimintalogiikassa, saat kuvan erittäin nopeasti. Ja sen havainnollistamiseksi - ja pahoillani, että värit ovat päinvastaisia, sen pitäisi olla musta tausta ja vihreä olla vihreä näyttö, mutta voit silti lukea sen.
Kävin katsomassa nopeasti esimerkkiä siitä, mitä voisit tehdä, jos olisit todella hullu ja sinulla ei olisi minkäänlaista kokemusta ja tulisit erilaiselta ohjelmoinnin taustalta ja sovellamme C ++: n kaltaisia ominaisuuksia SQL: iin havainnollistaakseni asiaani ennen Annan opitun IDERA-vieraamme vierellemme. Tämä on jäsennelty kysely, joka on kirjoitettu kuten C ++, mutta koodattu SQL: ään. Ja se tosiasiallisesti suorittaa, mutta se suorittaa noin kolmesta viiteen minuuttiin. Ja se vetää näennäisesti yhden tietorivin pois useista tietokannoista, useista liittymistä.
Koko asia tässä on, että jos sinulla ei ole oikeita työkaluja, jos sinulla ei ole oikeita alustoja ja ympäristöjä, jotta pystyt tarttumaan näihin asioihin, ja ne siirtyvät tuotantoon, ja silloin sinulla on 100 000 ihmistä, joka lyö järjestelmään jokainen Päivä, tunti tai minuutti, päädyt pian Tšernobylin kokemukseen, jossa iso rauta alkaa sulaa ja haudata itsensä planeetan ytimeen, koska kyseisen koodin palan ei pitäisi koskaan päästä tuotantoon. Anteeksi, järjestelmäsi ja työkalusi tulisi poimia, ennen kuin se menee mihinkään läheisyyteen - jopa testiprosessin kautta, jopa UAT: n ja järjestelmien integroinnin kautta, tämä koodinpätkä on poimittava ja korostettava ja joku on tuotava syrjään ja sanomalla: "Katso, se on todella hieno koodi, mutta antaa DBA: n auttaa rakentamaan tuon strukturoidun kyselyn oikein, koska rehellisesti sanottuna, se on vain ilkeää." Ja siellä olevat URL-osoitteet voit käydä katsomassa - siihen viitataan nimellä monimutkaisin SQL-kysely, jonka olet koskaan kirjoittanut. Koska usko minua, se tosiasiassa kääntää, se suorittaa. Ja jos leikkaa ja liitä se ja vain pilkata tietokantaa, se on aika katsottavaa; Jos sinulla on työkaluja tietokannan katselemiseen, yritä vain sulattaa kolmesta viiteen minuuttiin, soittaaksesi takaisin, mikä on yksi rivi.
Joten tiivistääkseni koko tätä asiaa koodaamisen taustani on opettanut minulle, että voit antaa ihmisille aseen ja jos he eivät ole varovaisia, he ampuvat itsensä jalkaan; temppu on näyttää heille, missä turvamekanismi on. Oikeiden työkalujen ja oikeiden ohjelmistojen ulottuvilla, koodauksen jälkeen, voit tarkistaa koodisi, löytää ongelmia profiloimalla koodin, löytää tehokkaasti tahattomia virheitä, jotka ovat suorituskykyongelmia, ja kuten aiemmin sanoin Voit kerran tehdä sen katsomalla vihreää näyttöä. Et voi enää; koodisatoja on satoja tuhansia, kymmeniä tuhansia sovelluksia on käytössä, joissain tapauksissa on miljoonia tietokantoja, ja jopa super-ihmiset eivät voi tehdä tätä enää käsin. Tarvitset aivan kirjaimellisesti oikeita ohjelmistoja ja oikeita työkaluja sormenpäässäsi ja tarvitset ryhmää käyttämään näitä työkaluja, jotta voit löytää nämä ongelmat ja puuttua niihin erittäin nopeasti, ennen kuin pääset asiaan, kun taas Dr. Robin Bloor korosti, asiat joko muuttuvat tuhoisiksi ja asiat räjähtävät, tai yleisemmin, ne vain alkavat maksaa sinulle paljon dollareita, paljon aikaa ja vaivaa ja tuhota moraalia ja tavaraa, kun he eivät pysty selvittämään, miksi asiat vievät pitkä aika juosta.
Ja pitäen tämän mielessä, aion luovuttaa vieraillemme ja odotan innolla kuulevani, kuinka he ratkaisivat asian. Ja etenkin demo, jonka luulen saavani. Eric, palaa takaisin.
Eric Kavanagh: OK, Bert, vie se pois.
Bert Scalzo: OK kiitos. Bert Scalzo täältä IDERA: lta, olen tietokantatyökaluidemme tuotepäällikkö. Ja aion puhua virheenkorjauksesta. Mielestäni yksi tärkeimmistä asioista, jotka Robin sanoi aiemmin - ja sen totta on, että virheenkorjaus on vaivalloista ja ei-triviaalia, ja kun siirryt tietokannan virheenkorjaukseen, sen suuruusluokka on vieläkin vaivalloisempaa ja ei-triviaalia - niin, että oli tärkeä tarjous.
OK. Halusin aloittaa ohjelmointihistorian kanssa, koska monta kertaa näen ihmisiä, jotka eivät tee virheenkorjausta, he eivät käytä debuggeria, he vain ohjelmoivat millä tahansa kielellä, jota he käyttävät, ja monta kertaa he sanovat minulle: "No, nuo virheenkorjaustoimenpiteet ovat uusia, ja emme ole vielä alkaneet käyttää niitä. ”Ja niin teen, että näytän heille tämän aikajanakaavion, eräänlaisen esihistorian, vanhuuden, keskiajan, sen sanonnosta missä olimme ohjelmointikielten ehdot. Ja meillä oli hyvin vanhoja kieliä vuodesta 1951 alkaen kokoonpanokoodilla, ja Lisp, FACT ja COBOL. Sitten siirrymme seuraavaan ryhmään, Pascals ja Cs, ja sitten seuraavaan ryhmään, C ++ -ryhmiin, ja katsomme, missä kyseinen kysymysmerkki on - kyseinen kysymysmerkki on suunnilleen oikea vuosien 1978 ja 1980 välillä. Jotain sillä alueella meillä oli virheenkorjaimet, jotka ovat käytettävissämme, ja niin sanoakseni: "Hei, en käytä debuggeria, sillä se on yksi näistä uusista asioista", sinun on jo aloitettu ohjelmointi, tiedät, jo 1950-luvulla, koska se on ainoa tapa, jolla pääset poissa vaatimuksesta.
Nyt toinen asia, joka on hauska tässä kaaviossa, on Dez juuri kommentoinut Grace Hopperia, tiesin todella Gracen, joten se oli sellainen hauska. Ja sitten toinen asia, josta nauroin, on se, että hän puhui tyyppityypeistä ja siellä istuvasta menemästä: "Ihminen, se oli suurin hyppy, joka meillä koskaan ollut tuottavuudessa, kun siirryimme korteista teletyyppeihin, se oli kaikkien aikojen suurin hyppy." , ja Ive on ohjelmoinut kaikilla täällä olevilla kielillä, mukaan lukien SNOBOL, josta kukaan ei ole koskaan kuullut. Se oli CDC, Control Data Corporation, joten kai olen ikäänkuin hieman liian vanha alalle.
Dez Blanchfield: Aioin sanoa, että olet ikäissyt meidät kauheasti siellä.
Bert Scalzo: Joo, kerron sinulle, tunnen olevani isoisä Simpson. Joten tarkastelen virheenkorjausta ja erilaisia tapoja virheenkorjaukseen. Voisit puhua siitä, mitä me kaikki ajattelemme perinteiseksi pääsyksi virheenkorjaimeen ja askelemaan läpi koodin. Mutta myös ihmiset opettavat koodinsa; Siinä, kun kiinnität lauseita koodiin ja ehkä tuotat tulostetiedoston, jäljitetiedoston tai jotain, ja niin instrumentit koodisi. Luulen, että virheenkorjauksena on vähän vaikeampi tapa tehdä se, mutta se on tärkeätä. Mutta saimme myös kuuluisan lausunnon: katsot ja ihmiset tosiasiallisesti laittavat lausuntoja ja olen todella nähnyt työkalun, jossa - ja sen tietokantatyökalun - missä et tiedä kuinka käyttää virheenkorjainta, painat painiketta ja se pysyy kiinni. lauseet koko koodissasi sinulle ja sitten kun olet valmis, painat toista painiketta ja se poistaa ne. Koska totta, kuinka monet ihmiset tekevät virheen.
Syy, jonka vuoksi virheenkorjausta on kaksi: ensinnäkin, meidän on löydettävä asioita, jotka tekevät koodistamme tehottoman. Toisin sanoen, tyypillisesti tämä tarkoittaa, että kyseessä on logiikkavirhe tai että olemme jättäneet yritystoimintaa koskevan vaatimuksen huomiotta, mutta mikä se on, on, että koodi ei ole tehokas; Se ei tee sitä, mitä odotimme sen tekevän. Toinen kerta, kun menemme ja teemme virheenkorjausta, sen tehokkuus ja se voi olla logiikkavirhe, mutta mikä on, olenko tehnyt oikein, se ei vain palaudu tarpeeksi nopeasti. Nyt teen tämän huomautuksen, koska profiloijat ovat luultavasti parempia toiselle skenaariossa ja aikoivat puhua sekä virheenkorjajista että profiileista. Lisäksi tämä etävirheen käsite on olemassa; tämä on tärkeää, koska jos istuit tietokoneellasi ja käytät virheenkorjainta, joka osuu tietokantaan, jossa koodi tosiasiallisesti suoritetaan tietokantaan, et todellakin tee etävirheenkorjausta. Et ehkä ymmärrä sitä, mutta se mitä tapahtuu. Ja sitten, näiden virheenkorjaimien kanssa on hyvin yleistä saada murtopisteitä, katsella pisteitä, astua sisään ja astua yli ja joitain muita yleisiä asioita, joita aion näyttää näytöllä hetkessä oleville.
Nyt profilointi: voit tehdä profiloinnin parilla eri tavalla. Jotkut sanovat, että työkuorman sieppaaminen ja toisto siellä, missä se kaappaa kaiken, mikä lasketaan profilointiin. Kokemukseni on ollut sen parempaa, jos sen näytteenotto on tehty. Ei ole mitään syytä kiinni jokaisesta lausunnosta, koska jotkut lauseet voivat vain ajaa niin nopeasti, että et välitä, mitä todella yrität nähdä, hyvin, mitkä ovat niitä, jotka näytetään jatkuvasti uudestaan ja uudestaan, koska ne ajavat liian kauan . Joten joskus profilointi voi tarkoittaa näytteenottoa pikemminkin kuin koko asian ajamista. Ja tyypillisesti saat jonkinlaista lähtöä, jota voit käyttää, nyt se voi olla visuaalinen IDE-kehitysympäristössä, missä se saattaa antaa sinulle kuin histogrammin koodirivien suorituskyvystä, mutta se voisi silti myös olkoon, että se tuottaa jäljitetiedoston.
Profiilit ilmestyivät ensimmäisen kerran vuonna 1979. Joten ne ovat olleet olemassa jo pitkään. Erinomainen resurssien kulutus- tai suorituskykyongelmien löytämiseen, toisin sanoen tehokkuuden asiaan. Yleisesti ottaen se on erillinen ja erillinen virheenkorjaimesta, vaikka olen työskennellyt virheenkorjaimien kanssa, jotka tekevät molemmat samanaikaisesti. Ja vaikka profiilittajat ovat mielestäni mielenkiintoisimpia kahdesta työkalusta, jos minusta tuntuu, että virheitä ei ole tarpeeksi, silloin ei ehdottomasti ole tarpeeksi ihmisten profiileja, koska yksi kymmenestä virheenkorjaimesta tulee profiilille, näyttää. Ja se on sääli, koska profiloinnilla voi todella olla valtava ero. Nyt tietokantakielet, kuten aiemmin puhuttiin, sinulla on SQL - ja pakotimme eräänlainen pyöreän tapin täällä olevaan neliön reikään ja pakotimme siitä tulemaan ohjelmointikielen - ja Oraclen.Että PL / SQL - tämä on menettelykieli SQL - ja SQL Server, sen Transact-SQL, sen SQL-99, sen SQL / PSM - mielestäni sen menettelytallennetulle moduulille. Postgres antaa sille toisen nimen, DB2 vielä toisen nimen, Informix, mutta asia on, että kaikki ovat pakottaneet 3GL-tyyppiset rakenteet; toisin sanoen FOR-silmukat, muuttujien ilmoituksissa ja kaikki muut SQL: lle vieraat asiat ovat nyt osa SQL: ää näillä kielillä. Ja niin, sinun on pystyttävä vikaamaan PL / SQL tai Transact-SQL aivan kuten Visual Basic -ohjelma.
Nyt tietokantaobjektit, tämä on tärkeää, koska ihmiset sanovat: ”No, mitä asioita minun täytyy korjata tietokannasta?” Ja vastaus on, mitä tahansa, mitä voit tallentaa tietokantaan koodina - jos teen T- SQL tai PL / SQL - ja Im-kohteiden tallentaminen tietokantaan, sen todennäköisesti tallennettu menettely tai tallennettu toiminto. Mutta Theres laukaisee myös: liipaisin on tavallaan kuin tallennettu menettely, mutta se laukaisee jonkinlaista tapahtumaa. Nyt jotkut ihmiset liipaisimissaan laittavat yhden koodirivin ja kutsuvat tallennetun proseduurin niin, että he pitävät kaikki tallennetut koodinsa ja proseduurinsa, mutta se on sama käsite: sen liipaisin voi silti olla mikä aloittaa koko asian. Ja sitten Oraclena heillä on jotain nimeltään paketti, joka on tavallaan kuin kirjasto, jos haluat. Laitat 50 tai 100 tallennettua menettelyä yhdeksi ryhmäksi, jota kutsutaan paketiksi, joten se on kuin kirjasto. Joten, täällä debugger on vanha tapa; tämä on oikeastaan työkalu, joka menee sisään ja kiinnittää kaikki nämä virheenkorjauslauseet koodiin sinulle. Joten, kaikkialla, missä näet virheenkorjauksen esteen, älä poista, automaattinen virheenkorjauksen käynnistys ja jäljitys, ne kaikki olivat jonkun työkalun jumissa. Ja sen ulkopuolella olevat rivit, mikä on koodin vähemmistö, tarkoittavat hyvin ei-manuaalista virheenkorjaustapaa.
Ja syyn siihen, että tuon tämän esiin, on se, että jos yrität tehdä tämän käsin, aiot tosiasiallisesti kirjoittaa enemmän virheenkorjauskoodia laittaaksesi kaikki nämä lausunnot kuin olet koodin kanssa. Joten vaikka tämä saattaa toimia, ja vaikka se onkin parempi kuin ei mitään, tämä on erittäin vaikea tapa korjata virhe, varsinkin kun, entä jos tämän asian suorittamiseen kuluu 10 tuntia, ja jos sillä on ongelma, se on rivillä kolme? Jos tekisin vuorovaikutteisen virheenkorjauksen, olisin tiennyt sen riviltä kolme - viisi minuuttia siihen - hei, tässä on ongelma, voin lopettaa. Mutta tämän avulla Ive joutui odottamaan sen suorittamista, loppuun saakka, ja sitten Ive joutui katsomaan jotain jäljitetiedostoa, jossa todennäköisesti on kaikki nämä lausunnot, ja yrittämään löytää neula heinäsuovasta. Tämä on jälleen parempi kuin ei mitään, mutta se ei olisi paras tapa toimia. Nyt tämä tiedosto näyttää siltä, että se tuli aiemmasta diasta; Toisin sanoen suoritin ohjelmaa, ja se sai juuri joukon lauseita tähän jäljitystiedostoon ja voin ehkä olla, että en voi sifonkiida tämän läpi ja löytää sen, mitä minun on löydettävä. Joten jälleen kerran, en ole niin varma, että haluaisit työskennellä tällä tavalla.
Nyt vuorovaikutteiset virheenkorjaimet - ja jos olet käyttänyt jotain Visual Studiota ohjelmien kirjoittamiseen tai Eclipseä, sinulla on ollut virheenkorjauksia ja käytit niitä muiden kielten kanssa - et vain ajatellut käyttää niitä täällä tietokantaasi. Ja siellä on työkaluja, kuten DB Artisan ja Rapid SQL, tämä on täällä Rapid SQL, joilla on debugger, ja voit nähdä vasemmalla puolella, minulla on tallennettu menettely nimeltä “check for duplicates”. Periaatteessa se vain menee katsomaan, onko minulla taulukossa useita rivejä, joilla on sama elokuvan nimi. Joten, tietokanta on elokuville. Ja voit nähdä oikealla puolella, yläosassa kolmannen, Ive sai lähdekoodini keskelle, Ive sai niin kutsutut kellomuuttujat ja puhelupinoalustani, ja sitten alhaalta Ive sai joitain lähtöjä. Ja mikä tärkeätä tässä, on, jos tarkastellaan ensimmäistä punaista nuolta, hiiren osoittimen ollessa muuttujan yläpuolella, voin tosiasiallisesti nähdä, mikä arvo kyseisessä muuttujassa on tuona ajankohtana, kun olen askelmassa koodin läpi. Ja se on todella hyödyllistä, ja sitten voin siirtyä yhden rivin kerrallaan koodin läpi, minun ei tarvitse sanoa suorittaa, voisin sanoa askel linjan, anna minun katsoa mitä tapahtui, askel toisen rivin, anna minun nähdä mitä tapahtui, ja Teen tämän tietokantaan. Ja vaikka istun Rapid SQL: llä tietokoneellani ja tietokanta on ylös pilvessä, voin silti tehdä etävirheen ja nähdä sen ja hallita sitä täältä, ja tehdä virheenkorjauksia aivan kuten haluaisin millä tahansa muulla kielellä.
Nyt seuraava nuoli siellä - näet pienen kuin nuolen osoittaen oikealle, kohti sitä DBMS-lähtöä, eli siinä, missä kohdistin on tällä hetkellä - eli toisin sanoen, Ive astui ja on siinä, missä olen tällä hetkellä. Joten jos sanon: "Astu uudestaan", aion siirtyä seuraavalle riville. Nyt juuri sen alapuolella näet punaisen pisteen. No, se on tauonpiste, joka sanoo: "Hei, en halua astua näiden linjojen yli." Jos haluan vain hypätä kaiken yli ja päästä sinne, missä punainen piste on, voin painaa käynnistyspainiketta ja ajaa täältä joko loppuun tai murtopisteeseen, jos jollekin on asetettu raja-arvoja, ja sitten se pysähtyy ja antaa minun tehdä askel uudelleen. Ja syy siihen, että kaikki tämä on tärkeä ja voimakas, johtuu siitä, että kun teen kaiken tämän, keskellä ja jopa alaosassa tapahtuvat seikat - mutta mikä tärkeintä keskellä - muuttuvat ja näen muuttujien arvot, voin näet puhelupinon jäljen, tiedät, ja niin kaikki nämä tiedot näkyvät siellä, kun astuin läpi koodin, joten pystyn tosiasiallisesti näkemään ja tuntemaan ja ymmärtämään mitä tapahtuu ja kuinka koodi todella toimii suoritushetkellä . Ja tyypillisesti voin löytää ongelman, jos sellainen on tai jos olen riittävän hyvä tarttumaan siihen.
OK, nyt aion puhua profiilintekijästä, ja tässä tapauksessa tämä on profiili, jonka näen vianetsinnän kautta. Muista, että sanoin joskus olevan erillisiä ja joskus he voivat olla yhdessä? Tässä tapauksessa, ja jälleen kerran, olen Rapid SQL: ssä, ja näen vasemmalla puolella olevan marginaalin rivinumeroiden vieressä. Ja mitä se on, on se sekuntien tai mikrosekuntien lukumäärä, joka kului kunkin koodirivin suorittamiseen, ja voin nähdä, että selvästi koko ajan vietetään tässä FOR-silmukassa, jossa valitsen kaiken taulukosta. Ja niin, kyseisen FOR-silmukan sisällä tapahtuvia kosteutta on todennäköisesti jotain, jota minun on tarkasteltava, ja jos voin tehdä siitä paremman, se maksaa osinkoja. En aio saada parannuksia työskentelemällä linjoilla, joilla on esimerkiksi 0,90 tai 0,86; siellä ei ole vietetty paljon aikaa. Nyt, tässä tapauksessa ja jälleen kerran, olen Rapid SQL: ssä, näet kuinka voin tehdä profiloinnin sekoittuneena virheenkorjaukseen. Nyt, mikä hienoa, Rapid SQL antaa sinun tehdä sen myös toisin. Rapid SQL antaa sinun sanoa: “Tiedätkö mitä? En halua olla virheenkorjaimessa, haluan vain suorittaa tämän ja haluan sitten tarkastella graafisesti tai visuaalisesti samantyyppisiä tietoja. ”
Ja voit nähdä, että en ole enää virheenkorjaimessa ja se ajaa ohjelmaa, ja suorituksen jälkeen se antaa minulle kaavioita kertoa minulle asioita, jotta voin nähdä, että Ive sai yhden lausunnon, joka näyttää siltä, että se ottaa suurimman osan piirakasta. kaavio, ja jos katson, näen siinä ruudussa alaosaa, riviä 23, näkyy FOR-silmukka taas: hän ottaa eniten aikaa, hän on itse asiassa tummanpunainen pureskella kaikkia ympyräkaavioita. Ja niin, tämä on toinen tapa tehdä profilointi. Kutsumme sitä "Code Analyst" -työkaluomme. Mutta se on pohjimmiltaan vain virheenkorjaimesta erotettu profiloija. Jotkut ihmiset haluavat tehdä sen ensimmäisellä tavalla, toiset haluavat tehdä sen toisella tavalla.
Miksi teemme virheenkorjausta ja profilointia? Se ei siksi, että haluamme kirjoittaa maailman suurimman koodin ja saada palkankorotusta - se saattaa olla syy, mutta se ei oikeastaan ole miksi teet sen - lupasit yritykselle, että teet jotain oikein, että ohjelmasi on tehokas. Siinä käytetään virheenkorjainta. Lisäksi liiketoiminnan loppukäyttäjät; he eivät ole kovin kärsivällisiä: he haluavat tuloksia jo ennen kuin he painavat näppäintä. Piti lukea heidän mielensä ja tehdä kaiken heti. Toisin sanoen sen on oltava tehokas. Ja niin, thats mitä me käyttäisimme profiler. Nyt ilman näitä työkaluja uskon todella, että olet tämä kaveri työpukuissa jousella ja nuolella, ampuvat kohteeseen ja olet silmät silmät. Koska miten löydät kuinka ohjelma suorittaa vain katsomalla staattista koodia ja miten aiot selvittää mikä rivi on, missä se todella viettäisi eniten aikaa suorittamisessa, taas katsomalla staattista koodia? Kooditarkistus saattaa johtaa tai ei välttämättä osoittaa joitain näistä asioista, mutta mikään ei takaa, että koodikatsaus löytäisi ne kaikki. Virheenkorjainta ja profiilinmääritystä käyttämällä sinun pitäisi pystyä löytämään kaikki nämä virheet.
OK, aion tehdä täällä todella nopean esittelyn. Se ei ole aikomukseni levittää tuotetta, haluan vain näyttää sinulle, millainen virheenkorjaaja näyttää aiheuttavan monta kertaa, että ihmiset sanovat: ”En ole koskaan nähnyt yhtä näistä aikaisemmin.” Ja se näyttää kauniilta näytön napsautus dioilla, mutta mitä näyttääkö se liikkeellä ollessaan? Joten, näytölläni näytän DB Artisan -tuotetta; meillä on myös virheenkorjain siellä. DB Artisan on tarkoitettu enemmän DBA: lle, Rapid SQL on enemmän kehittäjille, mutta olen nähnyt kehittäjiä, jotka käyttävät DB Artisania, ja olen nähnyt DBA: ita, jotka käyttävät Rapidia. Joten, älä kiinni tuotteeseen. Ja täällä, minulla on mahdollisuus tehdä virheenkorjaus, mutta ennen kuin käynnistän virheenkorjauksen, aion purkaa tämän koodin, jotta voit nähdä, miltä koodi näyttää, ennen kuin aloitan sen suorittamisen. Joten, tässä on täsmälleen sama koodi, joka oli näytön tilannekuvassa, tämä on minun tarkistukseni jäljennökset. Ja haluan debugin tämän, joten painan debug. Ja nyt, se vie hetken ja sanot: “No, miksi se vie hetken?” Muista etävirhe: virheenkorjaus tapahtuu tosiasiallisesti tietokantapalvelimellani, ei tietokoneellani. Joten sen oli mentävä yli ja luotava siellä istunto, luotava etävirheen aihe, kytkettävä istuntoni siihen etävirheenkorjausistuntoon ja perustettava viestintäkanava.
Joten, täällä nuoleni, sen yläreunassa, rivillä yksi, thats missä olen koodissa. Ja jos painan kolmatta kuvaketta siellä, mikä on askel sisään, näet nuolen juuri liikkuvan, ja jos painan sitä edelleen, näet sen liikkuvat. Nyt, jos halusin mennä alas tälle FOR-silmukalle, koska tiedän, että ongelmassa on, voin asettaa väliajan. Ajattelin asettaa sen. Voi ampua, minulla oli yksi näytönkaappausnäppäimistä, jotka oli kartoitettu samaan avaimeen kuin virheenkorjaaja, mikä aiheuttaa sekaannusta. Okei, joten asetan vain manuaalisesti väliaikaisen pisteen sinne, joten nyt sen sijaan, että tein askel, askel, askel, askel, kunnes pääsen sinne, oikeastaan voin sanoa vain: "Mene eteenpäin ja aja tämä asia", ja se pysähtyy. Huomaa, että se on siirtänyt minut aina siihen kohtaan, missä murtopiste on, joten olen nyt joutumassa käyttämään tätä silmukkaa, näen mihin kaikki muuttujat on asetettu, mikä ei ole yllätys, koska aloitin ne kaikki nolla. Ja nyt voin astua tähän silmukkaan ja alkaa tarkastella mitä tapahtuu tämän silmukan sisällä.
Joten nyt se aikoo tehdä tietyn määrän vuokralaisistani ja voin hiirellä sen kaverin päälle ja katsoa, hes kaksi, kaksi on suurempi kuin yksi, joten se todennäköisesti aikoo tehdä seuraavan kappaleen tästä koodista. Toisin sanoen, se löysi jotain. Aion vain mennä eteenpäin ja antaa sen ajaa. En halua käydä läpi kaikkea täällä; haluan näyttää sinulle, että kun virheenkorjaaja on valmis, se päättyy aivan kuten normaali ohjelma. Ive sai raja-arvon asetettu, joten kun sanoin juosta, se vain palasi seuraavaan tauon pisteeseen. Annan sen ajaa loppuun, koska haluan, että näet, että virheenkorjain ei muuta ohjelman käyttäytymistä: Kun se oli suoritettu käynnissä, minun pitäisi saada täsmälleen samat tulokset, jos olisin ajaa sitä ei virheenkorjaimen sisällä.
Ja sen avulla keskeytän demon ja palaan takaisin, koska haluamme varmistaa, että meillä on aikaa kysymyksiin ja vastauksiin. Joten aion sen avata kysymyksille ja vastauksille.
Eric Kavanagh: Hyvä on, Robin, ehkä kysymys sinulta ja sitten pari Deziltä?
Robin Bloor: Joo, varmasti, minusta tämä on kiehtovaa tietenkin. Ive työskenteli tällaisten asioiden kanssa, mutta Ive ei koskaan työskennellyt mitään tällaista tietokannassa. Voitteko antaa minulle kuvan siitä, mihin ihmiset käyttävät profiilia? Koska ne ovat samankaltaisia, katsovatko he - luulen, että he katsovat - suorituskykyyn liittyviä kysymyksiä, auttavatko sinut erottamaan, milloin tietokanta vie aikaa ja kun koodi vie aikaa?
Bert Scalzo: Tiedätkö, se on fantastinen kysymys. Sanotaan, että työskentelen Visual Basicissä, ja minä Visual Basic Im -sovelluksen sisällä soitan Transact-SQL tai PL / SQL. Annan tehdä PL / SQL: n, koska Oracle ei pelaa hyvin aina Microsoftin työkaluilla. Voin profiloida Visual Basic -koodiani, ja siinä oleva profiili voi sanoa: “Hei, kutsuin tätä tallennettua menettelyä ja se kesti liian kauan.” Mutta sitten voin mennä tallennettuun menettelyyn ja voin tehdä tietokantaprofiilin tallennetulle ja sano: "OK, 100: sta täällä olevasta lausunnosta ovat viisi, jotka aiheuttivat ongelman." Ja niin, joudut ehkä tekemään tag-ryhmän, jossa joudut käyttämään useita profiileja.
Ajatuksena on, että jos koskaan kerrotaan tietokannassa olevan suoritusongelmasta, tietokantaprofiili voi auttaa sinua löytämään neulan heinäsuovasta, jonka lauseet ovat tosiasiassa ne, joissa sinulla on ongelma. Kerron teille toisen asiaan, joka osoittautui profiloinnista: jos sinulla on koodinpätkä, jota kutsutaan miljoona kertaa, mutta se vie vain mikrosekunnin jokaista miljoonaa kertaa, mutta sitä kutsutaan miljoona kertaa, mitä profiloija näyttäisi , se juttu meni niin monta aikayksikköä. Ja niin, vaikka koodi voi olla erittäin tehokas, saatat katsoa ja sanoa: “Voi, soitimme tähän koodinumeroon liian usein. Ehkä meidän pitäisi kutsua sitä vain joka kerta niin usein kuin joka kerta kun käsittelemme levyä ”tai jotain muuta. Ja niin voit tosiasiallisesti löytää, missä on tehokasta koodia, jota juuri kutsutaan liian usein, ja se on todella suorituskykyongelma.
Robin Bloor: Kyllä, se on upeaa. En ole koskaan tehnyt tätä. Tietysti, kun minulla oli tietokantaongelmia, se oli kuin olisin tavalla tai toisella käsittelemään tietokantaa tai koodia; En koskaan pystynyt käsittelemään molempia samanaikaisesti. Mutta jälleen kerran, en tehnyt - Ive ei ole koskaan itse ollut mukana rakentamassa sovelluksia, joihin meillä oli tallennettu menettelyjä, joten luulen, että Ive ei koskaan tosiasiassa joutunut ongelmiin, jotka ajoivat minua villiksi, ajatus siitä, että jakaisit koodin keskenään tietokanta ja ohjelma. Mutta niin, tee kaikki - oletan, että vastaukset ovat kyllä, mutta tämä on osa kehitysryhmän toimintaa, kun yrität tavalla tai toisella korjata jotain rikkoutunutta tai yrität ehkä tuoda uuden sovelluksen yhteen. Mutta sopiiko tämä kaikki kaikkiin muihin ympäristössä odotettaviin komponentteihin? Voinko odottaa, että voisin leikata tämän yhdessä kaikkien testipakkausteni ja kaikkien muiden tekemäni tavaroiden kanssa sekä projektinhallintatavaroideni kanssa, niin kuinka tämä kaikki leikataan yhteen?
Bert Scalzo: Joo, siitä voi tulla osa mitä tahansa jäsenneltyä prosessia, jolla suoritat ohjelmointi- tai kehitystyösi. Ja hauska, viime viikolla minulla oli asiakas, joka rakensi verkkosovellusta, ja heidän tietokantaansa oli historiallisesti ollut pieni, joten se, että heillä oli erittäin hyviä ohjelmoijia, ei koskaan satuttanut heitä. No, heidän tietokantaansa on kasvanut vuosien varrella, ja nyt verkkosivulta kuluu 20 sekuntia, kun sanot: “Kirjaudu sisään ja anna minulle tietoja nähdäksesi” ja kun näyttö todella tulee, ja niin nyt suorituskykyongelma. Ja he tiesivät, että ongelmaa ei ollut missään heidän Javassa tai muissa paikoissa. Mutta heillä oli tuhansia tallennettuja menettelytapoja, joten heidän piti aloittaa tallennettujen menettelyjen profilointi selvittääkseen, miksi tämän verkkosivun laatiminen vie 20 sekuntia? Ja huomasimme tosiasiallisesti, että heillä oli karteesialainen liittymään yhteen valitsemiinsa lausuntoihin ja et tiennyt sitä.
Robin Bloor: Vau.
Bert Scalzo: Mutta joku sanoi minulle kerran: ”No kuinka he voisivat saada Cartesian liittymään etkä tietämään sitä?” Ja tämä kuulostaa todella kauhealta; Joskus ohjelmoija, joka ei ole kovin mukava SQL: n suhteen, tekee jotain kuten antaa minulle Cartesian liittymisen, mutta antaa sitten vain ensimmäisen levyn takaisin, joten tiedän, että sain jotain, ja tarvitsen vain ensimmäisen. Ja niin, he eivät tiedä, että he ovat juuri tuoneet takaisin miljardin levyn tai katselevat miljardia levyä, koska he saivat kiinnostuksensa.
Robin Bloor: Vau, tiedän, mitä kutsutaan - no, siinä, mitä Dezillä tapahtui, ihmisten suhteen, jotka eivät ole juuri niin taitavia kuin ehkä heidän pitäisi olla, tiedät. Jos olet ohjelmoija, sinun pitäisi tietää, mitä komentojen antamisella on. Tarkoitan todellakaan, että mikään tyhmyys ei ole tekosyy. Oletan myös, että olet tällä tavalla tavalla tai toisella vain kielen agnostiikka, koska tämä kaikki keskittyy tietokannan puolelle. Olenko oikeassa siinä? Onko se aivan sama, mitä käytätkin koodauspuolella?
Bert Scalzo: Ehdottomasti, voit tehdä tämän Fortranissa tai C tai C ++. Itse asiassa joissakin Unixeissa voit jopa tehdä sen heidän skriptikielellään; he todella tarjoavat samat työkalut. Ja sitten haluan palata hetken taakse, mitä sanoit ilman syytä. Aion antaa ohjelmoijille yhden tauon, koska en halua heittää ohjelmoijia linja-auton alle. Mutta ongelma on todella akateeminen ympäristö, koska kun opit olemaan ohjelmoija, sinut opetetaan ajattelemaan kerrallaan. Sinua ei opeteta joukkoajattelua, ja juuri sitä Strukturoitu kyselykieli tai SQL toimii joukkojen kanssa; siksi meillä on liitto, risteys ja miinusoperaattori. Ja se on joskus erittäin vaikea henkilölle, joka ei koskaan ajatellut sarjojensa suhteen, lopettaa, päästä irti kerrallaan käsittelystä ja työskennellä sarjojen kanssa.
Robin Bloor: Joo, olen kanssasi siinä. Tarkoitan, että saan nyt, että on koulutuskysymys; Mielestäni tämä on täysin koulutuskysymys, mielestäni on luonnollista, että ohjelmoijat ajattelevat menettelytapoja. Ja SQL ei ole menettelyllinen, sen deklaratiivinen. Sanot oikeastaan vain: "Tämä on mitä haluan ja en välitä miten teet sen", tiedätkö? Kun taas ohjelmointikielellä olet usein saanut hihasi rullalle ja olet alas yksityiskohdissa jopa hallita laskut, kun teet silmukan. Sairas käsi -
Bert Scalzo: Ei, jatka.
Joo, aioin sanoa, että tuitte esiin yhden muun esimerkin siitä, että profiilintekijä olisi hyvä kiinni, tällainen jatkuu tällä levy-kerrallaan käsittelyllä. Joskus ohjelmoija, jolla on hyvä tietue kerrallaan -logiikka, ei pysty selvittämään, miten SQL-ohjelma tehdään. Sanotaan, että hän tekee kaksi FOR-silmukkaa ja periaatteessa tekee liittymisen, mutta hän tekee sen asiakaspuolella. Joten, hän tekee saman vaikutuksen kuin liittyminen, mutta hän tekee sen itse, ja profiili tarttuisi siihen, koska luultavasti vietät enemmän aikaa tekemällä liittymistä käsin kuin antamalla tietokantapalvelimelle tehdä sen puolestasi.
Robin Bloor: Kyllä, se olisi katastrofi. Tarkoitan, että vain rakastelet. Thrashings aina huono.
Joka tapauksessa, siirron Dezille; Olen varma, että hänellä on mielenkiintoisia kysymyksiä.
Dez Blanchfield: Kiitos, joo. Aion liittyä teihin siihen, ettet ohjelmoijaa heitä bussin alle. Tarkoitan, että Ive vietti liian monta vuotta elämässäni itse koodaajana, jokaisella tasolla tiedät, onko se kuten sanoit, istuessasi Unix-koneen komentorivillä, ja joissakin tapauksissa olin jopa mukana pari erilaista Unix-porttia laitteistoalustalta toiselle. Ja voit kuvitella haasteet, joita meillä oli siellä. Mutta todellisuus on harhaoppi, joka saa vankila-kortin jokaiselle maailman kooderille ja käsikirjoittajalle. Se on rakettitiede, varsin kirjaimellisesti, kirjoittaa todella tiukasti joka kerta, koko ajan, on rakettitiede. Ja kuuluisia tarinoita ihmisistä, kuten Dennis Ritchie ja Brian Kernahan, jotka työskentelevät itsenäisesti jonkin osan koodin parissa ja siirtyvät sitten kahvin päällä koodikatselukeskusteluun ja saavat selville, että he kirjoittivat täsmälleen saman koodin, täsmälleen samassa ohjelmassa, täsmälleen samalla tavalla. Ja he tekivät sen kohdassa C. Mutta tämä puristinen ohjelmointitaso esiintyy hyvin harvoin.
Tosiasia on, että päivittäin siellä on vain 24 tuntia päivässä, seitsemänä päivänä viikossa, ja meidän on pakko tehdä asiat vain. Ja niin, kun kyse ei ole vain perinteisistä ohjelmoijista, DBA-ohjelmista, ja koodaajista, ja komentosarjoista, ja sysadminista, verkon ylläpitäjistä ja turvallisuushenkilöstöstä, ja kaiken tämän jälkeen kansalaisten tietopuolelle; Kuulemme jokaisen vain yrittävän tehdä työnsä. Joten mielestäni suuri poistuminen tästä kokonaisuudesta on se, että rakastin demoasi ja rakastin takeawaya, jonka jätit meille siellä vain hetki sitten puhuessani Robinin kanssa siitä, että tällä on erityinen - ehkä ei niin paljon markkinarako - mutta laaja tila, johon se koskee, koodin, SQL: n ja tietokantojen korjaamiseen asti. Mutta olin todella innoissani kuulemasi sanovan, että voit pistää sen komentosarjoilla ja löytää joitain ongelmia, koska tiedät, että nykypäivän päivä ja ikä työskentelivät aina kaikkein halvimmalla kustannuksella.
Syy siihen, että voit ostaa 6 dollarin paidan jostakin, johtuu siitä, että joku rakensi järjestelmän, joka on riittävän halpa, jotta se tosiasiallisesti valmistaisi ja lähettäisi ja toimittaisi ja myisi ja vähittäiskaupan logistisesti ja suorittaisi online-maksuja saadakseen 6 dollarin paidan. Ja niin ei tapahdu, jos sait ihmisille 400 000 dollaria vuodessa koodin kirjoittamiseen täydellisellä tavalla; sen vain koko kehitys. Joten tuo kohta, luulen, että yksi kysymyksistä, jotka todella rakastan sinua antamaan meille vain lisää käsitystä, on mikä on niiden ihmisten leveys ja ulottuvuus, joita näet tällä hetkellä ja jotka käyttävät tällaisia työkaluja koodin profilointiin ja näyttämiseen suorituskykyongelmiin? Alun perin historiallisesti mistä ne ovat peräisin? Ovatko ne olleet suuria teknisiä taloja? Ja sitten eteenpäin, onko tilanne, ajattelen oikein, että yhä useammat yritykset toteuttavat tätä työkalua tai näitä työkaluja yrittääkseen auttaa koodaajia, jotka he tietävät, jotka ovat juuri tekemässä asioita saadakseen työn valmiiksi ja viedä se ulos ovesta? Ja joskus tarvitsemmeko vankilasta pääsyn korttia? Olenko oikeassa ajatellessani, että historiallisesti meillä oli enemmän tekniikan painopistettä ja kehitystä? Eikö nyt, kuten Robin sanoi, vähemmän akateemista lähestymistapaa ja nyt sen itseoppimista, tai leikkaa ja liitä -koodia, vai vain rakennatko asioita? Ja vastaako tämä sellaisia ihmisiä, jotka käyttävät tuotetta nyt?
Bert Scalzo: Juurikin niin. Ja annan teille hyvin erityisen esimerkin, haluamme vain saada työ saatu aikaan, koska liikemiehet eivät halua täydellisyyttä. Se on eräänlainen kuin tietokoneistettu shakkipeli: shakkipeli ei etsi täydellistä vastausta; se etsii vastausta, joka on tarpeeksi hyvä kohtuullisessa ajassa, joten se, kuinka ohjelmoimme. Mutta mitä löydän nyt, suurin osa ihmisistä sen sijaan, että sanoisivat haluavansa profiilin osana yksikkötestaustaan - niin minä tekisin sen, koska en näe sitä ajanhukkaa - mitä tapahtuu, nyt tapahtuu myöhemmin, joskus, integraatiotestauksen tai stressitestauksen aikana, jos onnea. Mutta useimmiten sen osa kärjistymisestä, jossa jotain meni tuotantoon, se juoksi jonkin aikaa, ehkä jopa juoksi vuosia, ja nyt se ei toimi hyvin, ja nyt se profiloi hyvin. Ja se näyttää olevan nyt yleisin skenaario.
Dez Blanchfield: Kyllä, ja luulen, että termi ”tekninen velka” on todennäköisesti yksi sinusta enemmän kuin tuttu; Tunnen Robinin ja olen todellakin. Uskon, että nykyään, etenkin ketterissä lähestymistavoissa kehittämiseen ja järjestelmän rakentamiseen, teknisen velan käsite on hyvin todellinen asia, ja otamme sen tosiasiallisesti huomioon hankkeissa. Tiedän, että meillä on omat projektimme, kuten Media Objektiivi ja muut, joissa koodaus tapahtui päivittäin, ja erilaisia asioita Bloor-konsernissa. Ja aina kun rakennimme jotain, katsomme sellaista, katson sitä ja katson aina sen näkökulmasta, mistä minun maksaa korjata tämä nyt, vai voinko vain saada sen tölkkiin ja viedä se sieltä, ja katsoa sitten katsoa, rikkovatko nämä asiat. Ja perinyt tämän teknisen velan, jonka tiedän, että minun on kiertävä takaisin myöhemmin ja korjattava.
Ja tarkoitan, Ive teki sen viimeisen seitsemän päivän aikana: Ive kirjoitti pari työkalua ja komentosarjaa, Ive kirjoitti pari kappaletta Python-kieltä ja Ive käytti sen Mongon takaosaan varmistaen, että se on mukava, puhdas ja turvallinen, mutta se vain saa kyselyn, jonka tarvitsen, tietäen, että tarvitsen tämän toiminnon toimimaan, päästäkseni isompaan palapeliin; siinä on tosi kipu. Ja niin syntyy tämä tekninen velka, ja mielestäni tämä ei ole nyt vain satunnainen asia, mielestäni tämä on osa kehityksen DNA: ta. Ihmiset vain - ei selvästi - he vain hyväksyvät teknisen velan, joka on normaali toimintatapa, ja heidän on vain aiheutettava se. Se, missä syntyy tekninen velka. Ja mielestäni hieno asia, jonka osoitit meille esittelyssä, oli se, että voit kirjaimellisesti profiloida ja katsoa kuinka kauan jotain kestää. Ja se on luultavasti yksi suosikkiasioistani. Tarkoitan, että Ive todella rakensi profilointityökaluja - rakensimme työkaluja Sedissä, Lexissä ja Orcissa ajaaksemme koodia ja nähdä missä silmukoita olivat, ennen kuin tällaiset työkalut olivat saatavilla - ja kun olet luonut koodin mennäksesi ja tarkistamaan omaasi koodiasi , saat erittäin hyvän, koska sinun ei tarvitse tarkistaa omaa koodiasi. Mutta niin ei ole nyt. Ottaen huomioon tämä, onko jokin tietty markkinasegmentti, joka vie tämän enemmän kuin mikään muu? Näyttää kuin massa -
Bert Scalzo: Ai niin, Ive sai… Aion piirtää analogian sinulle ja näyttää sinulle, että muut kuin ohjelmoijat tekevät sen koko ajan. Syy, jos minä koskaan opetan virheenkorjainta ja profiloin luokkaa tai istuntoa, kysyin ihmisiltä: "Okei, kuinka moni täällä käy Microsoft Wordiin ja ei tarkoituksella koskaan käytä oikeinkirjoituksen tarkistusta?" Ja kukaan ei aseta kättään, koska asiakirjojen kirjoittamiseen, me kaikki tiedämme, että voimme tehdä englanninkielisiä virheitä, ja niin jokainen käyttää oikeinkirjoituksen tarkistusta. Ja sanoin: ”No, miksi kun kirjoitat IDE: hen kuten Visual Basic, et käytä debuggeria? Se on sama asia, se on kuin oikeinkirjoituksen tarkistus. ”
Dez Blanchfield: Joo, oikeastaan on hieno analogia. En ollut todella ajatellut, minun on tunnustettava, että teen todella jotain samanlaista parilla työkaluilla, joita käytän. Itse asiassa yksi, ODF, suosikkini Eclipsen kanssa on vain leikata ja liittää koodi sinne ja mennä etsimään asioita, jotka vain korostavat heti, ja ymmärtääkseni tein kirjoitusvirheen joihinkin luokkapuheluihin. Ja, mutta koska se on mielenkiintoinen tällä hetkellä käytettävällä työkalulla, voit tehdä sen reaaliajassa sen sijaan, että tulisit takaisin ja katsoisit sitä myöhemmin, mikä on tavallaan mukavaa kiinni siitä etukäteen. Mutta kyllä, se on hieno analogia vain tekstinkäsittelyohjelmaan asettamisesta, aiheuttaa sen mielenkiintoisen herätyspuhelun, joka vain ymmärtää, että olet tehnyt joitain kirjoitusvirheitä tai jopa kielioppivirheen, eikö niin?
Bert Scalzo: Tarkalleen.
Dez Blanchfield: Joten, näetkö nyt enemmän uptickiä mielestäni, tarkoitan viimeistä kysymystä minulta, ennen kuin heitän kysymyksiisi ja vastaukseemme kenties osanottajillemme. Jos aiot antaa jonkinlaisen suosituksen lähestymistavan suhteen tähän - olettaen, että tämä on retorista - onko niin, että saatat aikaisin aikaisin ja saatat tämän täytäntöön kun kehität, ennen kuin kehität? Vai onko niin, että pääasiassa rakennat, siirryt, rakennat jotain ja tulet sitten sisään ja profiloit sen myöhemmin? Epäilen, että tapaus on, että pääset aikaisin ja varmista, että koodisi puhdistetaan etukäteen. Vai onko kyse siitä, että heidän pitäisi harkita tätä osaa uudelleensijoittamisestaan?
Bert Scalzo: Ihannetapauksessa he tekisivät sen etukäteen, mutta koska kaikki ovat hälinässä, jossa he ovat vain saaneet asiat tehtyä, he eivät yleensä tee sitä ennen kuin joutuvat suorituskykyongelmaan, jonka he eivät voi ratkaista lisäämällä lisää suorittimia ja muistia virtuaalikoneelle.
Dez Blanchfield: Joo. Joten todella mainitsit jotain mielenkiintoista, jos voin nopeasti? Mainitsit aiemmin, että tätä voidaan ajaa mistä tahansa, ja se voi puhua tietokantaan takaosassa. Joten tämä on mukava sellaisen bimodaalisen käsitteen suhteen, josta nyt puhumme, paikan päällä / ulkopuolella olevan pilven, myös asioiden ulkonäön perusteella päivän päätteeksi, jos se voi puhua takaosaan ja nähdä koodi, se ei todellakaan välitä, vai mitä?
Bert Scalzo: Aivan, kyllä, voit ajaa tämän pilvessä.
Dez Blanchfield: Erinomainen, koska mielestäni on sellaista, mihin uusi rohkea maailma menee. Joten, Eric. Aion heittää takaisin teille nyt ja nähdä, että meillä on täällä muutamia kysymyksiä ja haluan, että osallistujamme pysyvät edelleen luonamme, vaikka olemmekin ohittaneet tunnin.
Eric Kavanagh: Joo, siellä on muutama ihminen, kommentoin vain nopeasti: Bert, mielestäni metafora, analogia, jonka annat oikeinkirjoituksen tarkistamiseen, on rehellisesti loistava. Se on blogin tai kahden arvoinen, rehellisesti sanottuna, koska se on hyvä tapa kertoa cone siitä, mitä teet ja kuinka arvokasta se on, ja kuinka sen pitäisi olla paras tapa käyttää virheenkorjainta säännöllisesti, eikö? Lyön vetoa, että jotkut päät nyökkivät, kun heität sen ulos, eikö niin?
Bert Scalzo: Ehdottomasti, koska sanon heille, että "Miksi suoritan oikeinkirjoituksen tarkistuksen asiakirjoilleni? En halua hämmentyä tyhmien kirjoitusvirheiden takia. ”No, he eivät halua hämmentyvän tyhmien koodausvirheiden takia!
Eric Kavanagh: Oikea. Todellakin. Ihmiset, olemme palanneet täällä tunnin ja viiden minuutin ajan, niin suuri kiitos kaikille, jotka olette siellä aikaa ja huomiosta. Arkistoimme kaikki nämä verkkokeskusteluet, palaamme mielellämme milloin tahansa ja tarkistamme ne. Paras paikka löytää nämä linkit on todennäköisesti techopedia.com, joten lisää se tähän luetteloon täällä.
Ja sen kanssa aiovat jättää jäähyväiset, ihmiset. Uudelleen upea työ, Bert, IDERA-ystävämme kiitos. No puhua kanssasi seuraavan kerran, puhua kanssani ensi viikolla, itse asiassa. Pitää huolta! Hei hei.