Autors: Techopedia Staff, 2017. gada 15. marts
Takeaway: Uzņēmējs Ēriks Kavanagh apsprieda datu bāzu atkļūdošanu un profilēšanu ar Dr. Robinu Blooru, Dezu Blanšfīldu un IDERA Bertu Skalzo.
Pašlaik neesat pieteicies. Lai redzētu video, lūdzu, pierakstieties vai reģistrējieties.
Ēriks Kavanagh: Labi, dāmas un kungi, trešdien ir pulksten 4:00 pēc Austrumu laika, un tas, protams, nozīmē.
Robins Bloors: Es tevi nedzirdu, Ēriks.
Ēriks Kavanagh: Es biju tur pirms dienām, tāpēc tu neesi viens. Bet tāpēc šodien tēma ir patiešām interesanta. Tā ir lieta, par kuru vēlaties pārliecināties, ka jūsu uzņēmumā notiek fona, ja vien jūs neesat cilvēks, kas to dara, un tādā gadījumā jūs vēlaties pārliecināties, ka darāt to pareizi. Jo mēs runājam par atkļūdošanu. Nevienam nepatīk kļūdas, nevienam nepatīk, kad programmatūra pārstāj darboties - cilvēki apbēdina, lietotāji kļūst nedraudzīgi. Tas nav labi. Tātad, mēs runāsim par "Ātru reaģēšanu: datu bāzes atkļūdošana un glābšanas profilēšana".
Šeit ir informācija par jūsu patiesību, mani uzmeklē Twitter, protams, @eric_kavanagh.
Šis gads ir karsts. Un atkļūdošana būs karsta neatkarīgi no tā. Tā patiešām būs viena no šīm problēmām, kas nekad nezudīs, neatkarīgi no tā, cik labi mēs saskatāmies ar šīm lietām, vienmēr būs problēmas, tāpēc galvenais ir, kā nokļūt tur, kur jūs varat ātri atrisināt šīs problēmas? Ideālā gadījumā jums ir lieliski programmētāji, lieliska vide, kur ne pārāk daudz kas noiet greizi, bet, kā saka senais teiciens: “Negadījumi notiek vislabākajā ģimenē.” Un tas pats attiecas uz organizācijām. Tātad, notiek šie notikumi, tā notiks, jautājums ir, kāds būs jūsu risinājums, lai to risinātu un atrisinātu šīs problēmas?
Mēs dzirdēsim no Dr Robin Bloor, pēc tam mūsu Dez Blanchfield no apakšas, un, protams, no mūsu labās draudzenes Bert Scalzo no IDERA. Un patiesībā es nodošu Robin Bloor atslēgas, atņemšu to. Stāvs ir jūsu.
Robins Bloors: Labi. Šī ir interesanta tēma. Es domāju, ka tāpēc, ka Dez, iespējams, ķersies pie aktuālajām metodēm un kara stāstiem par atkļūdošanu, es domāju, ka es darīšu tikai fona diskusiju, lai mums būtu pilnībā noapaļots attēls par notiekošo. Es to darīju ilgu laiku, un es kādreiz biju kodētājs, tāpēc tas ir tāpat, un man bija gandrīz vilinājums ar šo prezentāciju sākt liriski izteikties par atvērtā koda ideju, bet es domāju, ka to atstāšu kādam citam.
Šeit ir slaveno kļūdu saraksts, un lielākā daļa no tām iekļūst ikviena populārākajā sarakstā, būtībā visas, izņemot pēdējās divas, maksā vismaz 100 miljonus USD. Pirmais bija Marsa klimata orbiters, pazuda kosmosā, un tas notika kodēšanas problēmas dēļ, kur cilvēki jauc metriskās vienības ar (smejas) kājām un collām. Ariane Five Flight 501 radās neatbilstība starp uzlikto motoru un datoriem, kuriem vajadzēja darbināt raķeti, kad tā tika palaista. Vairākas datora kļūmes, eksplodējoša raķete, jaunumi virsrakstā. Padomju gāzes vads 1982. gadā tika uzskatīts par lielāko sprādzienu planētas vēsturē; Es neesmu pārliecināts, vai tas tā ir. Krievi nozaga kādu automatizētu vadības programmatūru, un CIP saprata, ka viņi to darīs, un ievietoja tajā kļūdas, un padomji to ieviesa bez pārbaudes. Tātad, uzpūta cauruļvadu uz augšu, domāja, ka tas ir uzjautrinoši.
Morisa tārps bija kodēšanas eksperiments, kas pēkšņi kļuva par pārnēsājamu tārpu, kurš gāja apkārt visiem - tas acīmredzot nodarīja 100 miljonu dolāru vērtu kaitējumu; tas, protams, ir aprēķins. Intel pieļāva slavenu kļūdu ar matemātikas mikroshēmu - matemātikas instrukciju Pentium mikroshēmā 1993. gadā -, domājams, tai bija jāmaksā vairāk nekā 100 miljoni USD. Apple Maps programma, iespējams, ir vissliktākā un postošākā atklāšana jebkam, ko Apple jebkad ir darījis. Cilvēki, kas mēģināja to izmantot, es domāju, ka kāds brauca pa 101, un atklāja, ka Apple Map saka, ka viņi atrodas Sanfrancisko līča vidū. Tātad cilvēki sāka atsaukties uz Apple Maps lietotni kā iLost. Mūsu garākais pārtraukums 1990. gadā - tas ir tikai interesanti no kaut kā tā izmaksām - AT&T darbojās apmēram deviņas stundas un tālsarunās maksāja apmēram 60 miljonus USD.
Es biju Lielbritānijas apdrošināšanas uzņēmumā un datu bāzē, viņi ieviesa jaunu datu bāzes versiju, un tā sāka noslaucīt datus. Un es to ļoti labi atceros, jo pēc tam mani uzaicināja piedalīties kaut kāda veida datu bāzes atlasē. Un bija ļoti interesanti, ka viņi bija paņēmuši jaunu datu bāzes versiju, un viņiem bija daudz testu, ko viņi veica jaunām datu bāzes versijām, ka tā izturēja visus testus. Tas atrada patiešām neskaidru datu iznīcināšanas veidu.
Tātad, jebkurā gadījumā, tas ir tas. Es domāju, ka es runāšu par pretestības neatbilstību un izsniegto SQL. Interesanti, ka relāciju datu bāzēs dati tiek glabāti tabulās, un kodētāji mēdz manipulēt ar datiem objektu struktūrās, kas tabulās tiešām nav ļoti labi saderīgas. Un tāpēc jūs saņemat to, ko sauc par pretestības neatbilstību, un kādam tas kaut kādā vai citādā veidā ir jārisina. Bet kas notiek patiesībā, jo viens modelis, kodētāja modelis un cits datu bāze, nav īpaši saskaņoti. Jūs saņemat kļūdas, kas vienkārši nenotiktu, ja nozare būtu uzbūvējusi lietas, kas darbojas kopā, kas, manuprāt, ir jautrs. Tātad, galvenokārt, kodētāju pusē, kad jūs saņemat hierarhijas, tas var būt tips, tas var būt rezultātu kopas, tā var būt vāja API spēja, tā var būt daudz lietu, kas vienkārši izmet lietas attiecībā uz mijiedarbību ar datu bāzi. Bet lieta, kas man visvairāk patīk, tiešām ir interesanta; vienmēr mani pārsteidza, ka jums ir šī SQL barjera, kas ir arī sava veida pretestība tādā veidā, ka kodētāji un datu bāze strādā savā starpā. Tātad, SQL ir datu atpazīšana, kas ir laba, un tai ir DML atlasīšanai, projektēšanai un pievienošanai, kas ir lieliski. Jūs varat izmantot daudz iespēju, kā ar to iegūt datus no datu bāzes. Bet tam ir ļoti maz matemātiskas valodas lietu veikšanai. Tam ir nedaudz šī un tā, un tam ir ļoti maz laika pamatotu lietu. Tāpēc SQL ir nepilnīgs, ja vēlaties, datu iegūšanas līdzeklis. Tātad, datu bāzes puiši izveidoja glabātās procedūras, lai dzīvotu datu bāzē, un tur dzīvojošo procedūru iemesls bija tas, ka jūs patiešām nevēlējāties datus mest uz priekšu un atpakaļ uz programmu.
Daļai funkcionalitātes bija ārkārtīgi specifiska datu specifika, tāpēc tā nebija tikai atsauces integritāte un izdzēstu kaskādes un tamlīdzīgas lietas, datu bāze rūpējās par pēkšņu funkcionalitātes ievietošanu datu bāzē, kas, protams, nozīmēja, ka lietojumprogrammas funkcionalitāti var sadalīt starp kodētāju un pašu datu bāzi. Un tas dažu veidu funkciju ieviešanu padarīja patiešām diezgan grūtu, tāpēc tā bija vairāk pakļauta kļūdām. Tā ir viena datu bāzes spēles puse, jo tas nozīmē, ka, piemēram, esat iesaistījies daudzās implementācijās, ka esmu bijis iesaistīts relāciju datu bāzēs, tur tiešām ir šausmīgi daudz kodu, kas atrodas glabātajās procedūrās un tiek apstrādāti atsevišķi no koda, kas atrodas programmās. Un tas, šķiet, ir ļoti dīvaini, it kā būtu diezgan gudri, veicot dažādas lietas.
Es domāju, ka es runāšu arī par datu bāzu veiktspēju, jo veiktspējas kļūdas bieži tiek uzskatītas par kļūdām, taču būtībā jums var būt sašaurinājums centrālajā centrā, atmiņā, diskā, tīklā un bloķēšanas dēļ var rasties veiktspējas problēmas. . Ideja būtu tāda, ka kodētājam patiesībā nav jāuztraucas par veiktspēju un datu bāze faktiski darbosies samērā labi. Tas ir paredzēts tā, lai kodētājam tas nebūtu jāzina. Tomēr jūs saņemat sliktu datu bāzes dizainu, jūs saņemat sliktu programmu dizainu, jūs saņemat vienlaicīgumu darba slodzes sajaukšanā, kas arī var izraisīt veiktspējas problēmas. Jūs saņemat slodzes līdzsvarošanu, kapacitātes plānošanu, datu pieaugumu - tas var izraisīt datu bāzes vienkārši apstāšanos vai palēnināšanos. Tā ir interesanta lieta, kad datu bāzes kļūst gandrīz pilnas, tās palēninās. Datu slāņi var būt saistīti ar replikāciju un replikācijas nepieciešamību, kā arī dublēšanu un atjaunošanu. Jebkurā gadījumā tas ir vispārīgs pārskats.
Vienīgais, ko es gribētu pateikt, ir tas, ka datubāzu atkļūdošana var būt tikai tik apgrūtinoša un nebūtiska - un es to saku tāpēc, ka esmu to izdarījusi daudz - un jūs bieži atklāsit, ka tas ir tāpat kā visās atkļūdošanas situācijās. kādreiz pieredzētais ir, ir pirmā lieta, ko jūs kādreiz redzat, ir haoss. Un jums ir jāmēģina no putru puses izdomāt, kā šie putni radās. Un bieži vien, aplūkojot datu bāzes problēmu, viss, ko skatāt, ir bojāti dati un jūs domājat: “Kā ellē tas notika?”
Jebkurā gadījumā es nodošu Dezam, kurš, iespējams, sacīs vairāk gudrības vārdu, nekā es izdomāju. Es nezinu, kā nodot tev bumbu, Dez.
Ēriks Kavaņahs: Es to izturēšu, stāvēšu blakus, turēšos.
Automatizēta balss: dalībnieku līnijas tiek izslēgtas.
Ēriks Kavanaghs: Labi, pakavējieties vienu sekundi, ļaujiet man dot Dezam bumbiņu.
Dezs Blanšfīlds: Paldies, Ēriks. Jā, Dr Robin Bloor, jums patiešām ir visaugstākā taisnība: šī ir tēma, mūža garlaicīga vaina, ja jūs apžēlojaties ar sodu. Atvainojiet, ka es nevarēju sev palīdzēt šajā jautājumā. Cerams, ka tur varēsit redzēt manu pirmo ekrānu, atvainošanos par fonta lieluma problēmu augšpusē. Kļūdu tēma ir visas dienas lekcija, daudzos gadījumos pēc manas pieredzes. Tā ir tik plaša un plaša tēma, tāpēc es koncentrēšos uz divām galvenajām jomām, īpaši uz koncepciju, kuru mēs uzskatām par tik daudz kļūdu, bet gan uz programmēšanas problēmu. Es domāju, ka šajās dienās kļūdas ieviešana pati par sevi parasti tiek pieņemta ar integrētu attīstības vidi, lai gan tās var būt ilgstošas kļūdas. Bet bieži tas ir vairāk saistīts ar koda profilēšanu un ir iespējams uzrakstīt kodu, kas darbojas, tam vajadzētu būt kļūdai. Tātad, mans nosaukums slīd šeit, man faktiski bija šī kopija ļoti augstā izšķirtspējā A3, bet diemžēl tas tika iznīcināts, pārceļoties mājā. Bet šī ir ar roku rakstīta piezīme uz programmēšanas lapas no 1945. gada apmēram, kur it kā daži cilvēki Hārvardas universitātē ASV, viņu otrā mašīna, ko sauc par Marku II. Viņi atkļūdoja kādu problēmu kopējā valodā, bet viņi mēģināja atrast kļūdu, un izrādās, ka radās kaut kas nedaudz atšķirīgs no tā, kas bija aparatūras un it kā programmatūras jautājums.
Pilsētas mīts ir tāds, ka ap 1945. gada 9. septembri Hārvarda universitātes komanda izvilka mašīnu, viņi saskārās ar kaut ko, ko viņi sauca par “septiņdesmit releju” - tajos laikos programmēšana tika veikta fiziskā nozīmē, jūs ievainojāt kodu ap dēli, un tas bija, kā jūs efektīvi programmējāt mašīnu - un viņi atrada šo stafetes numuru septiņdesmit, tajā bija kaut kas nepareizs, un izrādās, ka patiesais termins “kļūda” radās tāpēc, ka tas burtiski bija kandža - domājams, ka tur bija kode, kas bija iesprausta starp kādu vara stieples gabalu, kas gāja no vienas vietas uz otru. Un stāsts ir tāds, ka leģendārais Grace Hopper kā šis titrs manā nosaukuma slaidā “pirmais faktiskais kļūdas gadījums” ir citēts.
Bet kā Robins jau uzsvēra savā pirmajā slaidā, kļūdas jēdziens sniedzas tik tālu, kā mēs varam iedomāties, ka cilvēki veic aprēķinus, tādus jēdzienus kā plāksteris. Termins “plāksteris” radās no tā, ka faktiskais lentes gabals ir piestiprināts virs cauruma perforatorā. Bet visa šī jēga ir tāda, ka termins “atkļūdošana” iznāca no šī jēdziena kļūdas atrašana fiziskā mašīnā. Kopš tā laika mēs esam izmantojuši šo terminoloģiju, mēģinot risināt problēmas, vai nu ne tik daudz kā kodēšanas problēmas programmā, kas nesastāv, bet gan kā programma, kas nedarbojas labi. Un īpaši nav profilēts, atrodiet tādas lietas kā nebeidzamas cilpas, kas vienkārši nekur neiet.
Bet mums ir arī scenārijs, un es domāju, ka es ielikšu pāris smieklīgus slaidus, pirms es iedziļināšos mazliet sīkāk. Šeit ir klasiskā karikatūra, ko tīmeklī sauc par XKCD, un karikatūristam ir diezgan smieklīgi skati uz pasauli. Un tas ir par kazlēnu ar nosaukumu “Mazais Bobija galdi” un domājams, ka viņa vecāki šo jauno zēnu nosauca par Robertu ”); DROP TABLE Studenti; - un to sauc, un tas ir “Sveiks, šī ir jūsu dēla skola, kurā ir zināmas datora problēmas”, un vecāks atbild: “Ak, dārgais, vai viņš kaut ko salauza?”, Un skolotājs saka: “Nu, savā ziņā ”, un skolotājs jautā:“ vai jūs tiešām nosaucāt savu dēlu Robertu ”); DROP TABLE Studenti; -? ”Un vecāks saka:“ Ak jā, mazos Bobija galdus, kurus mēs viņu saucam. ”Jebkurā gadījumā viņi turpina teikt, ka tagad ir zaudējuši studentu gada ierakstus, es ceru, ka esat laimīgs. Un atbilde ir: “Nu, jums vajadzētu iztīrīt un sanitārizēt savus datu bāzes ievadus.” Un es to daudzkārt izmantoju, lai runātu par dažām problēmām, kas mums rodas, atrodot lietas kodā, ka bieži vien kods neskatās datus arī.
Vēl viens smieklīgs, es nezinu, vai tas ir īsts vai nē - man ir aizdomas, ka tas ir mānīšanās -, bet atkal tas skar arī manu smieklīgo kaulu. Kāds maina numura zīmi savas automašīnas priekšpusē līdzīgam paziņojumam, kura dēļ datu bāzēs samazinās ātruma kameras un tā tālāk, kas fiksē automašīnu numura zīmes. Un es vienmēr uz to domāju, ka es šaubos, vai kāds programmētājs paredzēja, ka viņu kods tiks iedarbināts ar reālu mehānisko transportlīdzekli, bet nekad to nenovērtēju - dusmīga geipa spēku.
(Smiekli)
Bet tas, manuprāt, ved pie mana galvenā jautājuma, un tas ir, ka reiz mēs varētu atkļūdošanu un profila kodu kā vienkāršus mirstīgos. Bet es ļoti uzskatu, ka šis laiks ir pagājis, un, pateicoties manai pieredzei, tas ir mans pirmais - un tas mani briesmīgi novecos, es esmu pārliecināts; Robins, jūs esat laipni aicināts par mani izklaidēties - taču vēsturiski esmu nācis no fona 14 gadu vecumā, kurš klīst pa pilsētas galu un klauvē pie datu centra ar nosaukumu “Data Com” durvīm Jaunajā Jaunzēlande un jautā, vai es varētu nopelnīt kabatas naudu skolā, katru dienu dodoties mājās ar nokavēto autobusu, apmēram 25 km no mājupslīdes, braucot ar printeri un ievietojot lentes lentēs, un vienkārši būdams vispārējais administrators. Un dīvaini, ka viņi man deva darbu. Bet laika gaitā man izdevās iesaistīties personāla komplektēšanā un atrast programmētājus, un es sapratu, ka mīlu kodēšanu un izgāju skriptu un pakešdarbu palaišanas procesu, kas dienas beigās joprojām ir kods. Jums ir jāraksta skripti un sērijveida darbi, kas izskatās pēc mini programmām, un pēc tam viss process jāsēž 3270 termināļa rakstīšanas kodā ar roku.
Faktiski mana pati pirmā pieredze bija ar teletipa termināli, kas faktiski bija 132 kolonnu fiziskais printeris. Būtībā domājiet par ļoti vecu rakstāmmašīnu ar papīru, kas tam ritēja cauri, jo viņiem nebija CRT caurules. Un koda atkļūdošana šajā jautājumā bija ļoti mazsvarīgs jautājums, tāpēc jums bija tendence visu kodu rakstīt ar roku un pēc tam rīkoties kā mašīnrakstītājam, darot visu iespējamo, lai nekļūdītos kļūdas, jo tas ir ārkārtīgi nomākti. vienas rindas redaktors, lai pārietu uz noteiktu rindu un pēc tam izdrukātu līniju un pēc tam ierakstītu to atpakaļ. Bet reiz tas bija tas, kā mēs rakstījām kodu, un tā mēs atkļūdojām, un mums tas ļoti, ļoti izdevīgi izdevās. Un patiesībā tas mums piespieda ļoti labas programmēšanas tehnikas, jo to labot bija ļoti grūti. Bet tad ceļojums gāja cauri - un to mēs visi zinām - tas devās no 3270 termināļa pieredzes manā pasaulē uz Digital Equipment VT220, kur jūs varēja redzēt lietas uz ekrāna, bet atkal jūs darījāt tikai to pašu jūs to darījāt papīra formāta drukātajā formātā tikai CRT, taču jums bija vieglāk izdzēst un jums nebija skaņas “dit dit dit dit”.
Un tad jūs zināt, ka Wyse termināļi - piemēram, Wyse 150, iespējams, mans iecienītākais interfeiss datoram jebkad - un tad dators un pēc tam Mac, un šajās dienās mūsdienīgas GUI un ID, kas balstīti uz Web. Un virkne programmu caur to, programmēšana vienā un montētājā, kā arī PILOT un Logo un Lisp un un Fortran un Pascal un valodas, kas varētu likt cilvēkiem saspringt. Bet šīs ir valodas, kas piespieda jūs uzrakstīt labu kodu; viņi neļāva jums izvairīties no sliktas prakses. C, C ++, Java, Ruby, Python - un mēs nonākam tālāk šajā programmēšanas posmā, mēs kļūstam vairāk skriptiem līdzīgi, mēs arvien tuvāk un tuvāk strukturētai vaicājumu valodai un valodām, piemēram, PHP, kuras faktiski tiek izmantotas, lai izsauktu SQL. Punkts jums pateikt, tas ir, ņemot vērā manus apstākļus, es daudzējādā ziņā patstāvīgi mācījos, un tie, kas man palīdzēja mācīties, iemācīja man ļoti labu programmēšanas praksi un ļoti labu praksi attiecībā uz dizainu un procesiem, lai pārliecinātos, ka man nav ieviest buggy kodu.
Mūsdienās programmēšanas metodes, piemēram, SQL, ir strukturēta vaicājumu valoda, tā ir ļoti spēcīga, vienkārša vaicājumu valoda. Bet mēs to esam pārvēruši par programmēšanas valodu, un es īsti neticu, ka SQL kādreiz tika izstrādāts kā moderna programmēšanas valoda, taču mēs to esam sagrozījuši, lai tā kļūtu. Un tas ievieš veselu virkni jautājumu, kas radušies, domājot par diviem aspektiem: no kodēšanas un DBA viedokļa. Ir ļoti viegli nākt klajā ar tādām kļūdām kā tikai sliktas programmēšanas metodes, slinki centieni koda rakstīšanā, pieredzes trūkums, piemēram, klasiskā mājdzīvnieka mīkla, kas, piemēram, notiek ar SQL cilvēkiem, kuri lec Google, meklē kaut ko un atrod tīmekļa vietni ieguva piemēru un izdarīja esošā koda kopiju un ielīmēšanu. Un pēc tam atkārtojiet sliktu kodēšanu, nepareizu praksi un nododiet to ražošanai, jo tas vienkārši viņiem dod vēlamos rezultātus. Jums ir citi izaicinājumi, piemēram, šajās dienās mēs visi steidzamies uz to, ko mēs saucam par sacensību līdz nullei: cenšamies darīt visu tik lēti un tik ātri, ka mums ir scenārijs, kurā mēs nenodarbinām zemāku algots personāls. Un es to nenozīmē nepatīkamā veidā, bet mēs nealgojam ekspertus katram iespējamam darbam. Reiz viss, kas bija saistīts ar datoriem, bija raķešu zinātne; tas bija iesaistīts lietās, kas aizrāvās un bija ļoti skaļas, vai devās kosmosā, vai inženieri bija augsti kvalificēti vīrieši un sievietes, kuri bija ieguvuši grādus un ieguvuši stingru izglītību, kas viņus neļāva darīt trakas lietas.
Mūsdienās izstrādē un dizainā un datu bāzē iesaistās ļoti daudz cilvēku, kuriem nav gadu pieredzes, kuriem nav bijusi tāda pati apmācība vai atbalsts. Un tā jūs beidzat ar scenāriju, kurā redzami tikai tradicionālie amatieri un eksperti. Un tur ir slavena līnija, es faktiski neatceros, kurš izveidoja citātu, šī līnija iet: “Ja jūs domājat, ka ir dārgi nolīgt ekspertu, lai veiktu darbu, pagaidiet, kamēr jūs nolīgsit pāris amatierus, kuri rada problēmu, un jūs tas ir jāattīra. ”Un tāpēc SQL ir šī problēma, un to ir ļoti, ļoti viegli iemācīties, to ir ļoti viegli izmantot. Bet tā, manuprāt, nav perfekta programmēšanas valoda. Tas ir ļoti viegli, piemēram, izdarīt izvēles zvaigzni no jebkuras vietas un ievilkt to programmēšanas valodā, kas jums ir ērtāka, piemēram, PHP, Ruby vai Python, un izmantot programmēšanas valodu, kuru jūs esat dzimtā valoda. datu manipulācijas, nevis veikt sarežģītāku vaicājumu SQL. Mēs to daudz redzam, un tad cilvēki brīnās, kāpēc datu bāze darbojas lēni; tas notiek tāpēc, ka miljons cilvēku mēģina iegādāties biļeti no tiešsaistes biļešu sistēmas, kur tā izvēlas zvaigzni no jebkuras vietas.
Tagad, tas ir patiešām ekstrēms piemērs, bet jums tas viss liekas vērā. Tātad, lai šo punktu mājās patiešām sadurstu, lūk, piemērs, kuru es daudz pārvadāju. Es esmu liels matemātikas cienītājs, es mīlu haosa teoriju, es mīlu Mandelbrota kopas. Labajā pusē ir Mandelbrota komplekta pārsūtījums, ar kuru es esmu pārliecināts, ka mēs visi esam pazīstami. Un kreisajā pusē atrodas SQL gabals, kas to faktiski padara. Tagad, katru reizi, kad kaut kur to uzlieku ekrānam, dzirdu: “Ak, mans dievs, kāds Mandelbrota sēriju atveidoja ar SQL, vai tu nopietni? Tas ir nenormāli! ”Nu, visa tā jēga ir ilustrēt to, ko es tur vienkārši ieskicēju, un tas ir jā, patiesībā jūs tagad varat programmēt gandrīz jebko SQL; tā ir ļoti attīstīta, spēcīga, moderna programmēšanas valoda. Ja sākotnēji tā bija vaicājumu valoda, tā tika izstrādāta, lai tikai iegūtu datus. Tātad, tagad mums ir ļoti sarežģītas konstrukcijas un glabātas procedūras, programmēšanas metodika tiek piemērota valodai, un tāpēc to ir ļoti viegli veikt sliktas programmēšanas prakses, pieredzes trūkuma, izgrieztā un ielīmētā koda dēļ, zemu atalgoti darbinieki, kas cenšas būt augsti apmaksāti darbinieki, cilvēki izliekas, ka zina, bet viņiem ir jāmācās darbā.
Vesela virkne lietu, kur koda profilēšana un ko mēs dēvējam par atkļūdošanu, kas ir ne tikai kļūdu atrašana, kas pārtrauc programmu darbību, bet kļūdas, kas tikai kaitē sistēmai, un slikti strukturēts kods. Kad jūs tagad skatāties šajā ekrānā un domājat, ka tas ir vienkārši jauki, jūs domājat: “Oho, cik lielisks grafiks, es labprāt to vadītu.” Bet iedomājieties, ka darbojas kaut kāda biznesa loģika. . Tas izskatās diezgan glīti, taču runā par matemātiski grafiski atveidotu haosa teoriju, bet, domājot par to, ko tā potenciāli varētu izmantot kādā biznesa loģikā, attēls tiek iegūts ļoti ātri. Un, lai to patiešām ilustrētu - un man žēl, ka krāsas ir mainītas, it kā būtu jābūt melnam fonam un zaļam tekstam, lai tas būtu zaļš ekrāns, bet jūs to joprojām varat lasīt.
Es devos un ātri apskatīju piemēru tam, ko jūs varētu darīt, ja jūs patiešām esat traks un jums nebija nekādas pieredzes, kā arī nācāt no atšķirīga programmēšanas fona un lietojāt C ++ patīk SQL, lai patiešām ilustrētu manu viedokli. Es nododu mūsu iemācītajam viesim no IDERA. Šis ir strukturēts vaicājums, kas uzrakstīts tāpat kā C ++, bet ir kodēts SQL. Un tas faktiski tiek izpildīts, bet tas tiek izpildīts apmēram trīs līdz piecu minūšu laikā. Un tas šķietami atvelk vienu datu rindu no vairākām datu bāzēm, vairākiem savienojumiem.
Atkal viss šī jēga ir tāda, ka, ja jums nav pareizo rīku, ja jums nav pareizu platformu un vides, lai varētu noķert šīs lietas, un tās nonāk ražošanā, un tad jums ir 100 000 cilvēku sitot sistēmu katru dienu, stundu vai minūti, ļoti drīz jūs nonākat pie Černobiļas pieredzes, kad lielais dzelzs sāk izkausēt un aprakt sevi planētas kodolā, jo šis koda gabals nekad nedrīkst nonākt ražošanā. Atvainojiet, jūsu sistēmām un rīkiem vajadzētu to paņemt pirms tā nonākšanas kaut kur netālu - pat testa procesa laikā, pat izmantojot UAT un sistēmu integrāciju - šis koda gabals ir jāpaņem un jāizceļ, un kāds ir jānovieto malā un sakot: “Lūk, tas tiešām ir diezgan kods, bet iegūsim DBA, lai palīdzētu jums pareizi izveidot šo strukturēto vaicājumu, jo atklāti sakot, tas ir vienkārši nejauki.” Un tur ir URL, jūs varat doties un paskatīties - tas tiek dēvēts par vissarežģītākais SQL vaicājums, ko jūs jebkad esat uzrakstījis. Tā kā ticiet man, tas, kas faktiski apkopo, tas arī darbojas. Un, ja jūs to izgriezat un ielīmējat, un tikai piemārat datu bāzi, to ir diezgan ko skatīties; ja jums ir rīki datu bāzes skatīšanai, vienkārši mēģiniet nojaukt trīs līdz piecu minūšu laikā, lai atzvanītu, kas ir viena teksta rindiņa.
Tātad, apkopojot visu iepriekš minēto, kodēšana man ir iemācījusi, ka jūs varat dot cilvēkiem pistoli un, ja viņi nav uzmanīgi, viņi šauj sev pa pēdām; triks ir parādīt viņiem, kur atrodas drošības mehānisms. Izmantojot pareizos rīkus un pareizo programmatūru, kas atrodas pa rokai, pēc kodēšanas pabeigšanas jūs varat pārskatīt savu kodu, jūs varat atrast problēmas, profilējot kodu, jūs varat atrast efektīvi neparedzētas kļūdas, kas ir veiktspējas problēmas, un kā es teicu agrāk jūs kādreiz to varēja izdarīt, skatoties uz zaļu ekrānu. Jūs vairs nevarat; ir simtiem tūkstošu koda rindiņu, ir izvietoti desmitiem tūkstošu lietotņu, dažos gadījumos ir miljoniem datu bāzu, un pat supercilvēki to vairs faktiski nevar izdarīt ar roku. Jums burtiski ir vajadzīga pareiza programmatūra un pareizie rīki, kas atrodas pa rokai, un jums ir nepieciešama komanda, kas izmanto šos rīkus, lai jūs varētu atrast šos jautājumus un ļoti, ļoti ātri tos risināt, pirms nokļūstat vietā, tā kā Dr. Izceļot Robinu Blooru, lietas vai nu kļūst katastrofālas, un lietas uzsprāgst, vai arī parasti tās tikai sāk maksāt jums daudz dolāru, daudz laika un pūļu, kā arī iznīcina morāli un citas lietas, kad viņi nespēj noskaidrot, kāpēc viss notiek ilgi jāskrien.
Paturot to prātā, es došos nodot mūsu viesim un es ceru dzirdēt, kā viņi ir atrisinājuši šo jautājumu. Un jo īpaši demonstrāciju, kuru es domāju, ka mēs drīzumā saņemsim. Ēriks, es atgriezīšos pāri.
Ēriks Kavanaghs: Labi, Bert, atņem to.
Berts Scalzo: Labi, paldies. Bert Scalzo šeit no IDERA, es esmu mūsu datu bāzes rīku produktu menedžeris. Un es runāšu par atkļūdošanu. Es domāju, ka viena no vissvarīgākajām lietām, ko Robins teica jau iepriekš - un tā ir ļoti taisnība, ir tas, ka atkļūdošana ir apgrūtinoša un nav triviāla, un, kad jūs apmeklējat datu bāzu atkļūdošanu, tā ir vēl lielāka apgrūtinājuma un ne-triviāla apjoma secība - tā, ka bija svarīgs citāts.
LABI. Es gribēju sākt ar programmēšanas vēsturi, jo daudz reižu es redzu cilvēkus, kuri nemāk atkļūdot, neizmanto atkļūdotāju, viņi vienkārši programmē ar jebkuru valodu, kuru viņi lieto, un daudz reižu viņi man teiks, “Nu, tās atkļūdotāju lietas ir jaunas, un mēs tās vēl neesam sākušas izmantot.” Un tāpēc es daru viņiem parādītu šo laika grafiku, sava veida pirmsvēstures, vecumdienas, viduslaikus, tas ir laipns sakot, kur mēs bijām programmēšanas valodu ziņā. Un mums bija ļoti senas valodas, sākot ar 1951. gadu, ar montāžas kodu, kā arī Lisp, FACT un COBOL. Tad mēs nokļūstam nākamajā grupā, Pascals un Cs, un tad nākamajā grupā, C ++, un skatāmies, kur ir šī jautājuma zīme - šī jautājuma zīme ir aptuveni pa labi ap 1978. gadu vai varbūt 1980. gadu. Kaut kur šajā diapazonā mums bija atkļūdotāji, kas mums ir pieejami, un tā teikt: “Ei, es neizmantoju atkļūdotāju, “ jo tā ir viena no tām jaunajām lietām ”, tad jums, iespējams, ir jāsāk programmēšana, 50. gados, jo tas ir vienīgais veids, kā jūs varētu atbrīvoties no šīs prasības.
Otra lieta, kas ir smieklīga šajā diagrammā, ir Dez, kas tikko izteica komentāru par Grace Hopper, es patiesībā zināju Grace, tāpēc tas ir sava veida smieklīgs. Un tad otra lieta, par kuru es smējos, ir tas, ka viņš runāja par teletipiem, un es tur sēžu, ejot: “Cilvēks, tas bija lielākais lēciens, kāds mums jebkad ir bijis produktivitātē, pārejot no kartēm uz teletipiem, tas bija lielākais lēciens jebkad. “Tātad, un es esmu ieprogrammējis visās valodās šeit, ieskaitot SNOBOL, par kurām neviens vēl nekad nav dzirdējis, tas bija CDC, Control Data Corporation, tāpēc es domāju, ka šai nozarei esmu mazliet novecojis. .
Dezs Blanšfīlds: Es grasījos teikt, ka jūs mūs tur esat šausmīgi novecojuši.
Berts Scalzo: Jā, es jums saku, es jūtos kā vectēvs Simpsons. Tāpēc es skatos uz atkļūdošanu, un tur ir dažādi veidi, kā veikt atkļūdošanu. Jūs varētu runāt par to, ko mēs visi domājam par tradicionālu nokļūšanu atkļūdotājā un koda aktivizēšanu. Bet cilvēki arī izmantos savu kodu; tur jūs iespiežat paziņojumus kodā un, iespējams, jūs izveidojat izvades failu, izsekošanas failu vai kaut ko citu, un tādējādi jūs instrumentējat savu kodu. Es uzskatu, ka tas kā atkļūdošana ir mazliet grūtāks veids, kā to izdarīt, bet tas ir svarīgi. Bet mums ir arī slavenais paziņojums par drukāšanu: jūs skatāties, un cilvēki faktiski ievieto drukāšanas paziņojumus, un es faktiski esmu redzējis rīku, kur - un tas ir datu bāzes rīks - kur, ja jūs nezināt, kā izmantot atkļūdotāju, jūs nospiežat pogu, un tas pielīmēs izdrukas paziņojumus visā kodā, un pēc tam, kad esat pabeidzis, jūs nospiedīsit vēl vienu pogu, un tas tos izsvītros. Jo tas ir, kā daudzi cilvēki atkļūdot.
Atklāšanas iemesls ir divējāds: pirmkārt, mums bija jāatrod lietas, kas mūsu kodu padara neefektīvu. Citiem vārdiem sakot, parasti tas nozīmē, ka ir loģiska kļūda vai mēs esam nokavējuši biznesa prasību, bet kas tas ir, tas ir, ka kods nav efektīvs; tas nedara to, ko mēs to gaidījām. Citu reizi, kad mēs ejam, un mēs veicam atkļūdošanu, tas ir saistīts ar efektivitāti un tā varētu būt loģiska kļūda, bet kas tas ir, vai es rīkojos pareizi, tas vienkārši neatgriežas pietiekami ātri. Tagad es to uzsveru, jo profilētājs, iespējams, ir labāks par otro scenāriju, un mēs runāsim gan par atkļūdotājiem, gan par profilētājiem. Turklāt pastāv šī attālā atkļūdošanas koncepcija; tas ir svarīgi, jo daudzkārt, ja sēdējat personālajā datorā un izmantojat atkļūdotāju, kas nonāk datu bāzē, kur kods faktiski tiek izpildīts datu bāzē, jūs faktiski darāt tā saucamo attālo atkļūdošanu. Jūs, iespējams, to nesaprotat, bet tieši tas notiek. Un tad ļoti bieži šiem atkļūdotājiem ir lūzuma punkti, skatīšanās punkti, iekāpšana un aiziešana un dažas citas izplatītas lietas, ka es vienā mirklī tos parādīšu ekrāna momentuzņēmumā.
Tagad profilēšana: jūs varat veikt profilēšanu dažādos veidos. Daži cilvēki teiks, ka darba slodzes uztveršana un atkārtošana tur, kur tiek uztverts viss, kas uzskatāms par profilēšanu. Mana pieredze ir lielāka, jo labāk, ja tas tiek veikts paraugu ņemšanā. Nav iemesla uztvert katru paziņojumu, jo daži paziņojumi var tik ātri izpildīties, ka jums vienalga, ko jūs patiešām cenšaties redzēt, labi, kas ir tie, kas tiek rādīti atkal un atkal, jo viņi skrien pārāk ilgi. Tātad, dažreiz profilēšana var nozīmēt paraugu ņemšanu, nevis visas lietas vadīšanu. Un parasti jūs iegūsit sava veida izvadi, ko varēsit izmantot, tagad tas varētu būt vizuāls IDE izstrādes vidē, kur tas jums var sniegt, piemēram, dažādu koda rindiņu veiktspējas histogrammu, taču tā joprojām var būt tas rada izsekošanas failu.
Profileri pirmo reizi parādījās 1979. gadā. Tātad arī tie pastāv jau ilgu laiku. Lieliski, lai atrastu resursu patēriņu vai veiktspējas problēmas, citiem vārdiem sakot, šo efektivitātes lietu. Vispārīgi runājot, tas ir atšķirīgs un atšķirīgs no atkļūdotāja, lai gan esmu strādājis ar atkļūdotājiem, kas darbojas vienlaikus. Un, lai gan profilētāji, manuprāt, ir interesantākie no diviem rīkiem, ja man šķiet, ka atkļūdošanas nav pietiekami daudz, tad noteikti arī nepietiek, jo šķiet, ka viens no desmit atkļūdotājiem profilēsies. Tas ir kauns, jo profilēšana patiešām var radīt milzīgas atšķirības. Tagad, kā mēs jau runājām iepriekš, datu bāzu valodas ir ieguvušas SQL - un mēs esam piespieduši apaļo piespraudi šeit esošajā kvadrātveida caurumā un piespiedu to kļūt par programmēšanas valodu - un Oracle. Tas ir PL / SQL - tā ir procedūras valoda SQL - un SQL Server, tas ir Transact-SQL, tas ir SQL-99, tas ir SQL / PSM - man, manuprāt, tas ir procedūras saglabātais modulis. Postgres tam piešķir vēl vienu vārdu, DB2 - vēl vienu vārdu, Informix, bet jēga ir tā, ka visi ir spiesti 3GL tipa konstrukcijas; citiem vārdiem sakot, FOR cilpas, pie mainīgām deklarācijām un visa cita informācija, kas SQL ir sveša, tagad ir SQL daļa šajās valodās. Un tā, jums jāprot atkļūdot PL / SQL vai Transact-SQL tāpat kā Visual Basic programmai.
Tagad, datu bāzes objekti, tas ir svarīgi, jo cilvēki teiks: “Nu, kādas lietas man ir jāatkļūda datu bāzē?”, Un atbilde ir: nu, ko jūs varat uzglabāt datu bāzē kā kods - ja es daru T-SQL vai PL / SQL - un es glabāju objektus datu bāzē, iespējams, tā ir glabāta procedūra vai glabāta funkcija. Bet ir arī sprūda: sprūda ir sava veida glabāta procedūra, bet tā tiek aktivizēta uz kāda veida notikuma. Tagad daži cilvēki aktivizētājos ievietos vienu koda rindu un izsauks saglabāto procedūru, lai viņi saglabātu visu saglabāto kodu un procedūras, taču tā ir tā pati koncepcija: tas joprojām ir sprūda, kas iniciē visu. Un kā Oracle viņiem ir kaut kas tāds, ko sauc par paketi, kas ir sava veida bibliotēka, ja vēlaties. Jūs grupējat 50 vai 100 saglabātās procedūras vienā grupā, ko sauc par paketi, tāpēc tas ir kā bibliotēka. Tātad, šeit ir vecais atkļūdotājs; patiesībā tas ir rīks, kas reāli iestāsies un visus šos atkļūdošanas paziņojumus pielīmēs jūsu kodā. Tātad, visur, kur redzat atkļūdošanas bloķēšanu, nenoņemiet, automātiskā atkļūdotāja sākšana un izsekošana. Tie visi bija iestrēdzis ar kādu rīku. Un ārpus tā esošās līnijas, kas ir koda mazākums, labi, ka tā ir atkļūdošanas metode, kas nav manuāla.
Un iemesls, kāpēc es to izvirzīju, ir tas, ka, ja jūs mēģināt to izdarīt ar roku, jūs faktiski gatavojaties ievadīt vairāk atkļūdošanas kodu, lai ievietotu visus šos drukāšanas paziņojumus, nekā jūs to izmantojat. Tātad, kaut arī tas var darboties, un, kaut arī tas ir labāks nekā nekas, tas ir ļoti grūts atkļūdošanas veids, jo īpaši tāpēc, kas notiks, ja šīs lietas palaišana prasa 10 stundas, un, ja tai ir problēma, tā ir trešajā rindā? Ja es nodarbotos ar interaktīvu atkļūdošanas sesiju, es būtu zinājis, ka trešajā rindā - piecas minūtes - hey, šeit ir problēma, es varu pamest. Bet līdz tam man ir jāgaida, līdz tas darbosies, līdz tā pabeigšanai, un tad man nācās apskatīt kādu izsekošanas failu, kurā droši vien ir visi šie izdrukas paziņojumi, un mēģināt atrast adatu siena kaudze. Atkal tas ir labāk nekā nekas, bet tas nebūtu labākais veids, kā strādāt. Tagad izskatās šāds fails, kas nāk no iepriekšējā slaida; citiem vārdiem sakot, es vadīju programmu, un šajā izsekošanas failā ir tikai drukātu paziņojumu kopums, un es, iespējams, nespēšu to izskatīt un atrast to, kas man ir nepieciešams. Tātad es atkal neesmu tik pārliecināts, ka tas ir veids, kā jūs vēlētos strādāt.
Tagad interaktīvie atkļūdotāji - un, ja programmu rakstīšanai esat izmantojis kaut ko līdzīgu Visual Studio vai Eclipse, jums ir bijuši atkļūdotāji un jūs tos izmantojāt citās valodās - vienkārši nedomājāt tos izmantot šeit ar savu datu bāzi. Un tur ir rīki, piemēram, mūsu DB Artisan un mūsu Rapid SQL, šeit ir Rapid SQL, kuriem ir atkļūdotājs, un jūs varat redzēt kreisajā pusē, ka man ir saglabāta procedūra ar nosaukumu “pārbaudīt dublikātus”. Būtībā vienkārši iet un paskatīties, vai man tabulā ir vairākas rindas ar vienu un to pašu filmas nosaukumu. Tātad, datu bāze ir paredzēta filmām. Un jūs varētu redzēt labajā pusē, augšējā trešdaļā, man ir avota kods pa vidu, man ir tie, ko sauc par maniem pulksteņa mainīgajiem un maniem zvanu kaudžu paplātēm, un pēc tam apakšā - Es saņēmu dažus izvades ziņojumus. Un vissvarīgākais ir tas, ka, apskatot šo pirmo sarkano bultiņu un nospiežot peles kursoru virs mainīgā, es faktiski redzu, kāda vērtība tajā mainīgajā brīdī ir tajā brīdī, kad es pārvietojos pa kodu. Un tas ir patiešām noderīgi, un tad es varu kodēt vienu līniju vienā laikā, man nav jāsaka izpildīt, es varētu teikt soli pa līniju, ļaujiet man paskatīties, kas noticis, pacelt citu līniju, ļaujiet man redzēt, kas noticis, un es to daru datu bāzē. Un, kaut arī es sēdēju datorā ar Rapid SQL un mana datu bāze atrodas mākonī, es joprojām varu veikt šo attālo atkļūdošanu, redzēt un kontrolēt to no šejienes, kā arī veikt atkļūdošanu tāpat kā es, izmantojot jebkuru citu valodu.
Tagad nākamā bultiņa tur - jūs varat redzēt mazliet līdzīgo bultiņu, kas norāda uz labo pusi, virzienā uz šo DBVS izvadi, tur šobrīd atrodas mans kursors - tātad, citiem vārdiem sakot, esmu pakāpies un esmu tur, kur esmu tas mirklis. Tātad, ja es saku: “Soli atkal”, es iešu pie nākamās līnijas. Tieši zem tā redzēsit sarkano punktu. Tas ir lūzuma punkts, kas saka: “Ei, es nevēlos pārkāpt pāri šīm līnijām.” Ja es tikai vēlos pārlekt pāri visam un nokļūt tur, kur atrodas šis sarkanais punkts, es varu nospiest palaišanas pogu, un tas darbosies no šejienes vai nu līdz beigām, vai līdz pārtraukuma punktam, ja ir uzstādīti pārtraukuma punkti, un tad tas apstāsies un ļaus man atkal veikt soli. Un tas viss ir svarīgi un spēcīgi tāpēc, ka, kad es to visu daru, tas, kas notiek pa vidu un pat apakšā - bet pats galvenais - pa vidu - mainīsies, un es redzu vērtības no saviem mainīgajiem, Es zinu, ka es redzu sarunu kaudzes izsekošanu, un tāpēc visa šī informācija tur tiek parādīta, kad es izceļoju kodu, tāpēc es faktiski varu redzēt un sajust un iegūt izpratni par to, kas notiek un kā patiesībā ir kods. strādā izpildes laikā. Parasti es varu atrast problēmu, ja tāda ir, vai arī, ja esmu pietiekami laba, lai to noķertu.
Labi, tagad es runāšu par profilētāju, un šajā gadījumā tas ir profils, kuru es varu redzēt caur atkļūdotāju. Atcerieties, es teicu, ka dažreiz viņi ir atsevišķi un dažreiz viņi var būt kopā? Šajā gadījumā un atkal es esmu Rapid SQL, un es redzu, ka kreisajā pusē blakus līniju numuriem ir rezerve. Un kas tas ir, tas ir sekunžu vai mikrosekunžu skaits, kas bija nepieciešams katras koda rindas izpildei, un es skaidri redzu, ka viss mans laiks tiek pavadīts šajā vienā FOR cilpā, kur es visu atlasu no tabulas . Un tā, lai arī kas notiktu šīs FOR cilpas iekšienē, iespējams, ir kaut kas man jāaplūko, un, ja es to varēšu padarīt labāku, tas maksās dividendes. Es negrasīšos uzlabojumus, strādājot pie tām līnijām, kurām ir līdzīgi kā 0, 90 vai 0, 86; tur nav pavadīts daudz laika. Tagad, šajā gadījumā un atkal, es esmu Rapid SQL, jūs redzat, kā es varu veikt profilēšanu, kas sajaukta ar manu atkļūdošanu. Rapid SQL ļauj jums to darīt arī citādi. Rapid SQL ļauj jums pateikt: “Jūs zināt, ko? Es nevēlos atrast atkļūdotāju, es vienkārši gribu to palaist un tad vēlos aplūkot grafiski vai vizuāli tāda paša veida informāciju. ”
Un jūs varat redzēt, ka es vairs nepiederu atkļūdotājam un tas vada programmu, un pēc izpildīšanas tā dod man diagrammas, lai pastāstītu man lietas, lai es redzētu, ka man ir viens paziņojums, kas izskatās, ka tas sāk darboties lielāko daļu pīrāga diagrammas, un, ja es paskatos, tajā režģī redzu virzienā uz apakšējo līniju, 23. līniju, tur atkal ir FOR cilpa: viņš uzņem visvairāk laika, patiesībā viņš ir tas, ka tumši sarkans sakošļā visu pīrāga diagrammu. Tātad, tas ir vēl viens veids, kā veikt profilēšanu. Mēs to saucam par “kodu analītiķi” mūsu rīkā. Bet tas būtībā ir tikai profilētājs, kas atdalīts no atkļūdotāja. Dažiem cilvēkiem patīk to darīt pirmajā veidā, citiem patīk to darīt otrajā veidā.
Kāpēc mēs veicam atkļūdošanu un profilēšanu? Tas nav tāpēc, ka mēs vēlamies uzrakstīt pasaules lielāko kodu un saņemt atalgojumu - tas varētu būt mūsu iemesls, bet tas nav īsti iemesls, kāpēc jūs to darāt - jūs apsolījāt biznesam, ka jūs kaut ko darīsit pareizi, ka jūsu programma būs efektīva. Tam jūs izmantosit atkļūdotāju. Turklāt biznesa gala lietotāji; viņi nav ļoti pacietīgi: viņi vēlas rezultātus pat pirms taustiņa nospiešanas. Mums vajadzētu lasīt viņu prātu un visu darīt uzreiz. Citiem vārdiem sakot, tam jābūt efektīvam. Un tāpēc mēs izmantojam profilētāju. Tagad bez šiem instrumentiem es patiešām ticu, ka jūs esat šis puisis biznesa uzvalkā ar loku un bultu, un jūs šaujat mērķī, un jums ir aizsietām acīm. Jo kā jūs atradīsit, kā programma izpilda, tikai apskatot statisko kodu, un kā jūs izdomāsit, kura līnija ir tā, kur tā patiešām pavada visvairāk laika izpildē, atkal tikai apskatot statisko kodu? Iespējams, ka koda pārskatīšana parādīs dažas no šīm lietām, taču nav garantijas, ka koda pārskatīšana tās atradīs visas. Izmantojot atkļūdotāju un profilētāju, jums vajadzētu būt iespējai atrast visas šīs kļūdas.
Labi, es šeit izdarīšu tikai īstu demonstrāciju. Tas nav mans nodoms virzīt produktu, es tikai vēlos parādīt, kā izskatās atkļūdotājs, jo daudzas reizes cilvēki teiks: “Es nekad iepriekš neesmu redzējis nevienu no šiem”. Un tas ekrāna slaidos izskatās diezgan skaisti., bet kā tas izskatās, kad tas ir kustībā? Tātad, šeit, uz mana ekrāna, es palaidu mūsu DB Artisan produktu; mums tur ir arī atkļūdotājs. DB Artisan ir domāts vairāk DBA, Rapid SQL ir vairāk izstrādātājiem, bet es esmu redzējis izstrādātājus, kuri izmanto DB Artisan, un esmu redzējis DBA, kuri izmanto Rapid. Tātad, neaizraujieties ar produktu. Un šeit es varu izvēlēties veikt atkļūdošanu, bet pirms es sāku atkļūdot, es izgūstu šo kodu, lai jūs varētu redzēt, kāds ir kods, pirms sāku to palaist. Tātad, šeit ir precīzi tas pats kods, kas bija ekrāna momentuzņēmumā, šī ir mana pārbaude, vai nav dublikātu. Un es gribu to atkļūdot, tāpēc nospiežu atkļūdošanu. Un tagad paiet mirklis, un jūs sakāt: “Nu, kāpēc tas notiek īslaicīgi?” Atcerieties attālo atkļūdošanu: atkļūdošana faktiski notiek manā datu bāzes serverī, nevis manā personālajā datorā. Tātad tam bija jāiet pāri un tur jāizveido sesija, jāizveido attālā atkļūdošanas lieta, jāpievieno mana sesija šai attālajai atkļūdošanas sesijai un jāizveido sakaru kanāls.
Tātad, šeit ir mana bultiņa, tā ir augšā augšpusē, pa vienai rindiņai, tur es kodā. Un, ja es tur nospiedīšu trešo ikonu, kas ir solis uz priekšu, jūs redzēsit, ka bultiņa tikko ir pārvietojusies, un, ja es turpināšu to nospiest, jūs redzēsit, ka tā turpina kustēties. Tagad, ja es gribētu iet līdz šai FOR cilpai, jo es zinu, ka tur ir problēma, es varu uzstādīt pārtraukuma punktu. Es domāju, ka es to uzstādīju. Ak, šaut, man viena no ekrāna tveršanas taustiņiem bija piešķirta tai pašai atslēgai kā atkļūdotājam, tas ir tas, kas rada neskaidrības. Labi, tāpēc es vienkārši manuāli iestatu pārtraukuma punktu tur, tāpēc tagad tā vietā, lai veiktu soli, soli, soli, soli, līdz es tur nokļuvu, patiesībā es varu vienkārši pateikt: “Ej un palaid šo lietu”, un tas apstāsies. Ievērojiet, ka tas mani aizveda līdz pārtraukuma vietai, tāpēc es tagad esmu šīs cilpas palaišanas kontekstā, es redzu, kam ir iestatīti visi mani mainīgie, kas nav pārsteigums, jo es tos visus inicializēju. līdz nullei. Un tagad es varu iekļūt šajā cilpā un sākt skatīties, kas notiek šīs cilpas iekšpusē.
Tātad, tagad tas notiks, atlasot skaitīšanu no manas īres maksas, un es varu pārvietot peli virs šī puiša un paskatīties, ka viņš ir divi, divi ir lielāki par vienu, tāpēc, iespējams, gatavojas darīt nākamo šī koda daļu. Citiem vārdiem sakot, tas kaut ko atrada. Es tikai došos uz priekšu un ļaušu tam skriet. Es negribu šeit iet cauri visam; tas, ko es gribu jums parādīt, ir tad, kad atkļūdotājs ir pabeigts, tas beidzas tāpat kā parasta programma. Man ir noteikts pārtraukuma punkts, tāpēc, kad teicu palaist, tas vienkārši atgriezās pie nākamā pārtraukuma punkta. Es ļauju tai darboties līdz galam, jo tas, ko es vēlos, lai jūs redzētu, ir tas, ka atkļūdotājs nemaina programmas izturēšanos: kad tā tiek palaista, man vajadzētu iegūt tieši tādus pašus rezultātus, ja es nebūtu to palaidis. iekšpusē atkļūdotājs.
Pēc tam es apturēšu demonstrāciju un atgriezīšos, jo mēs vēlamies pārliecināties, vai mums ir laiks jautājumiem un atbildēm. Tāpēc es to atvēru jautājumiem un atbildēm.
Ēriks Kavanaghs: Labi, Robin, varbūt jautājums no jums un pēc tam pāris no Dez?
Robins Bloors: Jā, protams, man tas, protams, ir aizraujoši. Esmu strādājis ar tādiem sīkumiem kā šis, bet nekad datu bāzē neesmu strādājis ar kaut ko līdzīgu. Vai varat sniegt man priekšstatu par to, kādiem nolūkiem cilvēki izmanto profilētāju? Tā kā tas ir līdzīgi, vai viņi skatās - jo es pieņemu, ka viņi ir - viņi izskata veiktspējas problēmas, vai tas palīdzēs jums atšķirt, kad datu bāze prasa laiku un kad kods prasa laiku?
Berts Scalzo: Jūs zināt, tas ir fantastisks jautājums. Teiksim, ka es strādāju Visual Basic, un es savā Visual Basic es saukšu Transact-SQL vai PL / SQL. Ļaujiet man darīt PL / SQL, jo Oracle ne vienmēr labi spēlē ar Microsoft rīkiem. Es varētu profilēt savu Visual Basic kodu, un tur esošajā profilā var būt teikts: “Ei, es piezvanīju šai glabātajai procedūrai, un tā aizņēma pārāk ilgu laiku.” Bet tad es varu iedziļināties saglabātajā procedūrā un varu izveidot datu bāzes profilu par saglabāto Procedūra un sakiet: “Labi, no 100 šeit esošajiem paziņojumiem, šie ir pieci, kas izraisīja problēmu.” Un tā, iespējams, jums būs jāveido tagu komanda, kurā jums jāizmanto vairāki profilētāji.
Ideja ir tāda, ka, ja kādreiz jums tiek paziņots, ka veiktspējas problēma ir jūsu datu bāzē, datu bāzes profils var palīdzēt jums atrast adatu siena kaudzē, par kuru patiesībā ir tie apgalvojumi, kur rodas problēma. Es jums saku vēl vienu lietu, kas parādījās ar profilēšanu: ja jums ir koda gabals, kuru sauc miljons reizes, bet tas prasa tikai mikrosekundi katru miljonu reižu, bet tas tiek saukts miljons reizes, ko parādīs profilētājs, šī lieta ilga tik daudzās laika vienībās. Un tā kā kods var būt ļoti efektīvs, jūs varētu paskatīties un pateikt: “O, mēs pārāk bieži piezvanām uz šo koda daļu. Varbūt mums tas jāsauc tikai tik bieži, nevis katru reizi, kad apstrādājam ierakstu ”vai kaut ko citu. Un tā jūs faktiski varat atrast efektīvo kodu, kas tiek saukts pārāk bieži, un tas faktiski ir veiktspējas problēma.
Robins Bloors: Jā, tas ir brīnišķīgi. Es nekad to neesmu darījis. Jūs, protams, redzat, kad man bija problēmas ar datu bāzēm, tas bija tā, it kā es vienā vai otrā veidā nodarbotos ar datu bāzi vai ar kodu; Es nekad nevarētu tikt galā ar abiem vienlaikus. Bet tur es atkal nedarīju - es nekad neesmu faktiski iesaistījies tādu lietojumprogrammu veidošanā, kur mums bija saglabātas procedūras, tāpēc es domāju, ka es nekad neesmu faktiski saskāries ar problēmām, kas mani mēdza aizdzīt, domu, ka jūs kodu sadalītu starp datu bāzi un programmu. Bet tā, dariet visu - es pieņemu, ka atbilde būs jā, bet tā ir daļa no attīstības komandas aktivitātes, kad jūs vienā vai otrā veidā mēģināt labot kaut ko sabojātu vai varbūt mēģināt atnest jaunu pieteikums kopā. Bet vai tas viss ir piemērots visiem pārējiem komponentiem, ko es varētu sagaidīt vidē? Vai es varu sagaidīt, ka es to varētu saspraust kopā ar visām manām testa pakotnēm un visiem citiem materiāliem, ko es darīšu, un ar projekta vadības lietām, vai tas viss ir saspraužams kopā?
Berts Scalzo: Jā, tas var kļūt par jebkura strukturēta procesa daļu, lai veiktu jūsu programmēšanas vai attīstības centienus. Un tas ir smieklīgi, ka pagājušajā nedēļā man bija kāds klients, kurš veidoja tīmekļa lietojumprogrammu, un viņu datu bāze vēsturiski bija maza, un tāpēc tas, ka viņi nebija ļoti labi programmētāji, nekad viņiem nebija nodarījis pāri. Viņu datu bāze gadu gaitā ir augusi, un tagad tīmekļa lapā ir vajadzīgas 20 sekundes, starp jums sakot: “Piesakieties man un dodiet man dažus datus, lai redzētu”, līdz brīdim, kad ekrāns faktiski parādās, un tagad tas ir izpildes problēma. Un viņi zināja, ka problēma nav nevienā no viņu Java vai nevienā citā vietā. Bet viņiem bija tūkstošiem saglabātu procedūru, un tāpēc viņiem bija jāsāk profilēt glabātās procedūras, lai uzzinātu, kāpēc šīs tīmekļa lapas izveidošana prasa 20 sekundes? Un mēs patiesībā secinājām, ka viņiem bija Dekarta pieslējies vienā no viņu atlasītajiem paziņojumiem, un to nezinājām.
Robins Bloors: Oho.
Berts Scalzo: Bet kāds man vienu reizi teica : “Nu kā gan viņi varēja būt Dekarta pieslējies un to nezināt?” Un tas izklausīsies tiešām šausmīgi; dažreiz programmētājs, kurš nav ļoti apmierināts ar SQL, izdarīs kaut ko līdzīgu, dodot man Dekarta pievienošanos, bet pēc tam atdos tikai pirmo ierakstu, tāpēc es zinu, ka kaut ko ieguvu, un man ir nepieciešams tikai pirmais. Un tāpēc viņi neapzinās, ka ir tikko atgriezuši miljardu ierakstu vai arī skatās caur miljardu ierakstu, jo ir ieguvuši viņu interesējošo.
Robins Bloors: Oho, es zinu, tas ir tas, ko sauc - labi, tieši tas notika Deza sakarā ar cilvēkiem, kas nav tieši tik kvalificēti, kā varbūt viņiem vajadzētu būt, jūs zināt. Ja esat programmētājs, jums jāzina, kāda ir katras komandas izdošanas ietekme. Es domāju, tiešām, nav stulbuma līmeņa attaisnojums. Es arī pieņemu, ka jūs tādā vai citā veidā esat tikai valodas agnostisks, jo tas viss koncentrējas uz datu bāzes pusi. Vai man tajā taisnība? Vai tas ir tieši tas pats, neatkarīgi no tā, ko izmantojat kodēšanas pusē?
Berts Scalzo: Absolūti, to var izdarīt Fortran vai C vai C ++. Faktiski dažās Unixes to var izdarīt pat viņu skriptu valodās; tie faktiski nodrošina tos pašus rīkus. Un tad es vēlos atgriezties sekundē pie jūsu teiktā bez attaisnojuma. Es ieplānošu programmētājiem vienu pārtraukumu, jo man nepatīk iemest programmētājus zem autobusa. Bet problēma patiešām ir akadēmiskajā vidē, jo, dodoties iemācīties būt programmētājam, jums tiek mācīta ierakstu uzskaite vienlaicīgi. Jums netiek mācīta kopu domāšana, un tieši tā Strukturētā vaicājuma valoda jeb SQL darbojas ar kopām; tāpēc mums ir savienība, krustojums un mīnus operators. Un cilvēkam, kurš nekad nav domājis par komplektiem, dažreiz ir ļoti grūti pamest, atbrīvot no ierakstu apstrādes un strādāt ar komplektiem.
Robins Bloors: Jā, es esmu ar jums šajā jautājumā. Es domāju, ka es tagad saprotu, tas ir izglītības jautājums; Es domāju, ka tas ir pilnīgi izglītības jautājums, es domāju, ka programmētājiem ir likumsakarīgi domāt procesuāli. Un SQL nav procesuāls, tas ir deklaratīvs. Jūs patiesībā sakāt: “To es gribu un man nav vienalga, kā jūs to darāt, ” vai jūs zināt? Tā kā ar programmēšanas valodām jūs bieži saspiedat piedurknes un esat pat nonācis līdz pat skaitīšanas pārvaldības sīkumiem, kamēr jūs darāt cilpu. Es došu uz
Berts Scalzo: Nē. Labi, turpiniet.
Jā, es gribētu teikt, ka jūs parādījāt vēl vienu piemēru, ka profilētājam būtu labi pieķerties, un tas notiek ar šo ierakstu apstrādes laikā. Dažreiz programmētājs, kurš labi pārzina loģisko uzskaiti, nevar izdomāt, kā veikt SQL programmu. Nu, pieņemsim, ka viņš veido divas FOR cilpas un būtībā pievienojas, bet viņš to dara klienta pusē. Tātad, viņš rīkojas tāpat kā pievienošanās, bet dara pats, un profils to uztver, jo jūs, iespējams, galu galā pavadīsit vairāk laika, lai manuāli pievienotos, nevis ļaujat datu bāzes serverim to darīt jūsu vietā.
Robins Bloors: Jā, tā būtu katastrofa. Es domāju, ka jūs vienkārši mētājaties apkārt. Thrashing vienmēr ir slikti.
Jebkurā gadījumā es pāriešu uz Dezu; Esmu pārliecināts, ka viņam ir interesanti jautājumi.
Dez Blanchfield: Paldies, jā, es daru. Es grasīšos pievienoties jums, lai nemestu programmētājus zem autobusa. Es domāju, es esmu pavadījis pārāk daudzus gadus savā dzīvē, būdams kodētājs, katrā līmenī, jūs zināt, vai tas ir tāds, kā jūs teicāt, sēžot uz Unix mašīnas komandrindas, un dažos gadījumos es pat biju iesaistīts pāris dažādās Unix pieslēgvietās no vienas aparatūras platformas uz otru. Un jūs varat iedomāties izaicinājumus, kas mums tur bija. Bet realitāte ir tāda, ka katram pasaules kodētājam un scenārijam tiek nodrošināta izkļūšanas no cietuma karte. Tā ir raķešu zinātne, diezgan burtiski, ka visu laiku rakstīt ir ļoti stingri, tā ir raķešu zinātne. Un tādi slaveni stāsti par cilvēkiem kā Deniss Ritčijs un Braiens Kernahana patstāvīgi strādā pie kāda koda, pēc tam pie kafijas pāriet uz koda pārskata tērzēšanu un uzzina, ka viņi ir uzrakstījuši tieši to pašu koda gabalu, tieši tajā pašā programmā, tieši tādā pašā veidā. Viņi to izdarīja C. Bet tas programmēšanas puristiskais līmenis pastāv ļoti reti.
Fakts ir tāds, ka katru dienu dienā ir tikai 24 stundas, septiņas dienas nedēļā, un mums vienkārši ir jādara lietas. Un tā, ja runa ir ne tikai par tradicionālajiem programmētājiem, DBA un kodētājiem, un skriptiem, un sysadmin, un tīkla administratoriem, un drošības personālu, un mūsdienās viss notiek līdz pilsoņu datu pusei; mēs dzirdam, ka visi tikai cenšas darīt savu darbu. Un tāpēc es domāju, ka viss, kas jums no šīs lietas notika, ir tas, ka es mīlēju jūsu demonstrāciju un to, ka jūs tieši pirms brīža atstājāt mūs tur, runājot ar Robinu par to, ka tam ir īpaša nozīme - varbūt ne tik ļoti niša - bet plaša telpa, uz kuru tā attiecas, ciktāl tā nosaka kodu un SQL, kā arī datu bāzes. Bet man bija patiess prieks dzirdēt jūs sakām, ka jūs varētu to iebāzt čaulas skriptā un atrast dažas problēmas, jo, jūs zināt, šodienas apstākļos mēs vienmēr strādājam ar viszemākajām izmaksām.
Iemesls, kāpēc jūs kaut kur varat iegādāties kreklu 6 USD, ir tāpēc, ka kāds ir izveidojis sistēmu pietiekami lēti, lai faktiski ražotu un piegādātu, loģistiski piegādātu un pārdotu, kā arī veiktu mazumtirdzniecību un veiktu tiešsaistes maksājumus, lai iegūtu šo kreklu 6 USD vērtībā. Un tas nenotiek, ja jums ir samaksājuši USD 400 000 gadā, lai viņi perfekti uzrakstītu kodu; tā ir tikai visa attīstība. Tātad, es domāju, ka viens no jautājumiem, ar kuru es ļoti vēlētos, lai jūs mums sniegtu vairāk ieskatu, ir tas, cik plašs un sasniedzams ir to cilvēku tips, kurus jūs pašlaik redzat un kuri izmanto šāda veida rīkus profila veidošanai kodu un meklēt veiktspējas problēmas? Sākotnēji, vēsturiski, no kurienes viņi nāk? Vai tās ir bijušas lielās inženieru mājas? Un tad, runājot par priekšu, vai tas tā ir, es pareizi domāju, ka arvien vairāk uzņēmumu izmanto šo rīku vai šos rīkus, lai mēģinātu palīdzēt kodētājiem, kurus viņi zina, kuri tikai sāk darbu, lai darbu pabeigtu un iziet ārā pa durvīm? Un dažreiz mums ir vajadzīga izkļūšanas no cietuma karte? Vai man ir taisnība, domājot, ka vēsturiski mums bija vairāk inženierzinātņu un attīstības? Kā tagad, kā teica Robins, tagad mēs iegūstam mazāk akadēmiskās pieejas, un tagad tā ir pašmācība vai izgriezts un ielīmēts kods, vai arī vienkārši lietas tiek būvētas? Un vai tas atbilst veidam, kāds ir cilvēkiem, kuri šo produktu tagad lieto?
Berts Scalzo: Jā, tieši tā. Es minēšu jums ļoti konkrētu piemēru, mēs vēlamies tikai paveikt darbu, jo biznesa cilvēki nevēlas pilnību. Tas ir kā datorizēta šaha spēle: šaha spēle nemeklē perfektu atbildi; tā meklē atbildi, kas ir pietiekami laba saprātīgā laika posmā, tāpēc mēs to programmējam. Bet tas, ko es tagad atklāju, ir tas, ka vairums cilvēku tā vietā, lai teiktu, ka vēlas profilēt savu vienību pārbaudēs - kā es to darītu, jo es to neuzskatu par laika izšķiešanu - notiek tas, kas notiek tagad, kad tas tiek darīts vēlāk, dažreiz integrācijas pārbaudes vai stresa testēšanas laikā, ja mums paveicas. Bet lielākoties tā ir daļa no eskalācijas, kad kaut kas ir nonācis ražošanā, tas kādu laiku darbojās, varbūt pat ilga gadiem, un tagad tas nedarbojas labi, un tagad mēs to profilēsim. Un šķiet, ka tas tagad ir biežākais scenārijs.
Dezs Blanšfīlds: Jā, un es domāju, ka termins “tehniskais parāds”, iespējams, ir tāds, ar kuru jūs esat vairāk nekā pazīstams; Es zinu Robinu un noteikti esmu. Es domāju, ka šajās dienās, it īpaši veiklās pieejās izstrādei un sistēmu veidošanai, tehniskā parāda jēdziens tagad ir ļoti reāla lieta, un mēs to faktiski uzskatām projektos. Es zinu, es domāju, ka mums ir savi projekti, piemēram, Media Lens un citi, kur katru dienu notiek kodēšana, un dažādas lietas visā Bloor grupā. Un ikreiz, kad mēs kaut ko veidojam, mēs to skatāmies, es uz to skatos un vienmēr skatos, raugoties no tā viedokļa, kas man izmaksās, lai to labotu šobrīd, salīdzinot ar to, vai es to vienkārši varu iegūt es varu to dabūt ārā, un tad skatīties un redzēt, vai šī lieta sabojājas. Un mantojiet šo tehnisko parādu, kas, es zinu, man vēlāk būs jāatgriežas atpakaļ un jālabo.
Un es domāju, ka esmu to izdarījis pēdējo septiņu dienu laikā: esmu uzrakstījis pāris rīkus un skriptus, esmu uzrakstījis pāris gabalus Python valodas un ievietojis to Mongo aizmugurē, izveidojot pārliecinieties, ka tas ir jauks, tīrs un drošs, bet tas vienkārši saņem vajadzīgo vaicājumu, zinot, ka šī funkcija man ir nepieciešama, lai darbotos, lai nonāktu pie lielākas mīklas; tur ir manas īstās sāpes. Tātad jums rodas šis tehniskais parāds, un es domāju, ka šī nav tikai gadījuma lieta, es domāju, ka šī ir daļa no DNS, kas attīstās tagad. Cilvēki vienkārši - nevis izsakāmi atklāti - viņi vienkārši pieņem tehnisko parādu, ir parasts modus operandi jautājums, un viņiem tas vienkārši ir jāpiedzīvo. Šeit rodas tehniskais parāds. Un es domāju, ka lieliskā lieta par to, ko jūs mums parādījāt demonstrācijā, bija tā, ka jūs varat burtiski profilēt un skatīties, cik ilgs laiks kaut ko palaiž. Un tā droši vien ir viena no manām mīļākajām lietām. Es domāju, ka es faktiski esmu uzbūvējis profilēšanas rīkus - mēs izmantojām Sed, Lex un Orc rīku veidošanā, lai palaistu mūsu kodu un redzētu, kur ir cilpas, pirms bija pieejami šādi rīki - un kad esat izveidojis kodu, lai dotos un pārskatiet savu kodu, jums ir ļoti labi, ja jums nav jāpārskata savs kods. Bet tagad tas tā nav. Ņemot to vērā, vai ir kāds noteikts tirgus segments, kas to uzņem vairāk nekā jebkurš cits? Redz kā masu
Berts Scalzo: Ak, jā, es esmu ieguvis - es tev uzzīmēšu analoģiju un parādīšu, ka neprogrammētāji to visu dara. Iemesls: ja es kādreiz mācu atkļūdotāju un profilēju klasi vai sesiju, es pajautāšu cilvēkiem: “Labi, cik cilvēku šeit ieiet Microsoft Word un mērķtiecīgi nekad nelieto pareizrakstības pārbaudītāju?” Un neviens nepaceļ roku, jo dokumentu rakstīšanai mēs visi zinām, ka varam pieļaut kļūdas angļu valodā, un tāpēc visi izmanto pareizrakstības pārbaudītāju. Un es teicu: “Kā tad ir, ja jūs rakstāt tekstu IDE, piemēram, Visual Basic, jūs neizmantojat atkļūdotāju? Tas ir tas pats, tas ir kā pareizrakstības pārbaudītājs. ”
Dezs Blanšfīlds: Jā, patiesībā tā ir lieliska analoģija. Par to īsti nebiju domājusi, jāatzīst, ka patiesībā es kaut ko līdzīgu daru ar pāris instrumentiem, kurus izmantoju. Faktiski viens, ODF, mans iecienītākais ar Eclipse, ir tur vienkārši izgriezt un ielīmēt kodu un doties meklēt lietas, kuras vienkārši uzreiz tiek izceltas, un saprotot, ka es kādā klases zvanā veicu typo. Un, tā kā tagad ir interesanti, izmantojot šādu rīku, jūs varat to izdarīt reālajā laikā, nevis atgriezties un apskatīt vēlāk, kas ir ļoti patīkami, lai to sāktu izmantot. Bet jā, tā ir lieliska analoģija teksta ievietošanai tekstapstrādes iekārtā, jo tas ir interesants modināšanas zvans, ja saprotat, ka esat pieļāvis dažus drukas kļūdas vai pat gramatikas kļūdas, vai ne?
Berts Scalzo: Tieši tā.
Dezs Blanšfīlds: Tātad, vai jūs tagad redzat vairāk uptick, domāju, es domāju, ka pēdējais jautājums, ko man uzdeva, pirms es pievērsos mūsu jautājumiem un atbildēm, iespējams, mūsu apmeklētājiem. Ja jūs domājat sniegt sava veida ieteikumus, kā rīkoties, lai to izdarītu - es pieņemu, ka tas ir retorisks - vai tas ir tā, ka jūs agri iekļūstat un to ieviešat, attīstoties, pirms attīstāties? Vai arī ir tā, ka jūs galvenokārt ceļaties, ceļaties, kaut ko uzbūvējat, tad ienācat un vēlāk to profilējat? Man ir aizdomas, ka tas ir gadījumā, ja agri iekļūstat un pārliecinieties, vai kods ir pareizi sagatavots. Vai tas ir tā, ka viņiem būtu jāapsver šī pēcpasūtīšanas daļa?
Berts Scalzo: ideālā gadījumā viņi to darītu jau sākotnēji, bet, tā kā visi atrodas kņadas pasaulē, kur viņiem vienkārši bija jāsagatavo lietas, viņi to parasti nedara, kamēr nav saskārušies ar izpildes problēmu, kuru viņi nevar atrisināt pievienojot vairāk centrālo procesoru un atmiņas virtuālajai mašīnai.
Dezs Blanšfīlds: Jā. Tātad, ja jūs es ātri varēšu pieminēt kaut ko interesantu? Jūs jau iepriekš minējāt, ka to var palaist no jebkuras vietas un aizmugurē var sarunāties ar datu bāzi. Tātad tas ir apmierināti ar tāda veida bimodālo koncepciju, par kuru mēs tagad runājam, par mākoņu uz vietas / ārpus telpām, arī pēc lietu izskata, dienas beigās, ja tas var sarunāties ar aizmuguri un redzēt kods, tas nav īsti vienalga, vai ne?
Berts Scalzo: Tieši tā, jā, jūs varat to palaist mākonī.
Dezs Blanšfīlds: Teicami, jo es domāju, ka tieši tur atrodas mūsu jaunā drosmīgā pasaule. Tātad, Ēriks. Es tagad atgriezīšos pie jums un redzēšu, ka mums šeit ir daži jautājumi, un es vēlos, lai mūsu klātesošie joprojām paliktu pie mums, kaut arī mēs jau esam pagājuši garām stundai.
Ēriks Kavanaghs: Jā, tur ir daži ļaudis, es izdarīšu tikai īsu komentāru: Bert, es domāju, ka metafora, tā analoģija, kuru jūs piešķirat pareizrakstības pārbaudei, ir atklāti izcili. Tas ir godīgi sakot, emuāra vai divu vērtībā, jo tas ir labs veids, kā noteikt kontekstu par to, ko jūs darāt, cik tas ir vērtīgs un kā tam vajadzētu būt labākajai praksei, izmantojot atkļūdotāju. regulāri, vai ne? Varu derēt, ka, izmetot to ārā, dažas galvas pamāj, vai ne?
Berts Scalzo: Absolūti, tāpēc, ka es viņiem saku: “Kāpēc es veicu savu dokumentu pareizrakstības pārbaudi? Es nevēlos, lai mani samulsinātu par muļķīgām pareizrakstības kļūdām. ”Nu, viņi nevēlas, lai viņu samulsinātu par muļķīgām kodēšanas kļūdām!
Ēriks Kavanaghs: Pareizi. Jā, patiesi. Ļaudis, mēs šeit esam nodedzinājuši stundu un piecas minūtes, tik liels paldies jums visiem par jūsu laiku un uzmanību. Mēs arhivējam visas šīs tīmekļa tērzēšanas sarunas, nekautrējieties atgriezties jebkurā laikā un pārbaudīt. Vislabākā vieta, kur atrast šīs saites, iespējams, ir techopedia.com, tāpēc mēs to pievienosim šim sarakstam šeit.
Un līdz ar to mēs jums atvadīsimies, ļaudis. Atkal lielisks darbs, Bert, pateicoties mūsu draugiem no IDERA. Mēs ar jums sarunāsimies nākamreiz, patiesībā mēs ar jums runāsim nākamnedēļ. Rūpēties! Labdien!
