Tekijä Techopedia Staff, 15. maaliskuuta 2017
Takeaway: Isäntä Eric Kavanagh keskusteli tietokannan virheenkorjauksesta 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 se tietysti tarkoittaa.
Robin Bloor: En kuule 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 puhumme 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 puhumme aiheesta "Nopea vastaus: Tietokannan virheenkorjaus ja pelastustoimien profilointi".
Siellä on paikka todella omasi, lyö minut Twitteriin, tietysti @eric_kavanagh.
Tämä vuosi on kuuma. Ja virheenkorjaus tulee olemaan kuuma, ei väliä mitä. Se on todellakin yksi näistä ongelmista, joka ei koskaan katoa, riippumatta siitä, kuinka hyvää meillä on tämä asia, aina tulee 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 kuuluu, mikä on ratkaisusi käsittelemään sitä ja ratkaisemaan näitä ongelmia?
Kuulemme tohtori 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 siitä, mitä tapahtuu. Tein tämän pitkään, ja minulla oli tapana olla koodaaja, joten se on kuin, ja minulla oli melkein houkutus tämän esityksen kanssa aloittaa lyyrisen kirjoituksen tekeminen avoimen lähdekoodin ajatuksesta, mutta ajattelin, että jätän sen jollekin muulle.
Tässä on luettelo kuuluisista virheistä, ja suurin osa niistä pääsee kenen tahansa 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 siitä. 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 kaikkien ympäri - se ilmeisesti aiheutti 100 miljoonan dollarin arvosta vahinkoa; se on arvio tietysti. Intel teki kuuluisan virheen matematiikkapiirillä - matematiikkaohjeet Pentium-sirulla vuonna 1993 -, jonka piti maksaa yli 100 miljoonaa dollaria. Applen 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 mielenkiintoista jotain sellaisen kustannusten kannalta - AT&T oli poissa noin yhdeksän tuntia ja se maksoi noin 60 miljoonaa dollaria kaukopuheluista.
Ja olin Yhdistyneen kuningaskunnan vakuutusyhtiössä, ja tietokanta, he ottivat käyttöön uuden version tietokannasta ja se aloitti tietojen pyyhkimisen. 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 on se. Ajattelin puhua impedanssien yhteensopimattomuudesta ja annetusta SQL: stä. On mielenkiintoista, että relaatiotietokannat tallentavat tietoja taulukoihin ja kooderit pyrkivät manipuloimaan tietoja objektirakenteissa, jotka eivät todellakaan sovi kovin hyvin taulukoihin. Ja sen takia saat niin sanotun impedanssin epäsuhta, ja jonkun on käsiteltävä sitä jollain tavalla. Mutta mitä todella tapahtuu, koska yhtä mallia, kooderin 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, koodereiden 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 se asia, joka 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 elääkseen, ja syy siellä asuville tallennetuille menettelyille oli se, että et oikeasti halunnut heittää tietoja edestakaisin ohjelmaan.
Jotkut toiminnallisuuksista olivat erittäin tietospesifisiä, joten kyse ei ollut pelkästään viitteellisestä eheydestä ja poistotietojen asettamisesta kasautiin ja vastaaviin, tietokanta huolehti kaikesta äkillisestä toiminnallisuuden lisäämisestä tietokantaan, mikä tietysti tarkoitti sovelluksen toiminnallisuus 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 esimerkiksi paljon toteutuksia, että olen ollut mukana relaatiotietokannoissa, siellä on todella hirvittävä paljon tallennettuihin menettelyihin sijoitettua koodia, jota käsitellään erillään sovelluksissa olevasta koodista. Ja se tuntuu erittäin omituiselta joutumiselta, sen 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 vuoksi . Ajatuksena olisi, että kooderin ei todellakaan tarvinnut olla huolissaan suorituskyvystä ja tietokanta toimisi itse asiassa kohtuullisen hyvin. Sen on tarkoitus suunnitella niin, 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. On mielenkiintoista, 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, että se on kuin kaikki virheenkorjauksen tilanteet, koskaan kokenut on, on ensimmäinen asia, jonka koskaan nähnyt, on sotku. Ja sinun on yritettävä siirtyä sotkusta selvittämään, miten sotku tapahtui. Ja usein, kun tarkastelet tietokantaongelmaa, kaikki etsimäsi ovat vioittuneita tietoja ja ajattelet: "Kuinka helvetti niin tapahtui?"
Joka tapauksessa, välitän Dezille, joka todennäköisesti aikoo sanoa enemmän viisauden sanoja kuin minulla oli. En tiedä miten välittää pallo sinulle, Dez.
Eric Kavanagh: Ohitan sen, odotan, pidä kiinni.
Automaattinen ääni: Osallistujan rivit mykistetään.
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 vika, jos anteeksi armon, anteeksi, etten 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. Se on niin laaja ja laaja aihe, joten keskityn kahteen avainalueeseen, erityisesti käsitteeseen, jota pidämme niin suurena virheenä, 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 kyse koodin profiloinnista ja on 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 noin 1945-luvun ohjelmointiarkista, 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 kaupunkien myytti on, että noin 9. syyskuuta 1945 Harvardin yliopiston joukkue veti erilleen koneen, he tapasivat jotain, jota he kutsuivat “seitsemänkymmeneksi releeksi” - noina päivinä ohjelmointi tehtiin fyysisessä mielessä, te haavoitit koodin noin pöydän ympärillä, ja näin ohjelmoit koneesi tehokkaasti - ja he löysivät tämän välitysnumeron seitsemänkymmentä, että siinä oli jotain vikaa, ja osoittautuu, että todellinen termi "vika" syntyi, koska se oli kirjaimellisesti koi - oletettavasti siellä oli koi, joka oli kiinni jonkin paikan päältä kulkevan kuparilankapalan väliin. 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, kun 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, emmekä niinkään koodauskysymyksissä ohjelmassa, joka ei käänny, vaan ohjelmassa, joka ei toimi hyvin. Eikä erityisesti ole profiloitu, löydä vain asiat, kuten loputtomat silmukit, jotka eivät mene minnekään.
Mutta meillä on myös skenaario, ja ajattelin asettaa pari hauskaa dioa 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 tämä juttu lapsesta nimeltä “Little Bobby Tables” ja oletettavasti hänen vanhempansa nimitti tämän nuoren pojan Robertiksi); DROP PÖYTÄ Opiskelijat; - ja sitä kutsutaan, ja eräänlaiseksi "Hei, tässä poikasesi koulussa 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 kysyy:” Voi kyllä, pikkupoikaisia pöytiä kutsumme hänelle. ”Joka tapauksessa he jatkavat sanovansa, että ovat menettäneet vuoden opiskelijarekisterit, toivottavasti olet onnellinen. Ja vastaus on: "No, sinun pitäisi puhdistaa ja puhdistaa tietokannan syötteet." Ja käytän niin monta kertaa puhuaksemme joistakin ongelmista, joita meillä on asioiden löytämisessä koodissa, että usein koodi ei katso tietoja yhtä hyvin.
Toinen hauska, en tiedä onko tämä totta vai ei - epäilen, että se on huijaus -, mutta taas, se koskettaa myös hauskaa luuni. Joku vaihtaa auton etuosan rekisterikilven vastaavaan lausuntoon, joka aiheuttaa tietokantojen putoamisen nopeuskameroissa ja niin edelleen, että vangitsevat auton 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 hyvin sitä mieltä, että tuo aika on kulunut, ja kokemuksellisesti anekdoottisesti ensimmäinen - ja tämä vanhentaa minua kauheasti, olen varma; Robin, olet tervetullut pilaamaan minua tästä hauskanpidolla - mutta historiallisesti olen tullut taustalta 14-vuotiaana, vaeltaen kaupungin loppua ja koputtaen Data Data -nimisen datakeskuksen ovelle New Seelanti ja kysyin, voinko ansaita taskurahaa koulussa saamalla myöhässä linja-autolla kotiin, noin 25 km työmatkalle päivittäin, asettamalla paperia tulostimiin 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 itse asiassa 132-sarakeinen fyysinen tulostin. Ajatelkaa pohjimmiltaan hyvin vanhaa kirjoituskoneella, jolla on paperia, joka vieritti sitä 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, etteivät virheet juurtuisi sisään, koska on erittäin turhauttavaa sanoa yhden rivin toimittaja siirtyäksesi tiettyyn riviin ja tulostamalla sitten rivin ja kirjoittamalla sen sitten takaisin sisään. Mutta kerran kirjoitimme koodin ja näin 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 olemme kaikki tästä tuttuja - se siirtyi maailmani 3270-terminaalikokemuksesta Digital Equipment VT220: een, jossa voit nähdä asioita ruudulla, mutta taas, teit vain samaa asiaa teit paperiteipillä erään tyyppisen tulostetun muodon vain CRT: llä, mutta pystyit poistamaan helpommin, eikä sinulla ollut sitä "ääni, mutta se" -ääntä.
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ä suunnittelusta ja prosesseista varmistaakseen, että en esitellä buginen koodi.
Ohjelmointimenetelmät, kuten esimerkiksi strukturoitu kyselykieli, SQL, ovat nykyään erittäin tehokas, yksinkertainen kyselykieli. Mutta olemme muuttaneet sen ohjelmointikieleksi, enkä todellakaan usko, että SQL on koskaan suunniteltu nykyaikaiseksi ohjelmointikieleksi, mutta olemme vinoutuneet siitä, että siitä tulee se. Ja se tuo käyttöön kokonaisen joukon aiheita, kun ajatellaan kahta näkökulmaa: koodauksen ja DBA: n näkökulmasta. On erittäin helppo tulla mukaan ja esitellä virheitä esimerkiksi huonoista ohjelmointitekniikoista, laiskoista ponnisteluista koodin kirjoittamisessa, kokemuksen puuttumisesta, klassisesta lemmikkieläinten piilosta, jota olen esimerkiksi SQL-ihmisten kanssa hyppäämässä Googleen ja etsimässä jotain ja löytämässä 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ä me kaikki rynnämme kohti tätä, jota kutsumme kilpailuksi nollaan: yritämme tehdä kaikki niin halvalla ja niin nopeasti, että meillä on skenaario, jossa emme palkkaa alempia palkattu henkilökunta. En tarkoita sitä tyhjentävällä tavalla, mutta emme palkkaa asiantuntijoita jokaiseen mahdolliseen työhön. 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 kehittämiseen ja suunnitteluun ja tietokantoihin pääsee paljon 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ä on kuuluisa linja, en todellakaan muista kuka loi tarjouksen, linja kuuluu: ”Jos luulet, että asiantuntijan palkkaaminen on kallista, odota, kunnes palkkaat pari amatööriä, jotka aiheuttavat ongelman, ja sinä täytyy puhdistaa se. ”Ja niin SQL: llä on tämä ongelma, ja se on erittäin, erittäin helppo oppia, se on erittäin helppo käyttää. Mutta se ei ole mielestäni täydellinen ohjelmointikieli. On erittäin helppoa tehdä asioita, kuten tehdä valittu tähti mistä tahansa ja vetää kaikki ohjelmointikielelle, joka on mukavampaa, kuten PHP, Ruby tai Python, ja käyttää tekemissäsi alkuperäisesti tuttua ohjelmointikieltä. tietojen manipulointi sen sijaan, että suorittaa monimutkaisempi kysely SQL: ssä. Ja näemme tämän paljon, ja sitten ihmiset ihmettelevät, miksi tietokanta toimii hitaasti; johtuu siitä, että miljoona ihmistä yrittää ostaa lipun online-lippujärjestelmästä, jossa se valitsee valitun tähden mistä tahansa.
Nyt se on todella äärimmäinen esimerkki, mutta saat pisteen kaiken tästä. Joten vain lyödä se kohta kotiin, tässä on esimerkki, jota kannan paljon. Olen suuri matematiikan fani, rakastan kaaosteoriaa, rakastan Mandelbrot-sarjoja. Oikealla puolella on Mandelbrot-sarjan kopio, josta olen varma, että olemme kaikki tuttuja. Ja vasemmassa reunassa on pala SQL: tä, 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ä; se on 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 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, matalapalkkaiset työntekijät, jotka yrittävät olla korkeapalkkaisia, 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 katsot tätä näyttöä nyt ja luulet, että se on vain, se on tavallaan 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 olen pahoillani, että värit ovat päinvastaisia, sen pitäisi olla musta tausta ja vihreä teksti 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 opiskellulle vieraalle IDERAsta. Tämä on jäsennelty kysely, joka on kirjoitettu kuten C ++, mutta se on 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 sinulla on sitten 100 000 ihmistä lyömällä järjestelmää päivittäin tai tunneittain tai minuutteina, päädyt pian Tšernobylin kokemukseen, jossa iso rauta alkaa sulaa ja haudata itsensä planeetan ytimeen, koska kyseinen koodin pala ei saa 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 hankitaan DBA, joka auttaa sinua rakentamaan tuon strukturoidun kyselyn oikein, koska rehellisesti sanottuna se on vain ilkeää." Ja URL-osoite on siellä, voit käydä katsomassa - siihen viitataan nimellä monimutkaisin SQL-kysely, jonka olet koskaan kirjoittanut. Koska usko minua, se tosiasiassa kääntää, se toimii. Ja jos leikkaa ja liitä se ja vain pilkata tietokantaa, se on aika katsottavaa; Jos sinulla on työkaluja tietokannan katselua varten, yritä vain sulattaa kolmesta viiteen minuuttiin, soittaaksesi takaisin yhden rivin tekstiä.
Joten tiivistääkseni koko tätä asiaa koodaamisen taustallani 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, kun olet suorittanut koodauksen, voit tarkistaa koodisi, löytää ongelmia profiloimalla koodin, löytää tehokkaasti tahattomia virheitä, jotka ovat suorituskykyongelmia, ja kuten sanoin aiemmin, kerran, voit tehdä sen katsomalla vihreää näyttöä. Et voi enää; koodisatoja on satoja tuhansia, sovelluksia on kymmeniä tuhansia, joissain tapauksissa on miljoonia tietokantoja, ja jopa super-ihmiset eivät voi enää tehdä tätä 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 ottaen tämän huomioon, aion luovuttaa vieraamme ja odotan innolla kuulevani, kuinka he ovat ratkaisseet tämän asian. Ja etenkin demon, jonka mielestäni olemme vastaanottamassa. Eric, menen takaisin yli.
Eric Kavanagh: OK, Bert, ota se pois.
Bert Scalzo: OK, kiitos. Bert Scalzo täältä IDERAsta, olen tietokantatyökaluidemme tuotepäällikkö. Ja aion puhua virheenkorjauksesta. Mielestäni yksi tärkeimmistä asioista, joita Robin sanoi aiemmin - ja se on totta, että virheenkorjaus on vaivalloista ja ei-triviaalia, ja kun siirryt tietokannan virheenkorjaukseen, se on suuruusluokkaa 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ä virheenkorjainta, vaan vain ohjelmoivat mitä kieltä he käyttävät, ja monta kertaa he sanovat minulle, "No, 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, se on sellaista sanomme missä olimme ohjelmointikielten suhteen. 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 sanotun: "Hei, en käytä virheenkorjainta, " koska se on yksi niistä uusista asioista ", sinun on siis aloitettava ohjelmointi, tiedät, jo 1950-luvulla, " koska se on ainoa tapa päästä eroon vaatimuksesta.
Nyt toinen hauska asia tässä kaaviossa on Dez juuri kommentoinut Grace Hopperia, tiesin itse Gracen, joten se on eräänlainen hauska. Ja sitten toinen asia, josta nauroin, on se, että hän puhui tyyppityypeistä ja istun siellä menossa: ”Ihminen, se oli suurin hyppy, joka meillä koskaan ollut tuottavuudessa, kun siirryimme korteista teletyyppeihin, se oli kaikkien aikojen suurin hyppy. Joten, ja olen ohjelmoinut kaikki täällä olevat kielet, mukaan lukien SNOBOL, josta kukaan ei ole koskaan kuullut aiemmin, se oli CDC, Control Data Corporation, joten luulen olevani hieman liian vanha tälle teollisuudelle .
Dez Blanchfield: Aioin sanoa, että olet ikäissyt meidät kauheasti siellä.
Bert Scalzo: Joo, minä sanon sinulle, tunnen olevani isoisä Simpson. Joten tarkastelen virheenkorjausta ja virheenkorjausta varten on erilaisia tapoja. Voisit puhua siitä, mitä me kaikki ajattelemme perinteiseksi pääsyksi virheenkorjaimeen ja askelemaan läpi koodin. Mutta myös ihmiset opettavat koodinsa; sinne kiinnität lauseet koodiin ja ehkä tuotat tulostiedoston, 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 meillä on myös kuuluisa tulostuslausunto: katsot ja ihmiset tosiasiallisesti laittavat tulosteita ja olen itse nähnyt työkalun missä - ja se on tietokantatyökalu - missä jos et tiedä kuinka käyttää virheenkorjainta, painat painiketta ja se kiinnittää tulostettavat lausunnot koko koodiin puolestasi ja sitten kun olet valmis, painat toista painiketta ja se poistaa ne. Koska näin monet ihmiset virheenkorjaavat.
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 menettäneet liiketoimintavaatimuksen, 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, se on tehokkuuden vuoksi ja se voi olla logiikkavirhe, mutta mikä on, olenko tehnyt oikein, se ei vain palaudu tarpeeksi nopeasti. Nyt teen tämän huomautuksen, koska profiloija on todennäköisesti parempi toista skenaariota varten, ja puhumme sekä virheenkorjajista että profiileista. Lisäksi on olemassa tämä etävirheen käsite; tämä on tärkeätä, koska jos istut tietokoneellasi ja käytät virheenkorjainta, joka osuu tietokantaan, jossa koodi tosiasiallisesti suoritetaan tietokantaan, teet itse niin sanottua etävirheenkorjausta. Et ehkä ymmärrä sitä, mutta niin tapahtuu. Ja sitten, näillä virheenkorjaimilla on hyvin yleistä saada murtopisteitä, katsella pisteitä, astua sisään ja astua yli ja joitain muita yleisiä asioita, että aion näyttää heille ruudun tilannekuvan hetkessä.
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 sitä parempaa, että se on parempi, jos se tehdään näytteenotolla. Ei ole 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 juoksevat 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 tuon 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 profiiliin, näyttää. Ja se on sääli, koska profiloinnilla voi todella olla valtava ero. Nyt tietokantakielet, kuten olemme aiemmin puhuneet, sinulla on SQL - ja olemme pakottaneet pyöreän tapin täällä olevaan neliön reikään ja pakottaneet siitä ohjelmointikielen - ja Oraclen. Se on PL / SQL - se on prosessinkieli SQL - ja SQL Server, se on Transact-SQL, se on SQL-99, se on SQL / PSM - sillä, mielestäni, se on menettelytallennusmoduuli. 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 varastoin esineitä tietokantaan, se on todennäköisesti tallennettu menettely tai tallennettu toiminto. Mutta on myös liipaisimia: liipaisin on kuin tallennettu menettely, mutta se laukaisee jonkinlaista tapahtumaa. Nyt jotkut ihmiset laukaisevat laukaisevat yhden koodirivin ja kutsuvat tallennetun proseduurin niin, että he pitävät kaikki tallennetut koodinsa ja proseduurinsa, mutta se on sama käsite: se voi silti olla liipaisin, joka 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ässä on virheenkorjaaja 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ö, hyvin, se on ei-manuaalinen virheenkorjausmenetelmä.
Ja syyn siihen, että tuon tämän esiin, jos yrität tehdä tämän käsin, kirjoitat tosiasiallisesti enemmän virheenkorjauskoodia lisätäksesi kaikkiin näihin painetut lausunnot kuin sinulla on koodilla. 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 missä sillä on ongelma, se on linjassa kolme? Jos tekisin vuorovaikutteisen virheenkorjauksen, olisin tiennyt sen riviltä kolme - viisi minuuttia siihen - hei, täällä on ongelma, voin lopettaa. Mutta tämän kanssa minun on odotettava sen suorittamista loppuun saakka ja sitten minun on katsottava jotain jäljitetiedostoa, jossa todennäköisesti on kaikki nämä tulostuslausunnot, ja yritettävä löytää neula heinäsuovasta. Tämä on jälleen parempi kuin ei mitään, mutta se ei olisi paras tapa työskennellä. Nyt tämä tiedosto näyttää siltä, että se tuli aiemmasta diasta; Toisin sanoen suoritin ohjelman, ja siinä on juuri joukko tulosteita tähän jäljitystiedostoon, ja en ehkä voi ehkä sifonkiida tämän läpi ja löytää mitä tarvitsen löytää. Joten jälleen kerran, en ole niin varma, että haluaisit työskennellä tällä tavalla.
Nyt vuorovaikutteiset virheenkorjaimet - ja jos olet käyttänyt Visual Studion kaltaista ohjelmien kirjoittamiseen tai Eclipseä, sinulla on ollut virheenkorjauksia ja käytit niitä muiden kieliesi kanssa - et vain ajatellut käyttää niitä täällä tietokannasi kanssa. 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 ja katselemaanko minua taulukossa useita rivejä samalla elokuvan otsikolla. Joten, tietokanta on elokuville. Ja voisit nähdä oikealla puolella, kolmannella yläosalla, minulla on lähdekoodini keskellä, minulla on ns. Kellomuuttujat ja puhelupinoalustani, ja sitten alhaalla olen saanut joitain lähtöviestejä. Ja mikä on tärkeätä tässä, on se, että kun tarkastelet ensimmäistä punaista nuolta, hiiren osoittimen ollessa muuttujan päällä, voin tosiasiallisesti nähdä, mikä arvo kyseisessä muuttujassa on tuona ajankohtana, kun askan koodin läpi. Ja se on todella hyödyllistä, ja sitten voin siirtyä yhden rivin kerrallaan koodin läpi, minun ei tarvitse sanoa suorita, voisin sanoa askel riville, anna minun katsoa mitä tapahtui, askelta toiselle riville, anna minun nähdä mitä tapahtui, ja teen tämän tietokannassa. 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öä, siinä kohdistimeni on tällä hetkellä - joten toisin sanoen olen askenut ja olen täällä hetki. Joten jos sanon: "Astu uudestaan", menen seuraavalle riville. Nyt heti alapuolella näet punaisen pisteen. No, se on murtopiste, joka sanoo: "Hei, en halua astua näiden linjojen yli." Jos haluan vain hypätä kaiken yli ja päästä sinne, jossa tämä punainen piste, voin painaa Käynnistä-painiketta ja se juoksee. täältä joko loppuun tai murtopisteeseen, jos jollekin on asetettu raja-arvoja, ja sitten se pysähtyy ja antaa minun suorittaa askel uudelleen. Ja syy siihen, että kaikki tämä on tärkeä ja voimakas, johtuu siitä, että kun teen kaiken tämän, se, mitä tapahtuu keskellä ja jopa pohjassa - mutta mikä tärkeintä keskellä - muuttuu ja näen arvot muuttujistani, Näen puhelupinon jäljen, tiedät, ja niin kaikki nämä tiedot näkyvät siellä, kun askan koodin läpi, joten pystyn tosiasiallisesti näkemään ja tuntemaan ja ymmärtämään mitä tapahtuu ja kuinka koodi oikeasti on työskentelee toteutusaikana. Ja tyypillisesti voin löytää ongelman, jos sellainen on tai jos olen tarpeeksi hyvä tarttumaan siihen.
OK, nyt puhun profiilista ja tässä tapauksessa tämä on profiili, jonka näen vianetsinnän kautta. Muista, että sanoin joskus he ovat erillisiä ja joskus he voivat olla yhdessä? Tässä tapauksessa olen jälleen kerran Rapid SQL: ssä ja näen, että vasemmalla puolella on marginaali rivinumeroiden vieressä. Ja mikä se on, on se sekuntien tai mikrosekuntien lukumäärä, joka kului kunkin koodirivin suorittamiseen, ja näen selvästi, että kaikki aikani vietetään tässä FOR-silmukassa, jossa valitsen kaiken taulukosta . Ja niin, mitä tahansa kyseisen FOR-silmukan sisällä tapahtuu, on luultavasti jotain, jota minun on tarkasteltava, ja jos voin parantaa sitä, 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 sekoitettuna virheenkorjaukseen. Nyt on hienoa, että 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 kun suoritus on suoritettu, se antaa minulle kaavioita kertoa minulle asiat, jotta voin nähdä, että minulla on yksi lause, joka näyttää siltä, että se aloittaa Suurin osa ympyräkaaviosta ja jos katson, näen siinä ruudussa alaosaa, riviä 23, siellä on taas FOR-silmukka: hän vie 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 erotettua profiloijaa. Jotkut ihmiset haluavat tehdä sen ensimmäisellä tavalla, toiset haluavat tehdä sen toisella tavalla.
Miksi teemme virheenkorjausta ja profilointia? Ei siksi, että haluamme kirjoittaa maailman suurimman koodin ja saada palkankorotuksen - se saattaa olla syy, mutta se ei oikeastaan ole miksi teet sen - lupasit yritykselle, että teet jotain oikein, että ohjelmasi on tehokas. Sitä varten käytät 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ä. Meidän piti lukea heidän mielensä ja tehdä kaikki heti. Toisin sanoen sen on oltava tehokasta. Ja niin, siihen me käyttäisimme profiilia. Nyt ilman näitä työkaluja uskon todella, että olet tämä mies, joka on työpuku jousella ja nuolella, ampuvat maaliin ja olet silmäsi. 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 tiettyihin näihin asioihin, mutta ei ole takuuta, 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. Minulla ei ole aikomustamme levittää tuotetta, haluan vain näyttää sinulle, millainen virheenkorjaaja näyttää ", koska monta kertaa ihmiset sanovat:" En ole koskaan nähnyt yhtä näistä aikaisemmin. "Ja se näyttää kauniilta ruudun napsautus dioilla., mutta miltä se näyttää liikkuessaan? 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ä ole kiinni tuotteesta. 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 nyt, tässä on nuoleni, se on ylhäällä rivillä, siinä olen koodissa. Ja jos painan siellä kolmatta kuvaketta, mikä on askel sisään, näet nuolen juuri siirtyneen, ja jos painan sitä edelleen, näet sen liikkuvan. Nyt, jos halusin mennä alas tähän FOR-silmukkaan, koska tiedän, että ongelma on siinä, voin asettaa väliajan. Ajattelin asettaa sen. Voi ampua, minulla oli yksi näytönkaappausnäppäimistä, jotka oli kartoitettu samaan avaimeen kuin virheenkorjaaja, se on sekaannuksen aiheuttaja. 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ä taitekohta on, joten olen nyt tämän silmukan käytön yhteydessä, näen, mihin kaikki muuttujat on asetettu, mikä ei ole yllätys, koska minä alustain ne kaikki nollaan. Ja nyt voin astua tähän silmukkaan ja alkaa tutkia mitä tämän silmukan sisällä tapahtuu.
Joten nyt se tekee valitun laskutuksen vuokraani ja voin hiirellä sen kaverin päälle ja katsoa, hän on 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 juosta. 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. Minulle on asetettu murtopiste, joten kun sanoin juoksevan, se vain palasi seuraavaan taukokohtaan. Annan sen käydä loppuun saakka, koska haluan sinun näkevän, että virheenkorjaus ei muuta ohjelman käyttäytymistä: kun se on suoritettu käynnissä, minun pitäisi saada täsmälleen samat tulokset, jos olisin ajaa sitä ei sisällä debugger.
Ja sen kanssa aion keskeyttää demon ja palata 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: Kyllä, varmasti, minusta tämä on kiehtovaa, tietenkin. Olen työskennellyt tällaisten asioiden kanssa, mutta en ole koskaan työskennellyt mitään tällaista tietokannassa. Voitteko antaa minulle kuvan siitä, mihin ihmiset käyttävät profiilia? Koska se on kuin mitä he katsovat - koska luulen olevansa - he etsivät suorituskykyon liittyviä kysymyksiä, auttaako se erottamaan toisistaan, milloin tietokanta vie aikaa ja kun koodi vie aikaa?
Bert Scalzo: Tiedätkö, se on upea kysymys. Oletetaan, että työskentelen Visual Basicissä ja kutsun Visual Basic -sovelluksen sisällä Transact-SQL: tä tai PL / SQL: tä. 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 Toimi seuraavasti ja sano: "OK, sadasta 100 lauseesta, jotka ovat aiheuttaneet ongelman, tässä on viisi, jotka aiheuttivat ongelman." Ja niin, joudut ehkä tekemään tag-tiimin, jossa sinun on käytettävä 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, soitamme tämän puhelun tähän koodinosaan 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 löydät tosiasiallisesti tehokkaan koodin, jota kutsutaan liian usein, ja se on tosiasiallisesti 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 siellä jälleen kerran en tehnyt - en ole koskaan itse ollut mukana rakentamassa sovelluksia, joihin meillä oli tallennettu menettelyjä, joten luulen, että en ole koskaan tosiasiallisesti joutunut ongelmiin, jotka ajavat minut villiksi, ajatuksen, että sinä Jakaa koodin tietokannan ja ohjelman välillä. Mutta niin, tee kaikki - oletan, että vastaus tulee olemaan kyllä, mutta tämä on osa kehitysryhmän toimintaa, kun yrität tavalla tai toisella korjata jotain rikkoutunutta tai ehkä yrittää tuoda uutta sovellus yhdessä. 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 voit suorittaa ohjelmointi- tai kehityspyrkimyksesi. Ja se on hauskaa, viime viikolla minulla oli asiakas, joka rakensi verkkosovellusta, ja heidän tietokantaansa oli historiallisesti ollut pieni, joten se, että he eivät olleet kovin 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 se on suorituskykyongelma. Ja he tiesivät, että ongelma ei ollut heidän Javassa tai missään muussa paikassa. 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 emmekä tienneet 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 ymmärrä, että he ovat juuri tuoneet takaisin miljardin levyn tai katselevat miljardia levyä, koska he saivat kiinnostuksensa.
Robin Bloor: Vau, tiedän, niin kutsutaan - No, Dez oli juuri tekeillä siinä suhteessa, että ihmiset eivät ole aivan yhtä taitavia kuin ehkä heidän pitäisi olla. 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 jollain tavalla tai toisella vain kielen agnostikko tässä suhteessa, 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 pidä ohjelmoijien heittämisestä bussin alle. Mutta ongelma on todella akateemisessa ympäristössä, koska kun opit olemaan ohjelmoija, sinulle opetetaan ennätysmääräistä ajattelua. Sinua ei opeteta joukkoajattelua, ja juuri sitä Strukturoitu kyselykieli tai SQL toimii joukkojen kanssa; siksi meillä on liitto, risteys ja miinusoperaattori. Ja joskus henkilölle, joka ei ole koskaan ajatellut sarjojensa suhteen, on erittäin vaikea lopettaa, päästä irti kerrallaan käsittelystä ja työskennellä sarjojen kanssa.
Robin Bloor: Joo, olen kanssasi siinä. Tarkoitan, että saan nyt, se on koulutusongelma; Mielestäni se on täysin koulutusongelma, mielestäni on luonnollista, että ohjelmoijat ajattelevat menettelytapoja. Ja SQL ei ole proseduurinen, se on deklaratiivinen. Sanot oikeastaan vain: "Tämän haluan ja minusta ei välitä miten teet sen", tiedätkö? Kun taas ohjelmointikielellä olet usein saanut hihat käärittyä ylös ja olet alas yksityiskohdissa jopa hallita laskut, kun teet silmukan. Annan …
Bert Scalzo: Ei. OK, 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. Oletetaan, että hän tekee kaksi FOR-silmukkaa ja pohjimmiltaan 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 viettäisit todennäköisesti enemmän aikaa tekemällä liittymistä käsin kuin antamalla tietokantapalvelimelle tehdä sen puolestasi.
Robin Bloor: Joo, se olisi katastrofi. Tarkoitan, että vain rakastelet. Heittäminen on aina huonoa.
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ä olen viettänyt liian monta vuotta elämässäni itse koodaajana, kaikilla tasoilla, tiedät, onko se kuten sanoit, istuessani Unix-koneen komentorivillä, ja joissain tapauksissa olin jopa mukana parissa erilaisessa Unix-portissa laitteistoalustalta toiselle. Ja voit kuvitella haasteet, joita meillä oli siellä. Mutta todellisuus on tässä "vankila-kortti" 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 kääntyvät sitten kahvin päällä koodikatselukeskusteluun ja selvittivät heidän kirjoittaneen 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ää 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, että kaikki vain yrittävät 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 komentosarjan avulla ja löytää joitain ongelmia, koska tiedät, että nykypäivänä me työskentelemme aina kaikkein edullisimmin.
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 sinulle maksetaan 400 000 dollaria vuodessa koodin kirjoittamiseksi täydellisesti; se on vain koko kehitys. Joten tuolla kohdalla luulen, että yksi kysymyksistä, jotka rakastan sinua antamaan meille vain lisää käsitystä, on se, minkä leveys ja ulottuvuus on ihmisille, joita näet tällä hetkellä ja jotka käyttävät tällaisia työkaluja profiiliin koodi ja etsi suorituskykyongelmia? 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ä? Että nyt saamme vähemmän, kuten Robin sanoi, akateemista lähestymistapaa, ja nyt se on itseoppinut, tai leikkaa ja liitä -koodi, vai vain rakenna asiat? Ja vastaako tämä sellaisia ihmisiä, jotka käyttävät tuotetta nyt?
Bert Scalzo: Kyllä, tarkalleen. Ja minä annan teille erityisen esimerkin, haluamme vain saada työ saatu aikaan, koska liikemiehet eivät halua täydellisyyttä. Se on tavallaan kuin tietokoneistettu shakkipeli: shakkipeli ei etsi täydellistä vastausta; se etsii riittävän hyvää vastausta kohtuullisessa ajassa, joten ohjelmoimme sen. Mutta mitä löydän nyt, on se, että useimmat ihmiset sen sijaan, että sanovat haluavansa profiilin osana yksikkötestaustaan - niin minä tekisin sen, koska en pidä sitä ajanhukana - mitä tapahtuu on Nyt kun se tehdään myöhemmin, joskus integraatiotestauksen tai stressitestauksen aikana, jos olemme onnekkaita. Mutta useimmiten se on osa kärjistystä, jossa jotain on mennyt tuotantoon, se juoksi jonkin aikaa, ehkä jopa juoksi vuosia, ja nyt se ei toimi hyvin, ja nyt me profiloimme sen. Ja se näyttää olevan nyt yleisin skenaario.
Dez Blanchfield: Joo, ja luulen, että termi ”tekninen velka” on todennäköisesti sellainen, jonka olet enemmän kuin tunteva; 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, tarkoitan, että meillä on omat projektimme, kuten Media Objektiivi ja muut, joissa koodausta tapahtuu päivittäin, ja erilaisia asioita Bloor-konsernissa. Ja aina kun rakennamme jotain, katsomme sellaista, katson sitä ja katson aina sen näkökulmasta, mistä minun maksaa korjata tämä nyt, tai voinko vain saada sen voi ja saada sen sieltä, ja sitten katsoa ja nähdä, jos tämä asia menee rikki. Ja perinyt tämän teknisen velan, jonka tiedän, että minun täytyy kiertää myöhemmin takaisin ja korjata.
Ja tarkoitan, olen tehnyt niin viimeisen seitsemän päivän aikana: olen kirjoittanut pari työkalua ja komentosarjaa, olen kirjoittanut pari kappaletta Python-kieltä, ja olen ottanut sen käyttöön Mongon takaosaan tekemällä Varmasti, että se on mukavaa, puhdasta ja turvallista, mutta saa vain tekemäni kyselyn tietäen, että tarvitsen tämän toiminnon toimiakseni päästäkseni isompaan palapeliin; siinä on todellinen tuskani. 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. Siellä 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ä olen todella rakentanut profilointityökaluja - rakensimme työkaluja Sedissä, Lexissä ja Orcissa ajaaksemme koodiamme ja nähdä missä silmukoita olivat, ennen kuin tällaiset työkalut olivat saatavilla - ja kun olet rakentanut koodin mennäksesi ja tarkista oma koodi, saat erittäin hyvän, että 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, minulla on - piirtän analogian sinulle ja näytän sinulle, että muut kuin ohjelmoijat tekevät sitä koko ajan. "Syy, jos opetan koskaan virheenkorjainta ja profilointiluokkaa tai istuntoa, kysyn ihmisiltä:" Okei, kuinka moni täällä käy Microsoft Wordiin ja ei koskaan tarkoituksella käytä oikeinkirjoituksen tarkistusta? "Ja kukaan ei nosta kättään, koska asiakirjojen kirjoittamisessa me kaikki tiedämme, että voimme tehdä englanninkielisiä virheitä, ja niin jokainen käyttää oikeinkirjoituksen tarkistusta. Ja sanoin: "No, miksi sitten kun kirjoitat tekstiä IDE: ssä kuten Visual Basic, et käytä debuggeria? Se on sama asia, se on kuin oikeinkirjoituksen tarkistaja. ”
Dez Blanchfield: Joo, oikeastaan, se on loistava analogia. En ollut oikein ajatellut, minun on myönnettävä, että teen tosissani 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 se on nyt mielenkiintoista tämänkaltaisella 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 loistava analogia tekstin lataamisesta tekstinkäsittelylaitteeseen, koska se on mielenkiintoinen herätyskeino, joka ymmärtää, että olet tehnyt joitain kirjoitusvirheitä tai jopa kielioppivirheen, eikö niin?
Bert Scalzo: Aivan.
Dez Blanchfield: Niin, 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 - oletan, että tämä on retorista - onko kyse siitä, että saatat aikaisin aikaan ja panat tämän täytäntöön, kun kehität, ennen kuin kehität? Tai onko kyse siitä, että rakennat pääasiassa, siirryt liikkumaan, rakennat jotain ja tulet sitten sisään ja profiloit sen myöhemmin? Epäilen, että kyse on sisäänkirjautumisesta aikaisin ja varmista, että koodisi on puhdas 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 vain saivat asioita aikaan, he eivät yleensä tee sitä ennen kuin joutuvat esiin suorituskykyongelmaan, jota he eivät pysty ratkaisemaan lisäämällä prosessoreita ja muistia virtuaalikoneeseen.
Dez Blanchfield: Kyllä. 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 luulen, että se on sellainen, mihin uusi rohkea maailma menee. Joten, Eric. Aion palata takaisin teille nyt ja nähdä, että meillä on täällä muutama kysymys ja haluan, että osallistujamme pysyvät edelleen luonamme, vaikka olemmekin ohittaneet tunnin.
Eric Kavanagh: Joo, siellä on muutama ihminen, teen vain lyhyen kommentin: 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 konteksti, mitä teet ja kuinka arvokas 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ämmästyttää tyhmiä kirjoitusvirheitä. ”No, he eivät halua hämmentyvän tyhmien koodausvirheiden takia!
Eric Kavanagh: Oikein. Todellakin. Ihmiset, olemme palanneet tunnin ja viiden minuutin ajan täällä, 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äämme tämän tähän luetteloon täällä.
Ja sen kanssa, me jäämme jäähyväiset, ihmiset. Uudelleen upea työ, Bert, IDERA-ystävämme kiitos. Puhumme kanssasi ensi kerralla, puhumme sinäkin ensi viikolla. Pitää huolta! Hei hei.
